ブログの推薦用軽量embedding modelをBekkoに変えた

Wed, 05 Aug 2026 19:55:00 -0700

前回の話はこちらにあるので見てほしい

今、このブログではBekko a25mで関連記事が出るようになっている。そこに至るまでの経緯を書いていこう。

最新版のレポートはこちら

Opus 5が設計する代理指標の罠

正解ラベルのない推薦タスクなため、タグ・カテゴリ一致率という指標をOpus 5が提案した。この代理指標の重大な問題にOpus 5が気づいたため追加調査を行った。

一致率の分母 |P| というのは、推薦された記事に依存して変わるのである。

Bekko a25mは、タグ・カテゴリのついた記事を推薦しやすいという傾向が見られた。なので、再現率が上がり、分母が増えるから一致率が下がるという現象が発生していた。しかも、これをずっとOpus 5はHTMLに補足として書いていたのである！（人もLLMも真面目に読んでいなかった！）

Fable 5への切り替えとアノテーションツール

これを改善するために、Fable 5に切り替え指標を提案してもらった。今回は、分母を固定する固定プール precision@k とペアワイズAUCを使って比較をした（詳細はレポートを見てほしい）。Top 3についてみると、Bekko a25mのほうが同等か良くなっていた。

現行モデル対 bekko-a25m（英語のP@3は結局人手評価では）

しかし、タグ・カテゴリが付与されている記事は限られるし、同じタグがある記事数も限られるということを思い出し、タグの出現頻度分布を見たところ、やはり厳しいだろうとなった。

実際のデータをみないといけないと思い、Claudeに比較とアノテーションのためのツールを作ってもらいブラウザで人手評価をした。ツールでは出力結果に（順位を除いた）差異があったものだけを評価するスタイルになっている。Fableはしれっとactive learningの手法を使ってきたのだ。実は一部出力に対する所見はOpus/Fableにも出してもらっていたが、自分でデータを見ることが大事というのを思い出し初心に帰ったのだ。

アノテーションツール

389記事中162記事を評価したところで打ち切ったのだが、それを元に評価をし直したところ、信頼区間の下限まで見ると自信はないが、top 3の指標の差は全部非負であった。

LLMから得られた所見も役に立った。

The Real Group の新譜紹介 → a25m は同じアーティストの旧譜レビュー2件を並べる。現行は別アーティストのライブ告知を返した。

石田衣良「うつくしい子ども」の書評 → a25m は同じ著者の「アキハバラ＠DEEP」「愛がいない部屋」を並べる。現行は著者一致1件。

川崎Ruby会議01 の開催報告 → a25m は姉妹イベントの神奈川Ruby会議を最上位に。現行は毎月のミートアップ報告を返した。

姉妹イベント、よくわかりましたね。著者やアーティストの重なりも見ており良いのでは、という気持ちになった。癖と言うか傾向の違いはあれど実用に足りうると言えるだろう。

ブログ初期はほぼ日記だったので、雑多なテーマが多くタイトルからは想像できない記事も多かった。

遠回りをしたけど、結局は人手でデータを見るのが大事なのであった。

CIでembeddingする際の技術的なハードルの解決

並行していくつかのGHAのCIで実行するための最適化を行った。

モデルサイズが大きくなってもCIの実行時間を伸ばさないために、HFのモデルキャッシュをGHAでキャッシュする
embedding時にメモリ上限に引っかからないために、バッチングを最適化

これらにより、全452記事のembeddingがモデルDL込で3分8秒（キャッシュ利用時で2分51秒）と現実的な時間で動くことが確認できた。実際には、embedding vectorの計算は記事が追加されるごとに差分で実行されるので、もっと速くなる。

つまり、運用上の懸念点がなくなったのである。

こうして、Bekko a25mによる関連記事推薦が採用される運びとなった。

prelims-cli でBekko a25mを使うには

v0.0.11からBekko a25mを multilingual optionを渡すと使えるようになっている。

詳細はのPRを見てほしいが、設定としては以下のように書くだけである。

 - permalink_base: "/post"
 type: embedding_recommender
 language: multilingual
 topk: 3
 cache_db: ".prelims_embedding_cache.db"

ぜひ、試してみてほしい。感想お待ちしています。

ブログの推薦用軽量embedding modelをBekkoに変えようとして、変えれなかった

Tue, 04 Aug 2026 20:03:00 -0700

このサイトでは、している。prelims-cliはfrontmatterに色々と情報を付加できるをCLIで動くようにしたものである。

実装した当初、embedding modelを使った類似記事推薦をやってみたいと思ったが、当時使ったembedding modelではTF-IDFベースの手法に比べてイマイチな結果しか出なかったため諦めていた。

時は流れ、に「今どきはCPUでもサクサク動く軽量embedding modelがありますよ」と教えられてGitHub Actionsで動くのであった。

ruri-v3とgraniteが軽量だが性能が良いと言うので試してみたら、TF-IDFと比較してもレコメンド結果をざっと目視で見ても悪くない結果だったので採用した。なにより、sudachiの辞書をGHAからダウンロードするよりもembedding modelをダウンロードする方が速いのである。

つい先週、seconさんがという小型モデルをリリースしたという記事を読んだ。これは、ワンチャン日英大統一できないかなー、日英以外もサポートできないかなーと思って、Claude任せに実験をしてみた。三連休の最終日なのに。

それで、出来た実験結果はこちら。

レポートを別タブで開く

簡単に言うと、失敗である。

理由はいくつかあるが

自分のサイトのブログ記事の関連に正解データがない
代理指標として記事のタグ・カテゴリが同じものを推薦出来るかを見たが、タグ・カテゴリが付与されている数も少なかった
そんな指標で測ったので、日英両方とも既存モデルに対して大幅な改善は得られなかった（指標の分解能が±5〜7ptで、比べていた差が2pt前後とおよそ誤差レベル）
むしろ、レコメンドに使う文字列長を伸ばしたほうが、英語は改善した（データをみたら英語のほうが文字数が多い記事が多かった）

記事の文字数頻度分布

定性的にいくつか見比べても悪くはない感じではあったのだが、好みとしても既存モデルの傾向の方が良かったのもある。

「homebrewを移動してiRubyが壊れたときに見直すポイント」 (tags: ruby)
- ruri → 「Pythonの環境構築を自分なりに整理してみる」 (環境構築のトラブル)
- a25m → 「kawasaki.rb #008 を開催しました」 (Ruby)
「新しいPyPIでMarkdownのドキュメントを使う」 (tags: python)
- ruri → 「prelimsを使ってHugoの記事にレコメンドを追加する」 (tags: python)
- a25m → 「mecab-python3を捨ててnatto-pyにしよう」 (tags: nlp)

1個目なんかは、環境構築系という意味では似ているなと感じる。2個目もHugoもMarkdownだしね、というので良いかなと感じた。