Практическое руководство по оценке LLM для разработчиков
Хэмел Хусейн объясняет, как AI-инженеры используют оценки для систематического улучшения качества LLM, переходя от разработки на основе интуиции к анализу ошибок, основанному на данных, и автоматизированному тестированию.
Обзор
- В рассылке The Pragmatic Engineer Гергели Орош и инженер по машинному обучению Хамел Хусейн утверждают, что оценки LLM («evals») становятся важнейшей инфраструктурой для AI-инженеров, позволяющей систематически тестировать и улучшать недетерминированные AI-системы, заменяя «разработку на основе интуиции» повторяемыми инженерными практиками.
- Статья демонстрирует это на примере NurtureBoss, стартапа-помощника по аренде на базе AI, который внедрил систематический рабочий процесс анализа ошибок — изучение следов разговоров, кодирование сбоев по категориям с помощью открытого и осевого кодирования, заимствованного из традиций машинного обучения, а затем создание evals на основе кода для детерминированных проблем, таких как обработка дат, и оценщиков на основе LLM-судей для субъективных решений, таких как передача разговоров.
- Эта методология отражает общеотраслевой сдвиг, поскольку Хусейн обучил более 3000 инженеров из компаний, включая OpenAI, Anthropic и Google, методам оценки, в то время как практики все чаще интегрируют evals в конвейеры CI/CD для выявления регрессий и предотвращения сбоев в продакшене.
В сегодняшнем выпуске мы рассмотрим:
Ловушка разработки Vibe-check. Агент вроде бы работает хорошо, но после внесения изменений становится невозможно убедиться в его корректной работе.
Основной рабочий процесс: анализ ошибок . Анализ ошибок уже несколько десятилетий является ключевой частью машинного обучения и полезен для создания приложений LLM.
Создание оценок: правильные инструменты для работы. Используйте оценки на основе кода для детерминированных сбоев и степень магистра права в качестве судьи для субъективных случаев.
Формирование LLM-судьи. Не позволяйте вашему LLM-судье запоминать ответы, разбивая данные на части и измеряя, насколько хорошо судья обобщает незнакомые данные.
Согласуйте мнение судьи, сохраните доверие. Экспертные знания судьи LLM должны быть подтверждены опытом человека. Рассмотрите такие показатели, как процент истинно положительных результатов (TPR) и процент истинно отрицательных результатов (TNR).
Оценки на практике: от непрерывной интеграции и доставки (CI/CD) до мониторинга производства. Используйте оценки в конвейере CI/CD, но также используйте данные производства для постоянной проверки их корректной работы.
Маховик улучшений. Анализ → измерение → улучшение → автоматизация → начало заново.
1. Ловушка развития Vibe-check
Организации внедряют программы LLM в приложения, от обслуживания клиентов до создания контента. Однако, в отличие от традиционного программного обеспечения, конвейеры LLM не выдают детерминированных результатов; их ответы часто субъективны и зависят от контекста. Ответ может быть фактически точным, но иметь неправильный тон, или звучать убедительно, будучи совершенно неверным. Эта неоднозначность принципиально отличает оценку от традиционного тестирования программного обеспечения. Основная задача — систематически измерять качество наших систем ИИ и диагностировать их сбои.
Недавно я работал с NurtureBoss , стартапом, работающим на основе искусственного интеллекта, который разрабатывает помощника по аренде для управляющих жилыми помещениями. Помощник помогает планировать экскурсии, отвечает на рутинные вопросы арендаторов и занимается продажами. Вот скриншот того, как продукт выглядит для клиентов:
Они создали сложного агента, но процесс разработки был похож на игру в догадки: они меняли подсказку, проверяли несколько входных данных, и если результат «мне нравился» (LGTM), то выпускали его. Это ловушка «разработки на основе ощущений», и именно из-за неё многие проекты ИИ сходят с рельсов.
Чтобы понять, почему это происходит, полезно рассматривать развитие LLM как преодоление трех фундаментальных пробелов, или «пропастей»:
Пропасть понимания: разрыв между разработчиком и истинным пониманием своих данных и поведения модели в масштабе. Невозможно вручную прочитать каждый запрос пользователя и проверить каждый ответ ИИ, чтобы понять тонкие причины сбоя системы.
Разрыв в спецификации: разрыв между тем, что мы хотим , чтобы LLM делал, и тем, что ему фактически предписывают наши подсказки . LLM не умеют читать наши мысли; недостаточно конкретизированная подсказка заставляет их угадывать наши намерения, что приводит к противоречивым результатам.
Залив обобщения: разрыв между хорошо написанными инструкциями и способностью модели надёжно применять эти инструкции ко всем возможным входным данным. Даже с идеальными инструкциями модель может дать сбой на новых или необычных данных.
Преодоление этих трудностей — главная задача инженера ИИ. Именно здесь наивное применение разработки через тестирование (TDD) часто терпит неудачу. TDD работает, потому что для заданных входных данных существует единственный, детерминированный, известный и правильный выход, с которым можно спорить. Но с LLM это не так: попросите ИИ написать электронное письмо, и вы получите не один правильный ответ, а тысячи.
Проблема не только в «бесконечной поверхности» входных данных, но и в обширном пространстве допустимых, субъективных и непредсказуемых результатов. Действительно, вы не сможете проверить правильность, пока не проведёте систематическое исследование всего диапазона возможных результатов и не определите, что вообще означает «хорошо» для вашего продукта.
В этой статье мы подробно рассмотрим прагматичный рабочий процесс, который мы применяем в NurtureBoss и более чем в 40 других компаниях, чтобы перейти от догадок к воспроизводимой инженерной дисциплине. К концу статьи мы пройдём все этапы того, что мы называем «маховиком совершенствования».
2. Основной рабочий процесс: анализ ошибок
Чтобы обойти ловушку LGTM, команда NurtureBoss внедрила новый рабочий процесс, начав с систематического анализа трассировок диалога. Трассировка — это полная запись взаимодействия: первоначальный запрос пользователя, все промежуточные этапы рассуждений LLM, все выполненные вызовы инструментов и окончательный ответ, полученный пользователем. Это всё, что нужно для реконструкции того, что произошло на самом деле. Ниже представлен скриншот того, как может выглядеть трассировка для NurtureBoss:
Существует множество способов просмотра трассировок, в том числе с помощью инструментов наблюдения, специфичных для LLM. Примеры, с которыми я часто сталкиваюсь на практике, — это LangSmith , Arize (на фото выше) и Braintrust .
От сырых заметок к четким приоритетам
Поначалу это был не самый приятный процесс ручного просмотра данных с помощью просмотрщика трассировок. Но по мере того, как Джейкоб, основатель NurtureBoss, просматривал трассировки, трудности стали очевидны. Готовые инструменты для наблюдения, такие как LangSmith, Arize, Braintrust и другие, предлагают неплохие способы быстро начать просмотр данных, но по своей сути являются универсальными. В случае с NurtureBoss просмотр всего необходимого контекста, такого как данные о конкретных объектах и предпочтениях клиента, на одном экране был затруднительным. Это препятствие замедляло работу.
Вместо того, чтобы бороться с инструментами, они потратили несколько часов на написание простого пользовательского просмотрщика данных с использованием ИИ-помощника. Это было несложно, но решило их основные проблемы, наглядно отображая каждый диалог на одном экране, с сворачиваемыми разделами для вызова инструментов и простым текстовым полем для добавления заметок. Ниже представлен скриншот одного из экранов в их просмотрщике данных:
Этот простой инструмент стал настоящим прорывом. Он значительно повысил скорость проверки, позволив команде эффективно обрабатывать сотни трассировок. Благодаря более высокой производительности они начали добавлять заметки открытого формата о любом поведении, которое казалось неправильным, — этот процесс известен как открытое кодирование . При открытом кодировании важно избегать заранее заданных контрольных списков ошибок, таких как «галлюцинации» или «токсичность». Вместо этого позвольте данным говорить самим за себя и записывайте описательные наблюдения, например:
«Агент упустил явную возможность повторно привлечь пользователя, чувствительного к цене».
«Он дважды подряд просил отправить текстовое подтверждение».
«Как только пользователь запросил переключиться на человека, агент продолжал пытаться решить проблему вместо того, чтобы просто осуществить передачу».
После аннотирования десятков разговоров команда NurtureBoss собрала обширную, но беспорядочную коллекцию заметок. Чтобы найти нужный сигнал среди всего этого шума, они сгруппировали эти заметки по темам на этапе, называемом аксиальным кодированием . Степень магистра права (LLM) помогла с первоначальной группировкой открытых кодов по категориям (также известным как аксиальные коды), которые команда затем проанализировала и доработала. Простая сводная таблица показала, что большинство проблем приходилось всего на три проблемы: обработка дат, сбои в передаче данных и проблемы с потоком разговоров. Это позволило определить чёткую, основанную на данных, приоритетность видов сбоев в приложении. Ниже представлен пример того, как может выглядеть частичный вид этой сводной таблицы, представляющий собой подсчёт категорий сбоев:
Этот подход «снизу вверх» — противоядие от проблем, связанных с шаблонными, готовыми метриками. Многие команды поддаются соблазну использовать готовые «баллы галлюцинаций» или оценку «полезности», но, по моему опыту, эти метрики часто оказываются более чем бесполезными. Например, недавно я работал со стартапом в сфере психического здоровья, чья панель оценки была заполнена шаблонными метриками, такими как «полезность» и «фактичность», каждая из которых оценивалась по шкале от 1 до 5. Хотя оценки выглядели впечатляюще, они были бесполезны; команда не могла понять, за что ответ получил оценку «3», а за что — «4», и эти метрики не коррелировали с тем, что действительно было важно для пользователей.
Они создают ложное чувство безопасности, побуждая команды оптимизировать систему, добиваясь результатов, которые на самом деле не коррелируют с удовлетворенностью пользователей. Напротив, позволяя выявлять неисправности на основе собственных данных, вы гарантируете, что ваши усилия по оценке будут сосредоточены на реальных проблемах.
Этот процесс обнаружения ошибок в данных — не новый приём, придуманный для LLM; это проверенная временем дисциплина, известная как анализ ошибок , которая десятилетиями была краеугольным камнем машинного обучения и была адаптирована из строгих качественных методов исследования, таких как обоснованная теория в социальных науках. Далее давайте кратко изложим этот процесс в пошаговое руководство для решения вашей проблемы.
Пошаговое руководство по анализу ошибок
Этот процесс «снизу вверх» — самый высокорентабельный вид деятельности в разработке ИИ. Он гарантирует, что вы решаете реальные проблемы, а не гонитесь за пустыми метриками. Вот как его применять:
- Создайте простой просмотрщик данных. Это ваша самая важная инвестиция. Специальное веб-приложение, адаптированное под ваш домен, позволяет отображать весь необходимый контекст в одном месте и упрощает сбор отзывов.
Открытое кодирование: аннотирование снизу вверх. Открытое кодирование (не путать с программным кодированием) — это метод написания открытых заметок о наблюдаемых проблемах. В контексте LLM вы просматриваете не менее 100 различных трассировок и добавляете открытые заметки о любом нежелательном поведении. При анализе сложной трассировки наиболее эффективная тактика — выявить и аннотировать только первую ошибку на восходящем этапе. Конвейеры LLM — это причинно-следственные системы; одна ошибка на раннем этапе, например, неверное толкование намерения пользователя, часто приводит к каскаду проблем на последующих этапах. Сосредоточение внимания на первой наблюдаемой ошибке более эффективно, поскольку позволяет избежать увязнуть в каталогизации всех симптомов. Зачастую устранение этой единственной проблемы устраняет целую цепочку последующих сбоев.
Осевое кодирование: создайте таксономию. Теперь, когда у вас есть заметки открытого типа из шага 2, пора распределить их по категориям, чтобы понять закономерности. Сгруппируйте свои заметки открытого типа по 5–10 темам. Воспользуйтесь помощью специалиста LLM, чтобы предложить первоначальные кластеры, но всегда привлекайте человека для проверки и уточнения окончательных категорий.
Определите приоритет отказов на основе данных. Используйте простую сводную таблицу или скрипт для подсчёта частоты каждого вида отказов. Это преобразует качественные данные в количественную дорожную карту, показывающую, на чём именно следует сосредоточить инженерные усилия.
На этом этапе часто возникает вопрос: «Что делать, если реальных пользовательских данных для анализа недостаточно?» Именно здесь синтетические данные становятся мощным инструментом. Вы можете использовать мощную программу LLM для генерации разнообразного набора реалистичных пользовательских запросов, охватывающих сценарии и пограничные случаи, которые вы хотите протестировать. Это позволяет инициировать весь процесс анализа ошибок ещё до того, как появится хотя бы один пользователь. Специфика создания высококачественных, обоснованных синтетических данных — это глубокая тема, выходящая за рамки этой статьи.
Ниже представлена диаграмма, иллюстрирующая процесс анализа ошибок:
3. Создание оценок: правильный инструмент для работы
После анализа ошибок команда NurtureBoss получила чёткое, основанное на данных задание исправить обработку дат и передачу данных, основанное на таблице ошибок, представленной выше. Однако это разные типы ошибок: обработка календарных дат — это объективный результат, который можно сравнить с ожидаемым значением, в то время как вопрос о том, когда следует передавать обсуждение человеку, более тонок. Это различие важно, поскольку оно определяет тип создаваемого оценщика. Далее мы рассмотрим два типа оценщиков, которые следует рассмотреть: утверждения на основе кода и судьи LLM.
Для детерминированных сбоев → оценки на основе кода
Запрос пользователя, например, «Можно ли посмотреть квартиру 4 июля 2026 года?», имеет одну — и только одну — правильную интерпретацию. Задача ИИ — извлечь эту дату и преобразовать её в нужный формат для последующего инструмента. Это детерминированная, объективная задача, которая может быть выполнена либо правильно, либо неправильно.
Оценки на основе кода — идеальный инструмент для анализа простых сбоев. Чтобы создать такой инструмент, команда NurtureBoss сначала собрала «золотой набор данных» тестовых случаев. Они провели мозговой штурм, проанализировав множество различных способов, которыми пользователи могут запрашивать даты, сосредоточившись на распространённых закономерностях и сложных пограничных случаях. Целью было создание комплексного набора тестов, способного надёжно выявлять регрессии.
Вот упрощённая версия того, как выглядел их набор данных. Примечание: для относительных дат мы предполагаем, что текущая дата — 28 августа 2025 г.
С этим набором данных процесс оценки прост и аналогичен традиционному модульному тестированию. Вы проходите цикл по каждой строке, передаёте её User Queryв свою систему ИИ, а затем запускаете простую функцию, которая проверяет, соответствует ли извлечённая ИИ датаExpected Output.
Оценки на основе кода дешевле создавать и поддерживать, чем другие виды оценок. Поскольку результат ожидаем, достаточно запустить LLM для генерации ответа, а затем простое утверждение. Это означает, что их можно запускать чаще, чем другие виды оценок (например, при каждом коммите для предотвращения регрессий). Если ошибку можно проверить с помощью кода, всегда используйте оценку на основе кода.
Для субъективных неудач → LLM-как-судья
Но как насчёт более неоднозначной проблемы, например, как определить, когда следует передать разговор человеку? Если пользователь говорит: «Я запутался», следует ли ИИ немедленно передать разговор или сначала попытаться прояснить ситуацию? Однозначного ответа не существует; это вопрос здравого смысла, основанный на философии продукта. Тест на основе кода не может оценить такие нюансы.
Для субъективных сбоев мы создали ещё один золотой набор данных. Джейкоб, эксперт в данной области, основатель NurtureBoss, просмотрел трассировки, где потенциально требовалась передача данных, и вынес вердикт. В каждом случае он предоставил двоичную оценку «ПРОШЕЛ/НЕ ПРОШЕЛ» и, что особенно важно, подробный анализ с объяснением своих доводов.
Вот несколько примеров из их набора данных:
Использование оценки «ПРОШЕЛ/НЕ ПРОШЕЛ» работает лучше, чем балльная оценка. Обратите внимание, что в приведённом выше примере эксперт в предметной области Джейкоб использовал простую оценку «ПРОШЕЛ/НЕ ПРОШЕЛ» для каждой трассы, а не оценку от 1 до 5 баллов. Это был осознанный выбор. Я понял, что, хотя и заманчиво использовать шкалу Лайкерта для учёта нюансов, на практике это создаёт больше проблем, чем решает. Различие между оценками «3» и «4» часто субъективно и непоследовательно у разных рецензентов, что приводит к некорректным и ненадёжным данным.
Напротив, бинарные решения требуют ясности и заставляют эксперта в предметной области определить чёткую границу между приемлемым и неприемлемым, сосредоточившись на том, что действительно важно для успеха пользователей. Кроме того, это гораздо более практично для инженеров: «неудовлетворительно» — это чёткий сигнал к исправлению ошибки, тогда как «3» — неоднозначный сигнал: сигнал к чему именно? Начиная с «прошёл/не прошёл», вы устраняете неоднозначность и быстрее получаете чёткий и действенный показатель качества.
Этот набор данных, содержащий следы, суждения и критические замечания, не просто помогает команде понять проблему. Как мы увидим в следующем разделе, эти вручную размеченные примеры, особенно подробные критические замечания, становятся исходным материалом для создания надёжного эксперта-магистра права.
4. Становление магистра права как судьи
Набор данных об ошибках хэндовера, размеченный вручную, — необходимый первый шаг к измерению и решению проблем хэндовера. Однако другая проблема заключается в том, что ручной анализ не масштабируется. Следующим шагом в NurtureBoss стала автоматизация экспертных знаний эксперта в предметной области путем создания LLM-ассессора: оценщика на основе ИИ, способного последовательно применять свои рассуждения к тысячам будущих трассировок.