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

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

На повестке дня:

• В чем разница между оценкой LLM и оценкой системы LLM, а также их преимущества

• Офлайн-оценки, что такое бенчмарки системы LLM, как создавать наборы данных для оценки и выбирать правильные метрики оценки LLM, а также распространенные ошибки

• Оценки в реальном времени и их польза для улучшения наборов данных для офлайн-оценок

• Реальные примеры использования систем LLM и как их оценивать, включая chatbotQA и Text-SQL

Давайте начнем.

Оценка LLM vs оценка системы LLM

Давайте разберемся: в то время как LLM (большая языковая модель) относится конкретно к модели (например, GPT-4), обученной понимать и генерировать человеческий язык. LLM-система, в свою очередь, представляет собой полную инфраструктуру, которая включает не только саму LLM, но и дополнительные компоненты, такие как вызовы функций (для агентов), системы поиска (в RAG), кэширование ответов и т.д., что делает LLM полезными для реальных приложений, таких как чат-боты поддержки клиентов, автономные агенты продаж и генераторы Text-to-SQL.

Однако важно отметить, что система LLM иногда может состоять из одной LLM, как в случае с ChatGPT. Вот пример системы LLM на основе RAG, которая выполняет задачу Text-to-SQL:

Основной целью Text-to-SQL является генерация правильного и эффективного SQL для заданного пользовательского запроса, поэтому пользовательский запрос обычно сначала используется для извлечения соответствующих таблиц в схеме базы данных через конвейер извлечения, прежде чем использовать его в качестве контекста для генерации правильного SQL через конвейер генерации SQL. Вместе они составляют систему LLM (основанную на RAG).

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

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

Например, вы можете применить метрику контекстной полноты для оценки конвейера извлечения в примере Text-to-SQL выше, чтобы оценить, может ли он извлечь все необходимые таблицы, необходимые для ответа на конкретный запрос пользователя.

Аналогичным образом вы можете применить пользовательскую метрику корректности SQL, реализованную через G-Eval, для оценки того, генерирует ли конвейер генерации правильный SQL на основе извлеченных таблиц данных top-K.

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

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

Офлайн-оценки: тестовые кейсы, наборы данных для оценки, метрики LLM и бенчмарки

Офлайн-оценки относятся к оценке или тестированию вашей системы LLM в локальной среде разработки. Представьте себе выполнение оценок в вашей локальной среде разработки, которая может быть чем угодно: от скрипта Python, Colab/Jupyter Notebooks до конвейеров CI/CD в Github Actions перед развертыванием в продакшн. Это позволяет количественно улучшить архитектуру вашей LLM-системы или даже подобрать идеальный набор гиперпараметров (например, используемую LLM, шаблоны промптов, модель эмбеддингов и т.д. для каждого компонента).

Некоторые инженеры называют этот процесс "бенчмаркингом" LLM-систем, и это абсолютно верно. Бенчмаркинг LLM-систем — это процесс количественного измерения их производительности на основе набора пользовательских критериев, используя метрики оценки LLM и стандартизированный набор данных для оценки. Именно так проводится оффлайн-оценка. Исходя из примера Text-to-SQL в предыдущем разделе, метрики, используемые для сравнительного анализа нашей системы LLM, будут контекстной полнотой и пользовательской метрикой корректности SQL. Эти метрики оценивают, насколько хорошо LLM-система Text-to-SQL справляется с набором пользовательских запросов и выводами SQL, которые мы называем тестовыми кейсами.

Что касается терминологии, вот что вам нужно знать:

• Бенчмарки состоят из (обычно одного) набора данных для оценки и метрик оценки LLM.

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

• Для одного бенчмарка может быть несколько метрик оценки LLM, каждая из которых оценивает различные части системы LLM для каждого тестового кейса.

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

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

pip install deepeval

from deepeval.dataset import EvaluationDataset
from deepeval.metrics import ContextualRecallMetric

metric = ContextualRecallMetric(threshold=
0.5
)

dataset = EvaluateionDataset(test_cases=[...])
dataset.evaluate(metrics=[metric)

И для тех, кто хочет начать оценку немедленно, ознакомьтесь с кратким руководством DeepEval.

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

Набор данных для оценки — это набор тестовых кейсов.

Тестовый кейс — это единица данных, содержащая всю необходимую информацию для модульного тестирования вашей LLM-системы. Вот основные параметры, которые входят в тестовый кейс для LLM:

• Входные данные — входные данные для вашей системы LLM.

• Фактические выходные данные — текстовый ответ, сгенерированный вашей системой LLM.

• Ожидаемые выходные данные — идеальный ответ для заданных входных данных для вашей системы LLM.

• Контекст извлечения — текстовые фрагменты/документы, извлеченные в конвейере RAG/системе извлечения.

• Контекст — идеальные текстовые фрагменты/документы, из которых выводятся ожидаемые выходные данные.

Вот в чем подвох: разные метрики требуют заполнения разных параметров в тестовом кейсе LLM. Например, метрика релевантности ответа без эталона (reference-less answer relevancy metric, о которой вы узнаете позже) требует только входных данных и фактического вывода. В то же время метрика релевантности ответа с эталоном (reference-based answer relevancy metric) потребует входных данных, фактического вывода и ожидаемого результата.

Другой пример вы можете найти в исходной метрике контекстной полноты, использованной ранее в примере Text-to-SQL. Поскольку контекстная полнота оценивает, способна ли ваша система извлечения извлекать все соответствующие фрагменты текста для ответа на определенный запрос, вам понадобятся входные данные (т. е. запрос) и контекст извлечения (т. е. соответствующие фрагменты текста, которые были извлечены).

Вот несколько правил, которым необходимо следовать при подготовке набора данных оценки:

• Начните с 50–100 тестовых кейсов. Вы можете либо сформировать их с нуля, либо использовать данные из продакшена (если ваша LLM-система уже развернута). На практике это количество оптимально: оно достаточно для выявления слабых мест в вашей системе и не слишком велико для начальной работы.

• Подбирайте тестовые кейсы которые наиболее вероятно могут не соответствовать критериям, выбранным для оценки вашей LLM-системы.

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

• Заполните тестовые кейсы ожидаемыми выходными данными. Как было объяснено в разделе о метриках LLM, метрики с использованием эталонных данных (reference-based metrics) обеспечивают гораздо более точные результаты. Поэтому важно заранее определить ожидаемые выходные данные.

Подготовить тестовые кейсы с ожидаемыми выходными данными - это определенно непростая задача, особенно для 50–100 тестовых кейсов. В настоящее время существует два основных способа создания наборов данных для оценки для бенчмаркинга вашей системы LLM:

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

• Генерация синтетических данных. Этот метод немного сложнее: использовать LLM для генерации 100 тестовых кейсов.

Генерация синтетических данных с помощью LLM включает предоставление LLM контекста (того же контекста в тестовом кейсе LLM, как описано выше) и генерацию соответствующих входных данных и ожидаемых выходных данных на основе заданного контекста.

Например, в случае использования Text-to-SQL хороший генератор синтетических данных будет:

1. Случайным образом (для разнообразия набора данных) выбирать разные таблицы в вашей базе данных и использовать их как контекст тестового кейса.

2. Генерировать пользовательский запрос в качестве входных данных для вашего тестового кейса.

3. Генерировать ожидаемые выходные данные на основе контекста и входных данных вашего тестового кейса.

4. Повторять эти шаги до тех пор, пока не будет создан разумный объем данных для оценки.

Однако необходимо развивать ввод тестовых кейсов, чтобы сделать его более реалистичным и неотличимым от данных, подготовленных вручную. Этот процесс называется эволюцией, и он был изначально представлен в статье Evol-Instruct от Microsoft.

Вот быстрый способ сгенерировать синтетические данные с использованием LLM через DeepEval:

from deepeval.dataset import EvaluationDataset

dataset = EvaluationDataset()
dataset.generate_goldens_from_docs(
    document_paths=['example.pdf'],
    include_expected_output=True,
    max_goldens_per_document=
5

)

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

Метрики LLM

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

В одной из моих предыдущих статей я подробно рассказал обо всем, что вам нужно знать о метриках оценки LLM, но вкратце повторю - традиционные метрики, такие как BERT, ROUGE и n-gram, не работают, потому что выходные данные LLM слишком сложны для оценки статистическими методами или моделями, не основанных на LLM. Решение — использовать подход LLM-as-a-judge («LLM в роли судьи»).

LLM-as-a-judge предполагает использование LLM для оценки тестовых кейсов. Возможно, вы сначала отнесетесь к этому подходу скептически, но исследования показали, что использование LLM для оценки других LLM — это максимально близкий к человеческому подход корреляции.

Более того, такие подходы, как G-Eval, использование промптов для уменьшения объема текста, который нужно оценить в тестовом кейсе, или применение метода QAG (Question Answer Generation) для математически более точного вычисления оценки метрики для каждого тестового кейса, помогают LLM генерировать результаты, гораздо лучше соответствующие ожиданиям человека. (Я настоятельно рекомендую прочитать эту статью, если у вас есть какие-либо вопросы или вы хотите узнать больше о том, как использовать LLM для оценки других LLM.)

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

• Корректность

• Релевантность ответа

• Достоверность

• Сходство

• Связность

• Контекстная полнота

• Контекстная релевантность

• Контекстная точность

• Предвзятость

• Токсичность

(DeepEval поддерживает каждую из этих метрик «из коробки», и вы можете ознакомиться с документацией, чтобы узнать больше о каждой метрике и ситуациях, в которых ее следует использовать.)

Например, вот как можно реализовать пользовательскую метрику корректности с подходом «LLM в роли судьи» на практике:

from deepeval.metrics import GEval
from deepeval.test_case import LLMTestCaseParams

correctness_metric = GEval(
    name="Correctness",
    criteria="Determine whether the actual output is factually correct based on information in the expected output.",
    evaluation_params=[
      LLMTestCaseParams.ACTUAL_OUTPUT, 
      LLMTestCaseParams.EXPECTED_OUTPUT
    ]
)

Когда вы проводите оценки на стадии разработки, следует стремиться использовать метрики на основе эталонов (reference-based metrics). Эталонные метрики сравнивают результат модели с заранее подготовленным «золотым» стандартом или идеальным ожидаемым выводом в тестовом кейсе.

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

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

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

Бенчмарки

Бенчмарки состоят из наборов данных для оценки и метрик LLM, и в отличие от типичных бенчмарков для LLM, все бенчмарки систем LLM являются кастомными. Это связано с тем, что:

• Не существует стандартных метрик оценки LLM для систем LLM (даже для данного варианта использования, такого как Text-to-SQL), поскольку метрики зависят от точной архитектуры системы LLM, и не существует стандартной архитектуры для любого отдельного варианта использования.

• Не существует стандартного набора тестовых кейсов/набора данных для оценки для конкретного варианта использования. Например, вам понадобятся два разных набора данных оценки для двух разных схем базы данных для варианта использования Text-to-SQL, поскольку пользовательские запросы и golden выходные данные SQL в тестовых кейсах будут разными.

И пока я не забыл, вот как вы можете протестировать свою систему LLM в коде, используя метрику релевантности ответа:

from deepeval.dataset import EvaluationDataset
from deepeval.test_case import LLMTestCase
from deepeval.metrics import AnswerRelevancyMetric

test_case = LLMTestCase(
  input="Why did the chicken cross the road?", 
  actual_output="Quite frankly, I don't want to know..."
)
metric = AnswerRelevancyMetric()

dataset = EvaluationDataset(test_cases=[test_case])
dataset.evaluate(metrics=[metric])

Типичные ошибки в оффлайн-оценке

Самая большая ошибка, которую можно совершить, — это предположить, что ваш набор данных для бенчмарка «достаточно хорош», чтобы его никогда не улучшать. Улучшение набора данных для бенчмарка имеет решающее значение, поскольку для того, чтобы ваш бенчмарк имел смысл, он всегда должен отражать самые последние уязвимости в вашем приложении LLM.

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

Оценки в реальном времени

(Если ваша система LLM ещё не в продакшене, этот раздел может быть вам не актуален.)

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

Данные из продакшена включают входные данные и ответы, которые ваша система LLM получает и генерирует в реальной рабочей среде. Но вот в чём проблема: у вас, скорее всего, не будет времени и ресурсов, чтобы проверить все ответы, сгенерированные системой LLM в продакшене, и решить, какие из них добавить в набор данных для оценки.

Представьте, что ваше приложение LLM генерирует 50 000 ответов в месяц. Скорее всего, вы не сможете просмотреть их все, не потеряв рассудок. Вы можете случайным образом выбрать 10% ответов для проверки вручную, но даже это останется крайне трудозатратной задачей. Именно поэтому оценка в реальном времени столь ценна.

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

Метрики LLM в продакшене

В предыдущем разделе о метриках LLM мы подчёркивали, что на этапе разработки следует использовать метрики, основанные на эталонных данных (reference-based metrics), так как они делают результаты более надёжными благодаря строгим критериям оценки.

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

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

Примеры использования

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

1. Генерация синтетических тестовых кейсов для вашего бенчмарка

2. Выбор соответствующих метрик оценки LLM

3. Запуск бенчмарка

Чат-бот QA

Чат-бот QA (вопрос-ответ) — это по сути поисковая система на базе чата, но в отличие от ChatGPT он не является полностью разговорным. Обычно используется для быстрого поиска информации в базе знаний. Такой чат-бот применяет подход RAG: сначала он извлекает релевантную информацию с помощью векторного поиска по базе данных, содержащей проанализированную и индексированную информацию из базы знаний, а затем передаёт эту информацию в LLM для генерации ответа на пользовательский запрос:

(Примечание: эта диаграмма и схема Text-to-SQL выглядят почти одинаково, поскольку оба варианта использования представляют собой упрощенную систему LLM на основе RAG)

Шаг 1: Предполагая, что у нас уже есть несколько PDF-документов, представляющих нашу базу знаний, под названием knowledge_1.pdf, knowledge_2.pdf и т. д., мы можем сгенерировать синтетические тестовые кейсы из этих документов для нашего чат-бота QA:

from deepeval.synthesizer import Synthesizer

synthesizer = Synthesizer()
goldens = synthesizer.generate_goldens_from_docs(
    document_paths=[
      'knowledge_1.pdf', 
      'knowledge_1.pdf',
      'knowledge_1.pdf',
      'knowledge_1.pdf',
      'knowledge_1.pdf',
      'knowledge_1.pdf'

    ],
    max_goldens_per_document=
15
,
    include_expected_output=True

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

from deepeval.metrics import GEval, ContextualRecallMetric
from deepeval.test_case import LLMTestCaseParams

contextual_recall = ContextualRecallMetric(threshold=
0.6
)
correctness = GEval(
    name="Correctness",
    criteria="Determine whether the actual output is factually correct based on the expected output.",
    evaluation_params=[
      LLMTestCaseParams.ACTUAL_OUTPUT, 
      LLMTestCaseParams.EXPECTED_OUTPUT
    ],
    threshold=
0.6

)

(Ссылка на документацию по метрикам здесь)

Метрика корректности G-Eval сравнивает фактическую правильность фактических выходных данных с ожидаемыми выходными данными, в то время как контекстная полнота оценивает, содержит ли контекст поиска всю информацию, необходимую для генерации ожидаемых выходных данных для заданных входных данных. Также обратите внимание, что мы установили порог прохождения для каждой метрики на 0,6; это означает, что тестовый кейс будет пройден, если обе метрики наберут оценку выше или равную 0,6.

(PS: Прокрутите вверх и снова посмотрите диаграмму Chatbot QA, чтобы понять, какую часть системы LLM оценивает каждая метрика.)

Шаг 3: Имея готовый набор данных оценки и метрики, мы можем запустить бенчмарк. Мы не собираемся внедрять систему чат-бота QA, но предположим, что у нас есть гипотетическая функция run_chatbot_qa(), которая возвращает сгенерированный ответ и извлеченные узлы, используемые для генерации ответа:

llm_output, retrieved_nodes = run_chatbot_qa("A user query")

Мы можем запустить бенчмарк, сначала преобразовав голдены, сгенерированные на шаге 1, в тестовые кейсы, готовые к оценке:

from deepeval.test_case import LLMTestCase
from deepeval.dataset import EvaluationDataset
...

test_cases = []
for golden in goldens:
  query = golden.input
  llm_output, retrieved_nodes = run_chatbot_qa(query)
  test_case = LLMTestCase(
    input=query,
    actual_output=llm_output,
    retrieval_context=retrieved_nodes,
    expected_output=golden.expected_output   
  )
  test_cases.append(test_case)

dataset = EvaluationDataset(test_cases=test_cases)

(Ссылка на документацию по датасету здесь)

И наконец, запустите свой бенчмарк, применяя к нашему набору данных две выбранные метрики:

...

dataset.evaluate(metrics=[correctness, contextual_recall])

Это было не так уж и сложно, верно?

Text-SQL

Text-SQL — это сценарий использования, в котором система LLM генерирует соответствующий SQL-запрос для ответа на аналитический вопрос о данных, например, «Сколько пользователей зарегистрировалось на прошлой неделе»?

Мы собираемся повторно использовать ту же диаграмму архитектуры Text-SQL, что и в начале этой статьи:

Шаг 1: На этом этапе генерации данных мы будем создавать синтетические эталонные данные (goldens) с использованием таблиц данных в схеме базы данных.

from deepeval.synthesizer import Synthesizer, UseCase

table1 = """CREATE TABLE Students (
    StudentID INT PRIMARY KEY,
    FirstName VARCHAR(50),
    LastName VARCHAR(50),
    Email VARCHAR(100) UNIQUE,
    DateOfBirth DATE,
    Gender CHAR(1),
    Address VARCHAR(200),
    PhoneNumber VARCHAR(15)
);"""

table2 = """CREATE TABLE Courses (
    CourseID INT PRIMARY KEY,
    CourseName VARCHAR(100),
    TeacherID INT,
    Credits INT,
    DepartmentID INT,
    FOREIGN KEY (TeacherID) REFERENCES Teachers(TeacherID),
    FOREIGN KEY (DepartmentID) REFERENCES Departments(DepartmentID)
);"""

table3 = """CREATE TABLE Enrollments (
    EnrollmentID INT PRIMARY KEY,
    StudentID INT,
    CourseID INT,
    EnrollmentDate DATE,
    Grade CHAR(2),
    FOREIGN KEY (StudentID) REFERENCES Students(StudentID),
    FOREIGN KEY (CourseID) REFERENCES Courses(CourseID)
);"""

table4 = """CREATE TABLE Teachers (
    TeacherID INT PRIMARY KEY,
    FirstName VARCHAR(50),
    LastName VARCHAR(50),
    Email VARCHAR(100) UNIQUE,
    DepartmentID INT,
    FOREIGN KEY (DepartmentID) REFERENCES Departments(DepartmentID)
);"""

synthesizer = Synthesizer()
goldens = synthesizer.generate_goldens(
    contexts=contexts,
    use_case=UseCase.TEXT2SQL,
    max_goldens_per_context=
15

)

Шаг 2: Мы будем использовать пользовательскую метрику корректности SQL и метрику контекстной полноты:

from deepeval.metrics import ContextualRecallMetric

contextual_recall = ContextualRecallMetric(threshold=
0.5
)
sql_correctness = GEval(
    name="SQL Correctness",
    evaluation_steps=[
        "Check the `actual output` for SQL syntax errors.",
        "Verify that the `actual output` SQL is compatible with the schema in the `retrieval context`, ensuring correct usage of tables and columns.",
        "Execute the `actual output` SQL and ensure the results precisely match the `expected output`.",
        "Confirm that the `actual output` SQL is indeed relevant to the `input` user query.",
    ],
    evaluation_params=[
        LLMTestCaseParams.INPUT,
        LLMTestCaseParams.ACTUAL_OUTPUT,
        LLMTestCaseParams.EXPECTED_OUTPUT,
        LLMTestCaseParams.RETRIEVAL_CONTEXT
    ],
)

(Ссылка на документацию по метрикам здесь)

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

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

sql_output, retrieved_tables = run_text_2_sql("How many users signed up last week?")

Мы можем запустить бенчмарк, сначала преобразовав голдены, сгенерированные в шаге 1, в тестовые кейсы, готовые к оценке:

from deepeval.test_case import LLMTestCase
from deepeval.dataset import EvaluationDataset
...

test_cases = []
for golden in goldens:
  query = golden.input
  sql_output, retrieved_tables = run_text_2_sql(query)
  test_case = LLMTestCase(
    input=query,
    actual_output=sql_output,
    retrieval_context=retrieved_tables,
    expected_output=golden.expected_output   
  )
  test_cases.append(test_case)

dataset = EvaluationDataset(test_cases=test_cases)

(Ссылка на документацию по датасету здесь)

И наконец, запустите свой бенчмарк, применяя к нашему набору данных две выбранные метрики:

...

dataset.evaluate(metrics=[sql_correctness, contextual_recall])

Заключение

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

Мы познакомились с методами оффлайн-оценки, включая концепцию бенчмаркинга с использованием пользовательских наборов данных и метрик для регрессионного тестирования систем LLM, и рассмотрели, как инструмент DeepEval поддерживает весь цикл оценки. Мы также подчеркнули важность регулярного обновления наборов данных для бенчмаркинга и рассмотрели, как оценки в реальном времени в продакшене могут способствовать этому процессу. И наконец, мы подробно разобрали два распространённых сценария применения систем LLM — чатбот для вопросов и ответов (Chatbot QA) и генерацию SQL-запросов (Text-to-SQL) — и изучили подходы к их оценке.