4 篇博文 含有标签「Embedding」

做 RAG 的后端工程师大多有过这样的经历：一套 PDF 解析（PyMuPDF + pdfplumber）、分块、embedding、rerank 的管线在技术文档上效果不错，一换到财报、合同、产品手册就开始掉分。检索出来的段落看着相关，但答案在表格的某个交叉格里、在某张流程图的标注里、或者依赖两栏排版的位置关系——这些信息在"解析成纯文本"的那一步就已经丢了。

VisRAG 这篇工作把这个损失量化过：不做文本解析、直接把文档页当图片用 VLM 嵌入，端到端比传统文本 RAG 管线高 20%~40%。这个数字不必照搬（它建立在自建的检索/生成数据上），但方向是明确的：多模态文档的检索单元应该是"页"，而不是"段落"。

本文不讨论 VLM 生成侧，只讲检索层怎么落地：三条技术路线的取舍、多向量的存储与算力账本、把成本压下来的四种手段，以及我自己在 ColQwen 上趟过的坑。前置阅读可以看 RAG 进阶检索 和 向量索引 HNSW/IVF-PQ 两篇。

向量检索上线后最常见的两类问题，一类是「延迟一高就加机器」，另一类是「召回不够就把 efSearch 往上调两倍」——两种都治不了根，因为向量索引不存在「更好的参数」，只存在召回、延迟、内存三角里你愿意让出哪条边。基础链路见 RAG 全链路解析，召回与重排的工程取舍见 RAG 进阶实战，这篇下沉一层，讲索引本身：HNSW 的图怎么长、IVF-PQ 的码本怎么省内存、过滤检索为什么会塌方、删除为什么永远不还内存。

RAG 的链路谁都能搭：文档切块、embedding 进库、相似度召回、拼 prompt。但同一套链路，有人线上答对率八成，有人五成——差距不在「会不会搭」，而在「每一步的效果账算没算清」。基础链路见 RAG 全链路解析，这篇讲进阶：切块、混合检索、Re-ranking 各值多少分、花多少钱，Graph 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 倍——就是把这笔账砍下来的三条路。