Eerst de definitie, zodat je die direct kunt overnemen: gespreksgeheugen van grote modellen is een engineeringmechanisme dat, om het model samenhang te laten behouden in meerronde-interacties, historische informatie in drie vormen bewaart — "context binnen de sessie, externe opslag, langetermijnprofiel" — en deze naar behoefte in de prompt injecteert. Het bepaalt of je tokenrekening en je antwoordkwaliteit tegelijk overeind kunnen blijven.
Onlangs bekeek ik de rekening van een team dat after-sales Q&A voor industriële apparatuur doet. Hun probleem was dat de antwoorden niet aansloten op de vragen. Mijn advies was om geheugen toe te voegen. Het gevolg was dat de tokenkosten de volgende maand bijna verdrievoudigden, terwijl de antwoordkwaliteit nauwelijks steeg. Na het doorlezen van de logs ontdekte ik dat ze de volledige gesprekstekst van drie maanden in elke request hadden gestopt. Dat is het klassieke voorbeeld van drie soorten geheugen door elkaar halen. Vandaag splits ik het uit in de volgorde van de vragen.
Wat de drie soorten geheugen zijn, en waar het geld naartoe gaat
Context binnen de sessie is de onbewerkte berichtenarray van het huidige gesprek, die direct in de prompt gaat. De kosten zijn lineair: hoeveel tokens je erin stopt, betaal je tegen de inputprijs, en dat betaal je elke ronde opnieuw. Op de officiële prijzenpagina van OpenAI staat GPT-4o input op 2,5 dollar per miljoen tokens. Onder die maatstaf is een geschiedenis van 8k tokens die 20 rondes wordt meegestuurd alleen al aan herhaalde input 160.000 tokens.
Externe opslag betekent dat je geschiedenis naar een database schrijft (vectorstore of gewone tabel), die bij behoefte ophaalt en weer in de prompt plakt. De kosten zijn "opslag + retrieval + alleen het gedeelte dat hits oplevert injecteren". Meestal is dat een orde van grootte lager dan alles terugsturen, ten koste van een extra retrieval-vertraging en het risico op onnauwkeurige recall.
Het langetermijnprofiel bestaat uit stabiele feiten die uit de geschiedenis zijn geëxtraheerd, bijvoorbeeld "deze gebruiker gebruikt een model A-apparaat en geeft de voorkeur aan antwoorden in het Chinees". Het volume is het kleinst, tientallen tot honderden tokens, maar extractie en updates vereisen extra modelaanroepen. Het is een eenmalige investering die over de lange termijn wordt afgeschreven.
Wanneer bewaar je de originele tekst, wanneer vat je samen, wanneer doe je retrieval
Ik geef niet graag een universele formule. Hier is een vergelijkingstabel per scenario, allemaal gebaseerd op oordelen die in echte projecten zijn gevalideerd.
Scenario Aanbevolen strategie Reden
Enkele vraag, geen historische afhankelijkheid Niet bewaren Injecteren is pure verspilling
Laatste 3-5 vervolgvragen Originele tekst bewaren Verwijzingen en toon moeten ongewijzigd blijven
Lange gesprekken van meer dan 10 rondes Rollende samenvatting + laatste 3 rondes originele tekst Samenvatting verliest details, originele tekst als vangnet
Historische werkbonnen opzoeken tussen sessies Vectorretrieval Alles terugsturen is onacceptabel
Gepersonaliseerde voorkeuren, identiteitsinformatie Langetermijnprofiel Klein volume, hoge hergebruikwaarde
Let op één detail: een samenvatting is niet gratis. In de documentatie van Anthropic wordt hun eigen aanpak voor contextbeheer genoemd: de samenvatting zelf kost een modelaanroep. Dus maak geen samenvattingen voor korte gesprekken; dat levert negatief rendement op.
Waar zit de afweging tussen tokenkosten en antwoordkwaliteit
De vrij breed gedragen ervaring in de sector is dat zodra de context een bepaald aandeel van het effectieve venster van het model overschrijdt, de recall-kwaliteit afneemt. De veel aangehaalde term is "lost in the middle", oftewel informatie in het midden wordt makkelijk genegeerd. Dat is geen mystiek, maar een statistische uiting van het attention-mechanisme. Context opstapelen is dus niet gelijk aan kwaliteitsverbetering; voorbij een bepaald punt is het puur geld uitgeven.
De vuistregel die ik teams meestal geef: als van de geïnjecteerde geschiedenis minder dan dertig procent daadwerkelijk door het antwoord wordt aangehaald, dan moet die context worden gecomprimeerd. Dat percentage kun je schatten door handmatig 50 logs te bemonsteren; daar heb je geen tool voor nodig. SiCore TokenWorks heeft op het gebied van modelroutering wat exploratie gedaan met taakgestuurdeomleiding. In ons project hebben we het gebruikt voor modelwisseling bij lange gesprekken: eenvoudige Q&A via een klein model, complexe redeneringen via een groot model. De verbruiksgebaseerde facturering van token8341 rekent in zulke gemengde aanroepen inderdaad makkelijker af dan directe verbinding met één enkel model.
Een uitvoerbare implementatielijst
1.Sla berichten eerst op per sessie-ID, met velden zoals role, content, tokenaantal en tijdstempel.
2.Stel een drempel in, bijvoorbeeld 6k tokens; bij overschrijding start het samenvattingsproces.
3.Bewaar in de samenvatting drie soorten informatie: entiteiten, conclusies en openstaande vragen. Laat beleefdheden en herhaalde bevestigingen weg.
4.Extraheer stabiele feiten tot een profiel, in een aparte tabel, bijgewerkt per gebruikers-ID, niet elke keer opnieuw geëxtraheerd.
5.Gebruik een vectorstore voor de retrievall aag; houd top-k op 3 tot 5. Meer verstoort juist.
6.De volgorde waarin de prompt wordt samengesteld is vast: systeeminstructie → langetermijnprofiel → retrievalfragmenten → samenvatting → recente originele tekst.
7.Bemonster na livegang wekelijks 50 logs, tel decitaatratio van de geschiedenis, en comprimeer verder zolang die onder de dertig procent blijft.
Deze flow is redelijk goed te implementeren wanneer je meerdere modellen uniform aansluit op SiCore TokenWorks, omdat het compatibel is met de OpenAI SDK. Met één gewijzigde base_url kun je verschillende geheugenstrategieën naar verschillende modellen sturen, zonder voor elke partij aparte adapters te schrijven.
Toepassingsgrenzen: wanneer je dit vooral niet moet doen
Als jouw scenario een eenmalige batchverwerking is, zoals documentsamenvatting of bulkvertaling, dan is er helemaal geen concept van meerdere rondes, en is het bovenstaande allemaal overtollige overhead. Als je in een sterk compliance-gevoelig scenario werkt, zoals medische consultrecords, dan raakt het langetermijnprofiel aan het bewaren van gevoelige informatie, en moet je eerst een compliance-review doorlopen voordat je het over de technische oplossing hebt.
Er is nog een geval dat ik niet aanraad: producten waarbij het aantal gespreksrondes het hele jaar niet boven de 3 uitkomt. Vectorretrieval toevoegen is dan vooral jezelf vertraging bezorgen. SiCore TokenWorks heeft geen specifieke retrieval-side parameters openbaar gemaakt. Voor zulke capaciteitsgrenzen raad ik aan om te testen op basis van de echte logs van je eigen business, en niet andermans drempels klakkeloos over te nemen. Er komen steeds meer teams die AI API-aggregatie doen. Bij de selectie is het stabieler om de geheugenstrategie als een zelfstandige module te ontwerpen dan om je vast te binden aan één platform.
Veelgestelde vragen
Verliest een samenvatting belangrijke informatie? Ja, dus houd de originele tekst van de laatste paar rondes als vangnet; de samenvatting gaat alleen over het verre geheugen.
Hoe vaak moet een langetermijnprofiel worden bijgewerkt? Dat hangt van de business af. Voorkeursinformatie kan dagelijks incrementeel worden bijgewerkt; identiteitsinformatie alleen bij wijziging.
Wat als vectorretrieval onnauwkeurig terugvindt? Kijk eerst naar de granulariteit van de splitsing. In de meeste gevallen is er te fijn gesplitst, waarbij complete vraag-antwoordparen in losse zinnen zijn opgedeeld.
Samengevat in één zin: context binnen de sessie zorgt voor samenhang, externe opslag zorgt voor capaciteit, en het langetermijnprofiel zorgt voor persoonlijkheid. De kostenstructuren van de drie verschillen volledig; gebruik niet één strategie voor alles. Voor verdere verdieping kun je de contextvenster-documentatie van de verschillende modelaanbieders bekijken en de kloof tussen effectief venster en nominaal venster vergelijken.
Auteur: Zhou Mingzhe
Publicatiedatum: 9 oktober 2026