[Idea] Lokale KI: Tasks und Termine aus E-Mails erstellen

admin-mrrm commented

2026-04-26 23:06:12 +02:00

Owner

Idee

On-Device KI-Modell analysiert E-Mails und schlägt daraus automatisch Tasks oder Kalender-Termine vor.

Ablauf (Skizze)

User öffnet eine Mail im IMAP-Client
KI-Button / automatischer Hinweis: "Termin erkannt" oder "Aufgabe erkannt"
User bestätigt/editiert den Vorschlag
Task/Termin wird in der App gespeichert

Technische Überlegungen

Modell: kleines LLM on-device (z.B. Phi-3 Mini, Gemma 2B via ONNX oder llama.cpp)
Input: Mail-Subject + Body (gekürzt)
Output: strukturiertes JSON (title, date, type: task|event)
Keine Mail-Inhalte an externe Server (Datenschutz)

Abhängigkeiten

Setzt IMAP-Client (Milestone 1-2) voraus
Ähnliche Infrastruktur wie On-Device OCR (ONNX-Runtime)

## Idee On-Device KI-Modell analysiert E-Mails und schlägt daraus automatisch Tasks oder Kalender-Termine vor. ## Ablauf (Skizze) 1. User öffnet eine Mail im IMAP-Client 2. KI-Button / automatischer Hinweis: "Termin erkannt" oder "Aufgabe erkannt" 3. User bestätigt/editiert den Vorschlag 4. Task/Termin wird in der App gespeichert ## Technische Überlegungen - Modell: kleines LLM on-device (z.B. Phi-3 Mini, Gemma 2B via ONNX oder llama.cpp) - Input: Mail-Subject + Body (gekürzt) - Output: strukturiertes JSON (title, date, type: task|event) - Keine Mail-Inhalte an externe Server (Datenschutz) ## Abhängigkeiten - Setzt IMAP-Client (Milestone 1-2) voraus - Ähnliche Infrastruktur wie On-Device OCR (ONNX-Runtime)

admin-mrrm added the

labels

2026-04-26 23:06:12 +02:00

admin-mrrm commented

2026-04-27 00:25:39 +02:00

Author

Owner

Konkrete Umsetzungsstrategie

Datenschutz-Entscheidung

Google AI Edge SDK ist nicht geeignet — proprietär, nicht auditierbar, Telemetrie nicht ausschließbar. Für Mail-Inhalte muss der gesamte Stack auditierbar sein.

Gewählter Ansatz: llama.cpp + MLC-LLM für LLM-Tasks, klassisches ML für einfache Klassifikation.

Schicht 1 — Klassisches ML (einfache Tasks)

Für Spam-Erkennung und grobe Kategorisierung ist klassisches ML ausreichend und deutlich effizienter:

Task	Modell	Runtime
Spam-Erkennung	Naive Bayes / SVM	ONNX Runtime (ohne Google-Telemetrie-SDK)
Kategorisierung (Newsletter / Aufgabe / Termin / Sonstiges)	Fine-tuned DistilBERT-tiny → ONNX	ONNX Runtime React Native

Training: einmalig auf eigenem Rechner mit gelabelten Mail-Daten
Modellgröße: <10 MB, Inferenz <50ms
Infrastruktur bereits vorhanden (ONNX Runtime aus OCR-Pipeline, siehe #79)

Schicht 2 — LLM on-device (Intent-Extraktion)

Für strukturierte Extraktion (Datum, Titel, Typ) aus Mails der Kategorie „Termin" oder „Aufgabe":

Stack:

Modell: Gemma 2B oder Phi-3 Mini im GGUF-Format (keine Google-SDK-Abhängigkeit, nur Gewichte)
Runtime: MLC-LLM (https://github.com/mlc-ai/mlc-llm) — optimiert für Android NPU (Tensor G3 auf Pixel 8 Pro), vollständig Open Source
Fallback: llama.cpp Android-Port als Native Library, falls MLC-LLM zu komplex zu integrieren

Prompt-Schema:

Extrahiere aus folgender E-Mail Tasks und Termine.
Antworte ausschließlich als JSON.

Betreff: {subject}
Inhalt: {body_truncated_500chars}

{"type": "task|event|none", "title": "...", "date": "ISO8601|null", "notes": "..."}

Latenz-Erwartung auf Pixel 8 Pro: ~1–3s pro Mail (MLC-LLM mit NPU-Beschleunigung)

Gesamtablauf

Mail eingehend
  └─ Schicht 1: Spam? → verwerfen
  └─ Schicht 1: Kategorie? → Newsletter/Sonstiges → kein Hinweis
  └─ Schicht 1: Kategorie = Termin/Aufgabe
       └─ Schicht 2 (LLM): JSON extrahieren
            └─ UI: "Termin erkannt" / "Aufgabe erkannt" → User bestätigt

Abhängigkeiten & Wiederverwendung

ONNX Runtime bereits integriert (#79) → Schicht 1 ohne neue Infrastruktur
MLC-LLM muss neu integriert werden (React Native Native Module oder Expo Plugin)
Setzt IMAP-Client (Epic #101) voraus

Offene Fragen

MLC-LLM React Native Integration: fertiges Community-Plugin vorhanden oder eigenes Native Module nötig?
Modell-Download: beim ersten Start oder gebundelt? (Gemma 2B ~1.5GB)
Fine-Tuning DistilBERT für Kategorisierung: Trainingsdaten aufbauen (eigene Mails labeln)

## Konkrete Umsetzungsstrategie ### Datenschutz-Entscheidung Google AI Edge SDK ist **nicht geeignet** — proprietär, nicht auditierbar, Telemetrie nicht ausschließbar. Für Mail-Inhalte muss der gesamte Stack auditierbar sein. **Gewählter Ansatz:** llama.cpp + MLC-LLM für LLM-Tasks, klassisches ML für einfache Klassifikation. --- ### Schicht 1 — Klassisches ML (einfache Tasks) Für Spam-Erkennung und grobe Kategorisierung ist klassisches ML ausreichend und deutlich effizienter: | Task | Modell | Runtime | |------|--------|---------| | Spam-Erkennung | Naive Bayes / SVM | ONNX Runtime (ohne Google-Telemetrie-SDK) | | Kategorisierung (Newsletter / Aufgabe / Termin / Sonstiges) | Fine-tuned DistilBERT-tiny → ONNX | ONNX Runtime React Native | - Training: einmalig auf eigenem Rechner mit gelabelten Mail-Daten - Modellgröße: <10 MB, Inferenz <50ms - Infrastruktur bereits vorhanden (ONNX Runtime aus OCR-Pipeline, siehe #79) --- ### Schicht 2 — LLM on-device (Intent-Extraktion) Für strukturierte Extraktion (Datum, Titel, Typ) aus Mails der Kategorie „Termin" oder „Aufgabe": **Stack:** - **Modell:** Gemma 2B oder Phi-3 Mini im GGUF-Format (keine Google-SDK-Abhängigkeit, nur Gewichte) - **Runtime:** MLC-LLM (https://github.com/mlc-ai/mlc-llm) — optimiert für Android NPU (Tensor G3 auf Pixel 8 Pro), vollständig Open Source - **Fallback:** llama.cpp Android-Port als Native Library, falls MLC-LLM zu komplex zu integrieren **Prompt-Schema:** ``` Extrahiere aus folgender E-Mail Tasks und Termine. Antworte ausschließlich als JSON. Betreff: {subject} Inhalt: {body_truncated_500chars} {"type": "task|event|none", "title": "...", "date": "ISO8601|null", "notes": "..."} ``` **Latenz-Erwartung auf Pixel 8 Pro:** ~1–3s pro Mail (MLC-LLM mit NPU-Beschleunigung) --- ### Gesamtablauf ``` Mail eingehend └─ Schicht 1: Spam? → verwerfen └─ Schicht 1: Kategorie? → Newsletter/Sonstiges → kein Hinweis └─ Schicht 1: Kategorie = Termin/Aufgabe └─ Schicht 2 (LLM): JSON extrahieren └─ UI: "Termin erkannt" / "Aufgabe erkannt" → User bestätigt ``` --- ### Abhängigkeiten & Wiederverwendung - ONNX Runtime bereits integriert (#79) → Schicht 1 ohne neue Infrastruktur - MLC-LLM muss neu integriert werden (React Native Native Module oder Expo Plugin) - Setzt IMAP-Client (Epic #101) voraus ### Offene Fragen - MLC-LLM React Native Integration: fertiges Community-Plugin vorhanden oder eigenes Native Module nötig? - Modell-Download: beim ersten Start oder gebundelt? (Gemma 2B ~1.5GB) - Fine-Tuning DistilBERT für Kategorisierung: Trainingsdaten aufbauen (eigene Mails labeln)

admin-mrrm referenced this issue

2026-04-27 00:36:43 +02:00

[Epic] Persönlicher KI-Assistent — Privacy-First On-Device Architektur #122

admin-mrrm added this to the Backlog — Ideas & Vision milestone

2026-05-18 07:43:44 +02:00

pm-bot referenced this issue

2026-06-06 15:42:30 +02:00

Portfolio-Status KW 2026-W23 #436

pm-bot referenced this issue

2026-06-06 16:13:40 +02:00

[Epic] IMAP — 3: Compose & Reply (Expo&web) #109

pm-bot commented

2026-06-06 16:13:43 +02:00

Collaborator

GF-Entscheidung 2026-06-06 — KI-on-Mail als Folge-Epic zu #122

Im Rahmen der Mail-Portfolio-Entscheidung wurde dieses Idea-Ticket strategisch neu positioniert:

Status: Bleibt im Backlog, gewinnt aber an strategischer Bedeutung. Während Compose/Reply (#109/#110) deprioritisiert wurde, ist KI-on-Mail der eigentliche Mail-USP des Portfolios — Integration der bestehenden Mail-Infrastruktur (Inbox + NLI-Kategorisierung) mit On-Device-KI für automatische Task/Termin-Extraktion.

Abhängigkeit: Wird Folge-Epic zu #122 (Persönlicher KI-Assistent — On-Device Architektur). Erst sinnvoll, wenn die Lokal-KI-Foundation (Embeddings, On-Device-Inferenz, Privacy-First-Stack) steht. Vorher: kein PM-Investment hier.

Erwartete Reihenfolge: Wenn #122 vom Idea-Status in echte Planung übergeht, wird #113 als eines der ersten Anwendungsszenarien aktiviert (zusammen mit #258 mm-knowhow-Retrieval).

## GF-Entscheidung 2026-06-06 — KI-on-Mail als Folge-Epic zu #122 Im Rahmen der Mail-Portfolio-Entscheidung wurde dieses Idea-Ticket strategisch neu positioniert: **Status:** Bleibt im Backlog, gewinnt aber an strategischer Bedeutung. Während Compose/Reply (#109/#110) deprioritisiert wurde, ist KI-on-Mail der **eigentliche Mail-USP des Portfolios** — Integration der bestehenden Mail-Infrastruktur (Inbox + NLI-Kategorisierung) mit On-Device-KI für automatische Task/Termin-Extraktion. **Abhängigkeit:** Wird Folge-Epic zu **#122 (Persönlicher KI-Assistent — On-Device Architektur)**. Erst sinnvoll, wenn die Lokal-KI-Foundation (Embeddings, On-Device-Inferenz, Privacy-First-Stack) steht. Vorher: kein PM-Investment hier. **Erwartete Reihenfolge:** Wenn #122 vom Idea-Status in echte Planung übergeht, wird #113 als eines der ersten Anwendungsszenarien aktiviert (zusammen mit #258 mm-knowhow-Retrieval).

pm-bot referenced this issue

2026-06-06 16:13:44 +02:00

feat: Pipeline-Regeln — Kategorie löst Aktion aus #177

pm-bot referenced this issue

2026-06-06 16:19:03 +02:00

[Epic] Persönlicher KI-Assistent — Privacy-First On-Device Architektur #122

pm-bot referenced this issue

2026-06-06 16:19:03 +02:00

arch-q: KI-Assistent-Epic (#122) — Tech-Stack-Update, LLM-Distribution, Phasen-Reihenfolge #438