如何为AI系统设置检索边界以防止数据泄露？（权威控制层详解）

如果你正在构建处理真实数据的AI系统，本文探讨了如何：

• 防止跨租户数据泄露
• 定义哪些数据源允许进入上下文
• 在运行时强制执行检索隔离
• 将检索策略变更视为受发布流程管控的变更

If you are building AI systems that touch real data, this article explores how to:

• Prevent cross-tenant data leakage
• Define which data sources are allowed into the context
• Enforce retrieval isolation at runtime
• Treat retrieval policy changes as release-governed changes

这并非关于如何实现更好的搜索，而是关于控制系统被允许知道什么。

This is not about achieving better search. It's about controlling what your system is allowed to know.

大多数关于检索的讨论都在解决错误的问题。生产故障始于更早的一层：当系统接纳了它无权使用的证据时。这就是为什么检索边界运行时契约，用于管理特定请求允许哪些证据进入上下文的规则，定义了数据范围、环境范围、权威来源等权威规则。至关重要。

Most discussions about retrieval are solving the wrong problem. Production failures start one layer earlier: when the system admits evidence it has no authority to use. That is why retrieval boundaries matter.

检索并非让模型听起来博学多闻的原因，而是决定哪些证据在推理路径中可被采纳的控制面。

Retrieval is not what makes the model sound informed. It is the control surface that determines which evidence is admissible inside the reasoning path.

在《AI系统的深度思考模型》中，这属于Memory层，通过Control进行治理，并由Governance所约束。如果这些边界薄弱，检索质量的提升只是表面功夫，系统仍然基于错误的世界模型进行推理。

In The Heavy Thought Model for AI Systems, this sits in the Memory layer, governed through Control and enclosed by Governance. If those boundaries are weak, retrieval quality improvements are cosmetic. The system still reasons from the wrong world model.

核心模式

检索边界运行时契约，用于管理特定请求允许哪些证据进入上下文的规则，定义了数据范围、环境范围、权威来源等权威规则。是管理特定请求允许哪些证据进入上下文的运行时契约。

A retrieval boundary is the runtime contract governing what evidence is allowed into context for a given request.

这个契约必须回答大多数检索讨论视为实现细节的问题：

• 谁的数据在范围内 (Whose data is in scope)
• 哪个环境在范围内 (Which environment is in scope)
• 哪个来源被视为权威 (Which source counts as authoritative)
• 证据必须有多新鲜 (How fresh the evidence must be)
• 哪些来源信息必须保留到最终答案中 (What provenance must survive into the answer)

That contract has to answer questions most retrieval discussions treat as implementation details:

• Whose data is in scope
• Which environment is in scope
• Which source counts as authoritative
• How fresh the evidence must be
• What provenance must survive into the answer

这些不是搜索质量的偏好，而是权威规则。模型不决定它被允许知道什么，检索边界运行时契约，用于管理特定请求允许哪些证据进入上下文的规则，定义了数据范围、环境范围、权威来源等权威规则。决定。

Those are not search-quality preferences. They are authority rules. The model does not decide what it is allowed to know. The retrieval boundary does.

这与《概率核心 / 确定性外壳》中论证的架构分离思想一致：模型之所以有用，正是因为它具有概率性，而这正是围绕它的证据边界不能是概率性的原因。

This is the same architectural split argued in Probabilistic Core / Deterministic Shell: the model is useful precisely because it is probabilistic, which is why the evidence boundary around it cannot be.

隔离先于相关性

大多数团队以错误的顺序优化检索。他们在明确权威边界之前，就追逐召回率、重排序和上下文组装。

Most teams optimize retrieval in the wrong order. They chase recall, reranking, and context assembly before they have made the authority boundary explicit.

这导致了一种常见的生产故障模式：

• 检索到的证据高度相关 (The retrieved evidence is highly relevant)
• 答案流畅 (The answer is fluent)
• 引用看起来干净 (The citations look clean)
• 但该来源从一开始就不应被采纳 (The source was never admissible in the first place)

That creates a familiar production failure shape:

• The retrieved evidence is highly relevant
• The answer is fluent
• The citations look clean
• The source was never admissible in the first place

来自错误租户的高度相关文档不是排序失误，而是具有更好余弦相似度的边界突破。这就是为什么隔离先于相关性。

A highly relevant document from the wrong tenant is not a ranking miss. It is a boundary breach with better cosine similarity. This is why isolation comes before relevance.

一个支持助手使用另一个租户的案例历史来回答计费问题。答案是正确的，但系统已被破坏。

A support copilot answers a billing question using another tenant's case history. The answer is correct. The system is compromised.

如果系统从错误的范围、错误的环境、错误的来源类别或错误的时间范围进行检索，答案看起来有据可依，但在架构上仍然是非法的。

If the system retrieves from the wrong scope, wrong environment, wrong source class, or wrong time horizon, the answer looks grounded while remaining architecturally illegitimate.

典型例子包括：

• 伪装成有用答案的跨租户泄露 (Cross-tenant leakage disguised as a helpful answer)
• 仅用于预发布环境的操作手册被当作生产策略 (Stage-only runbooks treated as production policy)
• 过时的策略因为排名好而击败了当前的真相来源 (Stale policy beating the current source of truth because it ranks well)
• 内部摘要的排名超过了它们本应总结的记录系统 (Internal summaries outranking the system of record they were meant to summarize)

Typical examples include:

• Cross-tenant leakage disguised as a helpful answer
• Stage-only runbooks treated as production policy
• Stale policy beating the current source of truth because it ranks well
• Internal summaries outranking the system of record they were meant to summarize

当这种情况发生时，系统不仅仅是回答得不好，而是在基于它不被允许知道的证据进行推理。

When that happens, the system is not merely answering badly. It is reasoning from evidence it was not allowed to know.

检索边界运行时契约，用于管理特定请求允许哪些证据进入上下文的规则，定义了数据范围、环境范围、权威来源等权威规则。契约

在设计索引、选择嵌入模型或调整重排序器之前，系统需要一个检索契约。该契约至少应包含以下字段：

Before index design, embedding choice, or reranker tuning, the system needs a retrieval contract. At minimum, the contract includes fields like these:

Contract field	What it governs	Failure if weak
identity scope	Which tenant, team, user, or role is allowed to be read	Cross-tenant leakage, over-broad retrieval
environment scope	Prod, stage, internal, or draft separation	Wrong-environment answers, unsafe operational drift
source authority	Which systems are admissible and which outrank	Summaries or drafts beat the real source of truth
freshness	How current evidence must be for this answer	Stale policy, expired guidance, outdated state
provenance	What origin/version signals must survive	Unverifiable claims with decorative citations
answer-class route	Whether retrieval belongs in this path at all	Retrieval used where tools, refusal, or abstention were required

最后一个字段比团队通常承认的更重要。有些请求属于检索，有些属于工具调用，有些属于拒绝回答，有些则属于无需广泛检索的稳定内部规则。如果检索默认进入路径而非根据契约，系统将开始积累它永远不需要的上下文，并最终以过度自信从噪声中进行推理。

That last field matters more than teams admit. Some requests belong to retrieval. Some belong to tools. Some belong to refusal. Some belong to stable internal rules without broad retrieval at all. If retrieval enters the path by default instead of by contract, the system starts accumulating context it never needed and eventually reasons from noise with excessive confidence.

核心规则很简单：来自错误范围的相关证据仍然是无效证据。检索边界运行时契约，用于管理特定请求允许哪些证据进入上下文的规则，定义了数据范围、环境范围、权威来源等权威规则。不是指导方针，而是执行层。如果系统无法阻止不允许的来源进入推理路径，那么它就没有边界。

The governing rule is simple: Relevant evidence from the wrong scope is still invalid evidence. A retrieval boundary is not a guideline. It is an enforcement layer. If the system cannot prevent disallowed sources from entering the reasoning path, it does not have a boundary.

与“事实依据失败”的区别

这些故障类别经常混淆，因此需要明确区分。

These failure classes collide constantly, so the distinction needs to stay explicit.

Failure class	What actually went wrong
retrieval-boundary-failure	The wrong evidence entered the reasoning path
grounding-failure	The right evidence was available, but the answer exceeded or contradicted it
evaluation-blind-spot	The release process never tested the case that later failed

在所有三种情况下，用户看到的都是一个症状：一个自信的错误答案。但操作员看到的是三种不同的故障。

The user sees one symptom in all three cases: a confident wrong answer. The operator sees three different failures.

如果系统引用了另一个租户的文档，问题不在于模型未能正确依据事实，而在于架构在生成甚至开始之前就接纳了被禁止的证据。这是一个不同的故障，需要一个不同的修复方案。

If the system cites another tenant's document, the problem is not that the model failed to ground itself properly. The problem is that the architecture admitted forbidden evidence before generation even started. That is a different failure. It requires a different fix.

示例：企业支持助手

以一个为企业客户解答账户和政策问题的支持助手为例。

Take a support copilot that answers account and policy questions for enterprise customers.

假设问题是：“支持团队能否为这位客户恢复生产环境中已删除的发票，适用什么审批路径？”

Suppose the question is: "Can support restore deleted invoices for this customer in production, and what approval path applies?"

这个问题需要检索，但不能从任何地方检索。

This question needs retrieval, but not from everywhere.

允许的证据路径

• 当前租户范围内的账户记录 (Current tenant-scoped account records)
• 当前生产支持策略 (Current production support policy)
• 当前用于发票恢复的生产操作手册 (Current production runbook for invoice restoration)
• 该租户的授权案例历史 (Authorized case history for that tenant)

• Current tenant-scoped account records
• Current production support policy
• Current production runbook for invoice restoration
• Authorized case history for that tenant

拒绝的证据路径

• 另一个租户的案例历史 (Another tenant's case history)
• 仅用于预发布环境的操作说明 (Stage-only operational notes)
• 尚未批准用于生产的内部草稿策略 (Internal draft policy not yet approved for production use)
• 已被取代的陈旧原始资料 (Stale source material that has already been superseded)

• Another tenant's case history
• Stage-only operational notes
• Internal draft policy not yet approved for production use
• Stale source material that has already been superseded

现在想象一下，返回的答案流畅、具体且有引用。它说支持可以立即恢复发票，并引用了一份内部操作说明。该说明是真实的，但答案仍然是错误的。

Now imagine the answer comes back fluent, specific, and cited. It says support can restore the invoices immediately, and it cites an internal operational note. The note is real. The answer is still wrong.

支持团队现在根据系统本不应采纳的证据，采取了它在生产环境中从未被授权采取的行动。追踪记录显示了一个有效的引用，但没有显示该来源是可采纳的。为什么？因为被引用的说明是仅用于预发布环境的指南，它从未被允许进入该请求的生产支持推理路径。

Support now takes an action it was never authorized to take in production, based on evidence the system was never allowed to admit. The trace shows a valid citation. It does not show that the source was admissible. Why? Because the cited note was stage-only guidance. It was never admissible inside the production support reasoning path for that request.

这个事件无法通过提示词调优来修复。正确的应对是架构性的：

• 修正检索边界运行时契约，用于管理特定请求允许哪些证据进入上下文的规则，定义了数据范围、环境范围、权威来源等权威规则。 (Correct the retrieval boundary)
• 添加拒绝路径的评估用例 (Add a denied-path evaluation case)
• 确保追踪记录记录了为什么该来源被认为是可采纳的 (Ensure the trace records why the source was considered admissible)
• 阻止等效的检索策略变更在没有证据的情况下发布 (Block equivalent retrieval policy changes from shipping without evidence)

Nothing about that incident is fixed by prompt tuning. The right response is architectural:

• Correct the retrieval boundary
• Add a denied-path evaluation case
• Ensure the trace records why the source was considered admissible
• Block equivalent retrieval policy changes from shipping without evidence

这就是检索作为相关性工程与检索作为权威工程之间的实际区别。

This is the practical difference between retrieval as relevance engineering and retrieval as authority engineering.

检索变更是发布变更

检索变更是发布变更。这不是一个调优表面。改变检索策略，就改变了系统被允许知道什么。如果你没有评估它，你就发布了一个未经测试的系统。

Retrieval changes are release changes. This is not a tuning surface. Change the retrieval policy, and you change what the system is allowed to know. If you did not evaluate it, you shipped an untested system.

大多数系统失败不是因为检索不准确，而是因为检索从一开始就没有被治理。变更表面包括：

• 身份或ACL过滤器变更 (Identity or ACL filter changes)
• 来源权重变更 (Source weighting changes)
• 新鲜度逻辑变更 (Freshness logic changes)
• 来源包含或排除规则变更 (Source-inclusion or source-exclusion rules)
• 可能通过提升错误来源类别来覆盖权威姿态的重排序器变更 (Reranker changes that can override authority posture by surfacing the wrong source class)

Most systems do not fail because retrieval is inaccurate. They fail because retrieval was never governed in the first place. Change surfaces include:

• Identity or ACL filter changes
• Source weighting changes
• Freshness logic changes
• Source-inclusion or source-exclusion rules
• Reranker changes that can override authority posture by surfacing the wrong source class

大多数团队默默地做出这些更改，然后调试输出而不是系统本身。这就是检索通道直接连接到《评估门禁：无需猜测地发布AI系统》的地方。

Most teams make those changes silently. Then they debug outputs instead of the system. This is where the retrieval lane connects directly to Evaluation Gates.

在这些变更发布之前，发布系统必须要求提供证据，例如：

• 跨租户拒绝路径用例 (Cross-tenant denied-path cases)
• 错误环境拒绝路径用例 (Wrong-environment denied-path cases)
• 陈旧与当前来源选择用例 (Stale-vs-current source selection cases)
• 主要来源优于摘要的用例 (Primary-source-over-summary cases)
• 被引用声明的来源证明 (Provenance assertions for cited claims)

Before those changes ship, the release system must require evidence such as:

• Cross-tenant denied-path cases
• Wrong-environment denied-path cases

常见问题（FAQ）

AI系统检索边界运行时契约，用于管理特定请求允许哪些证据进入上下文的规则，定义了数据范围、环境范围、权威来源等权威规则。具体指什么？

检索边界运行时契约，用于管理特定请求允许哪些证据进入上下文的规则，定义了数据范围、环境范围、权威来源等权威规则。是运行时契约，用于控制哪些证据（如数据源、租户信息）可进入AI推理路径，防止跨租户泄漏AI系统在检索过程中，错误地访问并使用另一个租户的数据来回答问题，导致数据隔离失效的安全问题。和未授权访问，确保系统仅基于允许的数据进行推理。

为什么说隔离比相关性更重要？

因为即使检索到高度相关的文档，若来自错误租户或未授权来源，仍属边界突破。优先建立严格的检索隔离能防止数据泄露，而优化相关性应在隔离之后进行。

如何管理检索策略的变更？

检索策略变更（如允许的数据源、权威规则）应视为受发布流程管控的变更，需通过正式流程审批和部署，确保边界的一致性和安全性。