Die KI findet das Dokument. Aber kennt sie den Kontext?

SharePoint mit Langdock, ChatGPT oder einem anderen KI-Assistenten zu verbinden, ist ein sinnvoller Einstieg. Mitarbeiter finden Dokumente schneller, lassen Inhalte zusammenfassen und stellen Fragen zu vorhandenen Dateien. Für kleine Teams mit überschaubaren Anforderungen kann das bereits ausreichen.

Mit mehreren Tausend Nutzern verändert sich die Aufgabe. Dann zählt nicht allein, ob ein System irgendeine passende Textstelle findet. Es muss die gültige Information, in der richtigen Version, mit fachlichem Kontext und nachvollziehbarer Herkunft bereitstellen – und das bei kontrollierbaren Antwortzeiten und Betriebskosten.

Die entscheidende Frage lautet deshalb nicht: Welcher Connector kann SharePoint durchsuchen? Sondern: Welche RAG-Architektur benötigt unser Geschäftsprozess, damit Informationen zuverlässig gefunden, verstanden und verwendet werden?

Langdock bietet Integrationen für Unternehmensquellen und Funktionen zur Suche und Bereitstellung relevanter Inhalte. Eine pauschale Aussage, bei jeder Anfrage würden vollständige SharePoint-Dokumente an das Sprachmodell geschickt, wäre falsch. Moderne Retrieval-Verfahren können gezielt Dokumentabschnitte abrufen und nach Relevanz sortieren.

Das ist wichtig, löst aber nicht automatisch die Frage nach der fachlichen Verbindlichkeit von Daten. Ein Connector weiß nicht aus sich heraus, welcher Zeichnungsstand freigegeben ist, ob zwei unterschiedliche Produktbezeichnungen dieselbe Komponente meinen oder welche Arbeitsanweisung für eine bestimmte Maschinenkonfiguration gilt.

Ein Sprachmodell kann Zusammenhänge aus Text ableiten. Diese Ableitungen sind jedoch kein Ersatz für Stammdaten, dokumentierte Geschäftsregeln und eindeutige Beziehungen. Technisch funktionierender Zugriff ist noch keine belastbare Wissensarchitektur.

In Unternehmen ordnet der Vertrieb Dateien nach Kunden, Engineering nach Projektnummern, der Service nach Anlagen und die Produktion nach Linien. Dieselbe Komponente taucht unter mehreren Bezeichnungen auf. Dazu kommen Dubletten, historische Revisionen, PDF-Anhänge und Tabellen, deren Bedeutung außerhalb der jeweiligen Fachabteilung kaum dokumentiert ist.

Beispiel Maschinenbau: Ein Servicemitarbeiter fragt, welche Wartungsanweisung für die Antriebseinheit einer bestimmten Maschine in ihrer aktuellen Konfiguration gilt. Eine reine Textsuche kann mehrere Treffer liefern. Verbindlich wird die Antwort erst, wenn das System Maschinenkonfiguration, Bauteil, Dokument-ID, Freigabestatus und Gültigkeitszeitraum zusammenführen kann.

Diese Beziehungen liegen häufig nicht vollständig in SharePoint, sondern verteilt in ERP, PLM, MES oder weiteren Systemen. Sie müssen gezielt integriert und modelliert werden.

Eine Ontologie beschreibt fachliche Konzepte, Eigenschaften und erlaubte Beziehungen. Ein Knowledge Graph kann darauf aufbauend konkrete Entitäten und Verknüpfungen abbilden: Maschine X enthält Antriebseinheit A; diese verwendet Bauteil B; für Bauteil B gilt Wartungsanweisung W in Revision 4, die Revision 3 ersetzt.

Nicht jeder Anwendungsfall braucht einen Knowledge Graph. Oft reichen eindeutige IDs, Stammdaten, Mapping-Tabellen und sauber gepflegte Metadaten. Werden aber komplexe Beziehungen über Systeme hinweg zur eigentlichen Frage, kann eine graphbasierte Wissensschicht sinnvoll sein.

Die entscheidende Regel: Modellgestützt erkannte Beziehungen validieren, bevor sie als verbindliche Fakten dienen. Ein Embedding findet ähnliche Texte; es beweist nicht automatisch die Gültigkeit einer Wartungsanweisung.

Eine gute RAG-Pipeline wählt relevante Quellen aus und stellt dem Sprachmodell nur benötigte Informationen bereit. Problematisch werden Implementierungen, die zu viele Treffer, redundante Abschnitte oder große Dokumentpassagen ohne wirksame Filter in den Prompt aufnehmen.

Rechenbeispiel: 1.500 Mitarbeiter stellen täglich je acht Fragen. Werden pro Anfrage 12.000 Kontext-Tokens übertragen, entstehen 144 Millionen Kontext-Tokens am Tag. Bei 2.000 Kontext-Tokens je Frage sind es 24 Millionen. Das ist der sechsfache Kontextverbrauch – ausdrücklich keine Messung von Langdock und keine Aussage über sechsfache Gesamtkosten.

Die tatsächliche Wirtschaftlichkeit hängt unter anderem von Modellpreisen, Cache-Treffern, Indexierung, Reranking, zusätzlichen Tool-Aufrufen und Antwortqualität ab. Deshalb optimieren wir nicht auf möglichst wenige Tokens um jeden Preis, sondern auf Kosten pro erfolgreich gelöster Aufgabe.

PDFs, Word-Dateien und Tabellen nach Markdown zu konvertieren, kann ein nützlicher Verarbeitungsschritt sein. Markdown ist gut lesbar, versionierbar und für viele Retrieval-Pipelines geeignet. Doch aus 10.000 uneinheitlichen PDFs werden durch die Konvertierung nicht automatisch 10.000 fachlich konsistente Wissenseinheiten.

Dokumentversionen, Berechtigungen, Beziehungen, Tabellenstruktur, Quellen-IDs und Freigabestatus müssen weiterhin behandelt werden. Auch ein Vektorindex ersetzt keine Datenqualität. Bei fehlerhafter Extraktion können Tabellenbezüge, Einheiten oder Zeichnungsverweise verloren gehen.

Deshalb beurteilen wir Dokument-Pipelines nicht an der Anzahl erzeugter Chunks, sondern daran, ob die benötigte Information korrekt, vollständig und nachprüfbar abgerufen werden kann.

Welche Segmentierungsstrategien sinnvoll sind und wann LLM-gestütztes Chunking zusätzlichen Nutzen bringt, erklären wir im Beitrag Agentic Chunking: Dokumente für RAG sinnvoll strukturieren.

Die Datenpipeline beginnt bei den tatsächlichen Quellsystemen. SharePoint und Google Drive liefern Dokumente; ERP, CRM, PLM, MES und Datenbanken enthalten häufig die autoritativen strukturierten Informationen. Wir integrieren diese Quellen abhängig vom Anwendungsfall, statt alles ungeprüft in einen weiteren Ordner zu kopieren.

Anschließend extrahieren und klassifizieren wir Inhalte, erhalten sinnvolle Dokumentabschnitte, normalisieren Einheiten und Bezeichnungen und versehen Datensätze mit Quellreferenzen, Versionen, Zeitstempeln und Zugriffsmetadaten. Änderungen und Löschungen müssen ebenfalls in den Suchindizes ankommen.

Wo eindeutige Datensätze vorhanden sind, verwenden wir strukturierte Abfragen und APIs. Wo Fragen sprachlich unscharf sind, ergänzen wir semantische Suche. So wird die Retrieval-Schicht zur bewusst entworfenen Schnittstelle zwischen Daten und Modell.

Mehr zu den zugrunde liegenden Pipelines und Datenmodellen in unserem Data Engineering-Leistungsbereich.

Produktnummern und exakte Fehlercodes lassen sich oft mit klassischer Suche zuverlässig finden. Beschreibungen technischer Störungen profitieren eher von semantischer Suche. Bei Arbeitsanweisungen kommen Filter für Version, Standort, Maschinentyp und Freigabestatus hinzu.

Eine belastbare RAG-Architektur kombiniert je nach Bedarf Keyword-Suche, Vektorsuche, Hybrid Search, Metadatenfilter, Reranking und strukturierte Datenbank- oder API-Abfragen. Die Orchestrierung wählt nicht möglichst viele Quellen, sondern die passenden Quellen für eine konkrete Frage.

Das Modell bekommt anschließend einen begrenzten Kontext mit überprüfbaren Referenzen. Liegen widersprüchliche oder unvollständige Daten vor, sollte die Anwendung dies sichtbar machen, statt eine vermeintlich sichere Antwort zu formulieren.

Wie Retrieval, Kontextaufbereitung und Generation grundsätzlich zusammenspielen, zeigt unser technischer Überblick zu Retrieval-Augmented Generation.

Für eine belastbare Antwort reicht der Name einer PDF-Datei oft nicht aus. Relevanter sind Quellsystem, Dokument-ID, Revision, Extraktionszeitpunkt, Transformationen und die tatsächlich genutzte Textstelle.

Data Lineage dokumentiert die Herkunft und Verarbeitung der Daten. Die Traceability der konkreten KI-Anfrage ergänzt diese Sicht um Suchabfragen, ausgewählte Treffer, Tool Calls, Modellversion und Antwort. Beide Perspektiven gehören zusammen, sind aber nicht identisch.

Wenn eine falsche Wartungsanweisung ausgegeben wird, muss sich untersuchen lassen, ob das Quellsystem veraltet war, die Transformation Informationen verloren hat, das Retrieval falsch gefiltert hat oder das Sprachmodell die vorhandenen Quellen missinterpretiert hat. Ein längerer Prompt repariert keinen falschen Stammdatensatz.

Zehn vorbereitete Fragen sind kein Nachweis für ein produktiv belastbares System. Wir benötigen repräsentative Tests mit echten Fragen, erwarteten Quellen und nachvollziehbaren Regeln für korrekte und unzulässige Antworten.

Retrieval Recall und Ranking-Qualität zeigen, ob relevante Informationen überhaupt gefunden werden. Faithfulness und fachliche Antwortprüfungen untersuchen, ob das Modell seine Aussagen durch Quellen stützt. Testfälle sollten auch überholte Dokumente, widersprüchliche Revisionen, fehlende Fakten und mehrdeutige Fragen abdecken.

Frameworks wie Ragas unterstützen diese Evaluation. Automatische Bewertungen ersetzen jedoch keine fachlich geprüfte Stichprobe. Nach Änderungen an Chunking, Index, Filtern, Prompts oder Modell sollten Regressionstests erneut laufen.

Im Betrieb verfolgen wir Pipeline-Aktualität, Suchlatenz, Trefferqualität, Modellfehler, Input- und Output-Tokens, Kosten je Anfrage sowie p95-Antwortzeiten. Dazu kommen Traces für Retrieval, Tool-Aufrufe und Modellverarbeitung.

OpenTelemetry und Distributed Tracing liefern dafür technische Bausteine. Sensible Dokumentinhalte müssen dafür nicht pauschal in Logs kopiert werden; es sollten gezielt notwendige Metadaten, IDs und geeignete Zugriffskontrollen eingesetzt werden.

Erst durch diese Sicht auf das Gesamtsystem können wir schlechte Antworten systematisch Ursachen zuordnen und Qualität, Latenz und Kosten gegeneinander abwägen.

Ein Servicemitarbeiter erhält aus der Wissenssuche eine korrekte Wartungsempfehlung. Wenn er anschließend selbst das Ticket eröffnen, die betroffene Maschine zuordnen und den verantwortlichen Kollegen finden muss, bleibt die KI außerhalb des eigentlichen Prozesses.

Eine weiterführende Anwendung kann fachlich geprüfte Informationen mit strukturierten Geschäftsdaten verbinden und eine konkrete Prüfaufgabe vorbereiten – mit Maschine, Dokumentrevision, Quelle, Zeitpunkt und zuständiger Rolle. Kritische Aktionen bleiben an definierte Freigaben gebunden.

Auf diese Verbindung von Unternehmensdaten, Analytics, Machine Learning, KI und nachvollziehbaren Aufgaben ist Valanor AI ausgerichtet. Wir entwickeln dafür Datenintegration, Anwendungslogik, Evaluation und Monitoring. Nicht jeder Workflow braucht einen KI-Agenten; manchmal sind Regeln oder strukturierte Abfragen die bessere Lösung.

Ein überschaubarer Dokumentbestand, klare Zuständigkeiten und einfache Suchfragen rechtfertigen häufig einen pragmatischen Einstieg mit Standard-Connectors. SharePoint kann das führende Dokumentensystem bleiben, Langdock die Benutzungsoberfläche stellen und Google Drive weiterhin der Zusammenarbeit dienen.

Komplexere Wissensmodelle werden dann relevant, wenn mehrere Quellsysteme miteinander verknüpft werden müssen, Versionen geschäftskritisch sind, Antworten in operative Entscheidungen einfließen oder die Kosten bei hohem Anfragevolumen steigen.

Die Entscheidung ist deshalb kein grundsätzliches Build-vs-Buy-Votum gegen Langdock. Wir ergänzen Standardsoftware gezielt dort, wo die Aufgabe eine zusätzliche Daten- und Wissensschicht verlangt.

SharePoint an Langdock anzubinden, kann ein guter erster Schritt sein. Eine skalierbare RAG-Architektur entsteht aber erst dann, wenn Datenherkunft, Gültigkeit, fachliche Beziehungen, Retrieval, Evaluation und Betrieb als zusammenhängendes System behandelt werden.

Das Ziel ist nicht, jedes Datenproblem mit mehr Modellkontext zu überdecken. Das Ziel ist, dem Modell die richtigen Informationen bereitzustellen, unnötige Rekonstruktion zu vermeiden und die Ergebnisse kontrolliert in Geschäftsprozesse zu übernehmen.

Mit unserem Data & AI Engineering entwickeln wir die technischen Grundlagen. Wenn aus Informationen nachvollziehbare Empfehlungen und Aufgaben entstehen sollen, verbinden wir diese Grundlagen mit einer passenden KI-Anwendung.

Den Ansatz von der Datenbasis bis zum operativen Workflow erläutern wir unter Valanor AI.

Langdock: Company Knowledge und die dokumentierten Funktionen zur Unternehmenssuche.

Microsoft Graph: Delta Query für DriveItem.

Microsoft GraphRAG: Architekturüberblick.

Ragas: Evaluation Metrics.

OpenTelemetry: Generative AI Semantic Conventions.