База знаний для ИИ-бота: как подготовить документы, чтобы бот отвечал по делу
Сценарий, который сейчас внедряют все: бот отвечает клиентам или сотрудникам по вашим документам. Технически это RAG — разбирали, как он устроен. Но техника — половина дела. Вторая половина, о которой говорят реже: что именно лежит в базе.
Ниже — практика подготовки базы знаний. Она одинакова для бота поддержки, внутреннего помощника по регламентам или консультанта по каталогу.
Главный принцип: бот не умнее своей базы
Модель не знает ваших цен, сроков и регламентов. Всё, что она может, — найти кусок вашего текста и пересказать его. Отсюда два следствия:
- Если ответа нет в базе — бот его выдумает или откажется. Оба исхода плохи, но выдумка хуже: она выглядит как ответ.
- Если в базе противоречие — бот выберет случайную из версий. Два документа с разными ценами означают, что клиенты получают обе.
Поэтому работа над ботом начинается не с промпта, а с ревизии документов.
Что включать в базу
Порядок важности, проверенный на практике:
- Ответы на реальные вопросы. Выгрузите историю обращений за пару месяцев и сгруппируйте. Топ-50 вопросов покрывает обычно 80% потока — под них и пишутся статьи базы.
- Условия и цифры. Цены, сроки, лимиты, условия возврата. То, что спрашивают дословно и где ошибка бота дороже всего.
- Пошаговые процедуры. «Как вернуть товар», «как сменить тариф». Ботам они даются отлично, если написаны шагами.
- Границы. Чего компания НЕ делает: не доставляет в такие-то регионы, не чинит такое-то. Без этого бот будет обещать несуществующее.
- Когда звать человека. Явный список тем, где бот должен передать диалог: претензии, юридические вопросы, нестандартные случаи.
Чего в базе быть не должно
- Устаревших версий документов. Главный источник противоречий. Старое — удалять, а не оставлять «на всякий случай».
- Внутренней кухни в клиентском боте. Если в базу внутреннего регламента попал документ «как отвечать на жалобы», клиентский бот однажды его перескажет. Базы для разных аудиторий — физически разные базы.
- Сканов и PDF из картинок. Текст, который не выделяется мышкой, для поиска не существует. Либо распознавать, либо переносить в текст.
- Гигантских таблиц «обо всём». Таблица на 200 строк с десятком колонок при нарезке на куски превращается в конфетти без заголовков. Большие таблицы дробить по темам и подписывать.
- Персональных данных. База знаний — не CRM. Никаких примеров с реальными именами и номерами договоров.
Как писать документы, которые бот понимает
Правила простые и совпадают с правилами хорошей документации для людей:
- Один документ — одна тема. Простыня «Всё о доставке и возвратах и оплате» отвечает на любой вопрос хуже, чем три отдельных документа.
- Заголовок = вопрос пользователя. «Как вернуть товар без чека» найдётся по запросу; «Раздел 4.2. Порядок урегулирования» — нет.
- Первый абзац содержит ответ. Дальше детали. Бот часто берёт именно начало найденного куска.
- Самодостаточные абзацы. Документ нарежется на фрагменты, и «как сказано выше» в отдельном куске повиснет в воздухе. Не жалейте повторить условие.
- Цифры словами контекста. Не «лимит — 50 000», а «лимит вывода — 50 000 рублей в сутки»: кусок с голым числом без единиц и предмета бесполезен.
- Даты актуальности в тексте. «Тарифы действуют с 1 июля 2026» — страховка от молчаливого устаревания.
Обновление: где боты тихо ломаются
Базу собрали, бот запустили — через полгода он вежливо советует прошлогодние условия. Устаревание — главный режим отказа таких систем, и защищаются от него процессом, а не технологией:
- Владелец у каждого документа. Меняются цены — конкретный человек обязан обновить конкретную статью.
- Обновление базы — пункт в чек-листе изменений. Поменяли условия доставки → обновили статью. Не «потом», а тем же днём.
- Регулярная ревизия хвоста. Раз в квартал просмотреть документы, которые давно не трогали: они первые кандидаты в устаревшие.
- Читайте логи бота. Вопросы, на которые он не нашёл ответ, — готовый список того, чего не хватает в базе. Это самый дешёвый источник улучшений.
Как проверить базу до запуска
Составьте 30–50 реальных вопросов (из той же истории обращений) и прогоните через бота. Смотрите на три типа ошибок:
| Симптом | Причина | Лечение |
|---|---|---|
| Выдумывает детали | Ответа нет в базе | Дописать документ |
| Отвечает то так, то так | Противоречие в документах | Найти и убить старую версию |
| Находит не тот документ | Заголовки не совпадают с языком вопросов | Переименовать под формулировки людей |
Отдельно проверьте вопросы «на границе»: то, чего в базе нет и быть не должно. Правильное поведение — честное «не знаю, передаю оператору», и его стоит прописать в системном промпте явно.
Что запомнить
- Бот не умнее базы: ревизия документов важнее промпта.
- Основа базы — ответы на реальные вопросы из истории обращений, а не оргструктура компании.
- Противоречия и старые версии — главный источник вранья бота. Старое удалять.
- Документы писать по правилу: одна тема, заголовок-вопрос, ответ в первом абзаце, самодостаточные куски.
- Устаревание побеждается процессом: владельцы документов, обновление в чек-листе изменений, ревизия раз в квартал.
- Логи неотвеченных вопросов — бесплатный план развития базы.
Как работает поисковая часть под капотом — в разборе RAG. Прикинуть объём и стоимость векторной базы под ваши документы можно в калькуляторе.