Почему стандартные метрики не работают для Deep Research отчётов
Similarweb столкнулся с проблемой, знакомой каждому, кто строит AI-агентов для генерации длинных исследовательских отчётов. Результат работы агента - это не один правильный ответ, а многостраничный документ с выводами, источниками и цепочкой рассуждений. Классические метрики вроде BLEU или ROUGE, заточенные под сравнение с эталонной строкой, здесь бесполезны. Они не улавливают фактологическую точность, логическую связность и полноту аргументации.
Команда Similarweb пошла по пути комбинированной оценки. Вместо одной метрики они выстроили систему из четырёх компонентов: рубрики для LLM-as-judge, проверка faithfulness, трейсинг вызовов инструментов и A/B-сравнение с базовой версией. Этот подход закрывает главную боль инженеров - неопределённость в качестве многошагового вывода, где каждый этап может внести искажение.
Ключевой урок кейса: плохо откалиброванные критерии оценки способны замаскировать реальные улучшения агента. Similarweb изменил промпт и логику агента, ожидая роста качества, но метрики не шевельнулись. Причина - рубрики LLM-as-judge были настроены так, что не различали тонких различий в качестве аргументации. Только после пересмотра критериев и привязки каждого скора к трейсу в LangSmith команда увидела реальный прогресс.
Этот материал - практический разбор архитектуры оценки, который пригодится ML-инженерам и разработчикам RAG-систем, где результат не сводится к одному правильному ответу. Мы детально разберём четыре столпа подхода Similarweb и покажем, как воспроизвести эту систему в своём проекте.
Специфика агентов, генерирующих исследовательские отчёты
Агент Similarweb для Deep Research выполняет цепочку действий, которая принципиально отличается от одношагового чата. Сначала он ищет релевантные источники через вызовы поисковых инструментов. Затем анализирует извлечённые документы, выделяет ключевые факты и противоречия. На основе этого формирует структуру отчёта и пишет разделы, связывая выводы с конкретными источниками.
Многошаговость порождает каскад ошибок. Если агент на первом шаге выбрал нерелевантный источник, все последующие выводы оказываются под вопросом. Если он правильно извлёк факты, но неверно их проинтерпретировал, финальный отчёт выглядит правдоподобно, но содержит фактические ошибки. Оценка должна учитывать каждый этап цепочки.
Ещё одна особенность - отсутствие единственного «правильного» отчёта. Два разных агента могут сгенерировать качественные, но непохожие документы на одну тему. Один сделает акцент на количественных данных, другой - на экспертных мнениях. Метрика, заточенная на сравнение с эталоном, забракует один из них безосновательно. Именно поэтому Similarweb отказался от попарного сравнения с «золотым стандартом» в пользу многомерной оценки.
Схожая проблема возникает при диагностике продакшен-агентов. Мы разбирали её в статье про IssueBench - синтетический бенчмарк LangChain для оценки агента-диагноста. Там тоже ключевой вызов - отсутствие единственного верного ответа при анализе инцидентов.
Комбинированный подход Similarweb: четыре столпа оценки
Similarweb выстроил систему, где каждый компонент отвечает за свой аспект качества. Рубрики LLM-as-judge оценивают текст и структуру. Проверка faithfulness верифицирует факты по источникам. Трейсинг в LangSmith связывает каждый балл с контекстом выполнения. A/B-сравнение с базовой версией показывает направление изменений. Эти четыре компонента работают не изолированно, а дополняют друг друга, создавая полную картину качества агента.
LLM-as-judge: как правильно настроить рубрики для длинных отчётов
LLM-as-judge - это подход, при котором одна языковая модель оценивает результат работы другой по заданным критериям. Для коротких ответов достаточно одного-двух критериев вроде «релевантность» и «точность». Для длинного исследовательского отчёта требуется многомерная рубрика.
Similarweb определил несколько ключевых критериев. Ясность изложения - насколько легко читатель воспринимает аргументацию. Полнота охвата темы - все ли значимые аспекты раскрыты. Обоснованность выводов - подкреплён ли каждый тезис фактами из источников. Структурная логика - насколько связно разделы вытекают один из другого.
Самый болезненный этап - калибровка рубрик. Команда Similarweb потратила несколько итераций, чтобы критерии стали достаточно чувствительными. Первая версия рубрик давала высокие баллы за формально правильные, но поверхностные отчёты. Агент научился «угождать» оценщику: писал гладкий текст, избегал спорных утверждений, но не давал глубокого анализа. Когда инженеры улучшили агента, добавив более смелые выводы с опорой на данные, рубрики не показали роста - они просто не были настроены различать глубину аналитики.
Решение потребовало трёх шагов. Во-первых, критерии детализировали: вместо «обоснованность выводов» ввели отдельные оценки для «фактологической опоры на источник», «логической связи между фактом и выводом» и «признания ограничений данных». Во-вторых, для каждого критерия прописали примеры оценок по шкале 1-5 с конкретными формулировками. В-третьих, ввели перекрёстную проверку: два разных evaluator-промпта оценивают один отчёт, и расхождение больше 1 балла считается сигналом к пересмотру критерия.
Этот опыт перекликается с тем, что мы описывали в разборе Eval Engineering Skill от LangChain: автоматическая генерация тестов работает лучше, когда разработчик участвует в уточнении критериев через диалог, а не принимает первую версию.
Faithfulness: проверка фактов на основе источников
Faithfulness - это метрика, измеряющая, насколько утверждения в сгенерированном отчёте соответствуют исходным документам, которые агент использовал при написании. Агент может написать гладкий и убедительный текст, но приписать источнику то, чего в нём нет. Или сделать вывод, который напрямую противоречит данным. Faithfulness-проверка ловит такие расхождения.
Механика проверки у Similarweb устроена так. Для каждого абзаца отчёта система извлекает все фактологические утверждения - конкретные цифры, даты, причинно-следственные связи. Затем для каждого утверждения ищет подтверждение в документах, которые агент использовал на этапе исследования. Трейсинг в LangSmith здесь критичен: он показывает, какой именно документ был источником для какого фрагмента отчёта. Если утверждение не находит подтверждения ни в одном из источников, оно помечается как потенциальная галлюцинация.
Важный нюанс: не все расхождения - ошибки. Агент может сделать обобщение, которое напрямую не прописано ни в одном документе, но логически следует из совокупности источников. Поэтому Similarweb использует двухуровневую проверку. Сначала автоматическое сопоставление с источниками через embedding-поиск. Затем LLM-оценщик, который определяет, является ли расхождение допустимым обобщением или фактической ошибкой.
Результат faithfulness-проверки - это не бинарный вердикт «хорошо/плохо», а доля утверждений, подтверждённых источниками. Пороговое значение команда Similarweb установила на уровне 90%: отчёт с меньшей долей отправляется на ручную проверку или автоматическую доработку.
Трейсинг в LangSmith: связь оценки с контекстом выполнения
Выставить балл агенту недостаточно. Когда метрика показывает падение качества, инженеру нужно понять, на каком шаге цепочки произошёл сбой. LangSmith решает эту задачу, связывая каждый скоринг с полным трейсом выполнения агента.
В кейсе Similarweb трейсинг покрывает всю цепочку. Поисковые запросы агента и возвращённые результаты. Извлечение фактов из документов. Промпты, которые агент использовал для генерации каждого раздела. Итоговый отчёт и все промежуточные версии. Оценки от LLM-as-judge и faithfulness-проверки привязаны к конкретным узлам трейса.
Эта связность радикально ускоряет отладку. Когда Similarweb обнаружил, что faithfulness просела на 7 процентных пунктов, инженеры не гадали о причинах. Они открыли трейсы «провальных» прогонов и увидели паттерн: агент начал использовать новый источник, который содержал устаревшие данные. Проблему локализовали за минуты, а не часы.
Комментарии evaluator - ещё один слой, который LangSmith сохраняет в трейсе. Когда LLM-as-judge ставит низкий балл по критерию «обоснованность выводов», он генерирует текстовое пояснение: «Вывод о росте рынка на 15% не подкреплён источником, в документе указан диапазон 12-18%». Эти комментарии становятся частью трейса и доступны при разборе каждого конкретного прогона.
Для тех, кто строит production-пайплайны оценки, полезен опыт Motorway и AWS, который мы разбирали в статье про переход Databricks от Big Data к AI. Там тоже ключевой инсайт - качество оценки напрямую зависит от того, насколько быстро инженер может пройти путь от «метрика упала» до «вот конкретный баг».
Уроки внедрения: как плохая калибровка маскирует улучшения
Самый отрезвляющий момент кейса Similarweb - история с ошибкой калибровки, которая едва не привела к откату улучшений. Инженеры переработали агента: улучшили промпт для этапа синтеза, добавили перекрёстную проверку фактов перед написанием выводов, внедрили более агрессивную стратегию поиска источников. По внутренним ощущениям команды, качество отчётов выросло - выводы стали глубже, аргументация убедительнее.
Метрики показали нулевой прирост. LLM-as-judge ставил те же баллы, что и для предыдущей версии. Faithfulness не изменилась. A/B-сравнение не выявило статистически значимой разницы.
Причина вскрылась при ручном анализе трейсов. Оказалось, что рубрики LLM-as-judge были откалиброваны на «безопасный» стиль ответов. Агент, который писал осторожно и избегал сильных утверждений, получал высокие баллы за «обоснованность», потому что критерий был сформулирован как «выводы не противоречат источникам». Новая версия агента делала более смелые обобщения, которые формально выходили за пределы прямых цитат из источников, но были корректны по сути. Оценщик штрафовал за это, компенсируя реальный прирост качества.
Команда пересмотрела критерии, разделив «обоснованность» на три субкритерия: точность цитирования, логическая непротиворечивость вывода и признание неопределённости. После повторной калибровки метрики показали рост на 12 процентных пунктов по качеству аргументации. Улучшения, которые существовали объективно, наконец отразились в цифрах.
Три вывода из этого кейса. Первый: калибруйте рубрики на реальных примерах, а не на абстрактных представлениях о «хорошем отчёте». Второй: если метрики не реагируют на изменения, которые вы считаете улучшениями, проблема может быть в метриках, а не в агенте. Третий: всегда сверяйте количественные оценки с качественным анализом трейсов - LangSmith даёт для этого инструментарий.
Практические рекомендации для вашей системы оценки агентов
Внедрение комбинированной оценки не требует копирования подхода Similarweb один в один. Масштаб системы должен соответствовать сложности агента и цене ошибки. Чек-лист ниже поможет определить необходимый минимум и избежать переусложнения.
Определите метрики, релевантные вашей задаче. Для агента-поисковика критична точность источников. Для агента-аналитика - глубина выводов. Для агента-саппорта - ясность и эмпатия. Не пытайтесь измерить всё сразу, начните с трёх-пяти ключевых критериев.
Создайте рубрики с конкретными примерами для каждого балла. Шкала 1-5 работает лучше бинарной «хорошо/плохо», потому что позволяет отслеживать малые улучшения. Для каждого критерия пропишите, как выглядит ответ на 1 балл, на 3 балла и на 5 баллов, с реальными фрагментами отчётов.
Настройте faithfulness-проверки, если агент опирается на внешние источники. Минимальная реализация: для каждого утверждения в выводе искать ближайший чанк в исходных документах и проверять семантическое соответствие. Более продвинутый вариант - использовать отдельную LLM для попарного сравнения «утверждение - источник».
Интегрируйте трейсинг на раннем этапе. LangSmith позволяет начать с минимальной инструментации: обернуть вызовы LLM и инструментов в трейсы. По мере усложнения агента добавляйте кастомные метаданные к спанам - версию промпта, идентификатор сессии, параметры модели.
Итеративно калибруйте критерии. После каждого значимого изменения агента прогоняйте оценку на фиксированном наборе отчётов и сравнивайте не только баллы, но и распределение оценок по критериям. Если новый агент получает те же баллы, но вы видите качественные улучшения в трейсах, пересматривайте рубрики.
Когда комбинированная оценка необходима, а когда избыточна
Комбинированная оценка оправдана, когда агент выполняет многошаговую цепочку с внешними инструментами, а результат нельзя свести к одному правильному ответу. Примеры: генерация исследовательских отчётов, многошаговый анализ данных, агенты-диагносты, которые ищут корневые причины инцидентов. В этих сценариях цена фактической ошибки высока, а поверхностный ответ может быть опаснее отсутствия ответа.
Если агент решает узкую задачу с чётко определённым правильным ответом - классификация тикетов, извлечение сущностей, ответы на FAQ по базе знаний - достаточно одной-двух метрик. Например, точность классификации и доля успешно извлечённых сущностей. Трейсинг при этом остаётся полезным для отладки, но многомерные рубрики и faithfulness-проверки будут избыточны.
Промежуточный случай - RAG-системы, которые отвечают на вопросы по внутренней документации. Здесь полезна связка «релевантность ответа + faithfulness», но без сложных рубрик для оценки аргументации. Ответ либо содержит факты из документов, либо нет. Анализ трейсов помогает понять, почему агент не нашёл нужный чанк, и улучшить стратегию поиска.
Оценка не должна становиться самоцелью. Если вы тратите больше времени на настройку рубрик, чем на улучшение самого агента, система разбалансирована. Начните с минимальной жизнеспособной оценки, которая ловит критические ошибки, и наращивайте сложность по мере роста требований к качеству.