企业官网建设流程全解析

去年接了一个挺有意思的项目，帮一家本地装修公司从 0 到 1 搭一套企业级多模态 RAG 知识库。坦白讲，刚听到"装修公司要做 RAG"这个需求的时候，我心里是打问号的——这行既不缺数据，也不缺场景，但真正缺的是一个能把散落资料串起来的系统。等我进了项目，翻了他们的共享盘和微信群聊天记录之后才意识到，这个需求比很多互联网公司都硬核：施工工艺手册、效果图、材料报价单、保修条款、客服积累的上万条问答记录，全堆在网盘和聊天记录里，想查一个具体参数基本靠人肉记忆。这篇文章会把整个落地过程从头到尾拆开，包括方案选型、数据清洗、图文对齐、检索调优、上线运维，以及我踩过的那些坑。如果你也在给传统行业做 AI 知识库，或者正准备升级自己的 RAG 方案，这篇应该能帮你省下不少时间。

1. 背景拆解：装修公司到底需要什么样的知识库

1.1 先摸清楚这家公司的资料家底

项目启动第一周，我干的最多的事情不是写代码，而是翻文件夹。这家公司本身规模不大，一个设计部、一个工程部、一个客服售后团队，但共享盘里的东西多得吓人。我大致盘了一下，最终纳入知识库范围的文件有这些：

• PDF 文档约 5400 份，其中大半是施工工艺标准、验收规范、设计案例册，不少是扫描件
• 图片约 3200 张，包括效果图、主材实拍、工地现场照片、户型图
• Excel 表格 1800 份，主要是报价单、材料清单、施工进度表
• 客服部门的问答记录 6400 多条，散落在几个文档和聊天导出文件里
• 还有一些 Word 版的公司制度、售后保修细则、合同模板

总量加起来大概 68GB，听着不大，但乱是真乱。同一份工艺手册存在三个版本，报价单有 2019 年的也有 2024 年的，图片命名是"微信图片_20230915_103255.jpg"这种风格。最要命的是，这些资料长得都不一样，有的是纯文本 PDF，有的扫描件糊成一团，有的表格有合并单元格，有的图片里全是水印。

这个阶段最大的收获是：我意识到知识库建设 80% 的功夫在数据整理，模型和框架反而是最省心的环节。如果你打算做类似项目，第一周别急着选型，先让客户把资料归档目录拉出来，人工看一眼再定方案，能避掉后面至少一半的返工。

1.2 为什么纯文本 RAG 搞不定装修知识

很多人在设计 RAG 方案时会下意识默认"知识 = 文字"，但装修行业打破了这个假设。我举几个真实场景你就明白了。

客服那边经常接到这样的问题："你们这个灰色哑光地砖配什么颜色的墙比较好看？"这个问题里，客户真正想看的其实是瓷砖实拍图、铺贴效果图，光靠文字描述"灰色哑光，600x1200"根本没法让客户满意。设计师查工艺时也会问："卫生间防水施工的验收标准是什么，闭水试验做多久？"这类信息在手册里通常配着现场施工照片，图上标注了关键点位，光抽文字出来会丢掉大量细节。

还有一类内容是表格。报价单里的信息密度特别高：品牌、型号、规格、单价、单位、工艺说明，全部塞在一张表里。普通文本切片方式会把一行行数据拆得七零八落，检索"某型号瓷砖的单价"时经常只能召回半个表格。

所以纯文本 RAG 在这个场景下基本是"瘸腿"的。知识库必须做到图、文、表三类内容都能被检索到，并且能一起返回给大模型作为上下文。这就是多模态 RAG 存在的意义——不只是把图片存进去，而是让用户的问题能同时命中文字、图片和表格，然后拼成一个完整的答案。

1.3 场景优先级：先把钱花在刀刃上

企业知识库最忌讳的是"什么都要做"。这家装修公司最开始列了十几个需求，包括给客户自动生成设计方案、自动算报价、自动审合同等等。我直接砍掉了一半，原因很简单：数据还没到位，做出来也是玩具。

最终我们按"数据成熟度 × 业务频次 × 可量化收益"三个维度排序，定了四个核心场景：

优先做第一个。理由也很直白：客服是知识库使用频率最高的角色，他们的问题大多是重复的，而且答案对不对很容易判断——回复错了一个产品参数，客户马上就能发现。在这个场景跑通整个链路之后，再横向复制到其他场景，成本会低很多。

2. 技术底座：从文档解析到生成回答的完整链路

2.1 文档解析链路：不同材质用不同工具

装修公司的文档来源五花八门，统一用一种解析方案必然翻车。我的做法是把文件按"出生方式"分成三类，用不同的链路去处理。

第一类是电子版 PDF 和 Word，这类文件本身有文字层，直接用文本抽取库提取即可，速度快、成本低。第二类是扫描件 PDF 和拍摄的照片，这类必须上 OCR 和版面分析。第三类是 Excel 报价单，这类不能当普通文本来抽，要用表格模型把结构还原出来。

OCR 这块我对比过好几个开源方案。先说结论：对扫描版工艺手册这种"排版固定、字体统一"的资料，开源 OCR 套件的效果足够用，而且胜在可以私有化部署。装修公司的资料里有大量客户信息、报价金额、合同条款，数据出域是底线问题，所以一开始就把商业 OCR API 排除掉了。

版面分析同样关键。很多扫描件是 A4 纸对折再扫描的，页面里有页眉、页脚、多栏文字、穿插图片，直接整页 OCR 会把无关内容混在一起。我们用的方案是"版面检测 + 区域分类 + 分别识别"：先把页面切成标题、正文、表格、图片几个区域，再对每个区域做对应处理。这一步做完，后面的切片质量才有保障。

我在解析阶段用的核心参数如下，可以参考：

• OCR 检测阈值调到 0.5 左右，避免漏掉较淡的印刷字
• 版面分类里把"页眉页脚"单独标记，后续切片时直接丢弃
• 表格区域单独走表格还原模型，输出成 Markdown 表格
• 图片区域单独裁剪出来，保存成独立图片文件，并记录它在原页面中的坐标

这里有个很容易犯的错误：把 PDF 的每一页当成一个整体去切片。千万别这么干，页面上常常混合了多种语义块，切出来的 chunk 大概率是"半页工艺说明 + 半页材料表"这种缝合怪，检索时永远命不中完整信息。

2.2 Embedding 选型：单模态向量加图片描述最省心

多模态 RAG 里有两条技术路线。一条是"真多模态"，用一个跨模态模型把图文映射到同一个向量空间，比如 CLIP、SigLIP 这类模型；另一条是"桥接式多模态"，先用一个多模态模型把图片翻译成描述文字（这叫 image caption），再把描述文字和普通文本一起做向量检索。

两条路线我都试了，最终采用的是第二条：单模态文本向量 + 图片描述桥接。原因有三个。

第一，可控性好。图片描述是显式的文本，我可以直接检查"这个描述到底准不准"，出错了改 caption 比重新训练模型快得多。第二，检索精度好。装修领域的专业词很多，比如"波打线""垭口""过门石"，通用图片描述模型不一定翻译得准，但我可以用规则或人工批量修正这些描述。第三，成本低。CLIP 这类模型对 GPU 显存要求高，检索时要同时把图文都过一遍模型，延迟和成本都上去了。

文本向量这块，我选的是中文效果比较稳的开源向量模型，输出维度 1024。图片描述用的是部署在内网的多模态模型，批量跑了一轮，给全部 3200 张图片生成了描述文本。描述模板大概是"这张图展示了[空间/物品]，特点包括[颜色/材质/风格]，可用于[场景]"。生成完之后我又做了一遍人工抽检，准确率大概 95%，剩下的 5% 通过改写描述来修正，没有重训任何模型。

2.3 检索框架：混合检索 + 重排是标配

真正把检索做好，靠的不是单个向量模型，而是"文本稀疏检索 + 向量稠密检索 + 重排"的组合。我给的配置是这样的：

• BM25 稀疏检索，负责精确匹配型号、品牌、专有名词这类关键词
• 稠密向量检索，负责语义匹配，比如"灰色砖配什么墙"这种问题
• 两者结果用 RRF（Ranked Reciprocal Fusion）融合，然后把 Top 20 交给重排模型
• 重排模型输出打分，最终取 Top 5 作为上下文送给大模型

为什么需要重排这一步？因为向量检索出来的 Top 20 里，通常有七八个是和问题语义沾边但不完全对的内容。重排模型会在更精细的粒度上重新打分，把最相关的内容顶上来。我实测过，加了重排之后，答案的引用命中率从 62% 提到了 81%，这提升非常可观。

向量库初期我直接用了 pgvector，没上独立的向量数据库。原因是数据量不算大，整个库切片之后大概十万个 chunk，pgvector 完全扛得住，而且能和业务表放一起，运维省心。真要到了百万级以上，再迁移到专门的向量库也不迟，这是典型的"按规模选工具"的思路。

3. 落地实操：从数据到好用要过的几道关卡

3.1 数据清洗：脏数据直接决定 RAG 的上限

技术上最无聊、但影响最大的一步是清洗。我见过不少团队兴致勃勃搭好 RAG，结果一测就翻车，最后发现是源头数据太脏——一个跟"主卧设计"相关的 chunk 里混着广告水印文字，一个报价单表格被 OCR 成乱码，一张图片被旋转了 90 度。

我们这轮清洗分文件层和图片层两层做。文件层做了三件事：去重、去档案、去超时。按文件哈希去重，把不同版本目录下的重复件清理掉；把和业务无关的行政文档、报销单、团建照片全部剔除；把最后一次编辑时间超过三年的旧版文档单独归档，不进知识库，避免旧参数、旧价格污染答案。

图片层的清洗更考验功夫。工地实拍图里大量是模糊、过曝、重复的废图，我跑了一个轻量的图像质量筛选流程：先算清晰度评分，低于阈值直接丢；再做感知哈希去重，连续拍了很多张的同场景照片只留一张清晰的；最后人工过了一遍疑似问题图，把有客户人脸、有报价白板翻拍的图全部移除。这块花了大概两天时间，但对最终体验的提升是最直接的。

清洗阶段我学到的教训是：别把清洗看成一次性任务，它应该是一套可复用的脚本和流程。因为知识库是活的，每个月都会有新的工艺照片、新的产品资料进来，只有把清洗流程固化成自动化流水线，后面才不需要每次靠人工手动来一遍。

3.2 切片策略：给装修资料量身定做切割方式

切片是 RAG 项目里"人人都会，但没人做得精细"的环节。装修公司的资料结构差异大，我用了一套分类型的切片策略。

工艺手册这类长文档，按文档内嵌的章节层级切。先解析出标题结构（一级标题、二级标题），每个章节作为一个大段，如果章节太长再按段落边界切成 512 token 左右的块，块与块之间保留 50 token 重叠。这么做的好处是，一个 chunk 总是"一个完整的知识点"，而不是"半道工序"。

报价单和材料表完全不能用上面的方式。这类内容信息密度极高，切成 512 token 的文本块会破坏表格结构。我的做法是先把表格还原成 Markdown 表格，然后每个"产品行"连同表头单独切成一个 chunk。这样用户问"某型号瓷砖的规格和价格"，命中的就是完整的一行参数，而不是半张乱掉的表格。

客服问答记录是最简单的，每条 QA 单独作为一个 chunk，不合并、不截断。因为这些问答本来就是人工维护的高质量语料，一条一个知识点，直接喂给检索就是最佳形态。

图片单独作为一种 chunk 类型处理。每张图片一个 chunk，metadata 里记录文件路径、所属文档、章节名、图片描述文本。检索时，图片 chunk 的描述文本会被向量化参与匹配，命中后返回图片本身。

这里要特别强调 metadata（元数据）的设计。我给每个 chunk 都挂上了这些字段：来源类型（PDF/图片/表格/问答）、所属部门（设计/工程/客服/售后）、关键词标签、版本号、入库时间、权限级别。后面章节会讲权限控制——没有 metadata，权限就是空谈。

3.3 图文对齐：让文字检索能带出图片

多模态 RAG 的核心难点是图文对齐。用户的问题是文本，但答案可能需要图片，这中间怎么打通？

我们做的方案可以概括为"图片描述 + 上下文绑定"双通道。第一通道是图片描述检索：前面提到给每张图生成了描述文本，查询时描述文本参与向量匹配。比如客户问"灰色地砖配什么墙"，如果某张效果图描述里有"灰色哑光地砖、米白色墙面"，这张图就能被召回到。第二通道是上下文绑定：工艺手册里文字提到"闭水试验"的那一页，往往配着一张闭水试验现场图，我把这条文字 chunk 和图片 chunk 通过文档坐标和章节号绑定在一起，检索到文字 chunk 时直接把绑定图片一起取出来。

这两个通道加在一起的效果是，检索结果里有文字、有图片、有表格，大模型生成的答案可以引用图片作为参考。客服在线上回复客户时，可以直接把系统检索到的效果图发给客户看——这个功能做出来后，客服团队的主管是最兴奋的，因为以前找一张案例图要翻半天相册。

做图文对齐时有一点要注意：图片描述生成的质量直接决定召回效果。如果描述写成"这是一张室内照片"这种废话，那跟没描述一样。我们的描述强调三个要素：空间类型（客厅/卫生间/厨房）、核心物件（瓷砖/柜体/台面）、视觉特征（颜色/纹理/风格），缺一不可。

3.4 Prompt 和回答风格设计：让 AI 说人话，也守规矩

RAG 的生成端不是随便接个大模型就行，Prompt 设计直接决定回答能不能用。我为这家装修公司定了一套规则，主要有四条。

第一，回答必须引用来源。所有回答的末尾要带上知识库里的文档编号和章节，方便客服复核。第二，不知道就直说。检索结果里没有相关内容时，模型必须回复"这个问题我需要确认后再回答"，不许编造。第三，产品信息必须和库里一致。报价、型号、保修期这类硬事实，只允许从检索上下文里抽取，不准模型凭自己的知识补全。第四，语气要有行业感。装修客户咨询经常涉及大额消费，回答语气要求礼貌、专业、不催促。

系统提示词里我还加了一条很关键的约束：如果问题涉及具体工地的实况（比如"我家现在装修到什么进度了"），模型必须明确表示自己不知道，建议客户联系项目经理。因为知识库里没有实时工地数据，硬回答就是幻觉，在装修这种强信任消费场景里，一次错误回答可能丢掉一个客户。

4. 踩坑实录：上线前后最容易翻车的地方

4.1 检索不准？先按这五个原因排查

项目上线后我接到最多的反馈就是"问的问题答非所问"。每次排查我基本都按这个顺序走，命中率很高。

第一查切片粒度。有一种典型表现：问 A 问题，召回来的片段里只有半句话提到 A，其他全是 B 的内容。这种情况通常是切片把两个知识点切到了一起，解决方法是按语义边界重新切。第二查图片是否有描述。如果用户问的是视觉相关的问题但召回结果里一条图片都没有，基本就是 caption 缺失或描述太泛，先去补图片描述。第三查专有名词。装修行业词如"乳胶漆""石膏板""美缝剂"在向量空间里很容易和相似词混淆，解决方式是扩充同义词表：用户习惯说"刷墙"而库里写的是"墙面涂饰"，这个 gap 不补齐，召回永远差一截。第四查表格还原质量。报价单表格还原错了，检索内容就是错的，直接人工抽检表格结果。第五查重排阈值。有时候重排模型把正确答案压到了 Top 5 之外，适当放宽 Top N 或者调整融合权重就行。

4.2 报价单和表格是重灾区

整个项目里最有"技术含量"的活，其实是 Excel 报价单的处理。装修公司的报价单格式极其多样，有的用合并单元格，有的有多级表头，有的一个 sheet 里有多个表格，有的在表格中间嵌了图片。OCR 还原这些表格时，合并单元格一拆，数据就错位了；多级表头一合并，字段名和值对不上。

我的处理方案是"表格结构还原 + 规则校验"两段式。先用开源表格模型把表格转成带结构的文本，再用一组规则做校验：价格列里必须是数字，规格列里必须包含"mm"或"x"之类的单位模式，品牌列不能为空。校验不通过的行直接标记为"低置信度"，检索时不参与语义匹配，避免脏数据污染结果。这个思路可以沿用到任何行业的表格类文档——规则校验永远比模型更值得信任，模型负责理解，规则负责兜底。

4.3 权限控制：同一个库，不同人看到的必须不一样

装修公司的知识库里有很多敏感内容：材料进货价、客户联系方式、内部折扣规则。销售客服能看产品库和话术，但不能看进价；工长能看工艺手册，但不能看客户合同。这就要求知识库必须支持细粒度的访问控制。

我们利用每个 chunk 的 metadata 里的权限级别字段，把数据分成三级：公开级（产品介绍、工艺说明）、内部级（报价单、折扣政策）、机密级（客户合同、进价表）。检索前先根据当前用户的角色过滤 chunk 列表，过滤之后再喂给重排和生成。整个流程在应用层做拦截，不依赖底层向量库的权限机制，这样不管向量库选什么都适用。

访问审计也必须有。我们给知识库系统接了一个简单的日志模块，记录每一次检索的用户、时间、查询内容和返回结果摘要。最开始业务方觉得没必要，直到有一次一个离职员工试图导出全量客户资料被日志拦下来，他们才意识到审计不是形式主义。

5. 效果评估与后续运营

5.1 效果评估指标：不能只看模型准不准

知识库上线一个月后，我从三个维度做了系统评估。

第一个是检索层指标：召回率和命中率。我从客服实际问答里抽了 200 条真实问题，人工标注每条问题的标准答案文档，然后跑一遍检索流程，统计正确答案是否出现在 Top 5 结果里。最终命中率是 81%，这个数字作为基线保留，后续每次改动都要复测。

第二个是生成层指标：答案可接受度。让客服主管对系统生成的回答做抽样打分，分三档：可用、需修改后可用、不可用。最终可用加微调可用的比例大约 88%，剩下的主要是复杂多轮问题，需要跳转到人工。

第三个是业务指标：客服平均响应时间和问题解决率。这个指标是最有说服力的——上线前客服平均响应一个产品咨询要 5 分钟，上线后缩短到 1 分半，客户满意度评分还涨了。业务指标能拿到，老板才愿意继续投入。

我强烈建议做 RAG 项目的团队从一开始就建立评估集，而不是等项目上线后再补。200 条标注问题只需要一个下午就能做完，但后续每一次模型切换、每一个参数调整，都需要它来做回归测试，否则你的优化方向全靠感觉，迟早把系统改坏。

5.2 成本优化：企业私有化部署怎么省钱

这家装修公司的预算有限，私有化部署必须精打细算。我做了三处优化。

一是模型量化。生成端大模型用量化版本部署，效果在客服场景下和满血版基本无差别，但显存占用少了一半。二是缓存。高频问题（比如"你们的保修期是多久""有哪些主材品牌"）命中缓存后直接返回，不再走检索和生成链路，整个系统的吞吐量提升明显。三是离线批量处理。文档解析、图片描述生成这类重活全部放在夜间定时任务里跑，不占用白天的 CPU，GPU 只在需要时开机。

还有一个容易被忽略的成本点：向量维度。如果文本向量用的 1024 维，单条数据量大概率在 1.5KB 到 2KB，十万个 chunk 才几百 MB，向量存储成本很小。但如果你的数据量到了千万级，可以考虑先做 PCA 降维到 256 维，检索精度损失不大，存储和计算省下非常多。

5.3 知识库的运营机制：这活儿不能没人管

最后说一个最容易被忽略的问题：知识库不是搭完就能自转的。装修公司每个月都更新产品、调整工艺、变动价格，如果知识库没人维护，三个月后里面的信息就过时了。

我们最终定了一套轻量的运营机制。每个部门指定一个人做"知识管理员"，负责本部门资料的更新入库；更新必须走审核流程，先用小批量数据测试检索效果，确认无误后再全量发布；客服在使用过程中发现回答有问题，可以直接标记"此回答有疑问"，标记数据每周末汇总给运营人员修正。

这个机制看起来不起眼，但它决定了这套系统能不能持续用下去。我见过太多知识库项目，上线时效果惊艳，三个月后因为没人更新数据沦为摆设。AI 知识库的本质不是一次性的技术交付，而是一个需要持续喂养的内容产品——这句话值得所有做企业 RAG 的人记在心里。

最后再分享一个小经验：多模态 RAG 在传统行业落地，最大的难点从来不是模型不够聪明，而是数据太乱、场景太散、维护缺人。把这三个问题解决了，哪怕用的模型是中规中矩的，效果也能甩开那些"模型很强但数据一塌糊涂"的方案八条街。如果你也准备做类似的事，建议先在一个高频场景里把全链路跑通、让业务方看到实实在在的收益，再考虑扩大范围——技术这东西，只有用起来才叫价值。