Azok a táblázatok, amelyek nem léteztek

2. fejezet — Azok a táblázatok, amelyek nem léteztek

Egy északkelet-olaszországi gépgyár technikusa mesélte el nekünk egy eszpresszó mellett, a velenceiekre jellemző nyugalmmal, ami egy katasztrófát jelez előre: "A chatbotunk mindent tudott a motorról. Kivéve a motor adatai." Majd elmagyarázta. A belső AI asszisztensük tudta leírni a termékválasztékot, a felhasználási kontextust, a márka történetét, a versenyelőnyöket. Csodálatos volt narratív szempontból. De amikor egy ügyfél a CMP50L modell névleges nyomatékát kérdezte – azaz azt a műszaki adatot, amiért az emberek megnézik a katalógust, azt a számot, amiért motort vásárolnak – a chatbot homályosan válaszolt, néha hihetően, néha nem. Öt hónap fejlesztés, az operatív igazgató egyre zavartabb, és senki sem tudta megmondani, miért.

A diagnózis véletlenül, szinte unalomból érkezett, amikor a végtelennek tűnő, eredménytelen megbeszélés után kézzel vizsgáltam az adatbázist. A PDF katalógus 342 műszaki táblázatot tartalmazott. Az adatbázisban nulla érkezett. Nem néhány: nulla. Egyetlen táblázat sem. A PDF-ekből kitermelt táblázatokat kimentő kód columns és data mezőkbe mentette az adatokat, míg az azokat indexelő kód headers és rows mezőket várt. Egy meg nem tartott "szinonima". Egy belső egyezmény, amely egy elfelejtett refaktorálás során sérült meg. Az eredmény, öt csendes hónap után: a katalógus teljes numerikus intelligenciája – párok, teljesítmények, átmérők, súlyok, rendelési kódok, tápfeszültségek – elfolyt a csapból anélkül, hogy valaha is a pohárba öntöttek volna. Háromszáznegyvenkét táblázat, egyenként elvesztve liturgikus csendben.

Ez olyan hiba, ami nem kiált. Nem dob kivételeket, nem futtat le semmit, és nem jelenik meg a naplóban. Egyszerűen a világ egy része szűnik létezni a rendszered számára, és senki sem veszi észre, amíg egy felhasználó – általában egy dühös felhasználó – nem tesz fel elég kitartó kérdéseket, hogy feltárja a szakadékot. És ez egy jó példa egy sokkal nagyobb problémára, mint a mezőnevek: a generikus RAG keretrendszerek a folyó szövegre vannak optimalizálva – cikkekre, weboldalakra, elbeszélő bekezdésekre – és a táblákat másodrendű állampolgárként kezelik, ha egyáltalán kezelik. De az olasz vállalati dokumentumok gyakran táblák. Műszaki katalógusok, árfálisták, termékleírások, biztonsági adatlapok, rendelési közlemények: a dokumentumokat konzultáló személyek számára az értékes rész a táblázatos. Az, ami először elromlik, és amit senki sem vesz észre.

A tanulság nem az, hogy "figyelj a mezőnevekre". Sokkal nehezebb: egy komoly RAG-ben minden tartalomtípus – táblák, képek, alfanumerikus kódok, bekezdésvezető címek, láblécök – dedikált, tervezett, tesztelt kezelést igényel. És a működési teszt nem az, hogy "a chatbot válaszol egyszerű kérdésekre" – ehhez a rossz rendszereknek is tudnak válaszolni, mert elég ingadozó adat van ahhoz, hogy valamit meggyőzőnek építsenek. Az igazi teszt az, hogy "a chatbot válaszol olyan kérdésekre, amelyek minden egyes szakaszt kényszerítenek a pipeline-on". Specifikus, numerikus, ellenőrizhető kérdések. Olyan kérdések, amelyekre pontos és egyetlen válasz létezik, és ha a rendszer hibázik, azonnal tudod.

Ha ezt a tesztet nem végezd el, nem tudod, hogy a RAG-od működik-e. Csak azt tudod, hogy nem panaszkodik. És a "nem panaszkodik" egy nagyon alacsony minőségi kritérium egy olyan rendszerhez, amit az emberek döntéshozatalra használnak.