LLM判定は、安いフィルタの後ろに置く

バッチ処理のボトルネック。一見、ダウンロード速度だと思ったら、実は要約取得とLLM判定に時間がかかっていた。この発見から始まるのが、APIコストを削減するための思考方法だ。外部サイトから集めた記事候補を取捨選別するシステムを例に、何が起こっているか見ていこう。最初の実装では、候補のタイトルと要約をLLMに渡して判定するという流れだった。ところが測ってみると、実は要約を取得する前に「そもそも公開されていないサイトの記事」もすべて処理していた。つまり後で捨てる記事についても、先に金と時間をかけてLLMに判定させていたわけだ。

この記事が示唆するのは「何を処理するか」を先に決める大切さである。LLMの判定を2段に分け、安い確認作業（サイトが公開か非公開か）を先に持ってくる。関連性の深い判定はその後で。対象外が確定した記事は、要約取得もLLM呼び出しもスキップできるから、高コストな処理の回数が激減する。この順番の入れ替えだけで、質を落とさずに処理時間と費用が大きく削減される。キャッシュの使い方も重要で、タイトル段と要約段で別々に記録することで、再実行時の無駄もなくなる。

中小企業でも、自動化ツール導入後に「なぜか運用コストが下がらない」という悩みは多い。データの粒度を見直す、不要な前処理をそぎ落とす、という地味な最適化が実は効いている。問題は道具そのものではなく、その道具へ何を投げるか、どの順で投げるか。その取捨選別の設計が命運を分ける。技術の導入ありきではなく、フローの最適化ありきで考えると見える景色は変わる。