AIの出力品質を、
「なんとなく」で語らない

自作の朝刊エージェントが毎朝6:30にニュースメールを届けてくれるようになって、2ヶ月半が経った。動き続けるシステムには、動き続けるシステム特有の悩みが出てくる。

「今朝の紙面、ちょっと微妙だったな」——これだ。

昨日載った記事がまた載っている。金融の記事がAIカテゴリに入っている。見出しが元記事の内容と微妙に違う。どれも毎回ではない。でも、たまにある。

問題は、その「たまに」を体感でしか把握していなかったことだ。プロンプトを直して「直った気がする」と思っても、それは今日の紙面がたまたま良かっただけかもしれない。逆に悪化していても、数日は気づけない。LLMの出力は毎回違うので、1回の観察では何も言えないのだ。

コードの品質ならテストを書く。ではLLMの出力品質には何を書くか。答えは評価ハーネス——出力を継続的に採点する仕組みだった。機械学習の世界で「evals」と呼ばれているものを、個人開発のスケールに落として組み込んでみた。

評価ハーネスを作ろうとして最初に気づいたのは、評価したくても材料が残っていないことだった。配信されたメールは残っている。でも「そのときLLMに何を入力したか」が残っていなければ、出力の良し悪しは判定できない。見出しが元記事に忠実かどうかは、元記事がないと確かめようがない。

そこでまず、配信のたびに以下を丸ごとS3にアーカイブするようにした。

ポイントは、これが入力と出力のペアだということ。これがあれば「同じ入力でプロンプトだけ変えたらどうなるか」というA/B再実行もできるし、良い配信・悪い配信の実例を集めてゴールデンセット（正解データ集）の原料にもなる。

コストはほぼゼロだ。1配信分のJSONはたかが知れていて、S3の保存料は誤差の範囲。後から「あのとき記録しておけば」と思っても、過去のデータは二度と手に入らない。記録だけは、評価の設計が固まる前から始めておく価値がある。

最初の指標は重複率。「同じ記事が同じ紙面や直近の配信に2回載っていないか」だ。一番目につく品質問題で、新聞としては一番恥ずかしいやつでもある。

これはLLMに聞くまでもなく、コードで判定できる。

bigram類似はたいそうな機械学習ではない。文字列処理だけの素朴な手法だ。でも日本語ニュースタイトルの「同じ話題の言い換え」を拾うには十分で、なにより実行コストがゼロ円。毎配信どころか、過去全配信に対して何度でも走らせられる。

残る2つの指標は、文字列処理では測れない。

こういう「意味の判断」には、LLMに審判をさせるLLM-as-Judgeという手法を使う。生成とは別のLLM呼び出しで「この分類は適切か」「この見出しは原文に忠実か」を判定させ、判定理由つきの構造化JSONで返させる。

ここで気をつけたのが評価自体のコストだ。品質を測るために本体より高い金を払っていたら本末転倒だから、judgeにも生成と同じコスト設計を適用した。

結果、judgeのコストは実測で1配信分あたり約$0.003。配信本体が$0.02前後なので、評価は本体の15%程度。これなら気兼ねなく回せる。

評価ハーネスを作って早々に、実用の場面が来た。

このシステムは記事の収集経路が2つある。RSS・Webページの並列フェッチ（無料）と、鮮度を補強するためのweb_search（1検索$0.01、現在は一部トピックのみ・回数上限つき）。当然「検索をもっと増やせば紙面は良くなるのでは？」という誘惑がある。でも検索は従量課金だ。勘で増やしたくない。

そこで紙面の各記事にorigin（収集経路）タグを付け、評価ハーネスに「web_search由来の記事がどれだけ紙面に貢献しているか」を集計するレポートを足した。

まだ数日分のデータだが、すでに「検索由来は1件でも紙面の上位に食い込む傾向がある」ことが見えはじめている。このまま蓄積すれば、「$0.01/検索を追加で払う価値があるか」を数字で判断できる。

体感レビューの時代には、この問いは「なんとなく検索があったほうが良い気がする」で止まっていた。評価の仕組みは品質チェックのためだけでなく、次の投資判断の材料を生むためにある——作ってみて一番実感したのはここだった。

企業のML基盤のような大掛かりなものは要らない。個人開発のスケールで効いた設計原則を4つにまとめる。

運用コストの削減で使った考え方（別記事）と、根っこは同じだ。LLMにしかできない仕事だけをLLMに渡し、残りは全部コードでやる。生成でも評価でも、この原則は変わらなかった。

評価ハーネスができて変わったのは、数字が出ることそのものより、改善の議論の土台ができたことだ。

「最近重複が多い気がする」は「直近7配信の重複率は0%、ただし6/10は際どい類似ペアが1組」になった。「見出しが盛ってる気がする」は、忠実性judgeの判定理由つきで具体的な1件を指せるようになった。プロンプトを変えるときは、変更前後で同じアーカイブに対して評価を走らせれば、良くなったか悪くなったかが分かる。

ソフトウェア開発でテストコードが果たしている役割を、LLMシステムでは評価ハーネスが果たす。そして面白いことに、テスト文化で言われてきた格言がほぼそのまま通用する。後から書くのは大変、先に仕込めば資産になる。全部を自動化しなくても、回帰だけは機械に見張らせる。

次にやりたいのは2つ。プロンプト変更時に過去アーカイブで差分評価する回帰テストの定型化と、judgeの判定が自分の感覚とズレていないかを確かめる「judgeの評価」だ。審判を雇ったら、審判の精度も見なければいけない。この再帰がevalsの沼であり、面白さでもある。