最近一段时间，我陪着某装修公司把散落在各个角落的资料库，从 Word、PDF、微信群聊天记录、CAD 图纸截图、供应商报价表这些乱七八糟的格式，搭成了一个真正能用的多模态 RAG 知识库。整个过程最深的感受是：技术选型不是最难的部分，最难的是搞清楚企业里的知识到底长什么样、藏在哪里、被谁在用。如果你正准备做企业级知识库，或者手头有一堆带图片、带表格、带图纸的数据不知道怎么喂给大模型，这篇内容值得认真看一眼。
这个项目的核心场景并不复杂：设计师要翻历史案例，工程部要查施工工艺规范，客服要回复业主各种材料品牌问题，老板偶尔还想问“去年我们到底做了多少套北欧风的小户型”。以前这些需求全部靠人肉翻聊天记录、翻硬盘文件夹解决，效率极低。所谓多模态 RAG 知识库，就是把文字、图片、表格、PDF、图纸这些不同模态的数据统一解析、向量化，放进检索增强生成的框架里，让大模型基于企业私有知识来回答问题。下面这套流程，是我在实际落地过程中一步步跑通的，坑和捷径都有。
1. 项目背景：装修公司为什么需要多模态 RAG 知识库
1.1 数据很多，但每个人都在重复造轮子
这家装修公司的数据情况，估计和很多中小企业差不多：不是没有数据，而是数据多到没人知道有什么。工程部内部有几百份施工工艺标准 PDF，每份都有大量现场照片和工艺细节说明；设计部有一堆过往项目的提案 PPT，里面混着户型图、效果图、装修清单；客服手里攒了几千条微信聊天记录，记录着业主问得最多的材料品牌、验收标准、售后政策；财务和采购那边还有 Excel 版本的供应商报价表。
这些资料看似都在公司内部，但实际使用的时候特别痛苦。新来的设计师想找一个“三室两厅轻奢风”的参考案例，得在共享硬盘里翻好久，或者去群里问一圈。客服遇到“乳胶漆和墙布哪个更环保”这种高频问题，每次都要找材料部门确认。工程部想查某个防水工艺的最新标准，发现电脑里存了三个不同版本的文档，不知道哪个才是最新的。
当时我们做了一次摸底，最夸张的一个情况是：同一个批次的瓷砖报价信息，分别存在于采购的 Excel、项目群里的图片、供应商发来的 PDF 三处，而且三处数据对不上。这种情况下，任何一个单纯的“文档搜索工具”都解决不了问题，因为数据格式不同、存放位置不同、甚至同一个实体在不同文档里的叫法都不同。多模态 RAG 的价值就在这里：先把所有格式统一成可检索的向量，再通过大模型把检索结果组织成回答。
1.2 为什么选 RAG，而不是微调大模型
这里有一个很实际的决策过程。项目启动时，团队内部有人提出直接拿这些资料去微调一个大模型，让模型“学会”这些知识。我们仔细评估过这个方案，最终还是否决了。
一方面，装修公司的知识是动态的。施工规范会更新，供应商报价会调整，设计师案例每天都在新增。如果靠微调，每次资料更新都要重新训练一轮，成本太高、周期太长，业务方根本等不起。另一方面，很多知识带有强时效性，比如某个材料当前的价格、某批次产品是否还有货，这些信息本身就不适合固化在模型参数里。RAG 的本质是“先检索再生成”，把知识库放在外部存储里，模型只负责根据检索结果组织答案。这样每次新增资料，只要做好解析入库，系统马上就能用上新知识，不必重新训练。
当然，多模态数据的处理给 RAG 带来了更大的挑战。文本类资料还好说，切一切、转成向量就行；但户型图、施工照片、Excel 表格这些数据，不能直接当作纯文本塞给大模型。如果展示图片信息的方式不对，检索阶段就会丢数据，后面的生成再聪明也白搭。所以整个项目的核心工作，其实集中在数据接入和检索链路这两个环节。
2. 数据接入与多模态解析：从杂乱资料到结构化知识
2.1 盘点数据源与确定解析优先级
搭建 RAG 知识库的第一步，不是写代码，而是做数据盘点。我们花了两周时间，把各个部门手头的资料全部摸底了一遍，列了一个数据源清单，包括资料类型、存放形式、更新频率、使用频率、敏感程度。
这个步骤很关键，因为不同的数据源直接决定了后面对应的解析策略。按我们当时的梳理，主要分成四类：
| 数据类别 | 典型形式 | 主要使用场景 | 解析难点 |
|---|---|---|---|
| 文本规范类 | 施工工艺标准 PDF、Word 文档 | 工程部查工艺、检验标准 | 版式不同、旧版本混杂 |
| 表格数据类 | 报价表、材料清单 Excel | 采购/客服查价格、品牌 | 多表头、单元格合并 |
| 图像图纸类 | 户型图、效果图、施工照片 | 设计师找案例参考 | 图像信息无法直接用文本检索 |
| 非结构化资料 | 微信群聊天记录、项目记录 | 客服回答高频问题 | 噪音大、口语化、上下文缺失 |
我们按使用频率和业务影响排序，先处理施工工艺标准和设计案例库，因为这部分是最高频的查询对象，也是公司最希望沉淀的知识。聊天记录类数据放到了第二阶段，原因是数据清洗成本高、噪音大，而且涉密风险更高。
2.2 PDF、Word、Excel 表格的解析细节
PDF 是这里面最让人头疼的格式，没有之一。装修公司的 PDF 有两类：一类是文字版的施工工艺文件，排版规整，可以直接提取；另一类是扫描版的供应商图册，每一页都是图片，必须走 OCR。我们内部跑完一轮后，发现纯靠通用 OCR 引擎的效果并不理想，尤其是表格部分，识别出来的结构完全乱掉。
后来我们把解析管线拆成了三步：第一层做版面分析——先区分页面里的标题、正文、表格、图片区域；第二层对文字区域直接做文本提取，对图片区域单独跑 OCR；第三层做表格结构重建，把识别出的单元格位置还原成行列结构。这一步做完之后，再把提取出来的文本按阅读顺序重新组织成一个带结构标记的 Markdown 格式文档，方便后续切分。
针对 Excel 表格，我们一开始直接读取单元格内容然后拼接文本，结果发现效果很差。比如一份报价单里，某一列的“单价”前面有三层合并表头，直接拼接后模型根本不知道这个数字对应的到底是什么材料。我们后来改成结构化解析：提取每个单元格的值、所属行表头、列表头、合并单元格范围，把这些关系组装成一句完整的自然语言描述，比如“品牌 X 的 800x800 全抛釉地砖，工程价每平方米 79 元”。这样喂给模型时，上下文是明确且自足的。记住一个原则：宁可让解析结果啰嗦一点，也不要丢失表格里的对应关系。
2.3 图片与图纸类数据怎么处理
装修公司最核心的多模态数据，其实是设计图。效果图、户型图、施工图，这些图片如果只是简单地存进去，检索系统根本无法理解图中的布局和风格。我们当时做了一次测试：把一堆效果图直接交给一个纯文本检索库，用户输入“北欧风客厅效果图”，返回结果全部是空——因为图片本身没有对应的文本描述。
解决这个问题的常规做法是引入图片理解模型，先用视觉能力把图片内容翻译成一段结构化描述，再把描述文本和图片一起入库。比如一张客厅效果图，会先生成一段描述：“现代简约风格客厅，浅灰色布艺沙发，原木色地板，白色电视背景墙，绿植点缀，空间通透明亮。”这段描述既用于向量检索，也用于后续多模态召回时的文本匹配。同时，图片本身也可以单独跑一路视觉向量，作为另一路召回的入口。
户型图比效果图更难。户型图里有很多线条、标注和房间名称，视觉模型如果没经过专门训练，很容易把“卧室”识别成“客厅”。我们当时采用的办法是叠加解析：先对户型图做一次专门的图纸结构识别，提取房间区域、面积标注和功能标签；再把提取结果转成一段文字版布局描述，比如“该户型为三室两厅一卫，客厅朝南带阳台，主卧约 15 平方米……”这样用户搜索“三室两厅 朝南”的时候，检索系统才能通过文字描述匹配到图。没有这一步，户型图对 RAG 来说就是一堆模型看不懂的线条。
这里还有一个细节值得单独拿出来说：无论图片描述生成得再好，入库后也要保留原始图片的存储路径和链接。因为最后用户在问答场景里，不只是要一句文字结果，他还想看到原图。我们当时在知识库里为每个图文资料保存了“原始文件路径、解析文本、向量 ID”三条信息，方便生成答案时把原图一起带上。
3. 向量化与检索链路：让大模型能“找对资料”
3.1 文本 Embedding 模型的选型与验证
很多搞 RAG 的人容易犯一个错误：一上来就选一个现成的开源 Embedding 模型，跑完就觉得万事大吉。实际上 Embedding 模型的选型对最终效果的影响，可能比大模型本身还大。装修公司这个场景里有大量行业术语，比如“全抛釉”“多乐士”“生态板”“防潮石膏板”，通用模型对这类词汇的理解往往不到位。
我们当时用了一个比较笨但有效的筛选方法：从业务方那里收集了 20 组真实问答对，每组包含一个问题、一段标准答案、以及一段故意放在仓库里的干扰文档。然后分别用几个候选的 Embedding 模型给问题和文档打向量，计算 top 5 命中率。测下来发现，有些中文优化较好的通用模型在普通文本上表现不错，但在处理工程术语时会出现同义词匹配不上的情况；反而是我们自己做了一遍简单的词典增强之后，把常见材料别名、规格写法做了归一化，效果提升非常明显。
Embedding 维度和切块大小的配合也值得说一下。我们最终采用的方案是把文档按段落切分，单块文本控制在 400 到 500 个字符左右，重叠 50 个字符。一开始我们切得太大，1000 字一块，结果检索出来的块里经常包含大量无关内容，Rerank 之后也没有明显改善；切得太小又会导致检索结果碎片化，上下文不完整。经过多轮测试，400 到 500 字这个区间，对于装修行业的说明类文本来说是一个比较合适的平衡点，既保留了足够的上下文，又能精准定位到相关细节。
3.2 多模态向量的统一检索
纯文本的资料还好处理，多模态图片才是这次项目的重点。我们把多模态数据拆成了两路向量：一路是图片理解模型生成的文本描述向量，另一路是图片本身的视觉特征向量。
文本描述向量的好处是它和用户问题的文本空间是一致的，可以直接做相关性匹配。用户问“轻奢风卧室”，系统能通过描述文本中的“轻奢风”“卧室”直接检索到对应图片。视觉特征向量的好处是它保留了图片本身的内容信息，即使文本描述没有覆盖到某个细节，视觉相似度也能兜底。
当时的实现是在同一套向量数据库里建了两个集合，或者用一个集合加一个字段区分模态。用户发起检索时，系统会并行执行两路召回：一路基于描述文本向量，一路基于视觉特征向量。两路结果合并后，再做一次重排。这个方案跑下来，效果比只依赖一路向量好不少，尤其是用户输入比较模糊、描述文本匹配不到的情况下，视觉向量经常能给出意外惊喜的召回结果。
多模态向量检索这里还有一个容易被忽视的坑：图片描述文本的质量直接决定了召回率。如果你使用的图片理解模型能力一般，生成的描述全部是“这是一张室内设计效果图，画面中有沙发、茶几、电视”，那这路文本召回基本就是废的。我们最终对图片理解模型的输出做了两遍人工抽检，发现描述里缺乏风格、色调、材料信息时，会手动补充一批关键词，再重新灌库。后续我们还设计了一个小工具，定期对新入库的图片做一次空泛描述检测，自动提醒运营人员补写描述。
3.3 混合检索与重排的工程实践
只靠向量检索的 RAG 一定会有漏召回的问题，尤其在知识库里存在大量同义、近义表达时。比如用户问“墙面起皮怎么办”，施工标准文档里写的是“基层处理不当导致涂层剥落”，这两个句子在字面上差异很大，但语义相近。单靠向量检索也有可能召回，但通常不够稳定。我们最终采用混合检索方案：向量检索负责抓住语义上的相似内容，关键词检索负责保证命中确切的术语和编号。
关键词检索这里我们用的不是简单分词匹配，而是先对知识库文本做了字段富化，把每份文档的标题、编号、材料名称、规格型号提取出来单独建索引。这样用户搜索“C30 混凝土”或“工艺编号 3.2.1”时，关键词索引能直接精准命中。两路召回结果合并后，进入重排环节。
重排这一步是当时被我们所有人低估的。最初没有加 Rerank 模型时，检索结果经常出现“相关但与问题不完全匹配”的情况，比如用户问“瓷砖空鼓怎么处理”，检索返回的文档里有大量关于瓷砖铺贴的内容，但没有直接回答空鼓。加入重排模型之后，系统会基于问题和候选文档做更细致的相关性打分，再把得分最高的几条作为大模型的上下文。实测下来，加入重排环节后，最终答案的准确率至少提升了一截，效果非常明显。重排的候选数量我们取的是 20 条，也就是说向量检索和关键词检索各取 top 10，合并后送入重排模型，最后只留下 top 3 作为大模型上下文。
4. 上线效果评估、权限控制与常见问题排查
4.1 用测试集量化“回答得好不好”
评估一个 RAG 系统是不是真的能用，绝对不能只看几个演示样例。我们当时从客服、设计、工程三个部门收集了 200 条真实历史问答，涵盖了高频问题、长尾问题和多轮问题三大类，做成了一份标准评估集。之后每次调整检索策略或更换模型，都要用这套评估集重新跑一遍流程，记录几个核心指标：答案相关率、忠实度、召回率。
这里特别推荐用“忠实度”这个指标做日常观测。忠实度检查的是生成答案的内容是否严格基于检索到的上下文，防止大模型自己编造。装修行业里，工艺参数、材料价格绝对不能凭空捏造，宁可告诉用户“资料库中没有找到相关信息”，也不能编一个数字出来。我们当时在系统提示词里强制加了一条规则：当检索到的上下文不足以回答问题时，必须明确回复“资料库暂无相关信息”，并附上若干相关文档标题。这条规则上线后，客服那边的投诉压力明显小了很多。
每次评估跑完，我们会把回答质量差的案例拎出来做分类统计。最常见的失败原因不是大模型能力不够，而是检索阶段压根没拿到对的资料。遇到这种情况，我会去翻一下该问题对应的检索结果，看看是切块粒度问题、Embedding 模型问题还是数据源里面压根没有相关内容。只有区分清楚原因，才能对症调整，不然就是个无头苍蝇。
4.2 权限控制与数据安全
知识库上线后，权限问题马上浮现出来。公司内部有些资料是不能让所有人都看到的，比如供应商底价表、某些项目的毛利分析、未公开的工艺文件。如果把所有数据全部灌进知识库，任何员工一问就能问出核心商业数据，这是很大的风险。
我们的做法是把权限控制前置到数据入库环节。每个数据源在入库时都会打上一个权限标签，比如“全员可见”“工程部可见”“管理层可见”。检索和生成阶段，系统拿到当前用户的身份后，先在检索前就对知识库集合做过滤，只召回该用户有权访问的内容。这套方案虽然增加了维护成本，但必须做。如果你现在准备做企业级知识库，一定要把权限模型放进第一期，不要想着后补，后补会让你改到怀疑人生。
另外一个细节是输出内容的审计。我们在系统里记录了每一次问答的完整链路，包括用户问题、检索到的文档 ID、最终的生成结果。这样万一出了问题可以追溯。上线一周后我们就靠这个审计日志发现了一起客服人员问出了项目毛利率的越权事件，及时修正了权限配置。
4.3 三个典型线上问题的排查实录
第一个问题是“检索不到上下文”。用户问了一个问题，系统直接回复“资料库暂无相关信息”，但业务方坚持说资料库里一定有。排查后发现，问题出在数据更新环节——前几天新发的一款板材工艺文件，只更新了共享硬盘，没有同步到知识库数据源。知识库管理员每天手动同步，漏掉了这个新增文件。后来我们加了一个自动扫描任务，定时检查指定文件夹里的新增文件，同步完成后推送通知，再也没出现过新文档漏入库的情况。
第二个问题是表格数据张冠李戴。用户问“某品牌乳胶漆多少钱一桶”，系统给出了另一个品牌的价格。追查链路发现，这份材料的 Excel 表格里有多行数据，切分时把多行合并到了一个文本块里，而重排模型没抓准用户问题中的品牌关键词。我们把表格解析结果改成“一行一个数据条目，每一条目自带品牌名和规格”，并对品牌名做了强索引，问题随即解决。
第三个问题是回答太模糊。用户问“卫生间防水施工的步骤”，系统回答里只有一句“防水施工需按规范操作”，没有给具体步骤。这说明检索结果没有命中真正讲步骤的那一段。优化方案是，在知识库建索引时，给带有明显步骤性质的文本（包含“第一步”“第二步”“首先”“然后”的词块）打上结构标签，检索时优先匹配。重新灌库后，这类问题回答质量明显提高。
5. 踩坑总结与可以复用的经验
5.1 最容易低估的两个环节
按我这次的亲身体验，一个企业级多模态 RAG 项目里，最容易被低估的环节有两个：一个是数据治理，另一个是评估集建设。数据治理听起来不像技术活，但实际消耗的时间占了整个项目的一半以上。各种格式、各种版本的文档要清洗、要归一化、要打标签，没做过的人很难想象工作量。我们的经验是不要指望一次性把所有数据全部清洗完，而是按业务优先级划分成几个批次，每批数据上线后立即使用、收集反馈，下一批再优化处理策略。
评估集建设也一样。没有一套固定、可重复的评估集，你根本不知道系统是变好了还是变更差了。我们后来把评估集建设做成了持续机制：业务方每周都会遇到新的问题类型，我们会把这些问题沉淀到之前的 200 条基础评估集中，逐渐扩充到 500 多条。任何一次模型版本更新、检索策略调整，都同步跑一遍评估流程，用数字说话，不做感觉主义。
5.2 给后续项目的几条实操建议
如果现在让我重新搭一次这个知识库，我会把这几件事放到最前面做：第一，先找业务方拿到 50 个真实高频问题，甚至一条条去翻客服聊天记录，搞清楚用户到底会怎么问。第二，在设计切割策略前，先人工阅读 30 份典型文档，感受文档的真实结构，很多文档的排版方式会直接影响切块方案。第三，从第一天就做好权限标签建模，哪怕前期的数据源只有两三个。第四，一定要给用户留反馈入口，让他可以对回答结果点“满意”或“不满意”，这些反馈数据是后续优化最宝贵的输入。
还有一个省钱的小技巧：不用一上来就采购商业版的知识库产品。先用开源工具链把手动流程跑通，验证数据和业务场景匹配度，确认效果达到预期后再考虑换更重、更贵的方案。我们当时就是先用轻量级的开源组件在内部跑通了整个 Demo，再用跑通后的方案去采购资源，整体成本控制得很理想。
这个项目做完之后，我最大的体会是：企业级多模态 RAG 不是一个“模型打天下”的事情，而是一个系统工程。数据质量、解析策略、检索链路、重排方案、权限管理、评估方式，每一个环节都影响最终体验。踩过几次坑之后，我现在对任何 RAG 项目的第一个问题都变成了同一个：“数据是什么形态的？谁来维护？多久更新一次？”这三个问题问清楚了，项目至少能少走一半弯路。
