Туториал: мини-база знаний для RAG за неделю

Соберите документы одного процесса: инструкции, FAQ, регламенты, шаблоны писем, описания продуктов. Не смешивайте всё сразу. Узкая база быстрее показывает качество и не маскирует ошибки.

Сразу отметьте владельца документа, дату обновления и статус: актуальный, спорный, устаревший, нужен эксперт. Половина RAG-проблем начинается не в эмбеддингах, а в бардаке на входе.

Плохой chunking ломает даже хорошую модель. Фрагмент должен быть маленьким для точного поиска и достаточно полным, чтобы ответ не потерял условие или исключение.

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

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

После этого можно тестировать разные настройки retrieval и генерации, не споря на уровне вкуса. Вкус оставим дизайнерам, здесь у нас метрики.

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

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

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

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

Фрагменты должны сохранять смысл. Нельзя разрывать таблицу тарифов, пункт с исключениями или инструкцию, где условие находится в начале, а ограничение в конце. Если chunk слишком маленький, модель теряет контекст. Если слишком большой, retrieval забирает шум и ответ становится расплывчатым.

Практичный подход: разные стратегии для разных типов документов. FAQ можно резать вопрос-ответом. Регламент - пунктами с заголовками. Таблицы - строками или логическими блоками. Договоры и инструкции - с сохранением номера пункта и страницы. Потом всё проверяется на eval-вопросах, а не на ощущении, что «так красиво».

Не обязательно сразу запускать чат. Сначала можно проверить retrieval: задаём 30-50 вопросов и смотрим, какие фрагменты база возвращает. Если поиск не находит нужные источники, генерация только замаскирует проблему красивым текстом.

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

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

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

К концу недели результатом должна быть не просто демка с полем ввода. Нужны документы с метаданными, список владельцев, eval-вопросы, отчёт по найденным источникам, список конфликтов и решение, какие темы готовы к пилоту.

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