Как собрать базу знаний для ИИ-ассистента

Коротко: база знаний для ИИ-ассистента — это не «переписанный с нуля идеальный регламент», а структурированный набор реальных источников: переписок, FAQ, инструкций и кейсов, разбитых на короткие тематические блоки. Собирать её начинают не со всех процессов компании сразу, а с одного — там, где вопросы клиентов или сотрудников повторяются чаще всего. Ниже — порядок действий: от поиска повторяющихся вопросов до проверки базы на живых сценариях и типичных ошибок, которые превращают дорогой проект во внутреннюю галлюцинирующую игрушку.

Зачем вообще нужна отдельная база знаний

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

Какие вопросы собрать первыми

Частая ошибка — начинать с идеального документа «обо всём». Правильный старт — наоборот, узкий: выпишите 20–30 вопросов, которые сотрудники поддержки или отдел продаж слышат чаще всего. Источники для этого списка:

• история переписок в чатах поддержки и почте за последние 2–3 месяца;
• записи звонков или их расшифровки, если есть колл-центр;
• внутренние чаты, где сотрудники спрашивают друг друга «а как у нас принято делать Х»;
• тикеты в CRM с повторяющейся темой;
• вопросы на онбординге новых сотрудников — они честно показывают, где в документации пробелы.

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

Откуда брать контент: реальные источники, а не идеальные регламенты

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

• PDF и DOCX с регламентами, инструкциями, политиками;
• таблицы и Excel с тарифами, сроками, условиями по сегментам;
• успешные ответы саппорта — реальные формулировки, которые уже сработали на клиентах;
• презентации для отдела продаж с аргументацией и возражениями;
• кейсы и примеры, которые показывают нетиповые ситуации.

Там, где регламент расходится с реальной практикой (а так бывает почти всегда), фиксируйте актуальную практику — модель должна отвечать так, как компания действительно работает, а не так, как написано в документе пятилетней давности.

Как разбить знания на блоки и форматы

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

• разделите материал по смысловым категориям: тарифы, доставка, возвраты, техподдержка, юридические вопросы;
• внутри категории — отдельный короткий документ на каждый конкретный вопрос или сценарий, а не один файл на всю категорию;
• избегайте вложенной логики «если А, то читай документ Б» — модель хуже следует цепочкам ссылок между файлами, чем прямому ответу в одном месте;
• для таблично структурированных данных (цены, сроки, лимиты) используйте таблицы, а не описание прозой — так проще и человеку, и модели.

Такое дробление напрямую влияет на качество поиска по базе: чем точнее нарезка, тем точнее модель подтягивает именно релевантный фрагмент, а не весь документ целиком.

Какой технический подход выбрать: промпт, RAG или дообучение

На практике для базы знаний компании почти всегда используют один из трёх путей, и выбор между ними — не вопрос вкуса, а вопрос объёма данных:

1. Всё в промпт. Подходит, если база небольшая — несколько страниц. Весь контекст передаётся в системный промпт при каждом запросе. Просто, но упирается в лимит контекстного окна и становится дорого на больших объёмах.
2. RAG (retrieval-augmented generation). Основной подход для баз от нескольких десятков документов: система ищет релевантные фрагменты и подмешивает их в запрос перед ответом модели. Подробнее о механике — в статье как работает RAG простыми словами.
3. Дообучение модели. Имеет смысл только для узкоспециализированных задач с большим объёмом размеченных примеров — для типовой корпоративной базы знаний это избыточно и дороже, чем RAG.

Для подавляющего большинства компаний правильная точка входа — RAG поверх правильно нарезанной базы: он не требует переобучения модели при каждом обновлении документа и быстрее окупается.

Как проверить базу на реальных сценариях перед запуском

До того как показать ассистента клиентам, прогоните базу через те же 20–30 вопросов, с которых начинался сбор материала, плюс несколько пограничных случаев:

• задайте вопрос в формулировке, которую реально использует клиент, а не «правильным» языком документа;
• проверьте, что модель честно отвечает «не знаю» там, где в базе действительно нет данных, а не выдумывает ответ;
• протестируйте вопросы на стыке двух категорий — именно там чаще всего теряется контекст;
• сверьте цифры и условия в ответах с актуальным документом — устаревшие данные в базе дают уверенный, но неверный ответ;
• привлеките к тестированию сотрудника, который сам не писал базу — у него будут вопросы, до которых автор не додумался.

Частые ошибки при сборе базы знаний

Три вещи, которые чаще всего обнуляют качество готовой базы:

1. Базу собирают один раз и забывают. Тарифы меняются, регламенты обновляются — без владельца, который регулярно актуализирует документы, база через пару месяцев начинает врать уверенным тоном.
2. Загружают слишком объёмные файлы целиком. Вместо нарезанных по теме документов — один файл на 100 страниц «на всякий случай». Результат — модель либо не находит нужный фрагмент, либо тратит контекст на нерелевантный текст.
3. Не разделяют промпт и контент базы. Когда инструкции поведения модели и фактические данные перемешаны в одном месте, правку одного случайно ломает другое — держите эти два слоя раздельно, как и при обычной работе с промптами для бизнеса.

Частые вопросы

С какого объёма документов начинать делать RAG, а не промпт?
Ориентир — когда контент перестаёт помещаться в разумный системный промпт, обычно это больше 5–10 страниц текста или несколько десятков отдельных документов.

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

Как часто обновлять базу знаний?
Минимум — сразу при изменении тарифов, условий или регламентов; плюс плановая ревизия раз в месяц-два на предмет устаревших фрагментов.

Можно ли подключить к базе Excel-таблицы с ценами напрямую?
Да, табличные данные хорошо работают в базе знаний, но их тоже стоит разбить по смысловым блокам, а не грузить один огромный файл с десятками листов.

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

YUSMP Group: разработка веб-приложений с ИИ Попробовать генератор ответов