Automatische Prüfung von Lastenheften und RFQs: Warum Standard-LLMs ohne RAG scheitern

Wenn ein Ingenieur eine RFQ mit 200 Seiten erhält, sucht er nicht nach einer allgemeinen Antwort. Er sucht nach Muss-Kriterium 4.2, nach der Toleranzangabe auf Seite 87 und nach dem Ausschlusskriterium im Anhang C. Das ist keine Suche nach Wissen — das ist eine Suche nach einer spezifischen Belegstelle in einem bestimmten Dokument.

Genau hier scheitern allgemeine Sprachmodelle wie ChatGPT oder Copilot, wenn sie ohne eine strukturierte Retrieval-Architektur eingesetzt werden. Sie wurden auf öffentlichen Daten trainiert, kennen keine Lastenhefte aus Ihrem Haus, keine internen Qualitätsstandards und keine kundenspezifischen Normen. Was sie liefern, ist eine plausibel klingende Antwort — nicht die überprüfbare.

In technischen Ausschreibungen zählt nicht die plausible Antwort. Zählt die belegbare.

Der Unterschied ist für ein Angebotsteam existenziell: Eine fehlende Anforderung, die übersehen wurde, kann im schlimmsten Fall zu einem ungültigen Angebot, einer Vertragsstrafe oder einem verlorenen Auftrag führen.

Technische Ausschreibungsdokumente haben eine eigene Struktur und Logik. Sie sind nicht so zu lesen wie ein Whitepaper oder ein Handbuch. Ihr Wert liegt nicht im fließenden Text, sondern in der präzisen Verortung von Anforderungen.

• Hierarchische Anforderungsstruktur: Muss- / Soll- / Kann-Kriterien in unterschiedlichen Kapiteln und Anhängen verteilt
• Normreferenzen: Verweise auf DIN, ISO, IEC oder kundenspezifische Standards, die extern existieren
• Ausschlusskriterien: k.o.-Bedingungen, die nicht explizit als solche markiert sind, aber das Angebot disqualifizieren
• Versionsabhängigkeit: Revisionsstände, die frühere Angebotsstände ungültig machen
• Tabellengebundene Daten: Toleranzen, Prüfwerte, Stücklisten, die strukturell aus Fließtext herausfallen
• Querverweise: Anforderungen in Anhang D, die Klauseln aus Kapitel 3 modifizieren

Ein Sprachmodell, das einen langen Kontext liest, kann diese Struktur approximieren — aber nicht zuverlässig extrahieren. Insbesondere bei Tabellen, Revisionsvermerken und mehrstufigen Querverweisen treten systematische Fehler auf, die nur durch einen evaluierten Retrieval-Schritt reduziert werden können.

Ein häufiger Gegeneinwand: "Moderne Modelle haben 128.000 oder 200.000 Token Context Window — warum nicht einfach das gesamte Lastenheft hineinladen?"

Das klingt plausibel, unterschätzt aber mehrere reale Probleme:

• Lost in the Middle: Studien zeigen, dass Sprachmodelle Informationen in der Mitte langer Kontexte systematisch schlechter abrufen als am Anfang oder Ende.
• Tabellen und strukturierte Daten: PDFs mit Tabellen, Grafiken oder verschachtelten Listen verlieren beim Parsing oft ihre Struktur — der Rohtext wird unzuverlässig.
• Kosten und Latenz: Ein 200-seitiges Lastenheft (ca. 100.000 Token) verursacht bei jedem Prompt erhebliche Kosten und Wartezeiten.
• Keine Quellenverortung: Der Nutzer erhält eine Antwort, aber keinen direkten Verweis auf Seite 87, Kapitel 4.2 oder den konkreten Satz im Dokument.
• Kein Versionsmanagement: Das Modell unterscheidet nicht zwischen Revision A und Revision C des Lastenhefts — ohne externe Kontrolle.

RAG löst diese Probleme nicht durch ein besseres Modell, sondern durch eine bessere Architektur: Das Dokument wird strukturiert indexiert, Anfragen werden gegen einen sauberen Vektorindex gestellt, und nur die tatsächlich relevanten Abschnitte landen im Kontext — mit Quellenangabe und Versionsreferenz.

Ein gut konzipiertes RAG-System für technische Ausschreibungen liefert keine Chat-Demo. Es liefert einen strukturierten Prüfworkflow:

• Anforderungsextraktion: Alle Muss-, Soll- und Kann-Kriterien werden mit Kapitelreferenz und Seitenzahl extrahiert und verknüpft.
• Gap-Analyse: Das System vergleicht extrahierte Anforderungen mit dem aktuellen Angebotsstand und markiert nicht belegte Punkte.
• Normreferenz-Prüfung: Externe Normverweise (DIN, ISO) werden identifiziert und als offene Prüfpunkte markiert.
• Versionsdiff: Bei revidierten Lastenheften werden Änderungen gegenüber dem Vorstand automatisch erkannt.
• Exportierbare Prüfliste: Ausgabe als strukturierte Liste mit Quellenverweisen, Status und verantwortlicher Person.

Das entscheidende Merkmal ist nicht die KI-Antwort selbst — es ist die Nachvollziehbarkeit. Jede Aussage des Systems führt zurück zu einem konkreten Abschnitt im Originaldokument, der vom Ingenieur geöffnet und geprüft werden kann.

Lastenhefte und RFQs enthalten regelmäßig Informationen, die unter NDA stehen: Zielpreise, Toleranzangaben, Kundenvorgaben und technische Spezifikationen, die bei einem Wettbewerber nicht auftauchen dürfen.

Das schließt die Nutzung öffentlicher API-Dienste für solche Dokumente in den meisten Fällen aus — unabhängig davon, ob der Anbieter erklärt, keine Daten zu trainieren. Die vertragliche und technische Kontrolle muss vollständig beim Unternehmen liegen:

• Embeddings dürfen nicht extern erzeugt werden, wenn der Dokumentinhalt NDA-pflichtig ist.
• Das Sprachmodell darf keine RFQ-Passagen an externe Infrastruktur senden.
• Logs und Retrieval-Ergebnisse müssen in der kontrollierten Umgebung verbleiben.
• Support-Zugriffe des Anbieters dürfen keinen Einblick in Dokumentinhalte gewähren.

Das bedeutet in der Praxis: Entweder eine vollständig kundenkontrollierte Private-Cloud-Umgebung oder eine On-Premise-Bereitstellung. Die genaue Grenze hängt von der Schutzklasse der Dokumente und den vertraglichen Verpflichtungen gegenüber dem Kunden ab.

Ein sinnvoller Pilot beginnt nicht mit dem gesamten Dokumentenbestand. Er beginnt mit einem klar abgegrenzten Anwendungsfall: einer repräsentativen Auswahl von RFQs aus einem Produktbereich und einem definierten Satz von Prüffragen.

• Dokumentauswahl: 5–10 repräsentative Lastenhefte oder RFQs aus einem Produktbereich (unter NDA, in der gesicherten Umgebung)
• Testset: 30–50 reale Prüffragen, die ein erfahrener Angebotsingenieur stellen würde — mit bekannten Antworten und Quellenangaben
• Metriken: Retrieval-Qualität (welcher Abschnitt wurde gefunden?), Antwortgenauigkeit, Quellenverortung und Verweigerungsrate bei fehlender Belegstelle
• Infrastruktur: Bewusst begrenzter Stack — lokales Embedding-Modell, isolierte Vektordatenbank, klar definierte Verarbeitungsgrenze
• Ausgabe: Entscheidungsvorlage mit messbaren Ergebnissen, identifizierten Schwachstellen und Empfehlung für den nächsten Schritt

Dieser Pilot liefert keine beeindruckende Demo. Er liefert eine belastbare Antwort auf die Frage: Funktioniert das RAG-System für unsere Dokumente und unsere Fragen zuverlässig genug, um in einen produktiven Prozess integriert zu werden?

Für die Prüfung von Lastenheften und RFQs ist ein allgemeines Sprachmodell ohne Retrieval-Architektur kein geeignetes Werkzeug. Es fehlt die Quellenverortung, das Versionsmanagement, die strukturierte Extraktionslogik und die Datenkontrolle.

RAG löst diese Probleme — aber nur, wenn es sorgfältig auf den Dokumenttyp, die Schutzanforderungen und den Zielprozess abgestimmt wird. Der Mehrwert entsteht nicht durch das Modell selbst, sondern durch die Architektur darum herum: Parsing, Indexierung, Retrieval, Quellenanbindung und Audit-Protokoll.

Wenn Sie prüfen möchten, ob und wie ein solches System für Ihren RFQ- oder Lastenheft-Prozess funktioniert, können Sie ein Sovereign AI Assessment anfragen. Wir analysieren Dokumenttypen, Schutzanforderungen und Zielprozess — und entwickeln daraus eine konkrete Pilotempfehlung.