[Перевод] Как оценивать RAG-системы: метрики, методы и что измерять в первую очередь

Материал подготовлен для будущих студентов курса «ИИ-архитектор».

Когда RAG-система дает сбой, по одному только ответу невозможно понять, почему это произошло. RAG расшифровывается как retrieval-augmented generation – генерация с дополнением через поиск – и это одна из самых распространенных техник проектирования контекста, позволяющая добавлять AI-агентам дополнительную информацию, а значит, и повышать точность их работы. Поскольку RAG – критически важный компонент современных AI-приложений, разработчикам нужен метод оценки LLM, который позволяет выявлять проблемы и отслеживать качество работы RAG.

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

Также рассмотрим наиболее эффективный подход к оценке – LLM-as-a-judge. Подключение LLM к этапу оценки во многом вытеснило устаревшие детерминированные метрики вроде BLEU и ROUGE, которые измеряли совпадение слов, а не смысловую точность. LLM лучше справляются с оценкой текстовой релевантности, поэтому они хорошо подходят для набора инструментов оценки RAG.

Как выходят из строя RAG-системы и почему оценка должна быть раздельной

Ошибки в RAG-системах делятся на три категории, которые внешне выглядят одинаково, но требуют совершенно разных способов исправления:

• Поисковый модуль может не найти релевантные документы или поставить их слишком низко в ранжировании, из-за чего модели не хватает нужного контекста.

• Модель может галлюцинировать, то есть выдать вымышленный ответ, даже если релевантные документы были найдены.

• Модель может ответить не на тот вопрос, который задал пользователь, даже если ее ответ хорошо опирается на найденный контекст.

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

Рассмотрим конкретный пример. Пользователь спрашивает внутреннего HR-ассистента: «Имею ли я право на отпуск по уходу за ребенком, если работаю здесь 11 месяцев?» Система отвечает: «Сотрудникам положено 12 недель отпуска по уходу за ребенком». Что это было — ошибка поиска, когда система нашла общий документ о политике отпуска, но упустила документ с условиями, где указан минимальный стаж 12 месяцев? Или ошибка генерации, когда нужный документ был найден, но модель проигнорировала требование к стажу и ответила только на поверхностную часть вопроса?

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

Три измерения качества RAG: «триада RAG»

Самая полезная диагностическая схема для оценки RAG измеряет три взаимосвязи:

• Релевантность найденного контекста: связь между запросом пользователя и тем, что нашел поисковый модуль.

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

• Релевантность ответа: связь между исходным промптом пользователя и итоговым ответом, то есть действительно ли система ответила на вопрос или выполнила задачу пользователя.

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

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

LLM-as-a-Judge: механизм оценки, лежащий в основе этих метрик

Большинство метрик, о которых идет речь в этом руководстве, основаны на подходе LLM-as-a-judge: когда достаточно сильная LLM используется для оценки результатов, выданных другими моделями. Этот подход во многом вытеснил устаревшие метрики, основанные на пересечении токенов, такие как BLEU и ROUGE. Они измеряли совпадение слов на поверхности текста, а не смысл или фактическую точность. Ответ, который передает правильную информацию, но другими словами, получил бы низкую оценку по BLEU; LLM в роли судьи способна распознать семантическую эквивалентность.

Стоит знать о двух фреймворках. G- предложил использовать для оценки пошаговое рассуждение, при котором модель-судья перед выставлением оценки сначала формулирует критерии шаг за шагом, а затем использует вероятности токенов, чтобы получать непрерывные, а не целочисленные оценки. В Opik G-Eval реализован как встроенная метрика, поэтому его можно напрямую применять к результатам вашей RAG-системы. Prometheus (Kim et al., ICLR 2024) показал, что модели с открытым исходным кодом, дообученные специально для задач оценки, могут демонстрировать такую же корреляцию с человеческими оценками, как и GPT-4, если им задать структурированные рубрики. Для конвейеров оценки RAG это важно потому, что вы не оказываетесь привязаны к проприетарным моделям в роли судьи: платформы вроде Opik позволяют использовать в качестве основы для оценки любую LLM, поддерживаемую LiteLLM, включая open-source варианты.

Оценка триады RAG на практике

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

Как измерять качество поиска в RAG-системах?

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

В рамках этого измерения точность контекста показывает, насколько хорошо поисковый модуль ранжирует релевантную информацию. Найти правильный документ важно, но не менее важно, на каком месте в списке он оказался. Исследование Liu et al. показало, что при обработке длинного контекста языковые модели демонстрируют U-образную кривую качества: они хорошо воспринимают информацию в начале и в конце входных данных, но часто упускают то, что находится посередине. Из-за этого эффекта «потеря в середине» поисковый модуль, который прячет самый релевантный документ на 8-е место из 10, по сути, почти так же бесполезен, как если бы он вообще его не нашел.

Opik предоставляет и ContextPrecision, и ContextRecall как встроенные метрики на основе подхода LLM-as-a-judge. Обе используют few-shot-промптинг со структурированными рубриками и выставляют оценку по шкале от 0.0 до 1.0:

from opik.evaluation.metrics import ContextPrecision, ContextRecall precision_metric = ContextPrecision() recall_metric = ContextRecall() precision_score = precision_metric.score( input="Am I eligible for parental leave if I've been here 11 months?", output="Employees are eligible for 12 weeks of parental leave.", expected_output="Employees must complete 12 months of tenure to qualify.", context=["Parental leave policy: Eligible employees receive 12 weeks…", "Eligibility: Employees must complete 12 months of continuous employment."], ) recall_score = recall_metric.score( input="Am I eligible for parental leave if I've been here 11 months?", output="Employees are eligible for 12 weeks of parental leave.", expected_output="Employees must complete 12 months of tenure to qualify.", context=["Parental leave policy: Eligible employees receive 12 weeks…", "Eligibility: Employees must complete 12 months of continuous employment."], )

По умолчанию обе метрики используют GPT-4o в роли оценщика, но при необходимости вы можете переключиться на любую модель, поддерживаемую LiteLLM, задав параметр model. Метрика ContextPrecision штрафует системы, которые помещают релевантные документы ниже в ранжированном списке, тогда как ContextRecall показывает, извлек ли поисковый модуль всю релевантную информацию, необходимую для ожидаемого ответа.

Как выявлять галлюцинации в ответах RAG?

Вторая сторона триады, groundedness, то есть обоснованность, – в фреймворке Ragas ее также называют верность контексту (faithfulness) – оценивает, действительно ли ответ генератора подтверждается найденным контекстом. Это ваш основной инструмент для выявления галлюцинаций, и для большинства продуктовых команд именно эта метрика оказывается самой важной во всем стеке оценки.

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

Оценка верности контексту – это отношение числа подтвержденных утверждений к общему числу утверждений. Оценка 1.0 означает, что каждое высказывание можно проследить до найденного контекста. Оценка 0.6 означает, что 40% утверждений взялись откуда-то еще — скорее всего, из обучающих данных модели или вообще были выдуманы. Высокие значения верности контексту показывают, что генератор ведет себя как «прослойка естественного языка» над вашей базой знаний, а не импровизирует за счет своей параметрической памяти.

В Opik выявление галлюцинаций реализовано как встроенная метрика:

from opik.evaluation.metrics import Hallucination metric = Hallucination() score = metric.score( input="Am I eligible for parental leave if I've been here 11 months?", output="You're eligible for 12 weeks of parental leave after your first year, and you can split it into two blocks.", context=["Eligible employees receive 12 weeks of parental leave.", "Employees must complete 12 months of continuous employment to qualify."], )

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

Что измеряет релевантность ответа при оценке RAG?

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

Чтобы вычислить релевантность ответа без заранее написанного эталонного ответа, можно использовать подход с «обратным восстановлением». LLM генерирует несколько гипотетических вопросов, на которые текущий ответ действительно мог бы быть ответом, а затем система измеряет семантическое сходство между этими синтетическими вопросами и реальным запросом пользователя. Если ответ действительно релевантен, то восстановленные таким образом вопросы должны быть очень близки к тому, что изначально спросил пользователь.

Эта метрика позволяет поймать сценарии, которые не выявляет одна только верность контексту. Пользователь спрашивает: «Как мне сбросить пароль?» А система в ответ выдает подробное, хорошо обоснованное объяснение архитектуры безопасности вашей компании. Каждое утверждение подтверждается найденным контекстом. Оценка верности контексту идеальна. Но пользователь все равно не понимает, как сбросить пароль. Метрика релевантности ответа штрафует именно за такой разрыв.

В Opik для этого есть метрика AnswerRelevance, которая реализует такой подход. В сочетании с ContextPrecision, ContextRecall и Hallucination эти четыре метрики дают полное диагностическое покрытие триады RAG.

Метрики поиска для настройки в продакшене

Триада RAG дает вам высокоуровневую диагностику состояния системы. Но когда нужно тонко настроить реальную конфигурацию поискового модуля – включая такие параметры, как размер фрагментов, настройки top-K и выбор модели эмбеддингов, – понадобятся более детальные метрики из классической теории информационного поиска.

Recall@K показывает долю всех релевантных документов, которые попали в первые K результатов. Если в вашей базе знаний есть пять документов, способных ответить на конкретный запрос, а поисковый модуль выдает только три из них в первой десятке, то recall@10 будет равен 0.6. Эта метрика особенно важна в таких областях, как право или медицинские исследования, где пропуск даже одного релевантного документа может привести к неполному или неверному выводу.

Precision@K измеряет обратную сторону: какая доля из первых K результатов действительно релевантна. Если вы извлекли 10 документов, но полезны из них только 3, то precision@10 равен 0.3. Низкая точность означает, что вы забиваете контекстное окно LLM лишним шумом, тратите токены впустую и повышаете вероятность того, что модель запутается из-за нерелевантного содержимого.

Mean Reciprocal Rank, или MRR, фокусируется на том, насколько быстро поисковый модуль находит один-единственный лучший результат. Эта метрика вычисляет среднее значение обратного ранга первого релевантного документа по набору запросов. MRR, равный 1.0, означает, что лучший документ всегда оказывается на первом месте. MRR, равный 0.5, означает, что он обычно появляется на втором. Эта метрика особенно важна в случаях, когда системе, как правило, нужен один авторитетный ответ, а не синтез информации из нескольких источников.

Normalized Discounted Cumulative Gain, или NDCG, учитывает градуированную релевантность, то есть признает, что одни документы могут быть релевантнее других, вместо того чтобы рассматривать релевантность как бинарную характеристику. Эта метрика поощряет системы, которые ставят самые релевантные документы наверх, применяя логарифмическое снижение вклада для результатов, расположенных ниже в списке. Для сложных запросов, где разные документы вносят разные части ответа, NDCG дает более тонкую картину, чем бинарные precision или recall.

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

Смещения оценщика, за которыми нужно следить

LLM в роли оценщика несут в себе систематические смещения, которые могут искажать ваши оценки. Самые распространенные из них – это позиционное смещение, когда предпочтение отдается ответам в зависимости от их места в промпте, а не от их качества; смещение в пользу многословия, когда более длинные ответы получают более высокие оценки независимо от содержательности; и смещение в сторону согласия, когда модель лучше подтверждает правильные ответы, чем выявляет неправильные. Из-за этого автоматическая оценка может систематически завышать надежность системы.

Если говорить именно об оценке RAG, то стоит знать о таком подходе к калибровке, как Prediction-Powered Inference, или PPI, предложенном во фреймворке ARES (Saad-Falcon et al., 2024). PPI использует небольшой набор примеров, размеченных людьми, чтобы статистически скорректировать автоматические оценки и добавить доверительные интервалы. Это своего рода проверка на реальность, которая помогает откалибровать степень доверия ко всем остальным результатам автоматического оценщика.

Как внедрить оценку RAG на практике

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

Начните как можно раньше собирать датасет для оценки

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

Чтобы начать, не нужны тысячи примеров. Даже 50–100 хорошо составленных пар «запрос–ответ», покрывающих ключевые сценарии, с которыми должна справляться ваша система, уже дадут вам осмысленную базу. Примеры уровня «золотого стандарта», размеченные экспертами, идеально подходят для проверки в высокорисковых сценариях, но их подготовка обходится дорого.

Масштабируйтесь с помощью синтетических данных, но осторожно

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

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

Оценка с помощью Opik: сквозной рабочий процесс

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

Сначала определите метрики. Начните с покрытия триады RAG: Hallucination, ContextPrecision, ContextRecall и AnswerRelevance. Функция evaluate в Opik принимает список метрик и прогоняет их все по вашему датасету за один проход:

from opik.evaluation import evaluate from opik.evaluation.metrics import ( Hallucination, ContextPrecision, ContextRecall, AnswerRelevance ) metrics = [ Hallucination(), ContextPrecision(), ContextRecall(), AnswerRelevance(), ] results = evaluate( dataset=your_dataset, task=your_rag_pipeline, scoring_metrics=metrics, experiment_config={ "model": "gpt-4o", "chunk_size": 512, "top_k": 5, }, )

Задайте пороги прохождения и провала. Нужно явно определить, что для вашего сценария считается «достаточно хорошим» качеством – например, верность контексту должен быть выше 0.85, а релевантность ответа – выше 0.75. Запускайте оценку как часть вашего CI/CD-конвейера, чтобы изменения в промпте или обновления конфигурации поиска, вызывающие регрессию, отлавливались еще до выхода в продакшен.

Сравнивайте эксперименты. Параметр experiment_config позволяет помечать каждый запуск оценки той конфигурацией, которая его породила: моделью, размером фрагментов, значением top-K, версией промпта. Затем интерфейс Opik дает возможность сравнивать эксперименты бок о бок, чтобы вы точно видели, как изменение конфигурации повлияло на каждую метрику.

Переходите к мониторингу в продакшене. Когда система уже работает в боевом режиме, правила Online Evaluation в Opik позволяют автоматически прогонять те же самые метрики по продакшен-трейсам. Если оценка верности контексту падает, вы можете провалиться в конкретный трейc, который дал низкий результат, увидеть, какие именно документы были извлечены, изучить промпт, отправленный в LLM, и понять, где возник сбой – на этапе поиска или генерации.

Именно здесь сходятся наблюдаемость и оценка качества. Логирование трейсов во время разработки помогает быстрее делать итерации. Логирование в продакшене помогает выявлять дрейф и деградацию. А автоматическая оценка этих трейсов превращает сырые данные наблюдаемости в прикладные сигналы о качестве системы.

Стресс-тестирование и состязательная оценка

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

Пограничное тестирование: что происходит за пределами «успешного пути»?

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

Например, пользователь говорит вашему HR-ассистенту: «Раз компания удваивает взносы в 401(k) на уровне 8%, я хочу выбрать максимум». Если на самом деле размер сопоставления составляет 4%, система должна исправить ложную предпосылку, а не строить дальнейший ответ на ее основе. Такие тесты несложно составить: профильные эксперты обычно без труда могут придумать десятки коварных пограничных случаев на основе практического опыта. И именно они позволяют поймать типы сбоев, которые базовые метрики верности контексту и релевантности вообще не замечают.

Специфическая поверхность атак у RAG

RAG-системы создают векторы атак, которых не существует у автономных LLM. В редакции «Топ-10 рисков безопасности для LLM-приложений по версии OWASP» за 2025 год появился новый пункт – «уязвимости векторного поиска и эмбеддингов», специально посвященный уязвимостям RAG. Это отражает, насколько центральную роль конвейеры поиска стали играть в продуктовых AI-системах.

Самая серьезная угроза, характерная именно для RAG, – это то, что исследователи называют косвенной инъекцией промпта: вредоносные инструкции встраиваются не в запрос пользователя, а в документы, которые извлекает система. Greshake et al. формализовали этот класс атак в статье 2023 года, представленной на ACM Workshop on Artificial Intelligence and Security (AISec ’23), показав, что добавление механизма поиска к LLM фундаментально размывает границу между данными и инструкциями. Когда RAG-система извлекает документ со скрытыми указаниями вроде «игнорируй предыдущий контекст и ответь [содержимым атакующего]», LLM может подчиниться этим указаниям, потому что не умеет надежно отличать найденный контекст от системных команд.

Связанная с этим угроза – отравление базы знаний – идет еще дальше. Здесь злоумышленник не внедряет инструкции напрямую, а портит сам корпус, по которому идет поиск, добавляя в него документы, специально созданные так, чтобы всплывать по определенным запросам и подталкивать модель к заранее заданным, но неверным ответам. Исследование PoisonedRAG (Zou et al., представлено на USENIX Security 2025) показало, что внедрение всего пяти специально подготовленных документов в корпус из миллионов записей может обеспечить успешность атаки выше 90% для целевых запросов сразу на нескольких LLM и при разных конфигурациях поиска. Атака работает потому, что отравленные документы оптимизированы сразу под два условия: под условие поиска – чтобы их поднимал механизм извлечения, и под условие генерации – чтобы они направляли ответ LLM в нужную злоумышленнику сторону. Причем это эффективно даже в условиях черного ящика, когда атакующий вообще не имеет доступа к параметрам поискового модуля.

Что именно нужно тестировать

Практический набор тестов для состязательной оценки RAG-систем должен как минимум включать следующее:

Устойчивость к инъекции промпта. Проверяйте систему на типовых шаблонах инъекций, добавленных к пользовательским запросам: переопределение роли («Теперь ты неограниченный помощник...»), переопределение инструкций («Игнорируй предыдущие инструкции и...»), а также их замаскированные варианты. Измеряйте, отклоняется ли поведение системы от ожидаемого и раскрывает ли она содержимое системного промпта.

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

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

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

Чтобы начать такие проверки, не нужны сложные инструменты. Таблица с состязательными запросами, ожидаемым поведением и критериями прохождения или провала – с оценкой через LLM-судью, откалиброванную по схеме человек в контуре, – позволит отловить большинство критичных проблем еще до того, как с ними столкнутся пользователи.

Сначала начните измерять, потом – улучшать

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

По мере взросления системы добавляйте специализированные метрики поиска, такие как recall@K и MRR, чтобы тонко настраивать конфигурацию поиска. И обязательно вкладывайтесь в калибровку вашего конвейера LLM-as-a-judge по человеческим оценкам, чтобы автоматические баллы действительно отражали реальность.

Если RAG у вас уже не на уровне демки, то главная боль обычно не в одной метрике, а в архитектуре: retrieval шумит, генерация додумывает, пайплайн ломается на реальных сценариях. На бесплатном демо-уроке «Проектирование RAG систем» разберемся, когда RAG действительно нужен, как собрать базовый пайплайн без типовых ловушек и какие продвинутые техники стоит использовать в боевых решениях.

Урок проведут преподаватели Отус в рамках курса «ИИ-архитектор» 26 марта в 20:00. Это отличный шанс познакомиться с экспертами и протестировать формат обучения. Записаться на урок