Map-reduce voor lange gesprekken: samenvatten voorbij de contextlimiet

Een taalmodel kan maar een beperkte hoeveelheid tekst tegelijk lezen: de contextlimiet. Een gesprek van twee uur levert al snel een transcript op dat groter is dan die limiet, of zo groot dat het model belangrijke details in het midden gaat missen. Map-reduce lost dat op door het probleem op te knippen. Je snijdt het transcript in stukken die wél passen, laat het model elk stuk apart samenvatten (de map-stap), en voegt die deelsamenvattingen daarna samen tot één verslag (de reduce-stap). Is het samengevoegde geheel nog te groot, dan herhaal je de reduce-stap in lagen tot het past. Zo houd je grip op lengte, kosten en dekking, ook bij zeer lange gesprekken. De prijs die je betaalt: het model ziet nooit het hele gesprek in één keer, dus dwarsverbanden tussen ver uit elkaar liggende passages kunnen verloren gaan. Dit artikel legt uit hoe map-reduce werkt, waarom "alles in één prompt" bij lange gesprekken juist slechter wordt, en welke keuzes bepalen of het verslag klopt.

Het probleem: de contextlimiet van een taalmodel

Elk taalmodel heeft een maximum aan tekst dat het in één beurt kan verwerken: de context. Alles wat je erin stopt — het transcript, de instructie en het antwoord dat het model schrijft — moet samen binnen die limiet passen. Voor korte gesprekken is dat geen probleem: het hele transcript past, het model leest alles en schrijft een verslag. Maar een intake van een uur, een lang MDO of een geluidsopname van een middag levert een transcript op dat die limiet ruim overschrijdt.

Er speelt nog iets. Ook als een transcript technisch nog nét past, betekent dat niet dat het model alles even goed gebruikt. Hoe langer de invoer, hoe groter de kans dat informatie in het midden ondersneeuwt — daarover meer in sectie 3. Kortom: bij lange gesprekken heb je een aanpak nodig die het transcript niet in één hap probeert te verwerken, maar in behapbare stukken. Map-reduce is de bekendste van die aanpakken.

Wat map-reduce is — en waar het vandaan komt

De term komt niet uit de AI-wereld. Map-reduce is een programmeerpatroon dat Google in 2004 beschreef om enorme datasets over veel computers tegelijk te verwerken: je definieert een map-functie die elk stukje data apart bewerkt, en een reduce-functie die de tussenresultaten samenvoegt [1]. Het runtime-systeem verdeelt het werk dan automatisch over een cluster machines [1]. Datzelfde idee — splitsen, apart bewerken, samenvoegen — is later overgenomen om lange documenten door taalmodellen te laten samenvatten [3].

Toegepast op samenvatten ziet het er zo uit. Je knipt de lange tekst in stukken die elk binnen de contextlimiet passen. In de map-stap vraag je het model per stuk een samenvatting te maken; dat levert net zoveel deelsamenvattingen op als er stukken zijn [3]. In de reduce-stap voeg je die deelsamenvattingen samen tot één geheel [3]. Is dat samengevoegde geheel nog te lang, dan pas je de reduce-stap opnieuw toe — in lagen, tot je uitkomt op een samenvatting van de gewenste lengte [3]. Elke laag maakt de tekst fors kleiner, dus zelfs een gesprek van vele uren is met een paar reduce-rondes terug te brengen tot één verslag [3].

Waarom "alles in één prompt" juist slechter wordt

De verleiding is groot om te wachten op modellen met almaar grotere contextvensters en dan gewoon het hele transcript in één prompt te gooien. Onderzoek laat zien waarom dat een valkuil is. In de studie Lost in the Middle testten onderzoekers hoe goed taalmodellen informatie gebruiken die op verschillende plekken in een lange invoer staat. De uitkomst: de prestaties zijn het hoogst wanneer de relevante informatie aan het begin of het eind staat, en zakken duidelijk in wanneer het model die informatie uit het midden moet halen [2]. De grafiek van die prestatie vormt een U: hoog aan de randen, laag in het midden [2].

Voor een gespreksverslag is dat precies het verkeerde gedrag. Een belangrijke afspraak kan halverwege een gesprek van anderhalf uur vallen — juist op de plek waar een model met alles-in-één-prompt het slechtst oplet. Map-reduce omzeilt dit doordat elk stuk klein genoeg is dat er geen "midden" is om in te verdwalen: binnen een kort stuk let het model overal even goed op, en de map-stap dwingt af dat elk deel van het gesprek daadwerkelijk gelezen en samengevat wordt [3]. Je ruilt zo een onvoorspelbaar "het model heeft dit stukje gemist" in voor gegarandeerde dekking van het hele transcript.

Map-reduce op een gesprek, stap voor stap

Bij een gesproken gesprek begint map-reduce eigenlijk al eerder, bij de transcriptie. Whisper, het spraakherkenningsmodel, werkt zelf ook in stukken: het model verwerkt telkens een venster van dertig seconden audio, en lange opnames worden in overlappende brokken door het model gehaald en daarna aan elkaar geregen [4]. Het transcript dat eruit komt, is dus al opgebouwd uit segmenten met tijdstempels. Die tijdstempels zijn goud waard voor de volgende stappen.

De verslagketen met map-reduce loopt dan zo:

1. Knippen. Het transcript wordt in stukken geknipt die binnen de contextlimiet passen, met een kleine overlap tussen opeenvolgende stukken zodat een zin die op een knip valt niet halverwege wordt afgekapt.
2. Map. Het taalmodel vat elk stuk apart samen: de kernpunten, besluiten en actiepunten uit dat deel van het gesprek [3].
3. Reduce. De deelsamenvattingen worden samengevoegd en het model schrijft daaruit één samenhangend concept-verslag volgens het sjabloon voor dit gesprekstype [3].
4. Herhalen indien nodig. Was het gesprek zo lang dat zelfs de deelsamenvattingen samen niet passen, dan wordt de reduce-stap in lagen herhaald tot het past [3].
5. Reviewen. Een mens leest het concept, controleert het tegen de bron en keurt het goed. Pas daarna is het verslag definitief.

Een aandachtspunt loopt door alle stukken heen: consistentie van namen en termen. Als een cliëntnaam of een medicijn in het ene stuk goed wordt herkend en in het andere net anders, ontstaan er in het eindverslag twee schrijfwijzen. Een vast organisatie-woordenboek voor spraakherkenning houdt eigennamen over alle stukken heen gelijk — precies het soort fout dat map-reduce anders zou uitvergroten.

Wat je verliest — en hoe je dat opvangt

Map-reduce is geen gratis lunch. Omdat het model elk stuk apart bekijkt, ziet het nooit het hele gesprek in één keer. Dwarsverbanden tussen passages die ver uit elkaar liggen — iemand die aan het begin iets belooft en dat aan het eind terugneemt — kunnen daardoor onopgemerkt blijven. Kort gezegd ruil je met map-reduce diepe redenering over het geheel in voor voorspelbare dekking, beheersbare kosten en stabiliteit. Voor een verslag, waar volledigheid en herleidbaarheid zwaarder wegen dan literaire samenhang, is dat meestal een goede ruil.

Er zijn drie knoppen om de nadelen te beperken. Overlap tussen stukken voorkomt dat informatie op een knippunt tussen wal en schip valt. Stukgrootte is een afweging: grotere stukken behouden meer context binnen één samenvatting maar lopen eerder tegen het "lost in the middle"-effect aan [2]; kleinere stukken zijn scherper maar versnipperen het verhaal. En de reduce-instructie bepaalt of het eindverslag dubbelingen samenvoegt en tegenstrijdigheden markeert in plaats van ze allebei klakkeloos over te nemen. Deze keuzes zijn geen exacte wetenschap; ze verbeteren naarmate je ziet welke fouten in de praktijk terugkomen. Wie correcties van reviewers systematisch bewaart, bouwt daarmee een data-flywheel van eigen correcties die het knippen en samenvatten over tijd beter afstelt.

Waarom bewijsweergave en review hier extra tellen

Juist omdat map-reduce het gesprek in stukken hakt en in lagen samenvat, is het belangrijk dat je elke zin in het eindverslag kunt terugvolgen naar de bron. Bij elke reduce-laag comprimeert het model tekst, en bij compressie kan een taalmodel formuleringen produceren die scherper of stelliger klinken dan wat er werkelijk gezegd is. Zonder een spoor terug naar de opname is niet te controleren of een zin in het verslag echt uit het gesprek komt of onderweg is ontstaan.

Daarom houdt Verbinn elke zin in het concept klikbaar naar de letterlijke bronregel in het transcript — mogelijk gemaakt door de tijdstempels uit de transcriptiestap. En daarom blijft elk verslag een concept tot een mens het heeft goedgekeurd: zonder review geen export. Dat sluit ook aan bij de eis van de Autoriteit Persoonsgegevens dat belangrijke besluiten menselijke tussenkomst hebben en dat je niet méér gegevens verwerkt dan nodig [5]. Map-reduce maakt het schrijven schaalbaar; de mens blijft de eindredacteur die beslist of het concept klopt.

Waarom dit lokaal op één Mac past

Een prettige eigenschap van map-reduce is dat de map-stap uit losse, onafhankelijke taken bestaat: elk stuk kan apart worden samengevat, in principe parallel [1][3]. Dat maakt het patroon van oorsprong geschikt om over veel machines te verdelen [1]. Maar diezelfde eigenschap werkt ook de andere kant op: omdat de stukken los van elkaar staan, kun je ze net zo goed één voor één achter elkaar verwerken op één machine, zonder dat je een cluster of de cloud nodig hebt. Je ruilt dan wat snelheid in voor eenvoud — de dekking blijft gelijk.

Voor een opstelling waarbij geen woord het pand mag verlaten, is dat precies wat je wilt. Het hele proces — knippen, map, reduce, herhalen — draait op de tekst die al op de machine staat, met een model dat al op de machine staat. Er is geen enkel moment waarop een stuk transcript naar een externe dienst hoeft. Zo kun je een gesprek van uren verwerken tot één controleerbaar concept, zonder de contextlimiet te raken en zonder dat er iets weglekt.