NLI: Label-spezifische Hypothesen statt generisches Template #290

New issue

Closed

opened 2026-05-14 23:14:50 +02:00 by admin-mrrm · 1 comment

admin-mrrm commented

2026-05-14 23:14:50 +02:00

Owner

Problem

Der NLI-Klassifier (apps/mobile/src/services/nli-classifier.ts) nutzt aktuell ein generisches Hypothesen-Template:

export const NLI_HYPOTHESIS_TEMPLATE = Diese E-Mail handelt von ${label}.;

Das ergibt für die mDeBERTa-XNLI-Hypothesenpaare grammatikalisch holprige Sätze (z.B. Diese E-Mail handelt von Sendung. — Sendung braucht eigentlich einen Artikel), und es nutzt nicht die volle semantische Information die wir in CATEGORY_DESCRIPTIONS bereits pflegen.

Für den Web-Embedding-Pfad existiert bereits CATEGORY_DESCRIPTIONS mit reicheren Beschreibungen pro Label. Auf Mobile fließt davon nichts ein.

Hypothese

Konkretere, natürlichsprachliche Hypothesen-Sätze pro Label sollten den Entailment-Score messbar erhöhen — gerade bei der Close-Miss-Band 0.25–0.30 die wir in #268 als problematisch identifiziert hatten.

Beispiele (Vorschlag):

Sendung → Diese E-Mail informiert über eine Paketlieferung oder Versand.
Bestellung → Diese E-Mail bestätigt eine Bestellung oder einen Kauf.
Rechnung → Diese E-Mail enthält eine Rechnung oder Zahlungsaufforderung.
Konto → Diese E-Mail betrifft ein Benutzerkonto, Login oder Passwort.

Scope

Neue Konstante CATEGORY_NLI_HYPOTHESES in @mrrmlab/shared-types
nli-classifier.ts baut Hypothese pro Label aus der Map mit Fallback auf das alte Template (für User-Tags die nicht in der Map sind)
Tests für die Hypothesen-Wahl
Analyze-Script + NLI-Debug-Log schreiben die tatsächlich benutzte Hypothese pro Label (nicht nur das Template) — sonst kann man nichts vergleichen

Out of scope

A/B-Mess-Tooling für mehrere Templates (#251-related, vertagt)
Sender-Memory / Pro-Label-Threshold (separate Issues, online-driven)

Akzeptanzkriterien

Tests grün: hypothesis lookup pro Label, Fallback auf Generic-Template für unbekannte Labels
Mobile NLI klassifiziert weiter ohne Crash
JSONL-Debug-Log enthält pro Kandidat die benutzte Hypothese (für spätere Auswertung)

## Problem Der NLI-Klassifier (`apps/mobile/src/services/nli-classifier.ts`) nutzt aktuell ein generisches Hypothesen-Template: ```ts export const NLI_HYPOTHESIS_TEMPLATE = Diese E-Mail handelt von ${label}.; ``` Das ergibt für die mDeBERTa-XNLI-Hypothesenpaare grammatikalisch holprige Sätze (z.B. `Diese E-Mail handelt von Sendung.` — `Sendung` braucht eigentlich einen Artikel), und es nutzt nicht die volle semantische Information die wir in `CATEGORY_DESCRIPTIONS` bereits pflegen. Für den Web-Embedding-Pfad existiert bereits `CATEGORY_DESCRIPTIONS` mit reicheren Beschreibungen pro Label. Auf Mobile fließt davon nichts ein. ## Hypothese Konkretere, natürlichsprachliche Hypothesen-Sätze pro Label sollten den Entailment-Score messbar erhöhen — gerade bei der Close-Miss-Band 0.25–0.30 die wir in #268 als problematisch identifiziert hatten. Beispiele (Vorschlag): - `Sendung` → `Diese E-Mail informiert über eine Paketlieferung oder Versand.` - `Bestellung` → `Diese E-Mail bestätigt eine Bestellung oder einen Kauf.` - `Rechnung` → `Diese E-Mail enthält eine Rechnung oder Zahlungsaufforderung.` - `Konto` → `Diese E-Mail betrifft ein Benutzerkonto, Login oder Passwort.` ## Scope 1. Neue Konstante `CATEGORY_NLI_HYPOTHESES` in `@mrrmlab/shared-types` 2. `nli-classifier.ts` baut Hypothese pro Label aus der Map mit Fallback auf das alte Template (für User-Tags die nicht in der Map sind) 3. Tests für die Hypothesen-Wahl 4. Analyze-Script + NLI-Debug-Log schreiben die *tatsächlich* benutzte Hypothese pro Label (nicht nur das Template) — sonst kann man nichts vergleichen ## Out of scope - A/B-Mess-Tooling für mehrere Templates (#251-related, vertagt) - Sender-Memory / Pro-Label-Threshold (separate Issues, online-driven) ## Akzeptanzkriterien - [ ] Tests grün: hypothesis lookup pro Label, Fallback auf Generic-Template für unbekannte Labels - [ ] Mobile NLI klassifiziert weiter ohne Crash - [ ] JSONL-Debug-Log enthält pro Kandidat die benutzte Hypothese (für spätere Auswertung)

admin-mrrm referenced this issue

2026-05-14 23:21:38 +02:00

feat(mobile,#290): label-spezifische NLI-Hypothesen #291

admin-mrrm commented

2026-05-14 23:48:37 +02:00

Author

Owner

Ergebnis der Kalibrierung — Hypothese nicht bestätigt

Branch feat/290-nli-label-hypotheses (PR #291) gegen INBOX-Charge laufen lassen, Vergleich mit pre-#290-JSONL:

Metrik	Vorher (generisch)	Nachher (label-spezifisch)
Fast-path Hit-Rate	64 %	13 %
Llama-Fallback	36 %	88 %
Max Top-Score	0.95+	0.39

Struktureller Befund: NLI-Entailment belohnt breite Hypothesen — eine generische Aussage "Diese E-Mail handelt von X." lässt sich von fast jedem Mail-Text leichter implizieren als ein konkreter Satz wie "Diese E-Mail informiert über eine Paketlieferung oder den Versand."

Das Ergebnis war zudem durch eine Asymmetrie verzerrt: Default-Kategorien nutzten die neuen spezifischen Sätze, User-Tags (z.B. Zahlung, Paket, Shoppe) fielen auf das alte generische Template zurück. Damit gewannen User-Tags strukturell über die Default-Kategorien, selbst wenn semantisch ein Default-Label gepasst hätte (Beispiel: Werbemail "25 % Rabatt" → Top-1 Zahlung 0.19 statt Werbung 0.12).

Konsequenz: Hypothese aus dem Issue widerlegt. Konkretere Hypothesen verbessern den Score nicht — sie schaden. PR #291 geschlossen ohne Merge.

Nächster Versuch: Lever 2 — Snippet-Preprocessing mit Subject-Weighting (Issue folgt). Das Subject wird verdoppelt vor den Body gestellt, damit das stärkste Signal stärker gewichtet wird. Theorie: snippet-länge-unabhängig, gegen lange Footer robust.

## Ergebnis der Kalibrierung — Hypothese nicht bestätigt Branch `feat/290-nli-label-hypotheses` (PR #291) gegen INBOX-Charge laufen lassen, Vergleich mit pre-#290-JSONL: | Metrik | Vorher (generisch) | Nachher (label-spezifisch) | |---------------------|--------------------|-----------------------------| | Fast-path Hit-Rate | **64 %** | **13 %** | | Llama-Fallback | 36 % | 88 % | | Max Top-Score | 0.95+ | 0.39 | **Struktureller Befund:** NLI-Entailment belohnt *breite* Hypothesen — eine generische Aussage "Diese E-Mail handelt von X." lässt sich von fast jedem Mail-Text leichter implizieren als ein konkreter Satz wie "Diese E-Mail informiert über eine Paketlieferung oder den Versand." Das Ergebnis war zudem durch eine Asymmetrie verzerrt: Default-Kategorien nutzten die neuen spezifischen Sätze, User-Tags (z.B. *Zahlung*, *Paket*, *Shoppe*) fielen auf das alte generische Template zurück. Damit gewannen User-Tags strukturell über die Default-Kategorien, selbst wenn semantisch ein Default-Label gepasst hätte (Beispiel: Werbemail "25 % Rabatt" → Top-1 *Zahlung* 0.19 statt *Werbung* 0.12). **Konsequenz:** Hypothese aus dem Issue widerlegt. Konkretere Hypothesen verbessern den Score nicht — sie schaden. PR #291 geschlossen ohne Merge. **Nächster Versuch:** Lever 2 — Snippet-Preprocessing mit Subject-Weighting (Issue folgt). Das Subject wird verdoppelt vor den Body gestellt, damit das stärkste Signal stärker gewichtet wird. Theorie: snippet-länge-unabhängig, gegen lange Footer robust.

admin-mrrm closed this issue

2026-05-14 23:48:51 +02:00

admin-mrrm referenced this issue

2026-05-14 23:51:49 +02:00

NLI: Subject-Weighting im Premise (2× prepend) für besseren Score-Anker #292

admin-mrrm referenced this issue from a commit

2026-05-14 23:55:24 +02:00

feat(mobile,#292): Subject 2× im Premise für stärkeren NLI-Anker

admin-mrrm referenced this issue

2026-05-14 23:55:36 +02:00

feat(mobile,#292): NLI Subject-Weighting (Lever 2) #293

admin-mrrm referenced this issue