大模型RAG和专家系统的区别

做企业问答或规则咨询时，经常有人问：这不就是个专家系统吗，为什么还要上大模型？反过来也有人以为挂了知识库就等于专家系统过时了。这两种理解都容易踩坑。这篇把两者的思路差异、各自掉链子的地方和不适用条件摊开讲，最后给一个按场景选路的判断清单。

做企业问答或规则咨询时，经常有人问：这不就是个专家系统吗，为什么还要上大模型？反过来也有人觉得挂了知识库，专家系统就过时了。这两种理解都容易踩坑，因为两者解决的根本不是同一件事：一个靠人把知识写死成规则，一个靠检索找到资料再让模型组织语言。选错了，轻则白干几个月，重则上线后没人敢用。

这篇不站队，只把两者的知识来源、维护方式和出错方式摊开对比，最后给一份按任务反推的选型清单。凡是涉及具体模型能力、价格和横向对比的数字，都到站内资料库核对当时的实况，别拿记忆里的旧结论做决策。

知识装在哪里：规则库 vs 向量库

传统专家系统把知识写成显式规则或事实表，推理机按条件匹配，答什么、怎么答都能追溯到某一条规则。RAG 则是把资料切块、做向量化，提问时先检索召回相关片段，再让模型用自然语言把答案组织出来。前者是确定性的推导，后者是「召回+生成」的组合，同一问题问两次，措辞都可能不一样。

规则库

人写死的条件和结论，改动即生效，但覆盖范围受限于写得有多全

向量库

资料切块后的语义索引，覆盖面取决于你喂了什么文档

可追溯性

规则系统天生能出示依据；RAG 要靠引用片段和出处标注补上

• 答案必须逐字对得上依据条款、要能出示原文出处，偏规则路线；
• 答案允许自然语言归纳、问题覆盖面广且杂，偏 RAG 路线；
• 规则之间本身互相冲突、又都是长文本描述时，硬写规则库维护成本会失控，这种情况别硬上专家系统；
• 资料量小到几十条问答对就能覆盖，两条路都嫌重，直接维护对照表更省事。

维护和迭代方式差在哪

专家系统的改动等于改规则，动一条可能牵动全库，改完必须跑一遍回归，确认没有把别的场景带崩。RAG 的改动多数落在数据侧：换文档、调切分粒度、重建索引，模型基本不动。所以两者的日常工作量分布完全不同，一个花在规则梳理和冲突检测，一个花在资料清洗和检索调优。

有一点常被低估：RAG 的效果大头在数据准备，切分粒度、要不要加重排、要不要补元数据过滤，这些对结果的影响往往比换模型更大。反过来说，如果知识更新极慢、条目又极少，两套都嫌重，直接写死的问答对反而最稳。

各自会怎么出错，怎么兜

专家系统的典型故障是规则缺口和规则打架，表现出来就是答不出，或者同一问题在不同路径下给出互相矛盾的结论。处理办法不复杂：补规则，并且在上线前跑一遍冲突检查，把互相打架的条件标出来。

RAG 的典型故障更隐蔽：召回到了相似但不相关的段落，模型顺着这段编，答案读起来很顺，细节却全错。处理办法是强制给出引用出处、设置拒答阈值，对高风险问题宁可回「没找到依据」也别硬答，再配合定期人工抽检。

1. 建一个兜底出口两条路都要有「答不了就明说不知道」的机制，禁止模型硬编；验证方式是拿一批无答案问题测，看是否老实拒答。
2. 高风险结论交人复核合规、医疗、财务这类场景，系统只做初筛和引用整理，最终结论由人签字；验证方式是抽查复核记录是否留痕。
3. 规则与检索混用确定性的硬条件先用规则过滤，剩下的模糊问题再交给 RAG 组织语言；验证方式是分别统计两条路径各自的答对率。
4. 固定测试集再谈调参把问题与正确答案整理成测试集，每次改动都跑同一套；没有测试集的 RAG 项目，调参基本靠感觉。

选型清单：按任务反推该用哪条路

不要先选技术，先问三个问题：答案要不要逐字对得上依据；知识更新频率多高；答错了的代价多大。这三个问题的答案基本就决定了路线，剩下的只是工程细节。

• 三条都偏严（要可追溯、更新慢、错了代价大）：用规则，或者规则过滤加检索辅助的混合方案；
• 只有更新频率高：用 RAG，把精力放在文档治理和召回评估上；
• 要求都要兼顾：规则先做硬性过滤和合规拦截，RAG 负责把结果组织成人话；
• 团队没有维护文档的习惯：先解决资料整理，谈架构为时过早。

落地顺序上，建议先整理测试集，再小范围跑检索看召回情况，最后把明显属于确定性判断的部分抽出来写成规则。这样即使 RAG 效果不及预期，你也已经攒下了一套可复用的评测资料，不会白干。至于具体模型的检索表现、各家 API 的收费标准，到站内页面核对当时的数字，别用旧印象下判断。