Intel Dokimi 0.2.0：CLI再編、評価ゲート強化

1. コマンド名が機能別グループに移動した

従来のコマンドを実行すると、新しいコマンド名を知らせるメッセージが表示され、終了コード2で終了する。例えば、スコアを計算していたeval scoreはeval score pointwiseに変わった。

評価とスコア計算はeval配下にまとめ、資料の一覧表示・点検はcatalogに再配置した。追跡とデータ入出力も別のグループに移した。自動化スクリプトでは従来の名前を新しい名前に置き換え、終了コードに応じた後続処理も併せて点検する必要がある。

2. 測定漏れと不正なスコアは評価失敗になる

タスク実行・評価点検・リポジトリ実行は、予定された評価項目にエラー、未採点、欠落があると終了コード1を返す。文書点検と、回答を採点するモデルである審判の文言・一致度検査は、失敗判定を厳格に適用する厳格モードでこの基準を適用する。評価を実行した事実より、実際に採点された結果があるかを問う変更だ。

数値として定義されない値であるNaNや無限大のスコアも通過判定を受けられない。文書点検は厳格モードでNaNの区間を失敗扱いする。比較基準となる既存の評価結果であるベースラインとの比較も、厳格モードではモデルまたはプロバイダーが欠落するか不明と表示されると失敗する。

空の入力を成功と見なしていた点検も変わった。資料の探索を始める最上位フォルダーであるカタログルートにSKILL.mdがない場合や、レポート生成対象に評価結果がない場合は終了コード1を返す。ベンチマークの事前点検で、ファイル指定の入力が存在しない、読み取れない、空の場合は終了コード2となる。

3. 終了コードと比較結果の解釈も変わった

終了コードの基本体系は、成功が0、検査・通過基準・実行の失敗が1、不正な入力や使用法が2だ。リポジトリ実行と評価点検は一部の不正な入力にも1を返すため、自動化では実行したコマンドも併せて確認する必要がある。

ツール選好度コマンドは、予算を理由に停止すると3を返し、部分的な結果を残す。他のコマンドは予算による停止時に1を返す。バックエンド・実行履歴・追跡コマンドがJSON出力モードで異常終了すると5を返す。

質問ごとのスコア差に対する符号反転検定が、確率値の計算とリポジトリ比較の区間推定に使われる。質問ごとに差の方向を反転させて観測された差を評価する方式で、区間推定はスコア差を単一の値ではなく範囲で示す。レポートはこの検定の確率値と、スコアが変わったペアの数を示す。

リポジトリ比較には差の計算方法も表示され、タスクが5個以下の場合は区間の値が空になる。両方の評価群で採点された質問がなければ、ベースラインとの差も空になる。比較結果を読む際には、差の大きさとともに、ペアで採点された結果があるかも確認できる。

4. 新しい検証機能と再実行費用を併せて検討する必要がある

リポジトリの予算を確認するコマンドと、評価がどれだけ広く行われたかを点検する機能が追加された。ベースラインからの低下幅と、ペア比較に必要な最小結果数に通過基準を設ける機能は、任意で有効にできる。複数のモデルやリポジトリの変更を点検する開発者は、評価範囲を広げながら許容する変化の基準も設定できる。

検証手段は増えたが、以前の応答を再利用していた処理には再呼び出しの費用が生じる場合がある。BedrockとVertexでは、審判・ロール設定・質問生成器・検証器の既存キャッシュ応答、つまり以前の呼び出しで保存した応答を再利用しない。OpenRouterも同じ対象で、応答保存キーに、応答をリアルタイムで分割送信するストリーミングの有無が含まれるため、該当する呼び出しの費用を再度支払うことになる。

出力量の設定も変わった。OpenRouterの出力トークン上限2000が解除され、新規性評価の呼び出しは--max-tokensを指定しない場合、出力トークン16384個を要求する。リリースノートによると、Bedrockでlitellmが送っていた要求は4096個だった。

5. 移行時はベースラインとキーから確認する

スコアと判定は0.1.0の結果と直接比較できないため、ベースラインを再実行する必要がある。

以下のコマンドをOPENROUTER_API_KEYが設定された状態で実行した場合、検証器がOpenRouterのキーをGoogleのキーとして送信していたため、該当するキーを交換する必要がある。

eval questions generate --validate --provider google-vertex

Dokimi 0.2.0は評価の空通過を防ぎ検証手段を広げるが、コマンド移行とベースラインの再実行、一部の呼び出しの追加費用を伴う。