Poświęcasz tygodnie na dostrajanie chatbota AI. Odpowiedzi są trafne. Interesariusze dają akceptację, a ty wdrażasz system. Trzy miesiące później system z pełnym przekonaniem myli się w około jednej trzeciej pytań użytkowników. Nikt nie zmienił modelu i nikt nie ruszał promptów. Świat poszedł naprzód, ceny się zmieniły, zaktualizowano politykę, specyfikacja produktu otrzymała nową wersję, a bazowy magazyn wiedzy nie zmienił się razem z nimi.

To nie jest hipotetyczny scenariusz. To obecnie jeden z najczęstszych trybów awarii produkcyjnych w korporacyjnej AI, a większość zespołów inżynierii danych nie ma właściwych narzędzi, by go wychwycić, niezależnie od tego, w jaki sposób system AI pobiera dane. W miarę jak przedsiębiorstwa przechodzą od pilotaży AI do wdrożeń produkcyjnych na dużą skalę — Gartner konsekwentnie wskazywał jakość danych jako jedną z głównych barier adopcji AI — ta kategoria awarii przestaje być sporadyczną niedogodnością, a staje się ryzykiem systemowym.

Awaria, która nie wygląda jak awaria

Aplikacji AI jest obojętne, czy pobiera informacje z magazynu wektorowego, indeksu dokumentów czy wywołania API. Niezależnie od mechanizmu, w standardowym potoku wyszukiwania nic nie sprawdza, czy to, co jest serwowane, nadal jest poprawne. Nieaktualny dokument z cennikiem zostanie pobrany z takim samym przekonaniem jak aktualny, ponieważ system ocenia trafność lub dostępność, a nie poprawność. Rekord z po cichu brakującym polem przejdzie równie czysto jak rekord kompletny — z tego samego powodu.

Dlatego awaria jest z założenia niewidoczna. Nieaktualne lub niepełne dane nadal uzyskują wysoki wynik trafności albo przechodzą wszystkie kontrole, do których zaprojektowano potok danych. Model odpowiada z pełnym przekonaniem, ponieważ pobrany kontekst wygląda autorytatywnie. Wszystkie obserwowane dashboardy pozostają zielone. System wygląda, jakby działał. Tyle że się myli.

Widziałem podobną wersję tej sytuacji poza kontekstem AI, w potoku fintechowym. System wyższego rzędu zmienił pole bez powiadomienia użytkowników downstream. Potok nie zawiódł; po prostu propagował błędne wartości do dashboardów, ponieważ system sprawdzał tylko, czy zadanie zostało ukończone, a nie czy dane nadal były poprawne. Problem wyszedł na jaw dopiero wtedy, gdy klient zauważył niespójność. Do tego czasu błędne dane zdążyły już przepłynąć dalej.

Niezależnie od tego, czy chodzi o dokument, który się zdezaktualizował, czy o pole, które po cichu zniknęło, kształt awarii jest taki sam: brak błędu nie oznacza obecności poprawności, a bez zbudowania właściwych warstw walidacji nic w potoku nie jest w stanie zidentyfikować problemu. Stawka również rośnie, gdy agenci AI przechodzą od odpowiadania na pytania do podejmowania działań — agent działający na podstawie nieaktualnych cen lub wycofanej polityki może wykonać błędną transakcję, a nie tylko zwrócić błędną odpowiedź.

Dlaczego to problem inżynierii danych

Zespoły, które trafiają na taką awarię, mają tendencję do błędnej diagnozy — i zwykle robią to dwa razy.

Obwinianie modelu: Pierwszym odruchem jest obwinienie modelu, wypróbowanie innego LLM, dostosowanie promptu. Prawdziwy problem leży dalej w górę strumienia, w warstwie inżynierii danych — to ten sam odruch, który stał za opisaną wyżej awarią fintechową: monitoring zbudowany dla potoku, a nie dla danych.

Obwinianie warstwy wyszukiwania: Gdy model zostaje wykluczony, kolejnym odruchem jest obwinienie warstwy wyszukiwania lub kontekstu i zakup lepszej. Moment nie jest przypadkowy. Gdy przedsiębiorstwa wprowadzają te systemy do rzeczywistej produkcji, właśnie ta luka zaczyna wychodzić na powierzchnię, a odpowiedzi dostawców pojawiają się wszędzie. AWS właśnie dołączył do wyścigu o „warstwę kontekstu” z grafem wiedzy, który uczy się na podstawie użycia przez agentów. Nowe Horizon Context i Cortex Sense od Snowflake celują dokładnie w objaw, od którego zaczyna się ten tekst: agentów udzielających z przekonaniem błędnych odpowiedzi, ponieważ nikt nie zarządza logiką biznesową znajdującą się pod nimi.

Oba rozwiązania są realnymi odpowiedziami na realny problem, ale znajdują się warstwę wyżej; graf wiedzy nadal zależy od tego, czym jest zasilany. Prawdziwy problem leży dalej w górę strumienia, w warstwie inżynierii danych. Zespoły sprawdzają, czy zadanie się wykonało, a nie czy dane, które przeniosło, nadal są prawdziwe — to odruch starszy od AI o wiele lat. Monitoring jest budowany dla potoku, nie dla danych.

Czego naprawdę brakuje: obserwowalności danych

Obserwowalność danych to dobrze znane pojęcie, któremu poświęca się zbyt mało uwagi w kontekście faktycznego wdrażania. Sama kategoria dojrzała w ostatnich latach — firmy takie jak Monte Carlo Data i inne zbudowały dla niej wyspecjalizowane platformy, a IBM przejął Databand w 2022 roku, aby wzmocnić własne możliwości obserwowalności danych — jednak adopcja pozostaje nierówna, szczególnie wśród zespołów, które dopiero niedawno zaczęły budować aplikacje AI na istniejącej infrastrukturze danych.

Istotna metryka nie jest procentem — jest nią pokrycie: jaka część krytycznych zbiorów danych ma pochodzenie danych, które można faktycznie odpytać, zamiast istnieć wyłącznie w czyjejś głowie.

Uber zbudował dedykowaną platformę jakości i obserwowalności danych na długo przed pojawieniem się retrieval-augmented generation. Platforma Unified Data Quality obsługuje ponad 2,000 krytycznych zbiorów danych i wykrywa około 90% incydentów jakości danych, zanim dotrą do odbiorców downstream.

Netflix rozwiązał inny fragment tego samego problemu, budując ogólnofirmowy system pochodzenia danych, dzięki któremu każdy mógł odpowiedzieć, skąd pochodzi dany zbiór i co dotknęło go po drodze. System mapuje zależności między tematami Kafka, modelami ML i eksperymentami, a nie tylko tabelami w hurtowni. Podobnie jak w Uberze, platforma została zbudowana dla ludzi, a teraz stała się ważniejsza wraz ze wzrostem liczby aplikacji AI/LLM.

Razem Uber i Netflix obejmują dwie z czterech rzeczy, które warto budować. W praktyce myślę o tym jako o czterech wymiarach, z których każdy można mierzyć na własnych zasadach.

Poprawność: Czy każdy rekord odpowiada strukturze i regułom, którym powinien odpowiadać — właściwe typy pól, brak nieoczekiwanych wartości null, wartości w dopuszczalnym zakresie. Narzędzia takie jak Great Expectations i Soda dobrze sobie z tym radzą: automatyczna walidacja na poziomie wierszy i kolumn zamiast ręcznych kontroli po tym, jak coś się zepsuje. Należy śledzić odsetek rekordów przechodzących walidację w każdym uruchomieniu.

Aktualność: Czy dane są nadal aktualne względem swojego źródła, a nie tylko aktualne na moment ostatniej kontroli. Należy śledzić czas od ostatniej udanej aktualizacji dla każdego źródła, z SLA przypisanym do każdego zbioru danych zamiast jednego ogólnego progu, ponieważ niektóre źródła wymagają odświeżania co godzinę, a inne nie.

Spójność: Czy ten sam fakt jest odczytywany tak samo wszędzie tam, gdzie jest przechowywany lub indeksowany. To zawodzi po cichu — wychodzi na jaw dopiero wtedy, gdy dwa systemy zasilane tym samym źródłem zaczynają się ze sobą nie zgadzać. Okresowa kontrola krzyżowa między miejscami docelowymi downstream, oznaczająca wskaźnik niezgodności powyżej progu, wystarczy, aby wychwycić problem wcześnie.

Pochodzenie danych: Czy można prześledzić dowolny wynik z powrotem do jego źródła i każdej transformacji, przez którą przeszedł — to samo pytanie, na które Netflix zbudował swój system, by odpowiadać.

Nic z tego nie wymaga infrastruktury, której większość zespołów danych już nie ma. Wiem to, ponieważ sam to budowałem, a nie tylko argumentowałem za tym.

W Socure dane klientów przychodziły w dowolnej formie, w jakiej klient chciał je wysłać, a czasem były po cichu błędne. Wyzwanie polegało na zbudowaniu systemu, w którym niepoprawne dane można było zidentyfikować, zanim przepłynęły dalej. Zastosowanie miały te same zasady: walidować to, co przyszło, rozumieć, skąd pochodzi, i zapobiegać temu, by złe dane stały się problemem kogoś innego.

Great Expectations stał się częścią tego fundamentu: walidacja schematów i zakresów podczas przyjmowania danych, SLA aktualności dla poszczególnych źródeł, kontrole spójności między systemami oraz pochodzenie danych na poziomie plików. Wszystko to działało za wzorcem write-audit-publish, w którym dane trafiały do obszaru staging, były walidowane i przechodziły dalej tylko wtedy, gdy spełniały wymagane kontrole.

Rezultat był widoczny downstream: lepsza dokładność w całym środowisku — w raportowaniu, w modelach ML i w wyszukiwaniu AI zbudowanym na tych samych danych.

Co zrobić w poniedziałek rano

Jeśli uruchamiasz produkcyjnie systemy AI oparte na wyszukiwaniu, pytanie diagnostyczne nie brzmi, który model wypróbować jako następny ani do której architektury wyszukiwania migrować. Chodzi o cztery węższe pytania:

1. Czy dane bazowe są walidowane względem standardów wymaganych przez ich odbiorców?
2. Jaki jest najstarszy element treści obecnie serwowany z wysokim poziomem pewności?
3. Czy dwa fragmenty tego samego źródła mogłyby kiedykolwiek nie zgadzać się ze sobą w tym samym wyniku wyszukiwania?
4. Czy dałoby się prześledzić, skąd pochodził, gdyby okazał się błędny?

Jeśli nie potrafisz odpowiedzieć na te pytania, luka znajduje się w potoku między systemami źródłowymi a tym, z czego czyta twój agent. To wymaga naprawy w inżynierii danych, a nie wymiany modelu ani migracji do innego dostawcy.

Niezależnie od tego, czy budujesz potoki raportowania, systemy ML czy agentów AI, poprawność, aktualność, spójność i pochodzenie danych sprawiają, że dane są godne zaufania. AI po prostu ujawnia słabości, które od dawna istniały w inżynierii danych.