RAG mit selbst bereitgestellter Milvus-Vektordatenbank und Snowpark Container Services
Jiang Chen, Head of Ecosystem & AI Platform bei Zilliz, sprach kürzlich in einem Vortrag beim Unstructured Data Meetup darüber, wie wir Milvus nahtlos in Snowflake integrieren können. Konkret untersuchte er, wie man ein Retrieval Augmented Generation (RAG)-System mit der Milvus-Vektordatenbank und ihrer Integration in das Snowflake-Ökosystem mithilfe des Snowpark Container Service (SPCS) aufbaut.
< Sehen Sie sich Jiang Chens Vortrag auf Youtube an >
Dieser Beitrag fasst Jiangs wichtigste Punkte zusammen und behandelt drei wichtige Themen.
Zunächst werden wir die Nutzung von Milvus für die Vektorsuche besprechen, einen wesentlichen Schritt beim Aufbau eines RAG-Systems. Als Nächstes besprechen wir, wie Milvus mit SPCS in Snowflake integriert wird. Schließlich werden wir auch die zukünftige Landschaft von RAG erörtern. Bevor wir tief in die Themen eintauchen, sehen wir uns an, wie KI die Informationsbeschaffung verändert hat.
Wie KI den Prozess der Informationsbeschaffung revolutioniert
Der Fortschritt und die Beliebtheit von KI haben die gesamte Landschaft der Informationsbeschaffung schnell verändert. Vor dem Aufstieg der KI stützte sich die Informationsbeschaffung stark auf statistische Modelle und Keyword-Matching-Methoden wie Tagging. Zum Beispiel müsste der Besitzer eines Online-Shops für jedes Produkt manuell Tags in vordefinierte Kategorien eingeben. Wenn er einen riesigen Produktkatalog hat, wäre dieser Prozess nicht praktikabel.
Ebenso müssten wir als Kunden passende Tags eingeben, um genau das gewünschte Produkt zu erhalten. Das Problem ist: Wenn wir einen Tag eingeben, der nicht exakt ist, aber eine ähnliche Bedeutung wie das gewünschte Produkt hat, wird die Informationsbeschaffung über die Tagging-Methode uns nicht die passenden Produkte liefern. Mit anderen Worten: Die Tagging-Methode berücksichtigt nicht die semantische Bedeutung einer Anfrage.
KI revolutioniert, wie wir unstrukturierte Daten nutzen
KI revolutioniert, wie wir unstrukturierte Daten nutzen
Die Entstehung von Embedding-Modellen hat die Art und Weise, wie wir Informationen abrufen, vollständig verändert. Die meisten Embedding-Modelle verwenden die berühmte Transformer-Architektur als ihr Rückgrat. Das Transformer-Modell nutzt mehrere Encoder-Decoder-Blöcke, von denen jeder eine spezialisierte Attention-Schicht enthält. Diese Schicht ermöglicht es dem Modell, die semantische Bedeutung jedes Eingabe-Tokens in Bezug auf die gesamte Eingabesequenz zu erfassen, wodurch Embedding-Modelle die semantische Bedeutung von Eingabewörtern ableiten können.
Transformer-Architektur
Transformer-Architektur
Die Embedding-Modelle transformieren Anfragen, Bilder oder Textbeschreibungen in ihre numerischen Darstellungen, die als Vektoreinbettungen bezeichnet werden. Eine Vektoreinbettung trägt eine semantisch reichhaltige Bedeutung der Eingabe, die sie repräsentiert, und wir können die Ähnlichkeit zwischen zwei Vektoreinbettungen über Kosinus-Ähnlichkeit oder Kosinus-Distanz vergleichen. Wenn die Ähnlichkeit hoch ist, haben zwei Vektoreinbettungen eine ähnliche Bedeutung und umgekehrt.
Rohtexte zu Vektoreinbettungen.png
Rohtexte zu Vektoreinbettungen
Aufgrund dieser leistungsstarken Eigenschaften machen Einbettungsmodelle die Implementierung des Konzepts der Informationsabfrage viel einfacher und flexibler.
Retrieval Augmented Generation (RAG)
Der rasante Fortschritt bei Einbettungsmodellen und der Aufstieg großer Sprachmodelle (LLMs) haben zur Entstehung von RAG geführt, einer sehr ausgefeilten Methode der Informationsabfrage. RAG wurde entwickelt, um die Antwortqualität eines LLM zu verbessern, indem dem LLM neben der Abfrage relevanter Kontext aus einer internen Wissensdatenbank bereitgestellt wird. Das LLM verwendet dann den bereitgestellten Kontext, um die Abfrage zu beantworten.
RAG-Architektur
RAG-Architektur
In einer RAG-Anwendung verwenden wir unsere ausgewählten Einbettungsmodelle, um unsere Daten und die Eingabeabfrage in Einbettungen umzuwandeln. Anschließend berechnen wir die Ähnlichkeit zwischen der Einbettung unserer Abfrage und den Einbettungen unserer eigenen Daten. Die Daten, die unserer Abfrage am ähnlichsten sind, werden dann zusammen mit unserer Abfrage als Kontext an ein LLM übergeben. Letztlich kann unser LLM auf Grundlage des bereitgestellten Kontexts eine Antwort auf die Abfrage generieren. Auf diese Weise können wir die Antwortgenauigkeit eines LLM verbessern, ohne es feinabstimmen zu müssen.
Integration der Milvus-Vektordatenbank und Snowflake mit Snowpark Container Service
Milvus ist eine Open-Source-Vektordatenbank, mit der Sie eine riesige Menge an Vektoreinbettungen speichern können, die für RAG-Anwendungen nützlich sind, und Vektorsuchen darauf in Sekundenbruchteilen durchführen können. Es gibt mehrere Optionen, Milvus zu installieren und zu verwenden:
- Milvus Lite: Eine leichtgewichtige Version von Milvus, die sich für schnelles Prototyping eignet. Milvus Lite erfordert keinen Server; Sie können es auf Ihrem eigenen Gerät ausführen. Der Installationsprozess ist so einfach wie die Verwendung eines pip-install-Befehls.
!pip install "pymilvus>=2.4.2"
from pymilvus import MilvusClient
client = MilvusClient("milvus_demo.db")
- Milvus in Docker: Wenn Sie Ihre Milvus-Vektordatenbank in der Produktion verwenden möchten und nur eine kleine Datenmenge haben, können Sie sie als Docker-Container ausführen. Der Prozess ist ebenfalls unkompliziert, da Sie nur diese Befehle in Ihrer Befehlszeile ausführen müssen:
# Download the installation script
$ curl -sfL <https://raw.githubusercontent.com/milvus-io/milvus/master/scripts/standalone_embed.sh> -o standalone_embed.sh
# Start the Docker container
$ bash standalone_embed.sh start
# In your Python IDE
from pymilvus import MilvusClient
client = MilvusClient(
uri="<http://milvus:19530>",
)
- Milvus in Kubernetes: Diese Option eignet sich, wenn Sie über riesige Datenmengen verfügen oder Ihre RAG-Anwendungen eine enorme Anzahl von Benutzern haben. Mit Kubernetes können Sie bis zu 100 Milliarden Vektoren speichern. Der Installationsprozess mit Kubernetes ist etwas komplizierter als der von Milvus Lite und Docker. Lesen Sie daher dieInstallationsdokumentation für detaillierte Informationen.
Milvus bietet eine nahtlose Integration mit beliebten KI-Toolkits wie OpenAI, HuggingFace, Cohere, LangChain, LlamaIndex und Snowflake. Diese Integrationen erleichtern es, eigene RAG-Systeme oder andere GenAI-Anwendungen zu erstellen. In diesem Abschnitt wird gezeigt, wie Sie Milvus innerhalb des Snowflake-Ökosystems ausführen.
Milvus bietet eine nahtlose Integration mit allen beliebten KI-Toolkits
Milvus bietet eine nahtlose Integration mit allen beliebten KI-Toolkits
Snowflake ist eine Data-Warehousing-Plattform, mit der Sie Daten effizient und zuverlässig speichern, verarbeiten und analysieren können. Mit der Einführung des Snowpark Container Service (SPCS) können Sie nun containerisierte Anwendungen innerhalb der Snowflake-Umgebung ausführen. Auf diese Weise kann Ihre App mit den in Snowflake gespeicherten Daten interagieren, sodass Sie eine Vielzahl von Anwendungen erstellen können, darunter ein RAG-System.
In diesem Abschnitt erstellen wir zunächst eine App mit Milvus, die eine Vektorsuche durchführt. Anschließend containerisieren wir die Anwendung mit Docker und führen den Container innerhalb von Snowflake mit SPCS aus.
Um zu beginnen, erstellen wir eine Milvus-App, um eine Vektorsuche mit Jupyter Notebook durchzuführen. Wenn Sie mitmachen möchten, finden Sie in diesem Repository das vollständige Notebook und das Skript zum Erstellen des Embedding-Modells.
from pymilvus import MilvusClient
from pymilvus import DataType
import os
import mode
# init client
client = MilvusClient(
uri="<http://milvus:19530>",
)
# init model
model = model.Onnx()
# Create a collection in quick setup mode
client.create_collection(
collection_name="quick_demo",
dimension=model.dimension,
)
print("Collection Created!")
Im obigen Code haben wir eine Collection namens „quick_demo“ in einer Milvus-Vektordatenbank erstellt und das Modell geladen, um Texte in Embeddings umzuwandeln. Wir verwenden ALBERT als unser Embedding-Modell, das einen Eingabetext in ein 768-dimensionales Vektor-Embedding abbildet.
Fügen Sie als Nächstes einige Textdaten in unsere Collection „quick_demo“ ein.
# Data from which embeddings are to be generated
docs=[
"Artificial intelligence was founded as an academic discipline in 1956.",
"Alan Turing was the first person to conduct substantial research in AI.",
"Born in Maida Vale, London, Turing was raised in southern England.",
]
# Insert data into the collection
data=[]
for i in range(len(docs)):
data.append({
'id': i,
'vector': model.to_embeddings(docs[i]),
'doc_str': docs[i]
})
res = client.insert(
collection_name="quick_demo",
data=data
)
Im obigen Code wandeln wir unsere Eingabetexte mit ALBERT in Embeddings um und speichern sie zusammen mit ihren IDs und Rohtexten in der Collection.
Wenn wir nun eine Abfrage wie „Who started AI research?“ haben und den relevanten Kontext erhalten möchten, der die passende Antwort auf unsere Abfrage enthalten könnte, können wir mit Milvus ganz einfach eine Vektorsuche wie folgt durchführen:
# Search with a text query
query = "Who started AI research?"
query_embeddings = model.to_embeddings(query)
res = client.search(
collection_name="quick_demo",
data=[query_embeddings],
limit=1,
output_fields=["doc_str"],
)
print(res)
"""
Expected output:
"Alan Turing was the first person to conduct substantial research in AI."
"""
Und das war’s für unsere Milvus-App.
Zu diesem Zeitpunkt haben wir ein Jupyter Notebook, um eine Vektorsuche mit Milvus durchzuführen. Nehmen wir an, wir möchten dieses Notebook containerisieren, um es innerhalb des Snowflake-Ökosystems auszuführen. Als Erstes müssen wir die Rolle und die Berechtigungen konfigurieren, um den von Snowflake bereitgestellten Dienst zu erstellen und auszuführen.
Laden Sie zunächst SnowSQL herunter, indem Sie den Anweisungen auf der Installing SnowSQL doc page folgen. Führen Sie als Nächstes den folgenden Befehl im Terminal aus:
snowsql -a ${instance_name} -u ${user_name}
wobei das Format von ${instance_name} ${org_name}-${acct_name} ist, und Sie Informationen zu diesen beiden Feldern in Ihrem Snowflake account finden. Nun können wir die Rolle und Berechtigungen mit den folgenden Befehlen innerhalb der SnowSQL-Shell konfigurieren:
USE ROLE ACCOUNTADMIN;
CREATE SECURITY INTEGRATION SNOWSERVICES_INGRESS_OAUTH
TYPE=oauth
OAUTH_CLIENT=snowservices_ingress
ENABLED=true;
USE ROLE ACCOUNTADMIN;
GRANT BIND SERVICE ENDPOINT ON ACCOUNT TO ROLE SYSADMIN;
USE ROLE SECURITYADMIN;
CREATE ROLE MILVUS_ROLE;
USE ROLE USERADMIN;
CREATE USER milvus_user
PASSWORD='milvususerok'
DEFAULT_ROLE = MILVUS_ROLE
DEFAULT_SECONDARY_ROLES = ('ALL')
MUST_CHANGE_PASSWORD = FALSE;
USE ROLE SECURITYADMIN;
GRANT ROLE MILVUS_ROLE TO USER milvus_user;
Da Snowflake eine Data-Warehousing-Plattform ist, interagieren wir mit allen Objekten innerhalb von Snowflake über einen SQL-query-ähnlichen Befehl, wie Sie oben sehen können. Als Nächstes können wir das Data Warehouse und die Datenbank innerhalb von Snowflake mit den folgenden Befehlen erstellen:
USE ROLE SYSADMIN;
CREATE OR REPLACE WAREHOUSE MILVUS_WAREHOUSE WITH
WAREHOUSE_SIZE='X-SMALL'
AUTO_SUSPEND = 180
AUTO_RESUME = true
INITIALLY_SUSPENDED=false;
USE ROLE SYSADMIN;
CREATE DATABASE IF NOT EXISTS MILVUS_DEMO;
USE DATABASE MILVUS_DEMO;
CREATE IMAGE REPOSITORY MILVUS_DEMO.PUBLIC.MILVUS_REPO;
CREATE OR REPLACE STAGE YAML_STAGE;
CREATE OR REPLACE STAGE DATA ENCRYPTION = (TYPE = 'SNOWFLAKE_SSE');
CREATE OR REPLACE STAGE FILES ENCRYPTION = (TYPE = 'SNOWFLAKE_SSE');
--GRANT ROLE PRIVILEGES--
USE ROLE SECURITYADMIN;
GRANT ALL PRIVILEGES ON DATABASE MILVUS_DEMO TO MILVUS_ROLE;
GRANT ALL PRIVILEGES ON SCHEMA MILVUS_DEMO.PUBLIC TO MILVUS_ROLE;
GRANT ALL PRIVILEGES ON WAREHOUSE MILVUS_WAREHOUSE TO MILVUS_ROLE;
GRANT ALL PRIVILEGES ON STAGE MILVUS_DEMO.PUBLIC.FILES TO MILVUS_ROLE;
--CONFIGURE ACL--
USE ROLE ACCOUNTADMIN;
USE DATABASE MILVUS_DEMO;
USE SCHEMA PUBLIC;
CREATE NETWORK RULE allow_all_rule
TYPE = 'HOST_PORT'
MODE= 'EGRESS'
VALUE_LIST = ('0.0.0.0:443','0.0.0.0:80');
CREATE EXTERNAL ACCESS INTEGRATION allow_all_eai
ALLOWED_NETWORK_RULES=(allow_all_rule)
ENABLED=TRUE;
GRANT USAGE ON INTEGRATION allow_all_eai TO ROLE SYSADMIN;
Um eine containerisierte App innerhalb von Snowflake auszuführen, müssen wir das Docker-Image unserer App auf unserem lokalen Rechner erstellen. In diesem Projekt müssen wir zwei verschiedene Docker-Images erstellen: eines zum Instanziieren der Milvus-Vektordatenbank und eines zum Ausführen der oben erstellten Notebook-Datei.
Allerdings benötigen wir ein Dockerfile, um ein Docker-Image zu erstellen. Um die Dinge zu vereinfachen, klonen Sie das folgende repo. In diesem Repo finden Sie alle notwendigen Dateien, um die beiden benötigten Images zu erstellen. Nach dem Klonen des Repos können Sie die beiden Docker-Images mit den folgenden Befehlen in Ihrem lokalen Terminal erstellen:
cd ${repo_git_root_path}
docker build --rm --no-cache --platform linux/amd64 -t milvus ./images/milvus
docker build --rm --no-cache --platform linux/amd64 -t jupyter ./images/jupyter
Dann können wir den beiden neu erstellten Images mit den folgenden Befehlen passende Tags hinzufügen:
docker login ${instance_name}.registry.snowflakecomputing.com -u ${user_name}
docker tag milvus ${instance_name}.registry.snowflakecomputing.com/milvus_demo/public/milvus_repo/milvus
docker tag jupyter ${instance_name}.registry.snowflakecomputing.com/milvus_demo/public/milvus_repo/jupyter
Schließlich können wir die Images mit den folgenden Befehlen zu SPCS pushen:
docker push ${instance_name}.registry.snowflakecomputing.com/milvus_demo/public/milvus_repo/milvus
docker push ${instance_name}.registry.snowflakecomputing.com/milvus_demo/public/milvus_repo/jupyter
Nachdem wir die Images zu SPCS gepusht haben, müssen wir nur noch zwei Computing-Dienste erstellen, einen für jedes Image, wie Sie in den folgenden Befehlen innerhalb der SnowSQL-Shell sehen können:
USE ROLE SYSADMIN;
CREATE COMPUTE POOL IF NOT EXISTS MILVUS_COMPUTE_POOL
MIN_NODES = 1
MAX_NODES = 1
INSTANCE_FAMILY = CPU_X64_S
AUTO_RESUME = true;
CREATE COMPUTE POOL IF NOT EXISTS JUPYTER_COMPUTE_POOL
MIN_NODES = 1
MAX_NODES = 1
INSTANCE_FAMILY = CPU_X64_S
AUTO_RESUME = true;
Innerhalb des Repos, das wir zuvor geklont haben, befindet sich ein Ordner namens „specs.“ In diesem Ordner befinden sich zwei YAML-Dateien, eine für jedes Image. Öffnen Sie jede YAML-Datei und ändern Sie ${org_name}-${acct_name} im Feld image entsprechend Ihrem eigenen Snowflake-Konto.
Laden Sie als Nächstes mit SnowSQL die geänderten YAML-Dateien mit den folgenden Befehlen hoch:
PUT file://${path/to/jupyter.yaml} @yaml_stage overwrite=true auto_compress=false;
PUT file://${path/to/milvus.yaml} @yaml_stage overwrite=true auto_compress=false;
Und schließlich können wir die Dienste für beide Images wie folgt erstellen:
USE ROLE SYSADMIN;
USE DATABASE MILVUS_DEMO;
USE SCHEMA PUBLIC;
CREATE SERVICE MILVUS
IN COMPUTE POOL MILVUS_COMPUTE_POOL
FROM @YAML_STAGE
SPEC='milvus.yaml'
MIN_INSTANCES=1
MAX_INSTANCES=1;
CREATE SERVICE JUPYTER
IN COMPUTE POOL JUPYTER_COMPUTE_POOL
FROM @YAML_STAGE
SPEC='jupyter.yaml'
MIN_INSTANCES=1
MAX_INSTANCES=1;
Wenn Sie jetzt den Befehl SHOW SERVICE eingeben, sollten Sie die folgende Ausgabe sehen:
SHOW SERVICES;
+---------+---------------+-------------+----------+----------------------+--------------------------------------------------------+-----------------
| name | database_name | schema_name | owner | compute_pool | dns_name | ......
|---------+---------------+-------------+----------+----------------------+--------------------------------------------------------+-----------------
| JUPYTER | MILVUS_DEMO | PUBLIC | SYSADMIN | JUPYTER_COMPUTE_POOL | jupyter.public.milvus-demo.snowflakecomputing.internal | ......
| MILVUS | MILVUS_DEMO | PUBLIC | SYSADMIN | MILVUS_COMPUTE_POOL | milvus.public.milvus-demo.snowflakecomputing.internal | ......
+---------+---------------+-------------+----------+----------------------+--------------------------------------------------------+-----------------
Jetzt sind wir bereit, die Milvus-Vektordatenbank auszuführen und unser Notebook innerhalb von Snowflake zu testen. Erteilen Sie zunächst der Rolle, die wir zuvor erstellt haben, die Berechtigung für den Zugriff auf die containerisierte App.
USE ROLE SECURITYADMIN;
GRANT USAGE ON SERVICE MILVUS_DEMO.PUBLIC.JUPYTER TO ROLE MILVUS_ROLE;
Überprüfen Sie als Nächstes den Endpunkt unseres Notebook-Containers innerhalb von Snowflake mit dem folgenden Befehl:
USE ROLE SYSADMIN;
SHOW ENDPOINTS IN SERVICE MILVUS_DEMO.PUBLIC.JUPYTER;
Jupyter-Endpunkt, wie in ingress_url angezeigt
Jupyter-Endpunkt, wie in ingress_url angezeigt
Wenn alles reibungslos läuft, sehen Sie als Ausgabe eine Spalte namens „ingress_url“. Öffnen Sie Ihren Browser, kopieren Sie diese „ingress_url“ und fügen Sie sie ein, und Sie sollten sehen, wie Jupyter hochfährt. Anschließend können Sie die Notebook-Datei im Container öffnen und jede Zelle im Notebook ganz normal ausführen.
Die zukünftige Landschaft von RAG
RAG ist heutzutage eine sehr beliebte Technik. Ihre aktuelle Anwendung ist jedoch noch lange nicht perfekt. Laut Jiang Chen gibt es mehrere Vorhersagen zur zukünftigen Nutzung und Verbesserung von RAG-Anwendungen.
Kontinuierliche Evaluierung und Beobachtbarkeit
Der Aufbau von RAG ist durch die Verfügbarkeit verschiedener Plattformen oder Bibliotheken, die den RAG-Entwicklungsprozess vereinfachen und abstrahieren, einfacher geworden. Beispielsweise können wir mithilfe von drei verschiedenen Plattformen in wenigen Minuten einen RAG-Prototyp erstellen: Milvus, LangChain und OpenAI.
Wir stehen jedoch oft vor Herausforderungen, wenn wir eine RAG-gestützte Anwendung vom Prototyp in die Produktion überführen. In der Produktion müssen unsere RAG-Systeme Millionen oder sogar Milliarden von Dokumenten verarbeiten, weshalb es entscheidend ist, die von unserem LLM erzeugte Antwortqualität kontinuierlich zu überwachen
Kontinuierliche Evaluierung des RAG-Systems
Kontinuierliche Evaluierung des RAG-Systems
Bevor wir Verbesserungen implementieren, um die Qualität unseres RAG zu steigern, ist es wichtig, einen systematischen Ansatz zur kontinuierlichen Evaluierung und Verbesserung zu etablieren.
Einige zentrale Elemente dieses systematischen Ansatzes sind:
Aufbau einer dedizierten Verbesserungsinfrastruktur: In dieser Infrastruktur können wir verschiedene Methoden implementieren, um die Qualität von RAG zu verbessern, und anschließend ihre Antworten mittels A/B-Testing vergleichen.
Planung eines Release-Zyklus: Sobald wir einen Ansatz gefunden haben, der die Qualität von RAG gemäß unserem Anwendungsfall verbessert, müssen wir planen, wie wir ihn veröffentlichen und in unser System integrieren, um den alten Ansatz zu ersetzen, ohne die Benutzererfahrung zu unterbrechen.
Implementierung eines Observability-Systems: Wir müssen außerdem ein System aufbauen, um die Leistung unseres RAG in der Produktion zu beobachten und seine Effektivität zu bestimmen. Wenn die Leistung unzureichend ist, können wir über die dedizierte Verbesserungsinfrastruktur Verbesserungen untersuchen und implementieren.
Multimodales RAG
Bislang haben wir RAG hauptsächlich in der Verarbeitung natürlicher Sprache eingesetzt. Das bedeutet, dass wir Text als Prompt oder Abfrage verwenden und die Antworten unseres LLM ebenfalls in Textform vorliegen.
Die RAG-Landschaft könnte sich jedoch in Zukunft mit der Einführung von multimodalem RAG verändern. Multimodales RAG ist durch den Aufstieg multimodaler Embedding-Modelle in den letzten Jahren möglich geworden. In den vergangenen Jahren hat die Forschung gezeigt, dass Transformers natürliche Sprache als Eingaben sowie andere Modalitäten wie Bilder und Töne verarbeiten können.
Vision Transformers (ViT) und DETR-Modelle haben gezeigt, dass Transformers als leistungsfähige Modelle für Bildklassifizierung und Objekterkennung eingesetzt werden können. Aufbauend auf ViT stellte OpenAI ein multimodales Modell namens CLIP vor, das die Ähnlichkeit zwischen zwei Eingaben aus unterschiedlichen Modalitäten berechnen kann: Text und Bild.
Die multimodalen Fähigkeiten, die diese Transformer-basierten Modelle zeigen, können als Grundlage für zukünftige multimodale RAG-Anwendungen dienen. In diesem System können wir eine Kombination aus Text und Bild als Abfrage verwenden, und das LLM generiert auf Basis unserer multimodalen Abfragen ein Bild.
Nehmen wir als Beispiel an, wir möchten, dass unser LLM ein Bild generiert, das einem bereitgestellten Abfragebild sehr ähnlich ist. Wir können unser Abfragebild mit einer Textbeschreibung anreichern, um die Art von Bildern, die unser LLM generieren soll, weiter feinzujustieren, wie Sie in der folgenden Visualisierung sehen können:
Multimodale RAG-Anwendung, Kombination aus Text- und Bildabfragen
Multimodale RAG-Anwendung, Kombination aus Text- und Bildabfragen
In der obigen Visualisierung haben wir unsere Embedding-Modelle gebeten, Bilder zurückzugeben, die dem Bild oben links ähneln, und wir haben einen Text-Prompt hinzugefügt, wie etwa "ein Bild eines Berges während der goldenen Stunde," neben dem Bild oben links. Die Ergebnisse sind die drei anderen Bilder, die auf Basis der multimodalen Abfrage generiert wurden.
Dieser multimodale Ansatz für RAG eröffnet neue Möglichkeiten für intuitivere und ausdrucksstärkere Informationssuche und -generierung, indem er die Stärken sowohl textueller als auch visueller Modalitäten kombiniert.
Gutes RAG entsteht aus guten Daten
Die Qualität unseres RAG-Systems hängt stark von der Datenqualität ab, die wir in unserer Datenbank haben. Wenn die von unserem RAG generierte Antwort nicht optimal ist, sollten wir daher nicht vorschnell zu dem Schluss kommen, dass das Modell verbessert werden muss. Zuerst müssen wir immer die Qualität unserer Daten überprüfen.
Wie Sie vielleicht bereits wissen, hängt die Antwortqualität von RAG von den Kontexten ab, die zusammen mit der Abfrage übergeben werden. Wenn unser LLM aus den bereitgestellten Kontexten keine passenden Antworten auf die Abfrage finden kann, ist es nicht überraschend, dass die von unserem RAG-System generierte Antwortqualität schlecht sein wird.
Bevor wir uns also dafür entscheiden, die Einbettungsmodelle und das LLM in unserem RAG-System zu verbessern, sollten wir immer die folgenden Fragen stellen:
Haben wir die richtigen Daten in unserer Datenbank?
Haben wir alle verfügbaren Daten aus den Datenquellen in unsere Datenbank übernommen?
Haben wir den richtigen Datenbereinigungsprozess implementiert, bevor wir die Daten an die Einbettungsmodelle übergeben?
Haben wir den passenden Chunking-Ansatz auf unsere Daten angewendet?
Haben wir die korrekten Methoden zur Datenvorverarbeitung (z. B. PDF-Parsing, OCR-Parsing) auf unsere Daten angewendet?
Die Behebung datenbezogener Probleme ist ein entscheidender erster Schritt zur Optimierung der Leistung einer RAG-gestützten Anwendung. Erst nachdem wir die Datenqualität überprüft haben, sollten wir in Betracht ziehen, die Einbettungsmodelle, das LLM oder andere Komponenten des RAG-Systems zu verfeinern.
Agents: Abfragerouting mit Unterabfragen
Derzeit ruft ein gängiges RAG-System relevante Kontexte für eine gegebene Abfrage aus Texten und Einbettungen ab, die in einer internen Datenbank gespeichert sind. Dieser Ansatz könnte sich jedoch weiterentwickeln, da der Kontext aus internen Datenbanken und externen Quellen, wie z. B. Websuchen, abgerufen werden könnte.
Visualisierung von Agents für Abfragerouting
Visualisierung von Agents für Abfragerouting
Die Forschung in diesem Bereich läuft noch, aber das Hinzufügen eines sogenannten „Agent“ innerhalb eines RAG-Systems könnte dabei helfen, die geeignete Kontextquelle für eine gegebene Abfrage zu bestimmen.
Beispielsweise kann der Agent bei einer Abfrage wie „Who started AI research?“ entscheiden, ob RAG zur Beantwortung dieser Frage benötigt wird oder nicht. Falls nicht, kann das System das LLM die Antwort auf die Abfrage direkt und ohne zusätzlichen Kontext generieren lassen.
Wenn RAG als notwendig erachtet wird, sollte der Agent die Quelle für den Kontext bestimmen, sei es eine interne Datenbank oder eine externe Quelle. Ein weiterer Ansatz besteht darin, dass der Agent Informationen aus verschiedenen Quellen zu einem einzigen, zusammengefassten Kontext aggregiert, der vom LLM verwendet werden kann, um eine passende Antwort zu generieren.
Fazit
Die leistungsstarke Fähigkeit von LLMs, menschenähnliche Textantworten zu generieren, hat die gesamte Landschaft der Informationsbeschaffung verändert. Die Einführung von RAG soll die Antwortgenauigkeit von LLMs verbessern, indem ihnen relevante Kontexte für eine gegebene Abfrage bereitgestellt werden. Diese Kontexte werden typischerweise als Einbettungen gespeichert, die in einer Vektordatenbank wie Milvus gespeichert werden müssen.
Als Open-Source-Vektordatenbank mit fortschrittlichen Vektorsuchfunktionen bietet Milvus eine nahtlose Integration mit beliebten AI-Toolkits wie Snowflake. Mit Snowflakes Snowpark Container Service (SPCS) können Benutzer Milvus nun innerhalb des Snowflake-Ökosystems ausführen, wodurch sie mithilfe der in Snowflake gespeicherten Daten einfach mit Milvus interagieren können.
Weiterlesen
Zilliz Cloud Now Available in AWS Asia Pacific (Seoul)
Zilliz Cloud is now available in AWS Seoul — low-latency vector search, in-country data residency, and one-step migration for Korean AI teams. 31 regions across 5 clouds.
Why Context Engineering Is Becoming the Full Stack of AI Agents
Discover how context engineering unifies prompts, RAG, and tools to build smarter, production-ready AI agents powered by Milvus.
DeepSeek Always Busy? Deploy It Locally with Milvus in Just 10 Minutes—No More Waiting!
Learn how to set up DeepSeek-R1 on your local machine using Ollama, AnythingLLM, and Milvus in just 10 minutes. Bypass busy servers and enhance AI responses with custom data.