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

New issue

Closed

opened 2026-05-28 06:39:39 +02:00 by pm-bot · 1 comment

pm-bot commented

2026-05-28 06:39:39 +02:00

Collaborator

Ziel

Die Spike-CER-Messung (0.043 case-folded, #77) lief auf synthetisch gerenderten 20-Crops mit varied fonts/sizes/rotation. Vor Production-Rollout (#82) müssen wir auf echten Einkaufszettel-Crops messen.

Datenquelle

Server-OCR sammelt Korrektur-Sessions im Volume /training_data (Container apps/ocr/), per apps/ocr/app/ocr.py:230 _save_training_session(). Jede Session hat \n- Original-Crops\n- Korrigierte Ground-Truth-Lines\n\nDamit existiert bereits ein wachsender Real-World-Datensatz.

Scope

Export aller /training_data/-Sessions (read-only Pull vom prod-alt OCR-Container)
Anonymisierung-Check (keine PII auf Quittungen — Adressen, Kreditkartennummern maskieren falls vorhanden)
CER-Messung mit measure_cer.py (3 Varianten: TrOCR-int8 / TrOCR-fp32 / Server-Baseline)
Pro Aufnahme-Bedingung (gute/schlechte Beleuchtung, gerade/schief, Druck/Handschrift) auswerten
Go/No-Go: Wenn CER >0.15 auf realen Daten → Finetune-Story oder Modell-Swap (z.B. TrOCR-base-printed mit größerem Bundle)

Definition-of-Done

Real-World-Eval-Set extrahiert + anonymisiert
CER pro Variante + Aufnahme-Kategorie dokumentiert
Entscheidung: TrOCR-small-printed ausreichend / Finetune nötig / Modell-Swap
Bei Finetune-Bedarf: Folgestory mit Trainings-Pipeline

Referenzen

Parent-Spike: #77
Architecture-Reconciliation: #413, #77#issuecomment-2688
Blockiert: #82 (Production-Rollout sollte auf gemessene Real-World-CER warten)

## Ziel Die Spike-CER-Messung (0.043 case-folded, #77) lief auf synthetisch gerenderten 20-Crops mit varied fonts/sizes/rotation. Vor Production-Rollout (#82) müssen wir auf echten Einkaufszettel-Crops messen. ## Datenquelle Server-OCR sammelt Korrektur-Sessions im Volume `/training_data` (Container `apps/ocr/`), per `apps/ocr/app/ocr.py:230` `_save_training_session()`. Jede Session hat \n- Original-Crops\n- Korrigierte Ground-Truth-Lines\n\nDamit existiert bereits ein wachsender Real-World-Datensatz. ## Scope 1. Export aller `/training_data/`-Sessions (read-only Pull vom prod-alt OCR-Container) 2. Anonymisierung-Check (keine PII auf Quittungen — Adressen, Kreditkartennummern maskieren falls vorhanden) 3. CER-Messung mit `measure_cer.py` (3 Varianten: TrOCR-int8 / TrOCR-fp32 / Server-Baseline) 4. Pro Aufnahme-Bedingung (gute/schlechte Beleuchtung, gerade/schief, Druck/Handschrift) auswerten 5. Go/No-Go: Wenn CER >0.15 auf realen Daten → Finetune-Story oder Modell-Swap (z.B. TrOCR-base-printed mit größerem Bundle) ## Definition-of-Done - [ ] Real-World-Eval-Set extrahiert + anonymisiert - [ ] CER pro Variante + Aufnahme-Kategorie dokumentiert - [ ] Entscheidung: TrOCR-small-printed ausreichend / Finetune nötig / Modell-Swap - [ ] Bei Finetune-Bedarf: Folgestory mit Trainings-Pipeline ## Referenzen - Parent-Spike: #77 - Architecture-Reconciliation: #413, #77#issuecomment-2688 - Blockiert: #82 (Production-Rollout sollte auf gemessene Real-World-CER warten)

pm-bot added the

app/einkaufslisten

area/mobile

type/feature

labels

2026-05-28 06:39:39 +02:00

pm-bot referenced this issue

2026-05-28 06:48:27 +02:00

Portfolio-Status KW 2026-W22 #412

pm-bot commented

2026-05-28 12:22:24 +02:00

Author

Collaborator

Real-Data-Eval abgeschlossen

77 echte Crops aus 5 corrected sessions aus /training_data (prod-alt OCR-Container).

Metrik	Synthetic (Tag-5)	Real (this eval)
TrOCR-int8 mean CER	0.043	0.510
Acceptable (CER≤0.15)	~85%	9%
Exact-match	n/a	7% (5/76)

EasyOCR-Baseline: CER 0.670 (TrOCR ist besser, aber beide weit unter Brauchbarkeit).

Befund: TrOCR-small-PRINTED kann keine Handschrift. Best-Performers (BLOCK, SOCKEN, KISSEN, HUT, RUCOLA) sind alles gedruckte Items; Worst-Performers sind handgeschriebene Einkaufszettel-Einträge wo das Modell plausible englische Druckschrift halluziniert (Hund → REHOL, Knoblauch → LABELEL).

Konsequenz: v0.5 pivotet auf Fuzzy-Match #415 als Hauptpfad statt On-Device-OCR-Optimierung. Closing-Cascade #77/#81/#82/#414 in den nächsten Comments.

Eval-Skript + Daten auf dev-neu: /root/ocr-spike/measure_cer_real.py + /root/ocr-spike/real-eval/.

## Real-Data-Eval abgeschlossen 77 echte Crops aus 5 corrected sessions aus `/training_data` (prod-alt OCR-Container). | Metrik | Synthetic (Tag-5) | Real (this eval) | |---|---|---| | TrOCR-int8 mean CER | 0.043 | **0.510** | | Acceptable (CER≤0.15) | ~85% | **9%** | | Exact-match | n/a | 7% (5/76) | **EasyOCR-Baseline:** CER 0.670 (TrOCR ist besser, aber beide weit unter Brauchbarkeit). **Befund:** TrOCR-small-PRINTED kann keine Handschrift. Best-Performers (`BLOCK`, `SOCKEN`, `KISSEN`, `HUT`, `RUCOLA`) sind alles gedruckte Items; Worst-Performers sind handgeschriebene Einkaufszettel-Einträge wo das Modell plausible englische Druckschrift halluziniert (`Hund → REHOL`, `Knoblauch → LABELEL`). **Konsequenz:** v0.5 pivotet auf **Fuzzy-Match #415 als Hauptpfad** statt On-Device-OCR-Optimierung. Closing-Cascade #77/#81/#82/#414 in den nächsten Comments. Eval-Skript + Daten auf dev-neu: `/root/ocr-spike/measure_cer_real.py` + `/root/ocr-spike/real-eval/`.

pm-bot closed this issue

2026-05-28 12:22:25 +02:00

pm-bot referenced this issue

2026-05-28 12:22:52 +02:00

feat(mobile): On-Device OCR-Pipeline zusammenführen + Server-Fallback #82

pm-bot referenced this issue

2026-05-28 12:22:53 +02:00

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

pm-bot referenced this issue

2026-05-28 12:22:55 +02:00

spike(mobile): CRAFT-Line-Detection on-device — ONNX-Export + RN-Integration #414

pm-bot referenced this issue