SharePoint & Copilot: Unternehmensdaten in KI-Modelle integrieren

Ein LLM besitzt meist nur Daten und Wissen, die zum Zeitpunkt des Trainings des Modells zur Verfügung standen. Somit kann es nur auf Fragen reagieren und mit einer höheren Wahrscheinlichkeit richtig antworten, wenn genügend und aktuelles Wissen dem Modell zur Verfügung steht. Fehlt das Wissen oder ist es nicht aktuell genug, dann erhöht sich die Rate der Falschantworten und es kommt zu den bekannten Halluzinationen.

Im Unternehmenskontext kommt noch erschwerend dazu, dass die LLM kein internes Unternehmenswissen besitzen. Somit kann zunächst das LLM keine verlässlichen Antworten auf Fragen zu internen Geschäftsabläufen liefern. Um dies zu ermöglichen, muss dem LLM zunächst internes Wissen des Unternehmens zur Verfügung gestellt werden. Dies ist aus Gründen des Datenschutzes und der Datensicherheit problematisch. Um einem LLM das notwendige Wissen eines Unternehmens bereitzustellen, gibt es 2 mögliche Wege:

• Fine-Tuning des Modells
• Retrieval-Augmented Generation (RAG)

Beim Fine-Tuning wird einem Modell internes Firmenwissen als Trainingsmaterial bereitgestellt. Dieser Ansatz ist jedoch meist komplex, teuer und muss aufgrund von Datenänderungen häufig wiederholt werden. Findet keine periodische Wiederholung statt, so veraltet das Modell schnell und die Rate der Falschantworten steigt über die Zeit.

Ein gebräuchlicherer, effizienterer und oft effektiverer Ansatz ist Retrieval-Augmented Generation, kurz RAG. Der RAG-Ansatz erweitert das Modell bei Bedarf um zusätzliches Wissen, welches aus einer weiteren Vektordatenbank bezogen wird. Um das Wissen in der Vektordatenbank aktuell zu halten, muss diese auch periodisch aktualisiert werden. Zu diesem Zweck werden dann in der Regel sogenannte RAG-Pipelines eingesetzt.

Die Vorteile gegenüber dem Fine-Tuning liegen in der Datenaktualität. RAG kann neue Informationen einfach integrieren, indem neue Dokumente zum Vektorspeicher hinzugefügt werden, ohne dass das Sprachmodell neu trainiert werden muss.

Da jedoch im Unternehmenskontext oft geschützte Informationen verarbeitet werden müssen, ergeben sich bei beiden Ansätzen Probleme bezüglich der Sicherheitsreplikation. Werden die internen Daten extrahiert und in einem Modell verarbeitet, verlieren diese die gesetzten Zugriffsrechte aus dem Zielsystem. Somit könnte ein LLM mit Informationen antworten, auf die ein Benutzer eigentlich im Quellsystem keinen Zugriff hat.

In Microsoft 365 mit Copilot und SharePoint als Datenquelle wird ein erweitertes RAG eingeführt, das den Ansatz verfolgt:

Data stays where it lives

Das bedeutet, die Daten werden nicht mehr verschoben oder kopiert, um von einem LLM verarbeitet werden zu können. Vielmehr werden bei einer Benutzeranfrage über Microsoft Copilot basierend auf der Anfrage die relevanten Unternehmensdaten ermittelt und dem Modell dynamisch zur Verfügung gestellt. Dabei werden alle Sicherheitsmechanismen und Zugriffsrechte des Benutzers berücksichtigt. Somit werden 2 wichtige Punkte durch den Microsoft-RAG-Ansatz gelöst:

• Nur Daten, auf denen ein Benutzer zum Zeitpunkt der Anfrage Zugriff hat, werden berücksichtigt.
• Die Daten sind aktuell.

Die folgende Abbildung verdeutlicht die RAG-Architektur in Copilot Studio (Quelle: Enhance AI responses by using Retrieval Augmented Generation).

RAG-Architektur in Copilot Studio.

Somit entfallen viele Nachteile der Fine-Tunings und des klassischen RAG-Ansatzes:

• keine eigene Vektor-Datenbank
• kein Re-Indexing
• keine Sicherheitsreplikation
• keine Datenpipelines

Intern liefert die Copilot-Retrieval-API zugriffsgefilterte, semantisch relevante Textauszüge aus Microsoft-365-Inhalten zur Grounding-Nutzung in generativer KI.

In dem Video erläutere ich die Zusammenhänge im Detail.