企业官网建设流程全解析

1. 准确率上不去？先承认一个反直觉的事实：RAG的最短板往往不在模型

做RAG项目的人，大概率都经历过这个循环：上线后效果不理想，第一反应是“换个更强的底座模型试试”，试了一圈发现答错的问题只挪了个位置，并没有消失。上个星期还有同事拿着评测结果来找我，说GPT-4o级别的模型在某些问题上照样胡编，最后我让他把知识库里检索出来的原文片段打出来看，他沉默了——原来系统压根没找到正确的段落。

这不是个别现象。RAG全链路里，大家天然把注意力放在“生成”这一头，因为模型的表现最直观、最容易被感知。但实际上，RAG的最短板的出现位置，往往比你想的要早得多——在文档进入系统之前，就已经决定了系统能答到什么程度。

1.1 RAG全链路拆解：模型只是最后一段

把一条RAG链路摊开看，它其实是这样的：

1. 文档接入：拿到PDF、Word、扫描件、网页等原始材料
2. 文档解析：把版式、表格、图片、公式从原始文件里“抠”出来
3. 文本清洗：去掉页眉页脚、乱码、水印、无关注释
4. 分块：按一定策略把长文本切成chunk，配合滑动窗口做重叠
5. 向量化：用embedding模型把chunk转成向量
6. 索引存储：进向量库、设置元数据过滤字段
7. 检索：根据用户问题做相似度召回
8. 重排与精排：对召回结果做相关性调整
9. 生成：把TopK片段拼进Prompt，交给大模型作答

很多团队优化RAG，动不动就调模型、换embedding、改Prompt，但回溯一下上面的链路会发现：第1到第6步，也就是文档进入向量库之前的全部环节，往往被当成了“理所当然的事”。一个最典型的场景是：PDF里一张表格被解析出来之后变成了乱序的纯文本，模型确实也“检索”到了这个片段，但里面信息是错的，它再怎么生成都是错。

1.2 把“答错”拆成三件事：是没找到、找到错的、还是理解错了

要定位问题，首先得把一个笼统的“答错”拆开。我在项目里一般把错误归成三类：

• 没找到：知识库里根本没有相关内容，或者有但没被召回。常见表现是模型回答说“根据现有资料无法确认”。
• 找到错的：召回结果跟问题相关，但里面没有答案，或者有答案但被切碎、被乱码污染。常见表现是模型一本正经地拿无关段落生成一个看似合理的回答，这就是典型的幻觉。
• 理解错了：召回内容是对的，但模型没有从中提炼出正确答案。常见表现是原文有明确答案，模型却答偏了。

这三类错误的修复方向完全不同。只有第三类是真正需要换模型、调Prompt去解决的；前两类问题，换再大的模型都没用。而前两类错误的根源，绝大部分都指向文档进入系统之前的那段工程链路。

所以，别急着替模型背锅。先从“文档进门”那一刻开始查起。

2. 文档在“进门”之前就坏了：解析环节的四大暗坑

文档解析是整个RAG项目里最无聊、最不被重视，但出事率最高的环节。它的目标只有一个：把原始文件里的所有信息“无损”地搬进系统。听起来简单，做起来全是坑。

2.1 扫描件和图片型PDF：不OCR，等于给系统喂天书

先看一个最极端的场景：拿到一批扫描版的书籍或合同，整个PDF就是一页页图片，没有任何文字层。如果你直接拿PyPDF2或者最朴素的解析方式提取文本，结果可能是空空如也，或者变成一张张整页截图。

这种文件，只能走OCR路线。我通常的组合是：

• 先用PaddleOCR或Tesseract做版面分析+文字识别
• 复杂的表格版式，配合PP-Structure这类结构化OCR工具

但OCR有个特别容易踩的坑：OCR输出的坐标信息如果没保留好，顺序就会乱。扫描件常见的是双栏排版，识别出来如果不做栏位判断，可能把左右两栏文字交叉拼接，读起来完全不通顺。所以如果你看到召回片段里的文字像“跳跃式”的，先怀疑版面判断没做好。

还有图像和表格内容：OCR只能识别文字，图片本身不会被还原。你可以在chunk里保留一段图文说明文本，但真正让模型“看图”需要多模态能力，或者让解析器把图片截取出来单独存储、用多模态模型描述后存为文字。具体取舍看你的场景：如果是知识库要存图片技术文档，建议走多模态链路；如果只是纯文本问答，OCR文字就够用了。

2.2 表格结构重建：RAG丢失信息最严重的重灾区

表格是RAG项目里最容易翻车的东西，没有之一。普通文本解析，顺序乱了顶多不通顺；表格解析乱掉，数字对不上号，答案直接变成错的。

我举一个真实案例：一份行业研报，里面有各家公司的季度营收对比表。原始表格结构是“行=公司，列=季度”。解析完之后变成了线性文本流，季度和数字被打乱，有的单元格甚至跑到了其他公司的名下。用户问“某公司Q3营收多少”，系统把Q2的数字当成了Q3，答案是错的。

这不是模型不行，是解析环节把表格拆坏了。解决这类问题，我的经验是按表格复杂度分级：

• 简单表格（结构规整、无合并单元格）：pdfplumber的extract_table函数就能拿到相对完整的二维数组，配合TableTransformer这类模型可以做单元格级别的还原，然后转成Markdown表格或HTML结构再入库。
• 复杂表格（合并单元格、多级表头、跨页）：推荐MinerU这类专门做结构化文档解析的工具，它对表格有自己的后处理手段，能把表格以HTML结构输出，保留合并关系。
• 完全花式的表格（扫描件中的复杂报表）：只能用OCR+版面分析硬啃，识别后还需要人工抽样校验。

另一个技巧是：不要把表格完全拍平成一个Markdown表格就扔进chunk里。超宽的表格（比如20列的数据）在分块后会被截断，表头也经常丢失。我更推荐先把表格转成“摘要式描述+关键行数据”，或者保留HTML结构并在分块时尽量让一个完整表格落在一个chunk内。

2.3 双栏排版、页眉页码与乱码：让语义分块分崩离析的小问题

比起表格，双栏排版问题更隐蔽，因为表面上文本提取得“很完整”。真实情况是：论文PDF是左右双栏的，解析器按页面物理顺序从上往下读，导致左边栏读到一半跳去右边栏、又跳回来，整段文字一句话被拦腰截断成两半。分块之后，这些切碎的片段会让检索质量急转直下。

页眉页脚也是经典问题。一份60页的PDF，每页顶部有公司名称，底部有页码，解析后如果不去除，向量化之后你会发现：检索“某公司2023年报”时，系统匹配到的全是页眉里那个公司名，真正的财报正文反而排到了后面。

乱码更麻烦。某些PDF字体编码异常，解析出来全是“锟斤拷”“口口口”这种替换字符。这些chunk索引进向量库，不影响相似度计算，但一旦被召回，模型就没法用了。还有隐藏水印：有些文档的页面背景嵌入了整页文字水印，光是复制PDF内容时能看到“本资料仅供参考”反复出现，如果不清理，检索时会被水印噪音严重干扰。

所以解析后必须有一道清洗工序，这个我在下一章展开说。

2.4 工具选型：从PyMuPDF到MinerU，适合的才是最好的

文档解析工具的选择，取决于你手里的材料类型。我把常用方案整理成一个表，方便对照参考：

其中，MinerU和Docling是最近社区讨论热度很高的两个开源项。之前我做一个金融项目时，用MinerU把一批招股说明书转成了Markdown结构化文本，表格、标题层级都很完整，后面分块和检索省了很多力气。注意一件事：解析结果一定要保存一份中间产物，比如统一的Markdown或JSON文件，不要只存在向量库里。排查问题的时候，这份中间产物就是你的案发现场。

3. 清洗、分块与索引：决定检索上限的“三座山”

解析完成之后，文本仍然是“刚从原生文档里剖出来”的原始状态。直接拿去分块、建索引，往往就是把脏数据永久固化。我习惯把这几个环节统称为“前处理”，它们共同决定了检索质量的上限——embedding和模型只是在这个上限内发挥。

3.1 脏数据清洗清单：看不见的页眉页脚、隐藏水印和乱码字符

清洗工序不复杂，但必须系统化地做。我在项目里会走一份固定的清洗清单：

• 页眉页脚/页码：用正则识别并剔除，比如页码一般是“第 X 页 / X / N”这类格式。注意不要误伤正文里的数字。
• 乱码替换字符：把“锟斤拷”“�”“口”这类替换符直接删掉，或者做字符集转码修复。
• 重复水印：识别整页重复出现的句子并剔除。有个粗暴但好用的方法：统计全文高频短句，如果某个句子出现频率异常高，且长度短，很可能就是水印。
• 多余空白与空行：把多个连续换行合并成段落分隔，避免分块时出现大量空块。
• 控制字符：剥离不可见的Unicode控制字符、零宽空格等，它们会影响分块和匹配。
• 编码修复：中文文档经常出现GBK和UTF-8混排，需要统一转码。

清洗之后，最好做一个可重复运行的pipeline。每次接入一批新文档，跑同样的解析+清洗流程，输出同样的结构化格式。别拿到一批文档就手工处理一次，那样既慢又容易漏。

3.2 分块策略：固定窗口、语义分块、父子分块怎么选

分块是前处理阶段最核心的决策。块太小，语义不完整，句子被切断；块太大，检索噪音多，向量化后特征被稀释。没有一个万能参数，要根据你的文本特性来定。

• 固定窗口+重叠（最常见）：比如chunk_size=512个token、overlap=50个token。重叠区域就是典型的滑动窗口思想，目的是让跨边界的信息至少在一个完整chunk里出现过。这个方案适合新闻、网页、通用说明文。
• 结构感知分块：按Markdown标题、段落、列表项来切。文档结构化解析做得好（比如用MinerU转出了带标题层级的Markdown），直接按标题切分是很稳的。注意标题层级要注入到chunk里，比如chunk开头带上“### 2.3 双栏排版”，检索时能大幅提升相关度。
• 语义分块：用embedding模型计算句向量之间的相似度，在“语义断裂处”切分。成本略高，但适合逻辑跳跃明显的材料。
• 父子分块（Parent-Child Chunking）：小chunk（比如128 token）负责召回匹配，同时保存其所属的父块（比如1024 token）。检索时用子块找位置，把父块喂给模型。这个方案是检索精度和上下文完整度之间的有效折中，尤其适合长文档QA。

另外一个容易忽略的细节：中文分词对token数的影响。512个token对于英文大约是380个词，对于中文大约是800到1000个汉字。如果你照抄英文项目的chunk_size，中文场景下块会偏大。建议先对一份真实文档做token统计，再定参数。

3.3 滑动窗口与上下文增强：把相邻片段的信息“缝合”起来

滑动窗口思想在RAG里不只是重叠分块那么简单。实际应用中还可以做两层“缝合”：

一是给模型喂回答上下文时，不只是召回的那一个chunk，而是把它的前后相邻1-2个chunk一并带上。因为很多答案的线索是跨段落分布的，比如“根据表2-1的数据可知”——如果你只召回到了“表2-1”的标题块，没有召回数据块，模型无法作答。把相邻上下文带上之后，这种跨块逻辑就能被弥补一些。

二是做“文档级滑动窗口”增强：把整段长文本切成多个固定窗口后，对每个窗口都做一次不完全重叠的窗口扩展，让每个chunk都携带前后一至两句话的“触角”。有研究显示，这种简单的滑动窗口扩展，比直接加overlap更能保持叙事完整性，代价是索引体积增加。

实操层面，我见过最省心的一种组合是：父块1024 token + 子块256 token + 子块滑动窗口128 token。召回子块，输出父块。对大段的研报、论文、产品文档都很友好。

3.4 索引与元数据：让检索有路可循

很多RAG项目只做“向量检索”，忽略元数据过滤，这会在知识库规模变大之后迅速遇到瓶颈。向量相似度适合找“语义近”的文本，但滤掉“来源错误”“类型不符”“时间过期”的内容，还得靠元数据。

我会给每个chunk至少打上这几类元数据：

• 来源：文件名、文档路径、URL
• 文档类型：研报、合同、技术文档、FAQ
• 章节路径：从顶级标题到当前标题的完整层级
• 时间戳：发布日期、更新日期
• 作者/部门（如果适用）

混合检索也是值得做的：BM25关键词检索与向量检索的结果做加权融合。比如用户问“2024年营收”，字面匹配很重要；用户问“公司今年赚钱了吗”，语义匹配更重要。我一般用RRF（Reciprocal Rank Fusion）把两路召回排序融合，实测稳定胜过单路向量。

4. 不花一分钱换模型，也能定位病根的验证方法

排查RAG问题，最忌讳的是“盲调”：一会儿改Prompt，一会儿换embedding，一会儿换模型，改了一圈，问题依旧。这里分享一套我在项目中反复使用的溯源验证法，核心思路是：用同一个模型做对照实验，逐段缩小嫌疑范围。

4.1 三层溯源法：用同一个模型找出问题环节

先准备好一组已知答案的问题集（不用多，20到50条足够），对每条问题做如下三层检查：

第一层：检查召回结果。

把检索TopK出来的chunk直接展示出来，不看模型输出。问自己两个问题：

1. 正确的信息在不在这些chunk里？
2. 排序靠前的chunk是不是相关？

如果正确信息压根没出现，那模型再强也无济于事，问题在检索链路上游：解析、分块、embedding、索引。

第二层：把召回chunk直接拼给模型。

手动构造一个Prompt：“以下是参考资料：…… 请根据资料回答问题：……”，把召回的内容原样拼进去，看模型能不能答对。

• 如果模型能答对，说明模型能力没问题，问题出在系统Prompt把模型带偏了，或者你用了太复杂的指令把它的注意力带歪了。
• 如果模型答不对，再看chunk本身质量。

第三层：阅读chunk原文。

直接在中间产物（解析后的Markdown或JSON）里搜答案的关键词。看看原文到底长什么样：

• 文字是否乱序、乱码？
• 表格数字是否错位？
• 答案是否被分块拦腰截断？
• 内容是否来自页眉页脚这类噪音？

到这一层，前端问题就完全暴露了。你不需要换任何模型，就能把责任定位到具体环节。

4.2 构建一个30问的最小评估集

排查类的工作，最怕没有基准。我强烈建议每个RAG项目都维护一份“真值清单”：30到50条有标准答案的问题，每条对应文档里的具体参照段落。

构建清单时注意覆盖三类问题：

• 直接抽取型：“某公司的注册资本是多少？”——考精确查找能力
• 总结归纳型：“这个产品的三大优势是什么？”——考跨段落整合能力
• 推理判断型：“如果应收账款增加，对现金流可能有什么影响？”——考知识加工能力

有了这份清单，每次改动前跑一遍，记录“召回正确率”和“最终正确率”两个指标。前者看检索层，后者看整体链路。两个指标差异很大，说明问题多半在生成端；差异很小但都低，说明前端还有硬伤。

4.3 从“召回结果”到“错误类型”对照表

最后把排查结果落到表格里，后续看问题会清晰得多。我常用的对应关系大概是这样：

这张表看起来简单，但是在项目里特别实用。它能帮你把“模模糊糊觉得系统不对”变成“某项指标明确不合格”，处理起来就有了抓手。

5. 一次真实排错复盘：从“换模型”到“重建知识库”

做个复盘吧，上个月处理的一个真实案例，完整还原一下排查链路。

5.1 第一次误判：以为模型太弱

客户反馈：内部知识问答系统在回答“截至2024年底，某项目累计成交金额是多少”时给出了错误数字。当时大家的直觉是模型理解力不足，或者Prompt引导不到位，计划换一个更强的模型。

我的建议是先别换，打开日志看召回。于是我把这个问题的TopK召回片段拉出来，发现：系统确实召回了相关表格所在的chunk，而且这个chunk在向量相似度排序里排第一，看起来一切正常。

5.2 顺着链条往下挖：召回结果不对劲

但把召回片段做人工阅读后，问题立刻出现了。片段里虽然有“累计成交金额”这几个字，但后面的数字和文档原文对不上：原文是“1,286万元”，召回片段里变成了“1,268万元”。

这说明文本是从某种解析结果里来的，但数字已经被改写过。于是我去翻了解析中间产物，发现表格被解析成了一张结构错乱的二维数组：部分单元格内容串位，列标题和数值对应关系被打破。更关键的是，这个错乱发生在文档刚进系统的那一步，后续所有环节都在忠实传递这个错误。

5.3 病根确认：PDF表格数字被“重新编码”

进一步排查发现，这份PDF本身是扫描件，最初走的是一条“先用OCR识别文字、再用规则提取表格”的流程。OCR对数字的识别本身有误差，同时表格线的断裂又导致列位置判断错误，两个问题叠加，最终产出了那份错位数据。

这里要补充一个惨痛教训：当时解析出来的中间产物没有保留原始图片块，也没做OCR置信度校验。如果我们一开始就在解析层面对数字字段做“OCR置信度低于阈值则标记待人工复核”的逻辑，这批坏数据根本不会进到知识库里。 升级方案是把这批PDF换成MinerU的结构化解析链路，其自带表格结构重建对扫描版式明显更稳。同时我在清洗环节加了数字抽查逻辑：用正则抓取文档中“万元”“亿元”附近的数字，和人工标注的结果做抽样比对，一旦发现异常率高，就停止入库并人工介入。

5.4 重建知识库后的前后对比

重建知识库后，同一道题的召回片段里数字正确了，模型答案自然也就正确了。整个过程没有更换大模型、没有调Prompt，只动了文档进门之前的那段链路。

这件事给我的感触很深：遇到RAG答错的场景，首先默认是前处理问题，再去怀疑模型。因为模型是通用能力，前处理是你的专属数据管道。前者是标准件，后者才是真正藏着项目差异和风险的地方。

几点经验，送给正在被RAG准确率折磨的人

如果你现在正被“答非所问”困扰，我的建议是：先别急着打开模型配置页。花半天时间，把你最头疼的10个问题拿出来，走一遍上面的溯源流程，看看问题到底出在第几环。

最后分享一个实操技巧：从接入第一批文档开始，就把解析后的结构化中间产物（Markdown或JSON）单独存一份，并且给每个chunk生成时记录来源文件名和章节路径。等到排查问题时，这三样东西——中间产物、chunk与来源的映射、召回日志——会帮你省出大把时间。文档解析、清洗、分块这些“脏活累活”，才是RAG项目真正的护城河。