坑一、二：接库即上线与机械切分
把文档灌进向量库就宣称完成检索，语料没有清洗、切分没有按结构，命中率自然低。如何验证？拿三十条真实问题做召回测试，看正确段落是否出现在前几条；排在第五位以后，基本等于没有命中，得先回去修索引。
坑三：只用向量检索
向量检索对同义表达友好，对编号、型号与专有名词却不敏感。制度问答里大量问题带着条款号，纯向量召回经常给出一堆相近但不对的段落。如何取舍？加上关键词检索与重排，改动不大，效果通常立竿见影。
坑四：忽略权限过滤
把全公司文档放进一个索引，再靠提示词要求模型不要透露，这种做法在审计时站不住脚。权限必须在检索层生效：先按用户身份过滤候选文档，再让模型作答，否则越权访问只是时间问题，边界要在检索层划清。
坑五：只看回答不评召回
只对最终答案打分，无法判断错误来自检索还是生成。应把评测拆成两段：召回层看正确段落是否被取到，生成层看答案是否忠于段落。两层分开看，才知道该修索引还是改提示词，这也是评测的边界。
坑六：不做增量更新
一次性把文档灌进去，之后靠人工补录，制度一改就出现新旧并存。应建立变更触发机制与失效标记，旧版本立即下线，并定期抽查答案是否还引用已废止的条款，这项检查最容易被忽略，却直接决定答案是否可信，如何抽查要写进流程。
适用与不适用
适合谁
- 正在搭建企业知识问答系统的团队
- 已经上线、但准确率长期停滞的项目
- 需要对内部知识做权限隔离的平台
不适合谁
- 文档量很小、人工查询更快的场景
- 没有文档管理规范、也没有负责人的组织
典型场景
某集团的知识库上线三个月后准确率下滑，排查发现是制度改版后旧文档仍在索引里。团队补了版本字段与失效标记，把召回测试固定到每周，并把权限过滤前移到检索层，越权提问与过期答案两类问题同时消失，复查也轻松了。
可执行步骤
- 用三十条真实问题做一轮召回测试，逐题记录正确段落被排在第几名
- 逐段检查切分是否按条款与章节进行，把缺失的结构信息补齐并复核
- 同时开启关键词与向量检索，加入一层重排，再对比前后两轮的命中率
- 把权限过滤前移到检索层，按用户身份缩小候选文档范围，再做召回
- 建立文档变更即触发更新的机制，同时给旧版本打上失效标记并下线
常见坑
- 把文档灌进向量库就宣布完成，没人测过召回，上线后答不对也找不到原因，只能反复试。
- 权限只写在提示词里，模型仍能读到不该读的文档，审计时无法自证合规，风险全部留在企业。
- 只评最终答案，检索与生成的问题混在一起，改来改去没有方向，几轮之后团队就会放弃。
- 文档更新全靠人工补录，旧条款长期留在索引里，答案新旧混杂却无人发现，客户先发现。
自检与验收清单
- 是否用真实问题测过召回的名次以及失败分布
- 切分是否按结构进行，并保留完整的元数据字段
- 关键词检索与向量检索是否同时启用并做重排
- 权限过滤是否在检索层就已经生效，并留下记录
- 是否有变更触发更新与旧版本失效标记的机制
常见问题
向量库能不能直接用开源方案？
可以，多数场景用开源组件就能起步，成本也低。真正的难点在语料清洗、切分与权限，而不是数据库选型；把精力放在这三件事上，比反复更换组件更有效，也不容易在选型上走弯路。
召回率多少算合格？
取决于业务容错度，通常要求正确段落稳定出现在前三条。低于这个水平，生成层再优化也很难补救。建议先用三十到五十条真实问题建立基线，再逐轮改进，每轮只改一个变量。
权限过滤会不会降低召回？
会缩小候选范围，但这是必须付出的代价，也是正确行为。用户本来就不该看到那些文档，过滤后答案更聚焦。若过滤导致大量拒答，说明索引里的可共享语料不足，应补内容而不是放开权限。