long_context_methods_20260417_deep_research

Z3 全文↑ Z2 条目

方法论库 · 引用级 · none

本页是 <code>contexts/methodology/long_context_methods_20260417_deep_research.md</code> 的逐字投影（仅隐私清洗，零改写）。

时点提示：本页是仓内文件 contexts/methodology/long_context_methods_20260417_deep_research.md 的逐字投影（仅做隐私清洗：仓库根绝对路径→相对路径、家目录→~/；除此零改写）。若源文件后续有修订，以仓内真源为准。

报告元数据（frontmatter）

name: long_context_methods_20260417_deep_research
description: RAG vs 长上下文决策方法
domain: infra
consumption:
  surface: none
  trigger: ""
  consumer: orchestrator
status: library
promoted_to: null

突破 LLM Context Window 限制：长文本处理技术方案深度调研

调研日期：2026-04-17
数据截止：2026 年 4 月（覆盖 2024–2026 发表的论文与工程实践）
调研方法：WebSearch + WebFetch，系统覆盖学术论文（arXiv/ACL/NeurIPS/ICLR）、官方文档、工程博客

1. TL;DR：2026 年"突破 context window"的真实技术格局

长 context 模型确实有用，但不是银弹。 Gemini 2.5 Pro（1M tokens）、Claude Sonnet 4（1M tokens）、GPT-4.1（1M tokens）在 Needle-in-a-Haystack 类测试上接近完美（>99.7% 召回），但在需要多步推理、跨段落整合的任务上性能显著下降：LongBench v2 最强模型（Gemini 2.5 Pro）只达到 63.3% 准确率，而人类专家在同等约束下也只有 53.7%。

"Context Rot"是已被实测确认的真实现象。 Chroma 研究团队对 18 个模型（含 GPT-4.1、Claude 4、Gemini 2.5）的实验表明，即便任务复杂度不变，性能随 context 增长持续下降，且这种退化独立于内容质量。即使用白空间替换无关 token，性能仍退化 13.9%–85%。

RAG 与长 context 并非非此即彼。 2025 年工程共识：数据量超出 context 限制、数据动态变化、或成本敏感，用 RAG；静态长文档、多章节深度整合，用长 context（配合 prompt caching 降成本）。最优实践是混合路由（Self-Route 方案），按查询类型动态选择。

分治式方案（MapReduce、分层摘要）在工程上最成熟，适合批量提取任务，但信息压缩不可避免，不适合需要精确细节的任务。记忆增强方案（MemGPT/Letta、Mem0）适合对话型长期记忆，但不擅长单次深度阅读任务。

对于高密度结构化内容（信息论/控制论）和启发式论证内容（科研方法论），目前无专门工业工具，但可以组合方案：schema-driven extraction + GraphRAG + 长 context 精读，形成多轮流水线。

2. 方法论地图

2.1 长 context 模型直接输入（Brute-force Long Context）

核心思想：将完整文档放入支持 1M+ tokens 的模型，一次性推理，无需额外工程架构。

代表能力：

Gemini 2.5 Pro：1M tokens（官方宣布 2M tokens 版本在计划中）
Claude Sonnet 4 / Opus 4.6：1M tokens（2025 年 8 月开放）
GPT-4.1：1M tokens

实测效果：

Benchmark	最强模型	得分	说明
LongBench v2	Gemini-2.5-Pro	63.3%（w/ CoT）	含推理链；Claude 3.5 Sonnet 仅 41.0%
BABILong 多事实推理	GPT-4	有效利用约 10% 的 128K window	多跳推理急剧退化
Context Rot 实验	18 模型	随长度持续退化	GPT 模型幻觉率较高，Claude 模型弃答率较高
LongBench Pro (2026)	Gemini-2.5-Pro	73.42	GPT-5 72.61，Claude-4-Sonnet 69.87

局限：

"Lost in the Middle"效应已大量实验证实（Liu et al. 2023，TACL 2024）：关键信息在上下文中间时性能最差
BABILong 结论：即使 frontier 模型，单事实任务 4K tokens 内表现好，多事实推理快速退化
Context Rot：即便相关 token 不变，context 长度本身就是"认知税"
成本高：1M tokens 处理一本书约需 $0.5–$5（依据模型计费）

何时适用：静态长文档的全局理解、需要跨章节整合的单次任务、预算允许且不需要实时响应的场景。

来源：

LongBench v2：https://arxiv.org/abs/2412.15204 / https://longbench2.github.io/
BABILong：https://arxiv.org/abs/2406.10149，NeurIPS 2024
Context Rot：https://www.trychroma.com/research/context-rot
Lost in the Middle：https://arxiv.org/abs/2307.03172，TACL 2024

2.2 分治式处理（MapReduce 系列）

核心思想：将长文档分块，每块独立处理（map），再聚合结果（reduce）。本质是用并行化换信息损耗的取舍。

主要变体：

MapReduce Summarization（LangChain/LlamaIndex 标准实现）

Map 阶段：每个 chunk 独立摘要
Reduce 阶段：所有摘要合并为最终摘要
优点：可并行、可扩展、实现成熟
缺点：reduce 阶段本身可能超出 context；跨 chunk 信息无法聚合
工程参考：https://python.langchain.com/docs/how_to/summarize_map_reduce/

LLM×MapReduce（ACL 2025）
三阶段改进：Map → Collapse → Reduce。Collapse 阶段解决多 chunk 摘要本身超出 context 的问题，通过迭代压缩控制 reduce 阶段输入。

论文：https://aclanthology.org/2025.acl-long.1341.pdf

Chain of Density（CoD，EMNLP 2023 NewSum Workshop）
迭代式密度压缩：初始摘要稀疏，每轮迭代加入 1–3 个未提及的重要实体，同时保持字数不变。人类偏好研究（100 篇 CNN/DailyMail 文章）表明，适度密集的摘要比稀疏摘要更受欢迎，但过度压缩后可读性下降。

论文：https://arxiv.org/abs/2309.04269

Refine Chain（LlamaIndex）
非并行方案：顺序处理每个 chunk，每次将前一个摘要 + 当前 chunk 传入模型，生成更新的摘要。内存占用低，但无法并行，且错误会累积。

参考：https://developers.llamaindex.ai/python/examples/low_level/response_synthesis/

实测效果：无统一 benchmark；工程实践中 MapReduce 为批量文档摘要的工业标准，CoD 更适合需要高密度摘要的场景（如新闻压缩）。

局限：信息在压缩时不可避免地丢失；对"精确细节"需求高的任务（如需要引用原文的法律分析）不适用。

何时适用：批量长文档摘要提取、成本敏感的离线处理流水线、对全局理解要求高但对细节精度要求低的场景。

2.3 记忆增强（Memory-Augmented Agents）

核心思想：模拟操作系统的虚拟内存机制，将超出 context 的信息持久化到外存，按需检索。

MemGPT / Letta（最具代表性的架构论文）

论文：MemGPT: Towards LLMs as Operating Systems（arXiv:2310.08560）

架构（模拟 OS 层次内存）：

Main Context（RAM）：固定大小的 prompt，含系统指令 + 工作记忆 + 最近消息 FIFO 队列
Recall Storage：可检索的对话历史数据库
Archival Storage：向量化长期记忆，语义检索

LLM 被训练成能主动调用"内存管理函数"（写入、检索、压缩）来决定信息流向。

2024–2025 演进：MemGPT 已重组为 Letta（2024 年 9 月）。Letta v1 放弃了 heartbeat 机制，转向更现代的纯原生推理 + 直接 assistant 消息生成模式。

何时适用：长期对话型 agent、需要跨 session 记忆的个人助手、多 session 状态追踪。不适合单次深度阅读任务。

来源：https://arxiv.org/abs/2310.08560；https://docs.letta.com/concepts/memgpt/

ReadAgent（Google DeepMind，ICML 2024）

论文：A Human-Inspired Reading Agent with Gist Memory of Very Long Contexts（arXiv:2402.09727）

机制（三步流程）：

Episode Pagination：LLM 自主决定文本的"自然段落边界"（何时停下来，模拟人类阅读换页）
Memory Gisting：每页压缩为简短 gist memory，保留主旨
Interactive Look-up：给定任务时，先看所有 gist，判断需要哪几页，再取回原文

实测效果：

在 QuALITY、NarrativeQA、QMSum 三个长文档理解任务上均超越 baseline
有效 context 长度扩展 3.5–20 倍

局限：gist 压缩仍然损失信息；look-up 策略依赖 LLM 的判断准确性；对"公理推导"类需要精确原文的任务，gist 可能丢失关键符号表达。

何时适用：长篇叙事理解、问答任务、需要选择性精读的场景。

来源：https://arxiv.org/abs/2402.09727；https://read-agent.github.io/

Mem0 vs Zep（2025 生产级对比）

论文：Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory（arXiv:2504.19413）

核心发现：

Mem0 在 LLM-as-a-Judge 指标上比 OpenAI 提升 26%，延迟仅 1.44s，每轮对话仅用 7K tokens
Zep 在 LongMemEval 上得分 63.8%，比 Mem0 的 49.0% 高 15 分，但图构建延迟数小时，token 消耗 600K+（主要来自全量摘要缓存）
Mem0 适合生产延迟敏感场景；Zep 适合时序推理要求高且可接受离线预处理的场景

来源：https://arxiv.org/abs/2504.19413

2.4 Prompt / Token 压缩（KV Cache Compression）

核心思想：在推理前压缩输入，降低实际 context 长度，同时保留关键信息。

LLMLingua 系列（Microsoft，EMNLP 2023 / ACL 2024 / CoLM 2025）

三代演进：

LLMLingua（arXiv:2310.05736）：用小型 LM（Llama-7B）估算每个 token 的困惑度，保留高困惑度（信息量高）的 token。20x 压缩下性能损失约 1.5%（GSM8K）
LongLLMLingua（arXiv:2310.06839，ACL 2024）：针对长 context 场景的改进，NaturalQuestions 上性能提升 21.4%，同时减少约 4x tokens。GPT-3.5-Turbo 成本节省 94%（LooGLE benchmark）
LLMLingua-2：训练专门的压缩模型（而非依赖困惑度），14x 压缩下 GSM8K 性能持平；发表在 ACL 2024 Findings

局限：压缩比越高，信息损失越大；对需要精确原文引用的任务不适合；压缩本身有计算成本。

来源：https://llmlingua.com/；https://github.com/microsoft/LLMLingua

Activation Beacon（arXiv:2401.03462，ICLR 2025 入选）

机制：在 Transformer 每层直接压缩 Key-Value 激活（而非 soft prompt 中继），8x 压缩比下 KV cache 减少 8 倍，128K context 速度提升 2x，比 AutoCompressor 快 1.8x。

来源：https://arxiv.org/abs/2401.03462

H2O 与 StreamingLLM（KV Cache 选择性保留）

StreamingLLM：保留最初几个 token（attention sink）+ 最近 token，支持无限流式推理，但中间 token 的信息永久丢失
H2O（Heavy Hitter Oracle）：基于累积 attention score 动态识别"重要 token"，选择性保留 KV cache

这两类方法适合推理速度优化，不适合需要全文理解的任务。

2.5 RAG 与上下文检索改进

Anthropic Contextual Retrieval（2024 年 9 月）

机制：在生成 embedding 前，用 LLM 为每个 chunk 添加独立的上下文说明（chunk 所在的文档背景、相关实体等）。

实测效果：

仅用 Contextual Embeddings：top-20 检索失败率从 5.7% 降至 3.7%（-35%）
Contextual Embeddings + Contextual BM25 混合：失败率降至 2.9%（-49%）

Late Chunking（2024）

机制：先对整个文档生成 token-level embeddings，再按边界划分 chunk 并池化，保留跨 chunk 的上下文信息。

实测效果：对包含代词/指示词引用的文档，检索准确率提升 10–12%。

GraphRAG（Microsoft Research，arXiv:2404.16130）

机制：在标准 RAG 基础上构建知识图谱，节点为实体，边为关系。检索时支持图遍历，捕获多跳关系。

适用场景：针对"全局理解"类查询（如"文档中的核心论点是什么"），在 1M token 规模的数据集上显著优于传统 RAG（comprehensiveness 和 diversity 指标）。对"精确查找"类查询优势不明显。

RAG vs 长 context 的 2025 实用决策框架：

基于 arXiv:2407.16833（"Self-Route"论文）和 arXiv:2501.01880：

场景	推荐方案	依据
数据量超出 context 限制（>200K tokens）	RAG	物理限制
数据动态更新（每日/每周）	RAG	增量索引比全量重载高效
成本敏感、批量处理	RAG	LC 成本显著更高
静态长文档、需要跨章节整合	Long Context	LC 平均性能优于 RAG
对话型任务、开放域问答	RAG	RAG 在对话场景占优
知识库 <200K tokens、低延迟	Long Context + Prompt Caching	省去检索基础设施
复杂关系推理、多跳查询	GraphRAG	图遍历捕获关系链
任意场景、成本与性能平衡	Self-Route（混合路由）	按查询自动选择

来源：

Contextual Retrieval：https://www.datacamp.com/tutorial/contextual-retrieval-anthropic
GraphRAG：https://arxiv.org/abs/2404.16130；https://www.microsoft.com/en-us/research/project/graphrag/
Self-Route：https://arxiv.org/abs/2407.16833
Long Context vs RAG Revisit：https://arxiv.org/abs/2501.01880

2.6 架构性方案（超越单 LLM）

Skeleton-of-Thought（SoT，ICLR 2024）

机制：先让 LLM 生成 3–10 条答案骨架，再对每条骨架并行扩展，最后合并。速度提升最高 2.39x，同时在知识型问答中质量也有提升。

局限：适合结构可预测的问题；不适合需要顺序推理的任务。
来源：https://arxiv.org/pdf/2307.15337（ICLR 2024）

Schema-driven Extraction

先定义目标 schema（JSON/Pydantic），再逐段填充。2024 年各主要模型（OpenAI、Anthropic、Gemini）均已原生支持结构化输出（Structured Outputs）。

关键研究：PARSE 框架（arXiv:2510.08623），在结构化网页数据提取任务上提升 64.7% 准确率。Simon Willison 实测报告（2025 年 2 月）：https://simonwillison.net/2025/Feb/28/llm-schemas/

Multi-agent Reading（分工阅读）

概念：不同 agent 分别阅读不同章节或扮演不同角色（reader/critic/synthesizer），通过对话协作整合。AutoGen 提供基础框架。

目前工程成熟度：原型级，无大规模 benchmark 验证；适合定制化深度分析任务。

RecurrentGPT（arXiv:2305.13304）

机制：用自然语言实现 LSTM 类似的循环机制，每步生成一段文本并更新"语言工作记忆"（短期）和磁盘存储（长期），支持任意长度生成。

定位：主要适合长文本生成（小说写作），而非信息提取任务。

3. 长 context 模型 vs 架构性方案的实测对比

核心 Benchmark 数据汇总

LongBench v2（2024 年 12 月，arXiv:2412.15204）

设计：503 道高难度多选题，context 8K–2M tokens，六大任务类（单文档 QA、多文档 QA、长 ICL、对话理解、代码仓库理解、长结构化数据理解）
人类专家（15分钟限制）：53.7%
Gemini-2.5-Pro（CoT）：63.3%
GPT-4o（2024-11 版，CoT）：46.0%（2024-08 版 50.1%）
Claude 3.5 Sonnet（CoT）：41.0%（200K context）
o1-preview：57.7%（推理计算时间换准确率）
关键发现：推理增强（CoT、o1 类）比扩大 context 更有效；Gemini 系列在长 context 上领先

HELMET（Princeton，ICLR 2025）

设计：7 类应用任务（RAG召回、长文档QA、段落重排序、引用生成、摘要、ICL），覆盖 51 个模型，最长 128K tokens
关键发现：

NIAH 类合成任务与真实下游任务相关性低（不能用 NIAH 成绩预测实际能力）
GPT-4o 在召回和引用生成上更强；Gemini 在段落重排序和长文档 QA 上更强
开源模型在 ICL 任务上有时超越闭源模型
所有 frontier 模型在引用生成（citation）和段落重排序（re-ranking）任务上随 context 增长显著退化

来源：https://princeton-nlp.github.io/HELMET/；ICLR 2025

BABILong（NeurIPS 2024，arXiv:2406.10149）

设计：20 个推理任务（事实链、归纳、演绎、计数、列表处理），context 从 0 到 1M tokens
关键发现：

主流 LLM 有效利用约 10–20% 的 context
单事实问题：多数模型在 4K tokens 以内表现良好
多跳推理（需要 2–3 个事实）：性能在 4K tokens 以上急剧退化
RAG 方法在单事实 QA 上约 60% 准确率，独立于 context 长度
循环记忆变换器（Recurrent Memory Transformer）在 5000 万 tokens 下仍能求解，但需要专门微调

Context Length Alone Hurts LLM Performance（arXiv:2510.05381，EMNLP 2025 Findings）

即使 100% 召回到了正确信息，输入长度增加也导致性能下降 13.9%–85%
用白空间替换无关 token：性能依然退化
结论：context 长度本身是独立的性能损耗因子

Context Rot（Chroma Research，2025–2026）

18 个模型（含 GPT-4.1、Claude 4、Gemini 2.5）实验
Claude 系列：不确定时弃答率较高（相对保守）
GPT 系列：不确定时幻觉率较高
位置效应：关键信息放在 context 开头比放在结尾效果更好；结尾比中间好（U 形偏置）

对比结论

当前格局下，三类方案各有适用场景：

长 context 模型：适合静态文档全局理解，1M tokens 已可处理大多数书籍；但多跳推理、精确细节提取时性能不可靠
分治式（MapReduce/ReadAgent）：适合批量提取、成本控制；信息有损，不适合精确引用
RAG/GraphRAG：适合动态数据、大规模知识库、多跳关系查询；单次深度整合能力弱于长 context

2025 年主流实践：对于需要高质量深度理解的任务，长 context + 推理增强（CoT/extended thinking）是最优组合；对于生产部署，混合路由（Self-Route 类）在成本与性能间取得最优平衡。

4. 针对高密度结构化内容（信息论/控制论）的最优路径

内容特点分析

Shannon 的 Mathematical Theory of Communication 和 Wiener 的 Cybernetics 具有以下结构特征：

形式化程度高：定义 → 定理 → 推论，有严格依赖关系
符号密集：大量数学符号、公式，自然语言仅作为"胶水"
逻辑依赖树深：理解第 N 个定理需要理解之前 M 个定义
内容密度高：每段信息量密度远高于普通叙述文本

推荐方案：三阶段流水线

阶段一：结构提取（Schema-driven Extraction）

先定义提取 schema，再逐章节填充：

{
  "type": "Theorem/Definition/Lemma/Corollary",
  "name": "字符串",
  "formal_statement": "原文公式或命题",
  "informal_description": "自然语言解释",
  "prerequisites": ["依赖的概念/定理名"],
  "page_range": "章节引用",
  "significance": "在整体理论中的作用"
}

工具：OpenAI / Anthropic 原生 Structured Outputs，或配合 Instructor 库（https://python.useinstructor.com/）

阶段二：依赖图构建（GraphRAG / Knowledge Graph）

将提取出的条目构建为有向图，节点为定理/定义，边为"依赖"关系。这允许：

回答"推导 X 需要哪些前置条件"
按拓扑序列理解整本书
精确定位某个结论的完整证明链

工具：Microsoft GraphRAG（https://github.com/microsoft/graphrag）或轻量的 NetworkX + 自定义 LLM 提取。

参考工程实践：ontology-guided KG construction（ACL 2024，https://aclanthology.org/2024.kallm-1.8.pdf）

阶段三：精读验证（Long Context）

对于依赖图中的关键节点，用长 context 模型精读相关章节（通常 10–50 页），验证提取结果的准确性，补充缺失的隐式假设。

这里 ReadAgent 的 gist + look-up 机制很适合：先生成全书 gist，再对关键证明环节取回原文。

注意事项：

数学符号在 token 化过程中易产生歧义，建议保留 LaTeX 原文而非转为自然语言
对于涉及连续函数、测度论等概念的部分，模型容易在"形式正确但逻辑有误"的地方产生幻觉，需要人工验证关键推导
依赖图的准确性很大程度上取决于第一阶段的提取质量，建议对核心章节做双轮提取并交叉验证

工程评估：目前无专门针对信息论/控制论文本的 benchmark，但 2024 年 Lean 形式化数学数据集（覆盖抽象代数、量子物理）已开始尝试 LLM 辅助定理依赖图提取，可供参考（arXiv:2505.23754 DeepTheorem 的方法论部分）。

5. 针对启发式论证内容（科研方法论）的最优路径

内容特点分析

Popper 的 Logic of Scientific Discovery、Kuhn 的 Structure of Scientific Revolutions、Adler 的 How to Read a Book、Booth 等的 Craft of Research 具有以下特征：

论证结构复杂：论断 → 例证 → 反例 → 修正，逻辑链呈网状而非树状
内容模糊性高：同一个 heuristic 可能在书中不同地方有不同侧面的表述
主张的层次性：核心主张（如 Kuhn 的"范式转移"）需要通过多章节的例子和论证才能理解
Actionable heuristics 往往隐含：需要读者主动提炼，而非直接陈述

推荐方案：两阶段提炼

阶段一：论证结构提取（Argument Mapping）

将全书分为若干 chunk（500–1000 tokens），对每个 chunk 提取：

- 核心主张（Claim）：作者在此处主张什么？
- 支撑理由（Warrant）：用什么支撑这个主张？
- 限制条件（Qualifier）：在什么情况下这个主张不成立？
- 隐含假设（Backing）：这个论证依赖哪些未明说的假设？

这个框架来自 Toulmin 论证模型，已有 LLM 实现：ARGUS（https://www.mdpi.com/2079-8954/13/12/1079，2025）和 HD-LoA 提示策略（ACL 2024，https://aclanthology.org/2024.acl-long.647/）。

阶段二：跨章节整合与 Heuristic 提炼

在所有 chunk 的论证结构基础上，用长 context 模型进行跨章节整合，提炼可操作的 heuristic 列表：

Heuristic: <一句话行动指导>
来源: <书名 + 章节>
原文支撑: <1–2 句原文引用>
适用场景: <什么情况下使用>
反例/限制: <什么情况下不适用>

这种结构化输出已被工程实践验证（arXiv:2510.16551 的产品评论 actionable insights 提取，方法论可迁移）。

关键挑战：

Popper/Kuhn 这类文本的核心洞察往往在"论证过程"中，而非结论句。纯粹的摘要方法会遗漏这类 embedded insights
不同 heuristic 之间可能存在张力甚至矛盾（如 Popper 的证伪主义 vs Kuhn 的范式内保护核），提炼时需要明确标注这类张力，而非试图统一
Adler/Booth 类"关于阅读/写作方法论的书"有额外的元层次复杂性：它们描述的是如何处理其他文本，提炼时需要区分"对象层"和"元层"的 heuristic

建议流程：

先用 ReadAgent 的 gist 方法生成全书摘要图（每章 1 个 gist）
用长 context 模型（Claude/Gemini）一次性读入所有 gist + 全书目录，生成初步 heuristic 草稿
对每条 heuristic 回溯原文验证（ReadAgent look-up 步骤），补充原文引用
人工审查张力/矛盾点，手动标注

6. 2025–2026 年关键趋势

趋势一：Reasoning-first 而非 Context-first

LongBench v2 的最重要结论：o1-preview（推理增强）得分 57.7%，超过人类专家（53.7%），而 GPT-4o 直接推理只有 50.1%。这说明在面对长 context 挑战时，增加推理计算时间比扩大 context window 更有效。2026 年的格局预计是：1M context + extended thinking 的组合，而非单纯依赖更大的 context 窗口。

来源：https://arxiv.org/abs/2412.15204；https://arxiv.org/html/2503.04723

趋势二：Context Rot 成为工程约束，而非可选优化项

Chroma 的实验和 arXiv:2510.05381 的发现表明，context 长度本身是不可消除的性能损耗因子。这意味着在系统设计层面，不能假设"更长的 context = 更好的结果"。工程实践需要为每个任务类型测试最优 context 长度，而非一味追求最长 context。

趋势三：RAG 从"替代方案"演变为"互补系统"

2025 年的实践共识是：RAG 与长 context 不是竞争关系，而是互补。Self-Route（arXiv:2407.16833）和 LaRA benchmark（SIGIR 2025 workshop）都在推动"智能路由"：按查询类型自动选择最优处理路径，而非硬编码使用某一种方案。预计 2026 年这类混合路由系统将成为企业 AI 应用的标配架构。

来源：https://arxiv.org/abs/2407.16833；https://sites.google.com/view/sigir25-lc-vs-rag/

趋势四：从"提取"到"理解图谱"的范式转变

GraphRAG（Microsoft）和 2024–2025 年的知识图谱研究（LLM-empowered KG construction survey，arXiv:2510.20345）表明，单纯的文本检索正在被"关系感知检索"替代。对于知识密集型任务，未来的标准流水线将是：LLM 提取 + KG 构建 + 图遍历检索 + 长 context 精读。

趋势五：长 context 模型的"输出"挑战正受到关注

arXiv:2503.04723（"Shifting Long-Context Research from Input to Output"）指出：研究界过于关注长 context 输入，而忽视了长输出质量的问题。LongProc（Princeton）开始评估长结构化输出生成能力。这预示着 2026 年的研究重点将从"能否读长文"转向"能否写出连贯的长文分析"。

来源：https://arxiv.org/pdf/2503.04723；https://pli.princeton.edu/blog/2025/long-input-long-output-holistic-long-context-evaluation-helmet-and-longproc

参考文献索引

方法	论文/来源	年份	会议/平台
Lost in the Middle	https://arxiv.org/abs/2307.03172	2023	TACL 2024
LongBench v2	https://arxiv.org/abs/2412.15204	2024	arXiv
BABILong	https://arxiv.org/abs/2406.10149	2024	NeurIPS 2024
HELMET	https://arxiv.org/abs/2410.02694	2024	ICLR 2025
Context Length Hurts	https://arxiv.org/abs/2510.05381	2025	EMNLP 2025 Findings
Context Rot	https://www.trychroma.com/research/context-rot	2025–2026	Chroma Research
ReadAgent	https://arxiv.org/abs/2402.09727	2024	ICML 2024
MemGPT	https://arxiv.org/abs/2310.08560	2023	—
Mem0	https://arxiv.org/abs/2504.19413	2025	arXiv
LLMLingua	https://arxiv.org/abs/2310.05736	2023	EMNLP 2023
LongLLMLingua	https://arxiv.org/abs/2310.06839	2023/2024	ACL 2024
Activation Beacon	https://arxiv.org/abs/2401.03462	2024	ICLR 2025
Chain of Density	https://arxiv.org/abs/2309.04269	2023	EMNLP 2023 NewSum
LLM×MapReduce	https://aclanthology.org/2025.acl-long.1341.pdf	2025	ACL 2025
Skeleton-of-Thought	https://arxiv.org/abs/2307.15337	2023	ICLR 2024
GraphRAG	https://arxiv.org/abs/2404.16130	2024	Microsoft Research
Self-Route (RAG vs LC)	https://arxiv.org/abs/2407.16833	2024	arXiv
LC vs RAG Revisit	https://arxiv.org/abs/2501.01880	2025	arXiv
Contextual Retrieval	https://www.datacamp.com/tutorial/contextual-retrieval-anthropic	2024	Anthropic 官方
PARSE schema extraction	https://arxiv.org/abs/2510.08623	2025	arXiv
HD-LoA Heuristic Prompting	https://aclanthology.org/2024.acl-long.647/	2024	ACL 2024
ARGUS Argument Analysis	https://www.mdpi.com/2079-8954/13/12/1079	2025	MDPI Systems
Shifting to Long Output	https://arxiv.org/pdf/2503.04723	2025	arXiv

← 返回方法论库索引 · 返回方法论区