Как я измеряю, действительно ли работает AI-агент

Содержание

Обновлено май 2026 г.

TL;DR: Большинство операторов полностью пропускают оценку и просто предполагают, что их агенты работают. Мой фреймворк: создать золотой набор из 5–10 известных входных данных с ожидаемыми результатами, определить критерии прохождения/провала на простом языке и еженедельно проверять логи. Не создавайте сложную систему оценки до того, как у вас будет 10 реальных запусков — это ловушка, которая убивает импульс.

[Взгляд оператора] Я управляю более чем 30 продакшн AI-агентами в рамках своего консалтингового бренда и Pickleland — площадки для пиклбола в Пфлюгервилле, штат Техас. В какой-то момент я понял, что трачу больше времени на беспокойство о дрейфе агентов, чем на их реальное использование. Это тот фреймворк оценки, к которому я пришёл — без PhD, без кастомной платформы оценки, без Python.

Проблема, о которой никто не говорит: агенты тихо дрейфуют

Когда человек-сотрудник начинает делать работу неправильно, вы обычно это замечаете. Когда AI-агент начинает производить мусор, он продолжает производить мусор — тихо, в масштабе, пока что-то не сломается достаточно плохо, чтобы человек наконец посмотрел.

У меня был контент-агент, который после обновления модели начал добавлять оговорки «Как языковая модель ИИ». Был агент-промоутер событий, который перестал включать ссылки на билеты, потому что изменилось имя переменной в промпте. Ни один из них не завалился шумно. Оба просто деградировали.

Решение — не строить систему мониторинга уровня NASA. Нужна простая, воспроизводимая проверка, которая обнаруживает дрейф до того, как он накопится.

Что такое оценка на самом деле (для операторов)

Инженеры используют слово «eval» для запуска бенчмарка на модели. Для операторов я имею в виду что-то проще: воспроизводимый тест, который говорит, делает ли ваш агент то, для чего вы его создали.

Три компонента:

1. Золотой набор — 5–10 реальных входных данных, которые вы уже видели, с ожидаемыми результатами, которые, как вы знаете, являются хорошими
2. Критерии прохождения/провала — правила на простом языке, определяющие, что считается прохождением
3. Запланированная проверка — вы или ваш ассистент фактически запускаете тест с определённой периодичностью

Вот и всё. Вам не нужен фреймворк. Вам нужна дисциплина.

Создание золотого набора

Извлекайте из продакшн-логов. Найдите 5–10 реальных входных данных, для которых вы уже знаете, как выглядит хороший результат. Это ваша базовая истина.

Для моего агента контент-пайплайна золотой набор — это 5 опубликованных постов, которые прошли мой чеклист голоса, когда я писал их вручную. Для промоутера событий Pickleland — 5 прошлых постов в Facebook с выше среднего вовлечённостью (комментарии + репосты, не только лайки).

Правила хорошего золотого набора:

• Реальные входные данные, а не гипотезы, которые вы придумали
• Включите хотя бы один пограничный случай (сложный входной, короткий, с необычным форматированием)
• Документируйте ожидаемые результаты — скриншот, текстовый файл, строка в таблице
• Никогда не удаляйте из золотого набора; только добавляйте

Когда агент последний раз подтверждённо работал хорошо, запишите, как именно выглядело «хорошо». Это становится вашим ожидаемым результатом.

Определение критериев прохождения/провала

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

Записывайте критерии как пункты чеклиста, которые мог бы оценить неспециалист. Вот реальные критерии, которые я использую для агента контент-пайплайна:

Чеклист прохождения/провала контент-агента:

• Пост имеет TL;DR в первых 100 словах
• Нет фраз типа «в современном быстро меняющемся мире» или «Как ИИ»
• Минимум одно конкретное число или статистика
• Количество слов от 800 до 2000
• Все внутренние ссылки работают (нет 404)

Для промоутера событий Pickleland:

Чеклист прохождения/провала промоутера событий:

• Название события совпадает с исходным календарём
• Дата и время правильные
• Ссылка на билеты присутствует и не сломана
• Текст менее 280 слов
• Пост не использует общие фразы-заполнители

Если 4 из 5 пунктов чеклиста прошли, запуск засчитывается. Если 3 или меньше — провал, и я расследую перед следующим запуском.

Использование Claude как судьи

Для агентов с длинными или сложными результатами я использую Claude Sonnet как автоматизированного судью. Это быстрее ручной проверки и обнаруживает вещи, которые я бы пролистал.

Вот промпт судьи, который я использую для контент-агента:

You are evaluating a blog post written by an AI agent. Your job is to check whether it meets the operator's standards.

Evaluate the following post against these criteria:
1. Starts with a direct answer or TL;DR in the first 100 words (YES/NO)
2. Contains at least one concrete number or specific example (YES/NO)
3. Free of AI-speak filler ("As an AI", "in today's fast-paced world", "delve", "it's worth noting") (YES/NO)
4. Word count is between 800 and 2000 words (YES/NO)
5. Tone matches the reference: direct, first-person, opinionated, no fluff (YES/NO)

For each criterion, respond YES or NO with one sentence of explanation.
At the end, output PASS if 4 or 5 criteria are YES, FAIL otherwise.

Post to evaluate:
---
{{post_content}}
---

Я запускаю это как Cloudflare Worker, который забирает последний черновик, запускает этот промпт и записывает результат в Google Sheet. Весь процесс занимает 8 секунд и стоит около $0,003 за запуск.

Для промоутера событий промпт судьи проще:

You are checking an AI-generated Facebook event post for accuracy and quality.

Source data:
- Event name: {{event_name}}
- Date: {{event_date}}
- Time: {{event_time}}
- Ticket URL: {{ticket_url}}

Generated post:
---
{{generated_post}}
---

Check:
1. Does the post correctly state the event name? (YES/NO)
2. Does the post correctly state the date and time? (YES/NO)
3. Does the post include the exact ticket URL? (YES/NO)
4. Is the post under 280 words? (YES/NO)
5. Is the tone inviting without using generic filler phrases? (YES/NO)

Output PASS if all 5 are YES, FAIL if any are NO. List which items failed.

Где смотреть: логи Cloudflare Worker

Если вы запускаете агентов на Cloudflare Workers (что я делаю для большинства лёгких агентов), встроенный log tail — ваш лучший друг. Для начала не нужен сторонний сервис логирования.

Что я проверяю при еженедельных выборочных проверках:

• Ошибки и исключения — всё, что рухнуло или вышло по таймауту
• Количество токенов — если запуск внезапно использует в 3 раза больше обычных токенов, что-то изменилось
• Пики задержки — внезапное замедление обычно означает, что промпт стал длиннее или модель испытывает трудности
• Дрейф длины результата — если средний результат упал с 600 до 200 слов, агент изменил поведение

Я трачу 15 минут каждое утро понедельника на это. У меня есть простой чеклист в Notion: открыть логи для каждого агента, отметить аномалии, сравнить использование токенов с базовым уровнем прошлой недели. Это весь процесс.

Оценка в таблице: некрасиво, но работает

До появления автоматизации я запускал оценки в Google Sheet. Я всё ещё использую это для новых агентов в первые 4 недели.

Структура:

Пять строк в неделю. Занимает 10 минут. Если два провала подряд — останавливайте агента и исправляйте промпт, прежде чем продолжать.

Это позорно низкотехнологично. Именно так я поймал три регрессии промпта, прежде чем они попали в продакшн.

Чего НЕ делать

Не создавайте систему оценки до 10 реальных запусков. Я видел основателей, которые тратили две недели на создание сложного пайплайна оценки для агента, который они запускали лишь дважды. Вы недостаточно знаете, как выглядит «хорошо», пока у вас нет реальных продакшн-данных.

Не оценивайте на синтетических входных данных, которые вы придумали. Синтетические тест-кейсы упускают странные пограничные случаи, которые выдаёт продакшн. Всегда начинайте с реальных логов.

Не оценивайте всё подряд. Выберите 3–5 агентов, провал которых реально навредит — клиентские результаты, всё, что публично постит, всё, что запускает платёж. Пропускайте внутренние утилитарные агенты, пока не будет ресурса.

Не автоматизируйте слишком рано. Таблица, которую вы реально используете, лучше дашборда Datadog, который вы забываете проверять. Начните вручную, автоматизируйте после 10 запусков проверки и понимания, что именно вы ищете.

Вывод оператора

Оценки не обязаны быть инженерного уровня, чтобы быть полезными. Золотой набор из 5–10 реальных входных данных, чеклист критериев прохождения/провала и 15 минут проверки логов каждый понедельник обнаружат 80% дрейфа агентов до накопления. Начните с этого. Если вы всё ещё запускаете агентов без какой-либо оценки, вы летите вслепую — и в конечном счёте что-то провалится достаточно публично, чтобы пожалеть, что не потратили 20 минут.