去年接了一个挺有意思的项目帮一家本地装修公司从 0 到 1 搭一套企业级多模态 RAG 知识库。坦白讲刚听到装修公司要做 RAG这个需求的时候我心里是打问号的——这行既不缺数据也不缺场景但真正缺的是一个能把散落资料串起来的系统。等我进了项目翻了他们的共享盘和微信群聊天记录之后才意识到这个需求比很多互联网公司都硬核施工工艺手册、效果图、材料报价单、保修条款、客服积累的上万条问答记录全堆在网盘和聊天记录里想查一个具体参数基本靠人肉记忆。这篇文章会把整个落地过程从头到尾拆开包括方案选型、数据清洗、图文对齐、检索调优、上线运维以及我踩过的那些坑。如果你也在给传统行业做 AI 知识库或者正准备升级自己的 RAG 方案这篇应该能帮你省下不少时间。1. 背景拆解装修公司到底需要什么样的知识库1.1 先摸清楚这家公司的资料家底项目启动第一周我干的最多的事情不是写代码而是翻文件夹。这家公司本身规模不大一个设计部、一个工程部、一个客服售后团队但共享盘里的东西多得吓人。我大致盘了一下最终纳入知识库范围的文件有这些PDF 文档约 5400 份其中大半是施工工艺标准、验收规范、设计案例册不少是扫描件图片约 3200 张包括效果图、主材实拍、工地现场照片、户型图Excel 表格 1800 份主要是报价单、材料清单、施工进度表客服部门的问答记录 6400 多条散落在几个文档和聊天导出文件里还有一些 Word 版的公司制度、售后保修细则、合同模板总量加起来大概 68GB听着不大但乱是真乱。同一份工艺手册存在三个版本报价单有 2019 年的也有 2024 年的图片命名是微信图片_20230915_103255.jpg这种风格。最要命的是这些资料长得都不一样有的是纯文本 PDF有的扫描件糊成一团有的表格有合并单元格有的图片里全是水印。这个阶段最大的收获是我意识到知识库建设 80% 的功夫在数据整理模型和框架反而是最省心的环节。如果你打算做类似项目第一周别急着选型先让客户把资料归档目录拉出来人工看一眼再定方案能避掉后面至少一半的返工。1.2 为什么纯文本 RAG 搞不定装修知识很多人在设计 RAG 方案时会下意识默认知识 文字但装修行业打破了这个假设。我举几个真实场景你就明白了。客服那边经常接到这样的问题你们这个灰色哑光地砖配什么颜色的墙比较好看这个问题里客户真正想看的其实是瓷砖实拍图、铺贴效果图光靠文字描述灰色哑光600x1200根本没法让客户满意。设计师查工艺时也会问卫生间防水施工的验收标准是什么闭水试验做多久这类信息在手册里通常配着现场施工照片图上标注了关键点位光抽文字出来会丢掉大量细节。还有一类内容是表格。报价单里的信息密度特别高品牌、型号、规格、单价、单位、工艺说明全部塞在一张表里。普通文本切片方式会把一行行数据拆得七零八落检索某型号瓷砖的单价时经常只能召回半个表格。所以纯文本 RAG 在这个场景下基本是瘸腿的。知识库必须做到图、文、表三类内容都能被检索到并且能一起返回给大模型作为上下文。这就是多模态 RAG 存在的意义——不只是把图片存进去而是让用户的问题能同时命中文字、图片和表格然后拼成一个完整的答案。1.3 场景优先级先把钱花在刀刃上企业知识库最忌讳的是什么都要做。这家装修公司最开始列了十几个需求包括给客户自动生成设计方案、自动算报价、自动审合同等等。我直接砍掉了一半原因很简单数据还没到位做出来也是玩具。最终我们按数据成熟度 × 业务频次 × 可量化收益三个维度排序定了四个核心场景场景使用者数据基础价值售前咨询问答客服/销售产品图册、报价单、常见问答高频直接提升客户响应速度工艺标准查询设计师/工长施工手册、验收规范、现场照片决策依赖减少返工和纠纷售后政策查询售后客服保修细则、合同模板敏感度高减少客诉新人培训辅助全体员工全量资料长期价值降低传帮带成本优先做第一个。理由也很直白客服是知识库使用频率最高的角色他们的问题大多是重复的而且答案对不对很容易判断——回复错了一个产品参数客户马上就能发现。在这个场景跑通整个链路之后再横向复制到其他场景成本会低很多。2. 技术底座从文档解析到生成回答的完整链路2.1 文档解析链路不同材质用不同工具装修公司的文档来源五花八门统一用一种解析方案必然翻车。我的做法是把文件按出生方式分成三类用不同的链路去处理。第一类是电子版 PDF 和 Word这类文件本身有文字层直接用文本抽取库提取即可速度快、成本低。第二类是扫描件 PDF 和拍摄的照片这类必须上 OCR 和版面分析。第三类是 Excel 报价单这类不能当普通文本来抽要用表格模型把结构还原出来。OCR 这块我对比过好几个开源方案。先说结论对扫描版工艺手册这种排版固定、字体统一的资料开源 OCR 套件的效果足够用而且胜在可以私有化部署。装修公司的资料里有大量客户信息、报价金额、合同条款数据出域是底线问题所以一开始就把商业 OCR API 排除掉了。版面分析同样关键。很多扫描件是 A4 纸对折再扫描的页面里有页眉、页脚、多栏文字、穿插图片直接整页 OCR 会把无关内容混在一起。我们用的方案是版面检测 区域分类 分别识别先把页面切成标题、正文、表格、图片几个区域再对每个区域做对应处理。这一步做完后面的切片质量才有保障。我在解析阶段用的核心参数如下可以参考OCR 检测阈值调到 0.5 左右避免漏掉较淡的印刷字版面分类里把页眉页脚单独标记后续切片时直接丢弃表格区域单独走表格还原模型输出成 Markdown 表格图片区域单独裁剪出来保存成独立图片文件并记录它在原页面中的坐标这里有个很容易犯的错误把 PDF 的每一页当成一个整体去切片。千万别这么干页面上常常混合了多种语义块切出来的 chunk 大概率是半页工艺说明 半页材料表这种缝合怪检索时永远命不中完整信息。2.2 Embedding 选型单模态向量加图片描述最省心多模态 RAG 里有两条技术路线。一条是真多模态用一个跨模态模型把图文映射到同一个向量空间比如 CLIP、SigLIP 这类模型另一条是桥接式多模态先用一个多模态模型把图片翻译成描述文字这叫 image caption再把描述文字和普通文本一起做向量检索。两条路线我都试了最终采用的是第二条单模态文本向量 图片描述桥接。原因有三个。第一可控性好。图片描述是显式的文本我可以直接检查这个描述到底准不准出错了改 caption 比重新训练模型快得多。第二检索精度好。装修领域的专业词很多比如波打线垭口过门石通用图片描述模型不一定翻译得准但我可以用规则或人工批量修正这些描述。第三成本低。CLIP 这类模型对 GPU 显存要求高检索时要同时把图文都过一遍模型延迟和成本都上去了。文本向量这块我选的是中文效果比较稳的开源向量模型输出维度 1024。图片描述用的是部署在内网的多模态模型批量跑了一轮给全部 3200 张图片生成了描述文本。描述模板大概是这张图展示了[空间/物品]特点包括[颜色/材质/风格]可用于[场景]。生成完之后我又做了一遍人工抽检准确率大概 95%剩下的 5% 通过改写描述来修正没有重训任何模型。2.3 检索框架混合检索 重排是标配真正把检索做好靠的不是单个向量模型而是文本稀疏检索 向量稠密检索 重排的组合。我给的配置是这样的BM25 稀疏检索负责精确匹配型号、品牌、专有名词这类关键词稠密向量检索负责语义匹配比如灰色砖配什么墙这种问题两者结果用 RRFRanked Reciprocal Fusion融合然后把 Top 20 交给重排模型重排模型输出打分最终取 Top 5 作为上下文送给大模型为什么需要重排这一步因为向量检索出来的 Top 20 里通常有七八个是和问题语义沾边但不完全对的内容。重排模型会在更精细的粒度上重新打分把最相关的内容顶上来。我实测过加了重排之后答案的引用命中率从 62% 提到了 81%这提升非常可观。向量库初期我直接用了 pgvector没上独立的向量数据库。原因是数据量不算大整个库切片之后大概十万个 chunkpgvector 完全扛得住而且能和业务表放一起运维省心。真要到了百万级以上再迁移到专门的向量库也不迟这是典型的按规模选工具的思路。3. 落地实操从数据到好用要过的几道关卡3.1 数据清洗脏数据直接决定 RAG 的上限技术上最无聊、但影响最大的一步是清洗。我见过不少团队兴致勃勃搭好 RAG结果一测就翻车最后发现是源头数据太脏——一个跟主卧设计相关的 chunk 里混着广告水印文字一个报价单表格被 OCR 成乱码一张图片被旋转了 90 度。我们这轮清洗分文件层和图片层两层做。文件层做了三件事去重、去档案、去超时。按文件哈希去重把不同版本目录下的重复件清理掉把和业务无关的行政文档、报销单、团建照片全部剔除把最后一次编辑时间超过三年的旧版文档单独归档不进知识库避免旧参数、旧价格污染答案。图片层的清洗更考验功夫。工地实拍图里大量是模糊、过曝、重复的废图我跑了一个轻量的图像质量筛选流程先算清晰度评分低于阈值直接丢再做感知哈希去重连续拍了很多张的同场景照片只留一张清晰的最后人工过了一遍疑似问题图把有客户人脸、有报价白板翻拍的图全部移除。这块花了大概两天时间但对最终体验的提升是最直接的。清洗阶段我学到的教训是别把清洗看成一次性任务它应该是一套可复用的脚本和流程。因为知识库是活的每个月都会有新的工艺照片、新的产品资料进来只有把清洗流程固化成自动化流水线后面才不需要每次靠人工手动来一遍。3.2 切片策略给装修资料量身定做切割方式切片是 RAG 项目里人人都会但没人做得精细的环节。装修公司的资料结构差异大我用了一套分类型的切片策略。工艺手册这类长文档按文档内嵌的章节层级切。先解析出标题结构一级标题、二级标题每个章节作为一个大段如果章节太长再按段落边界切成 512 token 左右的块块与块之间保留 50 token 重叠。这么做的好处是一个 chunk 总是一个完整的知识点而不是半道工序。报价单和材料表完全不能用上面的方式。这类内容信息密度极高切成 512 token 的文本块会破坏表格结构。我的做法是先把表格还原成 Markdown 表格然后每个产品行连同表头单独切成一个 chunk。这样用户问某型号瓷砖的规格和价格命中的就是完整的一行参数而不是半张乱掉的表格。客服问答记录是最简单的每条 QA 单独作为一个 chunk不合并、不截断。因为这些问答本来就是人工维护的高质量语料一条一个知识点直接喂给检索就是最佳形态。图片单独作为一种 chunk 类型处理。每张图片一个 chunkmetadata 里记录文件路径、所属文档、章节名、图片描述文本。检索时图片 chunk 的描述文本会被向量化参与匹配命中后返回图片本身。这里要特别强调 metadata元数据的设计。我给每个 chunk 都挂上了这些字段来源类型PDF/图片/表格/问答、所属部门设计/工程/客服/售后、关键词标签、版本号、入库时间、权限级别。后面章节会讲权限控制——没有 metadata权限就是空谈。3.3 图文对齐让文字检索能带出图片多模态 RAG 的核心难点是图文对齐。用户的问题是文本但答案可能需要图片这中间怎么打通我们做的方案可以概括为图片描述 上下文绑定双通道。第一通道是图片描述检索前面提到给每张图生成了描述文本查询时描述文本参与向量匹配。比如客户问灰色地砖配什么墙如果某张效果图描述里有灰色哑光地砖、米白色墙面这张图就能被召回到。第二通道是上下文绑定工艺手册里文字提到闭水试验的那一页往往配着一张闭水试验现场图我把这条文字 chunk 和图片 chunk 通过文档坐标和章节号绑定在一起检索到文字 chunk 时直接把绑定图片一起取出来。这两个通道加在一起的效果是检索结果里有文字、有图片、有表格大模型生成的答案可以引用图片作为参考。客服在线上回复客户时可以直接把系统检索到的效果图发给客户看——这个功能做出来后客服团队的主管是最兴奋的因为以前找一张案例图要翻半天相册。做图文对齐时有一点要注意图片描述生成的质量直接决定召回效果。如果描述写成这是一张室内照片这种废话那跟没描述一样。我们的描述强调三个要素空间类型客厅/卫生间/厨房、核心物件瓷砖/柜体/台面、视觉特征颜色/纹理/风格缺一不可。3.4 Prompt 和回答风格设计让 AI 说人话也守规矩RAG 的生成端不是随便接个大模型就行Prompt 设计直接决定回答能不能用。我为这家装修公司定了一套规则主要有四条。第一回答必须引用来源。所有回答的末尾要带上知识库里的文档编号和章节方便客服复核。第二不知道就直说。检索结果里没有相关内容时模型必须回复这个问题我需要确认后再回答不许编造。第三产品信息必须和库里一致。报价、型号、保修期这类硬事实只允许从检索上下文里抽取不准模型凭自己的知识补全。第四语气要有行业感。装修客户咨询经常涉及大额消费回答语气要求礼貌、专业、不催促。系统提示词里我还加了一条很关键的约束如果问题涉及具体工地的实况比如我家现在装修到什么进度了模型必须明确表示自己不知道建议客户联系项目经理。因为知识库里没有实时工地数据硬回答就是幻觉在装修这种强信任消费场景里一次错误回答可能丢掉一个客户。4. 踩坑实录上线前后最容易翻车的地方4.1 检索不准先按这五个原因排查项目上线后我接到最多的反馈就是问的问题答非所问。每次排查我基本都按这个顺序走命中率很高。第一查切片粒度。有一种典型表现问 A 问题召回来的片段里只有半句话提到 A其他全是 B 的内容。这种情况通常是切片把两个知识点切到了一起解决方法是按语义边界重新切。第二查图片是否有描述。如果用户问的是视觉相关的问题但召回结果里一条图片都没有基本就是 caption 缺失或描述太泛先去补图片描述。第三查专有名词。装修行业词如乳胶漆石膏板美缝剂在向量空间里很容易和相似词混淆解决方式是扩充同义词表用户习惯说刷墙而库里写的是墙面涂饰这个 gap 不补齐召回永远差一截。第四查表格还原质量。报价单表格还原错了检索内容就是错的直接人工抽检表格结果。第五查重排阈值。有时候重排模型把正确答案压到了 Top 5 之外适当放宽 Top N 或者调整融合权重就行。4.2 报价单和表格是重灾区整个项目里最有技术含量的活其实是 Excel 报价单的处理。装修公司的报价单格式极其多样有的用合并单元格有的有多级表头有的一个 sheet 里有多个表格有的在表格中间嵌了图片。OCR 还原这些表格时合并单元格一拆数据就错位了多级表头一合并字段名和值对不上。我的处理方案是表格结构还原 规则校验两段式。先用开源表格模型把表格转成带结构的文本再用一组规则做校验价格列里必须是数字规格列里必须包含mm或x之类的单位模式品牌列不能为空。校验不通过的行直接标记为低置信度检索时不参与语义匹配避免脏数据污染结果。这个思路可以沿用到任何行业的表格类文档——规则校验永远比模型更值得信任模型负责理解规则负责兜底。4.3 权限控制同一个库不同人看到的必须不一样装修公司的知识库里有很多敏感内容材料进货价、客户联系方式、内部折扣规则。销售客服能看产品库和话术但不能看进价工长能看工艺手册但不能看客户合同。这就要求知识库必须支持细粒度的访问控制。我们利用每个 chunk 的 metadata 里的权限级别字段把数据分成三级公开级产品介绍、工艺说明、内部级报价单、折扣政策、机密级客户合同、进价表。检索前先根据当前用户的角色过滤 chunk 列表过滤之后再喂给重排和生成。整个流程在应用层做拦截不依赖底层向量库的权限机制这样不管向量库选什么都适用。访问审计也必须有。我们给知识库系统接了一个简单的日志模块记录每一次检索的用户、时间、查询内容和返回结果摘要。最开始业务方觉得没必要直到有一次一个离职员工试图导出全量客户资料被日志拦下来他们才意识到审计不是形式主义。5. 效果评估与后续运营5.1 效果评估指标不能只看模型准不准知识库上线一个月后我从三个维度做了系统评估。第一个是检索层指标召回率和命中率。我从客服实际问答里抽了 200 条真实问题人工标注每条问题的标准答案文档然后跑一遍检索流程统计正确答案是否出现在 Top 5 结果里。最终命中率是 81%这个数字作为基线保留后续每次改动都要复测。第二个是生成层指标答案可接受度。让客服主管对系统生成的回答做抽样打分分三档可用、需修改后可用、不可用。最终可用加微调可用的比例大约 88%剩下的主要是复杂多轮问题需要跳转到人工。第三个是业务指标客服平均响应时间和问题解决率。这个指标是最有说服力的——上线前客服平均响应一个产品咨询要 5 分钟上线后缩短到 1 分半客户满意度评分还涨了。业务指标能拿到老板才愿意继续投入。我强烈建议做 RAG 项目的团队从一开始就建立评估集而不是等项目上线后再补。200 条标注问题只需要一个下午就能做完但后续每一次模型切换、每一个参数调整都需要它来做回归测试否则你的优化方向全靠感觉迟早把系统改坏。5.2 成本优化企业私有化部署怎么省钱这家装修公司的预算有限私有化部署必须精打细算。我做了三处优化。一是模型量化。生成端大模型用量化版本部署效果在客服场景下和满血版基本无差别但显存占用少了一半。二是缓存。高频问题比如你们的保修期是多久有哪些主材品牌命中缓存后直接返回不再走检索和生成链路整个系统的吞吐量提升明显。三是离线批量处理。文档解析、图片描述生成这类重活全部放在夜间定时任务里跑不占用白天的 CPUGPU 只在需要时开机。还有一个容易被忽略的成本点向量维度。如果文本向量用的 1024 维单条数据量大概率在 1.5KB 到 2KB十万个 chunk 才几百 MB向量存储成本很小。但如果你的数据量到了千万级可以考虑先做 PCA 降维到 256 维检索精度损失不大存储和计算省下非常多。5.3 知识库的运营机制这活儿不能没人管最后说一个最容易被忽略的问题知识库不是搭完就能自转的。装修公司每个月都更新产品、调整工艺、变动价格如果知识库没人维护三个月后里面的信息就过时了。我们最终定了一套轻量的运营机制。每个部门指定一个人做知识管理员负责本部门资料的更新入库更新必须走审核流程先用小批量数据测试检索效果确认无误后再全量发布客服在使用过程中发现回答有问题可以直接标记此回答有疑问标记数据每周末汇总给运营人员修正。这个机制看起来不起眼但它决定了这套系统能不能持续用下去。我见过太多知识库项目上线时效果惊艳三个月后因为没人更新数据沦为摆设。AI 知识库的本质不是一次性的技术交付而是一个需要持续喂养的内容产品——这句话值得所有做企业 RAG 的人记在心里。最后再分享一个小经验多模态 RAG 在传统行业落地最大的难点从来不是模型不够聪明而是数据太乱、场景太散、维护缺人。把这三个问题解决了哪怕用的模型是中规中矩的效果也能甩开那些模型很强但数据一塌糊涂的方案八条街。如果你也准备做类似的事建议先在一个高频场景里把全链路跑通、让业务方看到实实在在的收益再考虑扩大范围——技术这东西只有用起来才叫价值。
