Машина может проверить, что запрос агента выполняется. Но почти ничто не подтверждает, что полученный ответ верен.

В предыдущей статье я писал, что уровень автономности ИИ‑агента слабо связан с тем, насколько умной кажется модель. Способность системы обнаруживать ошибки задает верхнюю границу автономности. А стоимость необнаруженной ошибки и возможность отката определяют, насколько близко к этой границе можно подойти.

Для проверки я использую четыре типа контролеров: от полностью автоматических O3, где результат можно проверить механически, до O0, где остается человеческое решение. При этом наличие проверки само по себе ничего не гарантирует — важна ее реальная сила: охват, надежность, устойчивость и независимость. Эту модель я называю градиентом автономности.


Теперь попробуем применить ее к данным и аналитике. Отчасти потому, что это моя основная область. Но есть и более важная причина: аналитика одновременно нагружает почти все слабые места этой модели.

Проверить запрос — не значит проверить ответ

Когда агент пишет код, хороший набор тестов хотя бы позволяет проверить поведение программы напрямую: запустить ее и посмотреть, что произойдет. В аналитике вроде бы можно сделать то же самое, но эта аналогия быстро перестает работать. Машина способна проверить многое. Например, что SQL‑запрос выполняется, соответствует ожидаемой структуре и использует утвержденное в компании определение метрики. Все эти проверки полезны, но ни одна из них не гарантирует правильность ответа.

Проблема может находиться ниже.

Пайплайн загрузил только половину данных за вчерашний день и никого об этом не уведомил. В upstream‑системе произошел инцидент, который не попал в мониторинг. Определение показателя изменили квартал назад, а часть таблиц продолжает считать его по старой логике.

В результате механическая проверка подтверждает корректность формы вычисления, но ничего не говорит о достоверности данных, на которых оно основано. Запрос может быть безупречным и при этом возвращать неправильный ответ.

Неправильные числа умеют долго оставаться незаметными

Код тоже может ломаться тихо. Известный пример — Knight Capital, потерявшая около $440 млн менее чем за час из‑за программного сбоя. Поэтому речь не о том, что программные ошибки всегда заметны, а аналитические всегда скрыты. Разница скорее в частоте явных сигналов и времени между появлением ошибки и ее обнаружением. У кода довольно много способов сообщить о проблеме. Он может не скомпилироваться, упасть во время выполнения или сломать тест. Обычно сигнал появляется через секунды или минуты после ошибки.

У неправильного аналитического вывода таких встроенных сигналов часто нет. Число появляется на дашборде и внешне ничем не отличается от правильного. Потом его копируют в презентацию, обсуждают на встрече и используют при принятии решения. Между появлением ошибки и ее обнаружением могут пройти недели или кварталы. Иногда ее не находят вообще.

Именно это я называю misinsight: ошибочный вывод без явного сообщения об ошибке. Я пишу об этом не только теоретически — мне самому доводилось уверенно показывать число, а уже потом узнавать, что оно было неверным.

Независимая проверка стоит дорого, а иногда ее просто нет

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

В данных эта проблема делится на две части: проверку вычисления и проверку смысла.

Для вычислений независимые опорные источники найти можно, хотя для этого приходится строить дополнительную инфраструктуру. Аналитическую копию можно сверять с operational system — системой, которая проводит платежи, отправляет заказы или фиксирует другие бизнес‑события. Можно проверять, сходятся ли части с итоговыми значениями. Можно независимо вычислить одну метрику двумя разными способами и сравнить результаты.

Такие проверки сильны именно потому, что не зависят от того же пути, который сформировал исходный ответ. Но построение независимых источников и reconciliation — отдельная инженерная работа, и во многих data stack она реализована только частично.

Со смыслом сложнее. Здесь независимого источника может не существовать вообще. Правильно ли сейчас определен churn для конкретного бизнес‑решения? Никакая сверка таблиц на этот вопрос не ответит. В какой‑то момент проверка доходит до уровня человеческого решения. Причем большинство реальных аналитических вопросов смешивают оба типа проблем. Вопрос «сколько активных клиентов мы потеряли за прошлый месяц?» выглядит как обычное вычисление, но внутри него уже находятся несколько решений о том, кого считать активным, что считать потерей и какой временной интервал использовать.

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

Радиус ошибки определяется lineage

У данных есть еще одна особенность. Таблицы используются другими таблицами, те — метриками, дашбордами и моделями. В Data Engineering эту цепочку обычно описывают через data lineage.

Из‑за этого небольшое изменение в одной таблице может распространиться на большое количество downstream‑зависимостей. Поэтому стоимость ошибки нельзя оценивать только в точке, где агент внес изменение. Нужно смотреть на все объекты ниже по lineage, которые унаследуют неправильные данные и при этом могут ничего об этом не знать.

Получается, что вопрос «сколько будет стоить ошибка агента?» для data warehouse во многом превращается в запрос по lineage. Я проверяю это на практике, запуская команды агентов против работающей платформы данных. Пока повторяется та же закономерность, что и раньше: когда система начинает работать неправильно, первым часто ломается не агент, а проверяющий механизм. Это важное наблюдение‑ агент может продолжать выполнять свою работу ровно так, как от него ожидают, но тест уже не запускается, эталон устарел или проверка больше не покрывает изменившуюся часть системы. Формально контроль существует, фактически — уже нет.

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

Что градиент автономности дает на практике

Градиент не делает данные автоматически проверяемыми. Его задача проще: не позволять считать проверенным то, что на самом деле никто надежно не проверил, и показывать, куда имеет смысл вкладываться в инфраструктуру контроля.

Начать можно с механизма, который уже есть во многих data stack: если data quality check не проходит, пайплайн останавливается, чтобы плохие данные не распространялись дальше. Градиент добавляет еще один уровень. Вместе с пайплайном должны снижаться разрешения агента на работу с результатами этого пайплайна. Если вчера агент имел право самостоятельно публиковать анализ по конкретной таблице, а сегодня критическая проверка этой таблицы перестала работать, агент должен автоматически перейти в propose‑only mode. Он по‑прежнему может подготовить анализ и предложить действие, но не выполнять его самостоятельно. Для такого понижения режима не должно требоваться отдельное совещание или ручное изменение прав. Это немного меняет и разговор о бюджете на качество данных. Data quality, observability, мониторинг и документацию обычно рассматривают как техническую гигиену. А у гигиены есть неприятное свойство: пока все работает, ее легко отложить ради задач с более заметным бизнес‑результатом.

В контексте автономных агентов у этой работы появляется более прямой эффект. Она повышает уровень автономности, который система действительно может себе позволить. Проверка того, что сегодняшние данные полностью загрузились, reconciliation с operational system, актуальное и сертифицированное определение метрики — все это расширяет область, где агенту можно безопасно работать без человека. Сюда же относится context architecture: инфраструктура, которая хранит не только данные, но и определения, ограничения, происхождение и контекст их использования. Для агента такой слой становится частью системы проверки, а не просто удобной документацией.

Но есть области, где верификация остается слабой. Особенно это касается вопросов смысла. Здесь режим работы должен быть честным: агент готовит анализ и прикладывает доказательства, а coverage map показывает, какие части решения действительно были независимо проверены и какие не проверял никто. Причем coverage map — это запись самой системы, а не отчет агента о качестве собственной работы. Если существенная часть решения остается без независимой проверки, финальное решение остается за человеком. Не потому, что human‑in‑the‑loop сам по себе считается правильной архитектурой, а потому, что это соответствует фактическому уровню проверки.

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

Проверяющие тоже входят в failure surface

Есть еще один уровень проблемы. Сами контролеры становятся частью failure surface системы. Если решение об автономности зависит от data quality checks, reconciliation, coverage map и lineage, то ошибки в этих механизмах непосредственно влияют на то, какие действия разрешены агенту. Проверяющая инфраструктура перестает быть вспомогательной. Она становится частью системы управления доступом. Отсюда возникает еще одно требование — audit trail. Нужно понимать не только, какое действие выполнил агент, но и почему в этот момент ему было разрешено его выполнить: какие проверки прошли, какие версии определений использовались, какой coverage был действителен и на основании какого состояния системы был выбран уровень автономности.

Это направление я пока продолжаю проверять экспериментально. Но уже понятно, что надежность агента нельзя рассматривать отдельно от надежности контролеров вокруг него.

Для данных автономность — это свойство всей цепочки

В аналитике легко проверить, что SQL синтаксически корректен и выполняется. Намного сложнее доказать, что ответ соответствует реальному состоянию бизнеса. Еще сложнее доказать, что сам вопрос сформулирован правильно. Поэтому автономность аналитического агента нельзя определять только качеством модели или успешностью предыдущих запросов. Нужно учитывать состояние данных, независимые проверки, актуальность определений, coverage и lineage. Если одна из этих частей ослабевает, автономность должна снижаться вместе с ней. Причем снижение должно распространяться по downstream‑зависимостям так же, как распространяется потенциальная ошибка.

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