Building eval systems that improve your AI product

Построение систем оценки, которые улучшают ваш AI-продукт

Практическое руководство: как выйти за рамки обобщённых метрик и измерять то, что действительно важно

👋 Каждую неделю я разбираю вопросы читателей о создании продуктов, стимулировании роста и ускорении карьеры. Годовые подписчики получают бесплатный год доступа к 15+ премиальным продуктам: Lovable, Replit, Bolt, n8n, Wispr Flow, Descript, Linear, Gamma, Superhuman, Granola, Warp, Perplexity, Raycast, Magic Patterns, Mobbin и ChatPRD (пока есть в наличии).

Дополнительно: Lennybot | Подкаст Lenny | How I AI | Lenny's Reads | Курсы

Онлайн-курс Hamel Husain и Shreya Shankar — AI Evals for Engineers & PMs — занимает первое место по выручке на Maven и неизменно привлекает крупные группы студентов из всех ведущих AI-лабораторий. Причина в том, что они учат критически важному навыку: как строить системы оценки, которые действительно улучшают ваш продукт, а не просто генерируют красивые дашборды.

За последние два года Hamel и Shreya сыграли ключевую роль в превращении evals из малопонятной, запутанной темы в один из самых необходимых навыков для создателей AI-продуктов.

Обучив более 2 000 PM-ов и инженеров, а также руководителей в более чем 500 компаниях, они теперь делятся своим полным руководством — той же методологией, которую преподают в OpenAI, Anthropic и других ведущих лабораториях. Вы узнаете, как использовать анализ ошибок, чтобы понять, где ваш AI-продукт ломается, как строить надёжные evals, которым можно доверять, и как создать маховик непрерывного улучшения, который ловит регрессии до того, как они попадут в продакшен.

По случаю этой публикации Hamel и Shreya предлагают эксклюзивную скидку на курс: 35%. Это самая большая скидка, которую они когда-либо давали. Зарегистрируйтесь по этой ссылке (или используйте код LENNYSLIST при оформлении). У вас осталось три дня для записи.

Спасибо, что делитесь с нами этим ценнейшим материалом, Hamel и Shreya 🙏

Пост Aman Khan об evals прекрасно объяснил, почему оценка становится ключевым навыком, определяющим успех или неудачу продуктовых менеджеров. Данная статья — следующий шаг: руководство по построению системы оценки, которая приводит к реальным улучшениям продукта. Многие команды создают дашборды с eval-метриками, которые выглядят полезно, но в итоге игнорируются и не ведут к улучшению продуктов, потому что метрики этих оценок оторваны от реальных проблем пользователей.

Это руководство описывает процесс, позволяющий преодолеть разрыв доверия. Мы рассмотрим три фазы: выявление того, что измерять, через тщательный анализ ошибок; построение надёжного набора оценок; и операционализацию этого набора для создания маховика непрерывного улучшения.

Фаза 1: Привяжите evals к реальности с помощью анализа ошибок

Прежде чем улучшать AI-продукт, нужно понять, как именно он ломается. Пространство того, что можно оценивать, бесконечно. Самая распространённая ошибка — начать с измерения готовых, модных метрик вроде «галлюцинаций» или «токсичности». Такой подход часто приводит к отслеживанию показателей, которые не коррелируют с реальными проблемами, с которыми сталкиваются пользователи вашего продукта. Невозможно понять, что измерять, пока вы систематически не выясните, как именно ваш продукт ломается в конкретных контекстах. Процесс, который показывает, на чём сосредоточиться, называется «анализ ошибок» и должен завершаться чистым, приоритизированным списком наиболее частых режимов отказа вашего продукта.

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

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

Когда датасет готов, анализ начинается с открытого кодирования. По сути, это похоже на ведение журнала, но с некоторой структурой. Доменный эксперт просматривает каждое взаимодействие с пользователем и пишет свободную критику всего, что кажется неправильным или нежелательным, а также выставляет бинарную оценку «зачёт/незачёт» по работе AI.

Для зачётов мы объясняем, почему AI успешно удовлетворил основную потребность пользователя, даже если были критические аспекты, которые можно улучшить. Мы выделяем эти области для доработки, обосновывая при этом общую положительную оценку.

Для незачётов мы определяем критические элементы, которые привели к неудаче, объясняя, почему AI не выполнил основную задачу пользователя или скомпрометировал важные факторы — такие как пользовательский опыт или безопасность.

Вот скриншот открытого кодирования в действии на примере ассистента по аренде квартир. В интерфейсе видно, что AI выдумал виртуальный тур, хотя такой услуги не существует:

Как эвристика: критика должна быть достаточно подробной, чтобы новый сотрудник вашей компании мог её понять. Или, если так удобнее, чтобы вы могли использовать её как few-shot пример в промпте для LLM-судьи. Излишняя краткость — распространённая ошибка. Вот несколько хороших примеров открытого кодирования:

Обратите внимание, что примеры взаимодействий пользователя с AI упрощены для краткости — но для вынесения суждения вам может потребоваться дать доменному эксперту больше контекста. Подробнее об этом далее.

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

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

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

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

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

Конечный продукт этой фазы — простой подсчёт категорий, чтобы понять, куда инвестировать время. Вот как выглядит такой подсчёт для ассистента по аренде квартир — я рассчитал его с помощью сводной таблицы в электронной таблице:

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

Предостережение о готовых метриках

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

Фаза 2: Создание набора оценок

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

Выбор инструментов сводится к одному вопросу для каждого приоритизированного режима отказа из вашего списка: является ли этот сбой объективным и основанным на правилах (например: «Содержит ли вывод идентификатор пользователя?»), или он субъективен и требует суждения (например: «Был ли тон уместным для данного персонажа?»)?

Для объективных сбоев используйте оценщики на основе кода. Это простые проверки, написанные как код — наподобие ассертов в юнит-тесте. Они быстрые, дешёвые и детерминированные, что делает их идеальными для проверки таких вещей, как валидность JSON на выходе, наличие обязательного ключевого слова или выполнение без ошибок. Используйте их всякий раз, когда чёткое правило может определить успех или неудачу.

Для субъективных сбоев вам потребуется создать LLM-as-a-judge — LLM-судью, который надёжно оценивает качества, с которыми код справляется плохо: тон, релевантность или качество рассуждений. Это может быть строгий процесс — как и обучение любой LLM — но это единственный способ масштабировать нюансированные и субъективные оценки и в конечном счёте улучшить ваш продукт. Хорошая новость в том, что существует научный подход, позволяющий убедиться, что судья достаточно согласован с вашим видением продукта и критериями успеха.

Методика LLM-as-a-judge

Речь не о написании хитрого промпта. Речь о систематическом процессе привязки суждений LLM к вашей конкретной планке качества. На выходе — LLM, которая даёт бинарную метрику «зачёт/незачёт» для конкретных ошибок. И что ещё важнее — вам нужно доверять этой метрике. Путь к доверию — измерение судьи на размеченном человеком датасете, который вы создаёте. Это включает два шага. Первый — создать датасет, устанавливающий эталонную истину:

1. Установите эталонную истину

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

Задача эксперта — предоставить два элемента для каждого взаимодействия пользователя с AI, сгруппированных по сессиям: бинарное суждение «зачёт/незачёт» и подробную критику. Многие команды испытывают соблазн использовать шкалу Лайкерта от 1 до 5, полагая, что она фиксирует больше нюансов. Это ловушка. Различие между «3» и «4» субъективно и непоследовательно. Бинарные решения заставляют быть чёткими. Результат либо соответствует планке качества, либо нет. Нюансы при этом не теряются — они фиксируются в критике, которая объясняет, почему было принято то или иное решение. Эти критики — секретный ингредиент для создания высокоточного судьи. Рассмотрим, например, этот пример из ранее:

Разумные люди могут расходиться во мнениях о том, является ли это «достаточно хорошим». Тем не менее важно стремиться к тому, чтобы выносить суждение о том, что хорошо и что плохо для вашего продукта. В данном случае мы решили, что это взаимодействие было неудачным.

2. Создайте и валидируйте судью

После того как вы собрали эталонные данные, размеченные вашим доменным экспертом, вы готовы создать и валидировать судью. Не используйте весь датасет для построения и тестирования судьи. Это приводит к переобучению — вы итеративно улучшаете результаты на наблюдаемых примерах, но терпите неудачу на новых, невиданных данных.

Вместо этого разделите эталонные данные на три отдельных набора:

Обучающий набор (10%–20%): Небольшой набор чётких примеров, включая критики эксперта, для использования в промпте судьиНабор для разработки (40%–45%): Более крупный набор для итеративного тестирования и доработки промпта судьиТестовый набор (40%–45%): Отложенный набор, нетронутый в процессе разработки, для финальной, непредвзятой оценки работы судьи

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

Ниже представлена визуализация процесса выравнивания LLM-as-a-judge на высоком уровне.

3. Измеряйте то, что важно: TPR/TNR вместо точности

Типичный импульс — измерить работу судьи одним показателем точности (accuracy), но это может быть опасно обманчивым. Представьте AI-систему, которая успешна в 99% случаев. Судья, который всегда предсказывает «зачёт», будет точен на 99%, но никогда не поймает ни одного сбоя. Это распространённая проблема несбалансированных датасетов, где один исход значительно чаще другого.

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

TPR: Из всех примеров, которые должны получить «зачёт», какой процент судья правильно отметил как «зачёт»?TNR: Из всех примеров, которые должны получить «незачёт», какой процент судья правильно отметил как «незачёт»?

Судья с высоким TPR, но низким TNR хорошо распознаёт успехи, но пропускает сбои. Допустимый компромисс зависит от вашего продукта. Для AI, дающего медицинские рекомендации, ложноотрицательный результат (пропуск опасной рекомендации) обходится гораздо дороже ложноположительного. Для ассистента по креативному письму ложноположительный результат (пометка хорошего ответа как плохого) может быть хуже, поскольку он сдерживает творчество.

Зная TPR и TNR вашего судьи, вы можете даже статистически скорректировать его необработанные оценки, чтобы получить более точную оценку истинной частоты сбоев системы. Например, если судья сообщает о 95% зачётов на 1 000 новых примеров, но вы знаете, что у него 10% вероятность ошибочно пометить сбой как зачёт, вы можете скорректировать эту цифру 95% с учётом известной погрешности судьи. (Математические подробности этой коррекции будут в приложении.)

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

Особенности для конкретных архитектур

Существуют особые соображения и стратегии, которые стоит учитывать при проектировании evals для мультитурновых диалогов, RAG-пайплайнов и агентных рабочих процессов. Рассмотрим каждый из них ниже.

Мультитурновые диалоги

Многие AI-продукты являются разговорными, что создаёт проблему удержания контекста во времени. При оценке диалогов начинайте с самого высокого уровня: достигла ли вся сессия цели пользователя? Это суждение «зачёт/незачёт» на уровне сессии — главный показатель успеха.

Когда диалог проваливается, следующий шаг — изолировать первопричину. Типичная ошибка — предположить, что сбой связан со сложностями диалога. Прежде чем углубляться в мультитурновый анализ, попробуйте воспроизвести сбой в одном обращении. Например, если шоппинг-бот даёт неправильную политику возврата на четвёртом шаге, сначала спросите его напрямую: «Какова политика возврата для продукта X1000?» Если он всё равно ошибается, проблема, скорее всего, в простом пробеле в знаниях или извлечении информации. Если отвечает правильно — вы подтвердили, что сбой связан с диалогом: бот теряет контекст или неверно интерпретирует информацию из предыдущих реплик. Этот диагностический шаг экономит значительное время, разделяя простые пробелы в знаниях и истинные сбои диалоговой памяти.

Retrieval-augmented generation (RAG)

RAG-система — это механизм из двух частей: ретривер находит информацию, а генератор пишет ответ, используя эту информацию. Эти две части могут отказывать независимо, и сквозной показатель корректности не подскажет, какая из них сломалась. Их нужно оценивать по отдельности.

Сначала оцените ретривер. Рассматривайте это как задачу поиска. Для этого вам нужен датасет запросов, сопоставленных с известными правильными документами. Наиболее критичная метрика для RAG — часто recall@k. Она показывает, какой процент всех действительно релевантных документов попал в топ-k результатов, которые извлекает ваша система. Recall первостепенен, потому что если нужная информация не извлечена, у генератора нет шансов дать правильный ответ. Современные LLM на удивление хорошо игнорируют нерелевантный шум в контексте, но они не могут придумать факты из отсутствующей информации.

Значение k — критический параметр настройки, зависящий от вашей задачи. Для простого запроса, требующего одного факта, например «Каков налог на недвижимость для дома по адресу 123 Main St.?», обычно достаточно небольшого k (например, 3–5). Главная цель — убедиться, что единственный правильный документ извлечён. Однако для сложного запроса, требующего синтеза информации из нескольких источников, например «Обобщите последние рыночные тренды для трёхкомнатных домов в центре города», вам потребуется больший k (например, 10–20), чтобы обеспечить генератор достаточным контекстом для формирования исчерпывающего ответа. Хотя recall является приоритетом на этапе начального извлечения, precision@k (доля извлечённых документов, которые релевантны) становится важной в системах со вторым этапом ранжирования, предназначенным для отбора лучших документов для передачи LLM.

Когда ваш ретривер хорошо работает на разнообразном наборе запросов, можно оценить генератор. Здесь вы измеряете прежде всего две вещи. Первая — достоверность (faithfulness): придерживается ли сгенерированный ответ фактов из извлечённого контекста, или он галлюцинирует? Вторая — релевантность ответа: отвечает ли ответ непосредственно на исходный вопрос пользователя? Ответ может быть идеально достоверным по отношению к исходным документам, но при этом не отвечать на запрос пользователя.

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

Агентные рабочие процессы

Агенты — которые могут выполнять последовательность действий, таких как вызовы инструментов, для достижения цели — являются самыми сложными системами для оценки. Одно суждение «зачёт/незачёт» по конечному результату — хорошее начало, но оно не диагностично. Когда агент терпит неудачу, нужно знать, какой именно шаг в цепочке рассуждений сломался.

Для этого матрица отказов переходов — незаменимый инструмент. Представьте рабочий процесс агента как серию состояний или шагов, наподобие конвейера. Агент переходит из одного состояния (например, generating_sql) в следующее (например, executing_sql). Матрица отказов переходов — это таблица, которая показывает, где именно конвейер чаще всего ломается.

Строки матрицы представляют последний успешный шаг, а столбцы — шаг, на котором произошёл сбой. Анализируя трейсы неудачных взаимодействий с агентом и нанося их на эту матрицу, вы можете быстро выявить «горячие точки». Вместо угадывания вы видите по данным, что, например, ваш агент чаще всего ломается при попытке выполнить только что сгенерированный SQL или при неверной интерпретации результата вызова инструмента. Это превращает непосильную задачу отладки сложного агента в сфокусированное, основанное на данных расследование.

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

Фаза 3: Операционализация evals для непрерывного улучшения

Этот пост доступен только платным подписчикам