AI導入の失敗、原因は「設定ミス」だった話

先日、あるAI推論エンジンの技術検証レポートを読んでいて、妙に引っかかる話があった。

vLLMというAI推論エンジンのバージョンアップ（V0からV1）をした際、トレーニング中の報酬や精度が想定とズレてしまったという話だ。原因を追ったら、デフォルト設定の違いと、ログ確率の計算方式の差異だったという。具体的には「processed_logprobs」という設定をオンにしていなかっただけで、AIの学習曲線が大きくブレていた。

これを読んで、自分は「あ、これ他人事じゃないな」と思った。

「設定のまま使う」がどれだけ怖いか

うちの部でも昨年、生成AIツールをいくつか試験導入した。ベンダーの言う通りに設定してデモを見て、「よし、これで行こう」と判断した案件がある。でも実際に部下が日常業務で使い始めたら、出力の精度が安定しない。同じ条件で試しても結果がばらつく。ベンダーに問い合わせたら「デフォルト設定のままだとキャッシュの挙動が違う」と言われた。そういうことが普通に起きる。

今回の技術レポートで言うと、vLLM V1のデフォルトでは「プレフィックスキャッシュ」と「非同期スケジューリング」がV0と異なる動作をしていた。開発チームがそれを把握せずに走らせたから、学習結果が狂った。エンジン自体は正常。設定の組み合わせが違っただけ。

稟議を通して導入した後に「なんか思ってたより精度が低い」となるのは、だいたいこういう話だと思う。ツールが悪いのではなく、設定と運用の話。でもその区別をちゃんとできる人間が社内にいないまま進んでいるケースが多い。

ベンダー提案を「評価する」ために必要な視点

私が最近ベンダー提案を聞くときに意識するようになったのは、「デモ環境と本番環境の差異をどう管理するか」を必ず聞くことだ。デモはいつも綺麗に動く。本番に入れた瞬間に挙動が変わる。その理由を説明できるベンダーかどうかが、選定の一つの軸になってきた。

技術的な詳細を全部理解する必要はない。でも「バージョンアップしたら何が変わるか」「デフォルト設定で何が起きるか」を聞いたときに、具体的な答えが返ってくるかどうか。それだけで大体わかる。

今回のレポートでは、4つの問題を一つずつ切り分けて修正し、最終的にV0と同等の結果を出せたと報告されている。こういう「地味だけど丁寧な検証」ができる組織が作るツールは信頼できる。逆に言えば、そういうプロセスを経たかどうかをベンダーが説明できないなら、それはリスクとして経営陣への報告に入れるべきだと思う。

稟議書に「実証済み」と書くとき、それが本番環境に近い条件で検証されたものかどうかを確認する習慣を、部内に作っていきたい。自分自身も、来月のベンダー評価の場でこの視点を使ってみるつもりだ。