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

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

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

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

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

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

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

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

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

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

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

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

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

Наблюдаемость данных — хорошо известная концепция, которой уделяют недостаточно внимания в части фактической реализации. Сама категория за последние несколько лет созрела: такие компании, как Monte Carlo Data и другие, создали для нее специализированные платформы, а IBM в 2022 году приобрела Databand, чтобы усилить собственные возможности в области наблюдаемости данных. Тем не менее внедрение остается неравномерным, особенно среди команд, которые лишь недавно начали строить AI-приложения поверх существующей инфраструктуры данных.

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

Uber построила специализированную платформу качества и наблюдаемости данных задолго до появления генерации с дополнением извлечением. Их платформа Unified Data Quality поддерживает более 2,000 критически важных наборов данных и выявляет около 90% инцидентов качества данных до того, как они доходят до нижестоящих потребителей.

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

Вместе Uber и Netflix покрывают две из четырех вещей, ради которых стоит строить такие системы. На практике я рассматриваю это как четыре измерения, каждое из которых можно измерять отдельно.

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

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

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

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

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

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

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

Результат проявился ниже по потоку: более высокая точность в целом — в отчетности, в ML-моделях и в AI-извлечении, построенном поверх тех же данных.

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

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

1. Проверяются ли базовые данные на соответствие стандартам, требуемым их потребителями?
2. Какой самый старый фрагмент контента сейчас выдается с высокой уверенностью?
3. Могут ли два фрагмента одного и того же источника противоречить друг другу в одном результате извлечения?
4. Смогли бы вы проследить, откуда он пришел, если бы выяснилось, что он неверен?

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

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