Подготовка базы знаний для RAG: с чего начать

Какие документы нужны для базы знаний

RAG (система, при которой ИИ перед ответом находит нужные фрагменты в ваших документах и опирается на них; проще говоря, ИИ отвечает по вашей базе знаний, а не по памяти) работает только на том, что вы в него загрузили. Поэтому первый шаг — решить, что вообще класть внутрь.

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

• Прайсы и условия. Цены, скидки, сроки, правила доставки и возврата.
• Инструкции и регламенты. Как проходит процесс, что можно, что нельзя.
• Частые вопросы. Готовые ответы из сообщений и тикетов — главный источник реалистичных формулировок.
• Каталог. Товары, услуги, состав, характеристики.

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

Как нарезать текст на фрагменты

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

Крупный кусок размывает смысл, и ответ уходит в сторону. Мелкий теряет контекст, и модели не хватает деталей. Единого золотого размера не существует, он зависит от типа документов, но правило простое: резать по смыслу, а не по числу символов.

• По структуре. Документ делится по заголовкам, разделам и абзацам, а не «через N символов».
• С запасом контекста. Конец куска захватывает хвост предыдущего, чтобы не терять мысль.
• Границы не рвут. Один раздел — одна единица, а не разрезанная надвое страница.

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

Чистота: убрать мусор и противоречия

ИИ не отличает важное от мусора в загруженном файле. Если внутри копипасты, повторов, старой шапки или пустых разделов, поиск спотыкается. Чистка — это не косметика, а точность.

Сначала соберите дубликаты. Один прайс в трёх папках, «финальная версия» и «финальная версия 2» — оставляем один источник истины. Потом уберите служебное: меню, подписи, повторяющиеся колонтитулы, заметки. Наконец, разрулите противоречия. Старый регламент говорит одно, новый другое, оба в базе — и ответ может опереться на любой. Приводим к одному актуальному варианту.

Эту работу часто недооценивают, а именно она сильнее всего двигает качество. Чистая база отвечает точнее, даже если нарезка не идеальна.

Актуальность: база устаревает

База знаний живёт своей жизнью. Цены меняются, регламенты переписываются, товары снимаются с продажи. Загруженный однажды документ остаётся в базе, и ИИ честно повторит его, даже если информация устарела.

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

Устаревшая выдача опаснее отсутствия ответа: ассистент говорит уверенно и при этом неверно. Свежая база — половина доверия к системе.

Метки и метаданные: зачем они нужны

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

• Источник. Название документа и ссылка, чтобы ИИ мог указать его, а человек проверить.
• Тип. Прайс, регламент, ответ на вопрос. Тип позволяет фильтровать поиск.
• Дата и версия. Чтобы отсекать устаревшее и показывать, на чём основан ответ.
• Область. Отдел или категория, ограничивающая выдачу.

Польза видна на практике. На вопрос клиента ассистент отвечает и добавляет «по прайсу от 1 октября». Пользователь понимает, чему верить, и открывает источник. Без меток ответ превращается в непроверяемое утверждение.

Чек-лист перед запуском

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

1. Собрали вопросы. Записали реальные обращения клиентов и выбрали, на какие отвечает ассистент.
2. Отобрали документы. В базе только то, что закрывает эти вопросы, без лишнего.
3. Нарезали по смыслу. Фрагменты идут по разделам, с контекстом, без разорванных мыслей.
4. Почистили. Убраны дубликаты, служебное и противоречия, остался один источник истины.
5. Разметили. Каждому куску присвоены источник, тип и дата.
6. Назначили владельца. Понятно, кто и как обновляет документы.
7. Протестировали. Прогнали реальные вопросы и проверили, что ответы точны и со ссылками.

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

Частые ошибки при подготовке

Большинство проблем с RAG — не в модели, а в базе. Перечислим то, что встречается чаще всего.

• Загружать всё подряд. «Вся база компании» звучит полезно, но мусор шумит и роняет точность.
• Резать по символам. Ровные куски на пятьсот знаков рвут мысль посреди предложения.
• Не обновлять. Загрузили один раз и забыли — база устаревает, ответы врут.
• Без меток. Нет источников, ответ нельзя проверить, доверие падает.
• Тестировать на «красивых» вопросах. Идеальные формулировки не показывают, как ассистент ответит на реальные корявые запросы. Гоняйте именно их.

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