Доброго времени суток!

В прошлой статье мы немного поговорили, о понятии GoldenSet и том, что он необходим нам для того, чтобы оценивать нашу ИИ систему. А так же рассмотрели простой пример, как можно получить такой GoldenSet, для RAG системы автоматически, используя фреймворк RAGAS.

Давайте рассмотрим, что вообще разумно измерять в ИИ системе.

Немного расширим круг рассматриваемых метрик и не будем ограничиваться только RAG.

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

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

Factual Correctness

Рассмотрим это на примере реализации во фреймворке RAGAS, интересующая нас метрика - Factual Correctness.

Рассмотрим ее устройство детально.

Как часто бывает с LLM метриками, внутри мы увидим, достаточно простую реализацию, которая оперирует буквально 2-мя системными промптами:

Первый (ClaimDecompositionPrompt) используется для извлечения атомарных утверждений:

Decompose and break down each of the input sentences into one or more standalone statements. Each statement should be a standalone claim that can be independently verified. Follow the level of atomicity and coverage as shown in the examples.

К этому промпту в зависимости от настроек, добавляется несколько примеров в технике Few-Shot (эталоны запроса - пример правильного ответа от LLM)

Настроек такого рода у метрики 2:

atomicity: t.Literal["low", "high"] = "low"
coverage: t.Literal["low", "high"] = "low"

Атомарность (atomicity) - определяет на насколько мелкие утверждения нужно разбить фактический ответ
Покрытие (coverage) - определяет число извлекаемых утверждений, извлечь все факты из фактического ответа или только некоторые.

Я предпочитаю, в большинстве случаев ставить комбинацию high + high, так как в этом случае метрика наиболее точна, но понятно, что потребуется большее время для ее вычислений.

Когда утверждения извлечены, необходимо выполнить их сравнение с эталоном, тут используется еще один промпт и Few-Shot примеры к нему:

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.

Как мы видим, пока все достаточно просто. Получив оценку корректности утверждений, алгоритм сводит это к 3м метрикам на выбор:

Precision
Recall
F-beta score

Считаются, они в как обычно, но давайте освежим в памяти, на всякий случай:

TP(True Positive) - число утверждений в реальном ответе подтвержденные эталоном
FP(False Positive) - число утверждений в реальном ответе не подтвержденные в эталоне
FN(False Negative) - число утверждений в эталоне отсутствующие в реальном ответе (для вычисления этой метрики придется получить утверждения и для эталона)

Далее все просто:

$\text{Precision} = \frac{\text{TP}}{\text{TP} + \text{FP}}$ $\text{Recall} = \frac{\text{TP}}{\text{TP} + \text{FN}}$ $F_\beta = \frac{(1 + \beta^2) \cdot (\text{precision} \cdot \text{recall})}{(\beta^2 \cdot \text{precision} + \text{recall})}$

F-betа разновидность F меры, если нужно получить F1 просто не трогайте beta (по умолчанию там 1). Этот коэффициент используется для регулирование влияния Precision/Recall

больше 1 большее влияние Recall
меньше 1 большее влияние Precision

Метрика, крайне полезна в самых разных сценариях построения агентских систем, все, что нам нужно иметь GoldenSet и выверенные эталонный примеры.

Summarization Score

Суммаризация - генерация по длинному тексту, более короткого с сохранением смысла, одна из самых часто встречаемых техник в агентской системе. Работа с историей диалога, построение агентов для вайб-кодинга, заведение “карточек” с кратким описанием клиентских диалоговых сессий, построение графовых моделей по корпусу документов и т.п. совсем не всегда, нам доступен и не всегда рационален, подход с хранением всего контекста целиком или вынос его хранения в RAG топологию. Между тем суммаризация - конечно теряет часть информации и ее так же необходимо измерять. В Ragas для этого предлагается вполне качественный инструмент измерения - метрика Summarization Score.

Рассмотрим ее детально:

Основная идея метрики - текст после суммаризации, должен отвечать на те же вопросы что и текст до суммаризации. Сами вопросы и ответы метрика получает через LLM, делается это довольно просто:

Сперва извлекаем из оригинального текста ключевые сущности Библиотека делает это через промпт с Few-Shot примерами

Extract keyphrases of type: Person, Organization, Location, Date/Time, Monetary Values, and Percentages.

По каждой ключевой сущности генерируем вопрос опираясь на текст до суммаризации Cнова промт и Few-Shot примеры к нему

Based on the given text and keyphrases, generate closed-ended questions that can be answered with ‘1’ if the question can be answered using the text, or ‘0’ if it cannot. The questions should ALWAYS result in a ‘1’ based on the given text.

Важный момент: На все эти вопросы ответ из исходного текста всегда “да/нет” (1/0). Например, если ключевая фраза “Илон Маск”, вопрос может быть “Упоминается ли Илон Маск в тексте?”. Ответ из контекста — “1”.

По каждому вопросу ищем ответ в результате суммаризации: Как обычно ничего нового :-)

Based on the list of close-ended ‘1’ or ‘0’ questions, generate a JSON with key ‘answers’, which is a list of strings that determines whether the provided summary contains sufficient information to answer EACH question. Answers should STRICTLY be either ‘1’ or ‘0’. Answer ‘0’ if the provided summary does not contain enough information to answer the question and answer ‘1’ if the provided summary can answer the question.

Выход с этого шага, просто список нулей и единиц, каждый элемент списка соответствует тому удалось или нет, найти ответ в суммаризованном тексте.

Осталось свести этот список в разумную формулу.

$\text{Final Score} = \text{coeff} \cdot \underbrace{\frac{\text{Correct Answers}}{\text{Total Questions}}}_{\text{Summarization Score}} + (1 - \text{coeff}) \cdot \underbrace{\text{Conciseness Score}}_{?}$

С Summarization Score, должно быть все понятно, но давайте рассмотрим, что за Conciseness Score и coeff.

Eсли суммаризация просто скопирует весь исходный текст, она ответит на все вопросы правильно и получит идеальный балл. Но это плохая суммаризация! Она не краткая и вообще не работает. Для решения этой проблемы вводится Conciseness Score (Оценка лаконичности).

$\text{Conciseness Score} = 1 - \frac{\text{Length of Summary}}{\text{Length of Reference Context}}$

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

Последний параметр coeff - раз мы ввели лаконичность, нам теперь надо как-то зашить в формулу, что важнее лаконичность(компактность суммаризации) или ее качество, число правильных ответом на вопросы по ней, это этот коэффициент это и делает.

По умолчанию он равен 0.5. Это означает, что мы придаем равный вес качеству передачи информации и краткости.
Если вы хотите, чтобы метрика больше штрафовала за длинный текст, вы можете увеличить coeff (например, до 0.7), сделав акцент на Summarization Score.
Если вы хотите, чтобы метрика была более терпима к длине, вы можете уменьшить coeff (например, до 0.3).

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

Благодарю за внимание!

Инженерия качества: Как перестать надеяться на удачу и начать измерять своих ИИ-агентов [Часть 2]