LLM APIで文章を生成するとき、モデル名やプロンプトは調整しても、max_tokens、reasoning_effort、Temperatureはデフォルトのままにしがちです。
同じ再構成ブリーフを設定ごとに再実行してみると、デフォルトだけでは見えないシグナルがありました。これは各比較1回だけの観察であり、設定の優劣を決める実験ではありません。
まず押さえる制約
設定ごとに試したモデルは異なります。3設定×3モデルの対称な比較ではありません。
そのため、以下は「設定を変えればこうなる」という一般則ではなく、API運用で確認する観点です。
max_tokens: 文章が完結して見えても finish_reason を見る
GLM-5.2の元草稿は、8,000トークンの上限に達していました。読み終えた印象は自然でも、APIの終了理由は length でした。
上限を60,000にした再実行は自然終了し、分量は57%増えました。元草稿で見られた、根拠より強い表現も再実行では出ませんでした。
ここで重要なのは、上限を上げれば改善する、という結論ではありません。終了理由を確認しないと、制約を受けた出力を正常終了と見誤る可能性がある、という点です。
reasoning_effort: 最終出力の長さだけで判断しない
DeepSeek Flash / Pro を reasoning_effort=high で再実行すると、最終出力は短くなりました。それでも見出し構成は保たれ、検証対象の表現は出ませんでした。
ai&の実装では、推論設定を有効にすると最終回答とは別の reasoning フィールドが返ります。最終文だけを見ていると、どこに処理量が現れたのかを見落とすことがあります。
ただし1回の再実行では、設定の効果と偶然を分けられません。
Temperature: 許容値を安全値と扱わない
Temperatureを約2にしたところ、返ったDeepSeek出力2件は記事として使えない状態になりました。Flashは途中から混在スクリプトのノイズになり、Proは最初から意味を成しませんでした。GLMはタイムアウトで結論なしです。
UIが値を許容しても、対象タスクで実用的とは限りません。端の値は本番生成ではなく、捨て生成で先に試す方が安全です。
運用チェックリスト
- 応答本文だけでなく
finish_reasonを保存する - reasoning系パラメータがあれば、未指定との差を一度確認する
- Temperatureの高い値は、少数の捨て生成で品質を確認する
今回の観察はN=1で、GLMのブリーフも再構成です。デフォルトを否定する話ではなく、デフォルトが自分の文章タスクに合っているかを確認するための、低コストな点検手順として扱うのがよさそうです。