Reasoning

随着大语言模型的上下文窗口不断膨胀，一个很现实的问题摆在了桌面上：RAG（检索增强生成）这项技术，还有没有存在的必要？这个问题早几年提出来，可能会被当成笑话——那时候模型上下文只有几千token，不靠检索根本没法处理长文档。但现在GPT-4已经能处理128K token，Claude更是直奔200K甚至1M，传统RAG那套“切碎检索再拼接”的做法，看起来确实有点笨重。

Context windows are getting larger

Do we need RAG anymore?

从目前的技术趋势来看，业界大体有两个判断：

• 简单的、标准化的RAG可能会逐渐淡出，但高度定制化的RAG依然有生存空间。LLM自身的检索能力正在变得越来越值得信赖。

• 对大部分应用场景来说，等到后续模型API原生支持足够长的上下文之后，唯一制约RAG存在与否的因素，就只剩下成本了。

RAG: reasoning & retrieval on multiple chunks of information

先回顾一下RAG最基础的流程：用户提出一个问题 → 在文档库中做相似度检索 → 把检索出来的片段拼成新的Prompt → 交给模型生成回答。这套流程看起来简单直接，但它背后藏着很多值得深挖的细节。

Needle In A Haystack: test reasoning & retrieval in long context LLMs

一个经典的测试方法叫“大海捞针”（Needle In A Haystack），专门用来检测LLM在超长文本中的事实检索能力。实验流程很巧妙：在一篇超长的论文里插入三句关于披萨秘方的信息——比如“无花果是完美披萨的秘密成分之一”、“帕尔玛火腿也是”、“山羊奶酪也是”——然后问模型“完美披萨的秘密成分是什么”。模型找到几个成分就得几分。

实验结果揭示了几个关键现象：

1. 无论检索还是推理任务，当隐含事实（needles）数量增加时，GPT-4能找出来的数量都呈下降趋势。

2. 上下文越长，成功检索到的needle数量就越少。

3. 在上下文长度固定的前提下，越靠近Prompt末尾的needle越容易被找到，越靠近开头的则越容易被遗漏。

Challenge may be recency bias in LLMs

这说明LLM存在着明显的“近因偏见”——对近期（靠近末尾）的token记忆更牢固，但往往真正关键的信息可能出现在文档的较前位置。一个很有价值的启发是：RAG检索结果在拼入Prompt的时候，可以按照倒序排列——把相似度最高的片段放最后，最低的放最前面，这样反而能提高模型对关键信息的关注度。

RAG will change

今天的RAG更多聚焦于精确检索，即把相关文档块精准地捞出来。但面对长上下文LLM对远端token的遗忘问题，以及上下文越长检索成功率越低的问题，传统的chunk式检索策略需要重新设计。未来的RAG不会消失，而是会演变成一种更灵活、更智能的形态。

Need to balance system complexity vs latency & token usage

这里存在一个核心矛盾。检索过于精确，会带来一系列副作用：

• 系统设计过于复杂

• 整体复杂度飙升

• 召回率偏低（精确度虽然上去了，但漏掉的东西可能很要命）

• recall回来的chunk数量需要精打细算

反过来，如果图省事把全部文档一股脑丢给LLM，又会面临：

• 极高的token消耗

• 难以忍受的延迟

• 检索过程完全黑箱，无法监控

• 存在安全隐患

所以最终必须在这个光谱上找到一个合适的平衡点。

Some idea..

Query analysis: Connect questions to the right document

查询分析是提升RAG质量的第一步。具体可以做三件事：

1. Query Analysis——对用户问题做重写、拆分、甚至提取摘要。

2. Routing——将处理后的查询导向正确的数据库。

3. Query Construction——把自然语言问题转化为SQL、Cypher或向量数据库的查询语句。

这样一来，检索的命中率和相关性都能得到有效提升。

Indexing:

索引环节的核心问题是：如何保证检索到的chunk确实有足够的信息量？如果简单地把全文切块向量化，然后跟问题向量做相似度匹配，至少会碰到两个坑：

1. 你无法保证每个chunk都恰好是一个完整的语义段落。

2. 有些文档内容不够精炼，一个chunk可能与问题相似度很高，但并没有包含回答问题的关键信息——真正重要的答案可能在另一个chunk里。

Use representations to simplify document retrieval

一种有效的方法是：先让LLM对整份文档做摘要，然后把摘要向量化存入检索库（摘要与原文档的对应关系是一对一的）。检索时，先通过向量相似度找到最相关的摘要，再根据摘要定位到原始文档的对应部分，最后把完整的原文提取出来。这样既能保证检索的精准度，又不会丢失上下文完整性。

Use trees to consolidate info across many documents

另一种更高级的做法是把文档组织成树状结构。具体来说：将所有文档视为叶子节点，先对这些节点做embedding和聚类，然后对每一簇写一个摘要，形成父节点。再对父节点聚类……如此反复，直到只剩一个根节点。检索的时候，对所有层次节点同时做相似度搜索，这样得到的结果可能既包含高层的摘要，也包含具体的原文。好处很明显：无论用户问的是宏观问题还是微观细节，系统都能找到合适的回答素材。

Reasoning

Use reasoning / self-reflection around RAG

在检索前后加入推理和自我反思，能进一步提升RAG的质量。一种做法是：检索出相关文章后，让LLM自己对结果的相关性打分，只保留高分内容，再让LLM对生成的答案进行自我审查——是否产生幻觉？是否真正回答了问题？如果答案不理想，就重新调整检索策略并重复。

还有一些更简洁的workflow：比如检索到的内容如果相关性不高，就让LLM重写query，然后转向网络搜索。

Overall picture: Doc-centric, no splits or compression, reason pre/post retrieval

整体来看，新一代RAG的核心思路正在向“以文档为中心”转变——不再对文档做粗暴的分割和压缩，而是在检索前和检索后都引入推理能力（比如前面提到的自我校准）。这种做法保留了文档的完整语义，同时也让检索过程更可控、更可解释。虽然系统复杂度有所上升，但换来的是更可靠、更智能的检索增强能力。