Von RAG Agent Dreams zu einem VBA-Prototyp: Rohdaten und abgeleitete Daten trennen

Der Plan war bescheiden: eine kleine Version von Merge zu entwickeln, einen persönlichen KI-Agenten. Experimente mit RAG, LangChain, LangGraph, Embeddings und Vektorlagern waren bereits im Gange, und die ursprüngliche Idee war es, dem Agenten ein Langzeitgedächtnis sowie Zugriff auf interne Dokumente zu geben. Dann kam ein anderes Problem dazwischen. Die freiberufliche Projektverwaltung war chaotisch geworden, was dazu führte, zunächst ein kleines VBA-Tool zu schreiben. Das schien einfach, war es aber nicht. Im Laufe der Zeit verwandelte sich das VBA-Prototyp in etwas anderes – eine Methode, um die Geschäftslogik zu untersuchen, die ein KI-Agent eines Tages erben könnte.

Projekte, die sich einem sauberen Lebenszyklus verweigern

Freiberufliche Arbeit verläuft nicht immer auf einem geraden Weg. Zuerst wird eine Landing Page fertiggestellt, danach möchte der Kunde ein Neudesign. Die Geschäftsrichtung ändert sich, es kommt zur Integration von Zahlungsmethoden, anschließend zur LINE-Automatisierung und schließlich zu einem verwandten Projekt. Finanziell gesehen kann bereits eine Aufgabe abgeschlossen und in Rechnung gestellt werden, während die umfassendere Zusammenarbeit noch andauert. Wartungsverträge sind noch ungewöhnlicher, denn viele laufen einfach weiter, bis der Kunde sagt, er brauche sie nicht mehr.

Ein einzelnes Statusfeld reicht dazu nicht aus. Mehrere unabhängige Statusdimensionen hingegen schon:

billing_status = closed
task_status = active
invoice_status = pending

Wenn man es gemeinsam liest, heißt das, dass der Betrag festgelegt ist, die Aufgabe noch aktiv ist und die Rechnung noch nicht versandt wurde. Andernfalls wären zwanzig manuell definierte Kombinationszustände erforderlich gewesen. Unabhängige Felder halten das Modell klein.

Trennung der Verantwortlichkeiten

Nach einigen Tagen des Nachdenkens ergab sich eine Schichtungsregel:

Raw Data
   ↓
Small Logic
   ↓
Secondary Data
   ↓
END

Primäre Daten enthalten Fakten. Sekundäre Daten enthalten berechnete oder transformierte Informationen, die für den menschlichen Blick bestimmt sind. Es gilt eine klare Regel: Es dürfen keine tertiären Daten geben. Eine sekundäre Tabelle darf niemals eine weitere Berechnung auslösen. Wenn ein neues Ergebnis benötigt wird, muss die Arbeit wieder bei den Rohdaten beginnen, um eine weitere sekundäre Datensammlung zu erzeugen. Das kann letztendlich viele sekundäre Tabellen bedeuten – und das ist akzeptabel. Zwanzig unabhängige Ansichten sind besser als eine solche Kette:

Raw
 ↓
Secondary A
 ↓
Secondary B
 ↓
Secondary C
 ↓
Dashboard

Denn ein einziger Fehler im Mittelteil breitet sich überall aus. Das Funktionsprinzip ist, dass mehr Arbeitsblätter in Ordnung sind, aber tiefere Abhängigkeiten nicht.

Ein strenges Layout der Arbeitsmappe

Die Arbeitsblätter werden nach Verantwortungsbereichen geteilt, wobei eine Präfixkonvention verwendet wird:

D_ = Raw Data
M_ = Master Data
S_ = System Rules
V_ = Secondary Views

Die Rohdatenblätter sehen so aus:

D_Task
D_Point
D_Pharmacy

und die Master-Tabellen so:

M_Company
M_Project
M_Contact
M_Product
M_GroupS_SystemV_TaskList
V_MonthlyBilling
V_CurrentSummary

Die D_-Tabellen sind die Quelle der Wahrheit. Die M_-Tabellen sind Geschäftslexika, die Unternehmen, Produkte, Projekte und Kontakte umfassen. S_System speichert die für VBA spezifische Konfiguration: die Steuerquote, die Bedeutung jeder Statusart, die Stundensatz sowie die Einkommensziele. Tabellen mit dem Präfix V_ sind vorübergehende Ausgabe-Dokumente. Jede von ihnen kann nach Bedarf neu erstellt werden, und sie dienen dazu, von Menschen gelesen zu werden, nicht damit andere Formeln darauf vertrauen können.

Keine direkten Änderungen

Es gilt außerdem eine weitere Regel: Im normalen Betrieb sollte niemand je Rohdaten oder Haupttabellen manuell bearbeiten müssen. UserForms kümmern sich um das Erstellen, Aktualisieren und logische Löschen von Datensätzen. Das Löschen erfolgt nicht physisch, sondern ein Datensatz wird stattdessen markiert:

record_status = deleted

Die Zeile bleibt im System, was die Nachverfolgung der Historie erleichtern und zufällige Datenverluste vermeiden sollte.

VBA als Beobachtungstool

An diesem Punkt änderte sich die gesamte Struktur des Projekts. Ursprünglich sollte VBA den Arbeitsablauf automatisieren. Eine bessere Rolle könnte darin bestehen, ihn zu beobachten. Das System kann den erwarteten Projektumsatz sowie den erwarteten Umsatz des Apothekers berechnen, wie viel zusätzlicher Umsatz noch benötigt wird, was bei jedem Projekt übrig bleibt, welche Rechnungen noch nicht versandt wurden, wo sich jedes Projekt befindet und wie viele Punkte bereits verbraucht wurden.

Wenn man sich diese Zahlen ansieht, führt das zu Entscheidungen, wie zum Beispiel der Schluss, dass im nächsten Monat keine zusätzlichen Apothekerschichten benötigt werden. Wenn man Merge fragt, wie diese Entscheidung getroffen wurde, lautet die ehrliche Antwort heute etwas wie „Erfahrung“. Genau deshalb ist die Entscheidungsfindung noch nicht automatisiert. Das System sollte stets dieselben Informationen anzeigen, und nach ausreichendem tatsächlichen Einsatz könnten Muster in den Entscheidungen sichtbar werden. Diese Muster können anschließend in Python und schließlich im Agenten verarbeitet werden. Die mögliche Entwicklung:

Raw Data
   ↓
Python Logic
   ↓
Secondary Information
   ↓
AI Agent
   ↕
Human adjustment through Slack

Die VBA-Version ist also nicht unbedingt die endgültige Anwendung. Sie dient als Labor, um herauszufinden, was die endgültige Anwendung wissen muss.

Andere Tools, unterschiedliche Aufgaben

Alles in ein einziges System zu zwingen, wäre ein Fehler. Excel umfasst Zahlen, Rechnungen, Statusangaben, Aufzeichnungen und finanzielle Übersichten. Notion enthält detaillierte Aufgaben, Notizen und Projektinformationen. Eine physische Tafel dient dazu, Dinge zu notieren, an die man sich erinnern oder die man beachten muss.

Das langfristige Konzept kombiniert zwei Ansätze: einen in Form eines Berichts und einen in Form einer Zeitlinie, wobei Merge im Slack als Hauptplattform für die Kommunikation dient. Ein physisches Merge-Gerät könnte später wichtige Slack-Nachrichten mithilfe von Sprachsynthese laut vorlesen. Anfangs würde es nur Ausgaben liefern, wobei Antworten im Slack eingegeben werden, da die Spracherkennung im Freien unpraktisch ist und frühere Experimente zu unnatürlich lauter Sprache am Computer führten. Für direkte Sprachgespräche mit dem physischen Gerät käme wieder ein Raspberry Pi zum Einsatz.

Die Benutzeroberfläche verwandelt sich in eine Tafel

Nach Tagen voller Diskussionen über Architektur begann die Arbeit an dem ersten UserForm, das Gruppen, Unternehmen, Projekte, Kontakte und Produkte verwalten soll. Anfangs galt es nur als Werkzeug für den persönlichen Gebrauch, und das Aussehen spielte keine Rolle. Später wurde eine lustige Schriftart ausgewählt, der Hintergrund geändert, weiße Trennlinien hinzugefügt – so verwandelte sich das ursprünglich ernste Formular für Masterdaten in eine Tafelähnliche Benutzeroberfläche. Merge fand, es erinnere an MergeLab, während die ehrliche Reaktion war, dass es irgendwie sympathisch sei.

Intern gelten strenge Regeln: Abhängigkeiten, Eigentumsverhältnisse zu Rohdaten, logische Löschung sowie ein Verbot von sekundären Daten. Visuell erinnert die Oberfläche an jemanden, der mitten in der Nacht an einer Tafel die Normalisierung von Datenbanken erklärt. Die VBA-Funktionen funktionieren immer noch nicht, aber zumindest ist die Tafeloberfläche konsistent.

Lektionen

Die wichtigste Lektion ist, dass die Automatisierung nicht mit der Automatisierung beginnen sollte. Zuerst muss geklärt werden, welche Informationen faktisch sind, welche abgeleitet wurden und welche Entscheidungen weiterhin auf menschlichem Urteilsvermögen beruhen.

Weniger Tabellen bedeutet nicht automatisch weniger Komplexität. Viele unabhängige, sekundäre Ansichten können einfacher zu verstehen sein als eine kompakte Struktur mit langen Ketten abgeleiteter Daten.

Zustände unterschiedlicher Art gehören in unterschiedliche Felder. Anstelle vieler kombinierter Zustände können unabhängige Felder weitaus komplexere tatsächliche Situationen beschreiben:

task_status
billing_status
invoice_status
record_status

Die Geschäftslogik sollte sich von der Benutzeroberfläche fernhalten. Ein UserForm sammelt Eingaben und ruft wiederverwendbare Logiken auf, die Arbeitsmappe löst Aktualisierungen aus und zeigt Ergebnisse an, während die Berechnungen in kleinen, wiederverwendbaren Modulen stattfinden. Dadurch wird ein späterer Umzug des Prototyps erleichtert.

Vor allem kann der Prototyp versteckte Entscheidungsregeln offenlegen. Er muss nicht bereits heute jede Entscheidung treffen – es genügt, diese Entscheidungen sichtbar zu machen.

Nächste Schritte

Die unmittelbare Aufgabe besteht darin, das VBA dazu zu bringen, etwas zu tun, angefangen bei MasterManagementForm, das Gruppen, Unternehmen, Projekte, Kontakte und Produkte registriert und verwaltet. Sein grundlegender Ablauf ist folgender:

Input
 ↓
Validation
 ↓
Generate ID
 ↓
Create / Update / Logical Delete
 ↓
Master Data

Sobald die Masterdaten funktionieren, folgen separate Eingabeformulare für die Rohblätter:

D_Task
D_Point
D_Pharmacy

Danach können die ersten sekundären Ansichten erstellt werden. Die wichtigsten im Moment:

V_TaskList
V_MonthlyBilling
V_CurrentSummary

Sobald diese Lösungen in der Praxis einsetzbar sind, wird klar werden, welche Ansichten tatsächlich geöffnet werden und welche nur imaginiert waren. Erst wenn dieser Workflow stabil ist, wird eine ordentliche Neuentwicklung mit Python, Slack-Integration und einem KI-Agenten zu einer ernsthaften Option.

Die bisherige Abfolge war: Ein Versuch, einen mit RAG ausgestatteten Agenten zu entwickeln, anschließend Excel, dann mehrere Tage damit, Datengrenzen zu definieren, und schließlich ein Blackboard. Die Softwareentwicklung verläuft gut.