Keď poskytovatelia modelov oznámili kontextové okná v rozsahu miliónov tokenov, mnohí CTO-ovia a vedúci inžinieri reagovali rovnako: „Výborne — nacpeme tam celú dokumentáciu a nemusíme riešiť RAG." Je to pochopiteľná reakcia. Menej komponentov, menej infraštruktúry, menej ladenia. Realita v produkcii je však komplikovanejšia.
Veľké kontextové okno je mocný nástroj — ale má svoje fyzikálne a ekonomické mantinely. Tento článok vysvetlí, kde tieto mantinely ležia, ukáže, kedy 1M tokenov naozaj rieši problém, a naopak, kedy je jeho použitie zbytočne drahé a niekedy aj menej presné ako dobre navrhnutý pipeline s agentic RAG.
Čo vlastne znamená „1M tokenov"
Kontextové okno je maximálna dĺžka textu — vstup plus výstup — ktorú model vidí naraz pri jednom volaní. Token zodpovedá zhruba 0,75 slova v angličtine, v slovenčine a slovensky pomenovaných technických textoch sú tokeny trochu dlhšie.
Milión tokenov je asi 750 000 slov — celý priemer románu, stovky strán technickej dokumentácie alebo kompletný zdrojový kód stredne veľkého projektu. Dnes to nie je prémia: Claude (vyššie tiery), Gemini 2.5/3.x a Llama 4 Maverick ponúkajú 1M, Llama 4 Scout ide dokonca na 10M tokenov. Nie každý model je však takto „dlhý" — napríklad DeepSeek V3 má 128K. Aj tak platí, že 1M kontext už nie je výnimočná funkcia, ale rozšírený štandard.
Problém nie je, či model zvládne dlhý kontext. Problém je, čo to stojí a ako sa znižuje kvalita odpovedí pri narastajúcom kontexte.
Ako rastie cena s dĺžkou kontextu
Výpočtová cena pri inferencii neroste s kontextom lineárne — v skutočnosti je situácia komplikovanejšia, ale pre praktické rozhodnutia stačí pochopiť jeden mechanizmus: KV cache.
Každý token v kontexte si vyžaduje uloženie tzv. key-value vektorov v GPU pamäti (VRAM). Pri každom ďalšom generovanom tokene model pristupuje ku celej tejto cache. Pre 7B model je KV cache pri 128K tokenov zhruba 16 GB, pri 1M tokenov vyše 100 GB. Pre 70B model pri 128K tokenov je KV cache sama o sebe okolo 40 GB — a to ešte bez váh modelu.
Výsledok v praxi: ak chcete obslúžiť viacero paralelných požiadaviek s dlhým kontextom, potrebujete buď obrovský hardware, alebo budete žiadosti radiť do fronty. Na cloudovej API to znamená jednoducho vyššiu cenu za volaní — frontierové modely účtujú za každý vstupný token a dlhý kontext teda priamo zodpovedá vyšším nákladom. Na internom nasadení (on-prem) to znamená potrebu viacerých alebo výkonnejších GPU.
Dôležitá optimalizácia existuje: prompt caching. Ak váš systémový prompt, dokumentácia alebo iný statický obsah zostáva rovnaký naprieč viacerými volaniami, provider uloží jeho KV reprezentáciu a pri opakovanom čítaní zaplatíte len 10 % ceny vstupného tokenu (u Anthropic). Cache write je naopak o niečo drahší — 125 až 200 % bežnej ceny. Úspora nastáva len vtedy, keď rovnaký prefix čítate opakovane v krátkom čase. Podrobnejšie sa tejto stratégii venujeme v článku prompt caching a cost.
„Lost in the middle" — keď model stratí niť
Väčšina inžinierov vie o technologickom limite kontextového okna. Menej sa hovorí o inej, subtílnejšej hranici: context rot — degradácii kvality odpovedí s rastúcou dĺžkou kontextu.
Výskum ukazuje, že modely majú tendenciu sústrediť pozornosť na začiatok a koniec kontextu. Informácie uložené v strede dlhého dokumentu sú v odpovediach zastúpené menej presne — fenomén nazývaný „lost in the middle". Benchmark needle-in-a-haystack (hľadanie jednej vety schovanej v dlhom texte) meria iba schopnosť nájsť izolovaný fakt. Reálne produkčné úlohy sú komplexnejšie — vyžadujú prepojenie viacerých informácií z rôznych miest dokumentu, uvažovanie cez viacero krokov. Na takýchto úlohách degradácia kvality nastúpi skôr a je výraznejšia.
Prakticky to znamená: ak máte 500-stranovú technickú príručku a pýtate sa na závislosť medzi sekciou 3 a sekciou 47, model s celou knihou v kontexte nemusí nevyhnutne odpovedať lepšie ako model, ktorému ste podali iba relevantné dve sekcie cez RAG. A ten druhý prípad je podstatne lacnejší.
Kedy veľký kontext skutočne pomáha
Napriek týmto obmedzeniam existujú scenáre, kde je dlhý kontext objektívne lepšou voľbou. Hlavné kategórie:
Analýza celého dokumentu so sekvenčnou závislosťou. Ak chcete zhrnúť zápisnicu z trojhodinového stretnutia, extrahovať rozhodnutia z dlhého právneho spisu alebo analyzovať dlhý technický report kde záver závisí od kontextu v úvode — celý dokument v kontexte dáva zmysel. Tu je linearita výhodou, nie slabinou.
Dlhé konverzácie s plnou históriou. Multi-turn chatové systémy kde každá otázka závisí od predchádzajúcej odpovede — zákaznícka podpora s históriou, technická asistencia kde sa ladí jedno riešenie cez desiatky výmen. Uložiť celú históriu v kontexte je jednoduchšie ako implementovať sofistikovanú pamäť.
Code review alebo refaktoring celého repozitára. Keď potrebujete model opraviť závislosť naprieč viacerými súbormi naraz, kontext celého kódu eliminuje nekonzistencie. Presne takto fungujú moderné coding agenti — Cursor, Claude Code a podobné.
Jedna dlhá, ojedinelá otázka. Ak nahrávate 300-stranovú zmluvu raz za mesiac a pýtate sa na klauzuly o zodpovednosti, ekonomika funguje. Jedno volanie, jasný výstup, nízka frekvencia — cena je prijateľná.
Kedy je RAG lacnejší a presnejší
Väčšina produkčných LLM systémov vo firmách funguje inak: rozsiahla znalostná báza (technická dokumentácia, ISO normy, interné predpisy, histórie servisných zápisníkov), na ktorú sa pýtajú desiatky alebo stovky zamestnancov denne. Tu veľký kontext bez RAG prestáva dávať ekonomický zmysel.
Situácie, kde je RAG správnejšia voľba:
- Vysoký počet volaní s prekrývajúcimi sa zdrojmi. Ak sto operátorov denne pýta rôzne otázky o tej istej príručke, RAG vytiahne len relevantné úseky a zaplatíte za zlomok tokenov.
- Databáza rastie. Kontextové okno je fixné — ak vaša dokumentácia má 10 miliónov tokenov, ani 1M okno nestačí. RAG škáluje s veľkosťou bázy bez zmeny architektúry.
- Potrebujete presné lokalizácie zdroja. RAG vám vráti konkrétne chunky s odkazmi. Dlhý kontext vám dá odpoveď, ale bez atribúcie ku konkrétnemu odseku — dôležité v regulovaných prostrediach.
- Nízka latencia je kľúčová. Čas do prvého tokenu (TTFT) rastie s dĺžkou kontextu. Pri 128K tokenoch je latencia rádovo vyššia ako pri 4K kontexte s relevantným RAG chunkmi.
Podrobnejšie porovnanie oboch prístupov nájdete v článku RAG vs fine-tuning — rozhodovanie, kde rozoberáme aj kombinované scenáre.
Hybridný prístup: kontext + RAG
Prakticky, najlepšie produkčné systémy nekombinujú len „celý kontext" alebo „čistý RAG" — používajú oboje podľa situácie. Typická architektúra:
- 1.Systémový prompt a globálne inštrukcie — statický, kešovaný cez prompt caching, lacný pri opakovanom čítaní.
- 2.Dynamicky retrieval-ované chunky — relevantné úseky z dokumentácie, pridané do kontextu na základe dotazu. Typicky 5–20 chunkov, každý 200–500 tokenov.
- 3.Konverzačná história — posledné N výmen, zhrnutie staršej histórie ak je potrebná.
- 4.Celý dokument v kontexte — iba ak je dokument krátky (pod 50K tokenov) a úloha vyžaduje celok.
Táto kombinácia drží efektívnu veľkosť kontextu pri bežných dotazoch na 8–32K tokenov, čo je rádovo lacnejšie ako 500K+ pri naivnom „načítaj celé".
Praktické rozhodovanie: otázky pred nasadením
Pred tým ako sa rozhodnete pre architektúru, odpoveďte si na tieto otázky:
- Koľkokrát denne sa rovnaká znalostná báza použije? Ak viac ako 50×, RAG sa ekonomicky vyplatí aj pri vyšších nákladoch na setup.
- Je báza väčšia ako 500K tokenov? Ak áno, dlhý kontext nestačí a RAG je jediná realistická voľba.
- Závisí odpoveď od sekvenčného čítania celého dokumentu? Ak áno, dlhý kontext je legitímna voľba.
- Aká je tolerancia latencie? Real-time konverzácia s požiadavkou pod 2 sekundy a dlhý kontext sa ťažko kombinujú.
- Potrebujete citovateľné zdroje? RAG vám dá chunk s odkazom, veľký kontext nie.
Ak na väčšinu odpovedáte „nie, nie, áno, vysoká, nie" — dlhý kontext môže byť správna voľba. Ak prevláda opak, RAG alebo hybridná architektúra bude ekonomicky aj kvalitatívne lepšia.
Prompt caching ako kompromis
Špeciálnym prípadom je situácia, kde máte relatívne veľký, ale statický kontext — napríklad firemný štýlový manuál, rozsiahly systémový prompt s inštrukciami, alebo referenčnú dokumentáciu. Tu prompt caching ponúka atraktívny stred:
- Prvé volanie: zaplatíte plnú cenu za write do cache (125–200 % bežnej vstupnej ceny).
- Každé ďalšie volanie v TTL okne (5 minút alebo 1 hodina u Anthropic): platíte 10 % ceny vstupného tokenu za cached časť.
- Pri desaťnásobne zopakovanom statickom prefixe sú celkové náklady výrazne nižšie ako bez cache.
Typické úspory v produkcii pri vhodnom workloade dosahujú 50–70 % nákladov na vstupné tokeny. Dôraz na „vhodný workload" — ak každý používateľ prichádza s úplne iným dlhým promptom, cache hit rate bude blízko nuly a cache write naopak zdraží.
Čo to znamená pri výbere hardware a serving frameworku
Ak sa rozhodnete pre reálne dlhé kontexty v on-prem nasadení, je dôležité rozumieť hardwarovým dôsledkom.
KV cache pre dlhý kontext potrebuje veľa VRAM navyše oproti samotným váham modelu. Pre 70B model pri 128K kontexte je samotná KV cache okolo 40 GB — k tomu pripočítajte ~140–168 GB pre váhy modelu v FP16 (alebo ~35–40 GB pre Q4_K_M kvantizáciu). Toto rýchlo prerastie kapacitu jednej GPU a vyžaduje multi-GPU setup alebo tensor parallelism.
Na strane serving frameworkov: vLLM a SGLang implementujú PagedAttention a RadixAttention — techniky, ktoré znižujú fragmentáciu KV cache a umožňujú efektívnejšie zdieľanie medzi paralelne spracovávanými požiadavkami. Ollama je skvelý pre desktop a experimenty, ale pre produkčný multi-user serving s dlhými kontextmi je výkon rádovo nižší. Viac o porovnaní frameworkov nájdete v vLLM vs SGLang vs Ollama.
Grouped Query Attention (GQA), ktorý implementuje väčšina moderných modelov, výrazne znižuje veľkosť KV cache oproti klasickému multi-head attention — pri výbere modelu pre dlhý kontext je teda dôležité overiť, či GQA podporuje.
Časté otázky
Nahradí milión tokenov RAG úplne?
Pre väčšinu produkčných systémov nie. Ekonomika nefunguje: 1M tokenov pri každom volaní je rádovo drahšie ako retrieval relevantných chunkov. Navyše quality degradácia pri veľmi dlhom kontexte je reálna. Veľký kontext má zmysel pre jednorazové analýzy dlhých dokumentov, nie pre systém kde sa rovnaká báza pýta stokrát denne.
Ako veľmi klesá kvalita odpovedí pri dlhom kontexte?
Závisí od úlohy. Pri jednoduchom vyhľadávaní jedného faktu (needle-in-a-haystack) sú moderné modely spoľahlivé aj pri 1M tokenov. Pri komplexnejších úlohách — prepájanie informácií z viacerých miest, multi-hop uvažovanie — sa presnosť znižuje výraznejšie so stúpajúcou dĺžkou. Fenomén „lost in the middle" je experimentálne zdokumentovaný a treba s ním počítať pri návrhu architektúry.
Je prompt caching vždy výhodný?
Nie. Výhodný je pri statickom alebo málo sa meniacom prefixe, ktorý sa číta opakovane v rámci TTL okna (5 minút alebo 1 hodina). Cache write tokeny sú drahšie ako bežné vstupné tokeny (1,25–2× u Anthropic). Ak každý používateľ prináša unikátny dlhý kontext, alebo frekvencia volaní je nízka, cache hit rate bude nízky a celkové náklady môžu byť vyššie ako bez cacheovania.
Aký hardware potrebujem pre lokálne nasadenie s dlhým kontextom?
Závisí od modelu a dĺžky. Ako orientačné číslo: pre 70B model pri 32K tokenov potrebujete okolo 50–80 GB VRAM celkovo (váhy + KV cache pri Q4 kvantizácii). Pri 128K tokenoch je KV cache samotná zhruba 40 GB (pre 70B, FP16 KV). Pre 7B model je situácia priaznivejšia — pri 128K tokenov zvládnete na high-end GPU s 40–80 GB VRAM. Apple M-series so zjednotenou pamäťou (až 128–192 GB na M5 Ultra) je zaujímavá on-prem alternatíva pre 70B s dlhým kontextom.
Platia rovnaké princípy pre open-weight modely on-prem aj pre cloudové API?
Ekonomika je iná, princípy sú rovnaké. Na cloudovom API platíte priamo za tokeny. On-prem platíte za hardware (CAPEX) a energiu (OPEX) — ale KV cache a tým aj GPU pamäťové nároky rastú rovnakým spôsobom. Rozhodovanie „long context vs RAG" teda nestojí len na cene tokenov, ale na celkovej architektúre hardware, batch veľkosti a latencii.
*Ak riešite architektúru LLM systému a neviete si byť istí, kde je pre vás hranica medzi dlhým kontextom, promptovým cachingom a RAG, radi sa pozrieme na váš konkrétny prípad v MP Industrial Solutions — prinesieme skúsenosti z nasadení v priemysle, kde záleží na každom eure prevádzkových nákladov.*