Schutz sensibler und personenbezogener Daten in RAG mit Elasticsearch und LlamaIndex

Elasticsearch verfügt über native Integrationen mit den branchenführenden Gen-AI-Tools und -Anbietern. Sehen Sie sich unsere Webinare zu den Themen „RAG-Grundlagen“ oder zum „Erstellen produktionsreifer Apps“ mit der Elastic-Vektordatenbank an.

Um die besten Suchlösungen für Ihren Anwendungsfall zu entwickeln, starten Sie jetzt eine kostenlose Cloud-Testversion oder testen Sie Elastic auf Ihrem lokalen Rechner.

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.

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 und Überschwemmungen bei Starkregen. Diese Ansprüche haben zu Frustrationen geführt, da Ansprüche aus Gründen wie mangelnder rechtzeitiger Meldung, Wartungsproblemen, allmählichem Verschleiß und bereits vorhandenen Schäden abgelehnt wurden. Kunden äußerten Enttäuschung, Stress und finanzielle Belastung infolge dieser Ablehnungen ihrer Ansprüche und forderten faire Bewertungen und gründliche Überprüfungen. Einige Kunden sahen sich zudem mit Verzögerungen bei der Schadensregulierung konfrontiert, was zu weiterer Unzufriedenheit mit dem Service der Versicherungsgesellschaft führte.

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:

Kunde: Hallo, ich bin Matthew Lopez, geboren am 12. Oktober 1984, und wohne in 456 Cedar St, Smalltown, NY 34567. Meine Versicherungsnummer lautet TUV8901. Agent: Guten Tag, Matthew. Wie kann ich Ihnen heute behilflich sein? Kunde: Hallo, ich bin äußerst enttäuscht über die Entscheidung Ihres Unternehmens, meinen Antrag abzulehnen.

Maskierter Text durch den CustomPostProcessor.

Kunde: Hallo, ich bin [MASKED], [MASKED] ist [DOB MASKED], und ich wohne in der Cedar St 456, [MASKED], [MASKED] 34567. Meine Versicherungsnummer lautet [MASKED]. Agent: Guten Tag, [MASKE]. Wie kann ich Ihnen heute behilflich sein? Kunde: Hallo, ich bin äußerst enttäuscht über die Entscheidung Ihres Unternehmens, meinen Antrag abzulehnen.

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

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

Die Antwort sieht wie folgt aus:

Kunden haben im Zusammenhang mit Bränden Schadensansprüche an ihren Immobilien geltend gemacht. In einem Fall wurde ein Anspruch auf Schadensersatz für einen Brandschaden an einer Garage abgelehnt, da Brandstiftung vom Versicherungsschutz ausgeschlossen ist. Ein anderer Kunde reichte eine Schadensmeldung wegen eines Brandschadens an seinem Haus ein, der durch seine Versicherungspolice abgedeckt war. Darüber hinaus meldete ein Kunde einen Küchenbrand und erhielt die Zusicherung, dass der Brandschaden abgedeckt sei.

Nutzung lokaler LLMs über

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.

Kunden haben im Zusammenhang mit Bränden Schadensansprüche an ihren Immobilien geltend gemacht. In einem Fall wurde ein Anspruch auf Schadensersatz für einen Brandschaden an einer Garage abgelehnt, da Brandstiftung vom Versicherungsschutz ausgeschlossen ist. Ein anderer Kunde reichte eine Schadensmeldung wegen eines Brandschadens an seinem Haus ein, der durch seine Versicherungspolice abgedeckt war. Darüber hinaus meldete ein Kunde einen Küchenbrand und erhielt die Zusicherung, dass der Brandschaden abgedeckt sei.

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.