Eigenentwicklung · Referenzsystem
Status: Geführte Referenzdemo verfügbar; aktive Weiterentwicklung
Fachlicher Schwerpunkt: Kontrollierte lokale KI-Wissenssysteme mit nachvollziehbaren Quellen und systematischer Evaluation.
KGM Knowledge RAG ist ein eigenes Referenzsystem des Ingenieurbüros Marschner. Es zeigt, wie freigegebenes internes Wissen lokal erschlossen, für konkrete Fragen bereitgestellt und mit nachvollziehbaren Quellen verbunden werden kann.
Im Mittelpunkt steht nicht eine möglichst überzeugend formulierte KI-Antwort, sondern ein kontrollierter und überprüfbarer Gesamtprozess. Das Referenzsystem dient als technischer Kompetenznachweis und als Grundlage für die Planung abgegrenzter Kundenpiloten.
Was Sie in der geführten Demo sehen
Die geführte Referenzdemo ist verfügbar. An fünf synthetischen, ausdrücklich freigegebenen Markdown-Dokumenten lässt sich der Weg von der Suche zur Antwort mit zugeordneten Quellen nachvollziehen. Der Bestand enthält keine Kundendaten. Suche und Antwortverarbeitung laufen auf der lokalen Referenzworkstation, ohne Cloud-KI-Aufrufe im gezeigten Laufzeitpfad.
Eine lokale Browseroberfläche führt durch vier feste Fälle. Gemeinsam betrachten wir dabei vier Fragen:
- Finden: Welches Dokument beziehungsweise welche Textstelle findet die Suche?
- Belegen: Trägt die angezeigte Quelle die Antwortaussage?
- Verbinden: Werden Informationen aus mehreren Quellen richtig zusammengeführt?
- Grenzen erkennen: Wie reagiert das System, wenn die erforderliche Grundlage fehlt?
Das sind Beobachtungs- und Prüffragen, keine vorweggenommenen Erfolge. Der aktuelle Referenzstand kann unvollständige, unbelegte oder widersprüchliche Antworten liefern. Quellen machen Aussagen prüfbar; ob sie richtig und vollständig sind, bleibt fachlich zu bewerten. Fehlende Grundlage soll offen benannt werden, wird aber nicht zuverlässig erkannt.
Die Vorführung ist begleitet. Es gibt keinen frei zugänglichen Live-Zugang, keine freie Eingabe beliebiger Fragen und keine spontane Aufnahme von Kundendaten. Die begrenzte Demo ist mit diesen bekannten Grenzen angenommen; sie belegt noch keine Eignung für einen konkreten Kundenbestand.
Ausgangslage
Unternehmenswissen liegt häufig verteilt in Projektdokumentationen, Spezifikationen, Betriebshandbüchern, Runbooks oder internen Anleitungen. Klassische Stichwortsuchen erfassen sprachlich verwandte Inhalte nur eingeschränkt und machen nicht immer deutlich, welche Quelle eine gefundene Aussage tatsächlich trägt.
Allgemeine Sprachmodelle lösen dieses Problem nicht automatisch. Ohne kontrollierten Wissensbestand, nachvollziehbares Retrieval und überprüfbare Quellen können sprachlich plausible Antworten entstehen, deren fachliche Grundlage unklar bleibt.
Das Referenzsystem untersucht deshalb den gesamten Weg vom freigegebenen Dokument bis zur Antwort und ihrer fachlichen Prüfung – einschließlich der Frage, wie das Modell mit fehlender Grundlage umgeht.
Ziel des Referenzsystems
KGM Knowledge RAG soll die technische Machbarkeit eines kontrollierten lokalen RAG-Pfads nachvollziehbar belegen.
Ziel der Weiterentwicklung ist, dass
- ein abgegrenzter und versionierter Wissensbestand reproduzierbar verarbeitet wird,
- relevante Textabschnitte für eine Frage nachvollziehbar ausgewählt werden,
- Antworten auf den bereitgestellten Kontext begrenzt bleiben,
- verwendete Quellen eindeutig zugeordnet werden,
- unzureichende Evidenz offen benannt und eine nicht belegbare Antwort unterlassen wird,
- technische Prüfungen durch eine fachliche Bewertung ergänzt werden,
- bekannte Grenzen sichtbar dokumentiert bleiben.
Diese Ziele sind kein Nachweis, dass die aktuelle Demo sie in jedem Fall erfüllt. Angestrebt wird ein belastbarer Referenzstand für Architektur-, Qualitäts- und Pilotentscheidungen, kein fertiges Standardprodukt.
Kontrollierter Lösungsansatz
Die Verarbeitung beginnt mit einem versionierten synthetischen Referenzbestand ohne Kunden- oder personenbezogene Daten. Die Dokumente werden nach festgelegten Regeln aufbereitet und in reproduzierbare Textabschnitte zerlegt.
Für eine Anfrage werden semantisch passende Abschnitte aus einem lokalen Vektorindex ausgewählt. Nur eine begrenzte Auswahl dieser Abschnitte gelangt in den Antwortkontext. Die Anwendung ordnet gültige Quellenmarker im Antworttext den tatsächlich bereitgestellten Quellen zu und prüft definierte formale Regeln. Daraus folgt keine automatische inhaltliche Beweisprüfung jeder Aussage.
Reicht der bereitgestellte Kontext nicht aus, soll das Modell die fehlende Grundlage offen benennen und sich gegebenenfalls enthalten. Das ist gewünschtes Modellverhalten; eine zuverlässige automatische Erkennung fehlender Evidenz oder fachlich richtiger Enthaltung ist nicht gewährleistet.
Architektur und Technologien
Das Referenzsystem verbindet folgende Bausteine:
- Python-basierte Kommandozeilenwerkzeuge unter Linux beziehungsweise WSL,
- Markdown als kontrollierbares Dokumentformat,
- versionierte Manifeste und Prüfsummen für den Referenzbestand,
- deterministische Aufbereitung und Segmentierung der Dokumente,
- lokale Embeddings zur semantischen Repräsentation,
- einen lokalen FAISS-Vektorindex für das Retrieval,
- ein lokal ausgeführtes Antwortmodell mit begrenztem Kontext,
- formale Prüfung von Antwortformat und Quellenzuordnung,
- automatisierte Tests, versionierte Evaluationsfälle und Git-basierte Freigaben.
Die Architektur trennt Dokumentaufbereitung, Retrieval, Antworterzeugung und Evaluation bewusst voneinander. Dadurch können einzelne Komponenten geändert und erneut geprüft werden, ohne den gesamten Prozess als undurchsichtige Einheit zu behandeln.
Die Grafik zeigt den vereinfachten Antwortpfad; die im Antwortvertrag vorgesehene Ablehnung bei unzureichendem Kontext ist nicht dargestellt. Technische Tests prüfen Aufbereitung und Index, formale Prüfungen Antwortformat und Quellenzuordnung. Die manuelle Fachbewertung ergänzt die Evaluation am Referenzstand und ist kein automatischer Schritt jeder Antwort.
Konkrete Modellnamen, Hardwarekonfigurationen und einzelne Leistungswerte werden nicht als dauerhafte Eigenschaften des Referenzsystems veröffentlicht.
Engineering und Qualitätssicherung
KGM Knowledge RAG wird als Engineering-Projekt entwickelt. Architekturentscheidungen, Konfigurationen, Testfälle und bekannte Grenzen werden versioniert und gegen einen definierten Referenzstand geprüft.
Zur Qualitätssicherung gehören insbesondere:
- automatisierte Prüfungen der Datenaufbereitung und Indexerstellung,
- reproduzierbare Retrieval- und Antwortläufe,
- formale Validierung der Quellenangaben,
- positive, dokumentenübergreifende und nicht beantwortbare Testfragen,
- getrennte Bewertung von Retrieval, Antwortformat und fachlicher Vollständigkeit,
- manuelle fachliche Prüfung, wo automatisierte Kriterien allein nicht ausreichen,
- dokumentierte Freigaben und erneute Prüfung nach relevanten Änderungen.
Freigaben beziehen sich auf einen ausdrücklich begrenzten Einsatz und dokumentieren die geprüften Kriterien sowie bekannte Abweichungen. Die geführte Referenzdemo ist mit bekannten Inhaltsgrenzen angenommen. Das bedeutet weder, dass alle fachlichen Qualitätsziele fehlerfrei erfüllt sind, noch eine allgemeine Modell- oder Produktionsfreigabe.
Belegbare Ergebnisse
Die Retrieval-Grundlage wurde mit einem versionierten Fragensatz geprüft. Kontrolliert wurden die erwarteten Quellen, ihre Rangfolge, die Wiederholbarkeit der Ergebnisse und der Umgang mit Fragen außerhalb des Referenzbestands. Die für den dokumentierten Referenzstand festgelegten Retrieval-Kriterien wurden erfüllt.
Diese Ergebnisse gelten ausschließlich für den jeweils geprüften Datenbestand und dessen Chunking-, Embedding-, Index- und Retrieval-Konfiguration. Sie sind weder ein allgemeiner Qualitäts- oder Skalierungsnachweis noch ein Leistungsversprechen für andere Datenbestände.
Als weiterer Meilenstein ist die begrenzte geführte Referenzdemo einschließlich ihres Kundenmedienpakets freigegeben. Einrichtung und ausgewerteter manueller Betrieb der getrennten Demo-Installation sind angenommen. Bekannte inhaltliche Fehler bleiben sichtbar; die Annahme ist kein allgemeiner Qualitätsnachweis.
Weiterführende Evaluationen berücksichtigen zusätzlich Antwortformat, Quellenbezug, fachliche Vollständigkeit und den Umgang mit fehlender Grundlage. Technische und formale Prüfungen werden dabei bewusst durch eine manuelle fachliche Bewertung ergänzt. Frühere Evaluations- und Laufzeitbefunde bleiben an ihren jeweiligen Daten-, Modell- und Konfigurationsstand gebunden; sie werden nicht als Ergebnisse der heutigen Demo ausgegeben.
Antwortqualität, Laufzeit und Ressourcenbedarf hängen vom Datenbestand, den eingesetzten Modellen, der Hardware und der Konfiguration ab. Einzelne Referenzmessungen werden deshalb nicht als dauerhaftes Leistungsversprechen veröffentlicht.
Übertragbare Anwendungsszenarien
Die mit dem Referenzsystem entwickelte Methodik kann als Ausgangspunkt für abgegrenzte Unternehmenssituationen dienen.
Projektdokumentationen und Spezifikationen
Technische Entscheidungen, Anforderungen und dokumentierte Zusammenhänge können semantisch erschlossen und mit ihren ursprünglichen Quellen verbunden werden.
Runbooks und Supportwissen
Betriebswissen, Fehlerbeschreibungen und dokumentierte Lösungswege können für wiederkehrende Supportfragen kontrolliert auffindbar gemacht werden.
Interne Anleitungen und FAQs
Freigegebene interne Anleitungen können als begrenzter Wissensbestand für nachvollziehbare Antworten auf wiederkehrende Fragen dienen.
Diese Szenarien beschreiben übertragbare Einsatzfelder. Sie sind keine Behauptung, dass sämtliche Datenquellen, Integrationen oder Betriebsvarianten bereits als fertige Standardlösung umgesetzt sind.
Bewusste Grenzen
Das Referenzsystem besitzt bewusst gesetzte Grenzen:
- Es arbeitet mit einem begrenzten synthetischen Referenzbestand und nicht mit realen Kundendaten.
- Ergebnisse lassen sich nicht automatisch auf andere Datenbestände übertragen.
- Quellenmarker belegen die Zuordnung zu bereitgestellten Quellen, nicht die fachliche Richtigkeit oder Vollständigkeit einer Antwort.
- Fehlende Grundlage kann übersehen werden; auch eine Enthaltung kann fachlich falsch sein.
- Unvollständige, unbelegte oder widersprüchliche Antworten sind bekannte Grenzen des aktuellen Referenzstands.
- Es besteht keine Garantie für fehlerfreie, vollständige oder rechtlich beziehungsweise fachlich konforme Antworten.
- Das System ist keine fertige SaaS-Plattform und kein allgemein verfügbares Standardprodukt.
- Es gibt keinen öffentlichen Live-Demo-Zugang.
- Benutzerverwaltung, Mandantenfähigkeit, öffentliche API, Hochverfügbarkeit und Enterprise-SLA sind nicht Bestandteil des Referenzsystems.
- Es besteht kein unbegrenztes Skalierungs- oder Leistungsversprechen.
- Der vollständige Quellcode, interne Prompts und sicherheitsrelevante Betriebsdetails werden nicht öffentlich bereitgestellt.
Diese Grenzen gehören zum Kompetenznachweis: Sie zeigen, unter welchen Bedingungen Ergebnisse belastbar eingeordnet werden können.
Vom Referenzsystem zum Kundenpilot
Ein Kundenpilot übernimmt nicht einfach die Referenzkonfiguration. Er beginnt mit einem eigenen Anwendungsfall, einem freigegebenen Wissensbestand und gemeinsam festgelegten Erfolgskriterien.
Dazu gehören typischerweise:
- fachlichen Informationsbedarf und Nutzerfragen abgrenzen,
- Datenbestand, Qualität und Zugriffsgrenzen prüfen,
- geeignete Aufbereitung, Retrieval- und Betriebsannahmen festlegen,
- einen begrenzten Pilot implementieren,
- Retrieval, Quellen, Antworten und Ablehnungsfälle evaluieren,
- auf Grundlage der Ergebnisse über Ausbau oder Beendigung entscheiden.
Die Leistungsseite zu KGM Knowledge RAG beschreibt den möglichen Einstieg über einen KI-Wissenscheck und einen begrenzten RAG-Pilot.
Die Artikelserie „Vom Dokument zum lokalen Wissensassistenten“ erklärt Suche, Quellenprüfung, Grenzen und die Vorbereitung eines Piloten an einem durchgängigen fiktiven Beispiel.
Die Artikelserie „Lokale KI-Infrastruktur für Unternehmen“ erläutert technische Grundlagen und Entscheidungswege für lokale Betriebsmodelle.
Geführte Referenzdemo kennenlernen
Lernen Sie den Ansatz an den vier festen Fällen kennen und besprechen Sie die beobachteten Antworten und Quellen. Für Ihren eigenen Anwendungsfall bleibt der KI-Wissenscheck der erste fachliche Schritt; ein Pilot folgt nur bei bestätigter Eignung.