Спросили в чате: «сколько мне спать / есть белка / бегать в неделю». Модель ответила ровно и быстро. Пользователь закрыл вкладку довольный. Через несколько дней эта же цифра оказалась в разговоре с врачом или в строке таблицы с расходами. Вопрос уже не «удобно ли в интерфейсе», а другой: кто в этой цепочке сказал «да, мы это утверждаем»?
Wikipedia и прочие открытые базы отвечают на вопрос «что люди вообще накопили про тему». Продукт отвечает иначе: что мы готовы произнести от имени сервиса в конкретном сценарии – здоровье, деньги, учёба, работа. Формулировки похожи, масштаб последствий – нет. Внутренняя база знаний тут не «мини-вики» и не галочка в roadmap ради модного RAG. Это скорее политика доверия: кто отбирает тексты, где они работают, что нельзя додумывать и чего человек вправе ждать, когда видит ответ под вашим логотипом
Мы делаем Voicaj – платформу, где голос и текст превращаются в задачи, финансы, здоровье, учёбу и остальные модули в одном контуре, а ответы ассистента в щекотливых темах опираются на отдельные правила и курируемую базу, привязанную к сценариям, а не на «всё, что модель вспомнила». Ниже разбор этой линии: зачем она нужна и где ломается, если притвориться, что достаточно одного умного чата
Рамка решает
У энциклопедии нет договора с вашим пользователем. У продукта он есть, даже если вы его нигде не PDF-или. Он живёт в тоне ответов в опасных зонах. Свой UI, своя подписка – мозг автоматически записывает ответ как позицию сервиса, а не как «модель погуглила». Это не баг человека, это норма
Отсюда простая мысль, которую легко забыть в погоне за фичами: база в продукте – курируемый слой, а не поток всего подряд. В открытом мире выигрывает охват. В приложении выигрывает согласованность: те же границы – и в голосе, и в коуче, и рядом с модулем, где цифры потом превращаются в графики. Не «всё, что семантически похоже», а то, что вы сознательно оставили в игре для этого типа запросов
Курирование тут не снобизм. Это признание, что уверенная ложь (гладкий текст + выдуманная норма) бьёт сильнее, чем сухое «в наших материалах этого нет – сходите к специалисту / откройте официальный документ». Неидеально звучит. Зато честно
Правила и материалы – разные вещи
В зрелом контуре почти всегда полезно развести два слоя, хотя бы в голове команды
Правила – это не статьи. Это то, что должно работать стабильно: не выдавать дозировки без утверждённого текста, не прикидываться налоговым консультантом, не ставить диагнозы из чата, явно обозначать границы. Выключить это «на пару дней ради теста» – значит поменять договор с пользователем, просто ещё никто не написал пост в поддержку
Материалы – уже контент: выдержки, справки, адаптации первоисточников. Их можно включать и выключать, версионировать, сужать по темам. За этим обычно стоит редакция и иногда юристы: что кладём в контекст модели, в каком виде, с какой датой «мы это пересмотрели»
Если слить всё в одну кучу, через месяц никто не вспомнит, где политика, а где статья про сон. Пользователь этого не видит, но чувствует: правила не должны исчезать вместе со статьями, которые вы вычистили вчера
Зачем привязывать знания к сценариям
«Сколько спать» в дневнике настроения и «как разложить нагрузку» в спорте – близкие слова, разный контекст. Финансовый вопрос рядом с учёбой не обязан тащить за собой пол-больницы справочников. Привязка к модулям или сценариям – не бюрократия ради чекбоксов. Это способ не кормить модель лишним и не создавать у человека ощущение, что приложение всё знает, потому что так удобнее скроллить
Зрелость на этом месте выглядит скучно: вы заранее решаете, где у вас вообще есть право говорить от имени «нашей базы», а где ответ остаётся общим и с оговорками. Не каждый экран обязан быть медицинским справочником. Но там, где вы разрешили себе опору на источники, – не размазывайте планку
RAG – инструмент, доверие – процесс
В коридоре на кухне RAG часто звучит как «чанки, эмбеддинги, подставили в промпт – готово». Инфраструктура нужна. Но пользователь не платит за косинус близости. Он платит за ощущение, что сервис не подставит там, где дорого ошибиться
Имеет смысл время от времени честно отвечать себе: что считаем допустимым источником; не воюют ли два документа друг с другом; не остаётся ли у обрезанного куска контекста «хвост», который модель дорисует сама; поймёт ли поддержка и пользователь, опирался ли ответ на ваш слой или это общая генерация
Если на эти вопросы тишина, снаружи всё знакомо: то попадание в десятку, то уверенная чушь, ночные правки системного промпта и ощущение, что продукт живёт на удаче
Что можно сделать без героизма
Внутри команды обычно хватает набора регрессионных вопросов по щекотливым темам после каждого изменения базы или промпта. Явная договорённость «в базе пусто – скажи об этом». Разделение ролей: кто утверждает правила, кто наполняет материалы, кто может включить «расширенный» режим
Снаружи – без лозунгов: не обязательно светить весь текст базы, но полезно как-то помечать, когда ответ стоит на внутренних материалах, и не смешивать это с вольными рассуждениями без различия. Люди учатся читать интерфейс; модель они боготворить перестают быстрее, чем кажется
Когда чат – только верхушка айсберга
Если ассистент не болтает в вакууме, а цепляет задачи, календарь, деньги, привычки, доверие расползается по всей поверхности. Голос превращается в записи, записи – в отчёты и напоминания. Цепочка «сказал –> появилось в данных –> открыл через месяц» бьёт сильнее любого скриншота переписки. База знаний в такой архитектуре – не украшение: она поддерживает смысл там, где пустота иначе заполняется фантазией модели
Победа на профильной площадке – скажем, в среде, где привыкли спрашивать «а на чём основано» про налоги, статистику, бизнес-анализ – тогда читается не как медаль, а как проверка: держится ли идея аккуратной работы с данными в разговоре с людьми, которые не любят красивые слова без основания
В конце
База знаний в продукте – не Wikipedia, потому что Wikipedia не отвечает за то, что человек сделал после ответа именно в вашем приложении. Это политика доверия: что сервис считает своим мнением, как разведены правила и материалы, как привязано к сценариям, что происходит в дырах и кто в команде за это держит ответ – важнее очередного апгрейда модели
Техника тут нужна. Но цель одна: чтобы спустя год продукт не вспоминали как место, где однажды красиво соврали цифрой без подписи
Автор: luvgreyair
