Kontextové okno u LLM

Vytvořeno: 14.03.2026 | Aktualizováno: 28.07.2026 20:04

Kontextové okno je rozsah vstupu, se kterým model pracuje při generování odpovědi. V praxi určuje, kolik instrukcí, historie chatu, dokumentů nebo dat je model schopný vzít v úvahu najednou. Samotná velikost kontextového okna ale nezaručuje, že model využije všechny části dlouhého vstupu stejně dobře.

Technická zpráva Context Rot od Chroma ukazuje na kontrolovaných testech 18 LLM, že s délkou vstupu roste nespolehlivost modelů i tehdy, když se vlastní úloha nemění.

Kontextové okno je aktuální pracovní prostor modelu. Patří do něj například:

• systémové instrukce,
• prompt uživatele,
• předchozí zprávy v konverzaci,
• přiložené dokumenty,
• textové chunky načtené přes RAG.

Když se do kontextového okna něco nevejde, model s tím při generování odpovědi už nepracuje. Ani u textu, který se do okna vejde, ale není jisté, že všechny části dostanou stejnou váhu.

Proto je důležité řešit dvě věci:

• velikost okna - kolik obsahu se do něj vejde,
• strukturu vstupu - jak jsou informace v rámci dlouhého vstupu rozmístěné.

Context rot popisuje jev, kdy se výkon LLM se zvětšujícím se kontextem zhoršuje, přestože se náročnost samotného úkolu nemění. Nejde tedy jen o známý problém lost in the middle; relevantní informace může být v kontextu přítomná, ale model ji s rostoucím množstvím dalšího obsahu používá méně spolehlivě.

Autoři studie měnili délku vstupu a drželi vlastní úlohy co nejvíce konstantní. Testovali rozšířenou variantu Needle in a Haystack, konverzační benchmark LongMemEval a úlohu přesného zopakování dlouhé řady slov.

• Sémanticky nejednoznačné dotazy jsou citlivější na délku kontextu. Když otázka nepoužívá stejná slova jako hledaná informace, výkon se s rostoucí délkou vstupu zhoršoval rychleji. Běžný Needle in a Haystack proto nestačí: primárně měří doslovné vyhledání známé věty.
• Podobné, ale nesprávné informace škodí. Už jeden tematicky související distractor zhoršoval výsledky proti variantě bez distractoru; čtyři distractory problém dále prohloubily. Jednotlivé distractory neměly stejný dopad a modely na ně reagovaly rozdílně.
• Záleží na podobě okolního textu. Autoři pozorovali, že obsah a struktura haystacku ovlivňují úspěšnost. Ve svých testech modely konzistentně dosahovaly lepších výsledků nad promíchanými větami než nad logicky souvislým textem.
• Celá historie konverzace je horší než vybraný kontext. V LongMemEval měly modely výrazně lepší výsledky s přibližně 300tokenovým focused vstupem obsahujícím relevantní části než s plným vstupem o průměrné délce kolem 113 000 tokenů. Plný vstup po modelu vyžaduje současně retrieval i odpověď.
• Problém se týká i velmi jednoduchých úloh. Při přesném opakování dlouhé řady slov se s délkou vstupu a výstupu zhoršovala přesnost napříč testovanými modely; objevovalo se vynechávání, přidávání nebo náhodná slova i odmítnutí úlohy.

Režimy s reasoningem v LongMemEval zlepšovaly výsledky, ale neodstranily rozdíl mezi focused a plným kontextem.

Velké kontextové okno je kapacita, ne garance, že model celý obsah spolehlivě zpracuje. Pro agenty, RAG i dlouhá vlákna konverzace proto dává smysl nejprve vybrat relevantní podklady a až potom je předat modelu. Poslat celou historii, dokumentaci nebo logy jen proto, že se technicky vejdou, může zhoršit jak retrieval, tak následné uvažování nad nalezenými informacemi.

U delších vstupů se u LLM často popisuje jev označovaný jako lost in the middle. Model má tendenci věnovat více pozornosti začátku a konci dlouhého textu než jeho středu. Tento vzorec se často popisuje jako U-křivka pozornosti.

Praktický dopad je jednoduchý:

• informace na začátku lépe nastavují kontext,
• informace na konci častěji ovlivní finální odpověď,
• informace uprostřed mohou mít menší váhu nebo se v odpovědi vůbec neprojeví.

To je důvod, proč model někdy správně respektuje úvodní instrukce a závěrečné shrnutí, ale hůř využije důležitý odstavec schovaný uprostřed dlouhého dokumentu.

Velké kontextové okno je užitečné, protože umožňuje přiložit víc dat najednou. Samo o sobě ale neřeší problém s tím, že model nemusí všechno v dlouhém vstupu využít rovnoměrně.

Pokud je důležitá informace schovaná uprostřed dlouhého textu, může mít menší šanci, že se promítne do výsledku. Proto dává smysl pracovat nejen s délkou vstupu, ale i s jeho kompozicí.

U delších promptů je vhodné dát klíčové zadání hned na začátek. Pokud je prompt složitější, pomáhá důležité podmínky na konci stručně zopakovat.

Osvědčuje se hlavně:

• nejdřív jasně definovat cíl,
• hned na začátku vypsat zásadní omezení nebo pravidla,
• dlouhé zadání rozdělit do bloků,
• na konci přidat krátké shrnutí toho, co je opravdu důležité.

Příklad jednoduché struktury promptu:

Cíl: Vysvětli téma pro začátečníka.
Důležité podmínky: stručně, bez marketingu, s praktickými příklady.

Doplňující kontext:
...

Shrnutí zadání:
- vysvětlit princip
- uvést praktické dopady
- nepřidávat neověřené informace

U delších dokumentů nestačí mít správné informace jen někde v textu. Důležité definice, závěry a hlavní sdělení je vhodné dát na začátek a na konec.

Dobře funguje:

• krátké TL;DR nahoře,
• definice pojmu hned v úvodu,
• důležité body neukrývat doprostřed dlouhého bloku textu,
• na konci přidat stručné shrnutí.

Pokud je text příliš dlouhý, bývá lepší ho rozdělit na více samostatných článků nebo sekcí, které dávají smysl i samy o sobě.

Stejný princip platí i pro webové stránky. Pokud má stránka vysvětlit produkt, službu nebo konkrétní téma, hlavní informace by měly být viditelné hned na začátku stránky, ne až po delším úvodu.

Prakticky to znamená:

• hlavní odpověď dát do prvních odstavců,
• klíčové definice nebo přehled přidat hned nahoře,
• důležité informace zopakovat v závěru stránky,
• dlouhé texty strukturovat do menších logických celků.

Tento princip pomáhá nejen modelům, ale často i lidem, kteří obsah skenují podobným způsobem.

U RAG nestačí řešit jen kvalitu retrievalu. Důležité je také to, jak vypadají jednotlivé chunky a co se stane po jejich složení do výsledného kontextu.

Praktické dopady pro RAG:

• chunky mají být samostatně srozumitelné,
• důležitá definice nebo závěr nemá být jen v jiném chunku,
• dlouhé dokumenty je vhodné dělit podle významových celků, ne jen mechanicky podle délky,
• i při větším kontextovém okně se může část informací po složení více chunků ztrácet uprostřed.

Jinými slovy: větší kontextové okno samo o sobě problém neřeší. Pomáhá pojmout více dat, ale neodstraňuje nerovnoměrnou pozornost v rámci dlouhého vstupu.

Pro práci s kontextovým oknem se osvědčují hlavně tyto postupy:

• dát definici nebo hlavní pointu hned na začátek,
• přidat nahoře stručné TL;DR,
• na konci zopakovat klíčové závěry,
• rozdělovat dlouhý obsah do menších celků,
• připravovat pro RAG chunky, které dávají smysl i samostatně.

Nejde o to informace bezmyšlenkovitě opakovat, ale umístit je tak, aby byly pro model snadno dostupné ve chvíli, kdy je potřebuje použít.

Když připravuji delší vstup pro LLM, vyplatí se zkontrolovat:

• Je hlavní cíl nebo pointa hned na začátku?
• Nejsou klíčové instrukce schované až uprostřed?
• Obsahuje závěr stručné zopakování nejdůležitějších bodů?
• Dává každá sekce nebo chunk smysl i samostatně?
• Nebylo by lepší dlouhý obsah rozdělit na více kratších celků?

Kontextové okno určuje, s jak velkým vstupem model pracuje, ale samo o sobě nezaručuje rovnoměrné zpracování celého textu. U dlouhých vstupů mají LLM obvykle větší citlivost na začátek a konec než na střed.

Z praktického hlediska proto dává smysl psát prompty, články, webový obsah i RAG chunky tak, aby klíčové informace byly viditelné hned na začátku a znovu potvrzené na konci. Pokud je důležitý bod schovaný uprostřed dlouhého obsahu, model ho může využít hůř, i když se do kontextového okna formálně vejde.

• Chroma – Context Rot: How Increasing Input Tokens Impacts LLM Performance
• AI Carma – Context Window Optimization: Writing for the U-Shaped Attention Curve