企业官网建设流程全解析

去年我们公司决定做一个企业级多模态 RAG 知识库，起因其实特别朴素：装修这个行业的知识太碎、太散，而且高度依赖老师傅的“口口相传”。当时公司内部光是设计规范、施工工艺卡、材料参数表就分落在十几个文件夹和几个互不相通的系统里，客服回答一个“防水施工后几天能闭水试验”的问题都要翻好几个群。新来的设计师问旧版设计规范，老同事经常直接甩一个聊天记录过来，里面是几年前的截图。信息不是没有，而是找不到、对不上、不敢信。

所以当大模型的能力被聊得热火朝天的时候，老板问我一句：“这玩意儿能不能帮我们把知识管起来？”我就知道，纯靠一个大模型聊天框解决不了问题。我们需要的不是让模型“记住”公司知识，而是让它在被问到具体问题时，能准确“查”到公司内部的标准答案——这就是 RAG，检索增强生成。而装修公司的知识不只是文字，还有图纸、效果图、报价表、验收单，所以最后我们做的，是一个以多模态数据为核心的 RAG 系统。

这篇文章就把我们整个项目从零到一落地的过程完整记录一下。包括怎么选型、怎么切分数据、怎么设计检索、怎么建评测集，以及那些常规文档里不会告诉你、只有自己踩坑才能总结出来的细节。如果你们公司也在考虑做内部知识库，或者正在做 RAG 但效果不理想，这篇应该能帮你少走不少弯路。

1. 先弄清楚一个前提：装修公司的知识库到底要解决什么

1.1 知识资产的形态比想象中复杂

装修公司的“知识”分很多种，我一开始也想简单了，以为就是把文档扔进去，做个问答机器人。真正盘点之后发现，知识资产至少得切成四类：

第一类是设计规范与标准，包括公司内部的制图标准、户型改造原则、水电点位设计规则，这些通常是 Word、PDF，还有一部分在旧版 OA 里，格式乱得很。

第二类是施工工艺与验收标准，油漆基层怎么处理、瓷砖空鼓率控制在多少、防水闭水试验要多久，这些知识分布得最散，甚至有些内容只存在于监理的手机照片和项目复盘会议的录音里。

第三类是材料库与报价体系，瓷砖、地板、涂料、板材的型号参数、供应商信息、单位成本、损耗系数，这些大多在 Excel 表里，而且不同门店的报价口径还不完全一致。

第四类是客户常见问题与售后话术，比如“装修中途加插座要加多少钱”“你们的乳胶漆环保等级是多少”，这类知识散落在客服聊天记录和销售话术文档里。

所以要做的第一步不是选技术，而是和业务部门坐下来，把他们的知识资产挨个过一遍，确认优先级。我们当时花了整整两周做盘点，产出了一张知识地图，标清楚每种资料的格式、负责人、更新频率和使用场景。这张知识地图后来成了整个项目的需求和验收依据，这一步做得越细，后面就越省心。

1.2 为什么是 RAG，而不是微调大模型或让模型硬背知识

这个选择题，很多团队会纠结。我们当时的判断很直接：装修公司的知识是强时效、强权限、强结果导向的。材料价格可能一季度一变，施工工艺会因为新供应商而调整，这些知识如果靠微调塞进模型参数里，更新一次就要重新训练一次，而且训练之后也没法验证模型到底记住了多少，风险太大。

RAG 的好处在于，知识和模型是分离的。知识存在外部知识库里，大模型只负责“读”和“组织答案”。知识变了，只需更新知识库里的文档，不需要动模型。而且 RAG 可以在回答之后把引用来源展示出来，让设计师或项目经理敢看、敢信、敢追溯。

有人问，那直接用长上下文把几万字的文档都塞进去行不行？实测下来，长上下文在小范围测试时看着不错，但一旦资料多到一定程度，模型会把早期信息“忘掉”，也就是所谓的长上下文注意力衰减，而且成本也会随着 token 数量飙升。RAG 的优势是把信息检索压缩到只把最相关的一小段文本交给大模型，在成本可控的前提下，准确率反而更高。

多模态在这个场景里不是锦上添花，而是刚需。装修知识里最有价值的部分恰恰是图文混排的内容，比如一张工艺节点图，如果只是把图扔给模型，它可能只能看懂表面的结构，但无法知道这个节点对应的施工标准；如果只是把图下的文字提取出来，又丢失了图形本身的尺寸和结构信息。所以我们必须在知识接入阶段就做多模态的统一处理。

1.3 多模态在装修场景具体体现在哪里

我们说的多模态 RAG，不只是“能传图片和文字”，而是要让系统在处理检索和生成时都具备跨模态的能力。在装修公司的场景里，我认为有三种典型的形态：

第一种是图文混排文档。施工工艺卡通常是一半文字一半示意图，有的直接是扫描件。这类文档需要版面解析，把“图片中的标注文字”和“图中的结构信息”一并抽取出来，形成一个完整的描述单元。

第二种是纯图片。比如户型图、效果图、节点大样图，它们本身就是核心知识，没有配套文字。这类内容必须靠视觉理解模型提取结构信息，再结合人工补充的结构化字段，才能在检索时被正确匹配。

第三种是表格与结构化数据。报价表、材料参数表、施工进度表，这类数据天然是结构化的，如果简单转成纯文本去切分，会损失掉行列关系，导致回答时算错损耗率这类低级错误。

所以我们在设计阶段就确定了一个原则：不追求某一种模型“通吃所有模态”，而是用一条混合管线把不同模态先转成统一的、可检索的文本表征，再统一送入检索系统。后面在技术方案部分我会把这条管线展开讲。

2. 技术选型与整体架构：不追新，只追耐折腾

2.1 选型的三条硬约束

项目一开始，我们列了一堆候选技术，但很快意识到，企业级知识库的技术选型不能只看评测指标，还得看它在真实环境里能不能活下来。我们当时给自己定了三条硬约束：

第一，私有化部署优先。公司的图纸、报价、客户信息都属于敏感数据，不可能送去公有云 API 做解析。这意味着我们选的所有模型和组件，都必须能在内网环境跑起来。

第二，组件要“耐折腾”。装修公司的 IT 运维能力有限，没有专职的算法工程师队伍。所以我们倾向于选择有活跃社区、API 稳定的开源组件，而不是论文刚出、代码还没稳定的研究项目。

第三，成本要算总账。不仅仅是 GPU 采购成本，还要算维护的人力成本。模型越多、组件越复杂，运维压力就越大。能用一个模型解决的事，绝不用三个。

基于这三条约束，我们的技术栈最终锁定在这几类组件上：文档解析用开源版面分析工具加自研规则，视觉理解用部署在内部服务器的多模态模型，嵌入和重排序用中文效果稳定、社区口碑好的开源模型，向量库选支持混合检索的分布式开源向量数据库，生成模型用内部部署的大语言模型。所有组件都是开源的，没有一项是闭源商业方案。

2.2 嵌入模型、重排序模型、生成模型各负责什么

很多第一次做 RAG 的人会把所有希望寄托在“大模型”身上，但实际效果的好坏，更多是由嵌入模型和重排序模型共同决定的。在 RAG 链路里，嵌入模型负责把文档切片映射到向量空间，决定的是“召回”的天花板；重排序模型负责在召回的结果里重新打分，决定的是“精排”的下限。

嵌入模型我们试过好几个版本，最终选了一款对中文长文本支持较好的开源嵌入模型，它有三个特点比较契合我们：支持长文本输入，能处理我们单块知识几千字的长度；中文语义理解能力强，能区分“防水施工”和“卫生间防水验收”这两个强相关但不同层级的主题；支持领域微调，我们可以用装修领域的术语表做增量训练，让向量空间里的距离关系更贴合行业语义。

重排序模型我们选了轻量级交叉编码器，它和嵌入模型不同，嵌入模型是把文档和问题分别编码成向量，然后用余弦相似度计算，而交叉编码器是把问题和文档拼成一句，让模型一次性编码，计算量更大，但相关性判断更准。它不会参与全库扫描，只负责在嵌入召回的前 100 条候选里重新打分，从性能上说是完全可接受的。

生成模型我们最初考虑过业务场景是否有必要用超大参数模型，后来发现 70 亿到 130 亿级别的开源中文指令模型，在配合 RAG 场景的提示词之后已经足够应付绝大多数问答，关键是要把提示词和引用约束做好，比一味追求大模型要实在得多。

2.3 整体数据流与系统架构

整个系统的数据流可以分成三段：知识接入与解析、索引与存储、检索与生成。

知识接入与解析阶段，原始文件进入统一解析服务。文本 PDF 走版面解析，扫描件走 OCR，图片走视觉理解模型生成描述文本，Excel 表格走结构化解析生成 JSON 和文本两种形式。解析结果统一转换成标准格式，带上来源、更新时间、负责人、部门权限等元数据，写入待处理队列。

索引与存储阶段，解析好的文本块经过嵌入模型向量化，连同原始文本、元数据一起写入向量数据库。我们同时保留了基于倒排索引的关键词检索能力，用同一套文档 ID 做对齐，为后面混检做准备。

检索与生成阶段，用户提问后，系统先做意图识别和查询改写，然后同时走向量检索和关键词检索，两组结果汇总后经重排序模型精排，再把得分最高的 8 到 12 段文本拼进提示词，交给大模型生成答案，最后在答案下方附带引用来源，标注出内容来自哪份文档、哪个章节。

这套架构跟前几年流行的直接把文档嵌入向量库然后“查一下就回答”的简化方案有明显区别。简化方案在 demo 里跑通很容易，但在真实业务里，查询意图多样化、知识之间互相引用，单纯靠向量相似度根本不够。我们中途好几次想简化，最后都因为业务问题的刁钻程度放弃了。

3. 知识接入与清洗：这一步做不好，后面全白搭

3.1 盘点之后，先把“脏数据”分门别类

我们盘点的知识源拢共超过 6000 份文件，但真正能直接进入知识库的不到四成。大部分文件的问题是：有的是扫描件，无文字层；有的是公司内部讨论稿，和最终执行标准不一致；还有大量文件是图片截图，只有局部信息。

我们把脏数据分成几类，逐类处理。第一类是完全过期的废弃文件，比如 2019 年的墙体拆改规范，这类直接清除，不能留在库里，否则检索时会干扰答案。第二类是重复文件，同一个施工节点图在五个项目文件夹里各有版本，我们以最新的评审版为准，删除其他副本。第三类是信息不完整的文件，比如缺了材料损耗系数的报价表，我们会先找业务部门补全，补不全的宁可先不加库。

经验是，清洗这个环节最容易被低估。团队容易犯的错是拿到数据就急着切块、向量化，结果模型问答效果差，回头排查才发现是源数据本身质量差。这个问题在 RAG 系统里的影响是指数放大的——源文件有一处错误，知识库里所有相关切片都会带上错误，回答时就会被多次召回。

3.2 图文混排文档和扫描件的处理

装修公司大量规范文件是图文混排的，而且不少是扫描版。对这类文件，我们用文档解析组件做版面分析，先识别出标题、正文、图片区域和表格区域，再把图片区域抽取出来交给视觉模型，同时把文字层做 OCR 识别。

关键难点在于图文对应关系的还原。一张工艺节点图下面通常有一段说明，这段说明可能描述了图中好几处标注的含义。我们最初把图片和文字分开提取，结果在检索时经常出现“图片说的是一回事，文字说的是另一回事”的情况。

后来我们调整了策略，解析时把图片识别为多个区域文本描述，并把这些描述和图下方的说明文字合并成一个知识单元，用“图注 + 正文描述”的方式生成一段完整的上下文。这样在后续切分时，它们不会被拆散到不同的知识块里，检索召回时也不会出现信息割裂。视觉模型处理完图片后，生成的描述可能包含“图中标注 15 为阴角线”这样的细节，配合图下文字的“阴角线安装应保证垂直度控制在 3mm 以内”，整段知识才完整。

3.3 表格与报价单的结构化处理

表格类知识一开始把我们坑得很惨。报价表里 “8mm 强化复合地板 128 元/平方米” 这种信息，如果转成纯文本后切成多个文本块，问到 “强化复合地板多少钱一平” 时，检索系统可能只能召回模糊相关的内容，回答时大模型算出个不准确的数字。

我们最终的思路是：表格走结构化解析，不转纯文本。解析后的表格保留行、列、单元格坐标，并生成两种表示，一种是机器可读的 JSON，用于精确计算；一种是面向检索的自然语言描述，比如把一行数据转成“某品牌 8mm 强化复合地板，供货价 128 元每平方米，损耗系数 3%”这样的文本。两种表示都进入索引，但用途不同。自然语言描述用于检索召回，JSON 字段用于必要时做精确比对和展示。

这里有个细节，表格中的单位、损耗系数、计价单位经常被漏掉。我们专门在解析规则里加了字段对齐逻辑，强制每个材料报价行都必须解析出规格、品牌、单价、计价单位和损耗系数五要素，缺一不可。规整后的结构化数据，还顺手帮公司理清了不少报价口径不一致的老问题。

3.4 分块策略：不是所有文档都按字数切

分块是 RAG 系统里最微妙、最容易被忽略的环节。切小了，上下文不完整，知识碎片化；切大了，混入无关信息，检索噪声多，还会推高 token 成本。常规做法是按固定 token 数切，比如每 512 或 1024 个 token 一块，加重叠。

但我们很快就发现，装修领域的知识有极强的结构性，标题层级本身就反映了知识边界。比如一份施工工艺卡，通常按基层处理、涂刷要点、验收标准分成大节，每节之间是并列关系而非递进关系。按固定字数切会把“施工准备”的一部分和“施工步骤”的一部分拼在一起，检索时召回的段落经常是驴唇不对马嘴。

我们最终采用的是结构化感知的分块策略：先按文档的标题层级做基础切分，每个二级或三级标题下的内容作为一个候选块；再对特别长的块按语义完整度二次切分，保证每块能独立表达一个相对完整的意思。切分完成后做逐块自检，比如挑出包含表格的块，确认表格结构没被拆坏；挑出图文混合的块，确认图片描述和正文在同一个块里。

这一步没有银弹，只有结合业务知识反复试验。好在装修领域的文档本身就有很强的结构规范，一旦把解析规则理清楚，后续切分正确率能稳定在九成以上。

4. 检索与生成的完整链路实现

4.1 混合检索：向量、关键词、元数据过滤一个都不能少

初期我们只做了向量检索，效果在科普类知识上还行，但一到专业场景就出问题。“闭水试验一般要多久”这个问题，向量检索能召回防水施工相关文档，但经常召回不到具体讲闭水试验的那一节。原因在于，语义相似不等于字面相关，向量模型把“防水施工”和“闭水试验”这两个概念算得很近，但精确答案藏在字面上完全不同的段落里。

后来我们加入了关键词检索，用 BM25 这类倒排索引算法做字面匹配。向量检索擅长“语义相关”，关键词检索擅长“精确匹配”，两者互补之后，召回效果明显提升。实测中，混合检索的召回率比纯向量检索高出差不多 20 个百分点。

除了两种检索方式，我们还做了元数据过滤。知识接入时，每份文档都登记了来源部门、知识类型、适用范围、更新日期、权限等级。回答“设计规范”类问题时，优先过滤掉施工工艺类知识；回答“报价”类问题时，过滤掉没有定价权限的文档。元数据过滤的价值不只是提升准确率，还承担了一部分权限控制职责，后面会展开讲。

4.2 查询改写与意图识别

用户在真实业务里提问的方式，和我们在评测集里设计的问法差别很大。设计师会问“厨房吊顶用防水石膏板还是铝扣板好”，项目经理会问“轻钢龙骨隔墙最上面要不要封石膏板”，客服会问“客户问墙面裂缝怎么处理”。同一个知识主题，提问措辞千差万别，如果不做查询改写，检索系统经常被一些口语化表达带偏。

我们的做法是先做一个轻量级意图识别，把问题粗分成规范类、工艺类、材料类、报价类、售后类几大类，再按类别做查询改写。改写规则有两类，一类是规则驱动的同义词扩展，把“墙面”映射到“墙体饰面”，“吊顶”映射到“顶面工程”；另一类是让大模型基于业务术语表做改写，把口语问法转换成规范问法。改写后的查询再进入混合检索。

这个环节和权限控制、元数据过滤是联动设计的。报价类意图会强制附加“仅检索报价文档”的过滤条件，工艺类意图则只检索工艺卡对应的知识分组，这样既减少噪声，又防止越权知识被召回。

4.3 重排序模型精排候选

混合召回之后，我们会得到至少几十条候选知识块。直接用这几十条拼提示词，token 成本高、噪声大、大模型容易被无关信息带偏。所以我们加了重排序环节，用交叉编码器对“问题 + 每个候选块”做相关性打分，只保留分数最高的 8 到 12 条。

重排序模型的效果远超预期，但又确实是个计算瓶颈。交叉编码器要对每个候选块做一次完整计算，如果候选数量超过 100 条，延迟会明显上升。我们做了一层工程优化：先用向量检索和关键词检索各出前 50 条，合并去重后大约 80 到 100 条，再送重排序模型。实际压测下来，单次问答的检索链路延迟控制在 300 毫秒以内，完全够用。

重排序还有个隐藏价值，它能作为检索质量的观测指标。我们上线后长期统计每个问题排在前几位的知识块类型，如果大量问题召回的顶部结果都是同几份文档，说明这些文档可能是热门知识，也可能是检索偏移，需要人工关注。

4.4 提示词设计与答案生成

检索到的知识块质量再高，如果提示词设计不合理，大模型还是可能“自由发挥”。装修领域的答案必须严谨，涉及数字的地方一点都不能错，所以我们把提示词设计成强约束型。

我们在提示词里明确规定：答案只能基于提供的知识块生成，如果知识块不足以回答问题，必须明确说“基于当前知识库无法确切回答”，不能编造；涉及数字和标准时，必须保留原文档表述，不得改写；答案末尾必须列出引用来源，格式是“文档名称 + 章节标题”。为了让模型理解这些规则，提示词里给了一个简短示例，展示合规答案和违规答案的对比。

生成模型选择 70 亿到 130 亿参数级别的开源中文模型，在内部服务器上用两张 GPU 就能跑起来。实测效果稳定，配合强约束提示词，答案几乎没有出现胡编乱造的情况。唯一踩过的小坑是，模型偶尔会把知识块里不适用于当前问题的信息也写进答案。我们的对策是提示词里加一句“仅使用与问题直接相关的知识块内容”，并在重排序阶段把相关性阈值稍微调高。

4.5 权限控制与数据隔离

企业级系统绕不开权限。装修公司虽然不像金融、政务那样权限层级复杂，但设计规范、报价体系、客户信息这几类数据，确实只允许特定部门访问。我们的方案是给每个知识块打上访问标签，检索时结合当前用户的角色做过滤。

实现上不能只在“检索后”做过滤，那样效率低，而且容易遗漏。我们在检索阶段就把权限作为元数据过滤条件的一部分，比如项目经理角色默认不会检索到报价相关文档，客服角色不会检索到内部工艺评审记录。在生成阶段，如果引用来源包含用户无权访问的内容，系统会直接拒绝并提示无权限。这个逻辑在最初设计时就考虑进去，避免后续返工。

权限体系还配合了一套数据更新的审核流程。知识库里的每份文档都标有责任人，更新时必须经过业务负责人审批，审批通过后新版文档进入知识库，旧版自动下线。这套流程保证了知识库内容的时效性和权威性，避免了老版本和新版本同时在库里的混乱局面。

5. 落地过程中的评测与调优：效果好不好，得靠评测集说话

5.1 评测集构建：业务人员参与是关键

搭建知识库的过程中，我们犯过一个典型错误，就是拿技术团队自己写的问题当评测标准。技术团队写的问题往往太“标准”，比如“卫生间防水施工工艺是什么”，而业务人员真实问法是“卫生间做完防水多久可以贴砖”“闭水试验楼下漏水怎么回事”。如果不贴近真实提问，评测结果会严重失真。

所以我们拉了三个人进评测集构建小组，一个是资深设计师，一个是项目经理，一个是客服主管。请他们每人提供 30 到 50 条真实工作中会问的问题，并且规定必须包含模糊提问、口语化提问、跨知识域提问，比如“客户说墙体开裂是不是质量有问题”这种既涉及工艺又涉及售后的坑爹问题。

评测集做完后，我们对每个问题标注了正确答案出处和回答要点。这份评测集不只是在项目期间用来调模型，上线后也持续运营，每隔两周加入新出现的问题类型，保证评测集始终能反映真实业务变化。

5.2 六个典型的失败案例与调整记录

第一个失败案例是切块边界破坏知识完整性。有一份关于“轻钢龙骨隔墙”的施工文档，按标题切分后，一个知识块里只包含了材料说明，施工步骤跑到了另一个知识块里，导致回答“轻钢龙骨隔墙怎么施工”时，检索到的块只有材料信息，回答自然不完整。后来我们调整了切分逻辑，让“材料说明 + 施工步骤 + 验收标准”尽量落在同一个大块里，跨块内容通过引用关系建立关联。

第二个失败案例是向量检索召回“看似相关实则无关”的内容。问“客厅瓷砖选什么颜色耐脏”，系统召回了一块讲“瓷砖硬度等级”的知识块，原因是“瓷砖”这个实体词的向量关联度太高。混检加元数据过滤后，这类偏差明显减少。

第三个失败案例是对流程类问题的回答混乱。项目经理问“水电验收要经过哪几个环节”，系统把不同环节的验收标准杂糅在一起，步骤顺序混乱。我们对流程类文档做了额外处理，在每个知识块内部保留了步骤编号和先后关系，提示词中也要求按步骤顺序输出。

第四个失败案例是表格类数据被切碎。报价表被分块后，同一个材料的单价和损耗率被拆到两个块里，回答“某地板每平多少钱”时，单价和损耗率对不上。通过表格结构化解析和强制字段对齐，这个问题从根上解决。

第五个失败案例是扫描件 OCR 错别字导致检索召回失败。老规范扫描件里的“腻子”被 OCR 识别成了“赋子”，关键词检索匹配不到。我们在解析流程里增加了纠错规则，结合装修行业术语表做自动纠错，并在索引时同义词字段补充常见错别字。

第六个失败案例是新员工提问太口语化。“墙皮铲不铲”这种问题，规范文档里写的是“原墙面铲除处理”，如果不做查询改写，检索召回率极低。查询改写模块上线后，这类问题才真正解决。

5.3 效果评估指标与观察周期

我们评估知识库效果，不只盯“大模型回答得好不好”，而是从三个层面对齐。第一层是检索命中率，看正确答案对应知识块是否出现在前 10 个召回结果里；第二层是生成准确率，由业务人员人工打分，判断答案是否准确、完整、直接；第三层是实际采纳率，统计设计师、项目经理、客服真正用这个系统搜索并采纳答案的次数。

上线第一个月，检索命中率在八成左右，生成准确率只有六成多，很大原因是测试问题和真实问题分布不一样。经过查询改写和重排序调优，两个月之后生成准确率提升到八成半。这个提升不是单点优化带来的，是数据清洗、切分策略、混检、重排序、提示词几方面共同作用的结果。

评测过程还让我们意识到一个真相：RAG 系统是一个整体，任何一个环节的短板都会在最终答案上体现出来。数据清洗马虎，后面再好的模型也救不回来；切分不合理，检索召回上限就直接被锁死。

6. 常见问题与排障速查：踩过的坑，写下来免得再踩

6.1 知识库日常运维常见问题速查表

系统上线后，我们在运维手册里整理了一份常见问题速查表，技术团队一碰到问题就能按图索骥。

问题一：检索结果里出现明显无关的内容。优先检查知识源头，看最近是否有新文档入库时元数据没写全；再检查查询改写是否正常工作，如果问句命中了错误的意图分类，检索范围就会跑偏。排查时直接在日志里查看过滤后的候选集，看是哪一层的过滤条件没生效。

问题二：回答内容正确但结构很乱，前后没有逻辑。先看召回的多个知识块是否被拼接在一起、知识块之间是否互相冲突。如果是，需要优化切分策略，或者调整生成提示词，要求模型优先按顺序组织步骤类的知识。

问题三：新更新的知识检索不到。大概率是更新流程没有走完，新版本文档已经入库，但旧版本还没有被标记下架，或者新文档的权限标签配置错误，导致部分用户无法召回。建议运维脚本里加一个待更新队列，入库后自动检查权限和更新状态。

问题四：某类问题回答准确率特别低。打开评测集，把这类问题单独拎出来看召回结果。如果召回的文档不是预期的那几份，说明这类问题的语义表达和知识块内容之间的向量距离没有对齐，需要补充领域术语增强，或者调整查询改写规则。

问题五：系统回答变慢。优先检查图谱和索引层是否有积压任务，再看检索链路中候选集数量是否因为知识库扩张而膨胀。我们后来把向量库的索引参数做了分组优化，检索延迟又降了差不多两成。

6.2 一些关于落地路线图的真实建议

如果让我重新做一遍这个项目，有些决定会调整，但整体路线不变。在项目启动阶段，先用两周时间做知识盘点，产出知识地图，确保需求、数据源和技术选型对齐，这一步不能省。在产品设计上，优先保证“答案可溯源”，用户看到引用来源才敢相信系统，这比任何花哨功能都重要。在技术选型上，尽量克制，能用简单方案解决的事不引入复杂组件，团队维护压力会小很多。

个人体会最深的一点是，企业级 RAG 知识库不是“一次性建设”，而是一个需要持续运营的内容系统。知识更新了、组织架构调整了、业务方向变化了，知识库都要跟着维护。我们为此专门在制度上给每个知识域定了责任人，并安排了每个月的知识内容更新评审会。

6.3 从项目完成到真正的日常使用

最后分享一个容易被忽略的环节——推广使用的体验优化。系统做得再好，如果业务人员用起来不顺手，最后还是会被丢到角落里。我们把问答界面嵌到了公司内部办公平台里，设置了两个入口：一个是统一搜索框，支持直接输入问题；另一个是在项目资料详情页增加“AI 助手”按钮，当设计师打开某个项目时，一键就能基于当前项目上下文提问，比如“这个户型的厨房改造要注意什么”，系统会自动带上项目信息，去掉指定也能命中正确的知识范围。

上线半年后，我们统计了使用数据，知识库日均被查询 300 多次，其中约一半来自客服和项目经理，设计师的使用比例也在稳步上升。最有说服力的一幕是，一位刚入职不久的新设计师，在群里说“我在知识库查到一线工人对某型号瓷砖的铺贴反馈”，那一刻我就觉得这个项目真正扎下根了。没有惊心动魄的技术突破，但一个内部系统能被人长期主动使用，就是对项目最大的认可。