做这个项目之前我一度觉得知识库这个词跟装修行业没什么关系。直到我们公司把三百多个历史项目的合同、施工图、报价单、效果图和工艺照片翻出来盘点才发现这家公司最值钱的资产全都躺在一个没人能找到的角落——而它们恰恰是最典型的多模态 RAG 知识库素材。如果你是一家装修公司的负责人或者你在任何传统行业负责 AI 落地这篇实战记录应该能帮你少走几个月的弯路。1. 装修公司的知识管理困局老板为什么拍板要上 RAG1.1 痛点不是没知识而是找不到知识我所在的公司是一家三百多号人的装修企业业务覆盖设计、施工、主材和软装。体量不算大但项目类型很杂家装、小工装、旧房改造都有。真正让我意识到知识管理出问题的是三件特别不起眼的小事。第一件客服那边。每天有二三十条咨询其中三分之一是重复问题你们用的是什么板材柜子质保几年已经装到一半还能改设计吗这些答案其实在官网、合同模板和内部 FAQ 里都有但客服新来的小伙伴得在微信记录里翻半天才能找到标准说法。第二件设计师那边。有客户拿着手机里一张北欧风的客厅照片来问我们家 89 平能不能做设计师得先从公司图库里找类似户型、类似风格的案例再翻聊天记录找之前合作过的软装品牌。这个过程普遍要三到五个工作日。第三件工地那边。有位工长在群里问卫生间回填工艺用的是哪个版本的标准轻质回填还是陶粒回填结果施工部的同事翻出一份三年前的 PDF里面写着旧工艺做法。等发现这个问题的时候现场已经按错误工艺施工了两天。这三件事共同指向同一个结论企业不缺知识缺的是能把知识在正确的时间送到正确的人手里的通道。传统做法是靠人肉搜索引擎——问老员工、翻共享盘、查聊天记录效率低不说准确性也没法保证。1.2 为什么最后选了 RAG而不是微调一个行业大模型立项前的技术讨论会上团队里有人提出过两条看似更 AI的路线一是直接买一个通用大模型服务靠提示词硬扛二是拿公司历史资料微调一个专属大模型。这两条路线被我当场泼了冷水。通用大模型连我们公司的材料清单都记不住更别说回答08 户型的主卧背景墙当时用了什么工艺这种具体问题。你给再长的提示词模型也不知道你家公司有个 08 户型。微调大模型的成本更不用算图纸、合同、效果图、施工照片这些多模态数据光是清洗和标注的人力就够养一个小组了而且公司知识每周都在变每更新一批材料就微调一次这根本不现实。RAG检索增强生成的逻辑刚好反过来先按需检索再让大模型基于检索到的材料组织答案。它不要求模型记住企业资料只要求模型学会查资料。知识更新只需要维护好数据库不用重新炼丹。这个思路在今天已经是行业共识但在我当时给管理层汇报的时候还是花了两个晚上才让老板理解为什么我们不是买一个现成的问答机器人。真正推动老板拍板的是那张投入产出对比表微调大模型要花几十万买算力还要专职算法工程师维护RAG 方案的服务器成本只有前者的零头知识更新靠业务部门自己就能完成。对于一个毛利本身就不高的装修企业这笔账不用算第二遍。1.3 项目的边界不追求全能问答只解决三个场景立项后我做的第一件事不是选型而是把项目范围砍到只剩三个场景客服问答面向客户咨询的标准话术、材料说明、施工流程、售后政策设计辅助设计师按户型面积、风格、预算找历史案例和效果图施工支持工长和监理在工地现场查工艺标准、材料用量和常见问题。这三个场景有一个共同特征高频、重复、有标准答案。它们才是知识库最容易见效的地方。其他场景比如自动出报价自动画施工图当时连想都没想因为那不是知识库能解决的问题后面再描述。2. 多模态数据盘点装修资料里到底藏着哪些非文字信息2.1 不看不知道翻了三个服务机柜才凑齐资料全集开始动手之前我们花了整整两周做数据盘点。资料分散在三个地方公司共享盘、设计师个人电脑的 D 盘、以及几十个微信群聊天记录里。最后汇总出来的清单大致是这样数据类型原始载体关键信息载体使用场景施工工艺标准Word/PPT 转的 PDF文字 节点示意图施工支持设计案例效果图 方案说明图片为主文字为辅设计辅助户型图CAD 导出图 / JPG图形 面积标注 房间分布设计辅助报价单 / 材料清单Excel / PDF表格数字敏感客服问答合同模板与补充协议PDF / 扫描件文字 印章区域客服问答工地现场照片JPG / PNG图内细节 拍摄说明施工支持材料小样图册品牌商提供的图片 PDF图 参数表格混排设计辅助、客服问答盘点完我自己也吓了一跳非文字信息占了全部资料的大约四成。而这些非文字信息恰恰是装修行业知识密度最高的部分。一张北欧风效果图比五百字文字描述更直观一张卫生间防水节点图比工艺规范里十句话都有说服力。如果只做纯文字版 RAG等于把这四成资产直接扔进碎纸机。2.2 三种麻烦鬼扫描件、表格、竖版长图盘点的过程中我们提前识别出了三类日后一定会出问题的数据。第一类是扫描件合同。年代久远的合同是拿手机拍照或者老式扫描仪扫的分辨率低、纸张泛黄、还有手指头不小心入镜的情况。这种文件直接进 OCR 引擎出来一堆乱码不打紧怕的是识别结果似对非对——字体看起来正常但金额数字被认错。第二类是报价单和材料清单。这类文件的特征是大表格、多级表头、合并单元格。如果解析时把表格拍平成一个段落再切片数字所在的列就丢了更没法回答某品牌某型号板材多少一平这类问题。第三类是竖版长图。装修公司的很多工艺说明喜欢用一屏一屏的竖图排版一张图里有几十条步骤。这种图如果只截取局部做索引很容易把上下文切碎。后来我们统一把它们重新导出成横向 PDF 文字说明的配套组合才彻底解决。这三类数据在盘点阶段看着只是格式问题但在后面的解析阶段其实决定了整个 pipeline 的选型。所以我说盘点这一步是整个项目性价比最高的一天——它帮你提前知道哪些钱不该花。2.3 为什么不做一刀切的图像识别当时市面上做图像内容识别的解决方案不少很多是把所有图片统一送进视觉理解模型输出一段描述文字再进文本向量库。在演示环境中一切完美但放到装修公司真实资料上我很快发现了问题视觉模型对户型图的理解跟设计师完全不是一回事。通用视觉模型能看出这是一张卧室的照片但很难理解这张户型图是 89 平三房一卫、客厅朝南、主卧门和次卧门相对。户型图上的逻辑关系是结构化信息不是是什么物体的语义信息。它需要的是把面积标注、房间名、门洞位置抽出来再跟图本身建立的视觉索引做配合。于是我们确定了项目的核心约束不能用单一模型打天下必须根据内容类型分路处理。这也是整个多模态 RAG 架构设计的最初出发点。3. 技术选型与架构设计为什么最终选了双层路由 分治解析3.1 三种候选方案对比在设计整体架构之前我让团队出了三套方案专门开了一整天的评审会方案 A全量多模态向量化把所有文档、图片、表格统一转成多模态向量查的时候用一个向量检索搞定。优点是链路短缺点是造价高、解释性差——你很难说清楚一张效果图为什么排在报价单前面。方案 B全量解析成文本所有资料先 OCR / 解析成 Markdown 文本统一走文本向量库。优点是好落地缺点是表格和图纸的结构信息全丢了。方案 C双层路由 分治解析最终采用 入口先做一个轻量级意图识别判断用户问题到底要检索文本、图片、表格还是图纸然后各类型资料走各自最合适的解析与索引通道检索结果统一汇聚到重排模型再交给大模型组织回答。方案 C 当时看起来最复杂但我坚持选它理由有三点第一装修知识的检索需求天然是分裂的。你们用的什么板材是文本检索“这个茶几配什么风格的沙发”是图片检索“08 户型的主卧门要不要改方向”是户型图检索方案文本检索。把它们揉在一个向量空间里只会互相干扰。第二分治解析的扩展性好。以后如果增加视频巡检资料只需要新加一个视频解析通道原来文本、图片的通道完全不动。第三每个通道都能独立调试。现在后端同事改图片解析逻辑的时候不需要担心影响到合同解析那一路。对于只有三个后端开发的小团队这种隔离非常重要。3.2 系统最终的五层架构项目最终形态分为五层我尽量用大白话说清楚每一层干的事文档接入层对接公司共享盘、钉钉文件和本地数据库定时扫描增量文件按项目编号、日期、类型打标分治解析层文本走文本通道PDF 解析、表格抽取图片走图像通道检测、OCR、视觉描述生成、裁剪户型图走专门的户型信息抽取通道向量化与索引层分别构建文本向量库、图片向量库、结构化属性库比如面积、风格、造价区间都作为可过滤的字段路由与检索层识别 query 类型分发到对应通道检索并做粗召回 重排序融合答案生成层把检索回来的片段拼成带引用的上下文交给大模型生成答案同时在下方案展示出处链接。这套架构听起来跟通用 RAG 差不多真正的差异在第二层和第四层——它把装修行业的多模态不当作图片文字的简单堆叠而是当作文本、表格、户型图、效果图、工艺照片五种相互关联但本质不同的知识类型去处理。3.3 路由层的轻量是关键很多设计会把路由层也做成一个大模型调用我特意把路由设计成结构化规则优先 模型判断兜底的轻量机制。比如用户问你们主卧室背景墙方案有没有 2 万以内的结构规则直接根据价格关键词户型词命中设计案例通道用户问一句我想要原木风但又不想太素结构规则判断不了才交给语言模型做语义分类。这么设计的理由是省钱和稳定。路由层每多一次大模型调用就多一次延迟和失败风险。对于装修公司这种没有专门运维团队的场景宁可让路由笨一点也要保证它每次都走同样的路。后来实际跑下来大约 75% 的查询用规则就分对了剩下的 25% 才真正花大模型的推理费用。4. 知识库搭建实战从图纸、合同到施工标准的数字化4.1 文本资料的清洗与表格保真文本通道处理的第一个大坑就是前面说的报价单表格。刚开始我们直接用现成的 PDF 抽取工具把表格拍平成了拼音数字的一串文本切片之后 embedding 的效果惨不忍睹。后来我们调整为表格组件识别 → 转成 Markdown 表格 → 把每个表格作为一个独立 chunk 入库。每个表格 chunk 前面加了表格标题和项目编号作为上下文这样就保住了表头-列-行的对应关系。回答某品牌某型号多少钱一平这一类问题时大模型能直接从 Markdown 表格里找到精确数字。合同类文本处理相对简单但有一个细节值得提盖章扫描件的 PDF 必须按页切不按段落切。合同里甲方乙方这些字段跨越不同条款按页切能保证完整上下文按段切反而会切碎关键义务条款。切片大小我们统一使用 512 token 的重叠策略重叠窗口设置 32 个 token避免跨段断裂。4.2 效果图和户型图的图文配对入库法图片是最需要设计的地方。一开始我们也尝试直接把所有图片丢给视觉模型生成一句描述然后把描述文本存库。但很快就发现一个问题一句描述根本承载不了一张效果图的信息量。后来我们改用图文配对思路对每张效果图先让视觉语言模型生成结构化描述空间类型客厅/卧室/卫生间、风格现代/北欧/原木/轻奢、主色调、家具材质、亮点设计再把它对应的历史项目方案文字说明作为附属文本一起绑定到同一个向量表示上检索时query 同时匹配图片视觉向量和绑定的文本向量取最高分。这样做的好处是当客户说我想要原木风、浅色调、沙发背景墙不要岩板时系统能同时从图片的风格标签和文字的项目描述两个维度命中比单纯靠图像 embedding 泛泛找相似图准得多。户型图的处理走的是另一条路结构化抽取 视觉索引双轨。抽取的部分包括房间数量、建筑面积、各空间尺寸、朝向、承重墙位置、门洞位置。这些抽取结果不直接作为文本向量而是作为结构化字段存下来供检索时做硬过滤——比如面积在 80 到 100 平这种数字区间条件。4.3 工艺照片和现场验收照片的处理工地现场照片的问题完全不同它们太相似了。三个月内的几十个工地都拍过卫生间防水施工中的照片光靠视觉 embedding 区分度非常差。照片之间的差异在细节墙面有没有做 30 公分的防水上翻、地漏处有没有做附加层、管根有没有做圆弧处理。处理这类图片的关键在于照片的陪伴文本。我们把每张工艺照片和它对应的拍摄说明、验收标准绑定成一个知识单元。照片里看不清的细节靠文字补充文字说不清的形态靠照片确认。后来上线之后这类照片标准的组合反而是工长使用频率最高的功能之一。对于已经归档的老照片我们实在没法回去问当时的拍摄人就靠工长访谈把常见做法的标注补充进去。这活儿很费人力但做完整整一年之后相当于把公司历史上零散的施工经验整理成了一套带图文对照的工艺档案库。这个隐性收益比问答系统本身的价值还大。4.4 元数据体系和权限过滤装修公司的知识有一个特殊性非常讲究项目维度。同一套设计图在报价阶段是商务机密在施工阶段是现场依据。如果知识库不区分角色权限很容易出现客服把成本价报给了客户这种事故。我们在每个 chunk 上都挂了元数据元数据字段示例用途doc_type合同/报价/工艺/案例/户型路由分发project_idP202300124关联项目role_scope客服/设计/施工/管理层权限过滤trade水电/木工/瓦工/油漆工艺场景过滤area_range0-60/60-90/90-120户型场景过滤style现代/北欧/原木/轻奢设计场景过滤这套元数据在检索时承担了双重职责一是做硬过滤直接砍掉不该出现的内容二是做重排加成比如用户限定了90 平以内那么面积元数据匹配的案例在排序时会有更高权重。5. 检索效果调优装修专业词汇和图像检索的双重难关5.1 专业术语检索的同义词坑系统第一次内测我们拿真实问题测了一轮结果惨不忍睹。用户问墙板收口怎么处理系统召回的内容是多层实木夹板的安装规范——看起来沾边但实际上完全没有回答收口工艺。问题出在词面上收口这个行业词在资料库里对应的术语其实是阳角/阴角处理压条收边海棠角。装修行业的用词和书面术语之间的映射关系非常发散。同一个做法工长叫压边设计师叫收口材料商叫封边图纸上写的是线条收口节点。如果知识库没有术语归一纯靠 embedding 的语义相似度根本救不回来。我们采用三级方案解决建行业同义词表由三位资深项目经理和两位设计师共同整理出约四百组同义词同步注入到文本索引之前的分词词典和查询改写模块查询改写用户输入收口时系统自动扩充检索词同时搜收口/收边/压条/阳角处理/海棠角可解释反馈搜索结果展示相关搜索词提示让用户知道系统理解了哪些扩展概念用户不懂行业术语也能持续修正查询。5.2 图像检索的看得像与不对路图片检索调优比文字麻烦得多因为一张效果图可以同时命中好看和不是你要的那种好看。我们遇到的典型事故发生在内测第二天。当时有团队同事拿自家户型试问题140 平四室两厅想要新中式风格电视墙不要复杂的格栅。系统返回了一张效果图风格确实新中式但仔细一看那是一个 60 平小户型的客餐厅一体设计。原因是纯视觉 embedding 匹配的是风格家具形态完全忽略掉了面积和户型结构。这个问题的解药不是调整 embedding 模型而是把路由层和检索层的数据结构调整好。我们在路由层抽取了明确的户型面积 - 风格 - 预算槽位面积和户型做硬过滤风格做语义检索检索结果到了重排阶段再按户型结构相似度 风格相似度 文本描述相似度综合打分。经过这轮调整45 平 LOFT 想要新中式和140 平四居室想要新中式再也不会互相串门。5.3 大模型一本正经胡说八道的约束办法多模态 RAG 的大模型生成环节最怕的不是模型啥都不会而是它基于检索片段自由发挥造出一个看似专业、实则不存在的工艺标准。我们规定答案必须由若干检索片段拼接而成所有说法都有片段出处如果检索没有相关内容模型必须回答资料库中未找到该标准允许以建议形式提示建议咨询工程技术部不允许自行编造。这里通过系统提示词里强约束 后置规则双重兜底。我们只允许模型基于检索到的文字、表格、图片说明生成答案并且在答案下方固定展示出引用资料区列出命中的文档标题和页码。效果立竿见影。内测阶段幻觉率大约 18%上了引用约束之后降到 6% 左右。剩下的 6% 主要是模型对检索片段里语义相近但性质不同的内容做了过度概括——这时候单纯靠约束就没用了只能从源头提高召回质量。5.4 线上演示翻车引出的槽位校验机制项目上线发布会当天我们安排了一个现场演示环节结果当场翻车。市场部的同事上台提问“我们公司最新的 140 户型装修套餐是什么”系统把“140 户型”识别成了“140 平户型”一下检索出来几十条内容回答非常发散台下技术团队脸色都变了。复盘之后发现问题出在实体识别的粒度上。户型编号140 户型是公司内部指代某一栋楼特定户型的专有名词但通用实体抽取把它拆成了数字140和平数140平来理解。后来我们加了一套行业实体感知的槽位校验数字关键词优先匹配项目编号/户型编号字段只有在匹配不到项目编号的情况下才回退到平数语义。同时在上线演示系统里加入了人工纠正按钮万一自动识别错了演示人可以直接圈选正确检索范围兜底。6. 落地后的日常运营与常见坑垂直行业做 AI 落地的几点提醒6.1 知识库不是建完就完而是要当产品持续运营项目上线后最初的三个月效果还行但第四个月开始掉数据。回访后发现原因不复杂新的设计方案、新工艺、新材料都在持续产生但没有人在维护。后来我们从每个业务部门抽调了一个兼职管理员每周花半天时间把新增资料按规范丢进知识库。这套业务兼职 技术兜底的运营机制比任何技术优化都重要。更新后的知识库要重新建立索引但没必要每次都全量重建。我们按项目维度和类型维度做增量更新合同、报价一类的文档更新频率低工艺标准每月复核一次设计案例每周增量导入。索引更新的频率服务于业务真实节奏没必要追求实时。6.2 权限问题的第二条生命线之前提过元数据里的 role_scope这里我想多说一句。很多 RAG 项目做不好不是检索不行而是权限控制没跟上导致业务部门不敢用。我们早期发生过一个事故客服在测试环境里问这个项目成本多少系统竟然把内部采购价当回答生成出来了。幸好当时还在测试期没造成实际损失。那次之后我们把权限过滤提升到检索链路的第一位每个租户角色进入系统就带上权限上下文路由器分发的第一个动作就是按权限过滤候选集合。方案本身不算复杂但一定要在项目一启动就设计权限模型而不是等系统能跑通了再补否则返工成本极高。6.3 对传统行业做 AI 落地的几条体会最后说点个人体会可能有些不适合听第一不要先找技术再找场景反过来才对。装修公司不缺技术热情缺的是把客户总在问同样的问题这种日常烦恼翻译成需要一个带检索的知识库的能力。技术选型应该从业务痛点倒推。第二多模态的多不是炫技。对我们这个项目而言如果只处理文本顶多做一个不太准的 FAQ 机器人把户型图、效果图、工艺照片纳入进来以后它才真正变成了设计师和工长愿意用的工具。多模态 RAG 的价值取决于行业里看图说话的知识占比。第三系统要能解释自己。每个回答都带引用来源看起来只是产品功能其实是建立信任的过程。传统行业的老师傅骨子里不相信黑盒子——他们能接受机器帮忙找资料但不能接受机器替他做判断。所以给资料、不给结论反而是这套知识库最被认可的设计。这项目从启动到打完收工前后花了四个多月。中途有几天我也怀疑过自己是不是把一个简单事搞复杂了——现在回头看如果没有那套双层路由和分治解析后面所有的调优都会变成在一团乱麻里打补丁。如果你也在某个看起来不那么高科技的行业里做 AI 落地我的建议是先盘资产再定边界然后大胆让业务人员提需求技术是你的工具但业务才是你真正的产品经理。