RAG大文件高并发处理：从PDF解析到语义检索的工程实践

1. 项目概述：当RAG撞上大文件与高并发，我们到底在解决什么问题？

“RAG：支持大文件并发实践”——这个标题里藏着三个关键词的硬核碰撞：RAG（检索增强生成）、大文件（几十MB到数GB级原始文档）、并发（多用户、多任务、多线程同时触发知识检索与生成）。这不是一个玩具Demo，而是真实企业知识中台落地时踩出的第一道深坑。我带团队做过7个行业RAG项目，从法律合同库到医疗影像报告解析，几乎每个项目上线前都卡在同一个节点：用户上传一份200页PDF的尽调报告，系统卡死；三个人同时问“这份年报里Q3毛利率是多少”，响应延迟飙到12秒；更别说财务部门批量导入500份扫描版审计底稿——系统直接OOM。这背后不是模型不够强，而是整个RAG流水线在数据摄入层和检索服务层同时失守。所谓“RAG瓶颈”，90%以上出在文件预处理环节：传统方案把PDF一页页转成文本再切块，单文件耗时3分钟，10个并发就是30分钟排队；OCR识别精度一掉，后续所有检索都是空中楼阁；向量库写入没做分片锁控制，多个进程抢写同一chunk索引，结果检索返回乱码。而“rag知识库能存储图片嘛”这类问题，本质是混淆了原始载体和可检索语义单元——图片本身不进向量库，但它的OCR文字、结构化标签、甚至CLIP生成的视觉嵌入，必须被统一纳入多模态索引体系。本项目要做的，就是把“支持大文件并发”从一句口号，变成可量化、可压测、可运维的工程事实：实测单节点稳定支撑50路并发PDF解析（平均页数180页）+ 200QPS语义检索 + 30路流式生成，端到端P95延迟压在1.8秒内。适合正在搭建生产级知识库的架构师、需要快速交付RAG项目的算法工程师，以及被老板追问“为什么用户上传个文件要等半天”的技术负责人。

2. 整体架构设计：为什么必须放弃“单线程切块+全量入库”老路？

2.1 传统RAG流水线的三大致命断点

先说清楚我们到底要绕开哪些坑。几乎所有开源RAG教程（包括LangChain官方示例）默认采用的流程是：上传文件 → 同步解析（PDF→text）→ 按固定长度切块（如512字符）→ 调用Embedding API → 写入向量库 → 用户提问检索。这套逻辑在单文件、小文本场景下很优雅，但一旦放大到生产环境，立刻暴露三个结构性缺陷：

第一，IO阻塞不可解。PDF解析（尤其含表格/公式/扫描件）本质是CPU密集型+磁盘随机读操作。Python的pypdf或pdfplumber在解析100MB PDF时，单线程会持续占用一个CPU核心超4分钟，期间无法响应其他请求。更糟的是，当10个用户同时上传，进程队列堆积，Nginx的worker_connections很快耗尽，出现“nginx最大并发链接数老是用超”的告警——这不是Nginx配置问题，而是后端根本没释放连接。

第二，切块逻辑与业务语义脱钩。“按512字符切”是典型的技术妥协。一份财务报表里，“资产负债表”和“利润表”可能被硬生生切成两段，导致检索时只召回“资产”却漏掉“负债”，生成答案直接错误。而“ontology rag”强调的领域本体约束，在粗暴切块下完全失效。我们曾测试过某银行RAG系统：用户问“2023年不良贷款率”，因关键数字和定义分散在不同切块，top3检索结果无一包含完整计算公式，LLM只能胡编。

第三，向量库写入缺乏并发安全机制。多数教程直接用chroma.add()或pgvector.insert()，看似简单，实则埋雷。当多进程同时写入同一collection，若未加分布式锁或事务控制，会出现向量ID重复、元数据错乱。某客户线上事故复盘显示：并发导入500份合同后，检索“违约责任”条款，返回结果中混入了3份无关采购协议的签字页内容——根源就是向量ID冲突导致元数据映射错位。

提示：别迷信“rag框架自动处理并发”。LangChain的RecursiveCharacterTextSplitter是线程安全的，但它的上游（PDF解析）和下游（向量写入）完全不保证。真正的并发支持必须贯穿全链路。

2.2 我们的设计哲学：分层解耦 + 异步流水线 + 语义感知切块

针对上述断点，本项目采用三层解耦架构，核心思想是让每个环节只专注一件事，并通过消息队列解耦压力：

• 接入层（Ingestion Gateway）：Nginx反向代理 + 自定义上传中间件。关键改造是启用client_max_body_size 2G，并添加upload_progress模块实时反馈进度；对上传请求做令牌桶限流（每用户5路并发），避免突发流量打垮后端。

• 处理层（Async Processing Pipeline）：这是核心创新区。放弃单进程同步处理，改为“解析-切块-嵌入-入库”四阶段异步流水线：

  • 解析阶段：用unstructured库替代pypdf，它内置partition_pdf可智能识别标题、表格、页眉页脚，且支持多进程并行（processes=4参数实测提升3.2倍吞吐）；
  • 切块阶段：抛弃固定长度，改用语义边界切块（Semantic Chunking）。基于spacy的句子分割器，结合规则（如遇到“第X条”、“【风险提示】”等法律/金融标记符强制切分），确保每个chunk是一个完整语义单元；
  • 嵌入阶段：本地部署bge-m3模型（FP16量化后仅2.1GB显存），通过vLLM引擎提供高吞吐Embedding API，单卡A10可支撑120 QPS；
  • 入库阶段：向量库选用Qdrant（非Chroma），因其原生支持upsert原子操作和payload_index高效过滤，写入时自动加分布式锁。

• 服务层（Retrieval & Generation Service）：用户查询不直连向量库，而是通过FastAPI网关路由。关键优化是检索-重排-生成三级流水线：先用Qdrant做粗筛（filter by metadata），再用cross-encoder做精排（rerank top 50→top 5），最后将精排结果喂给LLM。这样既降低LLM token消耗，又提升答案准确率。

这套设计让“大文件”和“并发”不再是互斥选项。实测数据：单节点（32C64G + A10×2）处理100份150页PDF（总大小42GB），从上传完成到全部可检索，耗时18分23秒，全程无失败；并发查询时，P95延迟稳定在1.8秒内，远优于行业平均的5-8秒。

2.3 为什么选Qdrant而非Chroma/Pinecone？

选型不是跟风，而是基于压测数据的理性决策。我们对比了Chroma、Pinecone、Qdrant在大文件场景下的表现（测试环境：AWS c5.4xlarge + 2TB EBS）：

关键洞察：Chroma的SQLite底层在高并发写入时必然锁表，而Pinecone的serverless模式虽省心，但“100g大文件下载链接”这类需求要求我们能精确控制chunk归属（比如用户只想查某份PDF的第15页），这就必须依赖Qdrant的payload字段做细粒度索引。至于“rag知识库和结构知识库区分”，Qdrant的payload本质就是轻量级结构知识库——它不替代Neo4j，但能让RAG具备基础的关系推理能力（如“找所有属于《XX合同》且条款类型为‘违约’的chunk”）。

3. 核心细节解析：大文件处理的五个生死关

3.1 PDF解析：为什么OCR必须分层处理？

大文件的“大”，80%来自扫描件PDF。直接扔给Tesseract OCR？等着看30分钟无响应吧。我们的方案是三层OCR策略，按文件特征自动路由：

• 第一层：纯文本PDF快速通道。用pdfplumber提取page.chars，若字符密度>1500/页且无图像对象，则跳过OCR，直接走文本解析。实测提速5倍，准确率99.9%（因为PDF原文就是文本）。

• 第二层：混合PDF智能降级。检测到页面含图像但文字占比>30%，启用unstructured的strategy="hi_res"模式：先用轻量级OCR（paddleocr）识别文字区域，再对图像区域用layoutparser定位表格/公式框，最后拼接结构化文本。此模式单页耗时1.2秒，比全页Tesseract（8.7秒）快7倍。

• 第三层：纯扫描件精准攻坚。文字占比<10%的页面，才调用Tesseract 5.3（LSTM模型）+OpenCV预处理（二值化+去噪+旋转校正）。重点来了：绝不整页OCR！我们用layoutparser先分割出“正文”“表格”“页眉页脚”区域，只对正文区域OCR。某法院判决书测试显示，整页OCR错误率23%，而分区OCR降至4.1%，且耗时从210秒压缩到68秒。

实操心得：很多团队卡在OCR，其实是没做预处理。我们发现80%的OCR失败源于PDF图像DPI过低（<150dpi）。解决方案是在上传网关增加convert -density 200 input.pdf output.pdf命令，用ImageMagick无损提升分辨率——这一步让OCR准确率平均提升37%，且不增加存储成本（处理完即删临时文件）。

3.2 语义切块：如何让“第X条”成为天然切分点？

固定长度切块是RAG准确率的最大杀手。我们设计了一套领域感知切块规则引擎，以法律/金融文档为例：

• 一级切分符：r'第[零一二三四五六七八九十百千]+条'（匹配“第一条”“第一百零三条”）
• 二级切分符：r'【[^】]+】'（匹配“【风险提示】”“【特别约定】”）
• 三级切分符：r'\n\s*[-•]\s+'（匹配无序列表项）

但光有正则不够。我们引入上下文窗口约束：每个chunk必须满足min_length=200 & max_length=1200字符，且强制包含切分符前后的2句上下文。例如切分“第三条 付款方式”时，实际chunk是：“...第二条 交货时间：甲方应于2023年12月31日前完成交货。\n\n第三条 付款方式：本合同总价款为人民币XXX元，分三期支付：第一期于签约后5日内付30%...”——这样确保LLM看到完整条款逻辑。

验证效果：在某证券公司招股书RAG测试中，用户问“募集资金用途有哪些”，传统切块召回3个碎片（分别含“用于研发”“用于营销”“用于偿还债务”），而语义切块直接召回一个完整chunk：“募集资金扣除发行费用后，将全部用于以下项目：（一）研发中心建设项目，投资金额XX万元；（二）营销网络拓展项目，投资金额XX万元；（三）偿还银行贷款，金额XX万元。”答案准确率从62%跃升至94%。

3.3 向量库写入：分布式锁的两种实现与取舍

并发写入的核心矛盾是：既要快，又要准。我们尝试过三种锁方案，最终选择Redis+Lua原子脚本：

• 方案1：数据库行锁（PostgreSQL）。在chunk_metadata表加FOR UPDATE锁。问题：锁粒度太粗，一个文件的所有chunk共享一把锁，10个文件并发时实际是串行写入，吞吐归零。

• 方案2：文件级Redis锁。用SET file_id:xxx "locked" EX 300 NX。优点简单，缺点明显：若进程崩溃未释放锁，整个文件永久不可写。某次线上事故因GPU OOM导致进程退出，锁残留5小时，业务方投诉“上传的文件怎么搜不到”。

• 方案3：Chunk级乐观锁（最终采用）。写入前先GET chunk_id:xxx:version，若存在则比对版本号；写入时INCR chunk_id:xxx:version并SET chunk_id:xxx:payload "..."。Lua脚本保证原子性：

  local version = redis.call("GET", KEYS[1]..":version") if not version or tonumber(version) < tonumber(ARGV[1]) then redis.call("SET", KEYS[1]..":payload", ARGV[2]) redis.call("SET", KEYS[1]..":version", ARGV[1]) return 1 else return 0 end

  此方案吞吐提升4倍，且无死锁风险。代价是需在应用层处理return 0的重试逻辑——但这比锁住整个系统值得多。

3.4 大文件元数据建模：为什么payload比document更重要？

很多人把RAG元数据当成可选字段，但在大文件场景，它是救命稻草。我们的payloadschema强制包含5个核心字段：

{ "file_id": "doc_2023_001", "file_name": "2023年度审计报告.pdf", "page_number": 42, "section_title": "五、或有事项", "chunk_type": "table_text", // text/table/formula/image_caption "source_hash": "sha256_xxx" // 用于去重 }

关键设计点：

• page_number：支持“查这份报告第42页的内容”，这是streamsaver.js下载大文件场景的刚需——用户下载大文件后，需精准定位原文位置；
• chunk_type：让检索可过滤。用户问“展示所有表格”，加filter={"chunk_type":"table"}即可，避免LLM胡编表格数据；
• source_hash：解决“git 无法提交大文件”的同类问题——大文件去重。同一份PDF上传10次，只存1份向量，节省83%存储。

实测某律所知识库：启用payload过滤后，检索“担保条款”的准确率从71%升至96%，因为排除了大量无关的“声明”“附件”chunk。

3.5 并发查询优化：为什么重排（Rerank）必须前置？

LLM生成是RAG最贵环节。传统做法是“检索top 5 → 直接喂LLM”，但大文件场景下，top 5常含噪声。我们的方案是在检索后、生成前插入Cross-Encoder重排：

• 使用bge-reranker-base模型（仅380MB），部署为独立API服务；
• Qdrant粗筛返回top 50 chunk（耗时0.15s），全部送入reranker；
• reranker输出top 5相关chunk（耗时0.32s），再送LLM；
• 总耗时0.47s，比直接送top 50给LLM（token成本+延迟）低62%。

为什么不用LLM自己重排？实测gpt-4-turbo做rerank，单次耗时2.8秒，且成本是bge-reranker的17倍。而“swift并发安全”提醒我们：重排服务必须无状态、可水平扩展。我们用Kubernetes HPA根据CPU使用率自动扩缩reranker Pod，峰值支撑300 QPS。

4. 实操过程：从零搭建高并发RAG的七步落地清单

4.1 环境准备：硬件与软件的硬性门槛

别被“免费大文件测试包”误导——生产环境有硬指标。我们推荐的最小可行配置（支撑50并发）：

• CPU：32核（Intel Xeon Gold 6330或同级），主频≥2.0GHz。低于24核时，unstructured多进程解析会因上下文切换拖慢30%。
• 内存：64GB DDR4 ECC。注意：unstructured解析1GB PDF需约8GB内存，50并发需预留40GB缓冲。
• GPU：1×NVIDIA A10（24GB显存）。bge-m3FP16推理需18GB，留6GB给reranker和LLM。
• 存储：2TB NVMe SSD（非HDD！）。unstructured随机读取PDF页时，HDD IOPS不足会导致解析卡顿。
• OS：Ubuntu 22.04 LTS（内核5.15+）。CentOS 7因glibc版本过低，无法运行新版unstructured。

软件栈版本锁定（避坑关键）：

• Python 3.10.12（3.11+有GIL优化但unstructured不兼容）
• unstructured 0.10.27（修复了PDF表格跨页解析bug）
• Qdrant 1.9.0（支持payload_index的稳定版）
• vLLM 0.4.2（bge-m3量化推理最佳兼容版）

注意：网上教程常推荐llama.cpp跑Embedding，但实测其对长文本（>8192token）支持差，bge-m3在vLLM下吞吐高2.3倍。别省这点显存，A10够用。

4.2 文件上传网关：如何让前端“前端使用worker上传大文件”不卡死？

前端用Worker分片上传是标准解法，但后端必须配套。我们的FastAPI上传接口关键代码：

@app.post("/upload") async def upload_file( file: UploadFile = File(...), background_tasks: BackgroundTasks = BackgroundTasks() ): # 1. 生成唯一file_id file_id = f"doc_{int(time.time())}_{secrets.token_hex(4)}" # 2. 保存临时文件（用tmpfs内存盘加速） temp_path = f"/dev/shm/{file_id}.pdf" # /dev/shm是内存文件系统 with open(temp_path, "wb") as f: f.write(await file.read()) # 3. 异步触发处理流水线 background_tasks.add_task(process_pipeline, file_id, temp_path) return {"file_id": file_id, "status": "processing"}

重点在/dev/shm：Linux内存文件系统，读写速度是SSD的15倍。实测100MB PDF上传+保存，耗时从1.2秒降至0.08秒。而background_tasks确保HTTP连接立即释放，避免“nginx最大并发链接数老是用超”。

前端Worker代码要点：

• 分片大小设为4MB（非默认的1MB），减少HTTP请求数；
• 启用fetch的keepalive: true，复用TCP连接；
• 上传进度用SharedArrayBuffer跨Worker通信，UI实时显示。

4.3 解析流水线：unstructured的深度定制

unstructured默认配置不适合大文件。我们修改其partition_pdf参数：

from unstructured.partition.pdf import partition_pdf elements = partition_pdf( filename=temp_path, strategy="hi_res", # 必须！否则纯文本PDF也走OCR hi_res_model_name="yolox", # layoutparser模型 infer_table_structure=True, # 表格结构识别 include_page_breaks=True, # 保留页分隔符，切块时用 pages="1-100", # 防止意外解析整本PDF pdf_inferrence=True, # 启用PDF专用推理 )

关键参数解读：

• strategy="hi_res"：启用高精度模式，自动选择OCR引擎；
• pages="1-100"：强制限制页数，防止单文件解析失控（大文件常含无效附录）；
• include_page_breaks=True：在元素列表中插入PageBreak对象，切块时可据此强制分段。

解析后，elements是结构化对象列表，含Text,Table,Title等类型。我们遍历并构建page_map：

page_map = {} for el in elements: if isinstance(el, PageBreak): current_page += 1 elif hasattr(el, 'text'): page_map.setdefault(current_page, []).append(el.text)

此page_map是后续语义切块和payload注入的基础。

4.4 语义切块引擎：正则与NLP的协同作战

切块不是纯正则，也不是纯NLP，而是两者融合。我们的SemanticChunker类：

import re from spacy.lang.zh import Chinese class SemanticChunker: def __init__(self): self.nlp = Chinese() # 中文分词 self.split_patterns = [ (r'第[零一二三四五六七八九十百千]+条', 1), # 法律条款 (r'【[^】]+】', 2), # 标题块 (r'\n\s*[-•]\s+', 3), # 列表项 ] def chunk(self, text, page_num): chunks = [] # Step1: 按一级切分符粗分 parts = re.split(r'(第[零一二三四五六七八九十百千]+条)', text) for part in parts: if not part.strip(): continue # Step2: 对每个part，用spacy分句 doc = self.nlp(part) sentences = [sent.text.strip() for sent in doc.sents] # Step3: 合并句子成chunk（满足min/max长度） current_chunk = "" for sent in sentences: if len(current_chunk) + len(sent) < 1200: current_chunk += sent + "\n" else: if len(current_chunk) > 200: chunks.append(self._build_payload(current_chunk, page_num)) current_chunk = sent + "\n" return chunks def _build_payload(self, text, page_num): return { "content": text, "payload": { "file_id": self.file_id, "page_number": page_num, "chunk_type": "text" } }

此引擎确保每个chunk既是语义完整单元，又携带精准元数据。实测在《民法典》PDF上，切块数比固定长度少37%，但检索准确率高28%。

4.5 向量入库：Qdrant的批量Upsert实战

Qdrant的upsert是并发安全的核心。批量写入代码：

from qdrant_client import QdrantClient from qdrant_client.models import PointStruct, VectorParams, Distance client = QdrantClient("http://qdrant:6333") # 创建collection（一次） client.recreate_collection( collection_name="rag_knowledge", vectors_config=VectorParams(size=1024, distance=Distance.COSINE), payload_schema={ # 显式声明payload schema "file_id": "string", "page_number": "integer", "chunk_type": "string" } ) # 批量upsert（关键！） def batch_upsert(points: List[PointStruct]): # 分批，每批100个点 for i in range(0, len(points), 100): batch = points[i:i+100] client.upsert( collection_name="rag_knowledge", points=batch, wait=True # 等待写入完成，保证顺序 )

wait=True是并发安全的关键——它确保这批100个点写入完成才返回，避免多批次交叉。实测单批次100点耗时0.8秒，5000点总耗时42秒，比逐个插入（210秒）快5倍。

4.6 检索服务：三级流水线的FastAPI实现

检索接口是性能瓶颈，必须极致优化：

@app.post("/search") async def search(query: str, filter: dict = None): # Step1: Qdrant粗筛（毫秒级） search_result = client.search( collection_name="rag_knowledge", query_vector=embed_model.encode(query).tolist(), limit=50, query_filter=Filter(**filter) if filter else None, with_payload=True, with_vectors=False ) # Step2: Rerank（亚秒级） reranked = rerank_service.rerank( query=query, documents=[r.payload["content"] for r in search_result] ) # 返回top 5索引 # Step3: 构造prompt喂LLM（秒级） context = "\n\n".join([ f"[{r.payload['file_name']} P.{r.payload['page_number']}] {r.payload['content']}" for r in [search_result[i] for i in reranked] ]) prompt = f"基于以下资料回答问题：\n{context}\n\n问题：{query}" answer = llm.generate(prompt) return {"answer": answer, "sources": [r.payload for r in search_result[:5]]}

关键优化点：

• with_vectors=False：只取payload，不传向量，减少网络传输；
• limit=50：粗筛足够，rerank再精炼；
• sources返回完整payload，前端可渲染“来源：XX报告 第42页”。

4.7 压测与调优：用Locust模拟真实并发

不压测的RAG都是纸上谈兵。我们的Locust脚本模拟三类用户：

from locust import HttpUser, task, between class RAGUser(HttpUser): wait_time = between(1, 3) @task(3) # 30%权重：上传文件 def upload_pdf(self): with open("test_100mb.pdf", "rb") as f: self.client.post("/upload", files={"file": f}) @task(5) # 50%权重：并发查询 def search_query(self): self.client.post("/search", json={ "query": "2023年净利润是多少？", "filter": {"file_id": "doc_2023_001"} }) @task(2) # 20%权重：复杂查询（带rerank） def complex_search(self): self.client.post("/search", json={ "query": "比较A公司和B公司在研发投入上的差异", "filter": {"chunk_type": "table_text"} })

压测结果（50虚拟用户）：

• 上传成功率：100%（平均耗时28.3s）
• 查询P95延迟：1.78s（目标1.8s）
• Qdrant CPU使用率：62%（未达瓶颈）
• GPU显存占用：21.4GB/24GB（安全余量）

调优发现：当rerank服务Pod数<3时，P95延迟飙升至3.2s，故最终定为3副本+HPA。

5. 常见问题与排查技巧实录：那些文档里不会写的坑

5.1 “rag知识库能存储图片嘛？”——真相与解法

这是高频误解。RAG向量库不存原始图片，但必须存图片的可检索表示。我们提供三种方案：

• OCR文本：对图片调用paddleocr，存识别文字+坐标（payload中加ocr_text和bbox字段）。用户问“图中表格数据”，直接检索ocr_text。
• CLIP嵌入：用open_clip提取图片视觉特征向量，存入Qdrant的多向量字段（image_vector）。检索时，用户提问“找所有含汽车的图片”，用文本向量查image_vector相似度。
• 结构化标签：人工或模型生成标签（如{"type":"chart","topic":"revenue","year":"2023"}），存入payload，支持精确过滤。

实操心得：某客户坚持要“存原图”，我们妥协后发现：1000张图占存储12TB，但99%查询只需OCR文本。最终方案是——原图存OSS，向量库只存OCR+CLIP+标签，成本降92%。

5.2 “zcode可以同时并发多少个？”——并发数的科学测算方法

网上流传的“zcode并发数”毫无意义。真正决定并发上限的是最慢环节的吞吐。我们用公式计算：

系统最大并发 = min( Nginx worker_connections / 2, CPU核心数 × 1.5, GPU显存GB ÷ 18GB × 100, Qdrant写入QPS × 0.8 )

代入我们的配置（1024 connections, 32核, 24GB显存, Qdrant 120 QPS）：

• Nginx：1024/2 = 512
• CPU：32×1.5 = 48
• GPU：24÷18×100 = 133
• Qdrant：120×0.8 = 96
  →瓶颈在CPU，理论最大并发48。实测48并发时，CPU使用率92%，故安全值设为40。

5.3 “大文件导出”与“100g大文件下载链接”的实现

用户要下载原始大文件？别用send_file！我们的方案：

• 前端请求/download?file_id=xxx，后端生成预签名URL（AWS S3或阿里云OSS）；
• URL有效期2小时，自动过期；
• 后端记录下载日志（file_id,user_id,timestamp），用于审计；
• 对于“100g大文件”，启用S3的multipart download，前端用streamsaver.js分片下载，支持断点续传。

关键代码（FastAPI）：

@app.get("/download") async def download_file(file_id: str): # 生成预签名URL（S3 boto3） presigned_url = s3_client.generate_presigned_url( 'get_object', Params={'Bucket': 'rag-bucket', 'Key': f'raw/{file_id}.pdf'}, ExpiresIn=7200 # 2小时 ) return {"download_url": presigned_url}

5.4 “数据库并发锁”与RAG的关联陷阱

很多人以为“数据库锁”只影响OLTP。但在RAG中，当多个进程更新同一份文档的元数据（如file_status="processed"），若用MySQL的UPDATE ... WHERE id=xxx，会触发行锁。我们的规避方案：

• 元数据表用Redis：file_status:doc_2023_001存Redis，SETNX保证原子性；
• 向量库用Qdrant：其upsert自带乐观锁，无需额外处理；
• 绝对不用PostgreSQL存chunk：除非你真需要SQL JOIN，否则纯属自找麻烦。

5.5 “ontology rag”落地难点：本体如何注入RAG？

Ontology不是加个图谱就叫Ontology RAG。我们的轻量级方案：

• 在payload中加ontology_path字段，如["Financial", "Report", "ProfitLoss"]；
• 检索时，用户问“找所有利润表”，加filter={"ontology_path":{"$contains":"ProfitLoss"}}；
• 本体关系由业务方维护JSON Schema，不耦合RAG引擎。

某银行案例：将会计准则本体（CAS）映射到payload，用户问“CAS 22号准则相关条款”，直接过滤，准确率98%。

6. 最后分享一个血泪教训：监控必须覆盖“文件生命周期”

所有RAG项目都缺监控，直到出事。我们强制部署的5个黄金指标：

1. 文件处理时长分布：按file_id统计parse_time,chunk_time,embed_time,upsert_time，P95>120秒告警；
2. Qdrant写入失败率：upsert返回`status