0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@axzxs2001(suwei gui)

Agent は本当に本番投入できるかは、評価が業務フローを本当に制御できるかで決まる

0
Posted at

多くの Agent Demo は、ユーザーの質問を理解し、業務データを照会し、ツールを呼び出して、最後に応答を生成するという一連の流れを完走できます。
しかし、「完走できる」ことと「本番投入できる」ことの間には、なお大きな隔たりがあります。
AI カスタマーサポート Agent を例にすると、ユーザーはこう言います。
「買った製品に問題があります。すでに一度カスタマーサポートに連絡しましたが、ずっと対応されていません。返金したいです。」

Agent は、トリアージ、注文照会、過去のチケット照会、返金ポリシーの判断、処理アクションの決定、承認申請、返金実行、そして顧客向け返信の生成までを完了する必要があります。

技術的には、これは典型的な多段階 Agent Workflow です：

しかし、システムが本当に本番投入できるかを決めるのは、これらのステップそのものではなく、評価（Evaluation）が本当にプロセス制御層に入っているかです。

多くのシステムにも「評価」はありますが、その評価は事後採点にすぎません。
レポートを生成して「良いか悪いか」を知らせるだけで、誤りの発生を止めることも、実行経路を変えることもできません。

この種の評価は、本質的にはテストログにすぎず、本番の仕組みではありません。

一、Agent はただ「フローを回す」だけではだめで、「評価によりフローを制御される」必要がある

従来のプログラムでは、業務ルールは決定論的です：

同じ入力 → 必ず同じ出力

しかし Agent は違います。同じ「返金したい」という発話でも、モデルは次のようなことを起こしえます。

  • 返金要求と認識することもあれば、苦情として扱うこともある
  • 正しく返金ツールを呼び出すこともあれば、承認条件を見落とすこともある
  • 返金がまだ完了していないのに、直接「返金済みです」とユーザーに伝えてしまうこともある

そのため、本番システムは次のようには書けません。

var response = await agent.RunAsync(userInput);
await SendToCustomerAsync(response.Text);

問題は「実行できるか」ではなく、モデルの出力を信頼できるものとみなし、そのまま業務システムに流し込んでしまっていることにあります。

カスタマーサポートの場面では、次の 3 種類のリスクが発生します。

  • 判断ミス：ポリシーに合わない注文を誤って返金可能と判断する
  • 実行ミス：金額の誤り、または重複返金
  • 表現ミス：返金が完了していないのに「入金済み」と顧客に約束してしまう

したがって Harness の役割は「モデルを呼び出すこと」ではなく、モデルを制御し、制約し、モデルが失敗したときにフローを引き継ぐことです。

二、評価は 1 点ではなく、2 つの「業務ゲート」である

完全なカスタマーサポートの流れでは、評価は少なくとも 2 回の重要な遮断点として現れます。

1）Action Evaluation：この処理を実行してよいか？

これは実行アクションの後に発生します。

builder
    .AddEdge(policy, action)
    .AddEdge(action, actionEval)
    .AddEdge(actionEval, response)
    .AddEdge(response, replyEval)
    .WithOutputFrom(replyEval);

ここで重要なのは次の点です。

  • Action は「何をするか」を担当する（返金 / 交換 / エスカレーション）
  • Action Evaluation は「実行してよいか」を担当する

たとえば、Action Evaluation は「この処理を実行してよいか？」を判断します。

それが守るものは次の通りです。

  • 資金安全
  • 権限境界
  • コンプライアンス

2）Reply Evaluation：この文を送信してよいか？

これは返信生成の後に発生します。

.AddEdge(response, replyEval)
.WithOutputFrom(replyEval);

それがチェックするのは次の通りです。

  • 内部フィールドが漏れていないか
  • 機密情報が含まれていないか
  • 誤った約束をしていないか（例：「返金済みです」）

たとえば、Reply Evaluation は「この文を送信してよいか？」を判断します。

それが守るものは次の通りです。

  • 顧客体験
  • 情報セキュリティ
  • コンプライアンスに沿った表現

重要な違い

Action Evaluation：誤ったことをするのを防ぐ
Reply Evaluation：誤ったことを言うのを防ぐ

どちらか一方だけでは問題が起きます。

  • Reply Evaluation だけある → うまく言うが、誤ったことをする
  • Action Evaluation だけある → 正しく処理したが、顧客への伝え方を誤る

三、真の評価は「結果を記録する」のでなく、「実行を遮断する」必要がある

多くのシステムの問題は、evaluation = true/false であっても、フローはそのまま実行され続けることです。これは本番では受け入れられません。

評価は制御フローに直接関与しなければなりません。

if (!compliance.Allowed)
{
    finalAction = new ActionProposal(
        ActionKind.Escalate,
        RefundAmount: 0,
        RequiresApproval: true,
        Reason: compliance.Reason);
}
else if (proposal.Kind == ActionKind.Refund)
{
    var decision = await approvals.RequestAsync(proposal);
    if (decision?.Approved == true)
    {
        await refunds.RefundAsync(...);
    }
    else
    {
        finalAction = new ActionProposal(
            ActionKind.Escalate,
            Reason: "承認されませんでした");
    }
}

ここで示されているのは、評価の本質です。
評価はリスクを記述するものではなく、リスクを制御するものです。

四、評価は LLM だけに頼ってはいけない。「ルール + モデル」の二層構造にする

Action Evaluation では、重要な設計が 1 つあります。

1）決定論的ルール（必ずコードで実装する）

たとえば：

var overLimit = action.RefundAmount > policy.AutomaticLimit;

適用対象：

  • 金額
  • 権限
  • 状態
  • 承認条件

特徴：

  • テスト可能
  • 監査可能
  • 安定している

2）LLM の意味判断（補助層）

用途：

  • 妥当かどうか
  • 文脈が抜けていないか
  • 顧客の意図に合っているか

推奨構造

ルール層（Code） -> 意味層（LLM）

逆にして、ルールの判断まで全部 LLM に任せると、システムは必ず不安定になります。

五、Reply Evaluation：モデルを「自由に発揮」させてはいけない

モデルが返信を生成したあと、それをそのまま送信してはいけません。

state.CustomerReply = resp.Text;

なぜなら、次のような内容が出る可能性があるからです。

「返金は成功しました（内部 risk_level=low、execute_refund は完了済み）」

問題は次の通りです。

  • 内部フィールドの漏えい
  • ツール名の露出
  • 未完了の操作を先に約束してしまうこと

ローカル評価は LLM より信頼性が高い

たとえば：

var phoneRegex = new Regex(@"\b1[3-9]\d{9}\b");
var emailRegex = new Regex(@"\b[\w.-]+@[\w.-]+\.\w+\b");

適用対象：

  • PII
  • カード番号
  • メールアドレス
  • 内部フィールド

内部情報漏えいチェック

var internalTerms = new[]
{
    "execute_refund",
    "policy_compliant",
    "risk_level",
    "{", "}"
};

本質は、顧客にシステム内部の構造を見せるべきではない、ということです。

六、評価失敗時には必ず「安全な降格」を発動する

評価失敗はログだけではいけません。

if (!passed)
{
    reply = SafeFallback(...);
}

安全な降格は次を保証しなければなりません。

  • 情報を漏えいしない
  • 未完了の操作を約束しない
  • モデルによる救済に依存しない

たとえば：

if (receipt is not null)
{
    return "返金は受理されました。元の方法で返金されます";
}

重要な原則：状態が本当に存在するときだけ、その状態を表現できる

七、構造化出力は、評価を実行可能にする前提条件である

出力が自然言語だと、「返金できそうですが、手動確認を推奨します」のようになります。

するとシステムは次を判断できません。

  • 返金するのか
  • 金額はいくらか
  • 承認が必要か

したがって、必ず構造化する必要があります。

public class ActionResult
{
    public string Action { get; set; }
    public decimal RefundAmount { get; set; }
    public bool RequiresHumanApproval { get; set; }
}

ただし注意が必要です。
JSON が正しいこと ≠ 業務が正しいこと

そのため、二重の検証が必要です。
Schema 検証（形式） + 業務検証（ルール）

八、評価は実行時だけでなく、監査にも入れる必要がある

評価結果は構造化して記録しなければなりません。

{
  "evaluation": {
    "passed": true,
    "checks": [
      { "name": "no_pii_leakage" },
      { "name": "no_internal_leakage" }
    ]
  }
}

同時に監査システムにも入れます。

await audit.WriteAsync("refund.approval_decided", ...);

違いは次の通りです。

  • Evaluation：今この瞬間に安全かどうか
  • Audit：後から見て、なぜそうしたのか

九、評価はテスト可能でなければ本番投入できない

本番システムは次をシミュレートできる必要があります。

1）モデル出力の誤り

Assert.DoesNotContain("13800138000", result.CustomerReply);

2）承認拒否

Assert.Equal(0, refund.Calls);

3）冪等性

Assert.Equal(1, refund.Calls);

核心は、モデルが賢いかどうかではありません。
モデルが誤ったときでも、システムが安全であり続けるかどうかです。

十、評価が Harness 全体のどこに位置するか

完全なフローは次のようになります：

最後に

Agent の能力上限はモデルで決まりますが、本番投入できるかどうかは評価システムで決まります。

企業が本当に気にするのは、「質問に答えられるか」ではありません。
それよりも、次の点です。

  • 勝手に返金しないか
  • 情報を漏えいしないか
  • 不確実なときに止まれるか
  • エラーが起きる前に止められるか

したがって、明確な信頼チェーンを構築しなければなりません。

  • モデル出力 ≠ 実行可能な結果
  • 構造化出力 ≠ 業務的に正しい
  • 評価結果 = フローコントローラ
  • 高リスク動作 = 承認必須
  • 評価失敗 = 降格必須
  • すべての重要な判断 = 監査可能であること

評価の本質

評価は「採点」ではなく、次の 3 つです。

理解は正しいか？
この処理は実行できるか？
この結果は引き渡せるか？

モデルが Agent に何ができるかを決めます。
評価が、企業が本当にそれをやらせてよいかを決めます。

(Translated by GPT)

元のリンク：https://mp.weixin.qq.com/s/QkYQ58k5Cr0jT_npzACZmg?token=1307544074&lang=zh_CN&wt.mc_id=MVP_325642

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?