今年我接到一个内部需求团队手里有大量沉淀多年的业务文档包括操作手册、规章制度、常见问题解答分散在好几个盘符和内部网页里想找一份资料得开一堆窗口另一边还有一套很传统的表单审批流程流程节点、材料清单、判断规则全靠口头问、邮件传。领导的想法很简单——能不能让一个AI把这些都接住这就有了标题里说的“把两套传统体系装进AI”。我做的不是推倒重来而是用大模型把这两套旧体系盘活知识问答交给AI流程指引和预审也交给AI用户只面对一个对话入口。整个过程踩了不少坑今天把方案、代码路径、参数选择和问题排查都复盘一遍适合手里有存量文档、存量流程想低成本接大模型的朋友参考。1. 拆解需求两套传统体系到底“装”的是什么1.1 体系A知识散落全靠人肉搜索我在动手之前先花了一周时间做盘点。第一套体系说白了是一堆“知识库”但压根不成体系。团队日常用得最多的资料包括设备操作手册、业务办理指南、口径说明、历史问题答复这些内容有的躺在旧版系统的附件里有的在共享盘的某个“最终版V12”文件夹里还有一部分只存在于老员工脑子里。实际使用场景非常典型新人入职前三个月几乎每隔十分钟就要问一次“这个怎么弄”客服坐席遇到重复提问先开五六个窗口翻资料业务专家被拉进各种群解答低级问题。说白了知识是有的但没人知道它在哪、怎么调、信哪个版本。这个阶段我做了两件事。第一把所有能接触到的存量文档拉出来看了一遍按格式、时效、重复度做了个粗糙的统计第二找一线同事聊了聊他们日常找答案的路径。统计下来真正高频被查询的内容其实只占总文档量的30%左右剩下的多数是历史归档。这给我后面决定“首批装哪些进AI”提供了依据——不用一口气全量接先把高频、稳定、权威的内容装起来就能解决大多数问题。1.2 体系B流程冗长判断全靠经验第二套体系是内部跑了很多年的表单审批流程。以当时最典型的资产申请流程为例流程从提交申请开始经历部门初审、资产复核、预算确认、分管审批、最终归档五个节点每个节点都有各自要核对的材料清单和判断条件。金额范围不同走的路径不一样设备类型不同要补的材料不一样紧急程度不同处理优先级也不一样。这些规则本身是有文档的但问题是规则文档写得像一本厚厚的字典非流程专家根本不想翻实际判断经常靠老同事的经验——问一句“这种情况你之前怎么走的”然后照着历史案例操作。流程发起人最常问的是三个问题我该走哪个流程我该准备哪些材料现在卡在哪个环节传统表单系统给不了这类动态指引。它只能把字段摆在那里填错了打回材料缺了退回。用户体验是“被系统追着改”而不是“有人告诉我怎么弄”。这里我觉得有机会如果大模型能把规则读明白再用对话的方式告诉普通用户该怎么做整个流程的卡顿率会明显下降。1.3 项目的核心决策不重建而是“装进AI”很多团队遇到存量体系混乱第一反应是“重建一套系统”把知识重新整理、把流程重新开发。我评估了一下成本光是把几百份文档重新人工整理成标准化手册至少要两个人忙三个月流程系统重新开发排期更是按季度算。这个投入在当时根本批不下来。所以我的核心决策是不重建而是“装进AI”。什么意思知识体系不重写成新手册而是保留原文用索引和检索增强的方式让大模型基于原文回答问题流程体系不改动原有审批节点而是把规则结构化之后让大模型在入口处做预审和引导。原体系继续运转AI变成一层“智能外挂”。这个思路的价值在于业务零停摆技术人员只需要在数据层和接口层做改造不碰存量系统的核心逻辑。2. 方案选型为什么用RAG处理知识用LLM规则处理流程2.1 知识问答RAG是当前唯一合理路径把文档装进AI技术方案上有几种选择微调大模型、从头训练、检索增强生成RAG。我直接排除了前两个。从头训练不现实数据量和算力都不够微调虽然能让模型“记住”某些知识但文档总量大、更新频繁每次改内容都得重新微调一轮维护成本完全不可控。RAG的思路更像“开卷考试”不逼着模型背下所有文档而是每次回答时先从知识库里检索出相关片段把片段塞进上下文让模型基于这些片段总结答案。这个方案的优点很突出文档更新了索引跟着更新就行模型本身的参数不用动回答还能附带参考来源方便追溯。类比一下生活场景RAG就像一个戴着资料夹的助理你问他问题他先翻资料夹找出相关章节再照着章节内容回答你。翻资料这步就是检索照着章节回答就是生成。这套逻辑天然适合“存量文档多、更新频繁、要求有出处”的传统知识体系。2.2 流程预审LLM做解析规则做兜底流程体系和知识体系不一样。知识问答可以容忍模型自由发挥只要答案有出处就行但流程判断是强约束场景该走A路径就不能走B路径该要的材料少一样都不行。如果完全靠大模型自由发挥去判断流程走向迟早会出问题。我采用的思路是“分工”大模型负责两件事——从用户的自然语言里提取结构化信息比如申请金额、设备类型、申请人部门以及把用户的问题翻译成规则引擎能理解的查询条件规则判断本身交给可控的逻辑代码来做。大模型做“翻译官”规则引擎做“裁判官”。这样做的好处非常实际规则的任何变更只改规则表不用改提示词大模型的角色被限制在语义理解这个它最擅长的领域错误的代价大幅降低。后面实测下来流程路径判断的准确率主要取决于规则表的覆盖度而不取决于模型聪明不聪明。2.3 工具栈和整体架构整个系统的技术栈如下后端服务Python FastAPI负责接口、检索、调度、规则判断大模型走的是通用接口当时选了效果最稳的一款商用模型支持函数调用和JSON输出向量库开源的向量数据库支持集合分区和元数据过滤够用且好维护文档处理PDF解析库配合文本清洗流程表格统一转成自然语言描述前端直接套了一个支持流式输出的对话组件部署在内部服务器上整体流程分两支。第一支是知识问答用户提问进入后端先做意图分类判断是知识类还是流程类如果是知识类走混合检索关键词检索向量检索把召回片段拼成上下文交给大模型生成答案最后附上来源文档名。第二支是流程引导用户提问进入后端后大模型先做实体抽取把关键字段写成结构化JSON规则引擎读取JSON查流程路径表返回用户“该走什么流程、准备什么材料、下一步做什么”如果信息不全则触发追问模板。架构不算复杂关键是把“哪个环节交给模型、哪个环节交给代码”这条线划清楚。划清楚之后开发和排错都轻松很多。3. 实操过程两套体系AI化落地的每一步3.1 第一步文档清洗与知识拆解文档清洗是最脏最累、但最决定上限的一步。我最初天真地以为把文档直接丢进向量库就完事了结果检索回来的内容经常是半截话或者在回答时引用到过时条款。根源在于原始文档质量参差不齐有的PDF是扫描件有的是从老系统导出的表格有的Word文档里嵌了一堆批注和修订痕迹。我整理的流程是这样的。先做格式归一PDF用解析库抽文本扫描件实在抽不出来就先不管等第二批再说Word统一转Docx格式解析Excel表格不止要单元格数据还要把表头、行列关系转成自然语言。比如一张“材料清单表”转成话术就是“资产申请在金额五万以上时需要提交申请表、预算说明、资产明细、分管意见”。表格直接向量化效果很差转成句子之后检索命中率高很多。然后做分块。我前后试过几种策略固定字数切块最省事但会切断语义按段落切块对短段落还行长文档还是会出现一个块里塞了两三个主题的情况。最后用的是“按标题层级切块”把Word和PDF里的标题、子标题解析出来按标题把文档切成语义完整的片段每个片段控制在500到800个字符之间并在向量化时把标题作为前缀拼进文本。这样切出来的块语义完整度明显更高。这里有一个容易被忽视的点清洗阶段一定要做“去噪”。页眉页脚、目录页码、文档修订记录、最后的附件清单这些内容对检索不仅没有帮助还会造成干扰。比如检索“申请条件”时命中的片段可能是文档目录里的“申请条件详见第三条”而不是正文。拍照式的整篇导入看似省事实际检索效果一塌糊涂。我在这个环节宁可慢一点每一大类文档做一次抽样看效果也不要闷头把全部数据灌进去否则后面的调试成本反而更高。3.2 第二步向量库与混合检索链路文档处理好之后进入向量化环节。向量模型我选的是通用中文模型在语义相似度上表现很稳直接用它把每个文本块转成向量写进开源向量库。但很快发现一个问题纯向量检索在专业术语面前不够稳。比如用户问“资产报废”文档里写的是“资产处置报废流程”语义上接近向量检索通常能召回但有些简写、英文缩写、口语化叫法比如用户说“领电脑”系统里叫“电子设备申领”纯向量检索经常漏掉。解决办法就是上混合检索关键词检索负责精确匹配向量检索负责语义扩展两者结果合并后做去重和排序。混合检索的权重我调了很多轮。关键词检索和向量检索的得分范围不一样不能直接加权求和需要分别做归一化。我最终的参数是关键词权重0.3向量权重0.7召回数量top_k设为8再用相关性阈值0.55做过滤低于阈值的片段直接丢弃。这个组合在当时的测试集上命中率比纯向量检索提升了大约20个百分点。还有一个细节是元数据过滤。我把文档来源、更新时间、所属业务线作为标签写进向量库检索时优先过滤那些文档类型为“已作废”或“历史归档”的数据避免答到过时内容。这一步非常关键——我在初期没有做过滤结果一个回复里引用的是三年前的旧规则被业务同事当场抓包。从那以后凡是更新类的文档旧版本一律打上“已归档”标签新版本生效。3.3 第三步流程体系转成AI可读的结构化规则流程体系落地我分了两块一块是规则表一块是提示词。规则表是给程序看的我把它设计成一张决策表。每一行是流程节点每一列是判断条件包括金额区间、资产类型、是否紧急、所需材料编号。用户输入通过大模型提取成结构化JSON后规则引擎在决策表上做匹配输出流程路径。这个设计的好处是规则的维护人员完全不需要懂代码直接在表格里增删行就行。提示词是给大模型看的核心要求是“只提取、不判断”。我在提示词里明确写你是流程助理你的职责是从用户描述中提取字段字段包括申请类型、预算金额、资产类别、紧急程度如果缺少某个必填字段立即向用户追问提取到的字段以JSON格式输出不要回答任何流程判断结论。配上几个示例大模型的输出稳定度明显上升——它不再擅自给出“您应该走XX流程”这类体验式结论而是规规矩矩地把结构化数据交出来。这里补充一个参数选择的细节流程提取的温度我直接调到0。知识问答我用的温度是0.1到0.2保留一点点多样性但流程提取这种强结构化任务温度设置越高越容易在字段上发挥“创意”输出不存在的值所以必须用确定性的采样设置。实测下来温度调到0后字段抽取的格式错误率几乎归零。3.4 第四步对话编排与前端交互两套体系在对话层是共用同一个入口的。用户在对话框里既可以问“设备坏了怎么报修”也可以问“我想申请一台笔记本需要什么材料”系统先做意图分类然后路由到不同的处理链路。意图分类我最初也想过用大模型来判断但后来发现用一个小模型或规则结合就行用户问题里包含“怎么办、材料、流程、申请、审批”这些词优先路由到流程链路包含“怎么操作、是什么意思、为什么、规则”这些词优先路由到知识链路。分类置信度不高时再交回大模型兜底。这样做的原因是大模型判断虽准但每次判断都增加延迟和成本简单问题没必要动用重武器。前端交互我加了一个“引用溯源”区域知识问答的答案下面展示参考文档的标题和原文片段。这个交互的价值远远超出预期——用户看到引用来源后对AI答案的信任度高了很多不再把AI的话当“猜的”而是当“查到的”。哪怕答案偶尔不完整用户也能自己点开原文确认人工客服的负担反而减了。流程引导的交互则做成“步骤卡片”系统在对话里返回一条消息用列表展示流程路径、所需材料、预计耗时并在材料缺失时主动追问“您是否已经准备好XX材料如果没有我可以先帮您列出模板”。这个设计把一次性问答变成了一个交互流程体验比传统表单系统那种一次性填完、被驳回重改的方式顺畅得多。4. 常见问题与排查技巧实录4.1 检索不准、漏召回怎么定位这是知识问答遇到最多的坑。表现形式是用户问一个问题AI说“根据现有知识库无法回答”或者答出来内容泛泛而谈、没有落到关键细节上。我的排查路径是先不看模型回答看检索结果。把用户问题原样丢进检索链路打印召回的前几条片段人工判断片段和问题是否相关。如果召回片段本身就不相关说明问题出在检索环节如果召回片段相关但模型答得差才可能是生成环节的问题。检索环节常见问题有三类。第一类分块粒度太大一个块里塞了多个主题向量检索时“平均化”导致相关性下降解决方法是按标题层级重新切块。第二类用户问题偏口语文档表达偏书面纯向量检索匹配不上解决方法是加关键词检索做混合。第三类文档本身没有把核心信息写成句子比如表格里“是否必须是”这种字段型描述模型读起来缺乏上下文解决方法是把表格字段转成“XX在XX情况下是必须材料”这种自然语言描述。4.2 幻觉问题怎么压幻觉属于AI问答不可回避的问题我压幻觉主要靠两个手段。第一个手段是“限定来源”。在知识问答的提示词里写明仅根据提供的参考片段回答如果参考片段中没有对应信息直接回答“已知资料中未覆盖该问题”不要尝试推测。这个约束配合引用溯源能从源头掐断编内容的冲动。第二个手段是降低生成温度之前调到0.1后来发现即使0.2也会偶尔出现“根据我的理解”这种自行发挥的措辞索性统一降到0.1以下。还有一个隐蔽的幻觉来源知识库里的文档之间本身存在矛盾。老版本说“申请金额超过五万需要分管领导审批”新版本说“超过五万需要总经理审批”模型同时召回到两条就可能把两个判断捏在一起。解决思路是处理文档版本关系文档解析阶段把标题为“修订”或“废止”的内容自动打上过期标签检索时过滤掉新老版本同时存在时优先命中带“最新版”标签的集合。这个做法在知识类场景里比单纯调提示词更管用。4.3 流程规则冲突与误判流程引导链路里模型插了篓子通常不是因为不聪明而是因为“信息不全就下结论”。比如用户说“我想申请一台设备”没说金额也没说设备类型模型要是直接推测出“您应该走一般采购流程”就是误判的典型来源。我的对策是三层兜底。第一层提示词里强制要求“必填字段缺失时必须追问”。模型抽取出缺字段后直接返回追问模板而不是继续往下走流程匹配。第二层代码层面做校验抽取出的JSON字段如果金额为空或者数量不是数字直接拦截小程序端提示“请补充完整后再提交”。第三层规则匹配不到时不返回猜测性结论而是提示“该条件组合未匹配到现有流程规则请联系流程管理员确认”把异常暴露给人而不是让模型硬编一个流程路径。实测下来三层兜底之后流程路径的推荐准确率明显提升了而且就算推荐错了也会因为“信息齐全”和“未匹配提示”的存在把错误挡在流程发起之前不会让用户拿着错误清单去走线下流程。4.4 成本与性能平衡大模型接口的成本是每次调用都产生的量大了之后账单压力实实在在。我做了几个控制动作。第一给知识问答加“相似问题缓存”。同一个问题如果语义相似度超过0.95直接命中缓存返回结果不再调用大模型生成接口。第二把意图分类和流程实体抽取放到小的专用模型上减少调用主模型的高频请求。第三知识问答的上下文长度做瘦身只拼装召回片段和固定指令不加载额外历史对话既省Token又降延迟。性能方面的实测数据是知识问答全链路平均响应1.5秒左右其中检索耗时在几十毫秒内大头是大模型生成流程引导类问题因为有规则引擎参与链路更短普遍在1秒以内。如果对响应速度要求更高可以考虑把高频知识结果直接预生成并缓存这个方案适合“问题固定、答案稳定”的知识库场景。结尾最后说一点我个人操作的心得。这个项目做完之后我最大的感触是技术选型反而没有想象中重要真正花时间的地方全在数据清洗和规则梳理上。文档不整干净换再强的模型也答不准规则不表达清楚换再聪明的模型也会乱猜。AI不是替代传统体系的魔法它更像是让旧资产重新流通起来的管道——前提是这些旧资产本身得先被疏通。如果你也在盘算着把手里的体系装进AI建议不要一开始就追求大而全而是先选两个最高频的场景打通全链路。先把这几十个问题答准、把这几个小流程跑顺比一次性铺开几百个知识点更重要。我的经验是第一批落地场景虽小但只要能真正跑起来、被业务同事用上后面的推进会顺畅得多。