Quipu、エージェントによる知識グラフへの書き込みを「検証後にコミット」へ転換、拒否記録もバージョンをまたいでリプレイ可能に

新たにオープンソース化された知識グラフ・ストレージ層のQuipuは、言語モデルやソフトウェアエージェントが知識を大量かつ自動的に書き込む状況を想定し、従来の「まず受け入れ、後からクリーンアップする」という設計を反転させた。各書き込みはまずSQLiteのsavepointに置かれ、ガバナンスルールが書き込み後の候補状態に対して実行される。ルールがトランザクションを拒否した場合、データの差分はロールバックされる一方、ID、時刻、証拠のハッシュを含むEd25519署名付きの裁定は保存される。これにより、システムは現在どのような事実が存在するかを回答できるだけでなく、ある書き込みが拒否された時点で、どのバージョンのデータとルールが根拠になったかも追跡できる。

基盤にはEAVT形式の追記型ファクトログを採用し、transaction timeとvalid timeを同時に保存する。この二重時間設計は業務データだけでなく、信頼ラベル、ポリシー、裁定にも拡張されている。異なる情報源はnamed graphに配置され、統合結果は、信頼性、鮮度、耐久性、ポリシー上の義務から成るlatticeに基づいて絞り込まれる。これにより、隔離された情報源や出所が明示されていない情報源を認証済みデータと統合しても、クエリ結果が高信頼と見なされ続ける事態を防ぐ。ルール自体もグラフ内の事実として格納されるため、`T ⊨ Σ`のコンプライアンス検査は決定論的クエリで実行でき、モデルを再度呼び出す必要がない。

作者らはCensusの複数ライター・ライフサイクルを構築し、6件の欠陥を注入した同一のシードフローを評価した。ゲートなしのバージョンでは6/6件の欠陥が残存したのに対し、Quipuでは0/6件だった。7項目の統合プローブはいずれも「信頼は拡張されてはならない」という性質を維持し、過去の裁定50/50件を当時のルールに基づいて再構築できた。別のDEMM-Benchテストには、8種類の証拠劣化条件と512件のガバナンス質問が含まれていた。内容に基づく判定では過剰な主張は見られなかった一方、コンテナの存在だけを確認するベースラインでは、最大87.5%のケースで誤った主張が生じた。

エンジニアリング面で注目すべきなのは、エージェントのエラーをクリーンアップ用キューから、再試行可能な構造化された拒否ループへ移した点だ。プロジェクトはRust library、CLI、REST、SPARQL、SHACL、MCPツールも提供する。ただし論文は、これがエンジニアリング上の特性を記述したものであり、同種データベースとの性能比較ではないと明記している。主要な数値も、作者らが共同設計した決定論的テストに由来する。今後は、高並行性環境におけるトランザクションと署名のコスト、ルールの進化やグラフ横断の統合を経てもリプレイ可能性が維持されるか、さらに独立したチームが実環境のRAGまたは長時間稼働するエージェントのワークロードで結果を検証できるかを見極める必要がある。