Der blinde Fleck des RAG-Architekten: Vektorbanken als Black Boxes behandeln

Wir wiederholen einen Fehler aus den 1990er Jahren mit klassischen Datenbanken. Und er wird jemanden einen Produktionsausfall kosten.

Vektorbanken sind gute Technologie. Aber ich sehe immer wieder, wie Teams sie einsetzen, als wären sie etwas ganz anderes — mehr wie eine mathematische Operation, nicht Infrastruktur. Sie würden keine SQL-Datenbank live nehmen und hoffen, dass sie einfach funktioniert. Aber genau das passiert mit Vektorsuche gerade.

Der Ausfallmechanismus ist einfach. HNSW — Hierarchical Navigable Small World, Standard in Vektorbanken — läuft gut bei 100K Dokumenten. Schnelle, präzise Suche. Teams deployen es. Bei 1M Dokumenten fällt der Recall. Bei 10M ziehen Sie Dokumente, die absolut nichts mit der Anfrage zu tun haben. Ihr LLM antwortet auf Müll und klingt dabei sicher.

Das Gefährliche: das Monitoring merkt nichts. Latenz bleibt grün. Keine Fehler, keine Exceptions. System sieht gesund aus. Gibt nur falsche Ergebnisse zurück.

Ich habe ein Team beobachtet. Drei Wochen damit verbracht. Das RAG-System halluzinierte. Sie hatten gute Instrumentation: Latenz, Durchsatz, Kosten. Aber niemand maß, ob die Suche eigentlich funktioniert. Als sie das endlich taten — LLM-Judge gegen Ground Truth — fiel Recall von 0.82 auf 0.54 in sechs Monaten. Latenz identisch. Halb so relevant.

Das ist nicht das Problem der Vektorbank. Das ist Architektur. Teams haben Design-Arbeit übersprungen, die klassische Datenbanken brauchbar macht.

Als Datenbanken Production-Infrastruktur wurden, lernten Teams: strategisch indexieren, Index-Gesundheit überwachen, Query-Muster verstehen. Man maß, ob Indizes funktionierten. Das verschwand mit Embeddings. Plötzlich war Vektorsuche Mathematik, nicht Infrastruktur.

HNSW degradiert, weil der Raum dichter wird. Eine Hierarchie, die funktionierte wenn Dokumente verteilt waren, wird weniger wirksam. Man kann ef_search erhöhen, aber der Preis ist steil: ef=160 dauert 3x länger als ef=40. Teams tunen nicht. Sie akzeptieren es.

Klassische Datenbanken hatten das gleiche Problem. Ein Index wurde langsam — man machte ihn nicht größer. Man partitionierte die Daten. Fügte Metadaten-Filter hinzu. Nutzte mehrere Index-Typen für verschiedene Queries.

RAG skaliert mit dem gleichen Ansatz. Teams mit zuverlässigem RAG nutzen nicht bloß Vektorsimilarität. Sie verengen zuerst den Suchraum mit Filtern — Dokumenttyp, Domain, Datum. Dann läuft die Vektorsuche auf weniger Daten. Manche kombinieren Keyword- mit semantischer Suche. Sie partitionieren Vektoren nach Domain. Sehen die Bank als Infrastruktur, die Design braucht.

Eine Vektorbank allein skaliert nicht. Das ist kein Fehler der Technik. Das trifft alle Single-Index-Systeme. Aber man muss das wissen, bevor man anfängt.

Jetzt deployen Teams Vektorbanken, als wären sie erledigt. Sechs Monate später ist die Retrieval-Qualität unzuverlässig. Sie sind überrascht, weil sie es nicht gemessen haben. Das ist der blinde Fleck.

Quellen

• HNSW at Scale: Why Your RAG System Gets Worse as the Vector Database Grows (Towards Data Science, 2025)
• RAG, or Retrieval Augmented Generation: Revolutionizing AI in 2025 (Glean, 2025)
• Retrieval-Augmented Generation: A Comprehensive Survey of Architectures, Enhancements, and Robustness Frontiers (arXiv, 2025)
• Building Hierarchical Agentic RAG Systems: Multi-Modal Reasoning with Autonomous Error Recovery (InfoQ, 2025)
• Mitigating Hallucination in Large Language Models (LLMs): An Application-Oriented Survey on RAG, Reasoning, and Agentic Systems (arXiv, 2025)