超越 RAG：构建处理百万 Token 的递归语言模型 (RLM)

在当前的人工智能领域，开发者们面临着一个持久的瓶颈：上下文窗口（Context Window）。虽然像 Claude 3.5 Sonnet 和 Gemini 1.5 Pro 这样的模型已经将界限推向了数十万甚至数百万个 Token，但“迷失在中间”（Lost in the Middle）的现象仍然是一个关键障碍。当你拥有 100 万个 Token 的文本，而模型的上下文窗口只有 128K 时，通常的行业答案是检索增强生成（RAG）或者寄希望于长上下文模型足够“聪明”。

然而，RAG 往往会丢失全局上下文，因为它仅根据向量相似性检索片段。另一方面，长上下文模型随着输入长度的增加，性能往往会下降。这就是 递归语言模型 (Recursive Language Model, RLM) 概念的用武之地。通过利用来自 n1n.ai 等平台的高性能 API，开发者可以实现一种范式，让模型将文档视为外部环境，而不是静态输入。

RLM 范式：将文档视为环境

递归语言模型运行在一个简单而深刻的前提下：让 LLM 编写自己的程序来访问文档。与其将 100 万个 Token 塞进 Prompt，系统会将文档加载到一个模型无法直接看到的持久 Python 环境中。然后给模型一套工具——切片、正则搜索和递归子调用——以自主探索文本。

这种方法与 RAG 有本质的不同。在 RAG 管道中，检索系统（通常是双编码器）在模型开始推理之前就决定了什么是相关的。在 RLM 架构中，模型本身决定读什么、什么时候读以及调查的深度。通过使用 n1n.ai，您可以访问最新的推理模型（如 OpenAI o3 或 DeepSeek-V3），以高可靠性驱动这种自主探索。

实现指南：构建原型

RLM 的核心由三个组件组成：编排循环（Orchestrator Loop）、工具集和持久执行环境。

1. 编排循环

循环管理 LLM 与环境之间的状态。它一直持续到模型达到轮次限制或调用 final 工具返回答案为止。

for turn in range(1, max_turns + 1):
    # 注入预算信息以帮助模型规划
    messages.append({"role": "system", "content": f"剩余子调用次数: {remaining_budget}"})

    response = client.chat(
        messages=messages,
        tools=[python_exec, final_answer],
        tool_choice="auto",
    )

    # 如果模型调用工具，则执行它并反馈观察结果
    if response.tool_calls:
        observation = execute_tools(response.tool_calls)
        messages.append({"role": "tool", "content": observation})
    else:
        break

2. Python 工具集

模型通过 python_exec 工具与文档交互。环境包含作为变量 context 的全文。我们提供辅助函数来提高探索效率：

• get_slice(start, end): 提取特定的子字符串。
• search(pattern): 执行正则表达式搜索以在文本中查找锚点。
• llm_query(prompt): 这是递归部分。模型可以调用一个单独的、较小的 LLM 调用来总结或分析它刚刚找到的特定片段。

3. 处理推理模型 (o1/o3)

当通过 n1n.ai 使用先进的推理模型时，一个常见的陷阱是 max_completion_tokens 参数。在较新的模型中，此参数包括“推理 Token”（内部思维链）。如果您将其设置得太低（例如 800），模型可能会花费所有 800 个 Token 进行“思考”，而没有剩余的 Token 用于实际的工具调用或响应，从而导致 finish_reason: length 错误。对于递归子调用，将其设置为至少 8000 会更安全，以允许深度推理和结构化输出。

案例研究：分析 71 篇研究论文

为了测试 RLM，我编译了一个包含 71 篇 arXiv 论文的语料库，总计超过 400 万个字符（约 100 万个 Token）。使用标准的 RAG 方法，模型经常会错过全局主题，因为向量搜索返回的是方法论片段，而不是高层贡献。

RLM 方法遵循了独特行为模式：

1. 第一轮（探索）： 模型检查 len(context) 并使用 search() 识别文件边界。然后它从开头、中间和结尾采样片段。
2. 第二轮（批量分析）： 使用 llm_query_batch 辅助函数，模型启动并行子调用来总结每个文件的前 25,000 个字符。
3. 第三轮（综合）： 模型在 Python 环境中处理批量调用的结果，统计关键词频率并合成全局摘要。

通过利用 n1n.ai 的高吞吐量，处理 100 万个 Token 的整个过程大约耗时 3 分 25 秒，实现了对 71 篇论文的 100% 覆盖。

性能对比：RLM vs. RAG vs. 长上下文

专家提示：预算提醒机制

RLM 最有效的“护栏”之一是预算可见性。如果您只是告诉模型它有 15 轮，它可能会漫无目的地“游荡”。然而，如果您在每个工具响应中注入剩余的子调用计数——例如 [系统：剩余 11/15 次子调用]——模型的行为就会发生转变。随着预算的减少，它开始优先考虑综合信息而不是进一步探索。这种突发的资源管理能力是使 RLM 能够用于生产环境的关键。

总结

递归语言模型代表了从“检索”到“导航”的转变。对于涉及大规模数据集的复杂任务，如果“针”不仅仅是一个事实，而是一个跨越整个草堆的模式，那么 RLM 是更优的架构。随着 n1n.ai 等平台上的 LLM 成本持续下降和推理能力不断提高，多次顺序调用的开销对于所实现的分析深度来说，是一个非常值得付出的代价。

在 n1n.ai 获取免费 API 密钥。