A hat pólusú motor — A tíz soros kód mítosza

Hat részes sorozat az okokról, amiért a dokumentum chatbot, amit eladtak Önnek, továbbra is kitalál dolgokat – és arról az eltérő irányról, amit 2026 elején valaki elkezdett követni.

Hat részes sorozat az okokról, amiért a dokumentum chatbot, amit eladtak Önnek, továbbra is kitalál dolgokat – és arról az eltérő irányról, amit 2026 elején valaki elkezdett követni.

Bevezetés – A nyolcpólusú motor (de valójában hat volt)

Milánó, 2026 március. Egy vezető megnyitja a vállalati belső chatbotot, azokat, amelyeket az IT-osztály nagy lelkesedéssel és kevés bizalmatlansággal szerelt fel „két hét alatt”. Egyszerű kérdés: „Hány pólusa van a CMP40M motornak?” A chatbot teljes biztonsággal válaszol, ahogy a nagyméretű nyelvi modellek teszik: „A CMP40M motornak nyolc pólusa van.”

Helytelen. Hat van. A helyes válasz nem a 422 oldalas katalógusban rejtőzött, amelyet valaki hónapokkal korábban teljes bizalommal öntött egy vektor adatbázisba, meggyőződve arról, hogy onnantól kezdve a rendszer "mindent tudni fog". Ez az adat egyáltalán nem volt a katalógusban. Egy SEW technikusok által küldött e-mailhez csatolt PDF-ben volt, egy olyan mappában archiválva, amelyet senki sem vett a fáradságot indexelni.

Ez a jelenet, az iparág és a nyelvjárás változásaival, több száz olasz irodában megismétlődik. Az ígéret egyszerű és vonzó volt: adjuk meg az AI asszisztensnek az összes céges dokumentumot, és az képes lesz válaszolni bármilyen kérdésre azokra vonatkozóan. A valóság azonban sokkal prózaibb: a chatbot olvas, de nem érti, keres, de nem talál, és ha nem talál – ahelyett, hogy elmondaná – kitalál. Folyékonyan, tökéletes grammatikával, valószínű számokkal találja ki. Ez sokkal rosszabb, mint nem válaszolni.

2024 vége és 2026 eleje között hónapokat töltöttünk ezeknek a kudarcoknak a boncolásával. Nem a viták szítására, hanem hogy megértsünk valamit: miért válik egy ilyen lineáris gondolat – "adjuk meg a dokumentumokat, majd kérdezzük meg" – olyan nehézzé, amikor elhagyja a demo színpadát és belép a valódi szerverek szobájába.

Ez a hat fejezetből álló vizsgálat elárulja, amit találtunk: néma hibák, amelyek teljes katalógusokat töröltek, felhőalapú átrendezők helytelen pontszámokkal, hallucinációk, amelyek nem a modellből, hanem évekkel korábban szennyezett adatokból származtak, kimenő számlák, amelyek minden lekérdezést drágábbá tettek, és „népszerű” keretrendszerek, amelyek mindent ígérnek tíz sor kóddal, feltéve, hogy nem kérnek tőle túl sokat. És az utolsó fejezetben egy eltérő irány, amelyet valaki csendben kezdett el 2026 elején – egy olyan architektúra, amelyben a keresési stratégia abbahagyja a kódolást, és egy olyan dokumentummá válik, amelyet bárki a cégen belül olvashat és módosíthat.

Minden fejezet önállóan értelmezhető. Ha a 342 eltűnt tábláról, vagy a hazudó átrendezőről szeretnél olvasni, nyugodtan kezdd ott. De a történet egésze egy tanulságot rejt, amely csak a végén derül ki: a vállalati RAG – ez a technikai rövidítés a Retrieval-Augmented Generation kifejezést jelenti, vagyis „válaszok generálása először lekérdezett dokumentumok alapján” – még nem egy késztermék. Egy határvidék. És mint minden határvidék, eddig főként az eladók mesélték el. Itt az ideje, hogy azokat is meghallgassuk, akik belülről tapasztalták.

1. fejezet – A tíz soros kód mítosza

A diavetítés minden mesterséges intelligencia konferencián azonos 2023 óta: "A vállalati dokumentumkezelő asszisztensed 10 sor kóddal." A cím alatt egy pasztellszínű Python blokk látható, amely egy nyílt forráskódú könyvtárat – tipikusan egy híres amerikai könyvtárat, melynek neve fák vagy tibeti lámák láncolatait idézi – mutat, ami betölti a PDF fájlokat, feldarabolja azokat, beilleszti egy vektor adatbázisba, és egy nyelvi modellel kérdezi le. Öt perc alatt van egy chatbotod. Öt perc alatt tapsvihar. Öt perc alatt egy közepes méretű olasz vállalat meggyőződik arról, hogy a probléma megoldódott, és az IT részlege két hét alatt megoldja.

A probléma – amit a dia nem mond meg – az, hogy a demó három jól formázott PDF fájlból, egy tartalomhoz illesztett kérdésből, valós késlekedés nélküli színpadi előadásból és egy előadóból áll, aki huszonhét alkalommal próbálta ki az egészet a színpadra lépés előtt. A valóságban a vállalati dokumentumok egy geológiai katasztrófa: szkennelések szkenneléseiből, szövegre rétegzett táblázatokból, bekezdésekbe szivárgó lájegyzetekből, olyan alfanumerikus kódokból, mint a "RH1M", melyeket a chunker félbevág, mert szónak gondolja, képekből, amelyek a hasznos információ 70 százalékát tartalmazzák, de senki sem vonja ki őket, és olyan kreatív elrendezésből, amelyhez inkább régész, mint elemzőre van szükség.

A RAG – ez az ötlet a motorháztető alatt – egy nagyszerű ötlet. Vedd az felhasználói kérdést, keress a tárhelyeden a legrelevánsabb dokumentumokat, továbbítsd azokat a nyelvi modellnek, és kérj egy választ, ami ezeken a dokumentumokon alapul. Elméletileg elegánsan megoldja a hallucináció problémáját: a modellnek többé nem kell "tudnia" a választ, csak "el kell olvasnia" azokat a darabokat, amiket biztosítottál neki. A gyakorlatban a lánc minden egyes tagja – a darabolás, a beágyazás, a lekérés, az újrarangsorolás, a végső generálás – megtörhet, és a törés ritkán nyilvánul meg látható hibaként. Inkább egy enyhén helytelen válaszként jelenik meg. Aztán egy teljesen helytelen válaszként. Aztán egy vezetőként, aki azon tűnődik, miért fizet egy olyan rendszerért, ami kevesebbet tud, mint a gyakornok.

A nyílt forráskódú keretrendszerek, amelyek népszerűvé tették a RAG-ot, arra lettek kitalálva, hogy demonstráljanak, ne pedig hogy termeljenek. Nagyon elegáns absztrakciók láncolatai, amelyekben minden réteg egy hallgatólagos feltételezést rejt: hogy a PDF-jeid tisztességes OCR-rel rendelkeznek, hogy a fényképeidet már leírták, hogy a táblázataid egy konvenciót követnek, hogy a beágyazó modell valóban a te nyelveden beszél (spoiler: sokan csak angolul beszélnek jól), hogy az archívumod már megtisztították a duplikátumoktól. Amikor ezek közül egy feltételezés kudarcot vall — és legalább egy mindig kudarcot vall, gyakran három — a rendszer nem hagyja abba a működést. Sőt, rosszabb: abbahagyja a jól működést, de továbbra is ad válaszokat. Folyékony, biztos, és gyakran a valóságtól elrugaszkodó válaszokat.

Van egy mondás, ami azok között terjed, akik ezeket a rendszereket hivatásszerűen építik, és amit sosem fogsz olvasni a bemutatókban: "A RAG könnyű elkészíteni, és nehéz jól csinálni." Az első demó és az éles szolgáltatás között egy szakadék tátong, amit nem lehet GPU-k hozzáadásával vagy modellváltással áthidalni. Ezt a szakadékot azzal lehet áthidalni, ha megérted egy kellemetlen dolgot: amikor egy vállalati RAG-ot építesz, nem kódot írsz. Egy kis, makacs keresőmotort tervezel, amely a dokumentumaidra szabott, minden olyan szerkesztői döntéssel, amit ez magában foglal – mi a zaj, mi a jel, mit kell kétszer indexelni, mit kell eldobni. Csak a tízsoros bemutatókban ezeket a döntéseket valaki más hozza meg helyetted egyszer, aki sosem látta a dokumentumaidat. És szinte mindig ezek a döntések rosszak az adott esetre.