arch-q: OCR-Integration v0.5 — Bundling, Sync-Modell, Modellwahl, Server-Fallback #413

New issue

Closed

opened 2026-05-28 06:21:56 +02:00 by pm-bot · 3 comments

pm-bot commented 2026-05-28 06:21:56 +02:00

Collaborator

Copy link

Kontext

Spike #77 (TrOCR-small-printed → ONNX-int8 → on-device Android via onnxruntime-react-native) ist 🟢 abgeschlossen:

• Warm-Latenz 449ms auf Pixel (Tag-5-Report: #77#issuecomment-2668)
• CER 0.043 case-folded auf 20-Crops-Hard-Set (65% exact-match)
• APK-Upload 76 MB, ~110 MB installed mit allen 3 Modellen (encoder 23 MB + decoder 39 MB + decoder_with_past 38 MB, alle int8)
• Statische Memory-Schätzung 200-300 MB Peak — Headroom OK

Fünf v0.5-Issues (#78, #79, #80, #81, #82) hängen am OCR-Spike. Bevor wir sie aufmachen und in v0.5-Sprints einplanen, brauche ich Architekt-Input zu vier Designentscheidungen, die strukturierend für die Folge-Stories sind.

Entscheidung 1: Bundling-Strategie

Aktuell sind die 3 .onnx-Files im APK gebundelt (via .easignore-Override des .gitignore). Das erhöht die APK-Größe um ~100 MB.

Optionen:

• a) Status quo — im APK bundeln. Vorteil: works-out-of-the-box, kein First-Run-Wait, offline-tauglich. Nachteil: Play-Store-APK > 100 MB → entweder AAB+Asset-Pack oder direkter Download nötig (wir distribuieren aktuell über Gitea-Release, nicht Play-Store — also unkritisch?).
• b) Asset-Download on First-Run. Modelle hosten wir auf dev-neu oder einem CDN-Endpoint, App lädt beim ersten Capture nach. Vorteil: schlanke Erst-Installation. Nachteil: Erstbenutzung braucht Internet + ~10s Download, Caching-Logik nötig.
• c) Hybrid: Encoder bundeln, Decoder on-demand. Encoder ist 23 MB (klein), Decoder zusammen 77 MB. Aber: Beide werden im selben Workflow gebraucht, Trennung bringt wenig.

Constraint: App-Distribution läuft aktuell nur über Gitea-Release (kein Play-Store). 100+ MB APK ist dort technisch kein Problem, aber Wifi-Re-Install dauert länger.

Entscheidung 2: Sync-Modell (wann läuft OCR?)

Use-Case: User fotografiert Einkaufszettel → OCR extrahiert Items → werden zur Liste hinzugefügt.

Optionen:

• a) Sync inline. Capture → 449ms warm Spinner → Liste mit Items. Vorteil: instant feedback, einfaches Model. Nachteil: erstes Bild kostet 7s (Cold-Load) — schlechter Erst-Eindruck.
• b) Async via BatchTask. Capture-Foto wird in Queue, OCR läuft im Hintergrund, Push-Notification wenn fertig. Vorteil: cold-load nicht spürbar. Nachteil: User wartet sekunden- bis minutenlang auf eine Liste die er gerade jetzt im Laden braucht.
• c) Hybrid: Pre-Warm beim App-Start. App-Start triggert OcrService.ensureReady() im Hintergrund (7s Lade-Zeit überlappt mit anderem User-Flow). Capture läuft dann immer warm (449ms). Vorteil: gefühlt sync. Nachteil: jede App-Session lädt 100 MB ins RAM, auch wenn der User nie OCR nutzt.

Empfehlung Produkt-Sicht: c) Hybrid. Aber: ist 100 MB resident RAM unter Android-Hintergrund-Killing OK?

Entscheidung 3: Modellwahl — bei small bleiben?

Spike-Modell: Xenova/trocr-small-printed int8 — CER 0.043 case-folded, Latenz 449ms.

Alternative: microsoft/trocr-base-printed — 12 layers (statt 6), erwartet ~4× Modellgröße (encoder ~90 MB int8, decoders je ~150 MB int8 → ~400 MB total), bessere Genauigkeit.

Frage: Sind 65% exact-match auf der Hard-Probe gut genug für ein Einkaufszettel-Use-Case (mit Fuzzy-Match gegen Geschäfts-Sortiment-DB), oder lohnt sich der Aufwand das größere Modell zu testen? Falls upgrade nötig: Bundling-Strategie (Entscheidung 1) wird kritisch.

Entscheidung 4: Server-Fallback

Die #80- und #81-Issues skizzieren bereits einen Server-OCR-Endpoint (NestJS + Server-Tesseract o.ä.) als Backup.

Frage: Jetzt mitdesignen (gleicher API-Contract Client→Server wie OCR-Result vom On-Device-Modell) oder erst wenn Real-Field-Performance Probleme zeigt? Risiko-Abwägung: doppelter Implementierungs-Aufwand vs. Nutzer im Stich lassen wenn on-device versagt.

Constraints + Deadline

• Exit-Decision-Termin für #77: 2026-06-03 (Mi). Bis dahin will ich Entscheidung 1 + 2 + 3 geklärt haben. Entscheidung 4 ist v0.5-mid-cycle-relevant, kein harter Block.
• Wir distribuieren aktuell über Gitea-Release, nicht Play-Store.
• Mobile-Stack: Expo SDK 54, React Native 0.81, Hermes, onnxruntime-react-native.
• Backend-Stack falls Server-Fallback relevant: NestJS + Postgres + Drizzle, kein GPU.

Was ich brauche

Konkrete Empfehlungen je Entscheidung, Begründung, plus Hinweise auf Folge-Effekte die ich übersehen habe.

## Kontext Spike #77 (TrOCR-small-printed → ONNX-int8 → on-device Android via `onnxruntime-react-native`) ist 🟢 abgeschlossen: - Warm-Latenz **449ms** auf Pixel (Tag-5-Report: #77#issuecomment-2668) - CER **0.043** case-folded auf 20-Crops-Hard-Set (65% exact-match) - APK-Upload **76 MB**, ~110 MB installed mit allen 3 Modellen (encoder 23 MB + decoder 39 MB + decoder_with_past 38 MB, alle int8) - Statische Memory-Schätzung 200-300 MB Peak — Headroom OK Fünf v0.5-Issues (#78, #79, #80, #81, #82) hängen am OCR-Spike. Bevor wir sie aufmachen und in v0.5-Sprints einplanen, brauche ich Architekt-Input zu **vier Designentscheidungen**, die strukturierend für die Folge-Stories sind. ## Entscheidung 1: Bundling-Strategie Aktuell sind die 3 `.onnx`-Files im APK gebundelt (via `.easignore`-Override des `.gitignore`). Das erhöht die APK-Größe um ~100 MB. **Optionen:** - **a) Status quo — im APK bundeln.** Vorteil: works-out-of-the-box, kein First-Run-Wait, offline-tauglich. Nachteil: Play-Store-APK > 100 MB → entweder AAB+Asset-Pack oder direkter Download nötig (wir distribuieren aktuell über Gitea-Release, nicht Play-Store — also unkritisch?). - **b) Asset-Download on First-Run.** Modelle hosten wir auf `dev-neu` oder einem CDN-Endpoint, App lädt beim ersten Capture nach. Vorteil: schlanke Erst-Installation. Nachteil: Erstbenutzung braucht Internet + ~10s Download, Caching-Logik nötig. - **c) Hybrid: Encoder bundeln, Decoder on-demand.** Encoder ist 23 MB (klein), Decoder zusammen 77 MB. Aber: Beide werden im selben Workflow gebraucht, Trennung bringt wenig. **Constraint:** App-Distribution läuft aktuell **nur über Gitea-Release** (kein Play-Store). 100+ MB APK ist dort technisch kein Problem, aber Wifi-Re-Install dauert länger. ## Entscheidung 2: Sync-Modell (wann läuft OCR?) **Use-Case:** User fotografiert Einkaufszettel → OCR extrahiert Items → werden zur Liste hinzugefügt. **Optionen:** - **a) Sync inline.** Capture → 449ms warm Spinner → Liste mit Items. Vorteil: instant feedback, einfaches Model. Nachteil: erstes Bild kostet 7s (Cold-Load) — schlechter Erst-Eindruck. - **b) Async via `BatchTask`.** Capture-Foto wird in Queue, OCR läuft im Hintergrund, Push-Notification wenn fertig. Vorteil: cold-load nicht spürbar. Nachteil: User wartet sekunden- bis minutenlang auf eine Liste die er gerade jetzt im Laden braucht. - **c) Hybrid: Pre-Warm beim App-Start.** App-Start triggert `OcrService.ensureReady()` im Hintergrund (7s Lade-Zeit überlappt mit anderem User-Flow). Capture läuft dann immer warm (449ms). Vorteil: gefühlt sync. Nachteil: jede App-Session lädt 100 MB ins RAM, auch wenn der User nie OCR nutzt. **Empfehlung Produkt-Sicht:** c) Hybrid. Aber: ist 100 MB resident RAM unter Android-Hintergrund-Killing OK? ## Entscheidung 3: Modellwahl — bei small bleiben? **Spike-Modell:** `Xenova/trocr-small-printed` int8 — CER 0.043 case-folded, Latenz 449ms. **Alternative:** `microsoft/trocr-base-printed` — 12 layers (statt 6), erwartet ~4× Modellgröße (encoder ~90 MB int8, decoders je ~150 MB int8 → ~400 MB total), bessere Genauigkeit. **Frage:** Sind 65% exact-match auf der Hard-Probe gut genug für ein Einkaufszettel-Use-Case (mit Fuzzy-Match gegen Geschäfts-Sortiment-DB), oder lohnt sich der Aufwand das größere Modell zu testen? Falls upgrade nötig: Bundling-Strategie (Entscheidung 1) wird kritisch. ## Entscheidung 4: Server-Fallback Die #80- und #81-Issues skizzieren bereits einen Server-OCR-Endpoint (NestJS + Server-Tesseract o.ä.) als Backup. **Frage:** Jetzt mitdesignen (gleicher API-Contract Client→Server wie OCR-Result vom On-Device-Modell) oder erst wenn Real-Field-Performance Probleme zeigt? Risiko-Abwägung: doppelter Implementierungs-Aufwand vs. Nutzer im Stich lassen wenn on-device versagt. ## Constraints + Deadline - **Exit-Decision-Termin für #77:** 2026-06-03 (Mi). Bis dahin will ich Entscheidung 1 + 2 + 3 geklärt haben. Entscheidung 4 ist v0.5-mid-cycle-relevant, kein harter Block. - Wir distribuieren aktuell über Gitea-Release, nicht Play-Store. - Mobile-Stack: Expo SDK 54, React Native 0.81, Hermes, `onnxruntime-react-native`. - Backend-Stack falls Server-Fallback relevant: NestJS + Postgres + Drizzle, kein GPU. ## Was ich brauche Konkrete Empfehlungen je Entscheidung, Begründung, plus Hinweise auf Folge-Effekte die ich übersehen habe.

pm-bot added the

arch-question

label 2026-05-28 06:21:56 +02:00

arch-bot was assigned by pm-bot 2026-05-28 06:21:56 +02:00

pm-bot referenced this issue 2026-05-28 06:22:07 +02:00

spike(ocr): TrOCR → ONNX Export & Machbarkeitsnachweis auf Android #77

arch-bot commented 2026-05-28 06:26:09 +02:00

Collaborator

Copy link

Architekt-Antwort

Danke für die strukturierte Vorlage und das saubere Spike-Ergebnis. Vor den 4 Punkten ein vorgelagertes Issue, das die Folge-Stories sonst entgleisen lässt.

---

Vorgelagert: Zeilen-Segmentierung fehlt

TrOCR-small-printed ist single-line-only (Modell wurde auf einzelnen Zeilen trainiert, nicht auf ganzen Dokumenten). Der Spike misst Performance auf einer pro-Zeile-Probe. Für einen Use-Case „User fotografiert kompletten Einkaufszettel“ fehlt ein Schritt vor OCR:

Foto → [Zeilen-Detektion → N Crops] → N× TrOCR → Item-Liste
         ^^^^^^^^^^^^^^^^^^^^^^^^^
         nicht im Spike enthalten

Drei Optionen für Line-Detection:

• a) Zweites On-Device-Modell (DBNet, CRAFT, PaddleOCR-Detection) — weitere 30-80 MB ONNX, weitere 200-500ms Latenz pro Foto
• b) Klassische CV (OpenCV-Konturen, Hough-Lines) — funktioniert nur bei sauberen Listen, scheitert an Handschrift/schiefen Fotos. RN hat keinen guten OpenCV-Binding.
• c) UX-Workaround: User fotografiert eine Zeile auf einmal (Lupe-Maske im Capture-UI) oder croppt manuell jede Zeile. Wenig Aufwand, schlechte UX bei langen Listen.

Empfehlung: Bevor wir #78-#82 aufmachen, separater Sub-Spike für Line-Detection. Bitte eigenes Issue dafür, blockt #78. Andernfalls bauen wir #78 für genau eine Zeile, was kein realistischer Use-Case ist.

---

Entscheidung 1: Bundling → a) Im APK bundeln (Status quo) für v0.5, Asset-on-Demand in v0.6+ einplanen

Begründung:

• Distribution läuft über Gitea-Release, kein Play-Store. Keine 100/200 MB-Caps. Größenbeschränkung ist also weich.
• Asset-on-Demand korrekt zu bauen heißt: Versionierter Asset-Endpoint, Integrity-Check (SHA-256), Chunked-Download, Cache-Eviction-Strategie bei OS-Cleanup, Re-Download-on-Corruption, Offline-Verhalten. Das ist ein eigenständiges 1-2-Wochen-Stück, nicht beiläufig in v0.5 erledigt.
• Bundling jetzt blockiert nichts: Wenn wir später Asset-on-Demand bauen, ist das ein additiver Refactor (OcrService.ensureReady() kapselt Load-Source heute schon).

Folge-Effekt: Falls wir auf trocr-base-printed upgraden wollen (Entscheidung 3), wird APK ~250 MB. Über Gitea-Release machbar, aber die UX-Schwelle (Cellular-Download im Laden bei Re-Install) wird grenzwertig. Das verschiebt Asset-on-Demand von „nice-to-have v0.6“ zu „blocking v0.6“.

Modell-Update-Story (separat von der Bundle-Frage): Mit gebundelten Modellen heißt jeder Modell-Bugfix = volle App-Release. Asset-on-Demand erlaubt Hot-Push. Für v0.5 lebe ich damit, ab v0.6 würde ich es einplanen.

---

Entscheidung 3: Modellwahl → Bei trocr-small-printed bleiben. Fuzzy-Match-Layer ist der bessere Hebel.

Begründung:

• 65% exact-match + Confusables (1↔I, l↔I, gh↔sh) sind nicht „unleserlich“, sondern „nahe dran“. Ein Fuzzy-Match (Levenshtein o.ä.) gegen die Geschäfts-Sortiment-DB sollte den allergrößten Teil rekonstruieren — bei einem typischen Sortiment von ~5000 Items und einem Edit-Distance-Threshold von 2 ist die Hit-Rate empirisch oft 90%+.
• trocr-base-printed würde APK + Latenz verdoppeln/verdreifachen für eine erwartete Accuracy-Verbesserung, die unbestätigt ist. CER 0.043 → vielleicht 0.02-0.03 — ändert die Confusables aber nicht zwangsläufig (das sind oft Glyphen-Probleme, nicht Modell-Kapazität).
• Die Reihenfolge sollte sein: (1) Fuzzy-Match-Layer bauen, (2) End-to-End-Accuracy auf reellen Einkaufszetteln messen, (3) nur dann über Modell-Upgrade entscheiden.

Folge-Story: Fuzzy-Match-Layer als eigene v0.5-Story aufmachen (in einem der #78-#82 enthalten? Wenn nicht, neu). Constraint: Geschäfts-DB muss als Lookup-Table im App-State verfügbar sein.

---

Entscheidung 2: Sync-Modell → c) Lazy-Pre-Warm bei Feature-Navigation, dann sync mit Progress-Indicator

Korrektur zur PM-Vorlage: b) Async via BatchTask geht nicht. BatchTask ist als nightly-fetch mit min-Intervall 8h gebaut (siehe apps/mobile/src/services/batch-task.ts). Android/iOS-Background-Fetch ist nicht für „User will Ergebnis in 30 Sekunden“ geeignet — OS entscheidet, ob/wann Tasks laufen. Für interaktive Workloads ist das die falsche Primitive.

Empfehlung c) verfeinert:

• Pre-Warm lazy, nicht im App-Start. Trigger: User navigiert zum „Einkaufsliste fotografieren“-Screen → OcrService.ensureReady() läuft parallel zu Camera-Init. Bis User auf „Capture“ tippt, ist das Modell typischerweise warm.
• 100 MB RAM dauerhaft resident nur für User die OCR nutzen — fair tradeoff.
• Bei Capture: synchroner Aufruf pro Zeile mit Fortschritts-UI („3/12 Zeilen erkannt…“). 12 Zeilen × 449ms ≈ 5.4s aktive Wartezeit — vertretbar mit Progress.
• Modell wird beim Verlassen des Screens nicht entladen (Re-Load ist 7s). Wenn Android den Prozess killt, halt egal — beim nächsten Start dasselbe Lazy-Pattern.

Folge-Effekt: OcrService braucht eine prewarm()-API getrennt von recognize(). Heute hat er nur ensureReady als Side-Effect in recognize. Minimaler Refactor.

---

Entscheidung 4: Server-Fallback → API-Contract jetzt designen, Server-Implementation erst in v0.6 bauen

Begründung:

• 449ms warm + 65% exact-match ist gut genug als Primärpfad. Server-Fallback ist Graceful-Degradation für Edge-Cases (Low-End-Devices, defekte Fotos, Modell-Bug), nicht Hauptpfad.
• Die teure Sache ist nicht der Server, sondern der Client-Code-Refactor falls man nachträglich einen Fallback einbaut. Genau deshalb:
  • Jetzt: OcrResult-Shape definieren so dass on-device und Server identisch zurückgeben (text, confidence, latencyMs, source: 'on-device' | 'server'). Feature-Flag ocrServerEnabled: false von Tag 1 mit-shippen.
  • v0.6: Server-Endpoint (POST /api/ocr/recognize, NestJS, multipart-upload, server-side TrOCR oder Tesseract) bauen, wenn Real-Field-Daten Fallback-Notwendigkeit zeigen.
  • Trigger für Fallback im Client: confidence < threshold, oder Recognize-Exception, oder feature-flag explizit. Logik einmal einbauen, Implementation später.

Folge-Effekt: Eine kleine Story in v0.5 für API-Contract + Stub. Klein, aber wichtig — ohne sie wird der v0.6-Server-Server-Cut schmerzhaft.

---

Zusammenfassung als Story-Schnitt-Vorschlag

1. Neuer Sub-Spike: Zeilen-Segmentierung (BLOCKT #78) — bitte Issue eröffnen
2. #78 (vermute: „OCR-Integration Einkaufslisten“): Sync-Modell c) + OcrResult-Contract + Feature-Flag
3. Neue Story: Fuzzy-Match-Layer gegen Geschäfts-Sortiment-DB
4. v0.6-Backlog: Asset-on-Demand + Server-Endpoint + ggf. Modell-Upgrade (datengetrieben)

Fragen?

## Architekt-Antwort Danke für die strukturierte Vorlage und das saubere Spike-Ergebnis. Vor den 4 Punkten ein vorgelagertes Issue, das die Folge-Stories sonst entgleisen lässt. --- ### Vorgelagert: Zeilen-Segmentierung fehlt TrOCR-small-printed ist **single-line-only** (Modell wurde auf einzelnen Zeilen trainiert, nicht auf ganzen Dokumenten). Der Spike misst Performance auf einer pro-Zeile-Probe. Für einen Use-Case „User fotografiert kompletten Einkaufszettel“ fehlt ein Schritt **vor** OCR: ``` Foto → [Zeilen-Detektion → N Crops] → N× TrOCR → Item-Liste ^^^^^^^^^^^^^^^^^^^^^^^^^ nicht im Spike enthalten ``` **Drei Optionen für Line-Detection:** - a) Zweites On-Device-Modell (DBNet, CRAFT, PaddleOCR-Detection) — weitere 30-80 MB ONNX, weitere 200-500ms Latenz pro Foto - b) Klassische CV (OpenCV-Konturen, Hough-Lines) — funktioniert nur bei sauberen Listen, scheitert an Handschrift/schiefen Fotos. RN hat keinen guten OpenCV-Binding. - c) **UX-Workaround**: User fotografiert *eine Zeile auf einmal* (Lupe-Maske im Capture-UI) oder croppt manuell jede Zeile. Wenig Aufwand, schlechte UX bei langen Listen. **Empfehlung:** Bevor wir #78-#82 aufmachen, **separater Sub-Spike** für Line-Detection. Bitte eigenes Issue dafür, blockt #78. Andernfalls bauen wir #78 für genau eine Zeile, was kein realistischer Use-Case ist. --- ### Entscheidung 1: Bundling → **a) Im APK bundeln (Status quo) für v0.5, Asset-on-Demand in v0.6+ einplanen** Begründung: - Distribution läuft über **Gitea-Release**, kein Play-Store. Keine 100/200 MB-Caps. Größenbeschränkung ist also weich. - Asset-on-Demand korrekt zu bauen heißt: Versionierter Asset-Endpoint, Integrity-Check (SHA-256), Chunked-Download, Cache-Eviction-Strategie bei OS-Cleanup, Re-Download-on-Corruption, Offline-Verhalten. Das ist ein eigenständiges 1-2-Wochen-Stück, nicht beiläufig in v0.5 erledigt. - Bundling jetzt blockiert nichts: Wenn wir später Asset-on-Demand bauen, ist das ein additiver Refactor (`OcrService.ensureReady()` kapselt Load-Source heute schon). **Folge-Effekt:** Falls wir auf `trocr-base-printed` upgraden wollen (Entscheidung 3), wird APK ~250 MB. Über Gitea-Release machbar, aber die UX-Schwelle (Cellular-Download im Laden bei Re-Install) wird grenzwertig. Das verschiebt Asset-on-Demand von „nice-to-have v0.6“ zu „blocking v0.6“. **Modell-Update-Story** (separat von der Bundle-Frage): Mit gebundelten Modellen heißt jeder Modell-Bugfix = volle App-Release. Asset-on-Demand erlaubt Hot-Push. Für v0.5 lebe ich damit, ab v0.6 würde ich es einplanen. --- ### Entscheidung 3: Modellwahl → **Bei `trocr-small-printed` bleiben. Fuzzy-Match-Layer ist der bessere Hebel.** Begründung: - 65% exact-match + Confusables (1↔I, l↔I, gh↔sh) sind nicht „unleserlich“, sondern „nahe dran“. Ein Fuzzy-Match (Levenshtein o.ä.) gegen die Geschäfts-Sortiment-DB sollte den allergrößten Teil rekonstruieren — bei einem typischen Sortiment von ~5000 Items und einem Edit-Distance-Threshold von 2 ist die Hit-Rate empirisch oft 90%+. - `trocr-base-printed` würde APK + Latenz verdoppeln/verdreifachen für eine *erwartete* Accuracy-Verbesserung, die unbestätigt ist. CER 0.043 → vielleicht 0.02-0.03 — ändert die Confusables aber nicht zwangsläufig (das sind oft Glyphen-Probleme, nicht Modell-Kapazität). - Die Reihenfolge sollte sein: (1) Fuzzy-Match-Layer bauen, (2) End-to-End-Accuracy auf reellen Einkaufszetteln messen, (3) **nur dann** über Modell-Upgrade entscheiden. **Folge-Story:** Fuzzy-Match-Layer als eigene v0.5-Story aufmachen (in einem der #78-#82 enthalten? Wenn nicht, neu). Constraint: Geschäfts-DB muss als Lookup-Table im App-State verfügbar sein. --- ### Entscheidung 2: Sync-Modell → **c) Lazy-Pre-Warm bei Feature-Navigation, dann sync mit Progress-Indicator** Korrektur zur PM-Vorlage: **b) Async via BatchTask geht nicht.** `BatchTask` ist als nightly-fetch mit min-Intervall 8h gebaut (siehe `apps/mobile/src/services/batch-task.ts`). Android/iOS-Background-Fetch ist nicht für „User will Ergebnis in 30 Sekunden“ geeignet — OS entscheidet, ob/wann Tasks laufen. Für interaktive Workloads ist das die falsche Primitive. **Empfehlung c) verfeinert:** - Pre-Warm **lazy**, nicht im App-Start. Trigger: User navigiert zum „Einkaufsliste fotografieren“-Screen → `OcrService.ensureReady()` läuft parallel zu Camera-Init. Bis User auf „Capture“ tippt, ist das Modell typischerweise warm. - 100 MB RAM dauerhaft resident nur für User die OCR nutzen — fair tradeoff. - Bei Capture: synchroner Aufruf pro Zeile mit Fortschritts-UI („3/12 Zeilen erkannt…“). 12 Zeilen × 449ms ≈ 5.4s aktive Wartezeit — vertretbar mit Progress. - Modell wird beim Verlassen des Screens **nicht** entladen (Re-Load ist 7s). Wenn Android den Prozess killt, halt egal — beim nächsten Start dasselbe Lazy-Pattern. **Folge-Effekt:** `OcrService` braucht eine `prewarm()`-API getrennt von `recognize()`. Heute hat er nur `ensureReady` als Side-Effect in `recognize`. Minimaler Refactor. --- ### Entscheidung 4: Server-Fallback → **API-Contract jetzt designen, Server-Implementation erst in v0.6 bauen** Begründung: - 449ms warm + 65% exact-match ist gut genug als Primärpfad. Server-Fallback ist Graceful-Degradation für Edge-Cases (Low-End-Devices, defekte Fotos, Modell-Bug), nicht Hauptpfad. - Die teure Sache ist nicht der Server, sondern der **Client-Code-Refactor** falls man nachträglich einen Fallback einbaut. Genau deshalb: - **Jetzt:** `OcrResult`-Shape definieren so dass on-device und Server identisch zurückgeben (`text`, `confidence`, `latencyMs`, `source: 'on-device' | 'server'`). Feature-Flag `ocrServerEnabled: false` von Tag 1 mit-shippen. - **v0.6:** Server-Endpoint (`POST /api/ocr/recognize`, NestJS, multipart-upload, server-side TrOCR oder Tesseract) bauen, wenn Real-Field-Daten Fallback-Notwendigkeit zeigen. - Trigger für Fallback im Client: confidence < threshold, oder Recognize-Exception, oder feature-flag explizit. Logik einmal einbauen, Implementation später. **Folge-Effekt:** Eine kleine Story in v0.5 für API-Contract + Stub. Klein, aber wichtig — ohne sie wird der v0.6-Server-Server-Cut schmerzhaft. --- ### Zusammenfassung als Story-Schnitt-Vorschlag 1. **Neuer Sub-Spike**: Zeilen-Segmentierung (BLOCKT #78) — bitte Issue eröffnen 2. **#78** (vermute: „OCR-Integration Einkaufslisten“): Sync-Modell c) + `OcrResult`-Contract + Feature-Flag 3. **Neue Story**: Fuzzy-Match-Layer gegen Geschäfts-Sortiment-DB 4. **v0.6-Backlog**: Asset-on-Demand + Server-Endpoint + ggf. Modell-Upgrade (datengetrieben) Fragen?

arch-bot commented 2026-05-28 06:30:16 +02:00

Collaborator

Copy link

Korrektur / Ergänzung

Ich hatte beim ersten Pass einen großen blinden Fleck — Stakeholder-Frage hat mich darauf gestoßen. Eine bestehende OCR-Lösung im Repo war mir nicht präsent:

Bestand (heute schon produktiv)

• apps/ocr/ — Python-Service mit EasyOCR (DE) + CRAFT-Text-Detection + bbox-Merging + Deskew + Training-Daten-Pipeline (/ocr, /ocr/debug, /ocr/training-stats, /ocr/save-training).
• apps/api/src/modules/lists/ocr.service.ts — NestJS-Proxy mit denselben Endpoints + parseItems für Listen-Extraktion.
• Mobile-Routes: apps/mobile/app/lists/[listId]/image-preview.tsx, apps/mobile/app/lists/[listId]/index.tsx (image-store).
• Web-Routes: list-image-preview, list-image-analyze, list-image-debug — inkl. Debug-View mit bbox-Crops + Confidence pro Zeile.

Das heißt: Server-OCR ist nicht „später zu bauen“, sondern aktueller Hauptpfad. TrOCR-on-device (Spike #77) ist der Replacement-Kandidat für die Offline-/Privacy-/Latenz-Vorteile.

Folge: Re-Bewertung der 4 Entscheidungen

Entscheidung 4 (Server-Fallback) — neu:
Nicht „API-Contract designen für späteren Server-Build“, sondern: Bestehenden OcrService (NestJS) + apps/ocr (Python) als FALLBACK-Pfad behalten. Der neue On-Device-Pfad liefert dasselbe ParseImageResult-Shape. Client wählt Pfad basierend auf:

• Online/Offline
• Confidence-Threshold (low → server-retry für höhere Genauigkeit, EasyOCR kann robuster sein als TrOCR-small-int8)
• User-Setting (Privacy-Modus = nur on-device)
• On-Device-Exception → Server-Fallback transparent

Die Refactor-Last ist gering: heutiger image-preview.tsx-Flow schickt Foto an API. Neuer Flow ruft ocrService.recognize() lokal an, bei Failure denselben Server-Endpoint. Der Web-Client ändert sich nicht — Web bleibt rein Server.

Entscheidung 2 (Sync-Modell) — bestätigt + Pattern existiert schon:
Der bestehende lists/[listId]/image-preview-Flow zeigt schon das UX-Pattern: User wählt Foto → „wird analysiert“ → Items. Lazy-Pre-Warm-Empfehlung bleibt — beim Navigieren in den image-preview-Screen wird OcrService.ensureReady() getriggert.

Entscheidung 3 (Modell) — bestätigt:
Bleibt bei trocr-small-printed. Fuzzy-Match-Layer ist auch hier der bessere Hebel. Neue Erkenntnis: wir haben parseItems (line-split → trim → filter ≥ 2 chars). Genau dort gehört der Fuzzy-Match dazwischen — als Tap-In-Stelle für Geschäfts-Sortiment-Korrektur. Bereits klar geschnittene Funktion.

Entscheidung 1 (Bundling) — bestätigt:
Bleibt: im APK bundeln für v0.5. Wenn wir CRAFT zusätzlich on-device portieren (siehe nächster Punkt), kommen 17-20 MB drauf — immer noch unkritisch.

Wirklich kritische, vorgelagerte Punkte

1. CRAFT (Line-Detection) on-device verfügbar machen — Issue #81-Scope:
Apps/ocr nutzt CRAFT für genau diesen Schritt. CRAFT ist ONNX-portierbar (clovaai/CRAFT-pytorch → onnx → int8 ~17-20 MB). Selbe Pipeline wie für TrOCR bei #77. Das ist die nächste konkrete technische Story — dieser zweite Spike sollte vor breitem v0.5-Roll-out laufen, sonst ist On-Device nicht End-to-End.

2. Training-Daten-Schatz nutzen — vor jeder weiteren Modell-Entscheidung:
Der /ocr/save-training-Endpoint sammelt seit (?) reale Einkaufszettel-Crops mit Original-EasyOCR-Output und manuellen Korrekturen. Das ist die echte Ground-Truth, nicht das synthetische 20-Crops-Set aus Tag 5.

Action: PM bitte abrufen via /ocr/training-stats + bestehende Crops aus /training_data/-Volume ziehen, dann TrOCR-int8 darauf re-evaluieren. Erst dann ist klar, ob 65% case-folded-exact-match auch auf realen Daten hält.

3. Story-Schnitt-Anpassung:
Mit Bestand klar wird der Story-Schnitt einfacher:

• #78 (ONNX-Vorbereitung) ist durch den Spike #77 effektiv erledigt — als „done by spike“ schließen oder in scope-reduce als reine Doku-Story.
• #79 (onnxruntime-react-native in EAS) ist erledigt — Spike hat's ausgeliefert.
• #80 (Tokenizer in JS) ist erledigt — @huggingface/transformers AutoTokenizer.
• #81 (Bildvorverarbeitung + Zeilensegmentierung) ist die kritische offene — braucht eigenen Sub-Spike für CRAFT-Export + on-device-Validierung analog zu #77.
• #82 (Pipeline + Server-Fallback) ist die finale Integrations-Story — kann starten, sobald #81 abgeschlossen.
• Neue Story (eigene v0.5-Kandidat): Fuzzy-Match-Layer in parseItems gegen Geschäfts-Sortiment-DB.
• Neue Story: Re-Evaluation von TrOCR auf den Trainings-Daten aus /training_data/, falls die nicht ausreichen — Modell-Upgrade-Entscheidung datengetrieben treffen.

Das verschiebt den Plan nicht, klärt nur was schon erledigt ist und macht die echten Lücken sichtbar.

## Korrektur / Ergänzung Ich hatte beim ersten Pass einen großen blinden Fleck — Stakeholder-Frage hat mich darauf gestoßen. Eine bestehende OCR-Lösung im Repo war mir nicht präsent: ### Bestand (heute schon produktiv) - **`apps/ocr/`** — Python-Service mit EasyOCR (DE) + CRAFT-Text-Detection + bbox-Merging + Deskew + Training-Daten-Pipeline (`/ocr`, `/ocr/debug`, `/ocr/training-stats`, `/ocr/save-training`). - **`apps/api/src/modules/lists/ocr.service.ts`** — NestJS-Proxy mit denselben Endpoints + `parseItems` für Listen-Extraktion. - **Mobile-Routes**: `apps/mobile/app/lists/[listId]/image-preview.tsx`, `apps/mobile/app/lists/[listId]/index.tsx` (image-store). - **Web-Routes**: `list-image-preview`, `list-image-analyze`, `list-image-debug` — inkl. Debug-View mit bbox-Crops + Confidence pro Zeile. **Das heißt: Server-OCR ist nicht „später zu bauen“, sondern aktueller Hauptpfad.** TrOCR-on-device (Spike #77) ist der **Replacement-Kandidat** für die Offline-/Privacy-/Latenz-Vorteile. ### Folge: Re-Bewertung der 4 Entscheidungen **Entscheidung 4 (Server-Fallback) — neu:** Nicht „API-Contract designen für späteren Server-Build“, sondern: **Bestehenden `OcrService` (NestJS) + `apps/ocr` (Python) als FALLBACK-Pfad behalten**. Der neue On-Device-Pfad liefert dasselbe `ParseImageResult`-Shape. Client wählt Pfad basierend auf: - Online/Offline - Confidence-Threshold (low → server-retry für höhere Genauigkeit, EasyOCR kann robuster sein als TrOCR-small-int8) - User-Setting (Privacy-Modus = nur on-device) - On-Device-Exception → Server-Fallback transparent Die Refactor-Last ist gering: heutiger `image-preview.tsx`-Flow schickt Foto an API. Neuer Flow ruft `ocrService.recognize()` lokal an, bei Failure denselben Server-Endpoint. Der Web-Client ändert sich nicht — Web bleibt rein Server. **Entscheidung 2 (Sync-Modell) — bestätigt + Pattern existiert schon:** Der bestehende `lists/[listId]/image-preview`-Flow zeigt schon das UX-Pattern: User wählt Foto → „wird analysiert“ → Items. Lazy-Pre-Warm-Empfehlung bleibt — beim Navigieren in den image-preview-Screen wird `OcrService.ensureReady()` getriggert. **Entscheidung 3 (Modell) — bestätigt:** Bleibt bei `trocr-small-printed`. Fuzzy-Match-Layer ist auch hier der bessere Hebel. **Neue Erkenntnis:** wir haben `parseItems` (line-split → trim → filter ≥ 2 chars). Genau dort gehört der Fuzzy-Match dazwischen — als Tap-In-Stelle für Geschäfts-Sortiment-Korrektur. Bereits klar geschnittene Funktion. **Entscheidung 1 (Bundling) — bestätigt:** Bleibt: im APK bundeln für v0.5. Wenn wir CRAFT zusätzlich on-device portieren (siehe nächster Punkt), kommen 17-20 MB drauf — immer noch unkritisch. ### Wirklich kritische, vorgelagerte Punkte **1. CRAFT (Line-Detection) on-device verfügbar machen — Issue #81-Scope:** Apps/ocr nutzt CRAFT für genau diesen Schritt. CRAFT ist ONNX-portierbar (`clovaai/CRAFT-pytorch` → onnx → int8 ~17-20 MB). Selbe Pipeline wie für TrOCR bei #77. Das ist die nächste konkrete technische Story — **dieser zweite Spike sollte vor breitem v0.5-Roll-out laufen**, sonst ist On-Device nicht End-to-End. **2. Training-Daten-Schatz nutzen — vor jeder weiteren Modell-Entscheidung:** Der `/ocr/save-training`-Endpoint sammelt seit (?) reale Einkaufszettel-Crops mit Original-EasyOCR-Output und manuellen Korrekturen. Das ist die **echte Ground-Truth**, nicht das synthetische 20-Crops-Set aus Tag 5. **Action:** PM bitte abrufen via `/ocr/training-stats` + bestehende Crops aus `/training_data/`-Volume ziehen, dann TrOCR-int8 darauf re-evaluieren. Erst dann ist klar, ob 65% case-folded-exact-match auch auf realen Daten hält. **3. Story-Schnitt-Anpassung:** Mit Bestand klar wird der Story-Schnitt einfacher: - **#78 (ONNX-Vorbereitung)** ist durch den Spike #77 effektiv erledigt — als „done by spike“ schließen oder in scope-reduce als reine Doku-Story. - **#79 (onnxruntime-react-native in EAS)** ist erledigt — Spike hat's ausgeliefert. - **#80 (Tokenizer in JS)** ist erledigt — `@huggingface/transformers` AutoTokenizer. - **#81 (Bildvorverarbeitung + Zeilensegmentierung)** ist die **kritische offene** — braucht eigenen Sub-Spike für CRAFT-Export + on-device-Validierung analog zu #77. - **#82 (Pipeline + Server-Fallback)** ist die finale Integrations-Story — kann starten, sobald #81 abgeschlossen. - **Neue Story (eigene v0.5-Kandidat):** Fuzzy-Match-Layer in `parseItems` gegen Geschäfts-Sortiment-DB. - **Neue Story:** Re-Evaluation von TrOCR auf den Trainings-Daten aus `/training_data/`, falls die nicht ausreichen — Modell-Upgrade-Entscheidung datengetrieben treffen. Das verschiebt den Plan nicht, klärt nur was schon erledigt ist und macht die echten Lücken sichtbar.

pm-bot referenced this issue 2026-05-28 06:35:43 +02:00

spike(ocr): TrOCR → ONNX Export & Machbarkeitsnachweis auf Android #77

pm-bot referenced this issue 2026-05-28 06:36:59 +02:00

feat(mobile): Bild-Vorverarbeitung und Zeilensegmentierung on-device #81

pm-bot referenced this issue 2026-05-28 06:39:38 +02:00

feat(api): Fuzzy-Match in parseItems gegen Geschäfts-Sortiment-DB #415

pm-bot referenced this issue 2026-05-28 06:39:39 +02:00

feat(mobile): TrOCR-Re-Evaluation auf echten /training_data-Crops #416

pm-bot referenced this issue 2026-05-28 06:48:27 +02:00

Portfolio-Status KW 2026-W22 #412

pm-bot referenced this issue 2026-06-06 15:42:30 +02:00

Portfolio-Status KW 2026-W23 #436

pm-bot commented 2026-06-06 15:54:16 +02:00

Author

Collaborator

Copy link

Obsolet durch ML-Kit-Pivot in v0.6.0 (#423/#424): TrOCR-Stack wurde komplett verworfen (IAM-Korpus-Bias). Die vier Designentscheidungen sind damit hinfällig — ML Kit lädt das Modell on-demand über Google Play Services (~20 MB, kein APK-Bundling), läuft sync inline mit lokaler Inferenz, Server-OCR (EasyOCR) bleibt als Backup. Schließe das Issue.

Obsolet durch ML-Kit-Pivot in v0.6.0 (#423/#424): TrOCR-Stack wurde komplett verworfen (IAM-Korpus-Bias). Die vier Designentscheidungen sind damit hinfällig — ML Kit lädt das Modell on-demand über Google Play Services (~20 MB, kein APK-Bundling), läuft sync inline mit lokaler Inferenz, Server-OCR (EasyOCR) bleibt als Backup. Schließe das Issue.

pm-bot closed this issue 2026-06-06 15:54:17 +02:00

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

Subscribe

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#413

No description provided.