误区一：RAG 包治知识
检索不到就答不出，这是 RAG 的硬边界。切分粒度、同义词、表格与扫描件的解析质量都会直接影响召回；很多项目失败不是模型不行，而是文档没被正确切开，或权限把关键段落挡在外面。怎么提高召回，先修切分与解析，再调词表与权限。
误区二：微调能记事实
微调更擅长学怎么答，而不是答什么。把制度条款灌进训练数据，模型往往在相似问法上复述得像，遇到具体数字仍会编。要注入事实，优先改检索与知识库，而不是重训，后者还会带来遗忘。为什么微调记不住事实，因为训练目标学的是表达模式。
误区三：微调要海量数据
指令微调可以用几百条高质量样本起步，但评测集要足够覆盖真实问法。样本少时更要小心过拟合：同一批问题在训练集里表现很好，换个问法就崩，这种落差只能靠独立评测发现。怎么避免过拟合，留一批没进训练的题做独立评测。
误区四：RAG 免治理
索引会过期、文档会重复、权限会变。没有版本与责任人，知识库三个月就开始答旧制度。治理包括谁审核入库、多久复核、过期如何下线，这些和模型无关，却是可用性的前提。怎么治理，定审核人、复核周期与下线规则三件事。
误区五：只能二选一
常见做法是 RAG 供知识、轻量微调固定文书格式与语气。判断边界：如果调整只涉及说什么，改检索；如果涉及怎么说，再考虑微调。两者叠加以评测为准，不要为了架构好看而叠加。怎么判断该叠加，先看格式问题是否占了主要失败比例。
适用与不适用
适合谁
- 只想要一个什么都能答的通用助手
- 不愿意指定知识库责任人的组织方
- 需要向业务方解释能力边界的项目经理
不适合谁
- 只想要一个什么都能懂的通用助手
- 不愿意指定知识库责任人的组织方
典型场景
某设备厂家的维修助手答不准扭矩值。团队最初怀疑模型不行，准备微调；排查后发现手册里的表格在切分时被打散，数值与单位分到了不同片段。修好解析与切分后，同一批问题的引用命中明显改善，微调被推迟到需要统一工单话术时再做。
可执行步骤
- 抽查二十条错误回答，区分是没检索到、引错段落还是表达不准类型
- 对未检索到的，逐项检查切分粒度、同义词表与权限设置三项逐条记录
- 对表达不准的，先用提示词与示例约束，观察一周再评估，不行再换方法
- 确需微调时，准备独立评测集与可回滚的模型版本，先小样本试跑版本
- 指定知识库审核人与复核周期，并把规则写进文档入库流程与台账并留档
常见坑
- 把所有错误都归因于模型能力，直接安排微调，两周后同样的问题仍在，只是换了失败方式，钱也花了。
- 拿训练样本当评测集，指标很好看，上线后换个问法就答错，团队反而怀疑是检索出了问题。
- 知识库无人负责，制度更新后旧文档仍在索引里，助手给出已废止的条款，业务方不再信任。
- 为了同时用上两种技术而叠加，维护两套流程却说不清各自解决什么，成本翻倍而收益不明。
自检与验收清单
- 错误样本是否区分了未检索到、引错段落与表达不准
- 切分与解析是否用真实表格与扫描件验证过一次
- 微调是否有独立评测集与可回滚的模型版本号
- 知识库是否有审核人、复核周期与下线规则说明
- 是否写明两种技术各自负责什么，边界在哪一段
常见问题
RAG 效果不好一定是模型问题吗？
多数不是。先看召回：把检索到的片段打印出来，人工判断有没有包含答案；如果没有，问题在切分、同义词或权限。检索对了仍答错，才轮到模型与提示词，顺序反了会白花钱，还得返工。
微调会不会让模型变笨？
有可能，学术上叫灾难性遗忘：新任务学过头，旧能力下降。规避办法是混入少量通用样本、控制训练轮数，并在评测集里保留原有能力的题目，逐轮对比，别只看新任务的表现。
知识库要多大才值得做 RAG？
规模不是关键，结构才是。几十份制度如果切分清楚、术语统一，也能做出可用的问答；上万份文档若格式混乱、互相矛盾，检索只会把矛盾放大，先做小范围高质量知识库更稳。