Рахунок за Data Observability для AI-агентів надійшов

Платформний лід, який затвердив RAG-агента в першому кварталі, тепер дивиться на засідання ради директорів у третьому кварталі з чергою підтримки, повною звернень «бот назвав мені неправильну ціну». Ніхто не змінював модель. Ніхто не торкався промптів. Сховище знань просто тихо застаріло, а моніторинговий стек, побудований для пайплайнів, а не для даних, весь цей час продовжував світитися зеленим. Саме це архітектурне рішення кожна дата-організація зараз переосмислює — і вендорські презентації, що заповнюють поштові скриньки цього місяця, націлені точнісінько на симптом, а не на хворобу.

Що сталося

У липні зіткнулися дві речі. По-перше, як повідомив VentureBeat у матеріалі Джунаїда Еффенді від 22 липня, команди корпоративного AI стикаються з передбачуваним режимом відмови: сховища знань чатботів застарівають протягом трьох місяців після розгортання, і приблизно третина запитів користувачів починає отримувати впевнено хибні відповіді. Жодного дрейфу моделі, жодної регресії промптів. Просто світ рухається далі, а шар отримання даних — ні.

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

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

Технічна анатомія

Режим відмови витончений у найгіршому сенсі. Стандартний пайплайн отримання даних оцінює релевантність або доступність. Він не оцінює правильність. Застарілий документ із цінами, схема, де команда з upstream тихо перейменувала поле, запис із відсутнім атрибутом — усе це проходить кожну перевірку, для якої пайплайн був побудований. Модель потім відповідає з повною впевненістю, бо отриманий контекст виглядає авторитетно. Дашборди залишаються зеленими, бо дашборди стежать за завершенням задач, а не за істинністю даних.

Еффенді розповідає про до-AI інцидент у фінтеху, який ідеально відображає сьогоднішні збої RAG: upstream-система змінила поле, не повідомивши downstream-користувачів, пайплайн відпрацював чисто, і хибні значення поширилися в дашборди — аж поки клієнт не помітив. Відсутність помилки — це не наявність правильності. Цю фразу варто роздрукувати й повісити на стіну в кожній команді дата-платформи, яка цього кварталу запускає агентні воркфлоу.

Модель observability, яку він описує, має чотири виміри, проти яких варто закладати бюджет. Правильність (Correctness): чи відповідає кожен запис очікуваній формі та правилам — інструменти на кшталт Great Expectations і Soda забезпечують валідацію на рівні рядків і стовпців при інгестії. У Socure, де клієнтські дані надходили у змінних і часом некоректних форматах, Great Expectations відповідав за валідацію схем і діапазонів, а патерн write-audit-publish зупиняв дані перед переміщенням downstream. Свіжість (Freshness): час з моменту останнього успішного оновлення для кожного джерела, з SLA на джерело, а не одним загальним порогом — адже сигнал про шахрайство і маркетингова таксономія не потребують однакової частоти оновлення. Узгодженість (Consistency): періодичні перехресні перевірки між downstream-призначеннями із сигналізацією про перевищення порогу розбіжностей, бо неузгодженість проявляється непомітно — аж поки дві системи, що живляться з одного джерела, не починають суперечити одна одній. Лінія походження (Lineage): здатність відстежити будь-який вихід до його джерела та кожне перетворення по дорозі — саме для цього Netflix і будував свою систему.

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

Хто постраждає

Три категорії мають підстави для занепокоєння. По-перше, будь-який регульований вертикаль, що запускає клієнтські агенти на базі RAG: фінтех-асистенти для онбордингу, боти відповідального гейміну iGaming, сортувальники в сфері охорони здоров'я та страхування. У цих вертикалях впевнено хибна відповідь — це не звернення до підтримки, це регуляторне порушення. Юрисконсульт, який погодив текст розкриття інформації агента, не погоджував сховище знань, що вимірно деградує протягом кварталу.

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

По-третє, і це найменш обговорювана частина — менеджери з найму. Ринок інженерів, здатних будувати внутрішні платформи observability рівня Uber або Netflix, надзвичайно вузький, бо протягом десятиліття ці ролі сприймалися як обслуговуючі, а не стратегічні. Тепер вони потрібні кожній AI-орієнтованій організації — і потрібні ті, хто може артикулювати лінію походження через Kafka, feature store та векторні індекси, а не лише через таблиці сховища. Очікуйте, що компенсація старших інженерів дата-платформ з досвідом у observability помітно зросте в другій половині 2026 року. Команди, які спробують вирішити це через джуніор-найм і встановлення Great Expectations, отримають результат нижче очікуваного.

VP Engineering у фінтеху середнього ринку цього тижня має поставити своєму Head of Platform дуже конкретне запитання: яка частка датасетів, що живлять наших виробничих агентів, має доступну лінію походження — і яка частка живе лише в чиїйсь голові? Якщо чесна відповідь — менше половини, дорожня карта на четвертий квартал потребує змін до того, як наступний агент вийде у виробництво, а не після.

Плейбук для дата-команд

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

Потім свіжість — і не піддавайтеся спокусі встановити один загальний SLA. Пороги на джерело змушують провести розмову про те, яким даним справді потрібно бути свіжими, — а це виявляє бізнес-логіку, яку вендори тепер намагаються продати назад у вигляді контекстного шару. Перевірки узгодженості мають бути запланованими cross-destination порівняннями з оповіщенням про рівень розбіжностей, а не одноразовим аудитом. Lineage — це найтриваліша побудова та найвища рентабельність інвестицій після того, як агентні воркфлоу розмножаться, тож починайте формувати обсяг зараз, навіть якщо постачання — це проект на два квартали.

Щодо вибору між розробкою та покупкою: продукти контекстного шару варті оцінки, але не як замінник шару observability під ними. Розглядайте їх як управління поверх фундаменту даних, якому ви вже довіряєте, — а якщо ви ще не довіряєте фундаменту, відповідно розставляйте витрати за пріоритетом. Розмова з CFO простіша, ніж здається: витрати на observability — це фіксована вартість, що запобігає змінним регуляторним та репутаційним витратам. Витрати на контекстний шар — це змінна вартість, що масштабується з використанням системи, правильність якої ви ще не гарантували.

Ключові висновки

• Сховища знань AI-агентів застарівають протягом трьох місяців у описаному сценарії, видаючи впевнено хибні відповіді приблизно на третину запитів без жодних змін моделі або промптів.
• Граф знань AWS і Horizon Context та Cortex Sense від Snowflake вирішують питання управління бізнес-логікою, але розташовані на рівень вище реального розриву в data observability.
• Платформа Uber Unified Data Quality покриває понад 2 000 критичних датасетів і виявляє близько 90% інцидентів до того, як вони торкнуться споживачів; вона з'явилася ще до RAG — і в цьому весь сенс.
• Закладайте бюджет проти чотирьох вимірюваних вимірів: правильності, свіжості з SLA на джерело, узгодженості через cross-destination перевірки та доступної лінії походження.
• Команди, що оцінюють SKU контекстного шару цього кварталу, мають спочатку запитати, яка частка їхніх датасетів для агентів має observability-покриття, — і ціну рішення щодо вендора зіставляти з цим числом, а не з демонстрацією.