企业知识库 AI 助手

项目背景

客户是一家中型制造企业，产品线多、迭代快。售前、售后、生产三个部门各自维护着一套资料：产品手册在共享盘，故障处理经验在工单系统，工艺规范在 OA，还有大量知识只存在于几位老员工的脑子里。

新人上手要三个月，老员工每天被打断七八次回答重复问题。客户最初的诉求很直接：「能不能做个能问的搜索框。」

在写代码之前，我们花了两周做了一件看起来不太像开发的事——收集 220 条真实问题和标准答案，来源是工单记录、企业微信群聊和对老员工的访谈。

这份评测集后来成了整个项目最有价值的资产：每次调整切分策略、换检索方式、改提示词，都跑一遍打分，能直接看出是变好还是变坏。没有它，所有优化都只能靠感觉。

12 万份文档里有 PDF 扫描件、Word、Excel 工艺表、CAD 导出图纸说明、以及大量截图。

最初按固定字数切分，评测集准确率只有 63%。改成按文档语义结构切分（章节 → 小节 → 段落，保留标题层级作为上下文），并在每个片段前拼接「文档名 + 所属章节」后，准确率直接提升到 81%。

这是整个项目里性价比最高的一次优化，几乎没增加成本。

纯向量检索对「型号 XG-2400」这类精确关键词很不擅长。我们改成混合检索：向量召回 + BM25 关键词召回，合并后再用重排序模型精排，取 Top-K 送给大模型。准确率从 81% 到 88%。

剩下的 3 个百分点来自查询改写：把用户口语化的提问先改写成检索友好的表述，再去检索。

制造企业的工艺文件有明确密级。我们的做法是在检索层做权限过滤，而不是在生成后过滤——用户无权访问的文档片段根本不会进入上下文，从机制上杜绝泄漏。

每条答案下方列出引用的文档片段，点击可跳转到原文对应位置并高亮。同时明确区分三种情况：有依据的回答、知识库里没有相关内容、找到了但内容互相矛盾。第三种情况会同时列出冲突的两份文档，交给人判断。

宁可说"没查到"，也不要编一个看起来合理的答案——这条原则写进了提示词，也写进了验收标准。

上线前测算月度调用成本时发现，如果所有问题都走最高规格的模型，成本会超出客户预算三倍。我们做了三件事：

最终月度成本控制在预算内的 60%。