7.3 日志、监控与迭代运营


7.3 日志、监控与迭代运营

运营四指标:解决率(多少对话没转人工就闭环)、转人工率、平均轮次(对话效率与 Agent 健康)、单次成本(token 与工具调用)。日志面板是它们的数据源,周报是它们的呈现形式,迭代决策是它们的最终用途。上线只是让数据开始积累,这一节把积累变成改进。

交付三动作的最后一个:运营。全册主线在这里收口——从第 3 章上线的第一天起,小艺的每次对话都在积累日志,本节教会你把这份积累变成每周一次的、有数据支撑的改进。

日志面板的三种用法

**用法一,排障。**用户反馈"刚才它答错了",凭时间与关键词在日志里找到那条会话,点开就是完整现场:用户问了什么、命中了哪些知识分段、Agent 调了什么工具、模型答了什么。第 4 章的"看命中不看答案"、第 6 章的"读轨迹",数据都来自这里。**用法二,挖掘。**把一周日志按"转人工"过滤,逐条看转的原因——是知识库没覆盖、检索没命中、还是工具没查到?这就是下周改进清单的原料。**用法三,质检。**抽样看回答质量,点赞点踩的会话优先复核;配合标注功能,把高频优质问答固化为标注回复(相似问题命中标注时直接返回,不再走模型,又快又省)。

四指标周报

四个指标的定义与读法:

指标 定义 小艺首月基线 健康信号
解决率 未转人工即闭环的对话占比 58% 环比上升
转人工率 触发转单或人工的占比 34% 环比下降
平均轮次 单次咨询的对话轮数 2.4 稳定或缓降
单次成本 token 与工具调用折算 0.11 元 不随功能上涨

读指标的诀窍是成对读:解决率涨且成本不涨,是真改善;解决率涨但平均轮次暴涨,可能是"磨"出来的解决(用户被来回引导),体验反而差。首月的真实周报里抓到一个典型:物流类问题转人工率 40%,远高于其他类。归因(用法二)发现 query_logistics 的返回没有 ETA 字段,模型只能回答"在途",用户追问"到底哪天到"两轮没结果就点了转人工。修复(6.2 的防腐层加字段)后下一周该类转人工率降到 17%。一条字段,二十三个百分点——这就是数据驱动迭代最直观的样子。

图 7-3:周运营节奏与升级备份日历

图 7-3:周运营节奏与升级备份日历

升级与备份的节奏

2.1 给过命令,这里给节奏。备份:数据卷每周自动导出到异机存储(数据库与向量库两个卷都要),每月挑一次手动走恢复演练——没验证过可恢复的备份只是心理安慰。升级:每季评估一次平台版本,安全修复版本即时跟;升级前备份、按 2.1 三步走、升级后跑 2.3 的开台体检表加四指标对比,任何异常按回滚预案处理。回滚双保险:应用配置层用 DSL 版本库(分钟级),数据层用备份(小时级),两层独立,总有一层够得着。

问题:日志会一直涨,怎么管理存量?

会话日志是增长最快的存储项,两个动作管理它:其一,导出归档——运营要的周报与归因做完后,把明细导出到团队数据目录,平台内只留近期(比如三个月)供排障回放;其二,用量与明细分开看待——token 用量等指标已在导出时汇总进周报,不需要靠明细长存支撑。归档前确认没有未结的客诉个案引用旧会话,客服纠纷的追溯期决定你的保留下限。

问题:周报做了两个月没发现改进点,正常吗?

不正常,但问题通常不在日志,在挖法。三个自查:转人工会话真的逐条归因了吗,还是只看了数量?挖掘范围是不是太窄(只看转人工,没看低分反馈与超长对话)?改进清单是不是只盯着提示词(知识库补文档、工具改返回常常更有效)?把这三问补上仍无产出,说明产品已进入平台期——那反而是好消息,可以把精力转向扩场景:下一个"小艺"该服务哪个部门,答案就在你们公司的待办列表里。

给第一次做周报的同学一个起步模板:上半页四个指标加环比箭头,各配一句"为什么涨/跌";下半页三块——本周改进了什么(对应上周的归因)、下周计划改什么(附预期指标变化)、待决事项(需要产品或 IT 配合的事)。十行以内,例会上五分钟讲完。周报的生命力在于短,长了三周必弃。

全册收官:流水线的全景回放

七周走完,回放这条"应用搭建工作台"流水线:第 1 章认台(定位、选型、架构)→第 2 章开台(部署、模型、体检)→第 3 章首搭(创建、提示词、发布)→第 4 章喂数据(分段、检索、验收)→第 5 章上强度(节点、总装、工单流)→第 6 章放手(循环、工具、防护)→第 7 章交付(接线、筑墙、运营)。每一章的产出是下一章的输入,而第 7 章的运营产出——新的日志与新的需求——又回流成第 3 到 6 章的迭代输入。流水线是环形的,这正是导读知识地图上那条"阅读建议"背后的深意。

往哪儿去?三条进阶路线按兴趣选:评测工程——把 4.3 的召回测试集扩展成全自动回归流水线,每次变更自动跑分;多智能体——6.3 变式二的多 Agent 协作,适合更复杂的业务编排;平台定制——从 DSL 之外深入插件体系与源码级扩展,把工作台本身改造成团队专属形态。无论哪条,这本册子教的"验收先行、数据说话、迭代闭环"三件事,都是路上的随身工具。

⚠️ 常见坑:把运营做成"只看报表"。指标不是成绩单,是决策原料——每周必须产出至少一个"改一件事"的动作并下周验证,否则周报三周后就会变成没人看的仪式。

本节要点回顾

  • 日志三用法:排障看现场、挖掘归因转人工、质检沉淀标注回复;
  • 四指标成对读:解决率配成本、轮次配解决率,孤读必误判;
  • 周节奏固化:周报、归因、试验田单改、发布观察、质检五件套;
  • 月季动作:备份演练、密钥复核、逐级升级、测试集扩题;
  • 回滚双保险:DSL 分钟级、数据小时级,独立可靠;
  • 流水线是环的:运营产出回流为下一轮搭建输入,交付的真正形态是迭代闭环。

全册完。回到导读的知识地图,你会发现自己在七个站点各留下了一件可复用的资产:一份选型决策、一张架构图、一份说明书模板、一套测试集、一条流水线、一面工具墙、一本运营周报。下一张工作台,随时开工。


作者与出处
原作者: 灏天文库
来源:灏天文库
整理: 灏天文库整理
由灏天文库平台收录,内容或由平台用户上传,仅供学习交流
发布者: 作者: 灏天文库 转发
评论区 (0)
U