企业官网建设流程全解析

先说个我最近遇到的真实案例：有个朋友搭了一套 RAG 知识库，用的还是当下很火的框架，模型选得也不差，结果上线后用户随便问一句，检索出来的内容完全对不上。排查了一圈，模型没问题、Prompt 没问题、向量库也没问题，最后把源头一翻——PDF 解析阶段就错了，文本乱码、段落错位、表格碎成渣，后面所有环节都跟着遭殃。

这恰恰是很多 RAG 项目最容易忽略的事实：入库流程才是决定整个系统检索质量的天花板。模型再强，喂进去的是垃圾，出来的自然也是垃圾。这套"1200 行保姆级离线入库全流程"并不是什么高深的理论，而是我把 PDF 到可检索结构这条链路上所有坑都踩了一遍之后，沉淀下来的一套可复用的工程实践。这篇博文适合那些正在搭 RAG 知识库、或者搭完发现检索效果稀烂，想从头排查入库环节的开发者。我会把解析、切块、向量化、索引验证整个链路讲透，每个环节为什么这样做、翻车点在哪、怎么验证，一次说清楚。

1. 入库环节决定 RAG 生死：为什么"能检索"不等于"能搜对"

很多人对 RAG 有个误解，以为只要把文档切一切、向量化、丢进向量库，就能等着 LLM 输出高质量答案了。实际上入库这条链路里，任何一个环节的微小偏差，都会在检索阶段被成倍放大。

1.1 一个典型到不能再典型的翻车现场

我帮朋友排查的那个项目，文档是一批 PDF 格式的产品手册，大概几百页。现象是用户问"设备的最大工作温度是多少"，系统返回的片段却是"安装注意事项"里的一段话。单看返回内容完全正确，但它根本不是用户要的答案。

问题出在哪？PDF 解析之后，原文的段落结构被打乱了。原本一个完整的规格表格，因为解析库把表格单元格按坐标顺序导出，导致"工作温度"这个字段和它的值被拆到了两个不同的 chunk 里。检索时命中了包含"工作温度"的 chunk，但里面的数值却在相邻的另一个 chunk 中，最终 LLM 拿到的是残缺信息。

这就是入库环节"污染"的最典型形态：解析阶段的错误被切块固定下来，又被向量化语义化，最后在检索阶段以一个看起来完全合理的方式输出错误结果。这种问题极难被测试集发现，因为单独看每一段检索结果都像那么回事。

要理解为什么入库这么容易翻车，得先把 RAG 的完整链路拆开看。整个离线入库可以分成四个阶段：

1. 文档解析：从 PDF 等原始格式中提取干净文本
2. 文本切块：将长文本按语义或结构切分成适合检索的片段
3. 向量化：用 Embedding 模型把切块转为向量
4. 索引构建：将向量写入向量库并建立索引

检索阶段相对简单，就是向量召回 + 重排 + LLM 生成。但检索的质量上限，在入库那一刻就已经被定死了。解析错、切块烂、向量化没调好，后面做再多 rerank、调 Prompt 都是白费力气。

1.2 解析污染、切块污染、向量污染：三层递进式翻车

入库翻车不是一次性发生的，而是一层层累积的。我把它们归纳为三层污染链路，方便定位问题。

第一层：解析污染。这是最底层、也最致命的污染。PDF 本身不是一种为文本提取设计的数据格式，它记录的是"在某个坐标画一个字符"这类渲染指令。因此提取文本时可能出现：文字乱序、多栏文档读成单栏、表格结构丢失、页眉页脚混入正文、特殊字符（如 ≈、≥）变成乱码。这一层错了，下游看到的文本和用户看到的原始文档根本不是一回事。

第二层：切块污染。假设解析阶段侥幸过关，切块阶段也会引入新问题。固定长度按字符切，极易切断一句话、一个数据表、一段代码示例，导致单个 chunk 的含义不完整。更隐蔽的是，切块策略还会影响检索的粒度：切得太粗，一个 chunk 里混合多个主题，召回准确率下降；切得太细，上下文信息不足，LLM 拿到后无法理解。

第三层：向量污染。即便文本切块都对了，Embedding 环节依然可能出问题。比如批量向量化时模型上下文窗口限制导致截断、长文档 embedding 后语义混淆、没有做归一化导致余弦相似度计算有偏差。还有一个常见问题：没有排除 FAQ 类短文本，导致短文本和长文档在向量空间中互相干扰。

理解了这三层污染，再回头看我朋友那个翻车案例，就知道问题出在第一层和第二层的交界处：表格解析乱了，切块随之把数据拆散。

1.3 离线入库的核心矛盾：不求快，但求稳

线上检索要求毫秒级响应，但离线入库恰恰相反。很多团队在这上面犯的错，就是试图让入库流程"快一点"，比如用最快的解析库不做人工校验、十万个 chunk 一次性灌入向量库不检查重复、Embedding 批量任务挂了直接重头来。

我的建议是：离线入库的优先级永远是把"稳"放在"快"前面。这也是为什么我这套流程特意强调校验机制——每个环节都必须有输出检查，宁可慢 10 分钟也不要出现一批污染数据流入下游。

数据库领域有个经典原则叫"垃圾进，垃圾出"（Garbage In, Garbage Out），RAG 也不例外。入库流程的本质，是把非结构化数据转化为结构化可检索形式，这个过程中任何一步的妥协，都会在使用阶段连本带利地还回来。所以我们接下来逐个环节拆解，看每一步具体怎么做才不翻车。

2. PDF 解析选型与工程落坑：文本都没提对，后面全是白搭

PDF 解析是入库的第一步，也是坑最多的环节。很多开发者在这里随便选一个库就开始跑，直到跑完入库才发现文本是乱的。下面我会直接给出选型建议、常见问题的处理方案，以及一套我在项目里用的解析结果校验机制。

2.1 解析库选型：没有万能的，只有更合适的

市面上 PDF 解析库不少，但真的不存在一个"全都能解析好"的工具，只能根据文档类型组合使用。这几类是我实测下来比较可靠的方案：

选型逻辑很简单：如果你的文档主要是文字段落，PyMuPDF 就够了；如果表格密度高，加一个 pdfplumber 专攻表格区域；如果文档是扫描件，必须走 OCR。复杂混合文档可以直接上 MinerU 这类带版面分析的框架，虽然重一点，但能把版面还原、公式识别、表格结构一次做完。

实测下来我遇到过一个看似简单但很坑的点：PDF 里如果嵌入了字体子集，部分库提取出来的字符可能是乱码或者空白。这跟解析库本身关系不大，是字体编码映射问题，遇到的话一般只能换库或走 OCR 兜底。

2.2 扫描件和图片型 PDF：不是"加个 OCR"就能糊弄过去的

扫描件是 PDF 解析里绕不开的硬骨头。它的本质不是 PDF 解析问题，而是图像转文字问题。OCR 的精度直接决定后续链路的质量下限，而精度又取决于图像质量。

先说说判断文档是不是扫描件的方法。用 PyMuPDF 读取页面后，提取文本内容，如果所有页面提取结果为空或者只有极少数文字，而页面尺寸正常，那基本可以判定是扫描件或者图片型 PDF。更精确的方法是检查页面内容流里是否包含大尺寸图片对象且无文本对象。

扫描件处理流程我建议这样设计：

1. 预处理：用 OpenCV 做灰度化、二值化、去噪、倾斜校正。扫描件的质量参差不齐，有些角度歪了 5 度以上，直接影响 OCR 识别率。
2. OCR 识别：优先考虑 PaddleOCR。它在中文场景下的识别率比 Tesseract 高一个级别，内置了表格识别能力，还能输出每个文本块的位置坐标。Tesseract 也不是不能用，但需要自己微调训练数据，投入产出比不划算。
3. 版面还原：OCR 输出的是带坐标的文本块，需要用规则或版面分析模型将它们重新组织成段落。直接用识别顺序拼接文本，在多栏文档上会得到跨栏乱序。

这里插一个我踩过的坑：有一批扫描件是双栏排版的论文，直接用 PaddleOCR 默认的文本顺序输出，结果每一段都是左栏下半截接右栏上半截，语义全乱。后面我用坐标信息做了分栏判断，按"同一栏内从上到下、栏间从左到右"的顺序重组文本块，问题才解决。

OCR 识别率的底线是：每一个文本段落的关键信息不能缺。遇到识别置信度低的区域，不要硬选一个最可能的字符，宁可标记为存疑让后续人工介入，也不要默默吞掉错误。

2.3 表格、页眉页脚、多栏排版：结构信息不能无脑丢弃

PDF 解析最容易在表格和版面结构上翻车，因为它们涉及的不只是"有哪些文字"，还有"文字之间的关系"。一个产品规格表里"电压范围：220V-240V"，如果被切分成两行提取，语义就断了。

表格处理的工程实践：

对于规则表格，pdfplumber 的extract_table()方法能按行列规则提取，效果不错。但对于不规则表格，比如包含跨行单元格、合并单元格的，pdfplumber 也会翻车。这时候有两个选择：一是做后处理，根据单元格坐标和内容长度，用规则把它拼回去；二是直接用专门做表格识别的框架，比如 PaddleOCR 的表格识别模块。

我自己在项目里通常是组合策略：先用 pdfplumber 尝试结构化表格提取，如果失败，再用 OCR 的表格识别能力兜底。注意一个细节：提取表格时，一定要保留表头信息和单元格的行列关系，而不是只导出纯文本。因为切块阶段要利用这些结构信息决定如何切分，表格数据散成纯文本后会完全丢失可读性。

页眉页脚的处理：

页眉页脚看起来无害，但它们会污染 chunk 的语义。比如一份 50 页的文档，每页页脚都是"第 X 页/共 Y 页"，如果不去除，切块时这些重复文本会大量出现，既浪费向量空间，又给检索引入噪声。

处理方式是在解析阶段直接按坐标过滤：页面上方 10% 和下方 8% 区域通常是页眉页脚。但例外情况也很多，有些文档正文一直延伸到靠近页脚的位置。所以更稳的做法是：先按坐标过滤一次，再把过滤后文本做一次重复率检测——如果同一段文字在多个页面顶部或底部重复出现，判定为页眉页脚并删除。

多栏排版的处理：

多栏文档（如论文、报纸）是解析重灾区，原理上需要做版面分析。简单方案是按坐标把页面纵向切成多栏，再分别按栏提取文本；复杂方案是直接用版面分析模型（如 LayoutLM 系）识别栏结构。对于 90% 的场景，坐标切栏+按栏内顺序拼文本已经够用，只有遇到不规则复杂版面才需要上版面分析模型。

2.4 解析结果的校验机制：每个页面都要有"质量分数"

解析做完了，不能直接进下一步，必须先校验。我在这套流程里加了一个强制环节：给每一个解析出来的页面计算质量分数，低于阈值的页面单独输出到问题列表，人工或者规则补充处理。

质量分数的计算维度我建议包含以下几个：

• 文本密度：该页面提取字符数与原始页面预估文字量的比值。PDF 无文字且非扫描件时直接判为异常。
• 乱码比例：统计替换字符（U+FFFD）、常见 OCR 误识字、控制字符的比例。
• 段落完整性：检查段落开头是否有异常截断，例如不该出现换行符的位置出现换行。
• 坐标合理性：文本块的坐标是否超出页面边界，是否大量重叠（重叠可能意味着解析时重复提取了同一区域）。

我见过一个很能说明问题的例子：某页文本密度正常，但段落完整性检查发现，所有段落都以一个孤立字符开头或结尾，说明解析时每行文本被单独提取，段落换行信息完全丢失。如果不做校验，这批文本切块后全是断句碎片，检索效果可想而知。

校验环节产生的异常页面，不需要全部人工处理（那也太累了），但至少要保证它们是可见的、可追踪的，而不是静默流入下游。

3. 切块策略与元数据设计：chunk 的长度不是拍脑袋拍出来的

解析完成之后就是切块。很多 RAG 教程把切块讲得很简单："按固定长度切，加个 overlap 就行。"但实际上切块是整个入库流程中对检索效果影响最大、又最容易被低估的环节。

3.1 固定长度切块为什么是"看起来最合理"的坑

固定长度切块的代码写起来确实最简单：

def fixed_chunk(text, chunk_size=500, overlap=50): chunks = [] start = 0 while start < len(text): end = start + chunk_size chunks.append(text[start:end]) start = end - overlap return chunks

但这段代码几乎是为翻车量身定做的。最典型的问题：一个 chunk 正好落在一段话的中间，导致一句话被硬生生截成两半。比如"该设备的最大工作温度是 85 摄氏度，超过此温度请立即停机检查。"被切成：

• chunk A："该设备的最大工作温度是 85 摄氏度，超过此温度请立"
• chunk B："即停机检查。"

如果你检索的问题是"设备超温了该怎么办"，向量召回时命中的可能是 chunk A（因为包含"工作温度"），但它里面没有答案"停机检查"，于是 LLM 只能基于残缺上下文编造。这就是召回正确但答案错误的经典案例。

有人会寄希望于 overlap 解决这个问题，但 overlap 只解决了"边界上下文断裂"的一种情况，没法解决"一个完整表格被切成两半"、"一个代码示例被拆开"这类结构性问题。

3.2 结构感知切块：先标题层级，再语义边界，最后才是长度

真正靠谱的切块策略应该是以文档结构为主、长度约束为辅。我常用的分层切块逻辑如下：

第一层：按标题层级切。利用解析阶段保留的标题信息（H1/H2/H3），把文档切成"章节块"。每个章节块内部是主题一致的文本，这是最自然的检索单元。如果解析阶段没有保留标题信息，可以用文本特征（如字号、字体加粗）或者规则（正则匹配"第 X 章"、"1.1"等模式）来恢复层级。

第二层：对过长章节再切。如果一个章节块太长（超过 embedding 模型的最大输入长度），需要继续细分。这时候不要用固定长度硬切，而是找段落边界（\n\n）、句子边界（句号、分号）作为切分点。理想情况是：切出来的 chunk 内部语义紧凑，边界都在句子或段落之间。

第三层：长度兜底。如果以上两层做完，某个 chunk 依然过长，再执行软约束：优先在最近的段落边界切断，如果一段本身过长，就在句号附近切断，并设置 30 到 60 字符的 overlap 作为缓冲。

这套流程看起来比固定长度复杂一些，但它能让切出来的 chunk 基本符合"一个 chunk 尽量是一个完整语义单元"的目标。

3.3 元数据附加：chunk 必须"自带身份信息"

切块切得好不够，还得让每个 chunk 带上足够多的元数据，否则检索到之后 LLM 依然不知道这段内容从哪来、是什么、有什么约束。我建议每个 chunk 至少包含以下元数据字段：

为什么要记embedding_model这个字段？因为我被坑过一次：团队中途换了更好的 embedding 模型，但忘了记录哪些 chunk 是用旧模型生成的。后来的检索效果怎么调都不对，排查了老半天才发现向量库里的向量有一半是旧模型生成的，新旧向量语义空间不一致，混在一起互相干扰。从那以后我强制要求索引里带上模型版本号，换模型必须全量重建索引。

除此之外，有些业务场景还需要记录security_level（机密等级）、owner_department（所属部门）、valid_until（有效期）等业务元数据，这些在后续做权限过滤或时效过滤的时候都用得上。建议在设计元数据时预留扩展空间，别只存一个source字段就完事。

3.4 切块参数不要拍脑袋：用"可检索率"来校准

切块大小和 overlap 到底选多少，不能靠感觉。我的经验是用一组真实问题集去跑检索，统计"可检索率"——即问题答案是否完整落在命中的 chunk 内。

实操起来分几步：

1. 准备 30 到 50 个真实业务问题，标注每个问题对应的答案在原始文档中的位置（页码、段落）。
2. 用候选的切块参数跑一遍入库流程。
3. 对每个问题做检索，检查召回的前 5 个 chunk 中是否包含完整答案。
4. 计算命中率，对比不同参数组合的结果。

实测数据可以说明问题：在我做一个产品文档项目时，固定 500 字符切块的可检索率只有 62%，而结构化切块（按标题层级 + 段落边界）加 50 字符 overlap 的可检索率是 88%，提升非常明显。

参数校准的意义不只是优化效果，更重要的是建立一套可量化的依据：以后有人质疑"为什么 chunk 大小是 512 而不是 256"，你可以甩出实测数据，而不是说"大家都这么设"。

4. Embedding 与向量化：批量计算、并发控制与断点续跑

文本切好之后，下一步是embedding。50 个 chunk 的向量化随便跑，但几万、几十万个 chunk 的批量向量化是有工程门槛的。这里面的关键不是调用模型本身，而是一些工程化细节。

4.1 Embedding 模型选型：效果好但不适合你，也是白搭

嵌入模型选择的标准，不只是排行榜分数，还要看实际场景约束。

• 语义空间匹配：中文文档优先考虑中文语料训练的模型，如 BGE、M3E、text2vec 系列；英文文档则考虑 OpenAI 的 text-embedding-3 系列或 E5 系列。混用语言会产生严重的语义偏移。
• 最大输入长度：不同模型的最大输入长度差异很大（512 token、1024 token、8192 token）。切块长度必须适配模型的最大输入，超长会被截断，截断后的 chunk 语义不完整。
• 向量维度：维度越高信息越丰富，但存储成本和检索耗时会上升。768 维到 1536 维是目前的主流区间。
• 归一化问题：很多检索场景用余弦相似度，而部分模型输出向量未归一化。如果直接用点积或欧氏距离计算相似度，结果可能系统性偏差。建议在入库时对向量做 L2 归一化，检索时统一用点积或余弦。

本地部署还是调用 API，也是选型时必须考虑的。离线入库的数据往往涉及内部文档，走外部 API 会有数据外泄风险，所以我个人在项目里倾向于部署本地模型，比如 BGE 系列，7GB 显存就能跑，性价比很高。

4.2 批量向量化的工程细节：并发、限速与显存控制

批量向量化的第一个坑是并发控制。如果你调用的是 API，通常有 QPS（每秒请求数）限制，盲目高并发会导致大量请求失败。本地部署模型虽然可控性高，但也会遇到显存溢出、GPU 占用率不均衡等问题。

我的批量向量化管线设计大概是这样的：

import numpy as np from sentence_transformers import SentenceTransformer model = SentenceTransformer("BAAI/bge-large-zh-v1.5") batch_size = 64 results = [] for batch in chunks_of_texts(all_chunks, batch_size): # 模型内部会对 batch 做 padding，batch_size 越大越吃显存 vectors = model.encode( batch, normalize_embeddings=True, show_progress_bar=False, device="cuda:0" ) results.append(vectors) # 每批之间稍作停顿，避免 GPU 峰值过高 time.sleep(0.1)

batch_size 的调法不是越大越好。实测下来，batch_size 从 32 提高到 64 速度增益明显，但 64 提到 128 反而可能触发显存溢出导致 OOM。建议根据显存大小做一次摸底，找一个稳定不 OOM 的最大值。

本地模型的另一个细节：尽量用 batch 推理而不是单条循环。单条 encode 调用开销很大，包括 Python 前向传播、GPU 上下文切换等。1000 条单条编码可能耗时 10 分钟，批量编码只需要几十秒。

4.3 断点续跑：入库这个体力活不能靠运气

几万条 chunk 的向量化可能要跑几十分钟甚至更久，中途网络断了、显存溢出了、进程被杀掉了，如果要从头再来，绝对让人崩溃。所以批量入库流程必须要做断点续跑。

实现思路很简单：每条 chunk 处理完成后，立即记录状态。最简单的方式是把处理结果写到一个manifest.json或 SQLite 表里，记录chunk_id -> status (pending | done | failed)以及对应的向量 ID。重启后读取状态文件，只处理pending和failed的 chunk。

import json import os STATE_FILE = "manifest.json" def load_state(): if os.path.exists(STATE_FILE): with open(STATE_FILE, "r", encoding="utf-8") as f: return json.load(f) return {} def save_state(state): with open(STATE_FILE, "w", encoding="utf-8") as f: json.dump(state, f, ensure_ascii=False, indent=2) state = load_state() for chunk in all_chunks: if state.get(chunk["chunk_id"]) == "done": continue # 已处理的跳过 try: vector = model.encode(chunk["text"]) except Exception as e: state[chunk["chunk_id"]] = "failed" save_state(state) continue vector_db.insert(chunk["chunk_id"], vector, chunk["metadata"]) state[chunk["chunk_id"]] = "done" save_state(state)

这里有个细节要注意：每处理一条就写入状态文件会频繁刷盘，影响性能。可以在内存里维护状态，每处理完一批（比如 128 条）再统一落盘一次。如果进程中途异常退出，最多丢失一批的进度，可接受。

另一个实践中遇到的点是：向量库写入失败但状态已经标记为 done 了怎么办？这会导致重启后漏写一部分数据。我的处理方案是：先写向量库，成功之后再更新状态为 done。只有这两个操作都完成，这条 chunk 才算真正处理完。顺序反了，漏数据是必然的。

5. 索引落地与检索验证：入库完成后，如何证明"真的能搜对"

入库流程走到这一步，向量库里有数据了，系统能跑了。但"能跑"和"能搜对"之间还有一道鸿沟——索引参数调优和检索质量验证。如果不做这一步，你永远不知道系统是 60 分还是 90 分。

5.1 向量库选型与索引参数：HNSW 不是无脑默认就完事

向量库的选型直接关系到检索性能，但更重要的是索引参数配置。目前主流向量库有 Milvus、Qdrant、Weaviate、Chroma、Elasticsearch（自带向量插件）、pgvector 等，选哪个往往取决于团队已有的基础设施。

无论用哪个，底层索引大多基于 HNSW（Hierarchical Navigable Small World）图算法。HNSW 有几个关键参数会影响检索效果和性能：

一个实测教训：有次我把 M 值设置成 8 想要省内存，结果召回率掉了将近 10 个百分点。后来老老实实调回 32，效果立刻恢复。在这类参数上过度优化，省下的那点内存远不够弥补召回损失。

另外必须提到filter的能力。RAG 落地到业务场景后，往往需要按文档类型、时间范围、权限等级做过滤检索。如果向量库不支持元数据过滤，就只能召回后再在业务层过滤，性能差且体验割裂。选型时一定要确认向量库支持高效的过滤能力，尤其是"过滤 + 向量召回"能不能同时进行。

5.2 检索质量验证：别用测试集自嗨，要用真实问题集

入库完成后最怕的就是"自我感觉良好"。随便搜几个词，出来的结果像模像样，就以为系统没问题了。但真实用户的提问方式、用词习惯、问题复杂度，和开发人员自测时想的完全不一样。

我建议建立一套与入库流程绑定的问题集，包含三种类型：

1. 规范性问题：文档中直接有原文答案的问题。例如"最大工作温度是多少？"用于验证基础召回能力。
2. 推理型问题：答案需要跨多个文本片段整合的信息。例如"高温环境下需要注意哪些安全事项？"需要召回多个相关段落。
3. 边界型问题：文档里有相关内容但表述方式与问题差异很大的，用于验证语义泛化能力。例如文档中写的是"环境温度不应超过 85℃"，用户问"这台设备耐不耐高温？"。

用这三类问题跑完检索后，需要人工判断召回结果的相关性，并计算召回率、准确率等指标。这个过程很耗时，但值得做，因为它是你后续调优切块参数、embedding 模型、索引参数的判断依据。

还要注意一点：评估问题集要持续维护。每次业务新增文档类型，就往问题集里补充对应的测试问题。否则评估体系会慢慢失效，最终变成自嗨。

5.3 完整的入库-验证闭环：从日志开始，最终靠日志收尾

最后，我把整套离线入库流程串成一条可执行的闭环，方便你对照落地：

1. 采集：统一管理待入库的 PDF，记录文件名、来源路径、Hash 值。Hash 值用于判重，避免同一文件重复入库。
2. 解析：按文档类型选择解析策略（PyMuPDF / pdfplumber / OCR），生成带结构信息的中间格式（如 Markdown 或 JSON Lines）。
3. 校验：计算质量分数，异常页面进人工复核队列。
4. 切块：按标题层级 + 段落边界切分，附加完整元数据。
5. 向量化：批量 embedding，带断点续跑机制。
6. 索引构建：写入向量库，配置索引参数。
7. 检索验证：用真实问题集跑评估，分析失败案例，回溯到解析、切块或向量化环节修正。
8. 版本管理：记录 embedding 模型版本、切块策略版本、入库时间，方便回溯和重建。

在这个过程中，日志是你最重要的 Debug 工具。我习惯让整个入库流程输出结构化日志，记录每个环节的关键指标，比如每页解析耗时、乱码率、切块数量、embedding 平均耗时、失败 chunk 数。上线后一旦检索效果异常，靠这些日志能快速定位到具体环节，而不是大海捞针。

举个例子：有一次用户反馈检索结果大量出现"第 X 页"这种无用内容，我第一时间查看解析日志，发现页脚过滤规则在某类新文档上失效了。类似问题如果没有日志，定位可能要花半天，有日志十分钟就搞定了。

结尾

从我这几年的实践经验来看，RAG 项目能不能稳定落地，入库环节的质量占了七成以上的决定因素。很多人一开始把精力全放在模型选型和 Prompt 调优上，结果上线后被检索质量反复打脸。与其这样，不如在入职库阶段多花点心思，把 PDF 解析、切块、向量化、索引验证每一个环节都做成可追踪、可评估、可回溯的工程链路。这套流程刚开始搭的时候确实繁琐，但一旦跑顺，后续新增文档几乎是无脑操作，而且检索效果稳定得让人安心。

最后再分享一个小技巧：把切块策略和 embedding 模型的版本信息写进 chunk 元数据里，看似不起眼，真到换模型、调参数的时候能帮你省下大量的排查时间。入库这件事，慢就是快，稳就是省心。