Ihr Embedding-Stack zwingt zu einem 100%igen Re-Index, nur um die Modelle zu wechseln. Und die meisten Teams betrachten das als unvermeidlich. Stellen Sie sich vor, Sie haben eine RAG-Pipeline mit einem großen Embedding-Modell für hohe Abrufqualität erstellt, und es wird in die Produktion geschickt. Sechs Monate später steigen der Anwendungsverkehr und die Kosten für Ihr Embedding-Modell in die Höhe, während Ihre Pipeline Schwierigkeiten hat, zu skalieren. Sie möchten zu einem Modell wechseln, das Kosten und Latenz priorisiert, um dieser neuen Nachfrage gerecht zu werden. Aber Ihre bestehenden Embeddings leben in einem Vektorraum, während das neue Modell Embeddings in einem anderen erzeugt, was sie inkompatibel macht. Der Wechsel der Modelle bedeutet jetzt, dass der Index neu aufgebaut werden muss: - Jedes Dokument muss neu eingebettet werden - Jeder Chunk muss neu berechnet werden - Millionen von Vektoren müssen regeneriert werden, bevor Abfragen wieder funktionieren Die meisten Teams sehen sich das an und entscheiden sich, die Kosten zu absorbieren, anstatt zu wechseln. Im Laufe der Zeit wird dies zu einer unausgesprochenen Regel. Entweder optimieren Sie für Qualität oder Sie optimieren für Kosten, und Sie leben mit der Entscheidung, die Sie früh getroffen haben. Aber das ist keine grundlegende Einschränkung von Embeddings. Es ist eine Designentscheidung. Was wäre, wenn Embedding-Modelle denselben Vektorraum teilen würden? In diesem Setup könnten Sie Dokumente mit einem großen Modell indizieren und sie mit einem leichteren abfragen, ohne etwas neu aufzubauen. ...