https://x.com/SuguruKun_ai/status/1860474550737338585
この手法が必要となる理由（LLMは数えられない）も、有用である理由（出来ないタスクは外部に委譲）も分かるんだけど、ChatGPTが定額サブスクであることを利用した富豪的手法ではあるよね。
API利用なら、文章生成タスク全体をPythonとかのプログラムとして、作成部分はAPI実行、文字数カウントとリトライ制御は、（function callingではなく）そのまま関数実行するのが良いと思う。LLMに文字数カウント関数を毎回生成させたり、関数実行結果からリトライ必要性を判断させるのは無駄が多い。
これでも数打ちゃ当たる方式ではあるので、もっとちゃんとLLMを制御したいところ。例えば…
・文章生成中、時々、現在の文字数情報（残り文字数）をプロンプトとしてインジェクションする。
・文章生成中にリアルタイムに文字数カウントし、制限を超えたら自動的に生成を打ち切ってリトライ。このとき、最初からリトライするのはもったいないので、途中から再開する。
・まず、「生成すべき文章を5つの段落に分けて書きたい。各段落のタイトルを出力せよ」のようなプロンプトを実行。次に各段落の本文を順番に生成させるようにする（このとき文字数制限は、文章全体の文字数/段落数などの値を事前に計算して指定する）。各段落本文生成時には、前述の方式で文字数制御を行う。
ただ、これらの手法はプロンプトキャッシュ（kv cache）ありきではある。キャッシュが働かなければ、逆に、より高コストになってしまう可能性もある。
最近は各社、プロンプトキャッシュ機能をAPIにも提供するようになったけど、キャッシュが効けば無料というわけでもない。なので、ちゃんと推論コストをキャッシュ割引込みで見積もりつつ設計する必要がある。まあ文章生成タスクの制御を細かくすればするほど、必要コスト範囲が狭まり見積りやすくなるので、その観点からも数打ちゃ当たる方式より優れていると思う。
最終的には、推論と、キャッシュを完全に制御できる、ローカルしか勝たんけどね。
