向量数据库：存什么、怎么存、怎么查
核心不是"存向量"，是"存什么结构让检索最准"：一张 knowledge_chunks 表存 content + embedding + metadata 三件套，靠 ANN 索引（HNSW / IVF）把"跟全库算一遍距离"换成可控的近似——快是买来的：HNSW 用 M、efConstruction、ef，IVF 用 lists、nprobe 在召回与延迟之间调参；靠 metadata 做过滤，靠"向量 + BM25 混合"兼顾语义与精确。向量库不是取代数据库，而是补上数据库缺失的"语义近似查询"能力——表结构仍是关系型的，只是多了 embedding 一列和 ANN 索引。
1x2x
待播放
写入：文档→chunk(500-1000tok)→Embedding→INSERT → 读取：问题向量化→ANN检索→metadata过滤→混合检索→上下文扩展
Embedding API
VECTOR(1536)
光点 = 当前环节 · 向量库 = 倒排索引的语义版
knowledge_chunks 表（三件套）—
CREATE TABLE knowledge_chunks (
id UUID PRIMARY KEY,
source VARCHAR(256), -- 来源文档
chunk_index INT, -- 第几个chunk(保序)
content TEXT, -- 给 LLM 看的原文
embedding VECTOR(1536), -- 语义坐标
metadata JSONB, -- {title,section,tags}
created_at TIMESTAMPTZ
);
ivfflat
分区·先粗分桶再只扫 nprobe 桶
百万级 · lists=100 · 省内存
hnsw
多层图·上层粗定位逐层下沉
千万级 · 邻居数 M · 查询候选 ef
就绪点 ▶ 播放，看一条运维手册从入库到语义检索的全过程。向量数据库
⚡ 运行时动作：正在发生什么💡 知识讲解：为什么这么设计
知识点一句话总结：向量数据库核心不是存向量，是存什么结构让检索最准——content（给 LLM 的原文）+ embedding（语义坐标）+ metadata（过滤溯源）三件套缺一不可；ANN 的快是买来的：暴力检索要跟全库逐条算距离（O(N)，百万级直接进秒级且随库线性变差），HNSW 用图的可导航性（上层粗定位逐层下沉，跳数近似 O(log N)）、IVF 用分区（先粗聚类再只扫 nprobe 桶）换掉全量扫描；定价旋钮是 HNSW 的 M / efConstruction / ef 与 IVF 的 lists / nprobe——扫的候选越多，recall↑ 延迟也↑；量化把向量压成码本索引省内存、直接损 recall，生产用量化粗筛 + 原始向量重排把 recall 买回来；选型先问"放不放得进内存、需不需要精确"，再谈参数。查询链 = 问题向量化 → ANN Top-K → metadata WHERE 下推 → 向量+BM25 混合检索（纯向量漏精确词：版本号/报错码）→ 上下文扩展（chunk_index 保序取前后各 1 个）；阈值一律用同一个量：相似度（=1-余弦距离）< 0.7 判噪声丢弃，等价于 SQL 里距离 > 0.3；空结果触发降级。向量库不是取代数据库，是补上数据库缺失的"语义近似查询"能力。