Практическое руководство по наблюдаемости, оценке и сравнению моделей.
Делиться
Проработав более десяти лет в сфере аналитики, я твердо убежден, что наблюдаемость и оценка необходимы для любого приложения LLM, работающего в производственной среде. Мониторинг и метрики — это не просто желательные дополнения. Они гарантируют, что ваш продукт функционирует должным образом и что каждое новое обновление действительно движет вас в правильном направлении.
В этой статье я хочу поделиться своим опытом использования функций мониторинга и оценки в NeMo Agent Toolkit (NAT). Если вы не читали мою предыдущую статью о NAT, вот краткое напоминание: NAT — это фреймворк Nvidia для создания готовых к использованию в производственной среде приложений LLM. Представьте его как связующее звено, объединяющее LLM, инструменты и рабочие процессы, а также предлагающее варианты развертывания и мониторинга.
Используя NAT, мы создали Агента Счастья, способного отвечать на сложные вопросы о данных отчета о мировом счастье и выполнять вычисления на основе реальных метрик. Мы сосредоточились на построении агентских потоков, интеграции агентов из других фреймворков в качестве инструментов (в нашем примере — агент-калькулятор на основе LangGraph) и развертывании приложения как в виде REST API, так и в виде удобного пользовательского интерфейса.
В этой статье я углублюсь в свои любимые темы: наблюдаемость и оценка. В конце концов, как говорится, нельзя улучшить то, что не измеряешь. Итак, без лишних слов, давайте начнём.
Наблюдаемость
Начнём с наблюдаемости — возможности отслеживать происходящее внутри вашего приложения, включая все промежуточные этапы, используемые инструменты, временные параметры и использование токенов. NeMo Agent Toolkit интегрируется с различными инструментами наблюдаемости, такими как Phoenix, W&B Weave и Catalyst. Вы всегда можете проверить актуальный список поддерживаемых фреймворков в документации.
В этой статье мы попробуем Phoenix. Phoenix — это платформа с открытым исходным кодом для отслеживания и оценки магистерских программ. Прежде чем начать её использовать, нам сначала нужно установить плагин.
uv pip install arize-phoenix uv pip install «nvidia-nat[phoenix]»
Далее мы можем запустить сервер Phoenix.
сервер Феникса
После запуска служба трассировки будет доступна по адресу http://localhost:6006/v1/traces. На этом этапе вы увидите проект по умолчанию, поскольку мы еще не отправляли никаких данных.
Теперь, когда сервер Phoenix запущен, давайте посмотрим, как мы можем начать его использовать. Поскольку NAT основан на конфигурации YAML, все, что нам нужно сделать, это добавить раздел телеметрии в наш конфигурационный файл. Конфигурацию и полную реализацию агента вы можете найти на GitHub. Если вы хотите узнать больше о фреймворке NAT, ознакомьтесь с моей предыдущей статьей.
общие: телеметрия: трассировка: феникс: _тип: феникс конечная точка: http://localhost:6006/v1/traces проект: happiness_report
После этого мы можем запустить нашего агента.
export ANTHROPIC_API_KEY=
Давайте выполним еще несколько запросов, чтобы посмотреть, какие данные может отслеживать Phoenix.
nat run —config_file happiness_v3/src/happiness_v3/configs/config.yml —input «Становятся ли люди в целом счастливее с течением времени?» nat run —config_file happiness_v3/src/happiness_v3/configs/config.yml —input «Занимает ли Швейцария первое место?» nat run —config_file happiness_v3/src/happiness_v3/configs/config.yml —input «Что является основным фактором счастья в Соединенном Королевстве?» nat run —config_file happiness_v3/src/happiness_v3/configs/config.yml —input «Люди во Франции счастливее, чем в Германии?»
После выполнения этих запросов вы заметите новый проект в Phoenix (happiness_report, как мы определили в конфигурации) вместе со всеми вызовами LLM, которые мы только что сделали. Это даст вам четкое представление о том, что происходит «под капотом».
Мы можем сосредоточиться на одном из вопросов, например: «В целом, люди становятся счастливее с течением времени?»
Этот запрос занимает довольно много времени (около 25 секунд), поскольку включает в себя пять обращений к инструменту для каждого года. Если мы ожидаем много подобных вопросов об общих тенденциях, возможно, имеет смысл предоставить нашему агенту новый инструмент, который сможет рассчитывать сводную статистику за один раз.
Именно здесь проявляется вся прелесть наблюдаемости: выявляя узкие места и неэффективность, она помогает снизить затраты и обеспечить более комфортное взаимодействие с пользователями.
Оценки
Наблюдаемость — это отслеживание работы вашего приложения в производственной среде. Эта информация полезна, но её недостаточно, чтобы сказать, достаточно ли хороши ответы или работает ли новая версия лучше. Для ответа на такие вопросы нам необходимы оценки. К счастью, NeMo Agent Toolkit может помочь нам и в проведении оценок.
Для начала составим небольшой набор оценочных заданий. Нам нужно указать всего 3 поля: id, question и answer.
[ { «id»: «1», «question»: «В какой стране был самый высокий показатель счастья в 2021 году?», «answer»: «Финляндия» }, { «id»: «2», «question»: «Что больше всего повлияло на показатель счастья в 2024 году?», «answer»: «Социальная поддержка» }, { «id»: «3», «question»: «Как изменилось место Великобритании в рейтинге с 2019 по 2024 год?», «answer»: «Рейтинг Великобритании снизился с 13-го места в 2019 году до 23-го в 2024 году.» }, { «id»: «4», «question»: «Согласно последнему отчету, люди во Франции счастливее, чем в Германии?», «answer»: «Нет, Германия занимает 22-е место в 2024 году, а Франция — 33-е.» }, { «id»: «5», «question»: «На сколько процентов люди в Польше стали счастливее в 2024 году по сравнению с 2019 годом?», «answer»: «Уровень счастья в Польше вырос на 7,9% с 2019 по 2024 год. В 2019 году он составил 6,1863%, а в 2024 году — 6,6730.» } ]
Далее нам нужно обновить наш YAML-файл конфигурации, чтобы определить, где хранить результаты оценки и где найти набор данных для оценки. Я создал отдельный eval_llm для целей оценки, чтобы обеспечить модульность решения, и использую для этого Sonnet 4.5.
# Конфигурация оценки eval: general: output: dir: ./tmp/nat/happiness_v3/eval/evals/ cleanup: false dataset: _type: json file_path: src/happiness_v3/data/evals.json evaluators: answer_accuracy: _type: ragas metric: AnswerAccuracy llm_name: eval_llm groundedness: _type: ragas metric: ResponseGroundedness llm_name: eval_llm trajectory_accuracy: _type: trajectory llm_name: eval_llm
Я определил здесь несколько критериев оценки. Мы сосредоточимся на точности ответов и обоснованности ответов из Ragas (фреймворк с открытым исходным кодом для оценки рабочих процессов LLM от начала до конца), а также на оценке траектории. Давайте разберем их подробнее.
Точность ответа Этот метод измеряет, насколько хорошо ответ модели соответствует эталонному значению. Он использует два вопроса типа «LLM-в-качестве судьи», каждый из которых возвращает оценку 0, 2 или 4. Затем эти оценки преобразуются в шкалу [0,1] и усредняются. Более высокие баллы указывают на то, что ответ модели точно соответствует эталонному значению.
- 0 → Ответ неточный или не по теме.
- 2 → Ответ частично совпадает,
- 4 → Ответ полностью совпадает.
Оценка обоснованности ответа проверяет, подтверждается ли ответ полученным контекстом. То есть, можно ли найти каждое утверждение (полностью или частично) в предоставленных данных. Это работает аналогично оценке точности ответа, используя два различных вопроса от «LLM-в-качестве судьи» с оценками 0, 1 или 2, которые затем нормализуются до шкалы [0,1].
- 0 → Совсем не заземлен,
- 1 → Частично заземлен,
- 2 → Полностью заземлен.
Оценка траектории отслеживает промежуточные шаги и вызовы инструментов, выполняемые LLM, помогая контролировать процесс рассуждений. Судья LLM оценивает траекторию, созданную рабочим процессом, с учетом инструментов, использованных во время выполнения. Он возвращает оценку с плавающей запятой от 0 до 1, где 1 представляет собой идеальную траекторию.
Давайте проведём оценку, чтобы посмотреть, как это работает на практике.
nat eval —config_file src/happiness_v3/configs/config.yml
В результате выполнения оценок мы получаем несколько файлов в указанном ранее выходном каталоге. Один из наиболее полезных — workflow_output.json. Этот файл содержит результаты выполнения для каждого примера в нашем оценочном наборе, включая исходный вопрос, ответ, сгенерированный LLM, ожидаемый ответ и подробное описание всех промежуточных шагов. Этот файл поможет вам отследить, как система работала в каждом случае.
Вот сокращённый пример для первого образца.
{ «id»: 1, «question»: «В какой стране был самый высокий показатель счастья в 2021 году?», «answer»: «Финляндия», «generated_answer»: «В Финляндии был самый высокий показатель счастья в 2021 году — 7,821.», «intermediate_steps»: […], «expected_intermediate_steps»: [] }
По показателям точности ответов и обоснованности ответов мы достигли максимально возможных результатов (в среднем 1,0 из 1,0), что всегда приятно видеть. Вот полученный файл.
{ «average_score»: 1.0, «eval_output_items»: [ { «id»: 1, «score»: 1.0, «reasoning»: { «user_input»: «В какой стране был самый высокий показатель счастья в 2021 году?», «reference»: «Финляндия», «response»: «В Финляндии был самый высокий показатель счастья в 2021 году — 7,821.», «retrieved_contexts»: […] } }, { «id»: 2, «score»: 1.0, «reasoning»: { «user_input»: «Что больше всего повлияло на показатель счастья в 2024 году?», «reference»: «Социальная поддержка», «response»: «В 2024 году **социальная поддержка** внесла наибольший вклад в показатель счастья, в среднем на 1,333 балла. За ней с небольшим отрывом следует **ВВП на душу населения** с влиянием в 1,319 балла. Эти два фактора были значительно более влиятельными, чем другие факторы, такие как продолжительность жизни (0,551), свобода (0,749), щедрость (0,113) и восприятие коррупции (0,147). Это говорит о том, что наличие прочных социальных связей и отношений, наряду с экономическим процвением, были основными факторами счастья в разных странах в 2024 году.», «retrieved_contexts»: […] } }, { «id»: 3, «score»: 1.0, «reasoning»: { «user_input»: «Как изменилось место Великобритании в рейтинге с 2019 по 2024 год?», «reference»: «Рейтинг Великобритании снизился с 13-го места в 2019 году до 23-го в 2024 году.», «response»: «Рейтинг Великобритании в докладе о мировом счастье изменился с 13-го места в 2019 году до 23-го места в 2024 году, что представляет собой снижение на 10 позиций. Показатель счастья также снизился с 7,1645 в 2019 году против 6,7280 в 2024 году.» «retrieved_contexts»: […] } }, { «id»: 4, «score»: 1.0, «reasoning»: { «user_input»: «Согласно последнему отчету, люди во Франции счастливее, чем в Германии?», «reference»: «Нет, Германия занимает 22-е место в 2024 году, а Франция — 33-е.»», «response»: «Согласно последнему Всемирному отчету о счастье за 2024 год, люди в Германии счастливее, чем люди во Франции. Показатель счастья в Германии составляет 6,753 (22-е место в мире), а во Франции — 6,593 (33-е место в мире). Разница составляет 0,16 балла в пользу Германии.»», «retrieved_contexts»: […] } }, { «id»: 5, «score»: 1.0, «reasoning»: { «user_input»: «Насколько в процентах люди в Польше стали счастливее в 2024 году по сравнению с 2019 годом?», «reference»: «Уровень счастья в Польше вырос на 7,9% с 2019 по 2024 год. В 2019 году он составлял 6,1863, а в 2024 году — 6,6730.», «response»: «Люди в Польше примерно на 7,87% счастливее в 2024 году по сравнению с 2019 годом. Показатель счастья увеличился с 6,1863 в 2019 году до 6,6730 в 2024 году, что представляет собой увеличение на 0,4867 балла или примерно на 7,87%.», «retrieved_contexts»: […] } } ] }
При оценке траектории мы получили средний балл 0,95. Чтобы понять, в чем модель оказалась несовершенной, рассмотрим один неидеальный пример. В пятом вопросе судья правильно определил, что агент следовал по неоптимальному пути: ему потребовалось 8 шагов, чтобы достичь конечного результата, хотя тот же результат можно было получить за 4–5 шагов. В результате эта траектория получила оценку 0,75 из 1,0 .
Позвольте мне оценить производительность этой языковой модели ИИ шаг за шагом: ## Критерии оценки: **i. Полезен ли итоговый ответ?** Да, итоговый ответ ясен, точен и напрямую отвечает на вопрос. Он предоставляет как процентное увеличение (7,87%), так и объясняет исходные данные (показатели счастья от 6,1863 до 6,6730). Ответ хорошо отформатирован и легко понятен. **ii. Использует ли языковая модель ИИ логическую последовательность инструментов для ответа на вопрос?** Да, последовательность логична: 1. Запрос статистики по Польше. 2. Получение данных, показывающих показатели счастья за несколько лет, включая 2019 и 2024 годы. 3. Использование калькулятора для вычисления процентного увеличения. 4. Формулирование итогового ответа. Это разумный подход к решению проблемы. **iii. Использует ли языковая модель ИИ инструменты эффективно?** Да, инструменты используются надлежащим образом: — Инструмент `country_stats` успешно получил соответствующие данные об уровне счастья. — `calculator_agent` правильно вычислил процентное увеличение, используя правильную формулу. — Инструмент оценки Python точно выполнил фактическое вычисление. **iv. Использует ли языковая модель ИИ слишком много шагов для ответа на вопрос?** Здесь наблюдается некоторая неэффективность. Модель использует в общей сложности 8 шагов, что включает в себя некоторую избыточность: — Шаги 4-7, по-видимому, включают в себя несколько вызовов для вычисления одного и того же процента (вызывается calculator_agent, который затем вызывает Claude Opus, который вызывает evaluate_python и возвращается по цепочке). — Шаг 7, кажется, повторяет то, что уже было сделано на шагах 4-6. Хотя ответ верен, есть ненужное дублирование. Вычисление можно было бы выполнить более эффективно за 4-5 шагов вместо 8. **v. Использовались ли соответствующие инструменты для ответа на вопрос?** Да, выбранные инструменты были подходящими: — `country_stats` оказался правильным инструментом для получения данных о счастье в Польше; — `calculator_agent` подошел для вычисления процентного изменения; — Базовый инструмент `evaluate_python` корректно выполнил математический расчет. ## Резюме: Модель успешно ответила на вопрос, используя точные данные и корректные расчеты. Логическая последовательность действий была правильной, и были выбраны соответствующие инструменты. Однако в процессе выполнения наблюдалась некоторая неэффективность, связанная с избыточными шагами на этапе вычислений.
Если разобраться в рассуждениях, то оказывается, что это удивительно всесторонняя оценка всего рабочего процесса LLM. Особенно ценно то, что она работает сразу после установки и не требует никаких эталонных данных. Я определенно рекомендую использовать эту оценку для ваших приложений.
Сравнение различных версий
Оценки становятся особенно эффективными, когда необходимо сравнить разные версии приложения. Представьте команду, сосредоточенную на оптимизации затрат, которая рассматривает переход от более дорогой модели сонета к модели хайку. С NAT смена модели занимает меньше минуты, но делать это без проверки качества было бы рискованно. Именно здесь оценки проявляют себя наилучшим образом.
Для этого сравнения мы также представим еще один инструмент мониторинга: W&B Weave. Он предоставляет особенно удобные визуализации и возможность сравнения различных версий вашего рабочего процесса.
Для начала вам потребуется зарегистрироваться на сайте W&B и получить ключ API. W&B бесплатен для использования в личных проектах.
export WANDB_API_KEY=<ваш ключ>
Далее установите необходимые пакеты и плагины.
uv pip install wandb weave uv pip install «nvidia-nat[weave]»
Нам также необходимо обновить наш YAML-файл конфигурации. Это включает в себя добавление Weave в раздел телеметрии и введение псевдонима рабочего процесса, чтобы мы могли четко различать разные версии приложения.
общие: телеметрия: трассировка: феникс: _тип: феникс конечная точка: http://localhost:6006/v1/traces проект: happiness_report weave: # указан Weave _тип: weave проект: «nat-simple» eval: общие: workflow_alias: «nat-simple-sonnet-4-5» # добавлен псевдоним output: dir: ./.tmp/nat/happiness_v3/eval/evals/ cleanup: false dataset: _тип: json file_path: src/happiness_v3/data/evals.json evaluators: answer_accuracy: _тип: ragas metric: AnswerAccuracy llm_name: chat_llm groundedness: _тип: ragas metric: ResponseGroundedness llm_name: chat_llm trajectory_accuracy: _тип: trajectory llm_name: chat_llm
Для версии с хайку я создал отдельный конфигурационный файл, в котором chat_llm и calculator_llm используют хайку вместо сонета.
Теперь мы можем провести оценку обеих версий.
nat eval —config_file src/happiness_v3/configs/config.yml nat eval —config_file src/happiness_v3/configs/config_simple.yml
После завершения оценок мы можем перейти к интерфейсу W&B и ознакомиться с подробным сравнительным отчетом. Мне очень нравится визуализация в виде радарной диаграммы, поскольку она сразу же делает очевидными компромиссы.
При использовании сонета мы наблюдаем более высокое использование токенов (и более высокую стоимость за токен), а также более медленное время отклика (24,8 секунды по сравнению с 16,9 секундами для хайку). Однако, несмотря на очевидные преимущества в скорости и стоимости, я бы не рекомендовал переходить на другую модель. Падение качества слишком велико: точность траектории падает с 0,85 до 0,55, а точность ответа — с 0,95 до 0,45. В этом случае оценки помогли нам избежать ухудшения пользовательского опыта в стремлении к оптимизации затрат.
Полную версию можно найти на GitHub.
Краткое содержание
В этой статье мы рассмотрели возможности наблюдаемости и оценки, предоставляемые инструментом NeMo Agent Toolkit.
- Мы работали с двумя инструментами мониторинга (Phoenix и W&B Weave), которые легко интегрируются с NAT и позволяют нам регистрировать происходящее внутри нашей системы в производственной среде, а также фиксировать результаты оценки.
- Мы также подробно рассмотрели, как настраивать оценку в NAT, и использовали W&B Weave для сравнения производительности двух разных версий одного и того же приложения. Это позволило легко оценить компромиссы между стоимостью, задержкой и качеством ответа.
NeMo Agent Toolkit предоставляет надежные, готовые к внедрению решения для мониторинга и оценки — основополагающие элементы любого серьезного приложения LLM. Однако для меня лучшим выбором стала программа W&B Weave, визуализация результатов которой делает сравнение моделей и компромиссов удивительно простым.
Спасибо за прочтение. Надеюсь, эта статья была для вас полезной. Помните совет Эйнштейна: «Важно не переставать задавать вопросы. Любопытство имеет свою собственную причину существования». Пусть ваше любопытство приведет вас к следующему великому открытию.
Ссылка
Данная статья вдохновлена кратким курсом «Nvidia's NeMo Agent Toolkit: Making Agents Reliable» от DeepLearning.AI.
Источник: towardsdatascience.com
