1. 知识范围
知识点讲解确定系统回答哪些问题，不回答哪些问题。
老师板书
知识范围
知识库
知识范围是 RAG 的地图边界。
先用人话讲明白
知识范围定义 RAG 知识库应该包含什么、不包含什么。范围清楚，系统才知道能回答哪些问题，什么时候拒答。
类比可以把它理解成给模型配一间资料室，并规定它必须带着资料回答。
为什么要学规定 AI 能回答和不能回答什么。
把关键词拆开看
- 主题边界：覆盖哪些产品、功能、流程。
- 版本边界：资料对应哪个版本和时间。
- 责任边界：哪些问题交给人工或其他系统。
入门版理解：确定系统回答哪些问题，不回答哪些问题。
适用范围和边界
1. 优先原则：先满足前提，再谈使用
在实际工程里，任何概念都不能脱离场景硬套。学习「知识范围」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。
- 先看它服务的专业判断是不是「知识库」：规定 AI 能回答和不能回答什么。
- 知识库资料有来源、版本、更新时间、适用范围和负责人。
- 知道用户问题应命中哪些资料，也知道没有资料时必须拒答。
2. 引入边界：同时满足这些条件，才值得推进
只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。
- 当「知识范围」能改变设备说明书、错误码表、排障 SOP、版本发布说明、已知问题库里的设计、评测或风险控制动作时，才值得进入方案。
- 适合企业知识、产品文档、错误码、FAQ、SOP、发布说明等可追溯问答。
- 适合事实会变化、需要引用来源、需要按版本和权限区分的场景。
3. 反向边界：这些情况先停下来
专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。
- 范围过宽会增加错误回答风险。
- 范围过窄会导致用户常问问题检索不到。
- 不要把未经审核的聊天记录、论坛经验和过期文档直接进知识库。
- 不要只靠向量检索处理型号、版本号、错误码这类精确信息。
- 切片错误会把条件和答案拆开，导致模型拿到半截依据。
4. 上线前判断：能回答这些问题再落地
- 能给每条答案追到具体文档、段落、版本和适用范围。
- 能覆盖有答案、无答案、冲突资料、旧版本资料、精确错误码等评测样本。
- 现场追问：答案里的每个关键结论能不能追到资料、版本和适用范围？
架构师总结：知识范围是 RAG 的地图边界。 对架构师来说，知识范围 不是一个要背的名词，而是一把判断尺：先看前提是否成立，再看收益是否大于复杂度，最后看失败时有没有证据、兜底和责任人。
通用例子：先脱离技术看懂它
公司制度问答只覆盖内部制度，不应该回答法律咨询或医疗建议。
这个例子要看见的重点：规定 AI 能回答和不能回答什么。 所以例子不是为了记故事，而是为了训练你在新场景里做同类判断。
投影 / Android 实战推演
- 业务推演：投影 Android 业务里，知识库可以覆盖投屏协议、设备手册、App FAQ、错误码、版本发布说明；不应回答非官方刷机、硬件拆修、赔偿承诺等超范围问题。
- 你要补的证据：围绕「知识库」列出数据、文档、日志、用户反馈或人工标注，避免只凭感觉判断。
- 可交付物：沉淀 知识范围、资料等级、切片策略、检索评测和更新机制。，让同事能照着复用，而不是只听你口头解释。
- 验收指标：至少选一个质量指标、一个效率指标、一个风险指标；比如正确率/一次解决率、定位耗时/追问轮次、误导用户率/转人工率。
- 迁移能力：同一套思路也能迁移到客服、测试、研发效率、运营分析和产品决策，不局限于投影业务。
老师会这样检查你是否真会了
- 你能不能用一句人话解释「知识范围」，并说出它解决的是「知识库」里的什么问题？
- 你能不能举一个适用场景和一个不适用场景，并说明边界来自数据、流程、风险还是权限？
- 你能不能把它落到一个真实小任务：输入是什么、输出是什么、验收指标是什么、失败时谁兜底？
- 老师追问：答案里的每个关键结论能不能追到资料、版本和适用范围？
- 练习产物：为你们的 AI 知识库写“可回答/不可回答/需转人工”三张清单。
精通标准：知识范围是 RAG 的地图边界。 能精通的人，不是能背定义，而是能把它迁移到一个新业务里，写出判断表、数据要求、风险边界和落地动作。
业务判断方法
范围越清楚，评测和治理越容易。