Lokale KI im Bauingenieurwesen: Was wir aus dem ersten Projekt gelernt haben

# Lokale KI im Bauingenieurwesen: Was wir aus dem ersten Projekt gelernt haben

Wenn ein Bauingenieur morgens um 7:30 ins Büro kommt und die nächsten zwei Stunden

damit verbringt, eine Statikberechnung aus einem Projekt von 2017 zu suchen, dann

läuft etwas grundlegend falsch. Nicht weil der Ingenieur schlecht organisiert wäre.

Sondern weil das System, in dem er arbeitet, nie für die Menge an Wissen gebaut wurde,

die sich über Jahrzehnte ansammelt.

Genau das war die Situation bei einem führenden deutschen Bauingenieurunternehmen.

Dieser Artikel ist ein ehrlicher Erfahrungsbericht: was passiert ist, was schwierig

war und was am Ende funktioniert hat.

Die Ausgangslage

Das Unternehmen existiert seit über 30 Jahren. In dieser Zeit sind mehr als **250.000

Dateien** entstanden. Verteilt auf Netzlaufwerke, Abteilungsordner, lokale Rechner und

in manchen Fällen sogar auf USB-Sticks in Schreibtischschubladen.

Die Struktur war historisch gewachsen. Jede Abteilung hatte ihr eigenes System. Manche

Projekte waren nach Jahreszahlen sortiert, andere nach Auftraggebern, wieder andere

nach internen Projektnummern, die niemand mehr zuordnen konnte.

Das tägliche Problem

Ingenieure verbrachten im Schnitt bis zu 2 Stunden pro Tag mit der Suche nach

Dokumenten. Nicht weil sie faul waren oder die Windows-Suche nicht kannten. Sondern

weil die Windows-Suche bei 250.000 Dateien auf Netzlaufwerken schlicht versagt. Und

weil man erst wissen muss, *wo* man sucht, bevor man überhaupt anfangen kann.

Typische Szenarien sahen so aus:

• Ein Ingenieur braucht eine Referenzstatik für eine Brückenberechnung. Er weiss, dass

das Unternehmen vor etwa fünf Jahren etwas Ähnliches gemacht hat. Aber in welchem

Projekt? Unter welchem Auftraggeber? In welchem Ordner?

• Eine Ausschreibung kommt rein und das Team muss Referenzprojekte zusammenstellen. Das

bedeutet: Ordner für Ordner durchklicken, Kollegen fragen, E-Mails durchsuchen.

• Ein neuer Ingenieur fängt an und hat keinen Zugang zum kollektiven Wissen der Firma.

Er muss jeden Kollegen einzeln fragen, ob es zu seiner aktuellen Aufgabe schon

Vorarbeiten gibt.

Warum Cloud keine Option war

Das Unternehmen arbeitet zu einem grossen Teil für öffentliche Auftraggeber und

Industriekunden. Die Daten umfassen Grundrisse kritischer Infrastruktur,

Tragwerksberechnungen für öffentliche Gebäude und vertrauliche Kostenschätzungen. Die

Anforderungen an den Datenschutz waren eindeutig: Nichts davon darf das Haus verlassen.

Das war der Ausgangspunkt. Die Frage war nicht *ob* KI helfen kann, sondern **wie man

sie lokal zum Laufen bringt**, ohne Kompromisse bei Datenschutz oder Datenhoheit.

Was unerwartet schwierig war

Bevor wir über Lösungen sprechen, lass uns ehrlich über die Probleme reden. Denn genau

hier scheitern viele KI-Projekte: nicht an der Technologie, sondern an der Realität

der Daten.

OCR auf gescannten Bauplänen

Ein Grossteil der älteren Dokumente lag als gescannte PDFs vor. Baupläne aus den 90ern und 2000ern, teilweise in schlechter Qualität, manche schief eingescannt, manche mit handschriftlichen Anmerkungen.

Wir setzen auf SOTA OCR-Modelle, die deutlich über das hinausgehen, was klassische OCR-Engines wie Tesseract liefern. Moderne Vision-Language-Modelle können auch mit schwierigen Vorlagen umgehen, weil sie nicht nur einzelne Zeichen erkennen, sondern den visuellen Kontext des gesamten Dokuments verstehen. Trotzdem variiert die Qualität je nach Dokumenttyp:

Selbst bei handschriftlichen Anmerkungen auf Bauplänen kommen wir mit den aktuellen Modellen auf über 75% Erkennungsrate, was in den meisten Fällen ausreicht, um die Kernaussagen zu erfassen und das Dokument auffindbar zu machen. Bei Dokumenten mit niedriger Konfidenz markiert das System die Unsicherheit transparent, damit sich der Nutzer nicht auf potenziell lückenhafte Texterkennung verlässt.

Dateinamen die nichts aussagen

Du kennst das wahrscheinlich: Scan_2019_final_v3_neu.pdf. Oder noch besser:

Dokument1.pdf. Oder die Klassiker Kopie von Kopie von Berechnung.xlsx.

Bei einem Unternehmen mit 30 Jahren Geschichte summiert sich das. Geschätzt hatten

über 40% der Dateien Namen, aus denen sich keinerlei Rückschluss auf den Inhalt

ziehen liess. Das bedeutet: Der Dateiname als Metadatum war in vielen Fällen wertlos.

Die KI musste den Inhalt verstehen, nicht den Namen.

Rechtemanagement pro Projekt

Hier wird es richtig kompliziert. In einem Bauingenieurunternehmen darf nicht jeder

alles sehen. Ingenieur A arbeitet an Projekt X für einen öffentlichen Auftraggeber und

darf die Unterlagen sehen. Ingenieur B arbeitet an Projekt Y für einen

Industriekunden und darf die Unterlagen von Projekt X nicht sehen, selbst wenn sie

technisch relevant wären.

Das ist kein Nice-to-have, sondern eine **vertragliche und teilweise gesetzliche

Anforderung**. Die KI muss also nicht nur wissen, welche Dokumente relevant sind,

sondern auch, welche der anfragende Nutzer überhaupt sehen darf.

Das Format-Chaos

Bauingenieure arbeiten nicht nur mit PDFs. Die Realität sieht so aus:

• PDF: Berichte, Gutachten, Berechnungen, gescannte Altdokumente
• DWG-Begleitdokumente: Beschreibungen zu CAD-Zeichnungen, Planverzeichnisse
• Excel: Massenberechnungen, Kostenschätzungen, Nachtragskalkulationen
• Word: Angebote, Stellungnahmen, Protokolle
• E-Mail-Anhänge: Abstimmungen mit Auftraggebern, Planfreigaben
• PowerPoint: Präsentationen für Bauherren, Projektvorstellungen

Jedes dieser Formate braucht einen eigenen Parser. Und jeder Parser hat seine eigenen

Macken. Eine Excel-Datei mit zusammengeführten Zellen sieht für einen Parser komplett

anders aus als eine sauber strukturierte Tabelle.

Wie wir rangegangen sind

Lokalaise ist als Produkt bereits fertig entwickelt: Chat, Dokumentensuche, Agenten, Rechtemanagement, die gesamte Indexing Pipeline. Die eigentliche Arbeit bei einer Implementierung besteht darin, das System an die spezifischen Datenquellen und internen Prozesse des Unternehmens anzubinden. In diesem Fall waren die Anforderungen durch die Menge und Vielfalt der Daten anspruchsvoller als üblich, weshalb wir das Projekt in Phasen aufgeteilt haben.

Phase 1: Datenquellen inventarisieren und priorisieren

Der erste Schritt war überraschend analog. Wir haben uns mit Ingenieuren aus

verschiedenen Abteilungen zusammengesetzt und gefragt: **Wo sucht ihr am meisten? Was

braucht ihr am dringendsten?**

Das Ergebnis war eine priorisierte Liste:

1. Statische Berechnungen und Gutachten (höchste Priorität, weil sie am häufigsten

referenziert werden)

2. Ausschreibungsunterlagen und Referenzprojekte (wichtig für die

Akquisitionsabteilung)

3. Protokolle und Abstimmungsdokumente (wichtig für laufende Projekte)

4. Kostenschätzungen und Nachträge (sensibel, aber wertvoll)

5. Altbestand vor 2005 (niedrigste Priorität, aber langfristig relevant)

Diese Priorisierung hat uns davor bewahrt, alles gleichzeitig machen zu wollen. Statt

250.000 Dateien auf einmal zu indexieren, haben wir mit den wichtigsten 60.000

angefangen.

Phase 2: Indexing Pipeline konfigurieren

Die Indexing Pipeline in Lokalaise bringt bereits format-spezifische Parser für alle gängigen Dokumenttypen mit. Für dieses Projekt mussten wir vor allem die Konfiguration an die Besonderheiten des Datenbestands anpassen: Welche OCR-Vorverarbeitung brauchen die alten Scans? Wie chunken wir Statikberechnungen sinnvoll? Welche Metadaten extrahieren wir automatisch?

Der grundsätzliche Ablauf:

Datei erkannt → Format identifiziert → Parser ausgewählt →
Text extrahiert → Metadaten angereichert → Chunks erstellt →
Embeddings generiert → Vektorindex aktualisiert

PDFs durchliefen die OCR-Pipeline mit Vorverarbeitung (Entzerrung, Kontrastoptimierung), Excel-Dateien wurden zeilenweise mit Kontext versehen und Word-Dokumente strukturiert geparst. Für einige interne Systeme des Unternehmens haben wir zusätzliche Integrationen gebaut, die über den Standard hinausgingen.

Ein entscheidender Punkt war das Chunking. Bauingenieursdokumente haben eine andere

Struktur als typische Geschäftsdokumente. Eine Statikberechnung hat Kapitel, die

aufeinander aufbauen. Wenn man sie in zu kleine Chunks zerteilt, geht der Kontext

verloren. Wenn die Chunks zu gross sind, wird die Suche ungenau.

Wir haben mit verschiedenen Chunk-Grössen experimentiert und sind am Ende bei einem

hybriden Ansatz gelandet:

Die Metadatenanreicherung war ein weiterer kritischer Schritt. Da viele Dateinamen

nichtssagend waren, haben wir die KI selbst genutzt, um aus dem extrahierten Text

strukturierte Metadaten zu generieren: Projektname, Auftraggeber, Dokumenttyp,

Erstellungsjahr, relevante Normen und technische Schlagwörter.

Phase 3: Rechtemanagement implementieren

Das RBAC-System (Role-Based Access Control) war die technisch anspruchsvollste

Komponente. Es reichte nicht, einfach eine Rechtematrix aufzusetzen. Die Rechte mussten

zur Abfragezeit geprüft werden, nicht nur beim Indexieren.

Der Ablauf sieht vereinfacht so aus:

1. Nutzer stellt eine Frage über das Chat-Interface

2. Das System identifiziert den Nutzer und seine Projektzugehörigkeiten

3. Die Vektorsuche wird mit einem Filter ausgeführt, der nur Dokumente

zurückgibt, die der Nutzer sehen darf

4. Die Antwort wird generiert, ausschliesslich basierend auf Dokumenten, für die der

Nutzer berechtigt ist

Das klingt einfach, hat aber Implikationen. Wenn ein Ingenieur nach

"Brückenberechnung mit Spannweite über 50m" fragt und die beste Referenz in einem

Projekt liegt, für das er keine Berechtigung hat, dann bekommt er diese Referenz nicht.

Das System muss das transparent kommunizieren, ohne zu verraten, welches Projekt

die Information enthält. Wir haben das über eine einfache Meldung gelöst: *"Es gibt

möglicherweise weitere relevante Dokumente, auf die du keinen Zugriff hast. Wende

dich bei Bedarf an deinen Projektleiter."*

Phase 4: Chat-Interface für Ingenieure ausrollen

Das Interface war bewusst einfach gehalten. Ingenieure sind keine IT-Experten und

wollen es auch nicht sein. Das Team will eine Frage stellen und eine Antwort bekommen.

Designprinzipien:

• Einfache Texteingabe, keine komplexen Suchmasken
• Quellenangaben bei jeder Antwort (Dokumentname, Seite, Projekt)
• Direktlink zum Originaldokument auf dem Netzlaufwerk
• Feedback-Möglichkeit ("War diese Antwort hilfreich?")
• Keine Halluzinationen tolerieren: Wenn das System keine gute Quelle findet, sagt

es das ehrlich

Der letzte Punkt war besonders wichtig. In einem Ingenieurbüro können falsche

Informationen im schlimmsten Fall zu Planungsfehlern führen. Das System wurde so

konfiguriert, dass es bei niedriger Konfidenz explizit darauf hinweist, dass die

Antwort unsicher ist, und immer die Originalquelle zur manuellen Prüfung verlinkt.

Was am Ende messbar besser wurde

Nach drei Monaten produktivem Einsatz haben wir gemeinsam mit dem Unternehmen eine

Evaluation durchgeführt. Die Ergebnisse waren in manchen Bereichen erwartbar, in

anderen überraschend.

Suchzeit: von 2 Stunden auf Sekunden

Die offensichtlichste Verbesserung: Ingenieure finden Dokumente jetzt in

durchschnittlich 15 Sekunden statt in bis zu 2 Stunden. Das ist keine

Übertreibung, sondern das Ergebnis von Zeiterfassungen vor und nach der Einführung.

Natürlich findet das System nicht immer sofort das richtige Dokument. Manchmal braucht

es eine Umformulierung oder eine manuelle Nachsuche. Aber selbst im ungünstigsten Fall

ist der Prozess um ein Vielfaches schneller als vorher.

Referenzprojekte finden

Vorher dauerte es teilweise mehrere Tage, ein passendes Referenzprojekt zu

identifizieren. Jetzt stellt ein Ingenieur eine Frage wie *"Welche Projekte haben wir

mit Spannbetonbrücken über 40m Spannweite in den letzten 10 Jahren gemacht?"* und

bekommt in Sekunden eine Liste mit Quellenangaben. Das hat nicht nur die Effizienz

verbessert, sondern auch die Qualität der Referenzauswahl. Vorher wurde oft das

erstbeste Referenzprojekt genommen, jetzt kann der Ingenieur aus mehreren relevanten

Projekten das passendste auswählen.

Ausschreibungsvorbereitung

Die Vorbereitung von Ausschreibungsunterlagen war vorher ein Prozess, der sich über

Wochen ziehen konnte. Mit dem System konnte die Vorbereitungszeit deutlich reduziert

werden. Das Team berichtet von einer Zeitersparnis von mindestens 50% bei der

Referenzzusammenstellung.

Onboarding neuer Ingenieure

Das war die überraschendste Verbesserung. Neue Ingenieure nutzen das System intensiv,

um sich in laufende Projekte einzuarbeiten. Statt Kollegen zu unterbrechen, fragen sie

erst das System. *"Was wurde bei Projekt X zur Gründung entschieden und warum?"* liefert

eine brauchbare Zusammenfassung mit Verweisen auf die Originaldokumente. Ein

Senior-Ingenieur hat es so formuliert: *"Das ist wie ein Kollege, der bei jedem

Projekt dabei war und sich an alles erinnert."*

In Zahlen

Der Wert von 87% bei korrekt beantworteten Fragen braucht Kontext. Das bedeutet nicht,

dass 13% der Antworten falsch waren. Es bedeutet, dass in 13% der Fälle das System

keine zufriedenstellende Antwort liefern konnte, entweder weil das Dokument nicht

indexiert war, die OCR-Qualität zu schlecht war oder die Frage zu vage formuliert wurde.

Falsche Antworten, die als korrekt dargestellt wurden, lagen im evaluierten Zeitraum

unter 2%.

Was wir anders machen würden

Kein Projekt ist perfekt. Hier sind die wichtigsten Lessons Learned, die wir beim

nächsten Mal berücksichtigen werden.

Nutzer früher einbinden

Wir haben die Ingenieure erst in Phase 4 aktiv eingebunden, beim Rollout des

Chat-Interface. Das war ein Fehler. Hätten wir sie schon in Phase 1 stärker

einbezogen, hätten wir einige Annahmen über die Datenpriorisierung früher korrigiert.

Beispiel: Wir hatten Protokolle auf Priorität 3 gesetzt. Im Nachhinein stellte sich

heraus, dass Baubesprechungsprotokolle für laufende Projekte extrem wichtig sind, weil

in ihnen Entscheidungen dokumentiert werden, die nirgendwo anders festgehalten sind. Die

hätten auf Priorität 1 gehört.

Lektion: Binde Endnutzer ab Tag eins ein. Nicht als Testpersonen, sondern als

gleichberechtigte Projektbeteiligte.

Metadatenstrategie von Anfang an

Wir haben die Metadatenanreicherung erst im Laufe von Phase 2 als kritisch erkannt.

Rückblickend hätten wir von Anfang an eine klare Metadatenstrategie definieren

sollen: Welche Metadaten brauchen wir? Welche können wir automatisch extrahieren?

Welche müssen manuell ergänzt werden?

Die nachträgliche Anreicherung hat funktioniert, war aber aufwändiger als nötig. Eine

vorausschauende Strategie hätte uns mindestens zwei Wochen Entwicklungszeit gespart.

Datenqualität vor Indexierung prüfen

Wir haben anfangs alles indexiert und dann geschaut, was brauchbar ist. Besser wäre es

gewesen, zuerst einen Qualitäts-Check einzubauen, der Dokumente nach OCR-Qualität

kategorisiert und bei Bedarf zur manuellen Nachbearbeitung markiert.

In der jetzigen Pipeline ist dieser Check eingebaut. Dokumente mit einer

OCR-Konfidenz unter 70% werden automatisch geflaggt und können bei Bedarf manuell

überprüft werden. Das hätten wir von Anfang an so machen sollen.

Change Management nicht unterschätzen

Technik ist die halbe Miete. Die andere Hälfte ist, die Leute mitzunehmen. Einige

Ingenieure waren anfangs skeptisch. *"Die KI versteht doch nichts von Statik"* war ein

häufiger Kommentar. Es hat geholfen, konkrete Anwendungsfälle zu zeigen und die

Ingenieure selbst ausprobieren zu lassen, anstatt mit abstrakten Versprechen zu

argumentieren.

Besonders wirkungsvoll war ein interner Workshop, bei dem Ingenieure ihre eigenen

Fragen an das System stellen konnten. Als ein erfahrener Kollege innerhalb von

Sekunden ein Referenzprojekt fand, das er seit Monaten gesucht hatte, war die Skepsis

bei den meisten verflogen.

Feedback-Loop von Anfang an einplanen

Das Feedback-Feature ("War diese Antwort hilfreich?") haben wir erst nach vier Wochen

produktivem Einsatz eingebaut. In diesen vier Wochen haben wir wertvolle Daten

verloren. Jedes Mal, wenn ein Nutzer eine unbefriedigende Antwort bekommt und das

nicht meldet, ist das eine verpasste Gelegenheit zur Verbesserung.

Heute nutzen wir das Feedback aktiv, um die Retrieval Pipeline zu optimieren. Fragen,

die regelmässig zu schlechten Ergebnissen führen, werden analysiert und das System

wird entsprechend angepasst.

Technische Erkenntnisse für die Praxis

Für alle, die ein ähnliches Projekt planen, hier einige technische Erkenntnisse, die

über das Offensichtliche hinausgehen.

Hybrid Search schlägt reine Vektorsuche

Wir haben anfangs auf reine Semantic Search mit Embeddings gesetzt. Das funktioniert

gut für konzeptuelle Fragen ("Welche Gründungsvarianten wurden bei ähnlichen

Bodenverhältnissen gewählt?"). Aber für exakte Suchen ("Projekt 2019-0847 Anlage 3")

versagt reine Vektorsuche regelmässig.

Die Lösung war eine Hybrid Search, die semantische Suche mit klassischer

Volltextsuche kombiniert. Die Gewichtung zwischen beiden Methoden lässt sich pro

Anfrage dynamisch anpassen.

Embeddings sind nicht alles

Die Qualität der Embeddings ist wichtig, aber die Qualität des Retrieval-Kontexts

ist wichtiger. Ein perfektes Embedding nützt nichts, wenn der Chunk, den es

repräsentiert, keinen sinnvollen Kontext enthält.

Konkret: Ein Chunk, der nur den Satz "Die Ergebnisse sind in Tabelle 4.3 dargestellt"

enthält, hat ein brauchbares Embedding, liefert aber als Retrieval-Ergebnis keinen

Mehrwert. Die Chunk-Strategie muss sicherstellen, dass jeder Chunk selbsterklärend

ist.

Lokale Inferenz ist production-ready

Es gibt immer noch Vorbehalte gegenüber lokaler KI-Inferenz. Die Erfahrung aus diesem

Projekt zeigt: Mit der richtigen Hardware und Konfiguration sind **Antwortzeiten unter

5 Sekunden** bei komplexen RAG-Anfragen realistisch.

Die wichtigsten Faktoren für die Performance:

• GPU-Speicher als primärer Bottleneck, nicht die CPU
• Quantisierung des Sprachmodells als pragmatischer Kompromiss
• Caching von häufig abgefragten Embeddings
• Batch-Processing bei der Indexierung statt Echtzeit-Verarbeitung

Monitoring ist Pflicht

Ein KI-System ohne Monitoring ist wie ein Auto ohne Tacho. Du merkst erst, dass etwas

schief läuft, wenn es zu spät ist.

Wir tracken unter anderem:

• Antwortzeiten pro Anfrage (Ziel: unter 5 Sekunden)
• Retrieval-Qualität (werden die richtigen Chunks gefunden?)
• Nutzer-Feedback (zufriedenstellende vs. unbefriedigende Antworten)
• Index-Aktualität (werden neue Dokumente zeitnah indexiert?)
• OCR-Fehlerrate bei neu hinzugefügten Dokumenten

Fazit

Lokale KI für Bauingenieure ist kein Experiment mehr. Es funktioniert produktiv, es

spart messbar Zeit und es löst ein echtes Problem, das die Branche seit Jahrzehnten

hat.

Aber es ist auch kein Selbstläufer. Die Datenqualität in gewachsenen Unternehmen ist

eine echte Herausforderung. Das Rechtemanagement darf nicht nachträglich angeflanscht

werden. Und die Ingenieure müssen von Anfang an mitgenommen werden.

Was uns an diesem Projekt am meisten beeindruckt hat: **Der Moment, in dem das System

zum normalen Arbeitswerkzeug wurde.** Nicht die Technologie-Demo, nicht der erste

erfolgreiche Test, sondern der Punkt, an dem Ingenieure morgens das Chat-Interface

öffneten, bevor sie den Datei-Explorer öffneten. Das war nach etwa sechs Wochen der

Fall.

Die Baubranche hat einen enormen Wissensschatz in hunderttausenden Dokumenten auf

Servern, in Ordnern und in den Köpfen erfahrener Ingenieure. Die Köpfe können wir

nicht indexieren. Aber die Dokumente schon.

Wenn du vor einer ähnlichen Herausforderung stehst, hoffen wir, dass dieser Bericht

hilfreich war. Nicht als Blaupause, denn jedes Unternehmen ist anders, sondern als

ehrlicher Einblick in das, was dich erwartet.