「詳しく調べて」と打たれたときに起きていること
リクエストを打つのと、メニューから選ぶのとで、結果が違ってはいけません。キーワード表でやると 7 言語では必ず漏れ、毎メッセージでモデルに聞くと遅くて高い。何を計測したのか、なぜルーターが 2 段なのか、そして同じ一文がドキュメントを開いているときには別の道に進む理由。
入力欄の横にある + が機能メニューです——もっと深く調べる、ドキュメントを書いて、
人につなぐ。ほとんどの人はこれを開きません。かわりにリクエストを打ちます——
「research it」、「查查看」、「もっと深く調べて」。打った場合と選んだ場合で結果が違うなら、このメニューは飾りになります。
そこでプラットフォームは、打たれたメッセージを同じ機能へルーティングします。このページはそのやり方についてです。素直に思いつく実装は 2 つともうまくいかず、その失敗は似たものを作る前に知っておく価値があります。
キーワード表が負ける理由
トリガー語のリストは、対応するすべての言語で正しくなければならず、しかも人が実際に打つ文字列に耐えなければなりません。
reserach it please——綴りが違うだけで、表は 1 件も一致しません。- 「研究一下呗」——誰も追加しようと思わなかった言い回し。
go deeper on that one——表の語が 1 つも現れません。
フレーズはいくらでも足せます。できないのは足し終えることです。言語が増えるたびに表は倍になり、しかも取りこぼしは無音です。訪問者はリクエストを打ち、ふつうの回答を受け取り、それを処理できる機能があったことを知る手立てがありません。
毎メッセージでモデルに聞くのも負ける
もう一つの素直な案——毎メッセージで小さなモデルに「この人は機能を呼び出そうとしているか」と聞く ——は精度としては十分ですが、すべてのメッセージの前にモデル呼び出しを置くことになります。その大半は明らかにふつうの質問です。訪問者が体感する遅延であり、答えが最初から明らかだったメッセージに払うコストです。
2 段構え：安い門番、そのあとに判定
ルーターは埋め込みによる門番 + モデルによる判定です。
第 1 段：埋め込み。 各機能にいくつかのアンカー文があり、さらに共有の反例アンカー——トリガー語と意味的に近い、日常の返事——があります。メッセージは両方と比較されます。埋め込みは多言語なので、1 セットのアンカーで 7 言語をカバーできます。*「深挖一下」*と *「research it」*は空間の同じ領域に落ちます。どちらにも近くなければ、ここで打ち切り。モデル呼び出しはゼロです。
第 2 段：モデル。 ボタンを押しているように見えるなら、小さなモデルが候補から 1 つを選ぶか、 どれでもないと答えます。
順序が重要で、しかも最初に試した版とは逆です。埋め込みは「この文はリクエストの形をしているか」には強く、「この人は機能を使いたいのか、機能について聞いているのか」には弱い——
How does your deep research feature work? は本物のトリガーと見分けがつきません。そしてその区別こそモデルが得意なことです。だから安い段が門番をし、正確な段が決めます。
反例アンカーは何のためにあるか
アンカーだけでは tell me more と dig deeper を分けられません——意味として本当に近いからです。分けているのは、tell me more が反例側にいることです。最近傍がトリガーではなく日常の返事になります。次の 2 種類は、テストで誤爆してから追加されたものです。
| 種類 | 例 | これが無いと何が起きたか |
|---|---|---|
| 短い追い質問 | and in Tokyo? | ディープリサーチに流れた |
| 知らない固有名詞への質問 | what is ANVISA | 「調べに行け」と読まれた |
| 同じ話題の長い質問 | 「我这个产品在当地属于哪一类」 | 誰も頼んでいないドキュメントを書き始めた |
| 「さっきの話をまとめて」 | 「把刚才说的整理一下发我邮箱」 | 「新しいドキュメントを書け」と読まれた |
3 つ目が示唆的です。ドキュメントを書いて のアンカーは長文である必要があり（短いアンカーは長いリクエストに対してスコアが伸びない）、長文である以上、そのエージェントの話題を必ず抱え込みます。その結果、同じ話題の長い質問が類似度を駆け上がります。実測で 0.711——本当にドキュメントを求めている文よりも高い値でした。
数字
独立に書き起こした 110 件のサンプル（発火すべき 60 件、すべきでない 50 件）、7 言語、言い回しは意図的にアンカーと変えてあります。
| ルーター | 正解率 |
|---|---|
| 埋め込みのみ | 84.5% |
| 埋め込みの門番 + モデルの判定 | 95.5% |
門番のしきい値は好みで決めていません。同じサンプルに対して各値を総当たりしました。
| しきい値 | モデル呼び出し | 拾えた本物のリクエスト（60 中） | 誤発火（50 中） |
|---|---|---|---|
| 0.00 | 110 | 60 | 9 |
| 0.45 | 100 | 60 | 7 |
| 0.55 | 88 | 60 | 5 |
| 0.60 | 77 | 59 | 4 |
| 0.70 | 71 | 59 | 3 |
0.55 は、本物のリクエストをまだ 1 件も落としていない最後の行です。これより上げると、誤発火を 1 つ減らすたびに本物のリクエストを 1 つ失います。しかもこのサンプル数では 1〜2 件の差はノイズです—— 再現率をノイズと交換はしません。
同じ一文、2 つの意味
「ブラジルの経路について 1 節足して。」
ドキュメントが開いていなければ、これは「何か書いて」という依頼です。右側にドキュメントが開いていれば、これはそのドキュメントを直してという依頼です。同じ言葉、違う答え——そして間違えたときの代償は見た目より大きい。レポートを書いていた訪問者が「1 節足して」と言い、別のドキュメントがもう 1 つ作られました。
最初の修正はルールでした——ドキュメントが開いている間は ドキュメントを書く にルーティングしない。バグは止まりましたが、別のものが壊れました。本当に 2 つ目のドキュメントが欲しい人が、それを頼めなくなったのです。2 つ目のルール（図の依頼には文字どおり「図」の語が要る）も同じ形で、同じ代償でした。*「その数字を別の見せ方で」*を認識できません。
ルールの上にルールを積むのは、判断している部品が間違っているという合図です。いまは文脈そのものが判定の段に入ります——モデルに「ドキュメントが開いている」と伝え、選択肢を 1 つ増やします： 開いているドキュメントを編集する。これはどこにもルーティングしません。ドキュメント編集ツールはそのターンですでに使える状態にあり、それらが担当すべきだからです。元の 2 つのバグは直ったまま、 2 つの本物のリクエストも復活しました。
意図的な非対称が 1 つあります。モデルに届かず埋め込みの推測へフォールバックする場合、ドキュメントが開いているときはハードルを上げます。そこで誤るとターン全体が乗っ取られるからです——21 日の審査ウィンドウについて話していた訪問者が「21 日の審査ウィンドウの図は描けません」と返される。同じ間違いがふつうの会話で起きても、最悪で余計な図が 1 枚出るだけです。
あなたのエージェントにとっての意味
- 打って発火できるのは、そのエージェントのメニューにある機能だけです。 ディープリサーチを有効にしていなければ、訪問者が求めてもふつうの回答が返ります。買っていない機能は動きません。
- トリガー語を書く必要はありません。 テナントごとのキーワード表は、どの言語にも存在しません。
- 対象が要るのに文中に無いリクエストは、推測ではなく「入力欄への差し戻し」として返ります。 話題がはっきりしないまま 「research it」 と打った人は、入力欄に話題が入った状態を見て、送信前に直せます——誤推測の代償が、1 分の無駄から 2 語の修正に下がります。