Wie man einen hybriden LLM‑RAG‑Agenten in einer serverlosen Architektur erstellt

In den letzten Jahren haben sich Sprachmodelle (LLM) zu einer Grundlage moderner konversationaler Schnittstellen entwickelt. Die Modelle selbst können Text generieren, aber ihr Nutzen steigt, wenn wir sie mit externen Wissensquellen (RAG) und Werkzeugaufruf‑Mechanismen kombinieren. In diesem Artikel beschreiben wir, wie man einen hybriden LLM‑RAG‑Agent in einer serverlosen Umgebung entwirft, um niedrige Betriebskosten, akzeptable Latenz und die Kontrolle über die Datensicherheit zu erreichen.

Warum ein hybrider LLM‑Agent?

Der traditionelle Ansatz besteht darin, ein einziges großes generatives Modell zu verwenden, das alle Fragen eigenständig beantwortet. Ein solches System ist einfach, weist jedoch wesentliche Nachteile auf: hohe Tokenisierungskosten, Halluzinationsrisiko und fehlender Zugriff auf aktuelle, domänenspezifische Daten. Der hybride Agent kombiniert zwei Komponenten – LLM als „Gehirn“ und die Retrieval‑Augmented‑Generation‑Schicht (RAG) als „Bibliothek“. Dadurch kann der Agent auf die neuesten Dokumente zurückgreifen und gleichzeitig die leistungsstarken generativen Fähigkeiten des Modells nutzen.

Grundlegende serverlose Architektur

Serverless, konkret Dienste wie AWS Lambda, Azure Functions oder Google Cloud Functions, ermöglichen das Ausführen von Code als Reaktion auf Ereignisse ohne Serververwaltung. Für einen hybriden LLM‑Agent sind die wichtigsten Elemente:

• Die handler-Funktion, die Anfragen vom Client entgegennimmt (z. B. HTTP API Gateway).
• Die RAG‑Schicht – meist eine Vektor‑Suchmaschine (z. B. FAISS, Milvus, OpenSearch), die als separate Funktion oder Container betrieben wird.
• Das Werkzeugaufruf‑Modul – z. B. ein SDK für API‑Aufrufe, Datenbanken oder Queue‑Systeme.

All diese Komponenten können in einem einzigen Lambda‑Paket (für kleine Projekte) oder als separate Mikro‑Services, verbunden über Queues (z. B. SQS), je nach Skalierbarkeitsanforderungen, betrieben werden.

Schritte zum Aufbau eines LLM‑Agents mit RAG in AWS Lambda

1. Erstellung des Vektor‑Indexes. Domänenspezifische Dokumente werden mit einem Embedding‑Modell (z. B. sentence‑transformers) in Vektoren umgewandelt. Der Vektor‑Index wird in einem Service wie Amazon OpenSearch Service oder in einem FAISS‑Container, der als Lambda‑Layer läuft, gespeichert.

2. Implementierung der Retrieval‑Funktion. Die Funktion retrieve(query) nimmt eine Anfrage entgegen, wandelt sie in einen Vektor um und liefert die top‑k ähnlichsten Abschnitte zurück. Beispielcode:

import numpy as np
from sentence_transformers import SentenceTransformer
from faiss import IndexFlatL2

model = SentenceTransformer('all-MiniLM-L6-v2')
index = IndexFlatL2(768)

def retrieve(query, k=5):
    q_vec = model.encode([query])
    distances, ids = index.search(q_vec, k)
    return [documents[i] for i in ids[0]]

3. Werkzeugaufrufe. Nachdem die Abschnitte aus RAG erhalten wurden, entscheidet der Agent, ob ein externer API‑Aufruf (z. B. ein Buchungssystem) nötig ist. Diese Entscheidung trifft das LLM, das eine Anweisung im JSON‑Format generiert. Anschließend parst unser Code diese Anweisung und ruft das entsprechende SDK auf.

4. Integration mit dem LLM. Die Client‑Anfrage, die Retrieval‑Ergebnisse und mögliche Werkzeug‑Ergebnisse werden zu einer Systemnachricht zusammengefasst und an das Modell (z. B. OpenAI GPT‑3.5‑turbo oder einen anderen verfügbaren Endpunkt) übergeben. Das Modell liefert die finale Antwort, die wir an den Nutzer zurückgeben.

Werkzeugaufrufe in LLM‑Agents

Der zentrale Mechanismus ist das sogenannte tool calling. Das LLM kann eine Struktur wie folgt erzeugen:

{
  "action": "check_availability",
  "parameters": {"date": "2024-12-01", "room_type": "deluxe"}
}

Unsere Anwendungsschicht interpretiert diese Struktur und führt das passende API aus. Nach Erhalt des Ergebnisses (z. B. Zimmerverfügbarkeit) übergeben wir es erneut dem Modell, damit es die Antwort finalisiert. Dieser Zyklus „Anfrage‑Retrieval‑Tool‑Response‑LLM“ eliminiert die Notwendigkeit, ein dediziertes Modell für spezifische Aufgaben zu trainieren.

Kosten und Latenz hybrider LLM‑Agents

Serverless wird nach Anzahl der Aufrufe und genutztem Speicher/CPU abgerechnet. Für einen LLM‑Agent ist das teuerste Element in der Regel der Aufruf des generativen Modells – besonders bei Nutzung eines externen Anbieters. RAG hilft, die Token‑Anzahl zu reduzieren, da wir dem Modell nur die relevantesten Abschnitte und nicht das gesamte Dokument übermitteln.

• Token‑Kosten – wir reduzieren sie, indem wir top‑k = 3‑5 Abschnitte und kurze Zusammenfassungen verwenden.
• Latenz – Lambda‑Funktionen haben einen Kaltstart (bis zu einigen Sekunden). Gute Praxis: Funktionen „warm“ halten mittels provisioned concurrency oder Retrieval und LLM in separate Funktionen aufteilen, sodass sie parallel laufen können.
• Datenschutz – sensible Informationen sollten im VPC verbleiben, und der Zugriff auf externe APIs sollte auf kurzlebige Tokens beschränkt werden.

Typische Fehler und Kompromisse

1. Überlastung von LLMs mit großen RAG-Fragmenten – erhöht die Kosten und das Risiko von Halluzinationen. Lösung: BM25‑Ranking vor der Vektorsuche einsetzen, um die Anzahl der Kandidaten zu begrenzen.

2. Zu wenig Speicher in Lambda – Vektorindizes wachsen schnell. Option: Index in einen dedizierten Dienst (OpenSearch) verschieben und über HTTP aufrufen.

3. Fehlerhafte Fehlerbehandlung bei Tool‑Aufrufen – LLM kann ungültiges JSON erzeugen. Implementiere Schema‑Validierung und Fallback auf manuelle Antworten.

„Ein hybrider LLM‑Agent ist keine Magie, sondern die bewusste Kombination von drei einfachen Komponenten – Modell, Speicher und Tools. Wenn jede davon gut gestaltet ist, sinken die Kosten und die Antwortqualität steigt.“

Praktische Checkliste für die Implementierung

• ✅ Definiere den Umfang der Dokumentation, die RAG unterstützen soll.
• ✅ Wähle ein Embedding‑Modell und erstelle den Vektor‑Index.
• ✅ Erstelle eine Retrieval‑Funktion in Lambda oder als separaten Service.
• ✅ Entwerfe das Kommunikationsschema für Tool‑Calling (JSON + Schema‑Validierung).
• ✅ Konfiguriere den Zugriff auf das LLM (API‑Key, VPC, Throttling).
• ✅ Teste die Latenz: Messung von Retrieval‑Zeit + LLM + Tool‑Call.
• ✅ Überwache Token‑Kosten und Lambda‑Aufrufe.

Zusammenfassend ist ein hybrider LLM‑RAG‑Agent in einer serverlosen Umgebung ein praktischer Weg, intelligente Produkte mit kontrollierten Kosten und akzeptabler Reaktionszeit zu bauen. Wenn du möchtest, dass dein Team von unserem Know‑how bei der Gestaltung einer solchen Architektur profitiert, kontaktiere Coderia.it – wir helfen dir, deine Idee in ein funktionierendes System zu verwandeln.