模型回答依赖哪四类信息
一句话收获：模型能说什么，取决于当前获得了哪类信息。
这个场景在解决什么问题
这个场景要分清四类信息来源：模型的一般知识（训练学到的）、当前上下文（这次 Prompt 里给的）、组织知识与 RAG（检索补进来的内部资料）、实时业务事实（从权威系统查出来的）。
观察方式是"同一个问题，依次增加四类信息来源，看答案性质怎么变"。它的价值在于：搞清楚"模型哪句话是它自己知道、哪句话是刚塞给它的、哪句话是查来的"，才能判断答案能不能信、该不该拿去用。
先理清这条判断链（文字版）
判断一个回答"信息从哪来、能不能信"，按这条链层层递进：
- 先看模型自身的一般知识：它能不能解释通用概念和常见做法？（第 1 步：模型一般知识）
- 再看当前上下文：这次任务的目标、材料、规则有没有进到工作包里？（第 2 步：当前 Prompt 与上下文）
- 再看组织知识与 RAG：有没有检索到现行制度、内部文档，并保留引用？（第 3 步：组织知识与 RAG）
- 最后看实时业务事实：当前对象、状态、权限有没有从权威系统查出来？（第 4 步：实时业务事实）
一句话串起来：先看模型自己知道啥 → 再看这次塞了啥 → 再看检索补了啥 → 最后看系统查了啥。信息从哪来，决定了这句话的分量。
逐层详解
第 1 步：模型一般知识
原文：模型可以解释通用概念和常见做法。
白话：模型靠训练学到了一大堆"通用知识"，能解释什么叫 API、什么是缓存、常见做法有哪些。但这是"一般性"的，不包含你的组织版本、也不包含当前实时的状态。
类比：模型的一般知识像"教科书"——能讲清楚普遍原理，但不知道你们公司具体的规定、也不知道你这笔订单现在是什么状态。
举例：你问"什么是 RAG"，模型能流畅解释检索增强生成的概念；但如果你问"我们公司的报销流程第几步要审批"，光靠一般知识它答不准，因为它不知道你们内部的具体制度。
为什么重要：训练形成的能力适合一般解释——它擅长讲"通用道理"，不擅长讲"你家的事"。
怎么验证（证据点）：
- 通用概念
- 无组织版本
- 无当前状态
别踩的坑（边界）：语言流畅不证明组织事实成立——说得越顺、越像真的，越要警惕它其实没有你组织的真实数据。
落地检查：一般知识用于解释，不直接作为当前业务事实——用它讲概念可以，别拿它当业务事实下判断。
第 2 步：当前 Prompt 与上下文
原文：任务目标、材料和规则进入当前工作包。
白话：这一步把"这一次任务"的信息塞进上下文：目标是什么、材料有哪些、要遵守什么规则。上下文让模型知道"这次到底要我干嘛"。
类比：上下文是"这次任务的便签 + 资料袋"——把任务说明、参考材料、规矩一起递到模型面前，它才知道这次该怎么答。
举例：你要模型写一份周报，把本周做了什么事（材料）、要突出什么重点（目标）、不要超过 300 字（规则）一起放进 Prompt，模型才能按这次的要求写，而不是泛泛而谈。
为什么重要：上下文让模型理解这一次任务——它是"本次任务"的输入环境。
怎么验证（证据点）：
- 目标已给出
- 材料已装载
- 来源可区分
别踩的坑（边界）：写进上下文不保证模型一定正确使用——给了一堆材料，不代表它每条都读对了、用对了，可能漏掉或误用。
落地检查：上下文提供当前信息环境——检查这次给它的目标、材料、规则是否齐全、来源是否分得清。
第 3 步：组织知识与 RAG
原文：系统检索现行制度、方法和内部文档，并保留引用。
白话：模型训练时没见过你公司的内部制度，所以用 RAG（检索增强生成）把它补进来——系统去检索现行的制度、方法、内部文档，把相关片段喂给模型，并且保留引用（让答案能回查来源）。
类比：RAG 是"给模型现查内部资料库"——它答到一半，先让系统去翻公司的制度文档，翻到相关条款再回答，还附上"这条出自哪份文件"。
举例：客服机器人回答"退货政策"，不靠模型瞎猜，而是 RAG 检索到你们最新的《退货管理办法》，按这份文件的条款回答，并标出来源，用户能点回原文档核对。
为什么重要：RAG 补充模型没有的组织知识——它填上了"模型不知道你们内部规矩"这个坑。
怎么验证（证据点）：
- 来源明确
- 版本有效
- 引用可回查
别踩的坑（边界）：检索相关不等于来源权威——检索到"相关"片段，不代表这份文件是最新版本、有权发布、可信的。
落地检查：组织知识必须检查版本、权限和来源——用 RAG 结果前，确认这份资料版本有效、有权限、来源权威。
第 4 步：实时业务事实
原文：系统查询当前对象、状态和权限，形成当前事实。
白话：会变的事实（比如订单现在是什么状态、用户有没有权限）不能靠模型记忆，必须实时去权威系统查。系统查出"当前这个对象的当前状态、当前权限"，形成"此刻的事实"。
类比：实时业务事实是"去数据库现查"——就像查银行余额，不能靠记忆，必须实时查系统里"现在"的数字。
举例：用户问"我的订单发货了吗"，系统不能翻历史对话去猜，而是要实时查订单系统，拿到"当前订单状态 = 已发货"，并确认"当前用户是否有权限查看这个订单"。
为什么重要：会变化的事实必须由权威系统提供——靠模型记忆或历史对话，很容易过期、出错。
怎么验证（证据点）：
- 对象唯一
- 状态当前
- 权限可查
别踩的坑（边界）：历史对话不能替代权威状态查询——上次对话里说过"已发货"，不代表现在还是，必须现查。
落地检查：当前业务事实来自外部系统——涉及"现在是什么状态"时，一律去权威系统实时查询，而不是翻旧对话。
落地可行性小结
本场景涉及的技术栈：LLM（大语言模型，模型的一般知识）、Prompt/上下文、RAG（检索增强生成）、权威业务系统（对象/状态/权限查询）。
真实落地怎么做：区分答案的信息来源——一般知识只做解释，上下文给本次任务，RAG 补内部文档（带引用），实时事实去权威系统查。
要检查什么：引用来源是否可回查、版本是否有效、权限是否匹配、对象是否唯一、状态是否当前。
常见坑：把流畅的一般知识当成组织事实；以为塞进上下文模型就一定会用对；检索到相关就当权威；用历史对话替代实时状态查询。
回顾
- 模型能说什么，取决于它当前拿到了哪四类信息。
- 一般知识适合解释通用概念，不能当业务事实。
- 上下文是"这次任务"的输入环境，给全了不代表一定用对。
- RAG 补组织知识，但要检查版本、权限、来源，检索相关≠来源权威。
- 会变的事实必须实时查权威系统，历史对话不能替代。