稀疏向量集合的存储优化核心是只存非零元素及其索引，跳过冗余零值；适用于稀疏度＞95%（非零占比极低）的高维向量，可大幅节省内存并提升计算效率。
稀疏向量集合的存储优化，核心在于“只存非零，不存冗余”。当向量维度高、但绝大多数元素为零（或接近零）时，传统密集存储方式会造成严重内存浪费——比如百万维向量中仅几十个非零值，却仍分配百万个浮点数空间。真正有效的压缩不是靠通用算法硬压，而是从数据结构层面跳过零值，用索引+值的紧凑表示替代全量数组。
识别是否适合稀疏存储
不是所有向量都该转稀疏。关键看两个指标：
- 稀疏度 > 95%（即非零元素占比
- 非零位置分布无强规律：如随机散落、按用户行为触发、文本TF-IDF特征等，适合用哈希或三元组索引；若非零集中在某几列（如固定字段），可能更适合列式压缩
- 查询模式以点查/内积为主，非全量遍历：稀疏结构天然支持快速跳过零项计算，但不擅长range scan或逐元素映射
主流稀疏向量实现方式对比
不同场景下，底层结构选择直接影响内存和性能：
- COO（Coordinate Format）：最直观，存三个平行数组——rows[]、cols[]、data[]，每组对应一个非零元。适合构建阶段插入频繁，但不支持高效向量运算
-
CSR（Compressed Sparse Row）：按行压缩，用indptr[]记录每行起始偏移，indices[]存列号，data[]存值。对行向量内积、批量相似度计算友好，pgvector 的
sparsevec即基于此 -
DOK（Dictionary of Keys）：用哈希表直接映射
(i,j) → value，随机写入/更新极快，但序列化后体积略大，适合动态稀疏特征更新场景
在 pgvector 中启用 sparsevec 存储
PostgreSQL 扩展 pgvector 原生支持稀疏向量类型 sparsevec，无需额外编译，开箱即用：
- 建表时指定类型：
CREATE TABLE docs (id SERIAL, embedding sparsevec(1024)); - 插入时自动解析稀疏语法：
INSERT INTO docs VALUES (1, '{1:2.3, 55:−1.7, 999:0.8}');—— 只传非零项，键为下标，值为浮点数 - 查询仍兼容原操作：
SELECT * FROM docs ORDER BY embedding '{0:1.0, 2:0.5}' LIMIT 3;，内核自动展开稀疏内积 - 实测效果：100万条1024维向量，平均稀疏度98.3%，原始float32需约4GB，转sparsevec后仅需约180MB（压缩率95.5%）
进阶：混合压缩策略提升实效性
纯稀疏结构在某些场景仍有优化空间，可叠加轻量级处理：
- 值域截断 + int16 编码：若非零值集中在 [−3.0, +3.0]，可用 int16 按 1/1024 精度量化，再与索引一起存，进一步节省30–40%空间
-
索引差分编码：对排序后的列索引（如 CSR 的
indices[]），用 delta 编码代替绝对值，小整数更易压缩，LZ4二次压缩后体积再降15–25% - 分块稀疏：对超长向量（如2M维），按1024维分块，每块独立稀疏化+局部归一化，兼顾缓存友好性与精度稳定性
