RAG ist kein Magic-Trick — was wirklich funktioniert

Wenn man die ersten 15 Minuten in einem RAG-Demo verbringt, sieht alles wunderschön aus. Die KI antwortet treffsicher auf jede Frage zu deiner Dokumentation, zitiert Quellen, formuliert höflich. Drei Wochen später wundert man sich, warum genau diese KI plötzlich behauptet, dass Vertrag X bis 2031 läuft (in Wahrheit: 2024 ausgelaufen).

Das Problem ist fast nie das Modell. Es ist die Retrieval-Schicht.

Drei Anti-Patterns, die wir immer wieder sehen

1. Vector-Search als Allheilmittel

Vektor-Embeddings sind großartig für semantische Ähnlichkeit. Sie sind katastrophal, wenn du nach präzisen Werten suchst (Preise, Datumsangaben, Vertragsnummern). Die Cosine-Similarity zwischen „Vertrag läuft bis 2024” und „Vertrag läuft bis 2031” ist erschreckend hoch.

Lösung: Hybrid-Retrieval. Erst BM25 (klassische Keyword-Suche) für strukturierte Fakten, dann Vektor-Search für die unscharfen Fragen.

2. Ein Index für alles

Wenn dein RAG-System Mandanten bedient, brauchen die Mandanten getrennte Vektor-Räume. Sonst leakt Kunde A’s Wissen in Kunde B’s Antwort. Bei uns ist das in nexxus von Haus aus mandantengetrennt (über pgvector mit Tenant-ID als Filter-Constraint im Index).

3. Keine Eval-Pipeline

90 % der Teams haben keinen automatisierten Test, der nach jedem Modell-/Prompt-Update prüft, ob die Antworten noch stimmen. Das fällt auf, wenn der erste echte Kunde anruft.

Was wir empfehlen

• Klein anfangen, scharf evaluieren. Lieber 50 perfekt funktionierende Antworten als 5.000 mittelmäßige.
• Quellenangaben sind Pflicht. Wenn die KI sagt „X gilt bis 2024”, muss daneben stehen, aus welchem Dokument.
• Frische Daten = Frische Antworten. Ein RAG-System, das nicht regelmäßig re-indiziert, lügt höflich.

Wenn du gerade selbst an RAG arbeitest und das wie eine Bestandsaufnahme deiner letzten drei Wochen klingt — schreib uns. Wir sehen das öfter, als wir möchten.