Noel Schmitt

Schlagwort: Automation

  • Mein persönliche Finanz-Dashboard: Warum ich meine Bankdaten lieber selbst verwalte

    Du öffnest deine Banking-App, willst schnell sehen, wo dein Geld landet – und landest in drei verschiedenen Menüs, ohne echte Übersicht zu haben. Apps wie Finanzguru versprechen Rettung, aber dafür sollen deine Finanzdaten irgendwohin hochgeladen werden, wo du nicht siehst, was damit passiert. Das war für mich der Moment, eine Entscheidung zu treffen: Entweder ich akzeptiere diese Kompromisse, oder ich baue mir das selbst.

    Also habe ich angefangen zubauen. Ein Dashboard mit vollständiger Datenhoheit, automatischer Kategorisierung und einem Desktop-First-Ansatz, der nicht auf Mobile-Kompromisse setzt. Was als Projekt für mein erstes größeres Laravel-System anfing, wurde zur Auseinandersetzung mit echten FinTech-Problemen: chaotische Bankdaten, Datensicherheit und Automatisierung ohne externe APIs.

    Das Problem mit fremden Lösungen

    Jede Banking-App zeigt Umsätze, aber keine von ihnen bietet das, was ich brauchte: eine Gesamtübersicht über mehrere Konten (Giro, Kreditkarte, Sparkonten) an einer Stelle. Und das mit dem Detail-Level, den nur ein größerer Bildschirm ermöglicht. Desktop-Analysen zu Finanzzielen sind einfach anders als auf 5 Zoll zu schwenken und zu scrollen.

    Hinzu kam der Datenschutz-Aspekt. Wer meine Transaktionen bekommt, was damit gemacht wird, welche Analysen laufen – keine dieser Apps macht das transparent. Also habe ich die radikalere Frage gestellt: Was brauche ich technisch, um das selbst zu kontrollieren?

    Die Architektur-Entscheidungen

    Tech-Stack:

    • Laravel (Backend, Geschäftslogik, Verschlüsselung)
    • React (Frontend, interaktive Analysen)
    • SQL-Datenbank (strukturierte Transaktionsdaten)

    Die Kombination war bewusst gewählt: Laravel bringt built-in Sicherheitsfeatures mit (Verschlüsselung, Validierung, Middleware), React ermöglicht die komplexen Visualisierungen ohne Seitenneuladen. Externe Tools wie n8n für Workflow-Automatisierung habe ich bewusst nicht gewählt – nicht aus Purismus, sondern aus praktischem Grund: Sobald sensible Finanzdaten die App verlassen, wird Datenschutz zum Problem. Eine API dafür zu bauen wäre ein zusätzliches Sicherheitsrisiko gewesen.

    Die CSV-Import-Hölle

    Der erste echte Problemfall: Die Daten. Jede Bank exportiert ihr CSV-Format selbst. Sparkasse nutzt anderes Format als Tomorrow Bank. Dezimaltrennzeichen: manchmal Komma, manchmal Punkt. Datumsformat: DD.MM.YYYY oder YYYY-MM-DD? Und wie wird eine Ausgabe gekennzeichnet – mit Minuszeichen oder in einer separaten „Soll“-Spalte?

    Manuell jede Bank mappen wäre möglich, aber nicht skalierbar. Also entstand eine intelligente Importstrecke.

    Automatische Schema-Erkennung statt manuelles Chaos

    Das System analysiert die hochgeladene CSV und vergleicht sie mit hinterlegten Bank-Schemata. Für Sparkasse und Tomorrow sind Templates definiert – erkennt das System eines davon, lädt es die richtige Konfiguration.

    Falls keine Übereinstimmung existiert, greift der manuelle Modus: Nutzer mappen Spalten zu Datenfeldern (Datum, Empfänger, Betrag, Beschreibung). Eine Vorschau zeigt, wie die Daten später aussehen. Erst dann werden sie in die Datenbank geschrieben. Das bedeutet: Nach dem ersten Import einer neuen Bank speichert das System deren Schema, künftige Importe laufen vollautomatisch.

    Datensicherheit als fundamentales Feature

    Wir sprechen hier über Kontostände, IBAN, Transaktionspartner – Informationen, die extremen Schutz benötigen. Meine Lösung: AES-256-CBC Verschlüsselung für alle sensiblen Felder.

    Das ist nicht optional und nicht nur auf die Datenbank angewendet – die Verschlüsselung läuft transparent über Laravels Encryption Facade. Der Vorteil: Entwickler müssen nicht selbst Kryptographie implementieren (Fehlerquelle!), stattdessen wird Verschlüsselung und Fehlerbehandlung vom Framework übernommen.

    Verschlüsselte Felder:

    • IBANs und Kontoinformationen
    • Beträge (ja, auch die)
    • Empfänger und Absender
    • Transaktionsbeschreibungen

    Ein direkter Datenbankzugriff zeigt nur Cipher-Text. Entschlüsselt werden Daten erst in der App, unmittelbar vor der Anzeige. Das bedeutet: Selbst wenn jemand die Datenbank kopiert, hat er nur verschlüsselte Strings.

    Automatische Kategorisierung – oder: Warum ich 250 Transaktionen nicht manuell mappen wollte

    Nach dem Import liegt eine große Tabelle vor: Transaktionen, aber ohne Kategorien. Wäre jede der 250 Transaktionen manuell zuzuordnen (Lebensmittel, Wohnen, Shopping, Medien, Transport), wäre das zeitlich nicht skalierbar.

    Also nächste Baustelle aufmachen.

    Die Automations-Engine

    Die Engine basiert auf einfachen, aber effektiven Regeln. Eine Regel: Wenn „Empfänger“ enthält „Edeka“, „Lidl“, „Aldi“ oder „Kaufland“, dann Kategorie „Lebensmittel“. Oder: Wenn Empfänger ist „Netflix“, „Spotify“, „Disney+“, dann „Medien“.

    Unterstützte Operatoren:

    • „ist gleich“
    • „enthält“
    • „beginnt mit“
    • „endet mit“

    Mehrere Bedingungen lassen sich kombinieren. Regeln können entweder bei jedem Import automatisch laufen oder manuell auf Knopfdruck. Der entscheidende Vorteil: Diese Integration bleibt innerhalb der App. Keine externe API, keine Datenübertragung – die Automation läuft direkt in Laravel als Background Job nach jedem Import.

    Das System kommt mit Default-Regeln für häufige Transaktionspartner. Aber Nutzende können eigene Regeln definieren. Ein neuer Lieblingsladen? Neue Regel. Nach kurzer Zeit haben sich die meisten Transaktionen selbst kategorisiert, nur noch Edge Cases brauchen Nachbearbeitung.

    Analysen: Das eigentliche Ziel

    Saubere Daten sind nur Mittel zum Zweck. Das Ziel: Verstehen, wohin das Geld wirklich fließt.

    Zeitliche Flexibilität

    Ein zentraler Datumsselektor mit Quick-Select-Optionen:

    • Gesamter verfügbarer Zeitraum
    • Letzter Monat, dieser Monat
    • Letzte 3, 6 oder 12 Monate
    • Dieses Jahr, letztes Jahr
    • Spezifisches einzelnes Datum

    Diese Flexibilität ermöglicht sowohl große Trends als auch Details zu sehen.

    Visualisierungen statt Tabellen

    Ein Donut-Diagramm zeigt die Übersicht: Gesamtausgaben, Ersparnisse, verbleibendes Budget auf einen Blick. Ein Breakdown nach Kategorien wird prozentual dargestellt – Wohnen 25,1%, Sparen und Investieren 16,8%, Shopping 12,6%, Lebensmittel 17%.

    Das Spannendste: Monatliche Vergleiche nebeneinander. Januar vs. Februar als gestapelte Balkendiagramme. Wo wurde mehr ausgegeben? Welche Kategorien sind gestiegen?

    War Shopping im Januar noch wild, im Februar aber deutlich reduziert? Sind Lebensmittelkosten konstant oder volatil? Diese visuellen Vergleiche ermöglichen datenbasierte Finanzentscheidungen – nicht Bauchgefühl.

    Was lief nicht optimal – und was ich daraus gelernt habe

    Die größten Herausforderungen waren nicht technisch, sondern konzeptionell.

    Zuerst dachte ich, dass die Datenbankstruktur das komplexeste Element ist. Tatsächlich war es die Datenharmonisierung. Jede Bank hat ihre eigenen Konventionen – das ist nicht zu unterschätzen. Der Import-Flow musste iterativ überarbeitet werden, nachdem erste Tests mit echten CSVs zeigten, dass die automatische Erkennung Edge Cases nicht abdeckte.

    Die Rule-Engine war auch nicht beim ersten Mal perfekt. Manche Transaktionen erfüllen mehrere Regeln gleichzeitig – hier musste ich eine Priorisierungslogik einbauen. Später kam die Erkenntnis, dass „Smart Defaults“ hilfreicher sind als zu viele Optionen für Nutzer.

    Bei der Verschlüsselung hätte ich früher merken sollen, dass ich zwar Laravels built-in Features nutze, aber noch nicht eingehend genug die Performance-Implikationen überprüft habe. Große Datasets mit AES-256 zu verarbeiten ist nicht instant, sondern braucht Optimierung (z.B. Selective Encryption statt alles zu verschlüsseln).

    Das Lernen aus diesen Punkten:

    Datenquellen sind chaotischer als Businesslogik. Das unterschätzen viele Entwickler. Jede externe Datenquelle hat ihre eigenen Quirks.

    Integration schlägt Orchestrierung. Externe Workflow-Tools hätten die Lösung vereinfacht, aber verschlüsselte Daten aus der App zu bringen ist die echte Komplexität. Integriert zu sein bedeutet: Die Automation läuft sicherer.

    Defaults sind mächtiger als Flexibilität. 80% der Nutzer wollen wahrscheinlich nur, dass das System automatisch funktioniert. Die restlichen 20% brauchen Custom-Rules – aber nicht alle Nutzer.

    Performance früh testen. Mit 250 Transaktionen merkt man Verschlüsselungs-Overhead nicht. Bei 5000 wird es relevant.

    Ausblick: Was noch fehlt

    Beta Tester

    Noch hat die App genau einen Nutzer: mich. Ein Deployment und anschließendes Einladen von Family & Friends wäre eine gute Gelegenheit, die UX und das UI noch weiter zu testen und zu iterieren.

    Automatische Bankanbindung

    Die FinAPI würde den nächsten Schritt bedeuten: echte API-Verbindung zu Banken, Echtzeit-Synchronisation, kein manueller CSV-Import mehr. Die Herausforderung: Das erfordert noch intensivere Auseinandersetzung mit Datensicherheit bei externen Verbindungen. Aber es wäre der logische nächste Schritt für weniger Reibung.

    KI für strukturierte Insights

    Mit den strukturierten Daten könnten konkrete KI-Analysen arbeiten. Nicht vage Vorschläge, sondern: „Du gibst im Durchschnitt 47€ pro Lebensmitteleinkauf aus. In Kategorie X könntest du 12% sparen.“ Kombiniert mit Kassenzettel-Scans wäre sogar granulares Produkt-Level-Tracking möglich.

    Haushaltskonten

    Verbinden von zwei Accounts zu einem gemeinsamen Haushaltskonto (entweder vollständig oder Granulat ausgewählt) könnte die Übersicht über mehrere Konten von mehreren Personen ermöglichen.

    Budgetplanung und Prognosen

    Auf Basis historischer Daten: Warnungen bei Budget-Überschreitungen, Prognosen für kommende Monate, vielleicht sogar Vergleiche mit anonymisierten Durchschnittswerten ähnlicher Personen.

    Fazit

    Das Projekt ist nicht einfach „ein Finanz-Dashboard“. Es ist ein Projekt mit steiler Lernlkurve in der Technologie und wie sich UX im Laufe der Zeit selbstständig weiterentwickeln kann. Und plötzlich baut man ein kleines FinTech-Systems mit intelligenter Datenspeicherung, Automatisierung und Analysen – alles unter vollständiger Kontrolle.

    Die größten Erkenntnisse liegen nicht in der Technologie selbst, sondern darin, wie man chaotische externe Daten in ein sauberes, internes System transformiert. Und dass Datensicherheit nicht später gelöst wird, sondern von Anfang an Teil der Architektur sein muss.

    Für mich ist es gleichzeitig ein Portfolio-Projekt geworden – ein Beweis, dass ich nicht nur code schreibe, sondern Systeme baue, die ein echtes Problem lösen.

  • Einen Marketing-Kritiker in die Hosentasche packen: Wie ich Oliver Voss als KI-Chatbot klonte

    Überblick

    Jeder in der Marketing-Bubble kommt irgendwann an Oliver Voss nicht vorbei. Auf Instagram bewertet er Plakate und Werbung auf eine Art und Weise, die einzigartig ist – direkt, fachkundig und mit einer Prise Humor, die Marketer entweder lieben oder hassen.

    Genau diese unique Art und Weise in einem Spaßprojekt synthetisch mit KI herzustellen, war die Idee dahinter. Das Ergebnis ist ein hyperpersonalisierter Chatbot, der auf den gesamten Instagram-Content von Oliver Voss zurückgreifen kann und sowohl auf Fragen antwortet als auch proaktiv Werbematerialien bewertet – als hätte man einen persönlichen Marketing-Kritiker in der Hosentasche.

    Was der Chatbot kann

    Der Bot arbeitet intelligent kontextabhängig: Je nachdem, welchen Input der User liefert, trifft das System selbstständig die Entscheidung, wie es agieren soll. Stellt man eine Frage wie „Was hat dir am letzten DM-Plakat nicht gefallen?“, zieht es relevante Transkripte aus der Vektordatenbank heran und antwortet basierend auf tatsächlichen Bewertungen. Lädt man hingegen ein Plakat-Layout hoch, wechselt es in den Bewertungsmodus und gibt direktes Feedback zu Headline, Bildaufteilung, Farbwahl – mit genau der Tonalität, die Oliver Voss ausmacht.

    Diese Entscheidungslogik wird übrigens in Langfuse getrackt, sodass nachvollziehbar ist, welche Aktionen das Modell wann und warum ausführt. Das Ganze funktioniert sowohl für Text als auch für Bilder. Werbetexte, Social-Media-Posts, komplette Kampagnen – alles kann bewertet werden. Und natürlich mit der gewissen Humorfarbe, die das Original auszeichnet.

    Technische Architektur

    Die Plattform ist eine Next.js-App, die API-Anfragen an OpenAI schickt. Im Hintergrund arbeitet GPT-4o als Hauptmodell. Die eigentliche Magie liegt aber nicht im LLM selbst, sondern in der Datenpipeline, die dafür sorgt, dass der Bot tatsächlich wie Oliver Voss denkt und argumentiert.

    Data Scraping und mehrstufige Aufbereitung

    Phase 1: Content-Extraktion mit n8n

    Der erste Schritt war die Extraktion aller relevanten Daten vom Instagram-Account. Über einen Scraper wurden Videos, Bilder, Captions und alle verfügbaren Metadaten geladen. Diese Rohdaten mussten dann in eine Form gebracht werden, die für die Vektorisierung geeignet ist.

    Phase 2: Intelligente Content-Verarbeitung

    Die Aufbereitung erfolgte mehrstufig über n8n-Workflows. Im ersten Schritt wurden Videos transkribiert – Oliver Voss\‘ Content ist primär video-basiert, und die gesprochenen Worte sind das Herzstück seiner Bewertungen. Aus diesen Transkripten wurden im zweiten Schritt Zusammenfassungen mit Key Takeaways erstellt. Das reduziert nicht nur die Datenmenge, sondern destilliert die wichtigsten Aussagen heraus.

    Phase 3: Marken- und Tag-Erkennung

    Ein kritischer Aspekt für spätere Suchanfragen: Welche Marke wird im Video bewertet? Es wurde geprüft, ob ein Markenname im Transkript oder in der Zusammenfassung erkennbar war. Sollte kein Name genannt worden sein, wurden Screenshots aus dem Video analysiert, um Logos oder Markennamen visuell zu identifizieren. Erst wenn auch das fehlschlug, wurde einfach keine Marke hinterlegt.

    Zusätzlich wurde ein Tag-System implementiert, das sich aus Beschreibungen und Zusammenfassungen automatisch Tags extrahiert hat – etwa „Plakat“, „Social Media“, „Print“, „Headline“, „Bildsprache“ etc. Diese Tags ermöglichen später präzisere Suchen in der Vektordatenbank.

    Phase 4: Strukturierte Datentabelle

    Am Ende dieser Pipeline stand eine umfassende Datentabelle mit Transkripten, Zusammenfassungen, Marken, Tags und Metadaten. Diese strukturierte Grundlage war entscheidend für die nächste Phase: die Vektorisierung.

    Vektorisierung mit semantischer Segmentierung

    Die Transkripte und Zusammenfassungen wurden in eine selbst gehostete Open-Source-Vektordatenbank überführt. Dabei wurde nicht einfach nach fixen Token-Längen abgeschnitten – ein häufiger Fehler bei RAG-Systemen. Stattdessen erfolgte eine semantische Segmentierung: Absätze wurden logisch getrennt, sodass zusammenhängende Gedankengänge nicht mittendrin abgeschnitten werden.

    Die Metadaten – Marken, Tags, Video-IDs – wurden direkt in die Vektorisierung integriert. Das ermöglicht später hybride Suchen: Man kann sowohl semantisch suchen („Wie bewertet er Headlines?“) als auch strukturiert filtern („Zeig mir alle Bewertungen zu McDonald\’s“).

    Diese Vektordatenbank wurde dann als Tool dem LLM über die OpenAI API zur Verfügung gestellt. Das bedeutet: GPT-4o kann bei Bedarf eigenständig entscheiden, ob es Suchen in der Vektordatenbank durchführen muss, und die relevantesten Inhalte für seine Antwort heranziehen.

    Prompt Engineering und Iterative Optimierung

    Ein hyperpersonalisierter Chatbot steht und fällt mit dem Prompt. Es reicht nicht, einfach zu schreiben „Antworte wie Oliver Voss“ – die Tonalität, der Humor, die fachlichen Schwerpunkte müssen präzise definiert werden.

    Das Prompt Engineering lief über Langfuse, das zentrale Prompt-Management ermöglicht. Versionierte Prompts mit vollständiger Historie machten es möglich, verschiedene Formulierungen zu testen und iterativ zu optimieren. Welche Systemprompt-Variante führt zu den authentischsten Antworten? Wie viel Kontext braucht das Modell? Wann sollte es proaktiv nachfragen?

    LLM as a Judge: Automatisierte Qualitätssicherung

    Hier wird es besonders interessant: Um die Antwortqualität systematisch zu bewerten, wurde ein „LLM as a Judge“-Prinzip implementiert. Ein kleineres, spezialisiertes Modell prüft die Antworten des Chatbots anhand konkreter Kriterien:

    • Entspricht die Tonalität dem Original?
    • Sind die fachlichen Aussagen korrekt und relevant?
    • Wird auf die Nutzerfrage präzise eingegangen?
    • Ist die Antwort weder zu kurz noch zu ausschweifend?

    Jede Antwort erhält einen Score. Die besten Antworten wurden herausgefiltert und dienten als Benchmark für weitere Optimierungen. Dieses automatisierte Feedback-System ist deutlich skalierbarer als manuelle Reviews und ermöglicht kontinuierliche Verbesserung.

    Performance-Monitoring mit Langfuse

    Jede Chatnachricht, die vom Nutzer abgeschickt wird, wird in Langfuse erfasst. Das schafft vollständige Transparenz darüber, wie die KI sich verhält:

    • Wie lange dauert eine Antwort insgesamt?
    • Wie lange dauert ein Tool Call zur Vektordatenbank?
    • Welche Metadaten wurden für die Suche verwendet?
    • Wie viele Tokens wurden verbraucht?
    • Welche Prompt-Version wurde verwendet?

    Diese Metriken sind nicht nur für Debugging wertvoll, sondern auch für strategische Optimierungen. Wenn Vektorsuchen zu lange dauern, liegt das am Query-Embedding oder an der Datenbank-Konfiguration? Wenn Antworten zu lang sind, liegt es am Modell oder am Prompt?

    Das Performance-Monitoring ermöglicht datengetriebene Entscheidungen statt Bauchgefühl.

    Deployment auf Vercel

    Die gesamte App wurde auf Vercel deployed, was nahtlose Integration mit dem Next.js-Framework bietet. Automatische Deployments bei jedem Push, Edge Functions für niedrige Latenz und einfaches Umgebungsvariablen-Management machen Vercel zur idealen Plattform für diesen Use Case.

    Was das Projekt zeigt

    Auf den ersten Blick ist es ein Spaßprojekt. Auf den zweiten Blick ist es ein vollständiges RAG-System mit mehrstufiger Datenpipeline, semantischer Vektorisierung, automatisierter Qualitätssicherung und umfassendem Performance-Monitoring.

    Die Herausforderung lag nicht darin, einen generischen Chatbot zu bauen – das kann jeder mit der OpenAI API in einer Stunde. Die Herausforderung lag darin, einen Chatbot zu bauen, der tatsächlich wie eine spezifische Person denkt, argumentiert und bewertet. Das erfordert sorgfältige Datenaufbereitung, intelligente Vektorisierung und präzises Prompt Engineering.

    Und genau das macht das Projekt zu einem spannenden Showcase für hyperpersonalisierte KI-Systeme.

  • Mira: Market Intelligence Research Agents

    Eine webbasierte Plattform für automatisierte Marktforschung durch KI-gestützte Persona-Agents. Nutzer erstellen Fragebögen über ein Next.js-Frontend und erhalten Feedback von 500 individualisierten KI-Personas anstelle realer Testpersonen.

    Die Herausforderung dahinter ist grundlegend: Traditionelle Marktforschung kostet Zeit und Geld – oft zu viel für frühe Produktphasen, in denen schnelle Iterationszyklen entscheidend sind. Genau hier setzt die Plattform an: Sie ermöglicht es, Produktideen, Features oder Messaging innerhalb von Minuten statt Wochen mit verschiedenen Zielgruppen zu validieren.

    Funktionsweise

    Der Nutzer definiert über einen strukturierten Fragebogen seine Forschungsfragen. Nach Absenden werden im Backend LangGraph-Agents aktiviert, die auf Basis ihrer zugewiesenen Persona-Profile antworten. Jeder Agent setzt sich individuell mit dem Produkt und Briefing auseinander und liefert entweder Freitextantworten oder skalierte Bewertungen.

    Der entscheidende Unterschied zu statischen Templates oder einfachen Prompt-Variationen: Jede Persona reagiert tatsächlich kontextbezogen auf die spezifische Fragestellung. Ein 28-jähriger Tech-Enthusiast aus dem urbanen Milieu antwortet anders auf die gleiche Produktfrage als eine 52-jährige Mutter aus dem ländlichen Raum – nicht weil unterschiedliche Prompts verwendet werden, sondern weil die zugrundeliegenden Persona-Profile diese Unterschiede in Wertesystemen, Lebenssituationen und Konsumverhalten bereits enthalten.

    Persona-System und Datenmanagement

    Das Herzstück der Plattform bilden 500 individualisierte Personas, die verschiedene Alters-, Milieu- und Geschlechtergruppen abdecken. Hier liegt eine der größten technischen und konzeptionellen Herausforderungen des Projekts: Wie erschafft man Personas, die glaubwürdig und konsistent antworten?

    Wissenschaftlich fundierte Milieu-Segmentierung

    Die Erstellung erfolgte über einen mehrstufigen, KI-gestützten Prozess, der auf etablierten deutschen Milieustudien basiert. Zunächst wurden neue Milieugruppen generiert, die aktuelle gesellschaftliche Strukturen abbilden. Jede Milieugruppe erhielt eine statistische Verteilung nach Geschlecht und Alter – beispielsweise 100 Personen in Milieu 1, davon 70% männlich, 30% weiblich, mit spezifischen Altersverteilungen pro Geschlecht.

    Intelligente Namensgebung und Migrationshintergrund

    Die Komplexität zeigt sich bereits bei einem scheinbar simplen Detail: den Namen. Bei der Generierung wurde berücksichtigt, welches Geschlecht die Person hat, in welchem Jahr sie geboren wurde (um zeitgemäße Namen zu wählen) und ob sie einen Migrationshintergrund besitzt. Das führte zu einer generationenspezifischen Namensgebung: In der Gen Z sind beispielsweise türkische Namen inkludiert, während in der Silent Generation (alles vor den 90ern) eher griechische, italienische oder polnische Namen dominieren – ein Abbild der deutschen Migrationsgeschichte.

    Datenverarbeitung mit n8n

    Die Verarbeitung dieser komplexen Datenmengen erfolgte über n8n als Workflow-Automation-Tool. Der initiale Generierungsprozess war nur der erste Schritt. Danach folgte die Validierung auf Konsistenz – widersprechen sich Datenpunkte innerhalb einer Persona? Ist die Verteilung über verschiedene Milieus realistisch? Gibt es ungewollte Bias in der Altersverteilung oder Geschlechterrepräsentation? Diese Fragen mussten systematisch beantwortet werden, bevor die Personas produktiv eingesetzt werden konnten.

    Jede Persona verfügt über ein detailliertes Profil mit 25 Spalten, die jeweils multiple Datenpunkte enthalten. Es reicht nicht, einfach „weiblich, 35 Jahre, verheiratet“ zu definieren. Erst die Kombination aus demografischen Daten, Wertesystemen, Konsumverhalten, Mediennutzung, politischen Einstellungen und konkreter Lebenssituation macht eine Persona glaubwürdig und differenziert genug, um auf unterschiedliche Fragestellungen authentisch zu reagieren.

    Flexible Zielgruppen-Segmentierung

    Bei der Umfrageerstellung können spezifische Zielgruppen definiert werden – etwa nach Geschlecht, Familienstand oder anderen demografischen Merkmalen. Umfragen lassen sich mit unterschiedlichen Personagruppen wiederholen, um verschiedene Zielgruppensegmente zu validieren. Das macht iteratives Testing möglich: Einmal den Fragebogen erstellt, mehrmals mit verschiedenen Zielgruppen getestet. Die Architektur erlaubt es, eine Produktidee erst mit Tech-Early-Adopters zu testen, dann mit preisbewussten Familien, dann mit Senioren – alles innerhalb weniger Stunden statt Wochen.

    Backend-Architektur: FastAPI und Supabase

    Das technische Fundament der Plattform besteht aus zwei zentralen Komponenten: einem individuell entwickelten Python-Backend mit FastAPI und Supabase als Backend as a Service.

    FastAPI als strategische Architekturentscheidung

    Die Entscheidung für FastAPI war strategisch: Alle Funktionen, die momentan vom Frontend abgerufen werden, sind bereits API-ready. Das bedeutet, dass die gesamte Marktforschungs-Logik perspektivisch als Schnittstelle in andere Systeme integriert oder für andere Kunden verfügbar gemacht werden kann. Ein SaaS-Produkt zu bauen war von Anfang an mitgedacht – nicht als nachträgliche Anpassung, sondern als Teil der Grundarchitektur.

    Das FastAPI-Backend übernimmt das gesamte Handling von LangGraph, die Orchestrierung der Agent-Chains und die Kommunikation mit den verschiedenen Services. Die asynchrone Natur von FastAPI ist hier besonders wertvoll: Wenn 50 Personas parallel auf einen Fragebogen antworten sollen, laufen diese Prozesse non-blocking ab.

    Strukturierte Responses mit Validation Layer

    Ein kritischer Aspekt der Architektur ist die Sicherstellung der Datenqualität. Die LLM-Agents werden zu strukturierten JSON-Antworten gezwungen. Wenn eine JSON-Antwort nicht korrekt formatiert vom LLM zurückgegeben wird, greift ein Validation Layer: Die Antwort wird abgelehnt und ein automatisches Retesting findet statt. Diese Fehlerbehandlung auf mehreren Ebenen stellt sicher, dass nur valide, verarbeitbare Daten in die Datenbank gelangen.

    Supabase für Authentication und Database

    Supabase übernimmt die Datenbankverwaltung für Personas, Umfragen und Ergebnisse sowie das komplette User-Authentication-System. Jeder Nutzer verfügt über einen individuellen Login-Bereich, in dem ausschließlich die eigenen Projekte und Umfragen angezeigt werden.

    Der entscheidende Vorteil dieser Architektur liegt in der PostgreSQL-Basis von Supabase. Es ist keine „Black Box“ wie bei vielen anderen Backend-as-a-Service-Lösungen. Row Level Security ermöglicht granulare Zugriffskontrolle direkt auf Datenbankebene. Nutzer können technisch gar nicht auf fremde Umfragen zugreifen – nicht weil die Application-Logik das verhindert, sondern weil die Datenbank es nicht zulässt. Diese Sicherheitsebene direkt in der Datenbank zu haben, statt sie nur in der Application-Layer zu implementieren, reduziert das Risiko von Sicherheitslücken erheblich.

    LLM-Integration und Modellauswahl

    OpenRouter: Eine API für alle Modelle

    Als LLM-Provider kommt OpenRouter zum Einsatz. Die Entscheidung für OpenRouter statt direkter Integration einzelner Anbieter bietet einen strategischen Vorteil: maximale Flexibilität in der Modellauswahl ohne Vendor Lock-in. Eine API für alle Provider bedeutet konkret, dass man innerhalb von Minuten auf neue, bessere Modelle von OpenAI, Anthropic, Google oder anderen Anbietern wechseln kann. In einem Feld, das sich so schnell entwickelt wie Large Language Models, ist diese Flexibilität entscheidend.

    Iterative Modellevaluation

    In einer initialen Testphase wurden verschiedene Language Models auf ihr Preis-Leistungs-Verhältnis und ihre Output-Qualität hin getestet. Schnell zeigte sich: Teurere Modelle liefern nicht automatisch bessere Ergebnisse – es kommt auf den spezifischen Use Case an. Für strukturierte Umfrageantworten mit klaren Persona-Vorgaben benötigt man nicht unbedingt die höchste Reasoning-Kapazität der teuersten Modelle. Wichtiger sind Konsistenz, Zuverlässigkeit und die Fähigkeit, Instruktionen präzise zu befolgen.

    Die Balance zwischen Kosten und Qualität ist kritisch: Bei 500 Personas und potenziell dutzenden Fragen pro Umfrage summieren sich die API-Kosten schnell. Ein Modell, das 30% teurer ist aber nur 10% bessere Ergebnisse liefert, ist wirtschaftlich nicht tragfähig. Die Tests führten zur Auswahl eines Modells, das sowohl wirtschaftlich als auch qualitativ optimale Ergebnisse für diesen konkreten Anwendungsfall liefert.

    Langfuse: Zentrales Prompt-Management und Observability

    Jede Agent-Antwort wird über Langfuse als LLM Observability Tool getrackt. Langfuse übernimmt dabei mehrere zentrale Funktionen: Es ermöglicht versionierte Prompts mit vollständiger Historie und macht es möglich, verschiedene Prompt-Varianten zu testen und zu vergleichen.

    Das Besondere: Langfuse wird für alle KI-Funktionen in der App genutzt – sowohl bei der initialen Persona-Generierung als auch für System-Prompts, Persona-Prompts, Summary-Prompts und alle weiteren KI-gestützten Features. Alles läuft zentral über dieses System, und es ist selbst gehostet, was zusätzliche Flexibilität bietet.

    Die gesammelten Daten dienen mehreren Zwecken: Sie ermöglichen kontinuierliches Monitoring der Agent-Performance – welche Personas antworten konsistent? Wo gibt es Ausreißer? Welche Fragen führen zu qualitativ hochwertigen Antworten? Gleichzeitig sind die gespeicherten Daten bereits so vorstrukturiert, dass sie später sehr einfach in ein klassisches Frage-Antwort-Format für das Training spezialisierter Large oder Small Language Models überführt werden können. Je mehr Umfragen durchgeführt werden, desto mehr Daten über erfolgreiche Persona-Antworten sammeln sich an – ein wachsendes Asset für zukünftige Modell-Optimierungen.

    Custom Token Management System

    Für die Nutzungsverwaltung wurde ein maßgeschneidertes Token-System entwickelt. Die Token-Berechnung basiert auf zwei Faktoren: der Anzahl der Fragen im Fragebogen und der Anzahl der ausgewählten Personas. Beispielrechnung: Bei einem Fragebogen mit 8 Fragen und 50 befragten Personas werden 400 Tokens verbraucht (8 × 50 = 400).

    Warum ein Custom System statt einer Standard-Lösung? Die spezifische Berechnungslogik reflektiert die tatsächlichen Kosten und den Wert der Plattform. Jede Frage an jede Persona verursacht einen LLM-API-Call – das Token-System bildet also direkt die dahinterliegende Ressourcennutzung ab. Standard-Lösungen wie „Credits pro Umfrage“ oder „Flatrate für X Umfragen“ hätten diese Granularität nicht bieten können.

    Das System beinhaltet eine automatische Token-Regeneration: Alle 30 Tage werden die Tokens des jeweiligen Nutzers wieder aufgefüllt. Diese Mechanik fördert regelmäßige Nutzung ohne dass sich Nutzer Gedanken über „verschwendete“ Tokens machen müssen. Die gesamte Token-Verwaltung – Verbrauch, Tracking und Regeneration – läuft über die Supabase-Datenbank und wurde vollständig individuell entwickelt, von der Berechnungslogik bis zur automatischen Cronjob-Ausführung für die monatliche Regeneration.

    Ergebnisaufbereitung mit Mehrwert

    Das Frontend bereitet die Agent-Antworten in einem übersichtlichen Bericht auf. Der Fokus liegt dabei nicht nur auf Darstellung, sondern auf echtem Erkenntnisgewinn: Die automatische Zusammenfassung von Meinungsbildern priorisiert bereits in welche Richtung es geht und liefert konkrete Key Takeaways.

    Statt nur zu schreiben „Die meisten Personas fanden das Produkt interessant“, werden spezifische Handlungsempfehlungen generiert: „47 von 50 Personas haben den Preis als zu hoch kritisiert, besonders in der Altersgruppe 25-35. Gleichzeitig wurde die Funktionalität X von 38 Personas positiv hervorgehoben. Handlungsempfehlung: Preis überdenken oder zusätzliche Features kommunizieren, die den Preis rechtfertigen.“

    Zusätzlich ermöglichen Visualisierungsfunktionen die Darstellung der Umfrageergebnisse in Diagrammform. Die Balance zwischen Überblick und Detail ist entscheidend – zu oberflächlich, und die Ergebnisse wirken nicht vertrauenswürdig; zu detailliert, und niemand wird sich durch hunderte Einzelantworten arbeiten. Die Plattform bietet beides: Schnelle Erfassbarkeit der wichtigsten Erkenntnisse in wenigen Minuten, aber gleichzeitig die Möglichkeit, bei Bedarf tief in die Einzelantworten einzutauchen.

    Validierung und Weiterentwicklung: Die SSR-Methode

    Erste Tests haben gezeigt, dass das System grundlegend funktioniert. Die entscheidende Frage bleibt jedoch: Sind die Ergebnisse valide? Antworten KI-Personas tatsächlich so, wie echte Menschen es tun würden?

    Das Problem der „generischen Mitte“

    Hier zeigt sich eine bekannte Problematik von LLM-basierten Umfragen: die sogenannte „generische Mitte“. Wenn ein Language Model auf einer Skala von 1 bis 7 bewerten soll, wählt es überproportional häufig mittlere Werte – ein Verhalten, das menschliche Antwortmuster nicht authentisch abbildet. Menschen sind polarisierter, emotionaler, weniger „ausgeglichen“ in ihren Bewertungen. Sie tendieren zu den Extremen, besonders wenn sie starke Meinungen haben.

    Semantic Similarity Rating: Wissenschaftlich validierte Lösung

    Eine vielversprechende Lösung bietet die kürzlich veröffentlichte Semantic Similarity Rating (SSR) Methode (Maier et al., 2025: „LLMs Reproduce Human Purchase Intent via Semantic Similarity Elicitation of Likert Ratings“). Die Studie basiert auf 57 Consumer-Research-Surveys mit über 9.300 realen Teilnehmern und zeigt wissenschaftlich fundiert, dass LLMs mit der richtigen Methodik valide Marktforschungsergebnisse liefern können.

    Der Ansatz dreht das Problem elegant um: Statt die KI direkt eine Zahl wählen zu lassen, lässt man sie tun, was sie am besten kann – natürliche Sprache generieren. Die KI gibt zunächst eine Freitextantwort, beispielsweise „Ich könnte mir vorstellen, das Produkt zu kaufen“. Diese Antwort wird anschließend vektorisiert und mit vordefinierten Musterantworten für jede Skalenstufe semantisch abgeglichen. Das System vergibt dann basierend auf der höchsten semantischen Übereinstimmung das Rating – nicht die KI selbst.

    Beeindruckende Validierungsergebnisse

    Die Studie zeigt beeindruckende Ergebnisse: SSR erreicht 90% der menschlichen Test-Retest-Reliabilität bei gleichzeitig realistischen Antwortverteilungen (KS-Similarity > 0.85). Dieser Umweg über die Vektorsuche umgeht die Tendenz zur generischen Mitte und führt zu authentischeren Antwortverteilungen. Die KI bleibt in ihrer Komfortzone (Textgenerierung), während das Rating systemseitig erfolgt. Es ist ein Beispiel dafür, wie man die Stärken von LLMs nutzt und gleichzeitig ihre Schwächen umgeht, statt gegen sie anzukämpfen.

    Integration als nächster Schritt

    Die Integration dieser Methode ist ein logischer nächster Schritt, um die Validität der Umfrageergebnisse wissenschaftlich fundiert zu erhöhen und das System näher an reale Marktforschungsstandards heranzuführen. Die technische Infrastruktur dafür ist bereits vorhanden – Vektorisierung und semantische Suche sind etablierte Technologien. Die Herausforderung liegt in der Erstellung und Kalibrierung der Musterantworten für jede Skalenstufe, aber die wissenschaftliche Evidenz aus der Studie liefert klare Richtlinien für die Implementation.