JevでRSSフィードのスコアリング

はじめに

Jevが話題になっている。入力したデータ（文章など）を評価し、あらかじめ与えた評価軸で構造的なスコアを返す仕組みだ。今回は手元にあるRSSアプリの記事スコアラーで使っているClaude Haiku 4.5をJevに置き換え、どのくらい安価になるかを検証する。

前提

Haikuでは、一度に30件の記事を問い合わせているが、Jevでは1件ずつ投げるしかないため、実運用では時間で56%削減、コストで71%削減に留まった。

今回は純粋な性能を測るため、あえてHaikuも1件ずつ投げるよう調整して計測した。LLMは長いコンテキストの中間を無視し、前半を尊重する傾向にあるため、この変更の方が性能は出る（1件ずつだとかなりトークンを消費するため仕方なく30件ずつにした経緯がある）。

準備

Typesafe(Jev)プラグインをClaudeに導入する。

cd PROJECT_ROOT
claude plugin marketplace add typesafe-ai/skills
claude plugin install typesafe@typesafe
mkdir ./.claude/skills/typesafe
cd ./.claude/skills/typesafe
curl -O https://raw.githubusercontent.com/typesafe-ai/skills/main/skills/typesafe-ai/SKILL.md

APIキーをTypefaseのAPIキータブから取得して.envなどに格納する。

実測

リクエストを150回送り、速度とコストを比較した。

	Jev 1.13.0	Claude Haiku 4.5
1リクエスト 平均	267ms	1,473ms
全リクエスト合計	40.1s	221.0s
送信バイト	908,085	920,385
受信バイト	458,897	102,375
実費	$0.0148(2.22円)	$0.3776(56.64円)

速度で5.51倍、コストで25.51倍改善したことがわかる

集計結果

Haikuで集計した結果との相関は0.84と比較的高く、全体的性能は（個人の主観なので計測できないが）Jevの方がやや良い、という結果になった。ただし、Jevは比較的新しい話題を取りこぼす癖があり、新語が入っているタイトルを過小評価する傾向が見られた。

特筆すべき点としては、Jevは一貫して数値で分析結果を返却するため、「評価ポイント（一次情報寄り、など）」「マイナスポイント（煽りタイトル、ガジェット寄り、など）」などを複数の観点で取得してロジック側で集計できる点が強いと思った。

例えば「ソースが一次情報寄りかどうか」という評価観点の影響が強すぎる、と感じた場合はロジック側で重みを軽くするだけでよい。LLMの場合はプロンプトに書かざるを得ないので調整が反映されたかどうかが分かりにくい。結果の微調整をいわゆる「プロンプトエンジニアリング」に頼らなくても良い点は評価できる。

メリット・デメリット

今のところ以下のメリット・デメリットがあると感じた。

Haikuを使うメリット

• レートリミットに達しない限り追加料金が発生しない(有料プランの場合)
• リクエストを束ねて投げられるため、試行回数を少なくできる
  • ただしリクエストを束ねた場合、順序バイアスなどが生じ正確性が減損する
• 知識カットオフが比較的最近である

Jevを使うメリット

• 今のところ月50$の月間無料枠が設定されているため、この範囲で収まる
• Haikuと比べて高速・安価に運用できる
• 純粋な分類性能は高め
• 出力形式の誤りがない（Haikuはしばしば誤ったフォーマットを返す）
• 評価が数値でかえるため、ロジック側で重みを調整できる

結論

RSSフィードの評価はJevの得意とする分野でもあり、Haikuに比べてやや優秀である、という結論に至った。今後はRSSフィードのランカーにはJevを使ってみようと思う。
知識カットオフが古そうな感じがするので、そこは課題となる。