Von den vier vorgestellten Demonstratoren nimmt dieser Teil einen näher unter die Lupe: Den Assistenten für Nachverfolgbarkeit, der die Traceability über Anforderungen, Komponenten, Tests und Testergebnisse hinweg ermöglicht. An einem konkreten Fall zeigt er, wie aus einer Frage in natürlicher Sprache eine belegbare Antwort wird und beschreibt dabei zugleich den methodischen Kern, auf dem die weiteren Anwendungen dieses Kapitels aufsetzen.
Die Frage und die Datenlage
Als Beispiel dient ein öffentlicher Datensatz aus der Entwicklung des Mars-Rovers, eines Fahrzeugs mit vielen Subsystemen und dokumentierten Anforderungen, Komponenten, Tests und Testergebnissen. Ein*e Ingenieur*in fragt: „Der Rover hat bei einer Erprobungsfahrt einen Fehler in der Fortbewegung gemeldet. Was war die Ursache, und welche Subsysteme tragen die Verantwortung?“ Die Frage klingt einfach, aber die Datenlage ist es nicht. Die Antwort steht in keinem einzelnen Dokument, sondern muss aus mehreren Quellen zusammengesucht werden.
Was von Hand lange dauert, wird hier zu einem geführten, wiederholbaren Suchprozess, nicht, weil der Assistent schlauer wäre, sondern weil er systematischer arbeitet. Der Ablauf hat drei Phasen: Planen, Ausführen, Antworten.
Phase 1: Die richtige Reihenfolge planen
Der erste Schritt ist ausdrücklich nicht, eine Antwort zu erzeugen. Der Assistent betrachtet zuerst das Beziehungsmodell der Datenbasis, bei dem es sich im Kern um einen Graphen aus typisierten Objekten und Verknüpfungen handelt: Welche Arten von Informationen gibt es, z.B. Anforderungen, Komponenten, Tests, Testergebnisse, und welche Verknüpfungen gibt es zwischen ihnen - im Sinne von prüft, gehört zu oder ist fehlgeschlagen bei? Daraus entsteht ein Suchplan, der vorgibt, welche Daten in welcher Reihenfolge herangezogen werden müssen, um die Frage später belegbar beantworten zu können.
Das Bemerkenswerte daran ist, dass nichts davon die Antwort ist. Der Assistent hat noch kein Wissen über den tatsächlichen Fehler, sondern nur einen Plan, wie er ihn finden würde. Und dieser Plan ist einsehbar, bevor ein einziges System abgefragt wird, eine Eigenschaft, die erst der fest beschriebene Ablauf möglich macht. Damit ist vor der ersten Suche klar, welche Spur der Assistent bei der Bearbeitung verfolgen wird.
###Bild3###
Phase 2: Die kombinierte Suche ausführen
Wo die Daten bereits feste Verknüpfungen enthalten wie bei einer Anforderung, die direkt mit einem Test verbunden ist, folgt der Assistent diesen Verweisen. Solche direkten Verweise gibt es in industriellen IT-Systemen, aber sie sind selten vollständig.
Der eigentliche Wert entsteht dort, wo sie fehlen. Dann bildet das Modell aus dem jeweiligen Plan-Schritt mehrere gezielte Suchanfragen mit unterschiedlichem Begriffsschwerpunkt. Diese laufen durch dieselbe hybride Suche aus wort- und bedeutungsbasierten Wegen mit einem zusammengeführten Ranking, wie in Kapitel 2 beschrieben. Bleibt die Trefferliste zu unscharf, prüft ein weiterer, eng umrissener KI-Schritt sie gegen die ursprüngliche Frage und sortiert Unpassendes aus.
Entscheidend bleibt die Rollenverteilung: Das Modell beantwortet nichts. Es formuliert Suchanfragen, bewertet Relevanz und wählt aus. Jede Teilaufgabe bleibt klein und überprüfbar, und auch die Wiederholung bleibt Teil des beschriebenen Ablaufs: Ob weiter gesucht wird, ergibt sich aus den geprüften Zwischenergebnissen und nicht aus freier Entscheidung des Sprachmodells.
Phase 3: Die Aufbereitung der Nachweiskette
Vor der eigentlichen Antwort steht ein letzter, unscheinbarer, aber zentraler Schritt: Die Aufbereitung des Materials. Es wäre naheliegend und falsch, dem Sprachmodell die rohe Trefferliste zu übergeben, denn dann müsste es die Zusammenhänge im Text selbst rekonstruieren: Welche Komponente zu welcher Anforderung gehört, welcher Test welche Komponente prüft etc. Das ist die Art von Aufgaben, bei der Sprachmodelle unauffällige Fehler machen.
Stattdessen wird die Treffermenge zuerst in eine klare Struktur gebracht: Anforderungen stehen oben, die zugehörigen Komponenten darunter, darunter die passenden Tests und Testergebnisse. Die Struktur der Darstellung zeigt damit bereits den fachlichen Zusammenhang, so dass das Modell ihn nicht erraten muss.
Zusätzlich trägt jeder Befund einen Verweis auf seine Quelle im Originalsystem. Diese Verweise erscheinen unverändert in der fertigen Antwort, sodass die Ingenieur*innen aus jeder einzelnen Aussage zurück zur Datenquelle springen können. Erst auf dieser geordneten Vorlage formuliert das Modell die Antwort, indem es die Befunde in eine lesbare Erklärung gießt, ohne neue Inhalte hinzuzufügen. Die Antwort ist damit nicht nur lesbar, sondern jederzeit nachprüfbar.
###Bild4###
Die ehrliche Grenze
Trotzdem lohnt der ehrliche Blick auf die Grenzen, und die erste ist eigentlich eine Stärke. Wo feste Verknüpfungen auf Datenbankebene fehlen, gibt sich der Assistent nicht geschlagen. Genau dort stellt die inhaltliche Suche die Verbindung her, nicht mit der Sicherheit eines gepflegten Verweises, aber mit relativ hoher Zuverlässigkeit und mit entsprechender Kennzeichnung: Die Verbindung war fest nicht vorhanden, sondern wurde rekonstruiert. Die Ingenieur*innen sehen damit nicht nur, dass eine Lücke besteht, sondern bekommen einen belegten Vorschlag, wie sie zu schließen ist. Das ist deutlich wertvoller, als nur zu zeigen, dass etwas fehlt. Dieses Rekonstruieren fehlender Beziehungen über den Graphen ist die eigentliche Stärke des Traceability-Assistenten, eine Fähigkeit, die nur dort greift, wo überhaupt ein Beziehungsgefüge aus Objekten und Verweisen existiert.
Die eigentliche Grenze liegt dahinter: Wo die Daten inhaltlich nichts Verwandtes hergeben, erfindet der Assistent nichts, sondern meldet die Lücke. Rekonstruierte Verbindungen bleiben Vorschläge, als solche markiert, und sind kein Ersatz für einen geprüften Verweis, bevor ein Mensch sie bestätigt. Der Assistent heilt die Daten also nicht heimlich, sondern schließt Lücken sichtbar, belegt und macht zugleich die Qualität der vorhandenen technischen Daten unbestreitbar sichtbar. Typische KI-Fehler wie falsches Verknüpfen über ähnliche Bezeichner oder verlorene Quellen werden damit nicht unmöglich, aber systematisch erschwert: Jede Aussage muss durch Struktur und Quelle getragen sein.
Damit ist der gemeinsame methodische Kern beschrieben: Planen, kombinierte Suche und quellgebundene Aufbereitung, mit klarer Rollenverteilung zwischen dem festen Ablauf und der punktuell eingesetzten KI. Der nächste Teil dieses Kapitels überträgt ihn in einen ganz anderen Bereich, die Analyse von Verträgen und Lastenheften. Gerade der Kontrast ist der stärkste Beleg dafür, dass die Methode verallgemeinerbar ist.
