Unser Text-zu-Abfrage-Agent verkürzte die Bearbeitungszeit von 45 Sekunden mit Spitzenmodellen auf 2 Sekunden mit GLM 5.3 Flash – bei gleicher Genauigkeit und einem Zwanzigstel der Kosten.
Der Großteil unserer aktuellen KI-Arbeit bei Conversion konzentriert sich auf allgemeine Marketing-Intelligenz.
Marketing-Automatisierungsteams erledigen ein breites Spektrum an Aufgaben über verschiedene Systeme hinweg: Konten recherchieren, Zielgruppen aufbauen, Kampagnen planen, Inhalte erstellen und auf Leistungsdaten reagieren. Wir bauen Agenten, die über diese Workflows hinweg denken und dieselben Tools nutzen können, die ein erfahrener Marketer verwenden würde.
Diese Systeme profitieren von leistungsfähigen, universellen Modellen. Die Arbeit ist ergebnisoffen, und eine gute Urteilsfähigkeit ist oft wichtiger als die schnelle Erledigung einer Aufgabe.
Aber wir hatten auch einen Rückstand an kleineren, fokussierteren KI-Funktionen. Eine davon waren natürlichsprachliche Filter: Einem Benutzer ermöglichen, eine Zielgruppe in einfachem Englisch zu beschreiben und diese Beschreibung in einen Filter umzuwandeln, den er im bestehenden Statement-Builder von Conversion einsehen und bearbeiten kann. (In Conversion wird ein Filter als Statement bezeichnet.)
Zunächst schien dies eine einfache Aufgabe der strukturierten Generierung zu sein. Gib dem Modell die verfügbaren Felder, beschreibe das Ausgabeformat und bitte es, JSON zu produzieren. Es stellte sich als erheblich schwieriger heraus.
Komplexes Statement, generiert in unter 5 Sekunden mit GLM 5.3 Flash.
Nehmen wir das folgende Beispiel:
Finde Kontakte, die das Demo-Formular in den letzten 30 Tagen mindestens einmal abgeschickt haben und bei einem Softwareunternehmen mit einer offenen Opportunity im Wert von mehr als 50.000 $ arbeiten.
Dies erfordert, dass das System:
- Das spezifische Formular findet, das der Benutzer mit "das Demo-Formular" meint
- Bestimmt, welches Feld die Branche eines Unternehmens repräsentiert
- Herausfindet, wie dieser Workspace "Software" darstellt, was bedeutet, dass die tatsächlich in diesem Feld gespeicherten Werte überprüft werden müssen, anstatt zu raten
- Von einem Kontakt zu dessen Unternehmen und dann zu den Opportunities dieses Unternehmens navigiert
- Sicherstellt, dass "offen" und "mehr als 50.000 $" für dieselbe Opportunity gelten
- Ein relatives Ereignisfenster anwendet
Es musste dies auch alles schnell genug tun, um sich wie eine Filteroberfläche anzufühlen, nicht wie ein Recherche-Agent.
Was wie eine kleine Prompt-Engineering-Aufgabe aussah, war zu einem eingeschränkten Text-zu-Abfrage-Problem geworden. Um es zu lösen, waren ein Tool-nutzender Agent, eine Zwischendarstellung (IR), ein deterministischer Compiler und ein semantischer Benchmark erforderlich.
Wir haben acht Modelle durch den resultierenden Benchmark, Statement Bench, laufen lassen, darunter Claude Opus 5, Kimi K3, GLM 5.3 Flash und die Gemini 3.8 Flash-Veröffentlichung von heute Morgen. Die Ergebnisse sind unten aufgeführt.
Dem Agenten Werkzeuge geben
Die meisten Informationen, die zur Beantwortung der obigen Anfrage benötigt werden, sind spezifisch für die Umgebung des Kunden. Ein einzelner Workspace kann Hunderte Millionen historischer Feldwerte zusammen mit seinen Assets und Objekten enthalten. Aus offensichtlichen Gründen konnten wir nicht alles in einen Prompt packen.
Unsere erste nützliche architektonische Entscheidung war, das Problem nicht mehr als gewöhnliche strukturierte Generierung zu behandeln. Stattdessen erhält das Modell einen kleinen Satz von Tools. Es kann Felder durchsuchen, historische Werte einsehen und geschäftsspezifische Assets wie Formulare, Kampagnen, E-Mails und Zielgruppen auflösen. Es verwendet diese Tools nur, wenn die Anfrage sie erfordert.
Ein Großteil dieser Suchinfrastruktur stammt aus unserer kürzlichen Global Search-Arbeit, die Text- und semantische Suche über alle Datensätze in Conversion ermöglicht. Wir planen, bald mehr dazu zu teilen!
Der grundlegende Ablauf sieht wie folgt aus:
1Natürlichsprachliche Anfrage2 |3 v4 Tool-nutzender Agent <-----------------+5 / | \ |6Felder Assets Beziehungen | Ablehnung mit Gründen7 \ | / |8 v |9 Eingeschränkte IR |10 | |11 v |12 Validator und Compiler ---------------+13 |14 v15 Produktions-Statement
Dies hält den anfänglichen Kontext klein. Es macht Fehler auch viel leichter verständlich. Wenn ein Statement falsch ist, können wir feststellen, ob der Agent das falsche Asset gefunden, das falsche Feld ausgewählt, eine Beziehung missverstanden, die richtige Idee falsch dargestellt oder einen Fehler im Compiler offengelegt hat. Diese Unterscheidung wurde später für unsere Evaluierungsschleife wichtig.
Eine kleinere Sprache erschaffen
Die Tool-Nutzung löste das Kontextproblem. Sie löste nicht die Latenz.
Eine Lehre aus frühem Feedback: Benutzer tolerieren weitaus weniger Latenz in einer zweckgebundenen Oberfläche als im Chat.
Dies weist auf ein breiteres Paradoxon hin. Wir setzen Latenzerwartungen basierend darauf, wie schwierig uns eine Aufgabe erscheint, nicht darauf, wie schwierig sie für das System ist. Das Schreiben von Inhalten fühlt sich schwierig an, weil wir die Arbeit sehen. Das Beschreiben eines Filters fühlt sich einfach an, weil unser Geist Kontext, Entitäten, Beziehungen und Absichten stillschweigend auflöst. Für das Modell ist die Rekonstruktion dieser verborgenen Annahmen die Aufgabe. Je weniger Arbeit der Benutzer wahrnimmt, desto weniger Zeit geben sie dem System, sie zu erledigen.
Basierend auf frühem Feedback setzten wir zwei Ziele: mehr als 95 Prozent Genauigkeit und eine Antwortzeit von etwa 5 Sekunden für häufige Abfragen.
Conversion hat eine ausdrucksstarke interne Abfragesprache. In unseren frühen Tests, bei direkter Verwendung des Produktionsformats, konnten nur die größten Modelle wie Claude Opus sie zuverlässig generieren. Selbst einfache Statements dauerten etwa 45 Sekunden.
Der visuelle Statement-Builder legt nur eine Teilmenge der vollständigen Sprache offen. Wir erstellten eine kleinere, agentenfreundliche Zwischendarstellung für diese Teilmenge. Kleinere Modelle konnten sie mit weniger Tokens produzieren, während ein deterministischer Compiler das vollständige Produktionsformat handhabte.
Betrachten Sie das Statement:
Jobtitel enthält "Director".
Das ursprüngliche Produktions-Statement sieht so aus:
1{2 "type": "LOGICAL",3 "version": 1,4 "logical": {5 "operator": "OR",6 "operands": [7 {8 "type": "LOGICAL",9 "version": 1,10 "logical": {11 "operator": "AND",12 "operands": [13 {14 "type": "VARIABLE",15 "version": 1,16 "variable": {17 "variableSchemaId": "550e8400-e29b-41d4-a716-446655440000",18 "where": {19 "type": "LOGICAL",20 "version": 1,21 "logical": {22 "operator": "AND",23 "operands": [24 {25 "type": "LOGICAL",26 "version": 1,27 "logical": {28 "operator": "CONTAINS",29 "operands": [30 {31 "type": "ATTRIBUTE",32 "version": 1,33 "attribute": {34 "name": "value"35 }36 },37 {38 "type": "CONSTANT",39 "version": 1,40 "constant": {41 "value": "Director"42 }43 }44 ]45 }46 }47 ]48 }49 }50 }51 }52 ]53 }54 }55 ]56 }57}
Die modellseitige Darstellung desselben Filters ist:
1{2 "field": "550e8400-e29b-41d4-a716-446655440000",3 "op": "contains",4 "value": "Director"5}
Die IR hat bereits mehrere Generationen durchlaufen, und die neueste wurde dadurch geprägt, dass kleine Modelle an früheren Versionen scheiterten. Eine große Verbesserung war die Einführung einer besseren Same-Record-Semantik (etwas, das die Schema-Validierung nicht abfangen kann):
1{2 "related": "OPPORTUNITY",3 "all": [4 { "field": "<stage uuid>", "op": "equals", "value": "Closed Won" },5 { "field": "<amount uuid>", "op": "gt", "value": 100000 }6 ]7}
Diese Aufteilung zwischen Modell und Code gab uns einige nützliche Eigenschaften:
- Nicht unterstützte Statements sind schwer auszudrücken
- Same-Record-Beziehungssemantik ist sichtbar
- Feld- und Beziehungsreferenzen können validiert werden
- Der Compiler kann unabhängig vom Modell getestet werden
- Generierte Statements bleiben in der bestehenden Benutzeroberfläche bearbeitbar
Die IR reduziert letztlich die Aufgabe des Modells: Der Agent löst die Absicht des Benutzers auf und erstellt einen eingeschränkten Plan; der Code übernimmt das Produktionsformat.
Aufbau eines semantischen Benchmarks
Eine Ausgabe kann vollständig gültig und dennoch falsch sein. Nehmen Sie diese Anfrage:
Kontakte bei Unternehmen mit einer gewonnenen Opportunity im Wert von mehr als 100.000 $.
Ein Kontakt gehört zu einem Unternehmen, und ein Unternehmen kann viele Opportunities haben. Das Abgleichen dieses Filters bedeutet, Beziehungen zu durchlaufen (Kontakt zu Unternehmen, Unternehmen zu Opportunities) und dabei zwei Bedingungen zu prüfen: Der Deal ist gewonnen, und der Deal ist mehr als 100.000 $ wert.
Die Schwierigkeit besteht darin, dass diese Bedingungen für dieselbe Opportunity gelten müssen. Wenn sie unabhängig voneinander geprüft werden, erfüllt ein Unternehmen mit einem gewonnenen 20.000 $-Deal und einem offenen 150.000 $-Deal beide: Eine Bedingung trifft auf jeden zu. Die Schema-Validierung wird dies nie abfangen.
Sobald einige solcher Beispiele bestanden wurden, riskierte die Bearbeitung des Prompts, sie zu verschlechtern. Wir brauchten eine Möglichkeit, die Bedeutung zu überprüfen, nicht nur die Gültigkeit, und dies jedes Mal zu tun, wenn sich etwas änderte.
Wir haben Statement Bench um das Verhalten des Produkts herum aufgebaut, abgeleitet von anonymisierten Zielgruppenmustern, die unsere Kunden zuvor erstellt hatten. Die Suite umfasst jetzt 100 Fälle in fünfzehn Kategorien wie einfache Feldbedingungen, Ereignisse, relative und kalendarische Zeitfenster, Beziehungen und zusammengesetzte Abfragen.
Jeder Fall wird gegen eine realistische Workspace-Sandbox ausgeführt. Der Agent erhält dieselben Daten und Tools wie in der Produktion.
Der Evaluator prüft mehrere Ebenen:
- Hat der Agent ein Statement zurückgegeben?
- Erfüllt die IR ihr Schema?
- Existieren die referenzierten Felder und Beziehungen?
- Kann das Statement kompilieren und die Produktionsvalidierung bestehen?
- Stellt es die angeforderte Bedeutung dar?
- Wie viele Modellschritte, Tool-Aufrufe, Tokens und abgelehnte Einreichungen waren erforderlich?
Die fünfte ist die interessanteste, da Gültigkeit keine semantische Gleichheit garantiert.
Die semantischen Prüfungen lesen das kompilierte Statement und stellen Dinge fest wie "eine Opportunity-Bedingung, die sowohl die Phase als auch den Betrag trägt", "ein E-Mail-Ereignis, dessen Typ ein Klick ist, kein Öffnen" oder "eine Webinar-Bedingung anstelle einer benutzerdefinierten Kampagnenbedingung".
Durchführen einer eval-gesteuerten Optimierungsschleife
Der Benchmark veränderte, wie wir an der Funktion weiterarbeiten konnten. Anstatt einen Coding-Agenten zu bitten, "den Prompt zu verbessern" oder "eine neue IR zu implementieren", konnten wir ihm eine ausführbare Definition von Verbesserung geben.
Die Schleife sah so aus:
- Führe den Benchmark aus
- Gruppiere Fehler nach ihrer zugrunde liegenden Ursache
- Untersuche die Tool-Trajektorie des Agenten und die eingereichte IR
- Ändere den Prompt, die Tools, die Validatoren oder den Compiler
- Führe den vollständigen Benchmark erneut aus
- Behalte die Änderung nur, wenn sie das System verbessert, ohne Regressionen einzuführen
Coding-Agenten konnten den Benchmark verwenden, um Modelle zu vergleichen, mit der IR zu experimentieren, Tool-Beschreibungen zu verbessern und den Prompt autonom zu verfeinern. Das Ausführen der vollständigen Suite nach jeder Änderung verhinderte auch, dass wir uns zu sehr an einzelne Fehler anpassten, und wir hielten weitere 50 Fälle zurück, um dies zu bestätigen.
Einige Änderungen verbesserten die Ergebnisse am meisten:
- Verschiebe Pfade, Typen und Struktur in den Compiler. Unsere erste IR ließ das Modell alle Beziehungen explizit ausschreiben: Kontakt zu Unternehmen, Unternehmen zu Opportunity. Die Metadaten des Feldes implizieren diesen Pfad bereits, sodass der Compiler ihn jetzt ableitet. Dasselbe haben wir für Daten, Typumwandlung, Negationsplatzierung und Gruppenverschachtelung getan. Das Verschieben von Regeln in den Compiler vereinfachte die IR und reduzierte Schemafehler.
- Lehne mit Erklärungen und Korrekturen ab. Jede Schema- und Compiler-Ablehnung sagt, was stattdessen geschrieben werden soll (wenn verfügbar): "gt kann für dieses Feld nicht negiert werden; verwende lte", "kopiere die ID aus campaign_list". Kleine Modelle konvergieren nach ein oder zwei Wiederholungen, und das Produktionsmodell wird bei wenigen Anfragen pro Hundert abgelehnt.
- Strukturiere den Prompt für kleine Modelle. Die Neustrukturierung des Prompts änderte die Genauigkeit nicht, halbierte aber die Anzahl der Wiederholungen, was die Latenz direkt verbesserte. Dies wurde inspiriert von den Prompting Best Practices von Anthropic.
- Verwende Beispiele anstelle von Prosa. Zwei zusätzliche Beispiele in unserer Formatreferenz behoben eine Klasse von Fehlern, die Absätze von Erklärungen nicht behoben hatten, und reduzierten abgelehnte Einreichungen um etwa die Hälfte.
- Gib vollständigen Kontext oder gar keinen. Modelle greifen auf das im Kontext Befindliche zu, bevor sie ein Tool aufrufen. Wenn der Kontext einen teilweisen oder unbeschrifteten Satz von Feldern enthielt, verwendete das Modell das nächstgelegene, anstatt zu suchen, was semantisch falsche Statements produzierte. Durch die Reduzierung von Teilkontext zugunsten von Tool-Aufrufen erhöhten wir die Build-Raten und reduzierten die Eingabe-Tokens um ein Fünftel.
Die endgültige Produktionskonfiguration, GLM 5.3 Flash, absolvierte alle 100 Benchmark-Fälle mit einer medianen Latenz von 2,3 Sekunden und einem 95. Perzentil von 7,1 Sekunden. Und 97 der 100 waren semantisch korrekt. Im Vergleich zum ursprünglichen Produktionsformat-Ansatz hatten sich einfache Filter von etwa 45 Sekunden auf etwas über eine Sekunde bei einem Zwanzigstel der Kosten verbessert.
Vergleich von Modellen auf Statement Bench
Der Benchmark gab uns auch eine Möglichkeit, Modelle bei der eigentlichen Aufgabe zu vergleichen.
Am 2. September 2026 ließen wir dieselben 100 Fälle über acht Modelle laufen. Jedes Modell erhielt denselben Prompt, dieselben Tools, dieselbe IR, denselben Compiler und ein 30-Sekunden-Request-Timeout.
Provider-Routing, Prompt-Caching und temporäre Inferenzlast beeinflussen alle die Latenz.
Modell
Gültige Builds
Semantisch korrekt
P50 Latenz
P95 Latenz
Cache-Read
Tool-Aufrufe
Abgelehnte Einreichungen
Geschätzte Kosten pro 1.000 Anfragen
Claude Opus 5
100/100 (100%)
100/100 (100%)
3,16s
8,53s
91,1%
162
0
27,51 $
GLM 5.2
100/100 (100%)
100/100 (100%)
4,38s
13,02s
93,5%
201
5
14,94 $
Kimi K3
100/100 (100%)
100/100 (100%)
5,17s
11,84s
34,3%
157
0
48,51 $
GLM 5.3 Flash
100/100 (100%)
97/100 (97%)
2,34s
7,07s
92,8%
163
2
1,33 $
DeepSeek V4 Pro
96/100 (96%)
96/96 (100%)
5,53s
24,31s
47,8%
172
1
12,00 $
Gemini 3.7 Flash
77/100 (77%)
77/77 (100%)
15,14s
30,01s
26,5%
228
1
18,24 $
Gemini 3.8 Flash
76/100 (76%)
76/76 (100%)
14,29s
30,01s
35,4%
266
1
27,44 $
DeepSeek V4 Flash
56/100 (56%)
55/56 (98%)
6,79s
30,00s
41,5%
100
1
0,56 $
Geschätzte Kosten pro 1.000 versuchte Anfragen unter Verwendung der beobachteten Eingabe-, Cache-Eingabe- und Ausgabe-Tokens zum jeweiligen nicht-promotionalen Tarif des Anbieters am 2. September 2026. Cache-Eingabe wird zum veröffentlichten Cache-Read-Tarif abgerechnet, wenn der Anbieter einen veröffentlicht, andernfalls zum vollen Eingabetarif.
Abbildung 1. Korrektheit im Vergleich zu den Kosten. GLM 5.3 Flash erreicht 97 Prozent zu etwa einem Zwanzigstel der Kosten von Claude Opus 5.
Abbildung 2. Latenzverteilung, Median und 95. Perzentil, geordnet nach P95.
Einige Erkenntnisse stachen hervor.
Weder Modellgröße noch Preis sagten die Latenz voraus. Das schnellste Modell war das kleinste und billigste. Das zweitschnellste war das größte und teuerste.
Fehler haben sich von falschen Antworten zu langsamen Antworten verlagert. Sechs der acht Modelle waren bei jedem Statement, das sie abschlossen, semantisch korrekt; die Unterschiede zwischen ihnen liegen fast ausschließlich darin, wie viele Anfragen innerhalb des Timeouts abgeschlossen wurden. In frühen Iterationen der IR und der Prompts scheiterten die meisten kleineren Modelle am Benchmark im Build-Schritt mit <50% semantischer Genauigkeit.
Reasoning-Tokens überwiegen Tool-Aufrufe. Gemini 3.8 Flash gab 180.000 seiner 192.000 Ausgabe-Tokens für Reasoning aus und tätigte 266 Tool-Aufrufe; Claude Opus 5 gab 813 Tokens für Reasoning aus, tätigte 162 und schloss jeden Fall ab. Unsere Global Search-Bemühungen reduzierten jede Tool-Suche auf den Millisekundenbereich, sodass die verbleibenden Kosten die Runden des Modells dazwischen sind.
Fazit
Modelle sind gut darin, Mehrdeutigkeiten aufzulösen, Code ist gut darin, Präzision durchzusetzen, und die meisten unserer frühen Fehler kamen daher, dass wir das Modell baten, beides zu tun. Der Bau dieses Agenten war die Arbeit zu entscheiden, welcher der beiden welchen Teil übernehmen sollte. Wir erwarten, dass dasselbe für Text-zu-SQL und die meisten anderen natürlichsprachlichen Schnittstellen gilt.
Wenn Sie an einem dieser Probleme interessiert sind, melden Sie sich! Wir stellen ein.
