Cohere Embed 5 trennt Indexierung und Abfrage, um die RAG-Latenz zu senken
Cohere hat Embed 5 veröffentlicht. Es ermöglicht Entwicklern, mit einem hochwertigen Pro-Modell zu indexieren und im selben Vektorraum mit einem schnelleren Fast-Modell abzufragen.
Automatisch aus dem englischen Original übersetzt.
Cohere hat am Mittwoch Embed 5 eingeführt und stellt damit eine Dual-Model-Architektur vor, die die Datenindexierung von der Abfrageausführung trennt. Dieses Update ermöglicht es Engineering-Teams, das höherwertige Embed 5 Pro für den Aufbau von Vektorindizes zu verwenden, während Live-Abfragen mit dem kostengünstigeren und durchsatzstärkeren Embed 5 Fast bedient werden – alles ohne separate Datenstrukturen pflegen zu müssen.
Was passiert ist
Die Kerninnovation dieser Veröffentlichung liegt im gemeinsamen Einbettungsraum (Embedding Space) beider Modelle. Bisher erforderte der Wechsel zu einem effizienteren Abfragemodell oft die Neuindexierung des gesamten Korpus oder die Pflege paralleler Indizes, was die Speicherkosten und die operative Komplexität verdoppelte. Mit Embed 5 können Entwickler Dokumente über das Pro-Modell aufnehmen, um eine hohe Retrieval-Qualität während der Indexierungsphase sicherzustellen. Wenn das System Benutzerabfragen bedient, wechselt es zum Fast-Modell, das innerhalb derselben Vektordimensionen und Kompatibilitätsstandards arbeitet.
Interne Tests von Cohere zeigen, dass dieser hybride Ansatz nur zu einer minimalen Verschlechterung der Retrieval-Qualität führt. Über 40 Datensätze hinweg, die Text, Bilder, fusionierte Dokumente und geparste Dokumente umfassten, erreichte die Kombination aus Pro-Indexierung und Fast-Abfrage einen relativen Score von 98,4 im Vergleich zu einem Baseline-Wert von 100 für die reine Pro-zu-Pro-Nutzung. Die Verwendung des Fast-Modells für sowohl Indexierung als auch Abfrage senkte den Score weiter auf 96,6. Das Unternehmen wies darauf hin, dass bei keinem einzelnen Datensatz ein erheblicher Leistungseinbruch bei der gemischten Pro-Fast-Konfiguration auftrat.
Dieser architektonische Wandel adressiert einen häufigen Engpass in Retrieval-Augmented Generation (RAG)-Systemen und Agent-Workflows. In diesen Systemen erfolgt die Datenaufnahme selten, Suchabfragen treten jedoch wiederholt auf und müssen latenzarm sein. Durch die Optimierung des starken Abfrageverkehrs mit dem Fast-Modell können Teams Antwortzeiten und Infrastrukturkosten erheblich reduzieren, ohne die Präzision zu opfern, die während der anfänglichen Indexierungsphase aufgebaut wurde.
Wie es funktioniert
Sowohl Embed 5 Pro als auch Fast erzeugen kompatible Vektoren mit identischen Dimensionen, sodass sie im selben Index koexistieren können. Diese Kompatibilität erstreckt sich auch auf fortschrittliche Kompressionstechniken wie Matryoshka-Truncation und int8-Quantisierung. Entwickler können aus sechs Vektordimensionen zwischen 256 und 2.048 wählen und je nach Speicher- und Präzisionsanforderungen zwischen float32-, int8- oder binären Formaten entscheiden.
Die Auswirkungen auf den Speicher sind bei großskaligen Bereitstellungen erheblich. Ein Standard-Vektor mit 2.048 Dimensionen im float32-Format belegt 8 KB, was bedeutet, dass ein Korpus von 100 Millionen Chunks etwa 819 GB erfordert. Der Wechsel zu einem int8-Vektor mit 1.024 Dimensionen reduziert diese Fußspur auf ungefähr 102 GB. Für noch höhere Effizienz schrumpft ein binärer Vektor mit 256 Dimensionen denselben Datensatz auf etwa 3,2 GB. Cohere empfiehlt das int8-Format mit 1.024 Dimensionen für die meisten Anwendungsfälle, da es Speicherersparnis mit nahezu voller Präzision beim Retrieval balanciert. Binäre Darstellungen werden für initiale Retrieval-Stadien empfohlen, in denen Geschwindigkeit kritisch ist, gefolgt von einem Reranking mit höherer Präzision.
Die Modelle unterstützen zudem multimodale Eingaben, einschließlich Text, Bildern und fusionierten Text-Bild-Kombinationen, in mehr als 100 Sprachen. Sie verfügen über ein Kontextfenster von 128K Tokens, was die direkte Verarbeitung großer Dokumente oder komplexer visueller Daten ermöglicht. Diese Fähigkeit erlaubt die Einbettung von Seitenbildern oder kombinierten Eingaben in einen einzigen Vektor und vereinfacht so die Handhabung unterschiedlicher Dokumenttypen in modernen KI-Anwendungen.
Wichtige Details
- Embed 5 Pro kostet $0,12 pro Million Tokens, während Embed 5 Fast $0,08 pro Million Tokens kostet.
- Das Fast-Modell liefert in Cohere-Tests durchschnittlich die 2,4-fache Dokumentdurchsatzrate im Vergleich zum Pro-Modell.
- Pro-Indexierung mit Fast-Abfrage erzielte einen relativen Score von 98,4 gegenüber einer Pro-zu-Pro-Baseline von 100 über 40 Datensätze hinweg.
- Beide Modelle unterstützen sechs Vektordimensionen von 256 bis 2.048 mit Optionen für float32-, int8- und binäre Formate.
- Die Modelle verarbeiten Text, Bilder und fusionierte Eingaben in mehr als 100 Sprachen mit einem Kontextfenster von 128K Tokens.
- Embed 5 ist über die Cohere-API, Model Vault, Microsoft Foundry und Amazon SageMaker verfügbar und unterstützt private VPC- sowie On-Premises-Bereitstellungen über vLLM.
Warum das wichtig ist
Für Software-Ingenieure, die RAG-Systeme entwickeln, ist die Möglichkeit, die Indexierungsqualität von der Abfragelatenz zu entkoppeln, ein erheblicher operativer Vorteil. Die meisten Produktionsumgebungen sind leseintensiv, was bedeutet, dass Kosten und Geschwindigkeit der Abfragen die Gesamtbetriebskosten dominieren. Durch die Verwendung eines günstigeren, schnelleren Modells für den hochvolumigen Abfragepfad können Teams API-Kosten senken und die Benutzererfahrung verbessern, ohne den Overhead für die Verwaltung mehrerer Indizes oder die Neuaufbereitung von Daten.
Allerdings sind die Benchmark-Ergebnisse mit wichtigen Vorbehalten verbunden. Cohere bewertete Embed 5 unter Verwendung von RCP-nDCG@10, einer Metrik, die abfragespezifische Relevanzkriterien anstelle fester Labels nutzt. Während diese Methode relevante Ergebnisse identifizieren kann, die von traditionellen Benchmarks übersehen werden, misst sie das Reranking über einem festen Kandidatensatz und nicht das First-Stage-Retrieval aus dem vollständigen Korpus. Das First-Stage-Retrieval wurde separat unter Verwendung von standardmäßigem nDCG und Recall evaluiert, was bedeutet, dass die berichteten Scores nicht direkt über alle Evaluationsarten hinweg vergleichbar sind.
Produktionsteams müssen diese Erkenntnisse gegen ihre eigenen Daten validieren. Retrieval-Fehler in Agent-Workflows können sich über mehrere Schritte kumulieren und zu erheblichen nachgelagerten Problemen führen. Daher können spezifische Domänen oder Abfragemuster anders reagieren, auch wenn der durchschnittliche Score-Verlust gering ist. Ingenieure sollten die Pro-zu-Fast-Konfiguration gegen ihren spezifischen Korpus und ihre Abfrageverteilung benchmarken, bevor sie vollständig migrieren.
Was Sie tun können
- Benchmarken Sie Ihre aktuelle RAG-Pipeline unter Verwendung von Embed 5 Pro für die Indexierung und Fast für die Abfrage, um Latenz- und Kosteneinsparungen zu messen.
- Bewerten Sie die Auswirkung verschiedener Vektordimensionen und Quantisierungsformate auf Ihre Speicherkosten und die Retrieval-Genauigkeit.
- Testen Sie multimodale Fähigkeiten durch das Einbetten von Seitenbildern oder fusionierten Text-Bild-Eingaben, wenn Ihre Anwendung unterschiedliche Dokumenttypen verarbeitet.
- Prüfen Sie Ihre Infrastruktur, um sicherzustellen, dass sie die gewählte Bereitstellungsoption unterstützt, wie z. B. vLLM für On-Premises- oder private VPC-Setups.
- Überwachen Sie die Retrieval-Qualität genau in der Produktion, insbesondere wenn Ihr Agent-Workflow mehrere sequentielle Retrieval-Schritte umfasst.
- Erwägen Sie die Verwendung binärer Vektoren für initiale Retrieval-Stadien, gefolgt von Reranking, wenn Speicherbeschränkungen eng sind.