Bon Dossier: drei Versionen, ein intelligentes System zur Belegerkennung auf dem Gerät

"Bon Dossier" wurde nicht schwierig, weil die App eine komplizierte Benutzeroberfläche hatte. Es wurde schwierig, weil die reale Welt feindlich gegen Reinigungsdaten ist. Quittungen sind schmal, gekrümmt, verblasst, gefaltet, fotografiert unter schlechtem Licht, in vielen Sprachen gedruckt, gefüllt mit Steuersumme, Treue-Text, Terminal-Metadaten, Rabatte, Rückerstattungen, Barcode-ähnliche Zahlen und Gesamten, die manchmal über mehrere Linien geteilt werden. Eine einfache OCR Demo kann Text erkennen. Eine Produktions-App muss entscheiden, welcher Text wahr ist.

Das Projekt entwickelte sich daher durch drei praktische Versionen. Es handelt sich nicht nur um Marketing-Veröffentlichungen. Es handelt sich um technische Epochen: zunächst um die Grundlage, dann um die Erkennungsmaschine, dann um die Produktionsplattform. Jede Version löste eine andere Klasse von Problemen und enthüllte jeweils die nächste Komplexität.

Die Anfangsbeschränkung: Privat, lokal und überprüfbar

Die wichtigste architektonische Entscheidung kam vor dem Scanner: ReceiptVault musste nützlich sein, ohne persönliche finanzielle Dokumente auf einen Server hochzuladen. Das schloss den einfachen Weg aus, Bilder an einen Online OCR oder Sprachmodelldienst zu senden. Die Produktions-App würde sich auf Apple Vision, VisionKit, Core ML, Swift Parser und deterministische Validierung verlassen, die alle lokal ausgeführt werden. iCloud könnte das private Archiv des Benutzers synchronisieren, aber es gäbe kein "Bon Dossier" Backend.

Diese Datenschutzbeschränkung formte jeden späteren Prozess. Schulungsdaten wurden als lokales Projektmaterial gehandhabt. Überprüfungskorrekturen wurden als lokale Beispiele gespeichert. Kandidatenmodelle wurden erst nach Berichten und Regressionsprüfungen gefördert. Sogar die Apple Foundation Models-Schicht wurde als optionales lokales Überprüfungspass mit strenger JSON-Schemavalidierung und einem Rückgang zum gebündelten Quittungsmodell entworfen.

Version 1: Die Knochen vor der Kamera aufbauen

Die erste Version war absichtlich unglücklicher. Anstatt mit einem Kamerabildschirm zu beginnen und zu hoffen, dass der Rest folgen würde, begann das Projekt mit einem testablen Swift-Paket namens ReceiptVaultCore. Dieses Paket enthielt das Domain-Modell, den Receipt-Parser, den Kategorisierer, den Duplikatdetektor, den Exportcode und später die meisten der Erkennungs- und Persistenzlogik. Das ursprüngliche Ziel war einfach: das Empfangsdatenmodell ausführbar und testbar zu machen, ohne sich auf den Simulator, die Kameraberechtigungen oder das Live OCR zu verlassen.

Das Kernmodell wuchs um ParsedReceipt: Händler, Adresse, Kaufdatum, Währung, Gesamtzahl, Subtotal, Steuer, Zahlungsmethode, Quittungsnummer, OCR Text, Notizen, Zeilenartikel, Scan-Assets und Überprüfungsstatus. Von dort hinzufügte das Projekt TSV Export, Excel Export, Duplikate-Gruppierung, Kategorie-Entscheidung, Fristerinnerungen und Qualitätsvalidierung.

Das SwiftUI-Shell folgte dem gleichen Prinzip. iPhone verwendete eine Tab-Struktur für Archive, Scan, Insights und Settings. iPad verwendete eine Seitenleiste und ein Split-Navigationsmodell. Ansichten wurden mit Systemcontainern wie TabView, NavigationStack, NavigationSplitView, List und Section statt einem benutzerdefinierten UI-Framework erstellt. Das hielt die App nativ, zugänglich und messbar.

Die erste wichtige Prozessentscheidung: Die App wurde als Produkt kleiner überprüfbarer Schichten behandelt. Domain-Tests kamen vor der Kamera-Integration. Das Parser-Verhalten wurde mit Fixtures eingeschlossen. Das Xcode-Projekt wurde durch Skripte generiert und geschützt. Build- und Testbefehle wurden erfasst, damit das Projekt statt manuell in Xcode reproduziert werden konnte.

Werkzeugverarbeitung in Version 1

• Swift 6 und SwiftPM für das gemeinsame Kernmodul.
• Xcode-Projektgenerierung durch Ruby-Scripts, einschließlich Sicherheitsmaßnahmen zur Quellsynchronisierung.
• XCTest für Parser-, Exporteur-, Archiv- und Quellregressionskontrollen.
• Simulator-Build-Scripts für die Verifizierung von iPhone und iPad.
• Befestigte Empfangsbilder und Textrekonstruktion, um Parser-Änderungen messbar zu machen.
• Ein lebendes Implementierungsstatusdokument, das abgeschlossenen, laufenden und blockierten Arbeiten verfolgt.

Eine frühe Infrastruktur-Hürde war Toolchain-Drift: Die installierte Befehlszeile Swift war nicht immer mit dem Xcode SDK ausgerichtet. Die Workaround war explizit und wiederholbar: verwenden Sie xcrun Swift Test und die Xcode-selektierte Toolchain für Paketbefehle. Das klingt alltäglich, aber es verhinderte, dass falsche Fehler als App-Regressionen maskiert wurden.

Version 2: Von OCR Text bis Empfang Verständnis

Die zweite Version begann, als klar wurde, dass OCR allein nicht das Produkt war. Apple Vision kann viele Zeilen aus einer Quittung lesen, aber es weiß nicht, welche Zahl die endgültige Summe ist, welche Zeile eine Mehrwertsteuerbasis ist, welcher Betrag ein Rabatt ist, welches Datum ein terminaler Zeitstempel ist oder wo der Artikelblock beginnt.

Der Scan-Pfad verwendete VisionKit für die Dokumentenkaptur auf iPhone und iPad, wobei ursprüngliche Scans als Assets erhalten wurden, während OCR und die Verarbeitung gekürzte oder rotierte Versionen verwenden konnten. OCR-Ausgabe wurde Eingabe, nicht Wahrheit. Die anerkannten Linien, Linienboxen, Vertrauenswerte und spätere Dokumentstrukturinformationen wurden einer Hybrid-Pipeline übergeben: Lokale Core ML-Modelle schlugen Rollen und Regionen vor, Swift-Pariser versammelten Kandidaten und deterministische Validiatoren entschieden, welcher Kandidat akzeptabel war.

Dies veränderte das Projekt von einer App mit Parsierungsregeln in ein offline-Maschinenlearning-System. Die Codebase entwickelte Skripte für Bootstrapping-Labels, Trainingslinie-Klassifikatoren, Trainingsdetektor- und Locator-Modelle, die Vorbereitung von YOLO Datensätzen, die Bewertung unsichtbarer Layouts, die Erzeugung von Nichtempfangsnegativen, die Prüfung von Etikettstrukturen, die Ableitung von Fachdatensätzen und die Durchführung von Post-Training-Checks. Die Produktions-App blieb lokal und deterministisch, aber der Entwicklungs-Workflow wurde zu einem Schleier der Messung, Isolierung, Kennzeichnung, Ausbildung, Vergleich und Förderung.

Die Erkennungspipeline

Die wichtigste technische Veränderung: Validierung wurde der Boss

Ein Modell kann vorschlagen. Ein Parsierer kann abschließen. Aber die endgültige Quittung muss ausgeglichen werden. "Bon Dossier" behandelt schließlich die arithmetische Validierung als Torhüter: Postenlinien sollten gegen die endgültige Summe geschlossen werden, Mehrwertsteuer sollte nicht doppelt gezählt werden, Untersumme und Steuergrundlagen sollten nicht über die endgültige Summe gewinnen, und Zahlungs- oder Kartenmetadaten sollten nicht zu Kaufbeträgen werden.

Diese Regel enthüllte subtile Fehler. Für europäische Mehrwertsteuer-Inklusionsrechnungen ist die korrekte Prüfung in der Regel insgesamt == Summe(Elemente), nicht insgesamt == Elemente + Steuer. Letzteres zählt Mehrwertsteuer doppelt und kann genau die falsche Summe segnen.

Weitere Korrekturen waren ebenso konkret: Diskontensummare überwältigten nicht mehr die endgültigen Summen, Spaltenheber wie "Preis" und "Total" verwechselten nicht mehr die Artikelpreise mit den Gutschriften, die Steuersatzreihen konnten nicht mehr über die Zahlungssummen gewinnen und Split-Labels wie "Total" gefolgt von dem Betrag auf der nächsten Zeile erhielten eine spezielle Bearbeitung. Sie waren Korrekturen für das Modell der Realität der App.

Schulungsdaten, ohne uns selbst zu täuschen

Das Projekt verwendete verschiedene Arten von Etiketten, da nicht alle Trainingsnachweise das gleiche Vertrauen verdienen. Handübertragene Etiketten wurden zu Gold. Vision- und App-Backup-Derivierungsbeispiele wurden als Bootstrap- oder Silberdaten behandelt. Handwerkliche Korrekturen wurden als nachverfolgbare Beispiele gespeichert. Die Produktionslinie vermied ausdrücklich das Überschreiben der anerkannten YOLO-Etikette, und die Kandidatenmodelle sollten gegen feste Validierungs- und Prüfspaltungen bewertet werden.

Dies war wichtig, weil Empfangssysteme sehr leicht versehentlich überpassbar sind. Ein dokumentierter Fehler machte die Zonen-Spezialisten-Ausbildung bedeutungslos: Der Spezialisten-Eingang enthielt die Antwort-ähnliche Etikettfunktion, die dem Modell ein künstliches Echo gab. Die Lösung entfernte das geleckte Etikett sowohl aus dem Training als auch aus dem Laufzeit-Eingang und zwang Spezialisten, ihre Punktzahl aus echten Funktionen zu verdienen. Eine weitere Reinigung entfernte Hardcoded Merchant-Abkürzungen und OCR Schreibfehler. Das Ergebnis war ehrlicher und vorübergehend schmerzhafter, aber es machte die verbleibenden Probleme sichtbar, anstatt sie hinter Betrügern zu verstecken.

Repräsentative Modellqualitätszahlen, die während des Aufwands aufgezeichnet wurden

• Ein aktueller Benchmark auf dem Gerät umfasste 728 Quittungen und 35.361 OCR Linien.
• Die überarbeiteten Analyseerwartungen erreichten 545 Übereinstimmungen von 546 überarbeiteten Einrechnungen, wobei eine überarbeitete Datumungleichheit noch sichtbar ist.
• Die Genauigkeit der Linienklassifizierung betrug 96,3 Prozent.
• Die durchschnittliche Parsierungszeit wurde um 47,5 ms aufgezeichnet, wobei die p95 um 81,4 ms auf der lokalen nicht-netzwerklichen Pipeline lag.
• Die Freigabe-Ambition blieb höher als das: Nahezu 99 Prozent Automatisierung erfordert mehr verifizierte reale Quittungen und Artikel-Line-Labels.

Version 3: Verwandeln eines Erkenners in ein Produkt

Die dritte Version handelte über alles, was eine intelligente Engine nutzbar macht: Persistenz, Synchronisierung, Suche, Datei-Import, Backups, Exporte, Einstellungen, Privatsphäre-Manifests, App Store Anmerkungen, Zugänglichkeit, Leistung, Lokalisierung, macOS und Betriebswerkzeuge.

Die Persistenz begann mit einem lokalen JSON-Archiv, weil es einfach, überprüfbar und schnell zu entwickeln war. Das war für die frühe Phase richtig, aber es war nicht genug für ein privates iPhone/iPad-Archiv. Die Produktionsrichtung zog zu einer Repository-Abstraktion mit Core Data als Primärgeschäft und NSPersistentCloudKitContainer für private iCloud-Synchronisierung. Das Design hielt ausdrücklich die ursprünglichen Scan-Assets, Checksums, Miniaturen und Empfangsmetadaten koordiniert, anstatt vorzugeben, dass ein Empfang nur eine Zeile in einer Tabelle ist.

Das Archiv wurde auch mehr als eine Liste. Es übernahm Mail-ähnliche Organisation: Alle Quittungen, Ordner, intelligente Ordner, Flaggen, eingeschränkte Suche, Auswahl, Bewegung Aktionen, Export und Mail Handoff. Import erweitert durch Dateien, Mail, Bilder, PDFs und Text Nutzlasten. App Intents und tiefe Links konnten Benutzer zu Archive, Scan, Insights und Einstellungen weiterleiten. Spotlight- und Share-Extension-Arbeiten ließen die Quittungen sich als Systembürger anfühlen und nicht als eingeschlossenen App-Daten.

Core Data und CloudKit: Die harten Teile waren in Betrieb

Die Core Data-Entscheidung war pragmatisch. SwiftData ist für Prototypen angenehm, aber ReceiptVault benötigte explizite Migrationskontrolle, binäre Asset-Handling, CloudKit-Debugging-Hooks, Konflikt-Handling und Jahre zukünftiger Schema-Evolutions. Core Data gab diese Hebel. Die App konnte immer noch eine saubere Repository-Schnittstelle der Benutzeroberfläche aussetzen, während die Speicherschicht die Migration von JSON-Dateien und die Wiederherstellung fehlender Scan-Dateien behandelte.

Die operativen Risiken waren real. CloudKit-Schema-Initialisierung musste programmatische Einheiten wie Quittungsregister, Scan-Asset-Register, Ordner, Marker und Smart-Ordner umfassen. Leere Schemas führten zu teilweisen Fehlern. Produktionsbuilds benötigten das CloudKit-Schema, das in die Produktionsumgebung befördert wurde. Release-Rechte mussten Produktions-APNs für stille Synchronisierungsbenachrichtigungen verwenden. Das sind keine glamourösen Probleme, aber sie entscheiden, ob Sync für echte Benutzer funktioniert.

Backups, Exporte und Kosten der Original-Scans

"Bon Dossier" Die App fügte TSV-Export, echten XLSX-Export, gefilterte Archiv-Export, ausgewählte Quittungsexport, manuelle Sicherung und Wiederherstellung sowie Sharesheets hinzu. Es behielt auch Original-Scan-Seiten, anstatt nach dem Parsieren Beweise wegzuwerfen. Das ist die richtige Produktentscheidung, aber es schafft Leistung und Speicherarbeit.

Ein Produktions-Audit identifizierte den Kompromiss klar: Die Speicherung von Scanbildern sowohl auf der Festplatte als auch als externen binären Aufzeichnungen Core Data verdoppelt den lokalen Speicherplatz, während voll eingebettete JSON-Backups den Speicher spitzen können, da alle Scan-Bytes gleichzeitig materialisiert werden. Der Lösungsweg war ebenso klar: Bewegen Sie teure Repository- und Backup-Arbeiten vom Hauptthread, streamen Sie oder stücken Sie große Backups, Cache-Tumbnails und prüfen Sie, ob Core Data oder das Dateisystem die einzige Quelle für Scan-Bytes ist.

Die macOS Version war kein Zuschauer

Der macOS-Plan war absichtlich ehrgeizig: kein nur-lesen-Companion, sondern ein nativer Desktop ReceiptVault, der das gleiche private iCloud-Archiv und die gleiche Kernlogik teilt. Das Mac-Ziel verwendet den geteilten Kern, OCR/ML-Pipeline, Archive, Export, Backup und Synchronisierungslogik, während die Präsentation, Befehle, Datei-Import und Kamera-Fassung für macOS-Konventionen angepasst werden.

Dazu fügte eine weitere Schicht von Werkzeugen hinzu: macOS-Rechte, App Sandbox, vom Benutzer ausgewählte Dateienzugriff, Kamera-Privatsphäre-Strings, Menübefehle, Kontinuitätskamera-Planung, native Import-Panels und App Store-Multi-Plattform-Release-Überlegungen. Es bewies auch den Wert, ReceiptVaultCore von den App-Shells getrennt zu halten.

Die Ingenieurprozesse hinter dem Werk

Das Projekt überlebte, weil es nicht als ein riesiger Ausbruch von Feature-Arbeit ausgeführt wurde. Es verwendete Schichtenlieferung, Quell-Audits, lokale Skripte, Fixtures, Modellberichte und dokumentierte Tore. Einige der wichtigsten Assets waren nicht Benutzer-ausgerichtete Bildschirme. Es waren die Skripte und Berichte, die das Werk messbar machten.

Vertretende Werkzeuge und Techniken

• Swift und SwiftUI: Appshells für iPhone, iPad und macOS, mit nativen Listen, Split Views, Einstellungen und Share-Flows.
• SwiftPM: ein gemeinsames Kernmodul und ML-Tools, die ausführbar sind, um die Geschäftslogik außerhalb des App-Ziels zu testen.
• XCTest: Parser-, Archiv-, Backup-, Export-, Lokalisierungs-, Quellschutz-, App-Absicht- und ML-Vertragstests.
• Apple Vision und VisionKit: Scan-Erfassung, OCR, Liniengeometrie und Dokument-Struktur-Extraktion.
• Core ML und Erstellen ML: Empfängerdetektor, Lokalisator, Klassifizierer, Feldranger und lokale Rollenmodelle.
• YOLO und Ultralytik: Layout-Regionen-Experimente, Zonen-Etiketten und Exportmodelle für Zulassungspapier- und Inhaltsregionen.
• Python, Swift und Ruby-Skripte: Vorbereitung von Datensätzen, Projektgenerierung, Modellbildung, Audits, Berichte und Ressourcen-Synchronisierung.
• Core Data und CloudKit: private synchronisierte Archivspeicherung, Migration von JSON und Scan-Asset-Spiegelung.
• KryptoKit: SHA-256-Checksumsum für die Scan-Asset-Integrität und einen zukünftigen Weg für verschlüsselte Backups.
• Integration von App-Ökosystemen: Teilen Erweiterung, Dokumentenimport, App Intents, tiefe Links, Spotlight-Aufzeichnungen, Mail-Stil-Export und manuelle Backups.

Die Hindernisse und ihre Lösungen

Was es zu einem Herkulesischen Ingenieurversuch gemacht hat

Der schwierige Teil war nicht ein Algorithmus. Es war die Anzahl der Grenzen, die alle gleichzeitig halten mussten. Ein Scan musste zu einem OCR Ergebnis werden. Das OCR Ergebnis musste zu einer Quittung werden. Die Quittung musste durchsuchbar, exportierbar, synchronisierbar, wiederherstellbar und erklärbar werden. Das Erkennungssystem musste sich verbessern, ohne private Daten zu verbreiten oder von einem Server abhängig zu sein. Die Benutzeroberfläche musste natürlich und ruhig bleiben, während die Pipeline unterhalb arbeitete, die näher an der Forensik als an der Formularanalyse lag.

Jede Version ließ die vorherige Version kleiner aussehen. Version 1 bewies, dass die App als ein sauberes Swift-Produkt existieren konnte. Version 2 bewies, dass das Empfangsverständnis eine echte lokale ML- und Validierungspipeline benötigte. Version 3 bewies, dass ein Erkennungsgerät kein Produkt ist, bis die Persistenz-, Synchronisierung-, Import-, Export-, Privatsphäre-, Performance- und Release-Operationen vertrauenswürdig sind.

Die Codebase enthält nun die Form dieser Reise: ein geteiltes Kernmodul, eine App-Shell, Scanner-Dienste, Archivansichten, Core Data-Repositories, CloudKit-Konfiguration, ML-Kontrakte, Modell-Cache, Trainingsscripts, Produktionslinienläufer, App-Shop-Dokumentation, Leistungsprüfungen und Dutzende fokussierter Tests. Das Ergebnis ist kein dünner Umschlag um OCR. Es ist eine On-Device-Receipt-Intelligence-Plattform, die den Unterschied zwischen Text und Beweis lernen musste.

Lehren für ähnliche Projekte

1. Beginnen Sie mit einem testbaren Kern. Die Kamera und OCR sind laut.
2. Behandeln Sie OCR als Beweis, nicht als Ausgabe. Geometrie, Vertrauen, Layout und Quittungsmathematik sind Teil der Wahrheit.
3. Abgesonderter Modellvorschlag von der Produktakzeptanz. Die deterministische Validierung sollte entscheiden, ob eine Analyse gut genug ist.
4. Lassen Sie sich die Ausbildungswerte nicht zum Theater verwandeln. Schutz vor Leckagen, Hardcoded-Abkürzungen und Validierungs-Set-Verunreinigung.
5. Planen Sie die Vermögenswerte frühzeitig. Originalbilder ändern die Speicher-, Sicherungs-, Synchronisierungs- und Leistungsarchitektur.
6. Überprüfen Sie die Produktionskonfiguration als Code. Ansprüche, Datenschutzerklärungen und CloudKit-Schemen sind Teil der App.
7. Halten Sie die plattformspezifische Benutzeroberfläche dünn. Ein gemeinsamer Kern machte iPhone, iPad und macOS möglich, ohne das Empfangs-Gehirn zu duplizieren.

Die Entwicklungsgeschichte von Bon Dossier ist eine Erinnerung daran, dass ernsthafte lokale Intelligenz kein einziges Merkmal ist. Es ist eine Vertrauenskette: Erfassen, OCR, Layout, Klassifizierung, Parsieren, Validierung, Beharrlichkeit, Synchronisierung, Export und Freigabe Disziplin. Brechen Sie einen Link und der Benutzer sieht das gesamte System als falsch. Stärken Sie jeden Link und eine chaotische Papierkosten wird zuverlässige private Daten.