Как собрать тестовый набор для ИИ-поиска по документам компании

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

Определите границу поиска

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

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

Соберите вопросы из реальной работы

Попросите трёх сотрудников записать по пять вопросов, с которыми они недавно открывали корпоративные файлы. Затем добавьте пять контрольных случаев. В них должны быть: устаревшая инструкция, неочевидный синоним, вопрос без ответа в базе, ограниченный документ и запрос, где нужны две разные страницы. Так получится двадцать заданий, которые проверяют не только совпадение слов, но и честность системы при пробелах. Не переписывайте вопросы на язык модели: сотрудник редко спрашивает «пункт 4.2 редакции 3».

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

Проверяйте две разные ошибки

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

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

Включите тесты на отказ и права

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

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

Считайте не процент «похожих ответов», а полезные исходы

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

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

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

Хватит ли двадцати вопросов?

Для первого решения о небольшом пилоте — да, если они представляют реальные задачи и включают трудные случаи. Для масштабного внедрения выборку придётся расширить по отделам и ролям.

Можно ли доверить оценку ответов другой модели?

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

Когда поиск лучше не запускать?

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