企业官网建设流程全解析

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

去年秋天，我帮一个做工业设备维保的团队搭知识库问答系统。他们的需求听起来特别朴素：把三千多份PDF格式的检修手册、故障案例、备件清单灌进去，让一线工程师用自然语言提问，系统给出准确答案和出处。我当时信心满满，觉得RAG嘛，LangChain加个向量库，两天就能跑通Demo。结果第一版上线当天就被打脸——工程师问"3号机组液压泵异响怎么处理"，系统返回的是一段关于"液压泵安装扭矩"的段落，出处标注还是另一台设备的章节。召回率看着有七成，但真正能用的答案不到三成。

那次之后我意识到，RAG这个东西，Demo和产品之间隔着一整个太平洋。后来我又陆续参与了两个项目：一个是给律所做合同条款检索，一个是给电商团队做售后话术库。三次下来，踩的坑几乎不重样——切分策略、Embedding选型、检索重排、评测缺失、知识库更新机制，每一个环节都能让系统从"看起来能用"变成"实际不能用"。

这个专栏就是把这些年我在RAG实战里摔过的跤、验证过的方案、以及那些文档里不会写的经验，系统地整理出来。它不是一篇入门科普，也不是框架API的搬运工。我想聊的是：当你手里有一个真实业务场景，怎么从零设计一套能扛住评测、能持续迭代的RAG架构。适合已经跑通过Demo、但卡在"效果上不去"阶段的开发者，也适合正在做技术选型、需要判断自研还是用现成方案的架构师。关键词里的RAG、架构设计、自研、MVP、评测，会贯穿整个专栏的每一条主线。

2. 专栏要解决的核心问题：RAG的瓶颈到底在哪

2.1 大多数RAG项目死在哪一步

我观察过一个现象：网上关于RAG的教程，百分之八十的篇幅花在"怎么把文档灌进向量库"和"怎么调LangChain的链"上，但真实项目里，这两步恰恰是最不容易出问题的。真正让项目翻车的，往往是后面那些没人讲的环节。

拿我那个工业维保项目举例。第一版用的是最朴素的固定长度切分，512个字符一刀切。问题出在检修手册的结构上——很多故障处理步骤是跨段落甚至跨页的，一刀切下去，步骤三和步骤四被切到两个chunk里，检索时只召回其中一个，答案自然残缺。后来改成按标题层级切分，再对超长段落做语义切分，召回质量立刻上了一个台阶。这个改动没有任何框架层面的黑科技，纯粹是对业务文档结构的理解。

再比如Embedding模型的选择。很多人默认用OpenAI的text-embedding-ada-002，但在中文专业领域，尤其是工业术语密集的场景，它的表现并不理想。我实测过几个中文优化的模型，在同样的测试集上，Top-5召回率能差出十五个百分点。这个差距在Demo阶段看不出来，因为Demo的query都是你精心设计的；但真实用户的提问方式千奇百怪，差距就会被放大。

2.2 评测缺失是最大的隐形杀手

如果说只能给RAG项目提一条建议，我会说：先建评测集，再写代码。听起来反直觉，但这是我三次项目里最深刻的教训。

没有评测集的时候，你改一个参数、换一个模型，根本不知道是变好了还是变坏了。只能靠"感觉"——找几个问题试试，觉得答案还行，就上线了。这种"感觉驱动"的迭代方式，在项目初期还能凑合，一旦知识库规模上去、query分布变复杂，就完全失控了。

我在律所那个项目里吃过这个亏。当时团队花了大量时间优化检索策略，但因为没有评测集，每次改动都是"这个case好像好了一点，那个case好像差了一点"，折腾了两周，整体效果原地踏步。后来我们花三天时间，从真实用户日志里抽了200条query，人工标注了标准答案和应召回的文档片段，建了一个最小可用的评测集。有了它之后，迭代效率完全不一样了——每次改动跑一遍评测，指标涨了还是跌了一目了然，两周内把Top-5召回率从六成出头提到了八成五。

这个专栏会把评测集的构建方法作为重点来讲，包括怎么从日志里挖query、怎么标注、怎么设计指标、怎么避免评测集过拟合。这些内容在关键词里对应的是"评测"和"agent评测集构建"，但我会讲得更具体、更可操作。

2.3 自研还是用现成方案：一个被低估的决策

关键词里有"自研"和"MVP"，这其实是一个很现实的决策问题。市面上有太多开箱即用的RAG平台，从LangChain到各种低代码工具，看起来都能快速搭起来。但我在实际项目里的体会是：MVP阶段可以用现成方案快速验证，但一旦进入生产迭代，自研核心链路几乎是必然选择。

原因不复杂。现成方案为了通用性，把很多环节封装成了黑盒。你不知道它怎么切分、怎么检索、怎么重排，出了问题只能干瞪眼。而RAG的效果恰恰高度依赖这些细节——你的文档结构、你的query分布、你的业务术语，都需要针对性地调整。黑盒方案给不了你这个灵活性。

我在电商售后那个项目里，一开始用的是某个开源RAG框架的默认链路，效果一直卡在及格线。后来把检索和重排两个环节拆出来自己实现，只用了不到一周，准确率就提了二十多个百分点。核心改动其实很简单：把默认的向量相似度检索换成了"向量召回+关键词召回"的混合策略，再加了一个轻量的重排模型。这些改动在框架里也能做，但你需要深入理解框架的内部机制才能改对，那还不如自己写。

专栏会专门用一个章节讲自研RAG的架构设计，包括哪些环节值得自研、哪些可以用现成组件、怎么设计模块边界让系统可替换可迭代。这不是鼓吹"什么都自己写"，而是帮你建立一套判断标准。

3. 专栏内容架构：从MVP到生产级的完整路径

3.1 模块划分与学习路径

整个专栏我打算按"从能跑到好用"的逻辑来组织，大致分五个模块，每个模块对应RAG系统的一个关键环节。不是那种"第一章介绍RAG是什么"的教科书式结构，而是直接切入实战问题。

第一个模块讲知识库构建，核心是文档解析和切分策略。这部分会覆盖PDF、Word、HTML、Markdown等常见格式的处理，重点讲怎么根据文档结构设计切分规则，而不是无脑按字数切。还会聊到图片和表格的处理——关键词里有人问"rag知识库能存储图片嘛"，答案是能，但怎么存、怎么检索、怎么和文本关联，这里面有很多细节。

第二个模块讲检索与召回，这是RAG效果的分水岭。会详细对比向量检索、关键词检索、混合检索的适用场景，讲Embedding模型的选型方法，讲怎么用重排模型提升Top-K精度。关键词里的"rag检索增强"和"rag瓶颈"主要对应这个模块。

第三个模块讲生成与答案组织，包括Prompt设计、上下文窗口管理、引用标注、幻觉抑制。这部分很多人觉得简单，但实际上，同样的检索结果，不同的Prompt组织方式，答案质量能差出一大截。

第四个模块讲评测与迭代，这是我认为整个专栏最有价值的部分。会讲怎么从零建评测集、怎么设计指标、怎么做A/B测试、怎么定位badcase的根因。关键词里的"agent评测集构建"和"评测"会在这里展开。

第五个模块讲架构设计与工程化，包括自研vs现成的决策、模块边界设计、知识库更新机制、性能优化、成本控制。关键词里的"架构设计"、"自研"、"MVP"主要落在这里。

3.2 每个模块的交付物

我不想把这个专栏做成"读完就忘"的科普。每个模块我都会配一个可运行的代码示例，基于一个统一的业务场景——就用我那个工业维保的案例，脱敏之后作为贯穿始终的示例。这样你学完一个模块，就能直接在自己的项目里复现。

比如知识库构建模块，我会给一个完整的文档处理pipeline，从PDF解析到切分到入库，代码可以直接跑。检索模块会给一个混合检索的实现，包含向量召回、BM25召回和重排的完整链路。评测模块会给一个评测框架，你只需要准备自己的query和标注数据，就能跑出指标。

这些代码不会依赖某个特定框架的魔法，核心逻辑都是显式写出来的，方便你理解和修改。关键词里的"langchain4j easy rag"和"ollama + 简易本地rag知识库"我也会涉及，但定位是"作为对比方案"，而不是"唯一正确答案"。

4. 关键技术选型：那些我踩过坑才明白的事

4.1 切分策略：别让固定长度毁掉你的知识库

切分是RAG里最被低估的环节。大多数人直接用框架的默认切分器，按字符数或token数一刀切，然后就不管了。但切分质量直接决定了检索的上限——切得不好，再好的Embedding和重排也救不回来。

我在工业维保项目里的做法是这样的：先按文档的标题层级做一级切分，把每个章节独立出来；然后对超长的章节，按段落做二级切分，但保留段落之间的重叠；最后对特别短的段落，向上合并到相邻段落，避免产生大量无意义的碎片。这套规则听起来简单，但需要你对业务文档的结构有深入理解。

还有一个细节：切分时要保留元数据。每个chunk除了文本内容，还要带上它所属的章节标题、文档来源、页码、甚至表格的列名。这些元数据在检索时可以用来过滤，在生成时可以用来标注引用。我见过太多项目，chunk里只有纯文本，检索出来根本不知道出自哪里，用户一看就不信任。

关键词里有人问"有没有本地的rag文本拆解工具"，我的建议是：工具可以用，但切分规则一定要自己定。通用工具能帮你处理格式解析，但切分策略必须结合你的文档结构来设计。专栏里我会给一个基于规则的切分器实现，你可以直接改成适合自己文档的版本。

4.2 Embedding选型：中文场景下的实测对比

Embedding模型的选择，直接决定了向量检索的质量。我在三个项目里实测过多个模型，这里分享一些结论。

在中文通用场景下，BGE系列和M3E系列的表现都比较稳。但在专业领域，比如工业术语、法律条文、医疗术语密集的场景，通用模型的优势就不明显了。我试过用领域数据对BGE做微调，在工业维保的测试集上，Top-5召回率比原版提升了大约八个百分点。微调的成本没有想象中高，几千条领域语料就能看到效果。

另一个容易被忽略的点是向量维度。高维向量检索精度更高，但存储和计算成本也更高。我在电商项目里做过对比，768维和1024维在最终效果上的差距不到三个百分点，但存储成本差了近一倍。对于知识库规模在十万级chunk以内的项目，768维通常够用；超过百万级，才需要认真考虑维度带来的成本问题。

还有一点：Embedding模型要和检索方式匹配。如果你用的是混合检索，向量召回只是其中一路，那Embedding模型的绝对精度就没那么关键，更重要的是它和关键词召回的互补性。这个思路在专栏的检索模块会详细展开。

4.3 重排模型：小投入大回报的环节

如果只能在一个环节投入优化资源，我会选重排。原因很简单：向量召回是粗筛，重排是精排，精排的质量直接决定了最终给到生成模型的上下文质量。

我常用的重排方案有两种：一种是基于Cross-Encoder的重排模型，比如BGE-Reranker系列，精度高但速度慢；另一种是基于LLM的重排，用Prompt让模型对候选文档打分，灵活但成本高。实际项目里，我通常先用Cross-Encoder做第一轮重排，把Top-50压到Top-10，如果对精度要求极高，再用LLM做第二轮精排。

重排带来的提升是立竿见影的。在律所项目里，加了重排之后，Top-3准确率从五成出头提到了七成五。这个提升幅度，比换Embedding模型或者调切分参数都来得大。而且重排模型的部署成本不高，一个中等规模的模型就能跑出不错的效果。

关键词里的"rag框架"和"rag实战"在重排这部分会有大量实操内容，包括怎么训练自己的重排模型、怎么评估重排效果、怎么平衡精度和延迟。

5. 评测体系：让RAG迭代从玄学变成工程

5.1 评测集怎么建：从日志里挖金矿

评测集是RAG迭代的指南针。没有它，所有的优化都是盲人摸象。但很多人不知道评测集怎么建，觉得要人工造几百条query太费劲。其实有更高效的方法。

我的做法是：从真实用户日志里挖query。系统上线初期，哪怕效果不好，也会有用户试用。把他们的提问记录下来，去掉重复和无效的，剩下的就是最真实的评测素材。这些query的分布，比你自己拍脑袋想的要准确得多。

有了query之后，需要标注两部分：一是标准答案，二是应该召回的文档片段。标准答案可以由业务专家来写，也可以从现有文档里摘取。应召回的片段标注更关键，因为它直接决定了召回率指标的计算。我通常会让标注人员标出所有相关的片段，而不只是最相关的那一个，这样能更全面地评估召回质量。

评测集的规模不需要很大。我的经验是，200到500条query就能覆盖大部分场景，关键是query的多样性和代表性。太少会过拟合，太多则标注成本太高。专栏里会给一个评测集构建的完整流程，包括query采样、标注规范、质量校验。

5.2 指标设计：召回率之外还要看什么

召回率是最常用的指标，但它不是全部。我在实际项目里会同时看几个指标：

这几个指标要结合起来看。比如召回率高但答案准确率低，说明问题出在生成环节；召回率低但答案准确率高，可能是评测集太简单。我在电商项目里就遇到过这种情况：召回率看着不错，但用户满意度很低，后来发现是引用标注经常出错，用户看到出处不对就不信任答案了。

关键词里的"agent评测集构建"和"评测"在这个章节会展开讲，包括怎么设计自动化评测流程、怎么用LLM做辅助标注、怎么避免评测集过拟合。

5.3 Badcase分析：定位问题的根因

评测跑完之后，最重要的是分析badcase。我通常会按错误类型分类：是没召回、召回了但排序不对、还是召回了也排序对了但生成错了。不同类型的错误，修复方向完全不同。

没召回的情况，要检查切分是否合理、Embedding是否适合领域、query和文档的表述差异是否太大。召回了但排序不对，要检查重排模型是否有效、是否需要加入关键词召回。生成错了，要检查Prompt是否清晰、上下文是否太长导致模型迷失、是否需要加入few-shot示例。

这个分析过程听起来繁琐，但它是RAG迭代的核心。我在工业维保项目里，就是通过badcase分析发现，很多错误集中在"跨章节的故障处理流程"上，于是针对性地调整了切分策略，把相关章节做了关联，问题就解决了大半。

6. 自研RAG的架构设计：模块边界与可迭代性

6.1 为什么我建议核心链路自研

市面上的RAG框架很多，从LangChain到LlamaIndex，再到各种低代码平台，看起来都能快速搭起来。但我在实际项目里的体会是：MVP阶段可以用框架快速验证，但生产迭代阶段，核心链路自研几乎是必然选择。

原因有三。第一，框架的抽象层太厚，出了问题很难定位。你不知道它内部怎么切分、怎么检索、怎么拼Prompt，只能靠猜。第二，框架的默认策略是为通用场景设计的，你的业务场景越特殊，默认策略的效果就越差。第三，框架的迭代速度和你项目的迭代速度不匹配，你需要的功能它可能没有，它更新的功能你可能用不上。

自研不等于什么都自己写。我的做法是：核心链路自研，外围组件用现成的。比如文档解析可以用开源库，向量库可以用Milvus或Qdrant，LLM可以调API，但切分策略、检索逻辑、重排逻辑、Prompt组织这些直接影响效果的环节，自己实现。这样既保证了灵活性，又不用重复造轮子。

6.2 模块边界怎么划

自研RAG的架构设计，核心是模块边界的划分。我的经验是按数据流来分：解析层、切分层、索引层、检索层、重排层、生成层、评测层。每一层有明确的输入输出，层与层之间通过标准接口通信。

这样分的好处是，每一层都可以独立替换和迭代。比如你想换Embedding模型，只需要改索引层和检索层，其他层不受影响。你想加一个新的重排策略，只需要在重排层加一个实现，不影响检索层。这种可替换性，是RAG系统能持续迭代的基础。

我在律所项目里就是按这个架构重构的。重构之前，所有逻辑混在一个大文件里，改一处经常影响另一处。重构之后，每个模块独立测试、独立部署，迭代效率提升了很多。关键词里的"架构设计"和"自研"在这个章节会详细展开，包括接口设计、数据格式、配置管理。

6.3 知识库更新：一个容易被忽略的工程问题

知识库不是一次建好就完事的。业务文档会更新，新的故障案例会加入，旧的条款会废止。怎么让知识库持续更新，同时不影响线上服务，是一个很现实的工程问题。

我的做法是增量更新+版本管理。每次文档更新时，只处理变化的文档，重新切分、重新Embedding、更新索引。同时保留历史版本，出问题时可以回滚。对于删除的文档，不是直接删索引，而是标记为失效，检索时过滤掉。这样既保证了更新的实时性，又避免了全量重建的开销。

还有一个细节：更新时要考虑chunk的稳定性。如果切分策略变了，同一个文档切出来的chunk会变，之前标注的评测数据就对不上了。所以切分策略的变更要谨慎，最好在评测集上验证之后再上线。

7. 一些实操心得和常见问题

7.1 关于Ollama和本地部署

关键词里有人问"ollama + 简易本地rag知识库"和"怎么在mac上搭建rag知识库"。本地部署RAG确实是一个很实用的场景，尤其是对数据隐私要求高的团队。Ollama跑本地LLM，配合本地的向量库和Embedding模型，可以搭出一套完全离线的RAG系统。

但本地部署有几个坑要注意。第一，本地LLM的生成质量通常不如云端大模型，尤其是在复杂推理和长上下文场景下。第二，本地Embedding模型的选择有限，中文领域的效果可能不如云端模型。第三，本地部署的维护成本不低，模型更新、硬件资源管理都需要投入。

我的建议是：如果数据隐私不是硬性要求，优先用云端模型；如果必须本地部署，把LLM和Embedding分开考虑，Embedding可以用云端API（只传文本不传原文），LLM用本地模型。这样能在隐私和效果之间找到一个平衡。

7.2 关于RAG和知识库的区分

关键词里有人问"kg知识库、rag知识库和结构知识库区分以及应用场景"。这个问题很典型，我简单说一下我的理解。

RAG知识库是"非结构化文档+向量检索"的组合，适合文档量大、结构松散、查询方式灵活的场景。KG知识库是"实体关系图谱+图查询"的组合，适合关系复杂、需要推理的场景。结构化知识库是"数据库+SQL查询"的组合，适合数据规整、查询明确的场景。

实际项目里，这三者往往不是互斥的，而是互补的。我在工业维保项目里就用了混合方案：设备参数用结构化数据库，故障案例用RAG，设备之间的关联关系用KG。查询时根据问题类型路由到不同的知识源。这种混合架构，比单一方案的效果好很多。

7.3 关于RAG的瓶颈和未来

RAG的瓶颈，我认为主要在三个地方：检索精度、上下文窗口、生成可控性。检索精度受限于Embedding模型和切分策略，上下文窗口受限于LLM的能力，生成可控性受限于Prompt设计和模型的对齐程度。

这三个瓶颈，短期内都不会有根本性的突破。所以RAG的优化，更多是在工程层面做权衡和组合。比如检索精度不够，就用混合检索和重排来补；上下文窗口不够，就用摘要和分层检索来压缩；生成可控性不够，就用引用标注和拒答机制来兜底。

这个专栏不会给你一个"银弹"，但会给你一套完整的工程方法论，帮你在自己的场景里找到最优解。关键词里的"rag教程"、"rag实战"、"rag项目"这些，最终都要落到具体的工程决策上。

8. 写在最后：一些个人体会

做RAG这几年，我最大的体会是：这个领域没有捷径，但有方法。捷径是那些"三行代码搭建RAG"的教程，看起来很美，但一到真实场景就露馅。方法是理解每个环节的原理，建立评测驱动的迭代习惯，根据业务场景做针对性的设计。

我见过太多团队，在Demo阶段信心满满，在生产阶段举步维艰。区别不在于用了什么框架、什么模型，而在于有没有建立起一套工程化的迭代体系。评测集、badcase分析、模块化架构、持续更新机制，这些听起来不酷，但它们是RAG从"能用"到"好用"的关键。

这个专栏会把这些方法系统地讲清楚，配上可运行的代码和真实的案例。如果你正在做RAG项目，或者准备做，希望这些内容能帮你少走一些弯路。毕竟，我踩过的坑，你没必要再踩一遍。