Как оценить RAG-поиск по русским документам

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

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

Не копируйте в набор паспорта, договоры с персональными данными, production-переписку, ключи или внутренние номера. Подмените прямые идентификаторы синтетическими значениями и ограничьте доступ к исходникам. Обезличивание снижает риск, но не автоматически делает данные анонимными или законно передаваемыми; цель, срок хранения, договор и применимые требования проверяются отдельно. Базовые правила минимизации описаны в чек-листе перед LLM API.

Измеряйте retrieval отдельно от ответа

Первый слой оценки отвечает на простой вопрос: оказался ли нужный фрагмент среди первых результатов. Зафиксируйте recall@k, например долю запросов, где эталон найден в первых пяти фрагментах, и MRR для позиции первого релевантного результата. Метрики не доказывают юридическую или фактическую правильность всего ответа, зато локализуют проблему: низкий recall чаще связан с разбиением, эмбеддингами или фильтрами, а не с формулировкой модели.

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

Проверяйте ответ и отсутствие ответа

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

Разделяйте качество генерации и решение продукта. Модельный текст остаётся недоверенным выводом; ваш backend должен ограничить доступ к документам, сверить права пользователя и не выдавать соседний проект только потому, что результат похож по вектору. Если RAG вызывает инструменты, применяйте allowlist и серверную проверку аргументов. Вредный документ может содержать инструкции, но не получает право менять правила приложения; практики защиты разобраны в руководстве по prompt injection.

Сделайте прогон повторяемым

Версионируйте набор вопросов, индекс, стратегию chunking, фильтры, model ID, шаблон ответа и код оценщика. После изменения обновляйте только одну переменную за раз, иначе невозможно понять, улучшился ли поиск или случайно поменялась выборка. Храните агрегированные метрики и ссылки на обезличенные артефакты, а не полный пользовательский контент. Перед rollout задайте собственные пороги: например, минимальный recall для критичных категорий и максимум неподтверждённых ответов.

Если показатель ухудшился, не компенсируйте его бесконечными retry или молчаливой подменой модели. Остановите эксперимент feature flag, сравните failures по категориям и вернитесь к известной версии. RussiaAPI не обещает точность RAG, результат конкретного запроса или постоянный набор моделей. Сначала проверьте доступный каталог и контракт проекта, затем запускайте ограниченный smoke test. Выбор модели на тестовой выборке рассмотрен в статье об evals.

Server-side пример

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

export function scoreRetrieval(cases, retrievedIds) {
  let found = 0;
  for (const testCase of cases) {
    const top = new Set(retrievedIds[testCase.id] ?? []);
    if (top.has(testCase.expectedChunkId)) found += 1;
  }
  return {
    version: process.env.RAG_EVAL_VERSION ?? 'local',
    recallAtK: cases.length ? found / cases.length : 0,
    note: 'Метрика действует только для этой версии обезличенного набора.'
  };
}

Проверьте синтаксис командой node --check, добавьте аутентификацию своего маршрута, rate limit, ограничение входа и негативные тесты. Не логируйте тело запроса или заголовки только ради отладки.

Что фиксировать в рабочем контуре

До запуска назначьте владельца сценария, версию адаптера, внутренний ID операции, разрешённый model ID и измеримый критерий результата. В безопасном журнале обычно достаточно времени, HTTP-класса, нормализованного кода, latency и request ID, если он есть. Не записывайте Authorization, полный prompt, ответ пользователя, временные URL или выгрузку заголовков: для первичной диагностики они не нужны и повышают риск утечки.

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