企业官网建设流程全解析

1. 为什么我要做这个专栏：从三次翻车说起

去年秋天，我帮一个做工业设备维保的团队搭知识库问答系统。他们的需求听起来特别朴素：把三千多份PDF格式的检修手册、故障代码表和工单记录灌进去，让一线工程师用自然语言提问，系统给出准确答案。我当时的反应是"这不就是RAG的经典场景吗"，拍着胸脯说两周交付。

结果第一版上线当天就翻车了。工程师问"3号压缩机报E047怎么处理"，系统检索出来的却是"E047传感器更换步骤"——答案本身没错，但那是另一台型号的设备。问题出在切块策略上：我把所有PDF按固定500字符切分，导致设备型号这个关键上下文被切到了相邻块里。这是第一次翻车，教会我一个道理：RAG的瓶颈从来不在模型，而在数据进入向量库之前的那段路。

第二次翻车是在评测环节。我自认为检索效果不错，随手抽了二十个问题测了一下，命中率挺高，就交付了。客户用了两周后反馈"越用越不准"。我回去一查，发现我测的全是"手册里能直接搜到原句"的问题，而真实用户的提问方式是口语化的、带错别字的、甚至隐含了多轮上下文的。我的评测集和真实分布完全脱节。这是第二次翻车，让我意识到没有科学评测的RAG项目，等于闭着眼睛开车。

第三次翻车最有意思。客户后来提出要支持图片——他们的手册里有大量电路图和爆炸图，工程师希望能"拍一张设备照片，问这是哪个部件"。我一开始想当然地以为向量库只能存文本，差点建议客户放弃这个需求。后来深入研究才发现，多模态检索这条路早就通了，只是我自己的知识停留在纯文本时代。这是第三次翻车，也是促使我系统梳理整个RAG技术栈的直接原因。

这三次翻车经历，基本覆盖了RAG落地过程中最容易踩的坑：数据预处理、检索评测、多模态扩展。市面上讲RAG的文章不少，但大多停留在"调个LangChain、接个向量库、跑通Demo"的层面，真正讲清楚"为什么这么设计""哪里会出问题""怎么评测"的内容很少。这就是我做《RAG进阶实战》这个专栏的初衷——不写入门科普，只写那些真正落地过、踩过坑、验证过的经验。

这个专栏适合三类人：一是已经跑通过RAG Demo、但效果不稳定的开发者；二是正在做企业级知识库、需要系统方法论的技术负责人；三是对RAG架构设计、评测体系、多模态扩展感兴趣，想少走弯路的从业者。如果你还在纠结"什么是向量数据库"，那这个专栏可能偏深了；但如果你已经在问"为什么我的召回率上不去"，那这里的内容应该对你有用。

2. 专栏的整体架构设计：从MVP到生产级的四层递进

2.1 为什么不做"从零到一"的线性教程

我见过太多RAG教程是按"安装依赖→加载文档→切块→嵌入→检索→生成"这条线走的。这条线本身没错，但它有个致命问题：它假设每一步都是独立的、线性的、一次做对的。而真实的RAG项目是高度耦合的——切块策略会影响检索效果，检索效果会影响评测指标，评测指标又会反过来指导切块策略的调整。你不可能"先做完切块再想检索"。

所以这个专栏的架构不是线性的，而是分层递进的。每一层解决一类核心问题，层与层之间有明确的依赖关系，但同一层内部的各个技术点是可以并行探索的。具体分四层：

这个分层的好处是：你可以根据自己项目的成熟度，直接跳到对应的层级。如果你的Demo已经跑通但效果差，直接从第二层开始看；如果你连数据怎么切都没想清楚，那就从第一层老老实实做起。

2.2 MVP框架的边界：什么该做，什么坚决不做

热词里出现了"mvp框架"，这个词在RAG语境下特别值得聊。我的观点很明确：RAG的MVP不是"功能最少"，而是"验证核心假设的最小闭环"。

很多团队做MVP时容易走两个极端。一个极端是"什么都做"——上来就搞多路召回、重排、知识图谱、Agent编排，结果三个月过去了还没上线。另一个极端是"什么都不做"——直接拿LangChain的默认配置跑一遍，发现效果不行就断定"RAG不靠谱"。

我定义的RAG MVP应该包含且仅包含以下要素：

• 一个真实的数据源：不要用网上的公开数据集，用你自己业务里最典型的100份文档。因为公开数据集的分布和你的业务分布完全不同，测出来的效果没有参考价值。
• 一套可解释的切块策略：能说清楚"为什么这么切"，而不是"默认参数就是这样"。
• 一个基础检索链路：向量检索即可，先不上混合检索和重排。
• 一个最小评测集：50到100个真实问题，带标准答案，能算出召回率和准确率。
• 一个明确的失败案例库：把检索错的、答偏的案例记下来，这是后续优化的金矿。

MVP阶段坚决不做的事情：不做多轮对话、不做权限管理、不做前端界面美化、不做多模态。这些不是不重要，而是它们会分散你对核心假设的注意力。RAG的核心假设只有一个：你的文档里确实有答案，且向量检索能找到它。如果这个假设不成立，后面做再多都是白搭。

2.3 专栏的更新节奏与配套资源

这个专栏我计划按"每两周一个深度主题"的节奏更新，每个主题配一篇主文加若干补充笔记。主文讲透原理和设计决策，补充笔记记录实操中的具体命令、参数和踩坑记录。

配套资源方面，我会提供三样东西：一是可复现的评测集模板，包含问题设计规范、标注格式和指标计算脚本；二是切块策略对照表，把常见的几种切块方式在不同文档类型上的表现列出来；三是架构决策记录模板，帮你在团队内部把"为什么选这个方案"讲清楚。这些东西不会直接给答案，而是给你一个思考框架，让你能根据自己的业务场景做判断。

3. 数据层：切块、元数据与知识库类型的选型逻辑

3.1 切块策略不是调参，是信息架构设计

回到我开头说的第一次翻车。固定500字符切块为什么失败？因为它假设"信息是均匀分布的"，而真实文档的信息密度是极不均匀的。一份检修手册里，"安全警告"可能占了大段篇幅但信息量很低，"故障代码对照表"可能只有几行但每个字都关键。

我现在用的切块策略是语义切块加结构切块混合。具体做法是：先用文档的天然结构（标题、章节、表格边界）做粗切，保证每个块不跨越逻辑边界；然后在粗切的基础上，用嵌入模型计算相邻句子的语义相似度，在相似度骤降的地方做细切。这样切出来的块，既保留了结构完整性，又避免了"一句话被切成两半"的问题。

这里有个实操细节：切块大小不要追求统一。技术手册的表格块可能只有100字符，而叙述性章节的块可能有800字符。关键是每个块要能独立回答一个问题。你可以用这个标准来检验：把切出来的块单独拿给一个没看过原文的人，他能不能理解这个块在说什么？如果不能，说明这个块缺上下文，需要合并或补充元数据。

3.2 元数据设计：被严重低估的检索增强手段

大多数人做RAG时，元数据只存个"来源文件名"。这是巨大的浪费。元数据在检索阶段可以发挥的作用，远超你的想象。

我现在的元数据方案包含四类字段：

• 来源标识：文件名、页码、章节路径。用于答案溯源，让用户知道答案从哪来。
• 业务标签：设备型号、文档类型、生效日期、版本号。用于检索时的硬过滤。比如用户问"3号压缩机"，我可以在检索前先过滤出"设备型号=3号"的块，把检索范围缩小80%。
• 语义标签：文档主题、关键实体、内容类型（步骤/警告/参数表）。用于重排时的加权。比如用户问"怎么处理"，步骤类内容的权重就应该调高。
• 质量标签：文档置信度、最后审核日期、是否过期。用于过滤低质量内容。

这套元数据方案的关键在于：它把一部分"语义理解"的工作前置到了数据层。与其让向量检索去猜"这个块是不是关于3号压缩机的"，不如直接在元数据里标好，检索时直接过滤。这比任何重排模型都可靠。

3.3 RAG知识库、KG知识库与结构化知识库的边界

热词里有个很好的问题："kg知识库、rag知识库和结构知识库区分以及应用场景"。这个问题我在实际项目中反复被问到，这里给出我的判断框架。

RAG知识库的本质是"非结构化文本的语义检索"。它擅长处理叙述性、解释性、步骤性的内容。比如"这个故障怎么排查""这个参数是什么意思"。它的弱点是：不擅长精确的数值计算、不擅长多跳推理、不擅长处理强结构化关系。

KG知识库（知识图谱）的本质是"实体和关系的精确表示"。它擅长处理"谁是谁的上级""哪个部件属于哪个系统""A故障会导致B故障"这类关系型问题。它的弱点是：构建成本极高，且难以覆盖长尾知识。

结构化知识库（比如SQL数据库、Excel表）的本质是"精确的字段查询"。它擅长处理"上个月故障率最高的设备是哪台"这类聚合统计问题。

我的建议是：不要试图用一种知识库解决所有问题。一个成熟的系统往往是三者组合：RAG负责回答"怎么做"，KG负责回答"是什么关系"，结构化库负责回答"是多少"。专栏的第6章会详细讲这三种知识库的融合架构，包括怎么让RAG的检索结果去KG里做关系补全，怎么让结构化查询的结果作为RAG的上下文。

3.4 图片存储：RAG知识库到底能不能存图

热词里"rag知识库能存储图片嘛"这个问题，答案是：能，但存法和你想的不一样。

向量库本身存的是向量，不是原始文件。图片要进RAG，有三条路：

第一条是图片描述法：用多模态模型给每张图生成一段文字描述，把描述文本嵌入向量库。检索时匹配描述，返回原图。这条路成本低，但描述质量决定了检索上限。

第二条是多模态嵌入法：用CLIP这类模型直接把图片编码成向量，和文本向量放在同一个空间里。检索时可以用文字搜图，也可以用图搜图。这条路效果好，但对向量库有要求，且需要处理文本和图片向量的对齐问题。

第三条是图文绑定法：把图片和它周围的文本作为一个整体块处理，图片本身不单独嵌入，但检索到文本块时把图片一起返回。这条路最简单，适合图片只是辅助说明的场景。

我在工业手册场景里用的是第三条加第一条的组合：图片和它的图注、上下文一起切块，同时用多模态模型生成一段描述作为补充元数据。这样既保证了图文不分离，又让图片内容可以被文字检索到。

4. 检索层：混合检索、重排与那些"看起来很美"的陷阱

4.1 纯向量检索的天花板在哪里

向量检索的核心优势是"语义匹配"——用户问"设备发烫怎么办"，能匹配到"温度过高处理流程"，即使两者没有一个字相同。这个能力确实强大，但它有个明确的天花板：对精确匹配和长尾实体的无力。

我做过一个测试：在三千份文档里搜"E047"这个故障代码。纯向量检索的召回率只有60%左右，因为"E047"这种无意义字符串在嵌入空间里没有稳定的语义表示，不同模型编码出来的向量差异很大。而加上BM25关键词检索后，召回率直接拉到95%以上。

这就是为什么我现在默认用混合检索：向量检索负责语义召回，BM25负责精确召回，两路结果用RRF（倒数排名融合）合并。RRF的好处是不需要调权重，对两路检索的分数尺度不敏感，特别适合快速上线。

4.2 重排模型：什么时候值得上，什么时候是浪费

重排（Rerank）是RAG进阶的标配，但我要泼一盆冷水：不是所有场景都值得上重排。

重排的本质是用一个更贵的模型，对初步召回的Top-K结果做精细排序。它的收益取决于两个条件：一是初步召回的Top-K里确实包含正确答案（召回率够高），二是正确答案的排名不够靠前（排序有问题）。如果初步召回根本没召回正确答案，重排再强也没用；如果初步召回的Top-3已经全是正确答案，重排就是浪费算力。

我的经验法则是：先测召回率，再决定要不要重排。如果Top-20召回率低于80%，优先优化切块和检索策略，别急着上重排。如果Top-20召回率超过90%但Top-3准确率低，那重排的收益就很大。

重排模型的选择上，我实测下来，小模型（如bge-reranker-base）在大多数场景下已经够用，大模型（如bge-reranker-large）的边际收益有限，但延迟增加明显。如果你的QPS要求高，建议先用小模型，把省下来的算力用在更好的切块上。

4.3 检索瓶颈的三种典型症状与对应解法

热词里"rag瓶颈"这个词很值得展开。我把常见的检索瓶颈归纳为三种症状，每种对应不同的解法：

症状一：答案在库里，但就是搜不出来。这是召回问题。解法优先级：优化切块（让答案块更完整）> 补充元数据过滤（缩小检索范围）> 增加检索路数（混合检索）> 换嵌入模型。

症状二：搜出来了，但排不到前面。这是排序问题。解法优先级：加重排模型 > 调整元数据权重 > 优化查询改写。

症状三：搜出来的都对，但拼在一起答非所问。这是生成问题，不是检索问题。解法：优化Prompt模板、控制上下文长度、增加答案引用约束。

这三种症状的排查顺序不能乱。很多人一上来就换嵌入模型，其实大部分时候问题出在切块上。我的建议是：每次只改一个变量，改完立刻用评测集验证。否则你永远不知道是哪个改动起了作用。

4.4 查询改写：一个被低估的免费提升手段

在检索之前加一步查询改写，是我实测下来投入产出比最高的优化手段之一。具体做法是：用户输入原始问题后，先用一个小模型把它改写成更适合检索的形式。

改写策略包括：去口语化（"这玩意儿咋整"改成"如何处理"）、补全上下文（多轮对话中把"它"替换成具体实体）、扩展同义词（"发烫"扩展为"发烫 过热 温度过高"）、拆解复合问题（"A和B有什么区别"拆成两个独立查询）。

这一步的成本很低——一个小模型跑一次改写，延迟增加不到100毫秒。但效果提升很明显，我在几个项目里实测，查询改写能让Top-5准确率提升10到15个百分点。而且它和切块、重排是正交的，可以叠加使用。

5. 评测层：没有评测集的RAG项目等于裸奔

5.1 评测集构建：从真实问题出发，而不是从文档出发

热词里"agent评测集构建"是个好切入点。我见过太多团队构建评测集的方式是：打开文档，找一段话，根据这段话编一个问题。这种方式构建出来的评测集，测的是"检索系统能不能找到这段话"，而不是"系统能不能回答用户的真实问题"。

正确的做法是从真实问题出发。具体步骤：

1. 收集真实问题：从客服记录、工单系统、用户群聊里捞至少200个真实提问。这些问题的价值在于它们的分布是真实的——有口语化的、有带错别字的、有隐含上下文的。
2. 标注标准答案：对每个问题，人工标注它应该匹配哪些文档块，以及最终答案应该是什么。这一步最耗时，但绝对不能省。
3. 分层抽样：把问题按难度分层——简单（直接匹配）、中等（需要语义理解）、困难（需要多跳推理）。评测集里三层的比例应该和真实分布一致。
4. 定期更新：业务在变，用户问题也在变。我建议每季度更新一次评测集，把新出现的典型问题加进去。

评测集的规模不需要很大，100到200个高质量问题就足够指导优化方向了。关键是质量，不是数量。

5.2 指标选择：召回率、准确率、MRR到底看哪个

评测指标的选择取决于你当前优化的阶段。我的建议是分阶段看不同指标：

这里特别说一下MRR（平均倒数排名）。这个指标衡量的是"正确答案的平均排名"，对排序优化特别敏感。如果你的Top-5准确率不错但MRR很低，说明正确答案虽然在前五里，但排名靠后，这时候上重排的收益就很大。

还有一个容易被忽略的指标是引用准确率：系统给出的答案，是否真的来自它引用的文档块。这个指标在合规要求高的场景里特别重要。我见过系统答对了但引用错了的情况，这在医疗、法律场景里是致命的。

5.3 评测自动化：怎么让评测跑起来不费人

人工评测准确但不可持续。我的做法是分层自动化：

• 召回率评测全自动：因为标准答案是"应该匹配哪些块"，这是确定性的，脚本可以直接算。
• 答案准确率半自动：用一个大模型做裁判，判断生成的答案和标准答案是否语义一致。裁判模型会有误差，但可以通过人工抽检校准。
• 引用准确率全自动：检查答案里的引用标记是否真的指向了检索到的块，这是确定性的。

这套自动化评测跑一次全量评测集大概需要十几分钟，成本可以接受。关键是它能让你在每次改动后立刻看到指标变化，形成"改动→评测→决策"的快速闭环。

5.4 那些评测中的反直觉发现

做评测多了，会遇到一些反直觉的现象。分享三个我印象最深的：

发现一：增加检索块数量不一定提升效果。我一度以为Top-10比Top-5好，因为召回率更高。但实测发现，当Top-10里混入太多不相关块时，生成模型反而容易被干扰，答案准确率下降。现在我的默认配置是Top-5检索加Top-3重排。

发现二：更贵的嵌入模型不一定更好。我在一个中文工业文档场景里对比过几个嵌入模型，结果一个中等规模的模型在领域内表现最好，因为它的训练数据里工业语料占比更高。模型选型要看领域匹配度，不是看排行榜。

发现三：评测集里的"简单问题"最有价值。我一开始觉得简单问题测不出东西，后来发现简单问题的失败往往暴露的是最基础的工程问题——切块切错了、元数据标错了、检索路数配错了。把简单问题全部答对，系统的基础就稳了。

6. 扩展层：多模态、知识图谱与Agent编排的融合路径

6.1 多模态RAG：图片检索的三种落地形态

第3章讲了图片怎么存，这里讲图片怎么用。多模态RAG在实际项目里有三种落地形态：

形态一：图作为答案。用户问"这个部件长什么样"，系统检索到相关文本块，返回关联的图片。这种形态最简单，本质还是文本检索，图片只是附加输出。

形态二：图作为查询。用户拍一张设备照片，系统检索出这个设备的名称、型号、相关文档。这种形态需要图片嵌入模型，把图片编码成向量去检索文本向量库。技术难点在于图文向量的对齐。

形态三：图作为推理依据。用户问"这个电路图里哪个是保险丝"，系统需要理解图片内容并定位。这种形态需要多模态大模型参与，成本最高，但能力最强。

我的建议是：从形态一开始，验证需求真实性后再往上升级。很多团队一上来就想做形态三，结果发现用户根本不需要那么复杂的功能。

6.2 Ontology RAG：知识图谱不是替代RAG，是补全RAG

热词里"ontology rag"是个前沿方向。我的理解是：Ontology RAG的核心思想是用本体（Ontology）来约束和增强检索。

传统RAG的检索是"扁平"的——所有块都在同一个向量空间里，靠相似度排序。而Ontology RAG会先定义领域本体（比如"设备-部件-故障-处理方案"这套关系），然后把文档块映射到本体上。检索时，系统不仅看语义相似度，还看本体上的关系路径。

举个例子：用户问"3号压缩机的E047故障怎么处理"。传统RAG可能检索到"E047故障处理"这个块，但不知道它属于哪台设备。Ontology RAG会沿着"3号压缩机→属于→某型号→有故障→E047→处理方案"这条路径检索，保证答案的设备上下文正确。

这条路的效果确实好，但构建成本高。我的建议是：在领域关系特别重要、且文档量足够大的场景下才考虑。小规模场景用元数据过滤就能达到类似效果。

6.3 Agent编排：RAG从"问答"到"做事"的跨越

热词里"rag智能体"和"agent评测集构建"都指向同一个趋势：RAG正在从"检索加生成"的固定流程，演化为"Agent自主编排"的灵活流程。

传统RAG的流程是固定的：检索→重排→生成。而Agent RAG的流程是动态的：Agent根据问题决定要不要检索、检索几次、要不要调用工具、要不要追问用户。

这个跨越的价值在于：它能处理传统RAG处理不了的复杂任务。比如"帮我对比3号机和4号机的故障率，并给出维护建议"，传统RAG只能检索到两段文本然后拼在一起，而Agent RAG可以分别查询两台设备的故障记录、调用统计工具计算故障率、再生成对比建议。

但Agent编排也带来了新的评测难题：流程不固定，怎么评测？我的做法是评测最终结果，不评测中间步骤。只要最终答案正确、引用准确、延迟可接受，中间走了几步不重要。当然，对于关键步骤（比如工具调用），还是要单独监控成功率。

6.4 本地化部署：Mac上搭建RAG知识库的实操要点

热词里"怎么在mac上搭建rag知识库"和"有没有本地的rag文本拆解工具"反映了很强的本地化需求。我自己的开发环境就是Mac，这里分享几个实操要点。

向量库选择：本地开发推荐Chroma或Qdrant的本地模式，安装简单，Python API友好。数据量超过百万级再考虑Milvus。

嵌入模型：本地跑嵌入模型推荐用Ollama加载，Mac的Metal加速对中小模型支持很好。如果追求效果，可以用API调用，但要注意数据合规。

文本拆解工具：本地拆PDF推荐PyMuPDF，速度快、对表格支持好。拆Word用python-docx。拆HTML用BeautifulSoup。这些工具都是纯Python，Mac上装起来没坑。

一个容易忽略的点：Mac的文件系统对大小写不敏感，而很多向量库的集合名是大小写敏感的。我在本地测试时用"Docs"建集合，部署到Linux服务器上用"docs"查，结果查不到。这种坑在本地开发时很难发现，建议从一开始就统一用小写命名。

7. 我在专栏策划中想清楚的三件事

第一件事：专栏的价值不在于覆盖多少技术点，而在于讲清楚多少个"为什么"。RAG的技术栈更新很快，今天讲LangChain，明天可能就有新框架。但"为什么这么切块""为什么要评测""为什么混合检索有效"这些底层逻辑是稳定的。我宁愿少讲几个工具，也要把每个决策背后的逻辑讲透。

第二件事：实战经验必须包含失败案例。我翻过很多RAG教程，几乎全是"这样做就对了"，很少有人讲"我这样做错了，错在哪"。但恰恰是失败案例最有价值，因为它能帮你避开同样的坑。这个专栏里我会尽量多分享翻车经历，包括那些最后没解决的难题。

第三件事：评测要贯穿始终，而不是最后补。我见过太多项目把评测当成验收环节，结果发现效果不行时已经来不及改了。正确的做法是：从MVP阶段就建评测集，每次改动都跑评测，让数据驱动决策。这个专栏会把评测作为一条主线，贯穿数据层、检索层、扩展层的每一个环节。

最后分享一个我在策划过程中反复提醒自己的原则：不要为了显得专业而堆砌术语。RAG领域的新词很多——混合检索、重排、Ontology、Agent编排——但术语本身不创造价值，解决问题才创造价值。如果一段内容不能用大白话讲清楚，那说明我自己还没想明白。这个专栏的每一篇，我都会用"能不能讲给一个刚入行的同事听懂"来检验自己。