让AI助手“靠谱”：评估框架把准确率拉到95%

把一个能聊天的 Agent 做出来不难；把它变成能交付、能上线、能持续改进的生产系统，难度完全不是一个量级。

Pushpay（为教会与公益组织提供数字化捐赠与管理平台）做了一个“用自然语言查数据”的智能搜索：工作人员输入一句话，比如“今年没奉献但在小组里的成员”，系统就能返回可行动的名单与洞察。早期用户反馈很直接：从手动操作约 120 秒缩短到 4 秒以内，效率提升近 15 倍。

但他们也撞上了大多数团队都会遇到的墙：原型阶段靠调 Prompt 能到 60–70% 的成功率，再往上就卡住了。Pushpay 的突破点不是“再写一段更长的提示词”，而是建立了一套可量化、可分域、可闭环的 GenAI 评估体系，并把它接进 Amazon Bedrock 的工作流里，把系统推到可控的 95% 准确率。

这篇文章放在「人工智能在智慧城市建设」系列里讲，原因很简单：智慧城市不缺数据，缺的是让一线人员（非技术）用自然语言就能拿到可靠答案的能力——在政务热线、城管巡查、交通调度、公共安全协同中尤为明显。你做的是教会管理还是城市治理，底层方法论是同一套。

真实问题：为什么你的 AI 助手总“看起来能用”，却不敢上线

核心矛盾是：用户问法无限多，但系统可执行的“结构化动作”是有限的。

Pushpay 的智能搜索要把自然语言转成 JSON（可被应用执行的过滤条件）。它面对的不是十几个筛选项，而是 100+ 可配置过滤器。当用户提出组合条件、模糊表达、同义词或边界场景时，LLM 可能：

• 选错过滤器（把“未参与活动”当成“未捐赠”）
• 参数填错（日期区间、包含/排除）
• 输出结构合法但语义不对（“看起来像答案”，却不是用户要的）

更糟的是，如果你只有一个“整体准确率”，你会陷入无效争论：到底是模型问题、Prompt 问题、还是数据/工具定义问题？

**我的立场很明确：没有评估体系的 Agent = 没有刹车系统的车。**它也许能跑，但你不该让它上路。

Pushpay 的架构思路：用 Bedrock 跑 Agent，用闭环评估把它管住

Pushpay 的方案可以抽象成四层：输入层、Agent 层、模型层、评估层。

1）自然语言入口：把“问问题”变成标准工作流的起点

用户不需要学新的 BI 工具，也不需要懂字段含义。他们只做一件事：用日常语言提问。

这点对小企业和智慧城市同样重要：让业务人员用熟悉的方式触发流程（文字或语音），而不是让他们适应系统。

2）Agent 核心：系统 Prompt + 动态 Prompt 构造器（DPC）

最开始 Pushpay 用一个很长的系统 Prompt，把角色、规则、以及所有过滤器说明都塞进去，并用 Bedrock 的 Prompt Caching 缓存，降低延迟和 token 成本。

但很快他们发现：长 Prompt 并不等于高准确率。因为每次都把“全部字段库存”喂给模型，反而增加混淆与幻觉空间。

于是他们加入 Dynamic Prompt Constructor（DPC）：

• 根据“用户问题 + 租户上下文（教会/组织差异）+ 人群角色”动态拼 Prompt
• 用语义检索从“几百个筛选项”里只挑相关的那一小撮给模型

一句话概括：把 Prompt 从“百科全书”改成“针对当前问题的工具清单”。

3）模型层：Claude Sonnet 4.5 输出结构化 JSON

这里关键不在于“选了哪个模型”，而在于输出是可执行的结构化结果，能直接驱动应用 UI/查询引擎。

对“AI 语音助手与自动化工作流”场景也是同理：你最终要的不是一段漂亮文字，而是 JSON / function call / workflow action。

4）评估层：黄金数据集 + LLM-as-a-Judge + 分域仪表盘

Pushpay 真正的转折点在这里。

他们搭了一套自定义 GenAI 评估框架，包含四个组件：

1. 黄金数据集（Golden Dataset）：300+ 代表性问题，每条都配“期望输出”。并且持续把真实用户问题加入并人工验证。
2. 评估器（Evaluator）：用 LLM as a judge 模式，把 Agent 输出和黄金答案对比，给出准确率，并记录日志与延迟。
3. 域分类（Domain Category）：用“生成式总结 + 人工正则”把问题分到不同领域（例如成员、捐赠、活动、参与度等）。
4. 评估仪表盘：不看一个总分，而是看“每个域”的准确率和延迟分布；并用 95% Wilson 置信区间展示统计可信度。

这套东西的意义是：让改进从“感觉”变成“证据”。

做对一件事：别盯总准确率，要盯“按域可控的可靠性”

Pushpay 在仪表盘上发现某个域（如 activity 活动类）准确率明显更低，且延迟更高。这个发现很现实：

• 有的域字段更复杂，组合条件更多
• 有的域用户问法更口语、更不稳定
• 有的域工具定义本身就不清晰

如果你只看整体 80% 或 85%，你会误以为“差不多能上”。但对业务来说，坏的那 15% 往往集中在最容易投诉的场景。

他们的上线策略很“工程化”：先抑制低表现域，再逐步放开

Pushpay 选择把低表现域暂时隐藏/降级，只让用户接触高表现功能，于是整体可交付能力直接拉到 95% 准确率。

这招特别适合智慧城市与企业自动化：

• 交通指挥先支持“拥堵查询、路段状态”这类高确定性问题
• 城管巡查先支持“工单查询、重复投诉合并”
• 政务热线先支持“政策问答+材料清单”而不是“一步到位办结”

靠谱的做法不是“一口气做全”，而是“按域逐步扩容”。

把它迁移到小企业与智慧城市：一套能落地的“语音助手 + 工作流”方法

你不一定在用 Bedrock，也不一定在做搜索。但只要你做的是“AI 助手驱动业务动作”，Pushpay 的方法可以直接复用。

1）先定义“可执行动作库存”，再让 AI 去选

别先写 Prompt。先列清楚系统能做什么：

• 可用的数据字段（客户、订单、工单、路段、摄像头、设备告警）
• 可用的动作（查询、创建工单、派单、发送短信、生成报表、触发审批）
• 每个动作的输入约束（时间范围、权限、必填参数）

然后让模型输出结构化指令，而不是自由文本。

2）做一个小而真的黄金数据集（从 30 条开始）

Pushpay 有 300+ 条，但你不需要一上来就做那么大。我的建议：

• 先收集 30–50 条“真实用户问法”（别用你自己编的）
• 每条给出期望的结构化输出（JSON / 工单字段 / SQL 模板参数）
• 每周新增 10 条，把线上失败案例“收编”进数据集

黄金数据集不是文档，是你的生产保险单。

3）用 LLM-as-a-Judge 做自动回归测试（每次改 Prompt 都跑一遍）

你要的不是“模型觉得像不像”，而是：

• 过滤器/字段是否正确
• 约束是否满足（日期、权限、敏感字段）
• 输出结构是否可执行
• 延迟是否超标（p50、p90）

把这些指标固定下来，你的团队就能从“争论 Prompt”变成“对着指标改”。

4）分域仪表盘 + 2×2 优先级矩阵：决定先修哪里

Pushpay 用“业务优先级 × 当前表现/可行性”的 2×2 来排优先级。我很赞同，因为这能避免团队陷入“专挑最难的啃”。

在智慧城市里，这个矩阵可以很具体：

• 高优先级 + 高可行：高频热线问题自动分流、常见材料清单、工单进度查询
• 高优先级 + 低可行：跨部门联动、复杂裁量规则、涉及多系统写入

先把“高优先级 + 高可行”做成稳定的 95%，用户会立刻感受到价值。

安全与责任：做城市级/企业级 Agent，别等上线才补课

Pushpay 的客户数据涉及捐赠与个人信息，他们强调数据只在受控生态里流转、不用于训练外部模型。

放到智慧城市与中小企业，这条更该提前做：

• 权限边界：不同角色能查哪些字段、能触发哪些动作
• 数据脱敏：日志、评估数据集、回放样本都要可控
• 提示词注入防护：把工具调用与系统指令隔离，关键动作加二次确认
• 可追溯性：每次回答对应的检索证据、调用参数、版本号

一句话：你要让系统“可解释、可回滚、可审计”。

你可以直接照抄的落地清单（两周起步版）

如果你正在做 AI 语音助手与自动化工作流，我建议用下面这套节奏：

1. **第 1–2 天：**梳理 20 个高频问题与 10 个可执行动作
2. **第 3–5 天：**做 30 条黄金数据集（真实问法 + 期望结构化输出）
3. **第 6–8 天：**接入 LLM-as-a-Judge 自动评估 + 记录延迟
4. **第 9–10 天：**分域看报表，先屏蔽最差的域，只上线最稳的 2–3 个域
5. **第 11–14 天：**引入动态 Prompt 构造（只给相关字段/工具），迭代一轮

目标不是“功能多”，而是可控地做到 95% 的可靠体验。

结尾：智慧城市的 AI，不缺聪明，缺“可验证的靠谱”

Pushpay 从 60–70% 的原型走到 95% 的生产可用，靠的不是玄学 Prompt，而是：黄金数据集、分域评估、可视化指标、按域发布、动态 Prompt 构造。

这套方法放到智慧城市更有价值，因为城市系统的容错更低、责任更重。一个不稳定的“聪明助手”只会制造额外工单；一个可评估、可迭代的助手，才能真正把查询、分流、派单、回访这些重复流程自动化。

你现在的 AI 助手，最不稳定的那 10% 场景集中在哪个“域”？如果你能把它标出来，你离可上线就不远了。