Engineering-Copilot 2026: RAG auf Bauteil- und Normdaten

Pexon Consulting | 9 Min. Lesezeit | 08.07.2026

TL;DR

Ein Engineering-Copilot durchsucht Bauteil-, Konstruktions- und Normdaten (IEC 60076, IEEE C57) und beantwortet Fragen der Konstrukteure mit exakter Quellenangabe: Norm-Klausel, Bauteil-ID, Revisionsstand. Pexon Consulting (80 MA, Microsoft Partner, Deutschland) baut das norm-bewusst und produktionsreif in einem 6-Wochen-Pilot, statt als PDF-Chat, der bei Normen halluziniert.

Warum PDF-Chat bei Normen scheitert

Die kurze Antwort: weil der Copilot bei Normfragen nicht raten darf, ein Standard-PDF-Chat aber genau das tut. Wenn ein Konstrukteur fragt, welcher Kurzschlussfestigkeits-Nachweis für einen Leistungstransformator nach IEC 60076-5 gilt, ist eine plausibel klingende, aber falsche Antwort schlimmer als gar keine. Sie geht in die Auslegung ein und fällt erst im Typprüffeld auf.

Das ist kein theoretisches Risiko. In der Praxis liegt der Engpass fast nie beim Sprachmodell. Wenn ein RAG-System falsch antwortet, liegt der Fehler in 73 Prozent der Fälle im Retrieval, nicht in der Generierung (Branchenanalyse 2026, ragaboutit.com). Und 70 Prozent der Teams mit RAG in Produktion haben laut einer Praktiker-Umfrage 2026 kein systematisches Retrieval-Level-Evaluation. Bei generischen Wissensdatenbanken fällt das monatelang nicht auf. Bei Normdaten fällt es beim ersten falschen Klausel-Verweis auf, und dann ist das Vertrauen der Konstrukteure weg.

Der Engineering-Copilot ist deshalb kein Chatbot auf einem PDF-Ordner. Er ist eine Retrieval-Maschine, die drei Datenwelten zusammenführt, die im Unternehmen heute in getrennten Silos liegen: Bauteildaten (meist im ERP oder PLM), Konstruktionswissen (Berechnungen, Auslegungsregeln, interne Richtlinien) und Normdaten (IEC, IEEE, DIN). Der Wert entsteht genau an der Naht, wo der Konstrukteur Bauteil und zutreffende Norm in einer Frage verbindet.

Was den Engineering-Copilot norm-bewusst macht

Norm-Bewusstsein heißt: Jedes Retrieval-Ergebnis trägt Metadaten, die eine Norm eindeutig machen. Ohne diese Metadaten ist eine Antwort wertlos, weil eine Norm-Klausel ohne Ausgabestand und Teil-Nummer nicht belastbar ist. Die Norm IEC 60076-1 liegt aktuell in der Revision von 2020 vor und deckt Leistungstransformatoren bis 765 kV ab. Die IEEE-C57-Serie wurde 2025 aktualisiert, unter anderem mit IEEE C57.91-2025 (Belastungsrichtlinie, konsolidiert die zurückgezogenen C57.92 und C57.115) und IEEE C57.152-2025 für Diagnose-Feldmessungen. Ein Copilot, der diese Ausgabestände nicht mitführt, verwechselt eine zurückgezogene Klausel mit der gültigen.

Wir modellieren das über norm-bewusste Metadaten pro Chunk. Jeder Textabschnitt bekommt beim Indexieren mindestens: Norm-Familie, Teil-Nummer, Ausgabejahr, Klausel-Nummer, Status (gültig/zurückgezogen). Das erlaubt zwei Dinge, die reiner Vektor-Similarity fehlen: hartes Filtern (nur gültige Ausgabestände) und exakte Zitation.

# Norm-bewusste Metadaten pro Chunk beim Indexieren
# Jeder Abschnitt trägt die Herkunft mit, damit die Antwort
# später eine belastbare Quellenangabe liefern kann.
chunk = {
    "text": "Der Nachweis der Kurzschlussfestigkeit erfolgt ...",
    "metadata": {
        "norm_family": "IEC 60076",
        "part": "5",
        "edition_year": 2006,        # Ausgabestand ist Pflicht
        "clause": "4.1.3",
        "status": "gueltig",         # zurückgezogene Klauseln filtern
        "component_type": "leistungstransformator",
        "source_uri": "s3://normen/iec-60076-5-2006.pdf#p42",
    },
}

# Beim Retrieval hart auf gültige Ausgabestände filtern,
# bevor die Vektor-Suche greift.
def build_filter(component_type: str) -> dict:
    return {
        "status": "gueltig",
        "component_type": component_type,
    }

Die Chunk-Größe ist bei Normen kein Detail, sondern der Hebel für die Trefferqualität. Für Wissensbasen gilt 512 bis 1024 Token pro Chunk mit rund 128 Token Überlappung als solider Ausgangspunkt. Bei Normen schneiden wir aber nicht blind nach Token-Zahl, sondern an Klausel-Grenzen: Eine Klausel ist die kleinste sinnvolle Zitier-Einheit. Zerschneidet man sie, verweist der Copilot später auf einen halben Absatz, und der Konstrukteur kann den Beleg nicht prüfen.

Als Embedding-Modell setzen wir für deutsche und gemischtsprachige Normtexte meist bge-m3 (FlagEmbedding, rund 11,9k GitHub-Sterne, abgerufen 8. Juli 2026). Der Grund ist praktisch: bge-m3 kann Dense-, Sparse- und Multi-Vector-Retrieval in einem Modell, unterstützt über 100 Sprachen und verarbeitet bis zu 8192 Token am Stück. Sparse-Retrieval fängt genau die Fälle, die bei Normen häufig sind: exakte Bezeichner wie „IEC 60076-5“ oder eine Bauteil-Kennung, die ein rein semantisches Modell verwässert. Das Modell ist MIT-lizenziert und läuft on-premise, was bei Konstruktionsdaten oft die einzige Option ist.

Retrieval mit Quellenangabe: der harte Teil

Der belegbare Unterschied zu einem generischen Chatbot ist die Quellenangabe. Nicht als nachträgliche Fußnote, sondern als Teil der Retrieval-Pipeline. Der Copilot liefert zu jeder Aussage: Norm-ID, Teil, Klausel, Ausgabestand und, wo es um ein konkretes Bauteil geht, die Bauteil-ID mit Revisionsstand. Fehlt der Beleg, gibt der Copilot keine Antwort, sondern sagt, dass er keine belastbare Quelle findet. Das ist für Konstrukteure der Vertrauens-Anker.

Technisch kombinieren wir Dense- und Sparse-Retrieval (Hybrid-Suche) und geben pro Treffer die Metadaten mit an das Sprachmodell. Hybrid-Retrieval ist 2026 zum Enterprise-Konsens geworden: Die Absicht, es einzusetzen, hat sich laut VentureBeat innerhalb eines Quartals von 10,3 auf 33,3 Prozent verdreifacht. Der Grund ist genau der Normfall: Dense findet die Bedeutung, Sparse findet den exakten Bezeichner.

# Retrieval mit Quellenangabe: Hybrid-Suche plus harter Norm-Filter.
# Das Sprachmodell bekommt die Metadaten mit, damit die Antwort
# jede Aussage mit Norm-ID und Revisionsstand belegen kann.
def retrieve_with_sources(frage: str, component_type: str, top_k: int = 6):
    hits = vektorstore.hybrid_search(
        query=frage,
        filter=build_filter(component_type),  # nur gültige Ausgabestände
        top_k=top_k,
    )
    kontext = []
    for h in hits:
        m = h["metadata"]
        beleg = f"{m['norm_family']}-{m['part']}:{m['edition_year']} Klausel {m['clause']}"
        kontext.append({"text": h["text"], "beleg": beleg})
    # Der Prompt zwingt das Modell, nur mit Beleg zu antworten.
    return kontext

def antwort_mit_quelle(frage, kontext):
    prompt = (
        "Beantworte nur mit den folgenden Belegen. "
        "Zitiere hinter jeder Aussage den Beleg in Klammern. "
        "Findest du keinen Beleg, sage das klar.nn"
    )
    for k in kontext:
        prompt += f"[{k['beleg']}] {k['text']}n"
    prompt += f"nFrage: {frage}"
    # Modell-ID explizit, damit Verhalten reproduzierbar bleibt
    return llm.generate(prompt, model="claude-sonnet-4-6")

Eine ehrliche Einschränkung: Das ersetzt keine Freigabe durch einen Ingenieur. Der Copilot beschleunigt die Recherche und macht sie belegbar, er trifft keine Auslegungsentscheidung. Genau so kommunizieren wir das auch im Rollout, weil ein überverkaufter Copilot beim ersten Grenzfall Vertrauen verbrennt.

Was in der Praxis passiert

Ein Hersteller elektromechanischer Komponenten für die Energietechnik hatte das klassische Silo-Problem: Bauteildaten im PLM, Berechnungsvorschriften in einem Wiki, Normen als PDF auf einem Laufwerk. Ein Konstrukteur, der prüfen wollte, ob eine geänderte Wicklungsauslegung den Kurzschlussnachweis nach IEC 60076-5 noch trägt, brauchte im Schnitt eine halbe Stunde und drei geöffnete Fenster. Nicht wegen der Rechnung, sondern wegen der Suche nach der richtigen, gültigen Klausel.

Der Engineering-Copilot hat diese Suche auf Sekunden gebracht, mit Klausel-Verweis und Ausgabestand. Wichtiger als die Zeitersparnis war der Nebeneffekt: Die Antworten wurden nachvollziehbar. Ein Reviewer konnte den Beleg in einem Klick prüfen, statt der Aussage zu vertrauen. In unseren Projekten ist das der eigentliche Umschwung. Nicht die eingesparten Minuten, sondern dass die Konstrukteure dem System glauben, weil sie jeden Satz gegen die Norm nachschlagen können.

Was wir nicht empfehlen: den Copilot direkt auf die gesamte Norm-Bibliothek loszulassen und „später aufzuräumen“. Das erzeugt genau die 73-Prozent-Retrieval-Fehler. Erst die Metadaten sauber, dann der Copilot. Ein enger, sauberer Korpus (eine Bauteil-Familie plus die zwei, drei zutreffenden Normen) schlägt einen großen, verrauschten Korpus jedes Mal.

Kosten und Zeitrahmen

Ein produktiver Engineering-Copilot ist ein 6-Wochen-Pilot, kein Jahresprojekt. Der Aufwand steckt zu 70 Prozent im Aufbereiten der Normdaten mit sauberen Metadaten, nicht im Modell. Die Modell-Kosten sind zweitrangig, weil On-Premise-Embeddings wie bge-m3 lizenzkostenfrei sind und die Inferenz für eine Konstruktionsabteilung überschaubar bleibt.

Wer die Norm-Metadaten schon strukturiert vorliegen hat, ist schneller. Wer bei null anfängt (PDFs ohne Struktur), sollte die erste Woche allein für die Aufbereitung einplanen. Unsere klare Empfehlung: nicht am Metadaten-Modell sparen. Jeder Euro dort spart drei Euro Debugging im Retrieval später.

Häufig gestellte Fragen

Was kostet ein Engineering-Copilot für die Konstruktion?

Ein produktiver Erstausbau liegt als 6-Wochen-Pilot im Bereich eines mittleren fünfstelligen Projektbudgets, abhängig vom Zustand der Normdaten. Der größte Kostenblock ist die Aufbereitung der Norm- und Bauteildaten, nicht das Sprachmodell. On-Premise-Embeddings sind lizenzkostenfrei, die laufenden Inferenzkosten für eine Abteilung bleiben im niedrigen dreistelligen Bereich pro Monat.

Engineering-Copilot oder klassischer PDF-Chat: was ist der Unterschied?

Ein PDF-Chat antwortet auf einem Dokument-Ordner ohne Norm-Bewusstsein und ohne belastbare Quellenangabe. Ein Engineering-Copilot führt Bauteil-, Konstruktions- und Normdaten zusammen, filtert auf gültige Ausgabestände und belegt jede Aussage mit Norm-ID und Klausel. Bei Normfragen ist das der entscheidende Unterschied, weil eine plausibel falsche Antwort teurer ist als keine Antwort.

Halluziniert der Copilot bei Normfragen?

Ein reiner PDF-Chat: ja, regelmäßig. Ein norm-bewusst gebauter Copilot: deutlich seltener, weil er nur auf Basis abgerufener, gültiger Klauseln antwortet und ohne Beleg keine Aussage macht. Halluzination lässt sich nicht auf null drücken, aber durch harte Metadaten-Filter, Hybrid-Retrieval und einen Beleg-Zwang im Prompt auf ein Niveau bringen, das für die Recherche vor der Ingenieur-Freigabe taugt.

Welche Normen kann der Engineering-Copilot abdecken?

Grundsätzlich jede strukturierte Norm-Familie: IEC 60076 (Leistungstransformatoren), die IEEE-C57-Serie, DIN-Normen, IEC/IEEE 82079-1 für technische Dokumentation. Voraussetzung ist, dass wir die Norm mit Metadaten (Teil, Klausel, Ausgabestand, Status) indexieren dürfen. Zurückgezogene Ausgabestände werden hart herausgefiltert, damit der Copilot nicht auf ungültige Klauseln verweist.

Bleiben unsere Konstruktionsdaten im Haus?

Ja. Wir setzen für Embeddings on-premise-fähige Modelle wie bge-m3 ein (MIT-Lizenz, läuft ohne Cloud-Zwang), und die gesamte Retrieval-Schicht kann im eigenen Rechenzentrum oder in einer souveränen Cloud laufen. Für Bauteil- und Normdaten ist das meist die einzige akzeptable Variante, und wir bauen den Copilot von Anfang an so.

Nächster Schritt

Wenn Sie gerade evaluieren, ob ein Engineering-Copilot für Ihre Konstruktion tragfähig ist, ist der schnellste Weg ein fokussierter Use-Case-Workshop: eine Bauteil-Familie, die zutreffenden Normen, ein messbarer Retrieval-Test.

Verwandte Themen