A stratégia mint dokumentum — A hetedik fejezet

6. fejezet — A stratégia mint dokumentum, nem mint kód

Eljutunk ahhoz a felismeréshez, amely a RAG-t építők történetében 2023 óta leggyakrabban ismétlődik, mint a „az, amit már az első naptól kezdve szerettem volna megérteni”.

A hagyományos keretrendszerek a keresési stratégiát Python kódként kezelik. Szeretné, a műszaki katalógusok esetében, először termékkód alapján, majd kulcsszavak alapján, majd szemantikus vektorok alapján keresni, és csak utolsó lépésként generálni a választ? Írjon egy függvényt. Szeretné, a fényképalbumok esetében, teljesen kihagyni a hagyományos szemantikus keresést, és egy képekre specializálódott újrarangsoroló rendszerre támaszkodni? Írjon egy másik függvényt. Szeretné, a vállalati videók esetében, elválasztani a hangot a vizuális sávtól, külön-külön átírni azokat, külön forrásként kezelni őket, majd összeállítani a végső válaszban? Még egy függvény. Minden tartalomtípus, minden terület, minden ügyfél végül egy olyan kódágat generál, amely eltér a másiktól, egészen addig, amíg a stratégia módosítása szoftverkiadást, kódellenőrzést, tesztciklust, telepítést igényel. A „van egy ötletem, hogyan javítsuk a műszaki kézikönyvek keresését” és a „az ötlet élesben van” közötti idő hetetekben mérhető. Minden ötlet esetében.

Az alternatív meglátás egyszerűen kimondható, de mélyreható következményekkel jár: a keresési stratégia nem kód. Egy dokumentum. Egy JSON – egy strukturált szöveges formátum, amit bármely szerkesztő fél óra képzéssel el tud olvasni – amely azt mondja: "először ezt próbáld ki, majd ezt, ha az első meghiúsul, menj a harmadikra, rangsorold át így, válaszolj ezzel a modellel." Ez a dokumentum egy adatbázisban él, nem egy tárolóban. Egy felületről módosítható, nem egy pull requesttel. Verziókövetésben rögzítik, másolják, és domain-specifikusra specializálják. Egy stratégia a műszaki katalógusokhoz, egy a fényalbumokhoz, egy a telepítési útmutatókhoz, egy a videókhoz, egy az audioanyagokhoz, egy a jogi szerződésekhez, egy az pénzügyi kimutatásokhoz. Mindegyik együtt létezik ugyanabban a rendszerben. Mindegyik valós időben módosítható.

Akik ezzel a megközelítéssel – nevezzük fantáziátlanul Meta-RAG-nak – dolgoztak, elmondják, hogy a sebességváltás az mérnöki kérdéseket is felülmúlja. Egy tipikus ügyféli kérés, például "adjunk hozzá egy specifikus keresést a termékkódokhoz, amelyek CMP40M vagy RH1M rövidítéseket tartalmaznak", többé nem egy két hetet igénybe vevő fejlesztési jegy. Ez egy új lépés, amelyet egy JSON eljáráshoz adunk, forró tesztelés egy staging környezetben, és egy délutánon belül élesítés. A kérdés "mi változik, ha más rangsort használunk a képekhez, a szöveghez pedig a jelenlegit?" egyetlen konfigurációs sor módosításával válaszolható meg. A kísérlet nem kerül semmibe, a visszavonás sem (csak a dokumentum előző verziójának helyreállítása), és a felhalmozott tudás – ami jól működik egy bizonyos típusú tartalomhoz – verziószámozott és átadható vagyonná válik, nem pedig annak a tudása, aki éppen ezt a kódrészt írta, és most szabadságon van.

Létezik egy érdekes társadalmi hatás is, amely azon szervezetekben mutatkozik meg, amelyek ezt a megközelítést alkalmazzák. A stratégiák dokumentumként való kezelésével elmosódik a határ a "fejlesztő" és a "tapasztalt felhasználó" között. Egy digitális könyvtáros, egy vállalati levéltáros, egy szakterületi szakértő – a műszaki iroda vezetője, a dokumentációs felelős, a termékmenedzser, aki jobban ismeri az ügyfelek valódi kérdéseit – elolvashat egy stratégiát, megértheti, mit csinál, javasolhat módosításokat, néha akár közvetlenül meg is írhatja azokat. Nem kell átmennie a fejlesztői jegyrendszeren, nem kell elmagyaráznia a fejlesztőnek olyan dolgokat, amiket a fejlesztő nem tud (mert nem az ő szakmája tudnia azokat). A RAG (Retrieval-Augmented Generation) abbahagyja, hogy egy fogyasztó termék legyen, és egy olyan eszközzé válik, amelyet a szervezeti tudásodra formálhatsz. Ez, akik kipróbálták, a projekt hangulatát változtatja meg még a mérőszámok előtt.

Ez nem varázslat, és költségei vannak. Szükség van egy olyan motorra, amely hatékonyan és biztonságosan hajtja végre ezeket a dokumentumként megfogalmazott stratégiákat. Szükség van egy olyan leíró nyelvre, amely elég gazdag ahhoz, hogy lefedje a valós eseteket, és elég szegényes ahhoz, hogy ne váljon egy újabb Turing-teljessé öltözött rendszerré. Szükség van verziókezelésre, tesztelésre, visszavonásra. De mindez a motor építőinek problémája – egyszer, és minden felhasználó számára. Az egyetlen végső felhasználó csak egy dolgot lát: a lehetőséget, hogy a kutatási stratégiáját a gondolkodás sebességével, nem pedig a szoftverkiadás ciklusának sebességével fejlessze. És ez, akik benne vannak, egy csendes forradalom, amely még nem találta meg a nevét a szakmai folyóiratokban.

Lezárás — A hetedik fejezet, néhány hónap múlva

2026 elején, az előző fejezetek tanulságait összegezve – az elveszett táblázatokat, a hazudozó újrarangsorolókat, az örökölt hallucinációkat, a gyorsabban növekvő felhőbeli számlákat, a sok ígéretet, de merev keretrendszereket – valaki Olaszországban elkezdett építeni egy másfajta RAG szervert. Pythonban írva, elérhető hardveren futtatható, képes a felhőbeli modellekkel kommunikálni, ha az előnyös, és a helyi modellekkel, ha a magánélet megköveteli vagy a költség nem éri meg. Egy olyan szerver, ahol a keresési stratégiák módosítható dokumentumok, az újrarangsoroló egy helyi GPU-folyamat, a táblázatok nem vesznek el, mert elsőrangú polgárként kezelik őket, a fényképek nem örökölnek tárgyakat más korok poros archívumaiból, és a lekérdezésenkénti költség – pénzben és harmadik félnek kiszivárgott adatokban – centenként ismert és szabályozható.

Nem fogjuk megnevezni a projektet. Ez nem az a cikk, amiben ezt megtennénk, és nem szeretnénk egy nyomozást reklámmá alakítani. De ha az előző fejezetek alapján felismered azt a helyzetet, amelyben te is vagy – egy vállalati chatbot, amely magabiztosan válaszol rossz kérdésekre, egy RAG projekt, amely hónapok óta nem halad, egy felhő számla, amely gyorsabban nő, mint az általa nyújtott hasznosság, vagy egy növekvő kétség, hogy a bizalmas dokumentumaid olyan helyekre kerülnek, amelyeket nem ismersz –, akkor érdemes tudni, hogy létezik egy másik út, amelyet valaki Olaszországban járt be, és amely 2026-ban kezdte megadni azokat az első válaszokat, amire 2023-ban számítottak.

A jó hír az, hogy a vállalati AI végre kilép a demó fázisból. A kevésbé jó hír az, hogy magával hozza az út során szerzett összes sebhelyet: felfújt keretrendszereket, szolgáltatói függőségeket, monolitikus architektúrákat, piszkos adatokat, néma hibákat és az iparág azon hajlamát, hogy megoldásokat adjon el, mielőtt még megértené a problémát. Hat fejezetben meséltük el ezeket. A hetedik – a történet arról, mi történik, amikor valaki végre jól csinálja a dolgokat, türelemmel, olaszul és nyílt forráskóddal – hamarosan megírjuk, kevesebb óvatossággal a nevekkel és több adattal az asztalon.

Közben, ha már idáig elolvastad, már több önvizsgálatot végeztél a döntéshozók 90%-ánál, akik jelenleg egy vállalati chatbot szerződést írnak alá anélkül, hogy feltérképeznék azokat a kérdéseket, amiket te feltettél ezeknek a fejezetek elolvasása közben. Ez jobb kiindulópont, mint amivel ők kezdték. És a következő hónapokban a különbség azok között, akik feltették ezeket a kérdéseket, és akik nem, nagyon látható lesz a számlákon – és a válaszokon, amiket a te AI-d ad a te ügyfeleidnek.

Ez a vizsgálat 2026 áprilisában készült, a 2024 végétől 2026 elejéig tartó tizennyolc hónapos vállalati RAG rendszerek tervezésének, építésének és optimalizálásának tapasztalata alapján.