RAG és JSON — miért nem elég a keresés önmagában?

TL;DR

TL;DR: A RAG rendszerek megtalálják a releváns szöveget, de a szabad formátumú generálás kiszámíthatatlan kimenetet ad. A JSON-réteg nem technikai finomkodás, hanem az AI megbízhatóságának alapja: konzisztens formátumot, bizonyosságmérést és forrásellenőrizhetőséget biztosít egyszerre. Ez a különbség a kutatási prototípus és a termelési rendszer között. A valódi kihívás nem a releváns szöveg megtalálása, hanem annak strukturált, gépi értelmezésre alkalmas formában történő visszaadása.

Koppenhágai kikötő, szeles reggel

A kikötőben ülök, a hideg szél fúj a hajamba. A víz sötét és hullámos, a konténerek szigorú sorokban állnak a dokkok mentén. Minden rakománynak van egy pontos helye, egy kódja, egy nyilvántartása. Látom a daruk mozgását – precíz, ismétlődő, kiszámítható. A hajók érkeznek, kiraknak valamit, majd azt továbbviszik. Pontosan tudják, mit hova kell tenni.

És mégis. A víz felszínén a hullámok kiszámíthatatlanok. A szél felsepri egy papírdarabot, ami céltalanul száll a levegőben. Van egy rend, de az információ – mint ez a papír – könnyen elveszhet, ha nincs megfelelő formába zárva.

Gondolok a konténerek pontos rendjére. Minden doboznak van egy célja, egy struktúrája. Mi történne, ha csak úgy bedobnánk a rakományt a dokkba, anélkül, hogy felírnánk a címét?

Az űrlap, amit senki nem tölt ki

A RAG (Retrieval-Augmented Generation) rendszerek megtalálják a releváns szöveget, de a szabad formátumú generálás kiszámíthatatlan kimenetet ad. A JSON-struktúra egyszerre három problémát old meg: konzisztens formátumot, bizonyosságmérést és forrásellenőrizhetőséget biztosít. Ez a réteg a különbség a kutatási prototípus és a termelési rendszer között.

Egy januári délután a lakás asztalán három ChatGPT-válasz feküdt egymás mellett. Mindhárom ugyanarra a kérdésre válaszolt: „Mennyi szabadság jár nekem a cégnél?” Az első azt írta: „Évi 25 nap jár a HR szabályzat szerint.” A második: „Huszonöt munkanap szabadság illeti meg a dolgozókat.” A harmadik: „Lásd a HR Policy 2024 PDF dokumentumot, 12. oldal.”

Mindhárom helyes. Egy ember érti, miről van szó. De mi van, ha ezt a választ egy másik rendszernek kell feldolgoznia? Egy applikációnak, ami automatikusan beírja a szabadságnapok számát egy táblázatba? Vagy egy payroll rendszernek, ami kalkulálja a szabadságdíjat? A szabad szöveg értelmezése emberi kognícióval triviális, de determinisztikus szoftverlogika számára egy megoldatlan problémává válik.

Ez olyan, mintha egy pénztárgépnél néha így írnák ki az árat: „1500 Ft”, néha így: „Ezerötszáz forint”, néha pedig: „Lásd az árlistát.” A pénztáros érti — de a bankkártya-terminál nem tudja feldolgozni. A modern vállalati szoftverek egyik legnagyobb előnye a folyamatok automatizálása, de ez csak akkor működik, ha az információcserének szigorú szintaxisa van. A JSON pontosan ezt a szintaxist szolgáltatja.

Miért nem elég a szabad szöveges válasz?

A Retrieval-Augmented Generation (visszakeresés-alapú szöveggenerálás) paradigma 2020-as bevezetése óta az enterprise AI alkalmazások alapkövévé vált. A koncepció elegáns: a retrieval komponens (visszakereső réteg) releváns dokumentumokat talál a tudásbázisban, míg a generációs komponens értelmezi és szintetizálja ezeket koherens válasszá. Ahogy a [CORPUS] is rámutat, a RAG rendszerek lényegében egy lekérdezést vesznek, vektor-embeddinggé alakítják, keresnek releváns dokumentumokat, és ezeket átadják a modellnek, hogy kontextushoz illő választ generáljon.

De van egy alapvető, gyakran figyelmen kívül hagyott probléma. A retrieval megtalálja a releváns szövegrészeket — és aztán a modell szabadon fogalmaz. Szabad szöveg. Természetes nyelv. Olvasható, de nem feldolgozható. A naiv RAG sikeréhez két dolog kell: hogy a felhasználó kérdése jól megfogalmazott legyen, és hogy az adat jól strukturált legyen [CORPUS]. De mi van a válasz strukturáltságával?

Amikor egy cég AI-alapú ügyfélszolgálatot, belső keresőrendszert vagy automatizált asszisztenst épít, ezek a rendszerek nem önmagukban működnek. Összekapcsolódnak más szoftverekkel: CRM-rendszerekkel, táblázatkezelőkkel, e-mail küldőkkel, dashboardokkal. Ha az AI válasza szabad szöveg, akkor minden egyes összekapcsolásnál valakinek meg kell próbálnia „kitalálni”, hol van a lényeg a válaszban. Mintha minden levelet kézzel kellene kiböngészni, ahelyett hogy egy jól kitöltött űrlapot kapnánk. Ez a probléma fokozódik, amikor a RAG rendszert olyan komplex feladatokra használjuk, amelyek kiterjedt háttértudást igényelnek, ami gyakran meghaladja a modell kontextusablakát — mint például teljes kódbázisok elemzése vagy több könyv összehasonlítása [CORPUS].

Az űrlap megoldása: JSON

A JSON (JavaScript Object Notation) egy egyszerű formátum, amit mind az emberek, mind a gépek könnyen olvasnak. Olyan, mint egy kitöltendő űrlap: vannak előre meghatározott mezők, és mindegyikbe a megfelelő információ kerül. Ez a struktúra nem csupán egy formátum, hanem egy szerződés a generáló AI és a fogyasztó rendszer között.

Ahelyett, hogy az AI szabadon fogalmazna, megkérjük, hogy töltse ki az űrlapot:

{
  "válasz": "25 nap",
  "bizonyosság": 0.95,
  "forrás": [
    {
      "dokumentum": "HR_Policy_2024.pdf",
      "oldal": 12,
      "chunk_id": "hr_policy_sec_4.2"
    }
  ],
  "pontos_idézet": "A munkavállalót évente 25 munkanap szabadság illeti meg.",
  "művelet": "INFORM",
  "további_meccsek": [
    {"dokumentum": "Employee_Handbook.pdf", "relevancia": 0.87}
  ]
}

Ez a megközelítés három alapvető problémát old meg egyszerre, és további rétegeket épít rá:

1. Konzisztencia. A válasz mindig ugyanolyan formátumú. Nem kell kitalálni, melyik részben van a szám, melyikben a forrás. Az applikáció azonnal feldolgozza a válasz mezőt, anélkül, hogy természetes nyelvfeldolgozást (NLP) kellene futtatnia rá. Ez a determinisztikus viselkedés alapja.

2. Bizonyosságmérés és meta-információ. Azonnal látjuk, mennyire biztos benne az AI. Egy 95%-os bizonyosság más döntést igényel, mint egy 40%-os. Szabad szövegben ez az információ elvész — vagy meg sem születik. A JSON lehetővé teszi meta-információk, például a válasz típusának (művelet: INFORM, CALCULATE, RECOMMEND) vagy alternatív találatok listájának (további_meccsek) beágyazását is, ami a válasz gazdagságát növeli anélkül, hogy összezavarná a fő üzenetet.

3. Forrásellenőrizhetőség és visszakövethetőség. A pontos idézet és a strukturált forráshivatkozás (akár több forrás listája) lehetővé teszi, hogy bárki ellenőrizze: tényleg ezt írja-e az eredeti dokumentum. Ez nem paranoia — ez a megbízhatóság architektúrája. A chunk_id vagy egy egyedi dokumentumazonosító lehetővé teszi a pontos szegmens visszakeresését a vektortárban, ami kritikus a hibakereséshez és a rendszer finomhangolásához. Ahogy a [CORPUS] is hangsúlyozza, a RAG nemcsak csökkenti a hallucinációkat és javítja a tényességet, hanem lehetővé teszi, hogy a modell belső cégadatokra vagy specifikus adatforrásokra épüljön — ennek a „grounding”-nak a sikeressége közvetlenül függ a források egyértelmű azonosíthatóságától.

Miért nem technikai finomkodás ez?

A JSON-réteg a RAG-rendszerben nem egy extra feature, amit a fejlesztők kedvtelésből tesznek bele. Ez az a réteg, amely a kutatási prototípust termelési rendszerré alakítja. A prototípus célja a koncepció bizonyítása: működik-e a retrieval, értelmes választ ad-e a modell? A termelési rendszer célja azonban az üzleti érték megbízható, skálázható és költséghatékony szállítása.

Prototípusban elegendő, ha az AI jó válaszokat ad szabad szövegben. Termelési rendszerben nem elegendő. Termelési rendszerben a válasznak:

Parsezhetőnek kell lennie (más szoftver tudja olvasni anélkül, hogy komplex NLP modelleket kellene bevetni).
Validálhatónak kell lennie (lehetőség kell legyen az eredeti forrás automatikus vagy manuális ellenőrzésére).
Verziózhatónak kell lennie (visszakövethető, melyik dokumentum-verzió alapján válaszolt, ami kritikus a jogi megfelelőség vagy audit esetén).
Mérhetőnek kell lennie (bizonyossági szint, relevancia-score, amelyek alapján nyomon követhetjük a rendszer teljesítményét és megbízhatóságát).

Ezek nem luxusfunkciók. Ezek a különbségek egy „ügyes demó” és egy „megbízható rendszer” között. Gondoljunk csak egy olyan hibrid keresőrendszerre, amely a [CORPUS] által említett módon kombinálja a pontos egyezéses (keyword) és a vektoros keresés erősségeit. Ennek a rendszernek a kimenete nem lehet egy homogén szövegtömeg; tartalmaznia kell metaadatokat arról, hogy melyik találat melyik módszerből származik, milyen rangszámmal rendelkezik. Ez a struktúra csak JSON-ben (vagy hasonló formátumban) tud kifejeződni.

A valódi 80/20 és a strukturálás gyakorlata

Minden RAG-implementáció ugyanazt a leckét tanítja meg: az adat előkészítése a munka 80%-a. A technológia, az embedding modell, a vektordatbázis — ezek a maradék 20%. A JSON-réteg pontosan ebbe a 80%-ba tartozik. Nem az AI intelligenciáját növeli — hanem a kimenet használhatóságát biztosítja. Mint az űrlap a közigazgatásban: nem azért töltetjük ki, mert bürokraták vagyunk, hanem azért, mert az a rendszer, amelyik feldolgozza, csak így érti meg.

A gyakorlatban a JSON-séma megtervezése együttműködési folyamat. Nem csak a technikai csapat feladata. Üzleti elemzőkkel együtt kell meghatározni: Milyen mezőkre van szükség a downstream folyamatokban? Kell-e egy határidő mező, ha a válasz egy feladatról szól? Kell-e egy érvényesség_dátuma a jogszabályi hivatkozáshoz? Ez a tervezési fázis teszi lehetővé, hogy a RAG rendszer ne csak „válaszoljon”, hanem integrálható üzleti eszközzé váljon.

Az AI válaszát is érdemes „űrlaposítani”. Hogy minden rendszer értse, és minden válasz ellenőrizhető legyen. Ez a lépés teszi lehetővé a teljes körű automatizálást: a JSON válasz közvetlenül betölthető egy JIRA ticketbe, frissíthet egy Salesforce rekordot vagy triggerelhet egy approval workflow-t anélkül, hogy emberi beavatkozásra lenne szükség.

Key Takeaways

A retrieval a kezdet, nem a vég. A RAG rendszer igazi értéke nem a releváns szövegrész megtalálásában rejlik, hanem annak feldolgozható formában történő visszaadásában. A szabad szöveg emberi kommunikációra optimális, de gépi integrációra alkalmatlan.
A JSON egy szerződés, nem csak formátum. Egy előre meghatározott JSON-séma szerződést köt a generáló AI és a fogyasztó rendszer között, garantálva a konzisztenciát, a parsezhetőséget és a visszakövethetőséget. Ez a szerződés teszi lehetővé a megbízható automatizálást.
A strukturált kimenet a megbízhatóság alapja. A bizonyossági szint, a strukturált forráshivatkozások és a meta-információk (pl. választípus) beágyazása nem extra, hanem alapvető funkció. Ezek teszik lehetővé a válasz validálását, a rendszer teljesítményének mérését és a hallucinációk kockázatának kezelését.
A prototípus és a termelés között híd a struktúra. Egy kutatási prototípus célja a koncepció bizonyítása, míg egy termelési rendszeré az üzleti érték megbízható szállítása. A két világot összekötő híd a szigorúan definiált, gépi olvasható kimeneti formátum.
A tervezés a munka nagy része. A RAG rendszer sikere nem annyira a legújabb embedding modelltől függ, hanem attól, mennyire gondosan terveztük meg az információ folyamatát — beleértve a kimeneti sémát. Ez az igazi 80/20 szabály.
A JSON lehetővé teszi az okosabb integrációt. Strukturált válaszokkal a RAG rendszer képes jelezni a bizonytalanságot, alternatív találatokat felkínálni, és egyértelmű műveleti utasításokat adni, ezzel egy magasabb szintű, kontextusérzékeny interakciót lehetővé téve a szoftverek között.

Gyakran Ismételt Kérdések

Miért nem elég, ha az AI jó szöveges választ ad?

Mert az emberi olvasás és a gépi feldolgozás különböző dolgot igényel. Egy ember érti, hogy az “Évi 25 nap” és a “Huszonöt munkanap” ugyanaz, de egy másik rendszer nem tudja parszelni anélkül, hogy ne használna komplex és hibára hajlamos nyelvi modelleket. Termelési környezetben az AI válaszát más szoftvereknek kell feldolgozniuk: CRM-rendszereknek, dashboardoknak, automatizációknak. Szabad szövegből ez nem lehetséges megbízhatóan és skálázhatóan. A RAG eredetileg azért jött létre, hogy leküzdje a modell kontextusablakának korlátait és hatékonyabban használja fel az információt [CORPUS]; ennek a célnak a teljes elérése csak strukturált kimenettel lehetséges.

Mennyire bonyolult a JSON-réteg bevezetése egy meglévő RAG-rendszerbe?

A JSON-réteg nem a rendszer újraépítését igényli, hanem a generációs komponens kimenetének strukturálását. A legtöbb modern LLM (Large Language Model) képes JSON-formátumú válaszokat adni, ha a prompt vagy a rendszerkonfigurálás tartalmazza a sémát (pl. a promptban részletesen leírjuk a kívánt JSON struktúrát). A valódi munka — és a legnagyobb kihívás — az elvárt mezők megtervezésében van: milyen információt kérsz vissza, milyen bizonyossági szintet, milyen részletességgel strukturált forráshivatkozást. Ez egy tervezési és egyeztetési feladat, nem feltétlenül egy mély technikai átalakítás.

Hogyan segít a JSON a hallucinációk kezelésében?

A JSON-struktúra önmagában nem szünteti meg a hallucinációt, de mérhető és ellenőrizhetővé teszi annak kockázatát. A bizonyosság mező azonnal jelzi, mennyire magabiztos az AI (alacsony érték riasztást indíthat). A strukturált forrás mező lehetővé teszi a visszakeresést és automatikus vagy emberi ellenőrzést: egy egyszerű szkript összevetheti a pontos_idézet-et a forrásdokumentum valódi tartalmával. Szabad szövegben ezek az információk vagy elvesznek, vagy egyáltalán nem jönnek létre, és a hallucinált válasz ugyanolyan meggyőző stílusban és formában jelenik meg, mint a helyes, ami nagyon veszélyes lehet.

Nem korlátozza a JSON a modell kreativitását és részletességét?

Nem, inkább irányítja és strukturálja. A modell továbbra is kreatívan dolgozhat fel információt a megadott mezők keretein belül. A válasz mező lehet hosszú, jól megfogalmazott szöveg. A kreativitás korlátja nem a JSON, hanem a rosszul megtervezett séma. Ha a séma tartalmaz magyarázat vagy háttér mezőket, a modell ott fejtheti ki részletesen a gondolatmenetét. A struktúra a zajt szűri ki, nem a lényeget.

Kapcsolódó gondolatok

Varga Zoltán - LinkedIn Neural • Knowledge Systems Architect | Enterprise RAG architect PKM • AI Ecosystems | Neural Awareness • Consciousness & Leadership Structure is not bureaucracy. Structure is trust.