RAG für Entwicklungsdokumentation: DOORS und Polarion

RAG für Entwicklungsdokumentation: DOORS, Polarion und Confluence anbinden

Ja, KI kann Fragen aus der Entwicklungsdokumentation beantworten, wenn eine abfragbare Doku-Sicht (Retrieval Augmented Generation, RAG) an die führenden Quellsysteme angebunden ist: an das Anforderungsmanagement in DOORS, die Arbeitsstände in Polarion, die Projekt-Wikis in Confluence und die gewachsenen Netzlaufwerke. Drei Anforderungen entscheiden über die Tauglichkeit im Serienkontext: Quellen- und Versionsanzeige in jeder Antwort, Vererbung der Zugriffsrechte aus den Quellsystemen und ein definierter Umgang mit widersprüchlichen Ständen über den Baseline-Bezug. Das System arbeitet dabei rein lesend und erzeugt keinen eigenen Arbeitsstand in den Quellsystemen. sensified beschreibt in diesem Beitrag die Architektur eines solchen Doku-RAG und ordnet sie als rein lesende Augmentation mit klarem Freigabepfad ein.

Die Ausgangslage ist in gewachsenen Steuergeräte-Projekten fast überall dieselbe. Die Anforderung steht in DOORS, der Umsetzungsstand in Polarion, die Architektur-Entscheidung von damals in Confluence, und die Schnittstellenbeschreibung des Zulieferers liegt als PDF auf dem Netzlaufwerk. Wer eine Frage über diese Grenzen hinweg beantworten muss, öffnet vier Werkzeuge, fragt zwei Kollegen und verliert einen halben Nachmittag. Entwicklungsleitungen und Tool-Verantwortliche kennen diese Rechnung, und sie kennen die Folgefrage aus der Geschäftsführung: Kann KI das nicht beantworten? Dieser Beitrag ist das Architektur-Stück zu genau dieser Frage. Er beschreibt herstellerneutral, was eine abfragbare Doku-Sicht leisten muss, damit sie in einem Umfeld mit Automotive SPICE (ASPICE) und Assessments trägt. Den Überblick über alle Einsatzfelder gibt der Beitrag zu KI in der Automotive-Softwareentwicklung. Eine Einordnung vorweg: Aussagen zu Eignung und Aufwand sind typisierte Hypothesen aus Projekterfahrung, die je Kunde und Toolchain zu prüfen sind. Über Personen oder deren Leistung trifft dieser Beitrag keine Aussage.

Warum die Volltextsuche an der Werkzeug-Grenze scheitert

Jedes der beteiligten Systeme bringt eine eigene Suche mit, und innerhalb ihres Systems funktioniert jede davon ordentlich. Die Fragen des Projektalltags halten sich an diese Grenzen jedoch nicht. Wer wissen will, welche Anforderungen an einer Busbotschaft hängen und was dazu im Design entschieden wurde, berührt mindestens drei Systeme mit drei Suchfeldern, drei Ergebnislisten und drei Berechtigungswelten.

Das Wissen liegt verteilt und heißt überall anders

In DOORS liegen Anforderungen in Modulen mit Baselines, in Polarion Work Items und LiveDocs mit Revisionshistorie, in Confluence Architektur-Entscheidungen, Review-Protokolle und Betriebswissen, auf den Netzlaufwerken Zulieferer-Spezifikationen, Messberichte und die Excel-Liste, die seit Jahren als inoffizielle Wahrheit dient. Erschwerend kommt die Begriffsdrift dazu: Dieselbe Funktion trägt im Lastenheft einen anderen Namen als im Wiki, und die Abkürzung aus dem Review-Protokoll taucht in keinem Anforderungstext auf. Eine Volltextsuche findet Wortgleichheit. Inhaltliche Nähe zwischen unterschiedlich formulierten Ständen findet sie nicht, und über Systemgrenzen hinweg sucht sie gar nicht erst.

Versionsstände und Zugriffsrechte entwerten die Treffer

Selbst der Treffer, der kommt, ist oft keiner. Die Suche liefert die Anforderung aus einem alten Stand, während längst eine neuere Baseline freigegeben ist; der Engineer merkt das erst beim Abgleich von Hand. Und ein zentraler Suchindex über alle Ablagen wirft die zweite Frage auf: Wer darf was sehen? Zulieferer-Dokumente unterliegen Vertraulichkeitsvereinbarungen, Personal- und Kalkulationsordner liegen auf denselben Laufwerken, und die Projekttrennung zwischen Kundenprogrammen ist vertraglich zugesichert. Eine Suche, die Berechtigungen ignoriert, ist im Zulieferumfeld kein Komfortgewinn; sie ist ein Compliance-Vorfall mit Ansage.

Das RAG-Grundprinzip: Index, Retrieval, Antwort mit Fundstelle

Retrieval Augmented Generation ist als Begriff sperriger als die Sache selbst. Das Prinzip besteht aus drei Schritten, die sich ohne Modell-Mathematik erklären lassen, und genau diese drei Schritte unterscheiden ein Doku-RAG von einem allgemeinen Chatbot.

Index und Retrieval: inhaltliche Nähe statt Wortgleichheit

Im ersten Schritt werden die angebundenen Inhalte in Abschnitte zerlegt und so aufbereitet, dass inhaltliche Ähnlichkeit berechenbar wird; technisch geschieht das über einen Vektor-Index, in dem ähnliche Aussagen nahe beieinander liegen, auch wenn ihre Worte verschieden sind. Zu jedem Abschnitt gehören Metadaten: Quellsystem, Modul oder Seite, Versionsstand oder Baseline, Berechtigungskreis. Im zweiten Schritt, dem Retrieval, sucht das System zu einer gestellten Frage die passendsten Abschnitte heraus, gefiltert nach den Rechten des Fragenden. Die Begriffsdrift zwischen Lastenheft und Wiki verliert damit ihren Schrecken, weil die Suche auf Bedeutungsebene arbeitet.

Antwort mit Fundstelle: das Sprachmodell formuliert, die Quellen tragen

Im dritten Schritt erhält ein Sprachmodell die Frage zusammen mit den gefundenen Abschnitten und formuliert daraus eine Antwort. Das Modell soll dabei ausschließlich aus den mitgelieferten Abschnitten schöpfen, und jede Aussage trägt ihre Fundstelle: Quellsystem, Dokument, Versionsstand, Link zum Original. Findet das Retrieval nichts Belastbares, lautet die korrekte Antwort, dass zu dieser Frage keine Fundstelle vorliegt. Das Sprachmodell ist in dieser Architektur ein Formulierungswerkzeug; die Autorität liegt bei den angebundenen Quellen und bleibt dort.

Drei Anforderungen, die im Serienkontext nicht verhandelbar sind

Was für ein internes Marketing-Wiki genügt, genügt für Entwicklungsdokumentation nicht. Der Maßstab ist die Nachweisfähigkeit, und die Branche steht dabei ohnehin unter Druck: 46 % der Automotive-Teams fällt der Nachweis der ISO-26262-Konformität schwer (Quelle: Perforce, 2025). Ein Auskunftssystem, das Antworten ohne Beleg liefert, verschärft dieses Problem. Drei Anforderungen entscheiden deshalb über die Serientauglichkeit.

Quellen- und Versionsanzeige in jeder Antwort

Eine Antwort ohne Fundstelle ist nicht prüfbar, und was nicht prüfbar ist, ist nicht assessierbar. Jede Antwort braucht darum ein festes Format: die Aussage, die Quelle, den Versionsstand und den Link ins Quellsystem. Wer die Antwort in ein Arbeitsprodukt übernimmt, prüft am Original; die Fundstelle macht diese Prüfung zu einem Klick statt zu einer halben Stunde Suche. Für das Assessment gilt dieselbe Logik: Der Assessor fragt, woher eine Aussage stammt, und die Antwort des Systems muss diese Frage bereits beantwortet haben.

Zugriffsrechte-Vererbung aus den Quellsystemen

Wer im Quellsystem ein Dokument nicht sehen darf, darf es auch über den Umweg der KI nicht sehen, in keiner Zusammenfassung und in keinem Zitat. Technisch heißt das: Der Berechtigungskreis wird je Abschnitt als Metadatum mitgeführt, und das Retrieval filtert zur Abfragezeit gegen die Rechte des Fragenden. Organisatorisch heißt es: Das Rechtekonzept der Quellsysteme ist dokumentiert, und die Vererbung wird bei der Anbindung je System geprüft und getestet. Ohne diese Vererbung wird das RAG zum Rechte-Bypass, der jahrelang gepflegte Projekttrennung in einem einzigen Suchfeld aufhebt.

Widersprüchliche Stände und der Baseline-Bezug

In jedem gewachsenen Projekt existiert dieselbe Anforderung in mehreren Ständen: im Arbeitsstand, in der letzten freigegebenen Baseline, in der Baseline des vorletzten Kundentermins. Ein brauchbares Doku-RAG braucht dafür eine Regel statt eines Zufallsprinzips. Bewährt hat sich der Baseline-Bezug: Antworten beziehen sich standardmäßig auf einen definierten freigegebenen Stand, Arbeitsstände werden als solche gekennzeichnet, und bei echten Widersprüchen zeigt das System beide Stände nebeneinander mit ihren Fundstellen. Das Harmonisieren widersprüchlicher Aussagen ist keine Aufgabe des Systems; es ist eine Klärungsaufgabe für das Team, und das System macht sie sichtbar.

Anbindungswege je Quellsystem

Die gute Nachricht: Für die führenden Systeme existieren dokumentierte Zugangswege, die ohne Eingriff in die Systeme selbst auskommen. Die folgende Übersicht nennt je Quellsystem den typischen Zugang und die Besonderheit, die bei der Anbindung Aufwand macht.

Führende Systeme mit definierter Schnittstelle

Für DOORS 9 ist der robuste Weg der Austausch über das Requirements Interchange Format, einen Standard der Object Management Group (OMG ReqIF); IBM dokumentiert den ReqIF-Export einschließlich der Option, Baseline-Informationen mitzuführen, und für automatisierte Abläufe stehen DXL-Skripte sowie OSLC über DOORS Web Access bereit. Polarion bringt eine von Siemens dokumentierte REST API mit, über die Work Items und Dokumente einschließlich eines Revisionsbezugs abrufbar sind; damit lässt sich der Versionsstand je Abschnitt sauber in die Index-Metadaten übernehmen. Confluence liefert Seiten, Anhänge und die Seitenhistorie über seine REST API. In allen drei Fällen gilt: Die Anbindung liest über die offiziellen Schnittstellen und lässt die Systeme unangetastet.

Netzlaufwerke und Office-Ablagen

Der unbequemste Teil der Anbindung sind selten die ALM-Systeme; es sind die Laufwerke. Dort liegen PDF, Word, Excel und PowerPoint in gewachsenen Ordnerstrukturen, deren Berechtigungen sich nur über Verzeichnis-ACLs ableiten lassen und deren Inhalte niemand systematisch pflegt. Ein Datei-Crawler bekommt die Inhalte in den Index, aber die Architektur-Entscheidungen fallen davor: Welche Ablagen sind führend genug für die Aufnahme, wie werden Dubletten und veraltete Kopien behandelt, und wer beantwortet die Eigentümerfrage je Ordner. Projekte, die hier ohne Aufräum-Regel starten, indexieren ihren eigenen Wildwuchs und wundern sich über widersprüchliche Antworten.

Arbeitsmodus: rein lesend, ohne Schreibzugriffe

Ein Doku-RAG gehört in die Klasse der rein lesenden Augmentation, in unserem Vorgehensmodell die Triage-Klasse B: Das System stellt Sichten bereit, der Mensch urteilt und verantwortet. Die vollständige Logik der Klassen beschreibt der Beitrag zur Triage zwischen Automatisierung und Augmentation im Engineering. Der rote Faden bleibt derselbe wie überall in der Werkzeug-Ebene: KI assistiert, der Mensch verantwortet.

Warum das System nicht in die Quellsysteme schreibt

Automatische Schreibzugriffe in DOORS, Polarion oder Confluence sind für ein Auskunftssystem weder nötig noch wünschenswert. Die Quellsysteme sind führend, und ein zweiter, maschinell erzeugter Arbeitsstand würde genau die Versionsklarheit zerstören, die das System herstellen soll. Hinzu kommt die Nachweisseite: Ein Werkzeug, das sicherheitsrelevante Arbeitsprodukte verändert, wirft nach ISO 26262 Fragen der Tool-Vertrauensbetrachtung auf, die ein rein lesendes Werkzeug in dieser Schärfe nicht stellt. Der Verzicht auf Schreibzugriffe hält den Baustein in der Klasse B, lässt die bestehenden Freigabeprozesse unberührt und macht die Einführung entsprechend leichtgewichtig.

Die Betriebsordnung gehört zur Architektur

Rein lesend bedeutet nicht regelfrei. Zum tragfähigen Betrieb gehören eine definierte Aktualisierungsfrequenz je Quelle, damit der Index dem Projekt nicht hinterherläuft, eine nachvollziehbare Protokollierung von Anbindung und Index-Läufen, ein Feedback-Kanal, über den falsche oder veraltete Antworten gemeldet und behoben werden, sowie eine benannte Zuständigkeit je angebundenem System. Regulatorisch ist der Rahmen überschaubar: Ein internes Auskunftssystem dieser Art fällt nach der KI-Verordnung (EU) 2024/1689 in der Regel in niedrige Risikoklassen; die Einstufung gehört dennoch je Anwendung geprüft, und die KI-Kompetenz der Beschäftigten ist seit Februar 2025 ohnehin Pflicht.

Was ein Doku-RAG im Projektalltag trägt

Steht die Architektur, trägt das Feld weiter, als die nüchterne Beschreibung vermuten lässt. Der Nutzen entsteht dort, wo heute Stunden in der Suche über Werkzeug-Grenzen verschwinden.

Typische Fragen aus dem Projektalltag

Die Einarbeitung neuer Teammitglieder wird kürzer, weil Fragen wie die nach dem Grund einer Design-Entscheidung von vor drei Jahren eine belegte Antwort bekommen. Zulieferer-Anfragen zu Schnittstellenständen lassen sich gegen die richtige Baseline beantworten. Die Assessment-Vorbereitung profitiert, weil die Frage nach der Evidenz zu einem Prozess-Outcome auf die Fundstelle führt. Zwei Nachbarfelder schließen direkt an: Für gewachsenen Quellcode gilt eine verwandte Logik, die der Beitrag zum KI-gestützten Codeverständnis für AUTOSAR-Codebasen beschreibt, und wo erfahrene Kollegen das Haus verlassen, wird die abfragbare Doku-Sicht zum Bewahrungsort für gesichertes Wissen, wie der Beitrag zur Wissenssicherung vor dem Renteneintritt zeigt.

Wo die Grenze verläuft

Das System liefert Sichten mit Beleg; es liefert keine Urteile. Ob eine gefundene Design-Entscheidung noch trägt, ob ein Widerspruch zwischen zwei Baselines eine Änderung erfordert, ob eine Auskunft an den Zulieferer gehen darf: Das bleibt menschliche Entscheidung, und jede Aussage, die das Haus verlässt, hat einen menschlichen Absender mit Verantwortung. Wer diese Grenze respektiert, bekommt ein Werkzeug, das Suchzeit in Klärungszeit verwandelt. Wer sie ignoriert, hat ein Orakel, und Orakel bestehen keine Assessments.

Nächste Schritte

Ob ein Doku-RAG in Ihrem Projekt der erste tragfähige Baustein ist, hängt von Toolchain, Datenqualität und Rechtelage ab und lässt sich nicht am Schreibtisch entscheiden. Der geordnete Einstieg sieht so aus:

1. Überblick lesen: Der Beitrag zu KI in der Automotive-Softwareentwicklung ordnet die abfragbare Doku-Sicht in die vier Einsatzfelder der Werkzeug-Ebene ein.
2. Vorgehen prüfen: Die Seite zur AI-Transformation im Automotive Engineering beschreibt, wie aus einzelnen Bausteinen ein geführtes Transformationsvorhaben wird.
3. Gespräch vereinbaren: In einem Qualifying-Call klären wir, ob Toolchain, Datenlage und Rechtekonzept Ihres Projekts einen belastbaren Start erlauben.

Häufige Fragen

Die folgenden Antworten fassen die Position von sensified zur abfragbaren Entwicklungsdokumentation zusammen. Sie beschreiben typisierte Architektur-Entscheidungen; wie die Anbindung in einem konkreten Projekt aussieht, wird je Kunde und Toolchain geprüft.

Kann KI Fragen aus unserer Entwicklungsdokumentation beantworten?

Ja, wenn eine RAG-Architektur an die führenden Quellsysteme angebunden ist und drei Bedingungen erfüllt: Quellen- und Versionsanzeige in jeder Antwort, Vererbung der Zugriffsrechte aus den Quellsystemen und ein definierter Baseline-Bezug bei widersprüchlichen Ständen. Das System arbeitet rein lesend; Antworten ohne Fundstelle sind im Serienkontext nicht verwertbar.

Was unterscheidet ein Doku-RAG von einem allgemeinen Chatbot?

Ein allgemeiner Chatbot antwortet aus seinem Trainingswissen und kann Projektfragen darum nur raten. Ein Doku-RAG sucht zu jeder Frage zuerst die passenden Abschnitte in den angebundenen Quellen und formuliert die Antwort ausschließlich daraus, mit Fundstelle und Versionsstand. Findet es keine Fundstelle, sagt es das. Die Autorität liegt bei den Quellen, das Sprachmodell formuliert nur.

Wie kommt ein RAG-System an Inhalte aus DOORS und Polarion?

Für DOORS 9 über den ReqIF-Export, DXL-Skripte oder OSLC über DOORS Web Access, jeweils mit mitgeführter Baseline-Information; für DOORS Next über die Schnittstellen der Jazz-Plattform. Polarion stellt eine dokumentierte REST API bereit, über die Work Items und Dokumente einschließlich Revisionsbezug abrufbar sind. Confluence liefert Seiten und Historie über seine REST API. Alle Wege sind rein lesend.

Wie werden Zugriffsrechte in einem Doku-RAG berücksichtigt?

Der Berechtigungskreis wird je Inhaltsabschnitt als Metadatum im Index mitgeführt, und das Retrieval filtert zur Abfragezeit gegen die Rechte des Fragenden. Wer ein Dokument im Quellsystem nicht sehen darf, erhält daraus weder Zitate noch Zusammenfassungen. Die Vererbung wird bei der Anbindung je System geprüft und getestet, sonst wird das System zum Rechte-Bypass.

Was passiert bei widersprüchlichen Versionsständen?

Das System beantwortet Fragen standardmäßig gegen einen definierten freigegebenen Stand und kennzeichnet Arbeitsstände als solche. Bei echten Widersprüchen zeigt es beide Stände nebeneinander mit ihren Fundstellen. Die Klärung des Widerspruchs bleibt Aufgabe des Teams; das System macht sie sichtbar und belegbar.

Schreibt das System in DOORS, Polarion oder Confluence?

Nein. Ein Doku-RAG arbeitet als rein lesende Augmentation, in unserer Triage die Klasse B. Die Quellsysteme bleiben führend, es entsteht kein zweiter maschineller Arbeitsstand, und die bestehenden Freigabeprozesse bleiben unberührt. Schreibende Automatisierung wäre ein anderer Baustein mit eigenem Freigabepfad und eigener Prüfung.

Wie geht das System mit Halluzinationen um?

Über vier Mechanismen: Das Sprachmodell formuliert ausschließlich aus den gefundenen Abschnitten, jede Aussage trägt eine Fundstelle zur Prüfung am Original, ohne belastbare Fundstelle verweigert das System die Antwort, und ein Feedback-Kanal fängt gemeldete Fehler ein. Ein Restrisiko bleibt; deshalb prüft der Mensch jede Aussage, bevor sie in ein Arbeitsprodukt oder eine Auskunft nach außen einfließt.