База знаний для ИИ-бота: как запустить пилот без хаоса в документах

ИИ-бот не становится экспертом после загрузки папки с документами. Он ищет фрагменты, сопоставляет их с вопросом и формулирует ответ. Если в папке лежат старые цены, противоречивые регламенты и сканы без распознанного текста, бот лишь быстрее разнесёт эту путаницу по диалогам. Поэтому запуск начинается не с выбора модели, а с маленького сценария, где качество можно проверить.

Выберите один вопрос, а не всю компанию

Первый пилот лучше строить вокруг узкого потока: статусы заказов, правила возврата, доступ к внутреннему сервису или ответы для новых сотрудников. Возьмите историю реальных обращений и выпишите 20–30 повторяющихся вопросов. Это язык, которым говорят люди; названия папок и отделов для поиска менее полезны.

Не включайте в пилот темы, где ошибка дорого стоит: персональные решения, юридические претензии, платежи, медицинские советы или индивидуальные данные клиентов. Для них бот должен честно передавать диалог человеку. Граница «могу ответить / передаю оператору» — часть продукта, а не признак слабости.

Соберите карточки знаний

Одна карточка отвечает на один вопрос. В ней есть понятный заголовок, короткий ответ, условия, пошаговые действия, дата актуальности и владелец документа. Вместо таблицы «всё о доставке» лучше сделать отдельные карточки «как изменить адрес», «когда доступен самовывоз», «что делать при повреждении». Каждый фрагмент должен быть самодостаточным: в поисковой системе он может оказаться отдельно от соседнего абзаца.

Цифры пишите с контекстом: не «лимит 50 000», а «лимит возврата на карту — 50 000 рублей за операцию». У каждой цены, срока и правила должна быть дата или версия. Старую редакцию нельзя оставлять рядом «на всякий случай»: бот не понимает, какая из двух разных сумм историческая, а какая действующая.

Если исходник — скан или сложный PDF, сначала получите проверяемый текст и сравните его с изображением. Общие приёмы разобраны в статье как разобрать документ PDF нейросетью. Ошибка распознавания в тарифе или инструкции становится ошибкой ответа.

Разделите знания и права доступа

Клиентский бот не должен видеть внутренние инструкции, заметки о жалобах, персональные примеры и документы сотрудников. Внутренний помощник не должен получать больше, чем необходимо роли пользователя. Делайте отдельные наборы знаний и проверяйте доступы до загрузки, а не после инцидента. Удалите из примеров имена, телефоны, номера договоров и секреты; это не CRM. Базовые правила описаны в гайде как защитить данные в нейросети.

Проверьте до запуска

Прогоните через бота реальные вопросы из пилота и отметьте три вещи: нашёл ли он правильный документ, не добавил ли несуществующие детали, умеет ли честно передать вопрос человеку. Отдельно спросите то, чего в базе нет. Правильный ответ в таком случае — не уверенная догадка, а понятный следующий шаг.

После каждого ответа сохраняйте вопрос, найденный фрагмент и результат проверки. Если бот путается, сначала исправляйте карточку или убирайте противоречие, а не бесконечно усложняйте промпт. Перед публикацией изменений пригодится чек-лист из материала как проверить ответ ИИ перед отправкой.

Настройте размер фрагмента и связь между карточками

Слишком крупный фрагмент прячет ответ среди лишнего контекста, слишком мелкий теряет условие или исключение. Для пилота разбейте материалы по смысловым действиям, а не по одинаковому числу символов. В конце каждой карточки укажите, что делать при особом случае, и добавьте ссылку на связанную карточку. Затем возьмите десять вопросов, для которых оператор уже знает правильный фрагмент, и проверьте, попадает ли он в первые результаты поиска. Отдельно измерьте случаи, когда правильный ответ состоит из двух карточек: бот должен собрать их без противоречия. Это позволяет отделить проблему поиска от проблемы формулировки.

Поддерживайте базу как продукт

Назначьте владельца каждой карточки и включите обновление базы в обычный процесс: изменили условие — обновили карточку в тот же день. Раз в месяц просматривайте вопросы без ответа и устаревшие материалы. Так журнал диалогов превращается в план развития, а бот остаётся полезным после первого красивого демо.

Измеряйте качество, а не количество ответов

У пилота должно быть несколько понятных метрик: доля вопросов, на которые бот нашёл подтверждённый ответ; доля корректных передач оператору; число случаев, когда ответ пришлось исправить; и самые частые пробелы в карточках. Не оценивайте систему только по тому, как естественно она пишет. Вежливый, но неверный ответ хуже короткой честной передачи человеку.

Раз в неделю выбирайте несколько случайных диалогов и сверяйте их с источниками. Если бот добавил условие, которого нет в карточке, это отдельная ошибка даже при благополучном исходе. Если он ответил правильно, но слишком длинно, сократите саму карточку и проверьте повторно. Такой ручной контроль на раннем этапе быстрее всего показывает, какие документы действительно нужны.

Не меняйте одновременно знания, системные правила и интерфейс. Иначе после улучшения нельзя понять, что именно повлияло на ответ. Ведите короткий журнал версий: дата, изменённая карточка, причина и результат повторного теста. Это делает базу управляемой даже в небольшой команде.

Полезно заранее написать сценарий эскалации: что именно увидит пользователь, кому уйдёт вопрос, какие сведения нужно запросить у него и как оператор добавит новый ответ в базу после решения. Тогда «не знаю» не превращается в тупик, а становится нормальной частью сервиса.

Надёжная база знаний — это не огромный архив. Это небольшой набор актуальных, понятных и проверяемых ответов с ясными границами. Тогда ИИ-бот экономит время сотрудникам и клиентам, не подменяя уверенным текстом то, чего компания на самом деле не знает.