导语：当大模型上下文窗口迈入百万 Token 级别，企业很容易产生一种错觉：既然整本制度手册、项目资料和历史邮件都能一次性塞进上下文，知识库是否可以不再检索，直接“全文投喂”？答案是否定的。长上下文扩大了模型可读取的信息量，却没有自动解决权限控制、信息定位、内容时效和敏感数据隔离问题。相反，投喂范围越大，原本分散在不同系统中的机密信息越可能被集中暴露。🔐
一、百万 Token 不等于无限且可靠的记忆
上下文窗口表示模型单次能够接收的内容上限，并不代表模型能同等准确地利用其中每一段信息。长上下文研究发现，关键信息位于输入中部时，模型表现可能低于信息位于开头或结尾时，这通常被称为“中间遗失”现象，详见相关研究。因此，把大量文档简单拼接进提示词，不仅会引入无关噪声，还可能让真正重要的条款被淹没。
对企业而言，百万 Token 更适合处理经过筛选后的长材料，例如合同全集分析、跨季度项目复盘和大型技术档案梳理，而不应成为取消检索层的理由。上下文窗口是推理资源，不是权限边界，更不是知识治理系统。
二、检索架构应从“找得多”转向“取必要”
传统 RAG 常采用文档切分、向量召回、重排序和生成回答的链路。进入长上下文时代后，切片可以适当增大，并保留章节、表格及上下文关系，但仍需坚持“最小必要检索”。建议将架构调整为：
- 查询理解：识别用户意图、部门、任务范围及敏感级别。
- 权限预过滤：在向量检索之前，根据用户身份、用户组、数据域和文档 ACL 缩小候选集合。
- 混合召回：组合关键词、向量、元数据及知识图谱检索，避免语义相似度成为唯一依据。
- 重排序与去重：优先保留权威、最新且与问题直接相关的内容。
- 上下文组装：按主题和来源组织材料，而不是机械拼接搜索结果。
- 输出检查：执行引用校验、敏感字段检测和回答范围约束。
对于需要跨文档发现关系的问题，可以探索图结构检索。Microsoft Research 对 GraphRAG 的介绍显示，这类方法通过知识图谱与分层摘要增强对大型私有数据集的整体理解，但它仍应与身份鉴权和安全过滤配合使用，参见GraphRAG 说明。🧭
三、敏感信息为何更容易过度暴露
长上下文应用的危险不一定来自模型“突破权限”，更多时候来自检索服务本身拥有过大的读取权限。例如，索引程序以超级账号抓取全部站点，却没有把源系统的文档权限同步到索引；普通员工虽然打不开原文件，却可能通过问答获得摘要、关键数字甚至人员名单。
另一个风险是权限粒度错位。源文档可能按文件夹、文档、段落甚至字段授权，而知识库只记录“内部可见”。一旦检索到包含薪酬、客户联系方式、并购计划或安全配置的切片，模型就可能在回答中重新组合这些信息，使零散数据变得更容易理解和传播。
安全原则应当是：模型能够读取的内容，不能超过当前用户在源系统中实际有权访问的内容；生成结果也不能因为摘要、推断或跨文档拼接而扩大信息可见范围。
四、权限控制要贯穿完整链路
企业应把授权判断放在检索阶段，而不是仅依靠提示词要求模型“不要泄密”。索引中需要保存文档所有者、允许访问的用户或用户组、密级、地域、保留期限和来源系统等元数据，并在每次查询时根据登录身份执行过滤。Azure AI Search 的文档级访问控制说明也强调，应从数据摄取到查询执行持续实施细粒度权限。
权限同步还要考虑撤权延迟。员工调岗、项目结束或外部协作者离场后，源系统权限可能已经改变，但搜索索引仍保留旧 ACL。可通过事件驱动同步、定期全量核验和高敏文档短周期刷新降低时间差，并为权限异常设置自动下架机制。⚠️
五、建立可执行的防护清单
- 数据分区：按公开、内部、机密和高度机密建立独立索引或安全域。
- 最小权限：采集账号只读取获批站点，避免使用跨租户或全库权限。
- 字段脱敏：身份证件、账号、密钥、私人联系方式等内容在入库前处理。
- 检索审计：记录查询人、召回文档、权限判断、模型版本和最终引用。
- 防提示注入：将文档内容视为不可信输入，禁止其覆盖系统规则或调用权限。
- 限制外发：对复制、下载、邮件发送和第三方插件调用设置额外控制。
- 持续测试：使用越权提问、模糊身份、跨部门组合查询等场景开展红队验证。
总结
百万 Token 带来的真正价值，是让模型能够在经过授权和筛选的材料中完成更完整的分析，而不是把整个企业知识库无差别装入提示词。面向新阶段，企业应保留并强化检索层，将身份、ACL、数据分级、重排序、审计和输出防护连接成闭环。只有坚持“先授权、再检索、后生成、全程留痕”，长上下文才能成为知识生产力，而不是敏感信息的放大器。✅
