收到好几个做科研的朋友私信都在问同一类问题文献读了一大堆研究问题还是提炼不出来好不容易写了个大纲审稿人一句话“论证不足”就给你打回原点。我自己也经历过这种阶段所以当我把“好写作AI”这个项目做完之后最大的感触就是学术写作里那些“只可意会”的功夫终于有一部分可以变成“可量化、可复现、可调用”的工具了。这个项目做的是两件事——第一从一堆原始材料里自动提炼出真正有价值的研究问题第二围绕这个研究问题自动构建一套逻辑完整的论证框架。简单说就是把“想清楚要研究什么”和“想清楚怎么证明这件事”这两个最费脑子的环节交给深度学习模型来辅助完成。这篇文章不打算讲那种ppt式的项目介绍我会把这套系统从需求拆解、技术选型、数据构造、模型训练到落地时踩过的坑、调参的经验、评估的教训全部摊开来讲。项目本身适合谁看呢如果你在做类似的文本生成系统、学术辅助工具或者你就是想搞明白“研究问题提炼”和“论证框架生成”这两个任务到底应该怎么做那这篇应该能给你省下好几周自己摸索的时间。1. 项目概述与需求拆解很多人在做AI写作工具时第一反应是“直接调一个大模型API不就行了吗”这是典型的没拆解清楚问题就动手的表现。学术写作辅助和普通写作辅助最大的区别在于它要的不是“通顺”而是“结构成立”。所以我一开始就把这个项目的目标拆成了两个独立又强相关的子任务研究问题提炼和论证框架构建。这两个子任务各有各的难点混在一起做只会让模型两头都不讨好。1.1 学术写作的三大痛点从“没想法”到“没结构”先说第一个痛点研究问题提炼。任何一个写论文的人都知道研究问题的重要性但问题是这东西怎么来很多新手是拿着题目硬想或者从文献里东抄一句西抄一句。真正的做法应该是从“文献综述”和“现有方法局限性”中自然地涌现出一个问题。但让一个硕士生或者刚入门的研究者自己完成这个过程效率极低。读了几十篇论文最后让他写“本文要解决什么问题”写出来的东西还是又空又泛。这里有个很微妙的点用大模型直接生成研究问题生成出来的往往都是“提高准确率”“降低计算复杂度”这种废话因为它缺少对“这个具体领域的研究边界”的理解。研究问题不是凭空生成的它需要先理解现有研究在哪里停住了才能往前走一步。这就是自动提炼的第一层难点模型要能从材料里识别出“现有工作的边界”在哪里。第二个痛点是论证框架的组织。研究问题定下来之后怎么向读者证明这个问题确实值得解决、你的方法确实有效这中间需要一条逻辑链从问题出现的背景到已有的尝试到这些尝试的不足再到你的切入思路最后到验证方案。这一条链在脑内想清楚不容易写出来更不容易。很多论文写得乱不是文字功底差而是内部逻辑链没有拉直。我们读论文时感觉到“这个作者思路不清”本质上是他没有做好论证框架的构建。第三个痛点是“写作习惯的不可迁移性”。每个研究者的思维习惯不一样有些人是跳跃型有些人是线性型。一套论证框架模板换到另一个人身上往往就不适用了。这意味着工具不能只给一个固定模板它得有“从用户的零散素材中识别论证脉络”的能力。这三点加起来就是我把任务拆成两个子任务的底层原因。1.2 技术方案选型为什么自建模型而不是直接套壳我在项目初期确实试过直接用通用大模型的API来跑这两个任务效果怎么说呢——能用但不能用。为什么这么说通用模型的优势是知识面广、语言组织能力强它能在三秒内输出一段像模像样的“研究问题”但你细看就会发现问题重重它生成的研究问题要么过于宽泛要么与用户输入的材料脱节要么基本是“为了提问题而提问题”根本没有从材料的逻辑断裂处出发。至于论证框架通用模型输出的框架在表面上结构完整但细看会发现很多分论点之间没有实质性的逻辑推进关系属于“结构上成立、语义上空洞”的典型症状。自建模型的优势有三个。第一可控性。我可以精确控制输入格式、输出约束、解码策略对“研究问题”这类高价值输出做结构化的约束。第二数据闭环。我可以自己构造训练数据针对学术写作这个特定场景做定向优化而不是把希望寄托在通用模型的隐含能力上。第三成本。项目做成之后要反复调用自建模型跑在自有推理环境上单次成本可以压到很低的水平长期看划算得多。当然完全从零预训练一个模型不现实。我的方案是在一个开源的中型预训练语言模型大概7B到13B这个量级基础上做全参数微调和指令微调。选这个量级的原因很朴素学术写作任务需要比较强的语义推理能力太小了1B到3B逻辑能力不够太大了70B以上训练和推理成本都承受不起。7B到13B这个区间配合适配的微调策略可以把专业任务做得相当好而且推理速度基本可控。2. 研究问题自动提炼的实现细节研究问题自动提炼是整个项目里我认为最有价值也最难啃的一块。难在哪里因为它本质上不是一个纯生成任务而是一个“判断生成”的结合体。模型必须先判断“材料里有哪些潜在的逻辑断点”再判断“哪个断点最值得深入”最后才能生成“一个具体、可验证的研究问题”。这三步中的任何一步做不好出来的问题就是废的。2.1 整体建模思路抽取与生成的融合设计我采用的方案是把研究问题提炼拆成两个阶段。第一阶段是一个抽取模块负责从输入材料中抽出“已有方法的关键点”和“被忽略的限制条件”。第二阶段是一个生成模块负责把这两个抽取结果融合成一句连贯、具体的研究问题。为什么要拆因为如果直接让模型从原文生成问题它容易把原文里已有的句子改头换面抄一遍产生“伪原创”。抽出来再融合至少能保证“生成的问题在内容要素上确实来源于原文”不会跑偏。抽取模块的输入是用户提供的材料文本可能是一段文献综述可能是几条要点记录甚至可能是一堆零散的想法。我会先把材料做成“句子列表”然后对每个句子打标签。标签体系设计成三类方法句描述了一种已有方法或已有结论限制句描述了这个方法或结论的局限性其他句跟这两个类别无关的内容这个抽取任务我用序列标注来解模型输入是拼接了分类提示的句子序列输出是每个句子的标签。模型用的是编码器-解码器架构解码时用约束解码保证每个标签只能从预定义集合里选。抽取模块训练完毕后它的作用就是把“这个领域里已经有啥还缺啥”这两类关键信息从长篇大论里拎出来。这个过程很像考古现场的工作把陶片分类有的属于容器有的属于武器分类清楚之后文物流传的脉络才显现得出来。抽取完成之后进入生成阶段。生成模块的输入是一个结构化提示词里面包含两个槽位已有方法列表从抽取模块输出中整理限制条件列表同样从抽取模块输出中整理。格式大致是已有方法方法列表 已知限制限制列表 任务基于以上信息提炼一个具体的研究问题。要求问题必须涉及上述一个或多个限制问题必须在已有方法基础上前进一步问题不能是宽泛陈述。生成模块用的是同一套预训练模型做指令微调训练数据里我刻意加了不少“负面样本”即那种宽泛的、不具体的伪研究问题。这样做的好处是模型会逐步学会避开“提高效率”“改进性能”这类空话转而生成具体的、可运作的问题。比如输入材料是“现有图像分割方法在小目标区域上准确率下降明显”模型生成的研究问题不会是什么“提高分割准确率研究”而会是“如何设计一种针对小目标区域的上下文增强机制在保持大目标分割精度的前提下缩小小目标分割误差”。区别就在这一个是口号一个是可执行的问题。2.2 数据准备从论文库中自动构造训练数据数据是这种任务的命根子。但问题来了做研究问题提炼的标注数据要想人工去标成本高到不现实。我的做法是两步走。第一步利用公开的学术论文数据库从每篇论文的“引言”部分和“摘要”部分自动提取“研究问题句”。这些句子通常有比较强的句式特征比如“本文旨在解决”“本工作重点关注”“This paper investigates”用规则抽取加人工抽检的方式可以先拿到一批可用的训练语料。第二步对这批语料做“数据增强”方法也很实用把每篇论文中的“已有方法描述段落”和“限制条件描述”手动标注一小批训练出一个初版抽取模型再用这个初版模型去标注更大规模的数据。这也就是常见的“自训练”思路但要注意一个重要细节——初版模型标注的结果必须抽检不能直接全量信否则错误会滚雪球。为了让它训练得更精准我还运用了一个“正负例对”构造技巧。对每一条研究问题我生成两个负例一个是把研究问题中的具体方法变量替换成随机词另一个是把研究问题中的范围限定去掉变成宽泛陈述。这样训练出来的生成模块对“问题不具体”“问题宽泛”这两种错误会更敏感。从结果看这个技巧对最终生成质量的提升非常明显甚至比增加参数量的效果更好。模型的具体参数配置方面我的实践经验如下表所示配置项值说明基础模型7B因果语言模型在训练成本可控前提下的最低选型微调方式全参数微调同时微调注意力层与输出层学习率2e-5warmup占比5%太高容易抖动太低收敛过慢训练轮数3轮早停条件为验证损失提升0.5再多轮数会产生过拟合最大序列长度2048覆盖论文段落级输入解码策略训练时teacher forcing推理时beam searchbeam4研究问题输出要求稳定、低风险训练数据量约12万对含增强与负例正负比约2:1训练过程用的框架是业内的常用分布式训练方案四卡并行的条件下7B模型训练一轮大概耗时一天半总共花了两周时间跑完全部训练流程。这里面有一个值得说的经验first run不要一上来就跑最大数据量先拿10%的数据跑通全流程验证数据管道和loss曲线的正常性确认无误后再全量跑。很多人忽视这一步结果在训练了一周之后才发现数据里有标签错位的问题那才是真的欲哭无泪。2.3 模型训练中的关键取舍训练这类模型有几个容易踩的细节我挑三个最关键的讲。第一个是损失函数的处理。一般生成任务用的都是交叉熵损失但在这里只计算研究问题部分文本的损失而提示词和输入材料部分不参与损失计算。这个东西在代码实现上是个很小的细节改一行mask即可但效果差别巨大。如果不加mask模型会花大量参数量在“模仿输入的格式”上面而不是在“学会怎么生成好的研究问题”上面。第二个是解码超参数的设置。生成研究问题时temperature设置在0.7到0.8之间是比较合适的区段top_p设置在0.9左右beam大小为4。大家可能会觉得生成式模型可以有更多创造性所以调高temperature。但实际经验是对于学术文本这种高风险输出来说创造性适可而止稳定优先。如果temperature太高同一段材料反复生成会得到语义漂移明显的问题陈述这在实际使用中非常影响体验。第三个是前缀提示的一致性。我要求所有训练样本和推理样本的问题前缀必须完全一致不能训练时用“研究问题是”推理时写个“提炼的问题为”。模型本身对输入前缀很敏感差一点都不行。这点很多教程里不讲但实际中至少能差5-10个百分点的质量。3. 论证框架构建的实操过程研究问题提炼出来之后接下来就是论证框架构建。如果说研究问题是论文的“靶心”那论证框架就是“弓”。弓的构造决定了你能不能有力地把箭送到靶心上。这部分我采用了“模板与生成结合”的混合方案。为什么不直接用纯生成模型因为论证框架有比较强的结构惯性它不像研究问题那样需要发散它更讲究“逻辑关系的正确承接”。纯生成模型容易把结构写歪模板驱动又不够灵活。混合方案是让模型先理解用户素材中的关键论点再根据一个结构化的“逻辑骨架”去填充内容。这样做既保证了结构可靠又保持了内容的适应性。3.1 论证框架的表示从“逻辑骨架”到“内容槽位”我用一套结构化的表示方法来描述论证框架。一个标准的论证框架包含七个模块背景、已有研究、已有研究不足、研究切入点、研究方法、预期结果、研究意义。这七个模块不是凭空设计出来的它是我分析了一百篇优秀论文的引言和核心章节之后归纳出的共模结构。现实里当然不是每篇好论文都严格按这个顺序写但绝大多数优秀论文的信息要素都能映射到这套结构上这已经足够支撑框架生成任务了。在做实现的时候我把这套七模块结构设计成一个三层树状结构根节点是“研究问题”第二层是七个功能模块第三层是每个模块下的“论证点”每个论证点需要包含两样东西——论据从原始材料中引用的事实性信息和逻辑关系标记因果、转折、递进、并列。按照这样的表示方式模型需要完成的任务就很具体了它先接收研究问题和一个“论据池”用户提供的素材内容然后从论据池中筛选相关的论据再把这些论据按“功能模块”和“逻辑关系标记”组织成一棵论证树。这个任务在NLP领域可以建模成一个“结构化生成”任务比自由文本生成的约束更强、确定性更高。3.2 论证树生成的实现与配套模板在具体实现里我把论证树生成分成了三个子步骤。第一步是论据分类对论据池中的每一条素材做分类推断它最可能属于哪个功能模块这个用的是游走式的分类思路先根据文本向量表示检索最接近的模块主题再用一个小分类器做置信度打分得分低的放进候选池不强行分配。第二步是模块内排序在同一个功能模块内部的多个论据要依据逻辑关系标记进行排序比如“因果”关系里的前提应该在结论之前“转折”关系里的铺垫应该在前。这一步我用的是一个基于transformer的排序模型输入一对论据加一个关系标记输出谁在前面、谁在后面。第三步是框架脱出如果用户已有的素材不足以支持某些模块的论据填充模型会基于研究问题本身和已有论据做一次最小限度的事实性推理扩展生成一个“推测型论据”同时专门标注“这是推测内容请人工核实”。我认为这个细节非常重要它让工具不越权也让最终的技术负责任地落在用户身上。光有结构还不够还要把树形结构翻译成自然语言段落。我设计了一个配套模板系统每个功能模块下有对应的段落开头模板。比如“已有研究不足”的段落开头可以是“尽管上述方法取得了显著成效但在……方面仍存在明显局限”。模板是基础但不会直接用模板套死模型生成的内容会把模板与论据的具体内容融合起来在模板框架下重写为自然段落。这个方案的执行效果我比较满意。用几个真实的用户输入场景来测试输入一段关于某个领域研究现状的素材模型生成出来的论证框架段落前后逻辑是清楚、可读的。不夸张地说我有一次把生成的框架段落直接发给一个朋友冒充自己写的内容他竟然在微信里说“这学期思路确实通透了”。当然这是开玩笑的但至少说明这套框架的落地效果还是有竞争力的。下面是两个核心提示模板的示例提供给大家参考。研究问题生成的提示模板输入材料{用户输入的文本} 已有方法{算法一}、{算法二}、{算法三} 已知限制{因素一}、{因素二} 任务基于以上信息提炼一个具体的研究问题。要求问题必须涉及上述一个或多个限制问题必须在已有方法基础上前进一步问题不能是宽泛陈述。论证树生成的提示模板研究问题{生成的研究问题} 论据池{用户提供的素材列表} 请完成 1. 将每个论据归入以下模块背景、已有研究、已有研究不足、研究切入点、研究方法、预期结果、研究意义。 2. 对每个模块内的论据进行时序排序。 3. 识别并标注论据之间的逻辑关系因果/转折/递进/并列。 输出格式以JSON树结构输出节点包含模块名、论据内容、逻辑关系标记。3.3 评估指标只盯ROUGE不够结构完整度同样重要做生成项目评估是老大难问题。很多文本生成项目只盯着ROUGE值实际是懒政。ROUGE衡量的是词语重合度但完全不衡量逻辑结构是否正确。我搭建了三个维度的评估体系每一个维度都从不同角度反映框架生成的成败。第一个是内容覆盖度计算生成的论证框架里有多少关键信息点是来自用户素材的采用召回式的计算方式理想值在0.8以上。第二个是逻辑合规度统计框架里各论证点之间的逻辑关系标记是否符合模块的功能预期比如“已有研究不足”模块里的论证点逻辑关系标记应当以转折为主。第三个是整体结构完整度框架是否包含所有七个模块、是否每个模块下都有至少一个有效论据。这三个维度合并出一个综合评价分数作为每次实验的横比标准。我还做了一个人工评估对比实验找了几位有经验的硕博士和青年研究者让他们用“五秒盲评”的方式对比系统生成的框架与人工写的框架哪份更像“出自熟练研究者之手”。盲评结果是系统生成的框架在“结构清晰度”上得分高于人工平均分但在“论点新鲜度”上低于人工平均水平。这其实也侧面说明了一个事实结构可以标准化而思想的新颖性永远需要人自己投入。工具能做的是把思想表达的路径修得平整一点但起点和终点仍属于人。4. 系统落地中的典型问题与排查经验任何真实项目都会遇到各种坑这个项目也不例外。我把开发过程中踩过的陷阱按典型程度分成了几个大类有些是技术细节问题大家可以直接按解决方法排查有些属于思路层面的问题这部分我愿意花多一点篇幅来展开。4.1 常见问题速查表先给一张上手就能用的速查表把高频问题列出来方便对照问题可能原因排查方法解决方案生成的研究问题宽泛空洞解码温度过高 / 训练数据中负面样本不够调低temperature至0.7再试检查数据集中负面样本占比低于15%需扩充在训练数据中显著增加宽泛负面问题对并降低推理temperature论证框架模块间逻辑断裂论据排序模型训练不充分或模块间转移忽略检查排序模型准确率过低的模块单独重新训练对“背景→已有研究”和“已有研究→不足”两段转移单独构造过渡模板同一条材料反复生成结果漂移大beam size太小 / 种子随机扰动固定解码种子增大beam至4或5推理时固定随机种子并将beam size调至4论据被强行分配进错误模块分类阈值设太低查看模块分类置信度分布低于0.7的比例是否过高将置信度阈值提至0.75低于阈值的论据归入候选池并在输出中提示缺失系统反应太慢用户体验差没做推理缓存和量化检查单次推理延迟静态文本批次是否可缓存对研究问题生成做结果缓存对模型做4bit量化推理延迟降到1秒以内微调后模型对原有基础能力退化灾难性遗忘用通用语言能力测试集做回归测试用10%通用语料混合微调训练中加入EWC正则项4.2 生成内容“模板化空洞”的解法这是我在项目中期最头疼的问题。训练数据质量不错模型效果逐步提升但生成出来的“研究问题”总有一种“学术八股”的味道好像句式都对但每个问题换个关键词都能用。后来排查下来发现问题出在数据构造环节我用的自动抽取规则对句式多样性做了无意中的限制导致训练数据里“旨在解决”这个句式占了过大的比重。模型学会了这种句式但并没有学会多维度地表达问题。解决方法是“句式去偏”在数据构造阶段对句式模板做聚类确保每个句式家族在数据集里的占比不超过某个阈值。同时我在推理阶段引入了随机性控制不是简单地使用固定解码参数而是对句式的开头词做一个“多候选抽样”让模型有机会从不同角度表达同一核心问题。这个方法在消除“模板化”方面见效很快最终生成结果里清一色的“旨在解决”句式明显减少了。另外一个值得分享的陷阱是“模型生成的论证框架中出现了和输入材料无关的内容”。这种“幻觉问题”在大多数生成式模型中都很常见需要在解码阶段执行事实约束。我的方案是在生成每个论证节点前强制要求模型参考已经抽取的论据内容并使用“强制覆盖”策略如果解码出的关键词在论据池里没有找到任何变体匹配就标记为“低置信度内容”且输出时用下划线高亮提醒而不是直接输出。这算是一种相对轻量级的事实性控制方法无法做到百分百消除幻觉但可以让用户明确知道“哪些话是推测出来的需要自己复核”。学术写作中内容的可靠性和真实性是第一位的宁可多让用户做一步确认也不能无脑输出有误导性的信息。4.3 拆解一次真实跑偏案例再说一个具体案例。某次测试中我输入了一小段关于边缘计算场景的材料系统生成的研究问题一开始是“如何在边缘设备上改进深度模型的推理效率”听起来还不错。但实际上原材料根本没有提“深度模型”它讲的是传感器数据融合。这个错误属于“过度推理”模型把研究问题从“传感器数据融合优化”被动地拉伸到了“深度模型推理效率”。这种错误在人工评阅时非常容易被发现但在自动评估指标上几乎看不出来因为文本连贯、语法正确、甚至是领域相关的。最终定位到原因是我在负样本构造时用的一个变量替换策略只替换了“变量词”但没替换“主题域词”导致模型把“改进推理效率”这个常用搭配错误地关联到了所有领域。修复方法是扩充负样本的主题域多样性同时在推理提示中增加一道约束“研究问题中的主体对象必须严格从输入材料中抽取不得泛化到其他领域。”从此这类问题大幅减少。5. 效果对比与使用心得在项目接近尾声的时候我做了一次系统的对比评估将这套自建方案与直接使用通用大模型API的效果放在一起比较同时也在真实的使用场景里跑了一遍记录了一些感受。对比结果可以很直观地告诉你“自建”这件事到底值不值得。5.1 与直接调用通用模型的对比结果我选了同一位用户输入的十组素材作为测试集每组素材包含一段文献综述和若干要点。直接使用通用模型API提示词尽量按照网上的模板套路来设计自建模型使用我前面讲的完整流程。我用四个维度来评价生成结果研究问题具体性、研究问题新颖性、论证框架结构完整度、逻辑连贯性。每个维度按1-5分人工打分最终结果如下维度通用模型API自建模型差值研究问题具体性3.14.41.3研究问题新颖性2.63.71.1论证框架结构完整度3.54.61.1逻辑连贯性2.84.21.4差异在各维度上都很稳定。特别值得说明的是“逻辑连贯性”这一项通用模型生成的框架经常在段落内部和段落之间出现断裂感它的每个单独句子都是对的但连在一起就感觉思路跳来跳去。自建模型因为有一个显式的论据排序步骤这层断裂感被显著抑制了。当然通用模型API在语言多样性和词汇丰富度上比自建模型略好这也是不公平的毕竟人家底模大得多。但对于学术写作辅助这个特化场景来说丰富度让位给逻辑连贯性我觉得很值。5.2 实操中的经验心得最后分享几点实际体验中的心得。第一项目最终的训练效果跟数据质量的关系远大于模型结构选择花三周做数据清洗和构造比花三周调模型结构带来的收益大得多。我之前也走过弯路早期总想着在模型结构上搞创新后面发现现成的结构在当前任务规模下已经完全够用关键瓶颈不在结构在训练数据的多样性和标注的准确性。第二系统的反馈闭环很重要。我搭了一个简单的“用户反馈通道”每次生成结果允许用户给一个“是否可用”的标记每月把标记为“不可用”的结果拉出来重新分析定位错误类型后进入下一轮数据增强。这个小闭环让系统在两个月内质量提升了将近一个档位比盲目加数据有效得多。第三学术写作工具的用户体验不仅是速度、质量更重要的是“可解释性”。在论证框架的每个节点上我都设计了一个“查看逻辑依据”的按钮用户点开就能看到这个论点是从哪一条原始素材里来的、属于什么逻辑关系标记。这个功能一开始是开发时的“顺带实现”没想到成了用户反馈里满意度最高的一项。这说明做这类工具时用户的信任感很大程度上来自于“我知道它为什么这么说”而不是“它能说得多顺溜”。项目做到这个阶段我自己的体会是深度学习模型在学术写作辅助这个场景里的定位不是帮你思考而是帮你把思考的过程外置、显性化。研究问题提炼逼着你去面对材料里的矛盾论证框架构建逼着你去整理论证的前后顺序。工具做了七成剩下三成真正决定论文高度的东西还是得人来填。这也是我最初想做这个项目的动机——不是替代作者而是做一个会搭骨架的助手让作者能把精力留给最该由人完成的那部分工作。