个人主页 for_ever_love__ 欢迎各位大佬莅临其他栏目: 大模型开发从0到1 其他栏目: iOS项目总结大全 其他栏目: 我想学python了 其他栏目: iOS UI 文章目录Map-Reduce 式全文问答当文档超出上下文时的分而治之一、四种链式策略行为决定适用面1.1 stuff不是策略是上限参照1.2 map_reduce并行全局型1.3 refine顺序精炼型1.4 map_rerank定位型二、按问题类型选链路决策表三、成本模型算账再上车四、一个 hybrid 实战先筛后跑五、坑与边界六、评估全文问答怎么测七、小结Map-Reduce 式全文问答当文档超出上下文时的分而治之有些问题向量检索根本帮不上忙“这本 300 页的白皮书里作者一共提出了几条反对意见”——答案散落在全文各处任何 Top-K 检索都捞不全。对这类全文级问题LangChain 的map_reduce/refine链路给出了最直接的答案把文档切成块逐块处理Map再把中间结果汇总Reduce。这篇文章讲透四种链式策略的行为差异、各自的成本与坑以及怎么为问题类型选对链路。一、四种链式策略行为决定适用面LangChain 的 summarization/问答链有四个经典策略先看全景对比策略MapReduce调用次数特点stuff无无1全部塞进一个 promptmap_reduce每块独立答合并中间答案N1各块相互独立全局视角refine每块在累积答案上迭代滚动更新N答案逐块精炼保序演进map_rerank每块独立答 打分取最高分N适合答案在某一块里的定位型问题1.1 stuff不是策略是上限参照所有材料塞一个 prompt一次 LLM 调用。上下文够小时最优先质量最好、没信息损失、最便宜超限时直接出局。它的价值在基线任何其他策略效果不如 stuff说明问题不在链路上。1.2 map_reduce并行全局型[chunk-1] ─→ LLM(问题chunk1) ─→ 中间答案A ┐ [chunk-2] ─→ LLM(问题chunk2) ─→ 中间答案B ┼→ LLM(汇总) ─→ 最终答案 [chunk-3] ─→ LLM(问题chunk3) ─→ 中间答案C ┘Map 阶段完全并行N 个块可以并发请求每个块只看到问题 自己这块内容产出一个局部回答Reduce 阶段把所有中间答案合并成最终答案。LangChain 实现fromlangchain.chainsimportMapReduceDocumentsChain,ReduceDocumentsChainfromlangchain.chains.combine_documents.stuffimportStuffDocumentsChain# Mapmap_chainLLMChain(llmllm,promptmap_prompt)# Reduce先 stuff 成组组超限再递归 reducereduce_chainReduceDocumentsChain(combine_documents_chainStuffDocumentsChain(llmllm,promptreduce_prompt),collapse_documents_chainStuffDocumentsChain(...),token_max4000,)chainMapReduceDocumentsChain(llm_chainmap_chain,reduce_documents_chainreduce_chain,document_variable_namecontext,)resultchain.invoke({input_documents:chunks,question:q})map_reduce 的天然优势与死穴✅ 每个块独立处理没有跨块依赖全文的每个角落都被扫到——全文有几条反对意见这类全局统计问题的最优解✅ Map 阶段天然并行 latency 约等于单块延迟 × 2❌Map 阶段每块都不知道其他块的存在——跨块的对比、演进、因果“第三章的观点和第七章矛盾吗”在中间答案层丢失❌ 中间答案 token 量大时Reduce 自身也要分段token_max触发 collapse300 块全文 → 中间答案比原文还长递归 reduce 烧钱没商量。1.3 refine顺序精炼型chunk-1 → 初始答案 chunk-2 → LLM(问题 当前答案 chunk2) → 更新答案 chunk-3 → LLM(问题 更新答案 chunk3) → 再更新 ...每一步都基于到目前为止的最佳答案吸收新块。LangChain 实现fromlangchain.chainsimportRefineDocumentsChain chainRefineDocumentsChain(initial_llm_chainLLMChain(llmllm,promptinitial_prompt),refine_llm_chainLLMChain(llmllm,promptrefine_prompt),document_variable_namecontext,)intermediate_steps可以拿到每步的中间答案——调试友好能看见答案是怎么一步步长出来的。✅ 顺序语义保住后面的块知道前面发生了什么观点的演变这类问题答得出❌串行 N 次调用latency 线性累加——50 个块就是 50 次串行请求一分钟起步❌顺序敏感块的排列顺序影响结果same cost 下结果有方差❌ 中间答案轮次膨胀第 20 块时上下文里已经有前 19 块的信息浓缩token 越滚越大。1.4 map_rerank定位型Map 阶段不只产答案还产这个问题和这块内容的相关度分数Reduce 取最高分块的答案。适合答案确定在某一段问合同条款具体规定、问某参数具体值。[chunk-1] → 答案 相关度分 0.2 [chunk-2] → 答案 相关度分 0.9 ← 它赢 [chunk-3] → 答案 相关度分 0.3 → 返回 chunk-2 的答案✅ 答案出自最相关块不会把弱相关块的内容搅进来❌ 每块必须独立成答跨块信息合并不了相关度打分本身也会飘。二、按问题类型选链路决策表问题类型例子推荐链路材料够小任意stuff全局统计/汇总“全文几条反对意见”map_reduce顺序演进/对比“作者观点怎么变化的”refine精确定位“违约金比例是多少”map_rerank或直接向量检索跨块关系“A 论点和 B 数据矛盾吗”map_reduce 把找矛盾写进 map prompt注意最后一行map_reduce 不是不能跨块——把跨块任务显式写给 Map 阶段的每块“这段内容和反对意见相关吗相关就总结出来”Reduce 阶段做归并。问题分解到位map_reduce 能覆盖相当多的复合问题。三、成本模型算账再上车全文级问答是 LLM 密集型操作单次成本 N × (每块 prompt token) Reduce token。以 30 万 token 文档、10 万 token/块处理为例策略LLM 调用大致成本倍数延迟stuff11×一次请求map_reduce30 1Reduce 还得分组~30×并行 ≈ 2 倍单块refine30 串行~30×中间膨胀30 倍串行map_rerank30 并行~30×并行快临门一脚的省钱技巧Map 阶段用便宜模型块级处理是体力活抽取、定位、打分gpt-4o-mini、GLM-4-Flash 完全够Reduce/Refine 的最终合成再用好模型——成本直接砍 70%预过滤块先用向量检索粗排一遍全文 300 块里只有 60 块可能相关Map 只跑这 60 块——“全文问答不等于每块都要问 LLM”缓存中间答案同一文档的类似问题“几条反对意见”/“几条支持意见”Map 结果可复用——按块缓存别全文重跑控制 chunk 大小块太大浪费 token每块 prompt 都带问题指令太小块数爆炸。512~1500 token/块是甜点。四、一个 hybrid 实战先筛后跑生产上我最常用的组合——向量预筛 map_reduce 分段 reduce# 1. 预筛全文块先过向量检索保留相关的candidatesvector_store.search(embed(q),top_k60)# 300 → 60# 2. Map便宜模型并发处理 60 块partialsasync_gather([cheap_llm(map_prompt.format(questionq,contextc))forcincandidates])# 3. Reduce 分组token 超限就分组 stuff递归上升groups[partials[i:i10]foriinrange(0,len(partials),10)]midasync_gather([cheap_llm(collapse_prompt.format(textsg))forgingroups])# 4. 最终合成好模型finalgood_llm(final_prompt.format(questionq,mids\n.join(mid)))效果与成本60 块里相关的一般不到 20 块的有效信息预筛砍掉 80% 的无谓调用三级模型分工便宜 → 便宜 → 好把总成本压到全量 map_reduce 的 1/4 左右质量几乎无损——无效块本来就产不出有用信息用贵模型处理它们是纯浪费。五、坑与边界map_reduce 的中间答案别太长Map prompt 里限定最多 3 句话只输出和问题直接相关的信息否则 Reduce 阶段被中间答案的废话淹没refine 的顺序块顺序打乱结果会变正式处理前固定排序规则按页码并在测试集验证顺序敏感性数值统计要小心map_reduce 数数“全文出现几次 X”时每块的计数相加可能重复计同一事件在多块被提到——这类数数问题更适合先 Norm 后统计或者专门写代码统计reduce 的递归终止条件Reduce 分组合并后仍超token_max时LangChain 会递归 collapse要设最大递归深度兜底别对全文问答上缓存幻觉中间答案只对同文档同子任务可复用问题一换 Map 就得重跑。六、评估全文问答怎么测这套链路没法用传统检索评估集没有标准检索块要换评估方式构造聚合型测试集人工通读全文标注全文级事实共几条、分布在哪些页、核心观点是什么LLM-as-judge让裁判模型对比标准答案和链路输出打分允许用 Claude/GPT-4 当裁判比人工快 20 倍消融对照同样问题跑预筛 vs 不预筛、“便宜模型 vs 好模型 Map”用分数差证明省钱技巧没掉点延迟统计map_reduce 的 P99、refine 的串行耗时——选型时延迟是硬约束refine 在块数 30 时基本不可用。七、小结Map-Reduce 式全文问答的四句话四种链路对应四种问题全局统计用 map_reduce、顺序演进用 refine、精确定位用 map_rerank、材料够小直接 stuffmap_reduce 并行但丢跨块语义refine 保顺序但串行慢——没有完美策略只有对口的策略生产组合向量预筛 map_reduce 三级模型分工把全文 30 倍成本压到 1/4质量靠预筛保证无效块本来就没信息评估用聚合型测试集 LLM-as-judge 消融对照别用检索评估集的标准考全文问答。下一篇讲增量索引新文档怎么做到分钟级可检索以及索引更新不停机的工程做法。
