Viele Diskussionen drehen sich aktuell um den besten Ansatz, um unternehmensinternes Wissen schnell und einfach zugänglich zu machen. Die Diskussionen schwanken zwischen klassischem Retrieval Augmented Generation (RAG), möglichst viel Kontext liefern und weiteren technischen Ansätzen. Doch generative KI liefert erst dann echten Nutzen, wenn Antworten nicht nur korrekt, sondern kontextuell passend und sicher sind. Unternehmen brauchen also mehr als reaktive Tool-Abfragen: Sie benötigen den notwendigen Kontext, der Metadaten, Beziehungen und Berechtigungen abbildet – und Ereignisse zwischen Systemen intelligent verknüpft. Dieser Beitrag erklärt, was Kontextual RAG ist, und warum der klassische RAG-Ansatz nicht für das reicht, was notwendig ist, um in Zukunft wettbewerbsfähig zu bleiben.
Inhaltsverzeichnis
Klassisches RAG
Beginnen wir zunächst mit einem Rückblick auf das klassische Retrieval-Augmented Generation (RAG). Klassisches RAG trennt Unternehmenswissen von dem Wissen eines KI-Modells: Ein Sprachmodell nutzt zur Beantwortung einer Anfrage nicht sein Trainingswissen, sondern zieht benötigte Informationen zuerst aus verfügbaren Quellen und formuliert daraus die Antwort. Entscheidend ist daher die Qualität des Retrievals – es steuert, welche Informationen überhaupt in die Antwort einfließen.
Im Kern existieren zwei verbreitete Ansätze für das Retrieval:
1. Upload-basierter Ansatz
Der Ansatz: Dokumente werden auf eine KI-Plattform hochgeladen, indexiert und durchsucht.
Die Herausforderung: Wichtiger Kontext geht verloren:
- Metadaten wie Autor, Projekt, Gültigkeitsdatum oder Sensitivität fehlen oder werden nicht konsistent übernommen.
- Zugriffsrechte (ACLs) werden oft nicht mitindexiert oder nur grob nachgebildet.
- Änderungen in den Dokumenten müssen stets manuell nachgehalten werden.
Ohne diese Signale kann die Suche Relevanz, Aktualität und Berechtigungen schlechter bewerten – Antworten werden unpassend oder unsicher. Somit sinkt die Qualität der generierten Antworten.
2. Systemanbindung per MCP/Federated Search
Der Ansatz: Die Suche wird per MCP- oder Federated-Search Ansatz an das Quellsystem delegiert, um Komplexität zu vermeiden.
Die Herausforderung: Wissen wird immer reaktiv genutzt, der Kontext ist begrenzt und es besteht eine Abhängigkeit zur Qualität der Fremdsuche:
- Die KI-Plattform verlässt sich auf die Suchqualität des angebundenen Systems (z. B. SharePoint-Suche) und hat wenig Einfluss auf Ranking, Signale oder Fehlerbehandlung.
- Kontextinformationen (z. B. Nutzerprofil, Historie, laufende Projekte) lassen sich kaum in akzeptabler Zeit einbeziehen, da jede Anfrage „on demand“ auf unterschiedliche APIs trifft.
- Rate-Limits, Latenzen und heterogene Indexpipelines mit unterschiedlichen Such-Syntaxen erschweren ein konsistentes, schnelles Retrieval.
Letztendlich bestimmt beim RAG-Ansatz das Retrieval die Antwortqualität. Wenn Metadaten fehlen, Rechte nicht sauber greifen oder Kontext nicht rechtzeitig verfügbar ist, produziert das beste Sprachmodell nur mittelmäßige Ergebnisse – oder riskiert Verstöße. Hier ist Kontextual RAG die notwendige Weiterentwicklung & Alternative:
Was ist Kontextual RAG?
Kontextual RAG verbindet klassisches RAG mit einer zusätzlichen Kontext Layer: Statt sich auf die Suchfunktionen der Quellsysteme (z. B. Laufwerke, SharePoint, Intranet) zu verlassen, erstellt es einen eigenen Index bzw. Knowledge Graph, der alle relevanten Informationen konsistent zusammenführt. So kombiniert Kontextual RAG die Vorteile aller Ansätze und liefert präzisere, kontextreiche Antworten.
Im Kontext Layer werden zusätzliche Inhalte modelliert, darunter zum Beispiel die folgenden:
- Metadaten (z. B. Autor, Erstellungsdatum, Dateityp, Projektzuordnung)
- Zugriffsrechte (auf Basis von Access Control Lists (ACL’s), rollen- und objektbasiert, inkl. Gruppen/Teams)
- Beziehungen und Ereignisse (z. B. „Ticket A referenziert Dokument B“, „Commit X löst Review Y aus“)
Der Vorteil: Antworten werden nicht nur aus den richtigen Quellen gezogen, sondern sind zugleich berechtigungs- und kontextkonform. Dabei Ergänzen sich die Begriffe folgendermaßen:
| RAG (Retrieval-Augmented Generation) | Kontext Layer |
| Ein Ansatz, bei dem ein Sprachmodell während der Antworterzeugung Informationen aus einem Suchindex/Knowledge Store abruft. | Eine übergreifende Schicht vergleichbar mit einem Datalake, die Datenobjekte, Metadaten, Berechtigungen und Ereignisse systemübergreifend zu einem konsistenten Kontextgraph verknüpft. |
Warum MCP allein nicht reicht
Viele KI-Plattformen sind in der Vergangenheit mit einem klassischem, upload-basiertem RAG-Ansatz gestartet und merken nun, dass es in der Praxis nur allenfalls als Proof of Concept taugt. Um im nächsten Schritt internes Wissen „einfach“ anzubinden, wird dann der MCP/Federated Search-Ansatz als schnellster und einfachster Weg verkauft.
In der Praxis reicht die Retrievalqualität jedoch nicht aus, da stets auf die bestehenden, nativen Suchlösungen von SharePoint & Co gesetzt wird. Deshalb greifen Unternehmen zu inflationären Tool-Calls: Statt eine einzige Anfrage mit dem notwendigen Kontext zu stellen wird jede Information und „Richtung“ in der abgefragt werden soll, einzeln abgefragt. Erfahre in diesem Blogartikel mehr über die Einschränkungen von MCP.
Falls du mehr über MCP erfahren möchtest, dann lade dir jetzt unser White Paper zu diesem Thema herunter. Dort erklären wir verschiedene technischen Ansätze, um unternehmensinternes Wissen anzubinden im Detail:
Ein Beispiel: Ein Maschinenbauerunternehmen hat das Produkt mit dem Namen „Kühltheke 5000“ entwickelt. In einigen Dokumenten wird die Kühltheke als „Kühltheke 5000“ bezeichnet, in anderen als „KT5000“, in anderen als „KT 5000“. Da diese unterschiedlichen Bezeichnungen für die SharePoint-Suche keine Synonyme sind, muss ein Anbieter, welcher für das Retrieval den MCP-Ansatz verwendet, für die Suche nach der Kühltheke mindestens 3 Abfragen stellen. Kompliziertere Kontextinformationen wie z. B. Abteilungs-/Nutzerinformationen o. Ä. sind hier noch nicht berücksichtigt.
Im Ergebnis erhält die KI bei einem MCP-Ansatz also nicht die passenden Abschnitte auf Basis des notwendigen Kontexts, sondern „irgendwelche“ Dokumente, in denen zufällig das passende Keyword von der SharePoint Suche als relevant betrachtet wurde. Um das zu korrigieren wird deutlich mehr Kontext (=gefundene Dokumente) in das „Kontextfenster“ geladen. Im Endeffekt wird die KI also mit „unnötigen“ Informationen gefüttert und muss diese nun selbstständig wieder herausfiltern. Dabei kostet jede unnötige Information direkt Tokens.
Zu Beginn fallen diese Kosten noch nicht ins Verhältnis – die Kosten werden jedoch unkontrollierbar, wenn:
- Die Lösung anfängt, in der Belegschaft zu skalieren
- Anwendungsfälle & Abfragen komplexer werden
- Prozesse automatisiert werden sollen und die KI-Plattform Wissen nicht nur für Menschen, sondern auch für KI-Agenten bereitstellt.
Du möchtest einen besseren Ansatz ausprobieren? Dann teste jetzt amber. amber setzt auf Kontextual RAG und hilft dir, das unternehmensinterne Wissen skalierbar anzubinden.
Wissen für KI-Agenten über eine Kontext Layer bereitstellen
In Zukunft wird Wissen nicht nur für Menschen, sondern vor allen Dingen für KI-Agenten aufbereitet. Unternehmen müssen sich also Gedanken machen, wie Wissen in einer Form bereitgestellt werden kann, sodass das Wissen auch von KI-Agenten sinnvoll verwendet werden kann. Genau hier hilft wiederum der Kontext Layer von amber:
- amber verfügt über alle notwendigen Schnittstellen, um eine Agent2Agent (A2A) Kommunikation zu ermöglichen.
- Abfragen an das Unternehmenswissen können über amber als manuelle Eingabe, per API oder MCP-Aktion getriggert werden, während amber im Hintergrund die Anfrage auf Basis des Kontext Layers beantwortet
- Über amber können KI-Agenten Aktionen in Drittsystemen auslösen
Was den amber Kontext Layer unschlagbar macht
Unternehmen, welche auf klassische RAG Ansätze setzen, können nur reaktiv handeln:
- Ein Ticket wird eröffnet à ein Workflow wird ausgelöst
- Eine Information wird gesucht à Eine Suche wird in den Systemen gestartet
Der Kontext Layer befähigt Unternehmen jedoch Zusammenhänge und Muster zu erkennen und auf dieser Basis proaktiv Entscheidungen zu treffen. Ein Beispiel:
- Ein neues Dokument, welches mit einer Kundenanfrage assoziiert ist, wird indexiert und in der Kontext Layer abgelegt. Aufgrund der semantischen Nähe erkennt die Kontext Layer, dass es dazu in der Vergangenheit ein Forschungsprojekt gab, das vor einigen Monaten eingestellt wurde. Daraufhin informiert die Kontext Layer den verantwortlichen Mitarbeitenden proaktiv, dass es bereits relevante Aktivitäten zu dieser Anfrage gibt.
- Ohne diese Verknüpfung wüssten – gerade in größeren Unternehmen – der Bearbeitende der Kundenanfrage und die Mitarbeitenden aus dem Forschungsprojekt möglicherweise nichts voneinander – die Anfrage könnte daher fälschlicherweise abgelehnt werden.
- Im klassischen RAG-Ansatz müsste man darauf hoffen, dass die richtige Suchanfrage gestellt wird und etwa die native SharePoint-Suche die passenden Treffer liefert.
Der von amber verfolgt Kontextansatz schließt solche Wissenslücken somit zuverlässig, indem er semantische Zusammenhänge automatisch erkennt und die relevanten Personen zielgerichtet auf die Synergien hinweist.
Umgang mit Zugriffsrechten
Einer der wichtigsten Punkte dabei ist die Einschränkung, dass nicht jeder Mitarbeiter jede Information sehen darf. Im Unternehmen existieren unterschiedliche Zugriffsrechte, welche über Anfragen hinweg berücksichtigt werden müssen.
Um Zugriffsrechte zu berücksichtigen, gibt es im Kern zwei Ansätze:
- Pre-Retrieval Filter: Es wird im Namen des Nutzers gesucht, so werden nur für den Nutzer freigegebene Dokumente berücksichtigt.
- Post-Retrieval Checks: Es werden im Namen der KI-Plattform alle Dokumente – unabhängig der Zugriffsrechte – durchsucht. Bevor die Ergebnisse durch die KI verarbeitet werden, wird für die Dokumente geprüft, ob der Nutzer Zugriff hat und Dokumente ohne Zugriff werden vor Generierung einer Antwort aussortiert.
Während es beim klassischen MCP-/Federated Search Ansatz von der anzubindenden Datenquelle abhängt, welcher Ansatz genutzt wird, setzt amber darauf, Zugriffsrechte in der Kontext Layer (über sogenannte Access Control Lists (ACL’s)) mit abzubilden. Darüber können beim Kontextual RAG direkt von Beginn an alle Zugriffsrechte berücksichtigt werden. Das führt dazu, dass nur relevante Dokumente durchsucht/verarbeitet werden. Dies wird konsequent über alle angebundenen Systeme (inkl. On Premise Systeme wie z. B. Laufwerke) umgesetzt.
Werden automatisierte Abfragen z. B. per Agent oder API getriggert, dann müssen diese immer ein Profil angeben, über welches entschieden wird, welche Informationen/Fähigkeiten für die jeweilige Anfrage benutzt werden dürfen.
Fazit
Viele Unternehmen stehen gerade erst am Anfang der KI-Einführung oder haben noch nicht gestartet. Dabei wird der langfristige Erfolg sowie die Skalierbarkeit maßgeblich von der gewählten Architektur abhängen. Hier bietet der von amber entwickelte Kontext-Layer die perfekte Grundlage, um Wissen langfristig nicht nur Menschen, sondern auch KI-Agenten zur Verfügung zu stellen.
Falls du dich fragst, wie du KI selbst einsetzen kannst, dann lass uns jetzt in Kontakt treten. Du findest hier unser Kontaktformular: