Der Index wurde teuer, bevor es jemandem auffiel
Niemand plant damit, dass der Index zum teuren Teil wird. Er beginnt als Rundungsfehler neben den Modellkosten, wächst mit dem Bestand statt mit der Nutzung, und wenn er auf einer Rechnung sichtbar wird, wächst er bereits seit einem Jahr.
Wie es sich angeschlichen hat
Das System begann mit rund zweihunderttausend Chunks, und der Vektorindex kostete neben den Modellaufrufen so wenig, dass ihn niemand in eine Grafik nahm. Drei Jahre und mehrere Dokumentquellen später hielt er etwa vier Millionen, und der Index war die zweitgrößte Position der monatlichen Infrastrukturkosten.
Das Wachstumsmuster ist die Falle. Modellkosten folgen der Nutzung, steigen also, wenn das System genutzt wird und jemand einen Nutzen davon hat. Indexkosten folgen dem Bestand, steigen also, wenn Dokumente hinzukommen — ob sie jemand abfragt oder nicht.
Was wir zuerst gemessen haben
Wie viel des Bestands überhaupt je abgerufen wird. Wir haben ein Jahr Anfragen genommen und die verschiedenen Chunks in den Topergebnissen gezählt: rund elf Prozent. Weitere zwanzig Prozent waren mindestens einmal in einem weiteren Kandidatensatz aufgetaucht, und die übrigen zwei Drittel waren nie zurückgegeben worden.
Diese Zahl verschob das Gespräch von wie speichern wir vier Millionen Vektoren günstiger zu warum speichern wir alle vier Millionen in derselben Stufe. Das sind verschiedene Probleme, und das zweite hat billigere Antworten.
Das Verfahren und sein Preis
Jeong veröffentlichte Anfang 2025 eine Arbeit zur Vier-Bit-Quantisierung von Embeddings für Retrieval-Augmented Generation — der direkte Weg: jede Vektorkomponente mit geringerer Genauigkeit speichern und einen Verlust in der Ähnlichkeitsberechnung hinnehmen.
Auf unserem Bestand senkte die Quantisierung den Indexspeicher um rund drei Viertel. Die Retrieval-Qualität auf dem Referenzset fiel um etwa anderthalb Punkte beim Topergebnis und deutlich weniger bei der Frage, ob die richtige Passage irgendwo unter den ersten zehn war — die Zahl, auf die es ankommt, wenn danach ein Reranker läuft.
| Ansatz | Wirkung bei uns |
|---|---|
| Vektoren quantisieren | Drei Viertel weniger Speicher, kleiner Qualitätspreis |
| Zwei Stufen, heiß und kalt | Große Ersparnis, mehr bewegliche Teile |
| Nie Abgerufenes löschen | Verlockend und falsch. Es heißt: noch nicht |
| Weniger, bessere Chunks | Die billigste Behebung — zuletzt gemacht |
Was wir tatsächlich betreiben
Quantisierte Vektoren für den gesamten Bestand in der durchsuchbaren Stufe und volle Genauigkeit nur für das Reranking, das einige Dutzend Kandidaten sieht statt vier Millionen. Genauigkeit dort, wo die Entscheidung fein ist; Kompression dort, wo es nur darum geht, das Feld einzuengen.
Diese Anordnung hat den größten Teil des Qualitätsverlusts zurückgeholt, denn der grobe Durchgang muss nur die richtige Passage in den Kandidatensatz bringen, und der teure Vergleich findet danach auf Vektoren statt, die nie komprimiert wurden.
Die Löschung, die wir nicht vorgenommen haben
Zwei Drittel des Bestands waren nie abgerufen worden, und sie zu löschen wäre die größte verfügbare Ersparnis gewesen. Wir haben es nicht getan, denn nie abgerufen ist eine Aussage über die bisher gestellten Fragen — und wenn jemand zum ersten Mal nach einem gelöschten Dokument fragt, scheitert das System nicht sichtbar. Es antwortet aus etwas anderem.
Das ist dasselbe Prinzip wie im Rest unserer Retrieval-Arbeit: Ein fehlendes Dokument erzeugt eine selbstsichere Antwort aus benachbartem Material, und das ist schlimmer als ein teurer Index. Wir archivieren statt zu löschen, und Archiviertes bleibt auffindbar, nur langsamer.
Die Behebung, die zuerst gehört hätte
Das Chunking. Als wir endlich hinsahen, erzeugte unser Chunker erhebliche Überlappung zwischen benachbarten Chunks — eine vernünftige Voreinstellung, die vor Jahren für einen anderen Bestand gewählt und nie wieder angefasst worden war. Die Überlappung zu verringern entfernte fast ein Fünftel der Vektoren ohne messbare Qualitätsänderung.
Das ist der unspektakulärste Befund dieses Beitrags und der, den wir zuerst wiederholen würden. Bevor man komprimiert, was man speichert, prüfe man, ob man dieselben Sätze viermal speichert — denn eine Chunker-Voreinstellung ist genau die Art Entscheidung, die nie überprüft wird.
Was wir heute beobachten
Indexgröße und -kosten auf demselben Dashboard wie die Modellausgaben, mit einer Kennzahl je tausend Chunks, damit Wachstum sichtbar wird, bevor es teuer ist. Und den Anteil des Bestands, der in den letzten neunzig Tagen abgerufen wurde — das Signal dafür, dass eine Quelle hinzugefügt wurde und nicht genutzt wird.
Diese zweite Zahl hat einen Importlauf gefunden, der sieben Monate lang still einen Dokumentbestand einlas, den niemand angefragt hatte. Ihn abzuschalten sparte mehr als die Quantisierung.
Was wir nicht behaupten
Wir behaupten nicht, Quantisierung sei kostenlos. Sie kostet Retrieval-Qualität, wir haben auf unserem Bestand gemessen wie viel, und ein System ohne Reranker, der den Verlust auffängt, würde es stärker spüren als unseres.
Wir behaupten auch nicht, unsere elf Prozent Abrufquote seien typisch. Es ist ein Bestand mit einem langen Schwanz selten konsultierter technischer Dokumente, und eine Wissensbasis häufig gefragter Inhalte sähe völlig anders aus.