推荐语
构建Agent知识库是企业AI落地的关键一步，这篇文章带你了解如何打造真正懂业务的知识底座。
核心内容：
1. Agent知识库的本质与核心要素
2. 公有知识与私有知识的区别与价值
3. 知识库构建的实战方法与案例解析
杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家
![]()
![]()
Agent想要落地，知识库是绕不过去的话题。
这篇文章结合AICX服务客户的一些具体案例，帮助大家理解以下问题：
什么是Agent搭建需要的知识
为什么Agent搭建需要知识
Agent搭建时常用的知识搜集/整理的流程及方法
enjoy~
Agent需要的知识库不是数据的堆砌，而是用户体验的基石。反过来说，Agent需要的知识库，一定是基于用户需求/体验构建的。什么是Agent需要的知识？知识是能够解决用户问题的结构化信息。知识包含的要点有三个，知识的标题、知识的相似文法以及答案。我们来看一个管理咨询公司Agent构建的实际案例：相似问法则是对于标题的延申，因为用户实际使用时会有大量不同的文法，为了提高知识的召回率和识别的准确率，我们需要设置尽可能丰富的相似的问法，最终提高知识的命中率。答案则是标准化的解决方案，包括解决问题的步骤、相关政策文件条款甚至相关操作需要的链接。大模型的训练是有周期的，所以大模型自带的知识库永远是out的，目前大家常用的Chatgpt、Claude、Qwen、DeepSeek等等自带的知识内容基本都局限在2024年6月以前，当用户提问涉及2025年发生的事情时，大模型就会抓瞎。同时，大模型基本都基于公有知识训练，并不了解很多我们真实业务场景下所需要的私有知识。 | |
| 指已经公开发表，每个组织和个人都可以获取（免费/付费）的知识，是人类认识世界的基础。 | 指在公共知识的基础上，结合组织和个人所面临的需求、场景、问题所形成的知识。大部分是以不同岗位和职能员工经验的形式存在，碎片化，难以跨岗位复用。 |
如果我们为了解答用户更新的问题每隔一段时间就去对模型训练一次，无论是时间成本还是资源成本都过高，对于很多个人和组织而言完全不可实现。基于此，我们需要给大模型配置一个所谓的知识库来解决这个问题。知识库相当于提供给大模型的时时更新且包含组织私有知识的百科全书，来解决大模型知识过期或者不具备私有知识的问题。这类知识库都是基于某类特定场景的，大模型通过调取知识库去回答特定场景下的问题。知识会分为三类，“高频知识”、“低频知识”、和“无效知识”。AICX服务企业的实践中有一个很典型的案例，当时项目一共整理知识2万余条，其中在落地实战3个月内有被用户咨询的不到4000条，80%以上的用户提问也就是所谓的“高频知识”只有600余条，其他16000条基本都是无人提问的“无效知识”。“高频知识”解决用户核心问题，“低频知识”覆盖用户长尾需求，剩下的无效知识不仅无用甚至有以下害处：干扰模型的判断，当用户提问时可能导致大模型错误匹配（知识库越大准确率越低）严重拖慢Agent对用户需求的响应速度（知识库越大越慢）构建知识库是“狙击”思维，从高频问题出发精准并不断根据环境变化调整，所以有价值的知识库，一定是相对少而精的，同时需要长期的更新和维护。组织在考虑Agent建设成本时，一定不要只考虑搭建成本，如果想要保证Agent的落地性和使用效果，维护成本很可能会超过搭建成本。
![]()
![]()
做知识搜集整理的第一要义，就是只收集有效知识，而不盲目做知识堆砌。这里有很多知识来源，最常用的就是历史数据（对话、工单、已有知识库）、出版发表的书籍文章以及对业务专家的访谈。除了内部信息来源，往往还需要外部的一些共有知识的补充，比如行业标准或者竞品知识库的逆向工程。我们还可以在对话日志中找到一些用户的高频提问但还没有标准答案的内容，然后对这些知识进行进一步的补充和整理。以上工作中，AI工具可以提供巨大的助力，但要做好AI工具生成结果的质检。比如在实践中AI生成的问法经常很不“人类”，需要我们人工优化。以上搜集的过程，其实是对企业知识体系一个精加工的过程。这个过程中我们需要合并重复问题（甚至合并类似场景）、去掉无效前缀、规范表达（比如用7W2H框架将知识归类为标准问题类型）、对看似相似实则不同的场景进行明确区分等等。比如当用户提问“如何与某专家老师达成培训业务合作，费用是多少？”这里其实是两条独立的知识，一个是合作的步骤方式，一个是收费标准。所以我们需要把一条知识拆分成两条独立的知识，这样用户单点提问时大模型可以找到精准答案，避免冗余信息干扰这个环节的本质是明确知识库的构建重点，确定知识整理的优先级。通过对历史数据的统计分析以及业务专家的经验判断，最终从搜集的知识中提炼出高频知识。我们的整体知识的维护资源是有限的，所以我们需要根据咨询频率和业务价值这两个维度去划分优先级。一般来说，在实操中会在高频知识投入80%以上的资源，因为这些问题基本可以覆盖90%以上的用户场景。高频知识有两种识别方法，一种是数据驱动，就是根据历史数据的频率，通过算法合并语义相同的提问，然后根据排序提取到高频知识。第二种是业务专家驱动，就是让业务一线人员根据经验去圈定一个范围，这非常适合没有历史数据的冷启动场景。我们一般会组织一些业务专家通过工作坊进行头脑风暴来整理知识清单。除此以外，我们要形成动态维护机制，我们需要通过日志去看每条知识的答复率和准确率，一旦超过阈值，就要纳入重点范围。对于低频知识，基本只会占用20%以内的精力，这类知识主要覆盖比较长尾的需求，在知识库上线后，如果季度或者半年没有这些知识的访问记录，一般就会纳入“待删除”。还有一类是无效知识，我们通过标记每条知识的最后命中时间，超过期限的就要及时清理，避免造成知识污染。无效知识包括新旧知识冲突，比如政策变动或者公司制度变动，又或者平台活动规则调整。我们可以通过系统的自动告警，及时冻结并删除旧知识。本质是对知识的结构化，厘清知识间的关联。这里一般可以分为可结构化的知识、模糊的知识、无规律的具体知识、表格知识以及多维度推理知识。结构化的知识指的有很清晰层级关系的知识。比如医保报销，这里会包括报销流程、报销比例、注册需要的证件等，这些知识的层级是非常清晰的，可以通过多轮对话让用户最终明确自己实际要咨询的问题。模糊的知识是指用户提问并没有包含足够的信息，没办法直接让大模型在知识库去匹配。这里我们就需要做一些多轮的意图澄清。比如用户说帮我查一下某某某号码。这里他的潜在意图有可能是想查某某号码上个月的消费记录，也可能是想查话费余额或者流量余额。这里我们需要构建一个可能的意图树，然后预设所有可能的子意图分支，然后把这些比较模糊的问题拆解为一些可选路径，让Agent根据这个意图树去进行追问。实践中这类选项的数量一般是3~5个，防止用户信息过载，同时也要提供一些兜底选项，类似于“转人工”这样防止用户想问的问题不是我们提供的任何一个选项的情况。同时我们要做好上下文，让Agent记住用户的历史选择或者历史问题种明确的指代，从上下文中找到用户本轮咨询的主语。无规律的具体知识一般都是一些长尾问题，这类问题往往彼此独立，且用户提问率比较低。对于这类知识，我们需要设计比较精细化的标签体系，包括业务的类目、地域甚至人群标签。比如这是一个“初级顾问”，他还是一个“人力资源领域”，同时他还在服务“新能源”行业，结合这些多标签的组合检索，可以提高这类人群会问的一些特殊问题的命中率。我们在设置答案的时候，也要设置得更加模板化。当用户文一些无规律的知识问题时候，我们可以快速梳理并填充到知识库中。比如某政府单位的知识库，我们可以这么设计答案模板：一句某某政策，可以根据ABC步骤办理，如果您还不了解，可以咨询XX电话或者XX部门。通过这个模板，我们可以快速维护无规律的知识。表格类知识非常适合参数化查询，能够快速响应用户的精准提问。这类知识会有明确的行列字段，我们在处理的时候需要让字段更加的标准化，并且关联用户最关心的核心属性（非核心属性可以简化）。我们还需要保证这类数据支持语义分析，比如当用户提问“最贵的咨询服务方式是哪种”（真有这么问的），这里我们要能够快速映射到咨询产品的价格以及交付方式上，然后把答案从知识库返回给大模型让大模型自己判断。最后是多维度的推理类知识，这类知识非常适合复杂逻辑判断，依赖知识图谱和规则引擎。主要用在解决涉及多个条件复杂问题的场景。比如某个用户提问，"某个项目收入是50万，项目周期6个月，涉及XX模块，客户有哪些特殊需求，是否可以立项"。这时候我们的处理步骤如下，首先去抽取用户问题里的关键参数，比如项目收入50万，涉及模块项目周期等，然后根据参数去配置规则引擎，比如根据用户企业体量，估计某模块的执行成本的计算公式。第三就是做一些动态的推理和输出，去最终判定这个项目是否合适立项。这里也可能需要设计一些意图树，让Agent去根据意图树进行追问以补充信息。第四步是选择问答引擎，基于知识类型来选择合适的引擎。问答引擎（Question Answering Engine, QAE） 是一种基于自然语言处理（NLP）和信息检索技术的系统，能够理解用户以自然语言提出的问题，并从结构化或非结构化的数据源中提取或生成答案。不同类型的知识（如结构化数据、非结构化文本、多维度推理等）需要不同的处理方式，而问答引擎是实现这一目标的技术工具。选择与知识类型匹配的引擎，可以显著提升系统的准确性、效率和用户体验。传统的检索引擎，一般类似图书馆查图书，基于目录进行快速匹配。比如FAQ问答引擎，特别适合处理简单的一问一答。然后就是多轮对话，主要适合那些需要通过追问补充信息或者厘清用户需求的厘清。表格查询引擎适合查询结构化数据，知识图谱适合处理多维度的推理问题，我们需要根据知识属性去针对性的选择问答引擎。老式引擎的使用和维度成本都比较高。以FAQ为代表，这类引擎需要我们手工录入，手动分类甚至手动关联，灵活性也非常差，甚至可能用户提问新增了一种问法，都需要手动去修改知识库。现在大模型出来以后，我们可以通过RAG+LLM大幅度降低维护成本，增加知识灵活性。但是大模型的使用成本相对较高，你可以理解老式引擎类似新华字典的目录，查询方式固定，印刷了就不能修改，但是查询精准且单次查询成本有限。大模型类似每次查询都需要把新华字典全部过一遍，虽然灵活，但是精准度和单次查询成本都不如老式查询方法。所以没有最好的，只有根据项目需要选择最合适的。第五步是知识整理，基于前面四步的任务产出，去整理知识库所需要的知识。包括QA清单、只是表格甚至知识图谱。以上知识搜集整理SOP，不是单次运行就足够的，而是多轮多次，在实践验证中不断补充完善，最终形成知识搜集整理的“飞轮。”
![]()
![]()
Agent的构建易学难精，搭建一个能跑的Agent可能只需要几分钟，但是搭建一个真正能用于业务的Agent需要很多条件，而知识库的构建就是其中最重要的环节之一。这篇文章，结合AICX服务客户时的业务实践，和大家分享如何构建一个企业级Agent需要的知识底座。
知识就是财富这句话，在过往可能只是一个哲学指引，但在AI时代已经变成了触手可及的现实。想要做出能够提效业务的Agent，知识管理不应该只是某个项目时的突击，而更应该是每个组织/企业的日常。了解了AI需要什么样的知识底座，平时才能有意识的去搜集整理，当真正面临场景落地时才能准备充分。
粤ICP备17114055号