惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

阮一峰的网络日志
阮一峰的网络日志
雷峰网
雷峰网
Last Week in AI
Last Week in AI
T
Tailwind CSS Blog
V
Visual Studio Blog
Jina AI
Jina AI
博客园 - 司徒正美
The Cloudflare Blog
Hugging Face - Blog
Hugging Face - Blog
博客园_首页
S
SegmentFault 最新的问题
博客园 - 三生石上(FineUI控件)
有赞技术团队
有赞技术团队
小众软件
小众软件
V
V2EX
Apple Machine Learning Research
Apple Machine Learning Research
美团技术团队
博客园 - 【当耐特】
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
IT之家
IT之家
WordPress大学
WordPress大学
爱范儿
爱范儿
月光博客
月光博客
大猫的无限游戏
大猫的无限游戏

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
【收藏】价值 10 万的 AI 生成内容评估方法(附模板)
Aaron · 2026-01-28 · via 人人都是产品经理

当AI生成内容面临凭空捏造与逻辑混乱的困境时,一套科学的评估体系成为破局关键。本文从风控实战出发,提出涵盖关键点覆盖、事实准确性、推理合理性与结果可用性的四维评估框架,并揭示如何通过量化评分将AI输出从'助手级'提升至'专家级'。这套方法论为Agent内容质量提供了可落地的验收标准。

每个做 Agent 的人,大概都经历过这样一个“至暗时刻”。

建好工作流,写好 prompt,把业务数据投喂给 Agent,希望他像资深分析师一样,给你出一份完美的风险研判报告。

但实际上对于生成的内容,第一眼看过去,完美。格式工整,行文流畅,甚至还会用“鉴于”、“综上所述”这种专业词汇。

但当仔细看内容时会发现各种问题,凭空捏造、逻辑错误、避重就轻、内容质量差、AI 感严重等问题,例如

  • 凭空捏造: 它写道“用户在凌晨 3 点进行了一笔 5w 的大额转账”,你查遍了日志,那一分钟风平浪静,根本没有交易。
  • 逻辑错误: 它分析说“因为该设备关联了 3 个账号,所以判定为团伙作案”。但实际是:关联 3 个账号在家庭场景下太正常了,这不应该被判断为团伙作案。
  • 避重就轻: 你让它分析核心的“洗钱链路”,然后它写了 500 字的“用户注册时间分布”。

结果就是,不仅没减负,反而员工成了 AI 的铲屎官。所以我们在开发 Agent 时就需要有一个合理的评估体系来评估生成的内容是否符合业务需求,然后根据评估结果不断做 Agent 的调整,直到结果符合预期。

关于公司业务

此前我是做电商行业的风控场景,基于客诉,关联账号数据、订单数据、鉴权数据、登录数据、各类业务数据,再基于这些数据去分析诈骗链路、风险特征、异常信号、作案模式、处置建议等,最终形成一份风险报告。

我们针对最终这份风险报告几乎完全无法评估好坏,因为涉及多个模块,每个模块又包含多个维度,无法进行整体评估,所以我们将一次性输出完整报告改为调用多次模型,模型每次仅输出其中一个模块,每个模块单独的工作流和 prompt,然后在前端页面上再合并到一起。

这样好处是能更精细化的生成模块内容,以及每个模块的可评估性更高。

并且设计了下面方法进行评估。

我们的评估方法

我们评估方法是参考这篇文献来设计的:https://arxiv.org/html/2508.19932v1#/ (案例:一种用于增强数字支付诈骗识别能力的智能体人工智能框架)

具体如下四个维度

1、关键点覆盖:关键指标是否有遗漏——完整性指标

评分公式: 命中点数 / 应覆盖点数

必查清单: 时间范围、PIN 数量级、订单金额级、涉及的主场景(支付渠道/业务类型)等。

执行标准: 少一项,就是信息缺失,必须补全才能出库。

2、事实准确性:不凭空捏造

模型输出内容与事实或业务真相的一致程度。模型推断的风险结论或作案模式是否正确地反映实际情况 。准确性评估需要有参照的“正确答案”或事实支撑,可通过人工标注的真值(如已确认的诈骗类型)来计算正确率。

例如:不能把“诈骗大案”说成“正常行为”。但把“边缘套利”略微夸张成“有较大风险”是可接受的(视业务而定)。

0 分:存在严重事实错误(指错方向、错场景、错类型),有任何凭空出现的事实(原始数据/客诉/分析结果中没有),直接判 0 分。

1 分:有轻微不一致/过度总结,但整体方向没错。把边缘套利说得稍重一些可以容忍。

2 分:所有关键事实与原始数据完全一致,无虚构。

3、推理合理性:产生结论是否合理,是否出现结论与入参信息矛盾

例如,在“作案模式推断”模块中,模型需要根据行为日志和信号进行合逻辑的推断,而非跳跃性结论。判断推理链条是否充分支持最终结论。

0 分:结论与证据明显不一致,或者跳跃严重

1 分:总体逻辑还可以,但局部解释牵强

2 分:结论都有对应证据,逻辑链条清晰

特别适用于“作案模式推断”。

4、结果可用性:对分析师“减负”程度

基本可用?部分可用?完全不可用?

通用评估体系:一套可迁移的方法论

注:上面是针对我们业务的评估体系,可参考,但如果需要更精致的进行评估,还是需要根据自己业务针对性去找参考文献。

下面是一套比较通用的评估体系

1、遵从性评估

定位: 机器可自动拦截的“硬指标”。 解决问题: Agent 是否听懂了指令?格式对不对? 执行策略: 这一层建议直接用代码(Rule-based)做,过不了直接打回重写,不消耗人类精力。

a. 格式规范

标准: 输出是否严格符合 JSON / Markdown / PDF 结构要求?

0分: 格式错误,无法解析(例如 JSON 缺了括号)。

1分: 格式完美,可直接入库。

b. 要素覆盖率

标准: Prompt 里要求的模块(如:摘要、数据表、结论、建议)是否齐全?

0分: 缺失核心模块。

1分: 所有模块齐全。

c. 篇幅限制

标准: 是否满足“不少于 X 字”或“不超过 X 页”的限制?

0分: 严重偏差(误差 > 20%)。

1分: 达标。

2、准确性评估

定位: 核心红线,风控/严肃业务的生命线。 解决问题: Agent 是不是在瞎编数据?有没有幻觉? 执行策略: 建议采用 LLM-as-a-Judge (用更强模型查) + 人工抽检。

a. 数据真实性

标准: 报告中的数字、时间、实体是否在原始输入中存在?

0分: 凭空捏造数据、实体(例如编造了一笔不存在的交易)。

1分: 数据存在,但单位、精度或属性有误。

2分: 100% 忠实于原始输入。

b. 信息一致性

标准: 上下文是否矛盾?

0分: 前后严重矛盾(如前文说增长,后文说下降)。

1分: 有细微冲突但不影响结论。

2分: 全文逻辑闭环。

c. 原文忠实度

标准: 总结/摘要是否扭曲了原文原意?

0分: 歪曲原意,断章取义。

1分: 略有偏差但大意对。

2分: 精准概括。

3、逻辑性评估

定位: 智能水平检测。 解决问题: Agent 的分析是否有深度?推导是否合理?

a. 推导严密性

标准: 结论是否由论据自然推导得出?

0分: 强行归因,逻辑跳跃(因为 A,所以 C,中间缺了 B)。

1分: 逻辑通顺,但论据单薄。

2分: 证据链完整,归因准确。

b. 观点明确性

标准: 是否给出了清晰的判断,而非模棱两可的废话?

0分: 全是“可能/大概”,车轱辘话来回说。

1分: 有观点但不够犀利。

2分: 观点鲜明,直击痛点。

c. 结构条理性

标准: 信息组织是否符合金字塔原理?

0分: 杂乱无章,堆砌素材。

1分: 有分段,但层级混乱。

2分: 结构清晰,层层递进。

4、可用性评估

定位: 最终交付标准。 解决问题: 客户拿到报告能不能直接用?人工还要改多久?

a. 可读性

标准: 语言是否通顺?专业术语是否准确?

0分: 翻译腔严重,语句不通。

1分: 通顺但有语病。

2分: 专业、流畅、信达雅。

b. 行动建议

标准: 是否给出了可执行的下一步建议?

0分: 无建议,或建议为空泛口号(如“加强管理”)。

1分: 有建议但落地难。

2分: 建议具体、可执行、有步骤(SOP化)。

c. ROI

标准: 人工需要花多少时间润色?

0分: 需完全重写(不可用)。

1分: 需修改 > 30%(半成品)。

2分: 只需改错别字 < 5%(成品)。

5、综合评分公式

可以将这套体系封装成一个计算公式,作为你 Agent 服务的验收标准:

总分 = (遵从性 × 20%) + (准确性 × 40%) + (逻辑性 × 20%) + (可用性 × 20%)

红线规则: 一旦“准确性”维度出现 0分项,无论其他项得分多少,总分直接归零。

交付分级:

< 60分: 废品。系统需重构(Prompt 或 Workflow 有大问题)。

60-80分: 助手级。需人工介入修改。

80分: 专家级。可直接自动化分发。

本文由人人都是产品经理作者【Aaron】,微信公众号:【曾俊AI实战笔记】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于 CC0 协议。