低コストのLLMを使える業務はどれか。モデルの振り分けと検証の基準

モデルを選ぶ前に業務を分類する

ルーティングは要求を分類し、モデルや処理経路を選ぶ方法です。単純な問い合わせが多いと費用を抑えられます。重要な例外を低コストの経路に誤配分したり、モデルを二回呼んだりする場合があるため、方針全体を試します。Anthropicのエージェント設計資料は、区別しやすい種類を正確に分類できる場合にルーティングを紹介しています。

固定したカテゴリへの分類、規程や契約書からの抽出、補償の判断では、誤りの影響が異なります。通常の問い合わせは別の担当へ移せるかもしれません。文書の抽出では根拠箇所、識別番号、単位が重要です。補償には支払いの権限、責任者の承認、外部結果の確認も必要です。

業務ごとに、誤りの影響、許されるデータと根拠、遅延、人が確認できる量、失敗時の対応を記録します。分類が容易でも、データを特定のアカウント外へ出せない場合があります。一方、複雑な形式でも隔離環境で結果を確かめ、人に下書きだけ渡す業務なら候補を試せます。クラウドのワークロード分類にある必須条件、希望、未確認の区分もデータ処理に適用できます。

ルーターが使う情報は方針に合わせます。サーバーが確認した役割、チャネル、注文ID、文書の分類があれば直接利用できます。複数の意図、不明な出所、未判定のリスクがある場合は追加確認や引継ぎを選びます。データとツールの許可範囲を先に定め、実行側で権限を確認します。

同じ評価データで候補と配分方針を試す

Aを低単価の候補、Bを高単価の候補とします。同じ入力条件、根拠、ツール契約を両者に与えます。専用のプロンプトが必要なら変更点を記録し、業務の正解と運用条件をそろえます。モデル単体と、実際のルーティング構成の最終状態を確認します。

固定カテゴリは正解との比較をコード化できます。複数の条件は項目別に判定し、例外相談では応答と実際の引継ぎを個別に確認します。Google Cloudの評価指標資料^[1]には参照回答や業務固有の評価の例があります。Anthropicのエージェント評価^[2]はモデルの申告と環境で観測した結果を区別します。

異なる文書形式、欠落、文章の後半に書かれた緊急の例外、別組織の資料への要求も入れます。実際の割合を代表する標本と、安全性の境界を集中的に確認する標本を分けます。繰り返し実行する場合は異なる入力の件数と試行数をそれぞれ残します。

確信度は実際の業務で校正する

分類器が確信度0.9と返しても、同程度の要求100件中で約90件正答するかを試します。回答に書かれた数値とモデル内部のトークン確率も異なります。Tianらの2023年の研究は、選定したモデルと短い質問応答ベンチマークで確信度の得方を比較しました。自社業務の精度は別途試験します。Tianらの確信度校正の研究^[3]

配分に使うならモデルの版と業務別に、確信度の範囲ごとの実測を確認します。0.9以上の件数、正答、重大な誤配分、要確認の件数を記録します。標本が少ない範囲では別の根拠も使い、モデルやプロンプトが変われば再検証します。権限、根拠、金額上限は確信度にかかわらず実行側で確認します。

誤配分を別の分母で集計する

振り分けの失敗がモデル評価の裏に隠れることがあります。緊急の補償案件100件のうち10件が一般の低コスト経路に入れば、その種類の誤配分は10%です。全1,000件の1%だけでは、危険な案件に偏った問題を読み取れません。高コストの経路に送った通常の問い合わせも別に数え、不要な呼び出しと遅延を確認します。

混同行列や関連記録に、専門家が承認した分類、実際の配分、検出後の再配分を残します。後段の検査で止められたか、利用者が回答を見る前だったか、人が直して完了したかを確認します。モデルが提案した分類とシステムが適用した結果を記録します。

月間の呼び出し費用が下がったときに確認する

架空の1,000件で比較します。定型700件、抽出200件、例外100件です。Aは一回40ウォン、Bは120ウォン、振り分けは業務ごとに5ウォン、人の確認は一件300ウォンとします。この処理集合で生じた費用を集計し、観測期間中に方針と業務状態を満たした件数を成功の分母にします。共通基盤と定期保守は同額として計算から外しました。

最初のAに例外が10件混ざり、代わりに通常の10件がBに入ったとします。Bに追加で送る120件には、後段で見つけた例外10件を含みます。適切な段階で止め、外部実行がなかったかを確かめます。承認を迂回して自動処理した案件があれば、費用が下がってもこの方針は保留します。確認した960件も業務種別の品質条件と照らします。

対象費用は46,600ウォン低下し、成功は10件減ります。Bへの追加が120件から520件に増えて他が同じなら、48,000ウォン増えて151,400ウォンになります。成功数が同じなら成功一件当たりも高くなります。昇格と人による確認の率を変えて試算します。FinOps FoundationのUnit Economics^[4]は費用を成果の単位に結びつけ、定義、仮定、対象費用を残すことを推奨しています。配賦についてはクラウド費用を業務単位で計算する方法も参照できます。

業務IDに呼び出し回数、入出力サイズ、検索・保管費、遅延、人への引継ぎを関連づけます。追加呼び出しの期限と回数を決めます。二モデルと人が関与した業務は費用をすべて加え、成功数には一件だけを数えます。処理方式の変更は費用と成功条件の双方に反映します。

本番の変化や障害時に配分方針を見直す

Aの障害で全件をBに送ると、利用上限や人の処理能力を超える場合があります。同じ提供元を使うなら共通の障害も想定します。自動で昇格する範囲、待機期限、人が引き取る経路、安全に止める処理を決めます。別モデルでもデータの分類やリージョン、承認とツール制限を確かめ、モデル変更だけで過去の外部実行を再開しません。

リリース記録にモデルとプロンプトの版、ルールとしきい値、評価データの版を残します。まず実際の副作用がない状態で配分だけ記録し、低リスク業務に絞って本番で試します。業務別に遅延、正しさ、昇格、引継ぎと費用を確認し、例外の増加や入力形式の変化を観測します。Google Cloudの運用ガイド^[5]が扱う入力変化の観測と継続評価も適用できます。

利用を許可した範囲を残します。危険な分類、データ利用条件違反、未知の種類の急増があれば、費用条件とは別に停止できます。設定を戻す場合は、すでに別モデルへ渡った作業と外部結果を確認します。次の変更では総合値とともに、業務別の境界、誤配分、救済した例外、成功一件当たりの費用を報告します。