企业官网建设流程全解析

做这个项目之前，我一度觉得"知识库"这个词跟装修行业没什么关系。直到我们公司把三百多个历史项目的合同、施工图、报价单、效果图和工艺照片翻出来盘点，才发现这家公司最值钱的资产，全都躺在一个没人能找到的角落——而它们恰恰是最典型的多模态 RAG 知识库素材。如果你是一家装修公司的负责人，或者你在任何传统行业负责 AI 落地，这篇实战记录应该能帮你少走几个月的弯路。

1. 装修公司的知识管理困局：老板为什么拍板要上 RAG

1.1 痛点不是"没知识"，而是"找不到知识"

我所在的公司是一家三百多号人的装修企业，业务覆盖设计、施工、主材和软装。体量不算大，但项目类型很杂：家装、小工装、旧房改造都有。真正让我意识到知识管理出问题的，是三件特别不起眼的小事。

第一件，客服那边。每天有二三十条咨询，其中三分之一是重复问题："你们用的是什么板材？""柜子质保几年？""已经装到一半还能改设计吗？"这些答案其实在官网、合同模板和内部 FAQ 里都有，但客服新来的小伙伴得在微信记录里翻半天才能找到标准说法。

第二件，设计师那边。有客户拿着手机里一张北欧风的客厅照片来问"我们家 89 平能不能做？"设计师得先从公司图库里找类似户型、类似风格的案例，再翻聊天记录找之前合作过的软装品牌。这个过程普遍要三到五个工作日。

第三件，工地那边。有位工长在群里问"卫生间回填工艺用的是哪个版本的标准？轻质回填还是陶粒回填？"结果施工部的同事翻出一份三年前的 PDF，里面写着旧工艺做法。等发现这个问题的时候，现场已经按错误工艺施工了两天。

这三件事共同指向同一个结论：企业不缺知识，缺的是能把知识在正确的时间送到正确的人手里的通道。传统做法是靠"人肉搜索引擎"——问老员工、翻共享盘、查聊天记录，效率低不说，准确性也没法保证。

1.2 为什么最后选了 RAG，而不是微调一个行业大模型

立项前的技术讨论会上，团队里有人提出过两条看似"更 AI"的路线：一是直接买一个通用大模型服务，靠提示词硬扛；二是拿公司历史资料微调一个专属大模型。

这两条路线被我当场泼了冷水。

通用大模型连我们公司的材料清单都记不住，更别说回答"08 户型的主卧背景墙当时用了什么工艺"这种具体问题。你给再长的提示词，模型也不知道你家公司有个 08 户型。微调大模型的成本更不用算：图纸、合同、效果图、施工照片这些多模态数据，光是清洗和标注的人力就够养一个小组了，而且公司知识每周都在变，每更新一批材料就微调一次，这根本不现实。

RAG（检索增强生成）的逻辑刚好反过来：先按需检索，再让大模型基于检索到的材料组织答案。它不要求模型记住企业资料，只要求模型学会"查资料"。知识更新只需要维护好数据库，不用重新炼丹。这个思路在今天已经是行业共识，但在我当时给管理层汇报的时候，还是花了两个晚上才让老板理解"为什么我们不是买一个现成的问答机器人"。

真正推动老板拍板的，是那张投入产出对比表：微调大模型要花几十万买算力，还要专职算法工程师维护；RAG 方案的服务器成本只有前者的零头，知识更新靠业务部门自己就能完成。对于一个毛利本身就不高的装修企业，这笔账不用算第二遍。

1.3 项目的边界：不追求"全能问答"，只解决三个场景

立项后我做的第一件事不是选型，而是把项目范围砍到只剩三个场景：

• 客服问答：面向客户咨询的标准话术、材料说明、施工流程、售后政策；
• 设计辅助：设计师按户型面积、风格、预算找历史案例和效果图；
• 施工支持：工长和监理在工地现场查工艺标准、材料用量和常见问题。

这三个场景有一个共同特征：高频、重复、有标准答案。它们才是知识库最容易见效的地方。其他场景比如"自动出报价""自动画施工图"，当时连想都没想，因为那不是知识库能解决的问题，后面再描述。

2. 多模态数据盘点：装修资料里到底藏着哪些"非文字"信息

2.1 不看不知道，翻了三个服务机柜才凑齐资料全集

开始动手之前，我们花了整整两周做数据盘点。资料分散在三个地方：公司共享盘、设计师个人电脑的 D 盘、以及几十个微信群聊天记录里。最后汇总出来的清单大致是这样：

盘点完我自己也吓了一跳：非文字信息占了全部资料的大约四成。而这些非文字信息恰恰是装修行业知识密度最高的部分。一张北欧风效果图比五百字文字描述更直观，一张卫生间防水节点图比工艺规范里十句话都有说服力。如果只做纯文字版 RAG，等于把这四成资产直接扔进碎纸机。

2.2 三种"麻烦鬼"：扫描件、表格、竖版长图

盘点的过程中，我们提前识别出了三类日后一定会出问题的数据。

第一类是扫描件合同。年代久远的合同是拿手机拍照或者老式扫描仪扫的，分辨率低、纸张泛黄、还有手指头不小心入镜的情况。这种文件直接进 OCR 引擎，出来一堆乱码不打紧，怕的是识别结果"似对非对"——字体看起来正常，但金额数字被认错。

第二类是报价单和材料清单。这类文件的特征是大表格、多级表头、合并单元格。如果解析时把表格拍平成一个段落再切片，数字所在的列就丢了，更没法回答"某品牌某型号板材多少一平"这类问题。

第三类是竖版长图。装修公司的很多工艺说明喜欢用一屏一屏的竖图排版，一张图里有几十条步骤。这种图如果只截取局部做索引，很容易把上下文切碎。后来我们统一把它们重新导出成横向 PDF + 文字说明的配套组合，才彻底解决。

这三类数据在盘点阶段看着只是格式问题，但在后面的解析阶段其实决定了整个 pipeline 的选型。所以我说盘点这一步是整个项目性价比最高的一天——它帮你提前知道哪些钱不该花。

2.3 为什么不做"一刀切"的图像识别

当时市面上做图像内容识别的解决方案不少，很多是把所有图片统一送进视觉理解模型，输出一段描述文字再进文本向量库。在演示环境中一切完美，但放到装修公司真实资料上，我很快发现了问题：视觉模型对"户型图"的理解跟设计师完全不是一回事。

通用视觉模型能看出"这是一张卧室的照片"，但很难理解"这张户型图是 89 平三房一卫、客厅朝南、主卧门和次卧门相对"。户型图上的逻辑关系是结构化信息，不是"是什么物体"的语义信息。它需要的是把面积标注、房间名、门洞位置抽出来，再跟图本身建立的视觉索引做配合。

于是我们确定了项目的核心约束：不能用单一模型打天下，必须根据内容类型分路处理。这也是整个多模态 RAG 架构设计的最初出发点。

3. 技术选型与架构设计：为什么最终选了"双层路由 + 分治解析"

3.1 三种候选方案对比

在设计整体架构之前，我让团队出了三套方案，专门开了一整天的评审会：

• 方案 A：全量多模态向量化把所有文档、图片、表格统一转成多模态向量，查的时候用一个向量检索搞定。优点是链路短，缺点是造价高、解释性差——你很难说清楚一张效果图为什么排在报价单前面。

• 方案 B：全量解析成文本所有资料先 OCR / 解析成 Markdown 文本，统一走文本向量库。优点是好落地，缺点是表格和图纸的结构信息全丢了。

• 方案 C：双层路由 + 分治解析（最终采用） 入口先做一个轻量级意图识别，判断用户问题到底要检索文本、图片、表格还是图纸；然后各类型资料走各自最合适的解析与索引通道；检索结果统一汇聚到重排模型，再交给大模型组织回答。

方案 C 当时看起来最复杂，但我坚持选它，理由有三点：

第一，装修知识的检索需求天然是分裂的。"你们用的什么板材"是文本检索；“这个茶几配什么风格的沙发”是图片检索；“08 户型的主卧门要不要改方向”是户型图检索+方案文本检索。把它们揉在一个向量空间里，只会互相干扰。

第二，分治解析的扩展性好。以后如果增加视频巡检资料，只需要新加一个视频解析通道，原来文本、图片的通道完全不动。

第三，每个通道都能独立调试。现在后端同事改图片解析逻辑的时候，不需要担心影响到合同解析那一路。对于只有三个后端开发的小团队，这种隔离非常重要。

3.2 系统最终的五层架构

项目最终形态分为五层，我尽量用大白话说清楚每一层干的事：

1. 文档接入层：对接公司共享盘、钉钉文件和本地数据库，定时扫描增量文件，按项目编号、日期、类型打标；
2. 分治解析层：文本走文本通道（PDF 解析、表格抽取），图片走图像通道（检测、OCR、视觉描述生成、裁剪），户型图走专门的户型信息抽取通道；
3. 向量化与索引层：分别构建文本向量库、图片向量库、结构化属性库（比如面积、风格、造价区间都作为可过滤的字段）；
4. 路由与检索层：识别 query 类型，分发到对应通道检索，并做粗召回 + 重排序融合；
5. 答案生成层：把检索回来的片段拼成带引用的上下文，交给大模型生成答案，同时在下方案展示出处链接。

这套架构听起来跟通用 RAG 差不多，真正的差异在第二层和第四层——它把"装修行业的多模态"不当作"图片+文字"的简单堆叠，而是当作文本、表格、户型图、效果图、工艺照片五种相互关联但本质不同的知识类型去处理。

3.3 路由层的"轻量"是关键

很多设计会把路由层也做成一个大模型调用，我特意把路由设计成"结构化规则优先 + 模型判断兜底"的轻量机制。

比如用户问"你们主卧室背景墙方案有没有 2 万以内的"，结构规则直接根据"价格关键词+户型词"命中"设计案例"通道；用户问一句"我想要原木风但又不想太素"，结构规则判断不了，才交给语言模型做语义分类。

这么设计的理由是省钱和稳定。路由层每多一次大模型调用，就多一次延迟和失败风险。对于装修公司这种没有专门运维团队的场景，宁可让路由笨一点，也要保证它每次都走同样的路。后来实际跑下来，大约 75% 的查询用规则就分对了，剩下的 25% 才真正花大模型的推理费用。

4. 知识库搭建实战：从图纸、合同到施工标准的数字化

4.1 文本资料的清洗与表格保真

文本通道处理的第一个大坑，就是前面说的报价单表格。刚开始我们直接用现成的 PDF 抽取工具，把表格拍平成了拼音+数字的一串文本，切片之后 embedding 的效果惨不忍睹。

后来我们调整为：表格组件识别 → 转成 Markdown 表格 → 把每个表格作为一个独立 chunk 入库。每个表格 chunk 前面加了表格标题和项目编号作为上下文，这样就保住了"表头-列-行"的对应关系。回答"某品牌某型号多少钱一平"这一类问题时，大模型能直接从 Markdown 表格里找到精确数字。

合同类文本处理相对简单，但有一个细节值得提：盖章扫描件的 PDF 必须按页切，不按段落切。合同里"甲方""乙方"这些字段跨越不同条款，按页切能保证完整上下文；按段切反而会切碎关键义务条款。切片大小我们统一使用 512 token 的重叠策略，重叠窗口设置 32 个 token，避免跨段断裂。

4.2 效果图和户型图的"图文配对"入库法

图片是最需要设计的地方。一开始我们也尝试直接把所有图片丢给视觉模型生成一句描述，然后把描述文本存库。但很快就发现一个问题："一句描述"根本承载不了一张效果图的信息量。

后来我们改用"图文配对"思路：

• 对每张效果图，先让视觉语言模型生成结构化描述：空间类型（客厅/卧室/卫生间）、风格（现代/北欧/原木/轻奢）、主色调、家具材质、亮点设计；
• 再把它对应的历史项目方案文字说明作为附属文本，一起绑定到同一个向量表示上；
• 检索时，query 同时匹配图片视觉向量和绑定的文本向量，取最高分。

这样做的好处是，当客户说"我想要原木风、浅色调、沙发背景墙不要岩板"时，系统能同时从图片的"风格标签"和文字的"项目描述"两个维度命中，比单纯靠图像 embedding 泛泛找相似图准得多。

户型图的处理走的是另一条路：结构化抽取 + 视觉索引双轨。抽取的部分包括房间数量、建筑面积、各空间尺寸、朝向、承重墙位置、门洞位置。这些抽取结果不直接作为文本向量，而是作为结构化字段存下来，供检索时做硬过滤——比如"面积在 80 到 100 平"这种数字区间条件。

4.3 工艺照片和现场验收照片的处理

工地现场照片的问题完全不同：它们太相似了。三个月内的几十个工地都拍过"卫生间防水施工中"的照片，光靠视觉 embedding 区分度非常差。照片之间的差异在细节：墙面有没有做 30 公分的防水上翻、地漏处有没有做附加层、管根有没有做圆弧处理。

处理这类图片的关键在于照片的陪伴文本。我们把每张工艺照片和它对应的拍摄说明、验收标准绑定成一个知识单元。照片里看不清的细节，靠文字补充；文字说不清的形态，靠照片确认。后来上线之后，这类"照片+标准"的组合反而是工长使用频率最高的功能之一。

对于已经归档的老照片，我们实在没法回去问当时的拍摄人，就靠工长访谈把常见做法的标注补充进去。这活儿很费人力，但做完整整一年之后，相当于把公司历史上零散的施工经验整理成了一套带图文对照的工艺档案库。这个隐性收益，比问答系统本身的价值还大。

4.4 元数据体系和权限过滤

装修公司的知识有一个特殊性：非常讲究"项目维度"。同一套设计图，在报价阶段是商务机密，在施工阶段是现场依据。如果知识库不区分角色权限，很容易出现"客服把成本价报给了客户"这种事故。

我们在每个 chunk 上都挂了元数据：

这套元数据在检索时承担了双重职责：一是做硬过滤，直接砍掉不该出现的内容；二是做重排加成，比如用户限定了"90 平以内"，那么面积元数据匹配的案例在排序时会有更高权重。

5. 检索效果调优：装修专业词汇和图像检索的双重难关

5.1 专业术语检索的"同义词"坑

系统第一次内测，我们拿真实问题测了一轮，结果惨不忍睹。用户问"墙板收口怎么处理"，系统召回的内容是"多层实木夹板的安装规范"——看起来沾边，但实际上完全没有回答收口工艺。问题出在词面上："收口"这个行业词，在资料库里对应的术语其实是"阳角/阴角处理""压条收边""海棠角"。

装修行业的用词和书面术语之间的映射关系非常发散。同一个做法，工长叫"压边"，设计师叫"收口"，材料商叫"封边"，图纸上写的是"线条收口节点"。如果知识库没有术语归一，纯靠 embedding 的语义相似度根本救不回来。

我们采用三级方案解决：

1. 建行业同义词表：由三位资深项目经理和两位设计师共同整理出约四百组同义词，同步注入到文本索引之前的分词词典和查询改写模块；
2. 查询改写：用户输入"收口"时，系统自动扩充检索词，同时搜"收口/收边/压条/阳角处理/海棠角"；
3. 可解释反馈：搜索结果展示"相关搜索词"提示，让用户知道系统理解了哪些扩展概念，用户不懂行业术语也能持续修正查询。

5.2 图像检索的"看得像"与"不对路"

图片检索调优比文字麻烦得多，因为一张效果图可以同时命中"好看"和"不是你要的那种好看"。我们遇到的典型事故发生在内测第二天。

当时有团队同事拿自家户型试问题："140 平四室两厅，想要新中式风格，电视墙不要复杂的格栅。"系统返回了一张效果图，风格确实新中式，但仔细一看，那是一个 60 平小户型的客餐厅一体设计。原因是纯视觉 embedding 匹配的是"风格+家具形态"，完全忽略掉了面积和户型结构。

这个问题的解药不是调整 embedding 模型，而是把路由层和检索层的数据结构调整好。我们在路由层抽取了明确的"户型面积 - 风格 - 预算"槽位，面积和户型做硬过滤，风格做语义检索；检索结果到了重排阶段，再按"户型结构相似度 + 风格相似度 + 文本描述相似度"综合打分。经过这轮调整，"45 平 LOFT 想要新中式"和"140 平四居室想要新中式"再也不会互相串门。

5.3 大模型"一本正经胡说八道"的约束办法

多模态 RAG 的大模型生成环节，最怕的不是模型啥都不会，而是它基于检索片段自由发挥，造出一个看似专业、实则不存在的工艺标准。

我们规定：答案必须由若干检索片段拼接而成，所有说法都有片段出处；如果检索没有相关内容，模型必须回答"资料库中未找到该标准"，允许以建议形式提示"建议咨询工程技术部"，不允许自行编造。这里通过系统提示词里强约束 + 后置规则双重兜底。我们只允许模型基于检索到的文字、表格、图片说明生成答案，并且在答案下方固定展示出"引用资料"区，列出命中的文档标题和页码。

效果立竿见影。内测阶段幻觉率大约 18%，上了引用约束之后降到 6% 左右。剩下的 6% 主要是模型对"检索片段里语义相近但性质不同"的内容做了过度概括——这时候单纯靠约束就没用了，只能从源头提高召回质量。

5.4 线上演示"翻车"引出的槽位校验机制

项目上线发布会当天，我们安排了一个现场演示环节，结果当场翻车。市场部的同事上台提问：“我们公司最新的 140 户型装修套餐是什么？”系统把“140 户型”识别成了“140 平户型”，一下检索出来几十条内容，回答非常发散，台下技术团队脸色都变了。

复盘之后发现，问题出在实体识别的粒度上。户型编号"140 户型"是公司内部指代某一栋楼特定户型的专有名词，但通用实体抽取把它拆成了数字"140"和平数"140平"来理解。后来我们加了一套行业实体感知的槽位校验：数字关键词优先匹配"项目编号/户型编号"字段，只有在匹配不到项目编号的情况下，才回退到平数语义。同时在上线演示系统里加入了人工纠正按钮，万一自动识别错了，演示人可以直接圈选正确检索范围兜底。

6. 落地后的日常运营与常见坑：垂直行业做 AI 落地的几点提醒

6.1 知识库不是建完就完，而是要当"产品"持续运营

项目上线后最初的三个月，效果还行，但第四个月开始掉数据。回访后发现原因不复杂：新的设计方案、新工艺、新材料都在持续产生，但没有人在维护。后来我们从每个业务部门抽调了一个兼职管理员，每周花半天时间把新增资料按规范丢进知识库。这套"业务兼职 + 技术兜底"的运营机制，比任何技术优化都重要。

更新后的知识库要重新建立索引，但没必要每次都全量重建。我们按项目维度和类型维度做增量更新，合同、报价一类的文档更新频率低，工艺标准每月复核一次，设计案例每周增量导入。索引更新的频率服务于业务真实节奏，没必要追求实时。

6.2 权限问题的第二条生命线

之前提过元数据里的 role_scope，这里我想多说一句。很多 RAG 项目做不好，不是检索不行，而是权限控制没跟上，导致业务部门不敢用。我们早期发生过一个事故：客服在测试环境里问"这个项目成本多少"，系统竟然把内部采购价当回答生成出来了。幸好当时还在测试期，没造成实际损失。

那次之后我们把权限过滤提升到检索链路的第一位，每个租户角色进入系统就带上权限上下文，路由器分发的第一个动作就是按权限过滤候选集合。方案本身不算复杂，但一定要在项目一启动就设计权限模型，而不是等系统能跑通了再补，否则返工成本极高。

6.3 对传统行业做 AI 落地的几条体会

最后说点个人体会，可能有些不适合听：

第一，不要先找技术再找场景，反过来才对。装修公司不缺技术热情，缺的是把"客户总在问同样的问题"这种日常烦恼，翻译成"需要一个带检索的知识库"的能力。技术选型应该从业务痛点倒推。

第二，多模态的"多"不是炫技。对我们这个项目而言，如果只处理文本，顶多做一个不太准的 FAQ 机器人；把户型图、效果图、工艺照片纳入进来以后，它才真正变成了设计师和工长愿意用的工具。多模态 RAG 的价值，取决于行业里"看图说话"的知识占比。

第三，系统要能解释自己。每个回答都带引用来源，看起来只是产品功能，其实是建立信任的过程。传统行业的老师傅骨子里不相信黑盒子——他们能接受机器帮忙找资料，但不能接受机器替他做判断。所以"给资料、不给结论"反而是这套知识库最被认可的设计。

这项目从启动到打完收工，前后花了四个多月。中途有几天我也怀疑过自己是不是把一个简单事搞复杂了——现在回头看，如果没有那套双层路由和分治解析，后面所有的调优都会变成在一团乱麻里打补丁。如果你也在某个看起来不那么"高科技"的行业里做 AI 落地，我的建议是：先盘资产，再定边界，然后大胆让业务人员提需求，技术是你的工具，但业务才是你真正的产品经理。