Наблюдаемость данных для ИИ: почему агенты совершают ошибки

Вы тратите недели на настройку ИИ-чата. Ответы точны. Заинтересованные лица дают добро, и вы запускаете систему. Спустя три месяца система с уверенной невозмутимостью выдает неверную информацию примерно по трети запросов пользователей. Никто не менял модель, никто не трогал промты. Мир изменился, цены обновились, вышло обновление политики или новая версия спецификации продукта, а лежащее в основе хранилище знаний осталось прежним.

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

Сбой, который не выглядит как сбой

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

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

Я наблюдал похожий сценарий за пределами контекста ИИ — в финтех-конвейере. Внутренняя система upstream изменила поле, не уведомив пользователей downstream. Конвейер не упал; он просто транслировал неверные значения в дашборды, поскольку система проверяла лишь то, завершилась ли задача, а не то, остались ли данные корректными. Проблема всплыла только тогда, когда клиент заметил несоответствие. К тому моменту некорректные данные уже ушли дальше по цепочке.

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

Почему это проблема инженерии данных

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

Обвинение модели: Первый порыв — обвинить модель, попробовать другую LLM или настроить промт. Настоящая проблема кроется глубже по потоку, на уровне инженерии данных — это тот же инстинкт, который проявился в упомянутом финтех-сбое: мониторинг настроен на сам конвейер, а не на данные.

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

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

• Новые инструменты Horizon Context и Cortex Sense от Snowflake нацелены ровно на тот симптом, с которого начинается эта статья: агенты выдают уверенные ошибочные ответы, потому что лежащая в их основе бизнес-логека ничем не регулируется.

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

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

Чего на самом деле не хватает: наблюдаемости данных

Наблюдаемость данных (Data Observability) — это хорошо известная концепция, которой уделяется недостаточно внимания в плане ее реальной реализации. Важной метрикой здесь является не процентное соотношение, а покрытие: какая доля критически важных наборов данных имеет реально отслеживаемую линию (lineage), а не существует лишь в чьей-то голове.

Компания Uber создала <специализированную платформу качества и наблюдаемости данных>специализированную платформу качества и наблюдаемости данных задолго до появления генерации, дополненной извлечением (RAG). Их платформа Unified Data Quality поддерживает более 2000 критически важных наборов данных и обнаруживает около 90% инцидентов с качеством данных до того, как они дойдут до конечных потребителей.

Netflix решила другую часть той же проблемы, построив общекорпоративную систему происхождения данных, чтобы любой сотрудник мог выяснить, откуда взялся набор данных и с чем он взаимодействовал по пути. Она сопоставляет зависимости между топиками Kafka, моделями машинного обучения и экспериментами, а не только таблицами хранилища. Подобно Uber, платформа создавалась для людей, но теперь ее значимость возросла с распространением ИИ/LLM-приложений.

Совместно Uber и Netflix охватывают два из четырех аспектов, ради которых стоит вести разработку. На практике я рассматриваю это как четыре измерения, каждое из которых поддается измерению по своим собственным критериям.

Корректность: Соответствует ли каждая запись предполагаемой структуре и правилам: правильные типы полей, отсутствие неожиданных пустых значений (null), нахождение значений в допустимых диапазонах. Инструменты вроде Great Expectations и Soda справляются с этим отлично: автоматизированная проверка на уровне строк и столбцов вместо ручных проверок после того, как что-то ломается. Отслеживайте процент записей, прошедших валидацию за один запуск.

Свежесть: Являются ли данные актуальными по отношению к их источнику, а не просто актуальными на момент последней проверки. Отслеживайте время, прошедшее с момента последнего успешного обновления для каждого источника, используя SLA для каждого набора данных, а не единый общий порог, поскольку некоторым источникам требуется ежечасное обновление, а другим нет.

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

Происхождение (Lineage): Можете ли вы проследить любой результат до его источника и каждого преобразования, через которое он прошел — это та самая задача, для решения которой Netflix создал свою систему.

Ничто из этого не требует инфраструктуры, которой у большинства команд по работе с данными еще нет. Я знаю это, потому что сам строил ее, а не просто призывал к этому.

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

Great Expectations стала частью этого фундамента: проверка схем и диапазонов при поступлении, SLA свежести для каждого источника, межсистемные проверки на согласованность и построчное отслеживание происхождения. Все это работало на базе паттерна write-audit-publish (запись-аудит-публикация), при котором данные попадали в стейджинг, проходили валидацию и передавались дальше по цепочке только в случае успешного прохождения необходимых проверок.

Результат отразился на последующих этапах: общая точность возросла как в отчетности и ML-моделях, так и в системе извлечения данных для ИИ, построенной поверх тех же данных.

Что делать в понедельник утром

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

• Проверяются ли базовые данные на соответствие стандартам, которых требуют их потребители?

• Какой самый старый контент в настоящее время выдается с высокой степенью уверенности?

• Могут ли два фрагмента из одного источника противоречить друг другу в одном и том же результате поиска?

• Смогли ли вы проследить, откуда взялись данные, если бы они оказались неверными?

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

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