プラットフォームスキル — 全てのエージェントが既に備えているもの
意図に基づいて取得され、一つずつ付与されるのではなく、全てのエージェントが利用可能な一般的な作業方法の共有ライブラリ。
list_skillscreate_skillupdate_agent原則 — プラットフォームスキルは メソッド であり、テナントスキルは あなたのビジネス である。 共有ライブラリには、一般的な作業方法(競合他社を調査する、規制を読む、見込み客を評価する)が含まれます。業界固有のものやデータ固有のものは、独自のスキルに格納してください。詳細は 設計原則 を参照してください。
すべてのエージェントは、付与する必要のない一連の プラットフォームスキル で始まります。これらは一般的な作業方法であり、他のスキルと同様にオンデマンドで読み込まれ、一つずつ接続するものではありません。
なぜ単に「エージェントにもっとスキルを追加する」ではないのか
数百個のメソッドからなるライブラリをプロンプトに含めることはできません。それらをすべてリストアップすると、選択の精度が測定可能な範囲で低下します。207 個のスキルをすべてリストした場合、モデルが正しいものを選択したのは 30% の場合 だけでした。リストを最も関連性の高い 15 個に絞り込むと、51% になりました。したがって、プラットフォームはリスト表示の前に検索を行います。
検索は、このターンメッセージに基づいて、共有ライブラリとあなたのライブラリの両方を対象に実行されます。一般的なスキルと同じ空間を共有しても、独自のスキルが不利になることはありません。193 個の一般的なスキルに混ぜられた 18 個の真に業界固有のスキルで測定すると、業界固有のスキルは より 信頼性高く認識されました(86% vs 79%)。これは、業界固有の語彙が一般的なメソッドの語彙から遠く離れているためです。
おおよそ 8 個以下のスキルでは検索は行われず、完全なリストが単純に表示されます。 その規模ではリストはすでに正確であり、検索は新たな失敗要因をもたらすだけです。つまり、正しいスキルがショートリストから外れ、モデルがログに何の兆候もなく自身の知識から回答してしまうという事態です。
制御できることとできないこと
| 接続できない | プラットフォームスキルは、すべてのエージェントにデフォルトで利用可能です。エージェントごとのチェックリストはありません。 |
| 無効化できる | 運用担当者は、全員に対してプラットフォームスキルを運用から外すことができます。これはエージェントごとの判断ではなく、プラットフォームレベルの決定です。 |
| 上書きできる | 同じタスク用の独自のスキルを作成します。独自のスキルは同じ基準で検索され、ビジネス固有であるため、実際のビジネスに関するリクエストでは通常勝ちます。 |
英語で記述する
プラットフォームスキルは英語で記述します — description、instructions、menu_label および生成されるトリガーフレーズ。
これはデモのためだけではありません。同じ 193 個の中国語スキルのライブラリで測定すると、3 つのプラットフォームスキルを中国語から英語に切り替えることで、それぞれが認識される信頼性が 向上しました:競合調査 75% → 83%、ポリシー読解 83% → 100%、見込み客の資格認定 50% → 62%。英語のスキルは、中国語のスキルの群れからベクトル空間上で遠く離れているため、選び出しやすくなります。(この利便性は 違い によるものであり、英語そのものによるものではありません — すべて英語のライブラリではこの利点は消えます。)
言語は、モデルがスキルを呼び出せるかどうかには影響しません。セルフホスト型の 35B モデルとホスト型のモデルの両方で、中国語および英語の説明から正しく整えられた load_skill 呼び出しが出力されました。英語を選択することは、技術的な回避策ではなく、プロダクトの判断です。
独自のスキルは別問題です — お客様が話す言語で記述してください。
スキルの実行前にプラットフォームに調べさせる
スキルは、開始前に材料を集めておくよう要求できます。instructions の先頭に次の一行を置きます。
PREFETCH: web x4プラットフォームは訪問者のメッセージをその本数の検索クエリに変え、実行し、引用用の番号付き事実表をスキルに渡します。PREFETCH: web だけなら既定の 2 本、この行を書かなければ何も検索しません。
幅を要求するのは、質問が複数の面を持つときだけにしてください。 ある製品調査——価格、制限、エクスポート——は、狭い探索では 2,957 語に出典 5 件で、そこに書かれた価格はどれもどの情報源にも存在しない具体的な数字でした。4 本にしたところ、同じ質問が出典 17 件で返ってきました。文章を書く・書き換える・計算するスキルは何も宣言すべきではありません。必要のない検索は、時間と費用の純粋な損失です。
これは規則を書き記すことの代わりにはなりませんが、実際に効く方の半分です。その同じスキルの手順には 材料にない価格は決して書かないことと既に書いてあり、それでも書きました。答えを変えたのは材料であって、あの一文ではありません。
実際に使用されるスキルを作成する
他のスキルと同じルールに加え、スケールした場合にのみ現れるルールが一つあります。
descriptionは、お客様が使っている言葉で いつ を記述します。 これが検索が一致する対象です。instructionsは、そのスキルが カバーしない 内容で終わります。 数百個のスキルがあるため、類似する近傍スキルは避けられません。その閉じる行は、モデルが間違ったスキルを開いたことに気づくための唯一の手段です。- トリガーフレーズは生成されます — 誰かがそれを依頼するかもしれない 8 つの平易な言語表現 — であり、編集できます。これらは一致対象として使用され、訪問者には表示されず、編集内容は再生成によって上書きされません。
スキルを作成した後で実行する価値のあるチェックがあります:ライブラリに、そのライブラリ自身のトリガーフレーズそれぞれに対してどのスキルが検索されるかを問い合わせてみます。あるスキルの自身のフレーズが常に 他の スキルとして返ってくる場合、そのスキルはライブラリに含まれていますが到達できません — 常に勝つスキルとマージするか、または二つのスキルが明確にどのように異なるかを記述してください。