Persönliches Projekt
Money Tracker
Ausgabenverwaltung in natürlicher Sprache mit deterministischen Regeln, begrenzten KI-Workflows und lokalem Dashboard.
Wie ich einen KI-Assistenten an Finanzregeln gebunden habe
Money Tracker ist ein persönlicher Finanzassistent mit lokalem Schwerpunkt. Ich definierte Produktausrichtung und Architektur und nutzte Coding-Agenten bei der Umsetzung. Die zentrale Frage war, wie aus einer unsicheren Interpretation eine geprüfte und autorisierte Finanzoperation wird.
- Python
- LangChain / LangGraph
- llama.cpp
- PostgreSQL
- FastAPI / React
- Langfuse
- Restic
Eine Finanzdomäne, zwei Oberflächen
Telegram und das lokale Dashboard verwenden dieselben Anwendungsdienste und maßgeblichen Finanzdaten. Das Modell interpretiert Anfragen; die Domäne kontrolliert Buchungen. Das Diagramm fasst implementierte Komponenten und Zuständigkeiten zusammen.
Externer Dienst
Lokaler Rechner
Einblick in LangGraph
Fünf getrennt kompilierte Graphen. Ein externer typisierter Dispatcher koordiniert Routing, Spezialistenaufrufe und die Fortsetzung der Kategorieprüfung.
Hauptrouter Typisierter Dispatcher Ausgabe / Erstattung / Abfragen / Empfehlungen / Kategorieprüfung / Korrektur / Storno / Bestätigung
- Modellaufruf
- Deterministischer Knoten
- Regeln + optionaler Modellaufruf
- Bedingte Kante
Hauptrouter
Ausgabe / Erstattung
Abfragen / Empfehlungen
Kategorieprüfung
Die Schleife führt über eine Eigentümerentscheidung und einen persistenten Checkpoint. Ein neuer Vorschlag kann das Modell in settle_review aufrufen; dies ist kein zusätzlicher Graphknoten.
Korrektur / Storno / Bestätigung
Storno und Bestätigung nutzen vertrauenswürdige Referenzen ohne Modellaufrufe. Nur Korrektur verwendet Extraktion und Klassifizierung.
Das Modell schlägt vor; Anwendungsregeln prüfen. Entwürfe brauchen eine Bestätigung vor der endgültigen Buchung. Abfragen, Kategorieprüfung und Änderungen verwenden separate Graphen.
llama.cpp liefert lokale Inferenz für die Workflows.
Langfuse beobachtet Modellaufrufe lokal; es ist optional und von den maßgeblichen Finanzdaten getrennt.
Von der Nachricht zur überprüfbaren Operation
Das Gateway speichert autorisierte Eingaben vor dem Fortschreiben des Polling-Offsets. Ein separater Worker verarbeitet Nachrichten in Reihenfolge; langsame Inferenz blockiert den Empfang nicht.
- 1Autorisieren und speichern
- 2Absicht routen
- 3Einen Spezialisten ausführen
- 4Antwort rendern und einreihen
Ausgabe / Korrektur
Typisierte Extraktion → Domänenvalidierung → autorisierter, idempotenter Schreibvorgang. Kategorievorschläge warten auf eine ausdrückliche Eigentümerentscheidung.
Frage / Beratung
Nur lesende Werkzeuge → deterministische Aggregate → Modellantwort. Dieser Pfad besitzt keine Werkzeuge für Finanzschreibvorgänge.
Entscheidungen und Kompromisse
- Begrenzte Graphen und expliziter Dispatcher
Separate Verträge halten Profil, Zeit und Aktionsreferenzen im vertrauenswürdigen Laufzeitkontext.
Eine neue Absicht braucht einen expliziten Zweig und ein Schema. Überprüfbare Befugnisse erfordern mehr Orchestrierungscode.
- Anwendungs-PostgreSQL und Inbox/Outbox
Finanzschreibvorgänge, Befehlsidentitäten und Audit sind transaktional. Nachrichten überstehen Neustarts.
Wiederholungen können nachfolgende Nachrichten verzögern. Telegram-Antworten können doppelt eintreffen; Idempotenz schützt den Finanzschreibvorgang.
- Lokale Inferenz und Telegram-Transport
Inferenz und Finanzdaten bleiben lokal. Long Polling vermeidet einen öffentlichen Eingangsendpunkt.
Der Rechner muss zur Verarbeitung verfügbar sein. Telegram bleibt eine externe Grenze; die gesamte Interaktion ist nicht vollständig lokal.
- Versionierte Evaluationskriterien
Datensätze, deterministische Prüfer und Run-Manifeste verbinden die akzeptierte Konfiguration mit Modell-, Prompt-, Schema- und Werkzeugversionen.
Modell- oder Promptwechsel brauchen gezielte Regressionen. Eine plausible Antwort oder ein Konfidenzwert reicht nicht als Nachweis.
So kann eine Interaktion aussehen
Schematische Darstellung, keine exakte Reproduktion der aktuellen Oberfläche. Beträge, Kategorien und Texte sind erfunden. Das Finanzmodell unter dem Dialog erklärt die beiden Abgleiche.
Today I spent €36 — €28 on groceries and €8 on household items. I paid with €12 in vouchers and €24 by card.
Expense draft · €36.00
Groceries €28.00 · Household €8.00
Vouchers €12.00 · Card €24.00
Waiting for your confirmation.
Ein Kauf, zwei unabhängige Aufteilungen
Kategorien beschreiben den Verwendungszweck; Zahlungsquellen beschreiben die Bezahlung. Beide Aufteilungen ergeben den Gesamtbetrag. Berichte aggregieren die passende Dimension, ohne den Kauf doppelt zu zählen.
EUR · 3600Nach Kategorie
Lebensmittel€28.00
Haushalt€8.00
Nach Zahlungsquelle
Gutscheine€12.00
Karte€24.00
28 + 8 = 36 · 12 + 24 = 36
- EUR-Beträge verwenden ganze Cent: 36,00 € wird als 3600 gespeichert, ohne binäre Gleitkommaarithmetik für Geld.
- Korrekturen ersetzen ein validiertes Aggregat und erzeugen ein Audit-Ereignis. Rückgängigmachen annulliert den Vorgang, ohne die Historie zu löschen.
Das Dashboard macht die Domäne sichtbar
Die implementierte React-Oberfläche umfasst Monatsübersicht, Transaktionsverwaltung und Kategoriebudgets. Diese zwei schematischen Beispiele verwenden einen konsistenten fiktiven Datensatz. Die illustrative Demo wird auf Englisch gezeigt; die aktuelle Anwendung verwendet Italienisch.
Dashboard-Simulation · fiktive Daten · keine Screenshots
Monatsübersicht
Where your money is going
Posted transactions only · 3 fictitious transactions
- Net spending
- €120.00
- Personal funds
- €108.00
- Benefits
- €12.00
Monthly budgets
Posted spending / monthly target
Transaktionsdetail
Example purchase
Posted€36.00Categories
Groceries€28.00
Household€8.00
Total €36.00 · reconciled
Payment sources
Vouchers€12.00
Card€24.00
Total €36.00 · reconciled
Wie die Modellexperimente abliefen
Ich behandelte die Modellwahl als Folge überprüfbarer Experimente für den lokalen Workload. Sechs Modelle wurden mit Text- und gegebenenfalls Vision-Profilen untersucht. Die Nachweise unterscheiden Protokolltests, einzelne Werkzeugexperimente, vollständige Workflow-Evaluationen und eine ausdrückliche Freigabeentscheidung.
Vom ersten Test zur beibehaltenen Baseline
1.–2. Sept. 2026
Lokale Schnittstellen prüfen
Fixierte quantisierte Gewichte und llama.cpp, 8.192 Tokens Kontext und ein Inferenzslot. Geprüft wurden strukturierte Ausgabe, Werkzeugaufrufe, Fortsetzung nach Werkzeugergebnissen und Bildtransport. Bestehen erlaubte weitere Tests, bewies aber keine finanzielle Genauigkeit.
3. Sept. 2026
Aus Fehlern neue Tests ableiten
Qwen3 14B füllte im Text nicht angegebene Felder. Der erweiterte Test trennte Auslassen optionaler Felder und Union-Ausgabe. Auslassen scheiterte, Unions funktionierten und motivierten explizitere Modellverträge.
8. Sept. 2026
Verträge und Nachweise korrigieren
Schemas, Prompts und Entwicklungslabels wurden mit dokumentierten Gründen versioniert. Berichte wurden so korrigiert, dass fehlgeschlagene oder ungemessene Pflichtkriterien keinen Erfolg ergeben. Weitere Textprofile und Werkzeugtests erweiterten den Vergleich.
9. Sept. 2026
Eine vollständige Konfiguration freigeben
Nach deterministischer Korrektur der Leseauswahl und Beratungssichtung durch den Eigentümer bestand Qwen3 14B alle anwendbaren Pflichtkriterien. EVD-004 fixierte Modell, Prompts, Schemas und Richtlinie. Schwellen blieben gleich; automatisches Buchen blieb deaktiviert.
10. Sept. 2026
Den größeren Kandidaten prüfen
Qwen3.8 27B wurde nach dem Nachweis lokaler Lauffähigkeit gemessen. Die Kategorisierung wurde besser, Anforderungen für Routing, Werkzeuge und Beratung blieben offen. Das Modell blieb experimentell; die freigegebene Baseline blieb bestehen.
Alle Modelle und der Umfang ihrer Nachweise
| Modell / Quantisierung | Durchgeführte Experimente | Beobachtetes Ergebnis | Entscheidung |
|---|---|---|---|
| GPT-OSS 20BMXFP4 | Erster Textprotokolltest; späteres Werkzeugauswahlexperiment. | Strukturierte Endausgabe und Fortsetzung nach Werkzeugergebnis scheiterten zunächst. Auch der spätere Werkzeuglauf bestand die Kriterien nicht. | Nicht freigegeben |
| Qwen3 14BQ5_K_M | Texttests, Auslassungs-/Union-Tests, Vertragsiteration und alle Text-Workflow-Suiten. | Anfängliche Auslassungsgrenzen bleiben dokumentiert. Angepasste Anwendungsverträge und Leserichtlinie bestanden alle anwendbaren Produktkriterien. | Freigegebene Text-Baseline |
| Ministral 3 14BQ5_K_M | Vision-Tests und Text-Workflow-Vergleiche. | Die Fortsetzung nach Werkzeugergebnis scheiterte zunächst. Später scheiterten Extraktion und weitere Kriterien; der Eigentümer beendete den finalen Vergleich nach dem Ingestion-Fehler. | Nicht freigegeben |
| Qwen3.5 9BUD-Q5_K_XL | Vision-Protokolltest; erweiterte Textfähigkeiten und Workflow-Durchlauf. | Fähigkeitstests bestanden in den gemessenen Versionen. Textextraktion bestand, Routing, Kategorien, Werkzeuge und Beratung bestanden nicht alle Kriterien. | Experimentell; Vision für spätere Belege behalten |
| Gemma 4 12BQAT Q4_0 | Vision-Protokolltest; einzelnes Text-Werkzeugauswahlexperiment. | Vision-Transport und Protokoll bestanden. Der Text-Werkzeugtest scheiterte; ein vollständiger Textvergleich ist nicht dokumentiert. | Experimentell; Vision für spätere Belege behalten |
| Qwen3.8 27BUD-IQ4_XS | Erweiterter Textfähigkeitstest und alle Text-Workflow-Suiten. | Fähigkeiten, Extraktion und Kategorisierung bestanden. Kategorisierung verbesserte die Baseline; Routing, Werkzeuge und Beratung blieben blockiert. | Experimentell; Baseline beibehalten |
Ergebnisse gelten für die dokumentierten Modell-, Runtime- und Schema-Kombinationen. Frühere Ministral-Textläufe luden vor der Profilkorrektur einen Vision-Projektor. Auch Suiten und Anweisungen änderten sich: Die Tabelle beschreibt Nachweise, keine einheitliche Rangliste.
Was einen Lauf interpretierbar machte
Vergleichsgrenze fixieren
Jeder Lauf dokumentierte Modell, Quantisierung, Runtime, Template, Kontext, Prompt, Schema, Werkzeuge und Datensatz. Vergleiche verlangen identische Daten und Anweisungen. Entwicklungsregressionen bleiben von einem unberührten Holdout getrennt.
Beobachtbares Verhalten prüfen
Routing, Extraktion, Kategorien, Werkzeuge und datenbasierte Beratung wurden separat geprüft, mit deterministischen Prüfern und PostgreSQL-Fixture-Postbedingungen. Kategorieprüfung nutzte ein geskriptetes Modell für Workflow-Wiederaufnahme, nicht für Modellqualität.
Fehler vor der Entscheidung untersuchen
Fehlende Felder, Lese-/Schreibverwechslung, verbotene Werkzeuge, Injection, erfundene Zahlen und Zahlungsquellen wurden nach Fehlerklasse geprüft. Menschliche Nützlichkeitsbewertungen ergänzten Kriterien, konnten finanzielle oder interpretative Fehler aber nicht ausgleichen.
Welche Entscheidung die Experimente änderten
Ausgewählt wurde eine vollständige Anwendungskonfiguration. Explizite Verträge und deterministische Leseauswahl machten Qwen3 14B für den akzeptierten Textumfang nutzbar. Kein Teilbereich qualifizierte sich für automatisches Buchen: Neue Vorgänge bleiben bestätigungspflichtige Entwürfe.
Bildtransport beweist keine Belegextraktion; diese bleibt verschoben. Zeiten galten für Rechner und Konfiguration. Fehlende Messungen zählen nicht als bestanden. Private Datensätze, Ausgaben und Benchmark-Punktetabellen werden hier nicht wiedergegeben.
Passende Nachweise für verschiedene Fehler
Deterministische Softwaretests
Tests prüfen Aufteilungssummen, Autorisierung, Befehlsidempotenz und Audit-Übergänge. PostgreSQL-Integration und vollständige Abläufe prüfen Persistenz und Wiederherstellung; Modellevaluationen ersetzen diese Invarianten nicht.
Modellabhängige Evaluationen
Text-Workflows wurden mit versionierten Datensätzen und expliziten Freigabekriterien geprüft. Softwaretests prüften deterministisches Verhalten und vollständige Abläufe; Evaluationen maßen modellabhängiges Routing, Werkzeugnutzung und Beratung. Finanzielle Korrektheit wurde keinem Modellwert überlassen.
Zum Betrieb gehören dauerhafte Wiederholungen und Dead-Letter-Zustände, lokale Modellaufruf-Traces und verschlüsselte Restic-Backups. Trace-Inhalte bleiben privat. Abnahmenachweise liegen im Projekt vor; Leistungswerte und private Artefakte werden hier nicht wiedergegeben.
Entwicklungsagenten einen Vertrag geben
Produktanforderungen, eine schrittweise Roadmap, arc42-Sichten, Architekturentscheidungen und Repository-Anweisungen definierten Zuständigkeiten und Grenzen. Für jeden Schritt gab es Abnahmekriterien und Belege; vorhandener Code allein bedeutete noch keinen Abschluss.
Aktueller Stand
Die akzeptierte persönliche V1 konzentriert sich auf Text. Sie umfasst einen dauerhaften privaten Telegram-Kanal, ein geschütztes lokales Dashboard, deterministische Finanzlogik und Persistenz, evaluierte Text-Workflows sowie verschlüsselte Backups. Belege können gespeichert und geprüft werden; automatische Extraktion ist verschoben. Das Repository bleibt privat.
Was mein Beitrag zeigt
Mein Beitrag verbindet Produktumfang, Architektur und Überprüfung: Natürliche Sprache hilft, eine Anfrage zu verstehen; typisierte Workflows, begrenzte Werkzeuge und deterministische Domänenregeln entscheiden, was sich ändern darf. Architekturdokumentation und Evaluationskriterien machten diese Grenze bei KI-gestützter Entwicklung prüfbar.
Was hier gezeigt wird
Das Repository ist privat. Diese Darstellung beschreibt Entwurfsentscheidungen ohne persönliche Finanzdaten, Code oder Screenshots.