# Ein 0-1 AI-Support für komplexe Fachsoftware

Das Verständnis des Programms muss für den Agenten zunächst von 0 erzeugt werden. Der schnellste Weg, um einen KI-Support Chat mit einem tatsächlichen Verständnis für das Programm zu entwickeln, ist es, den Source-Code zur Grundlage zu nehmen. Source-Code hat gegenüber Dokumentation den Vorteil, dass er aktuell ist und die Änderungen zwischen Versionsständen nachvollziehbar sind.

Obwohl der Quellcode bei diesem Fuse-Projekt in einer alten und heutzutage selten verwendeten Programmiersprache entwickelt wurde, konnte die Programmlogik von Sprachmodellen mit mehr als 50% Score im Artificial Analysis Intelligence Index bestens verstanden werden. In den Bezeichnern des Quellcodes (Variablen, Funktionen, usw.) ist nutzbares implizites Wissen zur Anwendungsdomäne enthalten. Daher nutzen wir ein Glossar mit Erklärungen zu anwendungsspezifischen Fachbegriffen, um das Kontextverständnis für die KI zu verbessern.

Auf Grundlage des Quellcodes bauen wir eine Dokumentation der gesamten Funktionalität des Programms in Markdown auf. Diese funktionale Dokumentation ist für uns ein Cache des Verständnisses der KI des Quellcodes. Pro Teilmenge des Programms muss der Agent nur einmalig Tool-Calls machen und die Funktionalität in den fachlichen Kontext bringen.

Zudem ist die funktionale Dokumentation das Layer, welches der spätere Chat zur Grundlage für RAG nimmt, u.a. für die Vektordatenbank sowie für Keyword-Search.

Für die funktionale Dokumentation und die entsprechenden Teilschritte der KI zu dessen Erstellung muss eine sinnvolle Struktur gewählt werden. In diesem Fall haben wir uns für eine Dokumentation je Programmoberfläche entschieden.

Pro Programm-Oberfläche soll ein KI-Agent eine Markdown-Datei nach einer vorgegebenen Struktur erstellen.

Beispiel:

Für die Erstellung einer vollumfassenden Dokumentation kommen drei Agenten zum Einsatz: Navigator, Schreiber und Prüfer. Der Navigator hat die Aufgabe, die Quellcode-Dateien der Ansicht herauszusuchen und daraus für alle in der Struktur vorgegebenen Aspekte Befunde zu erstellen. Der Schreiber erstellt alleine aus den Ergebnissen des Navigators die Dokumentation der Ansicht und speichert sie ab. Der Prüfer analysiert die korrekte Gliederung sowie die vollständige Beschreibung aller Befunde. Um Halluzinationen vorzubeugen, sind die Aufgaben der drei Agenten strikt getrennt.

Tools:

• -Datei lesen
• -Datei schreiben
• -Bash Kommando ausführen
• -Befunde strukturiert ablegen
• -Fachbegriffe im Glossar nachschlagen
• -Menüstruktur aus Datenbank abfragen
• -Tabelle mit allen Eingabefeldern anlegen
• -Muster-Suche für Sperrregeln, Meldungen, Berechtigungen auf Ansicht und Objektebene
• -Nachschlagen der Bedeutung einer Variablen in der Datenbankdokumentation

Tools:

• -Dokumentation ablegen
• -Git Commit erzeugen

Tools:

• -Datei lesen
• -Aussagen anhand des Quellcodes prüfen
• -Glossar und Datenbankdokumentation zum Prüfen der korrekten Beschreibung

Ein Skript beschreibt den Ablauf des Dokumentationslaufs für eine Ansicht: Zuerst ist der Navigator aktiv und erzeugt Befunde. Der Schreiber erstellt den ersten Entwurf der Beschreibung der Ansicht. Der Prüfer analysiert die Beschreibung. Bei einer vollständigen Beschreibung ist die Dokumentation der Ansicht abgeschlossen, ansonsten sind bis zu zwei Nachrunden erlaubt, in denen jeweils der Schreiber basierend auf der letzten Lückenliste die vorherigen Fehler beheben darf.

Ein Claude Code Agent überwacht den Lauf über alle zu dokumentierenden Ansichten. Zusätzliche Aufgaben umfassen die Optimierung der API Auslastung, das Neustarten fehlgeschlagener Durchläufe sowie Fortschrittsanzeigen bzgl. des erwarteten Fertigstellungszeitpunkts.

Als Harness haben wir uns für Pi (pi.dev) entschieden, um die volle Kontrolle zu behalten. Je nach Agent bzw. Aufgabengebiet wurden unterschiedliche Tools und Prompt-Anweisungen eingesetzt. Einzig der Runner wird von Claude Code betreut.

Wir haben das Open-Weights Modell DeepSeek V4 Flash 0731 gewählt, da die Qualität der Beschreibungen gut ist und das Modell ein gutes Kosten-Nutzen-Verhältnis hat.

Spannender als die Wahl des Sprachmodells war die Wahl des API Providers. Folgende Kriterien haben sich als besonders wichtig herausgestellt:

• -Sprachmodell Verfügbarkeit
• -Serverstandort
• -DSGVO Konformität
• -Hartes Kostenlimit einstellbar
• -Limitierungen der API in Token/Minute und Anfragen/Minute
• -Preis
• -Caching vorhanden (relevant für Preis)

Die erzeugten Beschreibungen der Ansichten werden zur Beantwortung von Fragen von Benutzern aus einem Chat-Interface benutzt. Das Backend dazu wird durch einen Retrieval Pi Agent gesteuert.

Tools:

• -Wissen suchen über RAG-Pipeline
• -Rechteauskunft
• -Glossar

Für das Abfragen von Beschreibungen wird eine Vektordatenbank zur Suche von inhaltlich ähnlichen Texten verwendet. Da ohnehin PostgreSQL als Datenbank der Anwendung eingesetzt wird, wurde die pgvector-Extension als Vektordatenbank verwendet. In Vektordatenbanken werden Textschnipsel gespeichert und die Zuschneidung der Chunks wurde anhand der Markdown Überschriften vorgenommen. Als Embedding Technologie wurde TEI mit BGE-M3 eingesetzt und alle erzeugten Dokumentationen indexiert. Als Kreuzkodierer wird bge-reranker-v2-m3 auf TEI eingesetzt.

Fragen können auch von einem Agenten beantwortet werden, der direkt selbst in der Codebasis sucht und die weiteren genannten Werkzeuge benutzen darf. Dieser Ansatz wurde aufgrund der höheren Antwort-Wartezeit und höheren zu erwartenden Betriebskosten abgewählt.

Jede Programm-Ansicht wurde vollständig von einem KI-Agent dokumentiert. Dafür wurde ein Katalog an zu beschreibenden Aspekten vorab definiert. Programmiersprachenspezifische Werkzeuge zum Parsen wurden definiert, die dem KI-Agent bei der Erstellung der Dokumentation helfen. In einem iterativen Prozess wird die Beschreibung der Programm-Ansicht ausgebaut, auf Vollständigkeit geprüft und weiter ausgebaut.

Der Zugriff auf das gespeicherte Wissen erfolgt über hybrides RAG mit BGE-M3 Embedding auf TEI. Als Kreuzkodierer wird bge-reranker-v2-m3 auf TEI eingesetzt. Die Ergebnisse bei der Abfrage über eine starre hybrid Retrieval RAG-Pipeline konnten durch den Einsatz eines pi.dev Agents weiter optimiert werden: Der Agent erhält die Retrieval Pipeline als ein Tool zum Wissen suchen. Zusätzlich bekommt der Agent ein Tool zum Abfragen von Rechten, um Fragen im Kontext des Benutzers beantworten zu können. Anhänge werden über ein weiteres Tool verarbeitet.