Custom AI Agent mit Claude: RAG-Setup für Mittelstand — Schritt für Schritt

Off-the-shelf-AI scheitert im Mittelstand am Kontext. Ein eigener Claude-basierter Agent mit RAG-Setup ist machbar — wenn Vector-DB, Chunking, Embeddings, Eval und Deployment-Layer richtig aufgesetzt sind. Ein Praxis-Walkthrough.

Wann ein Custom Agent statt ChatGPT oder Off-the-shelf?

ChatGPT-Plus reicht für ungefähr 90 % aller AI-Use-Cases im Mittelstand. Wenn ein Mitarbeiter sich einfach von einer KI bei Mails oder Brainstorming helfen lassen will, ist das die richtige Antwort. Spare das Geld für etwas anderes.

Ein Custom Agent macht Sinn, wenn mindestens zwei dieser Bedingungen erfüllt sind:

• Domänenspezifisches Wissen: der Agent muss interne Dokumente kennen (Helpdocs, Verträge, Wikis, technische Specs), die kein Off-the-shelf-Modell trainiert hat.
• Konsistente Persona: der Agent ist Kunden-facing und muss in der Brand-Tonalität antworten, ohne Workflow-Drift.
• Actions nötig: der Agent soll nicht nur antworten, sondern Dinge tun — Tickets erstellen, Termine buchen, Daten abfragen.
• DSGVO-Constraints: Daten dürfen die EU nicht verlassen, Trainings-Opt-Out muss garantiert sein.
• Volume: über ~1.000 Anfragen pro Monat — sonst rechnet sich der Setup-Aufwand nicht.

Wenn nur eines davon zutrifft, sollte zuerst geprüft werden, ob Claude.ai Teams oder ChatGPT Enterprise mit einem guten System-Prompt nicht reicht.

RAG vs Fine-Tuning: warum RAG fast immer gewinnt

Es gibt zwei Wege, einem LLM Wissen mitzugeben: Retrieval-Augmented Generation (RAG) oder Fine-Tuning.

RAG bedeutet: bei jeder Anfrage werden relevante Dokument-Snippets aus einer Vector-DB geholt und als Kontext an das LLM mitgeschickt. Das Modell ist „state-less" — wenn die Doku sich ändert, ist die nächste Antwort sofort aktuell.

Fine-Tuning bedeutet: die Modellgewichte werden auf eigene Daten angepasst. Das Wissen ist „eingebrannt", aber jede Doku-Änderung erfordert ein Re-Training.

Für 95 % der Mittelstands-Use-Cases ist RAG die richtige Wahl:

• Doku ändert sich ständig (neue Produkte, neue Policies) → RAG bleibt aktuell, Fine-Tuning veraltet
• Erklärbarkeit kritisch → RAG kann Quellen zitieren, Fine-Tuning halluziniert begründungslos
• Kosten → RAG kostet einmalig pro Embedding-Build (~50–500 EUR), Fine-Tuning startet bei mehreren tausend EUR und muss alle paar Wochen wiederholt werden

Fine-Tuning ist sinnvoll, wenn der Style des Outputs sehr spezifisch sein muss (z.B. Brand-Voice in Marketing-Content) — aber selbst da reicht oft ein Brand-Voice-Profile im System-Prompt.

Vector-DB-Optionen: pgvector vs Pinecone vs Weaviate

Die Vector-DB ist das Herz des RAG-Setups. Drei Optionen, die wir produktiv betreiben:

pgvector (Postgres-Extension)

Unser Default. Läuft als Extension in jedem Postgres (auch in Supabase eingebaut). Single-Tenant, EU-hostbar, integriert mit allen anderen Tabellen. Performance bis ~1 Mio Vektoren absolut ausreichend.

Vorteile: keine zusätzliche Infrastruktur, ein-DB-für-alles, einfaches Backup, EU-Hosting. Nachteile: bei sehr großen Datenmengen (10+ Mio Vektoren) wird Index-Tuning kritisch.

Pinecone

Managed Vector-DB, sehr schnell, sehr skalierbar. Pricing pro Index ab 70 USD/Monat. Hosting in USA — DSGVO-Pfad existiert, ist aber aufwendiger zu argumentieren.

Sinnvoll bei: 5+ Mio Vektoren, Multi-Tenant-Setups, Performance-kritische Echtzeit-Anwendungen. Nicht sinnvoll bei: deutschem Mittelstand mit moderaten Volumen.

Weaviate

Open Source, self-hostbar, mehr Features als pgvector (hybrid search out-of-the-box, GraphQL-Interface). Mehr Setup-Aufwand.

Sinnvoll bei: hybrider Suche (Vector + Keyword), sehr großen Datenmengen, eigenem Ops-Team. Für Boutique-Projekte oft overkill.

Default-Empfehlung: pgvector in Supabase EU-Region. Erst wechseln, wenn man konkrete Performance-Probleme hat.

Document-Ingestion-Pipeline

Bevor Vektoren in der DB landen, müssen Dokumente in eine gemeinsame Form gebracht werden. Die Ingestion-Pipeline besteht aus mehreren Stufen:

1. Source-Connector

Pro Datenquelle ein Connector. Typische Quellen:

• Notion → Notion-API, polling alle 6 Stunden
• Google Drive → Drive-API, Webhook für Echtzeit-Updates
• Confluence / SharePoint → REST-API mit OAuth
• Helpdesk (Intercom, Zendesk) → API-Sync für FAQ-Artikel
• Custom-Wikis → meist eigener Scraper

2. Konvertierung in plain text + Metadaten

Egal welche Quelle: das Output ist ein Tupel aus (text, metadata). Metadaten enthalten Source-ID, URL, Author, letzte Änderung, Tags. Diese Metadaten sind später kritisch für Filter (z.B. „nur Doks vom Produkt-Team").

Für PDFs nutzen wir pdfplumber oder pymupdf. Bei tabellen-lastigen Dokumenten Claude-Vision: PDF-Seite als Bild an Claude, „extrahiere strukturiert" — funktioniert bei komplexen Layouts besser als Text-Extraction.

3. Dedup & Filter

Doppelte Dokumente werden über Hash-Fingerprint dedupliziert. Drafts, archivierte Pages, Templates werden über Metadata-Filter ausgeschlossen.

4. Chunking

Siehe nächster Abschnitt — der wichtigste Schritt.

Chunking-Strategien: der unterschätzte Hebel

Wer einfach ein 50-Seiten-PDF in 500-Token-Stücke schneidet und in die Vector-DB packt, hat ein schlechtes RAG-Setup. Chunking ist der Schritt, der oft den größten Performance-Unterschied macht.

Was schlecht funktioniert

• Fixed-Size-Chunks (z.B. „jeder Chunk = 500 Tokens"): zerreißt Sätze und Argumente in der Mitte.
• Pro-Dokument-Embedding: zu grob, der Agent bekommt zu viel irrelevanten Kontext.

Was wir tun

Semantic Chunking + Hierarchical Storage:

• Strukturierte Dokumente (Markdown, Confluence) werden entlang von Überschriften gechunked. Jede H2-Section = ein Chunk. Falls Section > 1000 Tokens → entlang H3 weiter splitten.
• Pro Chunk wird zusätzlich der Header-Pfad gespeichert (z.B. „Produkt-Doku > API-Reference > Authentication") — bei Retrieval kann der Agent so verstehen, wo der Snippet herkommt.
• Vor dem Embedding wird jedem Chunk ein Contextual Summary vorangestellt: 1–2 Sätze, die Claude vorab generiert, die den Chunk in den Doku-Kontext einordnen. Das ist der Anthropic-„Contextual Retrieval"-Trick und steigert die Recall-Rate um 35–50 %.

Für unstrukturierte Texte (z.B. Slack-Threads, Support-Transkripte) nutzen wir Recursive Character Splitter mit Overlap (200 Tokens), aber wir bevorzugen es, vorher mit Claude eine Strukturierung zu erzwingen — Output ist dann saubere Doku.

Embedding-Models: text-embedding-3-large vs Voyage vs Open Source

Aktueller Stand (Mai 2026) für deutsche Texte:

• OpenAI text-embedding-3-large (3072 Dimensionen): unser Default. Sehr gute multilinguale Performance, stabile API, Kosten ca. 0,13 USD pro 1 Mio Tokens.
• Voyage AI voyage-3: bessere Recall-Rates in akademischen Benchmarks, aber Hosting US-only. Wir nutzen es nur, wenn DSGVO-Constraints nicht gelten.
• Cohere embed-multilingual-v3: gute Performance, EU-Hosting verfügbar.
• BGE-M3 (Open Source): läuft lokal auf eigenem GPU-Server. Performance vergleichbar zu OpenAI, aber Setup-Overhead. Nur sinnvoll bei sehr hohen Volumina (10M+ Tokens/Monat).

Wichtig: das Embedding-Model darf später nicht gewechselt werden, ohne die ganze Vector-DB neu zu bauen. Embeddings unterschiedlicher Modelle sind nicht vergleichbar. Wir bauen einen Migrations-Pfad ein (Re-Embedding-Job läuft im Hintergrund), wenn ein Wechsel nötig wird.

Function-Calling: vom Q&A-Bot zum Agent

Ein RAG-Setup, das nur Fragen beantwortet, ist ein Knowledge-Base-Search mit netter UI. Ein echter Agent tut Dinge.

Wir definieren Tools, die Claude über Function-Calling aufrufen kann:

• search_docs(query, filters) — die RAG-Retrieval-Funktion. Claude entscheidet selbst, wann gesucht wird.
• create_ticket(title, body, priority) — wenn Claude eine Frage nicht beantworten kann, eröffnet er ein Ticket im Helpdesk.
• lookup_customer(email) — Kontext-Holen aus dem CRM.
• schedule_callback(time, topic) — Termin-Buchung via Calendly-API.
• escalate_to_human(reason) — explizite Eskalation, mit Begründung.

Claude entscheidet pro Turn selbst, welche Tools genutzt werden. Wir geben ihm System-Prompt-Regeln mit, wann er eskaliert (z.B. „bei finanziellen Fragen immer eskalieren", „bei Beschwerden niemals selbst Refund anbieten").

Der Prompt enthält außerdem die ersten 3–5 Retrieval-Ergebnisse von vornherein, damit Claude nicht für jede Anfrage einen Tool-Call macht — Latenz-Optimierung.

Eval-Setup: warum es kritisch ist

Hier scheitern 90 % der RAG-Projekte: kein Eval-Setup. Das Resultat: der Agent geht live, scheint zu funktionieren, beantwortet aber 25 % der Fragen falsch — und niemand merkt's, weil keiner systematisch testet.

Was wir bauen:

1. Eval-Dataset

200–500 echte Beispiel-Fragen aus historischen Support-Tickets, Sales-Calls, internen Slack-Threads. Pro Frage: erwartete Antwort, erwartete Quellen, erwartete Aktionen. Aufbau dauert 2–3 Tage und ist die wichtigste Investition.

2. Automatisierte Eval-Runs

Bei jedem Release läuft das Eval-Dataset gegen den Agent. Auswertung:

• Retrieval-Quality: Wurden die erwarteten Quellen gefunden? (Precision & Recall)
• Answer-Quality: Ist die Antwort korrekt? (Bewertet via Claude-as-Judge mit Rubric)
• Tool-Use: Wurden die richtigen Tools in der richtigen Reihenfolge aufgerufen?
• Hallucination-Rate: Hat der Agent Quellen erfunden? (Cross-Check gegen Vector-DB)

3. Regression-Tests

Jede Code-Änderung am System-Prompt, Chunking, oder Modell-Wahl wird gegen das Eval-Set gefahren. Wenn die Hallucination-Rate steigt, blockiert das den Release.

Ohne Eval-Setup ist jeder Production-Agent ein Glücksspiel. Mit Eval-Setup ist er ein wartbares Software-Produkt.

Production-Deployment: was zu beachten ist

Letzte Schicht: Hosting und Deployment.

Backend

Wir hosten typischerweise auf Hetzner-VPS (Falkenstein) oder Render (Frankfurt), beide EU-Region. FastAPI als Framework, Supabase als DB (Auth + pgvector + normale Tabellen), Sentry für Error-Tracking.

Frontend

Je nach Use-Case ein Chat-Widget (custom oder Crisp/Intercom-Erweiterung), eine Slack-App oder ein Standalone-Web-App. Streaming-Responses sind heute Standard — Claude streamt Tokens, der UI rendert progressiv.

Rate-Limiting und Cost-Control

Anthropic-API hat keine Standard-Limits, aber Kosten können entgleiten. Wir verdrahten:

• Per-User-Rate-Limit (z.B. 50 Messages/Tag)
• Per-Conversation-Token-Limit (max 50k Input-Tokens)
• Daily-Spend-Alert (Slack-Notification bei > X EUR pro Tag)
• Caching für identische Anfragen (Anthropic-Prompt-Caching spart 90 % der Kosten bei wiederkehrenden System-Prompts)

Monitoring

Pro Conversation loggen wir: User-Input, Retrieved Chunks, Tool-Calls, Final Output, Latenz, Token-Verbrauch, User-Feedback (Daumen hoch/runter). Diese Logs sind die Basis für kontinuierliches Improvement.

DSGVO bei EU-Hosting: die unbequeme Realität

Anthropic hat ein Frankfurt-Hosting für API-Calls. Das ist die einfachste DSGVO-Story — Daten verlassen die EU nicht, AVV ist verfügbar, Auftrags-Verarbeitung sauber dokumentierbar.

Aber: EU-Hosting heißt nicht „kein Sub-Processor in den USA". Anthropic nutzt AWS, das wiederum US-Mutterunternehmen hat. Schrems-II-Argumentation: TADPF-Adäquanzbeschluss reicht, AWS Frankfurt ist in der Praxis akzeptiert. Die meisten Datenschutzbeauftragten geben hier grünes Licht.

Was zusätzlich kritisch ist:

• Training-Opt-Out: Anthropic trainiert API-Calls per default nicht für Modell-Improvement. Bestätigt im Vertrag, dokumentieren.
• Retention: API-Logs werden 30 Tage gespeichert. Für sensible Use-Cases optional auf 0 reduzierbar (Enterprise-Plan).
• Eigene Daten: Vector-DB und Conversation-Logs laufen bei uns immer in der Kontroll-EU-Infrastruktur (Supabase EU oder eigener Hetzner-Postgres).

Mit dieser Architektur ist der DSGVO-Compliance-Weg klar argumentierbar. Wir haben das mit mehreren Datenschutzbeauftragten von Kunden geklärt — keiner hat das Setup zurückgewiesen, sobald die Architektur transparent erklärt war.

Der Aufwand ist real: AVV mit Anthropic einholen, AVV mit Hosting-Provider, VVT-Eintrag, Risiko-Analyse, ggf. DSFA. Für Mittelständler in regulierten Branchen (Health, Finance) sind 2–4 Wochen interner Compliance-Aufwand realistisch — aber durchführbar.