Du klistrar in en rapport på 40 sidor och ber den lokala modellen om en sammanfattning. Svaret ser välskrivet ut, men det kan bygga på en bråkdel av texten. Den här artikeln visar hur du ser om dokumentet ryms, hur du delar upp det när det inte gör det och hur du kontrollerar att sakuppgifterna överlevde hela vägen.
Vad som hände när texten inte fick plats
Ollamas FAQ och API-dokumentation, lästa 1 nov 2026, beskriver hur kontextfönstret ställs in med num_ctx. De beskriver inte vad som händer när en prompt till /api/generate eller /api/chat är längre än fönstret. Bara inbäddningsanropet /api/embed har en dokumenterad truncate-inställning. Vi gjorde därför ett eget prov samma dag med Ollama 0.40.13 i Windows och modellen llama3:latest (8B, Q4_0).
Underlaget var en påhittad lagerrapport på 320 rader, ungefär 3 850 ord. Tre sakuppgifter låg på rad 20, rad 160 och rad 310. Frågan bad modellen svara ”saknas” om en uppgift inte fanns i texten.
| Inställning | prompt_eval_count | Rad 20 | Rad 160 | Rad 310 |
|---|---|---|---|---|
num_ctx 2 048 | 1 036 | ”Saknas” | ”Saknas” | Rätt |
num_ctx 8 192 | 7 431 | Rätt | Rätt | Rätt |
Med det mindre fönstret kom inget fel i API-svaret, och done_reason var stop precis som i den lyckade körningen. Kortningen syntes bara i serverloggen, som en varningsrad med texten truncating input prompt, prompt=7431 och new=1036. Uppgifterna på rad 20 och rad 160 föll bort medan slutet fanns kvar, och modellen påstod med säkerhet att två uppgifter saknades i texten.
Provet gäller en version, en modell och ett anropssätt. Andra versioner och klienter kan korta texten på ett annat sätt eller avbryta med ett fel. Gör därför provet nedan i din egen uppsättning.
Avgör om dokumentet ryms
Fältet prompt_eval_count anger enligt API-dokumentationen antalet token i prompten. Skicka hela dokumentet en gång med det num_ctx du tänker använda, och en gång med ett större värde som din dator klarar. Visar de två körningarna olika prompt_eval_count för samma text har den mindre körningen kortats.
{
"model": "DIN-MODELL:DIN-TAGG",
"prompt": "DIN TEXT",
"stream": false,
"options": { "num_ctx": 8192, "num_predict": 1 }
}num_predict satt till 1 begränsar svaret till en token, så körningen handlar nästan bara om inläsningen. I vårt prov blev 3 850 ord svensk text drygt 7 400 token, men förhållandet beror på modellens ordlista, så räkna inte om ett ordantal till token för en annan modell. Hur stort fönster datorn faktiskt orkar med är en egen fråga, som artikeln om kontext och minne i Ollama mäter. Den bredare dimensioneringen finns under hårdvara för lokal AI.
I ett chattprogram utan tokenräknare fungerar ett markörprov. Lägg tre påhittade meningar i dokumentets början, mitt och slut och fråga efter alla tre. LM Studios sida om standardinställningar per modell visar hur du sparar en kontextstorlek för en modell, men säger inget om vad som händer när texten är längre. Markörprovet visar det för din version.
Dela upp vid rubrikerna
Klipp dokumentet vid kapitel- eller avsnittsrubriker, inte vid ett fast antal tecken. En tabell eller en uppräkning som delas mitt itu blir två halva sakuppgifter, och ingen av delsammanfattningarna får med helheten. Ge varje del ett nummer och de sidnummer den täcker, så att du senare kan spåra en uppgift tillbaka.
Varje del, instruktionen och svaret ska rymmas tillsammans. Kontrollera prompt_eval_count för den största delen och lämna plats för svaret. Kör en del i taget. Ollamas FAQ anger att parallella anrop till samma modell ökar kontextstorleken och minnesbehovet, och du vill inte att ett snabbare upplägg ändrar förutsättningarna mitt i jobbet.
Samma beställning för varje del
Använd en och samma instruktion för alla delar, med fast temperature 0. Instruktionen ska beställa just de uppgifter du sedan kontrollerar:
Detta är del 3 av 8 (sidorna 21–30) av en rapport.
Sammanfatta delen på högst 150 ord.
Ta med alla siffror med enhet, datum, beslut och namn på organisationer.
Skriv bara det som står i delen.Spara varje svar i en egen fil med delnumret i namnet. Delsammanfattningarna är ditt mellanled: när en uppgift saknas i slutresultatet är det där du ser om den försvann i första eller andra steget.
Sätt ihop och se var fakta faller bort
Lägg delsammanfattningarna i ordning och be om en sammanfattning av dem, med samma krav på siffror, datum och beslut. Kontrollera prompt_eval_count igen. Åtta delar på 150 ord är cirka 1 200 ord, men med 30 delar kan även mellanledet bli för långt, och då behövs ett steg till.
Uppgifter faller bort på tre ställen. Det första är kortningen, som i vårt prov bara märktes i loggen och i tokenantalet. Det andra är uppdelningen, där en tabell eller ett resonemang hamnar på två sidor om en gräns. Det tredje är sammanslagningen: en siffra som bara förekommer i en del konkurrerar med sju andra delars innehåll om samma ordutrymme.
Är dina frågor konkreta, till exempel vad avtalet säger om uppsägning, passar sökning bättre än sammanfattning. Sökning hämtar de stycken som liknar en fråga, medan en sammanfattning ska täcka hela dokumentet. Den metoden testas i artikeln om lokal dokumentsökning med facit.
Kontrollprovet: fem sakuppgifter
Välj fem uppgifter ur originalet innan du läser sammanfattningen, så att resultatet inte styr urvalet. Ta dem från olika ställen och av de typer instruktionen beställde:
| Var i dokumentet | Exempel på uppgift | Utfall |
|---|---|---|
| Första sidorna | Ett datum eller ett beslut | Finns / fel / saknas |
| Mitten | En siffra med enhet | Finns / fel / saknas |
| Sista sidorna | En slutsats med siffra | Finns / fel / saknas |
| En tabell | Ett enskilt tabellvärde | Finns / fel / saknas |
| Nära en delningsgräns | Ett namn på en organisation | Finns / fel / saknas |
Leta upp varje uppgift i slutsammanfattningen och skriv ett av de tre utfallen. ”Fel” är värre än ”saknas”, eftersom läsaren då inte vet att något behöver kontrolleras. Saknas en uppgift letar du i delsammanfattningen för den del där den stod. Finns den där föll den bort vid sammanslagningen, annars vid delningen eller kortningen.
Vill du jämföra två modeller kör du samma fem uppgifter mot båda. Vi har inte mätt vilken modell som sammanfattar bäst, och antalet träffar i ditt eget prov säger mer om just ditt dokument än en allmän rangordning.
FAQ
Får jag ett felmeddelande när dokumentet är för långt för Ollama?
I vårt prov med Ollama 0.40.13 gav API-svaret inget fel. Varningen syntes bara i serverloggen, och prompt_eval_count visade 1 036 av 7 431 token.
Hur stora ska delarna vara?
Så stora att varje del, instruktionen och svaret ryms med marginal i det kontextfönster du har valt. Kontrollera prompt_eval_count för varje del i stället för att gissa.
Kan jag söka i dokumentet i stället för att sammanfatta det?
Sökning hämtar de stycken som liknar en fråga, medan en sammanfattning ska täcka hela dokumentet. Har du konkreta frågor passar sökning bättre.
Sammanfattar en större modell bättre?
Det har vi inte mätt. Kör samma kontrollprov med fem sakuppgifter på båda modellerna och jämför antalet träffar.
Källor och metod
- Ollama FAQ – inställning av kontextfönstret och parallella anrop.
- Ollama API – fältet prompt_eval_count och truncate för /api/embed.
- LM Studio: Per-model Defaults – kontextstorlek per modell.
Primärkällorna kontrollerades 1 nov 2026. Provet gjordes 1 nov 2026 med Ollama 0.40.13 i Windows 11, llama3:latest (8B, Q4_0), /api/generate, temperature 0 och seed 42, på en påhittad rapport. Det visar beteendet i den uppsättningen, inte hur alla versioner kortar en prompt. Uppdelningsmetoden och kontrollprovet är föreslagna arbetssätt som redaktionen inte har jämfört mot andra metoder.