1. 大文件并发场景下 RAG 的真实痛点拆解

做过 RAG 项目的人大概都有过这种体验：小规模 demo 跑得飞起，一旦把几百页的 PDF、几十兆的表格、甚至整本技术手册丢进去，系统立刻原形毕露——上传卡死、内存飙升、检索延迟从几百毫秒涨到十几秒，严重的时候进程直接被 OOM Killer 干掉。这不是模型不行，而是整个数据管线的并发模型和内存策略没设计好。

我前后在三个不同规模的知识库项目里踩过这类坑，从最初单机跑 Ollama 加一个简易向量库，到后来用 LangChain4j 搭多路检索、再到引入 GraphRAG 做本体增强，大文件并发始终是最容易被低估的一环。很多人把注意力全放在 embedding 模型选型、chunk size 调参、rerank 策略上，却忽略了文件读取、分块、向量化、入库这四个阶段本身就是一条并发流水线，任何一个环节阻塞，整条链路都会雪崩。

这篇内容就是围绕"大文件并发"这个具体问题展开，把我在实际项目里验证过的方案、参数、踩坑记录完整拆出来。适合正在做 RAG 知识库、已经过了 demo 阶段、开始面对真实业务数据的同学。如果你还在纠结用哪个 embedding 模型，这篇可能不是你的第一优先级；但如果你已经被"上传一个 200MB 的 PDF 直接把服务打挂"折磨过，那接下来的内容应该能帮你省不少时间。

核心思路一句话概括：把大文件当成流来处理，而不是当成一个完整对象来加载；把并发控制放在流水线层面，而不是简单地开线程池。下面逐层拆解。

2. 整体架构设计与并发模型选型

2.1 为什么不能"读完整文件再分块"

最朴素的 RAG 入库流程是这样的：读取整个文件到内存 → 按字符或 token 切分 → 批量 embedding → 写入向量库。这个流程在小文件上没问题，但一个 300MB 的纯文本 PDF 转成字符串后，内存占用可能直接到 600MB 到 1GB（Python 字符串和 Java String 都有额外开销），再加上分块后的 chunk 列表、embedding 前的 batch 缓存，峰值内存轻松突破 2GB。如果同时来三个这样的文件，服务基本就废了。

所以第一个设计决策就是流式读取。文件不从磁盘一次性读入内存，而是按块（block）或按页（page）逐步读取，读一块处理一块，处理完立即释放。这样单个文件的内存占用从"文件大小"降到"单块大小 + 处理缓冲区"，通常能控制在几 MB 到几十 MB 级别。

2.2 并发控制的三个层次

很多人一说并发就想到线程池，但在 RAG 入库场景里，并发其实分三个层次，需要分别控制：

这三层如果只用一个大线程池统一管理，就会出现"文件级并发把内存吃光"或者"块级并发把 embedding API 打到限流"的问题。我的做法是三层各自独立限流，通过有界队列串联，形成一条带背压的流水线。

2.3 流水线结构

整体结构可以抽象成四个阶段，用有界阻塞队列连接：

[文件扫描] → [流式分块] → [Embedding] → [批量入库] ↑ 有界队列 ↑ 有界队列 ↑ 有界队列

每个阶段有独立的线程池和队列容量。当某个阶段处理不过来时，队列满，上游自然阻塞，形成背压。这样不需要复杂的调度逻辑，靠队列容量就能把内存和并发控制在可预期范围内。

提示：队列容量不是越大越好。队列越大，内存缓冲越多，但背压响应越慢。我一般把 embedding 阶段的队列容量设成 embedding 批大小的 2 到 3 倍，既能平滑抖动，又不会积压太多。

2.4 为什么选流式而不是分片上传

有人会问：为什么不干脆让前端把大文件切成小片分别上传，后端一片一片处理？这个方案在纯 Web 场景下确实可行，但有两个问题。一是分片逻辑跑到客户端，不同浏览器、不同网络环境下行为不一致，重试和断点续传要额外做一套。二是很多 RAG 场景的文件来源不是浏览器上传，而是服务端从对象存储、共享目录、数据库里拉取，这时候根本没有"前端分片"这一说。所以流式处理放在服务端做，是更通用的方案，客户端只需要支持流式上传即可。

3. 流式分块与内存优化的核心细节

3.1 分块策略：按语义边界而不是固定长度

流式读取解决了"读"的问题，但分块本身也有讲究。固定长度切分（比如每 512 个字符一刀）实现简单，但会把句子、段落、表格切得七零八落，直接影响后续检索的 hit rate。我在实际项目里的做法是流式读取 + 语义边界检测：读取时维护一个滑动窗口，遇到段落结束符、标题标记、表格边界时触发切分，同时设置最大块长度兜底。

具体参数上，我一般这样配：

• 目标块大小：512 到 800 token
• 块间重叠：10% 到 15%
• 最大块硬上限：1200 token（超过强制切分）
• 最小块下限：80 token（低于则与相邻块合并）

重叠部分的作用是防止关键信息正好落在切分点上被割裂。10% 到 15% 是经验值，太小起不到保护作用，太大则向量库冗余严重、检索时重复命中。

3.2 内存优化的几个关键点

流式处理不等于内存就一定低，几个细节没处理好照样爆：

第一，避免在内存里累积所有 chunk。很多人习惯先把一个文件的所有 chunk 收集到一个 List 里，再统一送去 embedding。这个 List 本身就是内存杀手。正确做法是 chunk 一产生就推入队列，由下游消费者取走，List 不落地。

第二，embedding 结果及时释放。embedding 向量通常是 float 数组，一个 768 维的向量约 3KB，一万个 chunk 就是 30MB，十万个就是 300MB。如果把这些向量全缓存在内存里等最后统一入库，内存又会失控。所以 embedding 完成一批就入库一批，向量用完即弃。

第三，注意字符串编码的开销。从 PDF 或 Word 提取文本时，中间会产生大量临时字符串。Java 里可以用 StringBuilder 复用缓冲区，Python 里注意避免频繁的字符串拼接。这些细节单看很小，但在大文件场景下累积起来很可观。

3.3 分块阶段的并发设计

分块本身是 CPU 密集型操作（文本解析、边界检测），可以并行，但要注意单个文件内的分块最好串行，因为分块依赖上下文（前一块的边界影响后一块的起点）。真正能并行的是不同文件之间的分块。所以我的设计是：文件级并行分块，每个文件内部串行，分块结果推入共享队列。

这样既利用了多核，又避免了单文件内的状态竞争。如果某个文件特别大，它自己占一个分块线程，其他小文件可以并行处理，整体吞吐不会因为一个大文件而完全阻塞。

注意：PDF 解析库大多不是线程安全的。如果多个线程同时调用同一个 PDF 解析器实例，可能出现解析错乱甚至崩溃。稳妥做法是每个分块线程持有独立的解析器实例，或者用线程本地变量（ThreadLocal）隔离。

4. Embedding 与入库阶段的并发实操

4.1 Embedding 批处理与限流

Embedding 是整条流水线里最慢也最贵的一环。无论你用的是本地模型（比如通过 Ollama 跑的 embedding 模型）还是云端 API，都有吞吐上限。本地模型受 GPU 显存和算力限制，云端 API 受 QPS 和并发连接数限制。

我的做法是固定批大小 + 有界并发。批大小根据模型能力定，本地小模型一般 16 到 32，云端 API 一般 64 到 128。并发数根据实测吞吐调，原则是"打满但不打爆"。具体操作是：先设一个保守值（比如 4 个并发），逐步往上加，观察延迟和错误率，找到拐点就停。

这里有个容易忽略的点：批大小和并发数是两个独立维度，要分开调。批大小影响单次请求的效率和显存占用，并发数影响整体吞吐和 API 压力。我见过有人把批大小设成 256 还开 16 个并发，结果本地模型直接显存溢出，云端 API 直接返回 429。

4.2 向量库批量写入与背压

入库阶段的关键是批量写入 + 背压传导。单条写入向量库效率极低，批量写入能提升几倍到几十倍吞吐。但批量写入也有个度，批次太大单次事务时间长，批次太小又浪费。

我一般把入库批大小设成 embedding 批大小的 2 到 4 倍，这样多个 embedding 批次的结果可以合并成一次入库。同时入库队列要有容量上限，当向量库写入变慢时，队列积压到上限就阻塞 embedding 阶段，embedding 阻塞又传导到分块阶段，最终让文件读取也慢下来。这就是背压的价值——让整个系统自动降速，而不是某一环崩溃。

4.3 一个可参考的参数配置

下面是我在一个中等规模项目里实际用过的配置，供参考：

这套配置在一台 16GB 内存、8 核 CPU、带一块中端 GPU 的机器上，处理 200MB 左右的 PDF 时峰值内存约 4GB，单文件处理时间约 3 到 5 分钟，同时处理 3 个文件不会互相拖垮。

4.4 流式传输与进度反馈

大文件处理时间长，用户需要知道进度。流式传输在这里有两个含义：一是文件内容流式读取，二是处理进度流式反馈。进度反馈我一般按"已处理块数 / 预估总块数"来算，预估总块数通过文件大小和平均块大小估算。虽然不精确，但比转圈圈强得多。

进度信息通过 SSE（Server-Sent Events）或 WebSocket 推给前端，每处理完一批就推一次。注意进度推送本身也要限流，不能每处理一个块就推一次，否则网络开销比处理本身还大。我一般每 500ms 推一次，或者每完成一个 embedding 批次推一次。

5. 常见问题与排查技巧实录

5.1 内存持续增长不释放

这是最常见的问题。表现是处理几个文件后内存不降，最终 OOM。排查思路：

• 先确认是不是队列积压。如果某个队列长期处于满的状态，说明下游处理不过来，内存都堆在队列里。
• 再检查是否有全局缓存。比如 embedding 模型缓存、解析器缓存、向量库连接池，这些如果没设上限，会随处理量增长。
• 最后看是否有对象引用没释放。比如把 chunk 存到了某个全局 Map 里做去重，但忘了清理。

我遇到过一次，是因为在分块阶段做了一个"全局去重"的 Set，把所有 chunk 的哈希都存进去了，处理几十万块后这个 Set 占了几个 GB。后来改成布隆过滤器，内存立刻降下来。

5.2 Embedding 阶段频繁超时

超时通常有两个原因：批太大导致单次请求时间过长，或者并发太高导致排队。排查方法是先降并发再降批大小，观察哪个改善明显。如果降并发有效，说明是资源竞争；如果降批大小有效，说明是单次请求太重。

还有一个隐蔽原因：输入文本里有超长块。如果某个 chunk 因为边界检测失败变得特别长（比如几万 token），embedding 模型处理它会非常慢甚至报错。所以最大块硬上限一定要设，并且在分块阶段就强制切分。

5.3 向量库写入成为瓶颈

向量库写入慢的表现是入库队列长期满，上游全部阻塞。排查方向：

• 检查是否开了批量写入。单条写入在大多数向量库里都很慢。
• 检查索引是否在写入时同步构建。有些向量库支持延迟建索引，写入时先不建，写完再统一建，能大幅提升写入速度。
• 检查是否有唯一性约束或去重逻辑。每次写入都查重会拖慢速度，可以改成批量查重或异步去重。

5.4 常见问题速查表

5.5 几个独家避坑技巧

技巧一：给每个文件设处理超时。有些文件因为格式问题会卡在某个阶段，如果不设超时，它会一直占着资源。我一般给单文件设 10 分钟超时，超时后记录日志并跳过，不影响其他文件。

技巧二：处理前先做文件体检。检查文件大小、页数、是否加密、是否扫描件。扫描件需要 OCR，处理逻辑完全不同，提前识别能避免中途失败。加密文件直接拒绝，别浪费资源。

技巧三：日志里记录每个阶段的耗时。分块耗时、embedding 耗时、入库耗时分别记录，出问题时一眼就能看出瓶颈在哪。我见过太多人只记总耗时，排查时全靠猜。

技巧四：用小文件先跑通全流程。大文件并发的问题往往在小文件上也能暴露，只是不明显。先用小文件验证流水线正确性，再逐步加大文件，比一上来就怼大文件高效得多。

6. 从单机到分布式的扩展思路

单机方案能撑到什么规模，取决于硬件。一般来说，16GB 内存、8 核 CPU 的机器，用上面的配置能稳定处理每小时几十 GB 的入库量。如果超过这个量，就需要考虑分布式。

分布式的核心思路是把流水线拆到多台机器。文件扫描和分块可以放在一台机器，embedding 放在带 GPU 的机器，入库放在靠近向量库的机器。中间用消息队列连接，队列本身就是天然的背压机制。

但分布式也带来新问题：任务状态管理、失败重试、幂等性。这些在单机方案里靠内存状态就能解决，分布式下需要持久化。我的建议是不要过早分布式，单机方案优化到位能撑很久，分布式带来的复杂度往往超过收益。真到了单机撑不住的时候，再按上面的思路拆。

还有一个扩展方向是增量处理。大文件并发不只是"同时处理多个文件"，还包括"同一个文件更新后只处理变化部分"。这需要记录每个文件的处理状态和内容指纹，更新时对比指纹，只处理变化的块。这个方案能大幅降低重复处理的开销，尤其适合文档频繁更新的知识库场景。

6.1 增量处理的关键设计

增量处理的核心是内容指纹 + 块级对比。文件处理完后，记录每个块的哈希和对应的向量库 ID。文件更新时，重新分块并计算哈希，对比新旧哈希，只对新增和变化的块做 embedding 和入库，删除的块从向量库移除。

这个方案听起来简单，但有几个坑。一是分块边界可能因为内容变化而移动，导致大量块哈希变化，即使内容只改了一点点。解决办法是用基于内容的分块（content-defined chunking），让分块边界由内容决定而不是位置决定，这样局部修改只影响局部块。二是删除操作要小心，别误删还在被引用的块。我一般用引用计数，块被多个文件引用时不删，引用归零才删。

6.2 并发下的幂等性

并发处理时，同一个文件可能被重复提交，或者处理失败后重试。这时候幂等性就很重要。我的做法是给每个处理任务生成唯一 ID，入库时用这个 ID 做去重。向量库如果支持 upsert，直接用文件 ID 加块序号作为主键，重复写入自动覆盖。如果不支持，就在入库前查一次，存在则跳过。

幂等性还有一个层面是部分失败的处理。如果一个文件处理到一半失败了，重试时是从头开始还是从失败点继续？从头开始简单但浪费，从失败点继续需要记录中间状态。我一般对小于 50MB 的文件从头开始，大于 50MB 的记录检查点，从最近的检查点继续。

7. 实测数据与效果对比

为了验证这套方案的效果，我在一台 16GB 内存、8 核 CPU、带中端 GPU 的机器上做了一组对比测试。测试文件是一批技术文档 PDF，单个文件从 10MB 到 250MB 不等，总共约 2GB。

数据很直观：朴素方案直接 OOM；流式单线程能跑完但慢；本文的三层并发方案在内存可控的前提下把耗时压到 14 分钟；而无背压的并发方案虽然理论上更快，但内存失控，最终失败。

这组数据也说明一个道理：并发不是越多越好，关键是可控。有背压的并发能在资源约束下跑到最优，无背压的并发只会把系统推向崩溃。

7.1 检索质量的影响

并发和流式处理本身不直接影响检索质量，但分块策略会。我在测试里对比了固定长度分块和语义边界分块，用同一批查询测 hit rate：

语义边界分块的 hit rate 明显更高，代价是分块逻辑复杂一些、处理稍慢。但在大文件场景下，这个代价完全值得，因为检索质量是 RAG 的核心价值。

7.2 不同向量库的写入表现

入库阶段的性能跟向量库选型关系很大。我测了几种常见方案：

选型时不要只看写入吞吐，还要看检索延迟、内存占用、运维成本。我的一般建议是：单机项目用本地文件型，够用且简单；上了规模再考虑服务型。

8. 一些个人体会

这套方案我在几个项目里反复用过，最大的体会是：大文件并发的问题，八成不是并发本身的问题，而是内存和背压的问题。很多人一上来就调线程池大小，调来调去还是崩，因为根因在内存没控制住。把流式读取和背压做好，并发数反而不用调太高，系统自然就稳了。

另一个体会是参数没有万能值。上面给的配置是我在特定硬件和特定数据下的经验值，换环境一定要重新测。测试方法很简单：从保守值开始，逐步加压，观察内存、延迟、错误率三个指标，找到拐点就停。这个过程花不了多少时间，但能避免上线后翻车。

最后一个建议是先把单文件流程跑通再上并发。我见过太多人一上来就搞并发，结果单文件都有问题，并发只是把问题放大。单文件流程稳定了，并发只是加一层调度，难度低很多。

这套东西后续还能往几个方向扩展：一是结合 GraphRAG 做本体增强，把实体关系也纳入并发处理；二是做多模态，图片和表格的 embedding 走不同管线；三是做跨文件去重，多个文件里的重复内容只处理一次。这些方向我还在摸索，有新的心得再分享。