Доброго времени суток!
В прошлой статье, мы рассмотрели 2 достаточно универсальные метрики характерные для почти любой агентской системы, в этой сместим фокус внимания и поговорим об оценке самого популярного архитектурного шаблона RAG.
Есть довольно значительная вероятность, что уважаемый читатель, открывший статью про инженерию качества, уже знает, что такое RAG. Но на всякий случай дам краткое описание с ключевыми смыслами:
Что такое RAG и зачем он нужен
Когда мы работам с LLM мы довольно сильно ограничены длиной контекста - числом токенов(частей слов), которые модель может учесть в генерации ответа. Да, некоторые модели сейчас работают с контекстом больше 1 миллиона и даже бесплатный open source уже предлагает больше 200 тысяч. Для понимания роман “Война и мир” - от 600 до 800 тысяч токенов (в зависимости от в LLM), хватит ли нам этого для счастья? Интуитивно кажется, что да, но есть нюансы:
Потеря качества
Lost in the Middle, современные модели, совсем не одинаково трактуют содержимое в разных частях контекста и имеют свойство значительно лучше учитывать начало и конец контекста, скатываясь в бредогенератор когда мы оперируем чем-то в середине. Обычно нас совсем не устроит деградация качества, при ответе на вопросы из середины контекста, мало того если мы хотим от LLM режима максимальной точности, мы скорее всего в итоге тюнинга ограничим свои промпты и контекст к ним в сотни/тысячи токенов, даже если модель формально поддерживает миллион… Причин у явления много, если есть желание покопаться поглубже рекомендую полистать эту Статью, а тут я ограничусь довольно интуитивным объяснением:
Теоретически, механизм внимания используемый в LLM, позволяет модели “смотреть” на любой токен в последовательности с равной вероятностью, мы учитывает все имеющиеся токены, когда генерируем новый. Однако на практике модели обучаются выделять больше внимания тем частям текста, которые чаще встречаются в обучающих данных, а у обучающей выборке LLM есть особенность, эти данные часто имеют структуру, где ключевая информация находится в начале (введение/системный промпт) или в конце (вывод, заключение, учебный запрос от пользователя). Модель учится, что важная информация часто находится в этих позициях, и заметно хуже учитывает середину.
Значительный рост стоимости
Большие контексты довольно дороги, для одной пользовательской сессии может занимать гигабайты или десятки гигабайт памяти и если мы хотим, чтобы генерация была быстрой эта память GPU. Мы просто никогда не сведем экономику своего проекта если выдадим каждому пользователю огромный контекст, в случае если нашим агентом пользуются параллельно даже сотни пользователей, не говоря о больших порядках. Есть два популярных способа с этим жить:
Эпизодически использовать суммаризацию (метрику качества для нее, мы рассмотрели в прошлой статье)
Динамически подгружать только нужные части в контекст, но этот способ, сразу пораждает вопрос: “А как понять, какой контекст нужный”. Ответом на него и является архитектура RAG (хотя не только она тут применима) Что же это такое: Идея невероятно проста, если наш контекст основан на чем-то относительно статичном: корпоративных документах, исходном коде, картинках с котами, статьях для habr и т.п. давайте просто проиндексируем его заблаговременно каким-то способом, положим в специализированное хранилище и в каждом пользовательском запросе, по тексту самого запроса, просто будем доставать нужные части из индекса.
Общий пайплайн RAG
Таким образом мы сводим архитектуру системы к нескольким шагам:
Найти документы(или их части) которые потенциально могут быть полезны для ответа на запрос пользователя
Как-то их отранжировать и выбрать topN наиболее полезных
Все полезные упаковать в контекст к LLM, если нужно как-то пошаманив с ними дополнительно
По полученному контексту сгенерировать ответ на запрос Довольно просто и очень популярно, 2/3 проектов про ИИ на современном рынке, это что-то про RAG
Проблематика:
Давайте подойдем к метрикам, с проблематики которую они будут измерять, опишем, что именно в RAG может работать неправильно.
Мы не находим нужные фрагменты - мы не очень удачно проиндексировали свои данные и теперь в желаемый topN просто не попадают нужные данные, а если нет данных, то модель может их получить только бредогенерацией
Мы находим слишком много данных - опять же проблема в не очень корректной индексации, мы находим то, что нужно, но получаем в topN избыточные нецелевые данные, на которых начинаем ловить Lost in the Middle и палить вычислительные ресурсы в холостую.
Мы находим нужные данные, но модель не очень хорошо генерирует ответ, галлюцинирует или отвечает не совсем по теме запроса.
Давайте рассматривать как это измерять, как и в прошлых статьях на примере фреймворка RAGAS.
Начнем с поиска. Тут как в любой системе оперирующей SERP (Search Engine Results Page), нас интересует, чтобы нужные документы были в выдаче в принципе и чтобы более релевантные были выше в выдаче и метрики нам нужны соответствующие.
Context Precision
Первая метрика Context Precision - точность, измеряя именно ее, мы оцениваем релевантность выдачи и правильность порядка в соответствии с ней.
Формула довольно проста, но давайте рассмотрим ее подробнее:
TP_k (true positives@k) — число релевантных чанков в первых k результатах.
FP_k (false positives@k) — число нерелевантных чанков в первых k результатах.
v_k — индикатор: 1, если чанк k релевантен, иначе 0.
В знаменателе суммарное количество всех релевантных чанков среди первых K результатов.
Простой пример для понимания:
Представьте, что у нас есть список из 5 найденных чанков(документов). Мы нашли 2 правильных чанка. Правильные чанки находятся на позициях 2 и 5.
Позиция (k) | Правильный ли чанк (v_k)? | Precision@k (доля правильных в первых k) | Вклад в сумму (Precision@k × v_k) |
|---|---|---|---|
1 | Нет (0) | 0/1 = 0.0 | 0.0 × 0 = 0 |
2 | Да (1) | 1/2 = 0.5 | 0.5 × 1 = 0.5 |
3 | Нет (0) | 1/3 = 0.33 | 0.33 × 0 = 0 |
4 | Нет (0) | 1/4 = 0.25 | 0.25 × 0 = 0 |
5 | Да (1) | 2/5 = 0.4 | 0.4 × 1 = 0.4 |
Для второго ответа (позиция 2): Мы берем Precision@2, который равен 0.5, потому что только 1 из 2 первых документов был правильным. Этот “наказательный” балл за низкую точность в начале списка умножается на 1 (так как ответ правильный) и попадает в итоговую сумму.
Для пятого ответа (позиция 5): Мы берем Precision@5, который равен 0.4, потому что только 2 из 5 первых документов были правильными. Этот еще более низкий балл умножается на 1 и тоже попадает в сумму.
Сумма числителя: 0.5 + 0.4 = 0.9
Всего правильных документов в топ-5 (знаменатель): 2
Context Precision@5 = 0.9/2=0.45
Осталось, поговорить о том как вычисляется v_k, тут как и в примерах прошлой статьи, фреймворк просто эксплуатирует LLM со следующем промптом и примеры в технике Few-Shot
Given question, answer and context verify if the context was useful in arriving at the given answer. Give verdict as “1” if useful and “0” if not with json output.
В коде использование метрики выглядит вот так:
from ragas.metrics.collections import ContextPrecision
from ragas import SingleTurnSample
# Создаем экземпляр метрики
metric = ContextPrecision(llm=evaluator_llm)
# Формируем пример с контекстами, где правильные чанки на позициях 2 и 5
sample = SingleTurnSample(
user_input="Когда была основана Apple?",
retrieved_contexts=[
"Apple — это компания из Кремниевой долины.",
"Apple была основана в 1976 году.",
"Apple производит iPhone и iPad.",
"Apple имеет офисы по всему миру.",
"Основание Apple произошло 1 апреля 1976 года."
],
reference="1 апреля 1976 года"
)
# Вычисляем оценку
score = await metric.ascore(sample)
print(f"Context Precision@5: {score}")
Context Recall
Следующая метрика Context Recall полнота, определяет насколько наш SERP соотносится с эталонным ответом. Считается он крайне просто:
Самое любопытное тут конечно понятие “утверждение”, как легко догадаться, это результат обращения к LLM со следующим промптом и Few-Shot примерами
Given a context and an answer, analyze each statement in the answer and classify if the statement can be attributed to the given context or not. Use only binary classification: 1 if the statement can be attributed to the context, 0 if it cannot. Provide detailed reasoning for each classification.
У метрики довольно любопытная реализация, тут не стали как в Factual Correctness, отдельным проходом извлекать утверждения, а всю логику и определения утверждений и оценки их соответствия позиции в SERP, упаковали в единственный промпт с Few-Shot примерами и более сложным структурным выводом. Вообще это должно было негативно сказаться на точности и увеличить требования к когнитивности LLM, но так просто существенно быстрее, если разбирать сперва контекст и запрос на части, для оценки метрики на большом Golden Set ждать пришлось бы мучительно долго. У метрики есть более развесистая и точная вариации без этой особенности Context Entities Recall, для тех кто готов подождать, так же никто не запрещает прогнать и Factual Correctness, по мне это очень разумная практика.
Пример использования метрики в коде:
from ragas.metrics.collections import ContextRecall
from ragas import SingleTurnSample
metric = ContextRecall(llm=evaluator_llm)
sample = SingleTurnSample(
user_input="Кто основал Apple?",
retrieved_contexts=["Стив Джобс и Стив Возняк основали Apple."],
reference="Apple была основана Стивом Джобсом, Стивом Возняком и Рональдом Уэйном."
)
score = await metric.ascore(sample)
print(f"Context Recall: {score}") # Будет < 1.0, т.к. Уэйн не упомянут в контексте
Важно упомянуть, что Context Recall совсем не обязательно используют только для оценки и оптимизации поиска, есть немало техник построения RAG, в которых схожие промпты используются для сокращения нерелевантного ответа, уже на уровне Augmentation (этапа обработки SERP), с очень простой механикой: давайте попросим LLM повыкидывать из SERP все нерелевантное, а затем остаток отдадим на генерацию. Соотвественно Context Recall и его более тяжеловесные вариации, применимы и для оценки работы шага Augmentation.
Faithfulness
Последней в этой статье, рассмотрим метрику Faithfulness - “верность”, ее задача оценить последний шаг RAG пайплайна генерацию. Метрика оценивает все ли утверждения в ответе взяты из предоставленного контекста (отсутствие галлюцинаций). Как и две ранее упомянутые, она входит в тройку метрик “измеряемых при любых обстоятельствах”, в целом ее игнорирование крайне пагубная практика, к сожалению нередко встречаемая даже в казалось бы вполне взрослых платформах и конкретных реализациях RAG систем… Что иногда крайне развлекает меня, в процессе деятельности по аудиту различных ИИ систем :-)
Вы к этому моменту, уже наверное должны были осознать, что такое “утверждения” в терминах RAGAS, не буду сильно раздувать текст. В целом метрика крайне похожа на Factual Correctness, отличаясь ориентацией на верификацию SERP, а не сверку утверждений запроса с эталоном и менее сложным способом извлечь отдельные утверждения. Работает она в 3 прохода:
Сперва генерируем утверждения из сгенерированного ответа, используя промпт с примерами
Given a question and an answer, analyze the complexity of each sentence in the answer. Break down each sentence into one or more fully understandable statements. Ensure that no pronouns are used in any statement.
Затем верифицируем полученные утверждения по контексту(SERP от поискового движка), используя промпт с примерами
Your task is to judge the faithfulness of a series of statements based on a given context. For each statement you must return verdict as 1 if the statement can be directly inferred based on the context or 0 if the statement can not be directly inferred based on the context.
Забираем результат шага через структурный вывод и считаем итоговую метрику по формуле
Пример использования в коде:
from ragas.metrics.collections import Faithfulness
from ragas import SingleTurnSample
metric = Faithfulness(llm=evaluator_llm)
sample = SingleTurnSample(
retrieved_contexts=["Apple основана Стивом Джобсом."],
response="Apple основана Стивом Джобсом и Илоном Маском." # Галлюцинация!
)
score = await metric.ascore(sample)
print(f"Faithfulness: {score}") # Будет около 0.5
На этом, закончим данную статью. Надеюсь информация Вам была полезна! В следующей части поговорим об процессе Е-Е оценки.
Благодарю за внимание!