Mi az a RAG?

A RAG egy pipeline, nem egy modell

A lekérdezés-alapú generálás azt jelenti, hogy a modell az alkalmazásod által átadott szövegrészletekből válaszol, nem pedig abból, amit a betanítás során tárolt. A modell a pipeline utolsó lépése, nem az egésze. Valaminek először meg kell találnia a szövegrészleteket, és egy többnyelvű európai telepítésben ez általában három különálló modell, amelyek három különböző feladatot végeznek.

A felosztás látható az API-ban. Csak a végső szakasz egy OpenAI-kompatibilis chat-kiegészítés. A beágyazás és az újrarendezés saját hívások, saját modellekkel, és a router a kérés törzsében lévő mintát feladatként fogadja el: küldd el a „task”: „rag” mezőt a szabványos OpenAI mezők mellett, a névterezett llmeu objektumon belül.

A szakaszok és mindegyik feladata

Egyszeri indexelés: oszd fel a dokumentumokat darabokra, és minden darabot ágyazz be egy vektorba. Futásidőben: ágyazd be a kérdést, vedd a legközelebbi vektorokat, rendezd át ezeket a jelölteket egy keresztkódolóval, és add át a túlélőket a generátornak. Négy szakasz, amelyek közül három különböző modell lehet, és a válasz minőségének felső határát az határozza meg, amit a lekérdezés visszaadott. Egy jobb generátor sem tud válaszolni egy olyan szövegrészletből, amelyet soha nem kérdeztek le.

A katalógus két beágyazási modellt ajánl ehhez a feladathoz. A multilingual-e5-large egy 560M paraméteres XLM-RoBERTa modell MIT licenc alatt, amely körülbelül 100 nyelvet fed le, maximális szekvenciahossza 512 token a kártyáján, és nincs utasítási előtag a lekérdezésekhez – a dokumentumokat és a kérdéseket ezért ugyanúgy kell beágyazni. Az embeddinggemma-300m kisebb, 308M paraméterrel, 2048 token bemenetet fogad, és 768 dimenziót állít elő, amelyek Matryoshka reprezentációs tanulással 512-re, 256-ra vagy 128-ra csonkolhatók. A Google Gemma felhasználási feltételei szerint szállítják, nem OSI licenc alatt.

Mindkét ajánlott újrarendező keresztkódoló: pontozzák a lekérdezést egy szövegrészlet ellen, és nem tudnak sem indexet beágyazni, sem szöveget generálni, így a vektoros keresés után helyezkednek el. A gte-multilingual-reranker-base 305M paraméterrel rendelkezik, 8192 token bemeneti korláttal és 75 deklarált nyelvvel Apache-2.0 alatt, és a kártyája megjegyzi, hogy a közzétett példák 512 tokennél csonkolnak, hacsak nincs másképp konfigurálva. A llama-nemotron-rerank-1b-v2 1.24B paraméterrel rendelkezik OpenMDW-1.1 alatt, 26 nyelven értékelték, és akár 8192 tokent is fogad, közzétett benchmark pontszám nélkül.

A generátorhoz a Command R (08-2024) a ehhez a mintához írt kártya: 32.3B paraméter, 128K token kontextus és válaszok, amelyek a lekérdezett dokumentumokra hivatkoznak, CC-BY-NC-4.0 alatt, amely kizárja a kereskedelmi célú kiszolgálást. A Command A+ (05-2026) az Apache-2.0 megfelelője 218.75B paraméterrel, 48 nyelvet deklarálva, és szöveget és képeket fogad. A szkennelt papír először egy OCR modellen megy keresztül; a GLM-OCR egy 1.33B MIT modell, amelynek konfigurációja 131 072 szövegpozíciót tesz lehetővé hosszú dokumentumokhoz.

Darabolás a lánc legkisebb korlátjára

A lánc három korlátja 512, 2048 és 8192 token, és a legkisebb határozza meg. Ha a multilingual-e5-large modellel ágyazunk be, egy 900 tokenes darab csonkolódik a beágyazás során – csendesen, bármilyen jó is a generátor. Állítsd be a darab hosszát a beágyazási kártya alapján, ne a generátor kontextusablaka alapján.

Egy újrarendező egyetlen bemenetben látja a lekérdezést és a szövegrészletet, ezért tervezz mindkét felére, és szándékosan dönts a csonkolásról. Az újrarendezés egy előremenő passz jelöltenként, ezért adj neki egy rövid listát a vektoros keresésből, nem pedig a teljes indexet, és csak a túlélő szövegrészleteket add át a generátornak. A nyelvi listák akkor számítanak, ha a kérdés és a dokumentum eltér: a gte-multilingual-reranker-base 75 nyelvet deklarál, a llama-nemotron-rerank-1b-v2-t pedig 26 nyelven értékelték, így egy kártya listáján kívüli pár ellenőrizetlen az adott modellre nézve, nem pedig hibás – és egyetlen nyelvi lista sem helyettesíti a saját korpuszon végzett tesztet.

Mit tesz a router egy lekérdezési feladattal

A feladat illeszkedése a router pontszámának legfontosabb tényezője, és a rag feladat esetében a kontextusablakból számítják ki, mert egy modell, amely csak a rag címkét viseli, de nem tudja megtartani a darabokat, nem nyerhet. 8000 token alatt az illeszkedési pontszám 0.1-re esik; a jelöltkészletben a leghosszabb túlélő kontextus kapja a legmagasabb pontszámot, és egy címkézett modell ezen a hosszon teljes pontszámot kap. A lekérdezési modellekre is vonatkozik a szöveggenerálási szabály: egy beágyazási vagy újrarendező modell egyáltalán nem tud chat-kiegészítést válaszolni, és ha ilyet kérünk, not_a_text_model-t ad vissza üres válasz helyett.

A rezidencia minden szakaszra vonatkozik, nem csak az utolsóra. Egy lekérdezési pipeline a beágyazást, az újrarendezést és a generálást egy határon belül tartja, mert a lekérdezés eléri a beágyazási modellt, a szövegrészletek elérik az újrarendezőt, és az összeállított prompt eléri a generátort. Ha ezek közül az egyik más joghatóság alatt fut, mint amit ígértél, az ígéret már megszegődött, még akkor is, ha maga a chat hívás az EU-n belül lett irányítva. A router által alkalmazott szabály szűk és abszolút: a rezidencia egy szűrő a pontozás előtt, egy üres halmaz 409 no_endpoint_for_policy-t ad vissza, és a feladatátvétel nem léphet ki a szűrt halmazból.

Utólag ellenőrizhető válaszok

Két szokás teszi ellenőrizhetővé a lekérdezési telepítést. Tedd a generátort hivatkozóvá: csak a megadott szövegrészletekből válaszoljon, és mondja el, ha hiányzik a válasz, amit a Command R kártya kifejezetten megnevez. Ezután tartsd meg a nyomkövetést: minden válasz tartalmaz egy nyomkövetési azonosítót, és a tárolt sor elérhető ezen az azonosítón keresztül.

A megőrzés ehhez a rekordhoz tartozik. A nulla az alapértelmezett és az egyetlen megvalósított mód: a prompt és a kiegészítés törzse soha nem íródik az adatbázisba, és ezek az oszlopok null értékűek maradnak. Egy szabályzat tartalmazhat 24 órás, 7 napos vagy 30 napos választást, ami nem teszi lehetővé a tárolást – a szabályzat feletti kérés 403 retention_exceeds_policy-t ad vissza, és bármely engedélyezett, nullától eltérő tényleges megőrzés 501 retention_not_implemented-t ad vissza.

Még egy korlátot érdemes világosan megfogalmazni. A lekérdezés minőségét a korpuszodon mérik, vagy egyáltalán nem mérik, és az itt említett modellek egyikénél sem futtattak lekérdezési benchmarkot. Amit a kártyák tartalmaznak, az a kiadó saját feljegyzése: paraméterek száma, licencek, kontextuskorlátok és nyelvi listák, mindegyik a URL-lel, ahonnan olvasták.