Bei der LLM-Anreicherung sind die Tokens der Kostenfaktor. Entity Enricher ist darauf ausgelegt, so wenige abgerechnete Tokens wie möglich zu senden, ohne die Genauigkeit zu beeinträchtigen – angeführt vom Prompt-Caching und unterstützt durch Schema-Scoping, intelligentes Gating und weniger vergeudete Wiederholungen. Das meiste geschieht automatisch; nichts davon erfordert zusätzliche Konfiguration.
Jeder Anreicherungsaufruf bezahlt für Eingabe-Tokens (Ihr Prompt, das Schema und alle angehängten Dokumente), Ausgabe-Tokens (das strukturierte Ergebnis) und — falls aktiviert — Websuche-Abfragen. Der größte, sich am häufigsten wiederholende Teil ist normalerweise die Eingabe: Dieselben Systemanweisungen, die Schema-Beschreibung und die Quelldokumente werden bei jedem Aufruf erneut gesendet. Das Zwischenspeichern dieser gemeinsamen Eingabe ist der größte einzelne Hebel, deshalb kommt es zuerst.
Prompt + Schema + Anhänge. Groß und über Aufrufe hinweg sehr repetitiv – das Hauptziel für Caching und Scoping.
Das strukturierte Ergebnis. Schlank gehalten, indem jedes Modell nur nach den Feldern gefragt wird, für die es tatsächlich zuständig ist.
Fehlgeschlagene Wiederholungen, Rate-Limit-Überlastung und das Anreichern der falschen Entität. Von vornherein vermieden, statt dafür zu bezahlen.
Wenn eine Anreicherung mit mehreren Fachbereichen läuft, führt sie mehrere LLM-Aufrufe für dieselbe Entität aus — einen pro Fachbereich. Jeder dieser Aufrufe teilt denselben einleitenden Kontext: die generischen Systemanweisungen und alle angehängten Inline-Text-Dokumente. Entity Enricher hält diesen gemeinsamen Präfix über alle Aufrufe hinweg Byte für Byte identisch und markiert ihn als cachefähig, sodass der Provider ihn einmal speichert und bei jedem weiteren Aufruf zu etwa einem Zehntel des normalen Eingabepreises erneut liest.
Jeder der N Aufrufe sendet den vollständigen geteilten Kontext erneut zum vollen Eingabepreis. Fünf Expertise-Domänen bedeuten, dass Sie diesen großen geteilten Block fünfmal bezahlen.
Der gemeinsame Block wird einmal in den Cache geschrieben und dann bei den anderen vier Aufrufen zu ~10 % des Eingabepreises zurückgelesen. Die Einsparungen wachsen mit jedem zusätzlichen Fachbereich, jeder Sprache und jedem angehängten Dokument.
Provider-Caches sind erst nachdem die erste schreibende Anfrage abgeschlossen ist lesbar. Würden alle Expertise-Aufrufe gleichzeitig starten, fände keiner einen warmen Cache und jeder würde redundant seine eigene Kopie schreiben. Wenn Caching zutrifft, läuft der erste Aufruf daher allein, es wird ein kurzer Moment für die Verbreitung des Caches gewährt, und erst dann werden die übrigen Aufrufe parallel gestartet — sodass jeder den warmen Cache liest, statt für dessen erneutes Schreiben zu bezahlen.
Anthropic-Modelle cachen die gemeinsamen Anweisungen explizit; angehängte PDFs und Bilder werden direkt zwischengespeichert; und Anbieter mit automatischem Präfix-Caching (OpenAI, xAI, DeepSeek und andere) profitieren vom selben byte-identischen Präfix. Caching lohnt sich am meisten genau dann, wenn die Eingabe groß ist – viele Expertisen, mehrere Sprachen oder angehängte Dokumente.
Die Kostenabrechnung ist cache-bewusst: Zwischengespeicherte Eingabe-Tokens werden zum Cache-Lese-Tarif des Modells abgerechnet (ein Bruchteil des Eingabetarifs), und nur die tatsächlich neuen Tokens werden zum vollen Preis berechnet. Die Einsparungen erscheinen direkt in Ihren Kostenanalysen, nicht nur in der Theorie.
Über das Caching des gemeinsamen Präfixes hinaus verkleinert Entity Enricher den Teil jedes Aufrufs, der nicht gemeinsam genutzt wird.
Jeder Expertise-Aufruf erhält nur den Ausschnitt des Schemas, für den er zuständig ist, und nicht das gesamte Schema.
Ein Finanzexperte sieht die regulatorischen Felder nie. Weniger Felder bedeuten weniger Tokens ein- und ausgehend – und die Antwort wird vor dem Zusammenführen auf ihren Ausschnitt zurückgeschnitten.
Wenn Dokumente angehängt sind und Sie sich nicht für einen strikten Structured-Output-Modus entschieden haben, existiert die Feldliste nur im lesbaren Prompt – es wird kein Schema über die Leitung dupliziert.
Dadurch werden die Schema-Tokens vollständig weggelassen und das gemeinsame Präfix bleibt identisch (sodass es besser zwischengespeichert wird). Die Antwort wird weiterhin clientseitig validiert, mit automatischer Selbstkorrektur bei Abweichungen.
Die optionale Vorab-Classification führt ein einzelnes, günstiges, schnelles Modell aus, um zu prüfen, ob eine Entity tatsächlich zu Ihrem Schema passt, bevor eine teure Multi-Modell-Enrichment beginnt. Eine Nichtübereinstimmung – etwa ein Mond, der an ein „Planet“-Schema gesendet wird – wird für den Bruchteil eines Cents erkannt, statt eine vollständige Enrichment über mehrere Premium-Modelle zu verbrennen.
Sie ist nicht blockierend (schlägt die Prüfung fehl, wird die Anreicherung trotzdem fortgesetzt) und abbrechbar, sodass Sie nie für Modelle zu zahlen beginnen, die Sie überspringen wollten.
Eine fehlgeschlagene Validierungsrunde ist ein LLM-Aufruf zum vollen Preis, ohne greifbares Ergebnis. Zwei Mechanismen sorgen dafür, dass Wiederholungen selten und produktiv bleiben.
Häufige Eigenheiten von LLM-Ausgaben – indexbasierte Objekte, die eigentlich Arrays sein sollten, der String ‚null‘, versprengte maskierte Anführungszeichen – werden vor der Validierung korrigiert.
Viele potenzielle Validierungsfehler werden stillschweigend behoben, sodass sie gar keinen kostenpflichtigen erneuten Versuch auslösen.
Wenn ein erneuter Versuch tatsächlich nötig ist, wird der genaue Validierungsfehler an das Modell zurückgemeldet, damit es dieses spezifische Problem beheben kann.
Klares, spezifisches Feedback erhöht die Chance, dass der nächste Versuch gelingt, anstatt Versuche mit vagen Hinweisen zu verschwenden.
Der Einzeldurchlauf ist bei kleinen Schemas am günstigsten; Multi-Expertise ist für große Schemas konzipiert, bei denen sich Caching und die Eingrenzung pro Expertise mehr als auszahlen und die zusätzlichen Aufrufe rechtfertigen. Siehe Strategien, wann Sie welche verwenden sollten.
Ein Parallelitätslimit pro Anbieter verhindert, dass Jobs einen Anbieter mit Anfragen überhäufen und Rate-Limit-Fehler auslösen, die sonst Backoff und Wiederholungen nach sich ziehen würden – verschwendete Tokens und verschwendete Zeit. Gedrosselte, gleichmäßige Parallelität ist günstiger, als gegen 429er anzukämpfen.
Jede Anreicherung erfasst ihre tatsächlichen Token-Zahlen — einschließlich zwischengespeicherter Lesevorgänge — und die daraus resultierenden Kosten. Das Kosten-Dashboard verwandelt dies in Zeitreihendiagramme und Aufschlüsselungen pro Modell, sodass Sie genau sehen können, wohin die Ausgaben fließen, und bestätigen können, dass Zwischenspeicherung und Eingrenzung ihre Aufgabe erfüllen. Der Preis, den Sie sehen, ist der Preis, der Ihnen berechnet wird; rohe Provider-Kosten und etwaige Plattform-Aufschläge werden transparent gehalten.