Väčšina RAG projektov začína rovnako: niekto zaindexuje priečinok dokumentov, napojí vektorové úložisko na model a do dňa má demo, ktoré pôsobivo odpovedá na otázky. To demo je skutočné. Záver, ktorý si z neho ľudia odnesú — „retrieval funguje, stačí pridať zvyšok našich dokumentov“ — zvyčajne skutočný nie je.
Retrieval-augmented generation zlyháva v produkcii z dôvodov, ktoré majú s vektorovou databázou spoločné veľmi málo. Zlyháva pri ingestii, pri evaluácii a pri prevádzke. Chápať RAG ako systém znamená navrhnúť tieto časti s rovnakou vážnosťou ako samotný krok vyhľadávania.
Časti, ktoré demo preskočí
Produkčná RAG schopnosť obsahuje aspoň šesť podsystémov a vektorové úložisko je z nich to najmenej odlišujúce:
-
Ingestia a normalizácia. Dokumenty prichádzajú ako PDF s rozbitým rozložením, wiki so zastaranými stránkami, tikety s polovičnými vetami a databázy so štruktúrou, ktorú embedder nevidí. Rozhodnutie, čo vytiahnuť, ako to rozdeliť na časti, akú metadátovú stopu zachovať a kedy ingestiu zopakovať, určuje kvalitu odpovedí najviac — ešte pred vznikom prvého vektora.
-
Retrieval pipeline. Reálne systémy málokedy prežijú na samotnej kosínusovej podobnosti. Hybridné vyhľadávanie, filtrovanie podľa metadát, váženie aktuálnosti a re-ranking si svoje miesto zaslúžia podľa povahy korpusu. Pipeline musí odpovedať aj na ťažšiu otázku: čo sa stane, keď nič relevantné neexistuje? Systém, ktorý nevie povedať „neviem“, sebavedomo poskladá odpoveď z troch najmenej nerelevantných úryvkov, ktoré našiel.
-
Zostavenie kontextu. To, čo sa k modelu naozaj dostane — ako sú úryvky zoradené, zbavené duplicít, ozdrojované a orezané na rozpočet — je vlastná návrhová plocha. Ozdrojovanie je dôležité dvakrát: používateľom umožňuje odpoveď overiť a vám umožňuje ladiť retrieval, keď to nedokážu.
-
Evaluácia. Bez testovacej sady reálnych otázok, kde sa kvalita retrievalu a vernosť odpovede hodnotia oddelene, je každá zmena chunkovania, embeddingov či promptov iba odhad. Evaluácia je to, čo premení „zdá sa to lepšie“ na inžiniersku disciplínu, a najlacnejšie sa stavia ako prvá, kým sa očakávania ešte len dohadujú.
-
Riadenie prístupov. Korpus takmer vždy obsahuje dokumenty, ktoré nesmie vidieť každý používateľ. Oprávnenia sa musia vynucovať pri vyhľadávaní, v indexe, pri každom dopyte — nie nádejou, že model zamlčí to, čo dostal. Táto jediná požiadavka ovplyvňuje návrh indexu viac než akákoľvek úvaha o výkone.
-
Prevádzka. Dokumenty sa menia, embeddingy strácajú aktuálnosť, poskytovateľ vám pod rukami zmení správanie modelu a náklady rastú podľa vzorcov používania, ktoré nikto nepredvídal. RAG systém potrebuje sledovanie aktuálnosti, dashboardy kvality a stratégiu preindexovania rovnako ako ktorákoľvek dátová platforma.
Prečo na tomto rámovaní záleží
Ak tomu hovoríte „vektorová databáza plus model“, tímy to personálne aj rozpočtovo pokryjú ako funkciu. Ak tomu hovoríte systém, pokryjú to ako dátový produkt so životným cyklom — čím to aj je.
Praktickým dôsledkom je poradie. Tímy, ktorým sa to darí, stavajú zvyčajne takto: najprv úzky korpus s vysokou hodnotou, druhá evaluačná sada, tretia retrieval pipeline a až potom škálovanie korpusu. Tímy, ktoré zápasia, to robia naopak — maximum dokumentov hneď v prvý deň, evaluácia nikdy.
Poznámka o tom, kedy RAG nestavať
RAG si svoju zložitosť zaslúži vtedy, keď je znalosť rozsiahla, meniaca sa a naozaj používaná. Ak je korpus malý a stabilný, vloženie priamo do kontextu poráža budovanie retrieval infraštruktúry. Ak musia byť odpovede presné — ceny, oprávnenia, právne ustanovenia — deterministické vyhľadanie, kde model rieši iba konverzáciu, je lacnejšie aj bezpečnejšie. Najužitočnejším architektonickým rozhodnutím v mnohých rozhovoroch typu „potrebujeme RAG“ je zúžiť rozsah na tú časť, ktorá ho naozaj potrebuje.
Dobre spravený RAG je nefotogenický: pipeliny, kontrakty, testovacie sady, dashboardy. Aj preto funguje.