❝开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共3400人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7 8群已经爆满 9群 300+，开10群PolarDB专业学习群110+)
我很笨--学习PG Vector 1个小时我懂得HNSW 索引调优和使用--要不你也试试！！ （系列 4 ）
我很笨--学习PG Vector 1个小时我懂得了为什么用HNSW不用IVFFlat （系列 3 ）
我很笨--学习PG Vector 1个小时我懂得了索引 基本原理--要不你也试试！！ （系列 2 ）
我很笨--学习PGVector的 1个小时我懂得了AI 基本的原理--要不你也试试！！
接着上期，我们在postgresql 中使用pgvector的情况下，应该使用HNSW来建立向量索引的事情已经确定，这里我们确定 HNSW是极度的依赖内存，如何减少向量本身的体积是核心的挑战。
我们之前说了几个部分
1 使用半精度的向量 halfvec
这里需要研究的是在从32位浮点降低到16位浮点后，节省50%的内存空间同时，评估对特定模型的召回率的损耗问题。
2 二进制向量模型，如果业务使用了特定的embedding 模型，通过使用bit类型进行hamming distance的计算可以进一步压缩，特别适合超大规模的粗筛选场景。
3 稀疏向量:在这样的向量中，包含大量的五项的向量，我们需要学习如何用稀疏表示这些向量来优化存储和计算效率。
除此以外我们还应该研究混合查询中的计划分析，同样AI查询中会同时存在普通查询，怎么通过优化查询的方式来加速AI查询也是我们节省内存的一种手段。
这样的查询会存在索引合并的问题，同时预过滤和后过滤，过滤的条件非常严苛的情况HNSW索引会有可能失效，导致全表扫描。
除此以外，通过分区的方式也可以优化，通过每次将查询锁定在某一个分区来降低整体的HNSW使用内存的量，最后我们还可以通过调整 ef_search 动态调整，来建立一条适合特定业务的动态ef_search,最后适当的进行REINDEX可以有效的维护查询的速度和内存的占用。
今天我们就开始针对HNSW的优化方面进行深入
1 HNSW的本质是 向量数据和图结构
Memory ≈ N × (vector_size + M × pointer_size × layer_factor)
N = 向量数量 （1536 为假设的向量精度）
vector_size = 1536 * 4 = 6144bytes =6kb
M = HNSW连接数（默认16）
pointer_size = 8 bytes
layer_factor ≈ 1.1–1.3
这里第一个降低浮点的意图就是降低 vector_size 原来我们的向量大小位 6kb 在东float 32降低到 float 16的时候，就会降低到 3kb，这意味着整体的内存消耗将直接减少50%
我们计算一下内存的大小
内存= 10000000 * （6kb + 16 * 8 bytes * 1.3 ）= 58.77GB
这里100000000 指的是1000万的数据，所以在使用HNSW的方案，数据的行数和，所以如果将float降低后，那么 6KB 变成 3KB 则直接内存需要就从 58.77 砍掉一半。
所以降低浮点也就是我们文章中提到的 halfvec会节省大量的内存，后面的问题就出来了，如果要节省内存的情况下会导致计算的精度出现问题，直接导致，运算的结果不正确吗？
这个问题我们下期继续讨论 ！！
