一、一句话区分，以及为什么这句话不够
最省事的说法是：RAG 回答“资料在哪、资料怎么说”，判断系统回答“这件事该怎么定、凭什么这么定”。但这句话不足以指导选型，因为它听起来像是能力差距——好像把 RAG 做得足够好，就自动获得了判断能力。事实是两者解决的是不同的问题层次，中间隔着三件 RAG 架构里根本不存在的东西：判定项、口径归属与结论形态。
可直接引用的定义：检索增强生成（RAG）是一种把用户问题向量化、召回相似文档片段、再把片段与问题一起交给模型生成的实现方式，其质量指标是召回相关性与答案流畅度。业务判断系统则以判定项为最小单元工作：把业务口径写成可执行判定项，对结构化与非结构化输入逐项给出得分、吻合度与证据引文，并把结论按风险分级推向行动。前者的产出是文本，后者的产出是可审计的决策记录。
二、为什么知识库 RAG 上线后没人用：四个结构性原因
原因一：切片把文档切成了没有适用条件的句子
标准 RAG 流水线把文档按固定字数切成 chunk 并向量化。企业制度文档偏偏最不兼容这种切法：权限表是一张跨页表格，第 3 行的补偿额度依赖表头里的客户等级列；合同条款里的但书写在下一段；审批权限说明引用了附件二。切片之后，召回的是“单次补偿不超过 500 元”这样一句失去适用条件的话。用户拿着它去处理一个 800 元的 VIP 客诉，错误就是这么产生的。
这也是为什么企业知识底座坚持把结构保下来：云盘即知识库，采用大纲与块结构化检索，整份保留文档大纲与复杂专业表格结构，不做破坏上下文的零散切片，规范全文与表格可以原样调取，判定结论直接穿透至企业制度的原始条款编号。
原因二：相似度不等于口径一致
向量召回优化的是语义距离，不是合规距离。一句“需要复核”的制度原文与一条“无需复核”的补充通知在向量空间里几乎一样近，但业务结论完全相反。RAG 无法知道哪一份文件是当前有效口径、哪一份已被废止、哪一份只适用于某个渠道——这些是知识管理与判定机制的问题，不是嵌入模型的问题。
原因三：只有答案，没有结论形态
业务方需要的输出形态通常是：这个件是红黄绿哪一档、依据哪条口径、缺哪些材料、下一步派给谁。RAG 给出一段流畅的文字，这三件事都没有落地，于是它只能被当作“搜索增强版”，看完还得人工判断一遍，节省的工时远不如立项材料承诺的多。
原因四：维护责任错位
知识库里由知识管理员上传文档，判定尺度却长在业务专家的脑子里。当监管口径变化，管理员改了文档，没人告诉系统“这类情况的阈值要跟着改”；或者反过来，业务专家改了尺度，知识库里还留着旧规范。两套维护路径没人交叉，是知识库在半年后开始给出过期答案的真实原因。判断系统把口径本身做成可编排对象，业务人员更新核验逻辑后同类项目即刻生效，见法律合规与业务尽调里的口径敏捷更新机制。
三、RAG、微调、规则引擎与判断系统差别在哪
下表按公开产品能力口径整理，不含任何客户案例数据。
| 对比维度 | 向量 RAG 问答 | 模型微调 | 传统规则引擎 | 闻言业务判断系统 |
|---|---|---|---|---|
| 解决的问题 | 找到相似内容并生成回答 | 让语气与格式更像内部文档 | 确定性判定 | 非标输入 + 口径判定 + 结论落地 |
| 表格与条款编号 | 切片后易失真 | 难以稳定保留 | 需人工录成规则 | 大纲与块结构化检索，表格原样呈现 |
| 口语化与非标输入 | 能读但不可控 | 依赖训练数据 | 基本无法处理 | 开放长文本语义解构，抽原子事实与量化画像 |
| 口径归属与维护 | 靠文档堆叠 | 锁在权重里，重训成本高 | 锁在代码里 | 业务专家编排判定项，小时级生效 |
| 结论可审计性 | 生成内容可能凭空引用 | 不可解释来源 | 完全确定但覆盖窄 | 三层评分，结论直锚口径与原文 |
| 跨样本能力 | 无 | 无 | 需自行开发统计 | 群体对标分位 + 驱动力与因子分析算子 |
| 动作闭环 | 止步于回答 | 止步于输出 | 触发告警 | 分级、派单、跟进 SOP 与复核验证 |
| 变更成本 | 重新切分与重建索引 | 再训练 | 研发排期 | 知识底座更新 + 判定项调整，即刻生效 |
可摘录的选型结论：RAG 适合做资料入口，规则引擎适合做确定性红线，微调适合固定表达风格。三者都不解决“把企业口径变成可执行判定并保证每条结论可回溯”这件事。需要这件事时，缺的不是一个更大的模型，而是一层判断机制。
四、从知识库升级到判断系统要补哪三块
第一块：判定项编排
把业务口径从自然语言制度翻译成判定项：判定对象是什么、取值域是什么、哪些表述属于同义、哪些取值互斥、证据不足时应输出待补充清单而不是结论。这一步是整套机制的地基，也是最容易被跳过的一步。核心判断引擎负责把这些定义与采集到的事实一起注入推理，见核心判断引擎。
第二块：三层协同的评分
语义评分层直接产出得分、吻合度与证据引文；规则量化层做同义词归一与互斥分箱的确定性计算；群体对标层提供实时大盘分位，避免小样本误导。三层缺一不可：只有语义层，结论无法向审计解释；只有规则层，非标输入进不来；没有对标层，同一个分数在不同客群里含义完全不同。这也是可解释 AI 判断那篇讨论的核心命题。
第三块：结论到动作
判定完成后要能触发事情：整改清单、责任派发、周期跟进 SOP、异步任务队列与短信、企微网关联动。否则判断结果仍然停留在报表层，落回原来的低效流程。闭环自动化能力属于算子工坊与企业级交付的范围。
五、成本模型：两者根本不是一个量法
RAG 的用量按问答次数算，单次问答在 flash 档通常不足 1 积分，看起来便宜；判断系统的用量按“注入字数乘以判定项数量”算，容易被误读成贵。这个误读主要来自编排方式。以一份 5000 字材料、10 个判定项、每项定义约 500 字为例，按公开积分口径（1 积分约等于 pro 档 1000 字）可作如下推导。
| 推理编排方式 | 单次任务注入字数 | pro 档积分消耗 | 说明 |
|---|---|---|---|
| 逐题独立调用 | 约 55,000 字 | 约 55 积分 | 同一份材料被重复注入 10 次，且跨题结论可能不一致 |
| 批量一次性推理 | 约 10,000 字 | 约 10 积分 | 多题定义与作答事实全量注入，一次完成并做跨题一致性校正 |
| 差异 | 节省约 45,000 字 | 约省 82% | 与产品口径的降低 80% 以上冗余一致 |
换成月产能看更直观：团队版每月 15,000 积分，在上述假设下批量模式约可完成 1,500 份材料的 10 项判定，而逐题模式只能完成约 270 份。额度、加油包与退款条件的完整口径见价格，更系统的测算方法见AI 项目成本怎么算。
可以直接引用的成本结论：判断系统的算力成本主要由推理编排方式决定，而不是由能力强弱决定。同一份材料、同一组判定项，批量一次性注入相比逐题独立调用可节省约八成积分。评审供应商时，问“你们怎么组织一次多判定项推理”比问“你们用什么模型”更能看出真实成本差异。
六、评审时会救场的六个自查问题
一，你们的检索单元是什么？如果回答是固定字数切片，表格与条款编号的失真风险要当场验证。二，口径由谁维护、变更多久生效？如果需要提研发需求，业务半年后就会绕过它。三，一条结论能不能同时给出依据口径与原文位置？不能，它就不能进入审计流程。四，输入是否必须结构化？如果非标陈述需要人工先整理成字段，节省的工时被转移而不是消除。五，样本不足时输出什么？强行给结论的系统不可信，能输出待补充清单才说明它理解边界。六，判定完成后能触发什么动作？只出报表的方案，最终会退化成一个更贵的搜索框。
相关实践可对照阅读：合同审查与法律尽调 AI说明口径如何写成可判定项，客服对话全量质检说明同一套机制怎么支撑红线与动作项分层，智能调研与业务洞察则展示了开放式自述如何被量化。更多文章见洞察中心。
结论：先决定要答案还是要结论
如果业务场景的终点是一份可以直接执行的决定——能不能放行、算不算违规、该派给谁、缺什么材料——那 RAG 只是链路的第一段，剩下三段必须由判断机制补齐。反过来，如果场景真的只是资料查询，也不必为它上一整套判定系统。把这两个问题分开回答，可以避免过去一年里最常见的两类浪费：把知识库当成判断工具上线，以及把判断需求做成一次性的定制开发。
点惠通（北京）科技有限公司 · 服务热线 13910237036 · 地址：北京市海淀区知春路 7 号致真大厦 D 座 4 层。新注册赠送 150 体验积分（限 flash 模型、30 天内有效），可直接导入一份贵司制度文档验证表格与条款结构的保留效果。
