企业官网建设流程全解析

装修公司做多模态 RAG 知识库？听起来确实不像互联网大厂那样"根正苗红"，毕竟这个行业在过去几十年里，靠的是老师傅的经验、厚厚的图纸和微信里来回传的现场照片。但正是因为传统，痛点才足够尖锐。

先说一个最直观的场景：一家中型装修公司，手上同时跑着二十几个工地，每个工地的图纸、合同、报价单、主材清单、客户沟通记录分散在设计部、工程部、销售部三个系统里。客户在群里问一句"我家厨房瓷砖当时选的是哪款？"，客服需要翻三个系统、问两个人，折腾半小时才能答上来。这种"知识明明存在却拿不出来"的憋屈感，做企业级知识库的人应该都懂。

这个项目用一句话概括：给装修公司建了一个能"看图、读表、翻合同"的企业级多模态 RAG 知识库，把散落在图纸、报价单、现场照片、验收报告里的碎片化知识，变成可检索、可问答、可追溯的结构化资产。整个过程从数据盘点、多模态解析、混合检索到业务系统集成全部走了一遍，这里把完整的落地过程、踩过的坑和最终的架构选择分享出来，给同样想做企业级知识库、尤其是非互联网行业的同学做个参考。

1. 项目的第一阶段：先盘清"家底"，再谈AI落地

任何知识库项目，如果跳过数据盘点直接上模型，后面一定会被脏数据反噬。这个项目最花时间的不是写代码，而是把装修公司散落的"知识资产"理清楚。

1.1 装修公司的知识到底长什么样

传统认知里，知识库嘛，不就是文档吗？但真把装修公司的资料翻一遍，你会发现这个行业的知识是天然多模态的：

• 施工图纸（DWG/PDF/JPG）：平面布置图、水电改造图、吊顶尺寸图，既有矢量信息又有很多是扫描件
• 报价单和合同（Excel/Word/PDF）：主材品牌、型号、单价、工艺说明，大量以表格形式存在
• 现场照片（JPG/PNG）：水电验收照片、泥木工阶段照片、成品安装照，很多手机拍的，带时间水印
• 主材样品图（JPG）：瓷砖、地板、乳胶漆的色卡和样品照片，色差信息非常关键
• 客户沟通记录（微信导出/客服系统）：散落在对话里的需求变更、选型偏好
• 竣工验收报告（PDF）：有签字、有盖章、有整改记录

这些资料有一个共同特点：大部分是"非结构化"甚至"半结构化"的，而且表格、图片、文字混在一起，传统的关键词检索根本处理不了。这也就是为什么要上多模态 RAG——单纯用文本检索，连图纸里的空间尺寸、报价单里的型号都翻不出来。

1.2 数据基线测量：先量化，再定目标

动了多少数据、覆盖多少工地，决定了系统边界。我们当时对全公司做了一次摸底，拿到的数字是这样的：

这个摸底结果直接影响了两件事：

1. 确定"最小可行知识库"的范围：不要一上来贪全，先覆盖"客户服务+工程巡检"两个最痛的高频场景。
2. 明确权限粒度：报价和合同涉及金额，不能所有员工都能查到。所以权限隔离从第一天就要设计进架构，而不是后期打补丁。

这个阶段有一个很重要的认知：企业级知识库的价值，不在于它能回答多少"百科式问题"，而在于它能多快、多准地把"这家公司自己的业务知识"调出来。装修公司的知识库，回答"什么是干湿分离"没有意义，回答"XX小区XX户型的水电点位有什么特殊要求"才有价值。

2. 多模态数据管线的搭建：从图纸、照片到可检索的向量

数据盘清之后，进入最核心也最脏最累的阶段：把不同类型的多模态数据，变成 RAG 系统能用的格式。这个阶段没有捷径，每一步都要根据实际格式做定制化处理。

2.1 能过 OCR 的过 OCR，不能过的做视觉描述

装修公司数据里，PDF 扫描件和手机拍摄的图纸照片占比非常高。很多历史合同、带红章的验收单根本没有电子版，只有扫描件。这对多模态解析提出了很高要求。

我们的处理策略分三层：

1. 纯文本/Word 类：直接提取文本，走常规切分。
2. 扫描 PDF 和图纸图片：先用 OCR（光学字符识别）把文字层提出来，再用专门的版面分析还原标题、段落、表格结构。
3. 纯图片类（主材色卡、现场照片）：OCR 没用，直接交给视觉语言模型生成结构化描述。比如一张卫生间瓷砖铺贴的照片，会生成"灰色哑光瓷砖，工字铺法，墙地通缝，阴角收口处打胶处理"这样的文本描述，再进向量库。

这里有一个很实用的细节：图纸里的文字识别出来之后，不能直接扔掉原图。我们最终的存储结构是"原始图片 + OCR/描述文本 + 关联的项目ID+空间ID"三件套。文本用于检索，图片用于回答时展示原图给用户看，项目ID和空间ID用于过滤。这样既能搜到，又能溯源，还能避免跨项目串信息。

2.2 切分策略：装修文档不能按固定 chunk 切

做过 RAG 的人都知道，文档切分（chunking）是召回质量的分水岭。但装修行业的文档有极强的领域特性，按通用做法每 500 个 token 硬切，会切出大量无意义碎片。

我们在工程实践中最终采用了**"语义边界的自适应切分 + 表格保护"**策略：

• 合同、报价单：按"条款编号 + 表格行"作为边界，表格块整体保留，绝不把一个表格劈成两半。 因为报价单里"主材名称-品牌-型号-单价-损耗率"这五列信息一旦被切散，检索时必然丢字段。
• 图纸说明文字：按"空间区域 + 工艺项"切分。比如"厨房防水工程""卫生间排水改造"各成一块。
• 现场照片：每张照片的文本描述独立成块，但必须挂上拍摄日期、施工阶段、空间位置这三个标签。

技术选型上，embedding 模型用的是支持中文的通用向量模型，切分阈值和重叠 token 做了多轮调优。调优方法不复杂：拿 20 个真实业务问题做测试集，分别用 3 种切分策略跑召回，比较 Top-K 命中率。最终选定的参数是chunk_size=512，overlap=80，但要根据文档类型做覆盖式调整。

这个环节最深的体会是：多模态 RAG 的"多模态"不只是说输入有图片有文字，更关键的是你要把不同模态的数据对齐到同一套知识单元里。比如一张现场照片，知识单元不是"图片"，而是"某工地某阶段某空间的施工状态描述+对应图纸要求"。数据管线的本质，就是在做这种对齐。

2.3 敏感信息处理：企业级系统的底线

装修数据里有客户姓名、地址、电话、合同金额，这些是企业级系统绝对碰不得的红线。我们在管线里加了两层保护：

第一层，入口脱敏。在文档解析阶段，用正则+模型双重方式识别手机号、身份证号、具体门牌号，替换成占位符再入库。第二层，查询侧权限过滤。检索时先判断提问员工所属部门和项目权限，向量检索的 filter 条件里直接注入允许访问的项目ID列表，从源头阻断越权查询。

这一步看起来不复杂，但直接决定了系统能不能真正上线。没有这两层，多模态 RAG 做的再好也只能是个 Demo。

3. 混合检索与重排序：让"找到"变成"找对"

向量检索解决了"语义相近但字面不同"的问题，比如用户问"厨房墙面用啥砖"，向量模型能匹配到"厨卫墙砖选型"的文档。但它也有天然短板：对精确数字、型号、ID 不敏感——你问"XX-1003 型号的砖还有货吗"，向量检索很可能把 "XX-103" 也拉进来。所以这里的关键决策是：不能只靠向量，必须上混合检索（Hybrid Search）。

3.1 为什么必须做混合检索而不是纯向量

这个项目的场景决定了检索必须"字面精确"和"语义理解"两手抓：

• 客户报出一个主材型号，要求的是精确匹配
• 客户说"我想看看我家客厅当时怎么设计的"，要求的是语义理解

如果只用 向量检索（Vector Search），型号精确性会翻车；只用倒排索引（Keyword Search），"客厅设计"这种口语化表达又匹配不上。

所以我们架了双层结构：

• 第一层（粗召回）：向量检索 + 关键词检索 并行执行，各自取 Top-20
• 第二层（精排）：用重排序模型对合并后的候选集重新打分，取 Top-5 作为上下文

在重排序模型的选择上，试了通用文本匹配模型和专门的 Rerank 模型，最后的结论是：数据量不大（几万块知识单元）的私有化场景，直接用通用 Rerank 模型就够用，没必要刻意追求超大模型。线上效果，Top-5 相关文档准确率比纯向量检索提升了约 15 个百分点。

3.2 查询改写：把口语变成检索语言

真实业务场景里，用户问问题的方式都很"口语化"且信息不完整。比如："上次说的那个砖，后来换的那个，多少钱来着？"——"上次"是哪次？"那个砖"是哪款？"换的那个"是什么？这种问题直接拿去检索，谁来了都召回不准。

我们在检索前加了一个轻量级的查询规范化步骤，用大模型做三件事：

1. 补全省略的信息（结合对话上下文）
2. 拆解复合意图（"看看瓷砖款式和报价" 拆成 "瓷砖款式" + "报价" 两个检索需求）
3. 提取关键实体（品牌名、型号、项目ID、施工空间）

改写后的查询分别喂给双路检索。这一步极大提高了长尾问题的命中率，特别是客服场景下那种夹杂着口语和术语的提问。

3.3 多路召回后的上下文压缩：别把大模型"喂撑"

装修文档有个特点：细节极多，一张报价单拿出来，中间夹杂着辅材明细、损耗说明、施工备注。如果把 Top-5 的完整块全部塞给大模型，token 消耗大，回答还容易跑偏——模型会被无关的辅材信息带偏，忽略了用户真正关心的主材价格。

所以我们在精排之后，又加了一步上下文裁剪：

• 设定每个知识块的最大输入长度（比如 800 token）
• 超过的部分，用摘要模型把核心信息压缩成一段话
• 表格类内容，只保留与查询实体相关的行

这步做完，生成质量明显提升，回答更聚焦，cost 也更低。这个"召回-精排-裁剪"三段式策略，我认为比单纯堆模型参数更有价值，尤其是预算有限的企业级项目。

4. 企微机器人集成与多模态回答的工程落地

知识库做得再好，如果入口不在员工每天打开的地方，就没人用。装修公司员工最常打开的应用是什么？不是 OA 系统，是企业微信。所以我们的前端交互载体，直接选定了企微机器人。

4.1 一套"问答即服务"的集成模式

集成方式不复杂，本质上是三步：

1. 企微群里 @机器人 提问
2. 企微回调接口把消息转发到后端的 RAG 服务
3. RAG 服务检索、重排、生成回答，把结果连同引用的图片/文档链接返回群聊

但有几个工程细节值得单独说：

异步长任务处理。多模态 RAG 的响应链路比纯文本 RAG 长，因为要检索图片描述、OCR 文本、表格结构，整体延迟通常在 3~8 秒。企微机器人有响应超时限制，所以我们把流程改成了"先回复'正在查，稍等'，再通过应用消息推送结果"。用户体验不打折，还显得更专业。

富文本回传。回答不只是文字，当知识库里命中的是现场照片或图纸时，机器人会直接回传图片 + 圆圈标注 + 一句话说明。这里又用了一个多模态能力：视觉模型对命中的图片做一次"是否匹配问题"的二分类验证，避免答非所问还把图发出去。

4.2 多模态能力的关键工程点：把图片变成"可追溯的知识"

装修场景里，回答必须带证据。客户问"我家水电改造的墙面开槽是否符合规范？"，如果只回一句"符合规范"，没有任何说服力。正确回答是："根据XX工地水电验收单和现场照片，墙面开槽横平竖直，线管间距符合公司工艺标准（槽宽≥3cm，间距≥2cm），下图是验收时的照片。"然后附上原图。

实现"可追溯回答"，靠的是数据管线阶段为每张图片保留的元数据：工地ID、施工阶段、拍摄日期、GPS 水印、关联规范条款。回答生成时，大模型必须输出引用的知识块 ID，系统再根据 ID 调出原图和原始文档。

这一步，才是"企业级"和"玩具级"最深的一道分水岭：没有溯源能力的 RAG，在正式业务环境里就是定时炸弹。

4.3 权限落在业务流里，而不是死在配置表里

装修公司的权限模型和互联网公司不太一样：工程部项目经理只能看自己负责的工地，设计部可以看所有进行中项目的图纸，财务才能看合同金额。如果知识库的权限只做成"管理员在后台配置"，一定跟不上业务变化——工地交底、项目经理换人、客户催单，都是常态。

我们的做法是，权限套餐直接由业务系统实时提供。用户提问时，后端先向业务系统查询该员工的"当前可访问项目ID列表"，把这个列表作为检索 filter 强制注入。知识库本身不维护权限，只执行权限。这样权限变更不需要重新同步，也避免了"离职员工还带着旧权限"的经典风险。

5. 评估、上线和持续运营：这套系统怎么才算"好用"

项目上线不是终点。业界都说 RAG 难评估，多模态 RAG 更难评估。但我们没有追求做一个完美的评估框架，而是先定了一个"能不能用"的及格线。

5.1 用"业务模拟题"代替泛泛的测试集

我们没有用那种"阅读理解式"的通用评测集，而是找项目相关的核心业务角色，分别出题：

• 客服出的是："这周末客户想确认主卧乳胶漆色号，该怎么查？"
• 工程部出的是："XX工地的防水验收照片是什么时候拍的？有没有整改记录？"
• 设计部出的是："帮我把XX户型的三套方案里，用到了某品牌深灰色瓷砖的找出来"

然后用 30 道题（其中 20 道多模态相关）组成回归测试集。每轮系统迭代，都拿这套题重新跑一遍，看命中率和回答完整度。这个"以业务角色为中心"的评估方法，比任何公开榜单都更能反映企业落地的真实效果。

这里也发现了一个很有意思的现象：多模态检索的失败，大多数时候不是模型能力不够，而是数据管线没做好。比如某张现场照片描述生成得太笼统（"一个房间的照片"），或者图纸 OCR 认错了户型编号。模型再强也救不回错误的数据。所以这个项目的优化重点始终放在管线侧，而非模型侧。

5.2 上线后最值得关注的三个运营指标

系统上线跑了两个月，我们重点盯三个指标：

运营期最大的教训是：企业级 RAG 的维护不是"训一次就完事"，而是持续的内容运营。装修公司每个月都有新工地、新材料、新工艺，知识库必须不断摄入新数据。我们后来固定了一个"每周增量更新"的任务，把上周新增的图纸、照片、变更单自动跑一遍管线。否则系统会像不擦的镜子，越用越模糊。

5.3 模型落地的取与舍

最后说几个模型层面的取舍，希望能帮大家少走弯路：

• 生成模型没上最大参数版本，而是用了一个中量级模型加精心构造的提示词。因为企业问答场景，稳定性、响应速度、成本比"偶尔惊艳"更重要。
• 视觉描述模型用的开源方案，精度足够，而且数据不出内网。装修图纸和现场照片牵涉客户隐私，数据合规的前提下，能本地化就本地化。
• Rerank 模型必须是独立的，不能省。没有 Rerank 的 RAG 在企业场景基本没法用，召回 20 条里面可能只有 2 条是准的，直接把 Top-5 喂给大模型会漏得离谱。

这套系统上线四个月，处理了几千次真实问答，其中"图纸查询 + 照片追溯 + 报价核对"这三类问题占了 80% 以上的调用。这也验证了最初的一个判断：装修公司最需要的不是一个会聊天的 AI，而是一个能看懂图纸、翻得出照片、传得动合同的"档案管理员"，只是这个管理员用了多模态 RAG 的方式来做。如果你也在做类似的企业级知识库项目，我最大的建议是：把精力多分一些给数据管线和权限体系，模型只是最后那 20% 的锦上添花。