OCR-Belegscanner: 97,78% Konfidenz, drei Phasen, eine Session

Das Problem

Das Nebenprojekt: eine Web-App, bei der Nutzer Kassenbelege fotografieren und Cashback-Belohnungen für qualifizierende Einkäufe bekommen. Das Feature: Dual-Foto-Upload. Ein Foto des Belegs. Ein Foto des Produkts. Beide erforderlich. Beide verarbeitet. Cashback ausgelöst, wenn beide verifiziert sind.

Der Ansatz: drei Phasen, sequenziell verifiziert

Ich strukturiere KI-gebaute Features in Phasen statt "bau das Ganze." Jede Phase hat einen klaren Output, und du verifizierst ihn, bevor du zur nächsten gehst.

Phase 1: Datenbankschema. Neue Tabellen und Spalten zum Speichern von zwei Bildern pro Einreichung. Der Agent übernahm das Schema-Design. Ich reviewte die Migration.

Phase 2: Backend-API. Endpoints aktualisiert für zwei Dateien. OCR-Pipeline speziell auf das Belegbild verdrahtet, nicht auf beide.

Phase 3: Frontend-UI. Zwei Upload-Zonen. Preview-States für beide Bilder. Der vollständige User-Flow.

Fünf kritische Bugs

Keiner davon wäre von Unit-Tests mit synthetischen Daten gefunden worden.

Bug 1: Bild-Dekompression (erschien dreimal). Die Vision-API erfordert rohe Bild-Bytes. Die Upload-Pipeline komprimierte Bilder mit gzip. Kleine Testbilder komprimieren kaum, also bestanden Tests. Echte Kamerabilder in voller Auflösung produzierten vollständige Fehler. Der Fehler erschien dreimal, weil es drei separate Code-Pfade gab, die Bilder verarbeiteten.

Bug 2: OCR-Aggregations-Scope. Produktfotos wurden neben Belegfotos an die OCR-Pipeline übergeben. Das Modell versuchte, Text aus einem Foto einer Shampooflasche zu lesen und mischte ihn in die Belegdaten.

Bug 3: FormData-Feld-Reihenfolge. Das Backend erwartete Belegfoto zuerst, Produktfoto zweites. Auf Desktop-Browsern war die Reihenfolge korrekt. Auf mobilen Browsern mit bestimmten Bildquellen kehrte sie sich um. Der Cashback-Einreichung würde erfolgreich sein, aber das Produktfoto als Beleg verarbeiten.

Bugs 4 und 5 waren Validierungs-Edge-Cases: spezifische Bildabmessungen und Dateigrößenkombinationen, die einen Fehlerpfad auslösten, den das Frontend nicht behandelte.

Das Ergebnis

Nach allen fünf Fixes testete ich mit einem echten Belegfoto: die Art zerknittertes, leicht überbelichtetes, unter einem Winkel aufgenommenes Foto, das echte Nutzer einreichen.

OCR-Konfidenz: 97,78%.

Nicht ein Testbild. Nicht ein PDF. Ein echter Beleg, mit einem Handy fotografiert, unter Küchenbeleuchtung. Textextraktion akkurat. Einzelposten stimmten. Gesamtbetrag korrekt.

Was das für dein Team bedeutet

Die Lektion aus dieser Case Study ist nicht "KI baut Features schnell." Die Lektion handelt von der Lücke zwischen "es funktioniert" und "es funktioniert für echte Nutzer."

KI baut schnell. Schnell bedeutet, du erreichst diese Lücke schneller. Die Bugs verschwinden nicht. Sie kommen früher an. Teste mit echten Daten, echten Geräten, echten Nutzereingaben, so früh wie möglich.