AI-Agent zur Überprüfung technischer Spezifikationen: Entwicklung, Architektur, Praxis

KI-Agent für die Prüfung technischer Spezifikationen: Praxisnahe Erkenntnisse

Die Entwicklung eines Machine-Learning-Tools für automatisierte Überprüfungen technischer Spezifikationen erfordert eine klare Strategie und Einblicke in gängige Fallstricke. Unser Praxistest hat gezeigt, dass der Erfolg von hochwertigen Trainingsdaten und einer hybriden Architektur abhängt, die große Sprachmodelle (LLMs) mit klassischen Algorithmen kombiniert.

Aufbau des Trainingsdatensatzes

Der erste und wichtigste Schritt war das Sammeln und Beschriften von Daten. Wir haben einen repräsentativen Datensatz mit 90 technischen Spezifikationen erstellt, aufgeteilt in drei Kategorien:

• Hochwertige Specs (30 Beispiele), die die Entwicklung mit minimalen Änderungen gemeistert haben.
• Problematische Specs (30 Beispiele), die Konflikte, Nacharbeiten und verpasste Fristen auslösten.
• Durchschnittliche Specs (30 Beispiele), die funktionierten, aber Mängel aufwiesen, die erst in der Entwicklung auffielen.

Jede Spec war mit einer detaillierten Analyse eines Experten versehen, die Stärken und Schwächen hervorhob. Um Vielfalt zu schaffen, haben wir Specs von verschiedenen Autoren und Projekten aus Branchen wie Einzelhandel, Fertigung und Dienstleistungen einbezogen.

Klassifikation gängiger Spec-Fehler

Die Analyse problematischer Specs hat systematische Probleme aufgezeigt, die unser Agent erkennen muss. Wichtige Kategorien:

• Nur positive Szenarien. Die Anforderung beschreibt den Happy Path, vernachlässigt aber Fehlerbehandlung, Randfälle und Ausnahmen.
• Undeutliche Formulierungen. Subjektive oder schwammige Begriffe wie „schnell“, „benutzerfreundlich“ oder „flexibel“ ohne messbare Kriterien.
• Untestbare Anforderungen. Kein klarer Weg, um definitive Testfälle zur Verifizierung zu erstellen.
• Interne Widersprüche. Inkonsistenzen zwischen Abschnitten oder Klauseln innerhalb derselben Spec.
• Fehlende Randfälle. Keine Angaben zum Systemverhalten bei extremen oder ungewöhnlichen Eingaben.

Beispiele: Untestbare Anforderungen testbar machen

Typische vage Aussagen und wie man sie konkretisiert:

• Original: „Benutzer sollen Berichte flexibel anpassen können.“

Konkret: „Berichte bieten anpassbare Einstellungen: Datumsbereich (beliebiger Intervall), Gegenpartei (Mehrfachauswahl). Einstellungen werden pro Benutzer gespeichert. Gruppierungsoptionen nach Gegenpartei und Lager einbeziehen.“

• Original: „Das System muss große Datenmengen korrekt verarbeiten.“

Konkret: „Das Laden von 10.000 Dokumenten mit insgesamt 500.000 Zeilen muss in unter 15 Minuten abgeschlossen sein. Speicherverbrauch begrenzt auf 2 GB.“

• Original: „Alle Bildschirmformulare müssen ein einheitliches Design haben.“

Konkret: „In allen Dokumentenformularen befinden sich die Schaltflächen ‚Speichern‘ und ‚Buchen‘ oben rechts. Schaltflächenfarbe: grün (R=0, G=128, B=0). Schriftart: Arial, 10 Pt.“

Qualitätskriterien und Agent-Architektur

Wir haben eine Checkliste für die Bewertung von Specs definiert, die Geschäftsziele, Szenarienvollständigkeit, Klarheit, Testbarkeit, Konsistenz und Machbarkeit abdeckt. Diese bildeten die Grundlage für die Prompts und Logik des Agents.

Die Lösung nutzt ein hybrides Modell, das Retrieval-Augmented Generation (RAG) mit Entscheidungsbaum-Klassifikation kombiniert.

• RAG-Komponente übernimmt kontextbasierte Suche. Bei der Prüfung einer neuen Anforderung holt der Agent semantisch ähnliche Ausschnitte aus der Wissensbasis (90 beschriebene Specs), um gängige Fehler und ihre Kontexte zu erinnern.
• Entscheidungsbäume kategorisieren Fehler anhand strukturierter Merkmale. Der LLM-Agent parst zuerst den Rohtext in strukturierte Merkmale (z. B. JSON), die dann in den Klassifizierer eingespeist werden.

Technische Umsetzung der Analyse

Die Prüfung einer einzelnen Anforderung verläuft in diesen Schritten:

• Merkmalsextraktion: Ein LLM-basierter Analysator wandelt den Text in einen Merkmalsvektor um. Beispiele:

* has_numbers: 1 (enthält numerische Angaben) oder 0.

* has_negative_keywords: 1 (erwähnt „if“, „else“, „Fehler“) oder 0.

* boundary_conditions_mentioned: 1 (deckt Randfälle ab) oder 0.

* stopword_score: Gewichtung subjektiver Marker („flexibel“, „intuitiv“).

• Klassifikation: Der strukturierte Merkmalsvektor wird einem Entscheidungsbaum-Modell (z. B. aus Scikit-learn) zugeführt, das ihn einer Fehlerkategorie zuordnet oder als solide markiert.
• Berichtserstellung: Der Agent erzeugt einen detaillierten Kommentar, der den Fehlertyp, die Stelle im Text und Korrekturvorschläge aus Wissensbasis-Analogien benennt.

Diese Aufteilung – LLM für semantisches Verständnis und Datenauszug, Klassifizierer für starre Logik – gewährleistet Transparenz und Kontrolle.

Wichtigste Erkenntnisse

• Datenqualität ist entscheidend. Ohne repräsentativen, gut beschriebenen Datensatz (mindestens Dutzende Beispiele) ist effektives Training unmöglich.
• Hybrid schlägt reines LLM. Die Kombination aus RAG für Kontext und Entscheidungsbäumen für präzise Klassifikation liefert zuverlässigere, erklärbare Ergebnisse.
• Testbarkeit priorisieren. Eine gute Spec ermöglicht eindeutige Testfälle. Alle Anforderungen müssen messbar und spezifisch sein.
• Routine automatisieren. Der Agent ersetzt keine Analysten, sondern dient als frischer Blick, der systematisch gängige Fehler aufspürt, Zeit spart und menschliche Fehler minimiert.
• Weiterlernen. Regelmäßige Updates der Wissensbasis mit neuen Specs und Analysen steigern die Genauigkeit und passen den Agent an neue Projekttypen an.

— Editorial Team