企业官网建设流程全解析

年初我们团队接到某装修公司的需求，想把公司沉淀了十几年的资料真正盘活。我一开始以为这不过是普通的内部知识库项目，进场之后才发现，这家公司的知识形态根本不是纯文本能覆盖的——设计图纸、效果图、材料实拍、工地验收照片占了大头，散落在个人电脑、微信文件和网盘里，翻起来全靠老师傅的记忆。这个场景恰好就是我这些年做得最多的多模态 RAG 知识库的典型样本。这篇文章我会把整套从 0 到 1 的落地过程拆开讲，包括数据怎么清洗组织、图文如何绑定入库、检索怎么做才不退化成玩具、上线后踩了哪些硬坑。不论你是在装修行业搞数字化转型，还是想在别的垂直行业做多模态知识库，这条链路都值得参考。

1. 装修公司的知识资产长什么样：痛点盘点与需求边界

1.1 装修公司资料的真实形态

很多人想象装修公司的知识库就是一摞施工规范和合同模板，实际盘点下来完全不是这么回事。我带着团队在这家公司待了两周，把各部门的资料摸了一遍，大概分了这几类：

• 文本类：施工合同、报价单、主材清单、验收标准、售后政策、客服问答记录。
• 图像类：各风格效果图（奶油风、原木风、轻奢等）、主材实拍图、工地各阶段验收照片、设计节点大样图。
• 结构化数据：材料库存表、供应商价格表、项目经理排期表。
• 隐性知识：老师傅脑里的经验，比如"这个小区墙面容易起砂，贴砖前必须刷界面剂"。

这些资料最大的问题是没有统一的元数据标准。设计部存效果图用的是"最终版"三个字，客服部下发的材料参数是微信聊天记录里转发的截图，工程部的验收照片按施工日期命名但没人维护说明。这意味着，即使你立刻把所有文件放进向量数据库，检索效果也一定很烂——没有标签和上下文关联的图像向量，在语义检索里约等于抓瞎。

1.2 为什么通用 RAG 在这里不够用

一开始有人提议，先找个现成的纯文本 RAG 框架把合同和规范跑起来，图片的事以后再说。我直接否决了这个方案，原因很现实：如果知识库只能聊文字，那它对公司最大的价值就废掉了。

装修行业的典型知识需求是"给我找一张 2022 年那个原木风小户型客厅的效果图，客户要暖色调的"，或者"上次那个灰色柔光砖用在卫生间到底行不行"。这种 query 一半靠语言描述，一半指向具体图像。纯文本 RAG 会把图片当作附件丢弃，设计师拿到的检索结果永远是一堆文档标题，还要自己打开看才知道是不是想要的东西。

传统的关键词搜索也解决不了，因为装修行业的用户query口语化极其严重。客服会直接问"地板怕不怕水"，而资料里的准确术语是"防水等级达到 X 级"；设计师会搜"极简风"而不是规范的"现代简约风格"。字面匹配在这种场景下命中率低得可怜，需要语义检索把"怕不怕水"和"防水等级"关联起来。

1.3 先圈定三个高价值落地场景

多模态知识库最忌讳一上来就贪大求全。我和这家公司业务负责人碰了三天，筛出三个 ROI 最高的落地场景，按优先级排好：

• 客服问答助手：客服每天要重复回答材料参数、施工周期、售后流程，高频且答案相对固定，最适合做首个 MVP。
• 设计师历史案例检索：按风格、户型、造价区间找历史效果图和对应材料清单，帮设计师快速给客户出参考图。
• 工地质检辅助：把验收标准和现场照片关联，工长或质检员拍一张照片就能对照规范判断是否达标。

我的建议是先做第一个场景跑通全流程，再逐步扩到另外两个。前期最怕的不是技术问题，而是业务方期待过高，觉得"AI 应该什么都知道"。把使用边界定清楚，后面推进会顺畅很多。

2. 数据侧的准备：多模态语料的清洗、关联与权限约束

2.1 语料分级：该入库的和不该入库的

数据不是越多越好，这一点在装修行业尤其明显。项目组花了两周盘点资料，第一周做的事其实是"减负"：

应该入库的：现行有效版本的施工规范、工艺标准、材料产品手册、经过设计总监确认的历史案例、客服标准话术与售后政策。这些资料有明确时效和权威来源，是知识库的"正样本"。

不应该入库的：报价底价策略、客户联系方式、带完整小区名称地址的合同扫描件、已经失效的旧版材料目录、内部吐槽群聊天记录。这些内容要么涉敏感信息，要么会对回答准确度产生致命干扰。

我特别强调一点：过期的旧版规范一定要物理删除，不能抱着"留着也许有用"的心态入库。装修行业的材料迭代很快，两年前一款地板已经停产，如果旧规格和新规格一起进库，检索排名稍有波动就会给出错误的推荐。我们当时清理出了大约 30% 的无效语料，这些垃圾数据如果留着，后期维护成本会高到想哭。

2.2 图与文的绑定：多模态检索的地基

弄完删减之后，真正的难点来了：怎么让图像变得"可检索"。

我先把所有历史项目的效果图、工地照片和设计说明文件做了关联。一张效果图至少需要绑定六个维度的元数据：

这里有个反直觉的经验：多模态知识库的检索质量，七分靠元数据组织，三分靠模型能力。如果你只把图片扔给模型生成一段描述然后算向量，效果远不如"规范的人工标签 + 模型描述兜底"。当然，几千张图靠人工打标签不现实，我们的做法是先用视觉语言模型批量生成候选描述，再由设计助理快速复核修正。实测下来，人工复核成本大概是每张图 20 秒，完全可以接受。

2.3 脱敏与权限：别把报价和合同喂给全公司

这个环节看起来最不性感，但恰恰决定系统能不能安全上线。

公司内部对上这个系统最紧张的是财务和销售总监，怕的是设计师或客服通过知识库反问出底价信息。我们的处理分两层：

第一层是字段级脱敏。所有入库文本先跑一遍规则，把客户姓名、电话、具体小区名替换成占位符；报价单中的"成本价""渠道折扣"列直接剔除，只保留对外报价口径。

第二层是语料级权限隔离。每份文档入库时打上角色标签，比如 "role:customer_service"、"role:designer"、"role:project_manager"。客服问答机器人检索时只能看到客服权限范围内的语料，即使技术上能够到签合同的文档，权限过滤也会在检索阶段提前拦截。

这一步意味着整个检索架构里必须内置一层权限过滤器，而且要在最早的数据建模阶段就定义好角色矩阵，千万别等到上线前再补。我们当时就吃过这个亏，后面章节我会单独讲权限对成本和架构的影响。

3. 入库管线：从图纸、照片与表格到可检索的知识块

3.1 文本块的解析与切分

数据准备好之后，就开始写入库管线。第一类处理对象是文本，看似简单，实际坑不少。

装修公司的文本资料有几个非常不友好的特点：大量扫描件 PDF、Excel 格式的报价表、格式千奇百怪的 Word 工艺标准。我们按类型拆了三套解析流程：

• 扫描 PDF：先走 OCR，但不要整篇塞进 embedding。扫描件识别完还必须做版面分析，把标题、正文、表格区域分开，否则"验收标准"四个字会和后面的条款混成一大坨。
• Excel 材料表：按行拆分，每一行作为独立 chunk，并保留表头信息。比如某板材一行包含品名、规格、环保等级、适用场景，检索"E0 级实木多层板"时直接命中该行。
• Word 工艺规范：按章节和条款切块。这里我踩过一个教训：一开始用固定 length 简单切分，结果把"墙面防潮处理的施工步骤"切断成了两半，语义严重损失。后来改成按标题层级优先切分，再对超长段落做二次切分。

文本切分参数我给出一个相对通用的参考值：中文场景 chunk_size 设在 500 到 800 字符之间，重叠 100 到 150 字符。这个范围在语义完整性和检索精度之间比较平衡。太小了语义碎片化，太大了 vector 表征会被稀释。

3.2 图像的理解与转译

接下来是全文的核心：图像这块怎么入库。我对比过两条技术路线，在这家公司分别做了小规模验证。

路线 A：图像向量直接入库。用通用的视觉向量模型把整张效果图编码成一个向量，查询时把用户文本做向量化，两个向量直接算相似度。优点是链路简单、检索速度快，缺点是抽象风格类的 query 命中很差。比如用户问"温馨一点的暖色系客厅"，模型会把"温馨"和"暖色系"这种抽象概念和图片像素级特征分开处理，直接比对容易跑偏。

路线 B：先生成图像语义描述，再做文本向量入库。先用视觉语言模型把每张效果图"翻译"成一段结构化描述，比如"客厅，奶油风，米白色墙面，浅色木地板，无主灯设计，三人位布艺沙发"，然后把这整段描述和设计说明拼接，过 embedding 模型得到向量。检索阶段先匹配描述文本，再把命中的原图展示出来。

实测结果非常明显，装修场景必须走路线 B。因为业务 query 几乎全是"原木风客厅""卫生间干湿分离效果"这类抽象概念，先转译成语言再检索，语义匹配的准确率至少提升了 20 个百分点。路线 A 也不是完全没用，在"以图搜图"场景——比如拿着工地现场照片找历史相似施工图——它有天然优势。我们最终是 B 为主、A 为辅，两条索引同时维护。

3.3 向量化与索引存储

图像和文本都变成 chunk 之后，统一进入向量化环节。

embedding 模型我们没有做领域微调，直接用了主流的通用中文向量模型。有人可能会问，装修行业这么多专业术语，不微调能行吗？我的看法是，RAG 场景下特异性主要靠检索和 rerank 环节解决，embedding 模型只要具备基本的中文语义理解能力就够用了。专业词表可以在查询改写阶段做，性价比远高于训练一个领域 embedding 模型。

索引存储方面，向量索引我建议跟关键词倒排索引放在同一个引擎里，而不是拆成两套系统。装修知识库的 query 天然混合了语义检索和字面检索需求，比如查"板材标准 GB/T 23xxx"必须靠关键词精确匹配，查"哪种地板小孩用安全"则靠语义。两个索引都跑一遍，再做分数融合，比单一向量检索靠谱得多。

向量索引参数我用的是一组比较稳妥的配置：HNSW 图结构，m 值设 16，ef_construction 设 200，检索时 ef_search 设 64。这几项直接控制召回速度和精度平衡，如果你们的文档量在百万级以下，这套配置基本不用调。

4. 检索侧的实战：混合召回、查询改写与重排的必要性

4.1 混合检索：三层召回的组合拳

单靠向量检索撑不起企业级知识库，这是我在搭建过程中反复强调的一点。最终线上跑的检索逻辑分三层同时进行：

• 关键词层（BM25）：负责精准字面匹配。查规范编号、材料型号、"衣柜品牌A"这类专有名词，没它不行。
• 向量语义层：负责"意思相近但字面不同"的匹配。用户问"孩子小怕甲醛"，能召回"室内空气环保检测标准"这类文档。
• 元数据过滤层：这不是一个独立召回通道，而是叠加在以上两层之上的硬过滤。权限角色、文档时间范围、文档类型，全部以过滤器形式先执行，再做相似度计算。

三层召回拿到结果后需要融合排序。我做过几种融合策略的对比，最简单的加权求和（关键词得分 × 0.4 + 向量相似度 × 0.6）在装修语料上已经表现不错。更复杂的 rank fusion 方法提升有限，还要多维护一套计算逻辑，性价比不高。

4.2 查询改写：用装修行业词表对抗口语化提问

用户不会按照知识库里的规范术语提问，这是信息检索中最古老的问题。装修行业尤其严重。

客服后台的实测 query 长这样："阳台瓷砖用哑光的好还是亮光的好""家里有小娃娃铺什么地板""卫生间墙砖要不要做美缝"。这些句子送到向量检索里，虽然语义相似度模型能抓住一部分意图，但效果不稳定。我采用的方案是规则式查询改写 + 意图识别，不依赖 LLM 现场改写，理由有两个：稳定和便宜。

具体做法是构建一份装修行业同义词和上下位词表。比如：

• "小娃娃/小孩/儿童" → 追加关键词"儿童房、环保、甲醛等级"
• "哑光/亮光" → 保留原词，同时追加"柔光砖、釉面砖"扩展召回
• "美缝" → 追加"填缝剂、美缝剂、施工工艺"

这套词表是拿业务部门的真实询问记录一点点喂出来的。首版我让客服主管整理了 100 条高频问题，逐条分析后形成了约 400 组词条映射。效果立竿见影，检索的 Recall@5 直接提升了一截。

4.3 重排：让最相关的资料排在最前面

混合检索召回前 20 条之后，还不能直接丢给生成模型。我做过一次抽样检查，发现相关性最高的内容经常排在第 7 到第 12 位之间，只取前 5 名的话会漏掉正确答案。

解决这个问题需要在粗排之后加一层精排，也就是 rerank。粗排用双塔向量模型，速度快但精度天花板低；rerank 阶段改用交互式的排序模型，把 query 和候选文档拼成一个序列一起计算相关性，精度高，但算力开销也大，所以只对粗排的 top 20 做精排，再取 top 5 进入生成环节。

跑通这层后，线上真实问题的 Top1 命中率明显提高，业务方最直观的感受是"回答靠谱多了，不用翻半天也没找到想要的东西"。

4.4 用 30 个真实 query 做一轮检索评估

很多团队做 RAG 系统不建评测集，上线之后全靠感觉调参，这是大忌。我们当时从客服后台和设计师群收集了 30 个真实 query，组成一个固定评测集，每个 query 人工标注了正确答案的文档 ID。这个评测集成为后续所有改动的"红线测试"。

无改写无重排、有改写无重排、有改写加重排三档配置在评测集上的数据是这样的：

别小看这个评测集的价值。后来每次有人说"系统变笨了"，我们第一件事就是把 30 个 query 跑一遍，找到是哪一类问题退化了，再针对性调整。没有这个基准，优化就是无头苍蝇。

5. 回答生成与业务系统集成：让知识库真正被用起来

5.1 生成侧的约束与风格控制

检索做得再好，生成环节把答案写歪了，体验照样崩塌。我在设计系统提示词时定了三条硬规则：

第一，只能基于检索到的资料回答，找不到就不硬答，明确提示用户"资料库中未找到相关内容，建议咨询人工客服"。这是保住系统可信度的底线。

第二，答案必须带引用来源。装修行业的客服回答常常涉及责任边界，一句"这个做法符合规范"如果没有出处，客服是不敢直接转给客户的。生成格式上我们用 [1][2] 这样的编号对应到具体文档，点击能跳转原文。

第三，控制答案长度和语气。知识库面向的是业务人员和客户，不是论文读者。温度参数我直接调到 0.2，禁止模型自由发挥。回答结构要求"先说结论，再用不超过三点的依据支撑"，避免一段话写几百字。

这一层配置好之后，客服主管试用一周给出的反馈是"能用了"，从"能出结果"到"能直接用"之间，差的恰恰就是这些生成规范。

5.2 两个落地形态：客服助手与设计师资料库

项目上线后，知识库被集成到两个业务系统里，形成不同形态。

客服助手接入到公司的即时沟通工具，类似一个群内机器人。客服把客户问题转述给它，秒回答案加引用。跑了一段时间后的数据变化是：单条客服工单的平均处理时长降了 30%，翻历史聊天记录找材料参数的操作基本消失。更关键的是新入职客服的培训周期明显缩短，以前要跟老师傅学两个月才能独立接单，现在对着知识库能快速查证标准答案。

设计师资料库则是另一个交互形式。设计师输入需求描述，比如"原木风 小户型 客厅 预算10万以内"，系统返回以往项目的最匹配效果图、设计说明和材料清单。这个功能第一天就有设计师感叹"早知道有这个就不用翻三年朋友圈了"。

5.3 权限过滤要在检索之前做

权限这块我要单独拎出来讲，因为很多团队会把它做成上线后的补丁，导致整个检索架构变得别扭。

正确做法是：权限过滤必须在检索查询阶段就传入，而不是等生成结果出来再筛选。具体实现层面，每份语料入库时打上角色标签，用户在检索时携带自己的角色标识，所有召回查询都附带一个角色过滤条件。比如找客服角色能查的语料，就传到过滤器"role:customer_service"，密级更高的造价文档从源头就进不来。

这样做的原因除了安全，还有性能。如果在检索后过滤，意味着系统要为每个用户跑一遍全量召回再丢弃不该看的，浪费计算资源而且响应变慢。检索前过滤，相当于数据库里加了 WHERE 条件，扫描范围本身就缩小了。这个设计决策，越早定越好。

6. 上线后踩到的三个硬坑与后续的演进方向

6.1 坑一：模型"太能说"了

上线第一周，客服主管跑来找我，表情复杂地说："回答倒是挺全面，但是我发给客户人家不看啊，太长了。"这是个典型的生成风格问题，技术指标再高，业务接受度上不去也白搭。

解决方案不是改模型，而是改生成模板：要求模型先给出一个不超过 30 字的结论句，然后最多列三点依据，每条不超过 40 字。另外在前端做了折叠交互，默认只显示结论，想看依据再展开。这样改完一周后，客服群里的使用率明显上升。

我的体会是：RAG 系统上线后的调优，一半精力花在跟业务确认"什么叫好答案"上，这比调参重要得多。

6.2 坑二：多模态上下文里的数字幻觉

第二个坑出现在材料参数查询上。有次客服问一款地板的耐磨等级，系统回答引用了正确的等级描述，但把转数数值从"6000 转"答成了"600 转"。我排查出来，问题出在生成阶段模型把表格里的数字记错了。

数字幻觉在文本 RAG 里容易控制，但在多模态场景下更难防，因为表格和图片描述混在一起，prompt 里的 token 一多，模型对数值的保真度就下降。

我的处理方式很朴素：表格类数据一律不做自由文本生成，而是把原文以高亮块的形式原样返回。也就是说，当问题命中材料参数类文档时，生成模型只负责判断"哪一行相关"，而数值展示直接读数据库原始行内容。这样从机制上杜绝了改数字的可能性。涉及到价格、等级、型号这些敏感字段，宁可生硬一点，也要保证绝对的准确。

6.3 坑三：调用成本随权限粒度指数上涨

第三个坑有点隐蔽。我们做了角色权限隔离之后，为了效率给每个角色单独建了缓存。结果发现一个诡异现象：整体 API 调用费用不降反升。

一分析才明白，10 个角色意味着同一份公共语料会被 10 个角色各自召回和生成一次，缓存几乎全部失效。客服、设计、工程三个角色都要查同一个"施工规范"，以前一份缓存可以覆盖所有人，现在三个角色各算一遍，成本翻了三倍。

解法分两层：公共语料单独建一层共享缓存，角色私有语料才走各自的隔离缓存；同时把结果缓存粒度从"整个回答"细化到"检索结果片段"，因为不同角色问同一份规范时，命中片段大概率是相同的，生成部分再各算各的。这个改动之后，单次请求的平均成本回到合理水平，而且响应速度也更快了。

6.4 后续演进：从"找到资料"到"生成初稿"

系统跑稳之后，业务方自然会提出更多需求。目前已经在规划的两个方向：

一是多模态工地巡检。让工人用手机拍一张现场照片，系统比对入库的验收标准和历史项目影像，自动提示可能存在的工艺偏差。这个本质上是我们已经建好的"现场照片向量索引"的延伸，技术路线是现成的，难的是采集足够多的验收标准样本。

二是基于历史案例的方案初稿生成。设计师输入客户需求和预算，先根据多模态知识库找到 5 个高度相似的项目，然后自动生成包含风格描述、主材清单、施工要点的方案初稿。设计师再人工调整细节。这比单纯的资料检索价值大得多，相当于把 RAG 从"查"升级到"写"。

但我的建议是：在检索准确率还没达到业务方完全满意之前，不要急着做生成式初稿。生成之上的应用，地基都是检索质量。先把第一步做扎实，后面的扩展都会水到渠成。

最后说点个人体会。从 0 到 1 搭建一个企业级多模态 RAG 知识库，最难的部分往往是开始前两周的数据摸底和元数据设计，而不是模型选型或参数调优。装修公司这个案例让我更确认了：任何垂直领域的知识库，都要尊重行业语料的原始形态，花力气把图、文、表格之间的关系理清楚，系统才能真正从"demo 好看"走向"业务能用"。如果你也正准备做类似的系统，我的建议非常简单——先找一个最痛的单点场景，用真实数据把整条链路跑通，再谈规模化。