Agent 驱动的智能答疑产品构建：问答、诊断与修复实践

RAG 通过将外部知识库的检索与生成模型相结合，显著提升了生成内容的时效性、准确性，显著降低了幻觉率。如何应用和优化 GraphRAG、 Agentic RAG 等技术来提升复杂问题的解答能力；如何融合文本、图像、音频等多种数据形式的跨模态 RAG 的最新进展和应用创新？即将于 2025 年 4 月 10-12 日召开的 QCon 全球软件开发大会（北京站）将给大家带来相关实践案例，直击痛点，解锁可复制的经验与模式。

答疑类产品是提升用户体验的重要手段，是平台问题的“清道夫”。然而现有的智能化答疑产品，只能解决少量的静态文本匹配类问题，无法处理用户真实遇到的平台问题。因此才会有著名的“ Gartner：64% 受访者不希望客服系统部署 AI ”事件发生。在 InfoQ 举办的 QCon 全球软件开发大会（上海站）上，阿里巴巴技术专家黄建磊为我们带来了精彩演讲“Agent 驱动的智能答疑产品构建：问答、诊断与修复实践”，重点阐述在小喵智能答疑产品的研发实践中，如何通过主动问题定位、根因分析、问题修复构建的群体智能体，动态化解决用户问题，提升用户满意度。

内容亮点：

• 当前国内可用模型和 GPT 的代差，会造成工程层面大量的补丁工作；

• 最真实的 RAG 和 Agent 企业级落地。

以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。

我们团队大概在去年 10 月 1 日的时候，开始启动智能答疑系统的研发，现在正好过去一年时间，借这次 QCon 的机会，我们把过去一年在实践过程中遇到的问题以及我们如何解决这些问题分享给大家，希望对大家后续在应用层的落地有所帮助。

答疑产品的重要性

答疑产品在我们的生活和工作中无处不在。它是一种用于满足用户在使用特定平台时遇到问题后寻求解决方案的工具。这个特定平台可以被称为“宿主平台”。例如，常见的云产品如阿里云、腾讯云和 AWS 等都具备答疑产品的形态。

答疑产品的重要性体现在以下几个方面：如果设计得当，它可以显著提升用户体验、服务质量，并增强用户粘性。这些结论可以从一些公开资料和数据中得到佐证。然而，如果答疑产品设计不佳，反而可能产生负面影响。根据 Gartner 发布的最新报告，一个令人担忧的指标显示，约 60% 到 70% 的用户不希望他们使用的产品背后的答疑功能是由 AI 驱动的。甚至有超过 50% 的用户表示，如果他们所使用的产品背后的智能答疑是由 AI 驱动的，他们可能会转向其他平台。

答疑产品是依托于宿主平台的，用户在宿主平台上遇到问题后才会转向答疑平台。接下来，我们介绍一下我们团队所负责的宿主平台。我们平台是阿里巴巴研发运维的基础设施，面向产品研发人员提供软件交付全链路的自动化、平台化和智能化保障。简单来说，这就是一个 DevOps 平台，说得更专业一点，就是 SRE（Site Reliability Engineering，即网站可靠性工程）平台。

答疑产品的主要问题

我们先了解一个完整答疑的全链路过程。用户在宿主平台上进行操作时，可能会遇到红色感叹号提示，表明无法继续操作，这意味着用户遇到了问题。此时，用户会转向智能答疑的 AI 机器人，描述自己遇到的问题，例如“我遇到了什么样的问题，该如何解决？”

在智能答疑的背后，首先是一个 RAG（Retrieval-Augmented Generation）系统。RAG 系统包含底层的离线和在线知识库。问题进入系统的第一个环节是问题改写与泛化，这一环节也被称为问题的前置处理。处理完成后，问题会经过文本与向量的两路召回，从知识库中找到与问题最相关的问题 - 答案对。然后，将这些相关的内容传递给模型，模型会总结出一个答案，并通过答疑机器人告知用户，例如“你可以通过什么操作来解决这个问题”。

我想特别强调的是，在接下来的分享中，我不会过多强调 RAG 体系，但这并不意味着它不重要。实际上，RAG 是整个答疑系统中非常关键的环节。目前，无论是学术界还是工业界，对 RAG 的研究已经相当丰富。例如，LangChain、Llama Index 以及许多公开的论文都对这一领域进行了深入探讨。如果大家在 RAG 方面遇到问题，开源社区中已经有大量资源可以提供帮助。

对于答疑机器人给出的答案，用户可能不满意，或者不确定答案的正确性，这时他们会转向人工答疑。人工答疑分为两层：第一层是一线答疑人员，他们的主要职责是处理答疑工作。他们通常是非领域专家，主要解决相对简单的问题。一线答疑人员在解决问题时，往往依赖自己的隐性知识——即他们头脑中已有的知识。这种隐性知识与显性知识相对，显性知识是指明确记录在文档或知识库中的知识，而隐性知识则是个人在日常工作中积累的经验和直觉。

如果一线答疑人员无法解决问题，他们会将问题转给特定领域的专家。这些领域专家可能是功能的开发人员，他们对自己的功能模块和工作流程非常熟悉。他们会利用自己的隐性知识来解决问题。这就是一个完整的答疑系统。

在智能答疑系统的开发与落地过程中，我们遇到了三个核心问题。

首先，用户的问题描述往往不准确。 智能答疑系统依赖于用户的原始问题，但用户在输入问题时，往往只是希望快速绕过智能答疑环节，转而寻求人工帮助。因此，用户输入的问题通常非常简略，甚至不准确。数据显示，约 40% 的用户问题长度小于 8 个字符。这种简略且不准确的问题描述，即使后续有最先进的 RAG 体系或领先的模型支持，也很难为用户提供精确的答案。

第二是缺乏领域知识。当问题从通用领域转向特定私域时，基座模型往往不具备私域领域的专业知识。例如，企业内部的特定知识是基座模型所没有的，这就导致 RAG 体系中的知识库无法提供有效的解决方案。在答疑过程中，无论是人工一线答疑还是功能开发人员，他们解决问题时依赖的往往是自己脑海中的隐性知识，而这些知识并未被纳入 RAG 知识库中。因此，整体私域问题的解决率非常低。

第三是用户对 AI 的不信任。在实际应用中，用户对 AI 机器人给出的解决方案（例如分步骤的操作建议）往往持怀疑态度，甚至在转向人工答疑时，用户会要求一线答疑人员确认机器人给出的答案是否正确。本质上，当前的智能体系给出的是一套面向过程的解决方案，用户需要自行辨别这些解决方案的正确性，而这一过程需要用户承担一定的成本，这是用户不愿意接受的。相比之下，人工答疑给出的答案默认是被信任的，用户会直接执行。

目前市场上许多所谓的“ AI 产品”其实只是在名称上有 AI，本质上可能只有简单的提示（Prompt），而缺乏真正的智能化能力。在实际落地智能化应用时，我们遇到的这些问题，正是由于智能化本身的基座编程范式改变所引发的连锁反应。这些问题才是我们需要更多精力去解决的。相比之下，一些通用的、常见的组件在开源社区或工业界中都有相对成熟的参考案例。而我所提到的这些问题则更为具体、更具挑战性，这也是我今天分享的核心内容。

LLM 如何解决上述问题

接下来我们探讨如何在现有的 AI 基座之上，利用 AI 的能力解决上述提到的三个核心问题。首先，我们着重解决第二个问题——缺乏领域知识。在答疑过程中，人工答疑人员通常依赖自己脑海中的隐性知识来解决问题。那么，如何将员工脑海中的隐性知识转化为显性知识，并让这些显性知识能够被上层智能化系统（如 RAG 或模型对齐、SFT 过程中的语料）所利用呢？

在解决方案的迭代过程中，我们最初的想法是“人工智能，先有人工，再有智能”。因此，我们让一线人员手动编写知识，类似于编写代码的过程。然而，这种方式对开发人员的压力很大，因为它是一个旁路分支，不在他们的日常工作链路中。同时，显性知识的审核成本非常高，因此这条人工编写的链路难以持续。

随着对业界研究的深入，例如清华大学实验室关于智能体与环境对齐的工作，我们意识到可以利用专家知识来训练智能体。这启发我们转变思路：每个员工在日常工作中实际上已经在利用隐性知识解决问题，那么我们是否可以基于这些日常行为来提取显性知识呢？这就是隐性知识显性化解决方案的核心思路。

隐性知识显性化

隐性知识显性化是一个相对泛化的命题，不同的场景对知识的需求和知识的表示形式都不相同，因此落地形式也各有差异。举一个具体的案例：我们有一个智能修复 Agent，其中的 Planning 过程至关重要。Agent 在解决问题时需要规划如何解决，而这个规划过程需要私域知识的增强。我们发现，一线员工在构建平台上发起构建时，如果出现错误和错误日志，他们会利用隐性知识通过代码编写来解决问题。此时，错误日志以及解决错误的代码 Diff 可以构成一个生产数据集。我们可以通过这个数据集提取显性知识。

第一个阶段是知识提取。 底层依然使用基础语言模型，核心是利用其推理能力。我们向语言模型提供错误日志和用户代码的 Diff ，请求模型提取用户解决问题时的思路。

然而，仅靠知识提取还不够，因为模型底层可能存在幻觉，我们需要保证提取内容的准确性。业界常见的准确性解决方案有三种：第一种是找领域专家进行判断，这是最准确的方法；第二种是使用更先进的模型作为“教师”进行判断，但在我们的私域场景中显然不适用，因为私域知识无法让 GPT 或 O1 这样的通用模型进行判断；第三种是我们实践中采用的方法——自我一致性。简单来说，就是让模型多次判断同一问题。如果多次判断结果一致，那么在当前场景下就可以认为是正确的。我们将这些经过验证的知识流转到显性知识库中。

显性知识的提取核心在于通过精心设计的 Prompt 引导模型完成知识提取。具体来说，Prompt 采用三段论的结构化方式：首先，明确模型的身份和角色；其次，说明模型需要完成的任务；最后，告知模型输入的内容，例如错误日志和用户提交的代码 Diff。我们希望模型能够从这些输入中提取出显性知识，包括识别问题的类型、定位问题的方法、针对此类问题的通用解决路径，以及用户实际采用的解决路径。

第二个阶段是正确性的判断。 由于模型底层存在不稳定性，例如幻觉等问题，导致其输出可能具有概率性。因此，在正确性判断阶段，我们采用基于自我一致性的方法，让模型对同一问题进行多次判断。这一阶段的 Prompt 设计与第一阶段类似：首先明确模型的角色和任务，然后解释输入内容的含义，最后告知模型需要返回的结果形式。在这一阶段，模型需要从多个维度对提取的知识进行评估，包括：识别的问题是否正确、定位问题的理由是否合理、通用解决路径是否正确，以及用户的解决路径是否正确。最终，模型需要给出一个综合结论。这一阶段的目标是确保提取的知识在准确性上达到可接受的标准。

问题感知 Agent

在智能答疑系统中，用户对 AI 结果的信任度较低，尤其是在非编码领域。用户可能不会接受 AI 给出的解决方案，而是选择转人工处理。为了解决这一问题，我们提出了将面向过程的解决方案转变为面向结果的解决方案。传统的面向过程解决方案是指导用户按步骤操作，例如在构建失败的场景中，告诉用户第一步、第二步、第三步应该怎么做。而面向结果的解决方案则是直接为用户提供一个已经验证成功的代码 Diff 。这种思路的转变能够降低用户接受结果的成本，从而提高智能答疑系统的拦截率。

基于这一思路，我们引入了智能修复 Agent 的概念。我们意识到 Agent 将成为未来智能化应用的核心基座。如果将大语言模型（LLM）比作操作系统，那么 Agent 就是运行在该操作系统上的应用程序。因此，我们构建了一套完整的框架，涵盖 Agent 的定义、运行时管理、数据管理和知识提取。

在 Agent 的定义上，我们遵循了社区中广泛认可的 LangGraph 架构。这种架构在底层设计和生态扩展性方面都表现出色。在智能修复 Agent 的具体实现中，我们首先确认构建错误的发生，然后执行修复动作。修复节点中会进行规划（Planning）和排序（Sorting）操作。我们发现，在代码修复场景中，文件修改工具的成功率较低且受多种因素影响，因此我们将文件修改单独作为一个节点处理，并在修复过程中进行数据上报。这些数据对后续优化和效果评估具有重要意义。

Agent 运行时的设计至关重要。Agent 本质上是一个典型的“木桶应用”，由多个节点组成，任何一个节点的效果劣化都会对后续环节产生放大效应。为了避免这一问题，我们将 Agent 的运行时设计为一个链表，链表由多个步骤组成，每个步骤对应一个节点的运行时。每个步骤包含两个设计要素：Action 和 Checkpoint。Action 是模型的结构化输出，包括工具选择、行为生成和推理过程；Checkpoint 用于回退，当运行中出现效果劣化时，可以基于某些节点进行回退。Checkpoint 中包含状态（state）和环境（environment），例如当前的 Git 环境或工作区等。此外，我们还引入了 Reward 机制，类似于机器学习中的损失函数，使 Agent 能够自适应地决定是前进还是回退。

在数据到知识的维度上，我们继续推进隐性知识显性化的工作。最终，我们直接向用户提供经过验证的代码 Diff，用户可以直接接受而无需再手动执行复杂的步骤。

在智能答疑产品的开发过程中，我们整个思路是通过遇到一个个问题并基于这些问题实现一个个 Agent 。我们预测智能答疑未来将朝着群体智能的方向演进。尽管过去群体智能可能看起来较为虚幻，但在某些垂直领域和产品中，群体智能的实现或许会更快到来。我们团队将继续面向更多问题，补充更多 Agent ，并探索 Agent 之间的自主协作和沟通。我们认为，无论是答疑还是其他智能化应用，未来的底层架构一定是面向多 Agent 协作的方式演进。

心得感想

在 AI 产品的开发和应用中，我们有以下几点心得。

• 关注业务价值：当前许多 AI 产品只是名义上有 AI（AI in name only），实际上我们需要真正关注智能化应用的业务价值，避免仅仅为了蹭热度而开发产品。AI 产品的核心价值在于解决实际问题，提升效率或优化用户体验，而非单纯的技术堆砌。

• 进行可行性验证：与传统软件工程不同，AI 的基础是概率模型，这意味着其输出具有一定的不确定性。在某些需要严格容错的产品场景中，例如胰岛素注射剂量的计算等不允许出错的场景，我们需要更加慎重地验证 AI 的可行性，确保其可靠性和安全性。

• 优化用户体验：用户体验是 AI 产品成功的关键之一，主要体现在以下两个方面。

• 成本与效率的权衡：在 Agent 领域，用户体验和准确率之间往往需要进行权衡。Agent 的运行需要消耗大量资源，因此在设计时需要平衡效率和成本，确保用户在使用过程中能够感受到高效和便捷。

• 提供可解释性：为了增强用户对 AI 系统的信任，需要提供更多的可解释性。用户需要了解 AI 为什么做出某个决策或执行某个操作，这有助于减少用户的疑虑，提升他们对系统的信任感。

演讲嘉宾介绍

黄建磊，阿里巴巴技术专家。2017 年担任钉钉桌面前端负责人，是可交互卡片（现酷应用的重要底层能力）的发起人。2021 年开始做 O2 Space 研发平台，通过建设 O2 Pai 的开放能力，打造端到端的开放能力。2023 年至今，担任阿里巴巴爱橙科技的技术专家。研发过程智能化创新小组负责人，探索智能答疑、智能诊断、智能修复等研发过程中的智能化改造，提升研发效率和质量。

会议推荐

在 AI 大模型重塑软件开发的时代，我们如何把握变革？如何突破技术边界？4 月 10-12 日，QCon 全球软件开发大会· 北京站 邀你共赴 3 天沉浸式学习之约，跳出「技术茧房」，探索前沿科技的无限可能。

本次大会将汇聚顶尖技术专家、创新实践者，共同探讨多行业 AI 落地应用，分享一手实践经验，深度参与 DeepSeek 主题圆桌，洞见未来趋势。