訪問ノード数は 11。比較回数も変わらない。
2026 年 9 月のローカルテストで、発見プロトタイプは同じ計数を繰り返し報告した。ネットワーク内の Agent が 32 でも、512 に増やしても同じだった。リクエストは近傍を最大二ホップ進む設定で、計数は予想どおりに見えた。
ところが時間は変わった。検索遅延の第 95 百分位は 5.66 ミリ秒から 47.64 ミリ秒へ上昇した。ネットワークが 16 倍になると、検索は八倍以上遅くなった。
この食い違いが示したのは、訪問計数の外側でも仕事が行われているということだった。
リクエストの出発前に全網を巡っていた
この検索の動作から説明しよう。各 Agent は発見用の信号を持ち、少数の隣接ノードにつながる。リクエストがノードを通るとき、周囲にさらに探索する価値のある対象があるかを判断する。そのため、そのノードと一ホップ先の隣接ノードの公開信号をまとめた近傍要約を作る。
街の地図にたとえると、検索は数本の通りを歩くだけだ。近傍要約は交差点の案内板で、進む方向を決める助けになる。
初期実装では、書きやすい方法を選んだ。検索開始時に全ノードの案内板を作り直し、それからリクエストを出発させた。
# 早期请求路径的简化结构
adverts = build_all_neighborhood_summaries(network)
return walk_local_routes(request, adverts)
二行目は確かに局所経路だけを歩く。しかし一行目ですでに全網を走査している。
既存の資源計数は主に伝播と比較を対象としていたので、「11 ノードを訪問」と正しく報告した。それは伝播段階の作業量を答える指標だった。全要約の再構築はその前に行われ、時間を消費し、ネットワーク規模とともに増えるのに、この帳簿には載っていなかった。
データシステムでは珍しくない現象だ。返す行数が少なくても大量の行を走査することがあり、LIMIT 付きのクエリでも並べ替えやインデックス構築の開始コストが先にかかることがある。PostgreSQL の EXPLAIN 文書は、出力行数、開始コスト、全体コストを区別している。どの量がどの作業区間を覆うかを知る必要がある。
この Agent プロトタイプでは問題が具体化した。局所訪問で省いた仕事を、局所訪問に入る前に行っていた。
要約は必要になった時点で作る
一括構築をノード単位の構築に分けた。検索がある境界に到達し、その近傍を見る必要が生じたときだけ、その要約を作る。同じ同期クエリで再び使うなら計算済みの結果を再利用する。
# 修订后请求路径的简化结构
adverts = {}
def summary_for(edge_id):
if edge_id not in adverts:
adverts[edge_id] = build_one_neighborhood_summary(edge_id)
return adverts[edge_id]
return walk_local_routes(request, summary_for)
adverts の寿命は一回の検索だけだ。次の検索では現在のノードと接続を読み直すので、更新や参加、離脱の後には自然に新しい要約が得られる。これは意図的に残した単純さである。現在のプロトタイプは同期実行で、発見中にネットワークが並行更新されない。クエリ内の再利用で主な利益を得られ、クエリをまたぐキャッシュ無効化の複雑さも避けられる。
全要約を構築する入口も、診断や全網スナップショットの出力には役立つ。通常検索の必須経路から外しただけだ。
同時に、資源計数へ実際の動作を表す二つの量を加えた。構築した要約数と、読んだ要約寄与者数である。元の訪問計数も残し、準備段階を観察対象に含めた。
同じ負荷で遅延曲線が平らになった
同じマシン、トポロジー、クエリ、設定で比較した。各規模で発見リクエストを 12 回実行した。固定の双方向リングで各ノードをオフセット 1 と 3 の隣接ノードにつなぎ、伝播は最大二ホップとした。以下は当時の短時間のローカル構成テストの記録だ。
| ネットワークの Agent 数 | 修正前 p95 | 修正後 p95 |
|---|---|---|
| 32 | 5.66 ms | 4.28 ms |
| 128 | 13.21 ms | 4.91 ms |
| 512 | 47.64 ms | 5.15 ms |
図 1：同じ負荷に対する当時の前後比較。横軸は三つのテスト規模を並べたもの。線は読み取りの補助で、各点は 12 回のクエリの p95。
512 Agent の組ではスループットが毎秒約 22 回から約 209 回に上がった。各クエリの訪問数は依然 11 だが、構築するのは 10 要約、調べる寄与者は 50 になった。この二つの計数も三規模で同じだった。
対応比較では候補数、引き継ぎ数、訪問数、既存の資源計数を照合し、記録上は変化がなかった。修正の説明は明確だ。検索で使わない前処理を省いたのである。時間曲線と追加した作業量計数が互いを裏づけた。
この結果の範囲は、当時の単一マシン、同期実行、構成したトポロジーである。各組は 12 リクエストだけで、p95 は短い標本に線形補間を適用した統計量だ。本番の末尾遅延は並行処理、ネットワーク、データ変化の影響も受ける。ここで価値があるのは、全体規模とともに増える前置作業を実際に見つけて取り除いたことだ。
局所アルゴリズムには局所的なリクエスト経路が要る
中心のループは節約していても、初期化、シリアライズ、インデックス保守、後始末で全件を走査するアルゴリズムはありうる。今回は要約構築が抜けていた。新しい計数で、それも同じリクエストの費用に含めた。
自分のシステムでも小さく試せる。リクエストに必要な対象を固定し、無関係な対象だけを増やしながら端から端までの時間を測る。中心操作の計数が変わらず時間だけ増えるなら、リクエスト経路に沿って未計上の仕事を探す。
修正後は、使う要約だけを作る。10 要約、50 寄与者。一度の局所検索のために全網の案内板を用意することはなくなった。
資料について：2026 年 9 月 1 日の Discovery Front ローカル容量テストと対応分析による。本稿の作成時に元の比較ファイル、実行設定、現在の要約構築コードを照合した。コードは説明用の簡略形。詳細な所在は出版パッケージの SOURCE-NOTES.md を参照。既存実験に基づいて改稿したエンジニアリングノートである。