CapabilityRegistry
検出、検証、順序付け、そしてコンテンツアドレス方式のスナップショット。
英語版が原文です。
プロトコル:
CapabilityRegistry.snapshot(snapshot_id: str | None = None) -> CapabilitySnapshotCapabilityRegistry.create(capability_id: str) -> AnyCapabilityRegistry.observers() -> tuple[SourceObserver, ...]CapabilityRegistry.loaders() -> tuple[SourceLoader, ...]CapabilityRegistry.chunkers() -> tuple[Chunker, ...]CapabilityRegistry.language_detectors() -> tuple[LanguageDetector, ...]CapabilityRegistry.document_classifiers() -> tuple[DocumentClassifier, ...]CapabilityRegistry.page_classifiers() -> tuple[PageClassifier, ...]CapabilityRegistry.chunk_classifiers() -> tuple[ChunkClassifier, ...]CapabilityRegistry.page_entity_extractors() -> tuple[PageEntityExtractor, ...]CapabilityRegistry.chunk_entity_extractors() -> tuple[ChunkEntityExtractor, ...]CapabilityRegistry.document_enrichers() -> tuple[DocumentEnricher, ...]CapabilityRegistry.page_enrichers() -> tuple[PageEnricher, ...]CapabilityRegistry.chunk_enrichers() -> tuple[ChunkEnricher, ...]
CapabilityRegistry は、indx が利用できる処理機能と埋め込み空間の、バージョン付きインベントリを取得するための境界です。ID なしで snapshot() を呼ぶと現在のインベントリが返ります。ID を渡すと、保持された履歴からそのピン留めされたスナップショットが解決されます。
レジストリはインストール済みプロバイダーを検出し、その公開宣言を検証し、重複する識別子を拒否し、インベントリを決定的に順序付け、コンテンツアドレス方式のスナップショット ID を割り当てます。
create() は戻り道です。計画が選択した ID を、それを実行する実装へ変換します。どのプロバイダーがどの機能を宣言したかを知っているのは検出だけです。したがって、GET /v1/capabilities に答えたレジストリが、実行が問い合わせるレジストリでもあります。別の場所に作られた第二のルックアップは、計画の決定根拠となったスナップショットと食い違い得ます。
observers() が存在する理由も同じで、一段上の層にあります。どのプロバイダーが SourceObserver を宣言したかは検出が与えるべき答えであり、事前観察（preflight）が再びそれを調べてはなりません。オブザーバーは、indx が同梱するものが最後になるよう順序付けて返されます。indx が同梱するフォーマットを主張するインストール済みオブザーバーは、どのエントリーポイントが先に読み込まれたかではなく、意図的に勝つのです。chunkers() はエグゼキューター側で同じルールに従い、順序付けにラングが一つ増えます。fallback = True を宣言する Chunker — 同梱される 1 ページ 1 チャンクの床 — はすべての後にソートされます。すべてのページに答えを持つものは、最後に尋ねられる答えでなければならないからです。8 つの注釈アクセサ — document_classifiers()、page_classifiers()、chunk_classifiers()、page_entity_extractors()、chunk_entity_extractors()、document_enrichers()、page_enrichers()、chunk_enrichers() — はそれぞれ ID 順であり、それ以上の規則はありません。リクエストが望む分類器、抽出器、エンリッチャーを名指しするので、ここでの順序は公表されるリストを決めるだけです。それらの ID は 8 つすべてにまたがる 1 つの名前空間なので、重複検査はアクセサごとではなくポートを横断します。1 つの文字列を主張するページ分類器とチャンク抽出器は、重複する機能 ID と同じように拒否されます。その文字列を名指しするリクエストが、どちらを指しているのか言えないからです。
機能の可用性は、インストール済みパッケージ、設定、ハードウェア、プロバイダーの健全性によって変わります。バージョンのないライブなリストに対して計画すると、環境が変わった後に同じリクエストが別のルートを生成または実行することを許してしまいます。
スナップショットは、関連する決定コンテキストを凍結します。計画はその ID を記録するため、再現も比較もでき、必要なインベントリが利用不能または非互換なときには明示的に拒否できます。
任意入力はスナップショット ID です。省略すると現在のスナップショットを要求します。指定すると、一致する保持済みスナップショットを要求します。
出力は
CapabilitySnapshot
で、次を含みます。
- コンテンツアドレス方式のスナップショット ID。
- インベントリに関連付けられたルーティングポリシーのバージョン。
- 一意に識別された機能記述子。
- 一意に識別された埋め込み空間記述子。
機能記述子は、バージョン、kind、対応デバイスとメディアタイプ、要件、可用性を示します。埋め込み空間記述子は、次元、距離、正規化、互換な文書／クエリ埋め込み器を示します。
indx.capabilitiesという Python エントリーポイントグループを通じて公開されたプロバイダーを検出する。- プロバイダーの宣言を公開前に検証する。
- 重複する機能 ID と埋め込み空間 ID を拒否する。
- スナップショットの内容を決定的にソートする。
- 正規化された内容からスナップショットの同一性を導出し、同じインベントリが同じ同一性を持つようにする。
- 呼び出し側が渡すスナップショット ID を解決できるだけの履歴を保持する。
- 検出と記述を軽量に保つ。重い初期化は機能の生成と実行に属する。
- 現在のスナップショットに存在する任意の機能 ID の実装を生成する。未知の ID や生成できない ID は、クラッシュではなく一時的に利用不能として報告する。計画はすでに、代わりに試すべきフォールバックを名指ししている。
このプロトコルが規定するのはスナップショットの取得であり、レジストリ実装が使うストレージ機構や保持ポリシーではありません。
システム内の位置
Section titled “システム内の位置”公開ファサード indx.capabilities() と GET /v1/capabilities オペレーションがレジストリのスナップショットを公開します。プランナーは現在のスナップショット、または呼び出し側がピン留めしたスナップショットを使い、その ID をすべての RoutePlan に記録します。実行は、渡された計画をその決定コンテキストに照らして検証します。