先说一个我印象很深的场景。工艺车间的同事打电话问我“手册里这个物料的闪点到底是多少安全阀设定值有没有出处”我眼前摆着一本2599页的化工手册他问的那一页我不知道但我确信手册里一定有。于是我把当时刚做出来没多久的“AI专家”对话窗口发给他让他直接问。他半信半疑地敲了一句话进去十几秒后它不光给出了数值还标了“根据手册第X页”和对应章节。同事愣了半天说了一句“这玩意儿比我翻书快多了。”这就是这个项目的由来把一本2599页的化工手册通过知识蒸馏的思路转化成相当于企业私有的AI专家。这篇文章我会把从PDF解析、文本切分、向量检索到微调蒸馏的完整过程都交代清楚包括踩过的坑和调优时掉过的头发。如果你手头也有一堆又厚又难查的规范、手册、标准库想做成内部AI问答助手这篇文章可以直接当操作手册看。1. 项目目标拆解先搞清楚“AI专家”到底要会什么1.1 为什么通用AI答不了化工手册的问题在做这个项目之前我们内部其实已经有人试过把化工问题直接抛给市面上那些通用大模型。结果很典型问“甲苯的沸点是多少”它能回答得八九不离十但问“本厂手册里关于该物料储存温度的上限是多少”它就完全抓瞎了。因为通用模型压根没看过你那本手册它只能凭训练数据里那些“泛泛的常识”来编。化工这种行业凭印象给数据的后果相当严重轻则被工艺员骂重则出事。另外还有一个原因化工手册里的信息形态和普通文章差别非常大。里面有大量物性数据表、CAS登记号、单位换算、工艺参数区间、安全注释。通用模型即使读到了一段相关文字也很难保证它引用的数据来自正确版本、正确条目。我们要的不是一个“会聊天的化工爱好者”而是一个“能查资料、能给依据、能标出处”的工具。1.2 成功标准不是“答得快”而是“说得清查得有据”项目启动前我和使用方对齐了三个验收标准这里可以直接分享给你参考回答准确率针对手册内高频问题答案关键数据必须与原文一致不接受“大概其”。引用可溯源回答中必须能给出对应页码或章节查不到出处的答案视为不合格。覆盖率从手册目录随机抽取100个知识点系统至少能答对八成以上。定这几个标准不是为了显得专业而是防止项目做到一半跑偏。技术团队天然会被“用最新的框架”“加个Agent”这类事情吸引但用户要的只是“我得快速查到准确的数据并且能跟别人说清楚依据”。明确了边界之后后面每一步都能往回收不会越做越散。2. 第一步把2599页PDF变成“机器能读”的知识2.1 解析PDF的坑双栏、表格和那些需要人工“合体”的段落拿到手册的PDF文件之后第一反应可能是直接丢给LangChain抽取文本。但这里有个前提问题这个PDF是文字版还是扫描版。如果是扫描版你得先过一遍OCR否则后面全是空白。我这次拿到的文字版还算幸运但依然踩了三个非常典型的坑。第一个坑是双栏排版。化工手册很多页面是双栏印刷直接按阅读顺序抽文本会把左栏后半句和右栏前半句拼到一起读起来完全不通。我的处理方式是先用PyMuPDF把页面按坐标切分出左右区域再按区域分别提取文本。这个动作看起来不起眼但对后续切分质量影响巨大。第二个坑是表格跨页。手册里很多物性表横跨两三页如果按“一页一切”的思路去做会把一个完整表格切成好几截。后来我们改成PDF解析阶段就识别表格区域把跨页表格按“表头表项”合并重建再单独存成一个Markdown表格块这个问题才算解决。第三个坑是页眉页脚混入正文。页眉页码、公司名、章节名反复出现会让后续检索时匹配到大量噪声。我的做法是做一轮清洗规则去掉PDF抽取文本中距离页面边缘过近的短行再用正则滤掉重复出现的页眉文字。这个过程不复杂但能显著提升Chunk的质量。2.2 切分策略为什么不能像切西瓜一样一刀切文本切分是决定RAG效果最核心的一步。很多人习惯直接设一个“每500个字切一块”的固定长度这在化工手册上会出大问题。我给你举个例子。有一页讲某原料的储存条件前半部分是闪点数据后半部分是“泄漏处理建议”中间被一个固定长度切断了。结果用户问“这种物质泄漏了怎么处理”的时候检索系统找到的那块文本里只有闪点参数没有泄漏步骤答案自然答非所问。所以我的策略是“先按结构切再按语义补”。流程大概是先解析出目录和章节标题建立一个层级树在每个章节内部再根据段落语义、表格边界、列表结构做切分对于过长的章节再用递归字符切分作为兜底。这样切出来的块大部分保持“一个话题一块”而不是“500个字一块”。2.3 父子分块与表格的单独处理在化工手册里数据表格是问答的高频对象。用户经常问“某某物质的沸点、闪点、爆炸极限分别是多少”这类问题天然适合查表格。但表格很难和正文塞在同一切块里因为表格的信息密度太高和正文混在一起互相稀释。我的处理方式是“父子分块”每个章节保留一个较长的父块用于提供上下文在此基础上再细分出若干专注某个话题的子块用于检索匹配。当子块被命中时把整个父块内容一起送入大模型这样既能精准匹配到“闪点”这个关键词又能让模型结合前后文生成答案。表格则独立成块并给它单独打一个“table”标签在向量检索时可以做类型过滤。我建议你亲测一下“固定长度切分”和“父子分块”的差距同样的100道测试题前者答对率可能在60%左右后者能到80%以上。切分的工程量虽然大但它是整个RAG里最值得花时间打磨的地方。3. 第二步混合检索 重排让AI先学会“查资料”3.1 Embedding和向量库怎么选切分完成后下一步是把文本块向量化存入向量库让AI能“查资料”。这里有两个选型问题Embedding模型和向量数据库。Embedding模型我选的是BAAI的bge-large-zh-v1.5。原因很简单它对中文支持好、在MTEB中文榜单上成绩稳定、开源可离线部署、单张消费级显卡或者CPU都能跑。OpenAI的embedding确实强大但一来有数据合规问题二来每次调用都要走网络在化工这种对数据安全敏感的行业里不太合适。向量数据库我对比过Chroma、Qdrant和Milvus。Chroma适合原型验证装好就能用但数据量大之后性能一般。Milvus功能全、适合生产环境但部署和运维成本偏高。最后我用了Qdrant因为它支持过滤条件、支持MMR去重性能也够用。如果你只是自己折腾一个小知识库Chroma完全够如果要做成多用户服务可以认真考虑Qdrant。3.2 混合检索化工数据吃字面匹配光靠语义检索不够这里我要重点说一个很多新手会漏掉的关键点化工手册里的高频查询很多是“精确匹配”而非“语义匹配”。比如用户输入“CAS号 108-95-2”这串数字字母组合必须完全命中靠向量检索的“语义相似”并不好使。再比如“请查一下规格牌号PH-3”这种查询词面匹配远比语义相似靠谱。如果只做向量检索遇到这类问题召回率会很低。我的方案是混合检索向量检索负责“语义相似”的召回BM25关键词检索负责“字面精确”的召回最后用RRFReciprocal Rank Fusion把两路结果合并排序。实际效果是混合检索比纯向量检索的召回率能提升10到15个百分点。尤其是在化工这种缩写、代号、CAS号密集的场景混合检索几乎是必需品。3.3 加入重排与引文溯源向量检索初筛出来的候选块可能有几十条直接一股脑塞给大模型既浪费token又容易被噪声干扰。这时候最好加一个重排环节。我用了bge-reranker-v2-m3先把向量召回的前20条输入重排模型让模型逐对计算相关性再取前5条送入生成阶段。重排之后的答案质量提升非常明显尤其是那些“多个相似段落混在一起”的场景重排能帮你把最相关的那一段挑出来。引文溯源也是在生成阶段做。我给每个切块都存了元数据包括起始页码、章节号、小节标题。生成Prompt里明确要求回答必须基于给定资料并标注“手册第X页”如果资料中没有明确依据要直接说“手册中未找到明确表述”不允许编造。输出之后我还会跑一个校验脚本检查模型给出的页码是否在合理范围内防止它乱吐页码。这里有一个经验可以分享让大模型“基于页码生成”是可行的但前提是你把页码作为元数据拼进了上下文。如果你只是让模型“回忆”页码它一定会编。所以我会在发送给模型前把切块的元数据拼成一串固定格式的引用前缀模型只需要把前缀里的页码复制进回答即可。4. 第三步知识蒸馏把手册“压进”模型里4.1 这里的“蒸馏”到底在干什么到了这一节才真正回应标题里的“知识蒸馏”。需要先澄清概念传统意义上的知识蒸馏是把一个大模型的能力迁移到一个小模型属于模型压缩的范畴。但我在这个项目里做的事更贴近“数据蒸馏”的思路就是把2599页手册里那些高价值的问答知识通过构造训练数据的方式提炼出来再用LoRA微调注入到一个开源底座模型里。为什么要做这一步因为光靠RAG检索AI的回答虽然准但语言风格总有一种“拼凑感”读起来不像一个真正懂化工的专家在说话。微调的目的正是让模型学会手册的表述习惯、单位习惯和安全提示用语。举个例子检索出来的原材料文字是“本品遇热分解放出有毒气体”。RAG模式下的回答可能是“本品遇热分解放出有毒气体。根据手册第X页”。微调之后模型会自然地补一句“操作时应注意通风并避免高温环境”就像手册编写者真的在旁边提醒你。4.2 蒸馏数据集的构建宁可少不可错知识蒸馏成败的关键不在模型而在数据。我这次没有盲目追求数量而是追求质量最终用了约400条指令数据完成微调。数据构建流程是这样的先从手册目录里筛选出高频知识点覆盖物性数据、储运条件、泄漏处理、安全防护几大类然后针对每个知识点用大模型生成多个用户角度的问法再从原文提取标准答案要求答案必须引用原文内容不允许模型自由发挥最后请化工工程师做抽检和修订抽检比例不低于20%。这里有一条血泪教训用大模型自动生成问答对时它很擅长一本正经地编答案即使你喂了原文给它它也可能把数据改一个单位、换一个小数点。我后来严格要求生成脚本必须从原文模板中“填空式”抽取数值不允许逐字重写才把数据准确性拉上去。数据集格式我用了Alpaca格式{ instruction: 查询甲苯的闪点并给出安全操作建议, input: , output: 根据手册第274页甲苯的闪点为4.4℃闭杯为易燃液体操作时应远离明火并保持通风。安全操作建议详见手册第275页储运注意事项。 }注意上面的页码和数值仅用于展示格式。做成真实数据集时每个数据项都必须经过人工核对宁缺毋滥。4.3 LoRA微调实操参数与效果微调工具我用了LLaMA-Factory底座模型选了Qwen2.5-7B-Instruct。为什么用7B而不是更大的模型因为4090单卡跑LoRA很从容效果也够用14B虽然更强但推理延迟和显存压力都会增加对于内部工具来说没有必要。关键参数如下照着跑基本没问题参数配置lora_rank64lora_alpha128lora_dropout0.1learning_rate1e-4batch_size4gradient_accumulation_steps8epochs3最大序列长度2048训练时长大约三四个小时。微调完成之后我并没有让微调模型脱离RAG单独使用而是让它和RAG搭配检索回来的资料拼进上下文模型用自己的语言整合输出。这一套组合下来效果比“纯RAG”或“纯微调”都好。我的总结是RAG负责提供证据微调负责让模型“像行家一样说话”两者是互补关系。5. 实测记录哪些问题翻车了怎么修好的5.1 效果还不错的时候先报喜。上线前的压力测试里我拿高频问题去问典型回答质量已经相当能打。比如问“某原料的爆炸极限是多少”系统先通过BM25精准定位到物性表那块文本再经过重排选中正确那一行最后生成回答时引用表格里的“爆炸上限”“爆炸下限”数值全部和手册一致。再比如问“手册里关于该物质溢洒处理是怎么写的”系统能准确地引用“截断泄漏源”“使用惰性吸收材料覆盖”等原话并把页码标得很清楚。整个回答结构很干净没有多余的废话。这让我确认了“混合检索父子切分重排”这套组合是可靠的基础设施。5.2 翻车实录五个事故现场当然能拿得出手的案例是一轮轮修出来的这里把印象最深的五个坑列出来供你排查时对照。第一个坑是表格被切碎。早期按固定长度切分把一个“物质安全数据总表”切成了两截用户问“闪点”时检索只命中了下半截没有“闪点”列名模型就从别的地方胡编了一个数。后来我把表格整体保留为一个块并在元数据中标记“table”这问题才消失。第二个坑是返回内容重复。多个相近的切块同时被检索出来大模型把三段重复内容拼在一起显得很啰嗦。解决方案是在重排后加MMR去重保证送入模型的切块之间尽可能不重复。第三个坑是页码幻觉。模型回答里给出一个手册根本不存在的页码。原因是早期Prompt没有强制它基于元数据标注页码。后来我把元数据拼进上下文并在输出层加了校验凡是不符合“手册第X页”格式的引用一律拦截重试问题基本解决。第四个坑是单位错乱。有些表格列印的是kPa模型整合时自动帮用户“换算”成MPa结果错了三个数量级。这个比较难防我最后的方案是做一个后处理脚本把所有数字和单位的组合提取出来与原表核对一旦发现量级不一致就打回重生成。第五个坑是检索漏召回。用户问的是“操作温度”手册原文写的是“工作温度”向量检索找不到完全匹配BM25又没有同义词扩展。后来我在查询端加了一步“查询改写”先让大模型把口语问题转换成包含同义词的检索词集合比如“操作温度”改写为“操作温度 工作温度 使用温度”召回率立刻上来了。5.3 上线前必做的评估我把上面的测试整理成一套固定评估集从手册中抽取100道有标准答案的问题每道题标注对应页码。每次改完系统配置或Prompt就重跑一遍记录三个指标。指标计算方式合格线答案正确率关键数据与史料一致的比例85%以上引用准确率页码可溯源且页码内容相关的比例90%以上覆盖率100道题中能答上来的比例80%以上这套评估集是整个项目最值钱的资产。后续任何人改了代码、换了模型、调了切分参数跑一遍就知道有没有变差不用依赖“感觉”。6. 成本、设备与后续还能怎么玩6.1 一个月的开发周期和硬件清单很多朋友关心做这么一套东西贵不贵。我大概算了一笔账纯人力投入解析和切分约一天数据构造和人工审核约两周微调和评测调优约一周剩余时间在打磨Prompt和写校验脚本。总周期差不多一个月而且这一个月不是满负荷是穿插着做别的事的情况下完成的。硬件方面Embedding和BM25检索可以在普通CPU服务器上跑重排环节需要一张带CUDA的显卡我用的是4090。微调阶段也用同一张4090Qwen2.5-7B的LoRA训练没有压力。如果只做推理不需要那么强的显卡如果想把底座换成14B模型建议上双卡或者48GB显存的卡。这里再说一个成本上的真诚建议如果你只是想快速见效可以先只做“解析切分混合检索RAG”这四步半天就能搭出来效果已经能超过大多数通用问答。微调是锦上添花不是雪中送炭。6.2 从“会答问题”到“会干活”接Agent和更多扩展项目做完之后我思考了下这个问题还能往哪走。最简单的扩展方式是把它接入聊天机器人或Agent让工艺员不用面对一个问答窗口而是直接说“帮我查一下这批原料的存储条件如果库房温度超过35℃该怎么办”。系统先拆解任务再检索再生成带依据的回答。这就是典型的知识库Agent场景。更远一点的扩展方向是多手册合并。化工企业往往不止一本手册可能还有国标、行标、内部台账。多本手册合并时要重点解决“同一数据在不同手册中不一致”的问题。我的做法是给每个切块增加“来源手册”元数据回答时同时展示多手册信息并标注不一致让使用者自己判断优先级而不是让AI强行统一。还可以做增量更新。手册不定期修订修订页面需要重新解析和向量化同时保留历史版本。Qdrant支持按collection隔离版本替换时用新版collection切换即可运维成本不高。项目做下来我最大的体会是把精力花在“数据治理”和“评估集建设”上远比花在换模型、调框架上值得。我们一度纠结要不要换一个更大的底座模型后来发现瓶颈根本不在模型而在切分粒度不够细、检索召回不够全。这些问题解决之后7B模型已经表现得很体面了。最后再分享一个小技巧上线前一定要让实际使用者提20个他们日常真会问的问题拿去系统里测。因为他们问出来的话和开发时想象出来的问题差很远。我第一次让同事测的时候几个高频问法全是口语化的比如“这东西存仓库要注意啥”而不是标准术语。把这批口语问法加进评估集之后系统才真正算是在真实场景里站稳了。