企业官网建设流程全解析

做RAG也快两年了，中间带团队做过几个知识库项目，最常被问到的一个问题就是：“为什么我们换了更好的embedding模型、调了chunk size和overlap，检索结果还是稀烂？”

这个问题一开始也困扰过我。去年有段时间，我们某条业务线的客服知识库命中率卡在60%上下，怎么调都上不去。团队里甚至有人提出要重训一个领域向量模型，差点就走上了“从头训练”这条路。后来我花了两周时间把整个流程从头到尾捋了一遍，发现问题几乎全部出现在入库环节：表格被当成整块文本切碎、合同的关键条款被拦腰截断、网页里的导航栏和正文混在一起进了向量库。换句话说，检索不准，九成的锅不在向量，而在入库方案。

向量化只是把一段文字映射到语义空间里的坐标，它本身不会帮你恢复、重组或补全语义。如果入库时文本的语义单元本身就是残缺的、错位的，那embedding算得再准也没有用。这个道理说起来简单，但真正要落地，需要针对不同文件设计不同的入库策略。这篇文章就把我自己在这块踩过的坑和最终沉淀下来的方案完整讲一遍，希望能帮你省掉至少两个月的试错时间。

1. 为什么说检索不准的锅主要不在向量模型

1.1 向量化是语义空间的“搬运工”，不是内容的重构者

很多人对RAG有一个直觉：检索不准，那就是向量质量不行，于是拼命在embedding模型上做文章。这个直觉只对了一半。

Embedding模型做的事情，是把一段文本（也就是chunk）编码成一个高维向量，使得语义相近的文本在向量空间里距离更近。注意，它编码的对象是“一段给定的文本”，而不是“你心里想描述的那个意思”。如果这段文本本身就有语义缺失、上下文断裂、结构混乱，那么向量化之后的结果也只能是一堆破碎向量的排列组合。

我用一个不严谨但很容易理解的类比来解释：把一个图书馆里几十万册书搬进新馆，搬家公司就算技术再好，也只是按你贴的标签把书放到对应书架上。如果你在书脊上贴错标签、把一本书撕成几十份分别装箱，那搬运之后检索系统自然怎么都找不到完整的书。向量模型就是这个“搬家公司”，入库方案就是“贴标签和装箱的规则”。大部分RAG检索不准的项目，问题都出在装箱环节，而不是搬家公司身上。

1.2 换embedding模型为什么常常治标不治本

我之前做过一个对比实验：在同一个知识库、同一条query集合下，分别用通用开源模型和一个领域微调过的商业模型跑检索，Hit Rate从62%提到了接近66%。听着是有提升对吧？但我把重叠部分拿出来一看，改善的来源几乎都是“本来就能答对但排名靠后”的case，而那些彻底检索不到的case，依然检索不到。

原因很简单：当入库的chunk里压根没有包含答案对应的完整上下文时，再强的语义匹配也召不回缺失的信息。比如一个保险条款被切成两个chunk，“被保险人应当在事故发生后10日内通知保险人”被切成了“被保险人应当在事故发生后10日内”和“通知保险人”，用户问“出险后多久需要通知保险公司”，两个片段都可能召回来，但都不完整，模型生成的回答质量自然差。这时候你换十代embedding模型，答案依然残缺。

所以我的建议是：在换embedding模型、调参数之前，先做一次入库质量体检，把注意力放回源头。向量那部分的调优确实有价值，但它的价值通常在入库和切分方案已经合理的条件下才能体现出来。

1.3 召回的上限在入库时就确定了

检索环节再努力，也只是在“已有chunk集合”里找最像的。你的系统能答得多好，上限早在入库那一刻就被切分策略锁死了。这就像一个搜索引擎，页面内容里没有的关键词，你再怎么优化搜索算法也搜不到。RAG系统的信息天花板不在向量数据库，也不在大模型，而在进入向量库之前的那一步——也就是“文档是怎么被切分、转写、结构化的”。

这一点是整篇文章的地基。理解了它，你再看后面所有按文件类型设计入库方案的内容，就都能串起来了。

2. 文件类型决定语义单元：先给文档分门别类再谈入库

2.1 不同文件的“语义最小单元”完全不同

同一个“一句话切成固定长度”的粗暴思路去处理所有文件，是很多项目翻车的根源。不同文件的语义颗粒度是不一样的：

• 表格里的一行记录可能才是一个完整事件，一张表里几十行彼此并没有什么相关性；
• 合同里的一个条款、论文里的一个段落才是完整论述，切碎了上下文就丢了；
• 网页里的一个正文区块才是有效信息，周围全是导航、广告、推荐位；
• 对话记录里的一个完整来回才是有效回合，单拎一句出来根本不知道在说什么。

语义最小单元这个概念，是我在项目复盘时才正式总结出来的。说白了就是：一段文本被单独拿出来之后，能不能让一个没看过上下文的人看懂它“在说什么、属于谁、和问什么有关”。这个单元的粒度因文件类型而异，强行用统一的chunk_size切，等于把所有文档都硬塞进一个模具里，出来的东西自然变形。

2.2 用“下游查询视角”反推语义单元

怎么确定一种文件的语义最小单元？我推荐一个特别实用的方法：别从文件本身出发，而从“用户会怎么查”出发。

举个例子。一份Excel库存表，用户很可能问“A001这个型号的库存还有多少”“最近一批入库的货是什么时候”，那语义单元就应该是一行记录带上表头信息，而不是一整张表。一篇产品操作手册，用户会问“怎么设置自动回复”，语义单元就应该是以小标题为锚点的说明段落，而不是把前后不相关的操作步骤硬拼在一起。

这个方法我们内部叫“反推法”。你先列出这个文件最常被查询的十个问题，然后看每个问题的答案落在文件的哪个位置、需要带着哪些上文信息才能回答完整，那就是语义单元的天然边界。这比对着chunk_size参数调参要有用得多。

2.3 文档分类是入库方案的前置条件

既然语义单元因文件而异，那么入库就不能是一条流水线走到底。我们在新项目里的标准做法是：入库前先做文档类型识别和分类，文件进来先判断它是什么类型——表格类、长文类、网页类、对话记录类、代码日志类，然后路由到不同的处理管线。

这个分类不一定非要用多复杂的算法，很多场景下从扩展名、MIME类型、内容头部特征就能判断个八九不离十。后面“多路由入库系统”那一节我会给出一个具体可落地的判断逻辑和路由参考表。这一节先记住一个核心结论：入库方案的必须差异化，因为文件类型决定语义单元，语义单元决定切分策略。

3. 分文件类型的入库方案设计：五个典型场景的实操细节

3.1 表格文件（Excel/CSV）入库：行级语义化转文本

表格类文件是我见过被RAG做坏率最高的一类。最常见的情况是：工程师把整张Excel导出成文本或直接按固定长度切分，结果表头、列名、单元格内容混在一起，检索的时候根本分不清“型号”和“数量”是什么关系。

对表格，我实践下来效果最稳定的方案是**“行级语义化转文本”**：每一行记录生成一段独立的chunk，把表头信息作为上下文拼进这段文本里，并明确标注字段名。

拿一个库存表举例，原始数据大致是：

不应该把它切成一堆散落的单元格。推荐的做法是生成一条结构化的描述文本：

库存记录：型号A001，当前库存数量120件，入库日期2024-05-10，供应商上海XX电子。

这里的关键点是“把表头字段名写进文本”。因为 embedding模型对自然语言的编码要好过对裸数据的编码，把“型号”“库存数量”这样的字段名显式拼接到值的前面，检索“A001还有多少库存”时命中率会明显提升。我这边实测下来，同样的表格数据，这种行级语义化转文本方案比直接切分文本的Hit Rate大约能高出15到20个百分点。

如果表格的行数特别多，我建议按行分批生成chunk，每行一个chunk，然后统一写入向量库。如果表格本身还有层级结构（比如合并单元格、多级表头），需要先把表头展开成扁平字段名再转文本。

3.2 PDF/Word长文档：层级切分 + 父子chunk策略

PDF合同、产品说明书、行业报告这类长文档，是知识库里最主流的内容类型。对它们，我的做法是分两步走：先做结构识别，再做父子chunk。

结构识别这一步，优先从文档中提取标题、章节层级。大部分PDF用工具抽取后，可以通过标题字号、编号（如“第1章”“1.1”“第一条”）等特征还原层级结构。如果用的是专业转换工具，也可以直接拿到带层级标签的导出结果。拿到层级之后，切分就尊重这个结构：一级标题下的一个部分、二级标题下的一个子节，作为独立的切分单位，不让内容跨越标题边界。

父子chunk策略解决的是“要上下文还是要精确”的矛盾。父chunk可以是整个章节甚至更大一点的语义块，子chunk则是父chunk内部更细的片段。检索时，先用子chunk做精确匹配，命中后把所属的父chunk一起作为上下文丢给大模型。这样既保证了检索的精确度，又保证了生成回答时有足够的上下文。具体落地时，可以用LangChain里的HierarchicalDocumentSplitter，也可以自己存两组chunk并在元数据里记录父子ID关系。

参数方面给一个我们项目里常用的参考值，不一定适合所有场景，但可以作为一个起点：

需要强调的是，overlap不是越大越好。overlap太大容易让相邻chunk高度重复，既浪费向量库存储，也容易造成检索结果冗余。它存在的意义只是缓解“关键信息恰好在切点上被撕开”的问题，所以配合语义边界切分时，适当的小overlap就够了。

3.3 网页与在线文档：先清洗，再按标题锚点切分

网页类内容单独拿出来说，是因为它有一个独特问题：噪音。导航栏、侧边栏、推荐位、页脚版权信息，这些内容进向量库不是单纯的浪费，它们会严重污染检索结果。你不知道用户什么时候就会问到一个正好撞上导航栏文本的query，然后系统把一堆无关URL当证据返回给你。

处理网页入库，我建议的顺序是：

1. 先做正文提取，把网页主内容抓出来。常用工具包含 readability、trafilatura这些，我个人更偏好 trafilatura，它对中文页面正文的抽取效果更稳。
2. 对抽取出来的正文，按HTML的标题层级（h1、h2、h3）作为锚点切分。因为网页内容本身是模块化写的，标题层级天然就是语义边界，顺着它切比任何固定长度切法都靠谱。
3. 把页面URL、发布时间、来源站点名称作为元数据一并写入向量库。元数据有两个作用：一是后续可以做过滤，比如限定“只看最近三个月的公告”；二是检索结果展示时可以带上出处，让回答更可信。

这里有一个我自己踩过的坑：一开始我们图省事，直接把网页转成纯文本后按800字符切分，标题和正文的内容倒是都保留了，但一个h2下面讲多步操作时，两步之间可能被切开，用户问第二步怎么操作时召回的却是第一步的chunk。改成按标题锚点切分之后，这个问题基本消失。网页类文档切分时，宁可某个chunk偏长，也不要切断在标题的正逻辑块中间。

3.4 对话、邮件、工单记录：按会话边界和角色聚合

客服对话、邮件往来、工单记录，这类内容做RAG知识库时很有价值，因为他们带着真实问题的“问法”。但它们的切分方式和文档类完全不一样。

有一次我们想把历史客服会话做成知识库，一开始的做法是把整段会话按200字符切块，结果检索出来的片段语无伦次——一会儿是客户说话，一会儿是客服回答，上下文完全断裂。后来我们把整段会话看作一个“时间线”，只按会话边界切分：一次完整对话一个chunk，内部保留角色前缀（“客户：”“客服：”），把关键结论的原话留在片段里。这样检索到的是完整的话轮，大模型能看到问答的来龙去脉。

实际处理时，还可以自己写一个简单的聚合脚本：从会话日志里按session_id聚合同一轮对话，内部转成“角色+发言内容”的文本块，然后直接入库。邮件类的处理同理，按邮件主题（thread）聚合，保留发件人、时间、主题正文。这里最忌讳的是把不同会话、不同主题的碎片硬拼在一个chunk里。

3.5 代码、日志、配置文件：按逻辑块而非按行数切

如果你要检索的不是自然语言文档，而是代码库、日志、配置文件，那这套思路同样适用，只是“语义单元”变成了函数、类、异常栈。

代码切分的通用做法是抽象语法树（AST）分析，按函数或类把代码块切出来，保留方法的注释和签名。日志入库则建议按一次完整的请求或异常事件聚合，而不是简单按行切——一条异常log往往要连着前面的上下文日志才能定位问题。配置文件则通常一个配置项或一个section作为最小单元。这类场景里，如果按固定行数硬切，结果就是函数被腰斩、日志上下文丢失，检索到的信息基本没法用。

4. 判断入库方案合不合理的几个信号与排查路径

4.1 症状与病因对照表：先从结果反推问题

这套信号与病因的对照，是我自己在多个项目里总结出来的。当你发现RAG系统检索不准时，不要急着调参，先对着表格自查一下：

排查的时候不用靠猜，直接拿几个典型query去向量库做相似度检索，把召回的前5到10条片段列出来，人工看一眼它们的语义完整度。如果召回的片段读起来是断的，那问题基本在入库；如果读起来是完整的但匹配不上，才轮得到去看embedding和参数。

4.2 从query反推入库的“反查法”实操

具体的反查操作我给一个简单可复现的步骤：

1. 挑出你认为“应该能被知识库回答”的10到20个高频业务问题；
2. 直接调用向量检索接口，看召回结果；
3. 对每一条结果记录三个观察点：片段是否语义完整？是否包含答案所需的关键上下文？是否命中正确的文档和段落？
4. 统计“语义不完整”的占比。如果超过三成，大概率入库方案需要调整。

这个方法我个人每隔一两个版本就会跑一次。它看起来简单，但非常有效，比只看Hit Rate这类汇总指标更能定位问题。

4.3 效果评估不只看Hit Rate

做RAG项目评估，常见指标是Hit Rate、MRR、Context Precision等，这些指标有用，但也容易骗人。我给团队定的评估体系是三层：召回层、排序层、生成层。入库方案主要影响召回层。它的评估方式是针对一批标注过的query，检查正确的答案片段是否出现在召回结果里（Hit Rate），以及召回的片段是否语义完整。

生成层的评估同样有意思。有一次我们命中率已经做到85%了，但业务方依然觉得“回答没有灵魂”。后来发现是父chunk给的上下文太小，模型知道答案但不知道出处，回答显得干瘪。把父chunk范围扩大到整节之后，回答质量立刻上了一个台阶。所以评估一定要带上最终生成质量，别只盯着召回指标。

5. 多路由入库系统怎么搭：一套通用架构与迭代节奏

5.1 入库前的文件类型识别与路由

前面讲的都是单类型文件的处理，但真实企业知识库里往往是几十种文件混在一起。这时候需要一套路由逻辑，把不同文件分到对应的处理管线。

我项目里用的是一套很务实的规则，不复杂，准确率也够：

1. 先看扩展名和MIME类型，快速锁定大类；
2. 再抽样读文件内容的前若干行做二次校验（比如扩展名是.pdf但内容里全是表格，就按表格管线走）；
3. 最后根据业务目录或文件名中的关键词做业务域路由（可选）。

路由逻辑示意，用伪代码写大概是这样的：

def route_document(file_path): mime = detect_mime(file_path) if is_table_file(file_path, mime): return "table_pipeline" elif is_long_document(file_path, mime): return "longtext_pipeline" elif is_web_page(file_path, mime): return "web_pipeline" elif is_conversation_log(file_path, mime): return "conversation_pipeline" else: return "generic_pipeline"

不同管线之间的差异主要体现在切分策略、chunk构造方式和元数据字段上，但清洗、转码、向量化这几个基础环节可以共用一套，不用重复造轮子。

5.2 公共环节与差异环节的拆分

我把入库流程拆成两类环节。

公共环节包括：文本抽取、格式标准化、统一清洗（去空行、去乱码、统一换行符）。这些不管什么文件类型基本都适用，做成公共组件，一次开发全局复用。

差异环节包括：语义单元识别、切分策略、chunk的内容构造、元数据schema。表格管线要拼表头字段名，长文管线要维护父子chunk关系，网页管线要提取正文和标题锚点。这些环节不能用一套代码糊弄过去，必须按类型拆分实现。

公共和差异分开之后，最大的好处是扩展新文件类型时不用动老代码，新增一个管线就行。我接手过的很多项目之所以乱，就是因为所有逻辑都堆在一个“万能入库脚本”里，改一个文件类型的处理会影响所有文件。

5.3 推荐的推进顺序：先单类型跑通，再摊开多类型

如果你现在接手一个已有的RAG项目，我建议按这个顺序迭代：

1. 先对现有知识库做一次类型画像：哪些文件占大头、哪些类型检索抱怨最多；
2. 选一种占比最高或痛点最明显的文件类型，先按前面的方案重新定制入库管线；
3. 用典型query集合跑一轮效果对比，记录入库方案调整前后的召回差距；
4. 跑通并验证后再扩展到第二种文件类型，逐步把整个库的类型覆盖率提上来。

不要试图一天之内把所有类型全部重做。每换一种类型，做法和参数都需要重新验证，摊子铺太大容易什么都调不好。

5.4 多类型混库时的元数据设计

当多种文件共存于一个向量库时，元数据是避免互相干扰的一把钥匙。每个chunk至少建议带这些字段：文件类型、来源路径、文档标题、更新时间、业务域。检索时可以按文件类型过滤，或者要求只检索某个业务域下的数据。比如你是做企业知识库的，用户查“报销流程”时，如果库里同时有产品文档和财务文档，元数据过滤能帮你直接排除掉不相关的文件类型。

我这里特别想强调一个很多人会忽略的点：元数据字段的命名和取值要统一。比如“类型”这个字段，有的管线叫file_type，取值是pdf，有的管线叫doc_type，取值是PDF，检索过滤时大概率会踩坑。所有管线的元数据schema从一开始就要拉齐。

最后分享一点实际体会

做RAG这么久，我最大的感受是：很多人把RAG当成“模型问题”，但其实它更像一个“工程问题”。而工程问题里，入库环节又恰恰是最能快速见效、也最容易被忽视的一环。你不用急着换最新的embedding模型，也不用把架构改成Agentic RAG，先把手上的文档按类型重新入库一遍，检索效果往往就能立竿见影。

我自己的选型习惯是：对每个知识库项目，都会维护一张“文件类型 × 语义单元 × 切分策略 × 元数据”的对照表，新文件进来先查表归队。这套方法看起来不fancy，但确实帮我们稳定撑过了好几个业务场景的验收，也在生产环境扛住了真实的检索压力。如果你正在为RAG检索不准发愁，不妨先照上面这套思路做一个入库方案的体检，我相信你会回来感谢这份对照表的。