很多看起来是「推理任务」的 LLM 工作，其实骨子里是搜索任务。问一份 10M token 的代码库里某个 bug 何时引入，问一份万字 PDF 的第 17 页和第 184 页的数字是否一致，问一段"最近三个月里所有和 Symphony 架构有关的 commit 和 blog"——这些题目的共同点是，答案必须从一个远超模型上下文窗口的语料里找出来，推理只是最后一公里，前面 99% 的距离是检索。

这篇文章围绕一个具体问题展开：当任务里藏着一个巨大的搜索子问题，当前 LLM 社区在「降低搜索成本」和「提高搜索精度」两条线上各自走到了哪一步？ 选取三个互相咬合的锚点：递归语言模型（Recursive Language Models, RLMs）、LLM Wiki 范式、以及 RAG 家族自身在 2024–2026 年的演进。三者并列，不是因为它们属于同一层，而是因为它们从三个不同的抽象层次攻击同一个搜索成本问题。

一张图先把坐标系摆好

一个 LLM 应用要处理超出单次上下文窗口的知识，历史上只有四条路：

  • 参数化记忆：把知识预训练或微调进模型权重里。代价是更新贵、无法溯源、无法增量，收益是查询快。
  • 朴素长上下文：直接把全部相关资料塞进 prompt，让注意力机制自己挑。代价是 token 开销二次方级、长上下文下精度大幅衰减（context rot），收益是架构最简单。
  • 一次性 RAG：建索引、查 Top-K、拼接进 prompt。代价是召回上限受索引质量限制，收益是可扩展、可溯源。
  • agent 驱动的多轮搜索：让 LLM 自己调 search 工具、看结果、再搜。代价是 token 成本动辄 10×–15×，收益是复杂查询的精度远超一次性 RAG。

RLMs、LLM Wiki、新一代 RAG 分别对应其中三种组合的再抽象：

抽象层次 思路 降本手段 提精手段
RLMs 把长上下文当成 REPL 环境里的一个变量，让模型递归调自己 根模型只处理元数据，细粒度读取由子模型完成 分解粒度自己决定，不受固定 chunk 切分限制
LLM Wiki 在摄入阶段就把原始文档合成成 wiki 页面 查询阶段的检索成本摊到摄入时一次性做掉 交叉引用、矛盾检测在摄入时完成
现代 RAG 在一次性 RAG 管线的每一环做工程改造 小模型改写、late interaction、上下文压缩 混合检索、rerank、contextual embedding

三种路线顺着抽象从高到低，分别对应摄入阶段预合成（LLM Wiki）、查询时递归分解（RLMs）、查询时工程管线（RAG）。

一、Recursive Language Models：把上下文变成可编程变量

1.1 论文与核心机制

Recursive Language Models 由 MIT CSAIL 的 Alex L. Zhang、Tim Kraska、Omar Khattab 在 2025 年 10 月 15 日以博客形式首发 [Alex L. Zhang Blog, 2025-10-15]，随后整理成 arXiv 预印本 Recursive Language Models（arXiv:2512.24601，2025-12-31 v1）[arXiv:2512.24601, 2025-12]。论文摘要里的定义很克制：

We propose Recursive Language Models (RLMs), a general inference paradigm that treats long prompts as part of an external environment and allows the LLM to programmatically examine, decompose, and recursively call itself over snippets of the prompt.

翻成工程语言：RLM 不把长上下文塞进模型的注意力层，而是把它加载到一个 REPL（Read-Eval-Print Loop，比如 Python notebook）里，作为一个持久化变量存在。根模型（root LM）只看到查询和这个变量的元数据（长度、结构），它通过写代码去「窥视」这个变量——切片、正则、按行取、按 token 范围取——再通过 llm_query(prompt, chunk) 这样的原语递归调一个隔离的子模型去处理特定片段。子模型的结果回到 REPL 环境，根模型再决定是聚合、是继续拆分、还是做第二轮查询。

[PATTERN] RLM 的关键抽象翻译：RAG 是「预定义一套检索管道，每次查询走一遍」；RLM 是「不预定义任何管道，让根模型在查询时写一段代码描述它想要的检索行为」。前者把检索凝固成系统组件，后者把检索变成模型自己的运行时决策。

1.2 实验数据：OOLONG 与 BrowseComp-Plus

论文和博客共同报告的两组实验是理解 RLM 价值的关键。

第一组在 OOLONG benchmark 的 132k token 上下文上：一个用 GPT-5-mini 作为根模型和子模型的 RLM 系统，准确率比直接让 GPT-5 读取同样 132k token 的朴素方案高出一倍以上（博客原文：“over 110%” on 132k token sequences on OOLONG trec_coarse split），且单次查询的 API 成本更低 [Alex L. Zhang Blog, 2025-10-15]。意义在于，132k token 完全在 GPT-5 的上下文窗口内——这不是"窗口不够"问题，而是"窗口够了也读不好"问题。RLM 的优势是在窗口之内就存在的。

第二组在 BrowseComp-Plus（BrowseComp 的扩展版本，包含最多 1000 份文档、约 10M+ token 的深度研究任务）上：当文档数量推高到物理上下文容量两个数量级之外时，RLM(GPT-5) 是唯一保持稳定表现的方案；朴素 GPT-5 无论是截断读取还是配 BM25 检索，性能都随文档数单调下降 [arXiv:2512.24601, 2025-12]。

1.3 RLM 和 RAG、agentic search 的关系

三者界限容易混，但并不难区分：

  • RAG 是管线（pipeline）：索引、召回、rerank、拼接，每一步是固定组件。
  • Agentic Search 是循环（loop）：LLM 在每一步决定调不调搜索、搜什么、是否继续。搜索引擎仍然是黑盒工具，LLM 不会自己去"写一个切片函数"。
  • RLM 是递归（recursion）：LLM 把长上下文当变量，自己写代码决定怎么切、怎么分发给子模型，搜索行为退化成一种通用编程原语。

从这个视角看，RLM 并不"替代" RAG。当知识库是外部的、结构化的、可索引的，RAG 仍然更便宜；当"知识"就是用户当下丢过来的一份超大输入（一份 20M token 的 repo、一次 200 页的合同、一个月份的日志），RLM 才显出优势——它不依赖任何预建索引，纯靠根模型的编程决策把长输入消化掉。

1.4 局限性

根据博客和社区复现项目（如 ysz/recursive-llm、codecrack3/Recursive-Language-Models-RLM-with-DSpy 这两个基于 LiteLLM + DSPy 的第三方实现）的讨论，RLM 的代价主要有三块：

  1. 延迟。多层串行/并行的子模型调用和代码执行，使端到端响应时间显著高于单次 LLM 调用。
  2. 代码脆弱性。根模型写的 Python 代码一旦出错，整条推理链会断掉，需要重试或回退策略。
  3. 成本不可预测。虽然平均 token 成本可控，但在复杂任务上根模型可能连续发起几十次子查询，API 账单会非线性放大。

截至 2026 年 4 月底，RLM 的社区复现是存在的，但尚未出现针对其核心结论的大规模反驳。属于典型的新范式早期：idea 干净，工程工具链还在补。

二、LLM Wiki：把搜索成本摊给摄入阶段

2.1 Karpathy 的 idea file

"LLM Wiki"作为被讨论的术语，直接源头是 Andrej Karpathy 在 2026 年 4 月初发布的一份 GitHub Gist（gist ID 442a6bf555914893e9891c11519de94f），标题就叫 llm-wiki.md，副标题 A pattern for building personal knowledge bases using LLMs [Karpathy, 2026-04]。文件开头写得很克制：这不是一个可运行的代码仓库，是一个 idea file，目的是让读者把它贴给自己的 coding agent（Claude Code、Codex 等），由 agent 根据这份理念给每个用户搭一套自己的实现。

核心设计哲学只有一句话：不要在每次查询时做 RAG，把 LLM 当作一个持续维护 markdown wiki 的 agent，让它在摄入阶段把原始文档合成成交叉引用的 wiki 页面，查询时直接读 wiki。

对应到 RAG 的常规管线，差异落在时间轴上：

维度 传统 RAG LLM Wiki
知识处理时机 每次查询时（on every question） 摄入时一次（once per source）
知识形态 原始文档 chunk 结构化、交叉引用的 wiki 页面
矛盾检测 查询时可能才发现 摄入时就标记
查询开销 向量检索 + 拼接 + LLM 读 wiki（或 wiki + 少量检索）
可审计性 检索结果难以持久追溯 wiki 本身就是版本可控的 markdown
人类角色 上传与查询 策划、编辑、提问

2.2 为什么它可以"降低搜索成本"

把成本从「每次查询都跑一遍检索+生成」搬到「摄入时合成一次 wiki」，表面上只是挪了位置，实际节省体现在三点：

  1. 重复查询不再重复做检索。同一份文档被问 100 次，RAG 就要跑 100 次向量检索、100 次 rerank、100 次拼 prompt；LLM Wiki 只在摄入时做一次合成，之后所有问题都落在一份已经消化过的 wiki 上。
  2. 预合成减少了 query→chunk 的错配。RAG 失败的典型模式是问题措辞和 chunk 原文差异太大，向量召回不到。wiki 页面因为已经做过跨文档整合，覆盖了更多提问角度。
  3. 矛盾和重复在摄入阶段被消除。这等价于在索引阶段做了一次数据清洗，查询时不再需要模型临时判断"这两段哪个才对"。

2.3 它与学术界「显式记忆」流派的关系

Karpathy 的 gist 是工程范式级别的提法，但它背后的哲学在学术界有一条连贯的血脉，通常被称为非参数化记忆 / 显式记忆：

  • kNN-LM（Khandelwal et al., ICLR 2020）：最早把语言模型和外部 kNN 记忆库组合起来，用显式记忆弥补参数化模型的泛化能力。
  • Atlas（Izacard et al., JMLR 2023）：系统性展示了检索增强的 LM 可以用极少训练样本完成知识密集型任务。
  • REPLUG（Shi et al., NAACL 2024）：把 LLM 当黑盒，只通过可训练的检索器来增强，让纯 API 访问的大模型也能用上外部知识。
  • SILO（Min et al., ICLR 2024 Spotlight）：把版权风险高的数据放到非参数化 datastore，模型参数只在低风险语料上训练，推理时合法合规地"查"这些知识。
  • Memory³（Yang et al., arXiv:2407.01178，2024-07，鄂维南团队）：提出语言模型的第三类记忆形式——显式记忆，区别于模型参数里的隐式记忆和上下文 KV cache 里的工作记忆。论文作为概念验证从零训练了一个 2.4B 的 LLM，摘要声称它在测试中同时优于"更大规模的 LLM 和 RAG 模型"且解码速度高于 RAG，并提出了一套记忆稀疏化和两阶段预训练方案来支持显式记忆的落地。

这些工作和 LLM Wiki 的共同点是：承认 LLM 的参数不是放所有知识的好地方，让外部结构承担知识存储与检索，让参数只承担语言和推理能力。差别是，学术工作把"外部结构"做成稠密向量索引或 kNN 库，Karpathy 把它做成人类可读的 markdown——后者可审计性、可编辑性、可 diff 化都远优于前者，代价是依赖 LLM 本身的合成质量。

2.4 不能忽略的副作用

LLM Wiki 有两个真实存在的风险，社区讨论里被反复提到：

  1. 合成错误会被固化。RAG 每次查询都从原始文档重新取，错了下次还能修；LLM Wiki 一旦把错误信息写进 wiki，后续所有查询都会读到这份错误。必须配合审计和回看机制。
  2. 摄入成本并不低。把一份 1000 页的文档合成成结构化 wiki，需要 LLM 多轮阅读、整合、交叉校验，token 开销通常数倍于一次 RAG 查询。只有当这份知识会被问很多次（个人知识库、技术文档），摊下来才划算。

三、现代 RAG：在管线的每一环做工程战役

RAG 从 2023 年第一代"向量检索 + 拼 prompt"到 2026 年，已经分化成十几个小战场。按「降低搜索成本」和「提高搜索精度」两条线，各自挑几个最有代表性的工作。

3.1 提高搜索精度

Hybrid retrieval + Reciprocal Rank Fusion (RRF)。单独使用稠密向量检索（dense embedding）在专有名词、罕见实体上会失败，单独使用 BM25 在语义近义上会失败。把两路的排名用 RRF 融合已经是生产级 RAG 的默认做法，主流向量数据库（Weaviate、Pinecone、Vespa、Elastic 等）在 2024 年之后都原生提供 hybrid search + RRF 的开箱即用能力。

Cross-encoder rerank。双塔 bi-encoder 在召回阶段便宜但精度有限；cross-encoder 把 query 和候选 chunk 拼在一起走一次 transformer，精度显著更高但算不起完整库。Rerank 的用法是"先用 bi-encoder 召回 Top-100，再用 cross-encoder 从 100 里选 Top-10"。代表作有 Cohere Rerank 3、Jina Reranker v2（2024-06，支持 100+ 语言和代码）、BAAI BGE Reranker、以及基于 LLM 的 RankGPT / RankLLaMA。

Late interaction（ColBERT 家族）。bi-encoder 把一段文字压缩成一个向量，cross-encoder 每次要算一次 transformer，两者中间地带是 ColBERT：文档和查询各自编码成 token 级别的向量序列，在查询时做 token 与 token 之间的 max-sim 匹配，精度接近 cross-encoder，索引与检索效率接近 bi-encoder。ColPali（arXiv:2407.01449，2024-06 首发，ICLR 2025）把这套机制推广到视觉语言模型，用视觉 token 直接给文档页面的图像做 late interaction 检索，省掉了传统 OCR pipeline。

Contextual Retrieval（Anthropic, 2024-09）。Anthropic 官方发布的一个轻量预处理技术：在把 chunk 写入索引之前，用 LLM 给每个 chunk 生成一段 50–100 token 的上下文解释（“这段话出自某某文档的某某章节，讨论的是某某”），把这段解释拼在 chunk 前面再做 embedding 和 BM25 索引。官方数据：只用 Contextual Embeddings，top-20 chunk 的检索失败率从 5.7% 降到 3.7%（降幅 35%）；叠加 Contextual BM25 后降到 2.9%（降幅 49%）；再叠加 reranking 降到 1.9%（降幅 67%） [Anthropic, 2024-09]。

[PATTERN] Contextual Retrieval 的工程直觉：RAG 失败大多不是嵌入模型不好，而是 chunk 被切出来之后丢掉了语境。给每个 chunk 在索引阶段补回它的语境，比换一个更强的嵌入模型收益大得多。

HyDE / Query Rewriting / Multi-query / Step-back。这是一组解决"用户提问和文档用词不对齐"的技术。HyDE（Hypothetical Document Embeddings）让 LLM 先假装回答这个问题，用这份假设答案去做 embedding 检索，比用原始问题的 embedding 召回率高。Multi-query 是让 LLM 把一个问题扩写成多个变体一起检索。Step-back prompting 是先让 LLM 问一个更抽象的问题（“这个问题属于哪一类”），再用两层结果共同检索。

Late Chunking（Jina AI, 2024-09）。传统做法是先 chunk 再 embed，每个 chunk 丢失了它周围的语境。Late chunking 反过来：先用长上下文 embedding 模型对整篇文档做 token 级编码，保留全局注意力的结果，再在 token 序列上做均值池化形成 chunk 向量 [Jina AI, arXiv:2409.04701]。等价于让每个 chunk 的向量里都"看到过"全文。

3.2 降低搜索成本

Cache-Augmented Generation（CAG）。2024 年 12 月发布的 Don’t Do RAG: When Cache-Augmented Generation is All You Need for Knowledge Tasks（arXiv:2412.15605）给出的思路是：当知识库规模可以完整塞进现代长上下文 LLM 的扩展窗口时，就在服务启动时把整个知识库离线预填进 KV cache，查询时不做任何实时检索，直接在已有 KV 上跑 attention [arXiv:2412.15605, 2024-12]。没有向量库、没有 rerank、没有拼 prompt，单次查询只付 decoding 的钱。适用面狭窄（知识库必须足够小、更新低频、且模型支持足够长的上下文），但在满足条件的场景里极其便宜。

Context compression（LongLLMLingua、RECOMP、Selective Context）。检索拿回来的 Top-K chunk 动辄几千 token，里面大多数 token 和问题无关。用一个小模型先做一遍压缩，把真正关键的一小部分 token 留下来喂给生成模型，可以同时降低 token 开销和减少干扰。Microsoft 的 LongLLMLingua（ACL 2024）在 NaturalQuestions 上报告压缩后性能相对原始 prompt 最高提升 21.4%、token 数量约为原先的 1/4；在 10k token 规模、2×–6× 压缩比区间内端到端延迟加速 1.4×–2.6× [arXiv:2310.06839]。

Efficient rerank（小 cross-encoder 替代 LLM reranker）。LLM-based reranker（RankGPT、RankLLaMA）把每个候选文档都喂给大模型打分，精度最高，但每一次 rerank 都是一次完整的 LLM 调用，token 账单和延迟都显著高于专用 rerank 模型。在生产环境，体量更小的专用 cross-encoder（Cohere Rerank 3、Jina Reranker v2、BGE Reranker 这些 0.1B–1B 级别的模型）在大多数通用检索场景下精度接近 LLM reranker，推理成本低一个数量级，已经是 RAG 管线里的默认 rerank 选型。

3.3 哪些流行数字在 2025–2026 被复盘过

RAG 领域的数字通常来自小规模评测，放到真实业务就失真。有几个被重新检视的例子值得记住：

  • Semantic chunking 并不总是更好。早期宣传里 semantic chunking 在 Chroma 的评测里取得 91.9% recall，但后续独立测试（如 FloTorch 2026 的评估）在端到端准确率上只有 54%，比 recursive chunking 低一截。结论是 chunking 策略的效果高度依赖领域和评估指标，不存在一刀切的最佳切分。
  • Deep Research 的 benchmark 分数演化很快。OpenAI Deep Research 在 2025 年 2 月发布时在 Humanity’s Last Exam 上 26.6%、在 BrowseComp 上约 50%，当时是当时的 SOTA；但 benchmark 本身还在演化，基准数字随新模型快速被刷新。单看一个数字没有意义，要看发布时间和评测版本。

四、Agentic Search：让 LLM 自己控制搜索循环

上面三章处理的是「系统怎么把证据找给 LLM」；这一章处理的是「让 LLM 自己决定什么时候找、找什么、找完怎么办」。三条线并不冲突，现代生产系统通常是"现代 RAG 作为工具 + agentic 循环作为调度"的组合。

4.1 Search-R1：用 RL 把"会搜索"训进模型

UIUC 的 Bowen Jin 等在 2025 年 3 月发布 Search-R1: Training LLMs to Reason and Leverage Search Engines with Reinforcement Learning（arXiv:2503.09516，v5 更新至 2025-08-05）[arXiv:2503.09516, 2025-03]。核心做法是把搜索引擎当成一个可以被模型调用的 tool，用强化学习训练模型学会三件事：什么时候触发搜索、用什么 query 触发、拿到结果后要不要再触发。训练的工程细节上，论文同时验证了 PPO 和 GRPO 两种 RL 算法，并引入"检索 token 屏蔽"（retrieved token masking）稳定训练、用简单的 outcome-based reward 做奖励信号。摘要里的主结果是：在 7 个问答数据集上相比各种 RAG 基线，Qwen2.5-7B 基座的 Search-R1 提升 41%，Qwen2.5-3B 基座提升 20%。

意义在于：2023–2024 年的 ReAct、Self-Ask 这些 agentic 做法都是 prompt 工程层面的事，模型本身没被训练过。Search-R1 把"会搜索"这个行为直接训进了权重里，搜索策略从 prompt-time 可配置变成 train-time 可学习。

4.2 产品级 Deep Research

2024 年 12 月到 2025 年 2 月，Google Gemini、OpenAI、Perplexity 前后发布了同名的 “Deep Research” 功能，背后的架构都是同一套 agentic 模式：一个高级模型做规划和综合，一群子任务承担具体的网页检索和阅读，最后把结果综合成一份带引用的报告。公开的数字里，OpenAI Deep Research 在 2025 年 2 月发布时在 Humanity’s Last Exam 上取得 26.6% 完成率；随后 OpenAI 在 2025 年 4 月发布了 BrowseComp（arXiv:2504.12516），一个由 1,266 道问题组成的、专门衡量 agent 在互联网上持续导航定位稀有事实能力的 benchmark——问题的设计目标是答案简短可核对、但难以被简单搜索直接命中。

4.3 Anthropic 的多 agent 研究系统

Anthropic 在 2025 年 6 月发布的 How we built our multi-agent research system [Anthropic Engineering, 2025-06] 讲清了三件事：Claude 的 Research 功能是用 lead researcher agent + 多个并行 subagent 搭的；这种多 agent 架构相比单 agent chat，在内部研究类评测上显著占优；但它的 token 消耗是单 agent 对话的 10–15 倍。Anthropic 在另一份工程手册 Building Effective AI Agents 中也把这个 10–15× 作为架构选型的首要参考："Multi-agent systems use roughly 10-15x more tokens than single agents."

[PATTERN] agentic 成本的决策阈值：多 agent 不是万能药。它在「breadth-first」型任务（要横向搜索多个独立信息源再汇总）上收益最大，在「depth-first」型任务（要在一条线索上推理到底）上反而常常拖慢。Anthropic 自己的结论是——单任务预算紧张就用单 agent 或精心设计的并行 workflow，只有任务价值足够高才开 multi-agent。

4.4 agentic search 相对于一次性 RAG 的 trade-off

两个维度摆开看：

维度 一次性 RAG Agentic Search
搜索成本 1× 3–15×（多 agent 并行会更高）
搜索精度 受索引质量和单轮召回上限制约 可以自我修正、分解、二次检索
延迟 亚秒级 十几秒到几分钟
可预测性 成本稳定 成本随任务难度浮动
适合任务 简单事实查询、FAQ、文档问答 深度研究、跨源核对、多跳推理

工程上少见的奢侈是"一律用 agentic search"；常见的是"默认 RAG，对识别为复杂的 query 升级为 agentic"。这恰好是 OpenAI / Anthropic 最新几款产品的实际路由策略。

五、把四条路线叠在一起：一份选型速查

回到开头的问题——任务里藏着巨大的搜索子问题，该先找哪一把锤子？按下面的决策顺序走通常能少踩坑：

  1. 知识库能不能预建索引？
    • 能 → 从现代 RAG 开始（hybrid + rerank + contextual retrieval）。这是最成熟的方案，80% 的企业场景止步于此。
    • 不能（每次查询面对的是现场丢来的超长输入）→ 直接看 RLM 或长上下文模型。
  2. 同一份知识会被问多少次？
    • 几十次以上，且领域稳定 → 加一层 LLM Wiki 摄入，把检索成本摊给一次性的 wiki 合成。
    • 一次或少数几次 → RAG 或 RLM 足够，不值得 wiki 投入。
  3. query 复杂度如何？
    • 单事实、直接问答 → 一次性 RAG。
    • 多跳、要横向综合 → agentic search（Search-R1 这类 trained retrieval agent 或多 agent 架构）。
  4. 成本容忍度？
    • 紧 → 尽量用 contextual retrieval + 小 cross-encoder rerank + 上下文压缩。
    • 宽 → 上多 agent + LLM reranker，接受 10–15× 的 token 账单。

这些路径共享一个更深层的趋势：LLM 的进化正在把"搜索"从架构组件逐步提拔成模型的一等能力。最早的 RAG 把搜索完全外挂给模型，后来 Contextual Retrieval 改善外挂本身的精度，Search-R1 进一步把"如何搜索"训进模型权重；RLM 走得更远，让模型在运行时自己决定如何切分和分发查询；LLM Wiki 则换了个方向，承认与其每次查询时再搜，不如在摄入时就把知识整理好。这几条路线在不同时间尺度上并行推进，短期内不会出现赢家通吃，但它们共同回答了文章开头的问题——当任务本质是搜索时，降本靠摊派（wiki / cache / 压缩），提精靠分层（hybrid / rerank / contextual）或循环（agentic / recursive）。

参考资料

  • Alex L. Zhang, Recursive Language Models（blog post），2025-10-15：https://alexzhang13.github.io/blog/2025/rlm/
  • Alex L. Zhang, Tim Kraska, Omar Khattab, Recursive Language Models，arXiv:2512.24601，2025-12-31
  • Andrej Karpathy, LLM Wiki — A pattern for building personal knowledge bases using LLMs，GitHub Gist 442a6bf555914893e9891c11519de94f，2026-04
  • Anthropic, Contextual Retrieval，2024-09：https://www.anthropic.com/news/contextual-retrieval
  • Anthropic Engineering, How we built our multi-agent research system，2025-06：https://www.anthropic.com/engineering/built-multi-agent-research-system
  • Anthropic, Building Effective AI Agents: Architecture Patterns and Implementation Frameworks（PDF），2025
  • Bowen Jin et al., Search-R1: Training LLMs to Reason and Leverage Search Engines with Reinforcement Learning，arXiv:2503.09516，2025-03
  • OpenAI, BrowseComp: A Simple Yet Challenging Benchmark for Browsing Agents，arXiv:2504.12516 / openai.com/index/browsecomp/，2025-04
  • Jina AI, Late Chunking: Contextual Chunk Embeddings Using Long-Context Embedding Models，arXiv:2409.04701，2024-09
  • Don’t Do RAG: When Cache-Augmented Generation is All You Need for Knowledge-Intensive Tasks，arXiv:2412.15605，2024-12
  • Hongkang Yang et al., Memory³: Language Modeling with Explicit Memory，JMLR，arXiv:2407.01178，2024-07
  • Sewon Min et al., SILO Language Models: Isolating Legal Risk in a Nonparametric Datastore，ICLR 2024 Spotlight
  • Gautier Izacard et al., Atlas: Few-shot Learning with Retrieval Augmented Language Models，JMLR 2023
  • Urvashi Khandelwal et al., Generalization through Memorization: Nearest Neighbor Language Models，ICLR 2020
  • Weijia Shi et al., REPLUG: Retrieval-Augmented Black-Box Language Models，NAACL 2024