RAG大文件并发处理实战：异步流水线与性能调优

最近在把一个RAG知识库从实验阶段往生产推，结果一上手就碰到硬骨头：用户疯狂传50MB以上的PDF，同时几十个人在做检索，整个系统直接卡成PPT。查日志发现，上传解析、向量化、向量检索三个阶段都在排队，数据库连接池被打满，好几个请求直接超时。这一轮折腾下来，我对“RAG支持大文件并发”算是有了比较完整的实战经验。这篇内容就是把当时的方案选型、参数调优和踩坑记录梳理出来，给同样在做RAG落地的朋友一个参考。

先说结论：大文件并发的难点不在单点性能，而在“流水线”的稳定性。文件切分、向量化、写入、检索是一条完整链路，任何一环被流量冲垮，整体就会雪崩。所以整个实践的核心是：把大文件处理拆成异步任务，把并发控制在每个环节内部，让外部请求和内部处理彻底解耦。下面我会把架构设计、流水线细节、并发调度、检索优化和问题排查全部展开讲。

1. 整体架构与思路拆解

1.1 为什么RAG处理大文件会“卡”

很多人以为RAG慢是Embedding模型太慢，实际排查下来，大部分瓶颈都在前置环节。一个100MB的PDF，解析可能要几秒，切分之后产生几千个chunk，每个chunk都要调用Embedding接口，如果模型部署在GPU上还好，要是走外部API，光网络往返就有几十毫秒，几千个chunk串行跑，耗时直接变成几十秒甚至几分钟。

检索阶段也不轻松。当文档数量涨到几十万、上百万个chunk之后，向量检索的延迟会明显上升。如果用户同时发起大量查询，向量数据库的CPU和内存会迅速被打满，响应时间从几十毫秒恶化到几秒。我见过一个项目，PDF上传后用Flask直接同步处理，一个30MB文件就能让整个Web服务阻塞，并发进来后所有请求都在等文件处理完，最后全部502。

这就是典型的“同步处理”误区。大文件处理是重活，必须和Web请求分离。否则无论你后端用多强的机器，只要某个用户传了大文件，其他用户的所有轻量查询都会被连累。所以架构上的第一原则就是：把重计算从请求链路中摘出去。

1.2 并发场景下的三大瓶颈

我把并发冲击下的问题归结为三类：资源争抢、外部依赖限流、数据一致性。

资源争抢最直接。CPU、内存、磁盘IO、数据库连接池、线程池，每一项都有上限。16C32G的服务器听着不错，但如果同时跑文档解析、向量化、向量检索，内存直接飙到25G以上，GC频繁触发，系统就卡死。线程池的线程数不是越大越好，太多线程会导致上下文切换开销超过有效计算。

外部依赖限流是更隐蔽的坑。很多Embedding服务有QPS限制，比如OpenAI的Embedding接口默认限制每分钟几十万token，但单请求并发数有限制；本地部署的Embedding模型如果不做并发控制，GPU显存容易被一次性请求占满。向量数据库也有写入并发限制，我之前用某个向量库批量写入时，超过一定并发就返回timeout。这些问题通常不会在小规模测试时暴露，一上生产就被打脸。

数据一致性主要发生在写入阶段。同一个文档被重复上传、同一批chunk被多次写入、更新文档时旧chunk没删干净，都会导致检索结果混乱。并发场景下，多个任务同时操作同一个文档id，很容易出现“部分chunk是新版本，部分是旧版本”的怪象。

1.3 设计目标与方案选型

基于上述分析，我设计了这样的架构目标：外部请求只负责接收文件和返回任务id；文件解析、切分、向量化、写入全部放入异步任务队列；向量检索提供独立的查询服务，和写入链路分离；所有外部依赖都做超时、重试、熔断保护。

具体选型上，我用Celery作为异步任务框架，Broker用Redis，因为团队对Redis已经很熟，不需要额外引入RabbitMQ。任务队列分两个：一个用于文件解析，一个用于向量化写入，避免大文件解析阻塞小批量的向量化任务。向量数据库选的Qdrant，支持HNSW索引，并发查询性能不错，而且有原生批量写入接口。Embedding模型用的本地部署的bge-large-zh，用TensorRT加速，整体QPS能到20左右。

这里多说一句，不要迷信“轻量”。很多人为了部署方便，把RAG做成单进程Flask应用，上传、解析、检索全在一个进程里。这种方式原型验证没问题，但一到并发场景就会连环崩。我建议即使初期用户量不大，也至少要把异步任务队列拆出来，否则后面重构的成本远高于一开始的投入。

2. 大文件处理流水线设计

2.1 文件上传与分块策略

大文件上传本身就是一个并发敏感点。一个1GB的PDF，如果用普通表单上传，后端需要完整接收整个文件，占用大量内存，而且网络断了就要重新传。所以我做了前端分块上传：文件在前端按16MB切块，每块单独请求上传，后端接收后写入临时目录，全部传完后触发合并操作。

分块大小选16MB是有原因的。太小会拉高请求数量，增加HTTP握手开销；太大会导致单块失败重传成本高。16MB在多数网络环境下是一个平衡点，局域网传输很快，公网环境下单块也不会太大。前端用Web Worker处理文件分块，避免主线程卡死，这个细节很多教程不会提，但实际体验差别很大。

后端合并时需要注意并发覆盖问题。多个分块同时到达，如果直接在最终文件上写，很容易互相覆盖。我的做法是：每个分块先写入独立的临时文件，分块全部上传完成后，由一个合并任务按块顺序合并成大文件，合并完成后做文件校验（大小和MD5），通过后再进入解析队列。这样即使某个分块失败，也可以单独重传。

2.2 文档解析与文本切分的优化

文档解析是最容易被低估的环节。100MB的PDF，如果里面全是扫描图片，直接抽文本可能抽出来是空的，必须先做OCR。OCR本身就是重计算，tesseract跑一个整页可能几秒，一个100MB文档几十页，串行跑会导致任务积压。我的做法是：对PDF先做文本层检测，有文本层的直接提取，没有文本层的才进OCR队列，OCR任务再按页数拆成多个子任务并行处理。这样能把大文件的解析时间从几十秒压缩到十几秒。

文本切分同样需要“并发友好”。经典的递归字符切分器（RecursiveCharacterTextSplitter）在处理大文件时会生成大量chunk，每个chunk都带大量重复前缀元数据，内存开销不小。我改成先按段落粗切，再做固定大小chunk，同时使用overlap避免语义断裂。更重要的是，切分后的chunk写入队列时，不能一次性全部load进内存。我用生成器迭代，每次只保留当前批次的chunk，这样即使一个文档产生5万个chunk，内存峰值也可控。

这里还要考虑metadata的继承。每个chunk需要带上文档id、页码、标题路径等信息，方便后续检索时做过滤和溯源。并发处理时metadata的拼接要格外小心，字段分隔符建议用特殊字符，避免和正文内容混淆。之前遇到过正文里包含冒号、竖线，导致解析metadata出错，后来统一改成JSON序列化存入metadata字段，就没再出过问题。

2.3 向量化与写入批量控制

向量化阶段的核心是控制并发度。如果Embedding模型部署在单张GPU上，显存可能只够同时处理32个文本。并发设置过高，GPU显存溢出，任务直接失败；设置过低，GPU利用率上不去，处理时间拉长。

我在实践中的参数：bge-large-zh，batch size设为16，并发worker数设为4。也就是同时最多有4个worker在请求GPU，每个worker一次送16条文本。配合TensorRT加速，单条文本的Embedding耗时降到10ms左右，整体吞吐能达到每秒160条左右。这个参数不是拍脑袋定的，是跑了几轮压测后确定的：batch size超过32时，显存占用飙升，速度反而没提升；worker超过6时，GPU利用率接近100%，但延迟明显上升，说明已经过载。

向量写入Qdrant时也需要控制batch大小。Qdrant的批量upsert接口一次可以写入几百个点，但payload如果很大，单次请求体积会超过服务端的包体限制。我控制每次写入256个chunk，并开启wait=false的异步写入模式，这样写入请求不会一直占用连接等待索引构建完成。索引构建是后台异步进行的，查询时可能有一小段时间的数据不一致，但对于RAG场景来说，这个延迟窗口可以接受。

3. 并发调度与资源隔离实战

3.1 任务队列与worker池设计

我用Celery+Redis搭建了两级队列。队列A负责文档解析和切分，队列B负责向量化和写入。为什么拆两个队列？因为任务量差异太大。一个大文件的解析任务可能要跑30秒，如果在同一个队列里排队，后面几百个小文档的向量化任务都会堵住。拆开之后，解析队列用较少的worker，向量化队列用较多的worker，各自独立伸缩。

worker池的并发数怎么定？我参考了一个经验公式：CPU密集型任务，线程数 ≈ CPU核心数 + 1；IO密集型任务，线程数 ≈ CPU核心数 × 2 + 1。但Celery的worker是进程池，不能照搬线程公式。我的16C32G服务器上，最终配置是：解析worker开4个进程，向量化worker开8个进程。因为向量化主要依赖GPU，CPU开销不大，但需要等待网络IO，所以进程数可以多一点；解析任务比较吃CPU，4个进程基本能跑满4个核心，再多反而会导致CPU上下文切换过重。

内存上也要算清楚。每个解析worker在运行时，可能会加载PDF解析库、OCR模型等，内存峰值可能到2GB，4个worker就是8GB。向量化worker主要和GPU交互，内存占用相对小，1GB左右，8个worker占用8GB。剩下16GB给系统、向量数据库和其他服务。32G内存看着够用，但如果你没有做隔离，所有worker共享内存，一个worker出问题可能拖垮整个宿主机。所以我用systemd管理Celery worker，给每个进程加了MemoryMax限制。

3.2 数据库连接池与事务锁优化

RAG系统通常还会有个关系型数据库存文档元数据和任务状态。并发一高，数据库连接池就是第一个被打爆的资源。默认的连接池配置往往是5个连接，并发上来后全部卡在获取连接的等待中。我把连接池调成最小5、最大30，同时设置连接等待超时为3秒，超过3秒直接快速失败返回提示，而不是无限等待。

任务状态更新时最容易遇到锁问题。多个worker可能在同一个文档id上并发更新状态：一个正在解析，一个正在向量化，一个标记完成。如果都用普通的UPDATE，很容易出现后写的覆盖先写的，导致状态回退。我用乐观锁的思路，在任务表里加一个version字段，每次更新时带上version条件，如果更新影响行数为0，说明有人已经改过了，就重新读取最新状态再决定下一步。

还有一个常见的坑：redis中存储任务进度时，多个worker同时更新同一个文档的进度百分比，可能存在覆盖。比如解析完成50%，向量化完成20%，两个worker同时写“进度”字段，最后存的可能是20%。这个问题我直接把进度拆成了阶段字段，解析进度、向量化进度、总进度分开存储，展示时按权重合并，不会再互踩。

3.3 分布式环境下的限流与降级

虽然是单机部署，但为了后续扩展，我还是在应用层加了限流。对外提供两个核心接口：文件上传接口（低频、大流量）和检索接口（高频、小请求）。我分别做了不同的限流策略。

上传接口采用令牌桶限流，每分钟最多允许100个上传请求，突发可到20个并发，超过就返回429提示稍后重试。检索接口限流更严格，单个用户每秒最多5次查询，全局限流每秒50次。这个限流数值不是随便定的，是在压测中实测当前系统在保持良好响应时间的前提下能承受的最大值。如果超过这个值，系统不会直接崩，而是通过限流让部分请求排队或快速失败，保护整体可用性。

降级策略也很重要。如果Embedding服务和Qdrant连接超时，我设置了快速熔断：连续5次失败就打开熔断器，后续请求直接走降级逻辑（比如返回提示“系统繁忙”），不再继续调用外部服务，等30秒后半开探活。这个机制有效防止了外部服务故障时，内部worker还在疯狂重试导致资源耗尽。

4. 端到端检索并发优化

4.1 向量搜索并发瓶颈

检索阶段和写入阶段不同，它是同步响应给用户的，所以并发优化更敏感。Qdrant的HNSW索引是内存型索引，查询速度很快，但并发查询时吞吐量受CPU和内存带宽限制。我观察到的现象是：当并发查询数超过20时，单次查询延迟从20ms涨到80ms左右，如果并发超过50，延迟会到200ms以上，用户就明显感觉卡了。

为了提升检索并发能力，我做了两层优化。第一层，在向量数据库前面加一层本地缓存，把经过语义判重的高频查询结果直接存Redis，设置TTL为10分钟。第二层，把向量检索和关键词过滤结合起来，先通过元数据过滤掉明显不相关的文档集合，再在缩小的集合里做向量搜索，这样每次查询少扫大量不相关向量，QPS上限能提高一倍左右。

另外，索引参数的调优也很关键。HNSW的M参数决定了图的连接数，efSearch参数决定了查询时的候选集大小。我把M从默认的16调到了32，召回率上涨了约2%，而内存增加可以接受；efSearch则根据响应时间要求动态调，低延迟场景用128，高召回场景用256。这个参数建议在测试集上跑一遍，找到业务可接受的召回率和延迟平衡点，不要在线上乱动。

4.2 缓存与结果合并

RAG的检索结果通常需要对多个chunk做去重、排序，然后拼进Prompt里喂给LLM。这里的并发问题在于：多个用户同时发查询时，如果每次都重新计算chunk的相似度分数，会重复消耗CPU。所以我把检索结果和对应的相似度分数做了Redis缓存，key是查询文本的向量hash值加过滤条件，value是chunk id列表和分数。

结果合并阶段还有个大坑：重复chunk。同一个文档被多次更新后，旧版本的chunk可能还在向量库里，查询时会同时返回新旧版本的内容，导致LLM上下文信息互相冲突。我在写入时给每个chunk打上文档版本号，查询时按版本号过滤最新的chunk，并在结果评分时做惩罚，避免旧数据污染上下文。

4.3 前端交互优化

前端如果等整个RAG流程跑完再显示结果，大文件场景下用户会以为系统挂了。实际上，我对文件上传后的处理做了异步化，前端拿到task_id后，用轮询或者SSE的方式获取任务状态。这里建议优先用SSE，能实时推送每个处理阶段的进度，用户体验好很多。轮询的话要控制频率，我一般5秒查一次，避免给后端增加无谓的压力。

检索结果展示也用流式输出。LLM生成回答按token流式返回，用户可以边看边等，感知延迟大幅降低。如果后端不支持流式，前端可以先用占位加载动画，保证交互不卡顿。这些细节虽然不直接影响后端并发，但能显著减少用户反复请求的次数，间接降低系统压力。

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

5.1 典型并发异常对照表

我把实战中遇到的典型问题整理成了表格，方便快速排查：

5.2 压测方法与参数验证

压测不能只测接口次数，要同时模拟大文件上传和并发检索。我用了JMeter，设置两类线程组：一类线程组执行文件上传接口，用CSV数据源配置不同的文件路径和参数，模拟真实多用户上传不同文件；另一类线程组执行检索接口，每个请求的参数也不同，用JSON文件读取。这样能比较真实地反映系统在混合负载下的表现。

压测过程中我重点观察几个指标：事务成功率、平均响应时间、TP99延迟、系统CPU/内存/网络IO。一轮压测下来，把自己定下的限流阈值、worker数、batch size等参数都验证一遍。记得压测前清空旧数据，压测时避免和其他任务混跑，否则数值没有参考意义。

5.3 监控与日志排查建议

排查并发问题，没有监控就像闭着眼开车。我给系统加了四类监控：业务指标（任务积压数、处理成功率）、系统指标（CPU、内存、IO）、外部依赖指标（Embedding服务QPS、Qdrant延迟）、应用指标（接口QPS、响应时间）。日志统一用JSON格式输出，会自动带上request_id和task_id，方便按链路追踪。

日志里有一个小技巧：每个任务的每个阶段（解析完成、切分完成、向量化完成）都打一条带耗时和chunk数量的日志。这样排查慢任务时，直接搜task_id就能看出瓶颈在哪一步。比如发现某个文件解析耗时10秒，但向量化耗时30秒，那问题大概率在切分出的chunk数量太多，或者GPU资源被其他任务抢占。

5.4 独家避坑技巧

有一个坑是很多人没注意到的：文件解析和向量化用不同的worker池，但都共享同一个Redis，如果Redis内存满了，会发生缓存淘汰，任务状态可能丢失。我给Redis设置了allkeys-lru淘汰策略，同时监控内存使用率，超过80%就告警，我还在业务上对大文件的单次上传大小做了限制，当前限制是500MB，超过之后提示用户拆分文件，避免Redis存储任务状态时过载。

另一个坑与Embedding模型的并发有关。本地部署的模型服务如果不开启动态batch，并发请求会一个一个排队，表现就是任务堆积但GPU利用率很低。我改为在模型服务端支持输入队列，把多个请求攒成batch再喂给GPU，效果立竿见影。如果你用的是API方式，也要注意客户端的连接池大小，不要每次请求都新建连接，HTTP连接复用能显著降低延迟。

6. 个人实操心得与扩展建议

6.1 踩过的一次印象深刻的坑

有一次线上检索突然全部超时，查了一圈发现是Qdrant的HNSW索引在后台重建，占用了大量CPU，导致并发查询响应时间直接飙到3秒。我最初没有为索引重建预留资源，所有CPU都被查询耗尽了，启动重建任务后系统就崩溃了。后来我把索引重建任务设置为低优先级，配置了可并发查询的CPU上限，同时在业务低峰期手动触发重建，解决了问题。这次教训让我明白：在RAG系统里，不仅是业务流量要控制，后台维护任务也要纳入资源调度，否则任何一方都能成为压垮系统的最后一根稻草。

6.2 后续可以这样扩展

这套“异步化+并发控制+隔离”的思路还可以继续扩展。如果文档量继续增长到千万级，可以考虑分片部署Qdrant，或者换用分布式向量数据库，同时把任务队列迁移到Kafka，支持更高吞吐。检索效果层面，可以从单纯向量相似度升级为混合检索，结合BM25关键词用RAGFusion方式做结果融合，能明显提升召回质量。更进一步，可以引入Agentic RAG，让智能体根据用户问题拆解子任务、逐步检索多源数据，但这对并发和延迟的要求又会高一个层级，需要把每个子检索都做成可独立的并发任务。

我在实际跑这套系统时，最深的体会是：大文件并发不是一个“功能”，而是一整套工程约束。你做的每一个参数调整——从分块大小到worker数量，从连接池配置到限流阈值——本质都是在为系统的确定性保驾护航。把这些约束打磨好，用户上传多大的文件、多少人同时查询，系统都能给你一个可预期的响应。这也是我觉得RAG从demo走向生产最值得投入的地方。