知识库应用案例
最后更新于
这有帮助吗?
知识库是否可靠,不取决于资料数量,而取决于边界是否清楚、来源是否可维护,以及真实问题能否稳定召回正确证据。
下面的参数只作为起点。先用 3~10 份代表性资料跑通导入、召回和使用,再根据固定问题集扩充。
让员工查询差旅审批、住宿标准和报销例外,并能打开来源核对原文。
知识库:【员工差旅制度】
条目:【出差审批流程】
条目:【住宿标准速查】
条目:【差旅常见问题】

检索
先用 BM25
员工问法与制度措辞差异大时增加嵌入
重排
先不使用
正确候选已出现但顺序不稳定时启用
资料版本
只保留当前版
历史审计需要并存时在名称中写明年份
回答要求
结论、条件、来源分开
资料未说明时明确标记
出差住店最高能报多少?
海外租车能否报销?
预计总费用超过 5000 元时由谁审批?
未经批准先订酒店会怎样处理?
只根据“员工差旅制度”回答。先给结论,再列适用条件和来源;资料没有说明时写“制度未说明”,不要用常识补全。
验收通过时,同一条制度用原文问法和口语问法都能命中,回答中的金额、角色和条件可以由引用直接支持。
把官方手册、故障代码和已审核案例组织起来,让客服先给安全、可追溯的排查建议。
官方手册
规格、保修边界、标准步骤
保留型号和文档版本
故障代码
一条故障一个小节
标注适用固件和设备型号
审核案例
已确认原因与解决方案的案例
未审核聊天记录不得直接导入
不同型号规则差异明显时,按型号拆成独立知识库,避免相同故障码互相竞争。
PDF 先抽查目录、表格和双栏正文。
故障码依赖精确术语,保留 BM25。
客户描述较口语化时增加嵌入模型。
给售后 Agent 绑定官方手册和审核案例,只启用【知识库搜索】。
根据设备型号、故障码和现象分三步排查。每一步标明依据来自官方手册还是审核案例。涉及拆机、用电或数据清除时,先提示风险并等待确认。
不把其他型号的步骤用于当前型号。
安全警告出现在操作步骤之前。
官方规则和案例建议分开。
无资料支持时转人工,不猜测。
从论文、访谈笔记和网页快照中提取可核对证据,再由 Agent 生成带来源的比较报告。
按研究问题建库,不把所有论文塞进一个大库。
文件名包含作者、年份和短标题。
访谈笔记标明受访者角色、日期和是否可引用。
网页资料记录抓取日期,因为知识库保存的是导入快照。

在已绑定研究知识库中查找“用户为何放弃首次配置”的证据。先按来源列出原始观点和限制,再归纳共识、分歧和待验证假设。最终生成 Markdown 报告;不得把推断写成受访者原话。

共识由至少两个独立来源支持。
分歧保留各自条件,不强行合并。
引用、推断和建议有明确标识。
网页快照和论文版本可追溯。
目标
用户最终要做出什么判断或交付什么结果?
边界
哪些资料应该一起检索,哪些必须分开?
来源
文件、笔记、目录和网页怎样更新?
解析
哪类文档最容易出现 OCR、表格或顺序问题?
检索
BM25 是否足够?何时需要嵌入和重排?
验收问题
哪 3~10 个问题代表真实使用?
失败处理
无结果、冲突版本和无资料支持时怎么办?
维护
谁负责替换资料、重新索引和备份?
不要把“导入了很多资料”当成完成标准。资料越多,重复版本、权限混合和噪声竞争越需要被显式管理。
最后更新于
这有帮助吗?
这有帮助吗?