Что загрузить в RAG: аудит базы знаний до выбора векторной БД

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

Начните с действий, ради которых открывают бота

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

Затем попросите владельца процесса показать источник, по которому сотрудник действительно должен действовать. Отсутствие такого источника — самостоятельный результат аудита. Его нельзя исправить настройкой эмбеддингов. В плане проекта появится задача подготовить документ и назначить владельца.

Постройте карту покрытия

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

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

Выберите процесс, для которого есть основания ответа

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

tasks = [
 {"process": "onboarding", "task": "Доступ", "source": "IT-1", "owner": "IT", "status": "ready", "next": "index"},
 {"process": "onboarding", "task": "Оборудование", "source": "IT-2", "owner": "IT", "status": "ready", "next": "index"},
 {"process": "travel", "task": "Командировка", "source": None, "owner": "HR", "status": "missing", "next": "write guide"},
 {"process": "travel", "task": "Возврат расходов", "source": "FIN-1", "owner": "Finance", "status": "repair", "next": "fix form link"},
]
processes = sorted({t["process"] for t in tasks})
eligible = [p for p in processes if all(t["status"] == "ready" and t["source"]
            for t in tasks if t["process"] == p)]
backlog = [{"task": t["task"], "owner": t["owner"], "next": t["next"]}
           for t in tasks if t["status"] != "ready"]
assert eligible == ["onboarding"] and len(backlog) == 2
print({"pilot": eligible, "knowledge_backlog": backlog})

Выберите первый полезный контур

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

У источников, готовых к загрузке, сохраните постоянный ID, владельца и дату проверки. Файл может переехать в другую папку; связь с задачей пользователя должна пережить это перемещение. Для отсутствующих источников назначьте следующий шаг и человека, который его выполнит. Так карта станет рабочим планом, а не разовой презентацией.

Перед запуском попросите нескольких сотрудников решить выбранные задачи с помощью исходных документов. Сохраните места, где они застряли. Затем повторите те же задачи с помощником. Бот может сократить поиск, но плохо написанное правило придётся исправлять у владельца процесса.

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

Продолжить проект на практике

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

Откройте программу курса и выберите следующий этап своего проекта.

По теме: Гибридный поиск для RAG: BM25, векторы и расчёт RRF.