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

書き写しに推論は要らないだろうと考えて思考量を下げたところ、正答率が落ちたうえに所要時間まで伸びました。差し戻すまでに分かったことと、代わりに効いた速度改善を書きます。

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

試したこと

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

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

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

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

結果

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

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

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

なぜ遅くなったのか

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

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

想定: low（速い）で大半が片付き、たまに high
実際: low（無駄）→ high（本来の処理）を毎回やる

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

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

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

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

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

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

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

ここから言えること

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

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

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

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

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

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

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

検出器を過信しない

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

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

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

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

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

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

まとめ

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