Ollama och chattminne: vem sparar samtalet?

En chattruta kan visa gårdagens samtal samtidigt som nästa anrop bara innehåller din senaste fråga. För att reda ut Ollamas chattminne behöver du därför undersöka två saker: vad klienten har sparat och vad den faktiskt skickar. Börja med ett påhittat projektnamn och jämför två små anrop. Då får du ett konkret underlag för beslutet om historiken ska följa med nästa gång.

Det här är ett föreslaget läsarprov, inte en redovisning av egna modellkörningar. Inga uppmätta svar eller träffprocenter presenteras. Exemplen riktas till en nedladdad lokal modell via http://localhost:11434/api/chat. Ollamas API-introduktion skiljer den lokala basadressen från molnets och beskriver lokala anrop med en nedladdad modell. Kontrollera därför både adress och modellval innan du börjar; ordet localhost är inte ensamt ett kvitto på vilket modellval en klient gör.

Skilj tre beslut som lätt kallas minne

Skriv tre rubriker i dina anteckningar: sparad historik, skickad historik och laddad modell. Under den första noterar du vad din klient ska kunna öppna efter omstart. Under den andra sparar du anropets messages-lista. Under den tredje antecknar du laddningsinställningen. Med den uppdelningen kan du exempelvis välja att bevara ett samtal på disk men börja en ny konversation utan att bifoga de gamla turerna.

Ollamas chat-referens anger messages som en lista med meddelanden, med roll och innehåll, och keep_alive som modellens uppehållstid. Att modellen hålls laddad är alltså en annan parameter än konversationsturerna i anropet. Läs artikeln om keep-alive när problemet är laddningstid eller upptaget arbetsminne. Här undersöker du innehållet som följer med till nästa fråga.

Undvik också att kalla modellvikter eller promptcache för ditt chattarkiv. I detta prov är arkivet det underlag du själv väljer att spara och läsa tillbaka. Gör inget antagande om var en viss chattapp lagrar sina samtal, hur länge den behåller dem eller vad dess knapp för ny chatt gör. Det behöver kontrolleras mot just den klientens dokumentation och ett eget anrop.

Bestäm facit innan du frågar modellen

Använd projektnamnet Mosslykta-482 som ett påhittat facit. Slutfrågan ber om projektnamnet eller svaret OKANT om det saknas i samtalet. I variant A finns bara slutfrågan. I variant B finns dessutom en tidigare användartur med namnet och en assistenttur som bekräftar det. Du ska hålla modell, slutfråga och övriga fält lika. Det avsiktligt ändrade underlaget är de två historikturerna.

Det konstruerade assistentmeddelandet i B är testdata som du själv lägger in. Det är inte ett uppmätt tidigare modellsvar. Det gör jämförelsen enkel att upprepa även om den första bekräftelsen annars skulle bli olika mellan körningarna. Välj gärna ett eget ovanligt namn före provet, men byt då konsekvent i båda historikturerna och i ditt facit.

Gör två separata anrop från PowerShell

Starta din lokala Ollama-server och välj en modell som redan är nedladdad. Byt exempelvärdet llama3.2 till det exakta lokala modellnamnet. Kodens syntax är anpassad för Windows PowerShell 5.1; Microsoft dokumenterar ConvertTo-Json och Invoke-RestMethod för den versionen. Koden bygger objekt, omvandlar dem till JSON med uttryckligt djup och skickar UTF-8-byte med Invoke-RestMethod. Inga PowerShell 7-operatorer eller curl-alias behövs.

Kör först A och granska utskriften av jsonA innan du fortsätter med B. Dokumentationen anger strömning som standard; med stream: false begär du här ett samlat svar som är lättare att läsa. Själva svarstexten hämtas från message.content. Modellens ord kan variera: de förväntade svaren nedan är bedömningskriterier, inga löften om hur just din modell svarar.

$uri = 'http://localhost:11434/api/chat'
$modell = 'llama3.2' # Byt till din nedladdade lokala modell
$fraga = 'Vad heter mitt projekt? Svara bara med namnet, eller OKANT om namnet saknas i samtalet.'

# A: samma slutfraga, utan tidigare turer
$utanHistorik = [ordered]@{
    model = $modell
    messages = @(
        @{ role = 'user'; content = $fraga }
    )
    stream = $false
}
$jsonA = $utanHistorik | ConvertTo-Json -Depth 10
$jsonA # Inspektera payloaden innan den skickas
$svarA = Invoke-RestMethod -Uri $uri -Method Post -ContentType 'application/json; charset=utf-8' -Body ([System.Text.Encoding]::UTF8.GetBytes($jsonA))
$svarA.message.content

# B: samma slutfraga, med explicit user/assistant-historik
$medHistorik = [ordered]@{
    model = $modell
    messages = @(
        @{ role = 'user'; content = 'Mitt projekt heter Mosslykta-482. Bekrafta namnet.' }
        @{ role = 'assistant'; content = 'Ditt projekt heter Mosslykta-482.' }
        @{ role = 'user'; content = $fraga }
    )
    stream = $false
}
$jsonB = $medHistorik | ConvertTo-Json -Depth 10
$jsonB # Inspektera payloaden innan den skickas
$svarB = Invoke-RestMethod -Uri $uri -Method Post -ContentType 'application/json; charset=utf-8' -Body ([System.Text.Encoding]::UTF8.GetBytes($jsonB))
$svarB.message.content

Om anslutningen misslyckas har du inget resultat från minnesprovet ännu. Kontrollera servern och modellnamnet och kör om samma variant. Ett felmeddelande om anslutning ska inte bokföras som att modellen saknade historik. Undvik samtidigt att byta både modell och historik för att få ett bättre svar; då blir det svårare att förklara vad som gjorde skillnaden.

Läs payloaden först och svaret därefter

Granska jsonA och jsonB som två separata bevis. A ska innehålla en user-tur och inget projektnamn. B ska innehålla tre turer i ordningen user, assistant, user, med namnet i de två första. Om utskrifterna inte stämmer med detta är klientunderlaget fel redan innan du tolkar svaret. Rätta då objektet och gör ett nytt anrop.

Bedöm svaren med två enkla kriterier: rätt projektnamn eller rätt avstående, och om svaret håller det begärda formatet. Om B ger rätt namn plus en förklaring har modellen hittat uppgiften men inte följt formatet helt. Om A gissar ett namn har den inte följt instruktionen om saknad information. Ett korrekt gissat svar bevisar inte sparad historik; payloaden visar vilka turer du skickade, medan svaret visar vad modellen gjorde med underlaget.

Det här jämförelseprovet kan alltså hjälpa dig kontrollera ditt anrop utan att avgöra varje intern optimering i servern. Spara modellnamn, båda JSON-texterna och båda svaren tillsammans om du vill jämföra efter en uppdatering. Markera särskilt om du ändrat systeminstruktioner mellan proven. Då slipper du i efterhand försöka återskapa vilken fråga modellen faktiskt fick.

Välj vad klienten ska bevara och återanvända

Om du bygger en egen klient kan du börja med en explicit konversationslista. Lägg användarens fråga i listan, skicka den och lägg sedan till det mottagna assistentsvaret inför nästa fråga. Besluta separat om listan ska skrivas till en fil för att kunna öppnas efter omstart. Detta är ett designförslag för din klient, inte ett påstående om hur alla Ollama-appar fungerar.

Låt en ny chatt skapa en ny lista utan tidigare user- och assistant-turer. Bestäm samtidigt om gemensamma systeminstruktioner ska följa med. Att tömma det aktiva anropets historik och att radera ett sparat samtal är två olika användarhandlingar i den föreslagna designen. Prova knappen med samma kontrollfråga och läs payloaden: projektnamnet ska inte följa med om du avser att börja utan den gamla konversationen.

Om namn ändå kommer in i den nya listan, leta efter en återinläst fil, en sammanfattning eller ett förifyllt meddelande i din egen klientkod. Att bara gömma de gamla pratbubblorna är ingen tillräcklig kontroll av detta designkrav. Skriv ned vad som ska ske vid ny chatt, öppna sparad chatt och radera chatt, och kontrollera varje handling mot det skickade objektet.

Ge lång historik en egen budget

När du väljer att skicka fler turer behöver du också välja vilka som fortfarande är relevanta. Ett praktiskt exempel är att behålla projektets aktuella namn men stryka tre övergivna namnförslag. Om du ersätter turer med en sammanfattning, märk den som en sammanfattning och kontrollera den mot originalet. Annars kan ett gammalt missförstånd bli det underlag varje senare fråga bygger på.

Ollamas sida om kontextlängd beskriver gränsen i token och att större kontext kräver mer minne. Längre arkiv på disk och större tillgänglig kontext är därför separata beslut. Använd guiden om kontextens minnesbudget när den medskickade historiken växer. Om frågan i stället gäller roller, chattformat eller SYSTEM finns artikeln om Ollamas promptmall.

Avsluta med ett konkret beslut: vilka turer ska nästa anrop innehålla, var vill du själv spara dem och vad ska ny chatt tömma? Upprepa sedan kontrollfrågan efter att du öppnat en sparad konversation och efter att du startat en ny. De två payloadarna ger ett tydligare underlag för klientens funktion än att enbart fråga modellen om den kommer ihåg dig.

Källor och metod

• Ollama: Generate a chat message — messages, stream, keep_alive och svarsfält.
• Ollama: API introduction — lokal basadress och nedladdad modell.
• Ollama: Context length — tokenbudget och minnesbehov.
• Microsoft: ConvertTo-Json i Windows PowerShell 5.1 — JSON-omvandling och Depth.
• Microsoft: Invoke-RestMethod i Windows PowerShell 5.1 — HTTP-anrop med Body och ContentType.

Källorna kontrollerades 28 okt 2026. Payloadjämförelsen, facit och klientdesignen är redaktionella metodförslag. Inga lokala Ollama-svar har uppmätts i arbetet med artikeln. Kontrollera metoden igen om chat-API:ts meddelandeformat ändras.