向量数据库技术内核：从存储到检索，拆解其高效运作的秘密
<h1 id="向量数据库技术内核从存储到检索拆解其高效运作的秘密">向量数据库技术内核：从存储到检索，拆解其高效运作的秘密</h1><p></p>
<h2 id="写在前面我也是被向量数据库名词轰炸过的人">写在前面：我也是“被向量数据库名词轰炸”过的人</h2>
<p>说实话，我第一次接触向量数据库的时候，是有点抗拒的。</p>
<p>那会儿各种文章都在说：</p>
<ul>
<li>向量数据库是 AI 时代的“新型基础设施”</li>
<li>没有向量数据库，大模型就跑不起来</li>
<li>它彻底改变了传统数据库的范式</li>
</ul>
<p>结果我真正打开文档一看，全是：</p>
<ul>
<li>embedding</li>
<li>ANN</li>
<li>IVF</li>
<li>HNSW</li>
<li>PQ</li>
</ul>
<p>名词密度高到让我一度怀疑：<br>
这是不是又一个“包装得很厉害的老技术”？</p>
<p>直到后来我在项目里真的开始用它、调它、踩坑、看源码，才慢慢意识到一件事：</p>
<p>向量数据库真正有价值的地方，不在概念，而在它对「存储 + 检索」这件事做了极其激进的工程优化。</p>
<p>这篇文章，我不打算从“是什么”讲起，而是想换个更工程化的视角：</p>
<p>一个向量，从进数据库到被检索出来，中间到底经历了什么？</p>
<h2 id="一切的起点为什么向量这件事本身就很麻烦">一切的起点：为什么“向量”这件事，本身就很麻烦</h2>
<p>在传统数据库里，我们处理的是：</p>
<ul>
<li>int</li>
<li>string</li>
<li>datetime</li>
<li>少量结构化字段</li>
</ul>
<p>它们的共同特点是：<br>
可比较、可排序、可精确匹配。</p>
<p>而向量完全不是这么回事。</p>
<p>一个 embedding，通常是：</p>
<ul>
<li>384 / 768 / 1536 维</li>
<li>float32 或 float16</li>
<li>本身没有任何“语义”，只是一个数值数组</li>
</ul>
<p>你没法说：</p>
<p>这个向量 = 那个向量</p>
<p>你只能说：</p>
<p>这两个向量，有多像</p>
<p>而“有多像”，通常意味着：</p>
<ul>
<li>余弦相似度</li>
<li>内积</li>
<li>欧式距离</li>
</ul>
<p>到这里，其实问题已经很清楚了。</p>
<p>向量数据库的本质问题只有一个：<br>
如何在“巨量高维浮点向量”中，快速找到“足够相似”的那几个？</p>
<p>注意我用的是“足够相似”，而不是“最相似”。</p>
<p>这个细节，后面会反复出现。</p>
<h2 id="向量存储真的只是把-float-存起来吗">向量存储：真的只是把 float 存起来吗？</h2>
<p>刚开始我也以为，向量数据库的“存储”阶段应该很简单：</p>
<p>不就是一堆 float 数组写到磁盘上吗？</p>
<p>后来才发现，这个想法太天真了。</p>
<h3 id="存储的第一个难题空间">存储的第一个难题：空间</h3>
<p>假设你有：</p>
<ul>
<li>1000 万条向量</li>
<li>每条 768 维</li>
<li>float32</li>
</ul>
<p>那光原始数据就是：</p>
<p>1000万 × 768 × 4 bytes ≈ 30GB</p>
<p>这还没算索引、元数据、缓存。</p>
<p>所以第一个现实问题就是：</p>
<p>向量数据库不可能只存“原始向量”。</p>
<h3 id="压缩是绕不开的第一步">压缩，是绕不开的第一步</h3>
<p>几乎所有成熟的向量数据库，都会在某个阶段引入向量压缩。</p>
<p>但这里有一个经常被忽略的点：</p>
<p>向量压缩不是为了省钱，而是为了“让检索跑得动”。</p>
<p>常见思路包括：</p>
<ul>
<li>降低精度（float32 → float16 / int8）</li>
<li>Product Quantization（PQ）</li>
<li>Scalar Quantization</li>
</ul>
<p>它们的共同目标只有一个：</p>
<p>用更少的 bit，保留“相对距离关系”。</p>
<p>这也是为什么你会看到很多向量数据库文档里反复强调一句话：</p>
<p>压缩后，相似度计算仍然“足够准确”。</p>
<p>这里的“足够”，非常工程化。</p>
<h2 id="真正的核心为什么不能暴力算相似度">真正的核心：为什么不能暴力算相似度？</h2>
<p></p>
<p>「全量暴力搜索 vs ANN 搜索」复杂度对比图</p>
<p>如果你向量数量很少，事情其实很简单。</p>
<p>比如 1 万条向量，你完全可以：</p>
<ul>
<li>对 query 向量</li>
<li>和所有向量</li>
<li>全量算一遍相似度</li>
<li>排序取 topK</li>
</ul>
<p>但问题是，真实世界里几乎没人这么玩。</p>
<p>一旦数据量上来，全量计算就直接不可接受了。</p>
<p>这也是向量数据库真正开始和传统数据库分道扬镳的地方。</p>
<h2 id="ann向量数据库绕不开的不完美选择">ANN：向量数据库绕不开的“不完美选择”</h2>
<p>说句实话，如果你追求的是绝对精确，那向量数据库本身就是错的。</p>
<p>因为它几乎都建立在一个前提之上：</p>
<p>我不追求最优解，我追求一个足够好的近似解。</p>
<p>这就是所谓的 ANN（Approximate Nearest Neighbor）。</p>
<p>我当时第一次意识到这一点的时候，其实挺震惊的。</p>
<p>因为这意味着：</p>
<ul>
<li>向量数据库从设计之初</li>
<li>就放弃了“绝对正确”</li>
</ul>
<p>换来的，是速度和可扩展性。</p>
<h2 id="从工程角度理解索引到底在干什么">从工程角度理解：索引到底在干什么？</h2>
<p></p>
<p>“全部向量” → “候选集” → “TopK”</p>
<p>如果你把向量数据库当成一个黑盒，很容易迷失在各种算法名词里。</p>
<p>但如果换个角度想：</p>
<p>索引的核心目的，其实只有一个：<br>
尽可能少地看向量，但还能找到差不多对的那几个。</p>
<p>所有 ANN 索引，本质上都在做这件事。</p>
<h2 id="以-hnsw-为例为什么图这么好用">以 HNSW 为例：为什么“图”这么好用？</h2>
<p>HNSW 是我个人觉得最“反直觉但又最工程化”的一种索引结构。</p>
<p>它不是树，也不是 hash，而是一张图。</p>
<p>更准确地说，是多层小世界图。</p>
<p>你可以这样理解它：</p>
<ul>
<li>每个向量是一个点</li>
<li>相似的向量之间连边</li>
<li>上层图稀疏、下层图密集</li>
</ul>
<p>搜索的时候：</p>
<ul>
<li>从上层快速跳跃</li>
<li>慢慢下沉</li>
<li>最后在底层精细搜索</li>
</ul>
<p>这里面有个很重要的工程思想：</p>
<p>先用很便宜的计算，缩小搜索范围；<br>
再用更贵的计算，做精细判断。</p>
<h2 id="为什么向量检索速度能这么快">为什么向量检索速度能这么快？</h2>
<p>这个问题我后来想了很久，最后得出的结论其实很朴素：</p>
<p>向量数据库快，不是因为算得快，而是因为算得少。</p>
<p>它通过：</p>
<ul>
<li>索引结构</li>
<li>压缩表示</li>
<li>分层搜索</li>
</ul>
<p>把原本“必须算 1000 万次”的事情，变成：</p>
<p>只算几千次，甚至几百次。</p>
<p>哪怕每次计算稍微复杂一点，整体还是赚的。</p>
<h2 id="再说一个经常被忽略的点内存结构">再说一个经常被忽略的点：内存结构</h2>
<p></p>
<p>「内存 / 缓存 / 磁盘」分层访问示意图</p>
<p>很多人会以为，向量数据库主要瓶颈在 CPU。</p>
<p>但在真实系统里，内存布局和缓存命中率反而非常关键。</p>
<p>一些非常工程但很少被写进文章的事实：</p>
<ul>
<li>向量通常会被按块存储，方便 SIMD</li>
<li>热向量和索引节点会尽量常驻内存</li>
<li>IO 只在必要时发生</li>
</ul>
<p>这也是为什么很多向量数据库会强调：</p>
<p>内存越大，体验越好</p>
<p>不是营销，是事实。</p>
<h2 id="从存储到检索一次完整请求发生了什么">从存储到检索，一次完整请求发生了什么？</h2>
<p>我们把流程串起来看一次。</p>
<p>当你发起一次向量检索请求时，大致会发生：</p>
<ul>
<li>query 被转成 embedding</li>
<li>embedding 被归一化</li>
<li>从索引结构中选出候选集合</li>
<li>对候选向量做精细相似度计算</li>
<li>排序、返回 topK</li>
<li>如果有 metadata filter，再做一次过滤</li>
</ul>
<p>注意一个细节：</p>
<p>真正算“精确相似度”的向量，数量其实很少。</p>
<p>这就是整个系统能跑起来的关键。</p>
<h2 id="为什么向量数据库和传统数据库--插件不一样">为什么向量数据库和“传统数据库 + 插件”不一样？</h2>
<p>我一开始也尝试过：</p>
<p>能不能在 MySQL / PostgreSQL 里直接存向量？</p>
<p>答案是：<br>
能，但体验非常差。</p>
<p>原因并不复杂：</p>
<ul>
<li>存储层不是为高维 float 优化的</li>
<li>缓存策略不合适</li>
<li>没有针对 ANN 的索引结构</li>
</ul>
<p>向量数据库并不是“多了个字段类型”，<br>
而是从存储到检索路径全部重新设计过的一套系统。</p>
<h2 id="写到这里说点更现实的">写到这里，说点更现实的</h2>
<p>如果你只是：</p>
<ul>
<li>数据量不大</li>
<li>QPS 很低</li>
<li>对延迟不敏感</li>
</ul>
<p>你未必真的需要一套完整的向量数据库。</p>
<p>但一旦你遇到：</p>
<ul>
<li>向量规模上百万</li>
<li>检索要进主流程</li>
<li>延迟必须稳定</li>
</ul>
<p>那你会非常清楚地感受到：</p>
<p>这些“看起来很复杂的设计”，<br>
本质上都是被工程现实逼出来的。</p>
<h2 id="最后我现在怎么看向量数据库">最后：我现在怎么看向量数据库</h2>
<p>如果让我用一句话总结向量数据库，我会说：</p>
<p>它不是一项“新技术”，而是一堆老思想在 AI 场景下的极限工程化。</p>
<ul>
<li>高维数据</li>
<li>近似搜索</li>
<li>空间换时间</li>
<li>不追求完美，只追求可用</li>
</ul>
<p>这些思想其实并不新，但在大模型时代，被推到了一个前所未有的规模。</p>
<p>如果你已经开始在真实项目里用向量数据库，大概率会遇到一个现实问题：<br>
理论都懂了，但怎么把向量、检索、模型训练这几件事真正连起来，反而更麻烦。<br>
尤其是在做 RAG 或大模型应用时，向量数据库往往只是链路中的一环，前后还牵扯到：</p>
<ul>
<li>embedding 模型选择<br>
-数据构建与清洗<br>
-检索效果评估<br>
-以及后续的模型微调与对齐</li>
</ul>
<p>在这种情况下，很多团队会选择先用一些已经把训练和工程流程封装好的工具，把整体链路跑顺，再逐步替换成更定制化的方案。<br>
比如像 LLaMA-Factory online这样的工具，已经把模型微调、数据处理、实验配置这些容易出错的工程细节做了封装，对于想快速验证思路、减少重复造轮子的团队来说，会是一个相对省心的起点。<br>
它解决的不是“算法更先进”，而是一个很现实的问题：<br>
让工程师把精力放在真正需要思考的地方，而不是反复踩同样的工程坑。</p><br>来源：程序园用户自行投稿发布，如果侵权，请联系站长删除<br>免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！ 过来提前占个楼 过来提前占个楼 这个好，看起来很实用 不错，里面软件多更新就更好了 用心讨论，共获提升！ 感谢分享，下载保存了，貌似很强大 东西不错很实用谢谢分享 感谢，下载保存了 新版吗？好像是停更了吧。 懂技术并乐意极积无私分享的人越来越少。珍惜 这个有用。 谢谢楼主提供！ 懂技术并乐意极积无私分享的人越来越少。珍惜 不错，里面软件多更新就更好了 很好很强大我过来先占个楼 待编辑 喜欢鼓捣这些软件，现在用得少，谢谢分享！ yyds。多谢分享 谢谢分享，试用一下 热心回复！
页:
[1]
2