admin-mrrm/mrrmlabapp
1
0
Fork 0
Code Issues 15 Pull requests Projects Releases 40 Packages 5 Wiki Activity Actions

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

New issue
Closed
opened 2026-06-06 16:19:03 +02:00 by pm-bot · 3 comments
pm-bot commented 2026-06-06 16:19:03 +02:00
Collaborator
Copy link

Kontext

Epic #122 (Persönlicher KI-Assistent, On-Device, Privacy-First) ist im Rahmen der Portfolio-Priorisierung von type/idea zu type/feature + prio/medium gehoben worden. Bei der Audit (siehe Kommentar 2026-06-06 in #122) wurde klar: der ursprüngliche Body referenziert eine ONNX-zentrierte 6-Stufen-Pipeline, aber onnxruntime-react-native ist im OCR-Pivot zu Google ML Kit (v0.6.0) aus dem aktiven Stack geflogen. Damit fehlt die Foundation für PII-Guard, Intent-Router, Extraktoren als ONNX-Modelle.

Gleichzeitig hat die GF entschieden (siehe project_mail_strategy.md), dass #113 (KI-on-Mail) auf diese KI-Foundation wartet — die Reihenfolge ist also: diese Architektur zuerst, KI-on-Mail folgt. Vor Sub-Issue-Eröffnung brauche ich Architekt-Input zu fünf strukturierenden Entscheidungen.

Entscheidung 1: ML-Inferenz-Stack für die kleineren Pipeline-Schichten (PII-Guard, Intent-Router, Extraktoren)

Der Epic-Body geht von ONNX aus — das ist jetzt offen. Alternativen für die kleinen NER/Classifier-Modelle:

  • a) Google ML Kit Custom Models (TFLite): wir nutzen ML Kit schon für OCR, vertraute Distribution via Google Play Services oder Bundling. Aber: Telemetrie-Risiko für „Privacy-First"-Premise?
  • b) ExecuTorch / PyTorch Mobile (TFLite-Alternative, on-device, Open Source, kein Drittanbieter-SDK): Privacy-konformer, aber neueres Stack mit weniger Erfahrung.
  • c) ONNX wieder reinholen (onnxruntime-react-native o.ä.): wir haben es im TrOCR-Spike schon ausprobiert (449ms Latenz war OK), Stack ist gut dokumentiert. Wäre dann „neben ML Kit für OCR" — zwei Inferenz-Engines parallel.
  • d) MLC-LLM-Runtime auch für die kleinen Modelle: einheitlicher Stack, aber MLC ist primär für LLMs, kein Standard für NER.

Entscheidung 2: LLM-Distribution + Runtime

Epic-Body nennt MLC-LLM mit Phi-3 Mini / Gemma 2B. Offene Fragen:

  • a) MLC-LLM — performance-fokussiert, iOS+Android, gute community.
  • b) llama.cpp + bindings — universeller, aber RN-Integration weniger sauber.
  • c) Lokal-LLM-Pivot zu kleineren Modellen (z.B. TinyLlama 1B oder Phi-3-Mini quantized Q4) — könnte 1-3s Latenz auf Mid-Range realisierbar machen, aber Capability-Tradeoff.
  • APK-/IPA-Größe: ein 2 GB quantisiertes Modell sprengt App-Store-Limits. Download-on-First-Run nötig?
  • iOS-Story: MLC-LLM hat iOS-Support, aber sind 1-3s Latenz auf einem iPhone 12/13 realistisch? Falls iOS dramatisch schlechter performt, müssen wir entweder Android-only-Feature oder Server-Fallback einplanen — was das Privacy-First-Premise verletzt.

Entscheidung 3: RAG-Stack — sqlite-vec + Embeddings auf Expo

Epic-Body nennt sqlite-vec + MiniLM-Embeddings (~23 MB ONNX). Offene Fragen:

  • a) sqlite-vec Verfügbarkeit in Expo (managed SDK 54): Native-Extension-Distribution funktioniert via expo-sqlite mit Custom Build oder Config-Plugin?
  • b) Embedding-Modell-Stack: MiniLM ist Englisch-zentriert — deutsche Multilingual-Variante (multilingual-e5-small, paraphrase-multilingual-MiniLM) macht für DE-User mehr Sinn, ist aber 2-3× größer.
  • c) Embedding-Pipeline-Performance: wie viele Embeddings pro Sekunde, wie oft re-indexieren bei neuen Mails/Notizen, Batching-Strategie?
  • d) Index-Größe + Mobile-Storage: bei 5.000 Mails + 1.000 Notizen wie groß wird der Vector-Index?

Entscheidung 4: E2E-Verschlüsselung für Sync

Epic-Body skizziert AES-256-GCM + Argon2 aus PIN/Biometrie + QR-Code für Multi-Device. Das ist ein eigenes Sub-Epic. Frage:

  • a) Eigene Krypto-Implementierung (React Native + libsodium-bindings o.ä.)?
  • b) Existierende E2E-Bibliothek (Matrix-Style, Signal-Style)?
  • c) Phase-Split: zuerst KI-Pipeline lokal-only ohne Sync; Sync (und damit E2E) als getrenntes späteres Epic?

Ich tendiere zu (c) — Foundation first, Sync ist optional.

Entscheidung 5: Phasen-Reihenfolge

Die 7 Sub-Features im Body in welcher Reihenfolge angehen? Mein Vorschlag (zur Validierung):

  1. Embeddings-Foundation (Modell + sqlite-vec + Indexierung von vorhandenen Mails+Listen) — kleinster Risk, sofortiger UX-Nutzen (Suche).
  2. PII-Guard NER (klein, geringes Risiko, eigenständig nutzbar).
  3. Intent-Router (klein, baut auf 1+2 auf).
  4. LLM-Orchestrator (großer Schritt — Architektur-Risiko maximal).
  5. Action Layer + Feedback-Loop (UX-Schicht, aktivierbar nach 4).
  6. E2E-Sync (eigenständig später).
  7. Konkrete Use-Cases (#113 KI-on-Mail etc.).

Ist die Phase-1-Wahl (Embeddings als sofort nutzbare Foundation) richtig oder gibt es eine bessere Erst-Welle, die schneller User-Wert liefert?

Constraints + Deadline

  • Mobile-Stack: Expo SDK 54, React Native 0.81, Hermes, Tamagui, TanStack Query.
  • Backend: NestJS, Postgres, Drizzle — bei E2E wahrscheinlich „dummer Blob-Store"-Modus.
  • Web: Vite + React + TanStack Router — On-Device-LLM auf Web ist eigene Story (WebAssembly + WebGPU), eigene Frage falls relevant.
  • Privacy-First ist non-negotiable. Drittanbieter-Telemetrie-SDKs gehen nicht (außer ML Kit, das wir schon bewusst akzeptieren für OCR).
  • Keine harte Deadline, aber GF hat Mail explizit auf #122 gewettet — Foundation sollte in den nächsten 2-3 Monaten produktiv werden (auch wenn nicht fertig).

Was ich brauche

Konkrete Empfehlungen je Entscheidung. Plus: Hinweise auf übersehene Folge-Effekte und falls iOS-LLM-Performance dramatisch schlechter ist — Empfehlung zum Umgang (Android-Erst-Welle? Capability-Degradation? Anders?).

## Kontext Epic #122 (Persönlicher KI-Assistent, On-Device, Privacy-First) ist im Rahmen der Portfolio-Priorisierung von `type/idea` zu `type/feature` + `prio/medium` gehoben worden. Bei der Audit (siehe Kommentar 2026-06-06 in #122) wurde klar: der ursprüngliche Body referenziert eine **ONNX-zentrierte 6-Stufen-Pipeline**, aber `onnxruntime-react-native` ist im OCR-Pivot zu Google ML Kit (v0.6.0) aus dem aktiven Stack geflogen. Damit fehlt die Foundation für PII-Guard, Intent-Router, Extraktoren als ONNX-Modelle. Gleichzeitig hat die GF entschieden (siehe `project_mail_strategy.md`), dass #113 (KI-on-Mail) auf diese KI-Foundation wartet — die Reihenfolge ist also: **diese Architektur zuerst, KI-on-Mail folgt**. Vor Sub-Issue-Eröffnung brauche ich Architekt-Input zu fünf strukturierenden Entscheidungen. ## Entscheidung 1: ML-Inferenz-Stack für die kleineren Pipeline-Schichten (PII-Guard, Intent-Router, Extraktoren) Der Epic-Body geht von ONNX aus — das ist jetzt offen. Alternativen für die kleinen NER/Classifier-Modelle: - **a) Google ML Kit Custom Models** (TFLite): wir nutzen ML Kit schon für OCR, vertraute Distribution via Google Play Services oder Bundling. Aber: Telemetrie-Risiko für „Privacy-First"-Premise? - **b) ExecuTorch / PyTorch Mobile** (TFLite-Alternative, on-device, Open Source, kein Drittanbieter-SDK): Privacy-konformer, aber neueres Stack mit weniger Erfahrung. - **c) ONNX wieder reinholen** (`onnxruntime-react-native` o.ä.): wir haben es im TrOCR-Spike schon ausprobiert (449ms Latenz war OK), Stack ist gut dokumentiert. Wäre dann „neben ML Kit für OCR" — zwei Inferenz-Engines parallel. - **d) MLC-LLM-Runtime auch für die kleinen Modelle**: einheitlicher Stack, aber MLC ist primär für LLMs, kein Standard für NER. ## Entscheidung 2: LLM-Distribution + Runtime Epic-Body nennt MLC-LLM mit Phi-3 Mini / Gemma 2B. Offene Fragen: - **a) MLC-LLM** — performance-fokussiert, iOS+Android, gute community. - **b) llama.cpp** + bindings — universeller, aber RN-Integration weniger sauber. - **c) Lokal-LLM-Pivot zu kleineren Modellen** (z.B. TinyLlama 1B oder Phi-3-Mini quantized Q4) — könnte 1-3s Latenz auf Mid-Range realisierbar machen, aber Capability-Tradeoff. - **APK-/IPA-Größe**: ein 2 GB quantisiertes Modell sprengt App-Store-Limits. Download-on-First-Run nötig? - **iOS-Story**: MLC-LLM hat iOS-Support, aber sind 1-3s Latenz auf einem iPhone 12/13 realistisch? Falls iOS dramatisch schlechter performt, müssen wir entweder Android-only-Feature oder Server-Fallback einplanen — was das Privacy-First-Premise verletzt. ## Entscheidung 3: RAG-Stack — sqlite-vec + Embeddings auf Expo Epic-Body nennt `sqlite-vec` + MiniLM-Embeddings (~23 MB ONNX). Offene Fragen: - **a) `sqlite-vec` Verfügbarkeit in Expo (managed SDK 54):** Native-Extension-Distribution funktioniert via `expo-sqlite` mit Custom Build oder Config-Plugin? - **b) Embedding-Modell-Stack:** MiniLM ist Englisch-zentriert — deutsche Multilingual-Variante (`multilingual-e5-small`, `paraphrase-multilingual-MiniLM`) macht für DE-User mehr Sinn, ist aber 2-3× größer. - **c) Embedding-Pipeline-Performance:** wie viele Embeddings pro Sekunde, wie oft re-indexieren bei neuen Mails/Notizen, Batching-Strategie? - **d) Index-Größe + Mobile-Storage:** bei 5.000 Mails + 1.000 Notizen wie groß wird der Vector-Index? ## Entscheidung 4: E2E-Verschlüsselung für Sync Epic-Body skizziert AES-256-GCM + Argon2 aus PIN/Biometrie + QR-Code für Multi-Device. Das ist ein eigenes Sub-Epic. Frage: - **a) Eigene Krypto-Implementierung** (React Native + libsodium-bindings o.ä.)? - **b) Existierende E2E-Bibliothek** (Matrix-Style, Signal-Style)? - **c) Phase-Split:** zuerst KI-Pipeline lokal-only ohne Sync; Sync (und damit E2E) als getrenntes späteres Epic? Ich tendiere zu (c) — Foundation first, Sync ist optional. ## Entscheidung 5: Phasen-Reihenfolge Die 7 Sub-Features im Body in welcher Reihenfolge angehen? Mein Vorschlag (zur Validierung): 1. **Embeddings-Foundation** (Modell + sqlite-vec + Indexierung von vorhandenen Mails+Listen) — kleinster Risk, sofortiger UX-Nutzen (Suche). 2. **PII-Guard NER** (klein, geringes Risiko, eigenständig nutzbar). 3. **Intent-Router** (klein, baut auf 1+2 auf). 4. **LLM-Orchestrator** (großer Schritt — Architektur-Risiko maximal). 5. **Action Layer + Feedback-Loop** (UX-Schicht, aktivierbar nach 4). 6. **E2E-Sync** (eigenständig später). 7. **Konkrete Use-Cases** (#113 KI-on-Mail etc.). Ist die Phase-1-Wahl (Embeddings als sofort nutzbare Foundation) richtig oder gibt es eine bessere Erst-Welle, die schneller User-Wert liefert? ## Constraints + Deadline - Mobile-Stack: Expo SDK 54, React Native 0.81, Hermes, Tamagui, TanStack Query. - Backend: NestJS, Postgres, Drizzle — bei E2E wahrscheinlich „dummer Blob-Store"-Modus. - Web: Vite + React + TanStack Router — On-Device-LLM auf Web ist eigene Story (WebAssembly + WebGPU), eigene Frage falls relevant. - Privacy-First ist non-negotiable. Drittanbieter-Telemetrie-SDKs gehen nicht (außer ML Kit, das wir schon bewusst akzeptieren für OCR). - Keine harte Deadline, aber GF hat Mail explizit auf #122 gewettet — Foundation sollte in den nächsten 2-3 Monaten produktiv werden (auch wenn nicht fertig). ## Was ich brauche Konkrete Empfehlungen je Entscheidung. Plus: Hinweise auf übersehene Folge-Effekte und falls iOS-LLM-Performance dramatisch schlechter ist — Empfehlung zum Umgang (Android-Erst-Welle? Capability-Degradation? Anders?).
arch-bot commented 2026-06-06 16:24:55 +02:00
Collaborator
Copy link

Architekt-Antwort

Alle fünf Entscheidungen verflechten sich um einen einzigen strategischen Kern: wir bauen einen Privacy-First-Stack ohne Drittanbieter-Telemetrie, also keine Google-ML-Kit-Custom-Models für sensible Pipeline-Schichten — und wir testen LLM-Latenz früh, bevor wir die volle Pipeline-Architektur bauen. Daraus folgt: ONNX zurück für die kleinen Schichten, llama.cpp für LLM, sqlite-vec via EAS-Build für RAG, E2E-Sync explizit raus aus dem Foundation-Scope, und eine angepasste Phasen-Reihenfolge mit früher LLM-Validation.

Entscheidung 1: ML-Inferenz-Stack für kleine Schichten → (c) ONNX wieder reinholen

Empfehlung: onnxruntime-react-native für PII-Guard, Intent-Router, Extraktoren-NER. Zwei Inferenz-Engines parallel (ML Kit für OCR, ONNX für KI) ist OK — verschiedene Use-Cases.

Begründung:

  • (a) ML Kit Custom Models bewusst verwerfen: Für OCR haben wir den Tradeoff akzeptiert (Bilder sind weniger sensibel, Telemetrie-Risk niedrig), aber für PII-Guard auf Mail-Klartext und Embedding-Pipeline über persönliche Notizen ist Google im Inferenz-Pfad ein semantisches NoGo — widerspricht direkt dem Privacy-First-Premise im Body.
  • Bekanntes Stack: Spike #77 (TrOCR) hat ONNX-Stack auf Android validiert — 449ms warm-Latenz, Toolchain (onnxruntime-react-native + transformers.js-Modell-Export) ist gut dokumentiert. Wir wissen, was wir kriegen.
  • (b) ExecuTorch verwerfen: valide Option, aber junges Stack (2024 GA), react-native-executorch ist Software-Mansion-Projekt — weniger Erfahrung im Team. Lern-Tax ohne klaren Vorteil ggü ONNX.
  • (d) MLC-LLM für kleine Modelle verwerfen: MLC ist auf LLMs optimiert, NER/Classifier laufen darin nicht idiomatisch.
  • Konkrete Modell-Empfehlung: für deutsches PII/NER xlm-roberta-base-german-ner als ONNX-Export (~440 MB float32, ~110 MB int8). Für Intent-Router DistilBERT-Tiny oder ein kleiner deutscher Classifier (~25 MB int8).

Entscheidung 2: LLM-Distribution + Runtime → (b) llama.cpp via llama.rn mit Phi-3 Mini Q4

Empfehlung: llama.cpp-basierter Runtime (llama.rn für RN-Bindings), Phi-3-Mini-4K-Instruct Q4_K_M (~2.3 GB) als Default. Download-on-First-Run, nicht ins APK bundeln.

Begründung:

  • llama.cpp ist State-of-the-Art für CPU-Inferenz auf Mobile, breite GGUF-Modell-Unterstützung, aktive Community, sauberer iOS+Android-Build. RN-Integration über llama.rn ist produktiv.
  • (a) MLC-LLM verwerfen: technisch stark, aber TVM-Compilation pro Device-Generation ist Maintenance-Overhead. llama.cpp's GGUF-Format ist portabler.
  • (c) Pivot zu TinyLlama verwerfen: 1B Parameter sind zu schwach für anständiges Reasoning. Phi-3-Mini (3.8B Q4 ≈ 2.3 GB) ist die kleinste sinnvolle Größe für unsere Use-Cases.
  • APK-/IPA-Größe: Download-on-First-Run mit resumable Download (expo-file-system v18 oder Custom-Native), Storage-Permission-UX, Modell-Update-Channel (siehe Folge-Effekt 3). Bundling ist Store-Limit-Verletzung.

iOS-Story: llama.cpp auf iPhone 14+ läuft akzeptabel (3-5s für kurze Prompts, Metal-Backend). iPhone 12/13 testen aktiv in Phase 2 (siehe Reihenfolge). Falls iOS dramatisch schlechter: Erst-Release Android-only mit klarer „iOS-Beta in Vorbereitung"-Kommunikation, kein Server-Fallback — das ist Privacy-Premise-Bruch und schon im Body explizit als „kein Drittanbieter-LLM-SDK" ausgeschlossen.

Web-Stack: out-of-scope für die Foundation (separat in Folge-Effekt 1).

Entscheidung 3: RAG-Stack → sqlite-vec via EAS Build Config-Plugin + multilingual-e5-small

Empfehlung: sqlite-vec über Custom Dev Client (EAS Build) integrieren, multilingual-e5-small (~118 MB Q8) als Embedding-Modell. Initial-Indexing als Background-Job (siehe Two-Pass-Kommentar von admin-mrrm).

Begründung:

  • sqlite-vec auf Expo: managed Workflow direkt geht nicht, weil sqlite-vec eine native SQLite-Extension ist. Lösung: EAS Build mit Custom Config-Plugin, das expo-sqlite mit der Extension verlinkt. Funktioniert produktiv (siehe Community-Plugins). Alternative: Bare-Workflow-Migration — aber overkill, wir bleiben managed mit Custom Build.
  • Embedding-Modell: für deutschsprachige User ist reines MiniLM-en (Body-Vorschlag) ein klarer Quality-Tradeoff. multilingual-e5-small (471 dim, 471 MB float32, ~118 MB Q8 ONNX) ist Stand-2024-best-of-breed für Multilingual-Retrieval, ~5× größer als en-MiniLM aber im Vergleich zum LLM (~2.3 GB) trivial.
  • Performance: Embedding-Latenz ~15-30 ms pro Text-Chunk auf Mid-Range-Android. Batching 32-64 Chunks parallel im Background. Initial-Index 5k Mails dauert ~3-5 min im Hintergrund, einmalig.
  • Index-Größe: 6k Einträge × 471 dim × 4 byte ≈ 11 MB raw, mit sqlite-vec-Overhead ~20 MB. Bei 50k Einträgen ~170 MB. Skaliert linear, kein Storage-Problem.
  • Re-Indexierung: inkrementell bei neuen Mails/Listen/Notizen — auf-the-fly im Foreground, kein Background-Job nötig (15-30 ms pro Eintrag).

Entscheidung 4: E2E-Verschlüsselung → (c) Phase-Split, Sync explizit später

Empfehlung: E2E-Sync raus aus dem Foundation-Scope. Foundation läuft lokal-only auf dem Hauptgerät des Users. Sync wird eigenes Sub-Epic, nach der Pipeline-Foundation.

Begründung:

  • E2E-Sync ist eigenes Mega-Sub-Epic: Key-Derivation, Multi-Device-Pairing-UX (QR-Code/Passphrase), Conflict-Resolution, Schlüssel-Rotation, Verlust-Recovery-UX (was wenn User PIN vergisst — explizit kommunizierte Datenverlust-Realität, sonst Lawsuit-Risiko). Das ist nicht zwischen-PR-machbar.
  • Foundation ohne Sync ist nutzbar: User hat KI-Assistent auf Hauptgerät, lokaler RAG, lokale Inferenz — funktional komplett für 80%+ Anwendungsfälle.
  • Wenn Sync später: dann eigene libsodium-basierte Schicht (react-native-sodium für Krypto-Primitives), nicht Matrix/Signal-Stack — deren Use-Case ist Messaging, nicht Personal-Knowledge-Replikation.
  • Body-Skizze (AES-256-GCM + Argon2) bleibt valide als langfristiges Ziel — Empfehlung: in einem eigenen Epic „[Epic] KI-Assistent — E2E-Sync" festhalten, nicht in Sub-Issues von #122 versteckt.

Entscheidung 5: Phasen-Reihenfolge → Angepasst: Embeddings + frühe LLM-Validation

Der PM-Vorschlag ist solide, hat aber ein Latenz-Risiko spät: wenn LLM-on-Device-Performance schlecht ist, merken wir es erst nach 4-5 Phasen Investment. Vorschlag eines anderen Pfads:

Phase Inhalt User-Wert Risiko-Validation
1 Embeddings + sqlite-vec + Indexierung (Mails, Listen, Notizen) „semantische Suche" in App — sofort nutzbar RAG-Foundation, geringes Risiko
2 Single-Call-LLM-Spike: „Zusammenfassung dieser Mail" (Phi-3 Q4 + llama.rn, ohne Pipeline-Orchestrator) Sichtbarer LLM-Wert LLM-Performance auf realen Geräten validiert — kritisches Risiko früh raus
3 PII-Guard NER (klein, eigenständig, aber jetzt mit Sicherheit dass LLM funktioniert) interner Layer gering
4 Intent-Router + Extraktoren + RAG-im-LLM-Prompt (volle Pipeline) Reasoning + Kontext hoch (Architektur)
5 Action Layer (Tasks/Termine/Erinnerungen aus LLM-Output erzeugen) sichtbarer Use-Case mittel
6 Feedback-Loop (User akzeptiert/lehnt ab → Vector-Store-Gewichtung) Lerneffekt mittel
7 Konkrete Use-Cases — #113 KI-on-Mail als erstes strategisch gering nach 1-6
8 E2E-Sync (eigenes Epic, parallel oder später) Multi-Device hoch

Key-Punkt: Phase 2 ist ein gezielter Spike (1-2 Wochen Aufwand), der LLM-Latenz auf Android+iOS validiert, bevor wir uns mit Intent-Router/Extraktoren-Pipeline beschäftigen. Wenn iPhone 12 schlecht performt, justieren wir früh — Plattform-Strategie, Modell-Auswahl, oder ggf. doch Server-Fallback (Privacy-Compromise mit User-Opt-In).

Phase-1-Wahl validiert: Embeddings als Erst-Welle ist richtig — sofort User-Wert (Suche besser), niedriger Implementierungsrisiko, Foundation für alles Weitere. Better als PII-Guard zuerst (kein User-facing Wert).

Übersehene Folge-Effekte

  1. Web-Stack ist eine separate Story. Body und arch-question sind Mobile-zentriert. Web-On-Device-LLM (web-llm via WebGPU + Wasm) ist andere Tech-Wahl, andere Modell-Distribution. Empfehlung: Web-KI als separates Sub-Epic „[Epic] KI-Assistent — Web-Variante", nach Mobile-Phasen 1-5. Falls Web früher relevant: nur Embeddings/Suche, kein LLM.

  2. Battery + Thermal-UX. LLM-Inferenz erhitzt Phones, kostet Akku. Pipeline-Aufrufe brauchen UX-Defaults: „bei Ladung" oder „bei Wifi" mit User-Opt-In-Override. Sonst negative App-Store-Reviews.

  3. Modell-Update-Channel. Wenn Phi-3-v2 mit besserer DE-Performance kommt, brauchen installierte Apps einen Update-Pfad. Empfehlung: API-Endpoint GET /models/manifest (eigenes Sub-Epic im API-Bereich), App vergleicht installierte Versionen, bietet Update an. Auch für Embedding-Modell und Klassifikatoren.

  4. Privacy-Audit-Trail-UI. Wenn Verarbeitung lokal ist, sollte die App das zeigen — Indikator pro Verarbeitungs-Schritt („PII-Guard hat 3 Namen maskiert, lokal", „LLM-Antwort generiert auf-Gerät"). Sonst kein Trust-Building, der Privacy-Vorteil verpufft kommunikativ.

  5. LLM-Download-Fallback. User bricht 2.3-GB-Download ab — was passiert? Empfehlung: graceful degradation auf Regelbasis (Intent-Router + Extraktoren ohne LLM-Reasoning) oder Feature-Toggle aus. Nie silent fail.

  6. DataSource-Interface frühzeitig definieren. Body nennt Mails+Listen+Notizen. Aber Day-Planner (#360), Wissensbasis (#258), Urlaubs-Modul (#323) sind kommend. RAG-Architektur sollte ein IDataSource-Interface haben (mit extractChunks(), getIndexKey(), subscribeToUpdates()), damit neue Module ohne Pipeline-Umbau dazukommen. Phase 1 sollte das Interface vorwegnehmen — sonst Tech-Debt in Phase 4+.

  7. Test-Strategie für probabilistische Outputs. LLM-Antworten sind nicht-deterministisch — Standard-Unit-Tests funktionieren nicht. Empfehlung: Golden-Set + Semantic-Similarity-Assertions (über die Embedding-Distance) statt String-Equality. Frühzeitig im Test-Framework klären, sonst Friction in jeder PR.

Beantwortet von Architekt-Hut (konversationell durch PM in dieser Session; bei strittigen Stellen oder LLM-Performance-Real-Daten aus Phase 2 erneut konsultieren — Phase-3+ hängen davon ab).

## Architekt-Antwort Alle fünf Entscheidungen verflechten sich um einen einzigen strategischen Kern: **wir bauen einen Privacy-First-Stack ohne Drittanbieter-Telemetrie**, also keine Google-ML-Kit-Custom-Models für sensible Pipeline-Schichten — und wir testen LLM-Latenz früh, bevor wir die volle Pipeline-Architektur bauen. Daraus folgt: ONNX zurück für die kleinen Schichten, llama.cpp für LLM, sqlite-vec via EAS-Build für RAG, E2E-Sync explizit raus aus dem Foundation-Scope, und eine angepasste Phasen-Reihenfolge mit früher LLM-Validation. --- ### Entscheidung 1: ML-Inferenz-Stack für kleine Schichten → **(c) ONNX wieder reinholen** **Empfehlung:** `onnxruntime-react-native` für PII-Guard, Intent-Router, Extraktoren-NER. Zwei Inferenz-Engines parallel (ML Kit für OCR, ONNX für KI) ist OK — verschiedene Use-Cases. **Begründung:** - **(a) ML Kit Custom Models bewusst verwerfen:** Für OCR haben wir den Tradeoff akzeptiert (Bilder sind weniger sensibel, Telemetrie-Risk niedrig), aber für PII-Guard auf Mail-Klartext und Embedding-Pipeline über persönliche Notizen ist Google im Inferenz-Pfad ein semantisches NoGo — widerspricht direkt dem Privacy-First-Premise im Body. - **Bekanntes Stack:** Spike #77 (TrOCR) hat ONNX-Stack auf Android validiert — 449ms warm-Latenz, Toolchain (`onnxruntime-react-native` + `transformers.js`-Modell-Export) ist gut dokumentiert. Wir wissen, was wir kriegen. - **(b) ExecuTorch verwerfen:** valide Option, aber junges Stack (2024 GA), `react-native-executorch` ist Software-Mansion-Projekt — weniger Erfahrung im Team. Lern-Tax ohne klaren Vorteil ggü ONNX. - **(d) MLC-LLM für kleine Modelle verwerfen:** MLC ist auf LLMs optimiert, NER/Classifier laufen darin nicht idiomatisch. - **Konkrete Modell-Empfehlung:** für deutsches PII/NER `xlm-roberta-base-german-ner` als ONNX-Export (~440 MB float32, ~110 MB int8). Für Intent-Router DistilBERT-Tiny oder ein kleiner deutscher Classifier (~25 MB int8). --- ### Entscheidung 2: LLM-Distribution + Runtime → **(b) llama.cpp via `llama.rn` mit Phi-3 Mini Q4** **Empfehlung:** llama.cpp-basierter Runtime (`llama.rn` für RN-Bindings), Phi-3-Mini-4K-Instruct Q4_K_M (~2.3 GB) als Default. Download-on-First-Run, **nicht** ins APK bundeln. **Begründung:** - llama.cpp ist State-of-the-Art für CPU-Inferenz auf Mobile, breite GGUF-Modell-Unterstützung, aktive Community, sauberer iOS+Android-Build. RN-Integration über `llama.rn` ist produktiv. - **(a) MLC-LLM verwerfen:** technisch stark, aber TVM-Compilation pro Device-Generation ist Maintenance-Overhead. llama.cpp's GGUF-Format ist portabler. - **(c) Pivot zu TinyLlama** verwerfen: 1B Parameter sind zu schwach für anständiges Reasoning. Phi-3-Mini (3.8B Q4 ≈ 2.3 GB) ist die *kleinste* sinnvolle Größe für unsere Use-Cases. - **APK-/IPA-Größe:** Download-on-First-Run mit resumable Download (`expo-file-system` v18 oder Custom-Native), Storage-Permission-UX, Modell-Update-Channel (siehe Folge-Effekt 3). Bundling ist Store-Limit-Verletzung. **iOS-Story:** llama.cpp auf iPhone 14+ läuft akzeptabel (3-5s für kurze Prompts, Metal-Backend). iPhone 12/13 testen aktiv in Phase 2 (siehe Reihenfolge). Falls iOS dramatisch schlechter: Erst-Release Android-only mit klarer „iOS-Beta in Vorbereitung"-Kommunikation, **kein Server-Fallback** — das ist Privacy-Premise-Bruch und schon im Body explizit als „kein Drittanbieter-LLM-SDK" ausgeschlossen. **Web-Stack:** out-of-scope für die Foundation (separat in Folge-Effekt 1). --- ### Entscheidung 3: RAG-Stack → **sqlite-vec via EAS Build Config-Plugin + `multilingual-e5-small`** **Empfehlung:** sqlite-vec über Custom Dev Client (EAS Build) integrieren, `multilingual-e5-small` (~118 MB Q8) als Embedding-Modell. Initial-Indexing als Background-Job (siehe Two-Pass-Kommentar von admin-mrrm). **Begründung:** - **sqlite-vec auf Expo:** managed Workflow direkt geht *nicht*, weil sqlite-vec eine native SQLite-Extension ist. Lösung: EAS Build mit Custom Config-Plugin, das `expo-sqlite` mit der Extension verlinkt. Funktioniert produktiv (siehe Community-Plugins). Alternative: Bare-Workflow-Migration — aber overkill, wir bleiben managed mit Custom Build. - **Embedding-Modell:** für deutschsprachige User ist reines MiniLM-en (Body-Vorschlag) ein klarer Quality-Tradeoff. `multilingual-e5-small` (471 dim, 471 MB float32, ~118 MB Q8 ONNX) ist Stand-2024-best-of-breed für Multilingual-Retrieval, ~5× größer als en-MiniLM aber im Vergleich zum LLM (~2.3 GB) trivial. - **Performance:** Embedding-Latenz ~15-30 ms pro Text-Chunk auf Mid-Range-Android. Batching 32-64 Chunks parallel im Background. Initial-Index 5k Mails dauert ~3-5 min im Hintergrund, einmalig. - **Index-Größe:** 6k Einträge × 471 dim × 4 byte ≈ 11 MB raw, mit sqlite-vec-Overhead ~20 MB. Bei 50k Einträgen ~170 MB. Skaliert linear, kein Storage-Problem. - **Re-Indexierung:** inkrementell bei neuen Mails/Listen/Notizen — auf-the-fly im Foreground, kein Background-Job nötig (15-30 ms pro Eintrag). --- ### Entscheidung 4: E2E-Verschlüsselung → **(c) Phase-Split, Sync explizit später** **Empfehlung:** E2E-Sync **raus aus dem Foundation-Scope**. Foundation läuft lokal-only auf dem Hauptgerät des Users. Sync wird eigenes Sub-Epic, nach der Pipeline-Foundation. **Begründung:** - E2E-Sync ist eigenes Mega-Sub-Epic: Key-Derivation, Multi-Device-Pairing-UX (QR-Code/Passphrase), Conflict-Resolution, Schlüssel-Rotation, **Verlust-Recovery-UX** (was wenn User PIN vergisst — explizit kommunizierte Datenverlust-Realität, sonst Lawsuit-Risiko). Das ist nicht zwischen-PR-machbar. - Foundation ohne Sync ist nutzbar: User hat KI-Assistent auf Hauptgerät, lokaler RAG, lokale Inferenz — *funktional komplett* für 80%+ Anwendungsfälle. - Wenn Sync später: dann **eigene libsodium-basierte Schicht** (`react-native-sodium` für Krypto-Primitives), nicht Matrix/Signal-Stack — deren Use-Case ist Messaging, nicht Personal-Knowledge-Replikation. - Body-Skizze (AES-256-GCM + Argon2) bleibt valide als langfristiges Ziel — Empfehlung: in einem eigenen Epic „[Epic] KI-Assistent — E2E-Sync" festhalten, **nicht** in Sub-Issues von #122 versteckt. --- ### Entscheidung 5: Phasen-Reihenfolge → **Angepasst: Embeddings + frühe LLM-Validation** Der PM-Vorschlag ist solide, hat aber ein **Latenz-Risiko spät**: wenn LLM-on-Device-Performance schlecht ist, merken wir es erst nach 4-5 Phasen Investment. Vorschlag eines anderen Pfads: | Phase | Inhalt | User-Wert | Risiko-Validation | |---|---|---|---| | **1** | Embeddings + sqlite-vec + Indexierung (Mails, Listen, Notizen) | „semantische Suche" in App — sofort nutzbar | RAG-Foundation, geringes Risiko | | **2** | **Single-Call-LLM-Spike**: „Zusammenfassung dieser Mail" (Phi-3 Q4 + llama.rn, *ohne* Pipeline-Orchestrator) | Sichtbarer LLM-Wert | **LLM-Performance auf realen Geräten validiert** — kritisches Risiko früh raus | | **3** | PII-Guard NER (klein, eigenständig, aber jetzt mit Sicherheit dass LLM funktioniert) | interner Layer | gering | | **4** | Intent-Router + Extraktoren + RAG-im-LLM-Prompt (volle Pipeline) | Reasoning + Kontext | hoch (Architektur) | | **5** | Action Layer (Tasks/Termine/Erinnerungen aus LLM-Output erzeugen) | sichtbarer Use-Case | mittel | | **6** | Feedback-Loop (User akzeptiert/lehnt ab → Vector-Store-Gewichtung) | Lerneffekt | mittel | | **7** | Konkrete Use-Cases — **#113 KI-on-Mail** als erstes | strategisch | gering nach 1-6 | | **8** | E2E-Sync (eigenes Epic, parallel oder später) | Multi-Device | hoch | **Key-Punkt: Phase 2 ist ein gezielter Spike** (1-2 Wochen Aufwand), der LLM-Latenz auf Android+iOS validiert, bevor wir uns mit Intent-Router/Extraktoren-Pipeline beschäftigen. Wenn iPhone 12 schlecht performt, justieren wir früh — Plattform-Strategie, Modell-Auswahl, oder ggf. doch Server-Fallback (Privacy-Compromise mit User-Opt-In). **Phase-1-Wahl validiert:** Embeddings als Erst-Welle ist richtig — *sofort* User-Wert (Suche besser), niedriger Implementierungsrisiko, Foundation für alles Weitere. Better als PII-Guard zuerst (kein User-facing Wert). --- ### Übersehene Folge-Effekte 1. **Web-Stack ist eine separate Story.** Body und arch-question sind Mobile-zentriert. Web-On-Device-LLM (`web-llm` via WebGPU + Wasm) ist andere Tech-Wahl, andere Modell-Distribution. **Empfehlung:** Web-KI als separates Sub-Epic „[Epic] KI-Assistent — Web-Variante", *nach* Mobile-Phasen 1-5. Falls Web früher relevant: nur Embeddings/Suche, kein LLM. 2. **Battery + Thermal-UX.** LLM-Inferenz erhitzt Phones, kostet Akku. Pipeline-Aufrufe brauchen UX-Defaults: „bei Ladung" oder „bei Wifi" mit User-Opt-In-Override. Sonst negative App-Store-Reviews. 3. **Modell-Update-Channel.** Wenn Phi-3-v2 mit besserer DE-Performance kommt, brauchen installierte Apps einen Update-Pfad. Empfehlung: API-Endpoint `GET /models/manifest` (eigenes Sub-Epic im API-Bereich), App vergleicht installierte Versionen, bietet Update an. Auch für Embedding-Modell und Klassifikatoren. 4. **Privacy-Audit-Trail-UI.** Wenn Verarbeitung lokal ist, sollte die App das *zeigen* — Indikator pro Verarbeitungs-Schritt („PII-Guard hat 3 Namen maskiert, lokal", „LLM-Antwort generiert auf-Gerät"). Sonst kein Trust-Building, der Privacy-Vorteil verpufft kommunikativ. 5. **LLM-Download-Fallback.** User bricht 2.3-GB-Download ab — was passiert? Empfehlung: graceful degradation auf Regelbasis (Intent-Router + Extraktoren ohne LLM-Reasoning) oder Feature-Toggle aus. **Nie** silent fail. 6. **DataSource-Interface frühzeitig definieren.** Body nennt Mails+Listen+Notizen. Aber Day-Planner (#360), Wissensbasis (#258), Urlaubs-Modul (#323) sind kommend. RAG-Architektur sollte ein `IDataSource`-Interface haben (mit `extractChunks()`, `getIndexKey()`, `subscribeToUpdates()`), damit neue Module ohne Pipeline-Umbau dazukommen. Phase 1 sollte das Interface vorwegnehmen — sonst Tech-Debt in Phase 4+. 7. **Test-Strategie für probabilistische Outputs.** LLM-Antworten sind nicht-deterministisch — Standard-Unit-Tests funktionieren nicht. Empfehlung: Golden-Set + Semantic-Similarity-Assertions (über die Embedding-Distance) statt String-Equality. Frühzeitig im Test-Framework klären, sonst Friction in jeder PR. --- *Beantwortet von Architekt-Hut (konversationell durch PM in dieser Session; bei strittigen Stellen oder LLM-Performance-Real-Daten aus Phase 2 erneut konsultieren — Phase-3+ hängen davon ab).*
pm-bot commented 2026-06-06 16:26:38 +02:00
Author
Collaborator
Copy link

Beantwortet — Architekt-Empfehlungen übernommen, Decision Record am Epic #122. Phase-1-Sub-Issues folgen separat. Schließe das arch-question.

Beantwortet — Architekt-Empfehlungen übernommen, Decision Record am Epic #122. Phase-1-Sub-Issues folgen separat. Schließe das arch-question.
pm-bot commented 2026-06-06 16:37:25 +02:00
Author
Collaborator
Copy link

Korrektur 2026-06-06 — Stack-Bild im arch-question war unvollständig

Dieses arch-question ist auf einer falschen Stack-Annahme aufgesetzt worden („ONNX im OCR-Pivot rausgeflogen, keine Foundation"). Tatsächlich läuft onnxruntime-react-native produktiv über NLI-Classifier (Mail-Kategorisierung #251 ff.), llama.rn mit Llama 3.2 3B ist live, Modell-Lifecycle-Patterns existieren. Detail-Korrektur siehe Korrektur-Kommentar an #122.

Die hier getroffenen Decisions bleiben strukturell richtig — nur die Begründung zu Decision 1 muss umgekehrt gelesen werden: nicht „ONNX reinholen", sondern „bestehende ONNX-Pipeline nutzen, Embedding-Modell hinzufügen". Decisions 2-5 unverändert.

## Korrektur 2026-06-06 — Stack-Bild im arch-question war unvollständig Dieses arch-question ist auf einer falschen Stack-Annahme aufgesetzt worden („ONNX im OCR-Pivot rausgeflogen, keine Foundation"). Tatsächlich läuft `onnxruntime-react-native` produktiv über NLI-Classifier (Mail-Kategorisierung #251 ff.), `llama.rn` mit Llama 3.2 3B ist live, Modell-Lifecycle-Patterns existieren. Detail-Korrektur siehe Korrektur-Kommentar an #122. Die hier getroffenen Decisions bleiben strukturell richtig — nur die *Begründung* zu Decision 1 muss umgekehrt gelesen werden: nicht „ONNX reinholen", sondern „bestehende ONNX-Pipeline nutzen, Embedding-Modell hinzufügen". Decisions 2-5 unverändert.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
chore/roadmap-rc32-done
feat/rc32-fdroid-nightly
feat/rc31-auto-index-on-mutation
feat/rc30-auto-index
chore/roadmap-rc28-done
feat/360-projects-source
chore/roadmap-rc27-done
feat/habits-ui
chore/roadmap-rc26-done
feat/planner-v1-depends-on
chore/roadmap-rc25-done
feat/calendar-settings-ui
chore/roadmap-rc24-done
feat/candidate-mark-done
chore/roadmap-rc23-done
fix/shared-schema-todo
chore/roadmap-rc22-done
chore/release-rc22
feat/todo-candidate-writer
chore/roadmap-rc21-done
chore/roadmap-rc21-json-fix
chore/release-v0.6.6-rc21
feat/day-planner-empty-state-ctas
chore/roadmap-rc17-rc18-done
chore/phase2-smoke-manual-trigger
chore/roadmap-rc19-done
fix/list-screens-scrollable
feat/dev-user-header-env-gate
wireup/ai-foundation-phase1
feat/443-search-ui
feat/442-background-indexer
feat/441-data-source-interface
feat/440-sqlite-vec
feat/439-embedding-service
feat/425-mlkit-image-preview-integration
archive/spike-77-ocr-mobile
fix/gitea-release-shell-scope
feat/396-version-sync
feat/376-e2e-drone-integration
feat/374-e2e-playwright-setup
feat/372-planner-v1
feat/370-calendar-read
feat/368-planner-v0
feat/366-habit-source
feat/178-mail-candidate-writer
feat/253-nli-template-ab
fix/348-settings-nav-hijack-v2
fix/347-web-side-drawer
fix/349-profile-menu-close
feat-297-sender-memory-ui
feat-296-web-classifier-sender-memory
feat/294-sender-label-memory
chore/268-analyze-script-dynamic-labels
fix/268-nli-threshold-025
fix/266-imap-getmessage-timeout
fix-imap-unhandled-error
fix-175-onnxruntime-anchor
fix-175-onnxruntime-mainapp
ci-release-gate-apk
ci-mobile-bundle-check
fix-175-native-startup
fix-175-stub-onnxruntime-web
fix-175-import-meta-hermes
feat-web-parcel-scan-toggle
feat-tracking-manual-sync
fix-track17-carrier-ids
feat-232-mail-scanner
feat-233-trackings-post
feat-aftership-provider
feat-195-loading-skeletons
feat-197-error-boundary
feat-194-toast-system
chore/add-claude-md
155-auth-callback-route
feat/fdroid-deploy
fix/mail-messages-pagination-types
feat/ocr-correction-review
fix/ocr-inference-oom
fix/ocr-oom-and-finetune-training
feat/ocr-easyocr-and-training-data
feat/ocr-image-rotate-preview
feat/mobile-image-picker-57
feat/ocr-parse-image-endpoint
feat/lists-notes-e2e
fix/web-show-auth-error-body
fix/deploy-envfile
fix/deploy-ssh-port
feat/drone-deploy
fix/drone-secret-names
fix/dockerfile-deploy-flag
feat/drone-ci
feat/apps-web
feat/shopping-list-crud
v0.6.7-rc33
v0.6.6-rc32
v0.6.6-rc31
v0.6.6-rc30
v0.6.6-rc29
v0.6.6-rc28
v0.6.6-rc27
v0.6.6-rc26
v0.6.6-rc25
v0.6.6-rc24
v0.6.6-rc23
v0.6.6-rc22
v0.6.6-rc21
v0.6.6-rc20
v0.6.6-rc19
debug-rpi5
v0.6.6-rc18
v0.6.6-rc17
v0.6.6-rc16
v0.6.6-rc15
v0.6.6-rc14
v0.6.6-rc13
v0.6.6-rc12
v0.6.6-rc11
v0.6.6-rc10
v0.6.6-rc9
v0.6.6-rc8
v0.6.6-rc7
v0.6.6-rc6
v0.6.6-rc5
v0.6.6-rc4
v0.6.6-rc3
v0.6.6-rc2
v0.6.6-rc1
v0.6.5
v0.6.4
v0.6.3
v0.6.2
v0.6.1
v0.6.0
v0.5.0
v0.4.6
v0.4.5
v1.0.515
v1.0.468
v1.0.449
v1.0.442
Labels
Clear labels   
app/archiv

Document & email archive (Paperless-ngx integration)

  
app/einkaufslisten

   
app/imap-client

   
app/wissensbasis

   
arch-answered

arch-question wurde vom Architekten beantwortet und vom PM in Produkt-Entscheidung übersetzt

  
arch-question

Anfrage an Software-Architekt — Tech-/Architektur-Entscheidung gebraucht (PM hat sie nicht selbst getroffen)

  
area/api

NestJS backend

  
area/auth

Keycloak / OIDC

  
area/infra

Monorepo / CI / tooling

  
area/mobile

Expo React Native app

  
area/shared

Shared packages

  
area/ui

Tamagui UI package

  
area/web

Vite web app

  
portfolio-status

Wöchentlicher CEO-Portfolio-Status

  
prio/high

High priority

  
prio/low

Low priority

  
prio/medium

Medium priority

  
roadmap/public

In der public Roadmap der App sichtbar (roadmap.json kuratiert)

  
size/l

2-3 days

  
size/m

About 1 day

  
size/s

Half a day

  
size/xl

More than 3 days — should be split

  
size/xs

Less than 1 hour

  
status/blocked

Waiting on something

  
status/needs-info

Open questions before work can continue

  
type/bug

Something is broken

  
type/chore

Infra / tooling / maintenance

  
type/docs

Documentation

  
type/feature

New user-facing functionality

  
type/idea

   
type/refactor

Code refactor without behavior change

No labels
app/archiv
app/einkaufslisten
app/imap-client
app/wissensbasis
arch-answered
arch-question
area/api
area/auth
area/infra
area/mobile
area/shared
area/ui
area/web
portfolio-status
prio/high
prio/low
prio/medium
roadmap/public
size/l
size/m
size/s
size/xl
size/xs
status/blocked
status/needs-info
type/bug
type/chore
type/docs
type/feature
type/idea
type/refactor
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
arch-bot
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
admin-mrrm/mrrmlabapp#438
No description provided.