AIの「思考量を減らす」最適化が精度も速度も悪化

生成AIを使ったアプリで、応答が遅いのは実用上の弱点です。 そこで思考量を減らして速くしようとしたところ、精度も速度も両方悪化しました。 差し戻すまでに分かったことを書きます。

試したこと

画像から図を読み取る工程で、モデルの思考量（thinking budget）を high から low に下げました。

このときの見立ては次のとおりです。

書き写しは推論ではないから、思考量は要らないはずだ。 まず low で読み取ってみて、規則探索が答えを出せなかったときだけ high で読み直せばいい。

理屈は通っているように見えました。安い処理を先に置き、駄目なときだけ高い処理に上げる。 よくある二段構えの最適化です。

結果

実機で測ったところ、こうなりました。

• 正答率が下がった
• 所要時間も伸びた

速くするための変更で遅くなったので、差し戻しました。

なぜ遅くなったのか

1段目がほぼ毎回目標に届かなかったからです。

low で読み取った結果では、規則探索が答えを出せません。 結局ほぼ全件で high の読み直しが走るため、low の実行時間がまるごと無駄になりました。

1段目（low）で大半が片付くか

片付く想定どおり。安い処理で済んだぶんが得になる

片付かないlow の実行時間がまるごと無駄になり、毎回二度手間になる

二段構えが効くのは、1段目で十分片付く場合だけです。 1段目の通過率を測らずに導入すると、単なる二度手間になります。

なぜ精度まで下がったのか

こちらは予想していませんでした。

読み違えた結果が、たまたま選択肢のどれかに一致してしまう経路を踏んだためです。

この種の問題では、選択肢は「間違えたときに辿り着く答え」として作られています。 出題者が誤答の選択肢を用意するとき、ありがちな取り違えの結果を並べるからです。

つまり、読み違えの結果が選択肢に一致する確率は、ランダムよりずっと高い。 「どの選択肢とも一致しない」という検出器は持っていましたが、万能ではありませんでした。

誤答が確定してしまうと、読み直しのきっかけすら失われます。

ここから言えること

モデルに与える予算を削る方向は行き止まり

思考量や画像解像度は、読み取りの正確さに直結しています。 削ると精度が落ち、やり直しが増えて結局遅くなります。

「書き写しなら簡単だから軽くていい」という直感は、少なくともこのケースでは間違いでした。

速くしたいなら、仕事量そのものを減らす

予算を削るのではなく、やらせる仕事を減らす方向が有効でした。

• 読ませる範囲を狭める
• 書かせる量を減らす
• 同じものを二度読ませない

同じ精度で処理量が減るので、こちらは素直に速くなります。

検出器を過信しない

「おかしな結果は検出できるから、多少雑でも大丈夫」という設計は危険です。 検出をすり抜けた誤りは、検出されないぶん確信を持って返されるようになります。

呼び出し回数にも上限を決めた

このアプリは利用者が自分のAPIキーを持ち込む形なので、 呼び出し回数がそのまま利用者の負担になります。そこで工程ごとに上限を決めました。

工程	最大呼び出し回数
命令表	3回（読み直しを含む。別経路へは落ちない）
法則性・暗号	4回（読み取り1回＋別経路3回）

読み直しを入れているのは命令表だけです。 他は読み直しても改善する見込みが薄く、効果の分からない再試行で他人の無料枠を使わせない という判断です。

自分の財布で動かしていると気付きにくいところですが、 持ち込み型では呼び出し回数の設計が機能の一部になります。

まとめ

• 二段構えの最適化は、1段目の通過率を測ってから入れる。 通過しないと二度手間になる
• 思考量や解像度を削る方向は精度に直結する。 速くしたいなら仕事量を減らす
• 誤答が選択肢に一致する確率は低くない。 「一致しない＝失敗」の検出器は万能ではない
• 測らずに出すと、テストが通ったまま精度だけ落ちた版が出荷される

関連: AIに「解かせる」のをやめて「写させる」だけにしたら、正答率が17%から94%になった