做了两年RAG项目从最早只能喂纯文本到现在客户动不动就丢给我一堆带表格的PDF、手机拍的PPT截图、一小时一小时的培训录音我最大的感受是RAG系统上线之后能不能用、好不好用八成在数据进库之前就已经决定了。模型选得再好、向量库再稳定如果预处理阶段把多模态数据搞成一团乱麻后面检索和生成全是无源之水。所以这篇我想认真聊聊RAG知识库里多模态数据预处理这件事——它到底在解决什么问题、每一步该怎么设计、有哪些坑我替你踩过了。这篇文章适合正在搭建企业知识库、准备把非结构化文档接入大模型应用的工程师也适合对RAG感兴趣但被“文档解析、切块、向量化”这些环节劝退的学习者。我会从整体架构往下拆落到PDF解析、表格抽取、图片OCR、音视频转写、Chunk切分、向量化策略最后给出一段可运行的流水线示例和问题排查清单。不追求理论上的大全但求每一步都能落地。1. 多模态RAG的核心逻辑与预处理定位1.1 RAG系统的工作链路与预处理的位置先快速对齐一下RAG的基本链路。一个标准的RAG系统通常包含三段离线阶段的“数据入库”在线阶段的“检索召回”和“答案生成”。离线阶段负责把原始文档拆解、清洗、切片、向量化写入向量数据库在线阶段拿到用户问题后用同一个Embedding模型把问题向量化去向量库里做相似度检索把命中的原文片段交给大模型由大模型结合检索内容生成最终回答。很多人会把注意力放在在线阶段的检索策略和Prompt设计上这没错但一个残酷的事实是在线检索的上限在离线入库那一刻就已经被锁死了。如果原始文档里的表格被读成了乱码如果图片里的关键信息没有被抽取如果一段连续的文字在切分时被拦腰截断那无论检索策略多聪明也找不回已经丢失的信息。多模态数据预处理就是这个离线阶段里最关键、也最琐碎的一环。所谓“多模态”落到知识库场景里通常包括文本、版式复杂的PDF、扫描件、图片、表格、音视频。每一种模态都有自己的“脾气”预处理的目标就是把这些五花八门的原始输入统一转化为干净、结构清晰、语义完整、便于向量化的文本块。1.2 多模态数据给知识库带来的四类挑战我把实战中遇到的多模态数据问题归纳为四类这四类问题几乎覆盖了知识库建设初期的大部分“翻车现场”。第一类是信息载体分离。比如一份PDF里有标题、正文、表格、页眉页脚、图片这些元素在视觉上有明确位置关系但一旦用普通文本解析器直接抽取就会变成一股脑的线性文字流表格的二维结构丢失图片完全被忽略图表里的结论性描述自然也无从索引。最典型的例子是财报PDF一整页的营收表格被解析成“2023 2024 2025 1000 2000 3000”这样的平铺字符串检索时完全无法理解列和行的对应关系。第二类是格式噪声输入。扫描件带来的倾斜、噪点、水印Word文档里奇奇怪怪的制表符和分页符网页导出的PDF里残留的导航栏文字这些噪声如果不洗掉会把Chunk的语义浓度稀释得很厉害。我见过一个项目因为PDF页眉带公司名称和“内部资料”四个字结果每次检索“产品定价”都会先把“内部资料”给召回来大模型基于这种上下文生成的回答自然也是胡言乱语。第三类是语义切分的边界问题。原始文档有自己的章节结构但机器切分时如果只按固定字符数硬切很可能把一段论述的因果逻辑切断。比如“该方法并不适用于所有场景因为……”被切到上一块“……因为”后面的原因在下一块检索时只命中了前半句模型大概率会给出一段片面的解释。第四类是异构数据的统一映射问题。文本能直接Embedding图片怎么办音频怎么办表格是按行还是按块向量化如果所有模态都硬塞进同一个文本向量空间必须先想清楚映射方式否则检索阶段会出现跨模态召回率极低的问题。1.3 数据预处理在RAG里的“承上启下”角色如果把RAG在线部分比作一个解答问题的“学生”那离线预处理就是在给这个学生编“教材”。教材编得好不好直接决定了学生考试能考多少分。预处理做好了一个普通的Embedding模型加一个常规向量库就能撑起一个相当可用的知识库预处理敷衍了事换再贵的模型也救不回来。我习惯把预处理分成四个阶段解析Parse、清洗Clean、切分Split、向量化Embed。解析解决“有什么”清洗解决“干不干净”切分解决“怎么切最合理”向量化解决“怎么让机器能算相似度”。这四个阶段环环相扣任何一环出了问题后面的环节都会放大这个错误。所以做多模态预处理第一步不是写代码而是先想清楚你的原始数据长什么样、以及你期望用户从知识库里问到什么。2. 文档解析层把非结构化内容变成可处理的结构2.1 文档解析的本质与常见误区文档解析是整个预处理管线里最不显眼、但最容易“一夜回到解放前”的环节。很多人以为PDF解析就是调用一个库然后拿字符串实际上文档解析做的是“从版面还原语义”的逆向工程。因为PDF内部记录的是每个字符的坐标位置而不是标题、正文、表格这样的结构标签所以解析工具需要根据字符坐标推断出段落关系、层级关系、表格边界以及图片和文字的相对布局。这里有一个常见的误区以为“能抽出文字”就等于“解析成功”。实际上如果解析结果丢失了版式结构——比如把两列表格读成一行、把图片下的注释文字和正文混在一起——那么抽出来的文字只是“看似存在”在RAG检索场景里几乎不可用。我曾经测试过同一个PDF在四个不同解析工具下的输出有的能完整保留表格结构有的把表格拆成碎片最后检索质量的差距肉眼可见。2.2 PDF、Word、Markdown的解析方案选型不同的文件格式需要不同的解析策略选错工具等于自埋地雷。我按照经验把常见格式的方案整理成一张表供你选型时参考。文件类型推荐方案备选方案注意事项文字版PDFPyMuPDFfitz、pdfplumberpypdfPyMuPDF速度快pdfplumber对表格坐标更精确扫描版PDFDoccano/PaddleOCR/RapidOCRTesseract必须先做OCR不能直接走文本抽取Word.docxpython-docx、Unstructuredmammoth注意处理页眉页脚、批注、修订记录Markdown/HTMLmarkdown-it、BeautifulSouptrafilaturaHTML需提取正文去除导航与脚本标签复杂学术PDFDocling、UnstructuredGrobid对多栏、公式、图表有额外处理能力其中Docling是最近用得比较顺手的一个开源库它对多栏PDF、表格、图片都有专门的Layout模型来识别输出带有层次结构的文档对象比起直接用PyMuPDF“裸抽”要省心很多。Unstructured则胜在接口统一一个函数搞定多种格式但代价是体积重、依赖多在服务器部署时要注意资源占用。再说Word很多人直接用python-docx逐段读取但docx本质是一个XML包段落里有样式信息表格是单独的XML元素图片是嵌入的媒体文件如果单纯遍历paragraphs会漏掉表格和你嵌入的图表。建议用Unstructured或自定义XML解析器把paragraph和table分开处理再按原始顺序合并。2.3 扫描版PDF与OCR的工程坑扫描版PDF是知识库里最让人头大的输入之一处理不好就是数据黑洞。这类PDF本质上是图片的集合必须OCR才能转成文字。OCR选型上PaddleOCR的识别精度在国内业务场景中表现很好对中文、表格、公式都有支持RapidOCR是PaddleOCR的ONNX Runtime版本部署更轻量Tesseract虽然老牌但中英文混合文档的精度明显落后。OCR的工程坑我总结成三个。第一是图片预处理扫描件的倾斜和噪点会严重影响识别率在送入OCR前建议先做一次图像预处理包括灰度化、二值化、倾斜矫正、去噪。第二是版面顺序一份多栏的报纸或论文OCR引擎靠阅读顺序算法决定先读哪一栏如果顺序搞错输出的文本就是左右栏交错检索时语义完全错乱。第三是同页大段水印和印章会识别出一堆噪声文字需要在清洗阶段做规则过滤。操作上我通常会做“双层PDF”方案底层是原始扫描图上层是OCR识别出的隐藏文字层。这样既保留了原始版式可供人查阅又能让RAG管线直接读取文字层。如果上层文字识别错误还可以在检索结果页面里回链到原始图片让用户自己判断。2.4 表格抽取最容易翻车的环节表格是RAG多模态预处理里翻车率最高的地方没有之一。原因是表格的信息是二维的而向量化和大模型上下文都是线性文本强行拍平会损失行与列之间的对应关系。举个例子季度营收利润Q1100万20万Q2120万30万如果拍平成文本“季度营收利润Q1100万20万Q2120万30万”模型需要很强的推理能力才能还原“Q1的利润是20万”。为了减少这种损失抽取表格时有两条路线。第一条路线是把表格转成Markdown或Pipe格式也就是保留管道符和表头结构。因为大模型对Markdown表格的语法有很强的先验理解检索到这样的片段后它能相对容易地还原表格语义。第二条路线是“表格上下文”双轨存储——把表格转成文本后再补充一行表格说明例如“这是2024年各季度营收与利润数据”Chunk既包含数据本身也包含语义注解这样检索时哪怕问题只说了“Q2利润”也能靠说明和表头文本命中。工具层面pdfplumber的extract_table方法适合规则表格Camelot处理复杂边框表格更稳Unstructured也内置了HiRes表格识别。如果表格极其复杂还可以用基于深度学习的Table Transformer模型但推理成本高在大规模入库时不一定划算我通常会先跑Camelot只对失败页面再上重武器。3. 内容切分与清洗决定检索质量的分水岭3.1 切分策略的核心矛盾切分是文本进入向量库前的最后一道“塑形”其核心矛盾可以概括为一句大白话块太小语义信息不足块太大向量化后被无关噪声稀释检索精度下降。先看块太小的场景。把一句话单独作为一个Chunk向量化后它可能无法包含足够的上下文检索时和问题向量的相似度不高即使召回了给到大模型的上下文也极度碎片化没法支撑复杂推理。再看块太大的场景。一个Chunk包含3000字里面讲了好几个问题向量化后所有信息混在一起检索“如何更换电池”时它的向量和“如何充电”的向量可能差不多导致召回了但答案不精准还会拉高Token消耗。所以切分本质上是在“语义完整性”和“检索粒度”之间找平衡。没有万能参数必须结合文档类型和业务问题类型来调。3.2 固定窗口切分与语义切分的对比与选型目前主流的切分方案有三类固定窗口切分、递归结构切分、语义切分。固定窗口切分最简单就是按字符数硬切比如每512个字符一块块与块之间重叠64个字符。这种方案胜在速度快、实现简单适合内容相对均匀的文档但遇到章节结构清晰的文档时会显得“无脑”。递归结构切分是LangChain里RecursiveCharacterTextSplitter的做法它维护一组分隔符比如换行、句号、逗号先按最大的分隔符切如果块仍然超长再按小一级分隔符继续切。这样切出来的块通常能在段落边界收尾语义完整度比纯固定窗口好得多是目前性价比最高的默认选择。如果文档有明确的Markdown标题结构MarkdownHeaderTextSplitter更好用它会把标题层级作为元数据注入每个Chunk检索时还能带着“章节路径”一起返回。语义切分是近几年比较热的做法原理是先用一个小模型计算相邻句子之间的语义相似度在相似度出现明显“断点”的位置进行切分。优越是切得“懂内容”能把主题相近的句子聚在一起缺点是慢入库文档量大时切分阶段可能比向量化还贵。我的经验是通用知识库用递归结构切分足够面向深度问答的知识库可以局部用语义切分处理重点文档。3.3 清洗规范与质量打分机制切分之前必须先清洗顺序不能反。清洗的目标有三个去掉噪声、保留信息、稳定格式。我常用的清洗规则包括删除页眉页脚和重复导航文字可以通过统计多页高频文本识别去除多余空白字符和不可见Unicode字符修正错误断行尤其是PDF里因换行导致英文单词中间断裂的情况删除水印文字和“内部资料”等敏感标记将常见全角字符统一为半角避免影响检索短词匹配。清洗之后建议加一个质量打分机制对每个页面或每个Chunk输出一个0到1的质量分由规则加权计算。比如是否包含大量乱码、是否包含无法识别的特殊符号、文本密度是否过低可能是一张未被OCR的图片、是否有连续重复段落。质量分低于阈值的Chunk不要立即丢弃而是标记为“需人工复审”否则万一误杀重要内容后面找回来更费劲。3.4 Chunk元数据设计为召回排序打底很多人切完块就直接做向量化入库了忽略了元数据设计。元数据就是每个Chunk的“身份证”记录了它来自哪个文件、哪个章节、哪个页码、作者是谁、创建时间是什么。这些信息在检索阶段极有价值第一可以用来做过滤比如用户只查“2024年财报”可以在Metadata里按年份过滤后再做相似度检索第二可以用在重排序策略里第三可以把来源链接带回给用户增强可信度。我设计Metadata的规范是必须有document_id、chunk_id、title、section_path、page_number、file_type、created_at、checksum根据业务再加source_url、author、language、tags等。其中checksum很关键它用于增量更新时判断文档是否发生变化而不是重复入库。有了这层元数据知识库才谈得上可维护否则每次更新数据都等于推倒重建。4. 多模态元素的专项处理图片、表格、音视频4.1 图片处理OCR、Captioning与向量化知识库里的图片通常分成两类一类是“图文并茂”的信息图比如产品宣传页、PPT截图另一类是“图中有字”的扫描件、表格截图。对前者单纯OCR抽文字还不够因为图片本身的视觉信息也很重要比如图表反映的趋势、拍照原图里的实物特征对后者OCR基本能覆盖大部分信息需求。我常用的图片处理流程分三步先用检测模型判断图片里有没有文字区域如果有就走OCR然后对图片生成一段文字描述Caption这一步可以叫Captioning用的模型可以是BLIP、LLaVA或者更轻量的CLIP变体最后把OCR文本、Caption文本、图片的视觉向量三者共同存起来。检索时既可以用文本召回也可以用视觉向量做相似度召回再做个分数融合。4.2 表格数据结构化抽取与行级/块级索引表格在2.4节已经提过这里重点讲索引策略。表格区别于普通文本的地方在于它的信息密度高且查询往往针对具体单元格。传统做法是把整个表格作为一个Chunk向量化问题来了一个20行的大表格Chunk向量会被绝大多数不相关的单元格“稀释”用户查第15行的数据时整个Chunk向量和问题的相似度可能并不高。如果你在一个大表格里检索某一行的数据经常失败大概率就是这个原因。改进方案是块级索引一个表格不作为一个整体入库而是按表头若干行的组合切成块。比如每5行一组每组前面都带着表头组间加入行号说明。这样既保住了表格结构又缩小了检索粒度。注意每组之间要有行重叠避免恰好查询落在组与组的交界处。同时对表格这种高密度信息建议在Metadata里加上table_id和所在页码方便回归定位。4.3 音频与视频的“转写-切分-索引”流程会议录音、培训视频这类音视频资料在多模态知识库里扮演着越来越重要的角色。处理音视频的通用管线是音频转文字、文字切分、文字向量化。这里最大的难点是第一步也就是语音转写。如果业务对转写精度要求高推荐faster-whisper它在保持OpenAI Whisper模型精度的同时推理速度快很多在CPU上也能跑。转写出来后要按说话人做分割同时保留时间戳。然后对转写文本按语义切块把每个Chunk连同时间戳和视频片段链接一起存进知识库。用户提问时如果命中了某段转写文本就可以直接把用户引导到对应的视频时间点。音视频预处理有几个容易被忽略的细节一是背景噪声和多人同时说话会显著拉低识别准确率建议先做降噪二是转写文本里的口语词、重复词、语气词“嗯”、“那个”、“就是说”会污染向量质量切块之前要做口语清理三是字幕文件SRT/VTT如果存在可以直接作为转写的辅助但要处理好字幕断句逻辑和视频画面切换的关系。4.4 向量化策略单一向量还是多向量混合多模态数据预处理到了向量化这一步还会面临一个选择所有内容都用同一个文本Embedding模型映射到同一个向量空间还是按模态分别处理、使用多种向量简单知识库场景比如主要输入是各类文档我会直接统一用文本Embedding把图片的OCR文本、表格的Markdown都当作文本来处理这样做省心且兼容性最好。如果业务对图片相似性检索要求高比如“找一张和这个产品外观相似的图片”我就会单独为图片生成视觉向量存到单独的向量表或使用多向量字段检索时分别计算相似度后做加权融合。多向量方案会带来两方面的复杂度。一是存储和索引规格要升级比如给图片视觉向量单独建索引检索时要同时查两张表再合并二是分数融合本身就是一门学问文本相似度和视觉相似度的分数范围可能不一致需要做归一化。所以我的建议是先从单一文本向量开始跑通全链路再逐步加模态不要一上来就追求复杂的多向量框架。5. 工程化落地从脚本到服务化流水线5.1 流水线的基本架构与框架选型聊完单点方案我把它们组装成一条可落地、可扩展的预处理流水线。一条典型流水线包含四个服务文件接入层、解析处理层、切片索引层、元数据管理层。技术实现上文件接入层可以用FastAPI暴露上传接口处理层内部用Celery或简单的异步任务队列调度索引层对接向量数据库元数据层用关系数据库存储。框架选型方面习惯用LangChain的朋友可以继续用LangChain的Loader和Splitter组件尤其是和LangGraph搭配时可以很方便地把预处理流程编排成有状态、可中断的流水线偏好轻量逻辑的可以直接用Python写一个Pipeline类每个功能模块实现统一的process(input)接口代码更可控也便于测试。关于向量库pgvector配合PostgreSQL很适合中小型知识库省心且支持SQL过滤大规模场景再考虑Milvus或Qdrant。5.2 一个基于LangChain的预处理脚本示例下面是一段我实战里经常变体使用的预处理脚本骨架逻辑很简洁读取PDF → 提取文本 → 清洗 → 切块 → 生成向量 → 写库。from langchain_community.document_loaders import PyMuPDFLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_openai import OpenAIEmbeddings from langchain_community.vectorstores import PGVector # 1. 加载文档保留页面信息 loader PyMuPDFLoader(sample.pdf) docs loader.load() # 2. 清洗忽略页眉页脚压缩空白 for doc in docs: lines [l.strip() for l in doc.page_content.split(\n) if l.strip() and not is_header_footer(l)] doc.page_content \n.join(lines) # 3. 切分优先保留段落边界 splitter RecursiveCharacterTextSplitter( chunk_size512, chunk_overlap64, separators[\n\n, \n, 。, , , , , , ], add_start_indexTrue, ) chunks splitter.split_documents(docs) # 4. 注入元数据 for idx, chunk in enumerate(chunks): chunk.metadata[chunk_id] fsample-{idx:04d} chunk.metadata[checksum] compute_checksum(chunk.page_content) # 5. 生成向量并入库 embeddings OpenAIEmbeddings(modeltext-embedding-3-small) PGVector.from_documents( documentschunks, embeddingembeddings, connection_stringpostgresqlpsycopg://user:passlocalhost:5432/ragdb, )这段代码里的参数都是有讲究的。chunk_size512对多数通用文档来说信息密度适中chunk_overlap64保证跨块语义不裂开分隔符数组的顺序意味着优先按段落切其次按句号切。这里尤其要注意的是当分隔符列表里出现“”甚至“”时说明前面都无法在边界处切断才被迫按最小粒度切这会牺牲一部分语义完整性属于我们最不愿意走到的分支。如果你的文档里表格比较多可以考虑把表格内容单独抽取后转成Markdown再作为独立的Document对象和文本块一起交给下一步处理。5.3 增量更新与版本管理知识库最怕的不是第一次建库而是后续反复更新时出现重复数据、过期数据、漏更新数据。增量更新的核心是文档级别的版本管理和Chunk级别的去重。文档级别的版本管理我习惯在文件接入时计算整个文件的SHA-256存入元数据表的doc_checksum字段。每次新上传文件时先查一下checksum是否已存在如果存在且内容没变就不重复处理如果内容变了就对整个文档执行“旧Chunk删除新Chunk入库”保证库里永远只有最新版本。Chunk级别的去重同样可以用hash但要注意即使整个文档没变切分参数调整后也需要重建索引所以版本号要能反映处理参数而不只是文件内容。小细节增量更新时不要把旧Chunk物理删除后立即插入新Chunk可以先标记为“待淘汰”等新Chunk入库成功后再删避免检索窗口期出现问题。5.4 质量评测如何量化预处理效果很多团队把RAG系统上线后才发现检索效果不好再去回溯预处理链路这时排查成本非常高。我建议在预处理管线的每个关键节点都加上质量指标输出形成一份“数据体检报告”。解析成功率成功解析出文本的页数/总页数低于95%的文档要人工复核。清洗噪声率清洗后保留字符数/原始抽取字符数比值过低说明原文档噪声太多。切分有效率切块中没有被判定为重复或空块的占比。检索命中率用一批金标问题去测试检索Top-5中包含答案原文的比例。端到端准确率RAG系统最终回答的准确性可人工打分或借助LLM-as-Judge。定期运行这些指标能让你在用户投诉之前发现问题。比如某一天检索命中率突然下降很可能就是新入库的一批文档切分质量不达标而不是模型出了问题。6. 常见问题与排查技巧实录6.1 表格数据检索效果差现象用户问“去年Q3利润是多少”知识库返回不到正确表格或者返回了但模型答错。排查思路先确认表格在入库时是“拍平成文本”还是“结构化抽取”。用一条SQL或直接查向量库看对应Chunk内容如果发现入库存的是“季度利润2023Q3100”那基本就是拍平惹的祸。解决方案是走表格结构化抽取转成Markdown并加上表格说明文字同时检查向量化时有没有把表头信息带回没有的话就重新做一遍表头拼接。6.2 混合文档乱序、噪声大现象多栏PDF或图文混排文档解析出来的文本左右栏交错或者大量插入页脚和重复导航。排查思路先看解析工具环节PyMuPDF默认按坐标顺序抽取对多栏布局不敏感此时应切换Docling或Unstructured的HiRes策略或者用LayoutLMv3这类版面分析模型先检测文本块区域再按“从上到下、从左到右”排序。噪声问题则在清洗规则里加一条高频短语过滤统计多次出现的页眉页脚字符串并剔除。6.3 切分边界截断语义现象用户在线上问了一个跨Chunk的复杂问题检索结果里只有前半段原因没有后半段结论。排查思路检查切片参数如果chunk_size太小或者overlap太小可以在合理范围内调大比如chunk_size从512调到768overlap调到96。如果文档本身段落很长建议改为按标题层级切分先把层级树解析出来再在每个章节内部切块。还可以启用“父子Chunk”方案用细粒度Chunk做检索命中后回溯到上一级较大的父Chunk把完整段落一并给到大模型。6.4 增量更新遗漏与重复入库现象文档更新后库里出现新旧版本并存或者查询结果过期。排查思路确认接入层有没有计算文件checksum没有的话先补上确认删除旧Chunk的策略是“先删后插”还是“标记后覆盖”推荐使用后一种方案。另外注意切分参数变化时旧Chunk未必能被checksum识别出来要在版本号里包含工具链版本和切分参数版本方便定位问题。6.5 多模态召回率低现象图片里的关键信息检索不到或者视频里提到的内容搜不到。排查思路图片信息大概率没有进库检查图片处理节点是否对PDF内嵌图片做了抽取和OCR。视频则检查转写文本是否入库、时间戳是否保留以及语音转写质量是否过差。多模态场景应单独写一个“覆盖检查”脚本随机抽一批含图片和多媒体的页面核实最终库里是否存在对应的文本片段。6.6 成本与性能平衡现象入库速度慢、费用高尤其是利用大模型做图片描述或语义切分时。排查思路控制重模型的使用比例只有清洗后文本无法覆盖信息时才调用视觉模型识别和OCR部分用轻量开源模型尽量不调商用API。批量入库时用异步并发注意向量库写入端的批量BatchSize调整一次性提交128或256条比一条条写快很多。切分和向量化还可以加缓存相同内容的文档只计算一次。这些坑我基本都踩过一遍有些是在客户上线前最后一晚才摸索出来的。做数据预处理不像写模型代码那样“跑通就行”它更考验对数据本身的理解和耐心。我现在的习惯是接到一个新的知识库项目前三天不写一行代码先人工翻几页原始文档搞清楚格式、版式、噪声分布再决定解析选型和切分参数。多模态数据预处理不是一个一次性脚本能解决的事情它需要你持续根据线上检索效果做反馈调整。希望这篇文章能帮你把那些最容易出问题的环节提前预判掉把精力留给真正有价值的业务问答案例。