LLM-gestützter QA-Chatbot für Ihre Daten in Ihrer Cloud

OpenAI und LangChain haben es sehr einfach gemacht, eine Demo für Question-Answering über Ihre eigenen Dokumente zu erstellen. Es gibt zahlreiche Artikel im Internet, die beschreiben, wie das geht. Wir haben auch ein funktionsfähiges Notebook für Sie vorbereitet, falls Sie ein System Ende-zu-Ende testen möchten:

‍

truefoundry-examples/docs-qa-langchain/simple at main · truefoundry/truefoundry-examples

Dieses Repository enthält alle in den Demo-Beispielen erwähnten Projekte. - truefoundry/truefoundry-examples

GitHub TrueFoundry

‍

In diesem Artikel erläutern wir, wie Sie einen Question-Answering-Bot für Ihre Dokumente in die Produktion überführen. Wir werden ihn in Ihrer Cloud-Umgebung bereitstellen und auch die Nutzung von Open-Source-LLMs anstelle von OpenAI ermöglichen, falls Datenschutz und Datensicherheit zu Ihren Kernanforderungen gehören.

Der zentrale Workflow für den Aufbau des QA-Systems mittels RAG (Retrieval-Augmented Generation) sieht wie folgt aus:

Ablauf der Dokumenten-Indexierung:

1. Dokumente laden.
2. Dokumente in Chunks einer bestimmten Länge (z. B. len) aufteilen.
3. Chunks mithilfe eines Embedding-Modells einbetten (entweder OpenAI-Embeddings oder ein Open-Source-Modell wie e5-large-v2).
4. Embeddings in einer VectorDB wie Milvus, Qdrant usw. speichern.

Antwort auf eine Benutzeranfrage erhalten:

1. Benutzeranfrage mit denselben Embedder-Einstellungen einbetten, die für die Indexierung der Dokumente verwendet wurden.
2. Ähnlichste Chunks zur Anfrage aus der VectorDB suchen.
3. Prompt für das LLM unter Verwendung der Chunks zusammenstellen.
4. Antwort vom LLM erhalten (z. B. OpenAI-Modelle oder Open-Source-Modelle wie Falcon, Llama2 etc.).

RAG-Architektur

Um den oben beschriebenen Gesamtablauf bereitzustellen, müssen wir mehrere Komponenten zusammen deployen. Hier ist das Architekturdiagramm für das Deployment von RAG in Ihrer eigenen Cloud.

Die Kernkomponenten in der obigen Architektur sind:

Document Store

Hier werden die Dokumente gespeichert. In vielen Fällen ist dies AWS S3, Google Storage Buckets oder Azure Blob Storage. In manchen Fällen können diese Daten auch über APIs eingehen, wenn wir beispielsweise mit Confluence-Dokumenten arbeiten. 

Indexer Job

Dieser wird ähnlich wie ein Training Job im Bereich ML modelliert: Er erhält die Dokumente als Eingabe, teilt sie in Chunks auf, ruft das Embedding-Modell auf, um die Chunks einzubetten, und speichert die Vektoren in der Datenbank. Das Embedding-Modell kann im Job selbst geladen oder über eine API aufgerufen werden. Der API-Weg wird bevorzugt, da das Embedding-Modell so unabhängig hochskaliert werden kann, falls eine große Anzahl an Dokumenten verarbeitet werden muss. Die Jobs können ad-hoc oder nach einem Zeitplan ausgelöst werden, wenn ein kontinuierlicher Dokumentenstrom vorliegt. Nach Abschluss des Jobs sollte dieser den Status zusammen mit den Embedding-Einstellungen als erfolgreich in einem Metadata Store speichern.

Embedding Model

Wenn wir OpenAI oder ein extern gehostetes Modell verwenden, müssen wir in diesem Fall kein eigenes Modell hosten. Bei der Verwendung eines Open-Source-Modells müssen wir dieses jedoch in unserer Cloud-Umgebung hosten und die Embeddings anschließend über die API abrufen.

LLM Model

Wenn wir OpenAI oder gehostete Modell-APIs wie Cohere und Anthropic nutzen, müssen wir nichts deployen; andernfalls müssen wir Open-Source-LLMs bereitstellen.

Query Service

Dies kann ein FastAPI-Service sein, der die API bereitstellt, um alle indexierten Dokumenten-Collections aufzulisten, und dem Benutzer Abfragen über diese Collections ermöglicht. Es gibt auch eine API zum Auslösen eines neuen Indexierung-Jobs für eine neue Dokumenten-Collection.

VectorDB

Wir können hier eine gehostete Lösung wie Pinecone verwenden oder eine der Open-Source-VectorDBs wie Qdrant oder Milvus selbst hosten.

Metadata Store

Dies wird benötigt, um die Links zu den indexierten Dokumenten sowie die Konfiguration zu speichern, die zum Einbetten der Chunks in diesen Dokumenten verwendet wurde. Dies hilft dem Benutzer bei der Auswahl des zu abfragenden Dokumentensets und kann mehrere Dokumentensets innerhalb einer Organisation unterstützen.

Einrichtung dieser Architektur mit TrueFoundry

TrueFoundry ist eine Plattform auf Kubernetes, die das Deployment von ML-Training-Jobs und Services zu optimalen Kosten extrem vereinfacht. Mit TrueFoundry können wir alle Komponenten der obigen Architektur in Ihrem eigenen Cloud-Account bereitstellen. Das finale Deployment in Ihrer Cloud sieht etwa so aus:

Das mag nach viel Einrichtungsaufwand klingen, aber wir haben bereits ein Template erstellt, mit dem Sie in unter 10 Minuten starten können. Wir nehmen an, dass Sie bereits bei TrueFoundry registriert sind. Falls nicht, folgen Sie dieser Anleitung für das Onboarding. TrueFoundry funktioniert mit allen drei großen Cloud-Anbietern: AWS, Azure und GCP – Sie können es also bei jedem dieser Anbieter einrichten.

Wir haben in diesem GitHub-Repo einen Beispiel-QA-Bot für Sie erstellt, der den Code für den Indexer Job, den Query Service und ein Chat-Frontend mit Streamlit enthält:

‍

GitHub - truefoundry/docs-qa-playground

Tragen Sie zur Entwicklung von truefoundry/docs-qa-playground bei, indem Sie ein Konto auf GitHub erstellen.

GitHub TrueFoundry

‍

Sie können dies innerhalb von 15 Minuten auf TrueFoundry in Ihrer eigenen Cloud deployen. Dies ermöglicht ein produktionsreifes Setup und bietet Ihnen die volle Flexibilität, den Code an Ihre eigenen Anwendungsfälle anzupassen.

Wie deploye ich QA mit TrueFoundry?

Wir werden die gesamte Architektur auf einem Kubernetes-Cluster bereitstellen. Den vollständigen Code und die Anweisungen zum Deployment finden Sie in diesem GitHub-Repo.

TrueFoundry bietet eine einfach zu bedienende Abstraktion über Kubernetes, um verschiedene Anwendungstypen auf Kubernetes zu deployen. Wir gehen die einzelnen Schritte zur Bereitstellung von RAG in Ihrer Cloud durch.

ML-Repo erstellen und Dokumente als Artifact hochladen

TrueFoundry bietet einen Metadata Store in Form von ML-Repos. Sie können Artifacts und Metadaten speichern, und die mlfoundry Pip-Bibliothek stellt Methoden zum Hoch- und Herunterladen der Artifacts bereit. Jedes ML-Repo ist an den Cloud Blob Storage gekoppelt (AWS S3, GCS oder Azure Blob Storage). Wir beginnen mit dem Erstellen eines ML-Repos und laden dann unsere zu indexierenden Dokumente als Artifact hoch. Zum Erstellen eines ML-Repos folgen Sie der Anleitung hier: https://www.truefoundry.com/docs/creating-a-ml-repo

Sobald wir ein Artifact erstellt haben, erstellen wir eine neue Artifact-Version. Auf diese Weise können Sie jedes Mal, wenn sich der Dokumentensatz ändert, den neuen Satz als neue Version hochladen. Sie können Ihre Dokumente im folgenden Bildschirm hochladen.

Nach dem Hochladen der Dokumente erhalten wir die FQN der Artifact-Version, mit der wir das Artifact überall im Code referenzieren / herunterladen können.

Embedding-Modell deployen

Wir benötigen das Embedding-Modell zum Einbetten der Chunks – Sie können diesen Schritt überspringen, wenn Sie OpenAI Embeddings verwenden. Sie können jedes beliebige Embedding-Modell aus dem Modellkatalog deployen – im Allgemeinen haben wir festgestellt, dass e5-large-v2 sehr gut abschneidet. 

Sobald das Embedding-Modell bereitgestellt ist, können Sie die APIs über den OpenAPI Playground im TrueFoundry-Dashboard testen.

VectorDB deployen: Qdrant

Wir werden die Qdrant VectorDB deployen.

Indexer Job deployen

Wir deployen nun den Indexer Job. Ein Job in TrueFoundry ermöglicht es uns, ein Skript einmalig oder nach Zeitplan auszuführen, woraufhin die Compute-Ressourcen nach Beendigung des Jobs heruntergefahren werden. Der Code für den Indexer Job ist hier zu finden: https://github.com/truefoundry/docs-qa-playground/tree/main/backend/train. Der Indexer Job unterstützt das Laden von Daten aus lokalen Dateien oder aus einem mlfoundry-Artifact. Er rendert außerdem automatisch ein Formular, in dem Sie Argumente zum Auslösen des Jobs angeben können. Sie können die in Schritt 1 kopierte Artifact-FQN eingeben und im Feld Source-URI als mlfoundry://<artifact_fqn> einfügen. Der Repo-Name kann eine beliebige Zeichenfolge sein, die Ihnen hilft, diesen Indexierungs-Job zu identifizieren. Sie müssen auch den Namen des ML-Repos eingeben, das wir in Schritt 1 erstellt haben.

Sobald der Job läuft, können Sie alle Job-Ausführungen und deren Logs verfolgen:

Metadata Store

Bei jedem Joblauf erstellen wir einen Run im ML-Repo, der alle Embedding-Einstellungen und Parameter des Indexer Jobs speichert. Diese Einstellungen werden später vom Query Service verwendet, um die Embedding-Einstellungen für das Einbetten der Anfrage zu ermitteln. Sie können die Details aller Indexierungs-Jobs im Tab "Runs" verfolgen.

Query Service deployen

Der Query Service ist ein FastAPI-Server mit einer API zum Empfangen der Anfrage und Generieren der Antwort vom LLM. Nach dem Deployment können Sie Anfragen über die Swagger-UI von FastAPI stellen.

LLM-Modell deployen

Dies ist erforderlich, wenn Sie ein Open-Source-LLM anstelle von OpenAI verwenden möchten. Sie können das LLM aus dem Modellkatalog deployen.

Indexierung und Chatbot-Frontend deployen

Wir stellen auch eine Streamlit-App bereit, die mit Ihrem Indexierungs-Backend, dem Query Service und dem Metadata Store verknüpft werden kann, um alle indexierten Repositories aufzulisten und Abfragen darauf auszuführen. Eine Beispiel-Demo dazu ist unter https://www.truefoundry.com/docs/create-and-setup-your-account gehostet. Den Code finden Sie im GitHub-Repo hier. Damit dieses Frontend funktioniert, müssen Sie es über Umgebungsvariablen mit Ihrem Query Service und Ihrem Job verknüpfen:

Jetzt haben wir ein Ende-zu-Ende-System mit einem Frontend, das auf beliebig viele verschiedene Anwendungsfälle und Dokumentensätze innerhalb der Organisation skaliert werden kann. Es gibt einige Dinge, die wir in Zukunft integrieren möchten:

1. Inkrementelle Indexierung neuer Dokumente im Repository
2. Anpassung des Frontends an verschiedene Indexierungs-Jobs und Backend-APIs – derzeit funktioniert es nur für ein Backend und einen Job.

Diese Architektur ermöglicht auch einen zentralen Dokumenten-Indexierungsservice in einer Organisation, der auf einer zentralen Bibliothek von Datenladern und Parsern basiert.