モデルが嘘をつく前に、評価用ハーネスがあなたに嘘をつく

評価スコアボードでは、両方のエンジンが失敗したことになっていた。

Llama3.2は6ケース中5ケースで失敗。 Anthropic Sonnetは6ケース中6ケースすべてで失敗。

ラベルは「malformed」となっていた。しかし、その原因は異なっていた。

1つの失敗は、クレジット切れによるAPIエラー。 1つの失敗は、CLIコマンドによるターミナル制御バイトがテキストを破損させたもの。 1つの失敗は、パーサーが読み取れないmarkdownのフェンスでラップされた有効なJSON。

もし最初の要約をそのまま公開していたら、私は嘘をついていたことになる。自分のコードの不備を、モデルのせいにしてしまっていたのだ。

要約を鵜呑みにせず、生のレコードを確認することで、これらのバグを見つけることができた。

最初のバグは、Ollamaを呼び出すためにCLIのサブプロセスを使用したことが原因だった。コマンドがスピナーやカーソル移動などのターミナルアニメーションを生成し、それらのANSI制御バイトがデータに混入してしまった。パーサーは不可視文字を検知してクラッシュした。

修正策：CLIサブプロセスから直接的なHTTP APIへの切り替え。

2番目のバグは、LLMがJSONをmarkdownのフェンスで囲むことが多いため、発生した。私のパーサーは生の文字列に対して json.loads() を使用していた。そのため、バックティックを検知して失敗した。

修正策：パースする前にコードフェンスを取り除く関数を追加する。

パイプラインを修正すると、真の結果が現れた。

モデルが「ダメ」だったわけではない。単にハーネスによってデータが乱されていただけなのだ。修正後、2つのモデル間の品質の差が明確になり、測定可能になった。

AI評価パイプラインへの教訓：

  • 生の出力を保持すること。要約が「malformed」と言っているなら、生の出力こそが唯一の真実（source of truth）である。
  • 失敗の理由を記録すること。単に「malformed」とするのではなく、「API error」や「parse error」と明記すること。
  • テスト基準を固定すること。結果を良く見せるためにルールを変更してはならない。
  • ハーネスをテスト対象のシステムの一部として扱うこと。

審判にかけられているのはモデルだけではない。あなたのコードも同様だ。

出典: https://dev.to/kenielzep97/your-harness-will-lie-to-you-before-your-model-does-662

オプションの学習コミュニティ: https://t.me/GyaanSetuAi