做RAG这么久我发现很多团队做智能问答都挺顺一碰到学术综述生成这种场景就容易卡壳。原因不复杂通用问答只需要召回几篇文档拼出一个答案就够学术综述却要求你把上百篇论文读一遍再交叉归纳出清晰脉络还要保证每句话都有据可查。这个要求直接改变了RAG的产品设计思路已经从检索增强问答变成了多源长文写作。就我的工程实践来说Map-Reduce 出处追踪是目前在学术综述生成上性价比最高的落地方案。Map阶段把每篇论文浓缩成结构化卡片Reduce阶段把卡片按逻辑层次合并成长文再用句子级引用把正文和来源牢牢绑在一起。这套思路我在多个知识密集型场景里验证过特别适合综述、白皮书、行业研究报告这类多来源、长输出、强求证的内容生成需求。如果你正在做文献综述工具、学术助手、科研知识库这类RAG应用这篇文章可以帮你省下大量试错成本。下面把架构设计、代码实现、踩坑记录都摊开来讲尽量少讲空话。1. 为什么一次生成搞不定学术综述很多人的第一反应是直接把检索到的论文片段塞进上下文让模型一次性写完综述不就行了我最初也这么试过结果惨不忍睹。不是生成不出来而是生成出来的东西根本不能用。1.1 通用RAG问答与综述生成的本质差异先把两类任务的差异摆清楚。通用RAG问答的输出通常是一段100~300字的回答需要引用2~3篇文档目标是回答准确。综述生成则是5000~20000字的长文需要综合20~100篇文献目标是覆盖全面、逻辑自洽、观点可溯源、语句无幻觉。这个差异会导致几个连锁反应。第一个是上下文窗口的根本矛盾。即便产品用了很长的上下文比如128k甚至256k顶多也就能塞下20~30篇论文的完整正文。但综述往往需要覆盖一个方向几十年的发展脉络可能涉及上百篇关键文献。你不可能只靠把相关片段塞进去完成覆盖。第二个是综合归纳这个动作没法靠单次生成完成。综述不是把每篇论文的观点罗列出来而是要把同主题的多篇论文放在一起比较、归类、提炼共性、指出分歧。单次生成时模型很难在长上下文中完成跨论文比对它更倾向于顺着最后一篇论文的内容往下写导致综述视角严重偏移。第三个是引用追踪的粒度问题。问答场景引用到文档级别就够了读者只需要知道答案来自哪一篇。综述不行读者需要知道这句话具体来自哪篇论文的哪个章节、哪组数据。如果做不到句子级溯源这篇综述就失去了学术价值。我见过不少团队拿着通用RAG框架改一改就上综述场景结果评估时发现召回率看着还行但生成结果里大量句子找不到来源关键结论也经常张冠李戴。问题不在模型而在pipeline设计。综述生成不能用单次检索-单次生成的简单链路必须拆成检索-逐篇消化-分层合并的多阶段流程。1.2 学术场景独有的三个硬约束除了任务形态学术场景还有三个通用RAG很少遇到的硬约束。第一是文献覆盖度必须可证明。综述写出来之后审阅者会问这个方向重要的工作你覆盖了吗没覆盖的话为什么这意味着系统要能输出我检索到了什么、我遗漏了什么的过程证据而不是只有一个最终结果。这在工程上通常要记录检索日志、召回得分和候选集合快照。第二是引文不能编造。学术综述里引用错误是有学术风险的。模型在生成时很容易把描述A论文的方法和引用B论文的结论混在一起。你需要一套机制让模型只能引用已经读过并写入卡片的内容而不是让它在生成的瞬间去回忆或臆造。第三是多源冲突的处理。不同论文对同一个结论可能互相矛盾比如有的研究说方法X效果好有的说效果差。综述要呈现出这种分歧而不是让模型自作主张替读者选边站。这意味着生成链路里要显式处理对比和冲突标注让模型知道这两篇论文结论不同你必须如实并列呈现。这三个约束叠加起来单纯靠调prompt是解决不了的。需要从pipeline结构上重新设计这也是我选择Map-Reduce作为主架构的根本原因。2. 系统级架构设计与数据流拆解先给一张整体线路图。这套系统不是单一RAG调用而是入库-检索-Map-Reduce-校验-发布六段式流水线。每一段都有明确产出段与段之间有结构化数据交接。2.1 六段式pipeline总览我把数据流拆成六个阶段入库与分块论文PDF转文本按章节结构切分成chunk建立倒排索引和向量索引。这一步的产出是结构化的论文片段每个片段都携带论文ID、章节号、段落号。检索召回根据用户给定的综述主题用混合检索关键词BM25向量相似度召回候选论文。通常召回200~300篇经过粗排和去重后保留top 50~100篇进Map阶段。Map阶段逐篇消化对每一篇候选论文独立执行摘要抽取输出一张结构化论文卡片。卡片内容包括研究问题、方法、数据、核心结论、局限性、与主题相关的关键句以及每项卡片内容的出处坐标。Reduce阶段合并生成把几十张卡片按综述大纲骨架分层合并。先按子主题合并出段落再按章节合并最后拼接成全文。每一轮合并都有明确的输入输出卡片保证信息不丢失。出处追踪与校验解析生成文本中的引用标记对照卡片内容逐句校验找出无出处句子和错配引用输出带修订建议的校审报告。发布与反哺校审通过的综述入库生成结果反过来用于扩充主题词表、优化检索权重完成闭环迭代。每个阶段之间都用JSON或数据库表传递数据不要用上一步的输出直接当下一步的输入字符串这种临时方式。结构化交接是后面能追踪、能重跑、能定位问题的前提。2.2 论文入库与检索召回的关键设计很多团队在入库阶段就埋了坑。学术论文和普通网页文档最大的区别是内部结构强摘要、引言、方法、实验、结论、参考文献每个部分的信息密度和信息类型差异巨大。我的做法是结构感知分块。先用解析工具提取章节标题再按章节边界切分chunk。摘要部分独立成块方法部分按章节切块实验部分按实验设置-指标-结果对比切块。这样切出来的chunk在语义上天然内聚检索命中率比固定长度切块高不少。检索召回阶段我一开始只用向量检索后来发现漏召回很严重。原因在于学术文献术语密度高同一个概念往往有多种表达方式比如对比学习在不同论文里可能写成contrastive learninginstance discriminationself-supervised representation learning。单纯靠向量相似度语义相近但术语罕见的论文容易被漏掉。后来改成BM25向量检索双路召回再用RRF倒数排名融合合并结果漏召回率下降明显。还有一个容易被忽略的点召回后要按论文去重。向量检索返回的是chunk级别的结果同一篇论文可能有多个chunk都命中了如果不去重直接进下一步Map阶段会对同一篇论文重复抽取浪费token不说还会让Reduce阶段把同一篇论文当成多个独立来源。我通常在召回后加一个论文级聚合步骤把同一论文的chunk按章节顺序重排再决定是整体进入Map还是只选top chunk。3. Map-Reduce的核心实现细节下面进入正题。先说清楚这套架构里Map和Reduce各自到底做了什么事再给出可直接复用的prompt和参数。3.1 Map阶段逐篇论文的结构化抽取Map阶段的目标很纯粹把一篇论文压缩成一张语义紧凑但信息完整的卡片。为什么不能直接拿论文原文进Reduce因为原文太长几十篇论文直接堆在一起必然超出上下文。更重要的是原文里大量内容对综述并不重要比如冗长的相关工作介绍、实验细节直接进入Reduce会被模型当作有效信息拉低信噪比。我的卡片结构固定为六个字段研究问题这篇论文试图解决什么问题一句话说清楚。方法描述用了什么方法核心思路是什么包括模型结构、训练策略、关键算法。实验结论在什么数据集上取得了什么结果和哪些基线做了对比效果差异多少。关键数据点对综述可能引用的具体数字包括指标数值、样本量、消融实验结论。局限性声明作者承认的不足或者我判断的边界条件。上下文坐标上面每一条内容对应的段落号、章节号用于后续出处追踪。Map阶段使用的prompt我写了一个基础模板实测效果稳定请阅读以下论文片段输出一张结构化论文卡片。 要求 - 只基于给定片段不要补充片段之外的内容。 - 对每个字段给出该信息在片段中的段落坐标如第2章第3段。 - 如果某个字段在片段中没有信息标注为NOT_FOUND不要推断。 - 保持学术中立不评价论文好坏。 片段内容 {paper_chunk}这里有个关键设计强制模型输出NOT_FOUND。不加这个约束的话模型会习惯性脑补卡片里会出现原文根本没提过的方法或结论。一旦卡片被污染后面的综述必然跟着出问题。卡片阶段宁可信息缺漏不可内容失真。Map阶段的并发策略也很重要。每篇论文的抽取是独立的天然适合并行。我用并发调度每次跑8~12篇配合小模型速度快的轻量模型先粗抽再用强模型对可疑字段精修。实测下来纯用强模型跑Mapfitokens是一样的但速度慢3倍成本高5倍而质量提升并不明显。批量场景强烈建议Map用轻量模型。3.2 Reduce阶段层级合并与骨架对齐Reduce阶段是综述生成的核心也是最容易翻车的地方。先明确一个反直觉的结论不要一次性让模型读完所有卡片然后生成全文。卡片总量虽然比原文小但top 100篇论文的卡片拼接起来仍然有10万token左右超过一般模型的稳定输出上限。更麻烦的是一次性合并会导致模型只能关注到最后出现的卡片前面的信息被遗忘。所以我采用层级Reduce策略分三步走第一层按综述骨架合并。先由人或自动生成综述大纲骨架大纲包含章节标题和每个子主题的说明。然后对每篇卡片做主题路由把卡片分配给最相关的章节。第二层按章节合成。每个章节的卡片集合通常10~20张作为输入生成该章节的初稿。章节初稿必须严格遵循骨架中对这个章节的定位写到哪句话就引用哪张卡片。第三层全文级整合。把各章节初稿拼接后做一次跨章节一致性检查重点处理术语统一同一概念在不同章节是否用同一说法、观点一致性前面说A方法有效后面不能又说无效、过度重复同一个结论在多处重复出现。如果用两层级先Map再一次Reduce来写短综述是可以的但一旦综述主题跨度大、文献数量超过30篇强烈建议走三级甚至四级Reduce。每一级Reduce都做一次信息压缩和去噪逐级递进最终生成的质量远好于一次成型。在Reduce的生成prompt里我始终强调骨架即边界你正在撰写综述的第 {section_index} 章标题为 {section_title}。 本章需要覆盖以下子主题 {subsection_guidance} 可用素材是以下论文卡片每张卡片有唯一ID {card_id}。 要求 - 只能使用给定卡片中的信息不得补充卡片外的内容。 - 每个核心观点末尾标注引用标记引用标记格式为 [CARD:{card_id}]。 - 如果某子主题缺少卡片支撑明确标注[待补充]。 - 保留不同论文之间的分歧不要强行统一。 可用卡片 {card_texts}这段prompt里有几个细节值得解释。只能使用给定卡片中的信息这句是防幻觉的关键。有了这句模型在生成时会尽量贴素材而不是调用自己的知识库。虽然不能完全杜绝幻觉但能大幅降低无中生有的概率。保留分歧不要强行统一这句是学术综述特有要求。很多模型天然倾向把矛盾信息调和成一种说法这在综述里是大忌。明确要求保留分歧之后生成结构会变成A研究认为X有效而B研究在类似条件下未观察到显著效果这才是合格的综述语言。[待补充]标记是我临时加的技巧。它可以让模型在遇到素材不足时认怂而不是硬编造。生成结束后把这些待补充位置收集起来再触发一轮补充检索形成迭代闭环。3.3 可直接复用的pipeline代码骨架为了不让上面的描述停留在概念层面我贴一段精简的pipeline代码骨架演示Map-Reduce的数据流组织方式。你可以在此基础上替换成自己的模型调用和存储方案。from dataclasses import dataclass, field from typing import List, Dict dataclass class PaperCard: doc_id: str title: str fields: Dict[str, str] # 字段名 - 内容 coordinates: Dict[str, str] # 字段名 - 原文坐标 card_id: str dataclass class SectionDraft: section_id: str title: str content: str card_ids: List[str] field(default_factorylist) def map_stage(paper_chunks: List[Dict], llm_func) - List[PaperCard]: Map阶段并发抽取论文卡片 cards [] for ch in paper_chunks: card llm_func(ch[content], ch[doc_id], ch[coordinates]) cards.append(card) return cards def route_cards_to_sections(cards: List[PaperCard], skeleton: Dict) - Dict[str, List[PaperCard]]: 把卡片路由到综述骨架的各个章节 sections {sid: [] for sid in skeleton[sections]} for card in cards: sid classify_card_to_section(card, skeleton[sections]) sections[sid].append(card) return sections def reduce_stage(routed_cards: Dict[str, List[PaperCard]], skeleton: Dict, llm_func) - List[SectionDraft]: Reduce阶段逐章节合并生成 drafts [] for sid, cards in routed_cards.items(): sec_meta skeleton[sections][sid] content llm_func( section_titlesec_meta[title], card_textsrender_cards(cards), ) drafts.append(SectionDraft(sid, sec_meta[title], content, card_ids[c.card_id for c in cards])) return drafts def final_integration(drafts: List[SectionDraft], llm_func) - str: 跨章节一致性整合 full_text \n\n.join(d.content for d in drafts) return llm_func(full_text)这段代码重点看两个地方。一是PaperCard里保留了coordinates字段它把卡片内容和原文位置绑定在一起这是整个出处追踪的数据基础。二是route_cards_to_sections把Map和Reduce分开让Reduce阶段只面对和当前章节相关的卡片避免无关信息干扰。分类路由可以用一次轻量分类prompt实现也可以直接用卡片embedding和章节embedding的相似度做粗路由。我推荐先用embedding粗路由再人工校骨架因为分类prompt在章节多的时候稳定性不好。4. 出处追踪让每个句子都有据可查出处追踪是这个系统最花功夫、也最容易被低估的部分。很多团队把引用做成了文章末尾堆一堆参考文献正文里没有任何对应关系这本质上等于没做。学术综述真正需要的是正文每一句结论都能指向具体来源。4.1 从篇章级引用到句子级引用我在第三章的Reduce prompt里给了一个引用格式[CARD:{card_id}]。这里要强调的是引用粒度必须到句子甚至短语不能到段落。原因很简单一个段落里可能混合了三四篇论文的观点如果段落只挂一个引用读者根本不知道哪句话属于哪篇。句子级引用意味着每个包含了具体结论、数据、方法描述的句子末尾都要带引用标记。我实际操作中发现模型在长文生成时经常漏标引用。为了解决这个问题我在Reduce之后加了一个引用强校验步骤把生成文本按句子切分逐个句子判断这句话是否包含实质性论断。如果是实质性论断再检查句末是否存在[CARD:xxx]标记。没有标记的句子会被标记为无出处句子回到Refine环节重新生成。这一步听起来简单做起来有个难点怎么判断实质性论断我用了一个折中方案先用规则过滤掉过渡句和提示性表述比如接下来我们将讨论...再用一个二分类模型判断剩余句子是否包含可验证信息。这个分类模型的训练数据是从历史综述里人工标注的效果足够用。4.2 引用ID映射与全文回放CARD:{card_id}只是我们给模型看的逻辑ID在最终发布给读者之前需要转换成正式的参考文献编号。我维护了一张引用映射表结构类似{ CARD:p001: { doc_id: paper_2023_zhang_etal, title: A Method for ..., venue: ICML 2023, coordinates: sec.3.2, para.2, citation_num: [12] }, CARD:p002: { doc_id: paper_2024_li_etal, title: Revisiting ..., venue: NeurIPS 2024, coordinates: sec.4.1, para.3, citation_num: [13] } }生成完成后我写了一个后处理函数把正文里的[CARD:p001]统一替换成[12]同时在文末生成参考文献列表。整个过程完全自动确保正文标记和参考文献一一对应。但这个映射表只是最基本的。真正让出处追踪有价值的是全文回放能力。所谓回放是指读者或审阅者点击正文中的引用标记[12]时系统能立刻展示这段话在原始论文中的上下文片段让人直接核对原文。这个体验看起来不复杂实现上要求Map阶段必须把原文坐标和卡片内容完整存下来并在Reduce阶段全程携带。我在存储设计上用了比较简单的方案卡片表、引用映射表、原文快照表三张表。原文快照表存的是生成该摘要时模型实际看到的那段原始文本而不是重新去PDF里切一遍。这样最大的好处是完全可重放即使原始PDF后来被修改或丢失系统里留存的快照仍然支撑校验。4.3 校验机制找出张冠李戴的引用引用标记有了还得能验证标记得对不对。这是出厂前最后一道关卡也是我踩过最多坑的地方。我在校审阶段用了三层校验。第一层是对齐校验。检查正文每个引用标记是否都存在于引用映射表是否存在标记了[CARD:p999]但映射表里根本没有这个id的情况。这层校验靠正则就能完成。第二层是语义校验。对每个标记了引用的句子把它和对应卡片的内容做语义相似度计算。如果相似度过低说明模型给这句话挂了不相关的引用。我用向量模型算相似度阈值设为0.72左右低于阈值的句子自动标记为疑似错配。这一层能抓出不少问题但也会有误杀所以只是疑似需要人工确认。第三层是证据链校验。具体做法是把句子里的关键概念术语、数字、方法名抽取出来去原文坐标里做字符串或语义匹配。比如句子说准确率提升了3.2个百分点而对应卡片坐标里的原文并没有这个数字那就判定为证据不足。这一层最严格误报也最多我只在高质量综述发布前启用。三层校验跑完之后系统会产出一份校审清单把无出处句子疑似错配引用证据不足表述三类问题列出来再由人或模型逐条修订。整个过程跑下来一篇50篇文献的综述大约需要20~40分钟其中Map-Reduce生成只占一半时间校验和后处理占另一半。这个时间开销是值得的毕竟学术内容的可信度是第一生命线。5. 实测中踩过的坑与排查方法这部分想认真聊一下那些纸上不会写的坑。以下每一个我都花过至少一个周末来排查希望你能绕开。5.1 主题漂移与骨架漂移主题漂移是综述生成最经典的问题综述前半部分还围绕主题展开后半部分渐渐偏到相邻领域去了。一开始我以为是大模型的注意力问题后来排查发现根因经常出在Reduce阶段的骨架执行不到位。我的修复方式是骨架锚定。具体来说进入每个章节的Reduce之前先把该章节的子主题说明和综述的总主题绑定成一条约束写进prompt本综述的总主题是{topic} 你正在写的章节属于该综述的第二章章节定位是{section_role} 请不要展开与该章节定位无关的内容哪怕素材卡片中有相关内容。另一方面在合并结束后的整合阶段我会让模型做一次主题回归检查给全文打分评估每个段落跟总主题的相关性低分段落被标记出来再进行局部重写。这两板斧加进去之后主题漂移明显减少。还有一种是更隐蔽的骨架漂移——骨架本身在Reduce过程中被模型悄悄改写了。比如骨架要求第三章写对比分析模型在生成时把第三章写成了方法概述。原因在于最终的全文整合步骤里模型面对各章节初稿有自我发挥的空间。解决方案是每次整合都显式携带骨架原文并严格要求章节标题和定位不得变更而不是让模型自由决定。5.2 引用错位与幻觉引用引用错位太常见了。模型明明是在描述A卡片的内容却给句子末尾挂了B卡片的引用或者把一句话拆成两个分句只在其中一个分句挂了引用导致另一个分句变成无出处。我遇到过最离谱的一次综述生成系统里有一篇卡片的作者姓名出现在正文里但正文引用标记指向了另一篇论文。追溯下来是模型在生成时把作者名从一张卡片带进来然后因为标题相似把引用标到了另一张卡片上。这个case靠纯规则很难发现最后是第二层语义校验抓出来的。针对引用错位我总结出一个很实用的经验不要在Reduce prompt里给模型太多自由发挥空间。引用错位的根源是模型在生成时记混了卡片内容。要缓解可以考虑让模型在生成每个句子之前先显式写出本句素材来源卡片ID再写句子本体。这种来源先行的生成方式虽然会让输出速度慢一点、token多一点但能显著提高引用准确率。幻觉引用则是另一个方向的问题。模型发现要求每个核心观点都要有引用为了满足形式要求就会在缺乏对应素材时强行编一个引用。应对方法是把要求改成如果某个观点没有对应卡片请标注[待补充]不要编造引用。配合这个格式要求我在生成prompt里加了负面示例实测幻觉引用降低了六成以上。5.3 上下文爆炸与成本控制学术综述动辄上百篇文献上下文管理是逃不掉的工程问题。我的经验是三层策略第一层是卡片级瘦身。在Map阶段就严格控制卡片长度每个字段限制在200字以内。100篇论文的卡片总量能控制在8万token以内这基本是Reduce的可用边界。第二层是章节级隔离。不要让所有章节共享全部卡片而是先路由、再合并。每一章的Reduce只接触本章节相关的10~20张卡片上下文压力小得多。第三层是分层模型。Map阶段用便宜小模型Reduce阶段用最强的模型。别舍不得这个配置成本差距能到5~10倍。我算过一笔账处理50篇文献的综述全用强模型成本大约是全用轻量模型的6倍但综述质量提升主要来自Reduce阶段Map阶段用轻量模型完全够用。还有一个小技巧是摘要缓存。同一个主题的综述可能隔一段时间重跑Map阶段对同一篇论文的摘要是稳定可复用的。我把卡片的生成结果按论文ID做缓存只有论文库更新时才重新生成卡片。这个改动让二次综述的成本下降了80%。# 缓存目录结构示意 cache/paper_cards/ ├── paper_2023_zhang_etal.json ├── paper_2024_li_etal.json └── ...5.4 其他容易忽略的问题把一些零散但重要的小坑合并到这里。重复表述很常见。不同论文可能表达同一个结论Reduce阶段会把相似结论重复写在多个段落。我在整合阶段加了一个全局去重步骤用相似度比较来检测重复段落如果两段内容高度重合就合并成一段并保留两个引用。术语不统一也很烦人。同一个概念有的论文叫A有的叫B模型在综述里可能一会儿用A一会儿用B。我在整合阶段会传入一份术语表包括主题领域内必须统一使用的标准术语列表并要求模型全文统一。如果术语表还没整理好临时可以先让模型在输出里自动标注下文统一使用XX表述。最后是引用编号的稳定性。如果在生成的任何一步重新跑Reduce卡片ID可能变化导致引用映射表错乱。我的对策是卡片ID用论文ID哈希值生成而不是用自增序号。这样即使重跑流程同一篇论文的卡片ID也保持不变引用映射表不会乱。6. 效果评估与维护建议最后聊聊怎么评估这样一套系统以及上线后怎么持续维护。评估做不好前面所有优化都像在盲人摸象。6.1 评测指标怎么定学术综述生成的评估不能只看BLEU或ROUGE这种文本相似度指标。文本相似度对长文生成几乎没有区分度两篇结构完全不同的综述可能有接近的ROUGE分数但信息覆盖和质量天差地别。我自己的评测体系包含四个维度覆盖度综述正文中提到的重要观点占参考综述或人工标注观点列表的比例。这个指标直接反映Map阶段有没有漏信息。出处覆盖率带有有效引用标记的句子占全部实质性论断句子的比例。低于90%基本不能上线。引用准确率抽样检查引用标记与句子内容的匹配比例。人工抽100个标记看有多少个对应的卡片内容能支撑句子论断。忠实度用蕴含模型判断综述句子是否被对应卡片文本蕴含。这个指标最严格也最接近人工审核的视角。上线前我会准备一份固定题干的小测试集包含不同难度、不同文献数量的综述主题。每次改完系统都跑一遍对比指标变化。这个测试集不用太大6~10个主题就够但必须覆盖单一方法综述争论性综述跨领域综述三种代表性场景。我还建议加一个失败case复盘环节。每轮评估后把指标下降的case挑出来分析是哪一段出了问题。你会发现很多时候问题不在生成模型而是检索漏召回或者卡片抽取出错。这类复盘比盲目调prompt有效得多。6.2 上线后的监控与常见维护项系统上线不是终点。我把日常维护需要盯的几个点列在这里。检索质量监控记录每个综述主题的召回命中率尤其是人工确认应该被召回的论文是否真的被召回。如果发现某类主题频繁漏召回需要补充同义词表或微调向量模型。卡片质量抽检Map阶段产出的卡片会被反复使用质量一旦劣化会持续影响后续所有综述。我每个月抽5%的卡片做人工检查重点看字段是否完整、是否有编造内容。引用映射表一致性检查长时间运行后论文库更新可能导致引用映射表和实际文献对不上。我写了一个定时脚本每天检查映射表中论文元数据是否仍然有效。性能预警综述生成是长任务正常情况50篇论文跑完全流程在30分钟内。如果发现耗时翻倍大概率是某一步卡住了或者模型服务变慢需要及时告警。还有一条关于用户反馈的体验建议给最终读者提供点击引用返回原文的交互入口并且收集读者是否点击过引用作为信号。如果大量读者在某个章节频繁点击引用进行核对说明该章节的可信度可能有隐性问题值得优先复查。一点个人总结这套Map-Reduce 出处追踪的方案本质上是把综述写作这个复杂任务拆成了消化文献和组织表达两个环节让每个环节各司其职。Map阶段解决信息覆盖和源头可信Reduce阶段解决结构组织和逻辑连贯出处追踪则把两个环节绑定在一起形成一条可追溯的证据链。做了几个真实项目之后我最大的体会是学术综述生成的核心难点从来不是让模型写出一段通顺的文字而是让模型写的每一个字都有根有据。Map-Reduce是手段出处追踪是底线。如果你也要做类似系统我的建议是先跑通50篇以内的小规模流程把引用准确率做到90%以上再考虑扩大到100篇以上。不要一上来就追求大而全先把每一句话都能回放到原文这个基本功打好后面的事情会容易很多。