Vuonna 2026, käytössä on 1M tokenin konteksti-ikkunoita. Gemini, GPT-5, ja laajennettua päättelyä käyttävä Claude tukevat niitä. Esittelyissä mallit lukevat kokonaisia kirjoja yhdellä kertaa. Unelma näyttää toteutuneen: lisää kaikki kontekstiin ja anna mallin selvittää loput.
Todellisuus on tavalliseen tapaan vivahteikkaampi. 1M tokenia on tekninen kapasiteetti, ei suorituskykytakuu. Todelliset mallit toimivat parhaiten 5-50K kontekstitokenilla. Kun määrä on 100K+, ilmenee hienovaraisia laatuongelmia. Määrällä 500K+ tärkeää tietoa jää luotettavasti huomaamatta. Kohdassa 1M malli ylikuormittuu.
Kontekstin rapautuminen on todellinen, hyvin dokumentoitu ja arvioinneissa näkyvä ilmiö. Kaikkea ei voi vain kaataa kontekstiin. Tarvitaan kontekstisuunnittelua: tietoisia päätöksiä sisällytettävästä, tiivistettävästä ja dynaamisesti haettavasta tiedosta sekä lopullisen kontekstin rakenteesta.
Tässä artikkelissa käsitellään tehokkaan kontekstisuunnittelun toimintamallit ja kurinalaisuus vakavasti otettavissa tuotantojärjestelmissä.
Mitä kontekstin rapautuminen tarkoittaa
Kontekstin rapautuminen on empiirinen havainto, jonka mukaan LLM:n suorituskyky heikkenee kontekstin kasvaessa teknisen rajan sisälläkin.
Tarkat virhetilat:
Keskelle katoaminen (Liu et al., 2023). Mallit huomioivat enemmän kontekstin alun ja lopun sisältöä. Keskellä olevaa tietoa käytetään epäluotettavammin. Kohdassa 50K / 100K oleva tosiasia jää helpommin huomaamatta kuin sama tieto kohdassa 1K tai 99K.
Viimeaikaisuusharha. Mallit painottavat tuoretta sisältöä liikaa. Keskusteluhistoriassa vanha konteksti muuttuu käytännössä näkymättömäksi.
Häiriöherkkyys. Epäolennainen konteksti heikentää suorituskykyä tehtävissä, jotka eivät tarvitse sitä. Mallin on suodatettava sisältöä, eikä signaali erotu täydellisesti.
Päättelyn laatu heikkenee. Monivaiheinen päättely muuttuu epäluotettavammaksi kontekstin kasvaessa, koska seurattavaa on enemmän.
Kustannus ja viive. Laadusta riippumatta suuri konteksti on tokenhinnoittelun vuoksi kallis ja monissa malleissa tokenimäärään lineaarisesti sidotun käsittelyn vuoksi hidas.
Nämä eivät ole teoreettisia huolia. Huolimattomasti suurta kontekstia käyttävät tuotantojärjestelmät häviävät johdonmukaisesti kuratoitua kontekstia käyttäville.
Periaate: vähemmän on enemmän
Konteksti on arvokas ja heikkenevä resurssi. Käytä sitä strategisesti.
Huolellisesti valittu 30K tokenin konteksti voittaa yleensä kaiken sisältävän 300K tokenin kontekstin. Pienempi konteksti parantaa laatua, kustannusta ja viivettä.
Työ muuttuu kysymyksestä ”miten saamme kontekstiin enemmän” kysymykseksi ”mitä kontekstissa todella tarvitaan ja miten se sijoitetaan hyvin”.
Kontekstibudjetti
Ajattele kontekstia jaettavana budjettina.
Tyypillinen asiakaspalveluagentin jako:
Total context budget: 30K tokens
- System prompt: 1500 tokens (5%)
- Tool descriptions: 1000 tokens (3%)
- User profile / context: 500 tokens (2%)
- Conversation history summary: 1000 tokens (3%)
- Recent conversation turns (full): 4000 tokens (13%)
- Retrieved relevant knowledge: 12000 tokens (40%)
- User's current message: 500 tokens (2%)
- Output token budget (response): 10K tokens (33%)
Osat kilpailevat tilasta. Kontekstin kasvaessa joudut tekemään kompromisseja.
Ole jaosta eksplisiittinen. Älä anna minkään osan kasvaa rajatta.
Malli 1: keskustelumuistin tasot
Monivuoroisissa keskusteluissa täydellinen historia kasvaa rajatta. Useimmat tuotantojärjestelmät käyttävät monitasoista muistia:
Taso 1: viimeisimmät vuorot kokonaisina. Viimeiset 5-10 keskusteluvaihtoa sanatarkasti.
Taso 2: vanhempien vuorojen yhteenveto. Keskustelun aiempi osa pakataan lyhyeksi yhteenvedoksi.
Taso 3: poimitut tosiasiat. Keskustelun keskeiset tiedot, kuten käyttäjän nimi, mieltymykset ja päätökset, tallennetaan rakenteisina tosiasioina.
Toteutus:
On each turn:
1. Take the conversation history.
2. The last 10 turns are kept verbatim.
3. Turns 11-30 are summarized into 200 words ("Earlier, the user discussed X and we agreed Y").
4. Turns 31+ are reduced to extracted facts ("User prefers Python. User is on enterprise tier.").
5. Total memory: ~2K tokens regardless of conversation length.
Malli on olennainen kaikille pitkille keskusteluille. Ilman sitä laatu heikkenee keskustelun kasvaessa.
Yhteenvedon on säilytettävä agentin myöhemmin tarvitsema tieto. Jos käyttäjä kertoo tilinumeron vuorolla 5 eikä agentti siirrä sitä pitkäkestoiseen muistiin, vuorolla 50 tieto on kadonnut.
Aja yhteenveto eksplisiittisillä säilytysohjeilla:
Summarize the conversation so far. Preserve:
- All facts about the user (name, role, preferences, account info).
- All decisions made.
- All open commitments or follow-ups.
- The current goal of the conversation.
Discard:
- Pleasantries.
- Repeated information.
- Detailed reasoning that's been resolved.
Malli 2: haku juuri tarvittaessa
Älä esilataa kontekstia, vaan hae olennainen tieto silloin, kun sitä tarvitaan.
Vastamalli on kaikkien käyttäjän asiakirjojen lisääminen kontekstiin varmuuden vuoksi. Useimmat kyselyt tarvitsevat vain pienen osajoukon. Konteksti kuluu ja suorituskyky heikkenee.
Parempi tapa on hakea asiakirjat nykyisen kyselyn perusteella. Eri kyselyt saavat eri asiakirjat. Kutsukohtainen konteksti pysyy pienenä ja olennaisuus suurena.
Tämä on kurinalaisesti sovellettua RAG:a. Älä sorru lisäämään kaikkea vain siksi, että se on mahdollista. Pitkän kontekstin mallit houkuttelevat tähän kokeneitakin tiimejä.
Malli 3: pakatut esitykset
Käytä pakattua esitystapaa tiedolle, jonka pitää säilyä kontekstissa.
Alkuperäinen (monisanainen):
The user has been working in software engineering for 8 years. They started at a small startup called Acme Corp where they worked on backend systems. After 3 years they moved to a larger company called Beta Inc where they did frontend work. They're currently at Gamma LLC working on machine learning systems.
Pakattu:
User: SWE, 8 years, currently ML at Gamma LLC. Prior: backend@Acme (3yr), frontend@Beta.
Pakattu versio säilyttää olennaiset tosiasiat vähemmillä tokeneilla. Useimmissa tehtävissä malli käyttää kumpaakin yhtä hyvin.
Sovella tekniikkaa:
- Käyttäjäprofiileihin.
- Asiakirjayhteenvetoihin.
- Aiempaan keskustelukontekstiin.
- Tietopankin merkintöihin, kun täyttä sisältöä ei tarvita.
Pakkaus hävittää vivahteita. Käytä täyttä tekstiä, kun vivahteet merkitsevät, ja pakattua muulloin.
Malli 4: hierarkkinen haku
Hae hyvin suurista tietopankeista hierarkkisesti.
Vaihe 1: hae kyselyn perusteella laajat luokat tai asiakirjayhteenvedot.
Vaihe 2: hae olennaisimpien luokkien sisältä täsmälliset palat.
Vaihe 3: lisää lopulliseen kontekstiin vain vaiheessa 2 valitut palat.
Näin vältetään ajatus ”minulla on 10K asiakirjaa, lisään ne kaikki kontekstiin”. Suppilo pitää kontekstin tiiviinä.
Muunnelmassa pieni LLM-kutsu valitsee olennaisimmat palat ennen pääkutsua. Pieni lisäkustannus vähentää kontekstin paisumista huomattavasti.
Malli 5: kontekstin reflektointi
Pitkiä tehtäviä suorittavan agentin pitää arvioida säännöllisesti, mitä kontekstissa on ja mitä siellä pitäisi olla.
Every 10 steps, the agent does:
1. Reviews its current context.
2. Identifies what's relevant to ongoing work.
3. Summarizes or drops anything no longer needed.
4. Notes what additional context might help.
5. Replaces the old context with the curated version.
Tämä on kontekstin roskienkeruuta. Ilman sitä agentti kerää vanhentunutta tietoa, joka syrjäyttää uutta ja olennaista.
Toteutus vaatii omaa orkestrointia, sillä useimmat kehykset eivät tue sitä suoraan. Agentilla on vaiheiden välissä muistin yhdistämisvaihe, joka muokkaa kontekstia.
Malli 6: dynaamiset konteksti-ikkunat
Agenttiajon eri osille voivat sopia eri kontekstikoot.
- Päätösvaiheet: pieni, välittömään päätökseen keskittyvä konteksti.
- Synteesivaiheet: suurempi, useita lähteitä sisältävä konteksti.
- Generointivaiheet: keskikokoinen konteksti tyyli- ja muotoviitteineen.
Jokainen työnkulun vaihe käyttää erilaista kontekstimuotoa, ja orkestrointi hallitsee vaiheeseen annettavan sisällön.
Tämä edellyttää työn jakamista eksplisiittisiin vaiheisiin yhden suuren silmukan sijasta. Kehysvalinnalla on merkitystä: LangGraph käsittelee tämän luontevasti, suoralla API:lla työ tehdään itse.
Malli 7: sijainnin huomioiva sijoittelu
Koska mallit huomioivat enemmän kontekstin alkua ja loppua, sijoita tärkeä sisältö niihin.
Heikompi: kriittinen ohje pitkän järjestelmäkehotteen keskellä.
Parempi: kriittinen ohje aivan alussa JA uudelleen lähellä loppua.
Kun RAG hakee useita asiakirjoja, sijoita olennaisin alkuun, toiseksi olennaisin loppuun ja vähemmän olennaiset keskelle.
Kyse on taktisesta optimoinnista, jolla on mitattava vaikutus tuloksiin.
Malli 8: valikoiva yhteenveto
Kaikki yhteenvedot eivät ole samanarvoisia. Sovita yhteenveto jatkotehtävän tarpeisiin.
Huono: yleinen yhteenveto, joka kadottaa käyttäjän mieltymykset.
Parempi: yhteenveto, joka säilyttää eksplisiittisesti jatkotehtävän kannalta olennaiset mieltymykset.
Summarize this document focusing on:
- Technical decisions made.
- Stakeholders mentioned.
- Open questions or risks.
Drop:
- General context already known to the team.
- Repeated points.
Yhteenvetokehote suunnitellaan jatkokäyttöä varten.
Malli 9: rakenteinen konteksti
Pelkkä teksti on yksi vaihtoehto. Rakenteinen konteksti, kuten JSON, XML tai määrätty merkintätapa, voi olla paljon tiiviimpi.
Monisanainen proosa:
The customer's name is John Smith. He's been a customer since March 2023. His current plan is Pro, billed monthly at $29. He has 3 active integrations: Slack, Notion, and Linear. His usage in the last 30 days has been moderate — 1,250 API calls.
Rakenteinen:
{
"customer": {
"name": "John Smith",
"since": "2023-03",
"plan": "Pro",
"billing": "monthly $29",
"integrations": ["Slack", "Notion", "Linear"],
"usage_30d": {"api_calls": 1250, "tier": "moderate"}
}
}
Rakenteinen versio on lyhyempi ja usein mallille helpompi käyttää. Yksittäiset tosiasiat löytyvät nopeasti.
Kaikki mallit eivät käsittele rakenteista syötettä yhtä hyvin. Testaa käyttötapauksessasi molemmat muodot.
Malli 10: kontekstin kerrostaminen
Kerrostaa konteksti tärkeyden mukaan. Tärkein sisältö on aina mukana, keskitärkeä tarvittaessa ja vähiten tärkeä haetaan pyynnöstä.
Aina mukana:
- Järjestelmäkehote eli identiteetti ja käyttäytyminen.
- Käyttäjän nykyinen konteksti eli olennaiset tosiasiat.
- Viimeaikainen keskustelu.
Tarvittaessa:
- Kyselyä vastaavat haetut asiakirjat.
- Viime vaiheiden työkalutulokset.
Pyynnöstä:
- Tiedot, joita agentti pyytää työkalukutsuilla.
- Viimeaikaisen ikkunan ulkopuolinen historiallinen konteksti.
Pyynnöstä hakeminen on skaalautumisen kannalta ratkaisevaa: agentti hakee tarvitsemansa tiedon tarvittaessa kaiken esilataamisen sijasta.
Malli 11: poistostrategiat
Mitä poistetaan, kun konteksti lähestyy rajaa?
- Viimeaikaisuuteen perustuva: vanhin sisältö poistetaan ensin.
- Olennaisuuteen perustuva: nykyiseen tehtävään vähiten liittyvä sisältö poistetaan ensin.
- Tärkeyteen perustuva: vähämerkityksiseksi merkitty sisältö poistetaan ensin.
Käytännöllisessä mallissa kontekstikohteet merkitään prioriteeteilla ja poistetaan niiden järjestyksessä.
context_items = [
{"content": "...", "priority": "critical"}, # Never evict
{"content": "...", "priority": "high"}, # Evict last
{"content": "...", "priority": "medium"}, # Evict if needed
{"content": "...", "priority": "low"}, # Evict first
]
def evict_to_fit(items, budget):
items_by_priority = sorted(items, key=lambda x: priority_value(x.priority))
while total_tokens(items) > budget:
items.remove(items_by_priority.pop(0)) # Remove lowest priority
return items
Malli 12: toistuvan kontekstin välimuisti
Monet kutsut käyttävät samaa kontekstia, kuten järjestelmäkehotetta, työkalukuvauksia ja käyttäjäprofiilia.
Useimmat palveluntarjoajat tukevat nyt kehotevälimuistia:
- Anthropic: eksplisiittiset
cache_control-merkinnät viesteissä. - OpenAI: automaattinen saman alkuosan sisältäville pyynnöille.
- Google: eksplisiittisesti välimuistiin tallennettu sisältö API:n kautta.
Kun samaa alkuosaa käytetään uudelleen, välimuistiversio on nopeampi ja edullisempi, usein 90% halvempi.
Varmista monta istuntokohtaista kutsua tekevissä agenteissa, että muuttumattomat osat, kuten järjestelmäkehote, työkalut ja käyttäjäkonteksti, voidaan tallentaa välimuistiin. Sijoita muuttuva sisältö niiden jälkeen.
Tämä on yksi parhaan investoinnin tuoton optimoinneista. Kun 10K tokenin kiinteää alkuosaa käytetään istunnon 50 kutsussa, ensimmäinen kutsu maksaa täyden hinnan ja seuraavat saavat 90% alennuksen. Säästö on huomattava.
Malli 13: kontekstin huomioivat kehotteet
Kehotteella voi ohjata mallia käyttämään kontekstia hyvin:
Reference the documents below to answer the user's question. Always cite the specific document and quote relevant passages.
If you cannot find the answer in the provided documents, say so explicitly. Do not invent information.
When information from multiple documents is relevant, synthesize them and note any disagreements.
Tällainen kehote vähentää hallusinaatioita kontekstiin perustuvissa tehtävissä ja parantaa viittausten laatua.
Milloin pidempi konteksti kannattaa
Kontekstin rapautumisesta huolimatta pidempi konteksti on joissakin tehtävissä aidosti parempi:
Yhden asiakirjan analyysi. Jos tehtävä on sopimuksen analysointi, koko sopimus kontekstissa toimii usein paloihin perustuvaa hakua paremmin.
Monien kohteiden vertailu. Kun 10 sopimusta verrataan rinnakkain, kaikkien 10 lisääminen kontekstiin auttaa.
Koodin muokkaus kontekstissa. Funktion muuttaminen 5K koodirivin tiedostossa on helpompaa koko tiedoston kuin haettujen katkelmien avulla.
Koko keskustelun yhteenveto. Pitkän keskustelun yhteenveto onnistuu tiettyyn rajaan asti paremmin täydellä kontekstilla.
Kun tehtävä edellyttää perustavanlaatuisesti sisältöjen välisten suhteiden ymmärtämistä, pidempi konteksti auttaa. Jos tehtävään riittää pieni osa, pienempi konteksti on parempi.
Käytännön heuristiikka: enintään 50K tokenin kontekstit toimivat yleensä hyvin. 50-200K toimii laadun hieman heiketessä. 200K+ toimii usein lyhyempää kontekstia heikommin. Testaa empiirisesti.
Arviointikuri
Mistä tiedät kontekstisuunnittelun toimivan? Arvioinneista.
Täsmällisiä arviointeja:
Muistitestit. Sijoita keskeisiä tosiasioita pitkän kontekstin eri kohtiin. Testaa, käyttääkö malli niitä, ja mittaa muistaminen sijainnin mukaan.
Häiriötestit. Vertaa saman kyselyn tulosta epäolennaisen kontekstin kanssa ja ilman sitä. Mittaa heikkeneminen.
Pitkän kontekstin ja RAG:n vertailu. Vastaa samoihin kyselyihin täydellä kontekstilla ja haetuilla paloilla. Vertaa laatua.
Tokentehokkuus. Laatu kustannusta kohti. Kontekstin kasvattaminen maksaa enemmän: paraneeko laatu samassa suhteessa?
Arvioinnit osoittavat, auttavatko kontekstivalinnat todella. Ilman niitä arvaat.
Läpikäyty esimerkki: tutkimusavustaja
Todellinen esimerkki pienen tiimin tekoälytutkimusavustajasta.
Tehtävä: vastaa 200 asiakirjan aineistoa koskeviin kysymyksiin. Aineisto sisältää tutkimuksia, sisäisiä asiakirjoja ja kokousmuistiinpanoja.
Huolimaton lähestymistapa: lisää kaikki asiakirjat kontekstiin (300K tokenia). Laatu on kohtalainen, kustannus suuri ja viive huono.
Suunniteltu lähestymistapa:
Context budget: 25K tokens
- System prompt: 1500 tokens (cached)
- Tool descriptions (search, fetch_doc, etc.): 800 tokens (cached)
- Conversation memory: 1500 tokens (last 10 turns)
- Retrieved chunks for current query: 18000 tokens (top 12 chunks via RAG)
- User's current question: 200 tokens
- Output budget: ~3000 tokens
Agentti hakee palat dynaamisesti kysymyksen perusteella. Keskustelumuisti säilyttää viimeaikaisen kontekstin ja muuttumattomat osat tallennetaan välimuistiin.
Tulos:
- Viive: 2-3 sekuntia, kun vertailuarvo on 10-15 sekuntia 300K kontekstilla.
- Kustannus: ~€0.01/query (vertailussa ~€0.10).
- Laatu: arviointiaineistolla mitattuna parempi, koska olennainen sisältö saa asianmukaisen huomion.
Tältä kurinalainen kontekstisuunnittelu näyttää. Kyse ei ole kertapäätöksestä vaan jatkuvasta hienosäädöstä.
Yleiset virheet
Muutamia malleja:
Virhe 1: ”enemmän kontekstia on parempi”. Pidempi konteksti valitaan laatuongelmien ratkaisuksi, vaikka usein asia on päinvastoin.
Virhe 2: ei kontekstibudjettia. Osat kasvavat rajatta. Käyttäjäprofiilista tulee 5K tokenia ja haetuista paloista 50K.
Virhe 3: sijainti ohitetaan. Kriittiset ohjeet haudataan keskelle ja toivotaan mallin löytävän ne. Joskus se löytää, usein ei.
Virhe 4: tosiasiat monisanaisena proosana. Pitkiä lauseita käytetään, vaikka rakenteinen tieto riittäisi. Tokeneita tuhlataan.
Virhe 5: keskustelua ei tiivistetä. Keskustelu kasvaa rajojen yli ja joko katkeaa lopusta tai rikkoutuu.
Virhe 6: ei välimuistia. Toistuvista kiinteistä alkuosista maksetaan täysi hinta jokaisella kutsulla. Helppo säästö jätetään käyttämättä.
Virhe 7: kontekstivalintoja ei arvioida. Oletetaan paremman kontekstisuunnittelun toimivan. Joskus se ei toimi.
Virhe 8: yleinen yhteenveto. Tiivistetään miettimättä jatkotehtävän tarpeita ja menetetään tärkeää tietoa.
Johtopäätös
Pitkät konteksti-ikkunat ovat todellisia, mutta ne eivät oikeuta ohittamaan kontekstisuunnittelua. Laatu heikkenee paljon ennen teknisiä rajoja, ja kustannus sekä viive ovat todellisia.
Kontekstisuunnittelun kurinalaisuus:
- Käsittele kontekstia budjettina.
- Jaa muisti tasoihin: viimeisin sanatarkasti, vanhempi tiivistettynä ja vanhin tosiasioina.
- Hae juuri tarvittaessa, älä ennakolta.
- Pakkaa, kun tieto säilyy.
- Sijoita kriittinen sisältö suuren huomion kohtiin.
- Kerrosta konteksti tärkeyden mukaan.
- Tallenna kiinteät alkuosat välimuistiin.
- Arvioi jatkuvasti.
Näillä malleilla järjestelmät toimivat paremmin, nopeammin ja edullisemmin kuin huolimattomalla ”lisää kaikki kontekstiin” -tavalla.
Kypsissä tuotantojärjestelmissä kontekstisuunnittelu on tehokkaimpia kehityskohteita. Tekniset perusosat ovat yksinkertaisia, mutta kurinalainen käyttö erottaa ”esittely toimii” -tilanteen tuotantoluotettavuudesta.
Investoi malleihin ja rakenna kurinalaisuus. Tuloksena tekoälyjärjestelmät skaalautuvat hallitusti suurempaan tietoon, pidempiin keskusteluihin ja kasvavaan monimutkaisuuteen.
