评估一个Agent系统时，跑出来的成功率高达95%，上线后却频繁出错，这种离线与线上的巨大落差，往往不是模型能力问题，而是数据泄露在作怪。数据泄露指的是评估过程中，Agent通过某种不合规的途径获取了本不该知道的测试信息，导致指标被人为抬高。这类问题隐蔽性强，单看分数完全察觉不到，必须主动去检查。下面从三个最常见的泄露来源入手，逐一分析排查方法。
测试集与训练语料重叠：最基础也最致命的泄露
这是所有泄露场景中最常见的一种。如果你的Agent是基于某个基座模型做微调的，而微调数据和测试集中存在大量相同或高度相似的样本，那么评估结果测出来的其实是模型的记忆能力，而非泛化能力。模型在测试集上背答案，分数自然虚高。实践中这个问题出现的频率远超想象，很多团队从网上爬取数据集后直接随机切分，却没有做任何去重处理。
更隐蔽的情况是近似重复。两条数据字面不同，但只是改了个日期、换了个实体名，问题模板完全一样。这种数据用精确匹配是查不出来的，必须用指纹去重或向量相似度检测。常用的做法是对每条样本计算MinHash或SimHash指纹，聚类后人工抽查相似簇，确认是否属于变体重复。如果Agent涉及检索增强，还要检查知识库文档和测试问题之间的重叠程度。
下面是一段用向量相似度做重叠检测的示例代码：
from sentence_transformers import SentenceTransformer, util
model = SentenceTransformer("all-MiniLM-L6-v2")
train_emb = model.encode(train_questions, convert_to_tensor=True)
test_emb = model.encode(test_questions, convert_to_tensor=True)
# 计算测试集与训练集的余弦相似度矩阵
sim_matrix = util.cos_sim(test_emb, train_emb)
max_scores = sim_matrix.max(dim=1).values
# 相似度超过0.9的样本视为疑似泄露
suspect = [q for q, s in zip(test_questions, max_scores.tolist()) if s > 0.9]
print(f"疑似泄露样本数: {len(suspect)}")发现重叠后的处理方式要谨慎。不建议简单地从训练集中删除，因为可能破坏数据分布；更稳妥的做法是把高度相似的样本整体从测试集移出，或者单独建立一个去重后的干净子集，用它重新跑一次评估。如果干净子集上的分数明显下降，比如从90%掉到60%，那就说明之前的指标确实被记忆效应撑起来了。
检索链路泄露：知识库里藏着测试答案
对于带RAG能力的Agent，有一种泄露极其容易被忽视：测试集的构建来源和知识库的构建来源是同一批文档，甚至测试问题就是从知识库段落中直接生成的。这种情况下，评估测的是检索命中率，而不是Agent的真实问答能力。比如你用某产品手册生成了500条问答对做测试，同时这份手册又完整地放在了向量库里，那么只要检索不出大错，答案就在上下文里摆着，指标必然好看。
检查这类问题，第一步是梳理数据血缘。搞清楚测试集的每一部分来自哪些原始文档，再核对这些文档是否进入了知识库。如果确实存在重叠，需要从知识库中剥离对应内容，或者至少保证测试问题对应的答案原文不在库内。注意这里考量的粒度是文档级别而不只是句子级别，因为即使原文被改写过，只要核心事实还在库里，Agent依然可以拼凑出答案。
第二种链路泄露发生在工具调用环节。Agent的某些工具可能返回了过量的信息，比如一个订单查询工具把标准答案字段原样吐给了Agent，评估脚本再对比输出时就水到渠成。要审计每个工具的返回结构，确认工具没有因为评估需要而被特殊改造过。有一种典型的坏习惯：为了让评估跑通，团队临时给某个工具加了个返回真实标注答案的后门分支，上线前忘了去掉。这类问题可以通过代码审查加运行时日志比对来发现。
下面展示如何用日志审计上下文注入内容，检查测试答案是否出现在了传给模型的上下文中：
import json
def audit_context_leak(log_file, answer_field):
leaked_cases = []
with open(log_file) as f:
for line in f:
record = json.loads(line)
context = " ".join(record["retrieved_chunks"])
gold_answer = record[answer_field]
# 粗筛：答案原文出现在上下文中
if gold_answer in context:
leaked_cases.append(record["case_id"])
return leaked_cases
leaked = audit_context_leak("eval_run.log", "gold_answer")
print(f"上下文包含标准答案的用例: {leaked}")这段脚本只是一个粗筛，因为标准答案往往是人工提炼的短句，而上下文里可能只是恰好包含相同的事实表述。所以命中之后还需要人工复核命中比例。一个实用的判断标准是：随机抽样五十条答案命中上下文的用例，看这些用例的答题正确率与未命中用例的差异。如果差距悬殊，基本可以断定检索链路存在泄露。
评估流程自身的缺陷：提示词污染与盲测集缺失
除了数据层面的泄露，评估流程本身也可能制造虚高。一个高频错误是评估提示词里不小心混入了线索。比如在构造评估样本时，模板写成了「请回答以下问题，参考信息：标准答案是XXX」，而拼接逻辑在某些边界条件下没有把这个字段过滤掉，导致模型直接抄答案。这类bug往往出现在格式化字符串拼接、多字段模板渲染的场景中，排查方法是固定几条样本，把最终发给模型的完整prompt打印出来逐字检查。
另一个流程缺陷是评估集曾经参与过任何形式的调优。很多团队会经历这样的循环：看评估集上的badcase，改提示词，再跑评估，再改。反复多轮之后，评估集实际上参与了优化过程，你对它的每一条样本都了如指掌，提示词不知不觉就过拟合到了这个集合上。此时指标虽然反映的是提示词对该集合的拟合程度，但对外宣称为Agent能力，就属于一种流程性泄露。
应对方案是建立隔离的盲测集。做法如下：
- 三层集合划分：开发集用于日常调试，验证集用于对比方案，盲测集只在做最终验收时跑一次，任何人不得根据盲测集结果调整系统
- 定期轮换：盲测集使用一段时间后要补充新样本，因为旧样本会随着时间推移被间接「记住」
- 人工抽样复核：每轮评估后随机抽取一定比例的通过用例做人工审查，确认通过理由成立，防止评估脚本本身误判
还可以引入对抗性校验：让一个独立的检查模型判断每条测试样本「答案是否可以从系统可见的输入中直接推断出来」，推断成本越低的用例，泄露嫌疑越大。这种方法不能完全替代人工，但可以在几千条样本的规模上快速定位高风险区域，大幅缩小人工检查范围。
建立持续性的泄露检查机制
数据泄露检查不应该是上线前的一次性动作，而应该嵌入到评估流水线里，每次跑评估自动执行。一个最小可行的检查清单包括：训练数据与测试集的相似度扫描、知识库与测试问题来源的血缘核对、上下文注入内容的答案命中审计、评估prompt的模板渲染抽查。每项检查都输出量化的风险指标，比如疑似泄露样本占比，一旦超过阈值就阻断评估流程并告警。
同时要养成一个习惯：任何时候发现离线指标和线上表现差距超过十个百分点，第一反应不是怀疑模型，而是怀疑评估体系。从泄露角度重新审视一遍数据链路，往往能找到答案。评估指标的价值在于指导决策，一个被泄露污染的指标比没有指标更危险，因为它会让你在错误的方向上自信地前进。把泄露检查做成基础设施，才能让每一次评估结果都值得信赖。