Der sofort einsatzbereite Semantic Kernel Elasticsearch Vector Store Connector unterstützt die Abstraktionen des Semantic Kernel Vector Stores , was es Entwicklern sehr einfach macht, Elasticsearch als Vector Store beim Erstellen von KI-Agenten einzubinden.

Elasticsearch hat eine starke Verankerung in der Open-Source-Community und hat vor Kurzem die AGPL-Lizenz übernommen. In Kombination mit dem Open-Source-Microsoft Semantic Kernel bieten diese Tools eine leistungsstarke, unternehmensgerechte Lösung. Sie können lokal beginnen, indem Sie Elasticsearch in wenigen Minuten mit diesem Befehl curl -fsSL https://elastic.co/start-local | sh starten (siehe start-local für Details) und dann auf Cloud-gehostete oder selbstgehostete Versionen umsteigen, während Sie Ihre KI-Agenten produktiv einsetzen.

In diesem Blogbeitrag zeigen wir Ihnen, wie Sie den Semantic Kernel Elasticsearch Vector Store Connector in Verbindung mit Semantic Kernel verwenden. Eine Python-Version des Konnektors wird zu einem späteren Zeitpunkt verfügbar sein.

Szenario auf hoher Ebene: Entwicklung einer RAG-Anwendung mit Semantic Kernel und Elasticsearch

Im folgenden Abschnitt gehen wir ein Beispiel durch. Im Wesentlichen entwickeln wir eine RAG-Anwendung (Retrieval Augmented Generation), die eine Frage des Benutzers als Eingabe entgegennimmt und eine Antwort zurückgibt. Wir verwenden Azure OpenAI (ein lokales LLM kann ebenfalls verwendet werden) als LLM, Elasticsearch als Vektorspeicher und Semantic Kernel (.net) als Framework, um alle Komponenten miteinander zu verbinden.

Falls Sie mit RAG-Architekturen nicht vertraut sind, können Sie sich mit diesem Artikel eine kurze Einführung verschaffen: https://www.elastic.co/search-labs/blog/retrieval-augmented-generation-rag.

Die Antwort wird vom LLM generiert, der mit Kontextinformationen gespeist wird, die für die Frage relevant sind und aus dem Elasticsearch-Vektorspeicher abgerufen werden. Die Antwort enthält auch die Quelle, die vom LLM als Kontext verwendet wurde.

RAG-Beispiel

In diesem konkreten Beispiel entwickeln wir eine Anwendung, die es Benutzern ermöglicht, Fragen zu Hotels zu stellen, die in einer internen Hoteldatenbank gespeichert sind. Der Benutzer könnte z.B. Suchen Sie nach einem bestimmten Hotel anhand verschiedener Kriterien oder fordern Sie eine Liste von Hotels an.

Für die Beispieldatenbank haben wir eine Liste von Hotels mit 100 Einträgen generiert. Die Stichprobengröße ist bewusst klein gehalten, damit Sie die Konnektordemo so einfach wie möglich ausprobieren können. In einer realen Anwendung würde der Elasticsearch-Connector seine Vorteile gegenüber anderen Optionen, wie der `InMemory`-Vektorspeicherimplementierung, insbesondere bei der Arbeit mit extrem großen Datenmengen zeigen.

Die vollständige Demo-Anwendung finden Sie im Elasticsearch Vector Store Connector- Repository.

Beginnen wir damit, die erforderlichen NuGet-Pakete und die verwendeten Direktiven zu unserem Projekt hinzuzufügen:

Wir können nun unser Datenmodell erstellen und es mit semantischen Kernel-spezifischen Attributen ausstatten, um das Speichermodellschema und einige Hinweise für die Textsuche zu definieren:

Die Attribute des Speichermodellschemas (`VectorStore*`) sind für die tatsächliche Verwendung des Elasticsearch Vector Store Connectors am relevantesten, nämlich:

• VectorStoreRecordKey Eine Eigenschaft einer Datensatzklasse als Schlüssel zu kennzeichnen, unter dem der Datensatz in einem Vektorspeicher abgelegt wird.

• VectorStoreRecordData Eine Eigenschaft einer Datensatzklasse als 'Daten' kennzeichnen.

• VectorStoreRecordVector Eine Eigenschaft einer Datensatzklasse als Vektor kennzeichnen.

Alle diese Attribute akzeptieren verschiedene optionale Parameter, mit denen das Speichermodell weiter angepasst werden kann. Im Fall von VectorStoreRecordKey ist es beispielsweise möglich, eine andere Distanzfunktion oder einen anderen Indextyp anzugeben.

Die Textsuchattribute (TextSearch*) werden im letzten Schritt dieses Beispiels wichtig sein. Wir werden später auf sie zurückkommen.

Im nächsten Schritt initialisieren wir die Semantic Kernel Engine und erhalten Referenzen zu den Kerndiensten. In einer realen Anwendung sollte Dependency Injection anstelle des direkten Zugriffs auf die Service-Collection verwendet werden. Dasselbe gilt für die fest codierte Konfiguration und die Geheimnisse, die stattdessen mithilfe eines Konfigurationsanbieters gelesen werden sollten:

Der Dienst vectorStoreCollection kann nun verwendet werden, um die Sammlung zu erstellen und einige Demodatensätze einzulesen:

Dies zeigt, wie Semantic Kernel die Verwendung eines Vektorspeichers mit all seiner Komplexität auf wenige einfache Methodenaufrufe reduziert.

Im Hintergrund wird in Elasticsearch ein neuer Index erstellt und alle notwendigen Eigenschaftszuordnungen werden angelegt. Unser Datensatz wird dann vollständig transparent in das Speichermodell abgebildet und schließlich im Index gespeichert. Nachfolgend sehen Sie, wie die Zuordnungen in Elasticsearch aussehen.

Die embeddings.GenerateEmbeddingsAsync() -Aufrufe riefen transparent den konfigurierten Azure AI Embeddings Generation-Dienst auf.

Noch mehr Magie lässt sich im letzten Schritt dieser Demonstration beobachten.

Mit nur einem einzigen Aufruf von InvokePromptAsync werden alle folgenden Operationen ausgeführt, wenn der Benutzer eine Frage zu den Daten stellt:

1. Es wird eine Einbettung für die Frage des Benutzers generiert.

2. Der Vektorspeicher wird nach relevanten Einträgen durchsucht.

3. Die Ergebnisse der Abfrage werden in eine Eingabeaufforderungsvorlage eingefügt.

4. Die eigentliche Anfrage in Form der finalen Eingabeaufforderung wird an den KI-Chatvervollständigungsdienst gesendet.

Erinnern Sie sich an die TextSearch* -Attribute, die wir zuvor in unserem Datenmodell definiert haben? Mithilfe dieser Attribute können wir in unserer Eingabeaufforderungsvorlage entsprechende Platzhalter verwenden, die automatisch mit den Informationen aus unseren Einträgen im Vektorspeicher befüllt werden.

Die endgültige Antwort auf unsere Frage „Bitte zeigen Sie mir alle Hotels mit einer Dachterrassenbar“ lautet wie folgt:

Die Antwort bezieht sich korrekt auf den folgenden Eintrag in unserer hotels.csv-Datei.

Dieses Beispiel zeigt sehr gut, wie die Verwendung des Microsoft Semantic Kernel durch seine durchdachten Abstraktionen eine signifikante Reduzierung der Komplexität ermöglicht und gleichzeitig ein sehr hohes Maß an Flexibilität gewährleistet. Durch die Änderung einer einzigen Codezeile können beispielsweise der Vektorspeicher oder die verwendeten KI-Dienste ersetzt werden, ohne dass ein anderer Teil des Codes umstrukturiert werden muss.

Gleichzeitig bietet das Framework eine enorme Menge an High-Level-Funktionalität, wie zum Beispiel die Funktion `InvokePrompt` oder das Template- oder Such-Plugin-System.

Die vollständige Demo-Anwendung finden Sie im Elasticsearch Vector Store Connector-Repository.

Was ist sonst noch mit Elasticsearch möglich?

• Elasticsearch: Neues semantisches Textmapping: Vereinfachung der semantischen Suche

• Semantisches Reranking in Elasticsearch mit Retrievern

• Erweiterte RAG-Techniken Teil 1: Datenverarbeitung

• Fortgeschrittene RAG-Techniken Teil 2: Abfragen und Testen

• RAG mit Llama 3 Open-Source und Elastic erstellen

• Eine Anleitung zum Erstellen eines lokalen Agenten mit LangGraph, LLaMA3 und dem Elasticsearch-Vektorspeicher von Grund auf

Elasticsearch & Semantic Kernel: Was kommt als Nächstes?

• Wir haben gezeigt, wie der Elasticsearch-Vektorspeicher beim Erstellen von GenAI-Anwendungen in .NET einfach in den Semantic Kernel eingebunden werden kann. Seien Sie gespannt auf die nächste Python-Integration.

• Da Semantic Kernel Abstraktionen für fortgeschrittene Suchfunktionen wie die Hybridsuche erstellt, ermöglicht Elasticsearch Connect .NET-Entwicklern die einfache Implementierung dieser Funktionen bei der Verwendung von Semantic Kernel.

In diesem Beitrag werden wir uns mit Möglichkeiten zum Schutz personenbezogener Daten (PII) und sensibler Daten bei der Verwendung öffentlicher LLMs in einem RAG-Ablauf (Retrieval Augmented Generation) befassen. Wir werden untersuchen, wie man personenbezogene Daten und sensible Daten mithilfe von Open-Source-Bibliotheken und regulären Ausdrücken maskieren kann, sowie wie man lokale LLMs verwendet, um Daten zu maskieren, bevor man einen öffentlichen LLM aufruft.

Bevor wir beginnen, wollen wir einige Begriffe wiederholen, die wir in diesem Beitrag verwenden.

Terminologie

LlamaIndex ist ein führendes Datenframework für die Entwicklung von LLM-Anwendungen (Large Language Model). LlamaIndex bietet Abstraktionen für verschiedene Phasen der Entwicklung einer RAG-Anwendung (Retrieval Augmented Generation). Frameworks wie LlamaIndex und LangChain bieten Abstraktionen, damit Anwendungen nicht eng an die APIs eines bestimmten LLM gekoppelt werden.

Elasticsearch wird von Elastic angeboten. Elastic ist ein Branchenführer hinter Elasticsearch, einem skalierbaren Datenspeicher und einer Vektordatenbank, die Volltextsuche für Präzision, Vektorsuche für semantisches Verständnis und Hybridsuche für das Beste aus beiden Welten unterstützt. Elasticsearch ist eine verteilte, RESTful-basierte Such- und Analyse-Engine, ein skalierbarer Datenspeicher und eine Vektordatenbank. Die in diesem Blog verwendeten Elasticsearch-Funktionen sind in der kostenlosen Open-Source-Version von Elasticsearch verfügbar.

Retrieval-Augmented Generation (RAG) ist eine KI-Technik bzw. ein KI-Muster, bei dem LLMs mit externem Wissen versorgt werden, um Antworten auf Benutzeranfragen zu generieren. Dadurch können die Antworten des LLM auf einen spezifischen Kontext zugeschnitten und weniger allgemein gehalten werden.

Einbettungen sind numerische Repräsentationen der Bedeutung von Texten/Medien. Es handelt sich um niedrigdimensionale Darstellungen hochdimensionaler Informationen.

RAG und Datenschutz

Im Allgemeinen sind große Sprachmodelle (LLMs) gut darin, Antworten auf der Grundlage von im Modell verfügbaren Informationen zu generieren, die mit Internetdaten trainiert werden können. Für Anfragen, bei denen die im Modell nicht verfügbaren Informationen vorliegen, müssen die LLMs jedoch externes Wissen oder spezifische Details erhalten, die nicht im Modell enthalten sind. Solche Informationen könnten sich in Ihrer Datenbank oder Ihrem internen Wissenssystem befinden. Retrieval-Augmented Generation (RAG) ist eine Technik, bei der für eine gegebene Benutzeranfrage zunächst relevante Kontextinformationen aus externen Systemen (z. B. Ihrer Datenbank) abgerufen und diese Kontextinformationen zusammen mit der Benutzeranfrage an das LLM gesendet werden, um eine spezifischere und relevantere Antwort zu generieren.

Dadurch eignet sich die RAG-Technik hervorragend für Anwendungen in der Fragebeantwortung, der Inhaltserstellung und überall dort, wo ein tiefes Verständnis von Kontext und Details von Vorteil ist.

Daher besteht bei einer RAG-Pipeline die Gefahr, dass interne Informationen wie PII (personenbezogene Daten) und sensible Informationen (z. B. Namen, Geburtsdaten, Kontonummern usw.) öffentlichen LLMs zugänglich gemacht werden.

Obwohl Ihre Daten bei der Verwendung einer Vektordatenbank wie Elasticsearch (durch verschiedene Mechanismen wie rollenbasierte Zugriffskontrolle, Dokumentensicherheit usw.) sicher sind, ist Vorsicht geboten, wenn Sie Daten an ein öffentliches LLM senden.

Der Schutz personenbezogener Daten (PII) und sensibler Daten ist bei der Verwendung großer Sprachmodelle (LLMs) aus mehreren Gründen von entscheidender Bedeutung:

• Datenschutzkonformität: Viele Regionen verfügen über strenge Vorschriften, wie beispielsweise die Datenschutz-Grundverordnung (DSGVO) in Europa oder den California Consumer Privacy Act (CCPA) in den Vereinigten Staaten, die den Schutz personenbezogener Daten vorschreiben. Die Einhaltung dieser Gesetze ist notwendig, um rechtliche Konsequenzen und Geldstrafen zu vermeiden.

• Nutzervertrauen: Die Gewährleistung der Vertraulichkeit und Integrität sensibler Informationen schafft Nutzervertrauen. Nutzer werden Systeme, von denen sie glauben, dass sie ihre Privatsphäre schützen, eher nutzen und mit ihnen interagieren.

• Datensicherheit: Der Schutz vor Datenlecks ist unerlässlich. Werden sensible Daten LLMs ohne angemessene Sicherheitsvorkehrungen zugänglich gemacht, können sie gestohlen oder missbraucht werden, was zu potenziellen Schäden wie Identitätsdiebstahl oder Finanzbetrug führen kann.

• Ethische Überlegungen: Aus ethischer Sicht ist es wichtig, die Privatsphäre der Nutzer zu respektieren und verantwortungsvoll mit ihren Daten umzugehen. Der unsachgemäße Umgang mit personenbezogenen Daten kann zu Diskriminierung, Stigmatisierung oder anderen negativen gesellschaftlichen Auswirkungen führen.

• Unternehmensreputation: Unternehmen, die sensible Daten nicht schützen, können einen Reputationsschaden erleiden, der langfristige negative Auswirkungen auf ihr Geschäft haben kann, einschließlich Kunden- und Umsatzverlusten.

• Reduzierung des Missbrauchsrisikos: Der sichere Umgang mit sensiblen Daten trägt dazu bei, einen missbräuchlichen Einsatz der Daten oder des Modells zu verhindern, wie beispielsweise das Trainieren der Modelle mit verzerrten Daten oder die Verwendung der Daten zur Manipulation oder Schädigung von Einzelpersonen.

Zusammenfassend lässt sich sagen, dass ein umfassender Schutz personenbezogener Daten und sensibler Daten notwendig ist, um die Einhaltung gesetzlicher Bestimmungen zu gewährleisten, das Vertrauen der Nutzer zu erhalten, die Datensicherheit sicherzustellen, ethische Standards einzuhalten, den Ruf des Unternehmens zu schützen und das Missbrauchsrisiko zu verringern.

Kurze Zusammenfassung

Im vorherigen Beitrag haben wir besprochen, wie man ein Q&A-Erlebnis mit einer RAG-Technik und Elasticsearch als Vektordatenbank unter Verwendung von LlamaIndex und einem lokal laufenden Mistral LLM implementiert. Hier bauen wir darauf auf.

Das Lesen des vorherigen Beitrags ist optional, da wir nun kurz besprechen/zusammenfassen werden, was wir im vorherigen Beitrag behandelt haben.

Wir verfügten über einen Beispieldatensatz mit Callcenter-Gesprächen zwischen Agenten und Kunden eines fiktiven Hausratversicherungsunternehmens. Wir haben eine einfache RAG-Anwendung entwickelt, die Fragen wie „Für welche Art von wasserbezogenen Problemen reichen Kunden Schadensmeldungen ein?“ beantwortet.

Im Großen und Ganzen sah der Ablauf so aus.

Während der Indexierungsphase haben wir Dokumente mithilfe der LlamaIndex-Pipeline geladen und indexiert. Die Dokumente wurden in Abschnitte unterteilt und zusammen mit ihren Einbettungen in der Elasticsearch-Vektordatenbank gespeichert.

Während der Abfragephase, als der Benutzer eine Frage stellte, ermittelte LlamaIndex die K ähnlichsten Dokumente, die für die Abfrage relevant waren. Diese Top-K relevanten Dokumente wurden zusammen mit der Anfrage an das lokal laufende Mistral LLM gesendet, das dann die Antwort generierte, die an den Benutzer zurückgesendet wurde. Sie können sich gerne den vorherigen Beitrag durchlesen oder den Code erkunden.

Im vorherigen Beitrag hatten wir LLM lokal am Laufen. Im Produktionsbetrieb kann es jedoch sinnvoll sein, ein externes LLM von verschiedenen Anbietern wie OpenAI, Mistral, Anthropic usw. zu verwenden. Es könnte daran liegen, dass Ihr Anwendungsfall ein größeres Basismodell erfordert oder dass eine lokale Ausführung aufgrund von Anforderungen der Unternehmensproduktion wie Skalierbarkeit, Verfügbarkeit, Leistung usw. nicht möglich ist.

Die Einbindung eines externen LLM in Ihre RAG-Pipeline birgt das Risiko, dass sensible Daten und personenbezogene Daten unbeabsichtigt an die LLMs gelangen. In diesem Beitrag werden wir Möglichkeiten zur Maskierung personenbezogener Daten im Rahmen Ihres RAG-Prozesses untersuchen, bevor Sie Dokumente an einen externen LLM senden.

RAG mit einem öffentlichen LLM

Bevor wir darauf eingehen, wie Sie Ihre personenbezogenen Daten und sensiblen Informationen in einer RAG-Pipeline schützen können, werden wir zunächst eine einfache RAG-Anwendung mit LlamaIndex, der Elasticsearch Vector-Datenbank und OpenAI LLM erstellen.

Voraussetzungen

Wir benötigen Folgendes.

• Elasticsearch ist als Vektordatenbank zum Speichern der Einbettungen eingerichtet und betriebsbereit. Folgen Sie den Anweisungen aus dem vorherigen Beitrag zur Installation von Elasticsearch.

• OpenAI-API-Schlüssel.

Einfache RAG-Anwendung

Zur Information: Der vollständige Code befindet sich in diesem GitHub-Repository(Branch:protecting-pii). Das Klonen des Repositorys ist optional, da wir den Code im Folgenden genauer betrachten werden.

Erstellen Sie in Ihrer bevorzugten IDE eine neue Python-Anwendung mit den folgenden 3 Dateien.

• index.py Hierhin wird der Code für die Indizierung von Daten eingefügt.

• query.py Hier wird der Code für Abfragen und die Interaktion mit LLM eingefügt.

• .env dort, wo Konfigurationseigenschaften wie API-Schlüssel gespeichert werden.

Wir müssen einige Pakete installieren. Wir beginnen damit, eine neue virtuelle Python-Umgebung im Stammverzeichnis Ihrer Anwendung zu erstellen.

Aktivieren Sie die virtuelle Umgebung und installieren Sie die unten aufgeführten erforderlichen Pakete.

Konfigurieren Sie die Verbindungseigenschaften von OpenAI und Elasticsearch in der .env-Datei. Datei.

Indexierungsdaten

Laden Sie die Datei conversations.json herunter, die Konversationen zwischen Kunden und Callcenter-Mitarbeitern unseres fiktiven Hausversicherungsunternehmens enthält. Platzieren Sie die Datei im Stammverzeichnis der Anwendung zusammen mit den beiden Python-Dateien und der .env-Datei. die Datei, die Sie zuvor erstellt haben. Nachfolgend ein Beispiel für den Inhalt der Datei.

Fügen Sie den unten stehenden Code in index.py ein, der sich um die Indizierung der Daten kümmert.

Wenn Sie den obigen Code ausführen, wird ein Index in Elasticsearch erstellt und die Einbettungen werden im Elasticsearch-Index mit dem Namen convo_index gespeichert.

Falls Sie eine Erläuterung zur LlamaIndex IngestionPipeline benötigen, lesen Sie bitte den vorherigen Beitrag im Abschnitt "IngestionPipeline erstellen".

Abfrage

Im vorherigen Beitrag haben wir ein lokales LLM für Abfragen verwendet.

In diesem Beitrag verwenden wir das öffentliche LLM OpenAI, wie unten dargestellt.

Der obige Code gibt die Antwort von OpenAI wie folgt aus.

Kunden haben verschiedene Ansprüche im Zusammenhang mit Wasser geltend gemacht, darunter Probleme wie Wasserschäden in Kellern, geplatzte Rohre, Hagelschäden an Dächern sowie die Ablehnung von Ansprüchen aufgrund von Gründen wie mangelnder rechtzeitiger Meldung, Wartungsmängeln, allmählichem Verschleiß und bereits bestehenden Schäden. In allen Fällen äußerten die Kunden ihre Frustration über die Ablehnung ihrer Ansprüche und forderten eine faire Bewertung und Entscheidung in Bezug auf ihre Ansprüche.

Maskierung von PII in RAG

Was wir bisher behandelt haben, beinhaltet das Senden von Dokumenten unverändert zusammen mit der Benutzeranfrage an OpenAI.

In der RAG-Pipeline haben wir, nachdem der relevante Kontext aus einem Vektorspeicher abgerufen wurde, die Möglichkeit, personenbezogene Daten und sensible Informationen zu maskieren, bevor wir die Anfrage und den Kontext an das LLM senden.

Es gibt verschiedene Möglichkeiten, personenbezogene Daten zu maskieren, bevor man sie an ein externes LLM sendet, wobei jede ihre eigenen Vorzüge hat. Wir betrachten einige der folgenden Optionen.

1. Verwendung von NLP-Bibliotheken wie spacy.io oder Presidio (Open-Source-Bibliothek, die von Microsoft gepflegt wird).

2. Verwendung von LlamaIndex direkt aus der Verpackung NERPIINodePostprocessor.

3. Nutzung lokaler LLMs über PIINodePostprocessor

Sobald Sie die Maskierungslogik mithilfe einer der oben genannten Methoden implementiert haben, können Sie die LlamaIndex IngestionPipeline mit einem PostProcessor konfigurieren (entweder mit einem eigenen benutzerdefinierten PostProcessor oder mit einem der standardmäßig verfügbaren PostProcessors von LlamaIndex).

Verwendung von NLP-Bibliotheken

Im Rahmen der RAG-Pipeline könnten wir sensible Daten mithilfe von NLP-Bibliotheken maskieren. In dieser Demo verwenden wir das spacy.io-Paket.

Erstellen Sie eine neue Datei query_masking_nlp.py und fügen Sie den unten stehenden Code ein.

Die Antwort des LLM ist unten dargestellt.

Im obigen Code geben wir beim Erstellen der Llama Index QueryEngine einen CustomPostProcessor an.

Die Logik, die von der QueryEngine aufgerufen wird, ist in der Methode _postprocess_nodes von CustomPostProcessor definiert. Wir verwenden die SpaCy.io-Bibliothek, um benannte Entitäten in unseren Daten zu erkennen, und verwenden dann einige reguläre Ausdrücke, um diese Namen sowie sensible Informationen zu ersetzen, bevor wir die Dokumente an das LLM senden.

Nachfolgend finden Sie beispielhaft Ausschnitte aus den Originalkonversationen und der vom CustomPostProcessor erstellten maskierten Konversation.

Originaltext:

Maskierter Text durch den CustomPostProcessor.

Notiz:

Das Identifizieren und Maskieren von personenbezogenen Daten und sensiblen Informationen ist keine einfache Aufgabe. Die Berücksichtigung verschiedener Formate und Semantiken sensibler Informationen erfordert ein gutes Verständnis Ihres Fachgebiets und Ihrer Daten. Auch wenn der oben dargestellte Code für einige Anwendungsfälle funktionieren mag, müssen Sie ihn möglicherweise an Ihre Bedürfnisse und Tests anpassen.

Verwendung des LlamaIndex direkt aus der Verpackung NERPIINodePostprocessor

LlamaIndex hat den Schutz personenbezogener Daten in einer RAG-Pipeline durch die Einführung vereinfacht. NERPIINodePostprocessor.

Die Antwort sieht wie folgt aus:

Nutzung lokaler LLMs über PIINodePostprocessor

Alternativ könnten wir auch ein lokal oder in Ihrem privaten Netzwerk laufendes LLM nutzen, um die Maskierung durchzuführen, bevor die Daten an ein öffentliches LLM gesendet werden.

Wir werden Mistral, das auf Ollama auf Ihrem lokalen Rechner läuft, für die Maskierung verwenden.

Mistral lokal ausführen

Laden Sie Ollama herunter und installieren Sie es. Nach der Installation von Ollama führen Sie diesen Befehl aus, um Mistralherunterzuladen und auszuführen.

Das Herunterladen und erstmalige lokale Ausführen des Modells kann einige Minuten dauern. Prüfen Sie, ob Mistral weht, indem Sie eine Frage wie die folgende stellen: „Schreibe ein Gedicht über Wolken“ und prüfen Sie, ob Ihnen das Gedicht gefällt. Bitte lassen Sie ollama laufen, da wir später über Code mit dem Mistral-Modell interagieren müssen.

Erstellen Sie eine neue Datei namens query_masking_local_LLM.py und fügen Sie den unten stehenden Code ein.

Die Antwort sieht in etwa so aus wie unten dargestellt.

Fazit

In diesem Beitrag haben wir gezeigt, wie Sie personenbezogene Daten und sensible Daten beim Einsatz öffentlicher LLMs in einem RAG-Flow schützen können. Wir haben verschiedene Wege aufgezeigt, wie dies erreicht werden kann. Es wird dringend empfohlen, diese Ansätze anhand Ihres Anwendungsfalls und Ihrer Bedürfnisse zu testen, bevor Sie sie übernehmen.

Bevor wir anfangen, werden wir uns einige Fachbegriffe ansehen.

Terminologie

LlamaIndex ist ein führendes Datenframework für die Entwicklung von LLM-Anwendungen (Large Language Model). LlamaIndex bietet Abstraktionen für verschiedene Phasen der Entwicklung einer RAG-Anwendung (Retrieval Augmented Generation). Frameworks wie LlamaIndex und LangChain bieten Abstraktionen, damit Anwendungen nicht eng an die APIs eines bestimmten LLM gekoppelt werden.

Elasticsearch wird von Elastic angeboten. Elastic ist ein Branchenführer hinter Elasticsearch, einer Such- und Analyse-Engine, die Volltextsuche für Präzision, Vektorsuche für semantisches Verständnis und Hybridsuche für das Beste aus beiden Welten unterstützt. Elasticsearch ist ein skalierbarer Datenspeicher und eine Vektordatenbank. Die in diesem Blog verwendeten Elasticsearch-Funktionen sind in der kostenlosen Open-Source-Version von Elasticsearch verfügbar.

Retrieval Augment Generation (RAG) ist eine KI-Technik bzw. ein KI-Muster, bei dem LLMs mit externem Wissen ausgestattet werden, um Antworten auf Benutzeranfragen zu generieren. Dadurch können die LLM-Antworten auf den jeweiligen Kontext zugeschnitten werden und sind spezifischer.

Mistral bietet sowohl Open-Source- als auch optimierte LLM-Modelle für Unternehmen an. In diesem Tutorial verwenden wir deren Open-Source-Modell Mistral-7b , das auf Ihrem Laptop läuft. Falls Sie das Modell nicht auf Ihrem Laptop ausführen möchten, können Sie alternativ die Cloud-Version nutzen. In diesem Fall müssen Sie den Code in diesem Blog anpassen, um die richtigen API-Schlüssel und Pakete zu verwenden.

Ollama hilft dabei, LLMs lokal auf Ihrem Laptop auszuführen. Wir werden Ollama verwenden, um das Open-Source-Modell Mistral-7b lokal auszuführen.

Einbettungen sind numerische Repräsentationen der Bedeutung von Texten/Medien. Es handelt sich um niedrigdimensionale Darstellungen hochdimensionaler Informationen.

Erstellung einer RAG-Anwendung mit LlamaIndex, Elasticsearch und Mistral: Szenarioübersicht

Szenario:

Wir verfügen über einen Beispieldatensatz (als JSON-Datei) mit Callcenter-Gesprächen zwischen Agenten und Kunden eines fiktiven Hausratversicherungsunternehmens. Wir werden eine einfache RAG-Anwendung entwickeln, die Fragen wie diese beantworten kann:

Give me summary of water related issues.

Hoher Durchfluss

Wir betreiben Mistral LLM lokal mit Ollama.

Als nächstes laden wir Konversationen aus der JSON-Datei als Documents in den ElasticsearchStore (einen VectorStore, der von Elasticsearch unterstützt wird). Beim Laden der Dokumente erstellen wir Einbettungen mithilfe des lokal laufenden Mistral-Modells. Wir speichern diese Einbettungen zusammen mit den Konversationen im LlamaIndex Elasticsearch Vector Store (ElasticsearchStore).

Wir konfigurieren eine LlamaIndex IngestionPipeline und stellen ihr den lokal verwendeten LLM zur Verfügung, in diesem Fall Mistral, das über Ollama läuft.

Wenn wir eine Frage stellen wie „Geben Sie mir eine Zusammenfassung der wichtigsten wasserbezogenen Probleme.“ Elasticsearch führt eine semantische Suche durch und liefert Konversationen zum Thema Wasser. Diese Konversationen werden zusammen mit der ursprünglichen Frage an das lokal laufende LLM gesendet, um eine Antwort zu generieren.

Schritte zum Erstellen der RAG-Anwendung

Mistral lokal ausführen

Laden Sie Ollama herunter und installieren Sie es. Nach der Installation von Ollama führen Sie diesen Befehl aus, um Mistralherunterzuladen und auszuführen.

Das Herunterladen und erstmalige lokale Ausführen des Modells kann einige Minuten dauern. Prüfen Sie, ob Mistral weht, indem Sie eine Frage wie die folgende stellen: „Schreibe ein Gedicht über Wolken“ und prüfen Sie, ob Ihnen das Gedicht gefällt. Bitte lassen Sie ollama laufen, da wir später über Code mit dem Mistral-Modell interagieren müssen.

Elasticsearch installieren

Elasticsearch lässt sich entweder durch Erstellen einer Cloud-Bereitstellung (Anleitung hier) oder durch Ausführen in Docker (Anleitung hier) in Betrieb nehmen. Sie können auch eine produktionsreife, selbstgehostete Elasticsearch-Bereitstellung erstellen, indem Sie hier beginnen.

Sofern Sie die Cloud-Bereitstellung nutzen, besorgen Sie sich den API-Schlüssel und die Cloud-ID für die Bereitstellung, wie in der Anleitung beschrieben. Wir werden sie später verwenden.

RAG-Anwendung

Der vollständige Code ist als Referenz in diesem GitHub-Repository zu finden. Das Klonen des Repos ist optional, da wir den Code im Folgenden durchgehen werden.

Erstellen Sie in Ihrer bevorzugten IDE eine neue Python-Anwendung mit den folgenden 3 Dateien.

• index.py Hierhin wird der Code für die Indizierung von Daten eingefügt.

• query.py Hier wird der Code für Abfragen und die Interaktion mit LLM eingefügt.

• .env dort, wo Konfigurationseigenschaften wie API-Schlüssel gespeichert werden.

Wir müssen einige Pakete installieren. Wir beginnen damit, eine neue virtuelle Python-Umgebung im Stammverzeichnis Ihrer Anwendung zu erstellen.

Aktivieren Sie die virtuelle Umgebung und installieren Sie die unten aufgeführten erforderlichen Pakete.

Indexierungsdaten

Laden Sie die Datei conversations.json herunter, die Konversationen zwischen Kunden und Callcenter-Mitarbeitern unseres fiktiven Hausversicherungsunternehmens enthält. Platzieren Sie die Datei im Stammverzeichnis der Anwendung zusammen mit den beiden Python-Dateien und der .env-Datei. die Datei, die Sie zuvor erstellt haben. Nachfolgend ein Beispiel für den Inhalt der Datei.

Wir definieren eine Funktion namens get_documents_from_file in index.py , die die JSON-Datei liest und eine Liste von Dokumenten erstellt. Dokumentobjekte sind die grundlegende Informationseinheit, mit der LlamaIndex arbeitet.

IngestionPipeline erstellen

Fügen Sie zunächst die Elasticsearch CloudID und die API-Schlüssel, die Sie im Abschnitt Install Elasticsearch erhalten haben, in die Datei .env ein. Ihre .env -Datei sollte wie folgt aussehen (mit realen Werten).

Mit LlamaIndex IngestionPipeline können Sie eine Pipeline aus mehreren Komponenten zusammensetzen. Fügen Sie den unten stehenden Code in die Datei index.py ein.

Wie bereits erwähnt, kann die LlamaIndex IngestPipeline aus mehreren Komponenten zusammengesetzt sein. Wir fügen der Pipeline in Zeile pipeline = IngestionPipeline(... 3 Komponenten hinzu.

• SentenceSplitter: Wie aus der Definition von get_documents_from_file() hervorgeht, verfügt jedes Dokument über ein Textfeld, das die in der JSON-Datei gefundene Konversation enthält. Dieses Textfeld enthält einen langen Text. Damit die semantische Suche gut funktioniert, muss der Text in kleinere Abschnitte unterteilt werden. Die Klasse SentenceSplitter erledigt das für uns. Diese Abschnitte werden in der LlamaIndex-Terminologie als Knoten bezeichnet. Die Knoten enthalten Metadaten, die auf das Dokument verweisen, zu dem sie gehören. Alternativ können Sie auch Elasticsearch Ingestpipeline für das Chunking verwenden, wie in diesem Blog gezeigt.

• OllamaEmbedding: Embedding-Modelle wandeln einen Textabschnitt in Zahlen (auch Vektoren genannt) um. Die numerische Darstellung ermöglicht uns die semantische Suche, bei der die Suchergebnisse der Bedeutung des Wortes entsprechen, anstatt nur eine Textsuche durchzuführen. Wir stellen der IngestionPipeline OllamaEmbedding("mistral") zur Verfügung. Die mit SentenceSplitter aufgeteilten Chunks werden über Ollama an das auf Ihrem lokalen Rechner laufende Mistral-Modell gesendet. Mistral erstellt dann Einbettungen für die Chunks.

• ElasticsearchStore: Der LlamaIndex ElasticsearchStore-Vektorspeicher sichert die in einen Elasticsearch-Index erstellten Einbettungen. ElasticsearchStore kümmert sich um das Erstellen und Befüllen des angegebenen Elasticsearch-Index mit Inhalten. Beim Erstellen des ElasticsearchStore (referenziert durch es_vector_store) geben wir den Namen des Elasticsearch-Index an, den wir erstellen möchten (calls in unserem Fall ), das Feld im Index, in dem die Einbettungen gespeichert werden sollen (conversation_vector in unserem Fall ) und das Feld, in dem der Text gespeichert werden soll (conversation in unserem Fall ). Zusammenfassend lässt sich sagen, dass auf Basis unserer Konfiguration ElasticsearchStore ein neuer Index in Elasticsearch mit conversation_vector und conversation als Feldern (neben anderen automatisch erstellten Feldern) erstellt wird.

Um das Ganze zusammenzuführen, starten wir die Pipeline durch den Aufruf von pipeline.run(documents=documents).

Führen Sie das Skript index.py aus, um die Ingest-Pipeline zu starten:

Sobald der Pipeline-Lauf abgeschlossen ist, sollte in Elasticsearch ein neuer Index mit dem Namen calls angezeigt werden. Wenn Sie eine einfache Elasticsearch-Abfrage über die Entwicklerkonsole ausführen, sollten Sie die geladenen Daten zusammen mit den Einbettungen sehen können.

Zusammenfassend lässt sich sagen, dass wir bisher Dokumente aus einer JSON-Datei erstellt, diese in Abschnitte unterteilt, Einbettungen für diese Abschnitte erstellt und die Einbettungen (sowie die Textkonversation) in einem Vektorspeicher (ElasticsearchStore) gespeichert haben.

Abfrage

Mit dem llamaIndex VectorStoreIndex können Sie relevante Dokumente abrufen und Daten abfragen. Standardmäßig speichert VectorStoreIndex Einbettungen im Arbeitsspeicher in einem SimpleVectorStore. Alternativ können jedoch externe Vektorspeicher (wie ElasticsearchStore) verwendet werden, um die Einbettungen persistent zu machen.

Öffnen Sie query.py und fügen Sie den folgenden Code ein.

Wir definieren ein lokales LLM (local_llm), das auf das Mistral-Modell verweist, das auf Ollama läuft. Als nächstes erstellen wir einen VectorStoreIndex (index) aus dem zuvor erstellten ElasticsearchStore-Vektorspeicher und erhalten dann eine Abfrage-Engine aus dem Index. Beim Erstellen der Abfrage-Engine verweisen wir auf das lokale LLM, das zur Beantwortung verwendet werden soll. Wir geben außerdem (similarity_top_k=10) an, um die Anzahl der Dokumente zu konfigurieren, die aus dem Vektorspeicher abgerufen und an das LLM gesendet werden sollen, um eine Antwort zu erhalten.

Führen Sie das Skript query.py aus, um den RAG-Ablauf auszuführen:

Wir senden die Anfrage Give me summary of water related issues (Sie können query gerne anpassen) und die Antwort des LLM, die mit zugehörigen Dokumenten geliefert wird, sollte in etwa wie folgt aussehen.

Einige Einschränkungen:

Dieser Blogbeitrag ist eine Einführung für Anfänger in die RAG-Technik mit Elasticsearch und lässt daher die Konfiguration von Funktionen aus, die es Ihnen ermöglichen, diesen Ausgangspunkt in die Produktion zu überführen. Bei der Entwicklung für Produktionsanwendungen sollten Sie komplexere Aspekte berücksichtigen, wie z. B. die Möglichkeit, Ihre Daten mit Document Level Security zu schützen, Ihre Daten im Rahmen einer Elasticsearch Ingest-Pipeline in Chunking-Aufteilung aufzuteilen oder sogar andere ML-Jobs auf denselben Daten auszuführen, die für GenAI/Chat/Q&A-Anwendungsfälle verwendet werden.

Sie könnten auch in Erwägung ziehen, Daten aus verschiedenen externen Quellen (z. B. Azure Blob Storage, Dropbox, Gmail usw.) zu beziehen und Einbettungen mithilfe von Elastic Connectors zu erstellen.

Elastic macht all das und noch viel mehr möglich und bietet eine umfassende Lösung auf Unternehmensebene für GenAI-Anwendungsfälle und darüber hinaus.

Was kommt als Nächstes?

• Möglicherweise ist Ihnen aufgefallen, dass wir 10 thematisch zusammenhängende Konversationen zusammen mit der Benutzerfrage an das LLM senden, damit dieses eine Antwort formulieren kann. Diese Gespräche können personenbezogene Daten (PII) wie Name, Geburtsdatum, Adresse usw. enthalten. In unserem Fall ist das LLM lokal, daher ist ein Datenleck kein Problem. Wenn Sie jedoch ein LLM in der Cloud (z. B. OpenAI) verwenden möchten, ist es nicht wünschenswert, Texte zu senden, die personenbezogene Daten enthalten. In einem Folgeblogbeitrag werden wir sehen, wie man personenbezogene Daten maskiert, bevor man sie im RAG-Flow an externe LLMs sendet.

• In diesem Beitrag haben wir ein lokales LLM verwendet. Im kommenden Beitrag über die Maskierung personenbezogener Daten in RAG werden wir uns ansehen, wie man einfach von einem lokalen LLM zu einem öffentlichen LLM wechseln kann.