把二十万行日志、几百份会议纪要或一整套代码仓库塞进大模型然后问一句“找出所有相互矛盾的变更”通常会同时撞上三个问题输入可能超过上下文窗口即使能够装下模型也未必能稳定利用位于中段的信息一次超长请求还会把无关内容一起计费。扩大上下文窗口解决的是“最多能接收多少 token”却不自动解决“应该读哪一段、读几次、如何核对遗漏”。Recursive Language ModelsRLM递归语言模型换了一个视角不把全部文本当作模型提示词而是把它留在外部环境中模型只看到文本的规模、索引和少量预览。它可以用代码搜索、切片、统计再把相关片段交给子模型分析子模型仍可继续分解最终由根模型归并答案。论文把这种机制描述为一种推理时脚手架而不是新注意力架构也不是某个特定模型的名称。这篇文章从一个真实需求出发在一批超长运维记录中回答“某次故障的完整演化链是什么”并要求每个结论都能回到原始行号。我们会实现一个受预算约束的递归处理器验证它有没有漏证据同时把代码执行、提示注入、递归爆炸和成本失控等生产风险说清楚。1. RLM到底改变了什么普通长上下文调用的结构是“问题加全文一起进入模型”。检索增强生成则先用向量或关键词挑出若干片段再让模型回答。RLM位于两者之间又不等同于任何一个它让模型参与“怎样读取上下文”的决策并允许通过程序对全文做精确操作。关键词/正则/统计按章节或时间切分否是超长文本留在外部存储根模型读取元数据与问题选择操作程序筛选候选片段生成子任务子模型语义分析证据是否充分根模型归并答案结论与原始位置引用关键区别可以概括为“变量空间”和“token空间”的分离。全文是程序中的变量只有被选中的切片进入某次模型调用。根模型不需要记住每一个字符但必须知道自己能执行哪些受限操作、已经检查过哪些范围、剩余预算是多少。这样做不会创造真正的无限上下文磁盘、执行时间、子调用次数和最终汇总窗口依然有限。它只是把一次难以控制的巨大调用改造成若干可观察、可中止的小调用。RLM也不是“RAG的替代品”。对稳定知识库中的普通事实问答预先构建的向量索引更快、更便宜对需要遍历所有记录、做跨段聚合或动态决定下一步搜索方向的任务递归程序更有优势。实际系统完全可以先用数据库和检索器缩小范围再让RLM处理剩余的复杂推理。2. 为什么装得下仍然可能答不好上下文窗口是硬上限信息利用率是另一个问题。“Lost in the Middle”研究表明相关证据在长输入中的位置会影响模型表现位于开头或结尾的信息往往比中间信息更容易被使用。更大的窗口因此应被理解为容量不应被当作可靠检索和覆盖率的保证。长文本任务大致有三类。第一类是稀疏定位例如从百万行日志中寻找唯一请求ID正则表达式通常比模型更合适。第二类是局部语义判断例如判断十段报错是否属于同一根因可以先程序过滤再交给模型。第三类是密集聚合例如比较每个月的规则变化必须让全部相关分区都被处理不能只取相似度最高的几块。RLM真正有价值的地方是允许一条轨迹混合这些操作而不是强迫所有问题都走同一种切块策略。以故障时间线为例直接搜索“数据库断连”可能漏掉更早出现的连接池耗尽和更晚出现的补偿任务积压。合理的递归策略是先定位告警附近的时间范围再按服务拆分让子调用分别提取“事实、时间、实体、证据位置”最后按时间排序并检查因果跳跃。如果答案声称A导致B却没有任何中间事件或原始行号系统应标为待确认而不是让语言流畅度掩盖证据缺口。3. 先建立可寻址的外部文本外部环境不能只是一个巨大字符串。最少要有稳定的片段编号、原始偏移、来源文件和内容摘要否则模型得到答案后无法回溯。下面的代码只用Python标准库把多个文本文件切成带重叠的片段并生成适合交给根模型的清单。它刻意不做embedding因为按字符位置和关键词扫描已经能构成一个透明基线。from__future__importannotationsfromdataclassesimportdataclassfrompathlibimportPathimporthashlibimportredataclass(frozenTrue)classSpan:span_id:strsource:strstart:intend:inttext:strdefnormalize(text:str)-str:texttext.replace(\r\n,\n).replace(\r,\n)return\n.join(line.rstrip()forlineintext.splitlines())defsplit_text(source:str,text:str,size:int6000,overlap:int500)-list[Span]:ifsize0ornot0overlapsize:raiseValueError(size必须为正数overlap必须在[0, size)内)cleannormalize(text)spans:list[Span][]start0whilestartlen(clean):endmin(startsize,len(clean))ifendlen(clean):boundarymax(clean.rfind(\n,start,end),clean.rfind(。,start,end))ifboundarystartsize//2:endboundary1piececlean[start:end]digesthashlib.sha256(f{source}:{start}:{end}.encode()).hexdigest()[:12]spans.append(Span(digest,source,start,end,piece))ifendlen(clean):breakstartend-overlapreturnspansdeffind_spans(spans:list[Span],pattern:str,limit:int30)-list[Span]:regexre.compile(pattern,flagsre.IGNORECASE)return[spanforspaninspansifregex.search(span.text)][:limit]defload_corpus(folder:Path)-list[Span]:result:list[Span][]forpathinsorted(folder.rglob(*.txt)):result.extend(split_text(str(path),path.read_text(encodingutf-8)))ifnotresult:raiseRuntimeError(没有读取到UTF-8文本文件)returnresultdef_self_check()-None:sample启动正常。\n中间记录。\n*1000ERROR request-42 数据库超时。spanssplit_text(demo.log,sample,size800,overlap80)hitsfind_spans(spans,rrequest-42)assertlen(spans)1andlen(hits)1assertsample[hits[0].start:hits[0].end]hits[0].textif__name____main__:_self_check()这里有两个容易忽略的设计。其一span_id由来源与偏移计算而不是简单使用列表序号只要原文件和切分规则不变引用就稳定。其二重叠只是防止句子被机械截断不应在统计时重复计数。后续聚合应依据原始事件ID或去掉重叠区而不能把同一条日志当作两条证据。真实项目还应记录语料版本例如源文件SHA-256、生成时间和解析器版本。没有版本信息的引用只能证明“某个时候有一段文本”不能证明答案对应当前资料。PDF、网页和代码文件也应先被解析成统一Span结构并保留页码、URL、提交哈希等原生位置。4. 一个受控的递归执行器论文和官方实现允许模型在REPL中生成代码并触发子调用这种自由度很高但在业务环境中不宜直接把任意代码交给宿主机执行。下面采用更保守的实现调度逻辑由程序固定模型只负责分析片段并返回结构化结果。它仍然具有递归分解、局部调用和逐层汇总三个RLM核心特征却更容易审计。示例把“模型调用”抽象成Model协议便于接入本地模型或任意云端SDK。每次调用都消耗预算达到最大深度、片段足够小或预算不足时立即停止继续分裂。为了让代码可静态检查和单元替换模型返回普通字符串生产实现则应要求JSON Schema并拒绝无法解析的输出。from__future__importannotationsfromdataclassesimportdataclassfromtypingimportProtocolclassModel(Protocol):defcomplete(self,prompt:str)-str:...dataclassclassBudget:calls_left:intchars_sent:int0defcharge(self,text:str)-None:ifself.calls_left0:raiseRuntimeError(模型调用预算已耗尽)self.calls_left-1self.chars_sentlen(text)defask(model:Model,budget:Budget,prompt:str)-str:budget.charge(prompt)returnmodel.complete(prompt)defrecursive_analyze(model:Model,question:str,spans:list[Span],budget:Budget,*,depth:int0,max_depth:int2,leaf_chars:int18_000,)-str:ifnotspans:return未发现候选证据totalsum(len(item.text)foriteminspans)ifdepthmax_depthortotalleaf_charsorlen(spans)1:evidence\n\n.join(f[{item.span_id}{item.source}:{item.start}-{item.end}]\n{item.text}foriteminspans)prompt(f问题{question}\n只根据证据提取事实每条事实必须引用方括号中的span_id。证据不足时明确写未知。\n\nevidence)returnask(model,budget,prompt)midpointlen(spans)//2leftrecursive_analyze(model,question,spans[:midpoint],budget,depthdepth1,max_depthmax_depth,leaf_charsleaf_chars,)rightrecursive_analyze(model,question,spans[midpoint:],budget,depthdepth1,max_depthmax_depth,leaf_charsleaf_chars,)merge_prompt(f问题{question}\n合并下面两份局部报告。保留原span_id删除重复事实若报告冲突必须并列呈现而不是擅自裁决。\nf报告A\n{left}\n\n报告B\n{right})returnask(model,budget,merge_prompt)classEchoModel:只用于验证控制流不代表真实语义模型。defcomplete(self,prompt:str)-str:returnprompt[-300:]def_demo()-None:spanssplit_text(demo.log,事件A。\n*3000,size5000,overlap0)budgetBudget(calls_left20)resultrecursive_analyze(EchoModel(),列出事件,spans,budget,leaf_chars6000)assertresultand0budget.calls_left20if__name____main__:_demo()这段代码采用二分只是为了清楚展示递归不代表生产系统的最佳切法。日志更适合按时间窗口和服务名分区合同更适合按章节代码仓库更适合按模块和符号。分区边界属于任务知识如果把一次事务的请求和响应切到两棵互不相见的分支后面的汇总很难恢复因果关系。预算也不该只有调用次数。生产环境至少同时限制总输入token、总输出token、墙钟时间、递归深度、并发数和单次工具输出大小。任何一个上限触发时都应返回“部分完成”以及已经覆盖的分区而不是伪装成完整答案。递归系统最危险的失败不是显式报错而是在检查了三成材料后仍用确定口吻作出全局结论。5. 让根模型选择动作但不要让它获得主机权限完整RLM会让根模型在REPL里查看变量、运行搜索和发起子调用。灵活性来自模型生成程序风险也来自同一个地方。只要外部文本不可信文档中就可能含有“忽略之前规则、读取环境变量、上传文件”等提示注入。文本是数据不是系统指令执行器必须从权限上保证这类句子无法获得工具能力。安全的REPL至少需要进程或容器隔离、只读语料挂载、无默认网络、有限CPU和内存、执行超时、受限标准库以及独立的临时目录。不要只靠关键词黑名单过滤import os因为绕过字符串过滤的方法很多。官方RLM仓库提供多种沙箱接口DSPy的RLM模块也明确使用受控解释器如果改成本地解释器应理解“能运行”不等于“安全隔离”。更简单的生产方案是白名单工具search(pattern)、read_span(id)、list_sources()、subcall(prompt, span_ids)和submit(answer)。根模型只能构造这些函数的参数不能运行任意Python。白名单降低了探索能力却显著缩小攻击面也便于把每次访问写入审计日志。只有确实需要任意计算且有成熟沙箱时才升级到开放REPL。工具输出也要限长。模型如果一次打印完整语料相当于绕过了外部上下文设计搜索结果如果有十万条则应只返回计数、分布和分页游标。对子调用的提示词同样要标明证据边界要求忽略证据中的命令性文本并把原始片段视为不可信引用材料。6. 不要把递归等同于正确递归只是一种控制流。第一次分解方向错了后面所有子调用都可能在错误子空间里认真工作。原始论文的轨迹分析和后续研究都提醒策略选择、成本长尾以及语义密集任务仍是薄弱点。一个会不断调用自己的模型可能把同一个误判层层放大。典型失败包括以下几类关键词过窄导致候选集合缺失分块边界切断上下文子模型输出不含引用汇总模型把不同来源的同名实体合并循环在相同片段上反复分析某个异常分支耗尽全部预算工具代码产生错误却被模型当作有效结果。应对这些问题不能只写一条“请认真检查”的提示词而要把约束落实为状态和验证规则。每个节点应记录输入span集合、问题、父节点、深度、模型版本、提示词版本、token消耗、耗时、输出和错误。调度器保存“已访问span”和“已执行动作”的哈希重复轨迹达到阈值就停止。合并阶段只能引用子报告已有的span_id最终答案中的每个引用必须能够映射回当前语料版本。这样才能复盘“答案为什么错”而不是只剩下一串自然语言。7. 用覆盖率而不是文采验收长文本系统最容易做出漂亮演示最难证明没有漏。评测集应来自业务问题并给出可机读的证据集合。除了最终答案正确率还要看证据召回率、引用精确率、分区覆盖率、无依据断言率、调用次数和P95延迟。密集聚合任务尤其要检查“所有目标分区都执行成功”Top-k检索命中几条不能代替遍历。下面的验证器从最终输出中提取span_id检查引用是否存在并计算回答覆盖了多少来源。它不能判断语义是否正确但能挡住引用幻觉和“只读一个文件就总结全部文件”这两类基础错误。importredefvalidate_answer(answer:str,spans:list[Span])-dict[str,object]:known{item.span_id:itemforiteminspans}citedset(re.findall(r\b[a-f0-9]{12}\b,answer))unknownsorted(cited-known.keys())cited_sources{known[item].sourceforitemincitedifiteminknown}all_sources{item.sourceforiteminspans}coveragelen(cited_sources)/len(all_sources)ifall_sourceselse0.0return{citation_count:len(cited),unknown_citations:unknown,source_coverage:round(coverage,4),valid:bool(cited)andnotunknown,}def_validation_check()-None:spanssplit_text(a.txt,已确认事件A。,size100,overlap0)reportf事件A已确认 [{spans[0].span_id}]resultvalidate_answer(report,spans)assertresult[valid]isTrueassertresult[source_coverage]1.0if__name____main__:_validation_check()更完整的离线测试应包含四组样本。第一组是“针在草堆”把唯一事实放在不同位置验证定位不受位置影响。第二组是跨分区聚合答案需要每个分区贡献一项验证覆盖率。第三组是冲突证据要求系统保留分歧和时间版本。第四组是对抗文本在语料中放入提示注入、伪造工具返回和超长重复段落确认沙箱和提示边界有效。不要直接拿生产机密材料交给第三方评测模型。自动裁判适合辅助比较不应成为唯一真值。对高风险结论应由领域人员抽查原文对计数、日期和标识符应尽量由程序计算并让模型只负责解释。8. RLM、长窗口、RAG和摘要链怎么选如果资料能放入窗口、问题简单且调用频率低直接长上下文是最短路径。若问题主要是从稳定知识库找局部事实RAG通常更合适索引可以复用延迟和成本也更可预测。若任务是按固定维度总结每一份文件普通Map-Reduce摘要链就够了不必让模型动态写控制程序。RLM适合的问题具备至少一个特征输入明显超出有效窗口不同问题需要不同读取策略需要在精确程序操作与语义判断之间切换子任务可递归拆解或者必须对大量分区进行聚合。它不适合毫秒级在线接口、不允许任何代码执行的环境、缺少可验证答案的高风险自动决策以及单次模型调用已经能稳定解决的普通任务。一个务实的演进顺序是先实现关键词搜索和可引用切片再加入固定Map-Reduce有证据表明固定流程无法覆盖多种问题后才让模型选择工具最后在沙箱、预算和评测成熟时开放更自由的REPL。RLM不是越“智能”越好可靠系统往往从较窄的动作空间开始。9. 上线时需要观察什么线上不能只记录最终文本。一次轨迹至少要能回答读了哪些来源执行了哪些搜索为什么产生子任务哪个分支超时子调用使用哪个模型总成本在哪里产生。建议为每个节点生成trace_id和parent_id将模型调用、工具调用、沙箱事件和预算变化串成一棵树。告警规则应关注异常形状例如递归深度突然增加、相同查询重复出现、无引用答案比例上升、某个来源从未被访问、平均成本正常但P99成本暴涨。RLM的费用分布可能有长尾只看均值容易漏掉少量失控轨迹。限额必须由执行器强制而不是由模型口头承诺。缓存可以降低重复子调用但缓存键必须包含模型版本、提示词版本、问题、span内容哈希和安全策略版本。只按文本片段缓存会把旧提示生成的结论混入新流程。包含个人信息或商业资料时还要确保缓存与租户隔离并提供按语料版本删除的能力。10. 从演示到生产的最小清单开始时不用复制论文中的全部能力。一个可用的第一版只需要稳定Span、有限搜索工具、固定深度递归、结构化子结果、预算和引用验证。随后用真实任务集衡量它是否优于“长窗口直接问”和“RAG Top-k”两个基线。如果没有明显收益就保留更简单的基线。生产检查可以归纳为六件事语料有版本且引用可回溯执行环境不信任文档内容递归深度与总调用量有硬上限失败返回覆盖范围而非伪完整答案离线集同时评估答案和证据线上轨迹可以重放。缺少其中任何一项RLM仍可以做研究原型却不应替人作出不可逆决策。10.1 先分类问题再决定是否递归根节点收到问题后不必立刻调用子模型。先做一次廉价的任务分类往往能省掉大量无意义轨迹。查询若包含确定的请求ID、文件名或时间戳程序直接精确检索若要求“分别总结每个章节”使用固定分区映射只有“找出异常模式并追踪相关证据”这类读取路径无法预先确定的问题才交给动态规划器。任务分类不能只依赖模型自述。可以从问题中提取结构信号是否存在唯一标识符是否要求计数是否要求覆盖“全部”答案是否需要跨来源关联。带“多少、全部、每个”的问题具有全量语义执行器应禁止只取Top-k后直接作答。带“是否存在”的问题可以在找到证据后提前停止但若答案是否定则必须证明搜索范围完整。对问题进行这样的类型约束还有一个好处能明确何时由程序计算。总数、最大值、日期排序和集合差异不应该让模型凭文本估算。子模型负责把非结构化内容转成字段聚合器用确定性代码计算根模型只解释结果。这种“语义抽取加程序归并”通常比让汇总模型重新阅读所有局部报告更容易验证。10.2 结构化子结果比自由摘要更可靠自由文本在递归层级中会不断压缩细节。第一层把“不排除缓存故障”写成“可能是缓存”第二层又可能写成“缓存故障”到根节点已经丢失不确定性。子结果最好使用固定字段例如claim、evidence_ids、time_range、confidence、unknowns和conflicts。合并器只能组合这些字段不得创造新的证据ID。置信度也不能让模型随意给一个百分数。更实用的是离散状态直接证据、间接推断、相互冲突、材料不足。直接证据必须引用原文间接推断要列出前提冲突必须保存双方来源。最终展示时再把这些状态翻译成自然语言用户能够看出哪些是事实哪些只是合理假设。结构化输出失败时不要用正则“尽量抢救”成看似合法的数据。执行器可以用明确错误提示重试一次仍失败则把该分支标为失败并进入覆盖报告。如果默默丢掉一个无法解析的分支最终答案就会产生难以发现的系统性遗漏。10.3 并行不是越多越快同一层的独立分区可以并发调用但并发数受模型速率、沙箱资源和下游限额约束。一次把几百个片段全部发出会造成限流重试、成本尖峰和结果乱序。更稳妥的方式是有限工作队列调度器只保持少量在途任务任一任务完成后再取下一个并把剩余预算原子地扣减。并行子调用结束后不能按返回顺序拼接因为网络快慢与原文顺序无关。每个结果应携带分区序号和原始范围聚合前恢复稳定顺序。若一部分调用失败可以只重试失败分区已经成功的结果以输入哈希缓存不必全部重跑。递归成本可近似拆成根规划、叶子分析和逐层归并三部分。二分树的叶子越小调用数量越多叶子越大单次上下文越长模型更可能漏细节。最佳点由任务决定不能从论文数字直接照搬。可以在固定验证集上尝试几组leaf_chars和max_depth画出证据召回、总token和延迟的帕累托曲线再选满足业务约束的配置。10.4 更新语料时如何避免整棵树作废长资料经常只修改少数文件。若缓存键基于整个语料哈希一处小改动会让所有结果失效。更好的做法是以Span内容哈希为叶子键父节点键由有序子节点哈希、问题和提示版本组合而成。没有变化的子树可以复用受影响路径重新计算。但缓存复用必须尊重撤权和删除。某份文档被用户撤销权限后即使其旧摘要仍在缓存中也不能参与回答。每次读取缓存都重新检查当前主体对所有来源的权限跨租户缓存只允许保存完全公开的数据。语料删除时按来源反向索引清理叶子和祖先不能只删除原文件。10.5 为“没找到”建立严格语义RLM很容易把“这次搜索没有命中”说成“材料中不存在”。两者不是一回事。否定结论必须附带搜索方法、覆盖来源、时间范围、失败分区和截断信息。只要有一个必查分区超时结果就应是“在已完成范围内未发现”而不是全局否定。同样程序搜索依赖解析质量。PDF文字提取失败、编码损坏或压缩包没有展开都会制造虚假的空结果。建立索引时应记录每个来源的解析状态和字符数异常问答前若目标范围含解析失败文件先向用户暴露这一事实。把不可读文档算作“已搜索但无结果”会让审计链从起点就不可信。10.6 人工接管不是失败而是设计出口高风险长文本分析应定义升级条件关键证据冲突、引用不足、预算耗尽、对抗内容命中、安全策略阻止工具、或结果将触发不可逆操作。升级包不应只有一句“模型失败”而应包括问题、已覆盖来源、候选事实、冲突点和未完成分支让人工从现有进度继续而不是重新读全部资料。升级时还要冻结当前语料版本和完整轨迹。若人工接管后资料又发生更新必须明确区分“模型分析时看到的版本”和“人工最终采用的版本”否则同一引用可能已经指向不同内容。对外结论也应记录批准者与批准时间避免把模型草稿误当成正式审计结果。人工修正可以进入评测集但不能未经审核直接变成提示模板。一次个案可能依赖隐含背景把它硬编码为普遍规则会伤害其他任务。先归类失败原因再决定修改解析器、分区策略、工具、提示还是模型。RLM的轨迹比单次调用更长正因如此错误归因也更值得结构化处理。11. 总结Recursive Language Models的核心不是“模型无限记忆”而是把长文本从提示词移到可编程环境让模型按需读取、分解和递归调用。它用更多可控的推理步骤换取超长输入上的灵活性也把新的复杂度带到调度、预算、沙箱和验证层。真正可落地的RLM必须保留原始位置限制递归与工具权限显式报告未覆盖范围并用证据召回率检验结果。对于普通查找数据库或RAG更直接对于需要动态探索和全局聚合的超长任务RLM提供了一种值得测试的新控制方式。先用透明的小实现建立基线再根据评测数据增加自由度比一开始追求“近乎无限上下文”更可靠。参考资料Recursive Language Models原始论文arXiv:2512.24601RLM作者维护的官方实现RLM Minimal最小参考实现Alex L. ZhangRecursive Language Models原始介绍DSPy官方RLM模块文档DSPy RLM源代码Lost in the Middle: How Language Models Use Long ContextsSelf-Reflective Program Search for Long ContextThe Y-Combinator for LLMs: Solving Long-Context RotRecursive Models for Long-Horizon Reasoning
把二十万行日志、几百份会议纪要或一整套代码仓库塞进大模型然后问一句“找出所有相互矛盾的变更”通常会同时撞上三个问题输入可能超过上下文窗口即使能够装下模型也未必能稳定利用位于中段的信息一次超长请求还会把无关内容一起计费。扩大上下文窗口解决的是“最多能接收多少 token”却不自动解决“应该读哪一段、读几次、如何核对遗漏”。Recursive Language ModelsRLM递归语言模型换了一个视角不把全部文本当作模型提示词而是把它留在外部环境中模型只看到文本的规模、索引和少量预览。它可以用代码搜索、切片、统计再把相关片段交给子模型分析子模型仍可继续分解最终由根模型归并答案。论文把这种机制描述为一种推理时脚手架而不是新注意力架构也不是某个特定模型的名称。这篇文章从一个真实需求出发在一批超长运维记录中回答“某次故障的完整演化链是什么”并要求每个结论都能回到原始行号。我们会实现一个受预算约束的递归处理器验证它有没有漏证据同时把代码执行、提示注入、递归爆炸和成本失控等生产风险说清楚。1. RLM到底改变了什么普通长上下文调用的结构是“问题加全文一起进入模型”。检索增强生成则先用向量或关键词挑出若干片段再让模型回答。RLM位于两者之间又不等同于任何一个它让模型参与“怎样读取上下文”的决策并允许通过程序对全文做精确操作。关键词/正则/统计按章节或时间切分否是超长文本留在外部存储根模型读取元数据与问题选择操作程序筛选候选片段生成子任务子模型语义分析证据是否充分根模型归并答案结论与原始位置引用关键区别可以概括为“变量空间”和“token空间”的分离。全文是程序中的变量只有被选中的切片进入某次模型调用。根模型不需要记住每一个字符但必须知道自己能执行哪些受限操作、已经检查过哪些范围、剩余预算是多少。这样做不会创造真正的无限上下文磁盘、执行时间、子调用次数和最终汇总窗口依然有限。它只是把一次难以控制的巨大调用改造成若干可观察、可中止的小调用。RLM也不是“RAG的替代品”。对稳定知识库中的普通事实问答预先构建的向量索引更快、更便宜对需要遍历所有记录、做跨段聚合或动态决定下一步搜索方向的任务递归程序更有优势。实际系统完全可以先用数据库和检索器缩小范围再让RLM处理剩余的复杂推理。2. 为什么装得下仍然可能答不好上下文窗口是硬上限信息利用率是另一个问题。“Lost in the Middle”研究表明相关证据在长输入中的位置会影响模型表现位于开头或结尾的信息往往比中间信息更容易被使用。更大的窗口因此应被理解为容量不应被当作可靠检索和覆盖率的保证。长文本任务大致有三类。第一类是稀疏定位例如从百万行日志中寻找唯一请求ID正则表达式通常比模型更合适。第二类是局部语义判断例如判断十段报错是否属于同一根因可以先程序过滤再交给模型。第三类是密集聚合例如比较每个月的规则变化必须让全部相关分区都被处理不能只取相似度最高的几块。RLM真正有价值的地方是允许一条轨迹混合这些操作而不是强迫所有问题都走同一种切块策略。以故障时间线为例直接搜索“数据库断连”可能漏掉更早出现的连接池耗尽和更晚出现的补偿任务积压。合理的递归策略是先定位告警附近的时间范围再按服务拆分让子调用分别提取“事实、时间、实体、证据位置”最后按时间排序并检查因果跳跃。如果答案声称A导致B却没有任何中间事件或原始行号系统应标为待确认而不是让语言流畅度掩盖证据缺口。3. 先建立可寻址的外部文本外部环境不能只是一个巨大字符串。最少要有稳定的片段编号、原始偏移、来源文件和内容摘要否则模型得到答案后无法回溯。下面的代码只用Python标准库把多个文本文件切成带重叠的片段并生成适合交给根模型的清单。它刻意不做embedding因为按字符位置和关键词扫描已经能构成一个透明基线。from__future__importannotationsfromdataclassesimportdataclassfrompathlibimportPathimporthashlibimportredataclass(frozenTrue)classSpan:span_id:strsource:strstart:intend:inttext:strdefnormalize(text:str)-str:texttext.replace(\r\n,\n).replace(\r,\n)return\n.join(line.rstrip()forlineintext.splitlines())defsplit_text(source:str,text:str,size:int6000,overlap:int500)-list[Span]:ifsize0ornot0overlapsize:raiseValueError(size必须为正数overlap必须在[0, size)内)cleannormalize(text)spans:list[Span][]start0whilestartlen(clean):endmin(startsize,len(clean))ifendlen(clean):boundarymax(clean.rfind(\n,start,end),clean.rfind(。,start,end))ifboundarystartsize//2:endboundary1piececlean[start:end]digesthashlib.sha256(f{source}:{start}:{end}.encode()).hexdigest()[:12]spans.append(Span(digest,source,start,end,piece))ifendlen(clean):breakstartend-overlapreturnspansdeffind_spans(spans:list[Span],pattern:str,limit:int30)-list[Span]:regexre.compile(pattern,flagsre.IGNORECASE)return[spanforspaninspansifregex.search(span.text)][:limit]defload_corpus(folder:Path)-list[Span]:result:list[Span][]forpathinsorted(folder.rglob(*.txt)):result.extend(split_text(str(path),path.read_text(encodingutf-8)))ifnotresult:raiseRuntimeError(没有读取到UTF-8文本文件)returnresultdef_self_check()-None:sample启动正常。\n中间记录。\n*1000ERROR request-42 数据库超时。spanssplit_text(demo.log,sample,size800,overlap80)hitsfind_spans(spans,rrequest-42)assertlen(spans)1andlen(hits)1assertsample[hits[0].start:hits[0].end]hits[0].textif__name____main__:_self_check()这里有两个容易忽略的设计。其一span_id由来源与偏移计算而不是简单使用列表序号只要原文件和切分规则不变引用就稳定。其二重叠只是防止句子被机械截断不应在统计时重复计数。后续聚合应依据原始事件ID或去掉重叠区而不能把同一条日志当作两条证据。真实项目还应记录语料版本例如源文件SHA-256、生成时间和解析器版本。没有版本信息的引用只能证明“某个时候有一段文本”不能证明答案对应当前资料。PDF、网页和代码文件也应先被解析成统一Span结构并保留页码、URL、提交哈希等原生位置。4. 一个受控的递归执行器论文和官方实现允许模型在REPL中生成代码并触发子调用这种自由度很高但在业务环境中不宜直接把任意代码交给宿主机执行。下面采用更保守的实现调度逻辑由程序固定模型只负责分析片段并返回结构化结果。它仍然具有递归分解、局部调用和逐层汇总三个RLM核心特征却更容易审计。示例把“模型调用”抽象成Model协议便于接入本地模型或任意云端SDK。每次调用都消耗预算达到最大深度、片段足够小或预算不足时立即停止继续分裂。为了让代码可静态检查和单元替换模型返回普通字符串生产实现则应要求JSON Schema并拒绝无法解析的输出。from__future__importannotationsfromdataclassesimportdataclassfromtypingimportProtocolclassModel(Protocol):defcomplete(self,prompt:str)-str:...dataclassclassBudget:calls_left:intchars_sent:int0defcharge(self,text:str)-None:ifself.calls_left0:raiseRuntimeError(模型调用预算已耗尽)self.calls_left-1self.chars_sentlen(text)defask(model:Model,budget:Budget,prompt:str)-str:budget.charge(prompt)returnmodel.complete(prompt)defrecursive_analyze(model:Model,question:str,spans:list[Span],budget:Budget,*,depth:int0,max_depth:int2,leaf_chars:int18_000,)-str:ifnotspans:return未发现候选证据totalsum(len(item.text)foriteminspans)ifdepthmax_depthortotalleaf_charsorlen(spans)1:evidence\n\n.join(f[{item.span_id}{item.source}:{item.start}-{item.end}]\n{item.text}foriteminspans)prompt(f问题{question}\n只根据证据提取事实每条事实必须引用方括号中的span_id。证据不足时明确写未知。\n\nevidence)returnask(model,budget,prompt)midpointlen(spans)//2leftrecursive_analyze(model,question,spans[:midpoint],budget,depthdepth1,max_depthmax_depth,leaf_charsleaf_chars,)rightrecursive_analyze(model,question,spans[midpoint:],budget,depthdepth1,max_depthmax_depth,leaf_charsleaf_chars,)merge_prompt(f问题{question}\n合并下面两份局部报告。保留原span_id删除重复事实若报告冲突必须并列呈现而不是擅自裁决。\nf报告A\n{left}\n\n报告B\n{right})returnask(model,budget,merge_prompt)classEchoModel:只用于验证控制流不代表真实语义模型。defcomplete(self,prompt:str)-str:returnprompt[-300:]def_demo()-None:spanssplit_text(demo.log,事件A。\n*3000,size5000,overlap0)budgetBudget(calls_left20)resultrecursive_analyze(EchoModel(),列出事件,spans,budget,leaf_chars6000)assertresultand0budget.calls_left20if__name____main__:_demo()这段代码采用二分只是为了清楚展示递归不代表生产系统的最佳切法。日志更适合按时间窗口和服务名分区合同更适合按章节代码仓库更适合按模块和符号。分区边界属于任务知识如果把一次事务的请求和响应切到两棵互不相见的分支后面的汇总很难恢复因果关系。预算也不该只有调用次数。生产环境至少同时限制总输入token、总输出token、墙钟时间、递归深度、并发数和单次工具输出大小。任何一个上限触发时都应返回“部分完成”以及已经覆盖的分区而不是伪装成完整答案。递归系统最危险的失败不是显式报错而是在检查了三成材料后仍用确定口吻作出全局结论。5. 让根模型选择动作但不要让它获得主机权限完整RLM会让根模型在REPL里查看变量、运行搜索和发起子调用。灵活性来自模型生成程序风险也来自同一个地方。只要外部文本不可信文档中就可能含有“忽略之前规则、读取环境变量、上传文件”等提示注入。文本是数据不是系统指令执行器必须从权限上保证这类句子无法获得工具能力。安全的REPL至少需要进程或容器隔离、只读语料挂载、无默认网络、有限CPU和内存、执行超时、受限标准库以及独立的临时目录。不要只靠关键词黑名单过滤import os因为绕过字符串过滤的方法很多。官方RLM仓库提供多种沙箱接口DSPy的RLM模块也明确使用受控解释器如果改成本地解释器应理解“能运行”不等于“安全隔离”。更简单的生产方案是白名单工具search(pattern)、read_span(id)、list_sources()、subcall(prompt, span_ids)和submit(answer)。根模型只能构造这些函数的参数不能运行任意Python。白名单降低了探索能力却显著缩小攻击面也便于把每次访问写入审计日志。只有确实需要任意计算且有成熟沙箱时才升级到开放REPL。工具输出也要限长。模型如果一次打印完整语料相当于绕过了外部上下文设计搜索结果如果有十万条则应只返回计数、分布和分页游标。对子调用的提示词同样要标明证据边界要求忽略证据中的命令性文本并把原始片段视为不可信引用材料。6. 不要把递归等同于正确递归只是一种控制流。第一次分解方向错了后面所有子调用都可能在错误子空间里认真工作。原始论文的轨迹分析和后续研究都提醒策略选择、成本长尾以及语义密集任务仍是薄弱点。一个会不断调用自己的模型可能把同一个误判层层放大。典型失败包括以下几类关键词过窄导致候选集合缺失分块边界切断上下文子模型输出不含引用汇总模型把不同来源的同名实体合并循环在相同片段上反复分析某个异常分支耗尽全部预算工具代码产生错误却被模型当作有效结果。应对这些问题不能只写一条“请认真检查”的提示词而要把约束落实为状态和验证规则。每个节点应记录输入span集合、问题、父节点、深度、模型版本、提示词版本、token消耗、耗时、输出和错误。调度器保存“已访问span”和“已执行动作”的哈希重复轨迹达到阈值就停止。合并阶段只能引用子报告已有的span_id最终答案中的每个引用必须能够映射回当前语料版本。这样才能复盘“答案为什么错”而不是只剩下一串自然语言。7. 用覆盖率而不是文采验收长文本系统最容易做出漂亮演示最难证明没有漏。评测集应来自业务问题并给出可机读的证据集合。除了最终答案正确率还要看证据召回率、引用精确率、分区覆盖率、无依据断言率、调用次数和P95延迟。密集聚合任务尤其要检查“所有目标分区都执行成功”Top-k检索命中几条不能代替遍历。下面的验证器从最终输出中提取span_id检查引用是否存在并计算回答覆盖了多少来源。它不能判断语义是否正确但能挡住引用幻觉和“只读一个文件就总结全部文件”这两类基础错误。importredefvalidate_answer(answer:str,spans:list[Span])-dict[str,object]:known{item.span_id:itemforiteminspans}citedset(re.findall(r\b[a-f0-9]{12}\b,answer))unknownsorted(cited-known.keys())cited_sources{known[item].sourceforitemincitedifiteminknown}all_sources{item.sourceforiteminspans}coveragelen(cited_sources)/len(all_sources)ifall_sourceselse0.0return{citation_count:len(cited),unknown_citations:unknown,source_coverage:round(coverage,4),valid:bool(cited)andnotunknown,}def_validation_check()-None:spanssplit_text(a.txt,已确认事件A。,size100,overlap0)reportf事件A已确认 [{spans[0].span_id}]resultvalidate_answer(report,spans)assertresult[valid]isTrueassertresult[source_coverage]1.0if__name____main__:_validation_check()更完整的离线测试应包含四组样本。第一组是“针在草堆”把唯一事实放在不同位置验证定位不受位置影响。第二组是跨分区聚合答案需要每个分区贡献一项验证覆盖率。第三组是冲突证据要求系统保留分歧和时间版本。第四组是对抗文本在语料中放入提示注入、伪造工具返回和超长重复段落确认沙箱和提示边界有效。不要直接拿生产机密材料交给第三方评测模型。自动裁判适合辅助比较不应成为唯一真值。对高风险结论应由领域人员抽查原文对计数、日期和标识符应尽量由程序计算并让模型只负责解释。8. RLM、长窗口、RAG和摘要链怎么选如果资料能放入窗口、问题简单且调用频率低直接长上下文是最短路径。若问题主要是从稳定知识库找局部事实RAG通常更合适索引可以复用延迟和成本也更可预测。若任务是按固定维度总结每一份文件普通Map-Reduce摘要链就够了不必让模型动态写控制程序。RLM适合的问题具备至少一个特征输入明显超出有效窗口不同问题需要不同读取策略需要在精确程序操作与语义判断之间切换子任务可递归拆解或者必须对大量分区进行聚合。它不适合毫秒级在线接口、不允许任何代码执行的环境、缺少可验证答案的高风险自动决策以及单次模型调用已经能稳定解决的普通任务。一个务实的演进顺序是先实现关键词搜索和可引用切片再加入固定Map-Reduce有证据表明固定流程无法覆盖多种问题后才让模型选择工具最后在沙箱、预算和评测成熟时开放更自由的REPL。RLM不是越“智能”越好可靠系统往往从较窄的动作空间开始。9. 上线时需要观察什么线上不能只记录最终文本。一次轨迹至少要能回答读了哪些来源执行了哪些搜索为什么产生子任务哪个分支超时子调用使用哪个模型总成本在哪里产生。建议为每个节点生成trace_id和parent_id将模型调用、工具调用、沙箱事件和预算变化串成一棵树。告警规则应关注异常形状例如递归深度突然增加、相同查询重复出现、无引用答案比例上升、某个来源从未被访问、平均成本正常但P99成本暴涨。RLM的费用分布可能有长尾只看均值容易漏掉少量失控轨迹。限额必须由执行器强制而不是由模型口头承诺。缓存可以降低重复子调用但缓存键必须包含模型版本、提示词版本、问题、span内容哈希和安全策略版本。只按文本片段缓存会把旧提示生成的结论混入新流程。包含个人信息或商业资料时还要确保缓存与租户隔离并提供按语料版本删除的能力。10. 从演示到生产的最小清单开始时不用复制论文中的全部能力。一个可用的第一版只需要稳定Span、有限搜索工具、固定深度递归、结构化子结果、预算和引用验证。随后用真实任务集衡量它是否优于“长窗口直接问”和“RAG Top-k”两个基线。如果没有明显收益就保留更简单的基线。生产检查可以归纳为六件事语料有版本且引用可回溯执行环境不信任文档内容递归深度与总调用量有硬上限失败返回覆盖范围而非伪完整答案离线集同时评估答案和证据线上轨迹可以重放。缺少其中任何一项RLM仍可以做研究原型却不应替人作出不可逆决策。10.1 先分类问题再决定是否递归根节点收到问题后不必立刻调用子模型。先做一次廉价的任务分类往往能省掉大量无意义轨迹。查询若包含确定的请求ID、文件名或时间戳程序直接精确检索若要求“分别总结每个章节”使用固定分区映射只有“找出异常模式并追踪相关证据”这类读取路径无法预先确定的问题才交给动态规划器。任务分类不能只依赖模型自述。可以从问题中提取结构信号是否存在唯一标识符是否要求计数是否要求覆盖“全部”答案是否需要跨来源关联。带“多少、全部、每个”的问题具有全量语义执行器应禁止只取Top-k后直接作答。带“是否存在”的问题可以在找到证据后提前停止但若答案是否定则必须证明搜索范围完整。对问题进行这样的类型约束还有一个好处能明确何时由程序计算。总数、最大值、日期排序和集合差异不应该让模型凭文本估算。子模型负责把非结构化内容转成字段聚合器用确定性代码计算根模型只解释结果。这种“语义抽取加程序归并”通常比让汇总模型重新阅读所有局部报告更容易验证。10.2 结构化子结果比自由摘要更可靠自由文本在递归层级中会不断压缩细节。第一层把“不排除缓存故障”写成“可能是缓存”第二层又可能写成“缓存故障”到根节点已经丢失不确定性。子结果最好使用固定字段例如claim、evidence_ids、time_range、confidence、unknowns和conflicts。合并器只能组合这些字段不得创造新的证据ID。置信度也不能让模型随意给一个百分数。更实用的是离散状态直接证据、间接推断、相互冲突、材料不足。直接证据必须引用原文间接推断要列出前提冲突必须保存双方来源。最终展示时再把这些状态翻译成自然语言用户能够看出哪些是事实哪些只是合理假设。结构化输出失败时不要用正则“尽量抢救”成看似合法的数据。执行器可以用明确错误提示重试一次仍失败则把该分支标为失败并进入覆盖报告。如果默默丢掉一个无法解析的分支最终答案就会产生难以发现的系统性遗漏。10.3 并行不是越多越快同一层的独立分区可以并发调用但并发数受模型速率、沙箱资源和下游限额约束。一次把几百个片段全部发出会造成限流重试、成本尖峰和结果乱序。更稳妥的方式是有限工作队列调度器只保持少量在途任务任一任务完成后再取下一个并把剩余预算原子地扣减。并行子调用结束后不能按返回顺序拼接因为网络快慢与原文顺序无关。每个结果应携带分区序号和原始范围聚合前恢复稳定顺序。若一部分调用失败可以只重试失败分区已经成功的结果以输入哈希缓存不必全部重跑。递归成本可近似拆成根规划、叶子分析和逐层归并三部分。二分树的叶子越小调用数量越多叶子越大单次上下文越长模型更可能漏细节。最佳点由任务决定不能从论文数字直接照搬。可以在固定验证集上尝试几组leaf_chars和max_depth画出证据召回、总token和延迟的帕累托曲线再选满足业务约束的配置。10.4 更新语料时如何避免整棵树作废长资料经常只修改少数文件。若缓存键基于整个语料哈希一处小改动会让所有结果失效。更好的做法是以Span内容哈希为叶子键父节点键由有序子节点哈希、问题和提示版本组合而成。没有变化的子树可以复用受影响路径重新计算。但缓存复用必须尊重撤权和删除。某份文档被用户撤销权限后即使其旧摘要仍在缓存中也不能参与回答。每次读取缓存都重新检查当前主体对所有来源的权限跨租户缓存只允许保存完全公开的数据。语料删除时按来源反向索引清理叶子和祖先不能只删除原文件。10.5 为“没找到”建立严格语义RLM很容易把“这次搜索没有命中”说成“材料中不存在”。两者不是一回事。否定结论必须附带搜索方法、覆盖来源、时间范围、失败分区和截断信息。只要有一个必查分区超时结果就应是“在已完成范围内未发现”而不是全局否定。同样程序搜索依赖解析质量。PDF文字提取失败、编码损坏或压缩包没有展开都会制造虚假的空结果。建立索引时应记录每个来源的解析状态和字符数异常问答前若目标范围含解析失败文件先向用户暴露这一事实。把不可读文档算作“已搜索但无结果”会让审计链从起点就不可信。10.6 人工接管不是失败而是设计出口高风险长文本分析应定义升级条件关键证据冲突、引用不足、预算耗尽、对抗内容命中、安全策略阻止工具、或结果将触发不可逆操作。升级包不应只有一句“模型失败”而应包括问题、已覆盖来源、候选事实、冲突点和未完成分支让人工从现有进度继续而不是重新读全部资料。升级时还要冻结当前语料版本和完整轨迹。若人工接管后资料又发生更新必须明确区分“模型分析时看到的版本”和“人工最终采用的版本”否则同一引用可能已经指向不同内容。对外结论也应记录批准者与批准时间避免把模型草稿误当成正式审计结果。人工修正可以进入评测集但不能未经审核直接变成提示模板。一次个案可能依赖隐含背景把它硬编码为普遍规则会伤害其他任务。先归类失败原因再决定修改解析器、分区策略、工具、提示还是模型。RLM的轨迹比单次调用更长正因如此错误归因也更值得结构化处理。11. 总结Recursive Language Models的核心不是“模型无限记忆”而是把长文本从提示词移到可编程环境让模型按需读取、分解和递归调用。它用更多可控的推理步骤换取超长输入上的灵活性也把新的复杂度带到调度、预算、沙箱和验证层。真正可落地的RLM必须保留原始位置限制递归与工具权限显式报告未覆盖范围并用证据召回率检验结果。对于普通查找数据库或RAG更直接对于需要动态探索和全局聚合的超长任务RLM提供了一种值得测试的新控制方式。先用透明的小实现建立基线再根据评测数据增加自由度比一开始追求“近乎无限上下文”更可靠。参考资料Recursive Language Models原始论文arXiv:2512.24601RLM作者维护的官方实现RLM Minimal最小参考实现Alex L. ZhangRecursive Language Models原始介绍DSPy官方RLM模块文档DSPy RLM源代码Lost in the Middle: How Language Models Use Long ContextsSelf-Reflective Program Search for Long ContextThe Y-Combinator for LLMs: Solving Long-Context RotRecursive Models for Long-Horizon Reasoning
