Mi az a kontextusablak, és mi az a token?

Két szám, ami eldönti, mit küldhetsz

A hosszú kontextus, a 200k kontextus és a token három módja egy kérdés feltevésének, ezért érdemes szétválasztani a mögöttük lévő két mennyiséget. A token az a egység, amit egy modell olvas és ír. A kontextusablak az, hogy hány ilyen egység fér el egy hívásban. Mindkettő rögzítve van minden modellkártyán, és mindkettő érvényesítve van, nem csak hirdetve: az útválasztó motor elutasít egy modellt, amelynek dokumentált ablaka kisebb, mint a becsült bemenet plusz a kimeneti költségvetés, és rögzíti az okot.

Mi az a token

A modellek nem látnak karaktereket vagy szavakat. A szöveg tokenekre van felosztva, és egy token nagyjából egy szótöredék: a gyakori rövid szavak általában egy token, a hosszú vagy ritka szavak és összetételek több részre oszlanak. Az írásjelek és a szóközök a szomszédos tokenekhez kapcsolódnak. Egy német összetett főnév jellemzően két vagy három token, ahol az angol megfelelője egy, ami a gyakorlati oka annak, hogy egy dokumentum az egyik nyelven észrevehetően többe kerülhet feldolgozni, mint ugyanaz a dokumentum egy másik nyelven.

Az itt használt becslés szándékosan durva és dokumentált: körülbelül négy karakter tokenenként latin írás esetén, felfelé kerekítve. A felfelé kerekítés a biztonságos irány, mert szigorúbbá teszi a kontextusellenőrzést, nem pedig megengedőbbé. Egy kép becsült értéke 850 token képrészletenként, plusz egy kis boríték minden üzenethez. Mindez nem tokenizáló mérés; ez egy költségvetés, amelyet az útválasztó használ egy olyan kérés elutasítására, amely nem férne el.

Mi az ablak, és mi nem az

Az ablak mindent együtt számol a hívásban: a rendszerüzenetet, az eddigi összes üzenetet, az alkalmazás által lekérdezett szövegrészeket, az eszközdefiníciókat és azokat a tokeneket, amelyeket a modell visszaírhat. A bemenet és a kimenet osztozik rajta. Egy modell, amely jól válaszol egy 32k-s ablakon belül, nem növeli csendesen a kapacitását, ha 40k-t küld; a kérést úgy kell megtenni, hogy beleférjen.

Az itt közzétett ablakok nagyságrendekben különböznek. Az EuroLLM 9B, az EuroLLM 22B és a Mistral 7B Instruct v0.3 32 768 tokent rögzít. A Pharia-1-LLM-7B-control-aligned 8 192-t, a Teuken 7B Instruct v0.6 pedig 4 096-ot. A Mistral Small 4, a Mistral Large 3, a Gemma 4 31B és az NVIDIA Nemotron 3 Super 262 144-et rögzít. A Llama 3.1 8B Instruct, a Llama 3.3 70B Instruct, a Command A+ és a Command R (08-2024) körülbelül 128k-t rögzít. A Llama 4 Scout 17B-16E Instruct 10 485 760 tokenre van listázva, a gyártó által közzétett adatok szerint. Két furcsaság inkább a kártyán, mint egy összefoglalóban szerepel: a Command A+ 128K bemenetet és 64K kimenetet dokumentál, miközben konfigurációja 200 000 pozíciót engedélyez, és a Nemotron 3 Super akár egymillió token kontextust hirdet, miközben konfigurációja 262 144-et engedélyez, a gyártó által jelentett RULER pontszámokkal 96,30 256k-nál és 91,75 egymilliónál. Ahol egy kártya egy értéket, egy konfigurációs fájl pedig egy másikat állít, mindkettő rögzítésre kerül.

A kis ablakok sem tűntek el: az EuroLLM 1.7B Instruct 4 096 tokent rögzít, ami egy-két oldalnyi szöveg, nem pedig egy dokumentumkészlet.

Miért van szükség egy második kérdésre a „200k kontextus” esetében

A hosszú ablak kapacitás, nem minőségi ígéret. A fontos kérdés az, hogy a modell mit tesz még a távoli végén. A gyártók ritkán tesznek közzé nyelvenkénti lekérdezési minőséget egy ablakon keresztül, és amikor számot tesznek közzé, az általában egy hosszú kontextusú benchmark futtatása a saját eszközeikkel, ezért a kártyák ezeket az adatokat gyártó által jelentettként jelölik. Egy RULER pontszám azt jelenti, hogy a modell talált valamit egy hosszú bemenetben egy adott teszt során; nem azt jelenti, hogy egy francia záradék egy német szerződés 400. oldalán ugyanolyan megbízhatóan lesz kezelve, mint az 1. oldalon lévő.

A második kérdés a költség. A bemeneti tokenek számlázásra kerülnek, függetlenül attól, hogy hasznosak voltak-e, és egy olyan pipeline, amely minden fordulóban újra elküld egy nagy ablakot, lineárisan növekszik a beszélgetéssel. A hosszú kontextus valóban olcsóbb, ha egy lekérdezési pipeline-t helyettesít, és valóban drágább, ha csak a már meglévő darabolást helyettesíti.

A harmadik az a csapda, amit a lekérdezési útmutató említ: a lánc legkisebb korlátja érvényesül. Beágyazás egy olyan modellel, amelynek kártyája 512 token maximális szekvenciahosszt használ, és egy 900 tokenes darab csendesen csonkolódik a beágyazás során, függetlenül attól, hogy mekkora a generátor ablaka. Állítsa be a darab hosszát a beágyazó modellből, ne a generátorból.

Hogyan érvényesül az ablak egy kérésen

A bemeneti tokenek becsültek, a maximális kimeneti költségvetés hozzáadódik, és minden olyan jelölt, amelynek dokumentált ablaka kisebb, mint ez az összeg, elutasításra kerül egy rögzített okkal, amely megnevezi az ablakot és a követelményt. Ez az ellenőrzés a rezidencia és modalitás szűrők után, és az árplafon előtt történik, így egy modell teljesen engedélyezett lehet a szabályzat szerint, és mégis eltávolítható, mert túl kicsi.

Az elutasítások láthatóak. Az útvonal oka megszámolja, hány végpontot zártak ki, és a nyomkövetés megőrzi a végpontonkénti okokat. Ha egy kérés azért hiúsul meg, mert semmi sem maradt, a válasz megnevezi, mit kell változtatni, ahelyett, hogy csendesen újrapróbálkozna egy rövidebb prompttal; a bemenet rövidítése az Ön döntése, nem az útválasztóé.

Gyakorlati szabályok, amelyek érvényesek

Küldje el, amire a feladatnak szüksége van, és semmi mást. Egy 262k-s ablak nem ok arra, hogy egy kódbázist küldjön; ez ok arra, hogy egy összefoglaló feladat egy egész jelentést egy menetben kezeljen. Tartsa az utasítást és az anyagot közel egymáshoz, ahelyett, hogy a kérdést negyven oldalnyi kontextus alá temetné, mert a hosszú bemenet feletti figyelem a gyakorlatban nem egyenletes.

Költségvetés a kimenetet explicit módon. A kimeneti tokenek számlázásra kerülnek, mint bármely más token, és egy hosszú köztes munkát produkáló érvelési mód ugyanúgy számlázásra kerül, ahogy több feladatjegyzet is rámutat.

Hosszú dokumentumok esetén tudatosan döntsön egy hosszú hívás és egy rövid hívások láncolata között. Egy hívás egyben tartja a dokumentumot, és egyszeri bemeneti token költséggel jár; egy lánc lehetővé teszi a köztes eredmények ellenőrzését, és minden lépést kicsiben tart. Egyik sem univerzálisan helyes.

Végül mérje meg a saját anyagával. Egy közzétett kontextusablak dokumentált kapacitás, egy hirdetett maximum a gyártó állítása forrással, és egy benchmark az Ön nyelvén az Ön dokumentumain az egyetlen adat, amely az Ön munkaterheléséről szól. Ez a katalógus ugyanazt a szabályt alkalmazza magára: minden szám hordozza a forrását, és egy olyan érték, amelyet senki sem állított, ismeretlenként kerül rögzítésre, nem pedig találgatásként.