Бенчмарк для дата-агентов на своих данных

Статья показывает, как компании теряют доверие к дата-агентам после пилота: модель, промпт и метрики меняются, а никто не проверяет, остались ли ответы верными. Решение — создать фиксированный набор «золотых вопросов» с известными ответами и прогонять его при каждом изменении. Такой регрессионный набор переносит проверку из разовых демо в регулярный процесс, как тесты в обычной разработке. Без него даже успешный пилот часто заканчивается отказом от внедрения, потому что первые реальные запросы дают расхождения с дашбордами и отчётами. Компаниям важно понимать, что дата-агент — это не разовая демонстрация, а система, которая должна сохранять точность при обновлении модели или промпта. Фиксированный набор вопросов помогает принять решение «брать или не брать» в продакшн: если точность падает после изменений, проект откладывают до устранения причин.

Почему готовые бенчмарки не помогают

Публичные наборы вроде Spider и BIRD проверяют умение модели писать SQL на чужих схемах. Даже лидеры Spider 2.0 набирают ниже 20 процентов на задачах с большими схемами и бизнес-логикой. В реальной компании вопросы зависят от определения «активного клиента», фискального календаря и правил расчёта выручки. Модель, которая лидирует в открытом тесте, может регулярно ошибаться именно на этих моментах. Готовые бенчмарки не учитывают внутренние правила компании, поэтому их результат не даёт оснований для решения о внедрении. Они полезны только на этапе выбора базовой модели, но не заменяют проверку на собственных данных. Без собственной проверки агент продолжает отвечать уверенно, но цифры расходятся с дашбордами. Для решения «брать или не брать» это критично: компания получает ложное ощущение готовности, а после запуска сталкивается с постоянными правками и потерей доверия пользователей.

Из чего состоит золотой вопрос

Каждый вопрос записывают вместе с ожидаемым результатом, разрешёнными источниками и правилами поведения. Нужно фиксировать не только итоговую таблицу, но и то, какие метрики агент должен использовать, а какие — нет. Отдельно отмечают случаи, когда агент обязан отказаться от ответа: запрос затрагивает недоступные данные или не имеет однозначной интерпретации. Золотой вопрос — это не просто текст, а полный набор условий, которые позволяют понять, корректен ли ответ агента. Вопросы берут из реальных обращений аналитиков и дашбордов, а не придумывают. Это даёт покрытие по частым сценариям и сразу показывает, где агент начинает «выдумывать» числа. При решении о внедрении такой набор помогает оценить, покрывает ли агент ключевые бизнес-процессы или остаются зоны, где ошибки неизбежны. Если золотые вопросы не отражают реальные запросы, то даже высокий процент прохождения не гарантирует полезности в работе.

Как зафиксировать данные и ответы

Чтобы ответы не уплывали при изменении таблиц, используют снимки Iceberg с тегами. Iceberg — это формат таблиц для озёр данных, который позволяет сохранять версии и помечать их тегами. Тег фиксирует состояние данных на момент создания вопроса. При проверке агент работает именно с этим тегом, а не с текущими таблицами. Сравнение результатов ведут через Arrow: два набора строк считаются равными, если они совпадают побайтово после сортировки. Arrow — это формат для обмена данными в памяти, который обеспечивает точное побайтовое сравнение без влияния порядка строк. Такой подход убирает ложные срабатывания из-за новых строк или обновления справочников. В российских проектах это особенно важно: данные часто приходят из нескольких систем с разным расписанием обновления, и без фиксации состояния невозможно понять, виноват ли агент или источник. Для решения «брать или не брать» фиксация состояния даёт объективную картину: если агент ошибается на зафиксированных данных, проблема в логике, а не в изменении источника.

Как встроить проверку в процесс

Набор вопросов хранят в репозитории вместе с историей запусков. Каждый прогон пишет результат в Parquet: какие вопросы прошли, какие упали и какие SQL сгенерировал агент. CI-пайплайн отказывает в мерже, если точность падает ниже порога. Это останавливает изменения промпта или модели, которые незаметно портят ответы. При внедрении важно не перегружать набор: начинают с 30-50 вопросов, покрывающих ключевые метрики, и добавляют новые только после того, как они стабильно проходят. Такой подход даёт командам уверенность, что агент можно развивать дальше, не боясь отката качества. Регулярная проверка позволяет принять обоснованное решение о масштабировании: если метрика держится выше порога после нескольких итераций, риск отката снижается. Если же набор слишком мал или не обновляется, компания может пропустить деградацию и зря инвестировать в развитие.

Источник

Это краткий разбор материала Dremio. Полная версия с примерами кода, схемами и деталями реализации — в оригинале: Бенчмарк для дата-агентов на своих данных.

Курс по теме — Каталог курсов Школы Больших Данных