采购需求智能审核的岔路口：训练模型还是搭建知识库？

从一个真实的客户反馈说起

我们给广东某高校上线了采购需求智能体审核功能，跑了一段时间后，客户给了一个耐人寻味的反馈：审核的内容基本符合人工审核的预期，但部分内容还有错误。

这个反馈传回团队，立刻出现了两种声音：

• 一种声音说：模型不行，训练模型（微调）吧，让它更懂业务；
• 我的第一反应则是：搭建该业务系统的知识库，让智能审核的智能体在做审核时检索知识库，做 RAG 增强。

哪种更优？为什么？或者有没有比这两者更好的方案？

这个问题其实是 AI 落地采购场景最经典的一道选择题：微调 vs RAG。我把整个分析过程摊开来讲，这个思路对几乎所有”合规审核类”的 AI 应用都适用。

先给结论

RAG 完胜微调。但更优的答案是”规则引擎 + RAG”的分层混合架构，而不是二选一。

为什么这么说？先从一个核心认知讲起。

采购审核本质上是一场开卷考试

微调改的是模型的”脑子”，RAG 改的是模型的”开卷资料”——这是两种方案最本质的区别。

而采购需求审核，恰恰是一场开卷考试：

• 答案都在文件里：《政府采购需求管理办法》（财库〔2021〕22 号）、87 号令、广东省的限额标准、学校的校内制度……
• 模型不需要”背会”这些，只需要找得准、引得对；
• 审核意见必须写清楚”依据某某文第 X 条”——引经据典是这个业务的天性。

有人提出训练模型，其实是把客户发现的错误一律诊断为”模型不行”——这是常见误诊。错误要不要靠训练解决，得先看错误是什么类型，后面会讲怎么正确归因。

五个维度硬碰硬

把两个方案放在采购审核这个具体场景里对比，五个维度 RAG 全部占优，而且不是险胜：

维度	训练模型（微调）	知识库（RAG）
法规时效性	法规年年改，知识”焊死”在参数里，模型会很自信地引用已废止的旧标准	法规更新当天重新入库，下次检索即生效
可解释性	引用是”凭记忆背出来的”，背错就是幻觉	引用附带原文出处，可核对、可追溯
数据要求	要千条级”需求书→审核结论”标注配对数据	现有法规文件+历史审核记录即可起步
修复速度	发现错误要重训，以周计	补一条知识、改一个切片，当天修复
合规底线	审核意见说不清依据，客户不敢用	引经据典，评标专家和监管一看就懂

微调在这个场景有三个硬伤，值得单独展开：

硬伤一：法规年年改，模型脑子换不了。 财库〔2021〕22 号之后还有各类补充通知，广东省集采目录定期调整，校内制度随时修订。微调把知识”焊死”在参数里，法规一更新，模型会很自信地引用已废止的旧标准——比不说话还危险。

硬伤二：合规审核的命根子是”引经据典”。 审核意见必须写清楚”依据某某文第 X 条”。微调模型的引用是”凭记忆背出来的”，背错就是幻觉——客户发现的错误里，大概率就有这一类。

硬伤三：没米下锅。 微调要千条级”需求书→审核结论”的标注配对数据，一所高校一年才审多少份需求书？数据量撑不起，硬训必然过拟合。

更优的答案：不是二选一，是分层

真正的问题在于：客户发现的那些错误，未必都该交给大模型去解决。把错误分类看，会发现有一大半根本不该出现在 LLM 的职责范围内。

这就是分层架构的由来——把”不该错的事”从 LLM 手里抢回来：

层级	管什么	为什么
L1 规则引擎	限额标准、集采目录比对、必填字段、品牌/型号关键词黑名单、资质门槛硬性红线	这些是确定性判断，代码判是 100% 准，让 LLM 判反而会错
L2 RAG + LLM	倾向性/排他性分析、需求完整性、预算合理性论证	需要语义理解和行业经验，检索法规+历史案例做增强
L3 人工复核	低置信度结论转人工兜底	审核员点”采纳/驳回”，驳回意见回流知识库——这是最值钱的数据资产

配套的知识库要分四个库建：

1. 法规库——按条款切，不按字数切。每个切片带元数据：发文机关、文号、生效日期、是否废止、适用范围。废止标记尤其重要，不然检索会召回旧条款，等于给模型喂毒药。
2. 案例库——把历史退回的需求书和整改后的版本做成对照案例：“这类写法上次被退了，理由是 XX”。这是通用大模型永远给不出来的东西，也是微调最想学却学不到的隐性经验。
3. 规则库——结构化的限额表、资质清单、关键词词库。
4. 模板库——标准需求书模板、审核意见模板。

几个落地要点：

• 混合检索：BM25 关键词 + 向量语义双路召回再加 rerank。法条编号、限额金额这类精确匹配靠 BM25，“变相指定品牌”这类语义判断靠向量，单靠任何一路都有盲区。
• 建评测集：拿历史上人工审过的需求书+人工结论做 golden set，每次改知识库、换模型都跑一遍回归——这是保证”错误只减不增”的机制。
• 提示词硬约束：只依据检索到的材料下结论，引用必须附原文，检索不到就明确说”知识库未覆盖”——宁可暴露短板，不可编造依据。

客户发现的错误，到底该怎么治

回到问题的起点——既然不该”一律诊断为模型不行”，那已发现的错误怎么归因、怎么对症下药？

错误类型	典型表现	病根	治法
幻觉引用	引用了不存在的条文、编造的文号	模型凭记忆编	RAG + 引用原文硬约束
漏检	明显问题没审出来	知识库没覆盖/检索没命中	补库 + 混合检索优化
误报	没问题的地方报了问题	判断标准模糊	规则显式化，边界案例进案例库
硬规则错	限额、字段这类低级错误	确定性判断交给了 LLM	下沉到规则引擎，代码判零误差

把客户发现的错误逐条归类，就是响应客户质疑的最好动作——它把”智能审核不准”这个模糊的抱怨，变成了一张清晰的整改清单。

给微调一个公平的说法

微调不是永远不对，它适合”学模式”不适合”学知识”——输出格式稳定、话风统一、特定推理套路。所以正确定位是远期可选项：等项目跑了一年半载、审核员沉淀了几千条采纳/驳回记录后，可以微调一个”审核风格模型”，但知识仍然靠 RAG 喂。现阶段提微调，属于没病先吃药。

一句话收口

跟客户和团队沟通时，别把话说成”RAG vs 微调”的二选一，要说：

该确定性的交给规则，该语义的交给 RAG，该兜底的交给人工，知识资产沉淀在学校自己的知识库里。

这套说法客户听着也舒服：数据不出校、知识可积累、法规更新当天生效——恰好是高校采购处最在意的三点。而且这个思路不只适用于采购需求审核，合同审查、制度合规检查、招投标文件核验……所有”依据文件做判断”的 AI 应用，都可以照搬这套三层架构。