Это саммари подкаста Ленни Рачицкого с Хамилем Хусейном и Шреей Шанкар. Ниже — пошаговый процесс проведения оценки качества AI-продукта.
Мы живем в эпоху, когда топ-менеджеры Anthropic и OpenAI называютеvals(оценка качества AI-продукта) самым важным навыком для продакт менеджеров. Два года назад никто не знал этого слова, а сегодня это новая нефть в мире LLM.
Что такое Evals простыми словамиEvals (от evaluations — оценка)— это системный подход к измерению и улучшению AI-продуктов. Если по-простому, это "тесты", которые помогают понять, насколько хорошо ваша нейросеть делает свою работу.Почему нельзя просто взять и протестировать LLM как обычную функцию?В обычном программировании мы пишемassert a == b. В мире LLM так не работает, потому что нейросеть — стохастическая. Она может ответить на один и тот же вопрос десятью разными способами. Вы не можете написать "ожидаю точный ответ 42".Главная проблема, которую решают Evals:Без Evals:кажется, после нового промпта бот стал лучше… или нет? Хз, выкатим и посмотрим. (Это называется "вайб-кодинг" или гадание на кофейной гуще).С Evals:запустил набор из 200 тестов. До фикса проходимость была 40%, после — 85%. Можно релизить.Два главных типа Evals:Code-based(с кодом): дешево и сердито. Проверить, что ответ — это JSON, не содержит мата, короче 1000 символов.LLM-as-a-Judge(LLM как судья): когда сложно проверить кодом (например, был ли бот достаточно вежлив?). Вы берете другую нейросеть и просите ее оценить первую. Главное правило: судья должен отвечать только "Да/Нет" (бинарно).Короче:Evals — это способ перестать молиться на нейросеть и начать управлять ее качеством с помощью данных. Это самый высокооплачиваемый навык в AI-разработке сегодня.
Часть 1. Что такое Eval? Спойлер: это не просто юнит-тесты
Заблуждение:Eval — это написание тестов для AI (какassert equals).Реальность:Eval — это системный подход к измерению и улучшению AI-приложения.
Если говорить просто: в обычной разработке мы пишем юнит-тесты. В AI всё сложнее. LLM — стохастическая штука. Вы не можете просто написать "функция должна вернуть 42". AI либо галлюцинирует, либо отвечает грубо, либо залипает в диалоге.
Eval — это дата-аналитика вашего LLM-приложения.Это способ перестать гадать (Кажется, стало лучше?) и начать измерять.
Кейс: Real Estate AI Assistant
Представьте AI-ассистента для аренды квартир (компанияNurture Boss). Он общается в чате, звонит, использует RAG (поиск по БД), вызывает разные тулзы (API для записи на просмотр). Как понять, что он плох? Без Evals вы просто фиксите промпт и молитесь. С Evals — вы смотрите на логи цепочек событий.
Совет от профи:не бегите сразу писать LLM-as-a-Judge. Сначала —анализ ошибок.
Часть 2. Анализ ошибок: скучная работа, без которой ничего не работает
Хамиль демонстрирует, как реально выглядят логи AI-ассистента для аренды квартир. Пользователь спрашивает про 1-комнатную квартиру. AI отвечает: "Нету, до свидания". Вопрос: это ошибка?
- Формально: AI сказал правду (квартиры нет).
- По сути (продуктовая логика) — это потеря лида. Надо было передать диалог человеку.
Варианты как делать проверку:
- Open Coding (Ручной анализ).Вы просто смотрите логи цепочек событий и пишете заметки: "Плохо", "Галлюцинация про виртуальный тур," "Завис в цикле", и тд.Миф №1: "Давайте попросим LLM сделать это за нас".Ответ на миф: Нет. У LLM нет вашего контекста продукта. Она увидит вежливый ответ для пользователя “Спасибо” и скажет “Все ок”. А вы, как продакт, поймете, что это тупик.
- Бенедиктивный диктатор. Назначьте одного человека (продакта или эксперта домена), который обладает контекстом, чуйкой и принимает решения. Не создавайте комитет.
- Теоретическое насыщение.Вы анализируете логи цепочек событий, пока не перестанете видеть новые типы ошибок. Обычно это около 100 примеров. Это звучит страшно, но как только вы сделаете 20 — остановиться будет невозможно (это затягивает как игра).
- Axial Coding (Кластеризация).У вас есть куча заметок на основе ручного анализа логов цепочек событий (open coding) и теперь вы можете попросить LLM сгруппировать их:Проблемы с переходом к человеку (handoff)— 45 случаев.Проблемы с конвейером текста (сломал верстку SMS)— 17 случаев.Галлюцинации (нет услуги, а AI говорит, что есть)— 10 случаев.
Как итог, из хаоса вы получаете датафрейм с приоритетами и теперь вы знаете, что убивает ваш продукт.
Часть 3. LLM-as-a-Judge: когда автоматизация неизбежна
Допустим, проблемаHandoff(передача пользователю ответа) возникает часто, но она не очевидна для кода. Вы не можете написатьif "transfer" in message— это ненадежно.
Решение: LLM как судья.
Главное правило бинарности:судья должен отвечать только "Провал" или "Успех" (True/False). Шкалы 1–7 — это зло.
Промпт для судьи (пример):
Оцени, должен ли был AI передать диалог человеку. Верни True, если:Пользователь прямо попросил “позвать менеджера”.AI не нашел данных в тулзе (API) и при этом не предложил альтернативу.Пользователь спрашивает о ценах “со скидкой для своих”, что требует гибкости человека.
Золотое правило:никогда не доверяйте LLM-судье сразу.
Валидация судьи:вы берете 100 размеченных вами примеров (вы делали это на шаге Open Coding) и прогоняете через судью. СчитаетеConfusion Matrix.
- Если судья говорит "Fail", а вы сказали "Pass" (False Positive) — плохо.
- Если судья говорит "Pass", а вы "Fail" (False Negative) — еще хуже.
Подводный камень:простая метрикаAccuracy(90%) опасна, если ошибка редкая (10%). Судья может просто всегда говорить "Ок" (True) и иметь 90% Accuracy, будучи бесполезным. Смотрите наPrecisionиRecallконкретных классов.
Часть 4. Evals vs. Vibe Coding
Недавно инженер Claude Code сказал:"Мы не делаем Evals, у нас вайб-кодинг".Это вызвало скандал. То есть, если вайбкодить, то делать оценку не надо?
Мнение Хамиль и Шрея:
- Контекст решает всёРазработчики используют AI для кода. Они сами — доменные эксперты. Инженер видит сгенерированный код и мгновенно понимает, какашка это или нет (dogfooding). Для юриста или врача такой "вайб" не прокатит — они не сидят часами, потребляя галлюцинации.
- Семантическая ловушкаНа самом деле, даже Claude Code основан на Evals. Фундаментальные модели обучены и оттестированы на бенчмарках. А когда инженер говорит "мне не нравится этот код" — он неявно проводит тот самый анализ ошибок.
Вывод:вайб-кодинг — это не отсутствие Evals, это сокращенный цикл обратной связи для очень специфичной аудитории (разработчики). Для всех остальных — нужны четкие метрики.
Часть 5. Практические советы: ROI и инструментарий
Главный совет:не стремитесь к совершенству. Цель —Actionable Improvement(улучшить продукт здесь и сейчас).
Как долго это занимает?
- Первая итерация (Анализ ошибок):3-4 дня. Вы смотрите логи цепочек событий и кластеризуете.
- Далее:30 минут в неделю. Вы прогоняете судей на новых данных (например, cron job раз в неделю по семплу из 1000 логов цепочек событий).
Совет:не ждите, что готовый инструмент сделает всё за вас. Хамиль показывает, что лучшие команды пишут свои тулзы под конкретный продукт (используя Cursor или Claude Code за пару часов). Зачем? Чтобы устранить всё, что замедляет или раздражает при просмотре логов. Например, скрыть системный промпт по умолчанию (не отвлекает), подсветить ошибки красным (сразу видно проблему), добавить кнопку "Добавить в eval" (один клик вместо пяти). Без таких важных улучшений люди часто устают и забрасывают анализ ошибок, но анализ ошибок — это самый высокоокупаемый процесс в AI-разработке.
Миф №2:У нас есть A/B тесты, зачем нам Evals?Ответ на миф:A/B тест — это тоже форма Eval. Но A/B тест отвечает на вопрос "Какая версия лучше по метрике?". А анализ ошибок отвечает на вопрос "Почемуикакие именно сценарии сломаны". Делать A/B тесты без предварительного анализа ошибок — стрелять из пушки по воробьям.
Итог: рождение новой PRD
Самое красивое, что показали в подкасте —Evals как новая форма PRD(Product Requirements Document).
Традиционный PRD:система должна вежливо отвечать и не галлюцинировать.Eval (LLM-as-a-Judge):жесткий набор правил (True/False), который выводится из реальных данных. Вы не просто говорите "будь вежлив", вы учите судью отличать вежливый отказ от бесполезного спама.
Когда вы интегрируете этого судью в CI/CD, вы получаетеживой документ, который защищает ваш продукт от регрессов так же, как юнит-тесты защищают бэкенд.
Вывод:Evals — это скучно? Нет. Это самая интересная и высокооплачиваемая роль в AI сегодня. Вы просто смотрите на диалоги вашего бота, ругаетесь на него, фиксите и смотрите, как цифры падают (или растут). Попробуйте, и вы не сможете остановиться.
