第一代值班问答 Agent 的幻觉率与准确率复盘

封面信息图

随着第一周大促备战的推进,我们团队基于大语言模型(LLM)与 RAG(检索增强生成)技术搭建的**“第一代智能值班问答 Agent”**,在企业微信生产值班群内完成了整整 7 天的实战值守。

从最初把散乱的 Wiki 文档直接喂给大模型时遭遇的“幻觉频出、胡编命令”,到经过 Runbook Markdown 结构化重构、BM25+向量混合检索、只读 AST 命令沙箱拦截与交互式卡片闭环改造,这个机器人终于从一个不靠谱的“聊天玩具”,蜕变为了值班工程师身边可靠的“数字副驾驶”。

本文系统复盘第一周值班 Agent 的运行实测数据,重点剖析大模型幻觉率的压降路径、准确率量化评估与生产落地经验

第一周实战数据大盘

在过去 7 天内,值班群共产生针对 Agent 的技术问答与排障交互 218 次。我们对每一次交互的输入、检索召回 Chunk、模型输出、以及工程师的最终采纳情况进行了人工与自动化的双重质检:

评估指标早期朴素 RAG(第 1~2 天)结构化+沙箱加固后(第 5~7 天)改善幅度
Top-1 Runbook 召回准确率54.2%94.1%提升 39.9%
严重事实性幻觉率(Hallucination Rate)28.5% (编造不存在的指令)3.2%压降 88.8%
危险非只读命令拦截率0.0% (无拦截)100.0% (成功拦截 12 次非安全操作)彻底兜底
值班工程师采纳率(Acceptance Rate)36.8%87.6%提升 2.38 倍
平均端到端响应耗时8.2 秒2.4 秒 (流式响应+语义缓存)缩短 70.7%

数据表明,经过深度的工程化重构后,大模型在专业垂直运维场景下的可靠性完全能够达到生产可用的严苛要求。

压降幻觉率的四大核心工程战役

在通用 LLM 应用中,大模型的幻觉往往只是让人会心一笑;但在运维值班场景中,一个虚构的参数或一条编造的清理指令,就足以引发一场重大故障。我们在治理幻觉时,坚决不依赖大模型自身的自觉性,而是构筑了四道物理级的工程防线:

[ 值班提问 ] ──► [ 1. 意图边界校验 (拒答无关/越界问题) ]
                       │
                       ▼
                 [ 2. AST 语法树切片 + BM25/向量混合召回 (Top-3 相似度 > 0.85) ]
                       │
                       ▼
                 [ 3. 严格 System Prompt 契约 (禁止外部知识推演) ]
                       │
                       ▼
                 [ 4. 输出事实性一致性比对 (Faithfulness Check) ] ──► [ 发送企微卡片 ]
1. 消除源头噪声:Runbook Markdown AST 语义切片

早期幻觉的一大半源自文档切片把父级标题和前置条件切碎了,导致模型在残缺上下文中自行脑补。重构切片器后,每一个进入向量库的 Chunk 强制携带完整的系统名称、故障类型与安全红线前缀,召回准确率瞬间从 54% 跃升至 94%。

2. 混合检索与拒答机制(Refusal Guardrail)

在检索阶段,如果混合检索(RRF 打分)返回的 Top-1 片段置信度得分低于 0.75,Agent 坚决不进入大模型推理流程,而是直接触发标准拒答模板:“当前知识库中未收录该故障的官方处置预案,为防止误操作,请立即联系二线专家值班人员处理(附值班表链接)”。宁可承认不知道,坚决不允许自由发挥。

3. 严格的 System Prompt 契约化约束

我们在 Prompt 中注入了冷酷的负面约束逻辑:

  • “你必须严格、字面地基于提供的 Context 内容进行回答。”
  • “如果 Context 中没有提供具体的命令参数,绝对禁止凭借预训练知识推测生成任何带有 --force--all 的操作。”
  • “回答中必须明确引用来源于哪一篇 Runbook 的哪一个小节。”
4. 自动化事实一致性打分(Faithfulness Evaluation)

在旁路评测流水线中,我们引入了基于 Ragas 框架的事实一致性评估。系统自动提取大模型回答中的每一个技术主张(Claim),反向与 Context 中的原文进行 NLI(自然语言推理)蕴含比对。只有当蕴含得分达到 1.0 时,该条回复才被判定为高质量。

一周实战沉淀的经验与不足

  1. 多轮对话上下文污染
    在群聊环境中,多位工程师交替提问时,如果 Agent 维护了全局会话 Session,容易把前一个故障的上下文代入到后一个完全无关的提问中。我们最终将群聊交互模式重构为**“单卡片独立上下文(Thread-isolated Context)”**,每个故障事件单对应独立的会话生命周期,彻底消除了跨事件的上下文污染。
  2. 缺乏多 Agent 协同分工
    第一代 Agent 是一个单体架构(Monolithic Agent),既要负责检索、又要负责 PromQL 查询、还要负责卡片组装,在面对跨网络、跨数据库的复杂复合故障时显得力不从心。

下一阶段演进方向

第一周的战役证明了 RAG 与 LLM 在值班场景下的巨大价值。
下周我们将正式启动第二代架构的升级:从“单体问答 Agent”全面进化为**“基于 LangGraph 的多 Agent 协同诊断集群”**,将系统拆分为指标分析 Agent、日志挖掘 Agent、网络拓扑 Agent 与主控仲裁 Agent,实现对复杂生产故障的自动化因果推导与联合排障。

Logo

DAMO开发者矩阵,由阿里巴巴达摩院和中国互联网协会联合发起,致力于探讨最前沿的技术趋势与应用成果,搭建高质量的交流与分享平台,推动技术创新与产业应用链接,围绕“人工智能与新型计算”构建开放共享的开发者生态。

更多推荐