Ihr produktives RAG ist wegen Index-Wildwuchs langsam: wie Sie Code, Protokolle, PDFs und CSVs mit einer lokalen MCP-Suchschicht vereinheitlichen

von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau

Ich bin Denis Shokhirev, Agentic AI Systems Architect in Freiburg im Breisgau, Germany, und ich liefere bei DennisCraft AI Studio produktive KI-Systeme auf Basis von Claude, Supabase, n8n, Doppler und selbst betriebenem Postgres. Der häufigste Grund, warum ein RAG-System im Produktivbetrieb langsam und schwer erklärbar wird, ist aus meiner Sicht nicht das Modell. Es ist Index-Wildwuchs: Code liegt in einer Suche, Protokolle in einer zweiten, PDFs in einer dritten Verarbeitung, CSV-Dateien in einem separaten ETL-Pfad.

Im Prototyp wirkt das ordentlich. Jede Datenart bekommt ihre eigene Behandlung. Im Produktivbetrieb entsteht dadurch ein anderes Problem: Der Agent muss raten, wo die entscheidende Information liegt. Genau dort steigen Latenz, Betriebskosten und Prüfaufwand. In regulierten Umgebungen ist das auch aus Sicht von DSGVO, ISO 27001 und dem EU AI Act relevant, weil Herkunft, Zugriff und Begründung einer Antwort sauber nachvollziehbar sein müssen.

Warum mehrere Indizes RAG im Betrieb ausbremsen

Fachanwender stellen keine nach Dateitypen sortierten Fragen. Sie fragen, warum eine Rechnung falsch verarbeitet wurde, warum ein Freigabeschritt übersprungen wurde oder welche Regel zu einer Entscheidung geführt hat. Die Antwort verteilt sich meist über 3 bis 4 Quellen gleichzeitig: Quellcode, Laufzeitprotokolle, PDF-Dokumente und tabellarische Daten.

Wenn jede Quelle ihren eigenen Suchpfad hat, trifft das Modell Routing-Entscheidungen, die Sie später erklären müssen. Ein Pfad sucht semantisch, ein anderer streng nach Stichworten, ein dritter liefert nur Absätze aus Dokumenten, ein vierter einzelne Zeilen aus CSV-Dateien. Das Ergebnis sind mehr Werkzeugaufrufe, mehr Token-Verbrauch und vor allem uneinheitliche Trefferlisten.

Anthropic empfiehlt in der Dokumentation zur Werkzeugnutzung klare Werkzeuge mit eindeutigem Vertrag statt überlappender Fähigkeiten, 2024, docs.anthropic.com. Diese Empfehlung deckt sich mit meiner Erfahrung im Produktivbetrieb: Ein einziges Suchwerkzeug mit stabilem Ein- und Ausgabeformat ist einfacher zu testen, einfacher zu protokollieren und einfacher gegenüber Revision, Datenschutz und Informationssicherheit zu vertreten.

Was ich mit einer lokalen MCP-Suchschicht meine

Ich meine kein neues Produkt, sondern ein Architekturprinzip. Das Modell erhält genau ein lokales Suchwerkzeug, typischerweise über MCP bereitgestellt. Dieses Werkzeug nimmt eine Anfrage wie search(query, source_types, limit) entgegen und verteilt sie intern auf Code, Protokolle, PDFs und CSVs. Die interne Komplexität bleibt verborgen.

Lokal ist dieser Ansatz aus 2 Gründen sinnvoll. Erstens sinkt die Latenz, wenn das Werkzeug nahe an Postgres, Dateispeicher und Protokollquellen arbeitet. Zweitens ist die Datenführung klarer. In DACH-Projekten mit sensiblen Geschäftsprozessen ist es oft günstiger, weniger externe Stationen in der Antwortkette zu haben. Das passt besser zu BSI-Grundschutz, ISO 27001 und den Nachweispflichten, die mit dem EU AI Act und NIS2 in vielen Organisationen stärker in den Vordergrund rücken.

Ein einfacher Suchvertrag

from typing import List, Optional
from pydantic import BaseModel

class SearchRequest(BaseModel):
    query: str
    source_types: Optional[List[str]] = None
    limit: int = 8

class SearchHit(BaseModel):
    source_type: str
    uri: str
    title: str
    snippet: str
    score: float

def search_local(req: SearchRequest) -> List[SearchHit]:
    types = req.source_types or ["code", "logs", "pdf", "csv"]
    hits = []
    if "code" in types:
        hits += search_code(req.query, req.limit)
    if "logs" in types:
        hits += search_logs(req.query, req.limit)
    if "pdf" in types:
        hits += search_pdf(req.query, req.limit)
    if "csv" in types:
        hits += search_csv(req.query, req.limit)
    return sorted(hits, key=lambda h: h.score, reverse=True)[:req.limit]

Wichtig ist nicht die Programmiersprache, sondern das einheitliche Rückgabeformat. Sobald Codeausschnitte, Protokolleinträge, Dokumentabsätze und Tabellenzeilen dieselbe Trefferstruktur besitzen, wird der nächste Schritt des Agenten deutlich stabiler.

Wie ich die 4 Quelltypen behandle

Code

Beim Code beginne ich mit repository-orientierter Zerlegung: Funktionen, Klassen, Konfigurationsdateien und ausgewählte Dokumentation. Vor der Aufnahme in die Suchschicht prüfe ich den Bestand in der Regel mit semgrep, bandit und gitleaks. So gelangen weniger Geheimnisse und weniger riskante Muster in den Kontext des Modells. OWASP führt Prompt Injection und Offenlegung sensibler Informationen in den OWASP Top 10 for LLM Applications, 2025, ausdrücklich als Risiken auf, genai.owasp.org.

Protokolle

Protokolle sind für die Ursachenanalyse oft die wertvollste Quelle, aber nur mit sauberer Struktur. Ich behandle Zeitstempel, Dienst, Schweregrad, correlation_id und Nachricht als Pflichtfelder. Damit kann der Agent nicht nur raten, sondern konkrete Laufzeitbelege für einen Fehler oder eine Entscheidung anführen.

PDFs

Bei PDFs ist Nüchternheit hilfreich. In Unternehmen sind das Verträge, Spezifikationen, Betriebsanweisungen oder Richtlinien. Ich speichere extrahierten Text, Seitenzahl, Überschrift falls vorhanden und eine Prüfsumme der Datei. Die Prüfsumme verhindert, dass ein Agent nach einer stillen Aktualisierung weiterhin aus einer alten Version zitiert.

CSV-Dateien

CSV-Dateien behandle ich nicht als bloße Textblöcke. Ich speichere Dateiname, Zeilennummer, Spalten und eine kompakte Textdarstellung der Zeile. So kann dieselbe Anfrage sowohl den konkreten Datensatz als auch die erläuternde Dokumentation zurückgeben.

python ingest_code.py --repo /srv/app --out postgres
python ingest_logs.py --input /var/log/app.jsonl --out postgres
python ingest_pdf.py --input /srv/docs --out postgres
python ingest_csv.py --input /srv/data --out postgres

psql "$DATABASE_URL" -c "create index if not exists idx_docs_type on docs(source_type);"
psql "$DATABASE_URL" -c "create index if not exists idx_docs_uri on docs(uri);"
psql "$DATABASE_URL" -c "analyze docs;"

Wo der praktische Gewinn entsteht

Der erste Gewinn ist geringere Latenz. Statt mehrere Suchwerkzeuge nacheinander aufzurufen und anschließend 4 Rangfolgen zusammenzuführen, geschieht diese Arbeit einmal innerhalb der lokalen Suchschicht. Der zweite Gewinn ist Nachvollziehbarkeit. Sie können Suchanfrage, Filter, Treffer und Antwort in einer Spur protokollieren. Der dritte Gewinn ist Zugriffssteuerung. Ein einziges lokales Suchwerkzeug nach Pfaden, Tabellen oder Dokumentarten zu beschränken, ist einfacher als dieselben Regeln in mehreren Diensten konsistent zu halten.

Auch das OpenAI Cookbook zeigt in seinen Beispielen zu Retrieval und Werkzeugnutzung, 2024, den Wert klarer Schnittstellen zwischen Modell und externem System, cookbook.openai.com. Im Produktivbetrieb gilt das noch stärker: Jede zusätzliche Werkzeugentscheidung vergrößert die Fehlerfläche.

tools:
  - name: local_search
    description: Search code, logs, pdf and csv from local sources
    input_schema:
      type: object
      properties:
        query: { type: string }
        source_types:
          type: array
          items: { type: string }
        limit: { type: integer, default: 8 }
      required: [query]

Was ich vermeiden würde

Ich würde nicht mit 4 unterschiedlichen Vektorsuchen beginnen, bevor ein stabiler Suchvertrag existiert. Ich würde das Modell nicht zwischen code_search, pdf_search, csv_search und logs_search wählen lassen, wenn es auch ein einziges Werkzeug tun kann. Ich würde Metadaten und Inhaltsobjekte nicht ohne dauerhafte Kennung auf mehrere Speicher verteilen. Und ich würde kein Repository in eine Suchschicht übernehmen, ohne vorher auf Geheimnisse zu prüfen.

FAQ

Brauche ich MCP zwingend für diesen Ansatz?

Nein. Entscheidend ist der einheitliche Suchvertrag. MCP ist ein nützlicher Standard, um diesen Vertrag einem Agenten bereitzustellen, aber nicht die Voraussetzung für das Architekturprinzip.

Muss jede Quelle Vektorsuche verwenden?

Nein. Gerade Protokolle und CSV-Dateien profitieren oft stärker von Filtern auf Metadaten und exakten Treffern. Ein gemischtes Verfahren ist im Betrieb häufig sinnvoller.

Reicht Postgres als technische Basis aus?

Für viele B2B-Anwendungen ja. Postgres deckt Metadaten, Prüfbarkeit, Teile der Suche und Zugriffskontrolle oft ausreichend ab, wenn das Schema diszipliniert aufgebaut ist.

Wie hilft das bei Compliance und Sicherheit?

Eine zentrale Suchschicht vereinfacht Protokollierung, Zugriffssteuerung und Herkunftsnachweise. Das ist für DSGVO, ISO 27001, BSI-Grundschutz und interne Revision deutlich günstiger als verteilte Ad-hoc-Suchen.

Wann sind getrennte Indizes trotzdem sinnvoll?

Wenn sich Aufbewahrungsfristen, Rechte oder Lastprofile sehr stark unterscheiden. Selbst dann bevorzuge ich nach außen weiterhin ein einziges Suchwerkzeug für das Modell.

Wo verlieren Sie in Ihrem produktiven RAG derzeit am meisten Zeit: bei getrennten Suchpfaden, bei uneinheitlichen Metadaten oder bei der Begründung von Antworten gegenüber Fachbereich, Revision und Kunden? Ich würde das gern anhand realer Systeme hören.

I run a free 30-min stack audit for DACH founders building AI in regulated markets. DM me on LinkedIn or write to @ger_dennis_ai.