量化RAG索引前务必实测召回率，不同Embedding差异巨大
If you quantize your RAG index, measure it on your own embeddings first. Same method: 0.992 recall on one dataset, 0.055 on another
RAG工程中的高频踩坑点，提供了完整的量化评估工作流与CI集成方案，直接解决选型焦虑，建议收藏备用。
I was planning to move a RAG index to binary/halfvec to save memory and wanted to know how much retrieval I'd actually lose. The answer was "it depends on your embeddings" way more than I expected.
我原本计划将 RAG 索引转换为 binary/halfvec 格式以节省内存，并想知道实际会损失多少检索效果。结果发现答案比预期中更多地取决于"你的嵌入模型是什么"。
Binary + rerank kept 0.992 of the true top 10 on OpenAI embeddings, 0.348 on GloVe and 0.055 on SIFT. Same method, same settings.
在 OpenAI 嵌入上，二进制 + 重排序保留了原始 Top 10 中的 0.992；在 GloVe 上为 0.348，在 SIFT 上仅为 0.055。使用的是相同的方法和设置。
So I built shrinkvec. You give it your vectors (a .npy/.parquet file or a Postgres table), it holds out queries, computes the exact neighbours, and reports recall, size and latency for 13 options (halfvec, int8, binary, RaBitQ, TurboQuant, rerank pipelines). Then it picks the smallest one that hits your target.
因此我构建了 shrinkvec。你提供向量数据（.npy/.parquet 文件或 Postgres 表），它预留查询集，计算精确邻居，并针对 13 种选项（halfvec、int8、binary、RaBitQ、TurboQuant、重排序管道）报告召回率、大小和延迟。然后它会选择满足你目标的最小方案。
The part I use most: run it in CI with --min-recall 0.95, so the build fails if switching embedding models quietly hurts search.
我最常用的部分：在 CI 中运行并设置 --min-recall 0.95，这样如果切换嵌入模型悄悄影响了搜索效果，构建就会失败。
pip install 'shrinkvec[pg]' Demo: docker run --rm -p 8080:8080 ghcr.io/ahmad-codex/shrinkvec:demo Repo (MIT): https://github.com/ahmad-codex/shrinkvec
pip install 'shrinkvec[pg]' 演示：docker run --rm -p 8080:8080 ghcr.io/ahmad-codex/shrinkvec:demo 仓库（MIT 协议）：https://github.com/ahmad-codex/shrinkvec
Has anyone checked recall after switching to a compressed index, or do most people just trust the defaults?
有人检查过切换到压缩索引后的召回率吗？还是说大多数人只是信任默认值？
更进一步：量化金融体系
看懂新闻只是起点——沿量化金融路径，把它变成能交付的工程能力