Tabele, których nie było

Rozdział 2 — Tabele, których nie było

Technik z firmy mechanicznej z północno-wschodniej Włoch opowiedział nam to przy espresso, z tą wenecką spokojem, który zwiastuje katastrofę: "Nasz chatbot wiedział wszystko o silniku. Oprócz danych silnika." Potem wyjaśnił. Ich wewnętrzny asystent AI potrafił opisywać gamę produktów, konteksty użycia, historię marki, przewagi konkurencyjne. Cudownie, pod względem narracyjnym. Ale kiedy klient pytał o nominalny moment obrotowy modelu CMP50L — czyli o dane techniczne, dla których ludzie otwierają katalog, liczbę, za którą kupuje się silnik — chatbot odpowiadał niejasno, czasem wiarygodnie, czasem nie. Pięć miesięcy rozwoju, coraz bardziej zdezorientowany dyrektor operacyjny i nikt nie potrafił powiedzieć dlaczego.

Diagnoza pojawiła się przypadkiem, niemal z nudów, podczas ręcznej inspekcji bazy danych po kolejnym bezowocnym spotkaniu. Katalog PDF zawierał 342 tabele techniczne. W bazie danych nie pojawiła się żadna. Nie kilka: zero. Żadna. Kod, który wyodrębniał tabele z plików PDF, zapisywał dane w polach o nazwach columns i data, podczas gdy kod, który je indeksował, oczekiwał pól o nazwach headers i rows. Niezachowane "synonim". Wewnętrzna konwencja, która przepadła w zapomnianym refaktoringu. Rezultat, przez pięć cichych miesięcy: cała inteligencja numeryczna katalogu — pary, moce, średnice, wagi, kody zamawiania, napięcia zasilania — wyciekała z kranu, nie będąc nigdy wlewana do szklanki. Trzysta czterdzieści dwie tabele, znikające jedna po drugiej w liturgicznej ciszy.

To jest rodzaj błędu, który nie krzyczy. Nie powoduje wyjątków, nic się nie zawiesza, nie pojawia się w żadnych logach. Po prostu część świata przestaje istnieć dla twojego systemu i nikt się o tym nie dowiaduje, dopóki użytkownik – zwykle zdenerwowany użytkownik – nie zada wystarczająco dużo uporczywych pytań, aby pokazać przepaść. I jest to symboliczne dla znacznie większego problemu niż nazwy pól: ogólne frameworki RAG są zoptymalizowane pod kątem bieżącego tekstu – artykułów, stron internetowych, akapitów narracyjnych – i traktują tabele jako obywateli drugiej kategorii, o ile w ogóle je traktują. Ale włoskie dokumenty firmowe *są* często tabelami. Katalogi techniczne, cenniki, specyfikacje produktów, karty bezpieczeństwa, biuletyny zamówień: dla osób konsultujących te dokumenty, to część tabelaryczna jest cenna. To ona psuje się jako pierwsza i nikt tego nie zauważa.

Lekcja nie polega na tym, żeby "uważać na nazwy pól". Jest bardziej kłopotliwa: w poważnym systemie RAG każdy rodzaj treści — tabele, obrazy, kody alfanumeryczne, nagłówki akapitów, przypisy — wymaga dedykowanego, zaprojektowanego i przetestowanego podejścia. A test działania to nie jest "chatbot odpowiada na banalne pytania" — na takie odpowiadają nawet uszkodzone systemy, ponieważ wystarczająco dużo danych pozwala na skonstruowanie czegoś wiarygodnego. Prawdziwy test to "chatbot odpowiada na pytania, które zmuszają go do dotknięcia każdego elementu potoku". Konkretne, numeryczne, weryfikowalne pytania. Pytania, na które istnieje jedna prawidłowa odpowiedź i jeśli system się pomyli, od razu się o tym dowiesz.

Jeśli nie przeprowadzisz tego testu, nie wiesz, czy Twój RAG działa. Wiesz tylko, że się nie skarży. A "nie skarży się" to bardzo niski standard jakości dla systemu, którego ludzie będą używać do podejmowania decyzji.