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