chore(mobile): On-Device OCR Benchmarking & Qualitätsmessung #83

New issue

Closed

opened 2026-04-26 09:12:09 +02:00 by admin-mrrm · 2 comments

admin-mrrm commented

2026-04-26 09:12:09 +02:00

Owner

Ziel

Ergebnisqualität und Performance von On-Device vs. Server systematisch messen und dokumentieren.

Aufgaben

Test-Dataset

10–20 Fotos von handschriftlichen Einkaufslisten sammeln (verschiedene Handschriften, Lichtverhältnisse, Winkel)
Ground-Truth-Texte manuell erfassen

Metriken

CER (Character Error Rate): edit_distance(predicted, ground_truth) / len(ground_truth)
WER (Word Error Rate): analog auf Wortebene
Inferenzzeit: Gesamt und pro Zeile
Modellgröße: Download-Größe, RAM-Verbrauch

Vergleich

Metrik	Server (base)	On-Device (small)	On-Device (base)
CER	?	?	?
WER	?	?	?
Zeit	60–120 s	~5–10 s	~15–25 s
Offline	✗	✓	✓

Skript

tools/benchmark-ocr.py – führt alle Varianten auf dem Test-Dataset aus und gibt Tabelle aus

Akzeptanzkriterien

Benchmark-Tabelle in der Issue-Kommentaren dokumentiert
Entscheidung: Welches Modell wird als Default für On-Device empfohlen?

## Ziel Ergebnisqualität und Performance von On-Device vs. Server systematisch messen und dokumentieren. ## Aufgaben ### Test-Dataset - [ ] 10–20 Fotos von handschriftlichen Einkaufslisten sammeln (verschiedene Handschriften, Lichtverhältnisse, Winkel) - [ ] Ground-Truth-Texte manuell erfassen ### Metriken - [ ] **CER** (Character Error Rate): `edit_distance(predicted, ground_truth) / len(ground_truth)` - [ ] **WER** (Word Error Rate): analog auf Wortebene - [ ] **Inferenzzeit**: Gesamt und pro Zeile - [ ] **Modellgröße**: Download-Größe, RAM-Verbrauch ### Vergleich | Metrik | Server (base) | On-Device (small) | On-Device (base) | |--------|--------------|-------------------|------------------| | CER | ? | ? | ? | | WER | ? | ? | ? | | Zeit | 60–120 s | ~5–10 s | ~15–25 s | | Offline| ✗ | ✓ | ✓ | ### Skript - [ ] `tools/benchmark-ocr.py` – führt alle Varianten auf dem Test-Dataset aus und gibt Tabelle aus ## Akzeptanzkriterien - [ ] Benchmark-Tabelle in der Issue-Kommentaren dokumentiert - [ ] Entscheidung: Welches Modell wird als Default für On-Device empfohlen?

admin-mrrm added this to the v0.5 — On-Device OCR + Infra milestone

2026-04-26 09:12:09 +02:00

admin-mrrm added the

app/einkaufslisten

area/mobile

type/chore

labels

2026-04-26 22:59:16 +02:00

pm-bot commented

2026-05-25 22:30:22 +02:00

Collaborator

QA: Akzeptanzschwellwerte vor Implementierung festlegen

QA-Hut, gepostet via pm-bot.

Dieser Benchmarking-Chore ist der richtige Ort, um harte Schwellwerte für "OCR ist gut genug" zu definieren — bevor #82 (On-Device-Pipeline), #80 (TrOCR-Tokenizer in JS), #81 (Preprocessing), #326 (Crop), #327 (Boxen-Korrektur) gebaut werden. Sonst gibt's später Endlosdiskussionen darüber, was "funktioniert" eigentlich heißt.

Vorschlag — Schwellwerte die hier definiert werden sollten

Erkennungs-Qualität (auf einem fixierten Test-Set):

Zeichenfehlerrate (CER): Schwellwert? Vorschlag < 5% für On-Device-Akzeptanz
Wortfehlerrate (WER): Vorschlag < 10%
Server-Fallback-Trigger: ab welcher Modell-Konfidenz fällt der Client auf Server-OCR (#82) zurück? Konkreter Schwellwert nötig.

Performance (Referenz-Gerät benennen — z.B. "Pixel 6 als Mid-Range"):

Latenz pro Bild P50 / P95: Budget? Vorschlag P95 < 3s
Speicher-Footprint des ONNX-Modells: Maximalgröße? Vorschlag < 50 MB (APK-Bloat-Limit)
RAM-Peak während Inferenz: relevant für ältere Geräte?

Test-Setup:

Goldenes Testset (Bilder + erwartete Texte) im Repo, versioniert
Reproduzierbarer Bench-Lauf (Skript), CI optional aber Pflicht für lokale Verifizierung
Ergebnisse dokumentiert pro Modell-Variante (TrOCR base/quantisiert)

Warum jetzt entscheiden

#79 (EAS-Integration) und #78 (ONNX-Export/Quantisierung) brauchen die Größen-/Latenz-Targets, um Modell-Variante zu wählen
#82 (Server-Fallback) braucht den Konfidenz-Trigger als Implementierungs-Input
Ohne Schwellwerte ist "Epic done" nicht entscheidbar → Risiko: Feature wird gebaut, ist subjektiv "so lala", niemand will Verantwortung für Cut-Off übernehmen

Soll ich daraus ein eigenes Spike-/Decision-Issue machen, oder bleibt das in #83 als Vor-Arbeit dokumentiert?

## QA: Akzeptanzschwellwerte **vor** Implementierung festlegen _QA-Hut, gepostet via pm-bot._ Dieser Benchmarking-Chore ist der richtige Ort, um harte Schwellwerte für "OCR ist gut genug" zu definieren — bevor #82 (On-Device-Pipeline), #80 (TrOCR-Tokenizer in JS), #81 (Preprocessing), #326 (Crop), #327 (Boxen-Korrektur) gebaut werden. Sonst gibt's später Endlosdiskussionen darüber, was "funktioniert" eigentlich heißt. ### Vorschlag — Schwellwerte die hier definiert werden sollten **Erkennungs-Qualität (auf einem fixierten Test-Set):** - Zeichenfehlerrate (CER): Schwellwert? Vorschlag `< 5%` für On-Device-Akzeptanz - Wortfehlerrate (WER): Vorschlag `< 10%` - Server-Fallback-Trigger: ab welcher Modell-Konfidenz fällt der Client auf Server-OCR (#82) zurück? Konkreter Schwellwert nötig. **Performance (Referenz-Gerät benennen — z.B. "Pixel 6 als Mid-Range"):** - Latenz pro Bild P50 / P95: Budget? Vorschlag `P95 < 3s` - Speicher-Footprint des ONNX-Modells: Maximalgröße? Vorschlag `< 50 MB` (APK-Bloat-Limit) - RAM-Peak während Inferenz: relevant für ältere Geräte? **Test-Setup:** - [ ] Goldenes Testset (Bilder + erwartete Texte) im Repo, versioniert - [ ] Reproduzierbarer Bench-Lauf (Skript), CI optional aber Pflicht für lokale Verifizierung - [ ] Ergebnisse dokumentiert pro Modell-Variante (TrOCR base/quantisiert) ### Warum jetzt entscheiden - #79 (EAS-Integration) und #78 (ONNX-Export/Quantisierung) brauchen die Größen-/Latenz-Targets, um Modell-Variante zu wählen - #82 (Server-Fallback) braucht den Konfidenz-Trigger als Implementierungs-Input - Ohne Schwellwerte ist "Epic done" nicht entscheidbar → Risiko: Feature wird gebaut, ist subjektiv "so lala", niemand will Verantwortung für Cut-Off übernehmen Soll ich daraus ein eigenes Spike-/Decision-Issue machen, oder bleibt das in #83 als Vor-Arbeit dokumentiert?

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:57:46 +02:00

Collaborator

Die generische Idee „Qualitätsmessung" bleibt valide, aber mit komplett anderem Scope (z.B. Fuzzy-Match-History-Hit-Rate, ML-Kit-Genauigkeit unter realen Handschriften, Curation-Wirkung in Lines-Review). Falls konkret nötig: neues Issue mit aktuellem Scope aufmachen, dieses hier schließe ich nachträglich.

Obsolet durch ML-Kit-Pivot in v0.6.0 (#423/#424): Der Scope dieses Issues (TrOCR-small vs TrOCR-base vs Server) ist hinfällig — wir haben nur noch ML Kit on-device + EasyOCR als Server-Backup, keine Modellwahl mehr. Die generische Idee „Qualitätsmessung" bleibt valide, aber mit komplett anderem Scope (z.B. Fuzzy-Match-History-Hit-Rate, ML-Kit-Genauigkeit unter realen Handschriften, Curation-Wirkung in Lines-Review). Falls konkret nötig: neues Issue mit aktuellem Scope aufmachen, dieses hier schließe ich nachträglich.

pm-bot closed this issue

2026-06-06 15:57:46 +02:00

No milestone

No project

No assignees

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

No description provided.

Rows
Columns