関連記事推薦のための埋め込みモデル比較

chezo.uno は Hugo で生成している個人ブログで、記事末尾の関連記事は prelims-cli が front matter に 書き込んでいる。記事を埋め込みベクトルにして、コサイン類似度の上位を推薦に使う仕組みである。

これを GitHub Actions 上で回している。ここが制約を決めている。

• GPU がない。推論は CPU のみ。ONNX Runtime で動くことが前提になる
• メモリが限られる。標準 runner は public リポジトリで 16 GB、 private で 7 GB。モデルの大きさだけでなく、埋め込み時のピークメモリも収まる必要がある
• 記事を追加するたびに走る。実行時間がそのまま公開までの待ち時間になる

この条件下で選べるのは軽量な埋め込みモデルに限られる。現状は言語ごとに 専用モデルを2つ持っており（日本語 ruri-v3-30m、英語 granite-small-english）、 言語判定して切り替えている。

出発点は、Bekko Embedding という軽量な多言語モデルへの興味だった（a25m のモデルカード）。アクティブパラメータ 8M / 25M という 小ささでこの用途に足りるなら面白い、というのがまずあって、そこから 現行の2モデルを置き換えられるかもしれない、 置き換えられなくても日英以外のカバレッジを広げられるかもしれない、 という2つの期待がついてきた。

そこで Bekko の2サイズと、同じく軽量な多言語モデルである granite-embedding-97m-multilingual-r2 を、現行の2モデルと同じ土俵で比較することにした。

「良い関連記事」の正解データはない。代わりに、記事に付いている人手のタグを 審判にした。同じタグを持つ記事同士を推薦できていれば、話題が合っているとみなす。 タグは推薦のために書かれたものではないので、審判としては独立している。

以下が、このレポートに出てくるすべての数字の定義になる。いずれも既製のベンチマークでは なく、この検証のために書いた代理指標なので、計算方法を残しておく。実装は scripts/compare_embedding_variants.py。 最初の指標（タグ一致率）には後述する設計上の欠陥が見つかったため、 モデル間の比較には次の2つ（固定プール precision@k と ペアワイズ AUC）を使う。

タグ一致率（any-tag@k）

記事 a のタグ集合を T(a)、推薦上位 k 件を R_k(a) とする。 採点対象は両側にタグがある組だけで、片方でも無タグなら数えない。

T(a) は front matter の tags / categories / keywords を小文字化して合併したもの。どのキーを使うかは --tag-keys で切り替える。この検証の主要な数値は tags と categories だけを使っている。

この定義には欠陥がある。採点対象 P をモデル自身が選んでいる —— どの記事を推薦するかはモデルが決めるので、分母がモデルごとに違う。 タグなし記事の推薦は分母から外れてノーカウントになるため、2つのモデルは同じ問題を 解かされていない。この帰結は「読み方で順位が逆になる」で示す。以下の2つが修理版で、 モデル間の順位はすべてこちらで判定している。

固定プール precision@k（judged-pool）

推薦候補をタグ付き記事だけに制限してから上位 k 件を取る。 情報検索で不完全な正解データに使う condensed list の手法で、 ソースもタグ付き記事に限るので、分母は「ソース数 × k」で固定され、 どのモデルも同じ記事プールから同じ数だけ選ばされる。S をタグ付き記事の集合とすると:

理論上の天井（どのランキングでも超えられないヒット数）も併記する。 同ラベルの相手が k 本未満しかない記事は k 本すべてを当てられないためで、 ja は k=3 で 285 枠中 203、en は 69 枠中 53 が上限になる。

ペアワイズ AUC

タグ付き記事の全ペアについて、同ラベルのペアが異ラベルのペアより 類似度上位に来る確率。0.5 が偶然。top-k の打ち切りを使わず類似度の順位全体を 使うので、ヒット数の増減では見えない差まで解像する。topk に依存しない。

実装は確率を数え上げるのではなく、Mann-Whitney U 統計量として計算する。 全ペアの類似度に順位（同値は平均順位）を振り、同ラベルペアの順位和から求める:

この形にすると、同ラベルペアが全部上位なら順位和が最大になって 1.0、 全部下位なら 0.0 になる。ペアを総当たりで比較せずに済むので、 日本語の 4,465 ペアでも一瞬で出る。

どちらの指標も、差には paired bootstrap の95%区間を付ける。 precision はソース記事単位、AUC は記事単位（ペア単位で引くと同じ記事を共有するペアの 相関で区間が狭く出すぎる）でリサンプルする。1,000回、seed 固定。

ハブ集中度

記事 x が何本の記事から推薦されたか（被推薦数、in-degree）を数え、その最大値と、 上位5記事が全推薦枠に占める割合を見る。N は記事数。

低いほど良い。特定の記事が話題と無関係にあちこちへ刺さる状態を捕まえる。 タグ一致率より先に反応することがあり、独立した観点として置いている。

プローブの分離幅

同じ内容を3言語に訳した3文（同トピック2文＋無関係1文）を埋め込み、 コサイン類似度の差を取る。実装は scripts/check_onnx_model.py。

この指標がランキング品質を測らないことは「指標の妥当性」で示す。

membership 変化と order-only 変化

2つの設定の推薦を比べたとき、上位 k 件の集合が変わったか、 順番だけが変わったかを分けて数える。順序だけの入れ替わりは front matter の差分には 出るが、読者から見た顔ぶれは変わらない。

この先に出てくる一致率は 0.3 から 0.5 のあたりに並ぶ。その値が高いのか低いのかは、 それだけでは決まらない。目盛りを与えるために、同じコーパスで無作為に選んだ2記事が タグを共有する確率を求めた。推薦を一切しなかった場合の下限にあたる。

日本語では観測値が偶然の8〜9倍で、指標は信号を拾っている。一方英語は偶然が 21%に達する。タグ付きが23本しかなく、語彙も python / oss / machine learning に 集中しているためで、無作為でも当たりやすい。

これが英語で差を解像しにくい理由の一つになっている。偶然の水準が高いぶん、 モデル間で使える幅が圧縮されている。記事数だけの問題ではない。 granite-97m-multilingual の int8 は topk=10 で 0.294、偶然の1.4倍にとどまる。

代理指標である以上、何を測れて何を測れないかを先に確定させる必要がある。 4点を確認した。

タグの出所によって順位が入れ替わる

front matter には人手の tags / categories のほかに、 TF-IDF で自動抽出された keywords がある （420本中405本に付与、2,350種、最頻値は「こと」）。これを審判に含めると、埋め込みが 置き換えようとしている当の手法との一致度を「話題の一致度」として測ることになる。 実際に審判を替えると、勝者が入れ替わる。

日本語では bekko の +7.6pt が −2.3pt に転じる。偶然一致率のほうは まったく動かない（どちらも 0.047）ので、目盛りが伸縮しているのではなく順序そのものが 変わっている。本レポートの数値はすべて人手の tags / categories のみで測っている。

英語では審判を替えても差がつかない（−0.6pt と +0.2pt）。汚染が日本語だけに出るのは、 keywords の付与率が日本語 405/420・英語 29/33 と大きく違うことに加えて、 人手タグの側が日本語では 95本しかカバーしていないためである。審判を替えると 採点対象が 271ペアから 2,090ペアへ8倍に膨らみ、その増分がすべて TF-IDF 由来になる。

修理後の指標で測り直すと、この汚染の出方まで見える。keywords 審判のもとでは 固定プール precision@5 で a8m が +7.6pt [＋5.6, ＋9.6] と有意に勝つのに、 同じ keywords 審判でも AUC では +1.1pt [−0.4, +2.5] しか差がない。 a8m の優位はランキング全体ではなく上位数件に集中しており、それは TF-IDF の語を 表層的に共有する記事が最上位に来やすいという説明と整合する。

言語をまたいだ絶対値は比較できない

偶然一致率は日本語 0.047 に対し英語 0.209 で、4倍の開きがある。 日本語の 0.40 と英語の 0.40 は同じ意味を持たない。 本レポートで言語をまたいで比べているのは、モデル間の順序と符号だけにとどめている。

プローブの分離幅はランキング品質を測らない

同一内容の3言語プローブで、同トピックのペアと無関係な文の類似度差を取る指標である。 bekko-a25m は a8m より分離幅が狭い（日本語 0.173 対 0.379）が、推薦は良い。 この指標が捉えているのは埋め込み空間の広がり方であって、ランキングの優劣ではない。

既存2モデルは無関係な文にも 0.72〜0.85 を返し、値が狭い帯に圧縮されている。 ruri のフランス語 0.072 と granite-english の日本語 0.055 は、守備範囲外の言語で分離が ほぼ消えることを示す。この指標の用途は「壊れていないか」「閾値を置けるか」の 判定に限られる。専用モデルを他言語へ流用できない根拠としては使える。

日本語の69種のうち39種、英語の26種のうち19種は、1本の記事にしか付いていない。 1本しかないラベルは定義上ペアを作れないので、語彙の半分以上は指標に何も寄与しない。 残りが作れる同ラベルのペアは日本語で 212、英語で 53 しかない。

これを全ペアと並べると、この指標の天井が見える。日本語のタグ付き95本が作る 4,465 ペアのうち、同じラベルを共有するのは 212 ペア（4.7%）だけ —— これが「正解」の総数である。固定プールの topk=3 では、どのランキングでも 285 枠中 203 ヒットが上限で、現行モデルは 103（上限の51%）を取っている。悪い数字ではないが、 正解の総数がこの規模である以上、ヒット数だけで数ポイントの差に意味を持たせるのは難しい。

英語には machine_learning と machine-learning が 別のラベルとして存在した。この検証の途中でタグの正規化を行い、本レポートの数値は すべて正規化後に測り直したものである。

分解能 —— この指標は何ポイントの差まで見えるのか

タグ一致率の分解能は |P|（両側にタグがある推薦ペアの数）に依存する。そして |P| は小さい。 日本語は 420本 × topk=3 で 1,260 件の推薦を出しているのに、 採点できるのは 174 件、全体の 14% しかない。 理由は一致率の低さではない。一致率自体は 49%、偶然の10倍あって信号ははっきり出ている。 効いているのはタグの網羅率のほうで、人手タグが付いているのは 420本中 95本。 しかも推薦する側とされる側の両端にタグが必要なので、23% が二乗で効く。

ではモデル間の2ポイントの差に意味はあるのか。paired bootstrap の95%区間で測ると、 3つの指標で分解能がはっきり違う。

固定プール precision は k が大きいほど区間が締まり、日本語の k=10 では ±1.3pt まで縮む。旧指標では「差があるとしても ±7pt 以内」という 上限しか言えなかったのが、修理後は 1〜2pt 台の差を判定できるセルが出てくる。 実際にゼロを外れたセルが現れたことは実験の節で示す。

分解能を上げるもう1つの方法はタグの付いた記事を増やすこと。420本すべてに付けば 同ラベルペアは大きく増え、区間はさらに縮む。AUC が k=10 の precision より 英語で広いのは、記事単位のリサンプルでは23本しかない標本の揺れをまともに受けるためである。

pooling を間違えると、エラーは出ないまま推薦だけが悪くなる。ruri と granite-english は ONNX にモデル自身の文ベクトルが同梱されていたので、自前の pooling と 突き合わせて実測で確定した。bekko と granite-multilingual は同梱がないため、 それぞれ 1_Pooling/config.json で確認している。

モデル間の判定は固定プール precision@k と ペアワイズ AUC で行う （分母がモデル依存になる旧指標での見え方は、記録としてこの節の後半に残す）。 precision は topk 3 / 5 / 10 で符号が揃うかを見る。AUC は topk に依存しない。

2,000 文字の時点でゼロを外れるのは granite-97m int8 の英語だけで、しかも悪い方向 （P@5 −7.8pt [−13.9, −1.7]、P@10 −5.7pt [−10.4, −1.3]）。量子化の劣化であって モデルの実力ではない（付録）。bekko の2つは、どの言語のどのセルでも現行と 区間が重なる —— ただし点推定は寄っていて、AUC は日本語で a25m +1.7pt、 英語で a8m +3.8pt / a25m +3.2pt と、4つの比較すべてで bekko 側がプラスである。

「同等か、わずかに上かもしれないが、この標本では断定できない」—— これが固定プールでの実験1の読みになる。本番条件（8,000 文字）での再測定と 有意になるセルは「読み方で順位が逆になる」の後で扱う。

従来指標での見え方（記録）

以下は分母の欠陥が見つかる前の読みである。専用モデルを破線の基準に置き、 多言語の候補3つを重ねた。数字そのものは正しいが、 モデル間の順位はここからは読めない。

人手の tags / categories のみを審判にした値。

同じデータが、読み方によって逆の順位を返す。日本語の一致率では現行の ruri が topk=3・5 で最良、再現率では bekko-a25m が3点とも最良になる。 どちらかが正しいのではなく、分母の取り方が違う。

一致率の分母は「採点できたペア数」で、これはモデルが動かせる。 タグの付いた記事を推薦先に選びやすいモデルほど分母が増え、率は下がる。実際 a25m の 採点対象は ruri より常に多い（194 対 174、307 対 271、564 対 513）。 再現率の分母は「取りうる正解数」で、こちらはコーパスだけで決まるので動かせない。

英語では両方の読み方が同じ向きを指す。一致率も再現率も bekko 系が topk=3・5 で上、現行の granite-small-english はどの列でも最良にならない。 ただし採点対象は 58〜199ペアしかない。

granite-97m-multilingual の int8 は、日本語で被推薦数が 47 まで伸びる （現行 ruri は 35）。量子化の影響は付録に。

ここまでの5モデルは、すべて同じ条件で比べている — 本文の先頭 2,000 文字だけを 埋め込むという条件で。実験1が固定していたこの値を、実験2では動かす。

2,000 という数字は max_content_chars の既定値で、メモリを抑えるために 置かれたものだ。品質のために選ばれた値ではない。まず、どれだけ捨てているのかを数えた。

数え方に注意が要る。prelims は埋め込む前に HTML タグ・コードフェンス・ 数式・URL を除去するので、Markdown の生ファイルを数えると実際にモデルが見る量を 大きく上回る。このコーパスは Medium からの移行記事が多く HTML と URL を大量に含むため、 生ファイル基準では ja の中央値が 1,205 文字・2,000 超えが 154本に見えていた。 上の表はフィルタ後の値で、本番の実行ログ（2,000 → 8,000 で ja 93本・en 15本が 再埋め込みされた）と一致する。

英語は本文の半分以上を捨てて埋め込んでいた。中央値が 1,854 文字なので、 長い記事ほど導入部だけで比較されていたことになる。分布で見るとさらにはっきりする。

日本語は 78% が 2,000 文字に収まっている。最も多い階級は 500 文字以下で、 420本のうち 150本を占める。上限を 8,000 に上げても、93本しか入力が変わらない。 英語は 2,000 文字以下が 55% にとどまり、8,000 文字を超える記事も 12% ある。

この差が、同じ設定変更が英語で効いて日本語で効かなかった理由をそのまま説明する。 なお 8,000 文字を超えて残る日本語記事は 420本中1本だけで、日本語では 8,000 がほぼ「全文」にあたる。

この検証で唯一、読み方によらず同じ向きに出た結果である。 的中ペア数は日本語で +1 / ±0 / +6、英語で +1 / +2 / +2。6点中5点でプラス、 残る1点も横ばいで、マイナスが1つもない。

モデル比較と違ってここが揃うのは、比べているのが同じモデルどうしだからである。 タグ付き記事を選びやすいかどうかというモデルの癖が両側で同じなので、分母の偏りが相殺される。 指標が壊れるのはモデルを跨いだときで、設定を跨いだときではない。

一致率で見ると英語のほうが大きく伸びて見えるが（+3.4 / +5.3 / +0.6 対 日本語 +0.2 / −0.5 / +1.0）、これは英語の分母が縮んでいるため（60→58、103→96）。 的中数で見れば両言語とも同程度に増えている。

8セルすべてで点推定が非負、負に出たセルはひとつもない。単セルでは 有意にならない（k=10 の2つが区間の端でゼロに接する）が、同じ向きが 指標をまたぎ、言語をまたぎ、k をまたいで崩れないことが、この変更のいちばん強い根拠になる。 モデル比較と違って両腕が同じモデルなので、旧指標の分母バイアスもほぼ相殺されていた —— 修理前後で結論が変わらなかった唯一の実験である。

それでも 8,000 を採る。両言語で正解ペアが増え、どちらも悪化していない。 費用はフィルタ後で日本語 1.33倍のトークン・2.5倍の attention、英語は絶対量が小さい。

その先は測っていない

生テキストで測っていた段階では 20,000 文字（実質無制限）まで見ており、8,000 から先は 両言語とも動かなかった。フィルタ後では測り直していない。ただしフィルタ後の最長記事は 日本語 8,890 文字・英語 15,581 文字なので、日本語で 8,000 を超えて残っている本文は ごく一部の記事の末尾だけである。

読み方で順位が逆になる

実験1で見えた食い違いを、専用モデル対 bekko-a25m に絞って詰める。同じ推薦結果を 2つの読み方で採点し、差分（bekko − 専用モデル）を重ねた。 ゼロの線が専用モデルである。

指標を直しても順位は決まらなかった。ここまでで未解決なのは、実はもっと手前の問いである —— この代理指標は、読者にとっての「関連している」をどれだけ捉えているのか。 指標の内側では答えられないので、推薦そのものを人手で判定して突き合わせた。

対象は推薦の顔ぶれが変わった 389 記事。専用の判定ツールを書き、2つの推薦リストを 並べて「関連記事として妥当だ」と思うものにチェックを付けていく形にした。設計で気をつけたのは 3点である。

• ブラインドを既定にした。どちらの列がどのモデルかを記事ごとに シャッフルして伏せ、タグとタグ一致の印も隠した。タグはモデルを選ぶ根拠に した指標そのものなので、見えたまま判定すると「指標が正しいか」を指標自身で検証することに なってしまう
• 同じ推薦は1回だけ判定する。両モデルが同じ記事を推薦している場合は 片方をチェックすればもう片方にも反映される。同一ペアに矛盾した判定が付かない
• 層を混ぜない。判定したのは「シード固定の無作為 40 件」と 「総入れ替え群（共通推薦がゼロ＝2モデルが最も食い違う 64 件）」を中心とする 162 記事。英語は変化した 19 件すべてを判定した。 総入れ替え群は差が最大になるように選んだ群なので、全体の推定には使えない。 不偏な推定値は無作為 40 件のほうだけである

判定 162 記事 / 827 ペア（日本語 143・英語 19）、「関連」とした推薦 458 件、 「どれも関連しない」とした記事 19 件。判定者は著者1名。

結果1 —— モデル差は、やはり検出できない

4つの層すべてで a25m が非負、現行が上回る層はひとつもない。 記事単位の勝敗も a25m 46勝・現行 36勝・引き分け 80（符号検定 p = 0.32）。 方向は一貫しているのに、どの層も区間はゼロを跨ぐ。 不偏推定である無作為 40 件の +1.7pt は、実数でいえば120 枠のうち 2 件多いだけである。

結果2 —— 代理指標は、関連性の 9% しか見ていなかった

本題はこちらである。判定済み 827 ペアについて、タグ一致を人手判定の予測器として 評価すると、指標が何を測っていたのかが数字で出る。

適合率 0.755、再現率 0.087。タグが一致していれば人手もほぼ関連と認める —— その向きは信頼できる。だが人手が「関連」とした 458 件のうち、 タグが拾えたのは 40 件だけである。

理由は単純で、判定済みペアの 86%（714/827）は少なくとも片側にタグがなく、 指標からは最初から見えていない。そしてその見えない領域で、 人手は 392 件を「関連」と判定している。

言語で分けると、同じ指標がまったく違う壊れ方をしているのが見える。

日本語は「当たれば正しいが、ほとんど何も見えない」 （適合率 0.86・再現率 0.06）。英語は「かなり見えるが、当たっても外れることがある」 （再現率 0.29・適合率 0.63）。タグ付き率が 23%（ja）と 70%（en）で違うためで、 タグが厚い英語では今度はタグ一致が緩くなり、人手が無関係と判断するペアを 9 件拾っている。 どちらの側に倒しても、代理指標が人手判定の代わりにはならない。

この非対称性は、実験の読み方をそのまま決める。

• 「タグが一致した推薦は妥当」—— この向きの推論は概ね安全（適合率 0.755）
• 「タグが一致しない推薦は妥当でない」—— この向きは完全に誤り（再現率 0.087）
• そしてモデル比較で効いていたのは後者の推論である。 2モデルの違いはほとんど無タグ領域で起きており、指標はそこを一切見ていなかった

つまり実験1・実験2の数値は「壊れていた」のではなく、 関連性のごく一部の断面を、その断面としては正確に測っていた。 断面が狭すぎてモデルの優劣を語れなかった、というのが正しい表現になる。

指標に写らない差 —— 具体例

タグの外側で何が起きているかは、判定中に読んだ個別の例に出ている。 a25m の勝ちパターンは同一エンティティの検出で、これはタグには まず書かれていない類の一致である。

2つの癖はどちらも壊れていない。どちらを好むかは設計の選択であって、 測定で決まる問題ではなかった —— というのが、162 記事を読んだ後の実感でもある。

結果3 —— では記事ごとに使い分けるべきか

癖が違うなら、次の問いは自然に出てくる。「この記事にはこちら」が 決まっているのではないか。もしそうなら、記事ごとに良い方を選ぶ仕組みが 両モデルを上回れる。

ただしこれは、勝敗表を眺めても答えられない。互角の2モデルでも、 推薦する記事が違えば勝敗はばらつくからで、「記事ごとに勝ち負けがある」ことは 構造の証拠にならない。問うべきはその勝敗が予測可能かである。3通りで測った。

オラクルの行が分かりやすい。記事ごとに勝った方を採用すれば 0.603 → 0.698 まで 上がる（+9.5pt）。ただし「勝った方を選ぶ」という操作は、2つのモデルが完全に互角でも 雑音の上澄みを取るだけで +7.9pt [+5.7, +10.0] 稼げてしまう。 観測された +9.5pt はその分布の端に乗っているだけで、 構造があるとしても雑音とほぼ同じ大きさである。

年代の傾向 —— 新しい技術記事ほど a25m 有利 —— は点推定では綺麗に並ぶが、 2020年以降は n=15 で区間が [−6.7, +26.7]。年との相関そのものは r = +0.086、p = 0.301 で、 並びの綺麗さは標本の細さで説明がつく。

結局、「どちらが好きか」という水準に落ち着く。 測定でも目視でも順位はつかず、記事ごとの使い分けも支持されない。 残るのは、どちらの癖を自分のブログに置きたいかという選好である。

統合先を1つに絞る以上、多言語候補2つのどちらを採るかは決めなければならない。 しかも効いてくるのは主に日英以外で記事を書いたときで、そこは測れていない。 この2言語での実測に加えて、公開されたカバレッジ情報に頼ることになる。

どちらも「学習した言語」は広い。bekko は100以上の言語を含むデータで 言語横断検索ができるように学習されており、翻訳を挟まずに日本語のクエリから英語の文書を 引ける。granite はベースのエンコーダが200以上の言語で事前学習されている。 違いは学習範囲ではなく、言語ごとの数字がどこまで公開されているかにある。

bekko が言語別に評価している14言語

学習範囲の上限ではなく、実測スコアが公開されている範囲である。 英語 NanoBEIR と、コミュニティが公開した13言語の翻訳版で測られている。

英語 · スペイン語 · イタリア語 · ポルトガル語 · ドイツ語 · ベトナム語 · 日本語 · フランス語 · スウェーデン語 · ノルウェー語 · 韓国語、 そして下位3言語の アラビア語 · セルビア語 · タイ語。

granite-97m-multilingual が強化サポートする52言語

ベースのエンコーダは200以上の言語で事前学習されており、どの言語でも汎用の埋め込みは 得られる。そのうえで、検索ペアと cross-lingual の学習データを明示的に与えた52言語で 品質が高いとされている。

モデルカードの表記のまま引用する。

sq  Albanian     ar  Arabic       az  Azerbaijani  bn  Bengali
bg  Bulgarian    ca  Catalan      zh  Chinese      hr  Croatian
cs  Czech        da  Danish       nl  Dutch        en  English
et  Estonian     fi  Finnish      fr  French       ka  Georgian
de  German       el  Greek        he  Hebrew       hi  Hindi
hu  Hungarian    is  Icelandic    id  Indonesian   it  Italian
ja  Japanese     kk  Kazakh       km  Khmer        ko  Korean
lv  Latvian      lt  Lithuanian   ms  Malay        mr  Marathi
no  Norwegian    fa  Persian      pl  Polish       pt  Portuguese
ro  Romanian     ru  Russian      sr  Serbian      sk  Slovak
sl  Slovenian    es  Spanish      sw  Swahili      sv  Swedish
tl  Tagalog      te  Telugu       th  Thai         tr  Turkish
uk  Ukrainian    ur  Urdu         uz  Uzbek        vi  Vietnamese

加えて Python · Go · Java · JavaScript · PHP · Ruby · SQL · C · C++ の コードで学習されており、コードの cross-lingual 検索にも対応するとされる。

宣言の粒度が違うので、カバレッジの広さで優劣はつけられない。 granite の52言語は検索ペアと cross-lingual データを明示的に与えた言語の一覧であって、 言語ごとのスコアではない。bekko の100以上は学習に含まれた言語であって、こちらも 言語ごとのスコアではない。どちらも「この言語なら大丈夫」と言える形の情報を 出していない。

実際に差があるのは1点だけ、言語別の実測値が公開されているかどうかである。 bekko は14言語について数字がある。granite は言語別の数字を公開していない。 統合先を選ぶ材料としては、この14言語だけが根拠らしい根拠になる。

公開ベンチマークでの位置

この2モデルは bekko の公開記事で直接比較されている。 言語別ではないが、第三者の測定として参照できる唯一の数字なので引く。

6項目中5項目で bekko-a25m が上、granite が上回るのは MMTEB の検索タスク （60.3 対 57.5）だけ。アクティブパラメータは a25m のほうが少ない （24.9M 対 28.3M）。

関連記事推薦は記事同士の対称的な類似度を扱うので、query → document の 検索タスクより、全131タスク平均の MMTEB (ALL) のほうが近い。そこでは 58.3 対 51.9 で 6.4pt の開きがある。ただしこれは言語別の数字ではないので、 「専用モデルのない特定の言語でどちらが良いか」には答えていない。

granite 側は IBM 自身が「枝刈りモデルは低リソース言語での劣化がより顕著」と 書いている。フォールバックは主に低リソース言語に使うので、ここは正面から効く。日本語という 高リソース言語ですら a25m に4〜5pt 負けている点も、その注記と整合して見える。

多言語モデル1つに統合し、入力長も変更する。 検証の途中で判断が二度ひっくり返っている。指標を修理する前は「置き換えるだけの 品質改善が測れない」。修理後は「品質は同等かわずかに上だが、その差がコスト増に届かない」。 そして人手評価とコストの実測を経て、「品質は同等。順位は原理的に決められず、 記事ごとの使い分けも支持されない。ならば残るのは選好とコストで、そのコストが 思ったより小さかった」——これが最終形である。

ja  → bekko-embedding-v1-a25m    199 MB  変更（← ruri-v3 + "トピック: "）
en  → bekko-embedding-v1-a25m    199 MB  変更（← granite-small-english）
他  → 同じモデルで動く

max_content_chars  2,000 → 8,000          変更

• 品質は判断材料から外れた。固定プールでは日本語 P@3 が同点、 P@10 で a25m が +1.4pt、AUC +1.8pt（n.s.）。人手評価では無作為 40 件で +1.7pt [−9.2, +12.5]、記事単位 46勝36敗80分（p = 0.32）。 英語は変化した 19 件すべてを判定して 完全な引き分け（40/57 対 40/57）。 すべての層で a25m が非負、現行が上回る層はひとつもないのに、 ひとつも有意にならない。そして 389 件すべてを判定しても有意にならないことまで分かっている （「人手評価」）。測れないものを判断根拠にはできない
• 決め手は癖の選好。a25m は同一エンティティ —— 同じアーティスト、 同じ著者、姉妹イベント —— を拾い、現行はトピックの純度を保つ。 記事ごとに使い分ける根拠は検定で否定されたので（結果3）、 どちらか一方の癖を選ぶことになる。個人ブログでは、 タグにも指標にも現れないエンティティのつながりのほうが読者に効くと判断した
• コストは実測して小さかった。本番の GitHub Actions で 初回 3分29秒（452記事を全再埋め込み、モデルDL込み）。内訳は 埋め込み 3分8秒・モデルDL 17秒で、199 MB という数字ほどには効かない —— アクティブパラメータ 25M の MoE なので1記事あたり約0.4秒で済む。 2回目以降は新規記事だけなので定常コストは変わらない。 同じ重みで2度回して推薦がバイト単位で一致することも確認した
• 副次的な利得。言語判定による切り替えが消え、設定が単純になる。 日英以外を書いたときも同じモデルが動く —— 元々の動機だった多言語カバレッジが、 品質を落とさずに手に入る
• max_content_chars を 2,000 から 8,000 へ。 この検証でいちばん確度の高い結果になった。固定プールと AUC の8セルすべてで 点推定が非負、負のセルはゼロ。両腕が同じモデルなので旧指標の欠陥の影響も受けていない。 「わずかに増えて、外しても損しない」で入れる
• 入力長を動かす前に、コーパスの長さ分布を見るべきだった。 入力が実際に変わったのは日本語 420本中93本、英語 33本中15本。 残りは上限を上げても1文字も変わらない。設定が届く範囲は、 モデルではなくコーパスが決めている
• 日英以外での品質は、依然として未検証のまま採用する。測ったのは 日本語と英語だけで、どちらも専用モデルが存在する言語である。他言語で a25m が どう振る舞うかは分からない —— ただしこれは以前より良い状態である。 専用モデルを持たない言語に対して、これまでは英語モデルを流用するしかなく、 プローブの分離幅ではフランス語 0.139・日本語 0.055 と守備範囲外で分離がほぼ消えていた。 未検証の多言語モデルのほうが、守備範囲外と分かっている専用モデルよりましだと判断した
• 対抗馬だった granite-97m-multilingual は落選した。実用になるのは fp32 のみで （int8 版は英語で AUC が 0.747 → 0.680 と崩れる）、その fp32 でも英語 AUC は a25m を下回り、公開ベンチマークでも 6項目中5項目で a25m が上だった

代理指標について

最初の指標は、粗い問いには答えられた。「置き換えるべきか」に対して 「置き換えるだけの改善は測れない」と返す —— 上限を知るだけならそれで足りた。 壊れたのは一段細かいことを訊いたときで、「どちらのモデルが良いか」を数ポイントの差で 決めようとした瞬間に、採点対象をモデル自身に選ばせているという設計が表面化し、 読み方によって順位が逆転した。

修理は2つの操作でできた。分母をモデルから取り上げる（候補をタグ付き記事に固定）、 閾値を捨てて順位全体を使う（ペアワイズ AUC）。どちらも情報検索では 不完全な正解データへの定石で、新しい発明ではない。修理後は区間が ±5pt から 1〜4pt 台に縮み、初めてゼロを外れるセルが出た。指標の設計を直すことは、 データを増やすのと同じくらい分解能に効いた。

それでも残っていた欠陥は、指標の内側からは見えなかった。 修理後の指標は、分母こそ公平になったものの、依然として関連性の 9% しか 見ていなかった（人手評価）。適合率は 0.755 と比較的高いので「タグが当たれば妥当」は 言えるのに、モデル間の差はほとんど無タグ領域で起きていて、そこは測定の外だった。 正しく設計された指標が、正しく狭い断面を測っていたというのが最終的な診断になる。

そしてこの検証で見つかった誤りは、どれも指標を睨んで見つかったものではない。

• 審判が TF-IDF 由来の語を含んでいた —— 審判を差し替えて気づいた
• 本番と違うテキストで測っていた —— 本番の実行ログと数字を突き合わせて気づいた
• 比率が分母の大きさに引きずられていた —— 個別の記事を1本ずつ読んで気づいた
• その分母の効果が、入力長の見かけの結論を作っていた —— 率を的中数と分母に分解して気づいた
• 分母をモデルが動かせるのは設計そのものの欠陥だった —— 同じデータを2つの読み方で並べて順位が逆転して確定した
• 修理後も指標が関連性のごく一部しか見ていなかった —— 推薦そのものを人手で判定して初めて分かった

いずれも指標の外にあるもの、あるいは指標同士の突き合わせで出てきた。 代理指標は単独では検証できない。代理指標は「何を正解とみなすか」 だけでなく「分母を誰が決めるか」で壊れ、直した後も「どれだけの範囲を見ているか」で 限界が決まる。3つ目で「副作用がある」と注記を書いた後も、自分の結論がその副作用で できていることにはしばらく気づかなかった。注記は免罪符にならない —— 設計を直すまで、誤りは結論に居座り続けた。

代理指標を作るなら、小さくてよいので人手判定の標本を先に取り、 代理指標をその予測器として評価しておくのが安い保険になる。今回それを最後にやったせいで、 「指標が低い＝推薦が悪い」という誤読を長く抱えたままだった。実際には推薦の 76% は妥当だった。

今回いちばん大きかった発見も、指標が出したものではない。入力長が英語で効いて 日本語で効かない理由は、420本中 327本が 2,000 文字に届いていないというコーパスの 長さ分布にあった。指標はそれを追認しただけで、説明はデータの側にあった。

この検証で測ったのは日本語と英語の2言語だけで、どちらも高リソース言語、 どちらも専用モデルが存在する言語である。フォールバックが必要になるのは、 まさにその条件を満たさない言語だ。結論で a25m を「第一候補」と呼ぶにとどめ、 採用を決めなかったのは、この非対称性のためである。

仮に決めようとすると、推論はこう組む必要がある。

1. 公開ベンチマークが複数言語の相対順位を与える（第三者の測定）
2. このコーパスが、その順位が関連記事推薦でも通用することを2点だけ確認する
3. 未測定の言語は、1のスコアが日本語と同程度なら2も同程度だろう、と外挿する

3が飛躍にあたる。渡っているのは「別の言語」という距離だけではなく、 リソース量という軸を渡っている。低リソース言語は cross-lingual transfer に 頼る領域で、どのモデルも最も劣化しやすい。IBM が granite について 「枝刈りモデルは低リソース言語での劣化がより顕著」と明記しているのは、 まさにこの領域についてである。

確かめる方法は1つしかない。対象言語の記事を数十本用意して、同じ手順を そのまま回すこと。この検証の道具立ては言語に依存しないので、コーパスさえあれば同じ指標で 測れる。対訳記事があれば、推薦の顔ぶれが言語をまたいで保たれるかも見られる。 chezo.uno には日本語と英語しかないので、現状では実施できない。

そのほかの限界として、審判が人手タグである以上、タグの付け方の癖が そのまま指標に入る。採点対象は topk に応じて58〜536ペアしかない。1つのブログの2言語で 測った結果であることも含め、ここで出た差はいずれもこの範囲でのものである。

人手評価にも同じ種類の限界がある。判定者は著者1名で、 一致率を測る第二の判定者がいない。ブラインド化（モデル名・タグ・タグ一致印を すべて伏せ、左右を記事ごとにシャッフル）でモデルへの偏りは断ったが、 「関連している」の基準そのものが著者の感覚に依存している点は残る。 判定したのは変化した 389 件のうち 162 件で、日本語は標本、英語は全数である。

ruri と granite は int8 の model_quantized.onnx、bekko は fp32 の model.onnx で測っていた（bekko の量子化版は作者が非推奨としている）。 bekko だけ有利な条件ではないかを確かめるため、3モデルを int8 と fp32 の両方で回した。

本番の2モデルは量子化で壊れていない。AUC の差は ruri +0.6pt [−0.2, +1.5]、granite −0.4pt [−3.2, +3.2] とどちらもゼロを跨ぎ、固定プールのヒット差も ±2件にとどまる。int8 のままでよい ——ruri を 120 MB に、granite を fp32 に置き換える理由は出なかった。

壊れていたのは候補の granite-97m-multilingual だけで、しかも被害の出方が言語で違う。 英語では AUC が 0.747 → 0.680 と 6.7pt 崩れ、固定プールでも全モデル中で唯一、 現行に有意に届かないセルを作った（実験1）。日本語では AUC がほぼ動かないのに、 ハブ集中は int8 が明確に悪い（最大被推薦数 47 対 39）。 同じ量子化が、英語では順位の質に、日本語ではハブ集中に出ている。

このモデルは 311m からの枝刈り版（22層→12層）で、冗長性が削られているぶん量子化に 回せる余地も残っていない、という説明が自然に見える。量子化耐性はモデル固有の 性質であり、1モデルでの測定を他モデルに一般化できない。実際、同じ検証の中で 3モデルが無傷、1モデルだけが壊れた。

したがって granite-97m-multilingual を比較するときは fp32 の値を使う。 int8 の数値を「このモデルの性能」として並べると、量子化の劣化をモデルの品質と取り違える。

副産物として、タグ審判が推薦の入れ替わりに対してかなり鈍いことも 見えた。ruri の int8 と fp32 では日本語 420本中 319本の推薦が変わっているのに、 固定プールのヒットは2件、AUC は 0.6pt しか動かない。顔ぶれが大きく変わっても、 タグで測れる範囲では同水準ということが起こりうる。

いずれも prelims-cli の scripts/ にある。

• check_onnx_model.py — ONNX の入出力、必要入力の充足、出力ランク、 モデル自身の文ベクトルと突き合わせた pooling の確定、プローブの分離幅
• compare_embedding_variants.py — 2設定でコーパスを回して差分と指標を出す。 タグ一致率・ハブ集中度に加えて、固定プール precision@k とペアワイズ AUC を paired bootstrap の95%区間つきで出力する（--bootstrap、既定1,000回・seed固定）。 --vary config で任意のモデル同士を比較でき、--cache-dir で 埋め込みを再利用するので topk スイープは1回分の計算で済む
• rerun_all.sh — 本レポートの全比較（モデル×2言語×topk 3水準、入力長、 量子化、審判の差し替え、per-article diff）を1コマンドで再実行し、出力をファイルに残す。 本レポートの数値はすべてこの出力から取っている
• judgments/ — 人手評価のラベル（162記事・827ペア）と集計スクリプト。 層別の precision@3、ブートストラップ区間、タグ指標との混同表がそのまま再現できる

bash scripts/rerun_all.sh          # 全比較の再実行（キャッシュ済みなら数分）

# 単発で1比較だけ回す場合:
python scripts/compare_embedding_variants.py ../chezo.uno/content/post \
    --language ja --permalink-base /post --topk 5 --vary config \
    --tag-keys tags categories --cache-dir ~/.cache/prelims-compare \
    --a "language=ja,prefix=トピック: " \
    --b "model_name=hotchpotch/bekko-embedding-v1-a25m,\
model_file=onnx/model.onnx,pooling=mean"

埋め込みキャッシュは記事本文だけをキーにしているので、front matter の タグを直してもキャッシュは温かいまま。審判（タグ）の修正後の再計測が数分で済むのは この性質による。