私たちのテキスト・トゥ・クエリエージェントは、フロンティアモデルで 45 秒かかっていた処理を、GLM 5.3 Flash で 2 秒に短縮し、同じ精度でコストは 20 分の 1 になりました。
Conversion における最近の AI 関連の取り組みのほとんどは、一般的なマーケティングインテリジェンスに焦点を当てています。
マーケティングオートメーションチームは、アカウントの調査、オーディエンスの構築、キャンペーンの計画、コンテンツの作成、パフォーマンスデータに基づくアクションなど、システム全体にわたる幅広い業務を行っています。私たちは、これらのワークフロー全体で推論し、熟練したマーケターが使用するのと同じツールを使用できるエージェントを構築してきました。
これらのシステムは、有能で汎用的なモデルの恩恵を受けます。作業はオープンエンドであり、タスクを迅速に完了することよりも、適切な判断を下すことの方が重要であることがよくあります。
しかし、私たちには、より小規模で焦点を絞った AI 機能のバックログもありました。その 1 つが自然言語フィルターです。ユーザーがプレーンな英語でオーディエンスを説明し、その説明を、Conversion の既存のステートメントビルダーで検査および編集できるフィルターに変換するものです（Conversion では、フィルターはステートメントと呼ばれます）。
当初、これは単純な構造化生成タスクのように思えました。モデルに利用可能なフィールドを与え、出力形式を説明し、JSON を生成するように依頼するだけです。しかし、実際にはそれよりもはるかに難しいことが判明しました。
GLM 5.3 Flash を使用して 5 秒未満で生成された複合ステートメント。
次の例を考えてみましょう。
過去 30 日間にデモフォームを少なくとも 1 回送信し、50,000 ドル以上のオープンな商談があるソフトウェア企業で働いている連絡先を見つけてください。
これには、システムが以下を行う必要があります。
- ユーザーが「デモフォーム」という言葉で意味する特定のフォームを見つける
- どのフィールドが企業の業界を表しているかを判断する
- そのワークスペースが「ソフトウェア」をどのように表現しているかを学習する。これは、推測ではなく、そのフィールドに実際に保存されている値を調べることを意味します。
- 連絡先からその企業、そしてその企業の商談へとトラバースする
- 「オープン」と「50,000 ドル以上」が同じ商談に適用されることを確認する
- 相対的なイベントウィンドウを適用する
また、リサーチエージェントではなく、フィルターインターフェースとして感じられるほど十分に高速に、これらすべてを実行する必要がありました。
小さなプロンプトエンジニアリングタスクのように見えたものが、制約付きテキスト・トゥ・クエリ問題になっていました。これを解決するには、ツールを使用するエージェント、中間表現（IR）、決定論的コンパイラ、およびセマンティックベンチマークが必要でした。
私たちは、Claude Opus 5、Kimi K3、GLM 5.3 Flash、そして今朝リリースされた Gemini 3.8 Flash を含む 8 つのモデルを、結果として得られたベンチマーク「Statement Bench」で実行しました。結果は以下のとおりです。
エージェントにツールを提供する
上記のリクエストに答えるために必要な情報のほとんどは、顧客の環境に固有のものです。1 つのワークスペースには、そのアセットやオブジェクトとともに、数億もの履歴フィールド値を保持できます。明らかな理由から、これらすべてを 1 つのプロンプトに入れることはできませんでした。
最初の有用なアーキテクチャ上の決定は、この問題を通常の構造化生成として扱うのをやめることでした。代わりに、モデルは小さなツールセットを受け取ります。フィールドを検索したり、履歴値を検査したり、フォーム、キャンペーン、メール、オーディエンスなどのビジネス固有のアセットを解決したりできます。リクエストで必要とされる場合にのみ、これらのツールを使用します。
この検索インフラストラクチャの多くは、Conversion のすべてのレコードに対するテキスト検索とセマンティック検索を提供する、最近の Global Search の取り組みから生まれました。これについては、近日中にさらに詳しく共有する予定です！
基本的なフローは次のようになります。
1自然言語リクエスト2 |3 v4 ツール使用エージェント <-----------------+5 / | \ |6フィールド アセット リレーションシップ | 理由付き拒否7 \ | / |8 v |9 制約付き IR |10 | |11 v |12 バリデータとコンパイラ ---------------------+13 |14 v15 プロダクションステートメント
これにより、初期コンテキストは小さく保たれます。また、障害の理解がはるかに容易になります。ステートメントが間違っている場合、エージェントが間違ったアセットを見つけたのか、間違ったフィールドを選択したのか、リレーションシップを誤解したのか、正しいアイデアを誤って表現したのか、コンパイラにバグがあるのかを判断できます。この区別は、後の評価ループにとって重要になりました。
より小さな言語の作成
ツールの使用はコンテキストの問題を解決しましたが、レイテンシの問題は解決しませんでした。
初期のフィードバックからの教訓の 1 つは次のとおりです。ユーザーは、チャットよりも、目的に特化したインターフェースでのレイテンシに対してはるかに寛容ではありません。
これは、より広範なパラドックスを指摘しています。私たちは、システムにとってどれだけ難しいかではなく、自分にとってタスクがどれだけ難しいと感じるかに基づいてレイテンシの期待値を設定します。コンテンツを作成することは、作業内容がわかるため、難しく感じられます。フィルターを説明することは、私たちの心がコンテキスト、エンティティ、リレーションシップ、意図を暗黙のうちに解決するため、簡単に感じられます。モデルにとって、それらの隠れた前提を再構築することがタスクです。ユーザーが認識する作業が少なければ少ないほど、システムにそれを実行させる時間も短くなります。
初期のフィードバックに基づいて、2 つの目標を設定しました。95 パーセントを超える精度と、一般的なクエリに対する約 5 秒の応答時間です。
Conversion には、表現力豊かな内部クエリ言語があります。初期のテストでは、プロダクション形式を直接使用した場合、Claude Opus などの最大のモデルだけが確実に生成できました。単純なステートメントでも約 45 秒かかりました。
ビジュアルステートメントビルダーは、完全な言語のサブセットのみを公開します。そのサブセットに対して、より小さく、エージェントフレンドリーな中間表現を作成しました。より小さなモデルは、より少ないトークンでそれを生成でき、決定論的コンパイラが完全なプロダクション形式を処理しました。
次のステートメントを考えてみましょう。
役職に「Director」が含まれている。
元のプロダクションステートメントは次のようになります。
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}
同じフィルターのモデル向け表現は次のとおりです。
1{2 "field": "550e8400-e29b-41d4-a716-446655440000",3 "op": "contains",4 "value": "Director"5}
IR はすでにいくつかの世代を経ており、最新のものは、小さなモデルが以前の世代で失敗するのを観察することで形成されました。大きな改善点の 1 つは、より優れた同レコードセマンティクス（スキーマ検証ではキャッチできないもの）を導入したことです。
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}
モデルとコードのこの分割により、いくつかの有用な特性が得られました。
- サポートされていないステートメントは表現が難しい
- 同レコードのリレーションシップセマンティクスが可視化される
- フィールドとリレーションシップの参照を検証できる
- コンパイラをモデルとは独立してテストできる
- 生成されたステートメントは既存の UI で編集可能なままである
IR は最終的にモデルの役割を軽減します。エージェントはユーザーの意図を解決し、制約付きの計画を生成します。コードがプロダクション形式を処理します。
セマンティックベンチマークの構築
出力は完全に有効でありながら、間違っている可能性があります。次のリクエストを考えてみましょう。
10 万ドル以上の受注商談がある企業の連絡先。
連絡先は企業に属し、企業は多くの商談を持つことができます。このフィルターに一致させるには、リレーションシップ（連絡先から企業、企業から商談）をトラバースし、その過程で 2 つの条件（商談が受注済みであること、商談が 10 万ドル以上であること）をチェックする必要があります。
難しいのは、これらの条件が同じ商談に適用されなければならないことです。それらが独立してチェックされた場合、受注済みの 2 万ドルの商談とオープンな 15 万ドルの商談を持つ企業は、両方の条件を満たします。1 つの条件がそれぞれの商談に一致します。スキーマ検証ではこれを決してキャッチできません。
このような例がいくつかパスすると、プロンプトを編集するとそれらが退行するリスクがありました。意味をチェックする方法が必要でした。単なる有効性ではなく、何かが変更されるたびにそれをチェックする方法が必要でした。
私たちは、製品の動作を中心に Statement Bench を構築しました。これは、顧客が以前に構築した匿名化されたオーディエンスパターンから導き出されています。スイートには現在、プレーンフィールド条件、イベント、相対時間およびカレンダー時間ウィンドウ、リレーションシップ、複合クエリなどの 15 のカテゴリにわたる 100 のケースが含まれています。
各ケースは、現実的なワークスペースサンドボックスに対して実行されます。エージェントは、プロダクションで受け取るのと同じデータとツールを受け取ります。
評価者は、いくつかのレイヤーをチェックします。
- エージェントはステートメントを返したか？
- IR はそのスキーマを満たしているか？
- 参照されたフィールドとリレーションシップは存在するか？
- ステートメントはコンパイルされ、プロダクション検証に合格できるか？
- 要求された意味を表しているか？
- 必要なモデルステップ、ツールコール、トークン、拒否された送信はいくつか？
5 番目が最も興味深いものです。有効性はセマンティックな等価性を保証しないからです。
セマンティックチェックは、コンパイルされたステートメントを読み取り、「1 つの商談条件がステージと金額の両方を運んでいる」、「メールイベントのタイプがクリックであり、開封ではない」、「カスタムキャンペーン条件ではなくウェビナー条件である」などをアサートします。
評価駆動型最適化ループの実行
ベンチマークにより、機能の開発方法が変わりました。コーディングエージェントに「プロンプトを改善する」や「新しい IR を実装する」と依頼する代わりに、改善の実行可能な定義を与えることができました。
ループは次のようになりました。
- ベンチマークを実行する
- 失敗をその根本原因ごとにグループ化する
- エージェントのツール軌跡と送信された IR を検査する
- プロンプト、ツール、バリデータ、またはコンパイラを変更する
- 完全なベンチマークを再度実行する
- 退行を導入せずにシステムを改善する場合にのみ変更を保持する
コーディングエージェントは、ベンチマークを使用してモデルを比較し、IR を実験し、ツールの説明を改善し、プロンプトを自律的に洗練することができました。すべての変更後に完全なスイートを実行することで、個々の失敗へのオーバーフィッティングも防ぐことができ、さらに 50 のケースを保留してそれを確認しました。
いくつかの変更が結果を最も改善しました。
- パス、タイプ、構造をコンパイラに移動する。 最初の IR では、モデルにすべてのリレーションシップ（連絡先から企業、企業から商談）を明示的に記述させていました。フィールドのメタデータはすでにそのパスを暗示しているため、コンパイラがそれを推論するようになりました。日付、型キャスト、否定の配置、グループのネストについても同じことを行いました。ルールをコンパイラに移動することで、IR が簡素化され、スキーマ障害が減少しました。
- 説明と修正を添えて拒否する。 すべてのスキーマとコンパイラの拒否は、可能な場合、代わりに何を書くべきかを示します。「このフィールドでは gt を否定できません。lte を使用してください」、「campaign_list から ID をコピーしてください」。小さなモデルは 1 回か 2 回の再試行で収束し、プロダクションモデルは 100 リクエストあたり数回拒否されます。
- 小さなモデル向けにプロンプトを構成する。 プロンプトを再編成しても精度は変わりませんでしたが、再試行回数が半分になり、レイテンシが直接改善されました。これは、Anthropic のプロンプトのベストプラクティスに触発されたものです。
- 散文よりも例を使用する。 フォーマットリファレンスに 2 つの追加例を加えたことで、説明の段落では捕捉できなかったクラスのミスが解決され、拒否された送信がほぼ半分になりました。
- 完全なコンテキストを与えるか、何も与えないか。 モデルは、ツールを呼び出す前に、コンテキスト内にあるものに手を伸ばします。コンテキストに部分的な、またはラベル付けされていないフィールドセットが含まれている場合、モデルは検索する代わりに最も近いフィールドを使用し、セマンティックに不正確なステートメントを生成しました。部分的なコンテキストを減らしてツールコールを優先することで、ビルド率が向上し、入力トークンが 5 分の 1 に削減されました。
最終的なプロダクション構成である GLM 5.3 Flash は、100 のベンチマークケースすべてを完了し、中央値レイテンシは 2.3 秒、95 パーセンタイルは 7.1 秒でした。そして、100 件中 97 件がセマンティックに正しいものでした。元のプロダクション形式のアプローチと比較して、単純なフィルターは約 45 秒から 1 秒強に短縮され、コストは 20 分の 1 になりました。
Statement Bench でのモデル比較
ベンチマークは、実際のタスクでモデルを比較する方法も提供してくれました。
2026 年 9 月 2 日、同じ 100 のケースを 8 つのモデルで実行しました。各モデルは、同じプロンプト、ツール、IR、コンパイラ、および 30 秒のリクエストタイムアウトを受け取りました。
プロバイダールーティング、プロンプトキャッシング、および一時的な推論負荷はすべてレイテンシに影響します。
モデル
有効なビルド
セマンティックに正しい
P50 レイテンシ
P95 レイテンシ
キャッシュ読み取り
ツールコール
拒否された送信
1,000 リクエストあたりの推定コスト
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
推定コストは、2026 年 9 月 2 日時点の各プロバイダーの掲載されている非プロモーションレートを使用して、観測された入力トークン、キャッシュ入力トークン、および出力トークンに基づく、試行された 1,000 リクエストあたりのコストです。キャッシュされた入力は、プロバイダーが公開している場合は公開されているキャッシュ読み取りレートで、それ以外の場合は完全な入力レートで請求されます。
図 1. コストに対する正確性。GLM 5.3 Flash は、Claude Opus 5 の約 20 分の 1 のコストで 97 パーセントに達します。
図 2. レイテンシ分布、中央値と 95 パーセンタイル、P95 で順序付け。
いくつかの発見が際立ちました。
モデルのサイズも価格もレイテンシを予測しませんでした。 最速のモデルは最小で最も安価でした。2 番目に速いのは、最大で最も高価なモデルでした。
失敗は、間違った答えから遅い答えへと移行しました。 8 つのモデルのうち 6 つは、完了したすべてのステートメントでセマンティックに正しく、それらの違いは、タイムアウト内に完了したリクエストの数にほぼ完全にあります。IR とプロンプトの初期の反復では、ほとんどの小さなモデルはビルドステップでベンチマークに失敗し、セマンティック精度は 50% 未満でした。
推論トークンはツールコールを上回ります。 Gemini 3.8 Flash は、出力トークン 192,000 のうち 180,000 を推論に費やし、266 回のツールコールを行いました。Claude Opus 5 は推論に 813 トークンを費やし、162 回のツールコールを行い、すべてのケースを完了しました。Global Search の取り組みにより、各ツールルックアップがミリ秒範囲に短縮されたため、残りのコストはそれらの間のモデルのターンです。
まとめ
モデルはあいまいさの解決に優れており、コードは精度の強制に優れており、初期の失敗のほとんどは、モデルに両方を実行させることに起因していました。このエージェントを構築することは、2 つのうちどちらが各部分を担当するかを決定する作業でした。テキスト・トゥ・SQL やその他のほとんどの自然言語インターフェースについても同じことが言えると予想されます。
これらの問題のいずれかに興味があれば、お問い合わせください！採用募集中です。
