全文で届くものと、名前だけで届くもの

検索には2つの役割があります。適切なナレッジを選ぶことはよく知られた役割です。もう1つは、選ばれた各エントリにどれだけの枠を与えるかを決めることで、良い答えが実際に収まるかどうかはこちらで決まります。

より単純な設計では、2つ目の問いに1つのルールで答えます。優先順位が付いたものはすべて、枠がなくなるまで優先度の順に全文で送る、というものです。優先度が8番目のエントリは1番目とまったく同じ扱いを受け、その次のエントリは関連性があっても何も受け取れません。関連性が決めるのは順番だけです。

Pathruleでは、関連性が形式を決めます。

3つの形式、1つの優先順位

• 最も近い少数は全文で届きます。 アシスタントはそれを読んでそのまま行動でき、別途の取得もラウンドトリップも必要ありません。
• それ以外の関連するものは、名前、ID、1行の説明として届きます。 アシスタントがそれを認識し、必要だとわかったときに本文を取得するには十分な情報です。
• スキルは、優先度がどれだけ高くても名前だけで届きます。 詳しくは後述します。

重要なのはリストの最後に挙げた性質です。関連性のあるエントリが、枠が足りないという理由で捨てられることはありません。プロンプトごとの予算に収まらないものはタイトルで列挙され、それを可能にしているのが軽量な形式です。

全文で届ける本文の数は、最も強くマッチしたものを完全な形で保ちつつ、優先順位が付いたエントリをすべて全文で送るよりもコストを抑えられるように選ばれています。正確な予算はPathruleのエンジンの一部であり、リリース間で変わる可能性があります。

スキルを押し込まない理由

メモリは事実です。ルールは制約です。どちらもアシスタントが作業中に当然知っておくべきものなので、どちらも内容として届けられます。

スキルは手順です。手順を求めていないターンのコンテキストに手順を入れると、アシスタントに情報を与えるのではなく指示することになります。そしてチェックリストを渡されたアシスタントは、そのチェックリストに従おうとしがちです。そのためスキルは名前で提示され、アシスタントは作業がまさにそのスキルの扱う作業であるときに手を伸ばします。たとえば::skill-nameで呼び出すと、その本文全体が読み込まれます。スキルがどうあるべきかについてはスキルの書き方を参照してください。

ルールも枠を勝ち取る必要がある

ルールが関連性テストを素通りすると、データベースマイグレーションに関する制約が、ボタンについての質問に答えられたはずのメモリを押しのけてしまうことがあります。そのためルールも他のすべてと同じ関連性テストを通り、無関係なルールは全文の枠を占めるのではなく名前として届きます。

例外は意図的なものです。strictに指定されたルールは本文を保持します。違反するとリグレッションを引き起こすような厳格な制約は、出し惜しみすべきものではないからです。ガードレールとしてのルールを参照してください。

格下げが関連性を観測可能にする

軽量な形式が重要な理由はもう1つあり、それはコストではなく学習に関わるものです。

優先順位が付いたエントリをすべて本文として押し込むと、レイヤーはそのどれかが必要とされたかどうかを知ることができません。求められずに届いた本文からは、どちらの方向の証拠も得られません。提示された名前は違います。アシスタントはそれを取得するか、しないかのどちらかであり、取得は作業に何が必要だったかを知っている当事者による意図的な行動です。

この取得は有用な関連性シグナルであり、何度も取得されるエントリは次回全文で届く可能性が高くなります。これは検索が適切なナレッジを見つける仕組みで説明している、より大きなループに沿ったものです。レイヤーはアシスタントに報告を求めるのではなく、自らが届けたものを測定します。

基準はどの言語でも成り立つ必要がある

エントリが送られるかどうかは関連性の基準で決まり、その基準は気づかないうちに言語に左右されることがあります。同じメモリでも、英語で書かれたプロンプトに対するスコアと、そのプロンプトを忠実に翻訳したものに対するスコアとでは、後者のほうが低くなることがあります。意味ベースのマッチングは、同じ考えであっても言語間で同一の結果を出すわけではないからです。英語のプロンプトだけで調整した基準は、誰にも気づかれないまま他の言語を切り捨ててしまいます。しかもその症状はエラーとしては現れません。現れるのは、トルコ語でプロンプトを書くチームが、同じプロンプトを英語で書くチームよりも少ないコンテキストしか受け取れないという状態です。

そのため基準は言語をまたいで成り立つ位置に設定されており、Pathruleはそれを前提とするのではなく、複数の言語のプロンプトでテストしています。こうした主張がどのように検証されているかは、Pathruleが強い主張を裏付ける仕組みで説明しています。

2つのことを尋ねるプロンプトには両方のナレッジが届く

1つの質問であれば、意味ベースのマッチングはうまく機能します。しかし同じメッセージで2つのことを尋ねると、構造的な問題が生じます。リクエストが2つの異なる考えの単一の平均になり、2つのものの平均はどちらにも近くないことが多いのです。1つ目の質問に答えるエントリと2つ目の質問に答えるエントリが、それぞれ単独なら超えられたはずの基準に、どちらも届かなくなることがあります。

Pathruleは、複数の部分からなるリクエストを部分ごとに読み取ります。各部分を個別にマッチングして結果を組み合わせるため、2つの部分からなる質問には両方に対するナレッジが届き、1つの部分だけの質問はこれまでどおりマッチングされます。

使える枠はワークスペースではなく質問に応じて増えます。2つのことを尋ねると、1つ尋ねるよりも少しコストが増えます。メモリが100件ではなく1万件あっても、コストは変わりません。

次に読むもの

• 検索が適切なナレッジを見つける仕組み：この配信モデルの土台となる選択について。
• フックの仕組み：選ばれたコンテキストが、最初のツール呼び出しの前にアシスタントへ届く仕組みについて。
• Pathruleが強い主張を裏付ける仕組み：言語をまたいだ挙動のような主張がどのようにテストされているかについて。