内存不够怎么办VexDB-Lite PQ 量化索引教程把向量存储压缩到几分之一【免费下载链接】VexDB-LiteA cross-platform vector database, which can be integrated into existing databases as a plugin.项目地址: https://gitcode.com/gh_mirrors/ve/VexDB-LiteVexDB-Lite 是一个可插入 PostgreSQL、DuckDB、SQLite 的跨平台向量数据库插件内置PQProduct Quantization乘积量化量化索引建索引时把每个向量用训练好的码本编码成几十字节的短码索引侧存储直接缩小到原始向量的几分之一特别适合内存紧张但又要跑向量相似度检索的场景。本文面向新手讲清楚 PQ 是什么、能省多少内存以及三种数据库里怎么写出一条 PQ 索引。一、为什么向量检索总吃内存一条 768 维的 embedding常见于文本/图像向量按 float32 存储就是 768 × 4 3072 字节。100 万条向量的裸向量文件约3 GB——这还没算图索引的拓扑结构和查询时的缓存。机器只有 8 GB 内存时索引直接加载进来基本就OOM 预演了。VexDB-Lite 的图索引默认会把向量留在索引侧参与距离计算开启 PQ 后索引侧只保留量化码原始向量留在业务表里查询时再按需取回精确重排。官方压测报告中100 万条 768 维向量的物理存储从 3.4 GB 级别压缩到 1.2 GB 级别见 Cohere-1M 复测报告量级思路与 PQ 一致索引越瘦内存越宽裕。二、PQ 量化原理把 768 维切成小段记编码PQ 的思路非常直观三步走切段把向量切成pq_m段子向量。例如 128 维向量、pq_m 32每段 4 维。训练码本对每段用 K-means 聚成 256 个簇心代码见 common/quantizer/product_quantizer.h 与 common/quantizer/annkmeans.h形成码本。编码每个向量的每段只记录落在哪个簇心1 个字节即可表示。于是压缩比一目了然向量维度原始大小float32PQ 码大小pq_m32压缩比128512 B32 B约 1/167683072 B32 B约 1/961536多模态 embedding6144 B64 Bpq_m64约 1/96怎么选pq_m唯一硬性要求是pq_m必须能整除向量维度。经验值是每段 4~8 维效果最好源码里也有同样的AutoSelectM逻辑见 product_quantizer.h即pq_m ≈ dim / 4768 维用 32~192 都合理128 维用 16~32。段数越多压缩越狠但召回损失也越大——这是本文后面调召回一节要解决的。三、PostgreSQL一条 WITH 子句开启 PQ 索引完整语法示例在 README.md 里核心就两步SET maintenance_work_mem 2GB; -- 训练需要内存内存不足会回退成普通图索引 CREATE INDEX idx_pq ON items USING vexdb_graph (vec floatvector_l2_ops) WITH (quantizer pq, pq_m 4);几个新手最容易踩的点训练样本要够训练样本少于 256 条、或内存预算太低时PQ 会回退成普通图索引并给出 NOTICE不会报错——建完记得检查。训练在主进程跑parallel_workers 0时并行 worker 只参与磁盘构建阶段码本训练仍在 leader 进程完成所以maintenance_work_mem给主进程留足。建完仍可增删改PQ 索引支持建后INSERT/UPDATE/DELETE新向量直接用已训练好的码本编码不用重建。compact 模式是强约束memory_modecompact下量化器必须激活样本或内存不足时直接报错而不是静默回退适合生产上我就要压缩的严格场景。四、DuckDB 与 SQLitecompact 模式极限压缩DuckDB语法见 documentation/features.mdCREATE INDEX idx_pq ON items USING GRAPH_INDEX (vec) WITH (quantizer pq, pq_m 32); -- 紧凑模式索引侧不再保留原始向量镜像 CREATE INDEX idx_compact ON items USING GRAPH_INDEX (vec) WITH (quantizer pq, pq_m 32, memory_mode compact);SQLite直接在建虚拟表时指定完整示例见 vexdb_sqlite/README.mdCREATE VIRTUAL TABLE idx USING GRAPH_INDEX( embedding FLOAT[128], metriccosine, quantizerpq, pq_m32, memory_modecompact );SQLite 侧的细节PQ 按ef_search × 1.25扩展候选再用%_vectors里的原向量做精确重排所以 compact 下业务数据仍然完整只是索引 blob 不再写原始向量镜像。五、PQ 之后怎么调召回和速度PQ 码算出的距离是近似距离VexDB-Lite 用精确重排找回召回先按 PQ 距离筛出一批候选再取原始向量精算距离排序。三个关键旋钮DuckDB 侧参数默认作用vexdb_ef_search64图搜索宽度调大提升召回vexdb_pq_refine_k_factor1.0重排倍率1.0 不额外扩展设 4.0 会按 top k×4 用 PQ 筛候选再精排vexdb_pq_search_modeoff设pq_only跳过精确重排速度最快但召回略低实用策略先默认跑一遍看 recall不够再调大ef_search仍不够且延迟可接受把pq_refine_k_factor提到 2.0~4.0。对应行为有完整测试用例覆盖可参考 graph_index_pq.yaml 与 graph_index_pq_refine.yaml。六、建完索引怎么确认真的量化了三个动作养成习惯查状态PG 用SELECT indexname, use_pq, pq_m FROM vexdb_index_info();DuckDB 用SELECT * FROM vexdb_index_info();。看内存模式PG 的 compact 模式下ALTER INDEX ... SET不会重写已有索引必须REINDEX后用vexdb_index_info()与index_inspect()关注Working Quantizer、Vector Storage两个属性确认实际状态。跑一遍 ANN 查询ORDER BY vec - ... LIMIT 10优化器会自动改写成索引扫描确认走的是量化路径而不是全表扫。小结内存不够时的决策清单向量维度高≥768 内存紧张 → 直接 PQ compact收益最大约 1/96 压缩pq_m取dim/4左右且整除维度兼顾压缩比与召回PG 记得给maintenance_work_mem留训练空间小表256 样本别开 PQ建完用vexdb_index_info()验证再用ef_search/ refine 倍率两档调召回。更多参数与三种引擎的差异对照推荐通读 功能文档想从源码理解量化内核K-means 训练、ADC 距离表、SIMD 分发入口在 common/quantizer/ 目录。【免费下载链接】VexDB-LiteA cross-platform vector database, which can be integrated into existing databases as a plugin.项目地址: https://gitcode.com/gh_mirrors/ve/VexDB-Lite创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考