Implementierung von Agentic RAG mit Claude 3.5 Sonnet, LlamaIndex und Milvus
Da sich KI-Systeme weiterhin rasant weiterentwickeln, reicht es nicht mehr aus, sich ausschließlich auf große Sprachmodelle (LLMs) zu verlassen, um den vielfältigen Anforderungen der heutigen Branchen gerecht zu werden. Diese zunehmenden Herausforderungen erfordern die Entwicklung komplexerer Architekturen, die Probleme effizienter und effektiver lösen können.
Beim von Zilliz veranstalteten Unstructured Data Meetup stellte Bill Zhang, Director of Engineering bei Zilliz, das Konzept der Compound AI Systems vor, das im Berkeley AI Research (BAIR) blog vorgestellt wurde. Dieser modulare Ansatz integriert mehrere Komponenten, um verschiedene Aufgaben zu bewältigen, anstatt sich auf ein einziges KI-Modell zu verlassen, und liefert dadurch maßgeschneidertere und effizientere Ergebnisse. Sie können sich Bills Präsentation auf dem Zilliz YouTube-Kanal ansehen.
In diesem Blog fassen wir Bills wichtigste Punkte zusammen, darunter die Entwicklung von LLM-App-Architekturen, die Konzepte von Retrieval Augmented Generation (RAG) und Agentic RAG sowie deren Herausforderungen und Vorteile. Außerdem führen wir Sie durch den Aufbau eines Agentic RAG mit Claude 3.4 Sonnet, LlamaIndex und der Milvus-Vektordatenbank.
Die Architekturentwicklung von LLM-Anwendungen
LLMs sind seit über einem Jahrzehnt Teil der KI-Landschaft, doch das Aufkommen öffentlich verfügbarer foundation models, insbesondere OpenAIs ChatGPT, hat in den letzten drei Jahren die Entwicklung von LLM-Anwendungen erheblich beschleunigt und deren rasche Ausbreitung vorangetrieben. Beim Unstructured Data Meetup fasste Bill die Schlüsselkomponenten der aktuellen KI-Architekturen und deren Entwicklung zusammen.
Figure 1- LLM System Evolution .png
Abbildung 1: Entwicklung von LLM-Systemen
Sich ausschließlich auf das vortrainierte Wissen von LLMs verlassen
Die einfachste Möglichkeit, ein LLM zu nutzen, besteht darin, sich auf sein „eigenes“ Wissen zu verlassen, um Ihre Anfrage zu beantworten. Diese Methode hat jedoch eine Einschränkung: LLMs können nicht alle Themen oder Anwendungsfälle abdecken, was zu ungenauen oder „halluzinierten“ Antworten führen kann. Eine Möglichkeit, dieses Problem zu beheben, besteht darin, mehrere LLMs zu verwenden, die jeweils auf unterschiedliche Fragetypen zugeschnitten sind, doch diese Methode würde das System übermäßig komplex und schwer skalierbar machen.
Compound AI systems: Hinzufügen zusätzlicher Komponenten zu Ihrer LLM-Pipeline
Wie können wir dieses Problem also lösen? Die Lösung liegt in Compound AI systems. Das Hinzufügen zusätzlicher Komponenten zur LLM-Pipeline kann die Leistung des Systems verbessern. Ein gängiges Beispiel ist Retrieval Augmented Generation (RAG). RAG führt eine „Wissensbasis“ oder einen „Kontext“ ein, die bzw. der typischerweise in einer Vektordatenbank wie Milvus oder Zilliz Cloud (dem verwalteten Milvus) gespeichert wird, wo spezifische Informationen für Ähnlichkeitssuchen gespeichert werden. Sie können auf Informationen zugreifen, die für Ihren Anwendungsfall angepasst sind, indem Sie Ihr Wissen in das RAG-System einspeisen. RAG nutzt die Stärke des LLM in Kombination mit einem maßgeschneiderten Prompt, der aus der Benutzeranfrage und dem aus der Vektordatenbank abgerufenen Kontext besteht, und erzeugt so genauere und relevantere Antworten.
Agenten
Müssen wir also weitere Module implementieren? Das hängt vom konkreten Anwendungsfall ab. Wie LLMs hat jedoch auch RAG Einschränkungen, da es vom jeweiligen Modell abhängt. Was ist zum Beispiel, wenn deine Anfrage die Durchführung einer Vergleichsaufgabe beinhaltet, dein Modell aber für Zusammenfassungen trainiert wurde? Wie können verschiedene Arten von Fragen effektiv verwaltet werden? Hier kommt ein zusätzliches Modul zum Einsatz: Agents. KI-Agenten sind komplexe Systeme, die „menschenähnliche“ Schritte in die Pipeline einfügen, wie Schlussfolgern, verwendete Tools oder Planung. Schauen wir uns zunächst die Grundlagen von RAG an, um die Vorteile von Agenten zu verstehen.
Retrieval Augmented Generation (RAG)
Wie oben erwähnt, verbessern RAG-Systeme die Ausgabe von LLMs, indem sie eine Vektordatenbank als Wissensbasis einbeziehen. Die grundlegenden Schritte zum Aufbau eines RAG-Systems lassen sich wie folgt zusammenfassen:
Chunking: Aufteilen von Dokumenten in kleinere Teile, um die Relevanz der aus der Vektordatenbank abgerufenen Inhalte mithilfe von semantischer Suche zu verbessern, einem zentralen Merkmal von Vektordatenbanken wie Zilliz Cloud und Milvus.
Embedding: Vektorisierung (Erstellung numerischer Repräsentationen) der Chunks, die in die Vektordatenbank aufgenommen werden.
Prompt: Anweisungen, die dem LLM gegeben wurden, um basierend auf der Anfrage in der Vektordatenbank zu suchen und die Antwort zu erhalten
Query: Die Frage, die dem LLM gestellt wird
Diese Schritte basieren hauptsächlich auf Ähnlichkeit. Das Modell sucht nach den ähnlichsten Chunks in der Datenbank und generiert auf dieser Grundlage die genaueste Antwort.
Figure 2- Basic steps of RAG .png
Abbildung 2: Grundlegende Schritte von RAG
Eine semantische Ähnlichkeitssuche ist jedoch keine magische Lösung. Die resultierende Antwort wird ebenfalls unzureichend sein, wenn die ähnlichsten Chunks nicht genau genug sind. Bill untersuchte einige der Schwächen von RAG-Systemen, insbesondere in Anwendungsfällen, in denen LLMs möglicherweise nicht optimal funktionieren, darunter Zusammenfassung, Vergleich und mehrteilige Fragen.
Das Problem von RAG, nämlich der Mangel an Schlussfolgerungsfähigkeiten und die Unfähigkeit, die erforderlichen Dokumente präzise abzurufen, kann jedoch durch die Einführung von Agents effektiv angegangen werden. Diese Entitäten spielen eine entscheidende Rolle im gesamten Prozess und bieten eine potenzielle Lösung für die durch RAG entstehenden Herausforderungen.
Agentic RAG
Nachdem wir nun die Einschränkungen von LLMs und RAG verstanden haben, können wir die Vorteile von Agenten eingehender untersuchen. Im untenstehenden Diagramm enthalten LLM-Agenten mehrere Komponenten, die in einem iterativen Prozess miteinander interagieren. Nun geht es nicht mehr nur um Ähnlichkeit, sondern auch um Planung, Schlussfolgern, Tool-Nutzung und Memorierung.
Figure 3- LLM Agents .png
Abbildung 3: LLM-Agenten
Obwohl es mehrere agentische Architekturen und Frameworks gibt, ist eines der beliebtesten ReAct (Reasoning/Acting). ReAct umfasst mehrere Schritte: Planung/Schlussfolgern, Handeln (Nutzung von Tools), Beobachtung/Bewertung und Antwortgenerierung. Bill hob diese Schritte als Teil eines iterativen Prozesses hervor.
Im Schritt Beobachtung/Bewertung sucht das Modell, wenn es die Antwort nicht findet, weiter nach Alternativen, indem es zum Schlussfolgerungsschritt zurückkehrt oder sogar einen zusätzlichen Prompt vom Benutzer anfordert.
Figure 4- ReAct Framework.png
Abbildung 4: ReAct-Framework (Quelle)
Wie können wir diese Agenten also in einer RAG-Pipeline nutzen? Das Gute ist, dass sie in allen Schritten der Pipeline implementiert werden können, sei es Routing/Planung in die nachgelagerte RAG-Pipeline oder Tool Calling. Sogar die Wissensdatenbank kann als Tool oder als ReAct-Framework betrachtet werden.
Figure 5- How An Agentic RAG works .png
Abbildung 5: Wie ein Agentic RAG funktioniert
Während des Vortrags erklärte Bill fünf mögliche agentische Implementierungen innerhalb einer RAG-Pipeline:
Routing: Die Benutzeranfrage wird an eine spezifische Wissensdatenbank weitergeleitet, die für die Anfrage relevant ist.
- Beispiel: Wenn der Benutzer nach Empfehlungen für bestimmte Arten von Büchern fragt, kann die Anfrage an die Wissensdatenbank weitergeleitet werden, die Informationen zu diesen Arten von Büchern enthält.
Query Planning: Die Anfrage wird in Teilanfragen aufgeteilt, wobei jede Teilanfrage an die relevante RAG-Pipeline weitergeleitet wird.
- Beispiel: Wenn Sie die Finanzergebnisse eines Unternehmens der letzten drei Jahre erfahren möchten, erstellt der Agent Teilanfragen für jedes Jahr und leitet jede an die entsprechende Wissensdatenbank weiter.
Tool Use: Ein LLM interagiert mit einer externen API oder einem Tool und bestimmt die notwendigen Parameter für die Interaktion.
- Beispiel: Wenn ein Benutzer eine Wettervorhersage anfordert, ruft das LLM eine Wetter-API auf, bestimmt Parameter wie Standort und Datum und verarbeitet die Antwort der API, um die Antwort bereitzustellen.
ReAct: Ein iterativer Prozess, der Schlussfolgern und Handeln umfasst, einschließlich Planungs-, Tool-Nutzungs- und Beobachtungsschritten.
- Beispiel: Um einen detaillierten Reiseplan zu erstellen, ermittelt das System durch Schlussfolgern die Bedürfnisse des Benutzers, nutzt APIs, um Informationen zu Attraktionen, Restaurants und Unterkünften zu sammeln, beobachtet die Ergebnisse auf Genauigkeit und Relevanz und stellt anschließend einen umfassenden Reiseplan bereit.
Dynamic Query Planning: Der Agent führt mehrere Aufgaben oder Teilanfragen parallel statt sequenziell aus und aggregiert die Ergebnisse
Beispiel: Wenn Sie die Finanzergebnisse zweier Unternehmen vergleichen und die Differenz in einer bestimmten Kennzahl berechnen möchten, verarbeitet der Agent die Daten für beide Unternehmen parallel und kombiniert anschließend die Ergebnisse, um den Vergleich bereitzustellen. LLMCompiler ist ein Beispiel-Framework, das eine effiziente und effektive Orchestrierung paralleler Funktionsaufrufe ermöglicht.
Figure 6- LLM Compiler.png
Abbildung 6: LLM Compiler (Quelle)
Agenten fügen der RAG-Pipeline also eine zusätzliche Ebene hinzu, wodurch die Gesamteffizienz des Prozesses gesteigert und verbessert wird. Allerdings bringen Agenten, genau wie LLMs und RAG als eigenständige Systeme, auch einige Herausforderungen mit sich, etwa die Kontrolle ihrer internen Schritte und ihre Anpassung, um die besten Ergebnisse für spezifische Anwendungsfälle zu erzielen.
Lassen Sie uns nun eine einfache agentische Pipeline mit der Milvus-Vektordatenbank vorstellen.
Agentic RAG mit Claude 3.5 Sonnet, LlamaIndex und Milvus
Das folgende Notebook ist ein Beispiel für eine Agentic-RAG-Pipeline, die mit LlamaIndex als agentischem Framework, Milvus als Vektordatenbank und Claude 3.5 Sonnet als LLM erstellt wurde. In diesem Abschnitt führe ich Sie durch den Aufbau dieses agentischen RAG.
Den vollständigen Code finden Sie auch in diesem Notebook.
Schritt 1: Datenladen
Wir verwenden die FAQ-Seiten aus der Milvus Documentation 2.4.x als privates Wissen in unserem RAG, was eine gute Datenquelle für eine einfache RAG-Pipeline ist.
!pip install -qq llama-index pymilvus llama-index-vector-stores-milvus llama-index-llms-anthropic
!wget https://github.com/milvus-io/milvus-docs/releases/download/v2.4.6-preview/milvus_docs_2.4.x_en.zip
!unzip -q /content/milvus_docs_2.4.x_en.zip -d /content/milvus_docs
from llama_index.core import SimpleDirectoryReader
# Dokumente laden
documents = SimpleDirectoryReader(
input_files=["/content/milvus_docs/en/faq/operational_faq.md"]
).load_data()
print("Dokument-ID:", documents[0].doc_id)
Schritt 2: Umgebungsvariablen
Wir müssen zwei API-SCHLÜSSEL importieren: Anthropic und OpenAI.
import os
from google.colab import userdata
os.environ["ANTHROPIC_API_KEY"] = userdata.get('ANTHROPIC_API_KEY')
os.environ["OPENAI_API_KEY"] = userdata.get('OPENAI_API_KEY')
Schritt 3: Datenindexierung
Ein Index der Dokumente wird mithilfe der Milvus-Vektordatenbank erstellt. Dies wird unsere Wissensbasis sein. Da OpenAI das standardmäßige Einbettungsmodell in LlamaIndex ist (es kann geändert werden), müssen wir dieselben Dimensionen (dim = 1536) im MilvusVectorStore definieren. Zusätzlich wird nach dem Ausführen des folgenden Codes eine lokale Datenbank erstellt, die unsere Wissensbasis enthalten wird.
from llama_index.core import VectorStoreIndex, StorageContext
from llama_index.vector_stores.milvus import MilvusVectorStore
vector_store = MilvusVectorStore(dim=1536)
storage_context = StorageContext.from_defaults(vector_store=vector_store)
index = VectorStoreIndex.from_documents(documents, storage_context=storage_context)
Schritt 4: Einfache Query Engine
Testen wir zunächst die Query Engine ohne Agenten. Sie wird von Claude 3.5 Sonnet unterstützt und sucht nach relevantem Inhalt in unserem Index.
llm = Anthropic(model="claude-3-5-sonnet-20240620")
query_engine = index.as_query_engine(similarity_top_k=5, llm=llm)
res = query_engine.query("What is the maximum vector dimension supported in Milvus?")
print(res)
"""
Ausgabe:
Milvus unterstützt standardmäßig Vektoren mit bis zu 32.768 Dimensionen. Wenn Sie jedoch mit Vektoren noch höherer Dimensionalität arbeiten müssen, haben Sie die Möglichkeit, den Wert des Parameters 'Proxy.maxDimension' zu erhöhen. Dadurch kann Milvus Vektoren mit Dimensionen aufnehmen, die das Standardlimit überschreiten.
"""
Schritt 5: Agentische Query Engine
Jetzt fügen wir das QueryEngineTool hinzu, das als Wrapper-Tool für die Query Engine fungiert und vom Agenten verwendet wird.
from llama_index.core import VectorStoreIndex
from llama_index.core.tools import QueryEngineTool, ToolMetadata
from llama_index.llms.anthropic import Anthropic
llm = Anthropic(model="claude-3-5-sonnet-20240620")
query_engine = index.as_query_engine(similarity_top_k=5, llm=llm)
query_engine_tool = QueryEngineTool(
query_engine=query_engine,
metadata=ToolMetadata(
name="knowledge_base",
description=(
"Provides information about Milvus FAQ."
"Use a detailed plain text question as input to the tool."
),
),
)
Schritt 6: Erstellung des KI-Agenten
Der in diesem Fall verwendete Agent ist der FunctionCallingAgentWorker von LlamaIndex, der kritische Reflexion auf die Query-Antwort unter Verwendung des Query-Engine-Tools einsetzt, um eine verbesserte Antwort zu generieren.
from llama_index.core.agent import FunctionCallingAgentWorker
agent_worker = FunctionCallingAgentWorker.from_tools(
[query_engine_tool], llm=llm, verbose=True
)
agent = agent_worker.as_agent()
response = agent.chat("What is the maximum vector dimension supported in Milvus?")
print(str(response))
"""
Ausgabe:
Benutzernachricht zum Speicher hinzugefügt: What is the maximum vector dimension supported in Milvus?
=== LLM-Antwort ===
Um Ihre Frage zur maximalen von Milvus unterstützten Vektordimension zu beantworten, muss ich die Milvus-FAQ-Wissensbasis konsultieren. Ich erledige das für Sie.
=== Funktion wird aufgerufen ===
Funktion wird aufgerufen: knowledge_base mit Argumenten: {"input": "What is the maximum vector dimension supported in Milvus?"}
=== Funktionsausgabe ===
Milvus unterstützt standardmäßig Vektoren mit bis zu 32.768 Dimensionen. Wenn Sie jedoch mit Vektoren noch höherer Dimensionalität arbeiten müssen, haben Sie die Möglichkeit, den Wert des Parameters 'Proxy.maxDimension' zu erhöhen. Dadurch kann Milvus Vektoren mit Dimensionen aufnehmen, die das Standardlimit überschreiten.
=== LLM-Antwort ===
Basierend auf den Informationen aus der Milvus-FAQ-Wissensdatenbank kann ich Ihnen die folgende Antwort geben:
Die maximal unterstützte Vektordimension in Milvus beträgt standardmäßig 32.768. Das bedeutet, dass Milvus sofort einsatzbereit Vektoren mit bis zu 32.768 Dimensionen verarbeiten kann, was für die meisten Anwendungen geeignet ist.
Es ist jedoch wichtig zu beachten, dass Milvus Flexibilität für Fälle bietet, in denen Sie möglicherweise mit noch höherdimensionalen Vektoren arbeiten müssen. Wenn Ihr Anwendungsfall Vektoren mit Dimensionen von mehr als 32.768 erfordert, haben Sie die Möglichkeit, dieses Limit zu erhöhen. Dies kann durch Anpassen des Parameters 'Proxy.maxDimension' in der Milvus-Konfiguration erfolgen.
Also, zusammenfassend:
1. Standardmäßige maximale Dimension: 32.768
2. Kann erhöht werden: Ja, durch Ändern des Parameters 'Proxy.maxDimension'
Diese Flexibilität ermöglicht es Milvus, eine breite Palette von Anwendungsfällen abzudecken, von typischen Machine-Learning- und KI-Anwendungen bis hin zu spezielleren Szenarien, die extrem hochdimensionale Vektoren erfordern könnten.
Basierend auf den Informationen aus der Milvus-FAQ-Wissensdatenbank kann ich Ihnen die folgende Antwort geben:
Die maximal unterstützte Vektordimension in Milvus beträgt standardmäßig 32.768. Das bedeutet, dass Milvus sofort einsatzbereit Vektoren mit bis zu 32.768 Dimensionen verarbeiten kann, was für die meisten Anwendungen geeignet ist.
Es ist jedoch wichtig zu beachten, dass Milvus Flexibilität für Fälle bietet, in denen Sie möglicherweise mit noch höherdimensionalen Vektoren arbeiten müssen. Wenn Ihr Anwendungsfall Vektoren mit Dimensionen von mehr als 32.768 erfordert, haben Sie die Möglichkeit, dieses Limit zu erhöhen. Dies kann durch Anpassen des Parameters 'Proxy.maxDimension' in der Milvus-Konfiguration erfolgen.
Also, zusammenfassend:
1. Standardmäßige maximale Dimension: 32.768
2. Kann erhöht werden: Ja, durch Ändern des Parameters 'Proxy.maxDimension'
Diese Flexibilität ermöglicht es Milvus, eine breite Palette von Anwendungsfällen abzudecken, von typischen Machine-Learning- und KI-Anwendungen bis hin zu spezielleren Szenarien, die extrem hochdimensionale Vektoren erfordern könnten.
"""
Die Ausgabe des Agenten liefert eine detailliertere Antwort, einschließlich der Informationsquelle, der Begründung hinter der Antwort und einiger zusätzlicher Vorschläge zum Thema. Dies hilft uns, die vom LLM-Modell gegebene Antwort besser zu verstehen.
Die Agentic-RAG-Architektur
Die vollständige Architektur des agentischen RAG, das wir gerade erstellt haben, sieht wie folgt aus.
Die agentische RAG-Architektur, erstellt mit Milvus, LlamaIndex und Cluade 3.5 Sonnet.png
Abbildung 7: Die agentische RAG-Architektur, erstellt mit Milvus, LlamaIndex und Cluade 3.5 Sonnet
Fazit
In seinem Vortrag untersuchte Bill Zhang die sich entwickelnde Landschaft von LLM-Systemen und hob den Wandel von eigenständigen Modellen hin zu komplexeren Architekturen hervor, die RAG und Agenten einbeziehen. Jede Komponente—LLMs, RAG und Agenten—hat Stärken und Schwächen. Das Konzept von Compound AI ermöglicht die Erstellung modularer Systeme, die darauf ausgelegt sind, verschiedene Engpässe zu beheben und dadurch die Gesamteffizienz der Pipeline zu verbessern.
Auch wenn die Ergebnisse dieser fortschrittlichen Systeme vielversprechend sind und produktionsreife Implementierungen immer häufiger werden, bleiben mehrere Herausforderungen bestehen, insbesondere bei der Verwaltung und Anpassung des Agentenverhaltens innerhalb dieser Systeme. Die Feinabstimmung dieser Komponenten, damit sie in spezifischen Anwendungsfällen effizient arbeiten, ist ein fortlaufender Entwicklungsbereich.
Weitere Ressourcen zu GenAI, VectorDB und ML
Weiterlesen
Zilliz Skills Breakdown: How AI Agents Master Vector Databases
Zilliz's Milvus Skill (pymilvus, 7 files) and Zilliz Cloud Skill (zilliz-cli, 14 modules) bring vector-DB dev and ops into one Claude Code session.
Demystifying the Milvus Sizing Tool
Explore how to use the Sizing Tool to select the optimal configuration for your Milvus deployment.
Vector Databases vs. Hierarchical Databases
Use a vector database for AI-powered similarity search; use a hierarchical database for organizing data in parent-child relationships with efficient top-down access patterns.