1. 为什么一个装修公司要自建多模态 RAG 知识库1.1 先说说这个项目是从哪冒出来的一个装修公司自己做多模态 RAG 知识库听起来像是技术圈硬凑出来的“大炮打蚊子”但这是我今年做得最实在的一个 AI 落地项目。说它是“企业级”是因为系统上线后要扛住公司几百号人同时在线的检索压力说它是“多模态”是因为知识库里躺着的除了 Word、PDF还有大量施工图、现场照片、报价表格和语音记录。我们公司做了十几年家装和工装这些年攒下的项目资料到底有多少合同模板、报价单、施工工艺标准、材料参数表、设计方案说明、客户问答脚本、售后维修记录……保守估计上万份。麻烦的是这些资料散落在共享盘、各部门群聊文件、个人电脑甚至纸质档案柜里格式从 Word、Excel、PDF 到 CAD、JPG、MP4 全都有。真要找一份某年某月的隐蔽工程验收记录得问遍工程部、行政部、项目经理折腾半天还不一定找得到。管理层最初的想法很简单上一套 AI 客服让客户在官网上自己提问。但我把家底盘了一遍之后发现问题根本不在于缺一个对话界面而在于这些知识从来没被系统化整理过。同一个问题“阳台防水怎么做”设计部、工程部、客服部给出的说法经常不一致。没有统一的知识底座接任何大模型都是花架子。于是项目从“做AI客服”转向了“先把企业知识管理起来”最后落到了多模态 RAG 知识库这件事上。1.2 RAG 解决的不是“生成”问题是“知识供给”问题为什么装修公司也需要 RAG因为业务里的问题大多是“查一下就知道”的问题。客户问“你们用的板材环保等级是几级”工长问“轻质砖墙体能不能挂壁挂马桶”监理问“瓷砖空鼓的验收标准是什么”。这类问题答案稳定、有据可查不需要模型现场编造需要的是从企业内部资料里准确找到对应内容。RAG 的核心思路就是“先查后答”先把资料切分、向量化成可检索的知识切片用户提问时先在这批切片里检索最相关的几段再把检索结果连同问题一起交给大模型组织成答案。这样做的好处很明显答案是站在真实资料基础上的不是模型胡诌的每个回答能附带来源出了问题可以追溯知识更新时只需要重新灌入新文档不用重新训练模型。我们没走“微调大模型”这条路。原因很现实装修知识更新频率不低工艺规范、材料型号、报价套餐年年变微调一次周期长、成本高而且微调解决不了“引用哪份文档”的问题。RAG 的知识都在外部索引里改文档就是改索引当天生效这点对业务部门来说特别友好。1.3 多模态到底体现在哪些地方做知识库之前很多人以为“多模态”只是噱头真正动手才知道装修行业的资料天生就是多模态的。客户往群里发一张瓷砖照片问“这种砖你们能做吗”监理在工地拍一张墙面空鼓照片问“这算不算质量问题”设计师分享一张效果图说“这个风格下一期主推”工长用语音发来一条现场情况汇报。这些内容如果只做文本检索全部都会丢。我们的处理思路是把非文本内容统统“翻译”成可检索、可理解的结构化文本。图片用视觉理解模型提取场景描述和关键信息表格解析成 Markdown语音先转成文字再入库CAD 图纸则转换成区域描述文档。这样一来用户既可以用文字问“有没有类似原木风的案例图”也可以直接丢一张参考图进来“找同款风格”整个过程都走同一条检索链路。下面我会把架构选型、数据处理、检索调优、企业级落地和踩坑实录这五块完整拆开讲每一块都有可以直接抄作业的细节。2. 整体架构与技术选型先把框架想清楚再动手2.1 选型原则能跑通优先能维护优先这类项目最忌讳一上来就追最新模型。我们的选型原则只有两条第一团队现有的维护能力之内能搞定第二业务部门能清楚说出每个环节在干什么。技术再先进如果没人会维护、业务不认账上线三个月就会变成摆设。基于这两条原则我们定了整体技术路线基础大模型调用成熟的商用 API知识库平台用开源 RAG 编排框架二次开发向量检索用开源向量数据库社区版。模型能力我们不自研因为装修公司没有算法团队自研就是给自己挖坑但数据清洗、切分、权限、评测这些工作必须自己做因为这些才是知识库的核心价值。部署方式上选的是私有化部署。原因很直接资料里有客户电话、合同金额、内部工艺标准这些数据不能随便出内网。我们在公司机房放了一台带 GPU 的服务器文本向量模型和视觉理解模型都跑在内网商用 API 只负责最后一步“把检索结果组织成答案”而且只传切片内容和问题不传原始敏感字段。2.2 一条完整链路要经过哪几道关整个系统从文档入库到用户拿到答案一共要过七道关。第一步是格式解析把 PDF 扫描件、Word、表格、图片、CAD、音视频统一转成可处理的文本或结构化数据。第二步是清洗增强去掉页眉页脚、重复段落、无效符号给图片生成图文描述、给表格补全字段含义。第三步是切片把长文档切成有独立语义的片段并挂上来源、部门、版本、权限级别等元数据。第四步是向量化入库文本切片经过嵌入模型变成向量写入向量数据库同时建好全文索引。第五步是查询改写和混合检索用户提问先被改写成检索友好的形式然后同时走向量检索和关键词检索把多路结果合并。第六步是重排用精排模型把候选切片重新打一次分留下最相关的几个。第七步是生成回答大模型基于这些切片组织答案并且强制要求附带引用出处。每一道关我们都踩过坑后面会展开讲。2.3 模型选型的几个具体权衡文本向量模型我们选的是中文语义表现较好的开源嵌入模型维度 768支持最长 512 token 的输入。选它的关键原因是能在内网 GPU 上跑检索延迟可以压到 100 毫秒以内。这里有一条经验不要只看公开榜单的分数要拿自己领域的问题去测。我们拿 50 个装修问答实测过有的模型通用语义很强但遇到“轻钢龙骨”“石膏板接缝”“闭水试验”这类行业词时召回效果明显变差最后选了一个在垂直领域表现稳定的模型。多模态理解模型承担两件事一是给图片生成图文描述二是回答“这张图和那条知识相关吗”这类问题。我们选的是支持图片输入的开源视觉语言模型部署在内网专门跑图片描述任务。商用大模型 API 负责最终的答案生成因为它语言组织能力强、幻觉相对可控。需要提醒的是API 调用要做限流和缓存同一问题重复问就直接返回缓存结果能省不少费用。向量数据库我们用的社区版单机部署评估时 10 万条切片以内基本没有压力。社区的运维成本低自带 RESTful 接口和权限控制对我们这个量级完全够用。如果公司资料超过百万级、并发很高再考虑分布式的方案也不迟没必要一开始就把架构造得特别重。3. 数据处理实战把 Word、PDF、图纸、照片变成高质量知识切片3.1 资产盘点别急着解析先摸清家底数据处理是这类项目里最脏最累、也最决定上限的环节。我们开工第一周没写一行代码全在做资产盘点。我把公司所有可接触的资料列了一张表按“业务条线 资料类型 存放位置 格式 预估份数 敏感等级”六个字段登记。这张表后来是权限设计、切片策略和落地优先级的主要依据。盘点之后发现几个普遍问题一是同一份材料有十几个版本文件名从“最终版”“真最终版”“打死不改版”一路排到“改回第一版”版本管理基本靠人工命名二是大量扫描件是手机拍的歪斜、过曝、模糊OCR 直接跑会出来一堆乱码三是很多“知识”根本不在文档里而是在老员工的脑子里和群聊记录里这部分只能靠访谈和人工录入补齐。建议第一次做资产盘点的团队不要贪多。选三个最核心的业务域先开工比如“客户问答与套餐”“施工工艺与验收”“材料与供应链”。把一个领域做透比十个领域都只做一半要强得多。我们就是从工程部的施工工艺规范开始试点的因为这个领域文档最完整、问题最明确、见效最快。3.2 不同格式的分流处理流程处理流程按格式分流每类格式有一套固定打法。文本类文档也就是 Word、PPT、原生 PDF直接用版式解析工具提取正文按一级标题、二级标题切出章节结构。扫描件 PDF 要先做图像增强把对比度拉高、去阴影、矫正倾斜再跑 OCROCR 结果按阅读顺序输出为带页码的文本。这里有个细节装修公司的图纸扫描件经常是蓝图底色深、线稿细直接 OCR 效果很差需要先反色再识别。表格类是报价单、材料清单、验收表的重灾区。我们统一解析成 Markdown 表格同时生成一段“表格说明文本”“该表为 XX 套餐主材清单包含品牌、型号、单位、单价、备注共 23 行。”这段说明文本会跟随表格一起入库否则用户问“XX 套餐里瓷砖是什么牌子”时模型只搜到一堆单元格数据根本匹配不上问题意图。图片资料分两类处理。一类是设计效果图和完工实拍图交给视觉理解模型生成结构化描述内容包括空间类型、风格元素、主要材质、色彩搭配、空间中的人物活动有品牌信息的还要单拎出来记录。另一类是工地问题照片比如空鼓、开裂、渗水除了生成场景描述外还要尽量识别出问题部位和严重程度。语音记录统一走语音转文字转写结果打上时间和发言人标签后进入清洗流程。CAD 图纸是其中最特殊的。图纸本身是矢量信息直接向量化没有意义我们采取“图纸 说明”的方式每个图纸文件对应一份由设计师填写的《图纸说明》内容包括项目名称、空间类型、主要尺寸、材料标注、设计亮点。检索时优先命中说明文字再看图纸附件。有同行尝试用视觉模型直接读 CAD 导出图效果不稳定不建议一上来就挑战高难度。3.3 切分策略与元数据决定检索质量的上限切分直接决定检索命中率。切得太碎比如每 128 token 一刀语义完整度不够经常出现上下文衔接不上切得太整比如整章几千字一个切片召回后塞给大模型上下文窗口挤爆关键信息被淹没。我们最后定的策略是“结构优先按语义边界切分”标题、章节、段落是天然边界尽量不跨标题切单个切片控制在 300 到 500 字之间。每生产一个切片必须带一条完整的元数据。我们的元数据字段包括来源文件名、页码、一级章节、二级章节、所属部门、文档版本号、安全级别、入库时间、文档责任人。为什么这么强调元数据因为后续的权限过滤、版本过滤、溯源展示全靠它。没有元数据的切片就像一本没有目录和页码的书检索到了也不知道它出自哪里、能不能给客服看、是不是最新版。这里给出一个切片的元数据示例我们内部就是按这个结构存储的chunk { content: 防水施工完成后必须进行闭水试验蓄水深度不低于20mm时间不少于24小时经监理验收合格后方可进行保护层施工。, metadata: { source: 工程部/隐蔽工程验收规范_v2.1.pdf, page: 8, section: 防水工程, owner: 工程部, security_level: 内部公开, version: v2.1, updated: 2025-03-18 } }经验之谈切分策略不要一次定死先用一个版本上线再根据“检索不到答案”的用户反馈反向调整。我们上线第二周发现客户问答类切片太碎导致模型经常只能看到半个案例后来把“问答对”作为一个整体单元入库效果立刻好转。4. 检索与生成调优让 AI 回答得又快又准4.1 混合检索与查询改写解决“搜不到”和“搜不准”知识库上线第一天就暴露了一个典型问题用户问“这个砖耐不耐脏”按语义向量检索返回的结果全是关于“瓷砖分类”“抛光砖特点”的内容根本没有提到“防污等级”“耐脏指数”。原因是文档里压根没有“耐脏”这两个字语义检索找不到字面上的匹配这是纯向量检索的通病。解决办法是混合检索加查询改写。混合检索很好理解向量检索跑一路关键词全文索引跑一路两路结果合并后按权重融合。品牌词、型号、产品名这种精确信息关键词检索特别擅长口语化、同义改写、上下文模糊的意图向量检索更在行。两路互补之后覆盖度明显上升。查询改写是在检索前加一步把用户口语问题改写成若干个更适合检索的语句。比如“这砖耐不耐脏”改写成“瓷砖 防污等级 测试标准”“抛光砖 耐脏性 日常清洁”“釉面砖 防污性能 参数”“防水做完多久能试水”改写成“闭水试验 蓄水时间 规范要求”。改写可以用大模型做我们为了控制成本和延迟只对问题长度小于 50 字、没有明确实体词的句子做改写其他直接原样检索。4.2 重排环节不能省它和召回是两码事很多 RAG 项目只做到“召回 Top 20直接丢给大模型”。我们实测下来这样不行向量检索和关键词检索各自返回的前 20 条里真正有用的往往在中间偏后的位置前几名经常是泛泛而谈的科普内容。如果直接把 Top 20 塞给大模型轻则答案啰嗦重则模型被无关上下文带偏输出错误结论。我们在召回和生成之间加了一道重排。重排模型用交叉编码器把问题和每个候选切片拼在一起打一个精细相关度分这种打分方式比“向量相似度”准确得多。具体流程混合召回返回 50 条重排后取前 5 条作为生成上下文。这一步把最终答案的引用准确率从不到 70% 拉到了 90% 以上是整个链路里性价比最高的一环。重排虽然效果好但计算量比向量检索大不少。我们对 50 条候选做重排单次延迟差不多增加 150 毫秒整体回答耗时约 1.5 秒业务方完全能接受。如果未来并发量上来了可以把重排模型换成一个更轻量的精排小模型或者只对 Top 20 做精排效果差异不大。4.3 Prompt 设计与溯源让模型“照着材料说不准自己编”GenPrompt 我改过十几版核心原则只有一句话逼着模型只依据给定材料回答材料里没有就明说不知道。第一步在系统提示词里写死“你是某装饰集团的业务知识助手只依据检索到的公司文档回答用户问题不要使用你自己的知识补充”。第二步要求模型每个回答都标注引用来源格式统一为“根据《文档名》第几章第几页”。这一步看起来简单实际上需要反复调。一开始模型总是编一个看起来很像的出处后来我们在提示词里加了严格约束“引用的文件名、章节、页码必须完整出现在给定的上下文中禁止推测来源信息。”再把“没有引用来源的回答一律视为不合格”写进离线评测规则模型慢慢就老实了。第三步给模型一个“拒绝模板”。当检索结果与问题相关性小于阈值时系统直接返回“这个问题在知识库里还没有找到明确答案建议转人工处理”而不是让模型硬凑一段模棱两可的话。这条规则非常重要装修行业很多问题涉及售后责任和施工安全答错一句可能引发客诉宁可说不知道也不能瞎说。4.4 离线评测与线上反馈效果好不好用数据说话RAG 系统的效果光靠感觉是不行的。我们从客服聊天记录、工长群和销售反馈里整理了 100 条高频业务问题每条人工标好标准答案和对应来源文档做成评测集。每次修改切分策略、调整检索参数或者换模型都拿这套评测集跑一遍记录三个核心指标检索命中率、答案可接受度、引用准确率。检索命中率看的是“正确答案是否出现在召回的 Top 5 里”答案可接受度由人工按四个档位打分完全正确、基本正确、部分错误、完全错误引用准确率看模型标注的出处是否真实对应检索到的切片。这三项指标分别对应数据处理、生成质量和溯源可信度任何一项下降都要能追溯到具体的改动。线上反馈同样重要。我们在问答页面加了一个“这个回答有帮助吗”的按钮以及“转人工”的入口。每周汇总所有“没有帮助”的回答人工复盘是什么原因是检索没找到、找到了但排太靠后、还是模型没读懂。复盘结论回流到数据处理或提示词里形成持续迭代的闭环。没有这个反馈机制系统上线三个月就会停在原地。5. 企业级落地权限隔离、私有化部署与团队协作5.1 知识权限不是所有资料都能让所有人看到装修公司虽然不像金融机构那样强调数据安全但内部的报价底价、材料采购成本、项目经理绩效数据绝对不能让客服直接念给客户听。权限设计是在数据切分阶段就要考虑的事不能等上线后再补。我们在元数据里设了“安全级别”字段分三档全体员工可见、仅内部员工可见、仅特定部门可见。系统实现上做了两层控制。第一层是知识库拆分把超预算的底价文档、供应商折扣表单独放在一个部门级知识空间只有财务和采购相关角色能配置访问权限。第二层是检索过滤同一个用户发起的所有检索请求都会自动带上他的角色标签在召回阶段就过滤掉无权限切片而不是在生成答案之后再做二次屏蔽这样才能保证消息完全不跨权限泄露。权限设置最麻烦的是“边界场景”。比如客户问“你们防水材料用的什么牌子”这个答案在市场部对外资料里是公开的但工程部的内部采购表里还包含了供应商底价检索时稍不注意就会把底价一起带出来。我们的解法是给对客问答和内部技术分别建库对客库只收录经过审核的对外口径内部库才包含完整信息两套库之间物理隔离谁也不能跨库检索。5.2 私有化部署与日常运维私有化部署的硬件并不夸张一台双路 GPU 服务器就能跑完文本向量模型、视觉理解模型、向量数据库和应用服务。最终回答生成调用外部大模型 API这部分不涉及内网敏感数据因为传给 API 的只是问题加上已脱敏的切片内容。如果公司对数据出境有更强约束也可以部署本地化的开源生成模型效果会略降一些但安全性更高。运维层面有三件事必须做一是监控检索延迟和 API 调用量延迟超过两秒要报警二是定期重建向量索引当文档增量较大、召回率出现波动时全量重建一次比增量更新更省心三是日志审计记录谁在什么时间问了什么问题、系统引用了哪些文档便于发生纠纷时回溯。审计日志我们保留六个月内部查过一次“某项目报价是否被泄露”靠的就是这份日志。部署时还有一个小建议将知识库的后台管理界面和员工问答入口分开。管理端做数据管理、切片预览、权限配置、评测集管理只有知识管理员能进员工端只保留一个类似聊天窗口的简洁入口降低使用门槛。很多项目把管理功能和使用功能揉在一个界面里员工觉得太复杂不肯用整个项目就死在推广阶段。5.3 业务部门协同知识库是业务项目不是 IT 项目这个项目能成关键不在技术在于让业务部门真正参与进来。我们组建了一个五人核心小组IT 部门出两个工程师工程部、客服部、市场部各出一个业务骨干。业务骨干的任务有两项第一确认各自领域的知识清单和文档优先级第二审核知识库里的对外话术是否与自己部门的口径一致。每周开一次例会业务骨干带着本周“从一线收来的典型问题”回来我们当场在系统里检索看能不能找到答案、答案是不是他们要的。这种做法比任何培训都有效。第一次例会的时候客服部提出“业主问装修工期为什么又延期了这种问题不能只回答合同上的天数要解释常见延期原因和补管理动作”我们据此把“工期管理”的切分内容重做了一遍。给业务人员的权限不要只停留在“提供资料”上要让他们能直接管理自己部门的文档。我们给每个部门设置了知识管理员角色他们能上传本单位的新资料、更新过期的规范文件。这个授权动作让业务部门有了主人翁意识技术团队也不至于沦为“传文件的人”。毕竟知识库最后是要靠一线员工天天用的他们不参与建设系统就活不起来。5.4 效果度量怎么让管理层看到这个项目的价值项目上线两个月后我们统计了一组数据客服人均单次应答时长从 6 分钟降到 2 分钟需要人工介入的重复性问题占比下降约 40%工程部在新项目交底时查规范的时间平均每次节省 20 分钟以上。这些数据是说服管理层继续投入的核心依据。最初立项时的 KP收益我们全部落实成了可量化的业务指标。我建议后来者在项目立项时就约定好度量方式不要等到上线后再补。测量维度可以很朴素一线员工每天使用次数、检索后解决率、转人工率、知识更新频率。哪怕刚开始数据不好看也没关系基线先跑出来后面每优化一个环节都能看到数字改善对团队士气和资源争取都很有帮助。6. 踩坑实录与常见问题速查6.1 五大高频翻车现场第一个坑明明库里有一模一样的资料系统却回答“没有找到”。后来查下来权限过滤器默认只查了“全体员工可见”的库而正确答案在工程部内部库里提问者虽然有权限但检索请求忘了带部门标签。排查思路是先看检索返回的原始结果里有没有正确答案如果召回里没有再往权限和数据处理方向查而不是急着调模型。第二个坑扫描版 PDF 里表格数字错得离谱。报价单里“300x300 瓷砖”被 OCR 识别成“300x300 碯砖”这种错误直接进向量库检索和生成都会出问题。解决方法是把表格扫描件的 OCR 结果单独走一遍数字和单位校正用正则加常见单位词典清洗保证型号数字不出错。第三个坑模型引用了过期版本。我们有一份《施工工艺规范》已经更新到 v3.0但库里还留着 v2.0 的老版本。用户问“墙面找平厚度标准”模型引用了旧版的 15mm而新版已改为 10mm。加“版本过滤”字段后解决检索时只取每个文档最新版本切片。这是企业级知识库必须处理的问题不能指望模型自己判断新旧。第四个坑视觉模型把效果图里的配色描述错了导致后续按“原木风”“奶油风”检索时漏召回。原因是测试阶段只看了描述句子通不通顺没有逐张核对关键属性。后来我们抽了 50 张效果图做属性级校验评价维度就是“风格标签是否正确”“主要材质是否齐全”“品牌元素有没有漏”不对的重新生成描述。第五个坑冷启动阶段没有用户真实提问评测集全靠业务骨干自己编上线后表现平平。后来我们把客服历史聊天记录里被反复问的问题捞出来按频次排序重新组了评测集系统的优化方向才对上了业务真正的高频场景。真实数据永远比经验猜测可靠哪怕数据不干净也先用起来。6.2 排查优先级问题到底出在哪个环节做 RAG 调试这么久我的排查习惯是“按管线顺序定位”。用户反馈“答案不对”时先看检索日志确认召回的 Top 5 切片里有没有正确答案如果有说明问题出在重排或者生成环节重排序挨个检查重排分数和 Prompt 约束如果没有正确答案说明问题出在召回这时再往切分策略、嵌入模型、查询改写方向查。我整理了一个速查表团队内部排查问题时照着走现象可能原因优先排查方向检索结果和问题完全不相关查询改写过度/切片粒度不合理检查改写后的问题、切片长度召回里有真相但答案说找不到权限过滤拦截/重排把正确项挤掉查检索请求的角色标签、重排分数答案来源引用错误文档上下文混杂了多个主题收紧重排阈值、限制引用数量图片相关问题命中率低图片描述生成太泛重新校验视觉描述的关键属性回答前后矛盾同一用户跨知识库提问检查对话上下文是否带权限策略新规范更新后回答仍是旧标准版本过滤未生效查元数据版本字段、重建索引这个表不足以覆盖所有情况但能帮你在面对莫名奇妙的问题时快速缩小范围。技术从业者很容易一上来就怀疑模型能力其实大部分线上问题都出在数据处理和权限配置这些“不性感”的环节。6.3 最后再分享一点实在建议如果让我重新做一遍这个项目我会在立项阶段就把一件事做得更狠先花两到三周把公司真实的高频问题清单做出来并且让每个问题都落到对应的文档和责任人。有了这张清单后面所有技术决策都有清晰的靶子。技术选型、切分粒度、检索调优全都在为这批问题服务不会被各种“看起来不错”的方向带偏。另一个建议是控制范围。第一个版本只做一到两个业务域哪怕只能回答工程部的工艺问题只要回答准确、方便、有引用一线员工就会主动用起来。有了第一批真实用户和真实反馈再逐步扩展到客服、设计、材料、售后节奏会顺很多。最怕的是追求“全覆盖”几百个模板文档一次性灌进去结果每个问题都答得模棱两可用户试几次就再也不来了。多模态 RAG 对企业最大的价值不是替代人而是把散落在员工脑子和硬盘里的经验变成公司的固定资产。项目上线至今我最高兴的不是模型答对了多少题而是看到一个新入职的工程助理能靠这个系统独立查清一套隐蔽工程的全部验收规范。知识被真正用起来这个项目才算没有白做。 
长河君 · 2026/10/17 11:54:54 · 阅读 1.2k 企业级多模态RAG知识库落地实践与踩坑实录
1. 为什么一个装修公司要自建多模态 RAG 知识库1.1 先说说这个项目是从哪冒出来的一个装修公司自己做多模态 RAG 知识库听起来像是技术圈硬凑出来的“大炮打蚊子”但这是我今年做得最实在的一个 AI 落地项目。说它是“企业级”是因为系统上线后要扛住公司几百号人同时在线的检索压力说它是“多模态”是因为知识库里躺着的除了 Word、PDF还有大量施工图、现场照片、报价表格和语音记录。我们公司做了十几年家装和工装这些年攒下的项目资料到底有多少合同模板、报价单、施工工艺标准、材料参数表、设计方案说明、客户问答脚本、售后维修记录……保守估计上万份。麻烦的是这些资料散落在共享盘、各部门群聊文件、个人电脑甚至纸质档案柜里格式从 Word、Excel、PDF 到 CAD、JPG、MP4 全都有。真要找一份某年某月的隐蔽工程验收记录得问遍工程部、行政部、项目经理折腾半天还不一定找得到。管理层最初的想法很简单上一套 AI 客服让客户在官网上自己提问。但我把家底盘了一遍之后发现问题根本不在于缺一个对话界面而在于这些知识从来没被系统化整理过。同一个问题“阳台防水怎么做”设计部、工程部、客服部给出的说法经常不一致。没有统一的知识底座接任何大模型都是花架子。于是项目从“做AI客服”转向了“先把企业知识管理起来”最后落到了多模态 RAG 知识库这件事上。1.2 RAG 解决的不是“生成”问题是“知识供给”问题为什么装修公司也需要 RAG因为业务里的问题大多是“查一下就知道”的问题。客户问“你们用的板材环保等级是几级”工长问“轻质砖墙体能不能挂壁挂马桶”监理问“瓷砖空鼓的验收标准是什么”。这类问题答案稳定、有据可查不需要模型现场编造需要的是从企业内部资料里准确找到对应内容。RAG 的核心思路就是“先查后答”先把资料切分、向量化成可检索的知识切片用户提问时先在这批切片里检索最相关的几段再把检索结果连同问题一起交给大模型组织成答案。这样做的好处很明显答案是站在真实资料基础上的不是模型胡诌的每个回答能附带来源出了问题可以追溯知识更新时只需要重新灌入新文档不用重新训练模型。我们没走“微调大模型”这条路。原因很现实装修知识更新频率不低工艺规范、材料型号、报价套餐年年变微调一次周期长、成本高而且微调解决不了“引用哪份文档”的问题。RAG 的知识都在外部索引里改文档就是改索引当天生效这点对业务部门来说特别友好。1.3 多模态到底体现在哪些地方做知识库之前很多人以为“多模态”只是噱头真正动手才知道装修行业的资料天生就是多模态的。客户往群里发一张瓷砖照片问“这种砖你们能做吗”监理在工地拍一张墙面空鼓照片问“这算不算质量问题”设计师分享一张效果图说“这个风格下一期主推”工长用语音发来一条现场情况汇报。这些内容如果只做文本检索全部都会丢。我们的处理思路是把非文本内容统统“翻译”成可检索、可理解的结构化文本。图片用视觉理解模型提取场景描述和关键信息表格解析成 Markdown语音先转成文字再入库CAD 图纸则转换成区域描述文档。这样一来用户既可以用文字问“有没有类似原木风的案例图”也可以直接丢一张参考图进来“找同款风格”整个过程都走同一条检索链路。下面我会把架构选型、数据处理、检索调优、企业级落地和踩坑实录这五块完整拆开讲每一块都有可以直接抄作业的细节。2. 整体架构与技术选型先把框架想清楚再动手2.1 选型原则能跑通优先能维护优先这类项目最忌讳一上来就追最新模型。我们的选型原则只有两条第一团队现有的维护能力之内能搞定第二业务部门能清楚说出每个环节在干什么。技术再先进如果没人会维护、业务不认账上线三个月就会变成摆设。基于这两条原则我们定了整体技术路线基础大模型调用成熟的商用 API知识库平台用开源 RAG 编排框架二次开发向量检索用开源向量数据库社区版。模型能力我们不自研因为装修公司没有算法团队自研就是给自己挖坑但数据清洗、切分、权限、评测这些工作必须自己做因为这些才是知识库的核心价值。部署方式上选的是私有化部署。原因很直接资料里有客户电话、合同金额、内部工艺标准这些数据不能随便出内网。我们在公司机房放了一台带 GPU 的服务器文本向量模型和视觉理解模型都跑在内网商用 API 只负责最后一步“把检索结果组织成答案”而且只传切片内容和问题不传原始敏感字段。2.2 一条完整链路要经过哪几道关整个系统从文档入库到用户拿到答案一共要过七道关。第一步是格式解析把 PDF 扫描件、Word、表格、图片、CAD、音视频统一转成可处理的文本或结构化数据。第二步是清洗增强去掉页眉页脚、重复段落、无效符号给图片生成图文描述、给表格补全字段含义。第三步是切片把长文档切成有独立语义的片段并挂上来源、部门、版本、权限级别等元数据。第四步是向量化入库文本切片经过嵌入模型变成向量写入向量数据库同时建好全文索引。第五步是查询改写和混合检索用户提问先被改写成检索友好的形式然后同时走向量检索和关键词检索把多路结果合并。第六步是重排用精排模型把候选切片重新打一次分留下最相关的几个。第七步是生成回答大模型基于这些切片组织答案并且强制要求附带引用出处。每一道关我们都踩过坑后面会展开讲。2.3 模型选型的几个具体权衡文本向量模型我们选的是中文语义表现较好的开源嵌入模型维度 768支持最长 512 token 的输入。选它的关键原因是能在内网 GPU 上跑检索延迟可以压到 100 毫秒以内。这里有一条经验不要只看公开榜单的分数要拿自己领域的问题去测。我们拿 50 个装修问答实测过有的模型通用语义很强但遇到“轻钢龙骨”“石膏板接缝”“闭水试验”这类行业词时召回效果明显变差最后选了一个在垂直领域表现稳定的模型。多模态理解模型承担两件事一是给图片生成图文描述二是回答“这张图和那条知识相关吗”这类问题。我们选的是支持图片输入的开源视觉语言模型部署在内网专门跑图片描述任务。商用大模型 API 负责最终的答案生成因为它语言组织能力强、幻觉相对可控。需要提醒的是API 调用要做限流和缓存同一问题重复问就直接返回缓存结果能省不少费用。向量数据库我们用的社区版单机部署评估时 10 万条切片以内基本没有压力。社区的运维成本低自带 RESTful 接口和权限控制对我们这个量级完全够用。如果公司资料超过百万级、并发很高再考虑分布式的方案也不迟没必要一开始就把架构造得特别重。3. 数据处理实战把 Word、PDF、图纸、照片变成高质量知识切片3.1 资产盘点别急着解析先摸清家底数据处理是这类项目里最脏最累、也最决定上限的环节。我们开工第一周没写一行代码全在做资产盘点。我把公司所有可接触的资料列了一张表按“业务条线 资料类型 存放位置 格式 预估份数 敏感等级”六个字段登记。这张表后来是权限设计、切片策略和落地优先级的主要依据。盘点之后发现几个普遍问题一是同一份材料有十几个版本文件名从“最终版”“真最终版”“打死不改版”一路排到“改回第一版”版本管理基本靠人工命名二是大量扫描件是手机拍的歪斜、过曝、模糊OCR 直接跑会出来一堆乱码三是很多“知识”根本不在文档里而是在老员工的脑子里和群聊记录里这部分只能靠访谈和人工录入补齐。建议第一次做资产盘点的团队不要贪多。选三个最核心的业务域先开工比如“客户问答与套餐”“施工工艺与验收”“材料与供应链”。把一个领域做透比十个领域都只做一半要强得多。我们就是从工程部的施工工艺规范开始试点的因为这个领域文档最完整、问题最明确、见效最快。3.2 不同格式的分流处理流程处理流程按格式分流每类格式有一套固定打法。文本类文档也就是 Word、PPT、原生 PDF直接用版式解析工具提取正文按一级标题、二级标题切出章节结构。扫描件 PDF 要先做图像增强把对比度拉高、去阴影、矫正倾斜再跑 OCROCR 结果按阅读顺序输出为带页码的文本。这里有个细节装修公司的图纸扫描件经常是蓝图底色深、线稿细直接 OCR 效果很差需要先反色再识别。表格类是报价单、材料清单、验收表的重灾区。我们统一解析成 Markdown 表格同时生成一段“表格说明文本”“该表为 XX 套餐主材清单包含品牌、型号、单位、单价、备注共 23 行。”这段说明文本会跟随表格一起入库否则用户问“XX 套餐里瓷砖是什么牌子”时模型只搜到一堆单元格数据根本匹配不上问题意图。图片资料分两类处理。一类是设计效果图和完工实拍图交给视觉理解模型生成结构化描述内容包括空间类型、风格元素、主要材质、色彩搭配、空间中的人物活动有品牌信息的还要单拎出来记录。另一类是工地问题照片比如空鼓、开裂、渗水除了生成场景描述外还要尽量识别出问题部位和严重程度。语音记录统一走语音转文字转写结果打上时间和发言人标签后进入清洗流程。CAD 图纸是其中最特殊的。图纸本身是矢量信息直接向量化没有意义我们采取“图纸 说明”的方式每个图纸文件对应一份由设计师填写的《图纸说明》内容包括项目名称、空间类型、主要尺寸、材料标注、设计亮点。检索时优先命中说明文字再看图纸附件。有同行尝试用视觉模型直接读 CAD 导出图效果不稳定不建议一上来就挑战高难度。3.3 切分策略与元数据决定检索质量的上限切分直接决定检索命中率。切得太碎比如每 128 token 一刀语义完整度不够经常出现上下文衔接不上切得太整比如整章几千字一个切片召回后塞给大模型上下文窗口挤爆关键信息被淹没。我们最后定的策略是“结构优先按语义边界切分”标题、章节、段落是天然边界尽量不跨标题切单个切片控制在 300 到 500 字之间。每生产一个切片必须带一条完整的元数据。我们的元数据字段包括来源文件名、页码、一级章节、二级章节、所属部门、文档版本号、安全级别、入库时间、文档责任人。为什么这么强调元数据因为后续的权限过滤、版本过滤、溯源展示全靠它。没有元数据的切片就像一本没有目录和页码的书检索到了也不知道它出自哪里、能不能给客服看、是不是最新版。这里给出一个切片的元数据示例我们内部就是按这个结构存储的chunk { content: 防水施工完成后必须进行闭水试验蓄水深度不低于20mm时间不少于24小时经监理验收合格后方可进行保护层施工。, metadata: { source: 工程部/隐蔽工程验收规范_v2.1.pdf, page: 8, section: 防水工程, owner: 工程部, security_level: 内部公开, version: v2.1, updated: 2025-03-18 } }经验之谈切分策略不要一次定死先用一个版本上线再根据“检索不到答案”的用户反馈反向调整。我们上线第二周发现客户问答类切片太碎导致模型经常只能看到半个案例后来把“问答对”作为一个整体单元入库效果立刻好转。4. 检索与生成调优让 AI 回答得又快又准4.1 混合检索与查询改写解决“搜不到”和“搜不准”知识库上线第一天就暴露了一个典型问题用户问“这个砖耐不耐脏”按语义向量检索返回的结果全是关于“瓷砖分类”“抛光砖特点”的内容根本没有提到“防污等级”“耐脏指数”。原因是文档里压根没有“耐脏”这两个字语义检索找不到字面上的匹配这是纯向量检索的通病。解决办法是混合检索加查询改写。混合检索很好理解向量检索跑一路关键词全文索引跑一路两路结果合并后按权重融合。品牌词、型号、产品名这种精确信息关键词检索特别擅长口语化、同义改写、上下文模糊的意图向量检索更在行。两路互补之后覆盖度明显上升。查询改写是在检索前加一步把用户口语问题改写成若干个更适合检索的语句。比如“这砖耐不耐脏”改写成“瓷砖 防污等级 测试标准”“抛光砖 耐脏性 日常清洁”“釉面砖 防污性能 参数”“防水做完多久能试水”改写成“闭水试验 蓄水时间 规范要求”。改写可以用大模型做我们为了控制成本和延迟只对问题长度小于 50 字、没有明确实体词的句子做改写其他直接原样检索。4.2 重排环节不能省它和召回是两码事很多 RAG 项目只做到“召回 Top 20直接丢给大模型”。我们实测下来这样不行向量检索和关键词检索各自返回的前 20 条里真正有用的往往在中间偏后的位置前几名经常是泛泛而谈的科普内容。如果直接把 Top 20 塞给大模型轻则答案啰嗦重则模型被无关上下文带偏输出错误结论。我们在召回和生成之间加了一道重排。重排模型用交叉编码器把问题和每个候选切片拼在一起打一个精细相关度分这种打分方式比“向量相似度”准确得多。具体流程混合召回返回 50 条重排后取前 5 条作为生成上下文。这一步把最终答案的引用准确率从不到 70% 拉到了 90% 以上是整个链路里性价比最高的一环。重排虽然效果好但计算量比向量检索大不少。我们对 50 条候选做重排单次延迟差不多增加 150 毫秒整体回答耗时约 1.5 秒业务方完全能接受。如果未来并发量上来了可以把重排模型换成一个更轻量的精排小模型或者只对 Top 20 做精排效果差异不大。4.3 Prompt 设计与溯源让模型“照着材料说不准自己编”GenPrompt 我改过十几版核心原则只有一句话逼着模型只依据给定材料回答材料里没有就明说不知道。第一步在系统提示词里写死“你是某装饰集团的业务知识助手只依据检索到的公司文档回答用户问题不要使用你自己的知识补充”。第二步要求模型每个回答都标注引用来源格式统一为“根据《文档名》第几章第几页”。这一步看起来简单实际上需要反复调。一开始模型总是编一个看起来很像的出处后来我们在提示词里加了严格约束“引用的文件名、章节、页码必须完整出现在给定的上下文中禁止推测来源信息。”再把“没有引用来源的回答一律视为不合格”写进离线评测规则模型慢慢就老实了。第三步给模型一个“拒绝模板”。当检索结果与问题相关性小于阈值时系统直接返回“这个问题在知识库里还没有找到明确答案建议转人工处理”而不是让模型硬凑一段模棱两可的话。这条规则非常重要装修行业很多问题涉及售后责任和施工安全答错一句可能引发客诉宁可说不知道也不能瞎说。4.4 离线评测与线上反馈效果好不好用数据说话RAG 系统的效果光靠感觉是不行的。我们从客服聊天记录、工长群和销售反馈里整理了 100 条高频业务问题每条人工标好标准答案和对应来源文档做成评测集。每次修改切分策略、调整检索参数或者换模型都拿这套评测集跑一遍记录三个核心指标检索命中率、答案可接受度、引用准确率。检索命中率看的是“正确答案是否出现在召回的 Top 5 里”答案可接受度由人工按四个档位打分完全正确、基本正确、部分错误、完全错误引用准确率看模型标注的出处是否真实对应检索到的切片。这三项指标分别对应数据处理、生成质量和溯源可信度任何一项下降都要能追溯到具体的改动。线上反馈同样重要。我们在问答页面加了一个“这个回答有帮助吗”的按钮以及“转人工”的入口。每周汇总所有“没有帮助”的回答人工复盘是什么原因是检索没找到、找到了但排太靠后、还是模型没读懂。复盘结论回流到数据处理或提示词里形成持续迭代的闭环。没有这个反馈机制系统上线三个月就会停在原地。5. 企业级落地权限隔离、私有化部署与团队协作5.1 知识权限不是所有资料都能让所有人看到装修公司虽然不像金融机构那样强调数据安全但内部的报价底价、材料采购成本、项目经理绩效数据绝对不能让客服直接念给客户听。权限设计是在数据切分阶段就要考虑的事不能等上线后再补。我们在元数据里设了“安全级别”字段分三档全体员工可见、仅内部员工可见、仅特定部门可见。系统实现上做了两层控制。第一层是知识库拆分把超预算的底价文档、供应商折扣表单独放在一个部门级知识空间只有财务和采购相关角色能配置访问权限。第二层是检索过滤同一个用户发起的所有检索请求都会自动带上他的角色标签在召回阶段就过滤掉无权限切片而不是在生成答案之后再做二次屏蔽这样才能保证消息完全不跨权限泄露。权限设置最麻烦的是“边界场景”。比如客户问“你们防水材料用的什么牌子”这个答案在市场部对外资料里是公开的但工程部的内部采购表里还包含了供应商底价检索时稍不注意就会把底价一起带出来。我们的解法是给对客问答和内部技术分别建库对客库只收录经过审核的对外口径内部库才包含完整信息两套库之间物理隔离谁也不能跨库检索。5.2 私有化部署与日常运维私有化部署的硬件并不夸张一台双路 GPU 服务器就能跑完文本向量模型、视觉理解模型、向量数据库和应用服务。最终回答生成调用外部大模型 API这部分不涉及内网敏感数据因为传给 API 的只是问题加上已脱敏的切片内容。如果公司对数据出境有更强约束也可以部署本地化的开源生成模型效果会略降一些但安全性更高。运维层面有三件事必须做一是监控检索延迟和 API 调用量延迟超过两秒要报警二是定期重建向量索引当文档增量较大、召回率出现波动时全量重建一次比增量更新更省心三是日志审计记录谁在什么时间问了什么问题、系统引用了哪些文档便于发生纠纷时回溯。审计日志我们保留六个月内部查过一次“某项目报价是否被泄露”靠的就是这份日志。部署时还有一个小建议将知识库的后台管理界面和员工问答入口分开。管理端做数据管理、切片预览、权限配置、评测集管理只有知识管理员能进员工端只保留一个类似聊天窗口的简洁入口降低使用门槛。很多项目把管理功能和使用功能揉在一个界面里员工觉得太复杂不肯用整个项目就死在推广阶段。5.3 业务部门协同知识库是业务项目不是 IT 项目这个项目能成关键不在技术在于让业务部门真正参与进来。我们组建了一个五人核心小组IT 部门出两个工程师工程部、客服部、市场部各出一个业务骨干。业务骨干的任务有两项第一确认各自领域的知识清单和文档优先级第二审核知识库里的对外话术是否与自己部门的口径一致。每周开一次例会业务骨干带着本周“从一线收来的典型问题”回来我们当场在系统里检索看能不能找到答案、答案是不是他们要的。这种做法比任何培训都有效。第一次例会的时候客服部提出“业主问装修工期为什么又延期了这种问题不能只回答合同上的天数要解释常见延期原因和补管理动作”我们据此把“工期管理”的切分内容重做了一遍。给业务人员的权限不要只停留在“提供资料”上要让他们能直接管理自己部门的文档。我们给每个部门设置了知识管理员角色他们能上传本单位的新资料、更新过期的规范文件。这个授权动作让业务部门有了主人翁意识技术团队也不至于沦为“传文件的人”。毕竟知识库最后是要靠一线员工天天用的他们不参与建设系统就活不起来。5.4 效果度量怎么让管理层看到这个项目的价值项目上线两个月后我们统计了一组数据客服人均单次应答时长从 6 分钟降到 2 分钟需要人工介入的重复性问题占比下降约 40%工程部在新项目交底时查规范的时间平均每次节省 20 分钟以上。这些数据是说服管理层继续投入的核心依据。最初立项时的 KP收益我们全部落实成了可量化的业务指标。我建议后来者在项目立项时就约定好度量方式不要等到上线后再补。测量维度可以很朴素一线员工每天使用次数、检索后解决率、转人工率、知识更新频率。哪怕刚开始数据不好看也没关系基线先跑出来后面每优化一个环节都能看到数字改善对团队士气和资源争取都很有帮助。6. 踩坑实录与常见问题速查6.1 五大高频翻车现场第一个坑明明库里有一模一样的资料系统却回答“没有找到”。后来查下来权限过滤器默认只查了“全体员工可见”的库而正确答案在工程部内部库里提问者虽然有权限但检索请求忘了带部门标签。排查思路是先看检索返回的原始结果里有没有正确答案如果召回里没有再往权限和数据处理方向查而不是急着调模型。第二个坑扫描版 PDF 里表格数字错得离谱。报价单里“300x300 瓷砖”被 OCR 识别成“300x300 碯砖”这种错误直接进向量库检索和生成都会出问题。解决方法是把表格扫描件的 OCR 结果单独走一遍数字和单位校正用正则加常见单位词典清洗保证型号数字不出错。第三个坑模型引用了过期版本。我们有一份《施工工艺规范》已经更新到 v3.0但库里还留着 v2.0 的老版本。用户问“墙面找平厚度标准”模型引用了旧版的 15mm而新版已改为 10mm。加“版本过滤”字段后解决检索时只取每个文档最新版本切片。这是企业级知识库必须处理的问题不能指望模型自己判断新旧。第四个坑视觉模型把效果图里的配色描述错了导致后续按“原木风”“奶油风”检索时漏召回。原因是测试阶段只看了描述句子通不通顺没有逐张核对关键属性。后来我们抽了 50 张效果图做属性级校验评价维度就是“风格标签是否正确”“主要材质是否齐全”“品牌元素有没有漏”不对的重新生成描述。第五个坑冷启动阶段没有用户真实提问评测集全靠业务骨干自己编上线后表现平平。后来我们把客服历史聊天记录里被反复问的问题捞出来按频次排序重新组了评测集系统的优化方向才对上了业务真正的高频场景。真实数据永远比经验猜测可靠哪怕数据不干净也先用起来。6.2 排查优先级问题到底出在哪个环节做 RAG 调试这么久我的排查习惯是“按管线顺序定位”。用户反馈“答案不对”时先看检索日志确认召回的 Top 5 切片里有没有正确答案如果有说明问题出在重排或者生成环节重排序挨个检查重排分数和 Prompt 约束如果没有正确答案说明问题出在召回这时再往切分策略、嵌入模型、查询改写方向查。我整理了一个速查表团队内部排查问题时照着走现象可能原因优先排查方向检索结果和问题完全不相关查询改写过度/切片粒度不合理检查改写后的问题、切片长度召回里有真相但答案说找不到权限过滤拦截/重排把正确项挤掉查检索请求的角色标签、重排分数答案来源引用错误文档上下文混杂了多个主题收紧重排阈值、限制引用数量图片相关问题命中率低图片描述生成太泛重新校验视觉描述的关键属性回答前后矛盾同一用户跨知识库提问检查对话上下文是否带权限策略新规范更新后回答仍是旧标准版本过滤未生效查元数据版本字段、重建索引这个表不足以覆盖所有情况但能帮你在面对莫名奇妙的问题时快速缩小范围。技术从业者很容易一上来就怀疑模型能力其实大部分线上问题都出在数据处理和权限配置这些“不性感”的环节。6.3 最后再分享一点实在建议如果让我重新做一遍这个项目我会在立项阶段就把一件事做得更狠先花两到三周把公司真实的高频问题清单做出来并且让每个问题都落到对应的文档和责任人。有了这张清单后面所有技术决策都有清晰的靶子。技术选型、切分粒度、检索调优全都在为这批问题服务不会被各种“看起来不错”的方向带偏。另一个建议是控制范围。第一个版本只做一到两个业务域哪怕只能回答工程部的工艺问题只要回答准确、方便、有引用一线员工就会主动用起来。有了第一批真实用户和真实反馈再逐步扩展到客服、设计、材料、售后节奏会顺很多。最怕的是追求“全覆盖”几百个模板文档一次性灌进去结果每个问题都答得模棱两可用户试几次就再也不来了。多模态 RAG 对企业最大的价值不是替代人而是把散落在员工脑子和硬盘里的经验变成公司的固定资产。项目上线至今我最高兴的不是模型答对了多少题而是看到一个新入职的工程助理能靠这个系统独立查清一套隐蔽工程的全部验收规范。知识被真正用起来这个项目才算没有白做。