选知识库智能体,第一步该判断什么?
先判断知识是什么形态,而不是先看产品。四类形态对应四种接法:结构化表格走字段查询,长文档走切片检索,问答对走直接匹配,系统实时数据则根本不该进知识库、应走接口。形态判断错了,后面的选型和调优基本是白做,这也是项目返工最常见的原因。
先看知识长什么样,再看产品长什么样
- 结构化数据:表格、台账、价目表,适合按字段精确查询,不适合切片检索。
- 长文档:制度、手册、方案,适合按段落切片,需处理标题层级与跨段引用。
- 问答对:客服话术、常见问题,适合直接匹配,但需定期清理过期条目。
- 实时数据:库存、工单、项目进度,应走接口查询,进知识库必然过期。
- 判断方法:抽 20 条真实问题,看答案分别来自哪类材料,来源分布决定接入重点。
- 覆盖缺口:盘点时统计有多少问题在现有材料里找不到答案,这部分缺口不能靠调优补齐,只能补文档。
边界与提醒现实里一份制度文档往往同时含条款、说明和附件表格,需要拆开按不同方式接入。整份文档统一按一种方式处理,检索效果通常只能达到预期的一半,这是接入阶段最常见的返工原因。拆分本身不需要高深工具,但需要业务方参与判断哪些段落属于哪一类。
四类知识形态,各自该怎么接?
接法差异很大:结构化数据要建字段映射与查询意图识别,长文档要做层级切分并保留上下文,问答对要做去重与版本管理,实时数据要定义接口与缓存策略。用同一套切片参数处理四类材料,是最省事也最不可靠的做法,效果通常在第二周就开始下滑。
接法不同,验收标准也不同
| 知识形态 | 处理方式 | 检索方式 | 常见错误 |
|---|
| 结构化表格 | 字段映射、建立指标口径 | 按条件查询,结果带原始行号 | 整表切片,数字被拆散失去含义 |
| 长文档 | 按标题层级切分,保留父子关系 | 段落召回后回溯所属章节 | 固定字数硬切,一句被切成两半 |
| 问答对 | 去重、标版本与生效期 | 问法相似度匹配 | 旧版本未下线,两个答案同时存在 |
| 实时数据 | 定义接口与缓存时长 | 调用接口并标注数据时间 | 导入知识库,第二天全部过期 |
边界与提醒表格类知识容易被低估:一份价目表如果能按条件查询,价值往往高于几十份文档的检索。但前提是字段口径统一,如果同一个指标在不同表里定义不同,先做口径治理再接系统,否则答案会前后矛盾且难以追责。另外,口径治理的产出物是一份指标定义表,写清每个指标的来源系统与计算方式,这份表在后续接入新系统时同样要用。
答案精度要求怎么定?它影响什么?
精度要求决定要不要建评测。如果只是内部检索参考、答错可由人复核,重点放在召回率即可;如果答案直接对外或进入流程,错一次就有实际代价,那就必须建评测集并设置拒答机制。宁可拒答也不要乱答,这条规则要在上线前就写进产品行为里。
先定错一次的代价,再定精度目标
- 内部参考型:答错成本低,目标是召回覆盖,允许标注不确定。
- 流程嵌入型:答案进入工单、报价、审批,必须有拒答与人工复核。
- 对外输出型:直接给客户看,需评测集加抽样人工复核双保险。
- 判断型问题:涉及取舍与建议,不宜由知识库直接回答,应转人工。
- 目标设定:按事实型、流程型、判断型三类分别设目标值,不用单一准确率。
边界与提醒精度目标不要定成单一准确率。同一套系统在事实型问题上的表现可能明显高于流程型问题,混在一起统计会掩盖真实短板。另外,拒答率不是越低越好,拒答率过低通常意味着系统在猜,这在对外场景里风险更大。
知识库的权限要隔到哪一层
至少三层:文档级(谁能打开这份文件)、段落级(同一文件里哪些段落受限)、引用级(回答里能不能带出受限内容)。多数方案只做到文档级,一旦文件里混排了薪酬、合同条款这类内容,答案就会在无意中把不该说的部分带出去。
段落级隔离最容易被漏掉
- 文档级:按目录或标签授权,实施成本低,适合边界清晰的资料库。
- 段落级:同一文件内按段落打标,需先做内容分类,成本较高但覆盖混排场景。
- 引用级:回答中的引用片段需二次过滤,避免带出受限原文。
- 留痕:谁在什么时候问了什么、系统引用了哪些内容,需可回溯。
- 测试方法:用低权限账号问一个只有高权限才能看的问题,看系统是否拒答。
边界与提醒段落级隔离会显著增加接入工作量,需要先完成内容分类。折中做法是把敏感内容从主文档中拆出单独存放,用文档级权限控制,成本更低也更可靠。但要注意拆分后主文档的可读性会下降,需保留指向说明。
更新频率高的知识怎么处理?
分两类:变更可预期的(制度、价目、组织架构)用定时同步,并在每次变更时手动触发一次;变更不可预期的(项目进展、库存、工单状态)不该进知识库,应走接口实时查询。把高频变动的数据塞进知识库,是答案过期最主要的原因,且很难通过调优解决。
会变的和不会变的,要分开处理
- 低频变更:制度、规范类,按月同步,变更时手动触发。
- 中频变更:价目、产品参数,按周同步,需记录版本与生效日期。
- 高频变更:库存、工单、进度,走接口,答案中标注数据时间。
- 过期处理:设置失效期,到期未确认的内容自动从检索范围移除。
- 责任人:每类知识指定一名内容责任人,同步机制由服务商维护,内容对错由责任人负责。
边界与提醒定时同步存在滞后窗口,业务上要明确能接受多长的滞后。如果答案是必须实时,那这类知识就不适合走检索增强,应改为接口调用并在回答中标注数据时间。另外,同步失败要有告警,否则会出现系统以为已更新、实际仍是旧版本的情况。
怎么验证检索效果?
建一个 50 到 100 条的真实问题集,覆盖三类问法:直接问、换说法问、跨文档问。每次调整后跑一遍,记录命中位置与答案正确性。只看演示时的那几个问题没有意义,因为那些问题通常是照着文档原文出的,真实用户不会那样提问。
测试集必须包含问不准的问法
- 直接问:用文档里的术语提问,验证基础召回。
- 换说法问:用口语、简称、错别字提问,验证语义匹配。
- 跨文档问:答案分散在两份材料里,验证多段拼合能力。
- 越权问:低权限账号问受限内容,验证隔离是否生效。
- 记录方式:每条记命中段落、答案是否正确、是否正确拒答,三项分开统计。
- 回归机制:每次调整切片或更换模型后,用同一套问题集重跑,防止修好一类问题同时弄坏另一类。
边界与提醒测试集必须由业务方出题并封存,不能由实施方提供。实施方出题会不自觉避开难点,导致测试通过但上线效果差。另外,测试集要定期补充新问题,否则会逐渐失真;建议每季度补 10 条以上来自真实使用记录的问题。
选型常见误判有哪些?
三个:把文档上传量当成接入完成度、把演示效果当成上线效果、把产品功能表当成交付能力。前两个是评估方法的问题,第三个是把对象搞错了——知识库效果大约七成取决于知识与规则的质量,三成取决于产品本身,只比功能表等于只比了三成。
三个误判,都是把过程当结果
- 上传量当完成度:接入 5000 份文档但没做切片与更新,效果不如 200 份高质量文档。
- 演示当上线:演示用的是整理过的数据,上线面对的是混乱的真实文档。
- 功能表当能力:功能列表趋同,差异体现在权限模型、引用溯源与切片策略上。
- 忽略运营:上线后无人维护知识,三个月内效果必然下滑。
- 忽略口径:同一指标不同定义,答案前后矛盾,用户信任一次性崩塌。
边界与提醒也要避免反向误判,认为产品完全不重要、全靠人工调优。产品在切片策略、权限模型、引用溯源上的差异是实打实的,只是这些差异要在真实知识上才能测出来,看功能表看不出来。合理的做法是用同一批真实问题横向测试 2 到 3 家,再比较结果。横向测试时要注意使用同一批问题与同一批文档,只改产品变量,否则比出来的只是数据差异,不是产品差异。
内容说明
平台能力描述以腾讯云官方产品页为准;知识接入与评测治理环节以深云官网公开表述为准。文中测试集规模与效果比例来自企业知识库项目的通行实施经验,具体项目需按知识规模调整。
正在选知识库方案?
可以先做一次知识形态盘点与问题集抽样,用你们自己的材料测出可行方案,再决定要不要采购。
看深云怎么做知识接入