Mi az az LLM retriever, és melyik többnyelvű beágyazási modellt használjam?

Két feladat, két különböző modell

A retriever nem egy modell. Egy szövegrészlet megtalálása a saját dokumentumaiban először egy reprezentációs modellt, másodszor pedig egy rangsoroló modellt igényel: egy beágyazási modell szöveget vektorokká alakít, hogy a hasonlósági keresés szűkítse a jelöltek körét, és egy reranker pontozza a szűkített szövegrészletet a lekérdezéshez képest, hogy a legjobb közülük kerüljön a promptba. A generátor a harmadik szakasz, és ez az egyetlen szakasz, amely az OpenAI chat formátumot beszéli.

Mindkét típusú modell megtalálható ebben a katalógusban teljes kártyákkal, és mindkettő nem utasításra hangolt modellként van rögzítve, mert egyik sem arra van kiképezve, hogy kérést kövessen. Egy beágyazási modell vektort ad vissza; egy reranker relevancia pontszámot ad vissza. Tegyen fel bármelyiknek kérdést, és nincs válasz, amit adhatna.

multilingual-e5-large: az alapértelmezett európai választás

A multilingual-e5-large egy 560 millió paraméteres szövegbeágyazási modell, amely XLM-RoBERTa-ra épül, MIT licenc alatt jelent meg, és körülbelül száz nyelvet fed le. Két rögzített részlet dönti el, hogyan használja. A modellkártyája 512 token maximális szekvenciahosszt használ, ami az indexelés és a lekérdezés tényleges korlátja. És nincs utasítási előtagja a lekérdezésekhez, így a dokumentumokat és a lekérdezéseket ugyanúgy kell beágyazni – nincs lekérdezés-oldali sablon, nincs előtag, amit elfelejt az egyik úton.

Az MIT licenc az oka annak, hogy a szabályozott környezetben működő csapatok itt kezdik: megengedő és rövid. Az 512 tokenes plafon az oka annak, hogy a darabjaikat 400-500 token körül méretezik, nem pedig a generátor kontextusablaka körül.

embeddinggemma-300m: hosszabb bemenet, nagyobb vektorok

Az embeddinggemma-300m paraméterekben kisebb – 308 millió – és abban nagyobb, amit elfogad: 2048 token maximális bemeneti hossz és egy 768 dimenziós kimenet, amelyet a Matryoshka reprezentációs tanulás lehetővé tesz 512, 256 vagy 128 dimenzióra való csonkításra újratanítás nélkül. A modellkártya több mint száz beszélt nyelven rögzíti a képzési adatokat.

A kártyán rögzített kompromisszum a licenc. A Google Gemma felhasználási feltételei szerint szállítják, nem pedig OSI licenc alatt, és a kártya ezt közvetlenül kimondja. Ha a termékdöntése megengedő licencet igényel, az az egyetlen sor a döntő tény, nem a benchmark táblázat. Ha nem, a 2048 tokenes bemenet megváltoztatja a darabolás módját: kevesebb, hosszabb szövegrészlet és kevesebb kontextusvesztés a határon.

Rerankerek: az olcsó minőségi nyereség

Mindkét reranker itt keresztkódoló. Nem tudnak indexet beágyazni és nem tudnak szöveget generálni; egy lekérdezést és egy szövegrészletet együtt vesznek, és pontszámot adnak, ami a vektoros keresés után helyezi őket, soha nem helyette.

A gte-multilingual-reranker-base 305 millió paraméterrel rendelkezik Apache-2.0 alatt, 8192 token bemeneti korláttal és 75 deklarált nyelvvel, és a kártyája megjegyzi, hogy a közzétett példák 512 tokennél csonkítják a bemeneteket, hacsak másképp nem konfigurálja. A llama-nemotron-rerank-1b-v2 nagyobb, 1,24 milliárd paraméterrel OpenMDW-1.1 alatt, 26 nyelven értékelték, 8192 tokenig működik, és nincs közzétett benchmark pontszáma a modellkártyáján.

Két gyakorlati következménye van ezeknek a soroknak. A rangsorolás jelöltenként egy előremenő passz, ezért a rerankernek a vektoros keresésből származó rövid listát adja, nem pedig a teljes indexet. És egy nyelvi lista egy értékelési állítás, nem garancia: egy lekérdezés és dokumentum pár a kártyán deklarált nyelveken kívül ellenőrizetlen az adott modellre nézve, ami ok arra, hogy saját korpuszon teszteljen, nem pedig ok arra, hogy feltételezze a hibát.

Az API oldal, ezen a telepítésen

A beágyazás saját útvonal, és egy hosztolt beágyazási modellre van szüksége. Ebben a buildben a determinisztikus helyi backend adja vissza a vektorokat, és a válasz egy mock jelölőt tartalmaz, mert a valós beágyazási súlyokat nem ezen a telepítésen szolgálják ki. Ez a közzététel szándékosan szerepel a válasz törzsében: egy valódinak tűnő vektor, amely egy helyettesítőtől származik, lenne a legrosszabb dolog, amit szállítani lehet. Maga a vektorindex az Ön feladata – ez a platform beágyaz, nem tárolja a vektorait.

A lekérdezés mint feladat első osztályú érték a kérésben: egy chat hívás a standard mezők mellett rag feladatot is tartalmazhat, és a router a jelölteket pontozza ehhez, a kontextus hossza a domináns tényező. Egy modell, amely csak lekérdezési címkét visel, de nem tudja tárolni a darabokat, nem nyerhet, ezért egy olyan jelölt, amelynek dokumentált ablaka 8k token alatt van, sokkal alacsonyabb pontszámot kap, mint egy, amelyik belefér.

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

Egy lekérdezési pipeline korlátai 512, 2048 és 8192 token, és a legkisebb irányít. multilingual-e5-large-val beágyazva egy 900 tokenes darab csonkolódik a beágyazás során, csendesen, bármilyen jó is a generátor utána. Állítsa be a darab hosszát a beágyazási kártyáról, nem a generátor kontextusablakáról, és ne feledje, hogy egy reranker a lekérdezést és a szövegrészletet egyetlen bemenetként látja, így mindkét fele osztozik a 8192 tokenes költségvetésén.

Egy határ a teljes pipeline-ra

A lekérdezés rétegenként megsérti a rezidencia ígéretét. A lekérdezés eléri a beágyazási modellt, a szövegrészletek elérik a rerankert, az összeállított prompt eléri a generátort – és ha bármelyik olyan helyen fut, amit nem ígért, az ígéret már megszegődött, még akkor is, ha maga a chat hívás helyesen lett irányítva. Az ebből következő szabály az, hogy mindhárom szakaszt ugyanazon a határon belül kell tartani.

Ezen a platformon a mechanizmus inkább szűrő, mint preferencia: a rezidenciát a pontozás előtt alkalmazzák, a feladatátvétel nem hagyhatja el a szűrt halmazt, és egy ellenőrizhetetlen osztály egyáltalán nem címezhető rezidencia. Ha semmi sem felel meg a szabálynak, a kérés 409 no_endpoint_for_policy hibát ad vissza egy közeli válasz helyett.

Választás a két beágyazási kártya között

Döntse el a licencet és a darab méretét, ebben a sorrendben, és hagyja, hogy a dimenziószám rendezze a tárolási számlát utána. A multilingual-e5-large MIT licenccel és 512 tokenes darabokkal a biztonságos alapértelmezett egy bekezdésekből álló korpuszhoz. Az embeddinggemma-300m 2048 tokenes bemenettel és egy csonkolható 768 dimenziós kimenettel olyan dokumentumokhoz illeszkedik, amelyek elveszítik jelentésüket, ha röviden felosztják őket, a Gemma feltételeinek költségén, nem pedig OSI licenc alatt. Egyik kártya sem tartalmaz az LLM EU által futtatott lekérdezési benchmarkot, és egyetlen nyelvi lista sem helyettesíti a saját dokumentumain végzett tesztet.