← Vissza az cikkekhez
Quando l'AI aziendale non sa quello che sa Fejezet 3 ból 6
AI 2026-04-16 ProtoMedia

A hazudó átrangsoroló

Automatikus fordítás · olvasd az eredetit

3. fejezet — A hazudó átrangsoroló

A RAG technikai szlengjében van egy kulcsfigura, ami nem túl látványos és keveset beszélnek róla: az átrangsoroló. Képzeld el a vállalati keresést egy szórakozóhely bejárataként. A vektor adatbázis a portás: gyorsan megnézi a tömeget, és harminc jelöltet beenged, akik első ránézésre hasonlítanak arra, amit keresel. Az átrangsoroló a belső ajtóóró: átnézi ezeket a harmincat, alaposan megvizsgálja őket, kiválaszt ötöt — azokat, amelyeket az LLM tényleg elolvas majd a válasz megalkotásához — és visszaküldi a többi huszonötöt. Ez egy kis, de hatalmas funkció: ha ő hibázik, mindenki hibázik. Ha az ajtóóró nem tud arcokat olvasni, a hely megtelik a rossz emberekkel, és senki sem fogja megérteni, miért ment tönkre a buli.

2025-ben több felhőszolgáltatás jelent meg a piacon, amelyek API-ként kínálták az átrangsorolókat. Küldesz egy kérdést és egy dokumentumlistát, és visszakapod az pontszámokat. Kényelmes, skálázható, nem kell GPU-t vásárolni, nem kell modelleket letölteni. Egy híres európai modellszolgáltató — név nélkül, de tudod, mely neveket kerülni próbáljuk — egy ígéretes Qwen családbeli, négy milliárd paraméteres modellt tett közzé, "Átrangsoroló" néven. Az ár elfogadható volt, a válaszidő elfogadható. Bárki, ebben a történelmi pillanatban, ezt választotta volna. Sokan választották.

Kivéve, hogy a pontszámok rosszak voltak. Nem "csak" rosszak, ahogy ez bármelyik modellnél előfordulhat: strukturálisan rosszak. Egyértelműen releváns dokumentumok 0,2-t, témán kívüli dokumentumok 0,8-at kaptak. Az első gyanúsítások, mint ilyen esetekben mindig, a szokásos bűnösökre irányultak: a beágyazó modell, a chunking, a lekérdezés megfogalmazása, a dokumentumok előfeldolgozása. Hetekig tartó téves nyomozás. Csak a reranker felhőbeli válaszainak szisztematikus összehasonlítása egy referencia helyi rerankerrel – ugyanaz a bemenet, ugyanazok a dokumentumok, a pontszámok egymás mellé helyezve egy Excel táblázatban – tárta fel a kellemetlen igazságot: az API-n keresztül elérhető modell hibás volt. Talán egy hibás telepítés, talán egy véletlenül feltöltött rossz verzió, talán egy hiba a pontszámok szerializálásában. A szolgáltató soha nem ismerte be hivatalosan. A probléma azonban egyszerűen eltűnt egy napon, egy néma frissítés után és a kiadási megjegyzésekben sem történt változás.

Ennek a történetnek a lényege nem az, hogy "a felhőszolgáltatások hibáznak" — mindenki hibázik, még a helyi modellek is. A lényeg finomabb: egy komoly RAG-rendszerben a reranker egy olyan elem, amibe be kell tudni látni. Ha ez egy fizetős fekete doboz, és ha a kimenetei olyan számok, amelyek valószínűnek tűnnek még akkor is, ha véletlenszerűek — és a reranker pontszámai mindig valószínűnek tűnnek, mert nullától egyig terjedő számok néhány tizedesjeggyel —, nincs módod arra, hogy megértsd, mi a hiba a rendszeredben. Mivel a reranker a "csővezeték végén" van, a hibája minden előző értékelést szennyez: a keresés lassanak tűnik, a lekérdezés hibás, a beágyazások gyengék. Valójában a biztonsági őr nem tud arcokat olvasni, te pedig a bejárat üvegét kérdőjelezed meg.

Néhány csapat ellentrenddel szemben menve – ahelyett, hogy még több felhőalapú megoldást alkalmaznának, visszatértek a gyökerekhez – úgy döntöttek, hogy a rerankert visszahozzák a házba. Egy nem túl nagy, nyílt forráskódú BGE családbeli modell, amit helyi GPU-n futtatnak (akár Apple Siliconon is, bár a driverekkel óvatosan kell bánni). Több adminisztrációs munka, az igaz. De lehetőség van kontrollált kísérletezésre, megérteni, hogy mikor hibázik, összehasonlítani a verziókat, és fenntartani a történelmi adatokat. És – nem utolsósorban – nem kell minden egyes felhasználói keresés után egy centfrakciót fizetni az API-nak. Ez a frakció, ha több tízezer lekérdezéssel szorozzuk egy hónap alatt, gyorsan nem egy frakció, hanem egy költségtételek lesz.

Amikor egy komponens olyan kritikus, hogy annak hibája tönkreteszi a teljes mérési képességedet, akkor nem hatékonyság a delegálása egy fekete dobozra. Ez egy hitbeli cselekedet. A hitbeli cselekedetek pedig gyártásban kamatos kamattal fizetődnek meg.

A lényeget röviden: Amikor egy komponens olyan kritikus, hogy annak hibája tönkreteszi a teljes mérési képességedet, akkor nem hatékonyság a delegálása egy fekete dobozra. Ez egy hitbeli cselekedet.

Van megjegyzésed? Írj nekünk

Az üzenet csak hozzánk érkezik. Ha a kommented érdekes, közzétehetjük az cikk alján, de csak jóváhagyás után.

Amíg írsz, a böngésződ egy kis számolási feladatot old meg – így szűrjük ki az automatikus üzeneteket harmadik fél szolgáltatás nélkül és anélkül, hogy semaforokat kéne felismerned. Semmit nem kérünk tőled, és semmilyen adat nem hagyja el ezt a weboldalt.