“收藏备用！RAG知识库文档处理实操”，这个标题我第一眼看到就想点头。做RAG知识库的人，谁没被文档处理折磨过？模型选型、Prompt优化这些话题都是热热闹闹的技术高地，结果真正把项目拖死的，往往是最朴素的一步——文档没处理好。纯文本没抽对、表格全碎、切分切得语义崩坏，后面所有环节都在给糟糕的数据填坑。这篇我打算专门聊聊RAG知识库文档处理这件事。你会发现这个环节几乎没有放之四海皆准的标准答案：同样的chunk_size，在技术文档里好使，搬到合同上就翻车；同样的清洗规则，对爬虫网页有效，对扫描PDF就是灾难。所以我的观点一直很明确：没有标准，只看效果。围绕你的文档、你的场景、你的评估指标，把流程跑通、把问题暴露出来、再一个个解决。这篇内容主要面向初次搭建RAG知识库的小白，以及被要求“把这堆文档做成知识库”的一线程序员。1. RAG落地第一步：先把文档“捋顺”，再谈调模型1.1 为什么文档处理能直接决定RAG成败很多人接到RAG任务，第一反应是研究大模型选型、调Prompt、搭向量数据库，这其实是走反了。RAG的信息流大致是：文档 → 解析 → 切块 → 向量化 → 入库 → 检索 → 灌给大模型生成答案。这条链路除了最后一步生成，前面每一步的产出物都是“文本片段”。这意味着，大模型再聪明，它实际能看到的也只有后端喂给它的那几段文本。如果文档在进入向量库之前就已经千疮百孔——表格被拆没了、标题层级丢了、同一知识点被切散到不同chunk、页眉页脚混进正文——那召回质量就是空中楼阁，模型答得好坏全看运气。我接触过某团队的项目，他们花了两周时间换模型、调模板，回答质量始终上不去。后来我抽了一批他们知识库里的PDF，发现文本抽取阶段就把排版信息全丢了，整篇文档变成一坨连续字符，chunk切完以后是语义不明的碎片。检索的时候偶尔命中，命中了数据也不全。问题根本不在模型层，而在于喂给模型的原料本身就是坏的。1.2 “没有标准，只看效果”到底是什么意思这个标题里最值得琢磨的就是这句话。网上的文档处理教程，最坑人的就是给你一张“最佳实践参数表”，好像照着填就能出成果。但实际情况是：同样的切分参数，用在一份章节清晰的操作手册上可能很顺，用在一堆扫描合同上就完全跑偏。文档类型、用户提问方式、embedding模型能力、乃至最终答案的呈现形态，都会影响你对处理策略的选择。靠谱的做法只有一条：建立你自己的评估集，然后围绕效果持续迭代。评估集不用多复杂，找20到50个真实业务问题，提前标注标准答案（或者标注答案来自哪份文档的哪个章节）。每一次调整文档处理策略，就把这些问题跑一遍检索，统计召回命中率和最终答案的可接受度。“没有标准”指的就是：参数和规则没有通用标准，识别手段和清洗逻辑都得看具体内容。“只看效果”则是指：你要定义自己业务的验收指标，拿数据说话，而不是迷信任何教程给出来的推荐值。1.3 先定指标，再动手改参数很多人做RAG效果调优，最大的问题是拍脑袋。改一个参数就去问几句测试问题，问的还都是同一批问题，感觉差不多了就收工。这完全不是科学调试的路子。我建议在动手之前先明确几个核心指标：检索命中率（理想命中文档/总测试问题数）、答案准确率（人工判断回答是否正确可用）、无答案率（该答出的问题有几条直接放弃回答）。这三个指标能帮你快速定位问题层级：命中率低，问题多半在解析或切分；命中率高但准确率低，问题多半在检索排序或Prompt组织；无答案率高，则要回到检索数量和重排策略上。这个评估习惯一旦养成，你会发现后面所有参数调整都变得有据可依。改一个overlap，跑一遍评估集，数据上升就保留，数据下降就回滚。这才是工程师该有的工作方式。2. 核心细节解析与实操要点2.1 文档加载：PDF、Word、Markdown，脾气完全不同文档处理第一步，是把原始文件变成干净的纯文本。这一步的难度远超想象，而难点恰恰在于各类格式的特性差异。PDF要先分清“文本型”和“扫描件”文本型PDF的文字是以文本对象形式存在的，调用解析库可以直接提取。扫描件PDF本质是图片，必须先走OCR，否则提取到的是空白或者乱码。一个经典坑是：网上不少教程从没提过这两个流派，导致小白拿一批扫描合同去解析，怎么处理都是空的，还以为是库的问题。判断方法很简单，在阅读器里试着用鼠标框选文字，能选中就是文本型；选不中就大概率是扫描件，得用OCR工具过一遍。解析库方面，我常用的是PyMuPDF和pdfplumber的组合。PyMuPDF速度快、对文本型PDF兼容性好，适合大批量抽取；pdfplumber擅长定位表格和精确坐标，遇到需要保留表格结构的页面，我会单独拿它处理。还有经常被提到的Unstructured，对各种格式的适应性广，能把文本、表格、图片分别抽取，缺点是比较重、慢，在服务器环境部署起来略折腾。Word文档要小心“形式上的Word”docx本身就是XML结构，段落、表格、样式都以节点形式存在，所以可以用python-docx做到“保结构提取”，而不像PDF那样靠坐标去猜。但这里有个大坑：很多企业内部的知识库Word文档，实质内容装在文本框、图片、SmartArt里，常规提取时会被悄悄丢掉。如果你发现文档处理完后内容莫名少了一截，多半就是这些元素没被处理。Markdown是RAG最友好的格式Markdown自带标题、列表、代码块语义，切分时可以参照标题层级来划定区块，精度比其他格式好不少。所以我在能转Markdown的场景下一定优先转，能不用PDF尽量不用PDF。这不是偷懒，而是让下游切分和检索省掉大量麻烦。这里整理一个格式处理速查表，方便对照：格式常见问题推荐解析方案切分提示文本型PDF排版信息丢失、断行PyMuPDF / pdfplumber按标题和段落切分扫描件PDF提取为空、乱码OCR（如PaddleOCR）先识别再按文本处理Word文本框、图片内容丢失python-docx遍历节点保留段落和表格结构Markdown相对省心直接解析即可按标题层级切分2.2 切分策略：无脑固定字数切分的坑在哪切分目标很简单：让每个chunk成为一个语义相对完整、能独立回答问题的小单元。但实际做的时候，很多人图省事，直接按字符数硬切，比如每500字符一切，重叠50字符。这个方案最大的问题是完全不考虑文本本身的语义边界。举个具体例子。产品说明书的“故障排查”章节，可能在第498字符处被一刀切开：前半段描述故障现象，后半段才给出解决方案。用户问“设备报E02错误怎么办”，检索系统把包含现象描述的chunk召回，里面没有解法；真正的解法chunk因为排位靠后没被召回。大模型对着残缺信息只能硬编一个答案。这种问题在固定长度切分下会反复出现。我的建议是“结构化切分优先，长度控制兜底”。对标题层级清晰的Markdown或Word，先按标题把文档拆成章节，再检查章节长度是否超标；对结构不明显的论文、合同，可以用滑窗式语义切分，或者至少在固定长度切分时把overlap调大，降低语义断裂的代价。overlap的作用是给相邻chunk创造缓冲区，减少上下文被切断的概率。overlap太小等于没设，overlap太大又会让同一段文本在多个chunk里重复，浪费token、增加检索噪音。我日常用得比较多的是chunk_size 400到800、overlap 50到100这个区间。这几组值完全可以用你自己的评估集去试，从一组基础值出发，向两个方向各调几档，记录指标变化，最后确定最合适的一档。2.3 清洗、表格与特殊内容：不是越干净越好抽取出来的原始文本远没有想象中干净。页眉页脚、页码、目录、水印文字、版权声明，还有PDF常见的自动换行断点，都会混进正文。这些噪音不清理，轻则浪费存储，重则让chunk语义混乱。我一般会做四类清洗：去掉页码、页眉页脚、目录行；修复PDF断行；删除水印和版权类文字；压缩多余空行、统一全角半角。但清洗规则一定要和你的真实样本匹配，克制是第一原则。我见过有人用爬虫级别的清洗规则去处理合同，结果把合同编号和分条结构全删了，效果反而更差。清洗宁可保守，保留一点噪音也别误伤正文。表格是另一个重灾区。RAG对表格的理解天生弱，直接把表格拍平成纯文本，检索效果很差。常见做法有两种：一种是转成Markdown格式表格，保留分隔符，让模型能理解行列关系；另一种是给表格生成摘要文本，比如“本表记录2023年各季度销售额，按华东、华北分行展示”。实测下来，信息密度极高的实验数据表、财务报表，用“表格摘要+原始表格文本”双轨入库，效果明显强于只塞纯文本。图像信息同样不能忽略。很多架构图、流程图、数据图表，在文本抽取后直接消失。如果知识库高度依赖图，需要把图片提取出来交给多模态模型生成文字描述，再连同原图路径一起入库。尤其操作手册里的接线图、按钮位置图，纯文字根本覆盖不了，图像描述这一环必须补上。3. 实操过程与核心环节实现3.1 一套可直接复用的文档处理管道下面给出一套我用过很多次的处理流程，覆盖PDF抽取、清洗、结构化切分和元数据构建。代码保持精简，核心逻辑完整，你可以在此基础上加自己的规则。首先是PDF文本抽取。文本型PDF用PyMuPDF，遇到表格再用pdfplumber补一刀：import fitz # PyMuPDF import re def extract_pdf_text(pdf_path): doc = fitz.open(pdf_path) pages = [] for page_num in range(doc.page_count): page = doc[page_num] text = page.get_text("text") pages.append({ "page": page_num + 1, "text": text }) doc.close() return pages这个函数把每页文本单独保留并记下页码，方便后续重建元数据。如果是扫描件PDF，这个函数还不够，要先跑OCR再进入后续流程。然后是清洗层。我习惯写一个清洗函数，把页眉页脚、页码、意外断行一次性处理掉：def clean_text(raw_text: str) -> str: lines = raw_text.split("\n") cleaned_lines = [] for line in lines: stripped = line.strip() # 跳过纯数字页码 if re.fullmatch(r"\d{1,4}", stripped): continue # 跳过 "第X页" / "Page X" 形式 if re.fullmatch(r"(第)?\s*\d+\s*页?\s*/?\s*(Page\s*)?\d+", stripped, re.I): continue cleaned_lines.append(stripped) # 合并断行：行尾没有句末标点，大概率是自动换行 text = "\n".join(cleaned_lines) text = re.sub(r"(?<![。！？；：])\n", "", text) # 压缩多余空白 text = re.sub(r"[ \t]+", " ", text) text = re.sub(r"\n{3,}", "\n\n", text) return text注意，这个清洗函数的合并断行规则是我针对技术文档类样本调的，用在合同或论文上误伤风险会增加。每次换新文档类型，建议先抽几份文本人工检查清洗效果，再决定规则要不要改。然后是结构化切分。按Markdown标题切分是知识库里最常见且最稳的策略：def split_by_headings(markdown_text: str): lines = markdown_text.split("\n") chunks = [] current_title = "未命名章节" current_section = [] for line in lines: if re.match(r"^#{1,6}\s", line): if current_section: chunks.append({ "title": current_title, "content": "\n".join(current_section).strip() }) current_title = line.strip("# ").strip() current_section = [line] else: current_section.append(line) if current_section: chunks.append({ "title": current_title, "content": "\n".join(current_section).strip() }) return chunks这个函数按标题把文章拆成多个小节，每个chunk自带title，后续做元数据和检索过滤都很方便。注意表格内容在切分时容易被切断，如果文档里表格较多，切分后要检查一遍表格完整性。3.2 向量化、检索验证与参数调优文档处理好、向量化入库之后，不意味着可以高枕无忧。我强烈建议把“检索验证”当作文档处理阶段的一部分来完成，而不是等系统上线后再回头排查。所谓检索验证，就是拿着人工准备的问题，先用“只检索不生成”的模式跑一遍，看看系统到底招回了哪几块文本。这一步非常关键，它能帮你分清是索引有问题还是生成有问题。如果召回结果本身就答非所问，模型再强也白搭；如果召回正确但最终答案乱编，那要改的是Prompt和生成链路。我之前的某个内部知识库迭代，就建了一个30条问题的评估集，全部来自真实高频提问，每条标注了“应召回的章节”。每次调整切分策略或embedding模型，就跑一遍评估集统计命中率变化。这种土办法最直接，一周内就把命中率从不到50%拉到80%以上。embedding模型的选择同样直接影响效果。中文场景下，通用领域可以直接用常见的中文embedding模型；法律、医疗、金融这类垂直领域，文档术语特征强，通用模型未必好用，必须实测。判断embedding好坏有个很土的办法：拿几组语义相近但主题不同的句子查相似度，看模型能不能分清。如果相近类别混得厉害，就要考虑换更强的嵌入模型。3.3 检索返回数量与重排：不只盯着TopK还有一个容易被忽略的参数是检索返回条数。默认TopK=4或5在很多场景下不够用，因为chunk切得小而分散，信息分布比较碎；chunk切得大而冗余时，5条又会混入大量无关内容。我一般先在检索层返回10到20条，再做重排或相似度过滤，最后筛出真正喂给大模型的那几条。重排这块我现在基本必上。开源和商业化重排模型都有，成本不高，但效果提升很大。尤其当知识库规模变大、相似chunk互相干扰时，重排模型能有效把最匹配的几条顶到前面，最终答案质量的提升很明显。建议不要跳过这一步，它属于性价比极高的一笔投入。4. 常见问题与排查技巧实录4.1 检索不到内容怎么办这是RAG落地最典型的症状：文档里明明有，系统却回答“没有相关内容”。排查应该沿着一条线走下来，别上来就怀疑模型。第一步，确认文档真的入库了。检查向量库里有没有对应记录、chunk数量是否和预期一致。很多入库程序会静默失败，比如某类PDF解析返回空文本，程序没报错只是没存进数据，结果知识库就悄悄少了一块。第二步，抽查切分后的文本。随机打印几个chunk看内容，如果本身是乱码、缺字、表格碎片，问题就在解析环节。第三步，检查提问与文档术语粒度是否匹配。文档里写的是专业缩写，用户问的是完整名称，检索失败十分正常。这时候可以考虑在切出来的chunk里补充别名和同义词元数据。第四步，再看检索方式。有些场景只靠向量检索可能不够，需要配合关键词检索做混合召回。工程实现不复杂，但对“检索不到”的改善立竿见影。这里整理一个排查速查表，按顺序走即可：现象排查动作常见根因解决方向检索为空查向量库记录入库静默失败检查解析返回结果召回乱码打印chunk解析环节问题换解析库或补OCR语义匹配差跑评估集术语不匹配补充同义词/别名检索覆盖不足检查召回方式单一向量检索增加关键词混合召回4.2 回答张冠李戴怎么办能检索到内容，但大模型把A产品的方案套到B产品头上，这也很常见。根源通常是召回的chunk混入了一些同主题不同实体的内容，大模型缺少足够“身份信息”来区分。一种有效做法是给每个chunk注入更丰富的身份标识，把实体名称、适用范围、文档来源写进元数据，并在生成上下文里作为前缀拼接。比如用户问“型号A”，就在上下文里明确标出哪些内容来自型号A的章节。另一种做法是增加一道实体校验，在召回后过滤掉与提问实体明显冲突的chunk。这条规则实现很轻，但对答准率帮助很大。还有一种常见情况，是大模型基于多个chunk“缝合”出了混合答案。把Prompt改成严格基于提供资料作答，要求模型在拿不准时明说不知道，并输出文档标题作为依据来源。这既提高答案可信度，也帮用户判断信息出处是否可靠。4.3 表格、多栏文档和图片怎么处理前面说过表格的基本思路，这里讲一个真实案例。处理一份几十个价格表的商品手册时，最初简单把表格转纯文本，用户问“某型号耗材多少钱”，系统老是召回一堆杂乱数字。后来改成先用表格摘要文本锁定表格主题，再保留原始Markdown表格作为生成依据，效果立刻改观。摘要负责“让检索找到正确的表”，原始表格负责“让生成算出正确的数”，分工明确。多栏文档是PDF独有的痛点，两栏排版的论文、宣传册，抽取时常把左右两栏文字穿插到一起。遇到这种文档，我会先用pdfplumber按坐标分栏抽取，或者用基于布局的工具处理。实在处理不了，就考虑转成图片丢给多模态模型识别。没有万能解法，但值得为高频出现的多栏文档类型写专属解析规则，因为这类文档往往信息密度最高。图片入库的思路前面也提过，这里补充一点细节：一张配图的操作说明，如果只存了段落文字而没存图片描述，信息就是残缺的。我通常把图片交给多模态模型生成文本描述，然后连同原图路径一起入库。检索时，文本描述负责把用户问题引导到正确位置，原图路径则可以提供给前端作可视化展示。这一步多花一点成本，但知识库的可用性直接上一个台阶。4.4 性能与成本的三个实用建议最后聊点后端上线后的取舍。RAG的文档量会越滚越大，处理管线的稳健性比花哨更重要。第一，入库前做去重和版本管理。同一份内容以不同文件名或不同格式反复塞进知识库，会产生大量相似chunk，检索时互相干扰。建议入库前跑一遍内容哈希或相似度比对，重复的直接跳过；文档迭代更新时，先删旧版再入新版。第二，利用缓存减少向量化次数。切分后的chunk向量化是主要成本来源，只要内容没变，没必要重复调用接口。可以把文本哈希和向量一起存进数据库，下次入库前先查一下，已经存在的直接把向量取出来复用，能省下不少费用。第三，合理使用批量处理。调用embedding接口时，把一批文本传入接口比一条条循环调用快得多，一般SDK原生支持批量参数，很多人习惯写循环，白白浪费时间和预算。改成批量处理后，大批量文档的处理时常能压缩到原来的十分之一。最后再分享两个实操体会第一，RAG知识库的第一版永远不要贪大求全。先挑一块业务最核心、格式最规范的文档，把全流程跑通，再逐步扩展。一上来什么格式都往库里塞，出问题后连是哪一类文档导致的都定位不出来，排错成本直接爆炸。第二，无论采用哪套文档处理流程，务必把每个环节的中间产物留一份。文本抽取后的纯文本、清洗后的版本、切分后的chunk列表，全部存下来。这样做不仅能随时复盘，还能在效果回退时快速定位是哪一步改动引起的。我后面维护知识库时经常需要回看两周前的清洗规则和切分参数，如果没有这些中间副本，光凭记忆根本还原不了。文档处理这件事，在RAG项目里最不起眼，却直接决定整个系统的上限。与其反复折腾模型技巧，不如沉下心来把文档这层地基打牢。调试久了你会发现，知识库表现好不好的答案，往往藏在那些看似枯燥的数据细节里。希望这篇笔记里的土办法和踩坑记录，能帮你少走几段弯路。
“收藏备用！RAG知识库文档处理实操”，这个标题我第一眼看到就想点头。做RAG知识库的人，谁没被文档处理折磨过？模型选型、Prompt优化这些话题都是热热闹闹的技术高地，结果真正把项目拖死的，往往是最朴素的一步——文档没处理好。纯文本没抽对、表格全碎、切分切得语义崩坏，后面所有环节都在给糟糕的数据填坑。这篇我打算专门聊聊RAG知识库文档处理这件事。你会发现这个环节几乎没有放之四海皆准的标准答案：同样的chunk_size，在技术文档里好使，搬到合同上就翻车；同样的清洗规则，对爬虫网页有效，对扫描PDF就是灾难。所以我的观点一直很明确：没有标准，只看效果。围绕你的文档、你的场景、你的评估指标，把流程跑通、把问题暴露出来、再一个个解决。这篇内容主要面向初次搭建RAG知识库的小白，以及被要求“把这堆文档做成知识库”的一线程序员。1. RAG落地第一步：先把文档“捋顺”，再谈调模型1.1 为什么文档处理能直接决定RAG成败很多人接到RAG任务，第一反应是研究大模型选型、调Prompt、搭向量数据库，这其实是走反了。RAG的信息流大致是：文档 → 解析 → 切块 → 向量化 → 入库 → 检索 → 灌给大模型生成答案。这条链路除了最后一步生成，前面每一步的产出物都是“文本片段”。这意味着，大模型再聪明，它实际能看到的也只有后端喂给它的那几段文本。如果文档在进入向量库之前就已经千疮百孔——表格被拆没了、标题层级丢了、同一知识点被切散到不同chunk、页眉页脚混进正文——那召回质量就是空中楼阁，模型答得好坏全看运气。我接触过某团队的项目，他们花了两周时间换模型、调模板，回答质量始终上不去。后来我抽了一批他们知识库里的PDF，发现文本抽取阶段就把排版信息全丢了，整篇文档变成一坨连续字符，chunk切完以后是语义不明的碎片。检索的时候偶尔命中，命中了数据也不全。问题根本不在模型层，而在于喂给模型的原料本身就是坏的。1.2 “没有标准，只看效果”到底是什么意思这个标题里最值得琢磨的就是这句话。网上的文档处理教程，最坑人的就是给你一张“最佳实践参数表”，好像照着填就能出成果。但实际情况是：同样的切分参数，用在一份章节清晰的操作手册上可能很顺，用在一堆扫描合同上就完全跑偏。文档类型、用户提问方式、embedding模型能力、乃至最终答案的呈现形态，都会影响你对处理策略的选择。靠谱的做法只有一条：建立你自己的评估集，然后围绕效果持续迭代。评估集不用多复杂，找20到50个真实业务问题，提前标注标准答案（或者标注答案来自哪份文档的哪个章节）。每一次调整文档处理策略，就把这些问题跑一遍检索，统计召回命中率和最终答案的可接受度。“没有标准”指的就是：参数和规则没有通用标准，识别手段和清洗逻辑都得看具体内容。“只看效果”则是指：你要定义自己业务的验收指标，拿数据说话，而不是迷信任何教程给出来的推荐值。1.3 先定指标，再动手改参数很多人做RAG效果调优，最大的问题是拍脑袋。改一个参数就去问几句测试问题，问的还都是同一批问题，感觉差不多了就收工。这完全不是科学调试的路子。我建议在动手之前先明确几个核心指标：检索命中率（理想命中文档/总测试问题数）、答案准确率（人工判断回答是否正确可用）、无答案率（该答出的问题有几条直接放弃回答）。这三个指标能帮你快速定位问题层级：命中率低，问题多半在解析或切分；命中率高但准确率低，问题多半在检索排序或Prompt组织；无答案率高，则要回到检索数量和重排策略上。这个评估习惯一旦养成，你会发现后面所有参数调整都变得有据可依。改一个overlap，跑一遍评估集，数据上升就保留，数据下降就回滚。这才是工程师该有的工作方式。2. 核心细节解析与实操要点2.1 文档加载：PDF、Word、Markdown，脾气完全不同文档处理第一步，是把原始文件变成干净的纯文本。这一步的难度远超想象，而难点恰恰在于各类格式的特性差异。PDF要先分清“文本型”和“扫描件”文本型PDF的文字是以文本对象形式存在的，调用解析库可以直接提取。扫描件PDF本质是图片，必须先走OCR，否则提取到的是空白或者乱码。一个经典坑是：网上不少教程从没提过这两个流派，导致小白拿一批扫描合同去解析，怎么处理都是空的，还以为是库的问题。判断方法很简单，在阅读器里试着用鼠标框选文字，能选中就是文本型；选不中就大概率是扫描件，得用OCR工具过一遍。解析库方面，我常用的是PyMuPDF和pdfplumber的组合。PyMuPDF速度快、对文本型PDF兼容性好，适合大批量抽取；pdfplumber擅长定位表格和精确坐标，遇到需要保留表格结构的页面，我会单独拿它处理。还有经常被提到的Unstructured，对各种格式的适应性广，能把文本、表格、图片分别抽取，缺点是比较重、慢，在服务器环境部署起来略折腾。Word文档要小心“形式上的Word”docx本身就是XML结构，段落、表格、样式都以节点形式存在，所以可以用python-docx做到“保结构提取”，而不像PDF那样靠坐标去猜。但这里有个大坑：很多企业内部的知识库Word文档，实质内容装在文本框、图片、SmartArt里，常规提取时会被悄悄丢掉。如果你发现文档处理完后内容莫名少了一截，多半就是这些元素没被处理。Markdown是RAG最友好的格式Markdown自带标题、列表、代码块语义，切分时可以参照标题层级来划定区块，精度比其他格式好不少。所以我在能转Markdown的场景下一定优先转，能不用PDF尽量不用PDF。这不是偷懒，而是让下游切分和检索省掉大量麻烦。这里整理一个格式处理速查表，方便对照：格式常见问题推荐解析方案切分提示文本型PDF排版信息丢失、断行PyMuPDF / pdfplumber按标题和段落切分扫描件PDF提取为空、乱码OCR（如PaddleOCR）先识别再按文本处理Word文本框、图片内容丢失python-docx遍历节点保留段落和表格结构Markdown相对省心直接解析即可按标题层级切分2.2 切分策略：无脑固定字数切分的坑在哪切分目标很简单：让每个chunk成为一个语义相对完整、能独立回答问题的小单元。但实际做的时候，很多人图省事，直接按字符数硬切，比如每500字符一切，重叠50字符。这个方案最大的问题是完全不考虑文本本身的语义边界。举个具体例子。产品说明书的“故障排查”章节，可能在第498字符处被一刀切开：前半段描述故障现象，后半段才给出解决方案。用户问“设备报E02错误怎么办”，检索系统把包含现象描述的chunk召回，里面没有解法；真正的解法chunk因为排位靠后没被召回。大模型对着残缺信息只能硬编一个答案。这种问题在固定长度切分下会反复出现。我的建议是“结构化切分优先，长度控制兜底”。对标题层级清晰的Markdown或Word，先按标题把文档拆成章节，再检查章节长度是否超标；对结构不明显的论文、合同，可以用滑窗式语义切分，或者至少在固定长度切分时把overlap调大，降低语义断裂的代价。overlap的作用是给相邻chunk创造缓冲区，减少上下文被切断的概率。overlap太小等于没设，overlap太大又会让同一段文本在多个chunk里重复，浪费token、增加检索噪音。我日常用得比较多的是chunk_size 400到800、overlap 50到100这个区间。这几组值完全可以用你自己的评估集去试，从一组基础值出发，向两个方向各调几档，记录指标变化，最后确定最合适的一档。2.3 清洗、表格与特殊内容：不是越干净越好抽取出来的原始文本远没有想象中干净。页眉页脚、页码、目录、水印文字、版权声明，还有PDF常见的自动换行断点，都会混进正文。这些噪音不清理，轻则浪费存储，重则让chunk语义混乱。我一般会做四类清洗：去掉页码、页眉页脚、目录行；修复PDF断行；删除水印和版权类文字；压缩多余空行、统一全角半角。但清洗规则一定要和你的真实样本匹配，克制是第一原则。我见过有人用爬虫级别的清洗规则去处理合同，结果把合同编号和分条结构全删了，效果反而更差。清洗宁可保守，保留一点噪音也别误伤正文。表格是另一个重灾区。RAG对表格的理解天生弱，直接把表格拍平成纯文本，检索效果很差。常见做法有两种：一种是转成Markdown格式表格，保留分隔符，让模型能理解行列关系；另一种是给表格生成摘要文本，比如“本表记录2023年各季度销售额，按华东、华北分行展示”。实测下来，信息密度极高的实验数据表、财务报表，用“表格摘要+原始表格文本”双轨入库，效果明显强于只塞纯文本。图像信息同样不能忽略。很多架构图、流程图、数据图表，在文本抽取后直接消失。如果知识库高度依赖图，需要把图片提取出来交给多模态模型生成文字描述，再连同原图路径一起入库。尤其操作手册里的接线图、按钮位置图，纯文字根本覆盖不了，图像描述这一环必须补上。3. 实操过程与核心环节实现3.1 一套可直接复用的文档处理管道下面给出一套我用过很多次的处理流程，覆盖PDF抽取、清洗、结构化切分和元数据构建。代码保持精简，核心逻辑完整，你可以在此基础上加自己的规则。首先是PDF文本抽取。文本型PDF用PyMuPDF，遇到表格再用pdfplumber补一刀：import fitz # PyMuPDF import re def extract_pdf_text(pdf_path): doc = fitz.open(pdf_path) pages = [] for page_num in range(doc.page_count): page = doc[page_num] text = page.get_text("text") pages.append({ "page": page_num + 1, "text": text }) doc.close() return pages这个函数把每页文本单独保留并记下页码，方便后续重建元数据。如果是扫描件PDF，这个函数还不够，要先跑OCR再进入后续流程。然后是清洗层。我习惯写一个清洗函数，把页眉页脚、页码、意外断行一次性处理掉：def clean_text(raw_text: str) -> str: lines = raw_text.split("\n") cleaned_lines = [] for line in lines: stripped = line.strip() # 跳过纯数字页码 if re.fullmatch(r"\d{1,4}", stripped): continue # 跳过 "第X页" / "Page X" 形式 if re.fullmatch(r"(第)?\s*\d+\s*页?\s*/?\s*(Page\s*)?\d+", stripped, re.I): continue cleaned_lines.append(stripped) # 合并断行：行尾没有句末标点，大概率是自动换行 text = "\n".join(cleaned_lines) text = re.sub(r"(?<![。！？；：])\n", "", text) # 压缩多余空白 text = re.sub(r"[ \t]+", " ", text) text = re.sub(r"\n{3,}", "\n\n", text) return text注意，这个清洗函数的合并断行规则是我针对技术文档类样本调的，用在合同或论文上误伤风险会增加。每次换新文档类型，建议先抽几份文本人工检查清洗效果，再决定规则要不要改。然后是结构化切分。按Markdown标题切分是知识库里最常见且最稳的策略：def split_by_headings(markdown_text: str): lines = markdown_text.split("\n") chunks = [] current_title = "未命名章节" current_section = [] for line in lines: if re.match(r"^#{1,6}\s", line): if current_section: chunks.append({ "title": current_title, "content": "\n".join(current_section).strip() }) current_title = line.strip("# ").strip() current_section = [line] else: current_section.append(line) if current_section: chunks.append({ "title": current_title, "content": "\n".join(current_section).strip() }) return chunks这个函数按标题把文章拆成多个小节，每个chunk自带title，后续做元数据和检索过滤都很方便。注意表格内容在切分时容易被切断，如果文档里表格较多，切分后要检查一遍表格完整性。3.2 向量化、检索验证与参数调优文档处理好、向量化入库之后，不意味着可以高枕无忧。我强烈建议把“检索验证”当作文档处理阶段的一部分来完成，而不是等系统上线后再回头排查。所谓检索验证，就是拿着人工准备的问题，先用“只检索不生成”的模式跑一遍，看看系统到底招回了哪几块文本。这一步非常关键，它能帮你分清是索引有问题还是生成有问题。如果召回结果本身就答非所问，模型再强也白搭；如果召回正确但最终答案乱编，那要改的是Prompt和生成链路。我之前的某个内部知识库迭代，就建了一个30条问题的评估集，全部来自真实高频提问，每条标注了“应召回的章节”。每次调整切分策略或embedding模型，就跑一遍评估集统计命中率变化。这种土办法最直接，一周内就把命中率从不到50%拉到80%以上。embedding模型的选择同样直接影响效果。中文场景下，通用领域可以直接用常见的中文embedding模型；法律、医疗、金融这类垂直领域，文档术语特征强，通用模型未必好用，必须实测。判断embedding好坏有个很土的办法：拿几组语义相近但主题不同的句子查相似度，看模型能不能分清。如果相近类别混得厉害，就要考虑换更强的嵌入模型。3.3 检索返回数量与重排：不只盯着TopK还有一个容易被忽略的参数是检索返回条数。默认TopK=4或5在很多场景下不够用，因为chunk切得小而分散，信息分布比较碎；chunk切得大而冗余时，5条又会混入大量无关内容。我一般先在检索层返回10到20条，再做重排或相似度过滤，最后筛出真正喂给大模型的那几条。重排这块我现在基本必上。开源和商业化重排模型都有，成本不高，但效果提升很大。尤其当知识库规模变大、相似chunk互相干扰时，重排模型能有效把最匹配的几条顶到前面，最终答案质量的提升很明显。建议不要跳过这一步，它属于性价比极高的一笔投入。4. 常见问题与排查技巧实录4.1 检索不到内容怎么办这是RAG落地最典型的症状：文档里明明有，系统却回答“没有相关内容”。排查应该沿着一条线走下来，别上来就怀疑模型。第一步，确认文档真的入库了。检查向量库里有没有对应记录、chunk数量是否和预期一致。很多入库程序会静默失败，比如某类PDF解析返回空文本，程序没报错只是没存进数据，结果知识库就悄悄少了一块。第二步，抽查切分后的文本。随机打印几个chunk看内容，如果本身是乱码、缺字、表格碎片，问题就在解析环节。第三步，检查提问与文档术语粒度是否匹配。文档里写的是专业缩写，用户问的是完整名称，检索失败十分正常。这时候可以考虑在切出来的chunk里补充别名和同义词元数据。第四步，再看检索方式。有些场景只靠向量检索可能不够，需要配合关键词检索做混合召回。工程实现不复杂，但对“检索不到”的改善立竿见影。这里整理一个排查速查表，按顺序走即可：现象排查动作常见根因解决方向检索为空查向量库记录入库静默失败检查解析返回结果召回乱码打印chunk解析环节问题换解析库或补OCR语义匹配差跑评估集术语不匹配补充同义词/别名检索覆盖不足检查召回方式单一向量检索增加关键词混合召回4.2 回答张冠李戴怎么办能检索到内容，但大模型把A产品的方案套到B产品头上，这也很常见。根源通常是召回的chunk混入了一些同主题不同实体的内容，大模型缺少足够“身份信息”来区分。一种有效做法是给每个chunk注入更丰富的身份标识，把实体名称、适用范围、文档来源写进元数据，并在生成上下文里作为前缀拼接。比如用户问“型号A”，就在上下文里明确标出哪些内容来自型号A的章节。另一种做法是增加一道实体校验，在召回后过滤掉与提问实体明显冲突的chunk。这条规则实现很轻，但对答准率帮助很大。还有一种常见情况，是大模型基于多个chunk“缝合”出了混合答案。把Prompt改成严格基于提供资料作答，要求模型在拿不准时明说不知道，并输出文档标题作为依据来源。这既提高答案可信度，也帮用户判断信息出处是否可靠。4.3 表格、多栏文档和图片怎么处理前面说过表格的基本思路，这里讲一个真实案例。处理一份几十个价格表的商品手册时，最初简单把表格转纯文本，用户问“某型号耗材多少钱”，系统老是召回一堆杂乱数字。后来改成先用表格摘要文本锁定表格主题，再保留原始Markdown表格作为生成依据，效果立刻改观。摘要负责“让检索找到正确的表”，原始表格负责“让生成算出正确的数”，分工明确。多栏文档是PDF独有的痛点，两栏排版的论文、宣传册，抽取时常把左右两栏文字穿插到一起。遇到这种文档，我会先用pdfplumber按坐标分栏抽取，或者用基于布局的工具处理。实在处理不了，就考虑转成图片丢给多模态模型识别。没有万能解法，但值得为高频出现的多栏文档类型写专属解析规则，因为这类文档往往信息密度最高。图片入库的思路前面也提过，这里补充一点细节：一张配图的操作说明，如果只存了段落文字而没存图片描述，信息就是残缺的。我通常把图片交给多模态模型生成文本描述，然后连同原图路径一起入库。检索时，文本描述负责把用户问题引导到正确位置，原图路径则可以提供给前端作可视化展示。这一步多花一点成本，但知识库的可用性直接上一个台阶。4.4 性能与成本的三个实用建议最后聊点后端上线后的取舍。RAG的文档量会越滚越大，处理管线的稳健性比花哨更重要。第一，入库前做去重和版本管理。同一份内容以不同文件名或不同格式反复塞进知识库，会产生大量相似chunk，检索时互相干扰。建议入库前跑一遍内容哈希或相似度比对，重复的直接跳过；文档迭代更新时，先删旧版再入新版。第二，利用缓存减少向量化次数。切分后的chunk向量化是主要成本来源，只要内容没变，没必要重复调用接口。可以把文本哈希和向量一起存进数据库，下次入库前先查一下，已经存在的直接把向量取出来复用，能省下不少费用。第三，合理使用批量处理。调用embedding接口时，把一批文本传入接口比一条条循环调用快得多，一般SDK原生支持批量参数，很多人习惯写循环，白白浪费时间和预算。改成批量处理后，大批量文档的处理时常能压缩到原来的十分之一。最后再分享两个实操体会第一，RAG知识库的第一版永远不要贪大求全。先挑一块业务最核心、格式最规范的文档，把全流程跑通，再逐步扩展。一上来什么格式都往库里塞，出问题后连是哪一类文档导致的都定位不出来，排错成本直接爆炸。第二，无论采用哪套文档处理流程，务必把每个环节的中间产物留一份。文本抽取后的纯文本、清洗后的版本、切分后的chunk列表，全部存下来。这样做不仅能随时复盘，还能在效果回退时快速定位是哪一步改动引起的。我后面维护知识库时经常需要回看两周前的清洗规则和切分参数，如果没有这些中间副本，光凭记忆根本还原不了。文档处理这件事，在RAG项目里最不起眼，却直接决定整个系统的上限。与其反复折腾模型技巧，不如沉下心来把文档这层地基打牢。调试久了你会发现，知识库表现好不好的答案，往往藏在那些看似枯燥的数据细节里。希望这篇笔记里的土办法和踩坑记录，能帮你少走几段弯路。