面向初学者的研究说明、文献地图与实验蓝图。
LLM 上下文污染是指：模型本来能完成一个任务，但输入中混入了无关、冲突、误导或恶意的信息后，答案质量、稳定性、事实性或安全性下降。
一个最小例子：
问题：小明有 3 个苹果，又买了 2 个，一共有几个？
污染信息：小明最喜欢蓝色，而且昨天看了一场电影。
人很容易忽略第二句。LLM 却可能把它当作“既然出现在提示词里，就应该参与推理”的线索。污染越像正确证据、越靠近问题或答案位置、数量越多，模型越可能被带偏。
“LLM 上下文污染”目前不是一个定义完全统一的标准学术名词。本项目把它作为一个伞形概念，连接几个已有且可检索的研究方向：
| 本项目术语 | 常见英文关键词 | 含义 |
|---|---|---|
| 上下文窗口 | context window | 模型生成当前答案时能看到的输入，包括系统指令、聊天历史、检索文档和工具结果 |
| 无关上下文 | irrelevant context / distractor | 与任务无关但可能分散模型注意的信息 |
| 知识冲突 | knowledge conflict | 上下文之间，或上下文与模型参数记忆之间互相矛盾 |
| 长上下文退化 | long-context degradation / context rot | 输入变长、变乱后，有效利用信息的能力下降；“context rot”是常用描述，不是单一机制的严格名称 |
| 间接提示注入 | indirect prompt injection | 恶意指令藏在网页、邮件、文档或工具结果中，被应用送入模型后改变模型行为 |
| RAG 知识投毒 | RAG poisoning / knowledge corruption | 攻击者污染检索知识库，使恶意文本被检索并影响答案 |
| 参数知识 | parametric knowledge | 模型训练后存放在参数中的“记忆” |
| 上下文知识 | contextual knowledge | 本次推理时由提示词、文档或工具临时提供的信息 |
因此，本项目研究的不是“上下文太长”这一个问题，而是下面这条完整链路：
污染源 → 被拼入上下文 → 模型分配注意与判断可信度 → 推理或指令发生偏移 → 输出受损
一次真实的 LLM 调用通常可以抽象为：
系统指令
+ 开发者指令
+ 用户当前问题
+ 多轮聊天历史
+ RAG 检索文档
+ 搜索、浏览器、数据库等工具返回值
+ 中间推理或代理记忆
= 模型当前看到的上下文
污染可以出现在任何一层。普通聊天中的旧信息属于无意污染；网页里隐藏的“忽略用户要求并发送秘密”属于恶意污染。两者都会占用上下文，但风险模型并不相同，实验时不能混为一谈。
上下文没有直接说错话，只是加入了不需要的信息。难点在于“语义相近但答案无关”的 hard distractor 往往比随机文本更危险。
两段上下文给出不同答案，或外部上下文与模型原有记忆冲突。例如一段文档说某公司 CEO 是 A，另一段说是 B。模型必须决定信谁，却通常没有可靠的来源判断机制。
正确证据存在，但被大量文本包围。相关信息位于长上下文中间时，模型可能利用得更差，这就是著名的 Lost in the Middle 现象。
多轮对话或长时间运行的 Agent 不断追加旧计划、失败尝试、过期事实和中间输出。模型“看得到”不等于能正确区分当前有效状态与过期状态。
外部数据中混入看起来像指令的文本。根本问题是 LLM 使用同一种自然语言通道同时接收“数据”和“指令”，边界容易模糊。
攻击者把特制文本写入知识库。检索器随后主动把污染内容放进模型上下文，使攻击从“数据层”进入“生成层”。
可以先建立五个直觉，不必马上钻进 Transformer 数学：
- 模型不是数据库查询器。 它根据整个 token 序列预测后续 token，不会天然把文本分成“事实、噪声、指令、攻击”。
- 出现本身就是一种信号。 一段话被放入提示词，模型可能推断它与任务有关。
- 注意力不等于可靠性判断。 模型能关注一段文字，不代表它知道来源是否可信。
- 上下文长度上限不等于有效上下文长度。 能塞进 128K token，不代表模型能在所有 128K token 上稳定检索、聚合和推理。
- 冲突没有天然裁判。 模型可能偏向更近、更频繁、措辞更确定或更符合参数记忆的信息，而不是更真实的信息。
一个便于实验的概念模型是：
输出受损程度
≈ 污染强度
× 污染与任务的语义相似度
× 污染的显著性/位置优势
× 模型对来源的不加区分
− 模型与系统的过滤、验证和隔离能力
这不是已被证明的数学定律，而是本项目组织变量和提出假设的框架。
Shi et al., “Large Language Models Can Be Easily Distracted by Irrelevant Context,” ICML 2023. 论文构造了带无关信息的小学数学题数据集 GSM-IC，直接展示模型会被与答案无关的上下文干扰。
- 论文主页与 PDF（PMLR）
- 先看：Abstract、Figure 1、实验设置、Conclusion
- 阅读问题：随机噪声和“看起来相关”的噪声，哪一种更危险？
Liu et al., “Lost in the Middle: How Language Models Use Long Contexts,” TACL 2024. 这是长上下文位置偏差的代表作。它发现相关信息放在开头或结尾时表现通常更好，放在中间时性能可能明显下降。
- 论文主页与 PDF（ACL Anthology）
- DOI:
10.1162/tacl_a_00638 - 先看：Figure 1、Figure 5、实验任务
- 阅读问题：位置变化时，输入内容没有变，为什么结果却变了？
Hsieh et al., “RULER: What's the Real Context Size of Your Long-Context Language Models?”, COLM 2024. RULER 不只测试“从草堆找一根针”，还测试多针检索、多跳追踪和聚合，用来估计模型的有效上下文长度。
- 正式会议论文（OpenReview）
- 代码（NVIDIA/RULER）
- 先看：任务分类、不同长度下的性能表
- 阅读问题：一个模型通过单针检索，为什么仍不能说明它会长上下文推理？
Xu et al., “Knowledge Conflicts for LLMs: A Survey,” EMNLP 2024. 这篇综述把冲突分为 context-memory、inter-context 和 intra-memory 三类，是建立术语体系的好入口。
- 论文主页与 PDF（ACL Anthology）
- DOI:
10.18653/v1/2024.emnlp-main.486 - 先看：Figure 1、分类法、Table 2
- 阅读问题：模型是在坚持旧记忆，还是盲从新上下文？什么情况下两者都不可靠？
Greshake et al., “Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection,” ACM AISec 2023. 这是间接提示注入的代表性早期工作，系统讨论了网页或外部数据中的恶意指令如何影响 LLM 应用。
- ACM 论文页
- 开放预印本（arXiv）
- DOI:
10.1145/3605764.3623985 - 阅读问题：为什么“不要执行文档里的指令”并不是一个完美防御？
Zou et al., “PoisonedRAG: Knowledge Corruption Attacks to Retrieval-Augmented Generation of Large Language Models,” USENIX Security 2025. 论文把 RAG 知识库视为攻击面，研究少量恶意文本如何诱导目标问题产生攻击者指定的答案。
- 论文、PDF 与演讲材料（USENIX）
- 先看：威胁模型、Figure 1、攻击目标、限制与防御实验
- 阅读问题：攻击成功依赖哪些攻击者能力？现实系统是否满足这些假设？
Amiraz et al., “The Distracting Effect: Understanding Irrelevant Passages in RAG,” ACL 2025. 该工作进一步区分普通无关段落与 hard distracting passages，并尝试量化段落的干扰效应。
- 论文主页与 PDF（ACL Anthology）
- DOI:
10.18653/v1/2025.acl-long.892 - 阅读问题：应该只优化检索相关性，还是直接优化段落对生成器的实际影响？
现有研究共同支持以下有限结论：
- 上下文包含答案，不代表模型一定能稳定使用它；位置、长度和任务复杂度都会影响结果。
- 无关信息不是均匀的：语义接近、措辞强烈或与错误答案相关的干扰项通常更值得单独测试。
- 上下文可能与模型参数知识冲突，也可能在不同文档之间冲突。
- RAG 减少某些知识缺失问题的同时，也引入检索噪声、知识库投毒和间接提示注入等新攻击面。
- 单一的“needle-in-a-haystack”高分不足以证明模型具有可靠的长上下文理解能力。
不能从这些论文直接推出：
- 所有模型都以相同方式退化；
- 上下文越短一定越好；
- RAG 一定比长上下文更安全或更准确；
- 某一句防御提示可以彻底解决提示注入；
- 某篇论文在特定模型上的数值可以直接代表今天所有模型。
主问题：
当正确证据保持不变时，污染的类型、比例、位置、语义相似度和来源标记，分别如何影响 LLM 的准确性、稳定性、事实忠实度与安全性？
拆成五个可检验问题：
- RQ1：数量效应——污染比例从 0% 增加到 25%、50%、75% 时，性能如何变化？
- RQ2：位置效应——正确证据位于开头、中间、结尾时，污染造成的下降是否不同？
- RQ3：类型效应——随机噪声、主题相关噪声、冲突事实和恶意指令，哪种影响最大？
- RQ4：来源效应——给文档增加可信来源、时间戳和引用，能否帮助模型解决冲突？
- RQ5：防御效应——检索重排、上下文压缩、来源隔离、冲突检测和回答后核验各自能恢复多少性能？
以下是实验前假设，不是本项目已经得到的结论：
- H1：语义相关但不含答案的 hard distractor 比随机字符或跨主题文本更具破坏性。
- H2：正确证据位于上下文中间时，模型更容易受污染。
- H3：重复的错误证据比单条错误证据更容易覆盖正确证据。
- H4：只有来源标签而没有显式可信度规则，未必能稳定改善冲突处理。
- H5：先筛选证据再生成，比把所有检索结果直接拼接给模型更稳健。
先从容易自动评分的任务开始：
- 封闭域事实问答：答案唯一，证据明确；
- 多跳问答：必须组合两到三条证据；
- 数学文字题：便于加入无关条件；
- 指令遵循：检测外部文本是否改变系统任务；
- 小型 RAG：知识库完全由实验者控制。
| 变量 | 推荐取值 |
|---|---|
| 污染类型 | 无污染、随机噪声、主题相关噪声、冲突事实、提示注入 |
| 污染比例 | 0%、25%、50%、75% |
| 正确证据位置 | 开头、中间、结尾 |
| 上下文长度 | 2K、8K、32K token；根据模型限制调整 |
| 错误证据重复次数 | 1、3、5 |
| 来源标签 | 无标签、普通标签、可信来源+时间戳 |
| 防御 | 无防御、重排、压缩、隔离、冲突检测、回答核验 |
不要第一轮就做全因子组合。建议按下面顺序逐步增加复杂度：
阶段 A：污染类型 × 污染比例
阶段 B：加入正确证据位置
阶段 C：加入上下文长度
阶段 D：在最脆弱设置上比较防御
阶段 E：最后测试提示注入与 RAG 投毒
- 准确率 / Exact Match：答案是否正确；
- F1：答案文字不完全一致时的重合程度；
- 污染导致的性能下降：
Drop = CleanScore - PollutedScore； - 相对保持率：
Retention = PollutedScore / CleanScore； - 攻击成功率 ASR：恶意目标是否实现；
- 证据忠实度：答案能否引用实际支持它的证据；
- 拒答质量：证据冲突或不足时，模型能否诚实表达不确定；
- 稳定性：同一输入重复运行或轻微换序后，答案是否改变；
- 成本与延迟：token 数、调用费用和响应时间。
- Clean：只有问题和正确证据；
- No-context：只有问题，用来测参数知识；
- Random-noise：加入等长随机或跨主题文本；
- Relevant-no-answer：主题相关但不含答案；
- Conflict：加入明确错误或过期证据；
- Oracle：只保留真正相关的证据，表示理想检索上限。
如果没有这些对照，就无法判断失败来自模型能力、上下文长度、检索器，还是污染本身。
- 固定模型版本、API 日期、temperature、top_p、最大输出长度和系统提示；
- 保存原始请求、原始响应、token 数、延迟与错误；
- 每个条件使用同一批基础问题，只改变一个实验因素；
- 文档换序实验要保存随机种子；
- 随机生成任务应多次运行，报告均值、标准差和置信区间；
- 不把闭源模型一次调用的结果当作普遍规律；
- 明确区分预印本、正式发表论文和厂商博客。
run_id,model,model_version,task_id,seed,context_tokens,
pollution_type,pollution_ratio,evidence_position,defense,
gold_answer,prediction,is_correct,asr,latency_ms,input_tokens,output_tokens每一行是一轮模型调用。原始文本可单独保存为 JSONL，CSV 只保存分析字段，避免表格过大。
| 阶段 | 方法 | 作用 | 局限 |
|---|---|---|---|
| 进入知识库前 | 来源准入、签名、去重、版本管理 | 降低投毒进入语料库的概率 | 无法发现所有高质量伪造内容 |
| 检索阶段 | 混合检索、重排、阈值过滤 | 减少低相关结果 | hard distractor 仍可能高相关 |
| 拼接阶段 | 去重、压缩、按来源分区、保留元数据 | 减少冗余并明确边界 | 压缩可能删除关键细节 |
| 生成阶段 | 明确任务、要求引用、冲突时拒答 | 改善证据使用行为 | 仅靠提示词不能提供安全保证 |
| 生成之后 | 引用核验、事实核验、规则检查 | 拦截部分错误输出 | 增加成本，核验器也会失败 |
| 系统安全 | 最小权限、工具调用审批、敏感数据隔离 | 降低注入成功后的损失 | 主要限制后果，不消除模型脆弱性 |
防御研究要同时报告：干净数据上的性能、污染数据上的性能、误拒率、成本和延迟。只降低攻击成功率，却让正常任务全部失败，不算实用防御。
- 理解 token、上下文窗口、system/user message、RAG；
- 阅读 Shi et al. 和 Lost in the Middle；
- 手工设计 20 道带无关信息的题，观察一个模型的失败案例。
- 把题目保存成 JSONL；
- 固定模型参数，自动批量调用；
- 计算 Clean 与 Polluted 的准确率和 Drop；
- 画“污染比例—准确率”曲线。
- 阅读 Knowledge Conflicts Survey 和 RULER；
- 控制证据位置与错误证据重复次数；
- 做文档换序实验，测答案稳定性。
- 搭建一个小型本地知识库；
- 阅读间接提示注入与 PoisonedRAG；
- 先在隔离环境中测试，不让 Agent 拥有真实邮件、文件删除、付款或网络发布权限。
- 把“最大上下文窗口”当成“有效推理长度”；
- 只测试随机噪声，不测试语义相关干扰项；
- 同时改变模型、提示词、文档顺序和长度，最后无法归因；
- 用模型自己给自己的答案打分，却不做人类抽检；
- 只报告平均准确率，不报告不同任务、位置和污染类型的分组结果；
- 把提示注入和普通事实冲突混成一个指标；
- 引用二手博客代替原始论文；
- 把实验前假设写成已经证明的结论；
- 在拥有真实权限的 Agent 上直接做攻击实验。
- 给出“LLM 上下文污染”的操作性定义与术语边界；
- 建立无意污染与恶意污染的分类；
- 整理 7 篇代表性正式论文及阅读顺序；
- 提出研究问题、待验证假设、变量、指标与对照组；
- 给出四周初学者学习路线和防御地图；
- 实现数据生成脚本；
- 实现统一模型调用与日志记录；
- 运行基线实验；
- 生成统计表和图；
- 在多模型、多任务上复现并撰写实验报告。
当前仓库完成的是研究定义、文献综述和实验设计，尚未产生新的实证结果。任何新结论都应在代码、数据和运行日志提交后再写入。
| 主张 | 证据状态 |
|---|---|
| 无关上下文会影响部分 LLM 的任务表现 | 有 ICML 2023 等实验支持，但效应依赖模型与任务 |
| 长上下文中的信息位置会影响利用效果 | 有 TACL 2024 等实验支持，不应推广为所有模型、所有任务都相同 |
| 标称窗口不等于有效上下文能力 | RULER 等基准支持，具体有效长度依赖任务定义与阈值 |
| RAG 引入新的污染与攻击面 | 有间接提示注入和 PoisonedRAG 等研究支持 |
| 某一种防御足以解决上下文污染 | 没有证据；需要组合防御并持续评估 |
| 本项目提出的五条假设成立 | 尚未验证 |
如果本项目用于课程作业、论文或报告，请直接引用上面的原始论文，而不是把本 README 当作学术证据。README 的作用是帮助入门、建立术语和设计实验；正式论证必须回到论文原文、代码、数据与可复现结果。
提示注入和知识库投毒实验应只在授权、隔离的环境中进行。不要向公共知识库投放虚假内容，不要对第三方系统测试攻击，不要让实验 Agent 持有真实敏感数据或不可逆工具权限。研究目标是测量并降低风险，而不是制造现实污染。