2026-05-10 · Обновлено 2026-07-22

[!NOTE] Автоматический перевод Эта статья была автоматически переведена с оригинальной английской версии.

Оценка RAG: показатели для каждого этапа работы производственной системы RAG

Часть 1 серии для производственной среды RAG

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

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

!!! Совет: «Хотите пропустить описание и сразу запустить код?»

Запускаемый код [`slavadubrov/rag-evals-demo`](https://github.com/slavadubrov/rag-evals-demo) репозиторий применяет эти метрики к SciFact. `make eval` запускает набор тестов, и `make benchmark` Сравниваются конфигурации чанкинг, эмбеддинг и LLM. Ноутбуки с номерами от 00 до 09 предназначены для изоляции каждого из этих показателей. В демонстрации используется встроенная реализация Qdrant, поэтому нет необходимости в использовании Docker.

Кратко:

• Оценка определяет сущность системы. Этап без метрик — это этап, который функционирует в режиме бесшумного сбоя.
• Полезная стек-архитектура для оценки охватывает процесс входных данных, retrieval, процесс генерации граундинг, проверку соответствия онтологии и анализ сигналов системы. RАГИ, TruLens, DeepEval, Arize Phoenix, и TREC 2024 RAG дорожка Мы предоставляем необходимые инструменты. Однако они сами определяют критерии оценки для вас.
• В случае методов, основанных на метаданных и онтологиях RAG, неправильная метка или нестабильный жесткий предикат могут свести показатель воспроизводимости до нуля. Стандартный метод Recall@k позволяет выявить такую потерю, поскольку он сохраняет исходный золотой набор данных. Метрика фильтрации ошибочных исключений помогает определить причину проблемы, тогда как показатель точности может казаться в порядке, поскольку модель честно указал «Я не знаю».

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

Таблица решений для оценки RAG

Используйте эту таблицу в качестве отправной точки перед тем, как выбрать фреймворк. Подходящая метрика определяется способом возникновения сбоя, который необходимо выявить, а не названием инструмента.

Для более краткого сравнения инструментов см. Лучшие инструменты и метрики оценки RAG в 2026 году.

Часть 1: Определите критерии успеха до разработки архитектуры

Составьте набор эвал перед диаграммой архитектуры. Он позволяет задать измеримую цель для каждого последующего выбора компонентов.

Вы не можете выбирать между алгоритмами BM25 и плотными retrieval, рекурсивными и семантическими чанкинг, а также между методами Cohere Rerank и BGE, пока не определите, что именно вы пытаетесь оптимизировать. Понятие «лучших ответов» само по себе не является критерием оценки. Хорошим примером формулировки целей может служить требование к точности: «точность ≥ 0.85 для набора из 200 тестовых запросов, охватывающего три основные цели использования системы, при этом время обработки на уровне p95 латентность должно быть менее 1.5 секунд, а коэффициент ложных исключений — менее 2%». Указанные здесь числа являются лишь примерами; главное — наличие четких критериев для оценки качества, степени охвата, латентность и эффективности фильтрации.

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

Три слоя пайплайн и два режима работы

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

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

Эти слои определяют место возникновения сбоя. Термины offline и online указывают на момент выполнения проверки и на набор данных, по которым она производится. При оффлайн-оценке используется фиксированный датасет с известными эталонными значениями; такой подход обеспечивает воспроизводимость результатов и применяется при выборе компонентов, проведении сравнений типа A/B и на этапах контроля качества в рамках CI. Онлайн-оценка анализирует данные из реального трафика, учитывая процессы регенерации, время пребывания на странице, явную обратную связь и дрейф запросов. Этот метод более шумный и требует более сложной инструментализации.

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

На уровне компонентов против полного цикла обработки

Существуют две распространённые ошибки. Оценка исключительно в режиме «от конца до конца» позволяет сделать вывод о неисправности системы, но не указывает на место сбоя. Оценка только отдельных компонентов может показать, что все части работают корректно, при этом вся система всё равно терпит неудачу. Решением является использование нескольких ключевых метрик в режиме «от конца до конца» для принятия решений о допустимости или отклонении, наряду с метриками компонентов для постановки диагноза. Метрики Retrieval позволяют выявлять ухудшение качества работы модуля поиска информации, а метрики генерации — ухудшение качества работы модуля генерации текста. Проверка корректности ответа в режиме «от конца до конца» помогает обнаруживать проблемы с интеграцией.

Справочный вариант фреймворки (тур с жёстко заданным маршрутом)

Мой стандартный набор инструментов включает RAGAS для работы с лексиконом метрик, DeepEval для реализации этапов контроля качества в процессе CI, Phoenix для эксплуатации в продакшене трейсинг, а также пользовательский код для расчёта метрик, специфичных для конкретной онтологии. Любая начальная конфигурация со временем окажется недостаточной. Выбирайте фреймворк, который облегчит разработку собственных метрик.

Для бенчмарки используйте BEIR (Thakur et al., NeurIPS 2021) — для реализации обобщения без обучения на примерах retrieval. MTEB для обеспечения общего качества эмбеддинг. MIRACL для мультиязычного retrieval, а также TREC 2024 RAG дорожка для оценки в режиме «от начала до конца» RAG.

Часть 2: Соотнесение точек оценки с пайплайн

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

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

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

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

Часть 3: Оценка процесса поступления данных

Большинство сбоев RAG в продакшене возникают на этапе загрузки данных. Система корректно обрабатывает чистые тестовые документы, но терпит неудачу при работе с реальными PDF-файлами, сканами, таблицами и страницами из «грязных» корпусов данных.

Получение и парсинг документов

Что измерять:

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

• OCR точность: CER (Character Error Rate) и WER (Word Error Rate) — стандартные метрики качества речи/OCR:

  $$\text{CER} = \frac{S + D + I}{N}, \qquad \text{WER} = \frac{S_w + D_w + I_w}{N_w}$$

  где $S$, $D$, $I$ обозначают замены, удаления и вставки на уровне символов, а $N$ — количество исходных символов (подстрочный индекс $w$ применяется для версии слова). Не следует применять один и тот же границы CER ко всему корпусу данных; её необходимо калибровать с учётом класса документа и степени потерь в результатах ответов; печатный текст, рукописный текст и многоязычные материалы имеют разные профили ошибок. Вычисления выполняются jiwer (jiwer.cer(refs, hyps), jiwer.wer(refs, hyps)) или HuggingFace evaluate. Для корпусов оценки, FUNSD и SROIE они являются публичными бенчмарки.

  from jiwer import cer, wer
  
  refs = ["Mars has two moons, Phobos and Deimos."]
  hyps = ["Mars has two m00ns, Phobos and Deirnos."]
  
  print(f"CER = {cer(refs, hyps):.3f}")  # CER = 0.105
  print(f"WER = {wer(refs, hyps):.3f}")  # WER = 0.286

• Точность извлечения таблиц: TEDS (похожесть, основанная на расстоянии деревьев) позволяет оценить степень сходства предсказанной деревянной структуры HTML-таблицы с исходной, нормируя результат в зависимости от размера более крупной из структур. Из Чжон и др., 2020 (PubTabNet):

  $$\text{TEDS}(T_a, T_b) = 1 - \frac{\text{EditDist}(T_a, T_b)}{\max(|T_a|, |T_b|)}$$

  TEDS использует как структуру (строки, столбцы, спаны), так и содержимое ячеек; TEDS-S удаляет содержимое и оценивает исключительно структуру. Пример реализации: PubTabNet’s teds.py (использует) apted внутри алгоритма). Что касается корпусов для оценки, см. PubTabNet. FinTabNet, а также SciTSR. Наивные парсеры часто терпят неудачу при обработке таблиц; бенчмарк перед тем, как полагаться на них.

• Сохранение макета/структуры: порядок заголовков, целостность списков, последовательность чтения в многоколоночных PDF-документах. Используйте DocLayNet для меткированного бенчмарк. Готовое решение для сравнения может спан парсер элементов, такой как unstructured, библиотека для работы с PDF, такая как pymupdf, и парсер VLM вроде этого docling.

Сравните различные семейства парсеров: например, базовую версию Tesseract, реализацию на основе VLM типа OCR модель, а также вариант от вашего поставщика. Для тестирования используйте стратифицированный набор реальных документов с фиксированным разрешением DPI, включающий чистые сканы, фотографии, таблицы, многоязычный текст, математические формулы и рукописный текст. Предоставьте показатели CER или WER для каждого типа документов, а также значение TEDS для страниц с таблицами.

Очистка и нормализация

• Точность удаления шаблонного кода: точность/покрытие по сравнению с шаблонным кодом, помеченным людьми спаны. Агрессивное удаление приводит к потере значимого контента; ленивое удаление загрязняет эмбеддинги. Инструменты для сравнения: trafilatura, jusText, Resiliparse. Барбареси (2021) бенчмарки — прямое сравнение этих подходов.

• Нормализация Unicode: процент документов, дающих идентичные результаты применения форматов NFC и NFKC (рассчитывается с использованием стандартной библиотеки) unicodedata.normalize) это полезный сигнал дрифта. Именно несоответствия между символами нулевой ширины и похожими на них символами приводят к снижению показателя воспроизведения retrieval.

• Точность обнаружения языка: показатель F1 на маркированной мультиязычной выборке. Имеет критическое значение для мультиязычных индексов. Используйте fasttext-langdetect (Facebook’s lid.176), lingua-py, или cld3. FLORES-200 Этот инструмент предоставляет тексты для оценки на 200 языках, однако диапазон тестирования должен определяться с учётом состава языков в вашей продакшен-среде.

• Эффективность дедупликации (MinHash / LSH): точность/полнота вашего детектора близких дубликатов на основе ручно маркированного набора данных. Основная идея заключается в оценке сходства по методу Джаккара J(A, B) = \frac|A ∩ B|}{|A ∪ B|<$EOC_TEXT>Передача данных между наборами «шинглов» документов с использованием$k$ хешей от случайных перестановокБродер, 1997) и объединение почти одинаковых записей с помощью метода LSH-бандингаИндик и Мотвани, 1998). Проанализируйте количество хешей и порог Жаккара в вашем корпусе данных. Отдельно отслеживайте уровень ложных объединений (которые приводят к повреждению ответов) и уровень упущенных объединений (которые приводят к избыточному использованию пространства индекса). datasketch представлен реализованный ниже код; его параметры носят иллюстративный характер:

  from datasketch import MinHash, MinHashLSH
  
  def shingles(text: str, k: int = 5) -> set[str]:
      text = text.lower()
      return {text[i:i + k] for i in range(len(text) - k + 1)}
  
  def to_minhash(text: str, num_perm: int = 128) -> MinHash:
      m = MinHash(num_perm=num_perm)
      for s in shingles(text):
          m.update(s.encode("utf-8"))
      return m
  
  docs = {
      "d1": "Mars has two moons, Phobos and Deimos.",
      "d2": "Mars has two moons, Phobos and Deimos!",   # near-dup
      "d3": "Curiosity rover landed on Mars in 2012.",
  }
  
  lsh = MinHashLSH(threshold=0.8, num_perm=128)
  for did, text in docs.items():
      lsh.insert(did, to_minhash(text))
  
  print(sorted(lsh.query(to_minhash(docs["d1"]))))  # ['d1', 'd2']

• Очистка PII: точность и воспроизводимость, рассчитываемые отдельно для каждого типа сущностей (электронные адреса, номера социального страхования, имена, адреса). Ошибки воспроизводимости создают риски несоответствия нормативам; ошибки точности снижают качество ответов. Точку равновесия необходимо определить с юридической командой. Среди возможных инструментов — Microsoft Presidio, scrubadub, или отрегулированная модель NER модель на наборе с метками.

Чанкинг регулирует качество retrieval

Чанкинг может приводить к появлению разрыва в многоточечном восстановлении данных даже при неизменности значения эмбеддинг-модель. В Поставщик чипов NVIDIA для 2024 года бенчмарк, На уровне страницы чанкинг показал наивысшую точность и минимальную дисперсию для документов с разделением на страницы. Следует рассматривать этот результат как свидетельство эффективности данного метода в рамках тестируемого корпуса, а не как универсально оптимальное решение.

Семантические чанкинг группируют соседние предложения на основе эмбеддинг сходства и разделяют их в местах с низким уровнем сходства. В фреймворке LangChain SemanticChunker и LlamaIndex’s SemanticSplitterNodeParser Реализуйте эту стратегию. Она позволяет повысить точность восстановления данных при использовании фиксированных окон в тех случаях, когда важны границы тематических областей.

Рекурсивное разделение символов начинается с пробования разбиения на абзацы, затем — на предложения, и далее — на слова, пока каждый чанк не будет соответствовать заданному размеру. LangChain’s RecursiveCharacterTextSplitter реализуется последовательность обработки. Выберите подходящие значения параметров окна и перекрытия в зависимости от структуры вашего документа, после чего позвольте алгоритму «золотого набора» определить окончательные значения.

Метрики для отслеживания:

• Чанк коэрентность: $\text{coherence} = \overline{\cos(s_i, s_j)}_{\text{внутри}} - \overline{\cos(s_i, s_j)}_{\text{через границу}}$, где $s_i$ — предложения эмбеддинги. Здоровые чанки должны быть похожими друг на друга внутри структуры и отличаться при переходе через границы. Расчёт выполняется с использованием sentence-transformers плюс scikit-learn’s cosine_similarity.
• Качество границы: ручная оценка «является ли это разумным разрезом?» для образца, плюс структурная проверка на то, чтобы чанки не разделяли таблицы, списки или нумерованные разделы.
• Оптимальный размер чанк: протестируйте размеры токен (128, 256, 512, 1024) и построите график Recall@k в зависимости от размера на вашем золотом наборе. Выберите точку перегиба кривой; не следует опираться на рекомендации из учебников.
• Эффективность перекрытия: изменяйте значения коэффициента перекрытия и измеряйте значение Recall@k. Прекратите увеличивать степень перекрытия, когда локальная кривая воспроизведения станет плоской или затраты на дублирование превысят получаемую выгоду.
• Надежность атрибуции Чанк: процент чанки, у которых сохраняется верифицируемый указатель источника (номер страницы, анкор раздела, ID документа). Для обеспечения аудитоспособности это крайне важно.
• Поздняя vs. ранняя чанкинг: позднее чанкинг (Günther et al., 2024) предусматривает встраивание всего документа с последующей его сегментацией, что позволяет сохранить глобальный контекст (пример реализации приведён в) jina-embeddings-v3). Контекстуальный Retrieval (Anthropic, 2024) добавляет в начало каждого чанк контекст, сгенерированный с помощью LLM. Оба этих фактора увеличивают затраты. Перед тем как применять любой из них, необходимо оценить Бенчмарк вашего корпуса данных.

Мое мнение: структурный чанкинг (разделение по заголовкам, таблицам и разделам — реализуемое парсерами вроде unstructured.io Использование таких методов, как просмотр синтаксического дерева, уже сгенерированного парсером, остаётся недостаточно распространённым. Если ваши документы имеют определённую структуру, следует воспользоваться ею до того, как применять гистерики оценки сходства. Рекурсивное разделение символов является базовым подходом; применение семантического чанкинг оправдано лишь в случае неструктурированных текстов из-за связанной с этим дополнительной нагрузки.

Извлечение и обогащение метаданных

• NER точность/воспроизводимость/F1: по типу сущности, на помеченном подмножестве данных. В соответствии со стандартами CoNLL/MUC. Рассчитывается с использованием seqeval (from seqeval.metrics import f1_score) для версии, учитывающей метки BIO/IOB, либо библиотеку scikit-learn для сравнений спан-множеств. CoNLL-2003 и OntoNotes 5.0 являются стандартными эталонными корпусами данных.
• F1 для извлечения отношений: имеет ещё более важное значение для систем, основанных на онтологиях. Необходимо вручную маркировать набор данных, структурированный по типам отношений и классам документов. TACRED и DocRED являются публичными решениями бенчмарки; среди кандидатов на реализацию можно выделить opennre и spaCy связь пайплайны.
• Точность извлечения заголовка/названия: точное совпадение плюс нормализованная степень схожести по алгоритму Левенштейна ($1 - \frac{\text{edit\_dist}(a, b)}{\max(|a|, |b|)}$) по сравнению с истинными значениями — python-Levenshtein или rapidfuzz предоставить их оба в рамках одного вызова.
• Сохранение иерархических метаданных: процент чанки, у которых корректно сохраняются родительская секция, родительский документ и путь преемственности. Именно этот показатель определяет, сможет ли ваш RAG отвечать на вопросы типа «Что говорит дочерний элемент политики X?».

Генерация Эмбеддинг

• Модель выбор бенчмарки: MTEB для оценки общей эффективности (ключевым показателем является nDCG@10); пакет MTEB для Python позволяет воспроизвести лидерборд локально), BEIR для генерализации в режиме zero-shot. MIRACL для мультиязычных задач. Лучший retrieval модели кластер в узком диапазоне показателя nDCG@10, однако значения метрики MTEB на английском языке плохо предсказывают эффективность работы моделей на языках с ограниченными ресурсами.
• Оценка для конкретной области: не следует рассматривать общий ранг бенчмарк как результат, характерный для данной области. Необходимо сформировать «золотой набор» для данной области на основе её матрицы покрытия и уровня неопределённости, допустимого для принятия решения. После этого следует переоценить кандидатов модели в рамках этого набора. ranx или pytrec_eval. Набор доменов может изменить порядок в топ-листе, поэтому необходимо опубликовать фрагмент датасет, протокол retrieval, а также интервал уверенности вместе с полученным результатом.
• Эмбеддинг обнаружение смещения: отслеживание смещения в распределении на основе показателя KL или метода, основанного на модель, между фиксированным эталонным окном и динамическим производственным эмбеддинги; также измеряется стабильность по принципу ближайших соседей для заданного набора тестовых данных. evidently и alibi-detect Реализовать детекторы, основанные на модель, а также статистические детекторы. Evidently’s сравнительное исследование Это лишь одна из оценок поставщика; сравнивайте методы на основе известных сдвигов в вашем собственном эмбеддинги.
• Многовекторный подход против одновекторного: задержка во времени обработки позволяет сохранять представления на уровне токен, вместо того чтобы сводить каждый документ к одному вектору; ColBERT это канонический дизайн, имеющий реализации для сравнения RAGатуль и PyLate. Такая более детальная представление увеличивает затраты на построение индекса и retrieval. Перед тем как внедрять её, необходимо сравнить качество результатов, объём хранения данных и латентность с показателями базовой модели, использующей один вектор, на том же наборе доменов.

Построение индекса

• Recall@k при аппроксимации: сравнивайте индекс кратчайших ближайших соседей (ANN) в аппроксимированной реализации с точной базовой моделью методом перебора при том же значении k — в FAISS, это IndexHNSWFlat (или) IndexIVFFlat) против IndexFlatIP/IndexFlatL2. Укажите допустимую потерю воспроизведения в соответствии с вашим бюджетом качества на последующей стадии обработки. The ann-benchmarks Проект отслеживает кривые воспроизводимости и QPS по принципу Парето в различных библиотеках.
• HNSW настройка: HNSW (иерархический навигируемый малый мир — слоистая графика близости; см. Малков и Яшунин, 2018, реализовано в hnswlib, механизм FAISS IndexHNSWFlat, и большинство векторных БД) предоставляют три настраиваемых параметра: M (разветвление графа) efConstruction (ширина кандидата во время сборки) efSearch (ширина кандидатов во время запроса). Начните с заданных по умолчанию значений из документации библиотеки, затем постепенно изменяйте параметры, пока кривая воспроизводимости–латентность не будет соответствовать требованиям вашего набора для оценки.
• Настройка IVF: IVF (Inverted File index — разбиение векторов с помощью алгоритма k-means) nlist клетки, а затем во время выполнения запроса сканировать nprobe соседние ячейки; см. документацию FAISS к IndexIVFFlat и IndexIVFPQ). Проведение сканирования nlist и nprobe против показателя восстановления при точном поиске и латентность. Бенчмарк запросы с фильтрацией обрабатываются отдельно, поскольку семейства индексов и векторные базы данных реализуют процесс применения фильтров по-разному.
• Задержка обновления свежести: время от сохранения документа до его возможности получения. Необходимо отслеживать значения p50 и p99. Для систем, подчиняющихся нормативным требованиям, также следует учитывать процент запросов, обрабатываемых с использованием устаревших индексов.

Часть 4: Оценка во время выполнения запроса

В сегменте времени запроса хранятся метрики, позволяющие диагностировать путь retrieval. Одного только показателя Recall@k недостаточно для определения того, привело ли к сбою переписывание данных, фильтрация, реранкинг или формирование контекста.

Понимание запроса и его переписывание

• Качество расширения запроса: улучшение показателя Recall@k на золотом наборе при использовании расширенного запроса по сравнению с исходным. Перед тестированием необходимо заранее определить минимальную полезную прибавку и степень её неопределённости. Если расширение не преодолевает этот локальный критерий, оно не оправдывает своего использования латентность и связанных с ним затрат. Традиционные базовые методы вроде PRF (псевдообратной связи по релевантности) RM3 и Bo1 эти проверки на корректность по‑прежнему полезны; метод расширения, основанный на LLM, должен превзойти их по эффективности.
• Оценка HyDE: HyDE (Gao et al., 2022) генерирует гипотетический ответ с использованием LLM, встраивает его в результат и осуществляет поиск на его основе. Этот подход приводит к дополнительной генерации латентность, что создаёт новые возможности для возникновения сбоев. Необходимо отдельно оценить показатель Recall@10 для данных из той же области, данных из других областей и данных с низкой степенью уверенности, после чего определить, следует ли такой результат направлять по стандартному пути, использовать альтернативный вариант или исключить его полностью.
• Генерация множественных запросов: объединение результатов по принципу Recall@k для N вариантов переписывания по сравнению с одним запросом. Проводится сканирование значений N с целью выбора оптимальной точки на границе между показателем воспроизведения и латентность. Реализации: LangChain’s MultiQueryRetriever, LlamaIndex’s QueryFusionRetriever.
• Точность классификации намерений: стандартные показатели точности/воспроизводимости/F1 для каждого намерения (рассчитываются с sklearn.metrics.classification_report), однако ключевой показатель — это точность маршрутизации: вызывается ли правильный нижестоящий пайплайн?
• Адаптивный роутинг: Адаптивный-RAG (Aвторы Jeong и др., NAACL 2024) показывают, что не каждый запрос требует применения одинаковой стратегии retrieval. Необходимо отслеживать точность роутер в качестве критерия классификации на основе меткированного набора записей, обозначающих сценарии «не требуется retrieval / однократная обработка / итеративный подход».

Метрики Retrieval

Это базовые метрики. Если вы не отслеживаете их, вы не сможете определить, улучшается ли retrieval.

Формулы для справки (бинарная релевантность с множеством релевантных документов $R_q$ для запроса $q$, причём $\text{rel}_i = 1$, если $i$-й полученный документ находится в $R_q$):

Для оценки степени релевантности $\text{rel}_i \in \{0, 1, 2, \dots\}$; бинарный nDCG представляет собой специальный случай, используемый в приведённом ниже коде. MAP — это среднее по всем запросам значений \text{AP}_q = \frac{1}{|R_q|\sum_{i: \text{rel}_i = 1} \text{Precision@}i. См. Мэннинг, Рагхаван, Шютце, «Введение в поиск информации», Глава 8 — развёртывание доказательств.

Для кода, выпускаемого в продакшн, используйте ranx, pytrec_eval, или ir_measures — они реализуют весь набор метрик TREC и корректно обрабатывают понятие степени релевантности. Устанавливайте цели для выпуска на основе реалистичного золотого набора данных, качества ответов на выходном уровне и стоимости ошибочного результата. Не берите пороговые значения из учебных материалов.

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

from math import log2
from statistics import mean

# synthetic gold set: query_id -> set of relevant doc ids
gold = {
    "q1": {"d3"},
    "q2": {"d7", "d2"},
    "q3": {"d11"},
    "q4": {"d5"},
}

# ranked retrieval results: query_id -> ranked list of doc ids (top-10)
runs = {
    "q1": ["d8", "d3", "d1", "d4", "d2", "d9", "d6", "d10", "d12", "d13"],
    "q2": ["d2", "d6", "d4", "d7", "d1", "d3", "d8", "d11", "d5", "d9"],
    "q3": ["d11", "d2", "d3", "d4", "d1", "d6", "d7", "d8", "d10", "d12"],
    "q4": ["d1", "d2", "d3", "d6", "d8", "d9", "d10", "d12", "d13", "d14"],
}

def recall_at_k(ranked, gold_set, k):
    if not gold_set:
        return 0.0
    hit = sum(1 for d in ranked[:k] if d in gold_set)
    return hit / len(gold_set)

def reciprocal_rank(ranked, gold_set):
    # MRR contribution per query: 1/rank of the first relevant doc.
    for rank, d in enumerate(ranked, start=1):
        if d in gold_set:
            return 1.0 / rank
    return 0.0

def ndcg_at_k(ranked, gold_set, k):
    # binary relevance: rel ∈ {0, 1}
    gains = [1.0 if d in gold_set else 0.0 for d in ranked[:k]]
    dcg = sum(g / log2(i + 2) for i, g in enumerate(gains))
    # ideal DCG: all gold docs ranked first, capped by k
    n_gold_in_topk = min(k, len(gold_set))
    idcg = sum(1.0 / log2(i + 2) for i in range(n_gold_in_topk))
    return dcg / idcg if idcg else 0.0

K = 5
print(f"Recall@{K}: {mean(recall_at_k(runs[q], gold[q], K) for q in gold):.3f}")
print(f"MRR:       {mean(reciprocal_rank(runs[q], gold[q]) for q in gold):.3f}")
print(f"nDCG@{K}:  {mean(ndcg_at_k(runs[q], gold[q], K) for q in gold):.3f}")
# Recall@5: 0.750
# MRR:       0.625
# nDCG@5:    0.627

Это и есть ваша CI-шлюзовая точка retrieval. Подключите её к быстрому поднабору тестов, ориентированному на измерение уровня покрытия кода, при каждом создании PR, а полный набор тестов — к более медленной шлюзовой точке сборки для релизов. Заблокируйте процесс слияния, если значение заранее заданного метрического показателя превысит установленный лимит на возникновение регрессий.

Сопутствующий репозиторий фиксирует именно эти значения выше.Recall@5 = 0.750, MRR = 0.625, nDCG@5 = 0.627) в качестве теста единицы в tests/test_retrieval_metrics.py; журнал 01 проводятся анализы Recall@k / MRR / nDCG на реальном индексе SciFact, причём в продакшене используется харнесс, соответствующий реальным условиям работы evaluation/retrieval.py.

Гибридное слияние рангов retrieval и взаимных рангов

BM25 это редкий лексический оценщик, объединяющий точное совпадение терминов, взвешивание терминов и нормализацию длины. Он доступен в rank_bm25Elasticsearch, OpenSearch и большинство других поисковых движков.

Слияние рекурсивных рангов (Cormack, Clarke, and Buettcher, SIGIR 2009) объединяет алгоритм BM25 с методом плотных ранжировок по положению. Оригинальная k=60 Заданные параметры служат удобной отправной точкой для настройки. Метод RRF не зависит от используемой оценочной функции, что позволяет избежать нормализации между каналами, необходимой при линейной интерполяции. При наличии достаточно большого набора с метками для определения стабильного значения дельты также рекомендуется протестировать использование конвексной комбинации и отрегулировать параметр α.

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

Реализация занимает всего несколько строк.

from collections import defaultdict

# two retrieval lanes: dense embeddings and BM25.
dense  = ["d3", "d7", "d1", "d4", "d2", "d9", "d10"]
sparse = ["d2", "d3", "d8", "d1", "d11", "d4", "d6"]

def rrf(rankings: list[list[str]], k: int = 60) -> list[tuple[str, float]]:
    """Reciprocal Rank Fusion (Cormack et al., SIGIR 2009).

    score(d) = sum over rankings of 1 / (k + rank(d))
    Score-agnostic: only rank position matters. k=60 is the canonical default.
    """
    scores: dict[str, float] = defaultdict(float)
    for ranking in rankings:
        for rank, doc in enumerate(ranking, start=1):
            scores[doc] += 1.0 / (k + rank)
    return sorted(scores.items(), key=lambda kv: kv[1], reverse=True)

fused = rrf([dense, sparse], k=60)
for doc, score in fused[:5]:
    print(f"{doc}  score={score:.5f}")
# d3  score=0.03252   <- rank 1 dense, rank 2 sparse
# d2  score=0.03178   <- rank 5 dense, rank 1 sparse
# d1  score=0.03150

Обратите внимание на то, чего не делает RRF: он никогда не анализирует сырые значения показателей сходства. Результиры работы инструмента типа dense retriever с коэффициентом косинуса 0.98 и результаты работы алгоритма BM25 с показателем 17.4 нельзя сравнивать напрямую. Если нормализовать эти значения с помощью z-статистик или метода минимум-максимум, это может привести к тому, что будет отдаваться предпочтение тому способу поиска, у которого наибольшая дисперсия в данной группе данных.

RRF использует исключительно ранг. Если ретривер помещает документ на позицию 2, этот голос имеет такую же ценность 1 / (60 + 2), независимо от исходного балла, который его сгенерировал.

Гибридный подход + RRF в SciFact: журнал 02 сравнивает алгоритмы dense, BM25 и RRF с учётом дельт на уровне каждого запроса. Фьюзер, адаптированный для производственных условий, находится в retrieval/hybrid_rrf.py; tests/test_rrf.py фиксирует каноническую версию d3 / d2 / d1 формирование заказа k=60.

Реранкинг

• ΔnDCG / ΔMRR: единственный достоверный показатель реранкер — это прирост эффективности по сравнению с сценарием отсутствия ранжирования на вашем «золотом» наборе данных при глубине обработки, реально используемой вашим приложением. Его можно рассчитать путём измерения значений retrieval с применением и без применения реранкер к идентичным наборам кандидатов.
• Cross-encoder vs. bi-encoder: би-энкодер встраивает запрос и документ независимо друг от друга (по одному вектору на каждый элемент) и оценивает соответствие с помощью скалярного произведения; кросс-энкодер объединяет запрос и документ в один поток данных и выполняет один проход, при котором модель одновременно учитывает оба элемента. Кросс-энкодеры жертвуют несколькими проходами для каждого кандидата ради более сложных взаимодействий между запросом и документом. Пример реализации: sentence-transformers CrossEncoder. Бенчмарк релевантности и латентность для конкретного оборудования, размера пакета данных и глубины поиска кандидатов; нельзя переносить результаты одного модель или управляемой службы в другую среду.
• Поэлементно против пакетно: при подходе «поэлементно» оценивается каждая пара (запрос, документ) независимо; при подходе «пакетно» оценивается вся список кандидатов совместно, что позволяет модель сравнивать кандидатов между собой. Оценку необходимо проводить для одинаковых наборов кандидатов. Настройте пороги оценки в соответствии с модель и конкретным корпусом данных, вместо того чтобы считать опубликованные примеры универсально применимыми.

from sentence_transformers import CrossEncoder

reranker = CrossEncoder("BAAI/bge-reranker-v2-m3")

query = "How do I rotate database credentials in production?"
candidates = [
    "Production database credentials are rotated via Vault every 30 days.",
    "The new logo was unveiled at the all-hands meeting.",
    "To rotate prod DB creds, run the `rotate-secrets` GitHub Action.",
]

scores = reranker.predict([(query, c) for c in candidates])
ranked = sorted(zip(candidates, scores), key=lambda x: -x[1])
for doc, score in ranked:
    print(f"{score:+.3f}  {doc}")

реранкер представляет собой кандидата с высоким потенциалом для применения базовой техники RAG пайплайн, однако это не гарантирует успеха. Необходимо измерить его значения ΔPrecision@1 и ΔnDCG на золотом наборе данных, после чего оставить такой вариант лишь в том случае, если полученная прибавка превышает установленные лимиты латентность и бюджет расходов. Перед выбором следующей оптимизации сравните эту измеренную прибавку с менее значительными изменениями, достигаемыми с помощью retrieval.

ΔnDCG и ΔPrecision@1, рассчитываемые с помощью кросс-энкодера в SciFact: журнал 03; модуль: retrieval/reranker.py.

Построение контекста и проблема «потери в середине»

Именно здесь возникает множество сбоев типа «хороший retrieval, плохой ответ».

• Релевантность контекста: оценка релевантности для каждого элемента, рассчитываемая на основе чанк RAGAS ContextRelevancy или кросс-энкодер, агрегированный в виде среднего значения и процентного соотношения к чанки ниже установленного порога.
• Использование контекста: из чанки, находящихся в контексте, сколько из них было фактически цитировано или использовано в ответе. Рассчитывается по формуле \frac|\text{цитируемый чанки}|}{|\text{загружен чанки}|Вычисляется значение $ в отношении маркированного образца. Порог работы определяется на основе качества ответа и стоимости токен, а не с использованием универсального процентного показателя.
• Обнаружение ситуации «потерянного в середине»: синтетические эвал, при которых золотой чанк размещается в позициях {первая, средняя, последняя} длинного контекста, после чего оценивается корректность ответа. Наблюдаемое U-образное снижение качества является реальным феноменом, хорошо задокументированным в литературе. Лю и др. (TACL 2023). Современные модели показывают лучшие результаты по сравнению с модели прошлых версий 2023 года, однако смещение остаётся проблемой. Методы снижения влияния: сначала проводится переранжирование, а затем изменяется порядок элементов из набора top-k так, чтобы чанк с наивысшей оценкой оказался в начале или в конце списка (как это реализовано в LangChain). LongContextReorder должен делать именно это), либо агрессивно сжимать среднюю часть чанки. Оценивать результат следует с использованием позиционно-стратифицированного эвал, а не только общего суммарного балла. Готовая к работе, запускаемая версия позиционно-стратифицированного эвал находится в журнал 06 (module: evaluation/lost_in_middle.py).
• Сжатие контекста: указывайте коэффициент сжатия (входные данные токены / выходные данные токены) наряду с корректностью ответа. Среди инструментов для этой цели — LangChain. ContextualCompressionRetriever и LongLLMLingua. Сначала определяется максимально допустимый уровень потери корректности на основе оценки рисков приложения и лимита токен, после чего отклоняются конфигурации, превышающие этот порог.

Часть 5: Уровень ложного исключения фильтра

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

жёсткий фильтр метаданных вроде tenant_id = X AND product = Y AND locale = en-US Этот показатель может довести эффективную воспроизводимость до нуля. При правильной реализации метрики Recall@k удается зафиксировать такую потерю, поскольку её знаменатель остаётся прежним набором релевантных документов. Однако она не позволяет определить, была ли причиной пропуска фильтрация, механизм поиска или алгоритм ранжирования. Показатель верности всё равно может казаться в порядке, поскольку он оценивает ответ на основе неполного полученного контекста; модель верно заявил: «Я не знаю».

Красная ветвь на диаграмме отражает наиболее частую проблему: соответствующий документ действительно существует, но фильтр удаляет его ещё до retrieval.

Метрика

filter_false_exclusion_rate =
    (# queries where all gold docs were excluded by metadata filter) /
    (# queries with at least one gold doc)

В данном определении на уровне запроса учитываются катастрофические случаи исключения: при таких сценариях не остается ни одного релевантного документа. При работе с многокритериальными запросами метод Recall@k по‑прежнему приводит к частичной потере информации; если этот показатель имеет важное значение, следует ввести показатель скорости исключения для каждого документа отдельно. Для расчёта любого из этих показателей требуются: (а) идентификаторы документов, соответствующие истинному состоянию, для каждого запроса эвал, и (б) инструментарий для записи условий фильтрации, применяемых на этапе обработки, а не только окончательных результатов. Целевое значение следует определять на основе стоимости исключения корректного ответа и диапазона доверия вашей производственной выборки.

Вот рабочая реализация. В ней сравнивается стандартный показатель воспроизведения с некорректным эвалуатор, который изменяет критерии релевантности после фильтрации.

# A small worked example where hard filters remove relevant documents.
docs = [
    {"id": "d1", "tenant": "acme",   "locale": "en-US"},
    {"id": "d2", "tenant": "acme",   "locale": "en-GB"},
    {"id": "d3", "tenant": "globex", "locale": "en-US"},
    {"id": "d4", "tenant": "acme",   "locale": "en-US"},
    {"id": "d5", "tenant": "acme",   "locale": "de-DE"},
]

queries = [
    # the gold doc lives in en-GB but the dynamic filter forced en-US
    {"qid": "q1", "gold": {"d2"}, "filter": lambda d: d["locale"] == "en-US"},
    # the gold doc is correctly within the tenant filter
    {"qid": "q2", "gold": {"d4"}, "filter": lambda d: d["tenant"] == "acme"},
    # the gold doc is in a different tenant and gets dropped
    {"qid": "q3", "gold": {"d3"}, "filter": lambda d: d["tenant"] == "acme"},
    # the gold doc passes the filter (de-DE locale match)
    {"qid": "q4", "gold": {"d5"}, "filter": lambda d: d["locale"] == "de-DE"},
]

def filter_false_exclusion_rate(queries, docs):
    n_with_gold, n_excluded = 0, 0
    for q in queries:
        if not q["gold"]:
            continue
        n_with_gold += 1
        survivors = {d["id"] for d in docs if q["filter"](d)}
        if not (q["gold"] & survivors):
            n_excluded += 1
    return n_excluded / n_with_gold if n_with_gold else 0.0

rate = filter_false_exclusion_rate(queries, docs)
print(f"filter_false_exclusion_rate = {rate:.2%}")
# filter_false_exclusion_rate = 50.00%

# Correct Recall@k keeps the original gold set as its denominator.
def standard_recall_at_k(queries, docs, k=10):
    recalls = []
    for q in queries:
        survivors = [d for d in docs if q["filter"](d)][:k]
        survivor_ids = {d["id"] for d in survivors}
        recalls.append(len(q["gold"] & survivor_ids) / len(q["gold"]))
    return sum(recalls) / len(recalls) if recalls else 0.0

print(f"standard recall@10 = {standard_recall_at_k(queries, docs):.2%}")
# standard recall@10 = 50.00%

# INVALID: rebuilding the gold set after filtering changes the question.
# It drops queries whose relevant documents did not survive, then scores 100%.
def invalid_recall_over_filtered_gold(queries, docs, k=10):
    recalls = []
    all_doc_ids = {d["id"] for d in docs}
    for q in queries:
        all_survivors = {d["id"] for d in docs if q["filter"](d)}
        filtered_gold = q["gold"] & all_doc_ids & all_survivors
        if not filtered_gold:
            continue
        top_k_ids = set(list(all_survivors)[:k])
        recalls.append(len(filtered_gold & top_k_ids) / len(filtered_gold))
    return sum(recalls) / len(recalls) if recalls else 0.0

invalid = invalid_recall_over_filtered_gold(queries, docs)
print(f"INVALID recall (filtered gold) = {invalid:.2%}")
# INVALID recall (filtered gold) = 100.00%

assert rate == 0.5
assert standard_recall_at_k(queries, docs) == 0.5
assert invalid == 1.0

Половина запросов теряют свой идеальный документ из-за применения фильтра, в результате чего показатель Recall@10 снижается до 50%. Этот показатель выявляет симптом проблемы, но не позволяет определить её причину. Уровень ложных исключений указывает на то, что предикат удалял два ответа ещё до того, как началась процедура поиска. Намеренно созданные некорректные данные эвалуатор показывают 100% только потому, что они исключают такие сбои из своего набора идеальных документов. Никакой модель не может восстановить документ, который был отфильтрован.

Указанный выше коэффициент 50% реализован в виде теста на единицу в сопутствующем репозитории: tests/test_filter_exclusion.py::test_50_percent_exclusion_rate. Ноутбук 04 запускается на SciFact с синтетическими метаданными, что позволяет наблюдать, как реальный фильтр полностью устраняет рекал; метрика рантайм (вместе с сопутствующими показателями точности/рекал) присутствует в evaluation/filter_exclusion.py.

Вспомогательная метрика: точность и воспроизводимость предиката

Когда фильтрация динамическая (например, LLM извлекает предикаты фильтрации из запроса), необходимо рассматривать механизм извлечения предикатов как модель классификации модель и оценивать его соответственно. Точность и воспроизводимость предикатов следует измерять на основе помеченного набора данных. (query, correct predicate) Пары. Уровень ошибок предиката не соответствует напрямую такому же показателю потерь в части воспроизведения retrieval; необходимо измерять, с какой частотой эти ошибки приводят к исключению эталонного документа. Как только жесткий фильтр исключает эталонный документ, никакое количество реранкинг уже не может помочь.

Мягкое усиление против жесткого фильтра

Этот показатель вынуждает принимать определённое архитектурное решение. Необходимо использовать строгие фильтры в тех случаях, когда критерий корректности имеет два чётких состояния — например, юрисдикция, границы ACL или статус документа «опубликовано» против «в черновике». В то же время следует применять более гибкие механизмы усиления значимости, когда оценка релевантности производится по шкале: предпочтения локали, дата обновления, версия. Без измерения коэффициента исключения ошибочный выбор остаётся практически незаметным.

Правило принятия решений, измеримое:

For each filter predicate F:
  hard_recall_F  = retrieval_recall@k with F as a hard filter
  soft_recall_F  = retrieval_recall@k with F as a +0.X rerank boost
  hard_precision = relevant_in_top_k / k under hard filter
  soft_precision = relevant_in_top_k / k under soft boost
  exclusion_rate = % of queries where the gold doc was filtered out (hard)

Use hard filter only if exclusion_rate < ε AND hard_precision >> soft_precision.
Otherwise prefer soft boost.

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

Часть 6: Оценка генерации

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

Верность оригиналу и основанность на реальных данных

верность RAGAS разбивает ответ на атомарные утверждения (короткие, самодостаточные фактические заявления), после чего проверяет каждое из них по отношению к полученному контексту с помощью LLM джадж:

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

from datasets import Dataset
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_precision

samples = Dataset.from_dict({
    "question": ["How many moons does Mars have?"],
    "answer":   ["Mars has two moons, Phobos and Deimos."],
    "contexts": [["Mars has two moons named Phobos and Deimos."]],
    "ground_truth": ["Mars has two moons."],
})

result = evaluate(samples, metrics=[faithfulness, answer_relevancy, context_precision])
print(result)

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

def extract_claims(answer: str) -> list[str]:
    # Production: an LLM call that decomposes the answer.
    # Demo: split on sentence-final punctuation.
    return [c.strip() for c in answer.replace("?", ".").replace("!", ".").split(".") if c.strip()]

def verify_claim(claim: str, context: str) -> bool:
    # Production: an NLI (natural-language inference) model or LLM judge.
    # Demo: a deterministic stand-in so the example runs offline.
    entailed_pairs = {
        "Mars has two moons": True,
        "Phobos and Deimos orbit Mars": True,
        "Mars has a thick atmosphere": False,  # unsupported by context
        "Curiosity landed in 2012": True,
    }
    for k, v in entailed_pairs.items():
        if k.lower() in claim.lower() or claim.lower() in k.lower():
            return v
    words = [w.lower() for w in claim.split() if len(w) > 3]
    return all(w in context.lower() for w in words) if words else False

context = (
    "Mars has two moons, Phobos and Deimos. NASA's Curiosity rover "
    "landed on Mars in 2012."
)
answer = (
    "Mars has two moons. Phobos and Deimos orbit Mars. "
    "Mars has a thick atmosphere. Curiosity landed in 2012."
)

claims = extract_claims(answer)
verdicts = [(c, verify_claim(c, context)) for c in claims]
faithfulness = sum(1 for _, ok in verdicts if ok) / len(verdicts)
for c, ok in verdicts:
    print(f"  [{'✓' if ok else '✗'}] {c}")
print(f"faithfulness = {faithfulness:.2f}")
# faithfulness = 0.75   (one unsupported claim about the atmosphere)

Структура играет ключевую роль. В продакшене, verify_claim Это приводит к вызову механизма NLI модель или функции LLM. Остальные этапы процесса харнесс остаются без изменений: извлечение, проверка и агрегация.

Энд-то-энд извлечение утверждений и их верификация для генерируемых ответов SciFact: журнал 05; модуль: evaluation/faithfulness.py. В этом репозитории в том же цикле также запускается верификатор межсемейного типа HHEM, что позволяет определить, какая семья джадж совпадает с какой другой.

специально разработанная альтернатива LLM в роли джадж HHEM-2.1-Open (Hughes Галлюцинация Evaluation Модель, Vectara) — это классификатор, отточенный для обнаружения галлюцинация. В его модель-карте заданы чекпоинт, стандартные границы принятия решений, а также результаты тестирования на данных AggreFact и RAGTruth. Считайте эти данные доказательствами в формате модель-карт, а не гарантией качества всего вашего корпуса: откалибруйте пороговое значение с использованием локальных меток и сравните его с выбранным вами джадж перед началом деплой.

Оценка атомарных фактов

FActScore (Min и др., EMNLP 2023) разбивают процесс генерации длинных текстов на атомарные факты, извлекают соответствующие доказательства для каждого факта и присваивают каждому из них метку supported / not-supportedи сообщает поддерживаемую дробь:

Пример реализации: shmsw25/FActScore. Этот инструмент эффективно справляется с генерацией биографий, кратких резюме и другого текста длинной формы. Однако следует быть осторожным: чрезмерное количество повторяющихся тривиальных фактов может привести к завышению оценки, а атаки типа «MontageLie» (представление достоверных фактов в обманчивом порядке) способны сделать его недостоверным. VeriScore обрабатывает утверждения с необходимыми модификаторами; Ядро filter способствует предотвращению дополнения данных фактами.

Точность цитирования

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

В рамках тракта TREC 2024 RAG определён протокол оценки поддержки, обеспечивающий воспроизводимость результатов. Упадхьяй и др. (SIGIR 2025) В отчёте указано, что GPT-4o соглашается с мнением человека джаджи в 56% случаев при ручной оценке с нуля, а этот показатель повышается до 72% после постобработки предсказаний LLM. Такой результат полезен в качестве инструмента для усиления производительности в определённых условиях, но не может заменить человеческую оценку в критически важных ситуациях. Речь идёт лишь об автоматизированной приближённой оценке. ALCE (Gao et al., EMNLP 2023) предлагает методы определения точности/полноты цитирования с использованием проверки, основанной на задачах NLI.

Правильность ответа, полнота, отказ

• Правильность ответа против истинных значений: при наличии последних речь идёт об точном совпадении или токен-F1 в задачах с краткими ответами (evaluate.load("squad")), семантическое сходство для открытых формулировокbert-score, эмбеддинг вычисление косинуса с помощью sentence-transformers, или RAGAS AnswerCorrectness).
• Полнота через нагетты: «нагетт» — это отдельный атомарный элемент информации, который обязательно должен присутствовать в любом корректном ответе (например, для вопроса «Когда была основана компания?» нагеттами могут быть {year: 1994, founder: Jane Doe}. TREC’s AutoNuggetizer Извлекает наиболее ценные элементы правильного ответа из исходных данных, после чего оценивает долю информации, покрытой системой — наблюдается высокая корреляция с результатами ручной оценки при 21 тематике и 45 экспериментах в рамках TREC 2024.
• Поведение отказа: запросы, для которых в корпусе данных нет ответа, должны приводить к отказу в обработке, а не к галлюцинация. Необходимо отслеживать точность отказа (количество случаев, когда отказ был обоснован) и воспроизводимость отказа (количество запросов, выходящих за рамки задачи, которые также вызвали отказ). NoMIRACL Является ли публичный бенчмарк в вашем собственном домене способом маркировки части запросов, выходящих за рамки задачи, и отслеживания точности отказа от обработки таких запросов?

Проверка после генерации

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

• Проверка сущности граундинг: каждая именованная сущность в ответе должна присутствовать в полученном контексте (или может быть выведена из него). Для этого используется проверка с помощью простого регулярного выражения и точного совпадения (или spaCy’s ents при сравнении с нормализованной строкой контекста удается обнаружить значительную долю случаев использования галлюцинации.
• Проверка утверждений: извлекаются утверждения, выполняется оценка НЛИ по отношению к контексту; любые результаты ниже заданного порога приводят к сбою или маркировке. Оценка НЛИ как проверки достоверности модели: cross-encoder/nli-deberta-v3-large, MoritzLaurer/DeBERTa-v3-large-mnli-fever-anli-ling-wanli. Добавляет латентность. Это целесообразно для критически важных сфер применения.
• Самосогласованность (Ванг и др., ICLR 2023): Протестируйте несколько поколений генерации при температуре, превышающей 0; зафиксируйте коэффициент согласованности (например, долю поколений, соответствующих модальному ответу, или значение pairwise BERTScore). Выберите количество образцов на основе кривой стабильности и затрат, а также отметьте ответы с низким уровнем согласованности для дальнейшего рассмотрения человеком.
• Уровень уверенности калибровка: собираются данные о выражаемой уверенности пользователя («Насколько вы уверены? От 0 до 1») и сравниваются с фактической степенью точности на наборе эвал. Рисуется кривая калибровка, при этом указывается ожидаемая ошибка Калибровка: \text{ECE} = \sum_{m=1}^{M} \frac{|B_m|{n} |\text{acc}(B_m) — \text{conf}(B_m)|, где $B_m$ — это диапазоны уверенности. Реализации: netcal, torchmetrics.CalibrationError. Если модель сообщает уровень уверенности 0,9, то его результаты должны быть корректны примерно в 90% сопоставимых случаев; следует измерять разницу между фактическими показателями, а не полагаться на калибровка.

Часть 7: Оценка на основе онтологии RAG

Указанные выше стандартные метрики охватывают работу с открытыми корпусами RAG. Системам, основанным на онтологиях, требуются дополнительные показатели. Если ваш RAG выполняет поиск в структурированной онтологии, таксономии или графе знаний (товары в каталоге, условия в SNOMED, компоненты в BOM, методы защиты в MITRE ATT&CK), стандартные RAG метрики необходимы, но недостаточны. В таких случаях обязательно требуется измерять параметры самого слоя онтологии.

Точность связывания сущностей

Первая задача заключается в сопоставлении упоминания запроса с сущностью онтологии («Aspirin» → wikidata:Q18216”737” aircraft:Boeing_737).

• Точность/покрытие/F1 на уровне упоминаний: стандартные показатели, рассчитываемые по эталонному упоминанию спаны seqeval или сравнитель спан-set).
• Точность разрешения неоднозначности: из числа правильно обнаруженных упоминаний, какая доля соответствует правильному идентификатору сущности? К публичным примерам относятся ReFinED, REL, и ЖАНР; подобно бенчмарки AIDA-CoNLL и BELB Покажите, что результаты различаются в зависимости от системы и домена.
• Обработка NIL: точность/покрытие для случаев «энтитет отсутствует в онтологии». Оценивайте уровень пересоединения с близкими, но неверными энтитетами отдельно от ситуаций корректного воздержания.

Оценка с учётом иерархии

Простая точность рассматривает случай «прогнозирование Sedan, когда на самом деле это Hatchback» как эквивалентный ситуации «прогнозирование Sedan, когда на самом деле это Submarine». Однако эти ошибки не являются равноценными.

• Иерархическая точность/полнота/F1 (Космопулос и др., 2015): Присваивайте кредиты предкам и потомкам в даг-диаграмме онтологии. Пусть $\hat{P}_q$ — это предсказанный узел вместе со всеми его предками, а $T_q$ — истинный узел вместе со всеми его предками:

  $$hP = \frac{\sum_q |\hat{P}_q \cap T_q|{\sum_q} |\hat{P}_q|}, \quad hR = \frac{\sum_q |\hat{P}_q \cap T_q|{\sum_q} |T_q|}, \quad hF1 = \frac{2 \cdot hP \cdot hR}{hP + hR}$$

  реализовать с помощью networkx в графе онтологии; см. hierarchical-classifier-metrics для справки.

• Похожесть Wu-Palmer между предсказанной и эталонной сущностью в таксономии (Уу и Палмер, 1994):

  $\text{WuP}(c_1, c_2) = \frac{2 \cdot \text{depth}(\text{LCA}(c_1, c_2))}{\text{depth}(c_1) + \text{depth}(c_2)}$

  где LCA — это наименьший общий предок в таксономии. Доступен из коробки в библиотеке NLTK для WordNet.from nltk.corpus import wordnet as wn; wn.synset("car.n.01").wup_similarity(wn.synset("truck.n.01"))); для пользовательских таксономий вычисляется LCA с networkx.

• Уровень путаницы между братьями/сестрами и родителями: отдельно отслеживайте случаи путаницы с братьями/сестрами, родителями и детьми. count_sibling / total_errors, count_parent / total_errors, count_descendant / total_errors. Используйте проверенные примеры для тестирования того, связаны ли ошибки между сиблингами с неоднозначными упоминаниями, а ошибки родителей — с чрезмерной генерализацией.

Уровень фильтрации ложных исключений (повтор, теперь критично)

В системах, основанных на онтологиях, жесткие фильтры зачастую определяются самой онтологией («выводить только документы с меткой категории X»). Метрика скорости исключения (определённая в Часть 5) Это превращается в основной сигнал корректности. Неверная предсказание категории может полностью свести на ноль показатель воспроизводимости; коэффициент исключения отвечает за приписывание этой потери фильтру.

Соответствие ограниченному генерированию

При необходимости соблюдения ортогональности вывода к определённой онтологии (когда каждое имя сущности в ответе должно быть допустимым элементом этой онтологии, а каждый предикат — выходить из замкнутого словаря), необходимо измерять:

• Степень корректности схемы: процент выходных данных, которые успешно парсируются и проверяются с учётом схемы онтологии. Проводить проверку с использованием jsonschema или pydantic. JSONSchemaBench Является ли публичный бенчмарк универсальным инструментом для обработки structured output; в случае схем, специфичных для определённой онтологии, необходимо разрабатывать собственный верификатор.
• Соответствие словарю: процент именованных сущностей в результирующем выводе, которые являются допустимыми идентификаторами онтологии — это однострочная проверка принадлежности к заранее определённому списку терминов.
• Семантическое соответствие: наличие синтаксической корректности недостаточно; такой вывод может содержать неверную, но всё же допустимую сущность. Необходимо сочетать проверку соответствия с корректностью получаемых ответов.

Constrained decoding фреймворки (Основные положения, XGrammar, Рекомендации, OpenAI Structured Outputs) предназначены для обеспечения валидности схемы. JSONSchemaBench Сравнивает эффективность, уровень покрытия и качество между различными реализациями. Перезапустите его тесты, соответствующие вашим схемам, а также сервинг бэкенд, поскольку уровень покрытия и латентность напрямую зависят от обоих факторов.

Проверяемость

Для систем, основанных на онтологиях, в которых ответы подлежат проверке:

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

Часть 8: Оценка на уровне системы

Качество целостного ответа

• LLM-как-джадж (Zheng и др., NeurIPS 2023): масштабируемый подход к оценке, основанный на модель. Механизм G-Эвал (протокол типа LLM-джадж, при котором модель генерирует собственную шкалу оценки chain-of-thought перед проведением расчётов) позволяет формировать такую шкалу на основе критерия, изложенного на натуральном языке, а затем выполнять оценку с использованием весов, зависящих от логарифмических вероятностей. Степень согласованности результатов определяется в зависимости от джадж, конкретной задачи, промпт и используемого набора калибровка.
• Парная предпочтительность: представляются джадж в виде варианта ответа A против варианта ответа B; затем фиксируется предпочтение пользователя. Этот метод позволяет избежать проблем, связанных с использованием абсолютных оценок калибровка. MT-Bench В ходе тестирования была зафиксирована степень согласованности GPT-4 джадж на уровне свыше 80% как с предпочтениями людей, так и с результатами взаимного сравнения между людьми в рамках заданных бенчмарк условий; этот показатель нельзя переносить в другие области без соответствующего калибровка.

LLM в роли джадж действительно обладает смещениями:

• Смещение из-за позиции: джаджи приводит к тому, что система отдаёт предпочтение первому или второму ответу независимо от их качества. Способы снижения влияния: случайная сортировка результатов или выполнение поиска в обоих порядках с последующим усреднением результатов.
• Смещение из-за объёма: джаджи может приводить к путанице между длиной ответа и его качеством. A Контролируемое исследование 2026 года Обнаружено неоднородное поведение пар расширения ответа: три модели джаджи отдавали предпочтение более длинным ответам, Claude предпочитал краткие варианты, а GPT-4o проявлял примерно нейтральную тенденцию. Все пять моделей показали хорошие результаты при тестах на контроль обрезки текста. Результаты находятся в пределах ограничений, установленных бенчмарк, поэтому необходимо указать вашему джадж, как подходить к оценке полноты ответа и наличия лишних элементов, после чего самостоятельно оценить производительность при фиксированной длине ответа согласно вашей шкале.
• Склонность к самопредпочтению: GPT-4 отдаёт предпочтение своим собственным выводам; эта склонность коррелирует с плексичностью вывода (джаджи предпочитает текст, знакомый им). Способы смягчения эффекта: использовать другую семью джадж, отличную от той, что используется в системе, проходящей оценку. Не следует применять модель к самому джадж.

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

Руководство схемой Ризонинг для джаджи

Свободный формат вывода является одной из причин различий в результатах выполнения джадж. Два запуска с одним и тем же ответом могут по-разному интерпретировать критерии оценки, что приводит к разным баллам. Руководство схемой Ризонинг (SGR) Чтобы сделать эту структуру оценки явной, необходимо определить этапы анализа в виде схемы Pydantic, а затем обеспечить форматирование ограниченного вывода с помощью Outlines, XGrammar, vLLM structured outputs, или OpenAI. response_format Поэтому при каждом запуске возвращаются те же поля в том же порядке.

Для RAG эвал схема разбивает результат оценки на явные, поддающиеся аудиту поля, вместо того чтобы позволять модель сразу получать числовое значение:

from pydantic import BaseModel, Field
from typing import Literal

class FaithfulnessJudgment(BaseModel):
    extracted_claims: list[str] = Field(
        description="Atomic factual claims in the answer, one per item."
    )
    supported_claims: list[str] = Field(
        description="Subset of extracted_claims that are entailed by the context."
    )
    unsupported_claims: list[str] = Field(
        description="Subset that is NOT entailed by the context."
    )
    failure_mode: Literal[
        "none", "fabrication", "overgeneralization", "wrong_entity", "stale_fact"
    ]
    score: float = Field(ge=0.0, le=1.0)
    rationale: str

Благодаря структурированным полям оценка может быть восстановлена. len(supported) / len(extracted) Кроме того, отображается точный список утверждений, по которым джаджи пришли к разногласию. Инструмент Pydantic модель также позволяет видеть изменения в структуре классификации в виде различий кода. Благодаря ограничениям на формат вывода гарантируется строгое соблюдение структуры, но не обеспечивается беспристрастное суждение; поэтому методы случайной перестановки позиций, использование джаджи из разных семейств и участие людей калибровка по-прежнему применяются.

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

G-Эвал / двойное сравнение / смещение по позиции / межсемейное джадж харнесс присутствует в журнал 07; модуль: evaluation/llm_judge.py. Сканирование бенчмаркmake benchmark в репозитории) подключает три устройства высшего уровня модели — gpt-5-mini, claude-haiku-4-5, gemini-2.5-flash — во вращающуюся парную схему типа A/B джадж, при которой каждый модель джаджи сравнивается с остальными двумя, что позволяет численно выявить самопредпочтения.

Латентность и затраты

• p50, p95, p99 на каждом этапе пайплайн. Значения процентилов SLO и пороги оповещений выбираются исходя из характеристик пути пользователя, объёма трафика и доступного бюджета на обработку ошибок.
• Время до первого ответа-токен по сравнению с общим временем генерации. Для улучшения пользовательского опыта при потоковой передаче данных критически важно минимизировать это время.
• Структура этапов: retrieval, реранкинг, генерация, постобработка. Вместо предположений относительно причины проблем используйте трейс для выявления «хвоста» распределения; при сравнении результатов работы записывайте информацию о устройстве реранкер и размере пакета данных.
• Общая стоимость за запрос = эмбеддинг + retrieval + затраты на переранкинг + время генерации + амортизированные затраты на хранение. Необходимо отслеживать значения p50 и p99; именно в области длинного хвоста расходуется большая часть бюджета.
• Уровни индексации Кэш на уровнях эмбеддинг кэш, retrieval кэш и KV-кэш. Для каждого уровня необходимо устанавливать отдельные целевые показатели, учитывающие факты повторных запросов, правила аннулирования результатов и экономию затрат.

Встроена возможность расчёта показателей p50/p95/p99 по этапам с детальным разбивкой по стадиям. журнал 08 а также компонент выполнения в evaluation/latency.py; Отчёт бенчмарк объединяет латентность и показатели точности в одну матрицу, которую можно перезапустить для повторного анализа. make benchmark.

Тестирование A/B

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

Часть 9: Создание набора тестирования

Качество метрики полностью определяется набором тестовых данных, на которых она проверяется. Если ваш золотой набор включает три интента, а реальный трафик содержит спаны двенадцать, то метрика Recall@10 будет учитывать только первые три интента. Что ещё хуже, тестовый набор, слишком хорошо подходящий для простых запросов вроде «Какова политика возврата средств компании?», может дать положительную оценку системе, которая терпит неудачу при обработке сложных случаев, таких как «Является ли возможным возврат средств за частичное отменение заказа в соответствии с Законом ЕС об цифровых услугах 2023 года, если счёт выставлен в евро и заказ исходит из Ирландии?». В результате общий балл повышается, хотя система по-прежнему не справляется с значительной частью реального трафика.

Та же проблема возникает и с эталонными данными. Если специалисты среднего уровня помечают очевидные документы, но упускают менее распространённые, но релевантные варианты, метрика Recall@k будет занижать оценку поискового агента, который фактически их нашёл. Оптимизация проводится с учётом меток, а не с учётом самой истины.

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

Генерация синтетических запросов

Для генерации вопросов на основе вашего корпуса данных используйте LLM:

• По чанк: «Сгенерировать 3 вопроса, которые может задать пользователь, и на которые отвечает этот чанк».
• Мультихоповый подход: выбрать два чанки, сформулировать вопрос, требующий знания обоих.
• Адверсариальный подход: создавать вопросы с отвлекающими элементами, почти идентичными формулировками и неоднозначными упоминаниями.

RАГИ имеет встроенное распределение типов вопросов (ризонинг, условное, многоконтекстное). DataMorgana генерирует настраиваемые синтетические бенчмарки в разрезе категорий пользователей и запросов. Синтетические данные полезны для решения проблемы «холодного старта» и проведения тестов на полноту покрытия. Они не могут заменить реальные запросы пользователей.

Метод построения «золотого» датасет

Данные, отобранные вручную, служат основой для золотого набора.

1. Примеры реальных запросов пользователей (или симулированных в период до запуска), сгруппированные по целям использования.
2. Наёмные специалисты должны ответить на каждый вопрос и определить, в каком(ых) документе(ах) содержится ответ.
3. Размер набора определяется на основе матрицы покрытия и диапазона уверенности, необходимого для принятия решений о выпуске; показатель покрытия имеет большее значение, чем количество обработанных запросов.
4. Пересмотр набора данных проводится при наличии оснований, связанных с частотой выпусков, сигналами отклонения, рисками в конкретной области и возможностями аннотации.

Наборы данных для адверсарских тестов

• Контрфактические сценарии: замена ключевых сущностей в запросе. Воспроизводит ли система правильный чанки для изменённого запроса?
• Отвлекающие факторы: запросы, в которых в корпусе имеется правдоподобный, но неверный ответ, который не должен возвращаться. Именно это является RGB (Chen et al., AAAI 2024) проводят тесты на прочность: устойчивость к шуму, отклонение из‑за отрицательных результатов, интеграция информации и устойчивость к контрфактическим сценариям.
• Отрицания и кванторы: запросы, содержащие «not», «except» и «only». Методы плотного поиска часто сталкиваются с трудностями при обработке таких запросов.
• Вне диапазона: запросы, на которые в корпусе данных нет ответа. Система должна указывать «Я не знаю», а не генерировать вымышленную информацию. NoMIRACL живёт здесь. Оценивайте явление отсутствия ответов прямо для типов ваших запросов в продакшене.

Уровень покрытия и непрерывная оценка

• Составьте матрицу покрытия: намерение запроса × тип документа × ветвь онтологии. Цель — не менее одного запроса на каждую ячейку. Пустые ячейки представляют собой незащищённые области, где могут скрываться регрессии.
• Проводите ограниченные, быстрые тесты на выявление регрессий для каждого PR, а полный набор тестов — по более редкой графике.
• Определяйте график выполнения полного набора тестов эвал с учётом цикла выпусков и затрат на оценку; кандидаты на выпуск служат естественным контрольным этапом.
• Планируйте проверку на отклонения на основе объёма трафика, ожидаемых изменений и уровня риска. Используйте постоянную выборку из продакшена и стратифицируйте данные по отзывам, вместо того чтобы тайно изменять целевую распределение.

Часть 10: Мониторинг в продакшене

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

Косвенная и прямая обратная связь

• Коэффициент переходов / открытий на указанные источники (если интерфейс позволяет их отображать).
• Время пребывания на ответе.
• Частота повторных запросов: процент ответов, по которым пользователь снова задаёт вопрос или просит систему его пересоздать. Следует рассматривать это как один из признаков недовольства и корректировать показатели на основе проанализированных диалогов.
• Коэффициенты копирования / распространения / экспорта — явный положительный сигнал.
• Паттерны последующих вопросов: фразы вроде «Вы уверены?» или «А что насчёт X?» указывают на недоверие.
• Оценки «лайк/дизлайк» с возможностью указания причин (неверно, неполно, не по теме, вредно, медленно). Онлайн-редактирование, если интерфейс это поддерживает, является самым информативным видом обратной связи.

Обнаружение дрейфа

• Дрейф запросов: отслеживайте распределение запросов эмбеддинг по сравнению с эталонным окном с помощью дивергенции Кулбаки, метода MMD или детектора, основанного на модель. При обнаружении смещения активируйте уведомление для последующей сегментации и отладки.
• Дрейф Эмбеддинг: фиксируйте набор пробных документов; периодически повторно встраивайте их данные и измеряйте коэффициент косинуса по отношению к исходному эмбеддинги. Даже незначительный дрейф между версиями провайдера модель незаметно нарушает работу retrieval. Самым экономичным способом смягчения таких эффектов является хранение данных в версионированном формате эмбеддинг (с неизменяемыми данными для каждой версии снапшоты).
• Дрейф производительности: отслеживайте метрики, эквивалентные тем, что используются в продакшене (скорость генерации ответов в зависимости от цели), со временем. Резкие скачки указывают на возникновение сбоев, а постепенное снижение производительности — на изменение внешних условий.

Теневая оценка и участие человека в процессе

Запустите кандидатскую версию системы параллельно с продакшн-версией, сравните результаты в оффлайне и не предоставляйте их пользователям. Такой подход позволяет выявить регрессии ещё до выпуска продукта. Это требует дополнительных затрат инференс, однако не влияет на клиентов.

Для ревизии с участием человека (HITL):

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

Минимальный набор гардрейл

Предупреждение по этим пунктам в порядке приоритета:

1. Оценка точности/HHEM ниже установленного порога в роллингой выборке из продакшена.
2. p95 латентность превышает заданные показатели SLO.
3. Уровень ложных исключений выше установленного порога (определяется на основе выборки).
4. Частота регенерации находится за пределами локально откалиброванной диапазонной зоны, учитывающей размер окна, объём трафика, сезонность и лимит ложных сигналов.
5. Затраты/запрос превышают установленный бюджет.

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

Ограничения и замечания

• Цели являются локальными, а не универсальными. Любое число, обозначенное в данном руководстве как примерное, представляет собой конфигурацию или результат тестирования, а не критерий выпуска продукта. Настройте пороги в соответствии с особенностями вашей области применения, степенью риска, уровнем неопределённости в наборе данных для оценки и ожиданиями пользователей.
• Пространство фреймворк развивается очень быстро. Версии HHEM, названия метрик RAGAS, карты модель, а также порядок в таблицах лидеров могут изменяться после публикации информации. Перед окончательным использованием обязательно проверьте исходные источники и повторно выполните операцию бенчмарк.
• Числа согласованности LLM-as-джадж всегда указываются с звёздочками. Значение 80% для сравнения GPT-4 и человека получено в условиях тестов MT-Bench / Chatbot Arena. В узкоспециализированных областях и при адверсарских сценариях уровень согласованности резко снижается. Используйте джаджи в качестве коэффициента усиления, а не вместо прямой проверки качества.
• Улучшения, заявляемые поставщиками через бенчмарк, зачастую невозможно воспроизвести независимо. Прежде чем верить приведённым цифрам, обязательно проведите тестирование на собственных данных, особенно касательно более новых систем типа реранкеры и OCR.
• Ни одна метрика не может заменить прямой анализ результатов работы системы. Регулярно планируйте слепую оценку случайных образцов продакшн-контента в зависимости от объёма трафика, уровня риска и возможностей экспертов. Метрики лишь помогают оценивать эти показатели; они не заменяют собой сам процесс анализа.

Что будет далее в этой серии

Это был индекс. Следующие материалы — планирование:

• Мягкие усиления против жестких фильтров: углубленный анализ коэффициента ложного исключения при использовании фильтров, включающий код, реальные примеры из производства и критерии принятия решений фреймворк.
• Является ли Чанкинг скрытой переменной?: контролируемые эксперименты с применением рекурсивных, семантических, поздних и структурных чанкинг методов на трех корпусах данных.
• Выбор Реранкер в 2026 году: сравнение BGE, Cohere, ZeRank и современных кросс-кодеров модели по таким параметрам, как стоимость, латентность и эффективность улучшения качества.
• Оценка, основанная на онтологии RAG: пошаговый обзор от начала до конца: создание полной системы оценки харнесс для системы, связанной с сущностями retrieval.
• LLM-в-роли-Джадж без ловушки самопредпочтения: практические подходы к объективной автоматизированной оценке.
• Онлайн-оценка в производственной среде: шаблоны инструментализации, политики оповещений и панели управления для выявления реальных регрессий.

Список литературы

Фреймворки и бенчмарки

• Эс и др., Rаги: автоматизированная оценка генерации с использованием Retrieval, 2023.
• документация RAGAS и GitHub.
• Саад-Фэлкон и др., ARES: Автоматизированная система оценки Фреймворк для систем генерации с усилением с помощью Retrieval, NAACL 2024.
• TruLens, DeepEval, Arize Phoenix.
• Тхакур и др., BEIR: Гетерогенная Бенчмарк для оценки информации Retrieval Модели в режиме без обучения на примерах, NeurIPS 2021.
• Топ-лист MTEB.
• TREC 2024 RAG ниша.
• Прадип и др., Результаты первоначальной оценки кусочков данных для трека TREC 2024 RAG с использованием инструмента AutoNuggetizer Фреймворк, 2024.

Retrieval и ранжирование

• Cormack, Clarke, Buettcher, Метод слияния взаимных рангов демонстрирует лучшие показатели эффективности по сравнению с методами Кондорсе и обучения на основе индивидуальных рангов., SIGIR 2009.
• Гао и др., Точный метод плотного обучения без подготовительных примеров Retrieval без использования меток релевантности (HyDE), 2022.
• Jeong и др., Адаптивный RAG: Обучение адаптации Retrieval к условиям задач с разной степенью сложности в рамках расширенных больших языковых Модели моделей, NAACL 2024.
• Anthropic, Представляем контекстуальный Retrieval, Сентябрь 2024 г.
• Günther и др., Задержка Чанкинг: контекстуальный Чанк Эмбеддинги с использованием длинного контекста Эмбеддинг-модели, 2024.
• Сарти и др., RAPTOR: рекурсивная абстрактная обработка для древовидно организованных Retrieval, 2024.

Генерация, верность оригиналу, джаджи

• Мин и др., FActScore: тонкокалиброванная атомарная оценка точности фактов при генерации длинных текстов, EMNLP 2023.
• Лю и др., Затерянность в среднем масштабе: как язык Модели использует длинные контексты, TACL 2023.
• Chen и др., Сравнительные тестирования крупных языковых моделей Модели в среде генерации с усилением с помощью Retrieval (RGB), AAAI 2024.
• Vectara, HHEM-2.1-Открытая галлюцинация оценка модель.
• Чжэн и др., Оценка LLM в качестве Джадж с использованием MT-Bench и Chatbot Arena, NeurIPS 2023.
• Упадхьяй и др., Оценка качества поддержки для дисциплины TREC 2024 RAG: сравнение работы людей и LLM Джаджи, SIGIR 2025.
• Thakur и др., NoMIRACL: способность определять моменты отсутствия знаний для создания надёжных мультиязычных генеративных систем с использованием Retrieval, 2023.
• Geng и др., JSONSchemaBench: строгий Бенчмарк для Structured Outputs языка Модели, 2025 г. – Kosmopoulos и др. Методы оценки для иерархической классификации: единый подход и инновационные решения, 2015.

Дрейф и производственная среда

• Очевидно, Методы обнаружения дрейфа Эмбеддинг.

Вспомогательный код

• slavadubrov/rag-evals-demo — исполняемый харнесс для каждой метрики в данной статье, построенной на корпусе SciFact, плюс сканирование типа чанкинг × эмбеддинг × LLM бенчмарк. Сюда входят ноутбуки с номерами от 00 до 09, тесты на единицы, фиксирующие приведённые выше рабочие примеры, а также встроенный индекс Qdrant, что позволяет запускать всё без использования Docker.