RAG pipeline optimalizácia: 90 s na 4 s bez modelu

RAG pipeline^?Systém, ktorý pred odpoveďou modelu vyhľadá relevantné dokumenty a pridá ich do kontextu. RAG znamená retrieval-augmented generation. optimalizácia sa vo väčšine prípadov neskrýva v modeli, ale v retrieval vrstve a orchestrácii volaní. Autor jednej nedávnej prípadovej štúdie tvrdí, že odozvu produkčnej pipeline skrátil z približne 90 sekúnd na približne 4 sekundy bez toho, aby siahol na model, a náklady pritom klesli asi o 95 %. To sedí s tým, čo vidíme v prevádzke: pomalosť takmer vždy vzniká okolo modelu, nie v ňom.

Zdrojom je jeden príspevok na Reddite a nadväzujúci rozpis na blogu Agentic Up. Nikto tretí čísla nezávisle nepotvrdil, takže k nim pristupujme ako k autorskému tvrdeniu, nie ako k overenému faktu. Napriek tomu je logika za tým poučná a zhoduje sa s tým, čo pri ladení RAG systémov riešime aj my.

Prečo bola RAG pipeline pomalá, keď model bol v poriadku?

Lebo pracovala retrieval vrstva^?Časť systému, ktorá vyhľadáva relevantné dáta k dopytu, typicky vo vektorovej databáze, ešte pred generovaním odpovede., nie model. Autor v pôvodnom príspevku menuje tri príčiny: nafúknuté embeddingy^?Číselné vektory, ktoré reprezentujú význam textu, aby sa dal porovnávať podobnosťou. Väčšie embeddingy spomaľujú vyhľadávanie., žiadny caching a redundantné volania, ktoré sa hromadili s rastom dokumentovej bázy. Používatelia podľa neho odchádzali skôr, než sa odpoveď načítala.

Tento vzor vidno stále dokola. Keď dopyt trvá minútu a pol, prvou reakciou býva vymeniť model za väčší alebo drahší. Model však väčšinou generuje odpoveď v sekundách. Zvyšok času sa spáli inde: pri embeddovaní dopytu, pri prehľadávaní vektorovej databázy, pri opakovaných volaniach na obohatenie kontextu a pri čakaní na dáta, ktoré už systém raz mal spočítané.

Kde v RAG pipeline reálne vzniká latencia

Rozdeliť čas odozvy na komponenty je prvým krokom každej vážnej optimalizácie. Milvus vo svojej referencii k latencii RAG rozpisuje tri hlavné zložky, ktoré treba merať oddelene:

• Embedovanie dopytu: čas, kým sa otázka premení na vektor. Pri malých modeloch zanedbateľné, pri veľkých embedding modeloch citeľné.
• Prehľadávanie vektorovej databázy: rastie s objemom dokumentov a s tým, ako presne chcete výsledky. Bez indexových parametrov ladených na dáta sa tu latencia hromadí.
• Generovanie odpovede: samotné volanie modelu. Často jediná časť, na ktorú sa všetci pozerajú, hoci býva najmenším problémom.

Ako sa dá odozva RAG pipeline skrátiť bez výmeny modelu?

Tromi zásahmi do architektúry: zmenšiť prácu retrievalu, pridať cache na opakované dopyty a odstrániť redundantné volania. Autor prípadu to zhrnul vetou „streamlined that retrieval layer". Nič z toho nevyžaduje silnejší hardvér ani drahší model, len disciplínu pri meraní a strihaní zbytočnej práce.

Poradie zásahov, ktoré dáva z praxe zmysel:

1. Zmerajte, kde čas vzniká. Bez rozpadu na tokeny, počet LLM volaní a hit rate^?Podiel dopytov, ktoré cache obslúžila z uloženej odpovede namiesto nového výpočtu. Nízky hit rate znamená, že cache prakticky nepomáha. cache optimalizujete naslepo.
2. Zmenšite embeddingy a kontext. Nafúknuté vektory a priveľký kontext predražujú aj spomaľujú každý dopyt. Menej relevantných pasáží býva lepšie než viac hluku.
3. Pridajte caching a poznajte jeho hit rate. Blog Agentic Up to formuluje tvrdo: ak máte semantickú cache a nepoznáte jej hit rate, počítajte s nulou.
4. Odstráňte redundantné volania. Opakované obohacovanie kontextu a viacnásobné retrievaly sa v produkcii hromadia potichu.

Ak riešite presne tento problém, teda máte funkčný prototyp, ale produkčná spoľahlivosť a latencia sa rozpadajú, oplatí sa pozrieť na intenzívny dvojdňový workshop o RAG architektúre a správe kontextu pre produkčné nasadenia. Nie je to úvod do RAG pre začiatočníkov; cieli na CTO a architektov, ktorí už niečo nasadili a potrebujú to stabilizovať. Ak zatiaľ len experimentujete v notebooku, počkajte, kým budete mať na ladenie reálnu prevádzku.

Čo z tohto prípadu je overené a čo treba brať s rezervou?

Overené je len to, čo napísal autor. Čísla 90 s na 4 s aj úspora 95 % pochádzajú z jeho vlastného popisu a z blogu Agentic Up. Žiadna tretia strana ich nepotvrdila, meno firmy nie je nezávisle doložené. Berte to ako case study, nie ako meranie.

To neznamená, že je zbytočná. Rovnaký smer ukazujú aj iné zdroje. RTInsights v texte o RAG pipeline pod sekundu tvrdí, že enterprise systémy sa dajú dostať na sub-sekundovú latenciu bez zmeny modelu. Skepsu voči efektnému číslu si však nechajte: úspora 95 % pri konkrétnej záťaži nič nehovorí o tom, ako sa systém správa pri iných dopytoch alebo pri desaťnásobku dokumentov.

Kde môže optimalizácia zhoršiť kvalitu odpovedí

Strihanie kontextu a agresívne cachovanie majú svoju cenu. Ak orežete priveľa relevantných pasáží, model dostane menej podkladov a začne si domýšľať. To je iná chyba než pomalá odozva a v niektorých doménach horšia. Rizikám halucinácií pri retrievale sme sa venovali v texte o halucináciách pri web search nástroji. Semantická cache^?Pamäť, ktorá si ukladá odpovede na významovo podobné dopyty, aby sa nemuseli počítať znova. zas môže vrátiť starú odpoveď na dopyt, ktorý si vyžadoval čerstvé dáta. Preto sa hit rate meria spolu s presnosťou, nie namiesto nej.

Kedy má tento prístup pre firmu zmysel a kedy nie?

Zmysel dáva vtedy, keď máte funkčnú RAG pipeline v produkcii, dopyty trvajú dlho a používatelia odchádzajú. Vtedy je optimalizácia retrievalu lacnejšia aj rýchlejšia než výmena modelu. Nemá zmysel, ak ešte nemáte čo merať alebo ak je problém v kvalite odpovedí, nie v latencii.

Ak si nie ste istí, či je vaša architektúra úzkym hrdlom, oplatí sa dať systém niekomu externému na hĺbkový technický review RAG architektúry s konkrétnymi odporúčaniami k nákladom a škálovaniu. Je to platený projekt s fixnou cenou, takže dáva zmysel pri systéme, kde latencia či náklady reálne bolia, nie pri víkendovom prototype.

Odporúčanie je triezve. Skôr než pridáte rozpočet na väčší model, zmerajte, kde sa čas a peniaze míňajú. V drvivej väčšine prípadov je odpoveď v retrieval vrstve a orchestrácii volaní, nie v samotnom modeli. Číslo 90 na 4 berte ako ilustráciu smeru, nie ako sľub výsledku.