Аудит RAG: как найти слой, на котором ломается ответ по документам
Внутренний чат может ответить уверенно и красиво, но при этом опираться на устаревший документ, пропустить важное условие или показать человеку текст, к которому у него нет доступа. В RAG-системе это не одна общая ошибка «модель плохо знает базу». Ответ проходит несколько слоёв: файл распознаётся, режется на фрагменты, индексируется, ищется, проверяется по правам и только затем превращается в фразу.
Аудит нужен, чтобы не лечить проблему наугад. Если вопрос не находит нужный раздел, новая модель не исправит плохое распознавание PDF. Если правильный фрагмент найден, но в ответ не попало исключение, менять поиск тоже бессмысленно. Хорошая диагностика оставляет след: на каком слое нарушилась цепочка и какой тест это показал.
Соберите не «демо», а контрольную выборку
Начните с 15–20 вопросов, которые сотрудники действительно задают. Добавьте несколько обычных, несколько пограничных и несколько вопросов, на которые система должна честно ответить «в базе нет данных». Для каждого вопроса заранее укажите ожидаемый документ, точный раздел, пользователя с нужным уровнем доступа и короткий критерий правильного ответа.
Например, контрольный вопрос не просто «как оформить отпуск», а «какой срок согласования указан в действующей инструкции отдела Х, версия от конкретной даты». Если документов несколько, запишите, какой из них является источником истины. Так команда проверяет не впечатление от формулировки, а фактическую трассу ответа.
Не используйте в первом тесте всю корпоративную библиотеку. Возьмите один процесс и ограниченный набор документов. Когда ошибка найдена на маленькой выборке, её проще воспроизвести и исправить, чем спорить о тысячах файлов сразу.
Слой 1. Исходный документ читается так, как его видит человек?
Откройте текст, который попал в индекс, и сравните его с оригиналом. У сканов и PDF часто теряются таблицы, колонки, сноски, нумерация и пометки «кроме». Проверьте даты, числа, единицы и заголовки. Если в документе есть таблица с правилами, убедитесь, что строки и столбцы не смешались в одну последовательность слов.
Фиксируйте тип дефекта, а не только «документ плохой»: пустая страница, перепутанный порядок, пропавший колонтитул, некорректное распознавание числа, недоступное вложение. Иногда достаточно заменить источник на нормальный файл или добавить текстовую версию. Иногда потребуется исключить документ из поиска до исправления, чтобы он не создавал правдоподобные ошибки.
Слой 2. Фрагменты сохраняют смысл и реквизиты?
RAG ищет обычно не весь документ, а небольшие куски. Посмотрите на границы фрагментов для контрольного раздела. Остался ли рядом заголовок? Попадает ли исключение в тот же кусок, что и основное правило? Видна ли дата версии, владелец документа и ссылка на оригинал? Если ответ разбит так, что правило в одном фрагменте, а условие «не применяется к…» в следующем, система будет регулярно отвечать слишком широко.
Не существует универсального размера фрагмента. Хороший размер определяется структурой материала и типом вопроса. Для инструкции важен законченный шаг с условием и исключением; для справочника — карточка с определением; для таблицы — строка вместе с заголовками. Проверьте несколько вариантов на одинаковой контрольной выборке и сохраните тот, который меньше теряет контекст, а не тот, что быстрее строится.
Слой 3. Поиск находит нужное и не тащит лишнее?
Для каждого контрольного вопроса сохраните топ найденных фрагментов. Проверьте две вещи: есть ли среди них ожидаемый источник и не вытеснил ли его похожий, но старый или общий документ. Отдельно тестируйте запросы с сокращениями, разговорными словами, опечаткой и неполным контекстом — реальные сотрудники редко формулируют вопрос как заголовок из регламента.
Если поиск не находит точный фрагмент, не переходите сразу к смене модели. Сначала проверьте название документа, метаданные, версию, разбиение и сам запрос. Если фрагмент найден, но стоит низко, проблема может быть в ранжировании. Если в выдаче только шум, возможно, в индекс попало слишком много устаревших или дубль-материалов.
Не скрывайте эти различия одним показателем «точность». В журнале аудита полезны отдельные статусы: не прочитан источник, потеряна граница, не найден нужный фрагмент, найдено лишнее, ответ исказил найденный текст.
Слой 4. Права проверяются до генерации
Система не должна искать только «лучший ответ» — она должна искать лучший ответ среди разрешённых пользователю материалов. Возьмите одинаковый вопрос и выполните его под двумя тестовыми ролями. У сотрудника с меньшим доступом закрытый документ не должен появляться ни в цитате, ни в кратком пересказе, ни в названии файла, ни в подсказке об отсутствии ответа.
Проверяйте не только права на исходный документ, но и права на его производные: индекс, кэш, историю диалогов, экспорт результатов. Если в схеме доступа есть неясность, тестируйте на синтетических примерах до запуска на реальных документах. О том, как организовать базу знаний и не смешать версии, есть отдельный гайд.
Слой 5. Ответ не выходит за найденный контекст
Откройте фрагменты, на которые опирался ответ, и выделите каждое утверждение. Оно подтверждено прямо, является аккуратным выводом или добавлено моделью от себя? Если в источнике не указан срок, ответ не должен называть точную дату. Если правило относится к одному отделу, система не должна распространять его на всю компанию.
Попросите модель показывать источник и версию там, где это уместно. Но ссылка сама по себе не гарантирует верность: она может вести к документу, который не подтверждает соседнее предложение. Редакторская проверка ответа описана в протоколе проверки ответа нейросети; в RAG к ней добавляется обязательная проверка всей трассы поиска.
Для критичных вопросов настройте безопасный отказ. Лучше сказать «не нашёл подтверждённый документ, обратитесь к владельцу процесса», чем собрать ответ из похожих фрагментов. Это не снижает полезность системы — это защищает доверие к ней.
Закройте аудит конкретным решением
После прогона не составляйте бесконечный список улучшений. Для каждого дефекта запишите слой, пример вопроса, владельца, приоритет, следующее действие и способ повторной проверки. Исправьте один класс проблем, повторите ту же выборку и сравните результат. Только после этого расширяйте базу или меняйте модель.
RAG становится надёжнее не после одного эффектного ответа, а когда команда может объяснить его путь: какой документ был доступен, как он был прочитан, почему этот фрагмент найден и где заканчивается подтверждённая информация. Такой аудит превращает внутренний чат из чёрного ящика в систему, которую можно улучшать последовательно.
Карточка одного сбоя
Для каждого спорного ответа сохраните пять полей: вопрос и роль пользователя, ожидаемый источник, фактически найденные фрагменты, точку расхождения и повторный тест. Например, если поиск показал старую инструкцию, укажите её дату и метаданные, а не только пометку «неактуально». Такая запись сразу подсказывает, исправлять реестр, права, разбиение или ранжирование.
После исправления повторите исходный вопрос и один похожий, но с другой формулировкой. Если улучшился только знакомый пример, проблема ещё не решена. Закрывайте карточку лишь тогда, когда источник, версия и права совпадают в обоих прогонах, а вопрос вне области приводит к честному отказу.