PathruleKnowledge IR
Pathruleが、チームが書いたテキストとあわせて各ナレッジの種類（要件、助言、コンテキスト）を保持する理由と、その権威がエージェントに届くまで失われない仕組みを説明します。
このページの内容
ルールはナレッジの単位ではありません。ナレッジを入れるコンテナです。
人が書いた1つの段落には、異なる種類の内容がいくつも同時に含まれているのが普通です。何かが決して起きてはならないこと、別の何かを検証しなければならないこと、そしてその仕組み全体がなぜ存在するのか。これらを1つの塊として配信すると、「ここにテキストがあるので念頭に置いてください」というものに潰れてしまいます。分けて保持すれば、重みの異なる3つの別々のものとして残ります。
Knowledge IRは、この構造化された表現の名前です。各ナレッジの種類と権威を、チームが書いたテキストの代わりにではなく、そのテキストとあわせて保持します。
ナレッジの種類
エージェントが受け取るナレッジは、いずれもいくつかの種類のどれかに当てはまり、その種類によって提示のされ方が決まります。
起きてはならないこと。 人がスコープに対して設定した制約です。適用されるパスだけを対象とし、それ以外には及びません。また、ランタイムが単に言及するだけでなく実際に作用できる唯一の種類のナレッジです。
検証しなければならないこと。 作業を完了と見なす前に行う必要があるチェックです。
この問題が起きたときに効果があったこと。 ある条件と、それを解決した修正です。これは助言であり、エージェントに何が効果的だったかを伝えるもので、何を禁止するかを伝えるものではありません。
ある条件の下で優先すべきこと。 推奨される選択と、それが優先された代替案です。好みを述べるだけで、代替案を禁止することは決してありません。それができるのはルールだけです。
どのように行うべきか。 順序付きの手順で、ステップは元の順序のまま保持されます。順序を入れ替えた手順は別の手順だからです。手順の多くはスキルに置かれています。
ここで成り立ち、役に立つこと。 何も禁止しないものの、正しいアプローチを左右する記述的な事実です。あるモジュールの背後にあるデータベースが読み取り専用のレプリカであることは、この種類の事実です。だからこそ、エージェントはinsertではなくキューを使うべきだとわかります。
なぜこうなっているのか。 判断の背後にある理由です。ルールは知っていても理由を知らないエージェントは、善意のリファクタリング1回でそのルールを台無しにしかねません。この種類はそれを防ぐためにあります。
権威の階層
種類どうしは対等ではありません。配信では、プロンプト内に現れる順序に頼るのではなく、そのことを明示します。
| 階層 | 対象 | 意味 |
|---|---|---|
| 要件 | ルール（起きてはならないこと、検証しなければならないことを含む） | 拘束する。 |
| 助言 | 過去の修正、推奨される選択、手順、理由、エージェントの知見、あなた個人の好み | 作業を改善する。 |
| コンテキスト | 作業に情報を与える事実 | 情報を与える。 |
配信経路のどこにおいても、下位の階層が上位の階層を覆せるかのように提示することは許されません。ルールは専用のセクションで届きます。エージェントの知見は、検証すべき助言として位置付けられて届きます。あなたの個人的な好みは、ワークスペースのルールと必須チェックが優先されることをエージェントに伝える見出しの下で届きます。要件と同じ強さで読める段落は、要件の代わりに従われてしまう段落です。この構造はまさにそれを防ぐためにあります。
「権威は平坦化されずにエンコードされる」とは、実際にはこういうことです。そしてこれこそが、構造化された表現と文章の寄せ集めとの違いです。
ドキュメントとアトム
メモリ、ルール、スキルはそのままです。人が書き、編集し、議論する対象であり続けます。構造化された表現はそれらを表現したものであって、置き換えるものではありません。
Rule document
|
+-- what must not happen
+-- what must be verified
+-- why
1つのドキュメントが複数の種類のナレッジを含むことがあります。これはごく普通のことで、コンテナと単位が同じものではない理由もここにあります。
最も重要なのは、拘束力を持つ種類がどこから来るかです。要件は、人が設定したルールからのみ生まれます。ルールは実行可能な制約を持つこともできますが、エージェントが提案した制約は提案として保存され、人が承認するまで強制されません。モデルが推論したものが、それだけで要件になることはありません。Proposed Knowledgeを参照してください。
矛盾
2つの助言が、どちらも妥当に見えながら食い違うことがあります。Pathruleは、その食い違いの整理をエージェントに任せません。
- 知見。 エージェントがコードについて記録した2つの知見が互いに矛盾する場合、どちらかを推測で選ぶのではなく、両方とも保留します。
- 好み。 同じ種類の作業について以前の好みと矛盾する好みを教えた場合、新しい好みがそれを置き換え、古い好みは置き換え先への参照を残して廃止されます。
- ルールと好み。 ルールは常に個人的な好みより優先されます。User Intelligenceを参照してください。
矛盾する2つの助言は、助言がないよりも悪い結果を招きます。この構造があるからこそ、Pathruleはそうした事態が起きていることを見分けられます。