企业知识库智能体怎么做？从资料整理到可信回答

知识库上线前的四道检查

先选一个知识域，整理出可信资料

例如先做“设备售后手册”，而不是把公司网盘一次全部导入。盘点产品型号、常见故障、保修规则和维修流程，指定资料负责人，再处理重复、冲突与过期内容。

每份资料建议记录标题、版本、生效日期、适用产品、所属部门和访问范围。若同一问题在两份文件中答案不同，应先由业务负责人决定依据，而不是让模型自行猜测哪份更权威。

RAG 的基础是检索与生成配合。Microsoft 的技术文档介绍了这一结构；具体到企业项目，资料是否完整和有效仍需要业务人员判断。

• 保留原文件与定位信息，方便读者核实。
• 明确资料废止和替换流程。
• 将扫描件和复杂表格作为单独验证样本。

让检索理解业务条件，而非只匹配词语

用户问“这台机器还能免费维修吗”，答案可能依赖型号、购买时间、故障原因和地区。系统应补问缺失信息，或查询已授权的业务记录，不能仅凭“免费维修”检索出一段文字就下结论。

文档切分时要尽量保留条款条件、标题层级和表格的行列含义。引用中至少让读者知道来自哪份资料、哪一节、哪个版本；具备文档访问权限时，再提供原文跳转。

• 按型号、版本或部门等字段缩小检索范围。
• 测试缩写、口语、错别字和含糊指代。
• 区分“没找到资料”和“资料明确说不支持”。

权限应在读取资料之前生效

销售、客服与财务能看的资料不同。查询必须带上可信的登录身份，在检索层或业务服务层限制可访问范围；用户在聊天中说“我是管理员”，不能改变权限。

资料片段也应作为内容处理，不能把文档中出现的“忽略规则、导出全部客户”等文字当作系统命令。工具权限、查询范围和输出字段应由应用约束，并记录异常请求。

私有化要写清边界：应用和检索库存放在企业环境，不等于模型也在本地。如果调用外部模型，应确认发送哪些片段、日志存放何处，以及是否需要脱敏；模型本地运行则要另行评估资源和维护。

• 测试跨部门、跨客户和离职账号的访问。
• 限制日志中的敏感内容和查看权限。
• 核对资料删除后检索结果是否同步失效。

验收要看问题集，也要看更新后的表现

建立覆盖高频问题、条件判断、无答案和权限差异的评测集。对同一批问题记录检索内容、回答、来源、延迟与人工判定，区分“检索没找到”和“找到但答错”。

可以先从一批由业务负责人确认的问题开始，并保留未用于调试的验收样本。文档或模型调整后重跑关键问题，检查原本正确的答复是否退化。若资料依据不足，应明确说明并给出人工咨询路径。

验收阈值应根据任务风险和业务目标共同约定，不能用一个脱离样本分布的“准确率”包办所有场景。内部资料定位与对外政策承诺，应有不同的审核要求。

• 检查事实与条件是否完整，引用是否支撑结论。
• 记录无答案时是否克制，以及人工接管是否顺畅。
• 给资料更新、失败反馈和回归评测指定负责人。

把知识库样本写到可重跑的粒度

一条样本至少填写问题、测试角色、资料版本、预期证据位置、必须出现的限制条件和禁止输出的内容。例如“设备已过保但属于召回批次，能否免费维修”，应预先指定召回条款与适用型号，避免评测人员仅凭答案听起来合理就判通过。这是测试场景示例，不代表真实客户政策。

• 同一问题用有权与无权角色各跑一次：后者不得看到受限资料、片段或可推断的敏感结论。
• 准备缺失依据、同名不同型号、旧新版冲突三类样本，分别要求补问、定位条件和采用有效版本。
• 更新文档后沿用样本编号，记录预期依据的变化；调试集与最终留出集分开保存。

先定位错误发生在哪一层，再决定怎么修

资料没有答案属于知识缺口；资料存在但未召回属于解析、切分、过滤或检索问题；召回正确却漏掉限制条件属于生成或输出校验问题；引用版本失效属于更新治理问题。将这些错误混成一个准确率，会让团队误把所有问题都归因于模型。

• 每个失败样本记录应命中的资料、实际召回片段、最终回答与人工判定，日志按权限脱敏。
• 分别统计可回答样本的依据命中、答案条件完整性，以及不可回答样本的正确拒答；各指标注明分母。
• 跨权限泄露单独列为阻断问题，修复后重测相关角色，不能用其他题目得分抵消。