企业知识库问答

1客户嘴上要的

「公司有几万份文档，散在共享盘、Wiki 和邮件里。做个企业 ChatGPT，员工问什么都能答。」

这是症状或现成方案，不一定是真问题。下面看两种做法。

2照字面做，会怎么烂

3好 FDE 的实际走法

共 6 周，分 5 个阶段。带三角标记的是这一步最容易踩的坑。

1. 1

   第 1 周选一个人群和一组问题

   • 跟知识管理负责人和 3 个业务部门负责人聊，选出问题最集中、损失最明确的人群：售后技术支持工程师。他们每天要查产品手册、技术通告和历史案例，一个问题平均查 20 分钟，新人要问老员工。
   • 从工单系统和内部群聊记录里收集他们近 3 个月的 300 个真实问题。成功标准定为：「在这 300 个问题的测试集上，答案正确且引用出处正确的比例不低于 85%；答不了时明确说『不知道』；新人查一个问题从 20 分钟压到 5 分钟。」
   • 踩坑别接「全员助手」这个范围。范围越大，越没有人能说清什么叫做好。
2. 2

   第 2 周先治理文档

   • 只纳入和这个人群相关的 3 类文档：产品手册、技术通告、已结案的典型案例。每类指定一个内容负责人。
   • 清理：同一产品的手册保留现行版本，旧版本标记「已废止」并移出检索；互相矛盾的技术通告列成清单，交产品技术部裁决。
   • 发现缺口：300 个问题里有 70 个在文档中找不到答案。请资深工程师补写 FAQ，而不是让模型编。
   • 权限：检索时按员工在原系统的权限过滤，看不到的文档不进入答案。
   • 踩坑别跳过治理直接调检索。文档有问题时，检索调得越好，错答案越自信。
3. 3–4

   第 3–4 周原型 + evals

   • 做针对性处理：手册里的参数表格单独解析成结构化数据，避免切块切断表格；按产品型号过滤，避免把 A 型号的参数答给 B 型号。
   • 每个答案附原文出处和文档版本；检索不到可信内容时回答「没有找到，建议联系某某组」。
   • evals：300 个问题由 2 个资深工程师标注标准答案和出处。每次改切块、检索或提示词都要全量跑，看总分和失败类型分布。
   • 踩坑只看「答案读起来对不对」不够。要单独核对出处，答对但引错出处的答案，用户也不敢用。
4. 5

   第 5 周Demo + 并肩改

   • 让新人和老员工各用一周。在每个答案下加「有用 / 没用 / 答错了」按钮，答错的自动进入待修清单，每周由内容负责人处理。
   • 反馈常见：「型号过滤最有用」「通告太多，我只要最近一年的」——按发布时间加权。
5. 6

   第 6 周交接交接

   • 交给售后技术支持部的知识负责人：维护文档范围和 FAQ，每周处理待修清单，每月跑一次 evals。IT 负责权限同步和系统运维。
   • 扩展到下一个人群时，重复同样的步骤：选问题、治文档、建评测集、找负责人。
   • 没有内容负责人，系统三个月内就会过期，回到「问了也不敢用」。

4这个案例教给你的可复用判断