手元のテキストベクトル群に、別のチームのベクトルを取り込もうとしている。両方ともコサイン類似度を使い、ベクトルの長さもちょうど同じだ。同じインデックスへ入れるには、データを取り込むだけでよさそうに見える。
その前に答えるべき問いがある。両者の数値は、同じ空間を記述しているのだろうか。
ベクトルモデルの出力は学習によって得られた座標だ。あるモデルの第 17 次元と、別のモデルの第 17 次元に自然な対応関係はない。同じテキスト群をよく似た形で理解していても、座標の書き方は異なりうる。
ToWowが研究する NAC（Nested Anchor Coordinates、入れ子状アンカー座標）は、各者が自分のモデルで共通の参照群を観察し、その結果を交換するという発想から出発する。まず手計算できる例でこの動作を説明し、協力相手の発見への使い方を考えたい。
回転するだけで直接比較は破綻する
二次元のモデル A が、あるテキストを x = (1, 0) に置くとする。モデル B で同じテキストは x′ = (0, 1) だ。この二つを直接コサイン類似度で比較すると 0 になる。
しかし、この説明用の例では、B は A の空間全体を反時計回りに 90 度回転させただけだ。テキスト間の角度はすべて保たれる。各モデル内部の検索結果は完全に同じでありうるのに、先ほどのモデル間比較は同じテキストを直交する方向とみなしてしまった。
共通の参照対象 a と b を加えよう。A ではそれぞれ (1, 0) と (0, 1) にあり、回転した B では (0, 1) と (-1, 0) にある。
各モデルに、テキストが a にどれほど似ているか、b にどれほど似ているかを答えてもらう。
| モデル | テキストの元の座標 | 参照 a とのコサイン類似度 | 参照 b とのコサイン類似度 |
|---|---|---|---|
| A | (1, 0) |
1 | 0 |
| B | (0, 1) |
1 | 0 |
元の座標は異なるが、参照に対する結果はともに [1, 0] になる。この結果の列を比較すれば、例の中の一致を認識できる。
空間を回転させ、数値を比べる
ここで再現するのは空間全体の回転だけです。実際のモデルが学習した関係は別途測定する必要があります。
B を A に戻す行列を学習したわけではない。各者は自分の空間内で妥当な類似度を計算し、共通の順序に従って結果を書く。同じ対象群との関係記述を交換している。
公共の参照が座標になるまで
NAC の参照には、固定テキストや共通に入手できる例を使える。まずプロトコルで参照集合と順序を決める。参加者は自身のエンコーダー E でローカルの内容 x と全参照 a₁…aₘ を符号化し、次を生成する。
c_E(x) = [cos(E(x), E(a₁)), …, cos(E(x), E(aₘ))]
第一の位置は「第一参照との関係」、第二の位置は「第二参照との関係」を意味する。モデル A の元のベクトルは 384 次元、B は 1,024 次元でもよい。同じ m 個の参照で計算すれば、どちらも m 個の関係値を出力できる。
相対表現には明確な先行研究がある。Moschella らの ICLR 2023 の Relative Representations は、サンプルとアンカーとの類似度で表現を構成し、潜在空間の比較やモデル部品の接続を研究した。NAC はこの種の座標の考え方を採用し、開かれた Agent ネットワークに必要な分割送信、関係の方向、バージョンの発展をさらに研究する。
共通参照は「何番目の数が何に対応するか」という曖昧さをなくす。意味をどれだけ保持できるかは、モデルと参照の実際の性質による。回転例がきれいに成立したのは、回転が角度を保つからだ。現実のモデルは、区別そのものを異なって学ぶ可能性がある。
たとえば、あるモデルは「機材を借りられる」と「機材を購入中」を強く区別し、別のモデルはどちらも機材という話題の近くに置くかもしれない。公共参照はその食い違いを比較可能な形にするが、それが検索を損なうかどうかは、さらに判断する必要がある。
関係の表から協力相手の発見へ
機材試験の設計例を考える。小さなチームが熱画像による品質検査に取り組み、二時間の機材使用と現場指導を必要としている。近隣の研究室には空き時間があり、別のエンジニアも同種のカメラを探している。
二組の探し手が書いた文章は、最も似ているかもしれない。機材名、試験目的、技術用語がよく重なるからだ。研究室の紹介文は「計測機器プラットフォーム」「短時間の利用開放」「操作支援」といった言葉を使い、表現上はかえって需要から遠い可能性がある。
そこで信号には、その内容が関係の中で担う役割も必要になる。NAC の設計では、ローカルの記述を「求める」「提供する」「背景」という方向の異なる断片に分けられる。需要側の「機材を求める」は、まず研究室の「機材を提供する」と比較する。もう一人の探し手も経験や紹介を提供しうるが、それには別の協力理由が必要だ。
信号生成は、具体的には次のように書ける。
- ローカル Agent が今回の需要に関係し、発見に利用してよい内容を選ぶ。
- ローカルモデルで公共参照に対する関係値を計算する。
- 「求める」の方向、参照の版、有効期限を添える。
- 受信者が対応する「提供する」の断片を使って候補を比較する。
ネットワークに渡るのは、意味的な方向を持つ関係記述だ。日程や機材の適合性は、後続の対話で徐々に補える。
通信予算に合わせて座標を展開する
発見ネットワークでは、安価な粗い絞り込みの後、少数の候補に計算を投入したい場合がある。NAC は参照を安定した順序で並べ、短い接頭部を先に送り、必要に応じて増やせるようにする。
たとえば初回は最初の 32 個の関係値だけを交換し、詳しく見る価値がある候補では 128 個へ広げる。この長さは説明用の例だ。有効な設定は実際の課題で測る必要がある。短い接頭部で有用な対象をどれだけ落とし、次の部分を加えるとどれだけ回復し、計算と通信がどれだけかかるかを調べる。
順序は慎重に設計しなければならない。最初の 32 参照が似た産業調達場面ばかりなら、芸術や教育の協力を十分に区別できないかもしれない。長いベクトル全体の性能が良くても、先頭部分は悪いことがある。「切り詰められる」と「切り詰めても役立つ」は別の課題だ。
これは NAC と Matryoshka Representation Learning の関係にもつながる。後者は、異なる長さの表現が実用性を持つよう学習する。NAC は分割可能な順序を外部参照に置き、参加者が自身のエンコーダーを保持できるようにする。その自由度は新たな実験課題も生む。どの通信予算でも有用な信号になるよう、参照をどう選び、並べるべきだろうか。
モデルも共通参照も変わっていく
浮動小数点数の配列を一つ交換するだけでは足りない。受信者は参照の版、受け取った接頭部の長さ、生成時刻を知る必要がある。同じ長さの配列でも、別の問いに対応しているかもしれないからだ。
そこで NAC は座標とともにバージョンと方向を運ぶ。ローカルモデルが更新されたら、Agent は元資料に戻って参照結果を再計算できる。参照集合の更新には新旧の移行も必要だ。一定期間は両版の信号を生成するか、同じ版を明示的に支援するノード同士で比較する。
興味深いのは、共通の依存先を「全員が同じモデルを入れること」から「全員が同じ参照を入手し解釈できること」へ移す設計判断だ。モデル選択は各者が維持し、参照の品質と発展はネットワーク共通の課題になる。
採用を検討する条件
すべての内容を一つのサービスで符号化できるなら、共有エンコーダーは直接的な出発点になる。同じ空間のベクトルが得られ、接続も検索も簡単だ。既存ベクトルを空間をまたいで再利用する必要がある場合は、変換を学習する方法もある。vec2vec は埋め込み分布から翻訳を学ぶ方向を研究している。
NAC を研究する価値があるのは、参加者がローカルモデルを保持しながら、共通に解釈でき、詳細を段階的に増やせる交換表現を必要とする環境だ。工学的な選択では、検索品質、参照の計算、通信量、モデル変更後の保守費用を合わせて見る必要がある。
現在、ToWowには信号設計と参照実装があり、モデル間の発見効果は検証すべき課題として残っている。過去のローカル診断にはアンカー座標や他の表現が含まれたが、メーカーをまたぐこの方式を判断できる完全な評価には至っていない。本稿が紹介するのは仕組みと設計理由である。
共有エンコーダー、学習した写像、公共参照は、それぞれ保守費用を別の場所に置く。NAC は各者がモデルを維持しつつ、参照の品質と順序を共同で維持する選択だ。適切な交換表現になるかどうかは、その費用でどれだけ有用なモデル間比較を得られるかにかかっている。
研究資料：NAC の機構資料と Discovery Front の現状記録。ローカルの所在は出版パッケージの SOURCE-NOTES.md を参照。二次元座標、機材場面、32/128 の接頭部は説明用で、モデル実験の結果としては使っていない。