A kontextusablak az a legnagyobb szövegmennyiség, tokenekben mérve, amelyet egy nagy nyelvi modell egyszerre fel tud dolgozni. Ismerd meg a működését, a korlátait, és azt, miért számít az MI-keresési láthatóság szempontjából.

Ezen az oldalon
Összefoglalás
A kontextusablak az a legnagyobb, tokenekben mért szövegmennyiség, amelyet egy nyelvi modell egyetlen kérésben fel tud dolgozni. Ez a modell munkamemóriája mindarra, ami a promptban és a válaszban szerepel.
Szeretnél többet megtudni? Kérdezd meg
A kontextusablak az a legnagyobb, tokenekben mért szövegmennyiség, amelyet egy nagy nyelvi modell egyszerre figyelembe tud venni egy válasz generálásakor. Mindez beleszámít: a rendszerutasítások, a felhasználói üzenet, a korábbi beszélgetés, a lekérdezett dokumentumok és a modell által írt válasz. Ha eléri a határt, a régebbi tartalmat el kell hagyni vagy összefoglalni.
Gondolj rá úgy, mint a modell munkamemóriájára, nem hosszú távú tárolóra. Ami a kontextusablakon kívül esik, az a modell számára az adott kérésben egyszerűen láthatatlan, ezért a kontextusablak mérete és kezelése határozza meg, mit tud valójában egy MI-asszisztens.
A kontextusablak határozza meg, mennyi információt tart egyszerre a látóterében a modell. Nem állandó memória, hanem az egyes kérések aktív munkaterülete. Amint a beszélgetés vagy a dokumentumcsomag meghaladja az ablak méretét, a rendszer vagy levágja a legrégebbi részeket, vagy összefoglalóvá tömöríti őket, mert a nyers tokenek már nem férnek el.
Ezért tűnhet úgy, hogy egy chatbot elfelejtette a hosszú beszélgetés elejét. A legkorábbi üzenetek kicsúsztak az ablakból, hacsak nem őrizték meg kifejezetten. Ennek a határnak a megértése sokat megmagyaráz abból, miért úgy viselkednek az MI-asszisztensek, ahogy.
A kontextusablakot tokenekben mérjük, nem szavakban vagy karakterekben. Egy token lehet karakter, szórész, egész szó vagy rövid jel, amelyet a tokenizáló állít elő, jellemzően bájtpárkódolással. Durva szabályként angolul egy token nagyjából négy karakter vagy háromnegyed szó, bár ez nyelvenként és tokenizálónként változik.
Mivel a díjszabás és a korlátok tokenekben vannak megadva, ugyanazt a gondolatot tömören kifejezve kevesebb helyet foglal az ablakból, mint egy bőbeszédű változat. Hosszú dokumentumok és hosszú csevegések esetén a token-hatékonyság közvetlenül meghatározza, mennyi fér el, és mennyi hely marad a modell érvelésének és válaszának.
A transzformermodellek az ablakban lévő összes tokent egyszerre dolgozzák fel egy figyelmi mechanizmussal, ahol minden token elvileg minden másikra figyelhet. Ez erős, de drága: a figyelem a sorozathossz négyzetével nő, így 10000 token nagyjából 100 millió összehasonlítást, 100000 token pedig nagyjából 10 milliárdot jelent.
Két további korlát húzza meg a gyakorlati plafont. A kulcs-érték gyorsítótár minden generált tokennel nő, és GPU-memóriát emészt, a gyors és a lassú memória közötti sávszélesség pedig szűk keresztmetszetté válik. Ezek együtt magyarázzák, miért korlátosak a kontextusablakok, és miért kerül többe a nagyobbak futtatása. A mögöttes felépítést a transzformer-architektúra szócikk tárgyalja.
Az ablakméretek gyorsan nőttek. A korábbi GPT-4 konfigurációk 8192 tokent kínáltak, a GPT-4o pedig eléri a 128000-et. A Claude-modellek 200000 tokent kínáltak, az újabb verziók pedig akár 1000000-ig, a Gemini 1.5 Pro pedig dokumentáltan akár 2000000 tokenig. A nyílt modellek, mint a Llama 3.1, jellemzően 128000 tokent támogatnak.
Ezek a számok hirdetett maximumok, nem garantált minőséget a teljes tartományban. A nagyobb ablakba több fér, de ahogy a következő szakasz mutatja, a több befogadása nem jelenti azt, hogy a modell mindent jól ki is használ. Az itt szereplő számok közzétett szállítói és elemzői forrásokból származnak, nem becslések.
A nagyobb ablakok dokumentált módon romlanak. A „közepén elvesző” jelenség azt jelenti, hogy a modellek jól figyelnek a bemenet elejére és végére, a közepén elhelyezett információ pontossága viszont csökken. Elemzések szerint a hosszú kontextusú modelleknél mérhető minőségromlás már nagyjából 32000 token környékén jelentkezik, és egy 200000 tokenes modell is romolhat jóval a határa előtt.
A gyakorlati tanulság, ahogy a szakemberek megfogalmazzák: ne bízz a specifikációs lapban, hanem mérd le a saját felhasználási eseteden, a célhosszon. A kicsi, fókuszált kontextus egyenletesebb figyelmet kap, mint egy nagyon nagy, alig releváns szöveggel teli kontextus. A több token még zajt is hozhat, ami rontja az érvelés minőségét.
Mivel a nagyobb ablak költséges és nem tökéletes, az éles rendszerek ritkán támaszkodnak csak rá. A visszakeresés-kiegészített generálás csak a legrelevánsabb részleteket hozza el és illeszti be, így a prompt kicsi és fókuszált marad. A szemantikus gyorsítótárazás a hasonló lekérdezések válaszait újrahasznosítja, az ügynökmemória-rendszerek pedig elválasztják a rövid távú beszélgetést a hosszú távú tudástól.
Ezért fontos a kiadóknak a tartalom darabolása is. A tartalom tiszta, önmagában álló szakaszokra bontása megkönnyíti, hogy a visszakereső rendszer a megfelelő részt emelje be a korlátos ablakba, ahelyett hogy a modellnek egész oldalakat kellene átrágnia magát.
A generatív motoroptimalizálás szempontjából a kontextusablak az a tér, amelyért a tartalmad versenyez egy MI-válaszon belül. Amikor egy asszisztens, mint a ChatGPT, a Perplexity vagy a Gemini forrásokat keres, csak korlátozott számú token jut be az ablakba, ezért a tömör, jól szerkesztett szakaszok, amelyek közvetlenül válaszolnak a kérdésre, nagyobb eséllyel kerülnek felhasználásra.
Ez a tiszta darabolást, a válasszal kezdő szerkesztést és a szoros relevanciát jutalmazza, ugyanazokat a szempontokat, amelyek az LLM-barát tartalom mögött állnak. A töltelékszövegre pazarló tartalom kisebb eséllyel marad meg a visszakeresés és a szintézis során, míg az, amely tömören ad választ, kiérdemli a helyét az ablakban, és vele együtt az idézés esélyét is.
A kontextusablak az a tokenkeret, amellyel a modell beolvassa a promptot és megírja a választ. Munkamemóriaként működik, nem állandó tárolóként. A figyelem költsége, a gyorsítótár-memória és a sávszélesség korlátozza, és még a nagy ablakokat is sújtja a közepén elvesző információ jelensége, így a több befogadása nem egyenlő a több kihasználásával.
A kiadóknak az a tanulság, hogy tömör, jól darabolt, válasszal kezdődő tartalmat írjanak, amely bejut a korlátos ablakba. Ehhez olyan technikák segítenek, mint a visszakeresés-kiegészített generálás és a tiszta tartalomdarabolás. Forrásként: Redis és Bitfern.
Források
Ez az a legnagyobb, tokenekben mért szövegmennyiség, amelyet egy modell egyetlen kérésben fel tud dolgozni. Beletartozik a rendszerprompt, a felhasználói bemenet, a beszélgetés előzménye, a lekérdezett dokumentumok és a generált válasz. Munkamemóriaként működik, így a határon túli tartalmat a rendszer elhagyja vagy összefoglalja, és a modell számára láthatatlanná válik.
Nem. A nagyobb ablakba több szöveg fér, de a pontosság gyakran romlik a „közepén elvesző” jelenség miatt: a modellek jól figyelnek az elejére és a végére, de a közepén lévőt kihagyják. Sok hosszú kontextusú modellnél már nagyjából 32000 token körül mérhető a minőségromlás, ezért a saját felhasználási eset mérése fontosabb, mint a hirdetett maximum.
Amikor egy MI-asszisztens válaszol, a lekérdezett forrásokból csak korlátozott számú token fér be a kontextusablakába. A tömör, jól szerkesztett szakaszok, amelyek közvetlenül válaszolnak a lekérdezésre, nagyobb eséllyel kerülnek be és idéződnek. A töltelékkel teli tartalom pazarolja a tokenkeretet, és kisebb eséllyel marad meg a visszakeresés és a szintézis során.
A TE ELŐTTED PRÓBÁLTÁK KI A SORANKOT
