В современной индустрии искусственного интеллекта на смену «интуитивной» разработке приходит строгая методология. Хамель Хусейн и Шрейя Шанкар в беседе с Ленни Рачицким доказывают, что создание систем оценки (Evals) стало самым высокорентабельным навыком для создателей ИИ-продуктов. В этом материале — подробный разбор того, как перестать полагаться на «вайб-чеки» и перейти к системному улучшению ИИ-агентов через анализ ошибок и автоматизированных судей.
🎯 Что такое эвалы и почему они важнее юнит-тестов 5:43
Эвалы (evals) — это способ систематического измерения и улучшения ИИ-приложений . По определению Хамеля Хусейна, это не просто тестирование, а полноценная аналитика данных в контексте больших языковых моделей (LLM). В отличие от традиционной разработки ПО, где поведение системы предсказуемо, ИИ-агенты работают в стохастической среде с огромной поверхностью атаки и неочевидными сценариями сбоев.
Шрейя Шанкар подчеркивает разницу между эвалами и привычными юнит-тестами:
- Юнит-тесты проверяют жесткую, не подлежащую обсуждению функциональность .
- Эвалы измеряют качество работы в условиях неопределенности: как агент реагирует на двусмысленные запросы пользователей или справляется с новыми распределениями данных .
Главная проблема современного ИИ-билдинга — зависимость от «вайб-чеков» (vibe checks), когда разработчик просто прогоняет пару запросов и субъективно оценивает ответ как «нормальный» . По мнению экспертов, такой подход становится неуправляемым при росте приложения . Эвалы же позволяют создать сигнал обратной связи, на основе которого можно проводить контролируемые эксперименты.
🛠 Анализ ошибок: с чего начинается создание ИИ-продукта 10:58
В качестве живого примера Хамель Хусейн демонстрирует работу ИИ-ассистента для управляющих недвижимостью компании Nurture Boss . Приложение помогает обрабатывать лиды, бронировать встречи и отвечать на вопросы жильцов через чат, текст и голос.
Процесс создания эвалов начинается не с написания кода, а с анализа ошибок (Error Analysis). Хусейн показывает работу в инструменте обсервабильности Brain Trust (также упоминаются аналоги: Phoenix Arise, LangSmith) :
- Просмотр трейсов (Traces): Изучение полной цепочки событий — от системного промпта до вызова инструментов (tool calls) и финального ответа .
- Выявление скрытых проблем: Например, пользователь спрашивает о наличии однокомнатной квартиры с кабинетом. ИИ отвечает, что такой нет, и прощается. С точки зрения логики LLM — ответ верный, но с точки зрения продукта — это провал, так как агент должен был предложить альтернативу или передать диалог человеку .
- Фиксация галлюцинаций: В одном из примеров ИИ предложил виртуальный тур, хотя компания его не проводит . Без внимательного чтения логов такие ошибки невозможно заметить .
По словам Шрейи Шанкар, попытка автоматизировать этот этап с помощью другого ИИ — главная ошибка новичков . LLM без контекста бизнеса часто оценивает плохие с точки зрения продукта ответы как «хорошие» .
👑 Концепция «Благосклонного диктатора» и открытое кодирование 25:29
Хамель Хусейн ввел термин «Благосклонный диктатор» (Benevolent Dictator) для описания процесса принятия решений в эвалах .
- Суть: Команды часто тонут в согласованиях критериев оценки всей комиссией. Вместо этого нужно назначить одного человека с глубокой экспертизой в предметной области (часто это продакт-менеджер), чей вкус станет эталоном .
- Открытое кодирование (Open Coding): Это процесс ручного написания заметок к трейсам в свободной форме (например, «ответ звучит дергано» или «не предложил альтернативу») .
Эксперты рекомендуют просмотреть вручную минимум 100 трейсов . Это создает «теоретическое насыщение» — момент, когда вы перестаете встречать новые типы ошибок .
📊 Аксеальное кодирование: как превратить хаос в метрики 31:40
После того как собраны сотни ручных заметок, в игру вступает ИИ для их синтеза. Этот процесс называется аксеальным кодированием (Axial Coding) .
- Категоризация: Все разрозненные заметки (опен-коды) загружаются в LLM (например, в Claude или ChatGPT) с промптом сгруппировать их в категории .
- Создание таксономии ошибок: В примере Nurture Boss выделились такие категории: проблемы с передачей диалога человеку, ошибки форматирования, невыполненные обещания перезвонить .
- Количественный анализ: С помощью сводных таблиц (Pivot Tables) подсчитывается частота каждой категории .
Этот этап позволяет приоритизировать работу: если 70% жалоб связаны с «дерганым» потоком сообщений в SMS, именно это нужно исправлять в первую очередь, а не заниматься «галлюцинациями», которые случаются в 2% случаев .
⚖️ LLM как судья: автоматизация субъективного качества 48:38
Когда ключевые типы ошибок определены, разработчики создают LLM-судью (LLM as a Judge). Это специальный промпт для модели, которая будет автоматически помечать наличие конкретной ошибки в новых диалогах .
Ключевые принципы хорошего LLM-судьи:
- Бинарная оценка: Судья должен отвечать только «Да» или «Нет» (True/False) . По мнению Хусейна, шкала от 1 до 5 — это «трусливый способ уйти от принятия решения», который делает метрики нечитаемыми (никто не понимает разницу между 3.2 и 3.7) .
- Узкая специализация: Один судья — на один конкретный тип ошибки (например, только на «ошибки передачи диалога») .
- Валидация валидатора: Шрейя Шанкар представила исследование «Who Validates the Validator?», в котором доказывается, что критерии «хорошего» ответа постоянно дрейфуют по мере того, как человек изучает данные . Поэтому промпт судьи нужно постоянно калибровать, сравнивая его решения с решениями «благосклонного диктатора» через матрицу путаницы (confusion matrix) .
⚔️ Дебаты об эвалах: Anthropic против системного подхода 1:10:04
В сообществе ИИ разгорелись споры после того, как инженеры Claude Code (инструмент от Anthropic) заявили, что они «не делают эвалы, а просто полагаются на вайбы» .
Шрейя Шанкар и Хамель Хусейн скептически относятся к таким заявлениям, выдвигая свои контраргументы:
- Фундамент: Команды прикладных инструментов стоят на плечах исследователей базовых моделей, которые прогнали тысячи бенчмарков (MMLU, HumanEval) .
- Скрытая работа: Под «вайбами» топ-инженеры часто подразумевают очень глубокий, но не формализованный анализ ошибок, который они делают в силу своей сверхвысокой квалификации .
- Специфика кода: В разработке ИИ-инструментов для написания кода сам разработчик является доменным экспертом. Он может «собачиться» (dogfooding) на своем продукте весь день . Для медицинских или юридических ИИ такой подход невозможен — там нужны строгие внешние эвалы .
🚀 Бизнес-эффект и роль OpenAI 1:20:15
Обсуждая недавнее приобретение компании Statsig (платформа для A/B тестирования) гигантом OpenAI, спикеры сошлись во мнении, что это подтверждает важность дата-центричного подхода . Эвалы становятся частью A/B тестов в продакшене.
По прогнозу Шрейи Шанкар, в ближайшее время фокус сместится с общих бенчмарков (как модель решает задачи по математике) на продуктовые метрики . Главный ROI эвалов — это возможность быстро находить и исправлять «песчаные» ошибки, которые мешают удержанию пользователей .
Основные советы для тех, кто начинает путь в эвалах:
- Не бойтесь данных: 3–4 дня ручного анализа в начале пути экономят месяцы бесцельной правки промптов .
- Используйте AI-ассистентов: Инструменты вроде Cursor или Claude Code отлично подходят для написания кода самих эвалов и промптов судей .
- Итерация, а не совершенство: Цель — не построить идеальную систему тестирования, а внести полезные изменения в продукт .
