做装修这行，有一个很扎心的现实：公司的核心资产从一开始就不在老板手里，不在销售手里，而在资深设计师和项目经理的脑子里。一个干了十几年的设计师，看一眼户型图就知道哪儿能拆、哪儿要防水、怎么改采光最好；一个老工长，听你说完漏水的情况，基本能判断是管道还是防水层出了问题。这种经验一旦遇到人离职、休假、或者业务扩张后新人接手，就全断档了。
我这次帮一家本地装修公司做的AI落地，核心就是把散落在图纸、合同、案例库、工地照片、售后记录里的这些“经验”和“信息”，全部扒出来，塞进一个多模态RAG知识库，让公司里任何人都能像问一个随叫随到的资深老师傅一样，快速拿到答案。咱们不聊那种PPT里飘着的大词，就说这家公司是怎么从零开始，把图纸、合同、照片这些乱七八糟的资料变成一套能跑的系统的。
1. 项目背景与核心痛点：为什么装修公司需要“企业级知识库”
1.1 装修公司的知识困境：资料都在，但找不到
先说说这家公司的实际情况。规模不算小，本地做了十来年，有设计部、工程部、售后部和两个门店。日常产出的资料五花八门：几千套设计源文件、竣工图、主材清单、供应商报价单、几十本项目册、微信群里的工地照片、售后维修记录、还有客户投诉录音。
表面看，这些资料都按项目归档了，放在公司NAS上，目录建得还挺整齐。但真到用的时候就抓瞎。举几个场景：
- 销售谈单：客户拿着一张某楼盘的户型图问能不能做，销售得先去问设计师“咱们做过类似户型没”。设计师可能记得做过，但记不清是哪年哪个项目，目录一层层翻，翻半小时没找到。
- 设计师做初步方案：想参考公司过去的餐厅卡座做法，关键词在NAS文件名里搜不出来，因为文件名大多叫“最终版_改3”这种，图片内容里的造型、尺寸根本搜不到。
- 售后维修：客户家里墙面开裂，上门师傅拍照片回来，老师傅凭经验判断是基层没处理好，但公司有没有相同问题的处理案例和当时的工艺做法，没人能立刻说清。
- 新人培训：新招的设计师、项目经理需要系统了解公司的工艺标准和材料型号，靠的是跟在一个老员工后面“传帮带”，周期长，而且老员工教的可能还不是标准做法。
这就是典型的“数据多、信息少”。文件以非结构化数据为主，常规的搜索工具只能按文件名和文件类型过滤，图片里的内容、图纸里的标注、合同里的条款、聊天记录里的口语化描述，全部处于“不可见”状态。
1.2 为什么是多模态RAG：不完全是追热点，是需求逼的
一开始我也考虑过给公司做一套传统的“文档库”加一个“在线问答机器人”，但梳理完资料类型后，发现单纯的文本RAG根本顶不住。
装修行业的资料天然就是多模态的：
- 设计图纸：含尺寸标注、布局、材料标注，这些信息在视觉层。
- 效果图：风格、配色、灯光氛围，靠像素表达。
- 工地照片：记录现场工艺细节、用材情况、问题点。
- 合同和报价单：有表格、有印章、有条款，结构复杂。
- 群聊记录和售后记录：混杂着语音、图片、口语化问题描述。
只用文本去做RAG，等于把绝大部分有价值的信息直接丢掉了。而且，用户问的问题本身也是多模态的。比如售后人员收到的是一张墙面空鼓照片，他得拿着照片去匹配历史案例；设计师拿到一张网红设计图的截图，想找公司有没有类似做法。这种“以图找图”的能力，纯文本向量检索实现不了。
所以，这里必须上多模态的思路：让系统能理解图像内容、表格结构、图纸标注，并把它们统一映射到一个向量空间里，再和文本一起做混合检索。这不光是为了解决“找不到”的问题，更多是为了让知识复用时，能把“经验”具象化地关联起来——那个老师傅看到照片就知道怎么做，系统也得能看到照片就能拉出来相关的工艺文档、材料和历史案例。
多模态RAG本质上把“看到”和“查到”合并了。
2. 整体架构与核心设计：小成本、可落地、不搞花活
2.1 设计原则：先跑通，再优化
这个项目的预算不是那种动辄上百万的大项目，老板要的是“能看见效果、别太贵、员工愿意用”。所以在架构设计上，我给自己定了几条规矩：
- 不重复造轮子。能用开源方案和成熟服务，就不自己训练模型。公司没有算法团队，也不该有。
- 先保证核心链路通。第一版先解决“图片能搜、文本能问、图纸能查”这三个核心场景，其他花哨功能（比如基于知识库自动生成设计方案）先放后面。
- 数据安全优先。装修公司的图纸和合同涉及客户隐私，所有模型尽量本地化部署或者走私有化接口，不能把资料直接扔到公开的云端API里。
基于这三点，整体架构就分成了五层：
- 数据接入层：把NAS、本地磁盘、微信群文件里的原资料汇聚起来。
- 解析与清洗层：区分文本、表格、图片、图纸，分别做OCR、版面分析、结构化抽取。
- 向量化与索引层：不同模态数据通过各自的embedding模型转成向量，存入向量数据库，并保留元数据（项目名、时间、类型、所属部门）。
- 检索与重排层：接收混合查询（文本+图片），先向量召回，再用Rerank模型精排。
- 问答与展示层：把检索到的多模态上下文喂给大模型，生成回答，并附上引用来源。
这层架构不复杂，但对装修公司这种数据质量参差不齐的场景很够用。
2.2 模型选型：开源为主，私有化部署
在模型选择上，我做了两手准备。
Embedding模型用了开源的通用向量模型，既能处理中文文本，也能映射图像特征。没有直接用CLIP，是因为还要考虑后续对表格、版面、图纸标注的适配。实测下来，通用多模态向量模型对“照片类”和“效果图类”的检索效果足够用，但对“设计图纸”这种线条密集、文字标注小的图片，单独靠通用模型还不行，得叠加OCR把标注文字抽出来再做一层文本索引，后面细说。
**生成模型（LLM）**用的国产开源大模型，私有化部署在公司的GPU服务器上。选它的原因是：
- 中文理解能力足够，尤其是装修行业大量口语化的描述，效果比某些闭源模型更贴合。
- 支持函数调用和引用格式，方便做答案溯源。
- 部署成本可控，一张主流显卡就能跑起来，量化后性能也不错。
Rerank模型用了开源的交叉编码器，中文效果不错。这一层非常关键，装修资料里同类内容太多，比如几十个项目的“水电验收”照片，向量召回后可能带回来都长得差不多，需要Rerank根据具体问题语义来做精确排序，把最符合的那几张顶到前面。
3. 数据接入与解析：真正的脏活累活
3.1 盘点资产，搭一个“数据清洗流水线”
如果只看标题，很多人觉得搭建知识库最难的是“算法”，但实际做下来，最耗时、最影响效果的其实是“数据接入和清洗”。装修公司的存量数据大概有这几个特点：格式混乱、命名随意、重复率高、信息密度低。
我的第一步是盘点。把NAS和各个部门电脑里的资料分门别类拉出来，先按类型统计：有多少PDF、多少DWG、多少JPG、多少Word文档、多少Excel表格。然后按“可用性”分了三类：
- 高价值资料：竣工图、效果图、工艺标准文档、供应商主材手册、完整合同模板。
- 中价值资料：历史项目过程照片、群聊记录里的问答、业主反馈、售后处理记录。
- 低价值/直接剔除资料：重复缓存文件、未命名截图、临时草稿。
盘点完了就写清洗流水线。这一步骤建议用脚本批量处理，千万别手动整理几万个文件，会疯。
清洗流程大概是：
- 按后缀名分类，复制到不同的处理目录。
- 跑一遍文件名清理，把“最终版_改3_最终版”这种冗余命名做规范化重命名，便于后续元数据管理。
- 对PDF和图片做解析。这一步值得多说几句。
3.2 三种“非文本”资料的解析实操
第一种：设计图纸（DWG/PDF格式）
装修公司的图纸主要两种：CAD源文件（DWG格式）和导出的PDF图纸。DWG直接用配套绘图控件导出成PDF或高分辨率PNG，然后再处理。图纸解析有个难点：图里文字小、密度高、还经常压线。
我的做法是分两条路并行：
- 整图切块。把一张A1图纸按网格切成多块小图，分别做识别和向量化，这样检索时能定位到“图纸的某个区域”，而不是整张图。
- OCR叠加。对切块后的小图跑OCR，抽出尺寸标注、材料标注、房间名称，转成文本块，和图片向量一起存进索引。
这样做的好处是，用户问“厨房防水怎么标注的”，系统能通过文本检索直接命中图纸里“厨房”“防水”“JS防水涂料”这些标注词，同时通过图片检索找到对应的视觉区块。两条路的结果再合并去重。
第二种：效果图和实景照片
效果图和实景照片是最典型的多模态数据。一开始我尝试直接用大模型给每张图生成一段详细的描述文字，再把这文字也存进向量库。后来发现这个方案有利有弊。
- 利：大模型生成的描述能把“风格”“材质”“配色”这类高层语义显式化，检索匹配更准。
- 弊：成本高，几千张图一张张调模型接口，费时费钱；而且描述可能不准，反而引入噪音。
最终我采取的折中方案是：对效果图只生成简短的结构化标签（风格、空间、主色调、主要材质），不生成大段描述；对实景照片则分成两类，一类是“工地过程照”（对应工艺工法），一类是“问题照片”（空鼓、开裂、漏水），后者非常重要，因为售后问题照片的价值在于“问题-原因-解决方案”的对应关系，需要额外标注。
第三种：表格类（报价单、材料清单、合同）
报价单和材料清单表格结构复杂，有的还有合并单元格、跨行表头，直接解析成Markdown表格最容易出错。我用的是“语义抽取+表格转文本”的思路：
- 先把表格区域切出来，做结构化识别，得到行列坐标。
- 再把表头和单元格的值按行拼接成自然语言句子。比如“品牌：某品牌；型号：某型号；规格：300x300mm；单位：平方米；单价：xx元”。
- 这样既保留了表格的精确数据，又能让向量模型理解“某品牌300x300砖”这种说法和用户问的“300的砖”匹配上。
3.3 元数据：知识库的灵魂
清洗完数据，最重要也是最容易被忽略的事是打元数据。
什么叫元数据？就是每个文件、每个切块的“标签”。装修公司的知识库里，必须有这几个维度：
| 元数据字段 | 说明 | 示例 |
|---|---|---|
| project_id | 所属项目编号 | P20230101 |
| category | 资料大类 | 图纸 / 效果图 / 工地记录 / 售后案例 / 合同 |
| subcategory | 子类 | 水电 / 木工 / 瓦工 / 油漆 / 安装 |
| source_dept | 来源部门 | 设计部 / 工程部 / 售后部 |
| upload_date | 上传时间 | 2025-06-01 |
| status | 资料状态 | 标准 / 待审核 / 已作废 |
别小看这套字段。有了它，检索的时候可以先用元数据“圈范围”，再在范围内做向量搜索。比如售后人员只想在“售后案例”这个类别里找“墙面开裂”的照片，而不是跑到几百个项目的效果图里乱翻。这个前置过滤一步，能把检索精确度提升一个档次，也能大幅减少后续Rerank的压力。
4. 向量化与检索引擎：多模态怎么“搜”起来
4.1 统一向量空间，还是分开索引？
这是多模态RAG设计里一个绕不开的问题。
方案A：所有模态用同一个多模态embedding模型，映射到同一向量空间。好处是图片可以直接搜文本，文本也能直接搜图片，实现“以文搜图、以图搜图”的无缝切换。坏处是单一模型对特定类型（比如图纸、表格）的适配不够。
方案B：文本、图片各用各的模型，分开建索引，检索时并行查。好处是每种模态都能用最合适的模型；坏处是跨模态检索时，文本和图片向量不在一个空间，没法直接比相似度，得额外做“模态对齐”或者“文本描述转图片查询”。
我实际采用的是“A为主，B为辅”的混合策略：
- 文本、效果图、实景照片统一走多模态embedding模型，进同一个向量库。
- 图纸切块图像和表格语义文本，单独走OCR+文本embedding，在文本库里建立索引。
- 检索时，两条索引并行查，各自召回Top-N，再做融合。
这么做的原因是装修场景里的查询通常带明显的“类别意图”：问工艺看工地照片，问风格看效果图，问价格看报价单。分开索引反而容易在各自领域里做到极致，最后融合排序即可。
4.2 检索链路：从“模糊query”到“精准命中”
一个好的检索链路，不能只是“用户输入一个句子，拿去向量搜索一把梭”。我给这套系统设计的是“意图理解—多路召回—去重融合—Rerank精排—扩上下文”的五段式流程。
意图理解：先用一个小模型或者规则判断用户输入的类型。比如用户发来的是一张图片，那就走“以图搜图”主链路；用户输入的是“你们做过玄关带洗手台的案例吗？”，就判断为跨模态查询，需要同时搜案例文本和效果图。
多路召回：除了向量检索，我还加了一个关键词检索通道（BM25）。原因很现实：向量模型对精确型号、长度、材料名这类“硬词”有时会抽风。比如用户搜“某品牌的生态板”，向量模型可能匹配到一堆“板材”相关的内容，但BM25能精确命中带这个品牌词的文本。两路结果混合后，用RFF（倒数排序融合）做合并，效果稳定很多。
Rerank精排：融合后的结果可能还有几十条，直接全塞进大模型上下文既不经济也容易分心。Rerank模型的作用就是把这些候选项按和当前问题的相关度重新打分，只保留最相关的5~8条。这一步非常值得投入，实测下来，在装修资料这种大量“相似但不同”的场合，Rerank能让回答准确率提升至少30%。
扩上下文：这里有个经验。只把命中的“图片/文本块”直接丢给大模型，有时候信息不够，因为图片理解的是局部，缺少全局上下文。所以我在把图片块送入大模型之前，会顺带把它所属的“父级文档”的摘要（比如项目名称、项目所属楼盘、整体风格、核心工艺方案）一起带入。这样大模型能结合全局背景来回答局部问题，答案的完整度会高很多。
4.3 查询带上“时间衰减”和“权限过滤”
装修公司还有个特殊性：知识的“时效性”。
五年前用的防水材料、老旧施工工艺，和现在的做法可能完全不同。如果知识库不区分时间，系统很容易把过时的工艺推荐给现在的项目，这是有实际施工风险的。
所以我在索引里给每条知识打了“入库时间”和“技术有效期”标记。检索时，除非用户明确问历史案例，否则默认按时间衰减函数降低过老资料的排序权重。最新入库的工艺标准和材料表，天然排在前面。
权限也得管。设计部、工程部、售后部、老板办公室能看的东西不一样。涉密合同、成本报价不能让全公司随便问，我在检索前加了一个“用户角色”过滤器，根据当前登录人所属部门，直接裁剪掉无权访问的知识条目。这是“企业级”的底线。
5. 问答能力的实现：让大模型学会“看图说话”
5.1 多模态大模型的接入方式
整个系统的问答环节使用了多模态大模型，主要处理两类任务：
- 纯文本问答：用户输入问题，系统检索出相关文档，拼接成提示词，大模型生成答案，并附上引用。
- 图文混合问答：用户上传一张现场照片，或者设计图，大模型需要“看到”图片内容，再结合检索到的历史案例和工艺文档来回答。
图文混合问答在工程实现上有个关键点：要把“检索到的证据图”和“用户上传的查询图”一起送入大模型的图像输入通道。也就是说，提示词里不只放文字上下文，还要把相关的历史案例图片、工艺照片作为图像上下文一起传给大模型。很多RAG系统只传文本，导致大模型根本没看到图片，回答自然不准确。
我封装了一个统一的函数，输入是“问题文本+查询图片+检索到的文本片段+检索到的图片路径列表”，输出是“答案+引用资料列表+相关图片推荐”。大模型底层支持多图输入，一次能处理多张图，方便做几张现场照片和历史案例图的对比分析。
5.2 提示词工程：装修行业的“项目制”写法
提示词不能写成通用的“你是一个AI助手”，得完全贴合这家公司的业务。我最终用的提示词模板大致是这样的：
你是一家装修公司的资深技术顾问，有超过15年的设计、施工、材料、售后经验。请根据以下检索到的内部资料回答用户问题。 回答要求：
- 优先引用知识库中提供的资料，不要凭记忆编造。
- 如果涉及施工工艺，请说明对应的工序名称和验收标准。
- 如果涉及材料，请给出品牌、型号、规格等关键信息。
- 如果知识库中没有相关内容，请直接说明“当前知识库没有找到相关案例”。
- 回答需区分“标准做法”和“特定项目的做法”，不要混用。
这个提示词能有效克制大模型“一本正经胡说八道”的毛病。装修行业特别容易踩坑的是“把以前项目的做法当成标准”，所以我在提示词里明确要求区分“标准”和“特定项目”的做法，答错了是要出施工事故的。
5.3 引用溯源：知识库的信任基础
老板和员工对AI不信任，最大的原因是怕AI“睁眼说瞎话”。为了解决信任问题，我强制要求所有回答最后一屏都带“参考资料”列表，列出引用了哪些项目、哪些文档、哪张图片。展示形式是一张卡片列表，点开就能看到原文出处。
这块技术上其实很简单，就是在RAG链路里把检索到的结果ID一直透传到前端，不丢就行。但很多项目会在“生成回答”这一步把来源信息丢掉，导致系统回答完连自己都不知道信息从哪来的，这种产品让人怎么信？所以引用溯源从一开始就是核心功能，不是可选项。
6. 前端展示与落地效果：让员工真的愿意用
6.1 一个“像聊天软件”的界面，而不是后台系统
这套系统最终给员工用的是网页端，交互起来很简单，就像微信聊天一样。左侧聊天窗口，右侧实时展示引用的资料卡片。用户可以上传图片提问，也能直接打字提问。
这个设计是有意为之。装修公司员工普遍不是技术人群，你让他们去“输入关键词、筛选条件、看列表页”，他们嫌麻烦；但让他们像发消息一样发个照片，说“这个裂缝是怎么回事”，他们很快就能上手。第一版上线时我特意去售后部看师傅们用，发现他们最常用的操作就是拍一张现场照片，发进去等结果。图像输入从一个“高级功能”变成了最普适的交互入口。
6.2 三类典型使用场景的效果
场景一：销售查历史案例
客户拿着一张户型图问“这种横厅能做吗”。销售上传户型图，系统匹配到几个类似户型的历史项目，给出项目实景效果图和设计说明。原来这个流程需要问设计师，现在直接一键完成，响应客户速度快很多。
场景二：设计师找工艺参考
设计师接到一个旧房改造项目，需要查公司有没有“木纹砖上墙”的工艺标准。系统同时检索文本工艺库和图片案例库，返回一份标准工艺文档加几张实际项目的完工照片，直接可参考。
场景三：售后分析问题
售后师傅上传一张墙皮起鼓的照片，系统检索到历史相似问题档案，显示“该现象可能原因：基层含水率过高或防水未干透”，并关联出当时处理此问题的施工方案记录和材料用量。这一步，直接帮售后人员节省了大量“翻旧账”的时间，减少了对老师傅经验的依赖。
7. 踩坑记录与实战避坑建议
7.1 最大坑之一：图纸OCR的识别率陷阱
最开始我直接拿一套通用OCR模型去识别CAD导出的PDF图纸，结果识别率惨不忍睹。原因在于图纸的字体是CAD里的SHX字体，和常规印刷体差异大；标注文字还可能被线条和图块压住。后来换了方案，先对图纸做“去线处理”（用图像形态学把底图线稿去掉，只留前景文字），识别率才提上来。这个细节特别值得提醒，做工程类知识库的一定要把“图纸预处理”当成专门的一步来做。
7.2 最大坑之二：小图的检索结果太碎，上下文断裂
切块策略虽然能提升定位精度，但也会带来“只见树木不见森林”的问题。用户问“这个项目整体是什么风格”，结果检索回来的是某张图的一个局部角落，大模型只能看到角落的花纹，回答自然偏。
后来我加了“父级文档聚合”机制：每个切块都记录所属父级文档ID，检索命中多个切块时，如果属于同一父文档，系统会自动把父文档的头部摘要、项目简介一并带上。这一招让回答完整性好了很多。如果你做类似系统，切块粒度一定要配合父级聚合策略，否则知识库用起来会“答非所问”。
7.3 最大坑之三：权限过滤做得太晚，回炉重造
第一版我没做权限控制，全量数据都进索引。结果测试阶段就出事：售后部的人员能搜到设计部的成本报价表，场面一度非常尴尬。后来重新设计元数据模型，加了部门权限字段，并把索引重建了一遍。这个教训告诉我，权限不是上线前“加上就行”，而是要在数据入库时就打好标签，不然后面洗数据的成本指数级上升。
7.4 实用避坑清单
如果你也想在自己行业里搭一套类似的多模态知识库，我把经验浓缩成这几条：
- 从小切口试点开始。别一上来就想覆盖所有资料，先挑一个高价值场景（比如售后问题图片匹配+历史案例）打通全链路，再慢慢铺开。
- 清洗数据比选模型更重要。脏数据进库，再好的模型也输出不了正确答案。我在这项目上约60%的时间花在数据接入与清洗，而模型调优只占15%。
- 元数据设计要前置。刚开始不觉得关键，后期发现问题时要返工，代价巨大。
- 检索结果必须可溯源。没有引用出处的知识库AI，员工用几天就会失去信任。
- 性能要给足余量。装修知识库的数据量不算大，但是图片切块和OCR很吃计算资源，GPU和CPU资源得留出提前量。
这个项目从立项到跑通第一版，前后花了大几十天。回过头看，多模态RAG真正的价值不在于技术多新鲜，而在于它第一次让装修公司那种“只能靠人传人”的经验，变成了公司可检索、可流动、可传承的资产。现在公司的老板和新来的设计师，都习惯先在系统里“查一查”，查不到再找人问。这个习惯的转变，比任何模型参数都重要。
