AI-агента нельзя оценивать по красивому ответу: уроки Google и Cloudflare

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

Две свежие публикации показывают, почему субъективной проверки ответа уже недостаточно. 15 октября Google описал систему оценки AI-агентов по пользовательским сценариям, трассам и проверяемым условиям. 19 октября Cloudflare рассказал, как анализ реальных запусков помог снизить среднюю стоимость собственного AI-ревьюера с 2,43 до 0,77 доллара, а медианное время работы — с 4 минут 9 секунд до 1 минуты 32 секунд.

Для компаний это не только инженерная история. Тот же принцип нужен в GEO: важно проверять не просто то, насколько хорошо звучит AI-ответ, а нашёл ли агент нужную страницу, использовал ли основной canonical, правильно ли извлёк факты и сослался ли на источник.

Что показали Google и Cloudflare

Google начинает с простой проблемы: команды часто проверяют нового агента несколькими запросами в терминале. Если ответы выглядят разумно, систему считают готовой. Но агент отличается от обычной формы или калькулятора. Он сам выбирает последовательность шагов, инструменты и момент завершения, поэтому может ошибиться внутри процесса и всё равно сгенерировать правдоподобный финал.

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

Cloudflare показала практическую сторону такого подхода на AI-ревьюере кода. Компания увидела, что средняя стоимость одной проверки выросла примерно с 1,19 доллара до более чем 2,4 доллара, хотя общая архитектура заметно не менялась. Причина стала видна только после разбора токенов, вызовов моделей, кэша, повторов и качества найденных замечаний.

После оптимизации средняя стоимость снизилась на 68% — до 0,77 доллара. Одновременно сократилось медианное время проверки. При этом Cloudflare отдельно проверяла, не исчезли ли вместе с расходами действительно важные замечания.

Почему красивый ответ скрывает сбои

Финальный текст показывает только последний этап работы. Он не отвечает на несколько важных вопросов:

• сколько раз агент обращался к поиску или API;
• не повторил ли он одно действие из-за неверно обработанного тайм-аута;
• получил ли данные из нужного источника;
• не выбрал ли устаревшую или дублирующую страницу;
• соблюдал ли ограничение по времени и стоимости;
• не выполнил ли внешнее действие дважды;
• можно ли воспроизвести результат на похожем запросе.

Особенно опасны тихие ошибки. Пользователь видит нормальный ответ, но за ним может стоять лишняя отправка формы, повторная запись в CRM, два заказа или неверная ссылка. Если оценивать только стиль текста, такие проблемы попадут в production.

Для контентных и поисковых задач риск похожий. AI может правильно пересказать тему, но сослаться на вторичный агрегатор вместо первоисточника, перепутать дату или объединить сведения с разных страниц. Ответ звучит уверенно, а цепочка доказательств остаётся слабой.

Как Google предлагает оценивать агентов

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

Например, для агента, который готовит отраслевой обзор, недостаточно условия «написал полезный текст». Проверка может включать:

1. нашёл публикации только за заданный период;
2. отделил первичные источники от пересказов;
3. проверил дату события, а не только дату статьи;
4. не приписал новость стране, которой нет в источнике;
5. сохранил точные URL источников;
6. не создал дубль уже опубликованного материала;
7. завершил работу в пределах лимита времени и запросов.

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

Важный совет — по возможности превращать размытые оценки в вопросы с ответом «да» или «нет». Формулировка «насколько ответ полезен по шкале от 1 до 5» нестабильна. Проверка «использовал ли агент официальный источник и указал ли дату» даёт более воспроизводимый сигнал.

Ещё один принцип — не менять набор тестов во время сравнения версий. Если после каждого запуска удалять сложные примеры и добавлять удобные, рост среднего балла ничего не доказывает. Нужен замороженный базовый набор, на котором сравниваются промпты, модели и инструменты.

Что изменила Cloudflare

Кейс Cloudflare показывает, что оптимизация AI-агента начинается с наблюдаемости. Несмотря на высокий процент попаданий в кэш, число токенов на одну проверку выросло примерно с 0,91 до 2,99 миллиона. Высокий cache hit rate не компенсировал увеличение самого контекста и количества вызовов.

Компания обнаружила несколько источников лишних расходов:

• агенты многократно передавали длинную историю разговора;
• часть справочных файлов каждый раз читалась отдельными инструментами;
• после готового результата выполнялся дополнительный шаг для резюме, которое никто не видел;
• медленный ответ иногда ошибочно считался сбоем провайдера и запускался повторно;
• одинаковый уровень усилий модели применялся к задачам разной сложности.

Около 40% экономии Cloudflare связала с изменениями кода и логики ревьюера. Остальная часть пришлась на подбор моделей и уровней усилий. Но команда не ограничилась стоимостью: она сравнивала, сколько важных замечаний находят разные конфигурации.

Это существенная оговорка. Более дешёвый агент не обязательно хуже, но сама экономия не доказывает сохранение качества. В тестах Cloudflare некоторые режимы действительно теряли полезные находки, поэтому их нельзя было выбирать только по цене.

Как это связано с GEO

GEO часто оценивают одним вопросом: «упомянул ли AI наш бренд?». Это такой же поверхностный vibe check. Одно упоминание не показывает, как система получила ответ и насколько результат устойчив.

Полезнее разделить цепочку на этапы:

1. Обнаружение. Может ли crawler или поисковый инструмент получить страницу?
2. Retrieval. Попадает ли нужный URL в кандидаты по конкретному вопросу?
3. Выбор версии. Используется ли основной canonical, а не параметрический или устаревший дубль?
4. Извлечение. Верно ли система читает цену, срок, услугу, автора и дату?
5. Grounding. Подтверждает ли источник конкретное утверждение?
6. Цитирование. Появляется ли ссылка рядом с релевантным фрагментом ответа?
7. Действие. Переходит ли пользователь на сайт и выполняет ли целевое действие?

Если бренд не появился в ответе, такая схема помогает найти причину. Проблема может быть в техническом доступе, слабом соответствии запросу, конфликтующих фактах, выборе дубля или в том, что AI назвал бренд без ссылки. Эти ситуации требуют разных исправлений.

Для регулярного GEO-мониторинга также нужен стабильный набор запросов. Сравнивать результаты разных недель корректно только при одинаковых формулировках, моделях, языках и условиях. Иначе изменение ответа может быть следствием нового теста, а не улучшения сайта.

Какие метрики собирать

Минимальный отчёт по AI-агенту или GEO-процессу стоит разделить на четыре группы.

Результат

• доля сценариев, завершённых без ручного исправления;
• доля фактов, подтверждённых указанными источниками;
• процент корректных canonical URL;
• число дублей и противоречий.

Процесс

• количество шагов и вызовов инструментов;
• повторные запросы и циклы;
• ошибки параметров;
• доля сценариев, где выполнены обязательные проверки.

Ресурсы

• время до результата;
• токены и стоимость на один успешный сценарий;
• cache hit rate вместе с общим объёмом контекста;
• API-квоты и частота повторов.

Качество после публикации

• HTTP-статус и доступность страницы;
• index/follow, canonical, robots и sitemap;
• появление страницы в retrieval и цитатах;
• корректность извлечённых фактов;
• переходы и конверсии из AI-источников.

Отдельно полезно считать стоимость не одного запуска, а одного успешно завершённого сценария. Дешёвый запуск, который приходится повторять или исправлять вручную, может оказаться дороже более надёжной конфигурации.

План проверки AI-агента

Начать можно без сложной платформы.

1. Выберите 10–20 критических сценариев, включая обычные и проблемные случаи.
2. Для каждого запишите обязательные источники, действия, ограничения и условия завершения.
3. Сохраните полную трассу: запросы, инструменты, параметры, ответы, время и стоимость.
4. Просмотрите первые трассы вручную и отметьте конкретные ошибки.
5. Превратите повторяющиеся ошибки в детерминированные или булевы проверки.
6. Зафиксируйте базовый набор тестов и не меняйте его во время сравнения.
7. Запускайте набор после изменения промпта, модели, источников или инструментов.
8. Проверяйте не только средние значения, но и самые медленные и дорогие сценарии.
9. После запуска добавляйте в тесты реальные production-сбои.

Для GEO-набора сценариев стоит включить разные формулировки одного намерения, брендовые и небрендовые вопросы, сравнения, цены, ограничения и запросы на подтверждающие источники. Так проверяется не удачный единичный ответ, а устойчивость видимости.

Что нельзя заключать из этих кейсов

Публикация Google — инженерное руководство по оценке AI-агентов, а не фактор ранжирования Google Search и не инструкция по получению цитат. Она полезна как метод контроля процессов, но не обещает рост видимости сайта.

Кейс Cloudflare относится к собственному AI-ревьюеру кода, определённым моделям, тарифам и периоду наблюдения. Снижение стоимости на 68% нельзя переносить как универсальный прогноз для любого бизнеса.

Наконец, трассировка и автоматические судьи не отменяют ручную проверку. Модель-оценщик тоже может ошибаться, а стабильный тест способен закрепить неверное требование. Поэтому цифры должны дополнять экспертную проверку, а не заменять её.

Главный вывод двух публикаций совпадает: качество AI-агента определяется не красотой последнего абзаца, а тем, насколько надёжно, быстро и проверяемо он проходит весь путь до результата. Для GEO это означает переход от случайных проверок бренда к системному контролю обнаружения, retrieval, источников, canonical и фактической точности.

Если нужна проверка того, как сайт обнаруживается, интерпретируется и цитируется AI-системами, можно начать с GEO-продвижения.