Cohere Embed 4: So messen Sie die Kosten einer nützlichen Suche

Die wirtschaftliche Frage lautet nicht: Was kostet ein Aufruf?

Die Kosten für ein Embedding-Modell werden üblicherweise anhand einer Abrechnungseinheit angegeben, die vom Zugangskanal abhängt. Selbst wenn dieser Wert bestätigt ist, beantwortet er nicht die entscheidende Frage für ein Suchteam: Wie viel kostet es, Ergebnisse zu erhalten, die für die Nutzerinnen und Nutzer einen festgelegten Nutzen erfüllen? Ein günstiger Aufruf kann wenig relevante Suchergebnisse liefern. Eine teurere Konfiguration könnte die Ergebnisse verbessern, wäre aber nur dann wirtschaftlich vorzuziehen, wenn diese Verbesserung im eigenen Korpus und bei den tatsächlich verwendeten Suchanfragen einen messbaren Wert hat.

Es empfiehlt sich, drei Fragen getrennt zu betrachten. Erstens die kommerzielle Frage: Welches konkrete Produkt wird über welchen Anbieter oder Zugangskanal abgerechnet, mit welcher Einheit und unter welchen Bedingungen? Zweitens die technische Frage: Welche Suchqualität erreicht die getestete Konfiguration? Drittens die betriebliche Frage: Welche weiteren Komponenten, etwa Speicher oder Suchinfrastruktur, gehören zu den Gesamtkosten? Werden diese Fragen zu einer einzigen Zahl vermischt, kann ein Vergleich fundiert wirken, obwohl die Daten ihn nicht tragen.

Die für diesen Artikel bereitgestellten Belege bestätigen weder einen konkreten Preis für Embed 4 Small oder Medium noch deren Abrechnungseinheit. Daher lässt sich auf dieser Grundlage keine Rangfolge der Varianten nach Kosten veröffentlichen. Möglich ist jedoch, einen reproduzierbaren Test zu entwerfen und genau festzulegen, welche Angaben vor einem wirtschaftlichen Vergleich erhoben werden müssen.

Was vor einem Vergleich von Small und Medium zu prüfen ist

Bevor Sie einen wirtschaftlichen Test durchführen, dokumentieren Sie die genaue Modellkennung, die vorgesehene Variante und den Zugangskanal. Gehen Sie nicht davon aus, dass ein Preis von Cohere auch für einen Cloud-Dienst gilt, der das Modell anbietet, oder dass die Bedingungen eines Anbieters auf einen anderen übertragbar sind. Die verfügbare Dokumentation weist Embed 4 in den Diensten Azure AI, Amazon Bedrock und Oracle Cloud Infrastructure aus. Die bereitgestellten Informationen belegen jedoch nicht, dass dort dieselben Zugangs- oder Abrechnungsbedingungen gelten.

Prüfen Sie für jeden Zugangskanal anhand einer offiziellen Quelle den aktuellen Preis, die Abrechnungseinheit, etwaige Mindestbeträge oder zusätzliche Gebühren, das Datum der Prüfung und die Frage, ob der Preis zwischen den Varianten unterscheidet. Bewahren Sie eine Kopie oder einen nachvollziehbaren Vermerk der geprüften Angaben auf: Preise können sich ändern, und das Prüfdatum ist Teil des Vergleichs. Wird der Preis in einer anderen Einheit angegeben als beim Vergleichskanal, rechnen Sie die Werte nicht anhand vermeintlicher Entsprechungen um, die von der Dokumentation nicht gestützt werden.

Klären Sie außerdem, was als abrechenbare Eingabe gilt und ob sich die Behandlung je nach Modalität oder Konfiguration unterscheidet. Die Dokumentation eines Dienstes kann Parameter oder Anfragegrenzen beschreiben, belegt dadurch aber nicht automatisch, wie die Rechnung berechnet wird. Wenn sich der Zusammenhang zwischen einer technischen Grenze und der kommerziellen Abrechnungseinheit nicht bestätigen lässt, müssen diese Angaben getrennt bleiben.

Einen Test entwerfen, der die tatsächliche Arbeit abbildet

Ein aussagekräftiger Vergleich beginnt mit einem repräsentativen Korpus, nicht mit einer Sammlung, die eine Variante begünstigt. Nehmen Sie Dokumente, Suchanfragen und Nutzungsmuster auf, die dem späteren Produktivbetrieb ähneln: relevante Sprachen, Textlängen, Inhaltstypen und schwierige Fälle. Wenn die Anwendung multimodale Inhalte durchsucht, beziehen Sie diese nur dann ein, wenn sich der Test unter klaren Bedingungen mit dem jeweiligen Zugangskanal und der dazugehörigen Dokumentation durchführen lässt.

Legen Sie vor der Messung fest, was als nützliches Suchergebnis gilt. Das Team kann beispielsweise bestimmen, welche Ergebnisse für eine Anfrage relevant sind und welche relative Reihenfolge erwartet wird. Entscheidend ist nicht, eine Metrik aus Gewohnheit zu übernehmen, sondern das Kriterium zu dokumentieren und für alle Varianten gleich anzuwenden. Anfragen, die zum Anpassen der Konfiguration dienen, sollten nicht mit den Anfragen für die abschließende Bewertung vermischt werden. Getrennte Datensätze helfen zu vermeiden, dass das Ergebnis lediglich Entscheidungen widerspiegelt, die anhand derselben Fälle getroffen wurden.

Auch für Relevanzbewertungen ist ein ausdrückliches Verfahren erforderlich. Halten Sie fest, wer bewertet, welche Anweisungen diese Personen erhalten und wie Uneinigkeiten geklärt werden. Stimmen mehrere Bewertende nicht überein, muss diese Unsicherheit in der Analyse erhalten bleiben. Ein zusammengefasster Wert gleicht uneinheitliche Kennzeichnungen nicht aus und macht aus einer kleinen Stichprobe keine schlüssigen Belege.

Zuerst die Qualität pro Suchanfrage messen, dann zusammenfassen

Die praktische Analyseeinheit ist jede einzelne bewertete Suchanfrage. Dokumentieren Sie für jede Anfrage, welche Ergebnisse die Konfiguration geliefert hat, welche davon als relevant bewertet wurden und ob das vereinbarte Kriterium erfüllt wurde. Je nach Ziel des Systems kann es wichtig sein, ob unter den ersten Treffern relevante Ergebnisse erscheinen, ob alle relevanten Inhalte abgedeckt werden oder wie gut die Reihenfolge der Ergebnisse ist. Welche Messgröße passt, hängt von der späteren Verwendung der Suche ab. Keine einzelne Metrik sollte als allgemein ausreichend dargestellt werden.

Nachdem die Ergebnisse pro Anfrage geprüft wurden, können Sie für den gesamten Datensatz eine Zusammenfassung berechnen. Bewahren Sie zugleich die Verteilung auf. Zwei Varianten können ähnliche Durchschnittswerte erreichen und sich dennoch bei schwierigen Anfragen, bestimmten Sprachen oder Dokumenttypen deutlich unterscheiden. Die Betrachtung solcher Fälle hilft zu erkennen, ob eine allgemeine Verbesserung zulasten einer Nutzergruppe oder eines Teils des Korpus geht.

Legen Sie eine Akzeptanzschwelle fest, bevor Sie die Ergebnisse des Vergleichs sehen. Definiert das Team die Schwelle erst neu, nachdem bekannt ist, welche Variante darüber liegt, ist der Test nicht mehr neutral. Wenn Stichprobe oder Bewertungen nicht ausreichen, um einen kleinen Unterschied vom Zufall zu unterscheiden, sollte das Ergebnis als nicht eindeutig beschrieben werden. Eine numerische Abweichung ist ohne ausreichende Belege keine nachgewiesene Verbesserung.

Die Kosten für das Erreichen der Schwelle berechnen

Sobald Abrechnungseinheit und Preis des jeweiligen Zugangskanals verifiziert sind, berechnen Sie getrennt die Kostenbestandteile, die sich anhand der verfügbaren Belege quantifizieren lassen. Gilt der Preis für die Erstellung von Embeddings, dokumentieren Sie das tatsächlich verarbeitete Volumen und wenden die veröffentlichte Einheit auf dieses Volumen an. Setzen Sie keine vermutete Einheit in die Rechnung ein und stellen Sie eine Schätzung nicht als tatsächlich angefallene Kosten dar. Veröffentlicht der Zugangskanal nicht die nötigen Bedingungen, um die Berechnung zu reproduzieren, weisen Sie darauf hin, dass sich die Kosten mit den verfügbaren Angaben nicht berechnen lassen.

Um das Ergebnis als Kosten pro Suchergebnis auszudrücken, das das Ziel erfüllt, muss der Nenner eindeutig definiert sein. Das kann die Zahl der Evaluationsanfragen sein, bei denen die getestete Konfiguration die Relevanzschwelle erreicht. Der Zähler muss sich auf die zugerechneten Ausgaben und denselben Zeitraum oder Arbeitsumfang beziehen. Decken die gemessenen Kosten nur die anfängliche Erstellung der Embeddings ab, sollten Sie sie nicht als vollständige Kosten jeder Anfrage ausgeben, ohne zu erläutern, wie die Ausgaben verteilt werden und welche Annahmen dieser Verteilung zugrunde liegen.

Veröffentlichen Sie nach Möglichkeit die Zwischenwerte und nicht nur das Endverhältnis: verarbeitetes Volumen, zurechenbare Kosten, Zahl der bewerteten Suchanfragen und Zahl der Anfragen, die das Kriterium erfüllen. So können andere Personen die Berechnung prüfen und Annahmen ändern, etwa zur Korpusgröße oder zur Aktualisierungshäufigkeit. Eine einzelne Zahl ohne diese Angaben kann Unterschiede im Umfang der verglichenen Varianten verbergen.

Text und weitere Modalitäten erfordern vergleichbare Bedingungen

Die verfügbaren Quellen beschreiben Embed 4 als multimodales Modell und erwähnen, dass in bestimmten Diensten mit Text und Bildern gearbeitet werden kann. Diese allgemeine Beschreibung reicht nicht aus, um zu folgern, dass eine multimodale Evaluation über verschiedene Zugangskanäle hinweg unmittelbar vergleichbar ist oder dass alle dieselben Eingabebedingungen, Parameter und Abrechnungsregeln bieten. Der Test muss angeben, welcher Dienst verwendet wird und welche Formate er in diesem Kontext unterstützt.

Für einen Texttest sollten Sie Suchanfragen und Dokumente verwenden, die zur Anwendung passen. Bei Bildern oder gemischten Text- und Bildinhalten müssen Sie Material, Suchanfragen und Relevanzkriterien für diese Modalität festlegen und bestätigen, dass der gewählte Dienst diese Eingaben unterstützt. Vermischen Sie Text- und multimodale Ergebnisse nicht zu einem einzelnen Wert, wenn sich Stichprobenzusammensetzung oder Kostenumfang unterscheiden.

Technische Grenzen, die ein Anbieter dokumentiert, dürfen ebenfalls nicht auf einen anderen übertragen werden. Die Quellen zu Oracle beziehen sich auf Embed 4 in OCI; die Dokumentation von Amazon Bedrock gilt für Bedrock, und der Eintrag von Azure AI für dessen Katalog. Prüfen Sie vor Verwendung einer Eingabegrenze im Testdesign, ob sie zum konkreten Dienst und Nutzungsmodus gehört, die tatsächlich getestet werden.

Unterschiede einordnen, ohne die Ergebnisse zu verallgemeinern

Ein Vergleich beschreibt ausschließlich den Korpus, die Suchanfragen, die Konfiguration und die Bedingungen, die tatsächlich geprüft wurden. Er belegt nicht automatisch, dass dieselbe Variante in einer anderen Sprache, mit einem anderen Dokumentbestand, bei einem anderen Nutzungsvolumen oder über einen anderen Dienst vorzuziehen ist. Wurde nur eine begrenzte Stichprobe untersucht, muss die Schlussfolgerung auf diese Stichprobe beschränkt bleiben und deren Einschränkungen nennen.

Untersuchen Sie fehlgeschlagene Suchanfragen und nicht nur den Durchschnitt. Eine Verbesserung, die nur bei wenigen Anfragen auftritt, kann wichtig sein, wenn diese für den Anwendungsfall kritisch sind. Sie kann aber auch instabil sein, wenn sie von einer kleinen Stichprobe oder strittigen Bewertungen abhängt. Das Team sollte vorab festlegen, welche Arten von Fehlern akzeptabel sind und welche Auswirkungen sie haben. Die wirtschaftliche Analyse ersetzt nicht die Entscheidung darüber, welches Qualitätsrisiko tragbar ist.

Verbessert eine Variante die Suche nur geringfügig, sollten Sie prüfen, ob der Unterschied größer ist als die Unsicherheit der Evaluation und ob sich dadurch der Anteil der Anfragen, die die Schwelle erreichen, tatsächlich sinnvoll verändert. Liegen keine ausreichenden Belege vor, berichten Sie, dass kein verlässlicher Unterschied festgestellt wurde. Vermeiden Sie eine eindeutige Rangfolge oder eine allgemeingültige Empfehlung auf Grundlage eines lokalen Tests.

Was tun, wenn sich die Preise nicht vergleichen lassen?

Wenn aus offiziellen Informationen weder der Preis noch die Abrechnungseinheit oder die abgedeckte Variante eindeutig hervorgehen, erstellen Sie keine Rangliste auf Grundlage einzelner Seitenausschnitte, allgemeiner Ankündigungen oder der Preise eines anderen Zugangskanals. Die in den Quellen enthaltene Cohere-Preisseite bestätigt in den verfügbaren Materialien keinen konkreten Preis und keine Abrechnungseinheit für Embed 4 Small oder Medium. Die Ankündigung zu Entwicklerpreisen bietet Kontext zur Preisgestaltung, legt aber für sich genommen keinen Preis dieser Varianten fest.

Veröffentlichen Sie in diesem Fall nur Angaben, die tatsächlich verifiziert wurden: den getesteten Zugangskanal, das Prüfdatum, bestätigte technische Bedingungen und beobachtete Qualitätsmetriken. Benennen Sie die fehlenden kommerziellen Angaben und erläutern Sie, welche Schlussfolgerung dadurch verhindert wird. Weist ein Marketplace zwar auf eine nutzungsabhängige Abrechnung hin, nennt das geprüfte Material aber weder Einheit noch konkreten Preis, lässt sich daraus kein Preis pro Suchanfrage ableiten.

Diese Einschränkung macht den Qualitätstest nicht ungültig. Sie ermöglicht es, eine reproduzierbare technische Evaluation von einer Kostenanalyse zu trennen, die noch nicht abgeschlossen werden kann. Sobald vergleichbare offizielle Preise vorliegen, kann die Berechnung ergänzt werden, ohne die bereits erfassten Qualitätsmetriken zu ändern, sofern Volumen und Bedingungen dokumentiert wurden.

Praktische Checkliste für einen wiederholbaren Vergleich

Ein nützlicher Vergleich hinterlässt eine Dokumentation, anhand derer ein anderes Team den Test wiederholen kann. Bewahren Sie die genaue Modellkennung, den Zugangskanal und die Konfiguration auf; außerdem die Zusammensetzung von Korpus und Suchanfragen, die Anweisungen und Relevanzbewertungen, die vor der Messung festgelegten Akzeptanzkriterien sowie die Metriken pro Suchanfrage und die zusammengefassten Ergebnisse. Notieren Sie auch alle Änderungen während des Tests, denn Anpassungen können spätere Vergleiche erschweren.

Halten Sie im wirtschaftlichen Teil den geprüften offiziellen Preis, das Prüfdatum, die Einheit, die Währung und den Umfang fest, sofern diese Angaben verfügbar und eindeutig sind. Dokumentieren Sie das verarbeitete Volumen und weisen Sie Kosten für Speicher, Infrastruktur und Betrieb separat aus, soweit sie bekannt sind. Sind solche Kosten nicht dokumentierbar, lassen Sie sie aus der Rechnung heraus und kennzeichnen Sie das Ergebnis als nicht repräsentativ für die Gesamtkosten des Systems.

Legen Sie abschließend fest, wann der Test wiederholt wird. Änderungen an Preis, Zugangskanal, Variante, Konfiguration oder Korpus können das Ergebnis beeinflussen. Ziel ist nicht, dauerhaft zu etikettieren, welche Variante die günstigste ist. Ziel ist eine überprüfbare und an Belege gebundene Entscheidung: Welche Suchergebnisse erfüllen das Ziel, unter welchen Bedingungen wurden sie gemessen und welche verifizierbaren Ausgaben lassen sich ihnen zuordnen?

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.