LLM Evals: Everything You Need to Know – Hamel’s Blog - Hamel Husain
Hamel Husain и Shreya Shankar собрали FAQ по оценке (evals) LLM-приложений на основе вопросов от 700+ инженеров и продакт-менеджеров. Центральная идея — анализ ошибок (error analysis) важнее любой инфраструктуры: нужно вручную просматривать 100+ трейсов, выявлять паттерны сбоев и лишь затем строить автоматические оценщики. Авторы рекомендуют бинарные (pass/fail) оценки вместо шкал Ликерта, назначение «доброжелательного диктатора» — единственного доменного эксперта — для аннотации, а также создание кастомных инструментов разметки вместо готовых решений. Отдельные разделы посвящены генерации синтетических данных через комбинации измерений, оценке RAG-систем (метрики извлечения отдельно от генерации), отладке многошаговых и агентных воркфлоу с помощью матриц переходных ошибок. В проектах авторов 60–80% времени разработки уходит на анализ ошибок и оценку, а не на построение автоматических проверок.
В этом документе собраны наиболее частые вопросы, которые мы со Shreya получали, обучая 700+ инженеров и продакт-менеджеров оценке ИИ-систем (AI Evals). Предупреждение: это резкие мнения о том, что работает в большинстве случаев. Это не универсальные истины. Руководствуйтесь собственным суждением.
👉 Хотите узнать больше об AI Evals? Ознакомьтесь с нашим курсом AI Evals. Это живая когорта с практическими упражнениями и часами вопросов-ответов. Вот промокод на скидку 25% для читателей. 👈
Послушайте аудиоверсию этого FAQ
Если вы предпочитаете аудиоверсию (озвученную ИИ), можете прослушать её здесь.
Начало работы и основы
В: Что такое LLM Evals?
Если вы совсем новичок в продуктовых LLM-оценках (не бенчмарках фундаментальных моделей), прочитайте эти статьи: часть 1, часть 2 и часть 3. В противном случае — читайте дальше.
Содержание:
Мотивация Быстрая итерация == Успех Кейс: Lucy, ИИ-ассистент для недвижимости Типы оценки Уровень 1: Юнит-тесты Уровень 2: Человеческая и модельная оценка Уровень 3: A/B-тестирование Оценка RAG Системы оценки открывают суперспособности Бесплатный файн-тюнинг Синтез и курирование данных Отладка
Содержание:
Проблема: ИИ-команды тонут в данных Шаг 1: Найдите главного доменного эксперта Шаг 2: Создайте датасет Шаг 3: Направьте доменного эксперта на вынесение суждений «Пройдено/Не пройдено» с критикой Шаг 4: Исправьте ошибки Шаг 5: Постройте LLM-as-a-Judge итеративно Шаг 6: Проведите анализ ошибок Шаг 7: Создайте более специализированных LLM-судей (при необходимости) Итоги Critique Shadowing Ресурсы
Содержание:
Как анализ ошибок стабильно выявляет улучшения с наибольшим ROI Почему простой просмотрщик данных — ваша самая важная инвестиция в ИИ Как дать возможность доменным экспертам (а не только инженерам) улучшать ваш ИИ Почему синтетические данные эффективнее, чем вы думаете Как поддерживать доверие к вашей системе оценки Почему в ИИ-дорожной карте нужно считать эксперименты, а не фичи
В: Что такое трейс?
Трейс — это полная запись всех действий, сообщений, вызовов инструментов и обращений к данным от одного начального запроса пользователя до финального ответа. Он включает каждый шаг по всем агентам, инструментам и системным компонентам в сессии: множественные сообщения пользователя, ответы ассистента, извлечённые документы и промежуточные взаимодействия с инструментами.
Примечание о терминологии: Разные поставщики систем наблюдаемости используют различные определения трейсов и спанов. Анализ Alex Strick van Linschoten подчёркивает эти различия (скриншот ниже):
В: Каков минимально жизнеспособный набор для оценки?
Начните с анализа ошибок, а не с инфраструктуры. Потратьте 30 минут на ручной просмотр 20–50 выходов LLM при каждом значительном изменении. Назначьте одного доменного эксперта, понимающего ваших пользователей, в качестве ответственного за качество («доброжелательный диктатор»).
Используйте ноутбук для просмотра трейсов и анализа данных или создайте собственный кастомный интерфейс аннотирования с помощью ИИ-ассистента для кодинга, такого как Claude или Codex. В любом случае вы сможете писать произвольный код, визуализировать данные и быстро итерировать. В видео ниже показан простой интерфейс аннотирования, построенный внутри ноутбука.
В: Какую долю бюджета разработки стоит выделять на оценку?
Важно понимать, что оценка — это часть процесса разработки, а не отдельная статья расходов, подобно тому как отладка является частью разработки ПО.
Вы всегда должны проводить анализ ошибок. Когда вы обнаруживаете проблемы через анализ ошибок, многие из них окажутся простыми багами, которые вы исправите сразу. Эти исправления не требуют отдельной инфраструктуры оценки — они просто часть разработки.
Решение о создании автоматических оценщиков сводится к анализу затрат и выгод. Если ошибку можно поймать простым утверждением или регулярным выражением, затраты минимальны и, скорее всего, оправданы. Но если нужно калибровать оценщик LLM-as-judge, подумайте, стоит ли данный тип сбоя таких инвестиций.
В проектах, над которыми мы работали, мы тратили 60–80% времени разработки на анализ ошибок и оценку. Ожидайте, что большая часть усилий уйдёт на понимание сбоев (т.е. изучение данных), а не на построение автоматических проверок.
Остерегайтесь оптимизации ради высоких показателей прохождения eval'ов. Если вы проходите 100% eval'ов, скорее всего, вы недостаточно нагружаете свою систему. Показатель прохождения в 70% может свидетельствовать о более содержательной оценке, реально стресс-тестирующей ваше приложение. Сосредоточьтесь на eval'ах, помогающих ловить реальные проблемы, а не на тех, которые улучшают метрики.
В: Будут ли сегодняшние методы оценки актуальны через 5–10 лет, учитывая скорость изменений в ИИ?
Да. Даже при идеальных моделях вам всё равно нужно убедиться, что они решают правильную задачу. Потребность в систематическом анализе ошибок, доменно-специфическом тестировании и мониторинге останется важной.
Сегодняшние трюки промпт-инжиниринга могут устареть, но вам по-прежнему нужно будет понимать режимы сбоев. Кроме того, LLM не может читать ваши мысли, и исследования показывают, что людям необходимо наблюдать за поведением LLM, чтобы правильно формализовать свои требования.
Для более глубокого понимания этой дискуссии смотрите две точки зрения: «Модель — это продукт» и «Модель — это НЕ продукт».
«Модель — это продукт»:
«Модель — это НЕ продукт»:
В: Как убедить команду инвестировать в оценку?
Не пытайтесь продать команде идею «eval'ов». Вместо этого покажите им то, что вы находите, когда смотрите на данные.
Начните с проведения анализа ошибок самостоятельно. Просмотрите 50–100 реальных пользовательских диалогов и найдите самые частые способы, которыми продукт даёт сбой. Используйте эти находки, чтобы рассказать историю на основе данных.
Представьте команде:
Список главных типов сбоев, которые вы обнаружили. Метрики, показывающие, как часто происходят критичные ошибки. Неожиданные способы взаимодействия пользователей с продуктом. Отчёты о найденных и исправленных багах, оформленные как «предотвращённые продакшен-инциденты».
Этот подход выстраивает доверие. Не просто показывайте дашборды и метрики — расскажите историю того, что вы находите в данных. Излагая свои находки, вы обучаете команду тому, что узнаёте сами, обеспечивая немедленную ценность. Когда вы исправляете проблему, покажите, как снизился показатель ошибок для этого конкретного случая. Вскоре ваша команда увидит прогресс и спросит, как вы этого добились. Пусть результаты, а не методы, ведут разговор.
Это похоже на классические проекты машинного обучения, где результаты спекулятивны, а прогресс ограничен итерациями над экспериментами. В этой ситуации важно делиться выводами из каждого эксперимента, чтобы показать прогресс и поощрить инвестиции.
Анализ ошибок и сбор данных
В: Почему «анализ ошибок» так важен в LLM-оценке и как он выполняется?
Анализ ошибок — самая важная деятельность в оценке. Анализ ошибок помогает решить, какие eval'ы писать в первую очередь. Он позволяет выявить режимы сбоев, уникальные для вашего приложения и данных. Процесс включает:
1. Создание датасета
Сбор репрезентативных трейсов взаимодействия пользователей с LLM. Если у вас нет данных, можно сгенерировать синтетические данные для начала.
2. Открытое кодирование
Аннотатор(ы) (в идеале — доброжелательный диктатор) просматривают трейсы и пишут свободные заметки о них, отмечая любые проблемы. Этот процесс подобен «ведению дневника» и заимствован из методологий качественных исследований. В начале рекомендуется фокусироваться на первом сбое, обнаруженном в трейсе, поскольку ошибки выше по цепочке могут вызывать последующие проблемы, хотя можно также отмечать все независимые сбои, если это реализуемо. Этот шаг должен выполнять доменный эксперт.
3. Осевое кодирование
Категоризируйте свободные заметки в «таксономию сбоев». Иными словами, сгруппируйте похожие сбои в отдельные категории. Это самый важный шаг. В конце подсчитайте количество сбоев в каждой категории. Для этого шага можно использовать LLM.
4. Итеративное уточнение
Продолжайте итерации на новых трейсах, пока не достигнете теоретического насыщения — момента, когда новые трейсы перестают выявлять новые режимы сбоев или информацию. Как правило, стоит просмотреть не менее 100 трейсов. Мой грубый эвристический критерий: если ~20 трейсов не выявляют новую категорию, можно остановиться (но начните с просмотра минимум 100). Помните: цель — приоритизировать сбои, которые действительно происходят чаще всего, а не ловить каждый возможный (eval'ы не бесплатны, поэтому нужен прагматизм).
К этому процессу следует возвращаться регулярно. Существуют продвинутые способы более эффективной выборки данных: кластеризация, сортировка по пользовательскому фидбэку, сортировка по паттернам с высокой вероятностью сбоя. Со временем у вас разовьётся «чутьё» на то, где искать ошибки в данных.
Не пропускайте анализ ошибок. Он гарантирует, что разрабатываемые вами метрики оценки основаны на реальном поведении приложения, а не на контрпродуктивных обобщённых метриках (к которым подталкивает большинство платформ). Примеры полезности анализа ошибок — в этом видео или в этой статье.
Вот визуализация процесса анализа ошибок от одного из наших студентов, Pawel Huryn, включая то, как он вписывается в общий процесс оценки:
В: Как находить проблемные трейсы для ревью помимо пользовательского фидбэка?
Хотя пользовательский фидбэк — хороший способ сфокусироваться на проблемных трейсах, полезны и другие методы. Вот три взаимодополняющих подхода:
Начните с случайной выборки
Самый простой подход — просмотр случайной выборки трейсов. Если вы находите мало проблем, переходите к стресс-тестированию: создавайте запросы, целенаправленно проверяющие ограничения ваших промптов, чтобы увидеть, следует ли ИИ вашим правилам.
Используйте eval'ы для первичного скрининга
Используйте существующие eval'ы для поиска проблемных трейсов и потенциальных проблем. Обнаружив их, можно переходить к стандартному процессу оценки, начиная с анализа ошибок.
Применяйте стратегии эффективной выборки
Для более продвинутого обнаружения трейсов используйте обнаружение выбросов, сортировку по метрикам и стратифицированную выборку, чтобы находить интересные трейсы. Обобщённые метрики могут служить исследовательскими сигналами для выявления трейсов, достойных ревью, даже если они не измеряют качество напрямую.
В: Как часто нужно перезапускать анализ ошибок на продакшен-системе?
Перезапускайте анализ ошибок при значительных изменениях: новые функции, обновления промптов, смена модели или крупные исправления багов. Полезный эвристический критерий — задайтесь целью просматривать минимум 100+ свежих трейсов за каждый цикл ревью. Типичные циклы ревью, которые мы наблюдали, составляют от 2 до 4 недель. Смотрите этот FAQ о том, как эффективно делать выборку трейсов.
Между крупными анализами просматривайте 10–20 трейсов еженедельно, фокусируясь на выбросах: необычно длинные диалоги, сессии с множественными повторами или трейсы, отмеченные автоматическим мониторингом. Корректируйте частоту в зависимости от стабильности системы и роста использования. Новым системам нужен еженедельный анализ, пока паттерны сбоев не стабилизируются. Зрелым системам может быть достаточно ежемесячного анализа, если только паттерны использования не меняются. Всегда проводите анализ после инцидентов, всплесков жалоб пользователей или дрейфа метрик. Масштабирование использования порождает новые краевые случаи.
В: Каков лучший подход к генерации синтетических данных?
Распространённая ошибка — просить LLM "дай мне тестовые запросы" без структуры, получая обобщённые, повторяющиеся результаты. Структурированный подход с использованием измерений даёт гораздо более качественные синтетические данные для тестирования LLM-приложений.
Начните с определения измерений: категорий, описывающих разные аспекты пользовательских запросов. Каждое измерение отражает один тип вариации в поведении пользователей. Например:
Для приложения рецептов измерениями могут быть Диетические ограничения (веганство, безглютеновое, нет), Тип кухни (итальянская, азиатская, домашняя) и Сложность запроса (простой запрос, многошаговый, краевой случай). Для бота поддержки измерениями могут быть Тип проблемы (биллинг, техническая, общая), Настроение клиента (раздражённый, нейтральный, довольный) и Предшествующий контекст (новая проблема, продолжение, решённая).
Начните с гипотез о сбоях. Если у вас нет интуиции о режимах сбоев, активно попользуйтесь своим приложением или привлеките друзей. Затем выберите измерения, нацеленные на вероятные сбои.
Сначала создайте кортежи вручную: напишите 20 кортежей от руки — конкретные комбинации, выбирающие по одному значению из каждого измерения. Пример: (Веганское, Итальянская, Многошаговый). Эта ручная работа помогает понять пространство задачи.
Масштабируйте двухэтапной генерацией:
Сгенерируйте структурированные кортежи: попросите LLM создать больше комбинаций, например (Безглютеновое, Азиатская, Простой) Преобразуйте кортежи в запросы: в отдельном промпте превратите каждый кортеж в естественный язык
Такое разделение позволяет избежать повторяющихся формулировок. Кортеж (Веганское, Итальянская, Многошаговый) превращается в: "Мне нужен рецепт лазаньи без молочных продуктов, который можно подготовить за день до подачи."
Подходы к генерации
Кортежи можно генерировать двумя способами:
Декартово произведение с фильтрацией: сгенерируйте все комбинации измерений, затем отфильтруйте с помощью LLM. Гарантирует покрытие, включая краевые случаи. Используйте, когда большинство комбинаций валидны.
Прямая генерация LLM: попросите LLM генерировать кортежи напрямую. Более реалистично, но склонно к обобщённым результатам и пропуску редких сценариев. Используйте, когда многие комбинации измерений невалидны.
Сначала исправьте очевидные проблемы: не генерируйте синтетические данные для проблем, которые можно исправить немедленно. Если ваш промпт не упоминает диетические ограничения, исправьте промпт, а не генерируйте специализированные тестовые запросы.
После итерации над кортежами и промптами прогоните эти синтетические запросы через реальную систему, чтобы собрать полные трейсы. Отберите 100 трейсов для анализа ошибок. Такое количество достаточно для ручного просмотра и выявления паттернов сбоев, не перегружая вас.
В: Есть ли сценарии, в которых синтетические данные ненадёжны?
Да: синтетические данные могут вводить в заблуждение или маскировать проблемы. Рекомендации по генерации синтетических данных, когда это уместно, — в разделе «Каков лучший подход к генерации синтетических данных?»
Распространённые сценарии, в которых синтетические данные не работают:
Сложный доменно-специфический контент: LLM часто упускают структуру, нюансы или особенности специализированных документов (например, юридических документов, медицинских записей, технических форм). Без реальных примеров критические краевые случаи остаются незамеченными. Малоресурсные языки или диалекты: для малоресурсных языков или диалектов образцы, сгенерированные LLM, часто нереалистичны. Оценки на их основе не будут отражать реальную производительность. Когда валидация невозможна: если вы не можете проверить реалистичность синтетических образцов (из-за сложности домена или отсутствия эталона), реальные данные важны для точной оценки. Высокорисковые домены: в высокорисковых доменах (медицина, право, экстренное реагирование) синтетические данные часто лишены тонкостей и краевых случаев. Ошибки здесь имеют серьёзные последствия, а ручная валидация затруднена. Недопредставленные группы пользователей: для недопредставленных групп пользователей LLM могут искажать контекст, ценности или трудности. Синтетические данные могут усиливать смещения в обучающих данных LLM.
В: Как подходить к оценке, когда система обрабатывает разнородные запросы пользователей?
Сложные приложения часто поддерживают совершенно разные паттерны запросов — от «Какова политика возврата?» до «Сравните ценовые тренды по регионам для продуктов, соответствующих этим критериям». Каждый тип запроса задействует разные возможности системы, что приводит к путанице при проектировании критериев оценки.
Анализ ошибок — это всё, что вам нужно. Ваша стратегия оценки должна вырастать из наблюдаемых паттернов сбоев (т.е. анализа ошибок), а не из предопределённых классификаций запросов. Вместо того чтобы создавать гигантскую матрицу оценки, покрывающую каждый тип запроса, позвольте реальному поведению системы определять, куда инвестировать усилия по оценке.
В ходе анализа ошибок вы, вероятно, обнаружите, что определённые категории запросов имеют общие паттерны сбоев. Например, все запросы, требующие временно́го рассуждения, могут давать сбой независимо от того, это простые поиски или сложные агрегации. Аналогично, запросы, требующие объединения информации из нескольких источников, могут сбоить одинаковым образом. Эти паттерны, обнаруженные через анализ ошибок, должны определять приоритеты оценки. Возможно, категория запроса — хороший способ группировки сбоев, но вы не узнаете этого, пока не проанализируете данные.
Чтобы увидеть пример базового анализа ошибок в действии, посмотрите это видео.
В: Как эффективно делать выборку продакшен-трейсов для ревью?
Просматривать трейсы случайно может быть трудоёмко, особенно когда большинство из них не содержат ошибок. Эти стратегии выборки помогут находить трейсы, с большей вероятностью выявляющие проблемы:
Обнаружение выбросов: отсортируйте по любой метрике (длина ответа, задержка, вызовы инструментов) и просмотрите крайние значения. Сигналы пользовательского фидбэка: приоритизируйте трейсы с негативным фидбэком, тикетами поддержки или эскалациями. Сортировка по метрикам: обобщённые метрики могут служить исследовательскими сигналами для поиска интересных трейсов. Просматривайте как высокие, так и низкие оценки и рассматривайте их как подсказки для исследования. На основе полученных знаний вы сможете построить кастомные оценщики для обнаруженных режимов сбоев. Стратифицированная выборка: сгруппируйте трейсы по ключевым измерениям (тип пользователя, функция, категория запроса) и делайте выборку из каждой группы. Кластеризация эмбеддингов: сгенерируйте эмбеддинги запросов и кластеризуйте их для выявления естественных группировок. Делайте пропорциональную выборку из каждого кластера, но с избыточной выборкой из малых кластеров для краевых случаев. Единственно правильного способа кластеризации нет — это исследовательская техника для выявления паттернов, которые вы можете упустить при ручном просмотре.
По мере совершенствования подхода к выборке вы сможете интегрировать эти тактики в дизайн ваших инструментов аннотирования.
👉 Хотите узнать больше об AI Evals? Ознакомьтесь с нашим курсом AI Evals. Это живая когорта с практическими упражнениями и часами вопросов-ответов. Вот промокод на скидку 25% для читателей. 👈
Проектирование и методология оценки
В: Почему вы рекомендуете бинарные (пройдено/не пройдено) оценки вместо рейтингов 1–5 (шкалы Ликерта)?
Инженеры часто полагают, что шкалы Ликерта (рейтинги 1–5) дают больше информации, чем бинарные оценки, позволяя отслеживать постепенные улучшения. Однако на практике эта дополнительная сложность чаще создаёт проблемы, чем решает их.
Бинарные оценки заставляют мыслить чётче и обеспечивают более согласованную разметку. Шкалы Ликерта порождают значительные проблемы: разница между соседними баллами (например, 3 и 4) субъективна и непоследовательна у разных аннотаторов, для выявления статистических различий требуются бо́льшие выборки, а аннотаторы часто выбирают средние значения, чтобы избежать трудных решений.
Бинарный выбор заставляет людей принимать решение, а не прятать неопределённость в средних значениях. Бинарные решения также быстрее принимаются при анализе ошибок — вы не тратите время на споры, это 3 или 4.
Для отслеживания постепенных улучшений рассмотрите возможность измерения конкретных подкомпонентов через собственные бинарные проверки вместо использования шкалы. Например, вместо оценки фактической точности от 1 до 5 вы можете отслеживать «4 из 5 ожидаемых фактов присутствуют» как отдельные бинарные проверки. Это сохраняет возможность измерять прогресс при чётких, объективных критериях.
Начните с бинарных меток, чтобы понять, как выглядит «плохо». Числовые метки — продвинутый инструмент, и обычно они не нужны.
В: Стоит ли практиковать разработку через оценки (eval-driven development)?
Как правило, нет. Разработка через оценки (написание оценщиков до реализации функций) звучит привлекательно, но создаёт больше проблем, чем решает. В отличие от традиционного ПО, где режимы сбоев предсказуемы, у LLM бесконечная поверхность потенциальных сбоев. Вы не можете предвидеть, что сломается.
Лучший подход — начать с анализа ошибок. Пишите оценщики для обнаруженных ошибок, а не для воображаемых. Это позволяет не застревать на вопросе «что оценивать» и предотвращает напрасные усилия на метрики, не влияющие на реальное качество системы.
Исключение: разработка через оценки может работать для конкретных ограничений, где вы точно знаете, как выглядит успех. Если вы добавляете правило «никогда не упоминать конкурентов», написать такой оценщик заранее может быть допустимо.
Самое важное — всегда проводите анализ затрат и выгод перед реализацией eval'а. Спросите себя, оправдывает ли данный режим сбоя инвестиции. Анализ ошибок показывает, какие сбои действительно важны для ваших пользователей.
В: Нужно ли строить автоматические оценщики для каждого обнаруженного режима сбоя?
Автоматические оценщики стоит фокусировать на сбоях, которые сохраняются после исправления промптов. Многие команды обнаруживают, что LLM не соответствует предпочтениям, которые они никогда явно не указывали — например, желание коротких ответов, определённого форматирования или пошагового рассуждения. Сначала устраните эти очевидные пробелы, а затем стройте сложную инфраструктуру оценки.
Учитывайте иерархию стоимости различных типов оценщиков. Простые ассёрты и проверки по эталону (сравнение с известными правильными ответами) дёшевы в создании и сопровождении. Оценщики LLM-as-Judge требуют 100+ размеченных примеров, еженедельного обслуживания и координации между разработчиками, продакт-менеджерами и доменными экспертами. Эта разница в стоимости должна формировать вашу стратегию оценки.
Стройте дорогие оценщики только для проблем, над которыми вы будете итерировать многократно. Поскольку LLM-as-Judge связан со значительными накладными расходами, оставьте его для устойчивых ошибок обобщения, а не для проблем, исправимых тривиально. Начните с дешёвых кодовых проверок, где возможно: регулярные выражения, структурная валидация или тесты исполнения. Сложную оценку оставьте для субъективных качеств, которые не описываются простыми правилами.
В: Стоит ли использовать «готовые» метрики оценки?
Нет. Обобщённые оценки тратят время и создают ложную уверенность. (Если только вы не используете их для исследования.)
Один из преподавателей отметил:
«Всё, что вы получаете от использования этих готовых eval'ов — вы не понимаете, что они на самом деле делают, и в лучшем случае они тратят ваше время, а в худшем — создают иллюзию уверенности, которая ничем не обоснована.»1
Обобщённые метрики оценки повсюду. Библиотеки eval'ов содержат такие оценки, как полезность, связность, качество и т.д., обещая лёгкую оценку. Эти метрики измеряют абстрактные качества, которые могут не иметь значения для вашего сценария. Хорошие оценки по ним не означают, что ваша система работает.
Вместо этого проводите анализ ошибок, чтобы понять сбои. Определите бинарные режимы сбоев на основе реальных проблем. Создайте кастомные оценщики для этих сбоев и провалидируйте их на основе человеческих суждений. По сути — весь процесс оценки.
Опытные практики всё же могут использовать эти метрики, но не так, как вы ожидаете. Как говорил Пикассо: «Изучай правила как профессионал, чтобы нарушать их как художник». Когда вы поймёте, почему обобщённые метрики не работают как оценки, вы сможете использовать их как исследовательские инструменты для поиска интересных трейсов (объясняется в следующем FAQ).
В: Полезны ли метрики сходства (BERTScore, ROUGE и др.) для оценки выходов LLM?
Обобщённые метрики вроде BERTScore, ROUGE, косинусного сходства и т.д. бесполезны для оценки выходов LLM в большинстве ИИ-приложений. Вместо них мы рекомендуем использовать анализ ошибок для выявления метрик, специфичных для поведения вашего приложения. Мы рекомендуем проектировать бинарные pass/fail eval'ы (с использованием LLM-as-judge) или кодовые ассёрты.
Для примера рассмотрим ассистента для CRM в сфере недвижимости. Предлагать показы, которые недоступны (можно проверить ассёртом), или путать профили клиентов (можно проверить через LLM-as-judge) — проблематично. Обобщённые метрики вроде сходства или объёма текста этого не поймают. Актуальная цитата из курса:
«Злоупотребление обобщёнными метриками носит эндемический характер. Многие поставщики eval'ов продвигают готовые метрики, втягивая инженеров в лишнюю работу.»
Метрики сходства не всегда бесполезны. Они полезны в задачах поиска и рекомендаций (и потому могут пригодиться для оптимизации и отладки извлечения в RAG). Например, косинусное сходство между эмбеддингами может измерять семантическую близость в системах поиска, а среднее попарное сходство — оценивать разнообразие выходов (где меньшее сходство означает большее разнообразие).
В: Можно ли использовать одну и ту же модель для основной задачи и для оценки?
Для выбора LLM-as-Judge обычно использование той же модели допустимо, поскольку судья выполняет другую задачу, чем ваш основной LLM-пайплайн. Хотя исследования показали, что модели могут проявлять предвзятость при оценке собственных выходов, в конечном счёте важно, насколько хорошо ваш судья совпадает с человеческими оценками. Судьи, которых мы рекомендуем строить, выполняют узкие задачи бинарной классификации. Мы обнаружили, что итеративного согласования с человеческими метками обычно можно достичь для такой ограниченной задачи.
Сосредоточьтесь на достижении высокого True Positive Rate (TPR) и True Negative Rate (TNR) вашего судьи на отложенном размеченном тестовом наборе. Если вы не можете добиться хорошего согласования с человеческими оценками, попробуйте другую модель. Однако подключение нового поставщика моделей может потребовать значительных усилий в некоторых организациях, поэтому мы не рекомендуем менять модель по умолчанию, если нет конкретной проблемы с согласованием.
При выборе моделей-судей начинайте с наиболее мощных доступных моделей, чтобы обеспечить надёжное согласование с человеческими суждениями. Оптимизировать стоимость можно позже, когда вы определите надёжные критерии оценки.
В: Как оценить способность модели выражать неуверенность или «знать, чего она не знает»?
Многие приложения требуют модели, способной отказать в ответе, когда ей не хватает информации. Чтобы оценить, насколько правильно откалибровано поведение отказа, нужно проверить, что модель отказывает в нужные моменты, не отказываясь при этом отвечать на вопросы, на которые должна уметь ответить.
Для эффективной проверки нужно составить набор для оценки, содержащий следующие компоненты:
Вопросы с ответом: сценарии, в которых правильный, проверяемый ответ присутствует в предоставленном модели контексте или общих знаниях. Вопросы без ответа: сценарии, спроектированные для того, чтобы спровоцировать модель на галлюцинации. Это вопросы с ложными предпосылками, запросы об информации, явно отсутствующей в контексте, или темы далеко за пределами базы знаний модели.
Хотя точная пропорция не критична, сбалансированный набор с примерно равным количеством вопросов с ответом и без ответа — хорошая отправная точка. Разнообразие и сложность вопросов важнее точного соотношения.
Сама оценка представляет собой бинарную проверку (пройдено/не пройдено) суждения модели. «Пройдено» требует выполнения двух условий: модель должна отвечать на вопросы с ответом и отказываться отвечать на вопросы без ответа. Провал определяется как предоставление выдуманного ответа на вопрос без ответа, что свидетельствует о плохой калибровке.
В научной литературе эта способность известна как «Abstention Ability» (способность воздерживаться). Для улучшения этого поведения стоит поискать этот термин на Arxiv, чтобы ознакомиться с последними методиками.
👉 Хотите узнать больше об AI Evals? Ознакомьтесь с нашим курсом AI Evals. Это живая когорта с практическими упражнениями и часами вопросов-ответов. Вот промокод на скидку 25% для читателей. 👈
Человеческая аннотация и процесс
В: Сколько людей должны аннотировать выходы моей LLM?
Для большинства малых и средних компаний наиболее эффективен подход с назначением единственного доменного эксперта в роли «доброжелательного диктатора». Этот человек — будь то психолог для чатбота по ментальному здоровью, юрист для анализа юридических документов или директор по поддержке клиентов для автоматизации саппорта — становится решающим голосом по стандартам качества.
Единственный эксперт устраняет конфликты аннотации и предотвращает паралич от «слишком многих поваров на кухне». Доброжелательный диктатор может принимать к сведению обратную связь от других, но он управляет процессом. Если вам кажется, что для оценки одного взаимодействия нужно пять экспертов — это сигнал, что охват вашего продукта может быть слишком широким.
Тем не менее крупным организациям или тем, кто работает в нескольких доменах (например, многонациональная компания с разным культурным контекстом), могут понадобиться несколько аннотаторов. Если вы используете нескольких, вам придётся измерять их согласованность с помощью метрик вроде каппы Коэна, учитывающей согласие помимо случайного. Однако полагайтесь на здравый смысл. Даже в крупных компаниях одного эксперта часто достаточно.
Начинайте с доброжелательного диктатора, когда это возможно. Добавляйте сложность только тогда, когда ваш домен этого требует.
В: Должны ли продакт-менеджеры и инженеры сотрудничать при анализе ошибок? Как?
На начальном этапе сотрудничайте для формирования общего контекста. Инженеры ловят технические проблемы — ошибки извлечения данных и инструментов. Продакт-менеджеры выявляют продуктовые недостатки — несбывшиеся ожидания пользователей, запутанные ответы или отсутствие функций, которые ожидают пользователи.
Со временем стоит опираться на доброжелательного диктатора для анализа ошибок: доменного эксперта или продакт-менеджера, понимающего потребности пользователей. Дайте доменным экспертам возможность оценивать фактические результаты, а не техническую реализацию. Спрашивайте «Была ли создана запись?», а не «Успешен ли вызов инструмента?» Лучший способ дать полномочия доменному эксперту — предоставить кастомные инструменты аннотирования, отображающие результаты системы рядом с трейсами. Показывайте подтверждение, сгенерированное письмо или обновление базы данных, подтверждающее выполнение цели. Размещайте весь контекст на одном экране, чтобы нетехнические ревьюеры фокусировались на результатах.
В: Стоит ли аутсорсить аннотацию и разметку третьей стороне?
Аутсорсинг анализа ошибок — обычно большая ошибка (с некоторыми исключениями). Суть оценки — формирование продуктовой интуиции, которая возникает только при систематическом анализе сбоев вашей системы. Следует крайне скептически относиться к делегированию этого процесса.
Опасности аутсорсинга
Когда вы аутсорсите аннотацию, вы часто разрываете обратную связь между наблюдением сбоя и пониманием того, как улучшить продукт. Проблемы аутсорсинга:
Поверхностная разметка: даже чётко определённые метрики требуют нюансированного суждения, которого лишены внешние команды. Критическая ошибка в анализе ошибок — исключение доменных экспертов из процесса разметки. Аутсорсинг этой задачи людям без доменной экспертизы, таким как обычные разработчики или ИТ-сотрудники, часто приводит к поверхностной или некорректной разметке. Потеря негласного знания: главный доменный эксперт обладает неявными знаниями и пониманием пользователей, которые невозможно полностью передать в рубрике. Привлечение таких экспертов помогает раскрыть их предпочтения и ожидания, которые они не всегда могут сформулировать заранее. Конфликты аннотации и рассогласование: без общего контекста внешние аннотаторы могут создавать больше разногласий, чем разрешать. Достижение согласованности — проблема даже для внутренних команд, а значит, вы потратите ещё больше времени на этот процесс.
Рекомендованный подход: выстраивайте внутренние компетенции
Вместо аутсорсинга сосредоточьтесь на построении эффективного внутреннего процесса оценки.
1. Назначьте «доброжелательного диктатора». Для большинства команд наиболее эффективная стратегия — назначить единственного внутреннего доменного эксперта финальным лицом, принимающим решения по качеству. Этот человек задаёт стандарт, обеспечивает последовательность и развивает чувство ответственности.
2. Используйте совместный рабочий процесс при нескольких аннотаторах. Если несколько аннотаторов необходимы, следуйте структурированному процессу для обеспечения согласованности: * Составьте первоначальную рубрику с чёткими определениями «Пройдено/Не пройдено» и примерами. * Попросите каждого аннотатора независимо разметить общий набор трейсов, чтобы выявить различия в интерпретации. * Измерьте межаннотаторское согласие (IAA) с помощью метрики, скорректированной на случайность, например каппы Коэна. * Проведите сессии согласования для обсуждения разногласий и доработки рубрики. * Итерируйте этот процесс, пока согласие не станет стабильно высоким.
Как справиться с ограничениями ресурсов
Формирование внутренних компетенций не означает, что вам нужно размечать каждый трейс. Используйте эти стратегии для управления нагрузкой:
Умная выборка: тщательно просматривайте небольшую репрезентативную выборку трейсов. Эффективнее проанализировать 100 разнообразных трейсов для выявления паттернов, чем поверхностно разметить тысячи. Протокол «думай вслух»: чтобы максимально использовать ограниченное время эксперта, применяйте эту методику из юзабилити-тестирования. Попросите эксперта проговаривать ход мыслей при просмотре нескольких трейсов. Этот метод может выявить глубокие инсайты за одну часовую сессию. Создавайте лёгкие кастомные инструменты: создайте кастомные инструменты аннотирования, чтобы упростить процесс ревью и повысить пропускную способность.
Исключения для внешней помощи
Хотя аутсорсинг основного процесса анализа ошибок не рекомендуется, есть сценарии, в которых внешняя помощь уместна:
Чисто механические задачи: для высокообъективных, однозначных задач — таких как определение номера телефона или валидация email-адреса — внешних аннотаторов можно привлечь после того, как рубрика определена в ходе строгого внутреннего процесса. Задачи без продуктового контекста: чётко определённые задачи, не требующие понимания специфических требований вашего продукта, можно аутсорсить. Перевод — хороший пример: он требует лингвистической экспертизы, но не глубокого знания продукта. Привлечение внешних экспертов: найм внешних предметных экспертов для роли ваших внутренних доменных экспертов — это не аутсорсинг, а привлечение необходимой компетенции в ваш процесс оценки. Например, AnkiHub нанял студентов-медиков 4-го курса для оценки своих RAG-систем по медицинскому контенту вместо привлечения неспециализированных аннотаторов.
В: Какие части eval'ов можно автоматизировать с помощью LLM?
LLM могут ускорить отдельные части рабочего процесса оценки, но не заменят человеческое суждение там, где необходима ваша экспертиза. Например, если позволить LLM выполнять весь анализ ошибок (т.е. просматривать и аннотировать трейсы), вы можете пропустить важные для вашего продукта случаи сбоев. Допустим, пользователи постоянно упоминают «лаг» в обратной связи, но LLM относит их к обобщённым «проблемам производительности» вместо создания категории «задержка». Вы пропустите повторяющуюся жалобу на медленное время отклика и не приоритизируете исправление.
Тем не менее LLM — ценные инструменты для ускорения определённых частей рабочего процесса оценки, когда они используются под контролем.
Вот области, в которых LLM могут помочь:
Первичное осевое кодирование: после того как вы самостоятельно провели открытое кодирование 30–50 трейсов, используйте LLM для организации ваших сырых заметок о сбоях в предложенные группировки. Это помогает быстро заметить паттерны, но всегда просматривайте и уточняйте кластеры самостоятельно. Примечание: если вы не знакомы с осевым и открытым кодированием, смотрите этот FAQ. Сопоставление аннотаций с режимами сбоев: когда вы определили категории сбоев, можно попросить LLM предложить, какие категории применимы к каждому новому трейсу (например, «Учитывая эту аннотацию: [open_annotation] и эти режимы сбоев: [list_of_failure_modes], какие подходят?»). Предложение улучшений промптов: когда вы замечаете повторяющиеся проблемы, попросите LLM предложить конкретные изменения в промптах. Проверяйте эти предложения перед применением. Анализ данных аннотации: используйте LLM или ноутбуки с ИИ для поиска паттернов в ваших метках — например, «сообщения о лагах возрастают в 3 раза в часы пик» или «медленное время отклика чаще всего отмечается пользователями на мобильных устройствах».
Однако эти задачи не следует делегировать LLM:
Первоначальное открытое кодирование: всегда читайте сырые трейсы самостоятельно в начале. Именно так вы обнаруживаете новые типы сбоев, понимаете болевые точки пользователей и формируете интуицию о данных. Никогда не пропускайте этот шаг и не делегируйте его. Валидация таксономий сбоев: группировки, предложенные LLM, нуждаются в вашей проверке. Например, LLM может объединить «приложение падает после входа» и «вход занимает слишком много времени» в одну категорию «проблемы с входом», хотя одна — проблема стабильности, а другая — производительности. Без вашего вмешательства вы пропустите, что для них нужны разные решения. Разметка эталонных данных: для любых данных, используемых для тестирования/валидации оценщиков LLM-as-Judge, вручную проверяйте каждую метку. LLM могут ошибаться, что приводит к ненадёжным бенчмаркам. Анализ корневых причин: LLM могут указать на очевидные проблемы, но только человеческий ревью поймает паттерны — вроде ошибок, возникающих только в определённых сценариях или краевых случаях, например баги, проявляющиеся только при вставке данных из Excel.
В итоге: начните с ручного изучения данных, чтобы понять, что действительно идёт не так. Используйте LLM для масштабирования того, что вы узнали, а не для того, чтобы избежать работы с данными.
В: Стоит ли перестать писать промпты вручную в пользу автоматизированных инструментов?
Автоматизация промпт-инжиниринга может быть соблазнительной, но стоит скептически относиться к инструментам, обещающим оптимизировать промпты за вас, особенно на ранних стадиях разработки. Когда вы пишете промпт, вы вынуждены уточнять свои предположения и формализовать требования. Хорошее письмо — это хорошее мышление 2. Если вы делегируете эту задачу автоматическому инструменту слишком рано, вы рискуете никогда полностью не понять собственные требования или режимы сбоев модели.
Дело в том, что автоматическая оптимизация промптов обычно выполняет подъём по градиенту предопределённой метрики. Она может улучшить промпт для известных сбоев, но не способна обнаружить новые. Обнаружение новых ошибок требует анализа ошибок. Кроме того, исследования показывают, что критерии оценки смещаются после просмотра выходов модели — явление, известное как «дрейф критериев» 3. Это означает, что оценка — итеративный, управляемый человеком процесс осмысления, а не статическая цель, которую можно задать один раз и передать оптимизатору.
Прагматичный подход — использовать LLM для улучшения промптов на основе открытого кодирования (свободных заметок о трейсах). Таким образом вы сохраняете человека в контуре, который смотрит на данные и формализует свои требования. Когда у вас есть качественный набор eval'ов, оптимизация промптов может быть эффективна для финальной доводки.
👉 Хотите узнать больше об AI Evals? Ознакомьтесь с нашим курсом AI Evals. Это живая когорта с практическими упражнениями и часами вопросов-ответов. Вот промокод на скидку 25% для читателей. 👈
Инструменты и инфраструктура
В: Строить кастомный инструмент аннотирования или использовать готовое решение?
Стройте кастомный инструмент аннотирования. Это самая результативная инвестиция, которую вы можете сделать для рабочего процесса оценки ИИ. С помощью инструментов разработки с ИИ, таких как Cursor или Lovable, вы можете создать подогнанный интерфейс за часы. Я часто наблюдаю, что команды с кастомными инструментами аннотирования итерируют примерно в 10 раз быстрее.
Кастомные инструменты хороши тем, что:
Они показывают весь ваш контекст из нескольких систем в одном месте Они могут отрисовывать данные способом, специфичным для продукта (изображения, виджеты, markdown, кнопки и т.д.) Они спроектированы под ваш конкретный рабочий процесс (кастомные фильтры, сортировка, индикаторы прогресса и т.д.)
Готовые инструменты могут быть оправданы, когда нужно координировать десятки распределённых аннотаторов с корпоративными контролями доступа. Даже тогда многие команды считают, что накладные расходы на настройку и ограничения того не стоят.
Приложение Isaac для аннотирования карточек Anki демонстрирует мощь кастомных инструментов — обработка 400+ результатов на запрос с навигацией с клавиатуры и доменно-специфическими критериями оценки, которые было бы почти невозможно настроить в обобщённом инструменте.
В: Что делает интерфейс ревью выходов LLM хорошим?
Хорошие интерфейсы делают человеческое ревью быстрым, ясным и мотивирующим. Мы рекомендуем создать собственный инструмент аннотирования, адаптированный под ваш домен. Ниже перечислены возможные улучшения, которые хорошо зарекомендовали себя, но вам не нужны все сразу. Показанные скриншоты — иллюстративные примеры для пояснения концепций. На практике я редко реализую все эти функции в одном приложении. В конечном счёте это вопрос суждения, основанного на ваших конкретных потребностях и ограничениях.
1. Отображайте трейсы осмысленно, а не обобщённо:
Представляйте трейс интуитивно понятным для домена способом. Если вы оцениваете сгенерированные письма — отрисовывайте их как письма. Если результат — код, используйте подсветку синтаксиса. Позвольте ревьюеру видеть полный трейс (вход пользователя, вызовы инструментов и рассуждения LLM), но держите менее важные детали в сворачиваемых секциях. Вот пример кастомного инструмента аннотирования для ревью писем ассистента по недвижимости:
2. Показывайте прогресс и поддерживайте навигацию с клавиатуры:
Поддерживайте ревьюеров в состоянии потока, минимизируя трение и мотивируя завершение. Добавьте индикаторы прогресса (например, «Трейс 45 из 100»), чтобы сессия ревью была ограниченной и поощряла завершение. Включите горячие клавиши для навигации между трейсами (например, N для следующего), применения меток и быстрого сохранения заметок. Ниже — иллюстрация этих функций:
3. Навигация по трейсам через кластеризацию, фильтрацию и поиск:
Позвольте ревьюерам фильтровать трейсы по метаданным или искать по ключевым словам. Семантический поиск помогает находить концептуально похожие проблемы. Кластеризация похожих трейсов (например, группировка по персонам пользователей) позволяет ревьюерам замечать повторяющиеся проблемы и проверять гипотезы. Ниже — иллюстрация этих функций:
4. Приоритизируйте разметку трейсов, которые предположительно проблемны:
Выводите на первый план трейсы, отмеченные гардрейлами, провалами CI или автоматическими оценщиками. Предоставьте кнопки для действий — добавления в датасеты, создания багов или перезапуска тестов пайплайна. Отображайте релевантный контекст (версию пайплайна, оценки eval'ов, информацию о ревьюере) прямо в интерфейсе, чтобы минимизировать переключение контекста. Ниже — иллюстрация этих идей:
Общий принцип: делайте минимально
Делайте интерфейс аннотирования минимальным. Включайте эти идеи только в том случае, если их преимущества перевешивают дополнительную сложность и затраты на поддержку.
В: Какие пробелы в инструментах оценки мне придётся закрывать самостоятельно?
Большинство инструментов оценки хорошо справляются с базовыми задачами: логирование полных трейсов, отслеживание метрик, песочницы промптов и очереди аннотирования. Это минимальные требования. Вот четыре области, в которых вам, вероятно, придётся дополнить существующие инструменты.
Обращайте внимание на поставщиков, закрывающих эти пробелы: это верный сигнал того, что они понимают потребности практиков.
1. Анализ ошибок и обнаружение паттернов
После просмотра трейсов, в которых ваш ИИ даёт сбой, может ли ваш инструмент автоматически кластеризовать похожие проблемы? Например, если в нескольких трейсах ассистент использует неформальный стиль для состоятельных клиентов, нужно что-то, что распознает этот более широкий паттерн «несоответствие персоны и тона». Мы рекомендуем создавать функции, использующие ИИ для предложения группировок, переписывания наблюдений в более чёткие таксономии сбоев, поиска похожих случаев через семантический поиск и т.д.
2. ИИ-помощь на протяжении всего рабочего процесса
Наиболее эффективные рабочие процессы используют ИИ для ускорения каждого этапа оценки. При анализе ошибок вам нужен LLM, помогающий категоризировать свободные наблюдения в согласованные режимы сбоев. Например, вы можете аннотировать несколько трейсов заметками вроде «неправильный тон для инвестора», «слишком неформально для покупателя элитной недвижимости» и т.д. Ваш инструмент должен распознать их как один паттерн и предложить единую категорию «несоответствие персоны и тона».
Вам также понадобится ИИ-помощь в предложении исправлений. После обнаружения 20 случаев, когда ассистент пропускает политику содержания домашних животных в описаниях объектов, может ли ваш рабочий процесс проанализировать эти сбои и предложить конкретные изменения промпта? Может ли он составить уточнения к инструкциям по генерации SQL, когда замечает паттерны пропущенных предложений WHERE?
Хорошие рабочие процессы также помогают анализировать данные аннотаций и трейсов. Мне нравится использовать ноутбуки с ИИ в контуре, такие как Julius или Hex. Они помогают обнаруживать инсайты вроде «ошибки неоднозначности местоположения возрастают в 3 раза, когда пользователи упоминают названия районов» или «несоответствия тона возникают на 80% чаще при генерации писем, чем в других модальностях».
3. Кастомные оценщики вместо обобщённых метрик
Будьте готовы строить большинство оценщиков с нуля. Обобщённые метрики вроде «оценки галлюцинаций» или «рейтинга полезности» редко отражают то, что действительно важно для вашего приложения — например, предложение недоступного времени для показа или пропуск бюджетных ограничений в письмах. По нашему опыту, успешные команды тратят большую часть усилий на метрики, специфичные для приложения.
4. API, поддерживающие кастомные приложения аннотирования
Кастомные интерфейсы аннотирования лучше всего подходят большинству команд. Это требует платформ наблюдаемости с продуманными API. Мне часто приходится создавать собственные библиотеки и абстракции только для того, чтобы сделать массовый экспорт данных управляемым. Вам не должно приходиться пагинировать тысячи запросов или справляться с эндпоинтами, склонными к таймаутам, просто чтобы получить свои данные. Ищите платформы с настоящими возможностями массового экспорта и, что критически важно, API, позволяющими эффективно записывать аннотации обратно.
В: Какой ваш любимый поставщик инструментов оценки?
Инструменты оценки находятся в крайне конкурентном пространстве. Сравнивать их возможности бесполезно. Если бы я попытался провести такой анализ, он устарел бы через неделю! Поставщики, с которыми я чаще всего сталкиваюсь органически в работе: Langsmith, Arize и Braintrust.
Когда я помогаю клиентам с выбором поставщика, решение в значительной степени определяется тем, кто может предложить лучшую поддержку, а не только функциональностью. Это зависит от размера клиента, сценария использования и т.д. Да — именно человеческий фактор имеет значение, и, осмелюсь сказать, вайбы.
У меня нет любимого поставщика. По сути, их возможности очень похожи — и я часто создаю кастомные инструменты поверх них под свои нужды.
Вот серия видео с живым комментарием о сильных и слабых сторонах трёх упомянутых поставщиков.
В: Как версионировать и управлять промптами?
Существует неизбежное противоречие между хранением промптов рядом с кодом и средой, доступной для нетехнических заинтересованных сторон.
Мой предпочтительный подход — хранение промптов в Git. Это позволяет рассматривать их как программные артефакты, которые версионируются, проходят ревью и деплоятся атомарно вместе с кодом приложения. Хотя командная строка Git неудобна для нетехнических людей, веб-интерфейс GitHub и приложение GitHub Desktop делают его вполне доступным. Когда я работал в GitHub, я сотрудничал со многими нетехническими специалистами, включая юристов и бухгалтеров, которые эффективно использовали эти инструменты. Вот статья, предназначенная для нетехнических людей, чтобы начать.
Альтернативно, большинство поставщиков в экосистеме LLM-инструментов, таких как платформы наблюдаемости Arize, Braintrust и LangSmith, предлагают специализированные инструменты управления промптами. Они доступны для быстрых итераций, но рискуют создать дополнительные уровни абстракции.
Почему инструменты управления промптами часто не справляются: ИИ-продукты обычно включают множество движущихся частей: инструменты, RAG, агенты и т.д. Инструменты управления промптами по своей природе ограничены, поскольку не могут легко выполнять код вашего приложения. Даже когда они могут, часто возникает значительная косвенность, затрудняющая тестирование промптов с возможностями вашей системы.
Когда возможно, ноутбук — отличное решение для экспериментов с промптами. Если у вас есть точки входа на Python в вашу кодовую базу или она написана на Python, Jupyter-ноутбуки особенно мощны для этой цели. Вы можете экспериментировать с промптами и итерировать над реальными ИИ-агентами с полными возможностями инструментов и RAG. Это значительно упрощает понимание работы системы на практике. Кроме того, в ноутбуках можно создавать виджеты и небольшие пользовательские интерфейсы, получая лучшее из обоих миров для экспериментов и итераций. Чтобы увидеть, как это выглядит на практике, Teresa Torres даёт отличный практический разбор того, как она, будучи продакт-менеджером, использовала ноутбуки для полного цикла оценки и экспериментов:
Если ноутбуки невозможны для вашей кодовой базы, интегрированная среда промптов может быть эффективной для экспериментов. В любом случае я предпочитаю версионировать и управлять промптами в Git.
👉 Хотите узнать больше об AI Evals? Ознакомьтесь с нашим курсом AI Evals. Это живая когорта с практическими упражнениями и часами вопросов-ответов. Вот промокод на скидку 25% для читателей. 👈
Продакшен и деплой
В: Как оценки используются по-разному в CI/CD и при мониторинге продакшена?
Самое важное различие между оценкой в CI и в продакшене — данные, используемые для тестирования.
Тестовые датасеты для CI небольшие (во многих случаях 100+ примеров) и целенаправленно составлены. Примеры покрывают ключевые функции, регрессионные тесты для прошлых багов и известные краевые случаи. Поскольку CI-тесты запускаются часто, стоимость каждого теста нужно тщательно контролировать (поэтому вы тщательно курируете датасет). Отдавайте предпочтение ассёртам или другим детерминированным проверкам перед оценщиками LLM-as-judge.
Для оценки продакшен-трафика можно выбирать живые трейсы и запускать оценщики на них асинхронно. Поскольку для продакшен-данных обычно нет эталонных ответов, вам, возможно, придётся больше полагаться на более дорогие безэталонные оценщики вроде LLM-as-judge. Кроме того, отслеживайте доверительные интервалы для продакшен-метрик. Если нижняя граница пересекает пороговое значение — расследуйте.
Эти две системы дополняют друг друга: когда мониторинг продакшена выявляет новые паттерны сбоев через анализ ошибок и eval'ы, добавляйте репрезентативные примеры в CI-датасет. Это предотвращает регрессии по новым проблемам.
В: В чём разница между гардрейлами и оценщиками?
Гардрейлы — это встроенные проверки безопасности, находящиеся непосредственно на пути запроса/ответа. Они валидируют входы или выходы до того, как что-либо достигнет пользователя, поэтому обычно они:
Быстрые и детерминированные — обычно несколько миллисекунд бюджета на задержку. Простые и объяснимые — регулярные выражения, списки блокировки ключевых слов, валидаторы схем или типов, лёгкие классификаторы. Нацеленные на очевидные, высокоимпактные сбои — утечки персональных данных, нецензурная лексика, запрещённые инструкции, SQL-инъекции, невалидный JSON, некорректный синтаксис кода и т.д.
Если гардрейл срабатывает, система может отредактировать, отклонить или перегенерировать ответ. Поскольку эти проверки видны пользователю при срабатывании, ложные срабатывания считаются продакшен-багами; команды версионируют правила гардрейлов, логируют каждое срабатывание и контролируют частоту, чтобы они оставались консервативными.
С другой стороны, оценщики обычно работают после генерации ответа. Оценщики измеряют качества, которые не могут уловить простые правила: фактическую корректность, полноту и т.д. Их вердикты наполняют дашборды, регрессионные тесты и циклы улучшения модели, но не блокируют исходный ответ.
Оценщики обычно запускаются асинхронно или в пакетном режиме, чтобы позволить себе более тяжёлые вычисления, такие как LLM-as-a-Judge. Встроенное использование LLM-as-Judge возможно только когда позволяют бюджет на задержку и требования к надёжности. Медленные LLM-судьи могут быть допустимы в каскаде, работающем на меньшинстве пограничных случаев.
Применяйте гардрейлы для немедленной защиты от объективных сбоев, требующих вмешательства. Используйте оценщики для мониторинга и улучшения субъективных или нюансированных критериев. Вместе они создают многоуровневую защиту.
Предостережение: не используйте LLM-гардрейлы готовыми, вслепую. Всегда смотрите на промпт.
В: Можно ли использовать оценщики для автоматического исправления или корректировки выходов в продакшене?
Да, но только определённое подмножество. Это различие между оценщиком и гардрейлом, которое мы обсуждали ранее. Напомним:
Оценщики обычно работают асинхронно после генерации ответа. Они измеряют качество, но не влияют на непосредственный опыт пользователя. Гардрейлы работают синхронно на критическом пути запроса, до того как результат показан пользователю. Их задача — предотвратить высокоимпактные сбои в реальном времени.
Есть два важных критерия для решения о том, стоит ли использовать оценщик как гардрейл:
Задержка и стоимость: может ли оценщик работать достаточно быстро и дёшево на критическом пути запроса, не ухудшая пользовательский опыт? Компромиссы по ошибкам: каков баланс затрат и выгод между ложными срабатываниями (блокировка хороших ответов и раздражение пользователей) и пропуском ошибок (допуск плохих ответов к пользователю и причинение вреда)? В высокорисковых доменах, таких как медицинские консультации, пропуск ошибок может стоить дороже ложных срабатываний. В творческих приложениях ложные срабатывания, блокирующие легитимное творчество, могут быть вреднее, чем периодические проблемы с качеством.
Большинство гардрейлов спроектированы быстрыми (чтобы не ухудшать пользовательский опыт) и с очень низким уровнем ложных срабатываний (чтобы не блокировать валидные ответы). По этой причине вы почти никогда не использовали бы медленный или недетерминированный LLM-as-Judge как синхронный гардрейл. Однако эти компромиссы могут отличаться для вашего сценария.
В: Сколько времени стоит тратить на выбор модели?
Многие разработчики зацикливаются на выборе модели как основном способе улучшить LLM-приложения. Начните с анализа ошибок, чтобы понять режимы сбоев, прежде чем рассматривать смену модели. Как Hamel отметил на часе вопросов: «Я предлагаю не рассматривать смену модели как главный рычаг улучшения системы сразу, без доказательств. Указывает ли анализ ошибок на то, что проблема — в модели?»
Доменно-специфические приложения
В: RAG умер?
Вопрос: стоит ли избегать RAG для моего ИИ-приложения после статьи о том, что «RAG мёртв» для кодинговых агентов?
Многие разработчики не понимают, когда и как использовать RAG, после прочтения статей, утверждающих, что «RAG мёртв». Понимание того, что RAG означает на самом деле, в отличие от узких маркетинговых определений, поможет принимать лучшие архитектурные решения для ваших ИИ-приложений.
Вирусная статья, утверждающая, что RAG мёртв, конкретно выступает против использования наивного поиска по векторной базе данных для автономных кодинговых агентов, а не против RAG в целом. Это критически важное различие, которое многие разработчики упускают из-за вводящего в заблуждение маркетинга.
RAG — это просто Retrieval-Augmented Generation (генерация с дополненным извлечением) — использование поиска для предоставления релевантного контекста, улучшающего выход модели. Основной принцип остаётся ключевым: вашей LLM нужен правильный контекст для генерации точных ответов. Вопрос не в том, использовать ли извлечение, а в том, как извлекать эффективно.
Для кодинговых приложений наивный поиск по векторному сходству часто не работает, потому что связи в коде сложны и контекстуальны. Вместо полного отказа от извлечения современные кодинговые ассистенты вроде Claude Code по-прежнему используют извлечение — они просто применяют агентный поиск вместо опоры исключительно на векторные базы, аналогично тому, как работают разработчики-люди.
У вас есть множество стратегий извлечения — от простого поиска по ключевым словам до сходства эмбеддингов и LLM-фильтрации релевантности. Оптимальный подход зависит от вашего конкретного сценария, характеристик данных и требований к производительности. Многие продакшен-системы комбинируют несколько стратегий или используют многоэтапное извлечение под управлением LLM-агентов.
К сожалению, «RAG» стало модным словом без общепринятого определения. Одни используют его для обозначения любой системы извлечения, другие ограничивают векторными базами. Сосредоточьтесь на конечной цели: предоставить вашей LLM контекст, необходимый для успеха. Будет ли это через векторный поиск, агентное исследование или гибридные подходы — это продуктовое и инженерное решение.
Вместо того чтобы следовать категоричным советам избегать или принимать RAG, экспериментируйте с разными подходами к извлечению и измеряйте, что лучше всего работает для вашего приложения. Подробнее об оценке и оптимизации RAG — в этой серии статей.
В: Как подходить к оценке моей RAG-системы?
RAG-системы имеют два отдельных компонента, требующих разных подходов к оценке: извлечение и генерация.
Компонент извлечения — это задача поиска. Оценивайте его с помощью традиционных метрик информационного поиска (IR). Распространённые примеры: Recall@k (из всех релевантных документов, сколько вы извлекли в топ-k?), Precision@k (из k извлечённых документов, сколько были релевантными?) или MRR (насколько высоко оказался первый релевантный документ?). Конкретные метрики зависят от вашего сценария. Это чисто поисковые метрики, измеряющие, находите ли вы нужные документы (подробнее ниже).
Для оценки извлечения создайте датасет запросов с парами релевантных документов. Сгенерируйте его синтетически: возьмите документы из вашего корпуса, извлеките ключевые факты, затем сгенерируйте вопросы, на которые эти факты отвечают. Этот обратный процесс даёт пары «запрос—документ» для измерения эффективности извлечения без ручной аннотации.
Для компонента генерации — насколько хорошо LLM использует извлечённый контекст, галлюцинирует ли, отвечает ли на вопрос — используйте те же процедуры оценки, что описаны в этом курсе: анализ ошибок для выявления режимов сбоев, сбор человеческих меток, построение оценщиков LLM-as-judge и валидация этих судей на основе человеческих аннотаций.
Статья Jason Liu «There Are Only 6 RAG Evals» предлагает фреймворк, хорошо соотносящийся с этим разделением. Его Уровень 1 охватывает традиционные IR-метрики для извлечения. Уровни 2 и 3 оценивают связи между Вопросом, Контекстом и Ответом — например, релевантен ли контекст (C|Q), соответствует ли ответ контексту (A|C) и отвечает ли ответ на вопрос (A|Q).
В дополнение к шести eval'ам Jason, анализ ошибок на ваших данных может выявить доменно-специфические режимы сбоев, заслуживающие собственных метрик. Например, медицинская RAG-система может систематически не различать дозировки лекарств для взрослых и детей, а юридическая RAG — путать юрисдикционные границы. Эти паттерны проявляются только при систематическом анализе реальных сбоев. После выявления вы можете создать целенаправленные оценщики для этих конкретных проблем помимо общего фреймворка.
Наконец, при реализации метрик уровней 2 и 3 Jason не используйте промпты из коробки. Стандартный процесс LLM-as-judge требует нескольких шагов: анализ ошибок, итерации над промптами, создание размеченных примеров и измерение точности судьи по сравнению с человеческими метками. Когда вы знаете True Positive Rate и True Negative Rate вашего судьи, вы можете скорректировать его оценки для определения реальной частоты сбоев в системе. Пропустите эту валидацию — и ваши судьи могут не отражать реальные критерии качества.
Подводя итог: сначала отладьте извлечение с помощью IR-метрик, затем займитесь качеством генерации с помощью правильно провалидированных LLM-судей.
В: Как выбрать правильный размер чанка для задач обработки документов?
В отличие от RAG, где чанки оптимизируются для извлечения, при обработке документов предполагается, что модель увидит каждый чанк. Цель — разделить текст так, чтобы модель могла эффективно рассуждать, не будучи перегруженной. Даже если документ помещается в контекстное окно, может быть лучше разбить его. Длинные входы могут ухудшить качество из-за ограничений внимания, особенно в середине контекста. Два типа задач требуют разных стратегий:
1. Задачи с фиксированным выходом → Большие чанки
Это задачи, где длина выхода не растёт с входом: извлечение числа, ответ на конкретный вопрос, классификация раздела. Например:
«Какой штраф указан в этом контракте?» «Какова была зарплата CEO в 2023 году?»
Используйте максимально большой чанк (с оговорками), который, вероятно, содержит ответ. Это снижает количество запросов и предотвращает фрагментацию контекста. Однако избегайте добавления нерелевантного текста. Модели чувствительны к отвлекающим факторам, особенно при больших входах. Средние части длинного входа могут получить меньше внимания. Кроме того, если стоимость и задержка — узкие места, рассмотрите предобработку или фильтрацию документа (поиском по ключевым словам или лёгким ретривером) для выделения релевантных секций перед подачей большого чанка.
2. Задачи с расширяемым выходом → Меньшие чанки
Это суммаризация, исчерпывающее извлечение или любая задача, где выход растёт с входом. Например:
«Резюмируйте каждый раздел» «Перечислите все жалобы клиентов»
В этих случаях меньшие чанки помогают сохранить качество рассуждений и полноту выхода. Стандартный подход — обработать каждый чанк независимо, затем агрегировать результаты (например, map-reduce). При определении размера чанков старайтесь соблюдать границы контента — абзацы, разделы или главы. Чанкование также помогает справиться с ограничениями выхода. Разбивая задачу на части, выход каждой части остаётся в пределах лимитов.
Общие рекомендации
Важно понимать, почему размер чанка влияет на результаты. Больший чанк означает, что модель должна рассуждать над бо́льшим объёмом информации за раз — по сути, более высокую когнитивную нагрузку. У LLM ограниченная способность удерживать и связывать детали в длинном тексте. Если втиснуть слишком много, модель может приоритизировать определённые части (обычно начало или конец) и упустить или «забыть» детали в середине. Это может привести к чрезмерно общим резюме или пропущенным фактам. Напротив, меньший чанк ограничивает задачу: модель может уделить этому разделу полное внимание. Вы обмениваете глобальный контекст на локальный фокус.
Ни одно эмпирическое правило не может идеально определить лучший размер чанка для вашего сценария — валидируйте экспериментами. Оптимальный размер чанка зависит от домена и модели. Я рассматриваю размер чанка как гиперпараметр для настройки.
В: Как отлаживать многораундовые диалоговые трейсы?
Начните просто. Проверьте, достигнута ли цель пользователя во всём диалоге, оценкой «пройдено/не пройдено». Посмотрите на весь трейс и сфокусируйтесь на первом сбое выше по цепочке. Сначала прочитайте видимые пользователю части, чтобы понять, пошло ли что-то не так. И только потом углубляйтесь в технические детали — вызовы инструментов и промежуточные шаги.
Логирование трейсов мультиагентных систем
Для мультиагентных потоков назначьте ID сессии или трейса каждому запросу пользователя и логируйте каждое сообщение с указанием источника (какой агент или инструмент), ID трейса и позиции в последовательности. Это позволяет восстановить полный путь от начального запроса до финального результата по всем агентам.
Стратегия аннотирования
Изначально аннотируйте только первый сбой в трейсе — не беспокойтесь о последующих, поскольку они часто являются следствием первого. Исправление сбоев выше по цепочке часто автоматически устраняет зависимые последующие проблемы. По мере набора опыта вы сможете аннотировать независимые режимы сбоев в одном трейсе для ускорения общего анализа ошибок.
Упрощайте, когда возможно
Когда вы обнаруживаете сбой, воспроизведите его с помощью максимально простого тестового случая. Вот пример: предположим, бот-шоппер выдаёт неправильную политику возврата на 4-м шаге диалога. Прежде чем погружаться в сложность многораундового диалога, упростите его до одного шага: «Какой срок возврата для товара X1000?» Если сбой повторяется, вы доказали, что ошибка не связана с контекстом диалога — скорее всего, это базовая проблема извлечения или знаний, которую проще отладить.
Генерация тестовых случаев
Есть два основных подхода. Первый — симулировать пользователей другой LLM для создания реалистичных многораундовых диалогов. Второй — «тестирование N-1», когда вы предоставляете первые N-1 шагов реального диалога и проверяете, что происходит дальше. Подход N-1 часто работает лучше, поскольку использует реальные префиксы диалогов, а не полностью синтетические взаимодействия, но менее гибок.
Ключ — в балансе тщательности и эффективности. Не каждый многораундовый сбой требует многораундового анализа.
В: Как оценивать сессии с передачей человеку?
Фиксируйте в трейсах полный путь пользователя, включая передачи человеку. Трейс продолжается до тех пор, пока потребность пользователя не решена или сессия не завершена, а не когда ИИ передаёт запрос человеку. Логируйте решение о передаче, причину, переданный контекст, время ожидания, действия человека, финальное решение и наличие достаточного контекста у человека. Многие сбои происходят на границах передачи, когда ИИ передаёт слишком рано, слишком поздно или без надлежащего контекста.
Оценивайте передачи как потенциальные режимы сбоев при анализе ошибок. Спрашивайте: была ли передача необходима? Предоставил ли ИИ достаточный контекст? Отслеживайте как качество передачи, так и частоту передач. Иногда лучшее улучшение — это полное сокращение передач, а не улучшение их исполнения.
В: Как оценивать сложные многошаговые рабочие процессы?
Логируйте весь рабочий процесс от начального триггера до финального бизнес-результата. Включайте в трейсы вызовы LLM, использование инструментов, утверждения людей и записи в базу данных. Эта видимость необходима для правильной диагностики сбоев.
Используйте как метрики результата, так и метрики процесса. Метрики результата проверяют, соответствует ли финальный результат требованиям: полон ли бизнес-кейс? Точен ли? Правильно ли отформатирован? Метрики процесса оценивают эффективность: количество шагов, затраченное время, использование ресурсов. Процессные сбои часто легче отладить, поскольку они более детерминированы, — начинайте с них.
Сегментируйте анализ ошибок по стадиям рабочего процесса. Сбои ранних стадий (понимание ввода пользователя) отличаются от сбоев средних стадий (обработка данных) и поздних стадий (форматирование вывода). Улучшения ранних стадий имеют больший эффект, поскольку ошибки каскадируются в LLM-цепочках.
Используйте матрицы переходных ошибок для анализа того, где процессы ломаются. Создайте матрицу, показывающую последнее успешное состояние и место первого сбоя. Это выявляет проблемные зоны и подсказывает, куда инвестировать усилия по отладке.
В: Как оценивать агентные рабочие процессы?
Мы рекомендуем оценивать агентные рабочие процессы в два этапа:
1. Сквозной успех задачи. Рассматривайте агента как чёрный ящик и спрашивайте: «Достигнута ли цель пользователя?» Определите точное правило успеха для каждой задачи (точный ответ, корректный побочный эффект и т.д.) и измеряйте с помощью человеческих или откалиброванных LLM-судей. Обращайте внимание на первый сбой выше по цепочке при проведении анализа ошибок.
Когда анализ ошибок покажет, какие рабочие процессы сбоят чаще всего, переходите к пошаговой диагностике, чтобы понять, почему они сбоят.
2. Пошаговая диагностика. При условии, что вы достаточно инструментировали свою систему с деталями вызовов инструментов и ответов, вы можете оценивать отдельные компоненты: - Выбор инструмента: был ли выбранный инструмент подходящим? - Извлечение параметров: были ли входные данные полными и корректными? - Обработка ошибок: восстановился ли агент после пустых результатов или сбоев API? - Сохранение контекста: были ли сохранены ранние ограничения? - Эффективность: сколько шагов, секунд и токенов было потрачено? - Контрольные точки цели: для длинных процессов проверяйте ключевые вехи.
Пример: «Найти дома в Беркли до $1M и назначить показы» разбивается на: параметры извлечены корректно, релевантные объявления получены, доступность проверена, приглашения в календарь отправлены. Каждая контрольная точка может пройти или провалиться независимо, что делает отладку управляемой.
Используйте матрицы переходных ошибок для понимания паттернов сбоев. Создайте матрицу, где строки представляют последнее успешное состояние, а столбцы — место первого сбоя. Это отличный способ понять, где происходит больше всего ошибок.
Матрицы переходов превращают подавляющую сложность агента в действенные инсайты. Вместо того чтобы тонуть в ревью отдельных трейсов, вы можете сразу увидеть, что переходы GenSQL → ExecSQL вызывают 12 сбоев, тогда как DecideTool → PlanCal — только 2. Этот подход, основанный на данных, подсказывает, куда инвестировать усилия по отладке. Вот ещё один пример от Bryan Bischof, также для text-to-SQL агента:
В этом примере Bryan показывает вариации матриц переходов по экспериментам. Как организовать матрицу переходов, зависит от специфики вашего приложения. Например, text-to-SQL агент Bryan имеет последовательный рабочий процесс, который он использует для дополнительного аналитического понимания. Вы можете посмотреть его полный доклад для подробностей.
Создание тестовых случаев для сбоев агентов
Создание тестовых случаев для сбоев агентов следует тем же принципам, что и в предыдущем FAQ об отладке многораундовых диалоговых трейсов (т.е. пытайтесь воспроизвести ошибку максимально простым способом, используйте многораундовые тесты только когда сбой действительно требует контекста диалога и т.д.).
👉 Хотите узнать больше об AI Evals? Ознакомьтесь с нашим курсом AI Evals. Это живая когорта с практическими упражнениями и часами вопросов-ответов. Вот промокод на скидку 25% для читателей. 👈
Сноски
Eleanor Berger, наш замечательный ассистент преподавателя.↩︎ Paul Graham, «Writes and Write-Nots»↩︎ Shreya Shankar и др., «Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences»↩︎