# Хамель Хусейн: «Эвалы — это самый высокорентабельный навык в разработке ИИ»

Источник: https://www.youtube.com/watch?v=BsWxPI9UM4c
Канал: Lenny's Podcast
Опубликовано: 25.09.2025

---

В современной индустрии искусственного интеллекта на смену «интуитивной» разработке приходит строгая методология. Хамель Хусейн и Шрейя Шанкар в беседе с Ленни Рачицким доказывают, что создание систем оценки (Evals) стало самым высокорентабельным навыком для создателей ИИ-продуктов. В этом материале — подробный разбор того, как перестать полагаться на «вайб-чеки» и перейти к системному улучшению ИИ-агентов через анализ ошибок и автоматизированных судей.

## 🎯 Что такое эвалы и почему они важнее юнит-тестов
[[JUMP:05:43]]

Эвалы (evals) — это способ систематического измерения и улучшения ИИ-приложений [05:43]. По определению Хамеля Хусейна, это не просто тестирование, а полноценная аналитика данных в контексте больших языковых моделей (LLM). В отличие от традиционной разработки ПО, где поведение системы предсказуемо, ИИ-агенты работают в стохастической среде с огромной поверхностью атаки и неочевидными сценариями сбоев.

Шрейя Шанкар подчеркивает разницу между эвалами и привычными юнит-тестами:

*   **Юнит-тесты** проверяют жесткую, не подлежащую обсуждению функциональность [08:50].
*   **Эвалы** измеряют качество работы в условиях неопределенности: как агент реагирует на двусмысленные запросы пользователей или справляется с новыми распределениями данных [09:03].

Главная проблема современного ИИ-билдинга — зависимость от «вайб-чеков» (vibe checks), когда разработчик просто прогоняет пару запросов и субъективно оценивает ответ как «нормальный» [07:04]. По мнению экспертов, такой подход становится неуправляемым при росте приложения [07:17]. Эвалы же позволяют создать сигнал обратной связи, на основе которого можно проводить контролируемые эксперименты.

## 🛠 Анализ ошибок: с чего начинается создание ИИ-продукта
[[JUMP:10:58]]

В качестве живого примера Хамель Хусейн демонстрирует работу ИИ-ассистента для управляющих недвижимостью компании **Nurture Boss** [11:12]. Приложение помогает обрабатывать лиды, бронировать встречи и отвечать на вопросы жильцов через чат, текст и голос.

Процесс создания эвалов начинается не с написания кода, а с **анализа ошибок (Error Analysis)**. Хусейн показывает работу в инструменте обсервабильности **Brain Trust** (также упоминаются аналоги: **Phoenix Arise**, **LangSmith**) [12:57]:

1.  **Просмотр трейсов (Traces):** Изучение полной цепочки событий — от системного промпта до вызова инструментов (tool calls) и финального ответа [13:50].
2.  **Выявление скрытых проблем:** Например, пользователь спрашивает о наличии однокомнатной квартиры с кабинетом. ИИ отвечает, что такой нет, и прощается. С точки зрения логики LLM — ответ верный, но с точки зрения продукта — это провал, так как агент должен был предложить альтернативу или передать диалог человеку [18:48].
3.  **Фиксация галлюцинаций:** В одном из примеров ИИ предложил виртуальный тур, хотя компания его не проводит [23:04]. Без внимательного чтения логов такие ошибки невозможно заметить [24:37].

По словам Шрейи Шанкар, попытка автоматизировать этот этап с помощью другого ИИ — главная ошибка новичков [24:50]. LLM без контекста бизнеса часто оценивает плохие с точки зрения продукта ответы как «хорошие» [24:23].

## 👑 Концепция «Благосклонного диктатора» и открытое кодирование
[[JUMP:25:29]]

Хамель Хусейн ввел термин **«Благосклонный диктатор» (Benevolent Dictator)** для описания процесса принятия решений в эвалах [25:29].

*   **Суть:** Команды часто тонут в согласованиях критериев оценки всей комиссией. Вместо этого нужно назначить одного человека с глубокой экспертизой в предметной области (часто это продакт-менеджер), чей вкус станет эталоном [26:21].
*   **Открытое кодирование (Open Coding):** Это процесс ручного написания заметок к трейсам в свободной форме (например, «ответ звучит дергано» или «не предложил альтернативу») [32:44].

Эксперты рекомендуют просмотреть вручную минимум **100 трейсов** [29:54]. Это создает «теоретическое насыщение» — момент, когда вы перестаете встречать новые типы ошибок [30:32].

## 📊 Аксеальное кодирование: как превратить хаос в метрики
[[JUMP:31:40]]

После того как собраны сотни ручных заметок, в игру вступает ИИ для их синтеза. Этот процесс называется **аксеальным кодированием (Axial Coding)** [33:53].

1.  **Категоризация:** Все разрозненные заметки (опен-коды) загружаются в LLM (например, в **Claude** или **ChatGPT**) с промптом сгруппировать их в категории [34:57].
2.  **Создание таксономии ошибок:** В примере Nurture Boss выделились такие категории: проблемы с передачей диалога человеку, ошибки форматирования, невыполненные обещания перезвонить [41:09].
3.  **Количественный анализ:** С помощью сводных таблиц (Pivot Tables) подсчитывается частота каждой категории [45:01].

Этот этап позволяет приоритизировать работу: если 70% жалоб связаны с «дерганым» потоком сообщений в SMS, именно это нужно исправлять в первую очередь, а не заниматься «галлюцинациями», которые случаются в 2% случаев [46:08].

## ⚖️ LLM как судья: автоматизация субъективного качества
[[JUMP:48:38]]

Когда ключевые типы ошибок определены, разработчики создают **LLM-судью (LLM as a Judge)**. Это специальный промпт для модели, которая будет автоматически помечать наличие конкретной ошибки в новых диалогах [51:13].

Ключевые принципы хорошего LLM-судьи:

*   **Бинарная оценка:** Судья должен отвечать только «Да» или «Нет» (True/False) [52:33]. По мнению Хусейна, шкала от 1 до 5 — это «трусливый способ уйти от принятия решения», который делает метрики нечитаемыми (никто не понимает разницу между 3.2 и 3.7) [52:47].
*   **Узкая специализация:** Один судья — на один конкретный тип ошибки (например, только на «ошибки передачи диалога») [51:01].
*   **Валидация валидатора:** Шрейя Шанкар представила исследование «Who Validates the Validator?», в котором доказывается, что критерии «хорошего» ответа постоянно дрейфуют по мере того, как человек изучает данные [1:03:19]. Поэтому промпт судьи нужно постоянно калибровать, сравнивая его решения с решениями «благосклонного диктатора» через матрицу путаницы (confusion matrix) [1:00:19].

## ⚔️ Дебаты об эвалах: Anthropic против системного подхода
[[JUMP:1:10:04]]

В сообществе ИИ разгорелись споры после того, как инженеры **Claude Code** (инструмент от **Anthropic**) заявили, что они «не делают эвалы, а просто полагаются на вайбы» [1:12:41].

Шрейя Шанкар и Хамель Хусейн скептически относятся к таким заявлениям, выдвигая свои контраргументы:

1.  **Фундамент:** Команды прикладных инструментов стоят на плечах исследователей базовых моделей, которые прогнали тысячи бенчмарков (MMLU, HumanEval) [1:12:14].
2.  **Скрытая работа:** Под «вайбами» топ-инженеры часто подразумевают очень глубокий, но не формализованный анализ ошибок, который они делают в силу своей сверхвысокой квалификации [1:13:32].
3.  **Специфика кода:** В разработке ИИ-инструментов для написания кода сам разработчик является доменным экспертом. Он может «собачиться» (dogfooding) на своем продукте весь день [1:14:11]. Для медицинских или юридических ИИ такой подход невозможен — там нужны строгие внешние эвалы [1:15:03].

## 🚀 Бизнес-эффект и роль OpenAI
[[JUMP:1:20:15]]

Обсуждая недавнее приобретение компании **Statsig** (платформа для A/B тестирования) гигантом **OpenAI**, спикеры сошлись во мнении, что это подтверждает важность дата-центричного подхода [1:20:15]. Эвалы становятся частью A/B тестов в продакшене.

По прогнозу Шрейи Шанкар, в ближайшее время фокус сместится с общих бенчмарков (как модель решает задачи по математике) на продуктовые метрики [1:21:58]. Главный ROI эвалов — это возможность быстро находить и исправлять «песчаные» ошибки, которые мешают удержанию пользователей [1:30:17].

Основные советы для тех, кто начинает путь в эвалах:

*   **Не бойтесь данных:** 3–4 дня ручного анализа в начале пути экономят месяцы бесцельной правки промптов [1:30:44].
*   **Используйте AI-ассистентов:** Инструменты вроде **Cursor** или **Claude Code** отлично подходят для написания кода самих эвалов и промптов судей [1:41:18].
*   **Итерация, а не совершенство:** Цель — не построить идеальную систему тестирования, а внести полезные изменения в продукт [1:27:01].