Warum reine Vektorsuche bei zeitkritischen Antworten versagt

Fragen Sie Ihr Retrieval-System nach der aktuellen Rückgabefrist, und es liefert Ihnen die Antwort aus dem Jahr 2022 mit voller Überzeugung. Nicht, weil die Fassung von 2026 im Index fehlt — sie liegt dort, ein paar Chunks weiter unten —, sondern weil ein Cosine-Score nicht weiß, welches Jahr gerade ist.

Das ist die häufigste Art, wie ein funktionierendes RAG-System still und leise aufhört, richtig zu sein. Nichts wirkt kaputt. Der Recall ist gesund, die Eval-Suite ist grün, die Demo überzeugt. Dann kommt eine Frage, deren Antwort ein Datum trägt, und das System antwortet aus der falschen Epoche.

Was folgt, ist Mechanik und publizierte Forschung, keine Anekdote aus einem Projekt. Jede Zahl ist mit ihrer Quelle verlinkt.

Warum Ähnlichkeit und Aktualität zwei verschiedene Achsen sind

Die Cosine-Ähnlichkeit misst den Winkel zwischen zwei Embeddings. Mehr ist es nicht. Sie sagt Ihnen, wie nah sich zwei Texte in ihrer Bedeutung sind, und hat keinerlei Meinung dazu, welcher von beiden gerade zutrifft.

Die beiden Chunks oben sind semantisch nahezu identisch. Gleiches Vokabular, gleicher Satzbau, gleiche Fachbegriffe. Der einzige Unterschied, der für einen Menschen zählt — dreißig Tage gegen vierzehn —, ist ein einzelnes Zahlen-Token, das semantisch fast nichts wiegt. Für den Index sind sie zweimal dieselbe Antwort.

Es ist schlimmer als ein Münzwurf. Ältere Dokumente sind oft die besser geschriebenen: Sie wurden häufiger überarbeitet, häufiger verlinkt, häufiger aufgeräumt. Ein Retriever, der indirekt nach Textqualität rankt, bevorzugt sie systematisch.

Eine Studie von 2026 hat das direkt gemessen. In einem harten Freshness-Test auf Basis von NVD-CVE-Daten erreichte eine reine Cosine-Baseline 0,00 bei Latest@10 — sie brachte kein einziges Mal das neueste relevante Dokument in die Top Ten. Quelle: Freshness and the Limits of Heuristic Trend Detection in Temporal RAG.

Null von zehn. Nicht verschlechtert — abwesend.

Vier Arten, wie ein rein semantischer Index veraltet

Es lohnt sich, diese zu trennen, denn sie brauchen unterschiedliche Lösungen — und nur eine davon ist in Ihren Logs sichtbar.

• Veraltet, aber ähnlich. Zwei Dokumente beantworten dieselbe Frage; das alte gewinnt über die Formulierung. Lösbar über das Ranking, nicht über Filter.
• Überholtes Duplikat. v3 und v7 desselben Dokuments liegen beide im Index und sind im Embedding-Raum nahezu identisch. Lösbar weiter vorne, indem tote Versionen gar nicht erst indexiert werden.
• Damals richtig. Der Text war 2023 korrekt und ist heute falsch, und nichts im Text weist darauf hin. Das ist der gefährliche Fall — das Modell hat kein Signal, um sich abzusichern, und nennt die veraltete Tatsache schlicht als Fakt.
• Gar kein Zeitstempel. Ohne Datum am Chunk gibt es nichts zu filtern und nichts abklingen zu lassen. Jede andere Lösung in diesem Artikel setzt diese voraus.

Beheben Sie zuerst den vierten Fall. Er ist das langweiligste Problem und die harte Voraussetzung für alles Weitere: ein Zeitstempel an jedem Chunk, durch die gesamte Ingestion-Pipeline durchgereicht, idealerweise zusammen mit einem Gültigkeitszeitraum statt nur einem Ingestion-Datum.

Was die Benchmarks wirklich messen — und was nicht

Die meisten Retrieval-Benchmarks sind ihrer Konstruktion nach zeitlos. Fragen haben eine richtige Passage, diese Passage hat keine konkurrierende spätere Fassung, und kein Teil der Bewertung hängt davon ab, wann etwas geschrieben wurde. Ein Retriever kann diese Ranglisten anführen und trotzdem nutzlos sein, sobald Ihr Korpus eine Historie hat.

Temporale Benchmarks gibt es, und es lohnt sich, sie zu lesen, bevor Sie eigene bauen. ChronoQA entstand aus über 300.000 Nachrichtenartikeln aus den Jahren 2019 bis 2024, mit 5.176 Fragen zu absoluten, aggregierten und relativen Zeitbezügen (arXiv:2508.12282). TempRAGEval nimmt TimeQA und SituatedQA und wendet zeitliche Störungen darauf an (arXiv:2510.13590). FreshQA bewertet sowohl Korrektheit als auch Halluzination bei Fragen, deren Antworten sich verändern.

Die naheliegende Antwort ist, dem Embedding-Modell Zeit beizubringen. Das wurde versucht. TempRetriever bettet sowohl das Anfragedatum als auch den Dokumentzeitstempel in das Retrieval ein und berichtet +6,63 % Top-1-Genauigkeit und +3,79 % NDCG@10 auf ArchivalQA sowie +9,56 % und +4,68 % auf ChroniclingAmericaQA gegenüber Standard-DPR.

Das sind echte Zuwächse — und zugleich einstellige Zuwächse eines spezialisierten Modells, das Sie trainieren und pflegen müssten. Stellen Sie sie neben den Sprung von 0,00 auf 0,60, den ein simpler Recency-Prior in einem Freshness-Test erzeugt, und die Schlussfolgerung schreibt sich von selbst: Die Embedding-Ebene ist der teure Ort, das zu beheben, die Ranking-Ebene der günstige.

Dieselbe Studie ist ehrlich darüber, wo die günstige Lösung aufhört zu funktionieren. Ihr heuristischer Themenverlaufs-Tracker — der erkennen soll, wohin sich ein Thema entwickelt, nicht nur wie alt ein Dokument ist — erreichte lediglich 0,08 Macro-F1. Aktualität lässt sich mit einem Prior gut in den Griff bekommen. Trenderkennung nicht.

Metadaten-Filter: notwendig, aber nicht ausreichend

Der erste Reflex ist eine WHERE-Klausel. Nur Dokumente durchsuchen, die aktuell gültig sind — dann können veraltete gar nicht auftauchen. Der Reflex ist richtig, und er leistet weniger als erwartet, aus einem Grund, den man leicht übersieht.

Approximative Vektorindizes filtern in der Regel nach dem Index-Scan, nicht währenddessen. In pgvector mit HNSW und dem Standardwert hnsw.ef_search = 40 bleiben bei einem Prädikat, das 10 % Ihrer Zeilen trifft, im Schnitt etwa vier Zeilen übrig — Sie haben die Top 40 nach Ähnlichkeit angefordert und davon 90 % weggeworfen. Der Recall bricht genau dann ein, wenn der Filter am selektivsten ist, also genau dann, wenn Sie ihn brauchten.

pgvector 0.8.0 hat iterative Index-Scans eingeführt, die den Graphen so lange weiter durchlaufen, bis genügend gefilterte Zeilen gefunden sind. Das holt den Recall zurück und bezahlt ihn mit CPU, Speicher und Tail-Latenz. Engines mit Filterung innerhalb des Algorithmus zahlen diesen Preis nicht. Welche Sie auch einsetzen: Wichtig ist, vor dem Verlassen auf einen Filter zu wissen, welche der drei Varianten Ihre Datenbank fährt.

Die tiefere Einschränkung ist begrifflich. Ein Filter ist eine harte Grenze, Aktualität ist ein Verlauf.

• Filter können: Mandantentrennung, Dokumenttyp, explizite Gültigkeitszeiträume, Kennzeichen für zurückgezogene oder überholte Inhalte — alles mit einer echten Ja-oder-Nein-Antwort.
• Filter können nicht: „Bevorzuge Neueres, aber ein wirklich gutes altes Dokument ist immer noch besser als ein mittelmäßiges neues.“ Das ist eine Gewichtungsfrage, und ein Boolean kann sie nicht ausdrücken.

Hybride Suche: BM25, Dense-Vektoren und Rank Fusion

Bevor Sie nach Zeit gewichten können, brauchen Sie eine Kandidatenmenge, die das Gewichten lohnt. Das bedeutet zwei Retriever, nicht einen.

BM25 ist derjenige, der Versionsnummern, ausgeschriebene Daten, Fehlercodes, Produktnamen und Dokumentkennungen findet — genau die Tokens, die ein Dense-Embedding wegglättet, und genau die Tokens, die v3 von v7 unterscheiden. Dense Retrieval findet die Umschreibung, das Synonym und die Frage in Worten, die im Dokument nie vorkommen. Keiner von beiden ist optional, wenn Ihr Korpus Versionen enthält.

Beide erzeugen inkompatible Zahlen: BM25-Scores sind nach oben unbegrenzt positiv, die Cosine-Ähnlichkeit liegt in [-1, 1]. Sie zu mitteln ist keine sinnvolle Operation — deshalb arbeitet Reciprocal Rank Fusion mit Rängen statt mit Scores: Position 1 aus einer der beiden Listen zählt gleich viel, unabhängig davon, welche Zahl sie erzeugt hat. Guillaume Laforge erklärt das anschaulich.

Kalkulieren Sie die Betriebskosten ehrlich ein: Ein BM25-Index ist ein eigenes Artefakt neben dem Vektorindex. Jeder Schreibvorgang muss beide erreichen, jedes Backfill läuft doppelt, und eine Neuindexierung des einen ohne das andere erzeugt ein System, das auf eine Weise falsch ist, die kein Test bemerkt.

Zeit in die Ranking-Funktion einbauen

Das ist die eigentliche Lösung, und sie ist kleiner als der Text, der ihr vorausgeht. Multiplizieren Sie den fusionierten Relevanz-Score mit einem Faktor, der mit dem Dokumentalter abfällt.

final_score = fused_score * 0.5 ** (age_days / half_life_days)

Das mittlere Feld zeigt den Fehler, den man benennen sollte. Ein harter Cutoff fühlt sich sicherer an als ein Decay und verhält sich schlechter: Ein Dokument, das gestern noch Ihre beste Antwort war, ist heute unsichtbar, weil es eine willkürliche Grenze überschritten hat — und Nutzer erleben das so, als würde das System zufällig Dinge vergessen. Ein Decay entfernt ein Dokument nie aus der Auswahl; es sorgt nur dafür, dass Alter etwas kostet.

Die Halbwertszeit ist die eine Zahl, die Sie wählen müssen, und sie sollte sich daran orientieren, wie schnell Ihr Korpus tatsächlich umschlägt. Die folgenden Werte sind Startpunkte zum Nachmessen, keine Empfehlungen:

• Schnelllebig — Incident-Notizen, Preise, Release Notes, alles mit einem Changelog: Tage bis wenige Wochen.
• Richtlinien-Tempo — interne Handbücher, Verträge, Support-Artikel: sechs bis achtzehn Monate.
• Referenzmaterial — Normen, Forschung, architektonische Grundlagen: Jahre — oder gar kein Decay. Ein Recency-Prior schadet hier aktiv.

Enthält Ihr Korpus alle drei, gehört die Halbwertszeit zur Dokumentklasse, nicht zum System. Eine globale Konstante über einen gemischten Korpus repariert Ihr Changelog und zerstört Ihre Normensammlung.

Reranking und was ein Cross-Encoder kostet

Ein Bi-Encoder bettet Anfrage und Dokument getrennt ein und vergleicht die beiden Vektoren — deshalb dauert die Suche über Millionen Dokumente nur einstellige Millisekunden: Die Dokumentseite wurde vorab berechnet. Ein Cross-Encoder liest Anfrage und Dokument gemeinsam, Paar für Paar. Er ist deutlich genauer und lässt sich nicht vorberechnen, läuft also immer nur auf einer Shortlist.

Veröffentlichte Zahlen beziffern den Zugewinn auf 5 bis 15 NDCG@10-Punkte (mehr bei lexikalisch schwierigen Datensätzen) für etwa 100 bis 300 ms zusätzliche Latenz. Stand Anfang 2026 kostet Cohere Rerank rund 2,00 $ pro 1.000 Search Units, wobei eine Unit aus einer Anfrage plus bis zu 100 Dokumenten besteht und alles über 500 Tokens automatisch in weitere Units zerlegt wird. Vergleich aktueller Reranker-Optionen.

Aus diesem Preismodell folgen direkt zwei Konsequenzen. Erstens: Reranken Sie eine Top-50, keine Top-500 — die Kosten sind linear in der Dokumentzahl, der Qualitätsgewinn ist es nicht. Zweitens: Self-Hosting beginnt sich irgendwo oberhalb von etwa 100.000 Anfragen pro Tag zu lohnen; darunter ist die API günstiger als die nötige GPU plus die Person, die sie am Laufen hält.

Ein Reranker ersetzt den Recency-Prior nicht. Er bewertet Relevanz neu — und Relevanz ist genau die Achse, auf der das veraltete Dokument bereits gewinnt. Wenden Sie das Decay auf die neu bewerteten Scores an, nicht anstelle davon.

Ein temporales Eval-Set aufbauen

Sie können keine Halbwertszeit tunen, die Sie nicht messen — und ein allgemeines RAG-Eval misst sie nicht: Dessen Fragen haben eine richtige Antwort und keine konkurrierende ältere Fassung. Das Set aufzubauen kostet einen Tag und ist der Unterschied zwischen Tunen und Raten.

1. Finden Sie Dokumente in Ihrem Korpus, die in mehreren Fassungen existieren. Versionskontrolle, eine CMS-Historie oder Duplikaterkennung auf den Embeddings fördern sie zutage.
2. Formulieren Sie zu jedem die Frage, deren Antwort sich zwischen den Fassungen geändert hat. Hat sich nichts geändert, ist es kein brauchbarer Testfall.
3. Kennzeichnen Sie die neueste Fassung als einzige korrekte Passage und halten Sie fest, zu welchem Datum die Frage gestellt wird.
4. Bewerten Sie Latest@k: Erschien die neueste korrekte Passage in den Top k? Berichten Sie den Wert getrennt vom gewöhnlichen Recall, denn der gewöhnliche Recall sieht durchgehend gut aus.
5. Variieren Sie die Halbwertszeit gegen dieses Set, wählen Sie den Knick der Kurve, und prüfen Sie anschließend, dass Ihr Referenzmaterial nicht schlechter geworden ist.

Der mittlere Balken ist der, bei dem man verweilen sollte. „Erst semantisch, dann nach Datum sortieren“ ist die Lösung, zu der die meisten Teams greifen; sie verdreifacht die Baseline und liegt trotzdem in vier von fünf Fällen daneben — denn eine Liste zu sortieren, die das richtige Dokument nie enthielt, bringt das richtige Dokument nicht hinein. Die Gewichtung muss vor dem Abschneiden passieren, nicht danach.

Was Sie am Montag tun können

• Prüfen Sie, ob jeder Chunk ein Datum hat. Kein Ingestion-Datum — das Datum, zu dem der Inhalt galt. Nichts anderes in diesem Artikel funktioniert ohne das.
• Indexieren Sie tote Versionen nicht mehr. Die günstigste Retrieval-Verbesserung überhaupt besteht darin, weniger falsche Antworten im Index zu haben.
• Stellen Sie BM25 neben Ihre Vektoren und fusionieren Sie über Ränge. Versionsnummern und Daten sind lexikalische Signale, und ein Dense-Embedding ist genau darauf ausgelegt, sie zu verwischen.
• Multiplizieren Sie mit einem Decay, filtern Sie nicht mit einem Cutoff. Und setzen Sie die Halbwertszeit pro Dokumentklasse, denn Ihr Changelog und Ihre Normensammlung altern nicht gleich schnell.
• Messen Sie Latest@k getrennt. Ihre bestehende Eval-Suite meldet gerade jetzt Grün für genau den Fehler, um den es in diesem Artikel geht.

Nichts davon erfordert ein besseres Embedding-Modell. Es erfordert das Eingeständnis, dass das Embedding-Modell nie der Teil war, der wusste, wie spät es ist.