Der Vector Store ist weniger entscheidend als die Pipeline, die ihn speist. Für Finanz-Retrieval unterhalb einiger Millionen Chunks ist pgvector auf Ihrem bestehenden Postgres meist die richtige Antwort: Es legt die Embeddings direkt neben die Metadaten, nach denen Sie filtern, und nimmt ein System aus Ihrem Betriebsdiagramm. Zu einem dedizierten Store greifen Sie, wenn Index-Aufbauzeit, Speicher oder Query-Nebenläufigkeit anfangen wehzutun. Die Wahl bestimmt Ihre Latenz und Ihre Kosten, nicht Ihre Genauigkeit.
An genau diesem letzten Punkt laufen die meisten Auswahldebatten in die Irre. Teams streiten über HNSW versus IVF oder darüber, welcher Managed-Anbieter den schnellsten Recall-Benchmark hat, während die tatsächliche Qualität der abgerufenen Passagen weiter oben in der Pipeline entschieden wird: durch Chunking, das Embedding-Modell und dadurch, wie gut die Metadaten es erlauben, eine Query einzugrenzen. Ein perfekter Index über schlecht segmentierten Dokumenten liefert selbstbewussten Unsinn. Bevor Sie also Stores vergleichen, seien Sie ehrlich darüber, wofür der Store verantwortlich ist und wofür nicht.
Wofür der Store tatsächlich geradesteht
Ein Vector Store erledigt drei Aufgaben: Er hält Embeddings, findet schnell approximative nächste Nachbarn und filtert Kandidaten nach Metadaten. Im Finanzbereich ist die dritte Aufgabe diejenige, die unterschätzt wird und die Projekte zum Scheitern bringt.
Praktisch jede reale Query ist eingegrenzt. Sie durchsuchen nicht sämtliche jemals eingelesenen Dokumente. Sie durchsuchen die Filings dieser Gegenpartei, die Term Sheets dieses Fonds oder die im zweiten Quartal gültigen Policy-Versionen. Diese Eingrenzung ist Metadatenfilterung, und wie ein Store sie umsetzt, entscheidet darüber, ob Ihre Latenz standhält. Es gibt zwei Muster, und sie verhalten sich sehr unterschiedlich:
- Pre-Filtering grenzt die Kandidatenmenge zunächst nach Metadaten ein und führt dann die Vektorsuche über dem Rest aus. Korrekte Ergebnisse, aber wenn der Filter selektiv ist, wird der HNSW-Graph dünn und der Recall fällt, mitunter drastisch.
- Post-Filtering führt zuerst die Vektorsuche aus und verwirft dann Kandidaten, die den Filter nicht erfüllen. Schnell, aber bei einem selektiven Filter können Sie fünfzig Nachbarn abrufen und drei behalten und dabei relevante Passagen komplett verpassen.
Für eine Bank, die nach einem Schuldner unter vierzigtausend fragt, liefert naives Post-Filtering klammheimlich nichts Brauchbares zurück. Sie wollen einen Store, der Filtered HNSW gut beherrscht, also die Graph-Traversierung anhand des Metadaten-Prädikats beschneidet, statt den Filter an einem der beiden Enden anzuflanschen. Der iterative Index-Scan von pgvector, die payload-aware Suche von Qdrant und die Filtered Search von Weaviate meistern das alle; ein Store, der nur Post-Filtering bietet, ist für eingegrenztes Finanz-Retrieval disqualifiziert, ganz gleich, was seine Benchmark-Zahlen sagen.
Point-in-Time-Korrektheit ist nicht verhandelbar
Finanzdokumente werden neu gefasst, ersetzt und korrigiert. Ein 10-K wird geändert. Eine Kreditrichtlinie hat Versionen. Ein Term Sheet wird vor der Unterschrift viermal redigiert. Wenn Ihr Store die Frage “Was wussten wir zu diesem Stichtag?” nicht beantworten kann, haben Sie eine Lookahead-Maschine gebaut, die zukünftiges Wissen in Antworten über die Vergangenheit einschleust.
Das ist dieselbe Disziplin, die Sie bei einem Feature Store anwenden, übertragen auf das Retrieval. Konkret heißt das: Jeder Chunk trägt mindestens ein Gültigkeitsdatum, einen Ingestion-Zeitstempel und eine Dokumentversions-ID, und jede Query kann danach filtern. Der Store braucht keine eingebauten Temporal Features. Er braucht eine Metadatenfilterung, die schnell und korrekt genug ist, dass das Anhängen von effective_date <= :as_of AND superseded_at > :as_of an jede Query Ihre Latenz nicht zerstört. Diese Anforderung drängt Sie zu Stores mit starker Filtered Search, und sie ist ein weiterer Grund, warum es reizvoll ist, die Embeddings in Postgres zu halten: Die zeitlichen Prädikate leben in SQL, dem Sie ohnehin vertrauen, und die Lineage vom Chunk zurück zum Quelldokument ist ein Join, kein zweites System, das abgeglichen werden muss.
Macht man das falsch, ist der Fehler im Demo unsichtbar und im Audit katastrophal. Eine Antwort, die auf einer neu gefassten Kennzahl beruht und abgerufen wurde, weil der Store keinen Begriff davon hatte, welche Version aktuell war, ist genau das Problem des selbstbewussten Satzes mit der falschen Zahl. Kein Reranker rettet Sie davor, denn die falsche Passage war tatsächlich der nächstliegende Treffer.
Hybride Suche, weil Finanzen auf exakten Tokens laufen
Dense Vectors sind gut in Bedeutung und schlecht in Bezeichnern. Finanzdokumente sind voll von Bezeichnern, die exakt übereinstimmen müssen: CUSIPs, ISINs, LEIs, Ticker-Symbole, definierte Begriffe, Abschnittsnummern, Basispunkt-Angaben. Embedden Sie “SR 11-7”, und eine reine Vektorsuche fördert bereitwillig Passagen über Modellrisiko im Allgemeinen zutage und verpasst dabei die eine, die genau diese Guidance benennt. Das ist ein Retrieval-Fehltreffer, den kein Embedding-Modell-Upgrade behebt, denn das Signal ist lexikalisch, nicht semantisch.
Bauen Sie hybride Suche also von Anfang an ein. Sie fahren Dense Retrieval parallel zu einem sparse oder keyword-basierten Retrieval (BM25 oder ein gelerntes Sparse-Modell wie SPLADE) und fusionieren die Ergebnisse, üblicherweise per Reciprocal Rank Fusion. Wenn Sie einen Store bewerten, prüfen Sie, was er Ihnen hier bietet:
- Natives BM25 oder Volltext neben der Vektorsuche, sodass Sie kein separates Suchcluster aufsetzen und abgleichen müssen.
- Einen Fusionsschritt, den Sie kontrollieren, oder zumindest sauberen Zugriff auf beide Ergebnismengen und ihre Scores, damit Sie selbst fusionieren können.
- Die Möglichkeit, die Exact-Match-Felder (Bezeichner, Daten, definierte Begriffe) als filterbare Metadaten zu halten, sodass Bezeichner-Treffer erzwungen statt nur gerankt werden können.
Weaviate und Qdrant liefern Hybrid nativ aus. Postgres gibt Ihnen tsvector-Volltext neben pgvector, und Sie fusionieren im Anwendungscode, was mehr Arbeit ist, aber alles an einem Ort mit einem Konsistenzmodell hält. Elasticsearch und OpenSearch kommen von der Suchseite und beherrschen Vektoren inzwischen kompetent, was sie sinnvoll macht, wenn Ihre Organisation sie ohnehin betreibt und personell trägt.
Wie die Entscheidung tatsächlich abläuft
Ordnen Sie die Fragen so, dass die disqualifizierenden zuerst kommen. Beherrscht der Store Filtered HNSW korrekt, sodass eingegrenzte Queries ihren Recall halten? Kann er Point-in-Time-Korrektheit durch schnelle Metadaten-Prädikate erzwingen? Unterstützt er hybrides Retrieval ohne ein zweites System? Erst danach zählen die vertrauten operativen Fragen: Index-Aufbauzeit bei Ihrem Dokumentvolumen, Speicherbedarf (HNSW ist speicherhungrig, und Quantisierung tauscht Recall gegen RAM), horizontale Skalierung, falls Sie über einen einzelnen Knoten hinaus sind, und ob Sie einen Managed Service oder Self-Hosting wollen, aus Data-Residency-Gründen, nach denen DORA und Ihre eigenen Kontrollen fragen werden.
Bauen Sie sich vor der Festlegung ein kleines Eval-Set aus echten Queries mit bekannten korrekten Passagen und messen Sie den Recall bei genau der Eingrenzung und Filterung, die Ihre Produktions-Queries tatsächlich nutzen werden, nicht an einem offenen Benchmark. Die meisten Teams stellen fest, dass die Stores bei der Retrieval-Qualität etwa gleichauf liegen und bei den operativen Kosten völlig auseinandergehen. Das ist die ehrliche Gestalt dieser Entscheidung: Wählen Sie den Store, der am günstigsten korrekt gegen die obigen Randbedingungen zu betreiben ist, und stecken Sie die eingesparte Zeit in die Chunking- und Eval-Arbeit, die Ihre Antworten wirklich bewegt.
Häufige Fragen
Brauche ich eine dedizierte Vektordatenbank oder reicht pgvector?
Für die meisten Finanz-Retrieval-Aufgaben unterhalb einiger Millionen Chunks genügt pgvector auf dem Postgres, den Sie ohnehin betreiben, und es hält Ihre Embeddings direkt neben den Metadaten, nach denen Sie filtern. Zu einem dedizierten Store greifen Sie, wenn Index-Aufbauzeit, Speicherdruck oder Sharding beginnen, Ihre Primärdatenbank zu behindern.
Wie stark beeinflusst der Vector Store die Antwortqualität?
Weniger, als die meisten erwarten. Chunking, das Embedding-Modell, Metadatenfilterung und Reranking bewegen die Qualität weit stärker als die Wahl zwischen HNSW-Implementierungen. Der Store bestimmt vor allem Ihre Latenz, Ihre Kosten und Ihren operativen Aufwand.
Muss die Vektordatenbank point-in-time-korrekt sein?
Ja, wenn Sie über Dokumente abrufen, die neu gefasst oder ersetzt werden, etwa Filings, Term Sheets oder Policy-Versionen. Der Store muss es Ihnen erlauben, auf den zu einem bestimmten Stichtag bekannten Stand zu filtern, sonst schleusen Sie zukünftiges Wissen in Antworten über die Vergangenheit ein.