インデックス化、回答生成、学習の違い

三つのレジーム、三つのよくある誤り

AIとウェブをめぐる議論では、三つの現象がしばしば一つにまとめられてしまう。

• インデックス化
• 回答生成
• 学習

この混同は、誤った診断を生む。インデックス化されているから、サイトは理解されていると思い込む。引用されているから、学習に使われていると思い込む。インデックス化を拒否すれば、他のあらゆる利用も禁じられると思い込む。

これらの等価関係は、いずれも信頼できない。

インデックス化

インデックス化は、発見、想起、順位づけのシステムの中にリソースが存在することに関わる。

それは最小限にとどまることがある。リソースは、次のような状態でありうる。

• 知られているが、あまり動員されない
• インデックス化されているが、よく理解されていない
• URLとして保持されているが、その役割は正しく解釈されていない

したがって、インデックス化はまだ意味上の勝利ではない。それは将来のアクセスのための、一つの可能な条件である。

回答生成

回答生成は、別のレジームである。

ここでは、ソースはもはや単に発見されるだけではない。出力を生み出すために、使われ、要約され、優先順位づけられ、言い換えられ、あるいは他のソースと競合させられる。

このレジームでは、問いは次のようになる。

• 誰が語っているのか
• どのソースが優先されているのか
• どの表現が採用されているのか
• カノンのどれだけが合成を経て残っているのか

あるリソースは、従来のインデックス化では目立たなくても、回答サーフェスとして構造的に動員可能でありうる。それを記述するのに役立つのが、構造的可視性である。

学習

学習は、別のレイヤーに属する。

ここで問題となるのは、回答の際にリソースを想起することだけではなく、挙動、選好、パラメーターを安定させるためにコーパスを用いることである。

だからこそ、「AIが私を引用した、したがって私のコンテンツで学習した」という文は、それだけでは何の価値ももたない。

同様に、「私のサイトはインデックス化をブロックしている、したがって他のいかなる目的にも使われえない」という文も、ドクトリン上は依然として危うい。

区別が重要である理由

この区別によって、公開されたアーティファクトの読み方が変わる。

• robots.txtは、主にクロールのアクセスと手続き的な発見に関わる。
• llms.txtは、主に文書の枠づけや方向づけのレイヤーに属する。
• 文脈ページ、マニフェスト、ガバナンスファイルは、主に読解、解釈、優先の条件を限定する。

これらのサーフェスのいずれも、それ単独で、あるレジームを別のレジームへと自動的に変換することはない。

観察にとっての帰結

組織は、自らがAIの回答に現れていることを観察したとき、次の三つの濫用を避けなければならない。

1. その存在を、支配的なインデックス化の証明と混同すること。
2. その存在を、学習の証明と混同すること。
3. 回答だけで読解の忠実性を記録するのに十分だと信じること。

正しい読解は、証拠レイヤー、Q-Ledger、Q-Metricsを経由する。

派生的な手段にとっての帰結

Better Robots.txtのようなWordPressの実装は、いくつかの運用上のレイヤーを整理するのに役立ちうる。それを、インデックス化、回答生成、学習をそれ単独で統御しているかのように扱ってはならない。

そのため、応用的な手段は、レジームのドクトリンの後に読まれなければならず、その前に読まれてはならない。

読み方のルール

インデックス化、回答生成、学習の違いに関するこのドクトリン上のノートは、解釈ガバナンスのコーパスにおける位置づけのためのサーフェスとして読まれなければならない。このノートは、正規の定義にも運用フレームワークにも取って代わるものではない。このノートが説明するのは、ある区別がなぜ重要なのか、ドクトリンがどこに境界を引くのか、そしてその境界が無視されたときにどのような種類の誤りが起こりやすくなるのかである。

読者は三つの水準を区別しなければならない。第一に概念の水準、すなわちこのページが何を名指し、何を名指すことを拒むのか。第二に手続きの水準、すなわちシステム、組織、評価者が回答に依拠する前に何を確認すべきなのか。第三に証拠の水準、すなわち何があれば解釈が再構成可能で、異議申立て可能で、修正可能になるのか。ドクトリンのページが最も強固であるのは、これら三つの水準を単一の説得的な定式化の中に溶け込ませるのではなく、見える状態に保っているときである。

コーパスにおける用途

このページは、定義、フレームワーク、観察記録をつなぐ橋渡しとして用いること。このページは、読解ルートを導くこと、あるフレームワークがなぜ存在するのかを正当化すること、あるいはある回答がなぜ限定、拒否、または監査されるべきなのかを説明することに役立ちうる。ただし、ランタイムの指示、モデルの挙動の保証、証拠の代わりとして扱ってはならない。このドクトリンに基づく回答が、どのソースが使われ、どの推論が許容され、どの不確実性が未解決のまま残ったのかを示せないのであれば、このドクトリンは運用上の管理ではなく、読解の原則にとどまる。