★ FEATURED ARTICLE 1. 通用大模型写论文时的失手根源在于三种错位这几年我一直在帮某高校课题组搭论文写作辅助系统几乎所有常写学术文章的同事都有同一个困惑大模型在闲聊、翻译、写周报的时候那么好用怎么一让它正经产出论文底稿就开始编引用、跑偏主题、术语也总差一口气这个问题其实是很多垂直项目起步时都会撞上的墙。我先把结论放在前面通用大模型没有你课题组的私有文献它的知识是被压缩过的公共知识且压缩过程完全不考虑学术写作对“可溯源”和“时效性”这两个硬指标的要求。想让它写出真正能用的论文内容光靠它在对话里“发挥”是不行的必须给它外挂一个可信的资料库并在生成时强制约束它只能基于这个资料库作答。这正是RAG检索增强生成在Vertical AI里最典型的落地场景。但在聊架构和代码之前我建议先花点时间搞清楚通用模型为什么会失手。方向没看明白后面调什么参数都是碰运气。1.1 知识截止日期带来的“过时感”与领域空洞通用大模型的训练数据有一个截止时间点。对学术写作来说这不是小事。一个做材料计算的朋友跟我说他让模型推荐某类合金的最新表征方法模型给出的方案还是三年前的主流路线而他们领域去年已经换了好几轮范式。模型没有错它只是没有更新过这块知识。更隐蔽的问题是领域空洞。通用模型为了覆盖全世界的常识会在每个具体专业方向上只保留一个“平均印象”。你问它“什么是扩散模型”它能说得头头是道你问它“某个具体数据集上某篇经典文献的预处理细节”它就开始含糊。这不是模型笨而是参数分配决定的几千亿参数要分摊到几乎所有学科和业务场景落到某一个二级学科下的有效容量可能只有几十亿参数的当量。反过来如果你用一个几亿参数的垂直小模型只学某一类文献它在术语召回和概念相关性上的表现往往比通用大模型更稳定。这也是垂直AI的核心逻辑——不是追求全知而是追求在特定领域内可靠。1.2 幻觉在学术场景里完全不可容忍大模型的幻觉在闲聊时叫“有创意”在写论文时叫“学术不端嫌疑”。通用模型的目标函数是让对话看起来流畅合理它并不在乎某个引用是不是真的存在。结果就是它会非常自信地编造一篇压根不存在的文献连作者名和期刊卷期都编得像模像样。我以前做过一个测试让某通用模型写一段关于某个冷门理论的发展综述并给出不少于五个参考文献。它给出的参考文献里只有两条能搜到真实论文剩下三条完全是“缝合怪”——把不同论文的作者、标题和期刊随机拼在一起。这在学术写作里是致命的。论文不是散文每一句话背后都要站得住脚每一个引用都要能被读者验证。通用模型天然不具备“验证”这个动作它只会“生成”。因此你在搭垂直写作系统时必须把这个验证环节放在架构层面而不是依赖提示词去祈祷。1.3 学术规范与领域习惯的语言错位第三个错位常被忽略论文写作有严格的文体要求、术语习惯和论证结构。通用大模型接受过海量互联网文本的熏陶更容易写出“公众号风格”的段落——短句多、排比多、观点先行但论证单薄。垂直领域的学术写作要求是另一套逻辑方法部分要可复现结果部分要克制讨论部分要对照前人工作。这些东西不是靠模型“懂道理”就能做到的它需要模型在回答时手边真的有一堆格式规范的期刊论文作为仿真模板。所以结论其实是三句话论文写作需要私有知识注入、需要引用可溯源、需要领域文体约束。这三件事恰好都是通用大模型本身不提供的。那怎么办两个主流路径微调和RAG。下面我展开聊为什么论文写作场景更应该优先考虑RAG。2. 论文写作场景为什么非得上RAG而不是拼命微调做垂直AI的人一上来就会碰到路线选择是收集一批领域语料把大模型微调成“领域专家”还是走RAG让模型在推理时检索外部知识我的经验是两者不冲突但要分清各自解决什么问题。在论文写作这个场景RAG一定是地基微调只能是锦上添花。2.1 微调与RAG的边界一个解决“怎么答”一个解决“答什么”我习惯用一个很土但好记的分法微调是训练模型的气质RAG是给模型递资料。微调擅长改变模型的表达风格、输出格式、思维链模式。比如你希望模型总是先复述问题、再分三部分回答、最后列出局限这些约束性习惯可以通过微调强化。但微调有一个硬伤它把知识写死在权重里。课题组每个月都有新文献进来导师的批注和修改意见也在不断累积你不可能每周都花成本重训一次模型。而且微调之后模型依然会幻觉因为它本质还是在“回忆”而不是在“查看”。RAG的思路完全不同。它把知识外置成一个动态更新的资料库模型回答问题时先从资料库里检索相关片段再基于这些片段生成答案。文献更新了你只需要往索引库里加数据模型的表现立刻就能跟上不用重新训练。下面这张表是我自己在项目选型时常用的对比维度直接列出来方便大家参考对比维度微调RAG知识更新成本需要重新训练周期长更新索引即可分钟级生效引用可溯源很难模型不会告诉你依据哪篇文献天然可溯源回答绑定检索片段来源幻觉控制依赖训练数据质量仍会编造生成阶段限定在检索片段内大幅降低编造概率领域风格塑造很强输出格式高度可控需要对提示词做约束效果相对弱一些冷门知识覆盖取决于训练数据里有多少取决于知识库里有多少部署与迭代成本高需要GPU训练较低主要成本在向量化和检索对论文写作这种“答案必须能站住脚”的场景答案的来源比答案的流畅度重要得多。所以我把RAG放在架构的核心位置微调只用来做辅助性的格式约束。2.2 RAG的三个环节索引、检索、生成到底在做什么RAG听起来玄乎拆开看就是三段流程清洗切分文档并建立向量索引根据用户问题召回最相关的片段把片段连同问题一起交给大模型生成答案。索引阶段的重点是“怎么让电脑记住文档”。论文PDF不能直接扔给模型得先解析成文本按一定策略切成小段每一段通过embedding模型转成一个向量。向量是一串数字语义相近的文本在向量空间里距离也近。这一阶段决定了系统后续能不能“找到”内容。检索阶段的重点是“怎么把最相关的内容捞出来”。用户提问后系统把问题转成同样的向量去向量库里做相似度搜索返回最接近的片段。这里有很多可调参数后面我会专门讲我实测过的参数组合。生成阶段的重点是“怎么让模型只照着资料说”。你不能把一大坨检索片段直接塞给模型就完事必须设计清晰的提示词结构让模型明白只许使用提供的片段回答并在对应句子后面标注引用来源编号。没有对应片段支撑的内容模型必须明确说“资料库中未找到”而不是自己脑补。三个环节环环相扣。检索环节如果召回了一堆无关内容生成环节再怎么修剪都是徒劳。很多时候大家觉得RAG“效果不好”其实问题多半出在索引和检索这两个前置阶段而不是模型本身。在开始动手搭系统之前还要先说清楚一个容易犯的错别把RAG做成“先检索再整段塞给模型”。一个高质量的知识库往往有几十万段文本检索出来top 5或者top 20只是候选必须让生成阶段感受到“资料约束”而不是“资料轰炸”。我见过一个早期版本把20个片段全部塞给模型结果模型被无关信息干扰回答质量反而下降。后来我们只保留5个高相关候选并增加rerank精排效果显著提升。这个细节后面会专门展开。3. 落地RAG的工程骨架从语料清洗到生成链路接下来说实操。我按我们自己在某文科课题组和某工科实验室里实际跑通的流程来写尽量给可直接复用的经验。3.1 数据源选择与文档解析RAG的效果上限由知识库决定。对一个论文写作辅助系统我把数据源分成了三类核心文献库领域内的经典论文、近期高质量期刊文章、综述。这是回答“领域里前人做了什么”的基础。过程资料库课题组内部的技术报告、实验记录、会议PPT、开题报告。这些私有资料是通用模型完全没有的优势。规范资料库目标期刊的写作要求、术语表、参考文献格式规范。这决定输出是否“像样”。三类数据源里最容易出问题的是PDF解析。学术PDF常见双栏排版如果直接抽取文本段落顺序会乱掉公式和图表区域常常被解析成乱码页眉页脚还会混进来污染正文。我的建议是优先选择有结构化文本来源的数据比如期刊官网的XML版本、作者提供的Word版本实在只有PDF时再用解析器并加一道人工抽检流程。公式部分尤其是重灾区宁可标记为“公式区域”跳过也不要让它变成乱码混入正文否则后续embedding会被严重干扰。3.2 文本切分chunk策略的第一课文本切分是索引阶段最容易被低估的环节。切得太小一段话表达一个完整意思时被拦腰截断检索到的内容不完整切得太大一段里塞进太多主题向量被平均化检索相关性下降。我常用的切分策略是按语义段落切辅以固定长度兜底。具体来说优先按段落边界、标题层级切分保证每个chunk是一个相对完整的语义单元。设定最大长度比如512 token超过上限则按句号或分号二次切分。相邻chunk之间保留一段重叠比如80 token避免关键信息正好落在边界上被截掉。下面是一段我当时调试用的简化Python伪代码思路可以直接复用def split_document(text, max_tokens512, overlap_tokens80): # 先按段落粗切 paragraphs [p.strip() for p in text.split(\n\n) if p.strip()] chunks [] current for para in paragraphs: # 估算token数这里用字符数近似 if len(current) len(para) max_tokens: current \n\n para else: if current: chunks.append(current) # 保留current末尾的overlap部分作为新chunk开头 overlap current[-overlap_tokens:] if len(current) overlap_tokens else current overlap \n\n para if current: chunks.append(current) return chunks这里我必须强调一个实测中反复踩过的坑不同领域的文档最佳切分策略差得很远。实验方法类论文段落界限明显按段落切效果很好政策分析类报告动辄一段几百字必须再做二次切分综述类文章小节内部逻辑紧密可以把整个小节作为一个chunk。没有一套参数通吃所有场景最好的做法是先小批量抽几十篇文档人工检查切分结果再决定策略。3.3 Embedding选型与向量索引建立切好的片段要转成向量。embedding模型的选择直接决定检索效果的基本盘。我们实验时对比过通用领域的embedding模型和领域微调过的embedding模型在材料学文献上的向量召回命中率能差十几个百分点。对学术场景我建议按这个优先级选先找是否已有针对本领域微调过的embedding模型没有的话用主流通用embedding暂时不要自己训练成本太高而且效果未必更好。向量维度方面常见的有768维和1024维。维度高代表表达能力强但检索速度慢、存储占用大。一个中等规模课题组的知识库一般在几十万到几百万chunk之间768维完全够用。向量索引我用的是常见的开源向量库支持HNSW这类近似最近邻索引。建立索引时有一个数据量大以后才会碰到的教训一定要按数据来源打标签。向量库里每条记录除了向量本身还要保留元数据字段比如文献标题、作者、年份、来源类型、所属方向。这不仅是后续做元数据过滤的基础也是引用溯源必须要的信息。3.4 生成链路的提示词约束检索做得再好生成提示词没约束住模型还是可能放飞自我。我们最后沉淀下来一套结构化的提示词模板核心思路是“角色资料区强制规则”。角色部分告诉模型它是某领域的写作助手资料区用明确的XML标签包裹检索片段并给每段编上序号强制规则里写死三条只能依据资料区中出现的信息作答禁止使用资料区之外的常识补充。每一个关键论断后必须用[来源编号]标注出自哪一段资料。如果资料区没有任何信息能回答当前问题直接回复“资料库中未找到相关内容”禁止编造。这三条规则并不复杂但它们在工程上很重要它们把“生成质量”这个模糊问题转化为一个可检验的“引用是否真实存在”的问题。后面做评测时这两条规则帮了大忙——我们可以自动检查模型输出的引用编号是否真的存在于检索结果中从而快速判断系统是否在瞎编。4. 检索质量才是RAG的命门我这几个月实测过的参数组合我在项目中期曾经陷入过一个状态生成提示词调得很精细模型输出看起来也流畅但让懂行的人一读立刻发现好几处关键信息不在点子上。后来我把问题定位清楚了——生成环节没有错错的是检索环节把不合适的片段捞上来了。这一章我把那段时间反复调整的参数和教训整理出来。这些结论不一定对所有领域成立但方法论是可以直接迁移的。4.1 chunk大小对检索召回率的真实影响我做过一组对照实验固定其他参数不变只调整最大chunk大小看同一批问题在某一领域文档集上的召回命中率变化。结果大致如下基于我们内部某材料分类文档集测试数值仅供趋势参考chunk大小召回命中率上下文完整性备注256 token78%较差很多句子被切断信息碎片化512 token84%中等整体均衡但段落衔接偶尔断裂1024 token73%较好单块语义太杂检索精确度下降结论很明确不是越大越好也不是越小越好512左右是多数场景的甜点区。但边界条件要再强调一次如果你们的文献句式很长、一个段落里包含多个完整论证适当调大如果文档以摘要类短文本为主调小到256反而更准。4.2 混合检索关键词与语义向量的互补纯向量检索有个天然盲区它擅长语义相似但未必擅长精确匹配。比如用户检索“2023年某方法的最新改进”向量检索可能找到一大堆“方法”相关的泛泛内容却不包含“2023年”这个硬性过滤条件。反过来BM25这类关键词检索擅长精确匹配却理解不了同义词和上下文意。所以我在生产环境里用的是混合检索同时跑一遍BM25关键词检索和一遍向量相似度检索然后把两组结果做加权融合。权重我最后定在BM25占0.35、向量占0.65这一比例在我测试过的几个领域里都比较稳。另外关键词检索最好做一次简单的同义扩展比如“神经网络”可以扩展出“深度学习模型”“网络结构”能明显提升召回。4.3 召回之后再做一次精排rerank的必要性很多RAG系统走到混合检索就结束了直接拿top-k结果丢给生成模型。我认为这对于论文写作场景是不够的。向量检索的粗排结果往往混杂着好几类“看着像但实际上只是相关但不够精确”的文本。我们做过统计top 20的混合检索结果里真正高价值的片段可能只集中在其中五六个。我的做法是再加一层rerank精排先让向量检索和BM25各召回20到30个候选合并去重后用一个交叉编码器对“问题候选片段”逐对打分重新排序最后只取得分最高的5个片段输入生成模块。这层精排的收益非常大。一个直观的测试结果加了rerank之后领域专家对生成内容“关键引用是否合适”的评分提升了大约百分之三四十。而增加这一层的代价只是一次额外的模型推理延迟增加一两百毫秒在论文辅助写作这种非实时场景里完全可接受。4.4 元数据过滤把不该出现的片段提前隔离最后一个检索优化点是元数据过滤。对论文场景来说这是必须做的否则会出现很尴尬的事用户问“近两年有什么新进展”结果系统检索出十年前的一段文献还标着【最新进展】。我的方案是给每个chunk打上完整的元数据标签包括年份、文献类型、研究方向、是否核心文献、来源库等。检索的时候先根据用户问题的意图判断是否需要过滤条件再在向量检索之前把不符合条件的chunk直接排除掉。比如用户问题里出现“最近”“近年”这类时间词就限定年份大于某个阈值用户问“方法论”就只检索方法类文献跳过综述类内容。这一步最难的不是实现而是判断用户当前提问的过滤意图。我们用的是一个小分类器专门识别问题中是否包含时间限定、方法限定、文献类型限定等意图准确率在内部测试集上接近九成。剩下的模糊场景宁可少过滤不可过滤错——漏召回总比错隔离好补救。5. 让RAG真正可用的三个工程细节引用溯源、拒答策略与评测闭环检索和生成都跑通系统看起来能回答问题了但这距离“真正能辅助论文写作”还差最后三件事。这三件事不做好系统就只是一个漂亮的Demo学术用户不敢把它的输出写进论文里。5.1 引用溯源让每一句话都能找到出处前面提到生成提示词要求模型在每个论断后标注[来源编号]。但这个机制一定要在工程上做到闭环——模型标注的编号必须能对应到实际检索到的chunk并且这条chunk必须能回溯到具体的论文来源。我们的实现是在向量库的每一条记录里保存一个完整引用链document_id、论文标题、作者、发表年份、所在期刊、原始文件页码。生成模型返回的答案如果带有来源编号系统就在返回结果中额外附带一个来源列表用户点击编号就能看到原始文本和完整的文献信息。工程上还有一道硬校验答案中出现的所有[来源编号]必须存在于本次检索返回结果中。如果模型擅自编了一个编号比如写了[7]但检索结果里只有5段资料系统会直接判定生成失败要求重新生成而不是把带病内容交给用户。这个校验逻辑简单但挡住了绝大多数幻觉内容。5.2 拒答策略不知道就是不知道学术写作里最怕的不是“答得不够好”而是“假装知道”。RAG系统的一个先天优势是如果知识库里确实没有相关内容检索结果的相关度会整体偏低。这是可以量化判断的——向量检索返回的相似度分数如果低于某个阈值就说明“没找到可信依据”。我们在这个阈值上做了两个月的人工标定。做法是找一批领域内的老师和博士生让他们标记“哪些检索片段可以用来支撑回答”然后统计这些标注为可用的片段的相似度分数分布把拒答阈值设在略低于最低可用分的位置。设置完之后系统面对冷门问题时不再硬撑着给一段模棱两可的回答而是直接提示“当前资料库中缺少与该问题直接相关的文献建议补充以下关键词的资料……”。这个“建议补充资料”的细节很受欢迎因为它把系统的能力边界变成了一个知识库优化的行动清单而不是一个简单的失败报错。5.3 评测闭环离线指标和人工抽查一起上RAG系统上线之后最大的挑战是怎么持续知道它好不好。我们搭了一套双轨评测机制。离线指标是自动化的准备一批领域问题每个问题标注了正确答案对应的文献片段。系统回答后自动计算检索召回率Recallk、排序指标MRR、引用准确率生成的引用编号是否都对得上。每周跑一次回归任何参数调整都先过这轮指标防止“修了A坏了B”。人工抽查是每两周做一次的从近期真实用户的提问中随机抽几十条让博士生和导师按“内容准确性”“引用合适度”“语言学术性”三个维度打分。人工抽查不追求高频但它能发现离线指标看不出的问题——比如模型虽然引用了正确的文献但表述逻辑完全是错的又比如引用的是相关文献但不是最优的那一篇。两轨结合的好处是离线指标给了我们对系统的定量信心人工抽查则保证定性方向不跑偏。任何一次大版本调整如果没有同时通过这两道关卡我是不会让它进生产环境的。最后聊一个这几个月下来我最深的体会。做Vertical AI的RAG技术上的难点其实不在模型而在**“领域工程”**——你得花大量时间去看文献结构、去理解学术写作的规范、去跟真正写论文的人反复确认他们的检索习惯和引用偏好。通用大模型写不好论文这件事从模型层面看是知识缺口从工程层面看是知识接入方式的问题。RAG解决的不是“让模型更聪明”而是“让模型有边界的聪明”。边界画在哪里、怎么画这就是垂直AI团队的功课了。一个小建议如果你的团队刚开始搭这类系统别急着追求大而全。先找一个小方向人工准备几百篇高质量文献把索引、检索、引用溯源这条链路跑通再逐步扩库。知识库不用大重点是把链路调稳体验做透。这个方向上的积累比盲目堆数据有用得多。
阅读完成 · 觉得有帮助？
