# Minnesbästa praxis
SUMMARY: Hur man strukturerar minnen för effektiv återkallning — kategorier, nycklar, taggar, prioriteringar.

Minnesbästa praxis
Hur ni strukturerar minnen avgör hur användbara de är. Den här guiden täcker
mönster för kategorisering, taggning och prioritering av minnen så att LLM:en
kan återkalla rätt information vid rätt tidpunkt.
Kategorier: välj den mest specifika
| Kategori | Använd för | Exempel |
|----------|---------|---------|
|  | Användarnamn, roll, kontaktinfo |  |
|  | Tycker om, ogillar, arbetsstil |  |
|  | Verifierbara fakta |  |
|  | Projektstatus, beslut |  |
|  | Användarens färdigheter |  |
|  | Tidigare fel att undvika |  |
|  | Sessionsrelevant kontext |  |
|  | Diverse anteckningar |  |
> [!TIP]
> Vid tveksamhet, använd  för verifierbar info och  för allt annat.
> Överkategorisera inte — bättre med en tydlig  än en förvirrande .
Nycklar: meningsfulla identifierare
Fältet  är minnets identifierare. Använd meningsfulla, stabila nycklar:
Bra nycklar:
- 
- 
- 
- 
Dåliga nycklar:
-  (inte meningsfull)
-  (inte beskrivande)
-  (datum hjälper inte återkallning)
Namngivningskonventioner för nycklar
-  (gemener med understreck)
- Prefixa med kategori: , , 
- Använd beskrivande substantiv, inte verb
- Håll under 50 tecken
Taggar: för sökning och filtrering
Taggar möjliggör snabb filtrering och sökning. Lägg till 2–5 taggar per minne:
[CODE BLOCK]
Taggmönster
- Projektnamn: , , 
- Ämnen: , , , 
- Status: , , 
- Prioriteringsindikatorer: , 
> [!NOTE]
> Taggar är skiftesokänsliga. Använd gemener för konsekvens.
Prioriteringar: var realistisk
| Prioritering | Använd för | % av minnen |
|----------|---------|---------------|
|  | Användaridentitet, juridisk info, oåterkalleliga beslut | 5% |
|  | Aktiva projekt, viktiga inställningar | 20% |
|  | De flesta fakta, anteckningar, kontext | 65% |
|  | Efemärt, trevligt att veta | 10% |
> [!WARNING]
> Markera inte allt som . Om allt är kritiskt är inget det.
> Reservera  för saker som skulle orsaka verklig skada om de glöms.
När man ska lagra vs inte lagra
Lagra alltid
- Användaridentitet (namn, e-post, roll)
- Långsiktiga inställningar
- Projektbeslut och motivering
- Tidigare misstag och lärdomar
- Åtaganden gentemot användaren
Lagra inte
- Övergående tillstånd (använd variabler istället)
- Ordagrant konversationshistorik (chattsystemet hanterar detta)
- Känslig data (lösenord, API-nycklar)
- Lätt härledbara fakta (aktuellt datum, filinnehåll)
- Efemär kontext (använd -kategori med låg prioritet)
Uppdatera minnen
POST  med samma  +  uppdaterar det befintliga minnet:
[CODE BLOCK]
> [!TIP]
> Använd stabila nycklar så att ni kan uppdatera utan att skapa dubbletter.
> LLM:en bör åter-POSTa samma nyckel när information ändras, inte skapa nya minnen.
Minneslivscykel
[CODE BLOCK]
- Create: POST /memory med full kontext
- Active: Återkalla ofta, uppdatera vid behov
- Stale: Fortfarande relevant men inte aktivt använd (lägre prioritet?)
- Archive: Sätt prioritet till , behåll för historisk referens
- Delete: DELETE /memory/:id när inte längre relevant
Periodisk rensning
[CODE BLOCK]
Mönster: Minnesarv
För hierarkisk kontext (projekt → delprojekt → uppgift):
[CODE BLOCK]
LLM:en kan sedan söka  för att hitta alla relaterade minnen.
Mönster: Beslutslogg
Lagra beslut med motivering så att LLM:en inte återupprättar dem:
[CODE BLOCK]
Mönster: Misstag undvikande
Lagra misstag med specifika undvikandeinstruktioner:
[CODE BLOCK]
Antimönster att undvika
> [!WARNING]
> - Lagra konversationsloggar — chattsystemet hanterar detta
> - Lagra hela filer — använd skriptlager eller extern lagring
> - Lagra efemärt tillstånd — använd variabler
> - Lagra hemligheter — använd miljövariabler
> - Duplicera minnen — använd stabila nycklar
> - Övertagga — 2–5 taggar per minne är idealiskt
> - Allt är kritiskt — var realistisk med prioriteringar
Nästa steg
- Memory API
- Beständig LLM-agent
- Minnes taggningsstrategi