知识库与 Embedding 底层原理

知识库解决什么问题#

企业里最常见的诉求：把公司的文档、手册、制度变成”能对话的 AI 问答系统”。

一条朴素的路线是微调：拿文档去继续训练模型。但微调成本高、周期长、知识更新就要重训，实际工程中 90% 的场景都不需要微调——用知识库 + RAG 就够了。

知识库系统 = 文档处理管线 + Embedding + 向量数据库 + 检索。这篇深入讲它最底层的两个引擎：Embedding 和向量检索。

一、Embedding 的底层原理#

从 one-hot 到稠密向量#

最早表示词的方法是 one-hot：每个词一个维度，向量长度为词表大小 V。问题很明显：

维度爆炸（V 可能几十万）
向量之间全是正交的，“猫”和”狗”没有任何相似度信息

Embedding 的做法是把词/句映射到低维稠密向量（几百到几千维），且语义相近的向量距离近。这背后的核心是**分布式表示（Distributed Representation）**思想：一个词的含义由它周围的词共同决定（“You shall know a word by the company it keeps”——Firth, 1957）。

上下文相关 vs 上下文无关#

类型	代表	特点
上下文无关（静态）	Word2Vec、GloVe	一个词只有一个向量，“苹果”（水果/公司）无法区分
上下文相关（动态）	BERT、BGE、text2vec	同一个词在不同句子里向量不同，能区分多义词

现代知识库用的都是上下文相关的 Embedding：把整段文本（句子/段落）过一遍 Transformer 编码器，取输出的池化结果作为该文本的向量。

Embedding 是怎么训练出来的：对比学习#

训练目标非常直观：让语义相近的文本对向量靠近，语义无关的文本对向量远离。

构造训练样本：

正样本：问题-答案、原文-改写、标题-正文（语义相同）
负样本：随机配对（语义无关）

损失函数（InfoNCE）：

1
L = -log( e^(sim(q, pos)/τ) / Σ e^(sim(q, neg_i)/τ) )

sim 是余弦相似度
τ 是温度参数，控制分布的尖锐程度
分子拉近正样本，分母推远所有负样本

训练完成后，模型输出的向量就具有了”语义距离”性质——这正是检索的基础。

Embedding 的关键细节#

归一化：使用前对向量做 L2 归一化，这样余弦相似度 = 内积，检索实现更简单
同模型原则：入库和查询必须用同一个 Embedding 模型，否则向量空间不一致
维度选择：768/1024/1536 是常见选择；维度高精度好但存储大、检索慢
中文适配：中文分词与英文不同，务必选中文语料训练过的模型（BGE 系列、m3e、text2vec）

二、向量相似度计算#

三种度量#

余弦相似度：cos(θ) = (q·d) / (|q||d|)，只关心方向，最常用
内积：归一化后与余弦等价，实现最快
欧氏距离：越小越相似，适合绝对距离有意义的场景

为什么余弦相似度就够了#

向量检索不关心”向量多长”，只关心”方向是否一致”——语义相关性本质是方向上的接近。所以归一化 + 内积是工业界标准实现。

三、向量检索：从暴力到 ANN#

暴力检索#

数据量小时（万级以内），直接遍历计算所有相似度取 top-k。简单准确，但数据量大了以后每次查询都要扫全库，完全不可用。

ANN（近似最近邻）的三大流派#

百万级以上必须用索引加速，核心思想是牺牲一点精度换速度：

算法	原理	特点
HNSW	构建分层图，先粗粒度跳到大致区域再精细搜索	召回率高、速度快，内存占用大；最主流
IVF	先对全库聚类（K-Means），查询时只在最近的几个簇里搜	内存友好，配合 PQ 可大规模部署
PQ	把向量切块量化压缩，用查表代替距离计算	极致省内存，精度有损

HNSW 为什么快#

HNSW 的思想是”六度分隔”：构建多层图，上层图连接稀疏（跳得远），下层图连接密集（走得近）。查询时从顶层开始，逐层向下贪心搜索，很快就能收敛到目标附近。复杂度接近 O(log n)。

向量数据库产品#

Milvus / Zilliz：分布式、云原生，百万级起步
Qdrant / Weaviate：Rust/Go 实现，性能好
Chroma：轻量，适合原型
pgvector：PostgreSQL 插件，和现有业务库同栈，中小项目首选
Elasticsearch：自带 kNN 检索，与全文检索一体

选型的核心指标：数据量、查询 QPS、内存预算、是否需要混合检索、是否已有存储栈。

四、混合检索：为什么纯向量不够#

向量检索擅长”语义相关”，但对精确匹配不敏感：

用户搜”型号 A100”——向量可能匹配到”A100 和 H100 的对比”，但用户要的是 A100 的规格页
搜错误代码 “ERR_503”——语义向量毫无办法，关键词匹配秒杀

**BM25（关键词检索）**恰好擅长这个：基于词频-逆文档频率打分，精确命中权重高。

工业级方案 = 向量检索 + BM25 双路召回 + RRF 融合：

1
RRF 分数 = Σ 1 / (k + rank_i)

RRF 把两路的排序位置融合成一个分数（rank 越靠前分越高），无需调权重参数，简单有效。

五、知识库系统的完整架构#

一个生产级知识库问答系统的分层：

1
┌──────────────────────────────────────────┐
2
│  接入层：Web / IM / API                   │
3
├──────────────────────────────────────────┤
4
│  编排层：Query 改写 → 检索 → Rerank → 生成 │
5
├──────────────────────────────────────────┤
6
│  检索层：向量库 + BM25 + 混合排序          │
7
├──────────────────────────────────────────┤
8
│  索引层：Chunking + Embedding + 元数据     │
9
├──────────────────────────────────────────┤
10
│  存储层：向量数据库 + 文档源 + 元数据库     │
11
└──────────────────────────────────────────┘

元数据（Metadata）的妙用#

每个 Chunk 不光存向量，还存元数据：来源文档、章节、更新时间、权限标签。作用：

过滤：只检索某部门/某时间段的文档（检索前先过滤，既快又准）
溯源：回答时能指出”依据来自《运维手册》第 3 章”
权限控制：不同用户只能检索到权限范围内的内容

文档更新与版本#

文档变了怎么办？

增量更新：只重新 Embedding 变化的 Chunk
版本管理：向量库中按文档版本打标，可回滚
定期全量重建：兜底方案，防止脏数据累积

六、常见误区#

误区	真相
”Embedding 模型越贵越好”	要匹配语言和数据域，中文场景用中文模型更稳
”向量维度越高越好”	高维度带来存储和检索开销，够用即可
”向量库能解决一切检索”	精确匹配场景必须混合 BM25
”数据入库就完事了”	数据质量、切分质量决定检索天花板
”RAG 能替代微调”	两者互补：知识用 RAG，风格/领域技能用微调

小结#

知识库的底层是两件事：

Embedding：用对比学习训练出的语义向量化能力，把文本变成可计算相似度的向量
向量检索（ANN）：用 HNSW/IVF/PQ 等索引结构，在百万级向量中毫秒级找出最相似的片段

上层再叠加 Chunking、混合检索、Rerank、元数据管理，就构成了完整的知识库问答系统。这也是 RAG 技术栈的基石——理解了这一层，任何知识库产品的原理在你眼里都是透明的。