LLM Evals: Everything You Need to Know
Статья представляет собой исчерпывающий FAQ по оценке (evals) LLM-приложений, составленный Hamel Husain и Shreya на основе вопросов от 700+ инженеров и продакт-менеджеров. Центральная идея — анализ ошибок (error analysis) является важнейшей практикой: необходимо вручную просматривать реальные трейсы, выявлять паттерны сбоев и лишь затем строить автоматические оценщики. Авторы рекомендуют бинарные (pass/fail) оценки вместо шкал Ликерта, предостерегают от использования готовых метрик вроде BERTScore и ROUGE, и советуют создавать кастомные инструменты разметки. Для RAG-систем предлагается раздельная оценка поиска (IR-метриками) и генерации (LLM-as-Judge). В проектах авторов 60–80% времени разработки уходит на анализ ошибок и оценку, а не на написание кода. Статья также охватывает синтетические данные, многошаговые агентные сценарии, матрицы переходных отказов и версионирование промптов через Git.
Этот документ собирает наиболее частые вопросы, которые получали мы с Shreya, обучая более 700 инженеров и продакт-менеджеров оценке ИИ (AI Evals). Предупреждение: это категоричные мнения о том, что работает в большинстве случаев. Это не универсальные истины. Используйте собственное суждение.
👉 Хотите узнать больше об AI Evals? Ознакомьтесь с нашим курсом по AI Evals. Это живая когорта с практическими упражнениями и консультациями. Вот код на скидку 25% для читателей. 👈
Послушайте аудиоверсию этого FAQ
Если вы предпочитаете послушать аудиоверсию (озвученную ИИ), вы можете воспроизвести её здесь.
Начало работы и основы
В: Что такое LLM Evals?
Если вы совсем новичок в продуктовых LLM-оценках (не в бенчмарках базовых моделей), прочитайте эти статьи: часть 1, часть 2 и часть 3. В противном случае продолжайте чтение.
Содержание:
Мотивация Быстрая итерация == Успех Кейс: Lucy — ИИ-ассистент для недвижимости Типы оценки Уровень 1: Юнит-тесты Уровень 2: Оценка человеком и моделью Уровень 3: A/B-тестирование Оценка RAG Системы оценки открывают суперспособности Бесплатная дообучение (Fine-Tuning) Синтез и курирование данных Отладка
Содержание:
Проблема: ИИ-команды тонут в данных Шаг 1: Найдите главного доменного эксперта Шаг 2: Создайте датасет Шаг 3: Направьте доменного эксперта выносить суждения «пройдено/не пройдено» с критикой Шаг 4: Исправьте ошибки Шаг 5: Итеративно постройте LLM-as-a-Judge Шаг 6: Проведите анализ ошибок Шаг 7: Создайте более специализированных LLM-судей (при необходимости) Резюме теневого критического анализа Ресурсы
Содержание:
Как анализ ошибок стабильно выявляет улучшения с наибольшим ROI Почему простой просмотрщик данных — ваша самая важная инвестиция в ИИ Как дать доменным экспертам (не только инженерам) возможность улучшать ваш ИИ Почему синтетические данные эффективнее, чем вы думаете Как поддерживать доверие к вашей системе оценки Почему ваш ИИ-роадмап должен считать эксперименты, а не фичи
В: Что такое трейс?
Трейс — это полная запись всех действий, сообщений, вызовов инструментов и обращений к данным от одного начального запроса пользователя до финального ответа. Он включает каждый шаг по всем агентам, инструментам и системным компонентам в рамках сессии: множество сообщений пользователя, ответы ассистента, извлечённые документы и промежуточные взаимодействия с инструментами.
Примечание о терминологии: Разные поставщики инструментов наблюдаемости используют различные определения трейсов и спанов. Анализ Alex Strick van Linschoten подчёркивает эти различия (скриншот ниже):
В: Какой минимально жизнеспособный набор для оценки?
Начните с анализа ошибок, а не с инфраструктуры. Потратьте 30 минут на ручной просмотр 20–50 выходов LLM при каждом значительном изменении. Используйте одного доменного эксперта, который понимает ваших пользователей, в качестве ответственного за качество — «доброжелательного диктатора».
Используйте ноутбук для просмотра трейсов и анализа данных, или создайте собственный интерфейс разметки с помощью ИИ-ассистента для кодинга вроде Claude или Codex. В любом случае вы сможете писать произвольный код, визуализировать данные и быстро итерировать. Видео ниже демонстрирует простой интерфейс разметки, построенный внутри ноутбука.
В: Какую долю бюджета на разработку следует выделять на оценку?
Важно понимать, что оценка — это часть процесса разработки, а не отдельная статья расходов, подобно тому как отладка является частью разработки программного обеспечения.
Вы всегда должны проводить анализ ошибок. Когда вы обнаруживаете проблемы в ходе анализа, многие из них окажутся простыми багами, которые вы исправите сразу. Эти исправления не требуют отдельной инфраструктуры оценки — они просто часть разработки.
Решение о создании автоматических оценщиков сводится к анализу затрат и выгод. Если ошибку можно отловить простым утверждением (assertion) или регулярным выражением, затраты минимальны и, вероятно, оправданы. Но если требуется настраивать оценщик LLM-as-Judge, подумайте, стоит ли этот режим отказа таких вложений.
В проектах, над которыми мы работали, мы тратили 60–80% времени разработки на анализ ошибок и оценку. Ожидайте, что основная часть усилий уйдёт на понимание сбоев (то есть на изучение данных), а не на создание автоматических проверок.
Остерегайтесь оптимизации ради высоких показателей прохождения оценок. Если вы проходите 100% оценок — скорее всего, вы недостаточно нагружаете свою систему. Показатель прохождения 70% может говорить о более содержательной оценке, которая действительно тестирует ваше приложение на прочность. Сосредоточьтесь на оценках, помогающих находить реальные проблемы, а не на тех, что делают ваши метрики красивыми.
В: Будут ли сегодняшние методы оценки актуальны через 5–10 лет, учитывая скорость изменений в ИИ?
Да. Даже с идеальными моделями вам всё равно нужно проверять, что они решают правильную задачу. Потребность в систематическом анализе ошибок, доменно-специфичном тестировании и мониторинге останется актуальной.
Сегодняшние приёмы промпт-инжиниринга могут устареть, но вам всё равно нужно будет понимать режимы отказов. Кроме того, LLM не может читать ваши мысли, и исследования показывают, что людям необходимо наблюдать за поведением LLM, чтобы правильно сформулировать свои требования.
Для более глубокого понимания этой дискуссии смотрите две точки зрения: «Модель — это продукт» против «Модель — это НЕ продукт».
«Модель — это продукт»:
«Модель — это НЕ продукт»:
В: Как убедить команду инвестировать в оценку?
Не пытайтесь продать команде идею «оценок». Вместо этого покажите, что вы находите, когда смотрите на данные.
Начните с анализа ошибок самостоятельно. Просмотрите 50–100 реальных пользовательских диалогов и найдите наиболее частые способы, которыми продукт подводит пользователей. Используйте эти находки, чтобы рассказать историю на основе данных.
Представьте команде:
Список основных режимов отказов, которые вы обнаружили. Метрики, показывающие, как часто случаются серьёзные ошибки. Неожиданные способы взаимодействия пользователей с продуктом. Отчёты о найденных и исправленных багах, поданные как «предотвращённые проблемы в продакшене».
Такой подход выстраивает доверие. Не просто показывайте дашборды и метрики — расскажите историю того, что вы находите в данных. Описывая свои находки, вы обучаете команду тому, что узнаёте, принося немедленную пользу. Когда вы исправляете проблему, покажите, как снизилась частота ошибок для этого конкретного случая. Вскоре команда увидит прогресс и спросит, как вы этого добиваетесь. Пусть результаты, а не методы ведут разговор.
Это похоже на классические проекты машинного обучения, где результаты спекулятивны, а прогресс ограничен итерациями над экспериментами. В такой ситуации важно делиться выводами из каждого эксперимента, чтобы показать прогресс и стимулировать инвестиции.
Анализ ошибок и сбор данных
В: Почему «анализ ошибок» так важен в LLM-оценках и как он проводится?
Анализ ошибок — самая важная деятельность в оценке. Он помогает решить, какие оценки писать в первую очередь. Он позволяет выявить режимы отказов, уникальные для вашего приложения и данных. Процесс включает:
1. Создание датасета
Соберите репрезентативные трейсы взаимодействий пользователей с LLM. Если у вас нет данных, вы можете сгенерировать синтетические данные для начала.
2. Открытое кодирование
Аннотаторы (в идеале — доброжелательный диктатор) просматривают трейсы и пишут свободные заметки, отмечая любые проблемы. Этот процесс сродни «ведению дневника» и заимствован из методологий качественного исследования. В начале рекомендуется фокусироваться на первом обнаруженном сбое в трейсе, так как ошибки на ранних этапах вызывают проблемы далее по цепочке, хотя можно также отмечать все независимые сбои, если это реализуемо. Этот шаг должен выполнять доменный эксперт.
3. Осевое кодирование
Категоризируйте свободные заметки в «таксономию сбоев». Другими словами, сгруппируйте похожие ошибки в отдельные категории. Это самый важный шаг. В конце подсчитайте количество сбоев в каждой категории. Для этого шага можно использовать LLM.
4. Итеративное уточнение
Продолжайте итерировать на новых трейсах, пока не достигнете теоретического насыщения, то есть новые трейсы перестанут выявлять новые режимы отказов или информацию. Как правило, стоит просмотреть не менее 100 трейсов. Мой примерный ориентир: если ~20 трейсов не выявляют новую категорию, можно остановиться (но начните с просмотра минимум 100). Помните, цель — приоритизировать сбои, которые действительно происходят чаще всего, а не отловить каждый возможный (оценки не бесплатны, поэтому нужен прагматизм).
Регулярно возвращайтесь к этому процессу. Существуют продвинутые способы более эффективной выборки данных, такие как кластеризация, сортировка по обратной связи от пользователей и сортировка по паттернам с высокой вероятностью сбоев. Со временем у вас выработается «чутьё» на то, где искать ошибки в ваших данных.
Не пропускайте анализ ошибок. Он гарантирует, что разрабатываемые вами метрики оценки основаны на реальном поведении приложения, а не на контрпродуктивных универсальных метриках (к использованию которых вас подталкивает большинство платформ). Примеры полезности анализа ошибок см. в этом видео или в этом блог-посте.
Вот визуализация процесса анализа ошибок от одного из наших студентов, Pawel Huryn — включая то, как он вписывается в общий процесс оценки:
В: Как обнаружить проблемные трейсы для просмотра помимо обратной связи от пользователей?
Хотя обратная связь от пользователей — хороший способ сузить поиск проблемных трейсов, другие методы тоже полезны. Вот три дополнительных подхода:
Начните со случайной выборки
Простейший подход — просмотр случайной выборки трейсов. Если проблем мало, переходите к стресс-тестированию: создайте запросы, которые намеренно проверяют ограничения вашего промпта, чтобы увидеть, следует ли ИИ вашим правилам.
Используйте оценки для первичного скрининга
Используйте существующие оценки для поиска проблемных трейсов и потенциальных проблем. После их выявления можно перейти к стандартному процессу оценки, начиная с анализа ошибок.
Используйте эффективные стратегии выборки
Для более продвинутого обнаружения трейсов используйте обнаружение выбросов, сортировку по метрикам и стратифицированную выборку для поиска интересных трейсов. Универсальные метрики могут служить сигналами для исследования — помогать находить трейсы, достойные просмотра, даже если они не измеряют качество напрямую.
В: Как часто нужно повторять анализ ошибок в продакшен-системе?
Повторяйте анализ ошибок при значительных изменениях: новые функции, обновления промптов, смена модели или крупные исправления багов. Полезный ориентир — ставить цель просматривать не менее 100 свежих трейсов за каждый цикл обзора. Типичные циклы обзора, которые мы наблюдали, составляют 2–4 недели. Смотрите этот FAQ о том, как эффективно делать выборку трейсов.
Между крупными анализами просматривайте 10–20 трейсов еженедельно, фокусируясь на выбросах: необычно длинных разговорах, сессиях с множеством повторных попыток или трейсах, отмеченных автоматическим мониторингом. Корректируйте частоту в зависимости от стабильности системы и роста использования. Новым системам нужен еженедельный анализ, пока паттерны сбоев не стабилизируются. Зрелые системы могут обойтись ежемесячным анализом, если паттерны использования не меняются. Всегда анализируйте после инцидентов, всплесков жалоб или дрейфа метрик. Масштабирование использования порождает новые пограничные случаи.
В: Каков лучший подход к генерации синтетических данных?
Распространённая ошибка — попросить LLM "дай мне тестовые запросы" без структуры, что приводит к шаблонным, повторяющимся результатам. Структурированный подход с использованием измерений (dimensions) даёт гораздо лучшие синтетические данные для тестирования 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 бесконечная поверхность потенциальных сбоев. Вы не можете предугадать, что сломается.
Лучший подход — начать с анализа ошибок. Пишите оценщики для обнаруженных ошибок, а не для воображаемых. Это избавит от ступора с вопросом «что оценивать» и предотвратит напрасные усилия на метрики, не влияющие на реальное качество системы.
Исключение: разработка через оценки может работать для конкретных ограничений, где вы точно знаете, как выглядит успех. Если вы добавляете правило «никогда не упоминать конкурентов», создание этого оценщика заранее может быть оправдано.
Главное — всегда проводите анализ затрат и выгод перед реализацией оценки. Спросите себя, оправдывает ли данный режим отказа такие вложения. Анализ ошибок покажет, какие сбои действительно важны для ваших пользователей.
В: Нужно ли создавать автоматические оценщики для каждого обнаруженного режима отказа?
Сосредоточьте автоматические оценщики на сбоях, которые сохраняются после исправления промптов. Многие команды обнаруживают, что их LLM не соответствует предпочтениям, которые они на самом деле никогда не формулировали — например, желание кратких ответов, определённого форматирования или пошагового рассуждения. Сначала устраните эти очевидные пробелы, а затем стройте сложную инфраструктуру оценки.
Учитывайте иерархию стоимости различных типов оценщиков. Простые утверждения (assertions) и проверки по эталону (сравнение с известными правильными ответами) дёшевы в создании и поддержке. Оценщики LLM-as-Judge требуют 100+ размеченных примеров, еженедельного обслуживания и координации между разработчиками, продакт-менеджерами и доменными экспертами. Эта разница в стоимости должна формировать вашу стратегию оценки.
Создавайте дорогие оценщики только для проблем, над которыми вы будете итерировать многократно. Поскольку LLM-as-Judge сопряжён со значительными накладными расходами, приберегите его для устойчивых ошибок обобщения — а не для проблем, которые исправляются тривиально. Начинайте с дешёвых кодовых проверок, где возможно: регулярные выражения, валидация структуры или тесты исполнения. Оставляйте сложную оценку для субъективных качеств, которые невозможно охватить простыми правилами.
В: Стоит ли использовать «готовые» метрики оценки?
Нет. Универсальные оценки тратят время и создают ложную уверенность. (Если только вы не используете их для исследования.)
Один из преподавателей отметил:
«Всё, что вы получаете от использования этих готовых оценок — вы не знаете, что они на самом деле делают, и в лучшем случае они тратят ваше время, а в худшем — создают иллюзию уверенности, которая ничем не подкреплена.»1
Универсальные метрики оценки повсюду. Библиотеки оценки содержат показатели вроде полезности, связности, качества и т. д., обещая лёгкую оценку. Эти метрики измеряют абстрактные свойства, которые могут быть нерелевантны для вашего сценария. Хорошие результаты по ним не означают, что ваша система работает.
Вместо этого проведите анализ ошибок, чтобы понять сбои. Определите бинарные режимы отказов на основе реальных проблем. Создайте кастомные оценщики для этих сбоев и валидируйте их относительно человеческих суждений. По сути — весь процесс оценки.
Опытные практики всё же могут использовать эти метрики, просто не так, как вы ожидаете. Как говорил Пикассо: «Изучите правила как профессионал, чтобы нарушать их как художник». Когда вы поймёте, почему универсальные метрики не работают в качестве оценок, вы сможете перепрофилировать их как инструменты исследования для поиска интересных трейсов (объясняется в следующем FAQ).
В: Полезны ли метрики сходства (BERTScore, ROUGE и др.) для оценки выходов LLM?
Универсальные метрики вроде BERTScore, ROUGE, косинусного сходства и т. д. не полезны для оценки выходов LLM в большинстве ИИ-приложений. Вместо них мы рекомендуем использовать анализ ошибок для выявления метрик, специфичных для поведения вашего приложения. Мы рекомендуем проектировать бинарные (пройдено/не пройдено) оценки (с использованием LLM-as-Judge) или кодовые утверждения (assertions).
Для примера рассмотрим CRM-ассистент для недвижимости. Предложение показов, которые недоступны (можно протестировать утверждением), или путаница между персонами клиентов (можно протестировать с LLM-as-Judge) — это проблемы. Универсальные метрики вроде сходства или многословия этого не поймают. Релевантная цитата из курса:
«Злоупотребление универсальными метриками носит массовый характер. Многие поставщики инструментов оценки продвигают готовые метрики, которые затягивают инженеров в бесполезную работу.»
Метрики сходства не всегда бесполезны. Они полезны в доменах поиска и рекомендаций (и, следовательно, могут быть полезны для оптимизации и отладки поиска в RAG). Например, косинусное сходство между эмбеддингами может измерять семантическую близость в поисковых системах, а среднее попарное сходство позволяет оценивать разнообразие выходов (где более низкое сходство означает большее разнообразие).
В: Можно ли использовать одну и ту же модель для основной задачи и для оценки?
При выборе модели для LLM-as-Judge использование той же модели обычно допустимо, потому что судья выполняет задачу, отличную от вашего основного LLM-пайплайна. Хотя исследования показали, что модели могут проявлять предвзятость при оценке собственных выходов, в конечном счёте важно, насколько хорошо ваш судья согласуется с человеческими суждениями. Судьи, которых мы рекомендуем создавать, выполняют узкие задачи бинарной классификации. Мы обнаружили, что итеративная настройка согласованности с человеческими метками обычно достижима для такой ограниченной задачи.
Сосредоточьтесь на достижении высокого показателя истинно положительных (TPR) и истинно отрицательных (TNR) результатов вашего судьи на отложенном размеченном тестовом наборе. Если вам не удаётся достичь хорошей согласованности с человеческими оценками, попробуйте другую модель. Однако подключение нового поставщика моделей может потребовать нетривиальных усилий в некоторых организациях, поэтому мы не рекомендуем использовать разные модели по умолчанию, если нет конкретной проблемы с согласованностью.
При выборе моделей для судьи начинайте с самых мощных доступных моделей, чтобы установить надёжную согласованность с человеческими суждениями. Оптимизировать по стоимости можно позднее, когда вы установите надёжные критерии оценки.
В: Как оценить способность модели выражать неуверенность или «знать, чего она не знает»?
Многие приложения требуют модели, способной отказаться отвечать на вопрос, когда информации недостаточно. Чтобы оценить, правильно ли откалибровано такое поведение отказа, нужно проверить, отказывает ли модель в нужные моменты, не отказывая при этом на вопросы, на которые должна уметь ответить.
Для эффективной проверки вам нужно составить набор для оценки со следующими компонентами:
Вопросы с ответом: сценарии, в которых правильный, проверяемый ответ присутствует в предоставленном контексте модели или в её общих знаниях. Вопросы без ответа: сценарии, намеренно провоцирующие модель на галлюцинации. Сюда входят вопросы с ложными предпосылками, запросы об информации, явно отсутствующей в контексте, или темы далеко за пределами её базы знаний.
Хотя точная пропорция не критична, сбалансированный набор с примерно равным количеством вопросов с ответом и без ответа — хорошая отправная точка. Разнообразие и сложность вопросов важнее точного соотношения.
Сама оценка — это бинарная (пройдено/не пройдено) проверка суждений модели. «Пройдено» требует от модели выполнения двух условий: она должна отвечать на вопросы с ответом и при этом отказываться отвечать на вопросы без ответа. Провал определяется как предоставление выдуманного ответа на вопрос без ответа, что указывает на плохую калибровку.
В научной литературе эта способность известна как «Abstention Ability» (способность к воздержанию). Для улучшения этого поведения стоит поискать этот термин на Arxiv, чтобы изучить новейшие методики.
👉 Хотите узнать больше об AI Evals? Ознакомьтесь с нашим курсом по AI Evals. Это живая когорта с практическими упражнениями и консультациями. Вот код на скидку 25% для читателей. 👈
Человеческая разметка и процесс
В: Сколько человек должны размечать выходы моего LLM?
Для большинства малых и средних компаний назначение одного доменного эксперта «доброжелательным диктатором» — наиболее эффективный подход. Этот человек — будь то психолог для чат-бота психологической помощи, юрист для анализа юридических документов или директор клиентского сервиса для автоматизации поддержки — становится решающим голосом по стандартам качества.
Один эксперт устраняет конфликты при разметке и предотвращает паралич от «слишком много поваров на кухне». Доброжелательный диктатор может учитывать вклад и обратную связь от других, но именно он ведёт процесс. Если вам кажется, что для оценки одного взаимодействия нужны пять предметных экспертов — это признак того, что охват вашего продукта, возможно, слишком широк.
Однако крупные организации или те, что работают в нескольких доменах (например, международная компания с различными культурными контекстами), могут нуждаться в нескольких аннотаторах. Если вы привлекаете нескольких человек, вам нужно измерять их согласованность с помощью метрик вроде каппы Коэна, учитывающей согласие сверх случайного. Тем не менее, используйте здравый смысл. Даже в крупных компаниях одного эксперта часто достаточно.
Начинайте с доброжелательного диктатора, когда это возможно. Добавляйте сложность только тогда, когда этого требует ваш домен.
В: Должны ли продакт-менеджеры и инженеры совместно проводить анализ ошибок? Как?
На начальном этапе сотрудничайте для формирования общего контекста. Инженеры замечают технические проблемы вроде ошибок поиска и сбоев инструментов. Продакт-менеджеры выявляют продуктовые сбои — неоправданные ожидания пользователей, запутанные ответы или отсутствие функций, которых пользователи ожидают.
Со временем стоит склоняться к модели доброжелательного диктатора для анализа ошибок: доменного эксперта или продакт-менеджера, понимающего потребности пользователей. Дайте доменным экспертам возможность оценивать фактические результаты, а не техническую реализацию. Спрашивайте «Была ли записана встреча?», а не «Успешно ли прошёл вызов инструмента?». Лучший способ расширить полномочия доменного эксперта — дать ему кастомные инструменты разметки, отображающие результаты системы рядом с трейсами. Покажите подтверждение, сгенерированное письмо или обновление базы данных, подтверждающее выполнение цели. Держите весь контекст на одном экране, чтобы нетехнические рецензенты фокусировались на результатах.
В: Стоит ли отдавать разметку и маркировку на аутсорс?
Аутсорсинг анализа ошибок — обычно серьёзная ошибка (с некоторыми исключениями). Суть оценки — формирование продуктовой интуиции, которая появляется только при систематическом анализе сбоев вашей системы. К делегированию этого процесса следует относиться крайне скептически.
Опасности аутсорсинга
Когда вы отдаёте разметку на аутсорс, вы часто разрываете обратную связь между наблюдением сбоя и пониманием того, как улучшить продукт. Проблемы аутсорсинга:
Поверхностная разметка: даже чётко определённые метрики требуют нюансированных суждений, которых нет у внешних команд. Критическая ошибка в анализе — исключение доменных экспертов из процесса разметки. Делегирование этой задачи людям без доменной экспертизы, таким как обычные разработчики или ИТ-специалисты, часто приводит к поверхностной или некорректной разметке. Потеря негласных знаний: главный доменный эксперт обладает неявными знаниями и пониманием пользователей, которые невозможно полностью зафиксировать в рубрике. Привлечение таких экспертов помогает раскрыть их предпочтения и ожидания, которые они могут не суметь сформулировать заранее. Конфликты и рассогласование разметки: без общего контекста внешние аннотаторы могут порождать больше разногласий, чем разрешать. Достижение согласованности — проблема даже для внутренних команд, а значит, вы потратите на этот процесс ещё больше времени.
Рекомендуемый подход: развивайте внутренние компетенции
Вместо аутсорсинга сосредоточьтесь на построении эффективного внутреннего процесса оценки.
1. Назначьте «доброжелательного диктатора». Для большинства команд наиболее эффективная стратегия — назначить одного внутреннего доменного эксперта финальным арбитром качества. Этот человек задаёт стандарт, обеспечивает последовательность и развивает чувство ответственности.
2. Используйте совместный рабочий процесс при наличии нескольких аннотаторов. Если несколько аннотаторов необходимы, следуйте структурированному процессу для обеспечения согласованности: * Составьте начальную рубрику с чёткими определениями «пройдено/не пройдено» и примерами. * Пусть каждый аннотатор независимо разметит общий набор трейсов для выявления различий в интерпретации. * Измерьте межаннотаторское согласие (IAA) с помощью метрики, скорректированной на случайность, например каппы Коэна. * Проведите сессии согласования для обсуждения разногласий и уточнения рубрики. * Итерируйте этот процесс, пока согласие не станет стабильно высоким.
Как справиться с ограничениями по ресурсам
Развитие внутренних компетенций не означает, что нужно размечать каждый трейс. Используйте эти стратегии для управления нагрузкой:
Умная выборка: тщательно просматривайте небольшую репрезентативную выборку трейсов. Эффективнее проанализировать 100 разнообразных трейсов для поиска паттернов, чем поверхностно разметить тысячи. Протокол «мышления вслух»: чтобы максимально использовать ограниченное время эксперта, применяйте эту технику из юзабилити-тестирования. Попросите эксперта проговаривать свой мыслительный процесс при просмотре нескольких трейсов. Этот метод может раскрыть глубокие инсайты за одну часовую сессию. Создавайте лёгкие кастомные инструменты: создайте кастомные инструменты разметки для ускорения процесса обзора и повышения пропускной способности.
Исключения для внешней помощи
Хотя аутсорсинг основного процесса анализа ошибок не рекомендуется, есть сценарии, в которых внешняя помощь уместна:
Чисто механические задачи: для высокообъективных, однозначных задач — таких как определение номера телефона или валидация адреса электронной почты — можно привлечь внешних аннотаторов после того, как рубрика определена строгим внутренним процессом. Задачи без продуктового контекста: чётко определённые задачи, не требующие понимания специфических требований вашего продукта, можно передать на аутсорс. Перевод — хороший пример: он требует лингвистической экспертизы, но не глубокого знания продукта. Привлечение предметных экспертов: наём внешних SME для роли ваших внутренних доменных экспертов — это не аутсорсинг, а привнесение необходимой экспертизы в процесс оценки. Например, AnkiHub нанял студентов-медиков 4-го курса для оценки своих RAG-систем для медицинского контента вместо привлечения обычных аннотаторов.
В: Какие части оценки можно автоматизировать с помощью LLM?
LLM могут ускорить части вашего рабочего процесса оценки, но не могут заменить человеческое суждение там, где ваша экспертиза незаменима. Например, если вы поручите LLM весь анализ ошибок (то есть просмотр и аннотирование трейсов), вы можете упустить случаи сбоев, важные для вашего продукта. Допустим, пользователи постоянно упоминают «задержки» в обратной связи, но LLM объединяет их в общую категорию «проблемы производительности» вместо создания категории «латентность». Вы пропустите повторяющуюся жалобу на медленное время отклика и не приоритизируете исправление.
Тем не менее LLM — ценные инструменты для ускорения определённых этапов рабочего процесса оценки, когда используются под контролем.
Вот области, в которых LLM могут помочь:
Первичное осевое кодирование: после того как вы сами провели открытое кодирование 30–50 трейсов, используйте LLM для организации ваших сырых заметок о сбоях в предлагаемые группировки. Это помогает быстро находить паттерны, но всегда пересматривайте и уточняйте кластеры самостоятельно. Примечание: если вы не знакомы с осевым и открытым кодированием, см. этот FAQ. Соотнесение аннотаций с режимами отказов: когда вы определили категории сбоев, можно попросить LLM предложить, какие категории применимы к каждому новому трейсу (например: «Учитывая эту аннотацию: [открытая_аннотация] и эти режимы отказов: [список_режимов_отказов], какие подходят?»). Предложение улучшений промптов: когда вы замечаете повторяющиеся проблемы, попросите LLM предложить конкретные изменения ваших промптов. Проверяйте эти предложения перед применением. Анализ данных аннотаций: используйте LLM или ноутбуки с ИИ для поиска паттернов в ваших метках — например, «жалобы на задержки возрастают в 3 раза в часы пиковой нагрузки» или «медленное время отклика чаще всего отмечается пользователями мобильных устройств».
Однако эти действия не стоит делегировать LLM:
Первичное открытое кодирование: всегда читайте сырые трейсы самостоятельно в начале. Именно так вы обнаруживаете новые типы сбоев, понимаете болевые точки пользователей и вырабатываете интуицию относительно своих данных. Никогда не пропускайте и не делегируйте это. Валидация таксономий сбоев: группировки, созданные LLM, требуют вашего пересмотра. Например, LLM может объединить «приложение падает после входа» и «вход слишком медленный» в одну категорию «проблемы со входом», хотя одна — проблема стабильности, а другая — производительности. Без вашего вмешательства вы упустите, что эти проблемы требуют разных решений. Разметка эталонных данных: для любых данных, используемых для тестирования/валидации оценщиков LLM-as-Judge, вручную проверяйте каждую метку. LLM могут ошибаться, что приводит к ненадёжным бенчмаркам. Анализ первопричин: LLM могут указать на очевидные проблемы, но только ручной просмотр выявит паттерны вроде ошибок, возникающих в определённых рабочих процессах или пограничных случаях — например, баги, проявляющиеся только при вставке данных из Excel.
В заключение: начинайте с ручного изучения данных, чтобы понять, что действительно идёт не так. Используйте LLM для масштабирования того, что вы узнали, а не для того, чтобы избежать работы с данными.
В: Стоит ли отказаться от ручного написания промптов в пользу автоматизированных инструментов?
Автоматизация промпт-инжиниринга может быть соблазнительной, но стоит скептически относиться к инструментам, обещающим оптимизировать промпты за вас, особенно на ранних этапах разработки. Когда вы пишете промпт, вы вынуждены прояснять свои предположения и формализовать свои требования. Хорошее письмо — это хорошее мышление2. Если вы делегируете эту задачу автоматизированному инструменту слишком рано, вы рискуете никогда полностью не понять собственные требования или режимы отказов модели.
Дело в том, что автоматическая оптимизация промптов обычно выполняет «восхождение на холм» по заранее определённой метрике оценки. Она может улучшить промпт на известных сбоях, но не может обнаружить новые. Обнаружение новых ошибок требует анализа ошибок. Кроме того, исследования показывают, что критерии оценки имеют тенденцию смещаться после просмотра выходов модели — явление, известное как «дрейф критериев»3. Это означает, что оценка — итеративный, управляемый человеком процесс осмысления, а не статическая цель, которую можно задать один раз и передать оптимизатору.
Прагматичный подход — использовать LLM для улучшения промпта на основе открытого кодирования (свободных заметок о трейсах). Так вы сохраняете человека в контуре, который смотрит на данные и формализует свои требования. Когда у вас есть качественный набор оценок, оптимизация промптов может быть эффективна на последнем этапе повышения производительности.
👉 Хотите узнать больше об AI Evals? Ознакомьтесь с нашим курсом по AI Evals. Это живая когорта с практическими упражнениями и консультациями. Вот код на скидку 25% для читателей. 👈
Инструменты и инфраструктура
В: Создавать кастомный инструмент разметки или использовать готовое решение?
Создавайте кастомный инструмент разметки. Это самая результативная инвестиция, которую вы можете сделать для рабочего процесса оценки ИИ. С помощью инструментов разработки с ИИ, таких как Cursor или Lovable, вы сможете создать адаптированный интерфейс за часы. По моему опыту, команды с кастомными инструментами разметки итерируют примерно в 10 раз быстрее.
Кастомные инструменты превосходят готовые, потому что:
Они показывают весь контекст из нескольких систем в одном месте Они могут отображать ваши данные в специфичном для продукта виде (изображения, виджеты, markdown, кнопки и т. д.) Они спроектированы под ваш конкретный рабочий процесс (кастомные фильтры, сортировка, индикаторы прогресса и т. д.)
Готовые инструменты могут быть оправданы, когда нужно координировать десятки распределённых аннотаторов с корпоративным контролем доступа. Но даже тогда многие команды считают, что накладные расходы на настройку и ограничения того не стоят.
Приложение Isaac для аннотации карточек Anki демонстрирует мощь кастомных инструментов — обработка 400+ результатов за запрос с навигацией по клавиатуре и доменно-специфическими критериями оценки, которые было бы практически невозможно настроить в универсальном инструменте.
В: Что делает интерфейс для просмотра выходов LLM хорошим?
Отличные интерфейсы делают ручной просмотр быстрым, наглядным и мотивирующим. Мы рекомендуем создать собственный инструмент разметки, адаптированный к вашему домену. Следующие возможности — это потенциальные улучшения, которые мы видели на практике, но вам не нужны все сразу. Показанные скриншоты — иллюстративные примеры для пояснения концепций. На практике я редко реализую все эти возможности в одном приложении. В конечном счёте это вопрос суждения, исходя из ваших конкретных потребностей и ограничений.
1. Отображайте трейсы осмысленно, а не шаблонно:
Представляйте трейс интуитивно понятным для домена способом. Если вы оцениваете сгенерированные письма, показывайте их как письма. Если выход — код, используйте подсветку синтаксиса. Дайте рецензенту видеть полный трейс (ввод пользователя, вызовы инструментов и рассуждения LLM), но менее важные детали поместите в сворачиваемые секции. Вот пример кастомного инструмента разметки для обзора писем ИИ-ассистента по недвижимости:
2. Показывайте прогресс и поддерживайте навигацию клавиатурой:
Поддерживайте рецензентов в состоянии потока, минимизируя трение и мотивируя к завершению. Включите индикаторы прогресса (например, «Трейс 45 из 100»), чтобы ограничить сессию просмотра и стимулировать завершение. Добавьте горячие клавиши для навигации между трейсами (например, N — следующий), применения меток и быстрого сохранения заметок. Ниже — иллюстрация этих возможностей:
3. Навигация по трейсам через кластеризацию, фильтрацию и поиск:
Позвольте рецензентам фильтровать трейсы по метаданным или искать по ключевым словам. Семантический поиск помогает находить концептуально похожие проблемы. Кластеризация похожих трейсов (например, группировка по персоне пользователя) позволяет рецензентам выявлять повторяющиеся проблемы и исследовать гипотезы. Ниже — иллюстрация этих возможностей:
4. Приоритизируйте разметку трейсов, которые могут быть проблемными:
Выделяйте трейсы, отмеченные защитными барьерами, сбоями CI или автоматическими оценщиками. Предусмотрите кнопки для действий — добавления в датасеты, создания багов или повторного запуска тестов пайплайна. Отображайте релевантный контекст (версия пайплайна, оценки оценщиков, информация о рецензенте) прямо в интерфейсе, чтобы минимизировать переключение контекста. Ниже — иллюстрация этих идей:
Общий принцип: сохраняйте минимализм
Держите интерфейс разметки минималистичным. Включайте эти идеи только если их польза перевешивает дополнительную сложность и затраты на поддержку.
В: Какие пробелы в инструментарии оценки мне придётся заполнять самостоятельно?
Большинство инструментов оценки хорошо справляются с базовыми задачами: логирование полных трейсов, отслеживание метрик, песочницы для промптов и очереди для разметки. Это минимум. Вот четыре области, в которых вам, скорее всего, придётся дополнять существующие инструменты.
Следите за вендорами, которые закрывают эти пробелы: это сильный сигнал того, что они понимают потребности практиков.
1. Анализ ошибок и обнаружение паттернов
После просмотра трейсов, в которых ваш ИИ ошибается, может ли ваш инструментарий автоматически кластеризовать похожие проблемы? Например, если в нескольких трейсах ассистент использует неформальный язык для клиентов премиум-сегмента, вам нужно что-то, что распознает более широкий паттерн «несоответствие персоны и тона». Мы рекомендуем создавать возможности, использующие ИИ для предложения группировок, переформулирования ваших наблюдений в более чёткие таксономии сбоев, помощи в поиске похожих случаев через семантический поиск и т. д.
2. ИИ-помощь на протяжении всего рабочего процесса
Наиболее эффективные рабочие процессы используют ИИ для ускорения каждого этапа оценки. При анализе ошибок вам нужен LLM, помогающий категоризировать ваши свободные наблюдения в связные режимы отказов. Например, вы можете аннотировать несколько трейсов заметками вроде «неправильный тон для инвестора», «слишком неформально для покупателя элитной недвижимости» и т. д. Ваш инструментарий должен распознать их как один и тот же глубинный паттерн и предложить объединённую категорию «несоответствие персоны и тона».
Вам также понадобится ИИ-помощь в предложении исправлений. После выявления 20 случаев, когда ваш ассистент упускает правила содержания домашних животных в описаниях объектов, может ли ваш рабочий процесс проанализировать эти сбои и предложить конкретные изменения промпта? Может ли он подготовить уточнения ваших инструкций по генерации SQL, когда замечает паттерн пропущенных условий WHERE?
Хорошие рабочие процессы также помогают проводить анализ данных ваших аннотаций и трейсов. Мне нравится использовать ноутбуки с ИИ в контуре, такие как Julius или Hex. Они помогают мне обнаруживать инсайты вроде «ошибки неоднозначности местоположения возрастают в 3 раза, когда пользователи упоминают названия районов» или «несоответствия тона возникают на 80% чаще при генерации писем, чем в других модальностях».
3. Кастомные оценщики вместо универсальных метрик
Будьте готовы создавать большинство оценщиков с нуля. Универсальные метрики вроде «оценки галлюцинаций» или «рейтинга полезности» редко отражают то, что действительно важно для вашего приложения — например, предложение недоступного времени показа или пропуск бюджетных ограничений в письмах. По нашему опыту, успешные команды тратят основную часть усилий на метрики, специфичные для приложения.
4. API, поддерживающие кастомные приложения для разметки
Кастомные интерфейсы разметки лучше всего подходят большинству команд. Для этого необходимы платформы наблюдаемости с продуманными API. Мне часто приходится создавать собственные библиотеки и абстракции, чтобы сделать массовый экспорт данных управляемым. Вы не должны пагинировать тысячи запросов или справляться с эндпоинтами, склонными к тайм-аутам, только чтобы получить свои данные. Ищите платформы с настоящими возможностями массового экспорта и, что критически важно, API, позволяющими эффективно записывать аннотации обратно.
В: Какой ваш любимый вендор инструментов оценки?
Инструменты оценки находятся в условиях жёсткой конкуренции. Сравнивать их функциональность бессмысленно. Если бы я попытался провести такой анализ, он устарел бы через неделю! Вендоры, с которыми я чаще всего сталкиваюсь естественным образом в своей работе: Langsmith, Arize и Braintrust.
Когда я помогаю клиентам с выбором вендора, решение в значительной мере определяется тем, кто может предложить лучшую поддержку, а не только функциональностью. Это зависит от размера клиента, сценария использования и т. д. Да — в основном важен человеческий фактор и, осмелюсь сказать, ощущения.
У меня нет любимого вендора. По сути, их функциональность очень схожа — и я часто создаю кастомные инструменты поверх них под свои нужды.
Вот серия видео с живым комментарием о сильных и слабых сторонах трёх вышеупомянутых вендоров.
В: Как версионировать и управлять промптами?
Существует неизбежное противоречие между хранением промптов рядом с кодом и средой, доступной нетехническим заинтересованным лицам.
Мой предпочтительный подход — хранение промптов в Git. Это превращает их в программные артефакты, которые версионируются, проходят ревью и развёртываются атомарно вместе с кодом приложения. Хотя командная строка Git недружелюбна для нетехнических людей, веб-интерфейс GitHub и десктопное приложение GitHub делают его весьма доступным. Когда я работал в GitHub, я сотрудничал со многими нетехническими специалистами, включая юристов и бухгалтеров, которые эффективно пользовались этими инструментами. Вот блог-пост, ориентированный на нетехнических людей, для начала работы.
Альтернативно, большинство вендоров в пространстве инструментов для LLM, таких как платформы наблюдаемости Arize, Braintrust и LangSmith, предлагают специализированные инструменты управления промптами. Они удобны для быстрых итераций, но рискуют создать дополнительные уровни косвенности.
Почему инструменты управления промптами часто не оправдывают ожиданий: ИИ-продукты обычно включают множество движущихся частей: инструменты, RAG, агенты и т. д. Инструменты управления промптами изначально ограничены, потому что не могут легко выполнять код вашего приложения. Даже когда могут — часто присутствует значительная косвенность, затрудняющая тестирование промптов с возможностями вашей системы.
Когда возможно, ноутбук — отличное решение для экспериментов с промптами. Если у вас есть Python-точки входа в кодовую базу или она написана на Python, Jupyter-ноутбуки особенно эффективны для этой цели. Вы можете экспериментировать с промптами и итерировать на ваших реальных ИИ-агентах со всеми их возможностями инструментов и RAG. Это значительно облегчает понимание того, как ваша система работает на практике. Кроме того, вы можете создавать виджеты и небольшие пользовательские интерфейсы внутри ноутбуков, получая лучшее из обоих миров для экспериментов и итераций. Чтобы увидеть, как это выглядит на практике, Teresa Torres даёт отличный, практический разбор того, как она, будучи продакт-менеджером, использовала ноутбуки для всего жизненного цикла оценки и экспериментов:
Если ноутбуки не подходят для вашей кодовой базы, интегрированная среда для промптов может быть эффективной для экспериментов. В любом случае я предпочитаю версионировать и управлять промптами в Git.
👉 Хотите узнать больше об AI Evals? Ознакомьтесь с нашим курсом по AI Evals. Это живая когорта с практическими упражнениями и консультациями. Вот код на скидку 25% для читателей. 👈
Продакшен и развёртывание
В: Чем различается использование оценок в CI/CD и в мониторинге продакшена?
Самое важное различие между оценкой в CI и в продакшене — данные, используемые для тестирования.
Тестовые наборы данных для CI невелики (во многих случаях 100+ примеров) и созданы целенаправленно. Примеры покрывают основные функции, регрессионные тесты для прошлых багов и известные пограничные случаи. Поскольку CI-тесты запускаются часто, стоимость каждого теста необходимо тщательно учитывать (поэтому набор данных нужно тщательно курировать). Предпочитайте утверждения (assertions) или другие детерминированные проверки вместо оценщиков LLM-as-Judge.
Для оценки продакшен-трафика можно делать выборку живых трейсов и запускать оценщики асинхронно. Поскольку для продакшен-данных обычно нет эталонных выходов, приходится больше полагаться на более дорогие безреференсные оценщики вроде LLM-as-Judge. Кроме того, отслеживайте доверительные интервалы для продакшен-метрик. Если нижняя граница пересекает ваш порог — расследуйте подробнее.
Эти две системы дополняют друг друга: когда мониторинг продакшена выявляет новые паттерны сбоев через анализ ошибок и оценки, добавляйте репрезентативные примеры в ваш CI-датасет. Это предотвращает регрессии по новым проблемам.
В: В чём разница между защитными барьерами (guardrails) и оценщиками (evaluators)?
Защитные барьеры — это встроенные проверки безопасности, расположенные непосредственно на пути запроса/ответа. Они валидируют входы или выходы до того, как что-либо достигнет пользователя, поэтому обычно:
Быстрые и детерминированные — обычно в рамках нескольких миллисекунд задержки. Простые и объяснимые — регулярные выражения, списки блокировки по ключевым словам, валидаторы схем или типов, лёгкие классификаторы. Нацелены на очевидные, высокоимпактные сбои — утечки PII, ненормативная лексика, запрещённые инструкции, SQL-инъекции, невалидный JSON, неправильный синтаксис кода и т. д.
Если защитный барьер срабатывает, система может отредактировать, отклонить или перегенерировать ответ. Поскольку эти проверки видны пользователю при срабатывании, ложные срабатывания рассматриваются как баги продакшена; команды версионируют правила барьеров, логируют каждое срабатывание и мониторят частоту, чтобы держать их консервативными.
С другой стороны, оценщики обычно запускаются после генерации ответа. Оценщики измеряют качества, которые простые правила не могут охватить, такие как фактическая корректность, полнота и т. д. Их вердикты наполняют дашборды, регрессионные тесты и циклы улучшения модели, но не блокируют исходный ответ.
Оценщики обычно запускаются асинхронно или в пакетном режиме, чтобы позволить более тяжёлые вычисления, такие как LLM-as-a-Judge. Встроенное использование LLM-as-a-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 «Существует только 6 RAG-оценок» предлагает фреймворк, хорошо соответствующий этому разделению. Его уровень 1 покрывает традиционные IR-метрики для поиска. Уровни 2 и 3 оценивают взаимосвязи между вопросом, контекстом и ответом — например, релевантен ли контекст (C|Q), верен ли ответ контексту (A|C) и отвечает ли ответ на вопрос (A|Q).
В дополнение к шести оценкам Jason, анализ ошибок на ваших конкретных данных может выявить доменно-специфичные режимы отказов, заслуживающие собственных метрик. Например, медицинская RAG-система может систематически путать дозировки лекарств для взрослых и детей, а юридическая RAG — путать границы юрисдикций. Эти паттерны проявляются только при систематическом анализе реальных сбоев. Выявив их, вы можете создать целевые оценщики для этих конкретных проблем, выходящие за рамки общего фреймворка.
Наконец, при реализации метрик уровней 2 и 3 Jason не используйте промпты из коробки. Стандартный процесс LLM-as-Judge требует нескольких шагов: анализ ошибок, итерация промптов, создание размеченных примеров и измерение точности вашего судьи относительно человеческих меток. Когда вы знаете показатели True Positive и True Negative вашего судьи, вы можете скорректировать его оценки для определения реальной частоты сбоев в вашей системе. Пропустите эту валидацию — и ваши судьи могут не отражать ваши реальные критерии качества.
Резюме: сначала отлаживайте поиск с помощью IR-метрик, затем работайте над качеством генерации с помощью должным образом валидированных LLM-судей.
В: Как выбрать правильный размер чанка для задач обработки документов?
В отличие от RAG, где чанки оптимизируются для поиска, обработка документов предполагает, что модель увидит каждый чанк. Цель — разделить текст так, чтобы модель могла эффективно рассуждать, не перегружаясь. Даже если документ помещается в контекстное окно, может быть лучше его разбить. Длинные входы могут ухудшить производительность из-за узких мест внимания, особенно в середине контекста. Два типа задач требуют разных стратегий:
1. Задачи с фиксированным выходом → Крупные чанки
Это задачи, где длина выхода не растёт с объёмом входа: извлечение числа, ответ на конкретный вопрос, классификация раздела. Например:
«Какой штрафной пункт в этом контракте?» «Какой была зарплата CEO в 2023 году?»
Используйте максимально большой чанк (с оговорками), который с наибольшей вероятностью содержит ответ. Это сокращает число запросов и предотвращает фрагментацию контекста. Однако избегайте добавления нерелевантного текста. Модели чувствительны к отвлекающим факторам, особенно при больших входах. Средние части длинного входа могут получать недостаточно внимания. Кроме того, если стоимость и задержка являются узким местом, стоит рассмотреть предварительную обработку или фильтрацию документа (через поиск по ключевым словам или лёгкий ретривер) для выделения релевантных разделов перед подачей огромного чанка.
2. Задачи с расширяемым выходом → Мелкие чанки
Сюда входят суммаризация, исчерпывающее извлечение и любые задачи, где выход растёт с объёмом входа. Например:
«Суммаризируйте каждый раздел» «Перечислите все жалобы клиентов»
В этих случаях мелкие чанки помогают сохранить качество рассуждений и полноту выхода. Стандартный подход — обрабатывать каждый чанк независимо, а затем агрегировать результаты (например, map-reduce). При определении размера чанков старайтесь соблюдать границы содержимого — абзацы, разделы или главы. Чанкинг также помогает обойти ограничения на длину выхода. Разбивая задачу на части, выход каждой части может оставаться в пределах лимитов.
Общие рекомендации
Важно понимать, почему размер чанка влияет на результаты. Больший чанк означает, что модель должна рассуждать над бо́льшим объёмом информации за раз — по сути, бо́льшая когнитивная нагрузка. У LLM ограничена способность удерживать и сопоставлять детали в длинном тексте. Если упаковать слишком много, модель может отдать приоритет определённым частям (обычно началу или концу) и упустить или «забыть» детали в середине. Это может привести к слишком обобщённым резюме или пропущенным фактам. Напротив, мелкий чанк ограничивает задачу: модель может уделить полное внимание этому фрагменту. Вы обмениваете глобальный контекст на локальный фокус.
Никакое эмпирическое правило не может идеально определить лучший размер чанка для вашего сценария — нужно проверять экспериментами. Оптимальный размер чанка может варьироваться в зависимости от домена и модели. Я рассматриваю размер чанка как гиперпараметр для настройки.
В: Как отлаживать многоходовые разговорные трейсы?
Начните просто. Проверьте, достигнут ли в ходе разговора цель пользователя, — бинарным суждением «пройдено/не пройдено». Просмотрите весь трейс и сосредоточьтесь на первом сбое в цепочке. Сначала прочитайте части, видимые пользователю, чтобы понять, пошло ли что-то не так. И только потом углубляйтесь в технические детали — вызовы инструментов и промежуточные шаги.
Логирование трейсов для мультиагентных систем
Для мультиагентных потоков присвойте каждому запросу пользователя идентификатор сессии или трейса и логируйте каждое сообщение с указанием его источника (какой агент или инструмент), 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, наш замечательный TA.↩︎ Paul Graham, «Writes and Write-Nots»↩︎ Shreya Shankar и др., «Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences»↩︎