Retrieval-Infrastruktur & Vektor-Stores

Ein Proof of Concept für die Vektorsuche und ein Produktivsystem, das unter realem Query-Volumen standhält, sind zwei verschiedene technische Probleme. Wir bauen und betreiben die Retrieval-Infrastrukturebene, die unter Ihrer RAG-Pipeline, Ihren agentischen Workflows oder Ihrem semantischen Suchprodukt liegt — die Vektor-Engine, die zuführende Embedding-Pipeline, das Index-Lifecycle-Management, das sie gesund hält, und den Observability-Stack, der Qualitätsverschlechterungen erkennt, bevor Nutzer sie bemerken.

Wir sind bei der Engine herstellerneutral. Unsere Praxis ist engine-agnostisch über Qdrant, Milvus, Weaviate, pgvector und Elasticsearch kNNhinweg, und welche wir empfehlen, hängt von Ihrer Vektoranzahl, Ihren Query-Mustern, Ihren Mandantenfähigkeitsanforderungen und Ihrer operativen Kapazität ab.

Von der 50K-Vektor-Demo zur 200M-Vektor-Produktion

Die Lücke zwischen einer Demo und einem Produktivsystem ist fast ausschließlich ein Infrastrukturproblem. Die Demo lädt 50K Vektoren in Pinecone, führt eine Kosinus-Ähnlichkeitsabfrage aus und liefert Ergebnisse in 40 ms. Die Produktion sieht ganz anders aus.

• 200 Mio. Vektoren und 500 Abfragen pro Sekunde dauerhaft
• 15 Metadaten-Filterdimensionen und Dokumente, die sich aktualisieren — stündlich
• Drei Teams, die sich unter strikter Mandantenisolation einen Cluster teilen

In diesem Maßstab lassen HNSW-Compaction-Spitzen Ihr P99 auf 800 mshochschnellen, der Recall verschlechtert sich nach einer Woche inkrementeller Updates unbemerkt, und die Embedding-Pipeline kommt mit Ihrer Dokumentenänderungsrate nicht mehr mit. Genau hier setzen wir an.

Die Engine-Auswahl ist eine Benchmarking-Übung, keine Markenentscheidung

Jeder Anbieter behauptet, erstklassige Leistung zu bieten; die Benchmarks erzählen eine differenziertere Geschichte. Wir wählen keine Datenbank aus einer Feature-Matrix — wir laden Ihre tatsächlichen Vektoren, führen Ihre tatsächlichen Abfragen mit Ihren tatsächlichen Metadatenfiltern aus und messen den Recall bei operativ relevanten k -Werten neben der P50/P95/P99-Latenz unter gleichzeitiger Last.

Die Ergebnisse widersprechen regelmäßig dem Marketing der Anbieter. Die Serverless-Stufe von Pinecone wirkt kosteneffizient, bis dauerhaft hohe QPS-Workloads die Read-Unit-Kosten über den Break-even-Punkt des Self-Hostings treiben, und pgvector wirkt einschränkend, bis iterative Scans die Lücke bei der gefilterten Suche schließen.

Die Embedding-Pipeline ist der Ort, an dem Produktions-Retrieval tatsächlich bricht

Teams investieren 60 % ihres Engineering-Aufwands für die Vektorsuche in die Pipeline, nicht in den Store. Die Pipeline übernimmt die Dokumentenaufnahme, das Chunking, die Inferenz des Embedding-Modells, das inkrementelle Re-Indexing bei Dokumentenaktualisierungen und die Metadatenweitergabe — und jede Stufe hat Fehlermodi, die die Retrieval-Qualität unbemerkt verschlechtern.

• Veraltetes Wissen — der zweithäufigste Produktions-RAG-Fehler. Ein Dokument wird in Confluence aktualisiert, aber der Index liefert weiterhin das alte Embedding. Die Lösung sind Change-Data-Capture-Trigger, die inkrementell neu einbetten, statt nächtlichem Batch-Re-Indexing.
• Geister-Dokumente — ein Quelldokument wird gelöscht, aber sein Vektor bleibt bestehen und liefert Ergebnisse für Inhalte, die nicht mehr existieren. Da atomare Transaktionen über ein Source-of-Truth-System und einen Vektor-Store hinweg in geteilten Architekturen nahezu unmöglich sind, bauen wir Abgleichsebenen, die verwaiste Vektoren erkennen und bereinigen.

Die Auswahl des Embedding-Modells ist wichtiger, als die meisten Teams glauben, und ein späterer Wechsel ist teuer: Das erneute Einbetten von 8 Mio. Dokumenten beim Upgrade von text-embedding-ada-002 auf text-embedding-3-large kostet tagelange Rechenleistung und erfordert eine Dual-Write-Infrastruktur, um Ausfallzeiten zu vermeiden. Wir evaluieren Modelle anhand Ihres domänenspezifischen Query-Sets, bevor Sie sich festlegen.

• Cohere embed-v4 — führt beim mehrsprachigen Retrieval mit 0,01 US-Dollar pro Million Tokens über 100+ Sprachen.
• Nomic Embed v2 — 137 Mio. Parameter, läuft auf der CPU, mit dem besten Qualitäts-zu-Größe-Verhältnis am Markt.
• OpenAI text-embedding-3-large — ein starker Allrounder.

Die richtige Wahl hängt von Ihrem Sprachmix, Ihren Latenzanforderungen und davon ab, ob Sie eine API-Abhängigkeit akzeptieren können oder On-Premises-Inferenz benötigen.

Index-Lifecycle: Das operative Problem, vor dem Sie niemand warnt

HNSW-Indizes verschlechtern sich — kein Bug, sondern eine architektonische Realität. Bei 160 Mio. Vektorendauert ein vollständiger HNSW-Neuaufbau 3–6 Stunden. Inkrementelle Updates machen die Graphstruktur suboptimal und untergraben mit der Zeit den Recall; Compaction-Ereignisse lassen die Query-Latenz hochschnellen; und jedes Upsert, jedes Delete und jeder Segment-Merge löst Teilindex-Neuaufbauten aus, die CPU für Wartung verbrennen, statt Abfragen zu bedienen. Der Kompromiss ist unausweichlich: das Anheben von 0,8 auf 0,95 Recall erhöht die HNSW-Latenz um rund 31 %.

Wir konzipieren ein Lifecycle-Management, das kontinuierliche Ingestion ohne Qualitätsverlust auffängt:

• Blue-Green-Index-Rotation — Neuaufbau auf separater Infrastruktur und atomarer Swap ohne Ausfallzeit.
• Automatisierte Recall-Validierungs-Gates — Abgleich eines Golden-Query-Sets mit dem aktuellen Index nach jeder größeren Operation; fällt der Recall unter den Schwellenwert, findet der Swap nicht statt.
• GPU-beschleunigter HNSW-Aufbau in Qdrant und Elasticsearch verkürzt die Neuaufbauzeiten um eine Größenordnung, wobei die Orchestrierung des Wann, Wie der Validierung und Wie des Swaps maßgeschneidertes Engineering ist.

Die Quantisierung geht noch weiter. Qdrant bietet jetzt 1,5-Bit-, 2-Bit- und asymmetrische Quantisierung, und Elasticsearch BBQ reduziert den Heap um über 95 % im Vergleich zu float32. Diese sparen Speicher und verbessern den Durchsatz, aber jedes Schema hat ein anderes Recall-Profil gegenüber unterschiedlichen Datenverteilungen — daher charakterisieren wir die Recall-Auswirkung auf Ihre spezifischen Vektoren, bevor wir die Quantisierung in Produktion einsetzen.

Mandantenfähigkeit und Isolation in echtem Maßstab

Plattform-Teams, die 200+ interne ML-Teamsbedienen, oder SaaS-Produkte mit Tausenden von Kundenmandanten benötigen eine Infrastruktur, die Isolation garantiert: Die Abfragen von Mandant A dürfen niemals die Daten von Mandant B zurückgeben, Audit-Logs müssen jede Abfrage bis zu einer Mandantenidentität zurückverfolgen, und kalte Mandanten sollten keine Ressourcen verbrauchen, die heiße Mandanten benötigen.

• Weaviate — das One-Shard-per-Tenant-Modell mit Mandantenzuständen (ACTIVE, INACTIVE, OFFLOADED nach S3) ist die ausgereifteste Implementierung für Deployments mit hoher Mandantenanzahl.
• Milvus — unterstützt Isolation auf Datenbank-, Collection-, Partitions- oder Partition-Key-Ebene und passt die Granularität an Ihre Compliance-Anforderungen an.

Beide erfordern in großem Maßstab eine maßgeschneiderte Orchestrierung — Mandanten-Provisionierung, Zustandsübergänge, Kontingentverwaltung und die Erkennung mandantenübergreifender Lecks werden von der Datenbank selbst nicht übernommen. Wir bauen die operative Ebene, die die Mandantenfähigkeit für regulierte Deployments beherrschbar macht, die SOC 2 oder ISO 27001 -Compliance erfordern.

Agentische Workflows verändern die Infrastrukturanforderungen

Die Welle der agentischen KI verändert, was Vektor-Stores leisten müssen. Statisches RAG ruft Dokumente gegen einen festen Korpus ab. Agentische Workflows erfordern episodisches Gedächtnis (Konversationsverlauf und Zwischen-Reasoning), semantische Suche über einen großen Dokumentenkorpus und Benutzerprofil-Ebenen — oft alle drei in einem einzigen Agentenschritt. Die Latenzanforderung von unter 400 ms ist enger als bei Batch-RAG, und ACID-Transaktionsunterstützung wird für mehrstufige Agenten unverzichtbar, die den Zustand ohne partielle Schreibvorgänge aktualisieren.

Keine einzelne Vektordatenbank bewältigt alle drei Gedächtnisebenen gut, daher setzen Teams Multi-Store-Architekturen zusammen: Redis für den Session-Zustand, Qdrant oder Milvus für die semantische Suche und eine Graphdatenbank für das Tracking von Beziehungen. Oracles Unified Memory Core (März 2026) versucht, Vektor-, JSON-, Graph-, relationale und räumliche Abfragen in einer Engine zu konvergieren. Wir konzipieren die Retrieval-Ebene für agentische Systeme — welche Stores welche Gedächtnistypen bewältigen, wie Abfragen über Stores hinweg geroutet werden und wie die Konsistenz gewahrt bleibt, wenn ein Agent den Zustand über mehrere Backends in einem einzigen Reasoning-Schritt aktualisiert.

Was wir liefern

Jedes Engagement beginnt mit einer Benchmarking-Phase: Wir laden Ihre Vektoren, führen Ihre Abfragen aus und erstellen quantifizierte Engine-Empfehlungen. Von dort aus bauen wir die Produktionsinfrastruktur:

• Den Vektor-Store-Cluster, mit Kapazitätsplanung und Skalierungs-Runbooks.
• Die Embedding-Pipeline, mit CDC-getriggertem inkrementellem Re-Indexing und Modellversionsverwaltung.
• Die Index-Lifecycle-Automatisierung, mit Blue-Green-Rotation und Recall-Validierungs-Gates.
• Die Mandantenfähigkeits-Orchestrierungsebene, wenn Sie Mandantenisolation benötigen.
• Den Observability-Stack, mit Drift-Erkennung, Recall-Regressions-Alerts und P95/P99-Latenzüberwachung.
• Migrations-Tooling für Teams, die zwischen Engines wechseln, unter Nutzung von zwischengeschalteten Parquet -Formaten, um Embeddings dort zu erhalten, wo die Dimensionalität übereinstimmt, statt ein vollständiges Re-Embedding zu erzwingen.

Wir umreißen jedes Engagement mit expliziten monatlichen Infrastrukturkosten-Prognosen, damit Sie wissen, was die Produktion kosten wird, bevor Sie sich festlegen.