向量数据库相关
查看所有标签做 RAG 的后端工程师大多有过这样的经历：一套 PDF 解析（PyMuPDF + pdfplumber）、分块、embedding、rerank 的管线在技术文档上效果不错，一换到财报、合同、产品手册就开始掉分。检索出来的段落看着相关，但答案在表格的某个交叉格里、在某张流程图的标注里、或者依赖两栏排版的位置关系——这些信息在"解析成纯文本"的那一步就已经丢了。
VisRAG 这篇工作把这个损失量化过：不做文本解析、直接把文档页当图片用 VLM 嵌入，端到端比传统文本 RAG 管线高 20%~40%。这个数字不必照搬（它建立在自建的检索/生成数据上），但方向是明确的：多模态文档的检索单元应该是"页"，而不是"段落"。
本文不讨论 VLM 生成侧，只讲检索层怎么落地：三条技术路线的取舍、多向量的存储与算力账本、把成本压下来的四种手段，以及我自己在 ColQwen 上趟过的坑。前置阅读可以看 RAG 进阶检索 和 向量索引 HNSW/IVF-PQ 两篇。
RAG 的链路谁都能搭：文档切块、embedding 进库、相似度召回、拼 prompt。但同一套链路，有人线上答对率八成，有人五成——差距不在「会不会搭」，而在「每一步的效果账算没算清」。基础链路见 RAG 全链路解析，这篇讲进阶：切块、混合检索、Re-ranking 各值多少分、花多少钱，Graph RAG 什么时候才值得上。
这是「每日一题」专栏的第十三篇。每天一道面试题，后端 + AI 混合路线，从原理到代码一次讲清。上一篇讲了 Feed 流系统设计，今天按轮换回到 AI/LLM 方向，聊上一篇预告的题：RAG 检索增强生成。
前两篇分别聊了向量数据库选型（向量数据库选型对比）和检索链路的分块/重排序（RAG 检索优化深度拆解），但都把 Embedding 模型当成了黑盒——喂进去文本，吐出来一串浮点向量。这篇把盒子拆开，聚焦一个高级后端工程师做规模化 RAG 时迟早会撞上的问题：向量又大又多，存储和检索延迟怎么砍？
先算笔账。一个 100 万 chunk 的语料库，用 1536 维 float32 的 Embedding（比如 text-embedding-3-small），单是向量本体就是：
1,000,000 × 1536 × 4 字节 ≈ 6.1 GB
这还没算 HNSW 图索引的开销（通常再乘 1.2 到 1.5 倍）。规模涨到 1000 万 chunk，向量本体就 61GB，单机内存放不下，得上分布式。但真相是：绝大多数检索场景根本用不到 1536 维的全精度浮点。今天聊的三件事——对比学习怎么训出 Embedding、Matryoshka 怎么一个模型任意维度截断、量化怎么把向量压 8 到 32 倍——就是把这笔账砍下来的三条路。
先抛一个反直觉的结论：RAG 效果不好的时候，九成问题出在检索，而不是生成。生成模型再强，检索漏掉的 chunk 永远不会出现在 context 里——"垃圾进，垃圾出"在 RAG 里是一条铁律。业界普遍共识是「检索质量决定 RAG 上限」：生成只能在上限之内修修补补，把答案写得通顺，但补不回没检索到的事实。
本文不聊"如何搭一个 hello-world RAG"，而是拆解检索链路里真正决定召回率的三个环节——分块（Chunking）、检索融合（Hybrid Search）、重排序（Re-ranking）——每一环给出可运行代码、性能量级和生产踩坑记录。这是我在多个生产 RAG 系统里反复调过的地方。
RAG 火了一年多，向量数据库的选型问题被问了无数次。本文基于实际使用经验，系统对比 8 款主流向量数据库，帮你做技术决策。