Automatische Code Review im Bauwesen: Warum RAG allein nicht reicht
Belastbare Prüfprozesse brauchen BIM-Extraktion, autoritative Prüfmaschinen und Agenten, die Werkzeuge kontrolliert aufrufen.
Automatische Code Review wird erst produktionsnah, wenn KI nicht frei entscheidet, sondern Daten extrahiert, geprüfte Tools aufruft und Ergebnisse nachvollziehbar dokumentiert.
Praktisches Problem
Viele Digitalisierungsprojekte im Bauwesen unterschätzen, wie unterschiedlich Prüfaufgaben sind. Manche Regeln lassen sich sauber berechnen, andere müssen interpretiert werden. Manche Daten liegen im BIM, andere in Tabellen, Plänen, Baubeschreibungen oder Betriebsprofilen. Eine automatische Code Review muss deshalb nicht nur Antworten geben, sondern heterogene Unterlagen in prüfbare Eingaben verwandeln. Das ist besonders für Behörden, Prüfer und große Projektorganisationen relevant, weil manuelle Reviews teuer, langsam und schwer skalierbar sind.
Was die Forschungsidee verständlich macht
Der spannende Punkt ist die Kombination mehrerer Mechanismen. Ein Agent extrahiert Geometrie, Zeitpläne oder Systemeigenschaften aus Projektunterlagen. Für klar definierte Prüfungen ruft er eine autoritative Engine auf. Für unvollständige oder schwer formalisierbare Regeln nutzt er Retrieval und Sprachmodell-Reasoning. Damit entsteht keine reine Chat-Lösung, sondern eine Orchestrierung aus Datenextraktion, Werkzeugaufruf und Begründung. Das ist näher an produktiver Software, weil deterministische Teile dort bleiben, wo sie hingehören: in geprüften Berechnungs- und Regelmaschinen.
Was heute schon als Arbeitsprinzip nützlich ist
Für AEC-Tech-Teams ist die Architektur wichtiger als ein einzelnes Modell. Gute Prüfsoftware sollte unterscheiden, ob ein Ergebnis aus einer offiziellen Berechnung, einer Modellabfrage, einer Dokumentensuche oder einer KI-Interpretation stammt. Diese Herkunft muss im Befund sichtbar sein. Ein MCP-ähnlicher Werkzeugansatz ist dafür hilfreich, weil er KI-Aktionen in explizite Funktionen übersetzt: Daten lesen, Parameter extrahieren, Prüfengine aufrufen, Ergebnis speichern. Dadurch wird der Agent nicht zum unsichtbaren Entscheider, sondern zum kontrollierten Koordinator.
Was noch riskant oder ungelöst ist
RAG kann Regeltexte zugänglich machen, aber es garantiert keine korrekte Auslegung. Auch Werkzeugaufrufe sind nur so gut wie die extrahierten Eingaben. Wenn Flächen, Neigungen, Nutzungszeiten oder Systemgrenzen falsch gelesen werden, wirkt das Ergebnis präzise, ist aber fachlich falsch. Deshalb braucht automatische Code Review Validierungsstufen: Eingabedaten prüfen, fehlende Werte markieren, Berechnungsweg speichern und Abweichungen verständlich erklären. Außerdem müssen lokale Normen, Projektvarianten und Zuständigkeiten berücksichtigt werden. Ohne diese Governance bleibt die Automatisierung riskant.
Bezug zu Proxino, IFC, GAEB und Prüfung
Proxino arbeitet an einer ähnlichen Grundfrage: Wie werden unstrukturierte oder heterogene Bauinformationen zu prüfbaren Zusammenhängen? IFC kann Modellobjekte und Mengen liefern, GAEB beschreibt Leistungen und Kostenlogik, Spezifikationen enthalten Anforderungen. Ein Agent kann diese Quellen verbinden, aber Proxino muss die Belege sichtbar machen. Für die Praxis zählt, ob ein Befund bis zur Quelle zurückführt: Objekt, Eigenschaft, Menge, Position, Regel und verwendeter Prüfschritt. Genau diese Rückverfolgbarkeit unterscheidet ein nützliches Prüfwerkzeug von einer plausiblen KI-Antwort.
Ähnliche Artikel
Alle anzeigen
BIM & KI
LLMs im BIM: Warum Sprachmodelle belastbare Werkzeuge statt freier IFC-Magie brauchen
Sprachmodelle können BIM-Teams bei der Arbeit mit IFC-Modellen unterstützen – aber nur, wenn sie nicht unkontrolliert in Modelldaten schreiben. Der Beitrag zeigt, warum definierte Funktionen, Rollenrechte, Prüfregeln und lückenlose Protokolle die Grundlage für praxistaugliche KI-Workflows in Planung, Kalkulation und Bauleitung sind.
- #IFC
- #LLM-Tools
- #MCP
BIM & AEC-Tech
IFC per Sprache abfragen: Warum BIM-Daten für Fachanwender schwierig bleiben
IFC-Modelle enthalten enorme Mengen wertvoller Informationen, bleiben für viele Fachanwender aber schwer direkt nutzbar. Ein hybrider Ansatz mit relationalen Tabellen, Graphstrukturen und Retry-and-Refine-Logik zeigt, wie natürlichsprachliche BIM-Abfragen robuster werden können – etwa für Mengen, Bauteilbeziehungen und Modellprüfungen.
- #IFC
- #Natürlichsprachliche Abfragen
- #Graphdatenbanken
BIM & KI
LLM-Agenten für heterogene BIM-Modelle: Erst erkunden, dann auswerten
BIM-Modelle folgen selten einem einheitlichen Schema. Die Arbeit „BIM Information Extraction Through LLM-based Adaptive Exploration“ untersucht einen LLM-Agenten, der die Struktur eines IFC-Modells zur Laufzeit erkundet, statt feste Abfragevorlagen vorauszusetzen. Für BIM-Manager, Kalkulation, Bauleitung und AEC-Tech-Teams ist der Ansatz relevant, weil robuste KI-Werkzeuge nicht nur Fragen beantworten müssen, sondern zuerst verstehen sollten, wie ein konkretes Modell tatsächlich aufgebaut ist.
- #IFC
- #LLM-Agenten
- #Adaptive Exploration