feat: Sender→Label Memory für Online-Tag-Learning #294

New issue

Closed

opened 2026-05-15 00:29:01 +02:00 by admin-mrrm · 0 comments

admin-mrrm commented

2026-05-15 00:29:01 +02:00

Owner

Problem

Nach #268, #290, #292 sind die manuellen NLI-Kalibrierungs-Hebel ausgereizt (Threshold getuned, Label-Wording und Subject-Weighting beide negativ). Pivot auf Online-Feedback-Loop: das System lernt aus User-Bestätigungen statt aus manuellen Tweaks am Premise.

Lösung — Erster Hebel

Sender→Label Memory: Bestätigt ein User auf einer Mail von noreply@dhl.de den Tag „Sendung", merkt sich der Server {owner, senderAddr="noreply@dhl.de", tagId=Sendung, confirmCount=1}. Beim nächsten Batch aus dieser Adresse → Tag direkt vergeben, NLI gespart.

Deterministisch, kein ML, für die häufigen Standard-Sender (Bank, Shop, Tracking) extrem effektiv.

Scope

In-scope:

Neue Tabelle mail_sender_label_memory (id, ownerSub, senderAddr, tagId, confirmCount, removeCount, lastSeenAt)
Unique-Index auf (ownerSub, senderAddr, tagId)
Hooks: confirmTag → confirmCount++; removeMessageTag (wenn vorher suggested/confirmed) → removeCount++
Batch-Endpoint POST /mail/sender-memory/lookup mit {senderAddrs: string[]} → Map sender→top-tags
Mobile categorizeFolderItems: vor NLI Memory pro Seite abfragen; bei klarem Match (confirmCount ≥ 2 und confirm > remove) → Tag direkt setzen, NLI skip
MailResource.lookupSenderMemory() im API-Client
Adress-Normalisierung: "John <john@x.de>" → john@x.de (lowercase, trim)

Out-of-scope (Follow-ups):

Web-Classifier-Integration
UI zum Anzeigen / manuellen Pflegen der Memory
Auto-Decay (alte Einträge verfallen)
Domain-basiertes Fallback (*@dhl.de)

TDD-Reihenfolge

Drizzle-Migration + Schema
SenderMemoryService (upsert/lookup) — Unit
Hooks in MailService.confirmTag / removeMessageTag — Unit
Endpoint + e2e
API-Client lookupSenderMemory
Categorizer-Integration — Unit

Bezug

Nach #290 und #292 (beide manuelle Hebel verworfen). Online-Loop ist die Konsequenz.

## Problem Nach #268, #290, #292 sind die manuellen NLI-Kalibrierungs-Hebel ausgereizt (Threshold getuned, Label-Wording und Subject-Weighting beide negativ). Pivot auf **Online-Feedback-Loop**: das System lernt aus User-Bestätigungen statt aus manuellen Tweaks am Premise. ## Lösung — Erster Hebel **Sender→Label Memory:** Bestätigt ein User auf einer Mail von `noreply@dhl.de` den Tag „Sendung", merkt sich der Server `{owner, senderAddr="noreply@dhl.de", tagId=Sendung, confirmCount=1}`. Beim nächsten Batch aus dieser Adresse → Tag direkt vergeben, NLI gespart. Deterministisch, kein ML, für die häufigen Standard-Sender (Bank, Shop, Tracking) extrem effektiv. ## Scope **In-scope:** - Neue Tabelle `mail_sender_label_memory` (id, ownerSub, senderAddr, tagId, confirmCount, removeCount, lastSeenAt) - Unique-Index auf `(ownerSub, senderAddr, tagId)` - Hooks: `confirmTag` → confirmCount++; `removeMessageTag` (wenn vorher suggested/confirmed) → removeCount++ - Batch-Endpoint `POST /mail/sender-memory/lookup` mit `{senderAddrs: string[]}` → Map sender→top-tags - Mobile `categorizeFolderItems`: vor NLI Memory pro Seite abfragen; bei klarem Match (confirmCount ≥ 2 und confirm > remove) → Tag direkt setzen, NLI skip - `MailResource.lookupSenderMemory()` im API-Client - Adress-Normalisierung: `"John <john@x.de>"` → `john@x.de` (lowercase, trim) **Out-of-scope (Follow-ups):** - Web-Classifier-Integration - UI zum Anzeigen / manuellen Pflegen der Memory - Auto-Decay (alte Einträge verfallen) - Domain-basiertes Fallback (`*@dhl.de`) ## TDD-Reihenfolge 1. Drizzle-Migration + Schema 2. `SenderMemoryService` (upsert/lookup) — Unit 3. Hooks in `MailService.confirmTag` / `removeMessageTag` — Unit 4. Endpoint + e2e 5. API-Client `lookupSenderMemory` 6. Categorizer-Integration — Unit ## Bezug Nach #290 und #292 (beide manuelle Hebel verworfen). Online-Loop ist die Konsequenz.