💻 computer science

KBSpec: LLM-driven Formal Specification Generation with Evolving Domain Knowledge Base

KBSpec ist ein LLM-gestütztes Framework, das formale Spezifikationen generiert, indem es eine selbstentwickelnde Wissensbasis aus externer Dokumentation und internem Verifizierer-Feedback nutzt, wodurch signifikante Verbesserungen der Verifizierungs-Passraten ohne die Notwendigkeit von Parameterabstimmung oder gelabelten Trainingsdaten erreicht wird.

Ursprüngliche Autoren: Wenhan Wang, Zeyu Sun

Veröffentlicht 2026-06-23

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Wenhan Wang, Zeyu Sun

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Das große Ganze: Einem Roboter beibringen, rechtliche Verträge für Code zu schreiben

Stellen Sie sich vor, Sie haben einen sehr intelligenten, kreativen Roboter (ein Large Language Model oder LLM), der hervorragend darin ist, Geschichten und Code zu schreiben. Sie möchten jedoch, dass dieser Roboter formale Spezifikationen schreibt – das sind wie strenge, mathematische rechtliche Verträge, die beweisen, dass eine Software niemals abstürzt oder sich schlecht verhält.

Das Problem ist, dass der Roboter bisher kaum solche „rechtlichen Verträge“ gelesen hat. In der realen Welt schreiben die meisten Programmierer keine solchen Verträge, sondern nur den Code. Wenn Sie den Roboter also bitten, einen zu schreiben, macht er oft Fehler: Er verwendet die falsche Grammatik, vergisst wichtige Sicherheitsregeln oder schreibt etwas, das zwar gut klingt, aber mathematisch gesehen unmöglich zu beweisen ist.

KBSpec ist ein neues System, das genau dieses Problem lösen soll. Es gibt dem Roboter ein „smartes Notizbuch“, das ihm hilft, zu lernen, wie man diese Verträge korrekt schreibt, ohne dass man das Gehirn des Roboters neu trainieren muss.

Das Zwei-Quellen-Wissenssystem

Die Arbeit argumentt, dass man zwei Arten von Informationen benötigt, um den Roboter zu verbessern – wie ein Schüler, der für eine schwierige Prüfung lernt:

Das Lehrbuch (Externes Wissen): Dies ist das offizielle Handbuch, geschrieben von den Experten, die die Sprache entwickelt haben. Es erklärt dem Roboter die grundlegenden Regeln und die Grammatik.
- Analogie: Stellen Sie sich vor, Sie geben dem Roboter ein Wörterbuch und ein Grammatikbuch. Er kennt die Wörter, weiß aber noch nicht, wie er sie in kniffligen Situationen anwendet.
Die Notizen des Coaches (Internes Wissen): Dies ist der einzigartige Teil von KBSpec. Dieses Wissen entsteht dadurch, dass man beobachtet, wie der Roboter versucht, scheitert, korrigiert wird und es erneut versucht.
- Analogie: Stellen Sie sich vor, der Roboter versucht, einen Vertrag zu schreiben, und ein strenger Schiedsrichter (ein Formal Verifier) bläst die Pfeife und sagt: „Fehler! Das darfst du nicht!“ Der Roboter versucht es dann erneut, behebt den Fehler und hat Erfolg. KBSpec speichert diese „Erfolgsgeschichte“ im Notizbuch. Wenn der Roboter das nächste Mal nachschlägt, kann er sagen: „Oh, ich erinnere mich! Als ich X versucht habe, wurde der Schiedsrichter sauer, aber wenn ich stattdessen Y mache, funktioniert es.“

Wie KBSpec funktioniert (Die 3-Schritte-Pipeline)

Die Arbeit beschreibt einen dreistufigen Prozess, um dieses System aufzubauen:

Schritt 1: Die Ersteinrichtung (Das Notizbuch füllen)
Die Forscher beginnen damit, die offiziellen Handbücher und Beispiele in das „Notizbuch“ (die Wissensbasis) des Roboters einzufügen. Dies gibt dem Roboter einen grundlegenden Ausgangspunkt.

Schritt 2: Die Trainingsschleife (Lernen durch Tun)
Hier geschieht die Magie. Das System durchläuft eine Schleife viele Male:

Der Roboter versucht, eine Spezifikation für einen Stück Code zu schreiben.
Der Verifier (der Schiedsrichter) prüft diese.
Wenn sie besteht: Das System speichert das „Rezept“ des Erfolgs im Notizbuch.
Wenn sie fehlschlägt: Das System schaut sich die Fehlermeldung an, bittet das Notizbuch um Hilfe und versucht, den Fehler zu beheben. Wenn die Korrektur funktioniert, wird auch dieses „Reparatur-Rezept“ gespeichert.
Der Filter: Das Notizbuch ist nicht einfach ein Haufen Papier. Das System prüft ständig: „Hat dieser Rat tatsächlich geholfen, den Test zu bestehen?“ Wenn ein Ratschlag aus dem offiziellen Handbuch zu einem Fehlschlag führt, wird er herabgestuft. Wenn ein neuer Trick, der durch eine Reparatur gelernt wurde, funktioniert, wird er hochgestuft.

Schritt 3: Die Abschlussprüfung (Inferenz)
Wenn der Roboter mit einem neuen, unbekannten Stück Code konfrontiert wird, rät er nicht einfach. Er sucht im entwickelten Notizbuch nach den relevantesten „Rezepten“, um ihm beim Schreiben der Spezifikation zu helfen. Er nutzt die Lektionen aus vergangenen Fehlern, um dieselben Fehler nicht zu wiederholen.

Warum das besonders ist

Die Arbeit hebt einige Kernpunkte hervor, die KBSpec von anderen Methoden unterscheidet:

Keine Gehirnoperation: Normalerweise muss man, um eine KI besser zu machen, ein „Fine-Tuning“ durchführen, was einer teuren Gehirnoperation am Modell gleicht. KBSpec rührt das Gehirn des Roboters gar nicht an. Es aktualisiert lediglich das Notizbuch. Das macht es kostengünstig und einfach einsetzbar bei jedem Roboter.
Das „selbstentwickelnde“ Notizbuch: Das Notizbuch ist nicht statisch. Es wird klüger, jedes Mal, wenn der Roboter übt. Es lernt, welche Regeln aus dem offiziellen Handbuch tatsächlich nützlich sind und welche zu komplex sind, um vom Schiedsrichter akzeptiert zu werden.
Bessere Ergebnisse: Als die Forscher dies an Java-Code testeten (mit einem Benchmark namens FormalBench), half KBSpec dem Roboter, die Verifikationstests 10 % bis 25 % häufiger zu bestehen als die besten bisherigen Methoden. Es erzeugte auch mehr Spezifikationen, die nicht nur „korrekt“, sondern auch „vollständig“ waren (also alle notwendigen Details abdeckten).

Der Haken (Was die Studie herausfand)

Die Forscher bemerkten etwas Interessantes bezüglich der „Vollständigkeit“ der Verträge. Manchmal musste das System den Vertrag etwas weniger streng gestalten (z. B. „Dies funktioniert für die meisten Zahlen“ statt „Dies funktioniert für jede Zahl“), um den Roboter dazu zu bringen, den Test zu bestehen.

Analogie: Es ist wie ein Anwalt, der erkennt: „Wenn ich dem Klienten den Mond verspreche, werde ich verklagt. Aber wenn ich ihm einen sehr großen, sehr sicheren Garten verspreche, kann ich beweisen, dass das wahr ist.“
Die Studie fand heraus, dass während die durchschnittliche Strenge leicht sank, das System mehr Verträge generierte, die tatsächlich nützlich und verifizierbar waren. Es tauschte ein kleines Stück Perfektion gegen viel mehr Erfolg ein.

Zusammenfassung

KBSpec ist wie ein Schüler, der sowohl ein Lehrbuch als auch einen persönlichen Tutor hat, der ein Tagebuch über jeden Fehler bei den Prüfungen und deren Behebung führt. Indem er dieses Tagebuch ständig basierend auf dem Feedback eines strengen Prüfers aktualisiert, lernt der Schüler, die Prüfung viel häufiger zu bestehen – ohne dass sich die Art und Weise ändern muss, wie der Schüler denkt, sondern nur durch bessere Notizen zum Lernen.

Technisches Resümee: KBSpec

Problemstellung

Die automatisierte Generierung formaler Spezifikationen ist ein entscheidender Schritt für das Verständnis von Programmen und die formale Verifikation. Während Large Language Models (LLMs) vielversprechende Ergebnisse bei der Codegenerierung gezeigt haben, stößt ihr Einsatz bei formalen Spezifikationen (z. B. Java Modeling Language, JML) auf eine erhebliche Hürde: den Mangel an formalen Spezifikationskorpora in den Trainingsdaten. Dieser „Low-Resource“-Status führt häufig zu syntaktischen Fehlern und semantischen Defiziten (z. B. fehlende Grenzwertprüfungen, inkorrekte Invarianten).

Bestehende Versuche, LLMs mit externem Wissen (z. B. offizieller Dokumentation) zu erweitern, sind unzureichend, da Ressourcen für formale Spezifikationen oft unvollständig sind, eine mangelnde Abdeckung diverser Verifikationsmuster aufweisen oder experimentelle Features enthalten, die von Verifizierern nicht vollständig unterstützt werden. Zudem reicht es nicht aus, sich allein auf statisches externes Wissen zu verlassen, um die nuancierten, verifiziererspezifischen Constraints zu erfassen, die für eine erfolgreiche Verifikation erforderlich sind.

Methodik: KBSpec

Die Autoren schlagen KBSpec (Knowledge Base-Augmented Specification Generation) vor, ein Framework, das LLMs durch eine dual-quellige, selbstentwickelnde Wissensbasis erweitert. Das System arbeitet ohne Modifikation der LLM-Parameter oder die Anforderung von gelabelten Ground-Truth-Daten und stützt sich statstattdessen auf das Feedback formaler Verifizierer.

Die KBSpec-Pipeline besteht aus drei Hauptphasen:

1. Initialisierung der Wissensbasis

Das System initialisiert eine Spezifikations-Wissensbasis ( $M$ ) mittels externen Wissens, das aus offiziellen Dokumentationen (z. B. OpenJML-Tutorials, Beispielen und Übungen) sowie menschlich geschriebenen Reparatur-Richtlinien stammt. Jedes Wissenselement ist als Tripel strukturiert: Originalinhalt ( $c_i$ ), eine Zusammenfassung ( $s_i$ ) und Schlüsselwörter ( $k_i$ ), die von einem LLM generiert wurden, um die Abfrage (Retrieval) zu erleichtern.

2. Evolution der Wissensbasis (Trainingsphase)

Dies ist die zentrale Innovation. Die Wissensbasis wird dynamisch durch eine Generierungs-und-Reparatur-Pipeline aktualisiert, die über einem „Trainings“-Korpus von Java-Programmen läuft.

Generierung: Für ein gegebenes Programm generiert das LLM eine Basis-Spezifikation. Anschließend ruft es relevante Wissenselemente ab und generiert neue Spezifikationen basierend auf unterschiedlichen Kombinationen der abgerufenen Informationen.
Verifikation & Scoring: Generierte Spezifikationen werden mit einem formalen Verifizierer (OpenJML) verifiziert. Ein Hilfreichkeits-Score wird jedem abgerufenen Wissenselement zugewiesen, basierend darauf, ob es dem LLM geholfen hat, die Verifikation zu bestehen, als es zuvor fehlschlug, oder ob es zum Fehlschlag führte, als es zuvor erfolgreich war.
Iterative Reparatur: Für Spezifikationen, die fehlschlagen, führt das System bis zu drei Runden der Reparatur durch. Das LLM nutzt die ursprüngliche Spezifikation, die Fehlermeldung des Verifizierers und das abgerufene Wissen, um eine korrigierte Version zu generieren. Die Hilfreichkeit der abgerufenen Elemente wird basierend auf der Reduktion von Fehlern oder der erfolgreichen Verifikation aktualisiert.
Update & Filterung: Nach jeder Epoche wird die Wissensbasis aktualisiert. Elemente mit niedrigen Hilfreichkeits-Scores werden herausgefiltert, und neue erfolgreiche Trajektorien (Generierung oder Reparatur) werden hinzugefügt. Redundanz wird mittels Ähnlichkeitsprüfungen verwaltet.

3. Wissensgestützte Inferenz

Während der Evaluationsphase nutzt KBSpec die entwickelte Wissensbasis, um die Spezifikationsgenerierung zu unterstützen. Im Gegensatz zur Trainingsphase, die eine zufällige Stichprobenziehung von Wissensgruppen verwendet, setzt die Inferenzphase einen LLM-basierten Selektor ein. Das LLM wählt autonom die relevantesten Wissenselemente (bis zu 3) aus dem abgerufenen Satz aus, um die Generierung und die anschließende Reparatur von Spezifikationen zu steuern.

Zentrale Beiträge

KBSpec-Framework: Ein neuartiger, parameterfreier Ansatz für die Generierung formaler Spezifikationen, der eine durch Verifizierer-Feedback gesteuerte, selbstentwickelnde Wissensbasis integriert.
Dual-Source-Wissen: Die Identifizierung und Validierung, dass die Kombination von externer Dokumentation (für das initiale Sprachverständnis) mit internem Wissen (destilliert aus Verifizierer-Feedback auf Generierungs-/Reparatur-Trajektorien) essenziell ist, um die Limitationen von LLMs bei formalen Spezifikationen zu überwinden.
Empirische Validierung: Eine umfassende Evaluierung auf dem FormalBench-Benchmark (JML-Spezifikationsgenerierung), die zeigt, dass KBSpec die State-of-the-Art-Baselines, einschließlich SpecGen und verschiedener Prompting-Strategien (Few-shot, Least-to-Most, Self-repair), signifikant übertrifft.

Ergebnisse

Die Experimente wurden unter Verwendung von drei LLM-Backends durchgeführt: GPT-5.2, GPT-5-mini und DeepSeek-v3.2.

Verbesserung der Erfolgsrate: KBSpec verbesserte die Verifikations-Erfolgsraten um 10–25 % gegenüber State-of-the-Art LLM-basierten Ansätzen (z. B. SpecGen). Bei GPT-5.2 stieg die Erfolgsrate von 43,35 % (SpecGen) auf 58,94 %.
Reduktion von Fehlern: Das Framework reduzierte die Fehlerraten erheblich (z. B. Senkung der Fehlerrate für GPT-5.2 auf 20,6 %).
Vollständigkeit: Während die durchschnittlichen Vollständigkeitswerte gewisse Schwankungen zeigten, produzierte KBSpec die größte Anzahl an hochgradig vollständigen Spezifikationen (Vollständigkeit $\ge$ 0,5). Die Analyse gegenseitig verifizierter Programme zeigte, dass KBSpec die Vollständigkeit im Vergleich zu SpecGen beibehielt oder verbesserte, was darauf hindeutet, dass die Gewinne in der Erfolgsrate nicht durch die Generierung trivial schwacher Kontrakte erzielt wurden.
Ablationsstudie: Die Studie bestätigte, dass der Mechanismus der Wissensbasis-Evolution (internes Wissen) die kritischste Komponente war und mehr zur Leistung beitrug als die initiale externe Dokumentation. Auch die iterative Reparatur wurde als wesentlicher Treiber des Erfolgs identifiziert.

Bedeutung und Behauptungen

Das Paper behauptet, dass KBSpec das „Low-Resource“-Problem formaler Spezifikationssprachen dadurch löst, dass es eine selbstverbessernde Schleife schafft, in der das System durch Verifizierer-Feedback aus eigenen Erfolgen und Misserfolgen lernt.

Modell-agnostisch: Der Ansatz ist leichtgewichtig und kann auf jedes LLM angewendet werden, ohne ein Fine-Tuning zu erfordern.
Generalisierbarkeit: Obwohl auf JML evaluiert, behaupten die Autoren, dass das Design sprachunabhängig ist und auf jede Spezifikationssprache mit einem automatisierten Verifizierer angepasst werden kann.
Pragmatisches Engineering: Die Analyse des gelernten Wissens zeigt, dass das System effektiv pragmatische Reparaturstrategien lernt (z. B. Handhabung von arithmetischen Überläufen, Entfernung nicht unterstützter Konstrukte), anstatt lediglich die Spezifikationen zu schwächen, um die Verifikation zu bestehen.

Die Autoren kommen zu dem Schluss, dass die Integration von dokumentationsbasiertem Wissen mit verifizierer-fundierter Gedächtnisevolution die Fähigkeit von LLMs, syntaktisch korrekte und semantisch verifizierbare formale Spezifikationen zu generieren, substanziell verbessert.