智能销售助手评测方案

目录

准确度评测 使用离线测试集+规则

Coordinator的评测，RAGAgent评测
1 设计本地离线数据集
2 跑测试用例，把测试用例的数据作为参数传给 Coordinator的input
3 下载langfuse的trace
4 通过脚本对比 input和output的差异

其他评测场景 LLM as Judge

【注意】LLM as Judge是针对具体执行的Agent评测，不可用放在Trace root进行

我直接给你结论图景，然后落到智能销售助手的具体可用场景。

一、先给你一句总判断

Coordinator 这种“强结构决策节点”，不应该用 LLM as Judge；
LLM as Judge 是给“不可规则化语义质量”的。

你现在设计的 1–4 离线评测流程，是 Coordinator 的正解路径。

二、为什么 Coordinator 不适合 LLM as Judge

Coordinator 的输出是：

{
  "intents": [...],
  "route_to": "rag_agent | react_agent | workflow_agent"
}

这类评测特征是：

特征 说明
离散 intent / agent 都是枚举
可比对 == / in / set overlap
可解释 错就是错
可回放 同输入应同输出

👉 LLM as Judge 在这里反而是噪声

例如：

  • 你已经知道 expected_agent = react_agent
  • 结果是 rag_agent

这不需要 LLM 判断，这是确定性错误。

三、那 LLM as Judge 用在“智能销售助手”的哪里？

下面是真正应该用的地方（非常关键）。

场景一：销售话术质量评估（最核心）

典型问题

“这个回复是不是有销售推动力？”

人类判断标准（不可规则化）

  • 是否自然
  • 是否有说服力
  • 是否引导下一步
  • 是否太啰嗦 / 太冷

示例

User: 这个产品多少钱？
Assistant A: 199 美元。
Assistant B: 现在是 199 美元，本周下单我们还包邮，并且支持 30 天无理由退货。

👉 哪个更好？规则无法写，但人一眼就知道

LLM as Judge 适配点

{
  "criteria": [
    "sales_effectiveness",
    "politeness",
    "clarity",
    "next_step_guidance"
  ]
}

场景二：多轮对话“成交路径合理性”

评测的问题不是单句，而是：

“这 5 轮对话是否在向成交推进？”

规则很难写：

  • 有没有过早报价
  • 有没有跳过需求澄清
  • 有没有打断用户

LLM Judge 非常适合做：

Given the conversation history,
does the assistant follow a reasonable sales funnel?

场景三：RAG 命中质量（而不是召回）

注意区分：

层 评测方式
RAG Recall 规则 / embedding
RAG Answer Quality LLM as Judge

例如：

  • 文档召回对了

  • 但回答：

    • 是否完整？
    • 是否过度推断？
    • 是否遗漏关键信息？

场景四：多意图处理是否“合理拆解”

这是 Coordinator 之后、Orchestrator 的事。

示例

用户说：

我想退货，顺便问下物流什么时候到？

输出可能是：

  • 顺序 A：先处理退货，再答物流
  • 顺序 B：先答物流，再引导退货流程

两者都可能合理，但规则无法穷举。

👉 LLM Judge 可以判断：

  • 是否覆盖全部意图
  • 是否逻辑顺序合理
  • 是否对用户友好

四、一个非常重要的误区（必须避免）

❌ 用 LLM Judge 来“评测意图是否正确”

原因：

  • intent 是你系统定义的 taxonomy

  • LLM 并不真正理解你业务 intent 边界

  • 会引入：

    • label drift
    • judge 不稳定
    • 无法回归测试

五、你现在的评测体系，应该是“双轨制”

轨道一：确定性评测（你已经在做）

用于：

  • Coordinator
  • Router
  • Policy Gate
  • Safety Gate

方式：

expected vs actual → script → accuracy / confusion matrix

轨道二：主观语义评测（LLM as Judge）

用于：

  • 销售话术
  • 成交推动
  • 多轮体验
  • RAG 回答质量

方式：

conversation / response → judge → score / rubric

六、给你一个“销售助手评测分层图”（建议你直接采纳）

[ User Input ]
      ↓
[ Coordinator ]        → 规则评测（脚本）
      ↓
[ Orchestrator ]       → 混合评测（规则 + LLM）
      ↓
[ Sales Agent Reply ]  → LLM as Judge

七、一句总结（非常重要）

凡是“对错明确”的，用脚本；
凡是“好不好”的，用 LLM as Judge。

你现在的问题，说明你已经在做正确的工程级评测拆分了。

如果你愿意，下一步我可以直接帮你：

  • 给你一份 “销售助手 LLM Judge Rubric 模板”
  • 或帮你设计 Langfuse Evaluator + 规则评测并存的流水线

你想先落哪一个？

posted @ 2025-12-23 07:36  向着朝阳  阅读(41)  评论(0)    收藏  举报