Счёт за наблюдаемость данных для ИИ-агентов подан

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

Что произошло

В июле столкнулись два события. Во-первых, как сообщил VentureBeat в материале Джунаида Эффенди от 22 июля, команды корпоративного ИИ сталкиваются с предсказуемым сбоем: базы знаний чат-ботов устаревают в течение трёх месяцев после развёртывания, и в описанном сценарии примерно треть пользовательских запросов начинает получать уверенно неверные ответы. Никакого дрейфа модели, никакой регрессии промптов. Просто мир движется вперёд, пока слой ретривала не успевает.

Во-вторых, это заметили гиперскейлеры. AWS вступил в так называемую гонку «контекстного слоя» с графом знаний, обучающимся на основе действий агентов. Snowflake выпустил два новых продукта — Horizon Context и Cortex Sense, — прямо нацеленных на агентов, дающих уверенно неверные ответы из-за отсутствия контроля над бизнес-логикой под ними. Оба вендора выставляют это как новый SKU, а не как функцию в рамках того, за что клиенты уже платят.

Аргумент Эффенди, опирающийся на его собственный опыт построения системы наблюдаемости в Socure и на публичные инженерные материалы Uber и Netflix, состоит в том, что контекстный слой находится на этаж выше реальной проблемы. Платформа Uber Unified Data Quality, созданная задолго до появления retrieval-augmented generation, обслуживает более 2 000 критических датасетов и перехватывает около 90% инцидентов с качеством данных до того, как они достигают потребителей. Netflix построил общекорпоративную систему отслеживания происхождения данных, которая отображает зависимости между топиками Kafka, ML-моделями и поверхностями экспериментов — а не только таблицами в хранилище. Обе системы строились для людей и стали ещё ценнее, когда появились LLM-приложения. Неудобный вывод: граф знаний настолько достоверен, насколько достоверны данные, которые его питают, — а большинство предприятий так и не профинансировали этот питающий слой.

Техническая анатомия

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

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

Модель наблюдаемости, которую он описывает, имеет четыре измерения, заслуживающих бюджетирования. Корректность: соответствует ли каждая запись нужной форме и правилам — инструменты вроде Great Expectations и Soda выполняют валидацию на уровне строк и столбцов при загрузке. В Socure, где клиентские данные поступали в переменных и иногда некорректных форматах, Great Expectations обеспечивал валидацию схемы и диапазонов, а паттерн write-audit-publish удерживал данные на стейджинге до их перемещения в даунстрим. Свежесть: время с момента последнего успешного обновления по каждому источнику, с отдельным SLA на источник, а не единым порогом для всех, — потому что сигнал о мошенничестве и маркетинговая таксономия не требуют одинаковой частоты обновления. Согласованность: периодические перекрёстные проверки между даунстрим-назначениями с оповещением при превышении порога несоответствия, поскольку несогласованность не проявляется явно до тех пор, пока две системы, питаемые одним источником, не начнут давать разные ответы. Происхождение данных: возможность проследить любой вывод до его источника и каждую трансформацию на пути — именно это и строил Netflix.

Ничего экзотического здесь нет. Большинство из этого чисто ложится на возможности, уже имеющиеся в современном стеке хранилища данных. Команда на Snowflake может реализовать значительную часть слоя корректности и свежести с помощью примитивов, задокументированных в документации Snowflake, а нативное тестирование dbt покрывает реальную часть поверхности валидации через dbt tests. Разрыв — организационный, а не технологический.

Кто пострадает

Три категории должны быть обеспокоены. Во-первых, любые регулируемые вертикали, выпускающие клиентские агенты поверх RAG: финтех-ассистенты онбординга, боты ответственных азартных игр, медицинская и страховая сортировка. В этих вертикалях уверенно неверный ответ — это не обращение в поддержку, а регуляторная претензия. Юридический директор, согласовавший формулировки раскрытия информации агента, не согласовывал базу знаний, которая деградирует заметным образом в течение квартала.

Во-вторых, команды платформ серии B и серии C, купившие SKU контекстного слоя как ярлык. Horizon Context, Cortex Sense и граф знаний AWS — это легитимные продукты, но они решают проблему управления бизнес-логикой, а не проблему того, остаются ли лежащие в основе данные истинными. Команды, пропустившие слой наблюдаемости и купившие контекстный слой, обнаружат на четвёртом месяце, что платят премиальные вендорские цены за систему, чьи входные данные никто не валидирует. Юнит-экономика быстро становится некрасивой: потребление контекстного слоя масштабируется с использованием агентов, поэтому сломанный агент, уверенно генерирующий бессмыслицу, сжигает токены с той же скоростью, что и рабочий.

В-третьих, и это наименее обсуждаемый аспект, — руководители по найму. Рынок инженеров, способных строить внутренние платформы наблюдаемости в стиле Uber или Netflix, тонкий — потому что десятилетие эти роли воспринимались как технические, а не стратегические. Теперь они нужны каждой ИИ-ориентированной организации, причём такие специалисты, которые могут внятно описать происхождение данных через Kafka, feature stores и векторные индексы, а не только таблицы в хранилище. Ожидайте, что компенсации для старших инженеров дата-платформ с опытом в области наблюдаемости заметно вырастут во втором полугодии 2026 года. Команды, пытающиеся решить эту задачу с помощью джуниора и установки Great Expectations, не достигнут результата.

Вице-президент по разработке в среднем финтехе должна на этой неделе задать своему руководителю платформы очень конкретный вопрос: какая доля датасетов, питающих наших production-агентов, имеет доступное для запросов происхождение данных, а какая доля живёт только в чьей-то голове? Если честный ответ — меньше половины, роадмап на четвёртый квартал нужно менять до запуска следующего агента, а не после.

Руководство для дата-команд

Начинайте с покрытия, а не с инструментария. Перечислите датасеты, питающие любого production-агента или LLM-поверхность, и оцените каждый по четырём измерениям. Сначала корректность — потому что её дешевле всего инструментировать и она даёт наибольшую отдачу: Great Expectations или Soda при загрузке, паттерн стейджинга write-audit-publish до перемещения чего-либо в даунстрим, и процент валидации, отслеживаемый на каждый запуск, а не на каждый инцидент.

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

Относительно выбора между build и buy: продукты контекстного слоя стоит оценивать, но не как замену лежащему под ним слою наблюдаемости. Рассматривайте их как управление поверх фундамента данных, которому вы уже доверяете, — а если фундаменту вы ещё не доверяете, выстраивайте расходы соответственно. Разговор с CFO проще, чем кажется: расходы на наблюдаемость — это фиксированные затраты, предотвращающие переменные регуляторные и репутационные риски. Расходы на контекстный слой — это переменные затраты, масштабирующиеся с использованием системы, корректность которой вы ещё не гарантировали.

Ключевые выводы

• Базы знаний ИИ-агентов деградируют в течение трёх месяцев в описанном сценарии, выдавая уверенно неверные ответы примерно на треть запросов без каких-либо изменений модели или промптов.
• Граф знаний AWS и продукты Snowflake — Horizon Context и Cortex Sense — решают задачу управления бизнес-логикой, но находятся на уровень выше реального разрыва в наблюдаемости данных.
• Платформа Uber Unified Data Quality охватывает более 2 000 критических датасетов и перехватывает около 90% инцидентов до того, как они достигают потребителей; она создана задолго до RAG — и в этом весь смысл.
• Закладывайте бюджет на четыре измеримых измерения: корректность, свежесть с SLA на источник, согласованность через перекрёстные проверки и доступное для запросов происхождение данных.
• Команды, оценивающие SKU контекстного слоя в этом квартале, должны сначала выяснить, какая доля датасетов, питающих их агентов, имеет покрытие наблюдаемостью, и соотносить вендорское решение с этим числом, а не с демонстрацией.