Embedding与向量数据库

1. 一句话理解

Embedding 是把文本、图片、音频、商品、用户行为等数据转换成固定维度的数字向量。
向量数据库 是专门存储这些向量，并支持按"语义相似度"快速检索的数据库或检索系统。

传统检索更像：

text 复制代码

关键词匹配：有没有出现"退款""退票""订单"这些词？

Embedding 检索更像：

text 复制代码

语义匹配：这句话表达的意思，和哪些文档最接近？

例如：

text 复制代码

用户问：我想知道迪士尼门票怎么退？
系统检索：退票政策、退款流程、改期规则、特殊天气退款说明

2. PDF 核心内容总结

PDF 的主线非常清晰：

从 N-Gram + TF-IDF + 余弦相似度 讲起。
再讲 Word Embedding / Word2Vec 如何把词语映射到向量空间。
然后讲 Embedding 模型如何选择，包括 MTEB 榜单、向量维度、Jina Embedding 的"俄罗斯套娃"能力。
最后讲 向量数据库，包括 FAISS、Elasticsearch、Milvus、Pinecone 的特点，以及如何把 Embedding 和原始数据/元数据一起导入 FAISS。

3. 从传统文本特征到 Embedding

3.1 N-Gram

N-Gram 是最基础的文本特征表达方法。

类型	含义	示例文本 `A B C D`
Unigram	单个词作为特征	A、B、C、D
Bigram	连续两个词作为特征	A B、B C、C D
Trigram	连续三个词作为特征	A B C、B C D

它的优点是简单、可解释；缺点是容易造成特征维度膨胀，并且语义理解能力有限。

3.2 TF-IDF

TF-IDF 用于衡量一个词对某篇文档的重要程度。

TF：词频，某个词在当前文档中出现越多，通常越重要。
IDF：逆文档频率，某个词在越少文档中出现，区分度越高。

在 PDF 的酒店推荐案例中，做法是：

对酒店描述字段 desc 做清洗。
用 TfidfVectorizer 提取 1-Gram、2-Gram、3-Gram 特征。
得到酒店描述的 TF-IDF 矩阵。
计算酒店之间的余弦相似度。
根据指定酒店，输出相似度最高的 TopK 酒店。

3.3 余弦相似度

余弦相似度通过两个向量夹角的余弦值来衡量相似度。

text 复制代码

值越接近 1：方向越一致，越相似
值接近 0：相关性弱
值越接近 -1：方向相反

常用于：

文本相似度
商品相似度
用户兴趣相似度
RAG 文档召回
推荐系统召回

4. Word Embedding 与 Word2Vec

4.1 什么是 Word Embedding

Word Embedding 可以理解为：

把词语从离散的 one-hot 编码，映射成低维、稠密、可计算相似度的向量。

例如：

text 复制代码

king -> [0.50, -0.61, 0.23, ...]
queen -> [0.48, -0.58, 0.26, ...]

语义接近的词，在向量空间中的距离也更近。

经典例子：

text 复制代码

king - man + woman ≈ queen

4.2 Word2Vec 的核心思想

Word2Vec 的本质是通过神经网络学习词向量。

常见模式：

模式	输入	输出	说明
CBOW	上下文	中心词	根据周围词预测当前词
Skip-Gram	中心词	上下文	根据当前词预测周围词

PDF 里提到，Word2Vec 的隐藏层权重矩阵可以看成一个查找表：输入 one-hot 后，矩阵乘法实际上就是取出某个词对应的 embedding 向量。

5. 现代 Embedding 模型的选择

5.1 Embedding 模型的核心能力

现代 Embedding 模型不只是把词变成向量，而是把完整文本、代码、图片、表格、文档页面等变成语义向量。

优秀的 Embedding 模型需要具备：

语义理解能力强
查询与文档匹配能力强
支持长文本
支持中文/英文/多语言
推理速度可接受
向量维度和成本可控
与业务数据匹配度高

5.2 MTEB 榜单怎么用

MTEB，全称 Massive Text Embedding Benchmark，是常用的 Embedding 评测基准。原始论文介绍的 MTEB 覆盖 8 类任务、58 个数据集、112 种语言；当前 Hugging Face MTEB Leaderboard 已扩展到更多文本和图像 embedding 模型及多语言评测。

MTEB 常见任务包括：

任务	说明	业务对应场景
Retrieval	从文档库中找相关文档	RAG、知识库问答、搜索
STS	判断两个句子语义相似度	去重、相似问匹配
Reranking	对候选文档二次排序	搜索排序优化
Classification	文本分类	工单分类、评论分类
Clustering	聚类	评论主题聚类、用户意图聚类
Pair Classification	判断文本对关系	重复问题识别
Bitext Mining	跨语言句对挖掘	翻译语料、跨语言搜索
Summarization	语义级摘要相似度评估	摘要质量评估

注意：不能只看榜单第一名。 选型时要结合：

业务语言：中文、英文、多语言？
任务类型：检索、分类、聚类、代码搜索？
数据类型：短文本、长文档、PDF、图片、表格？
部署方式：API 调用、私有化、本地模型？
成本：token 成本、GPU 成本、存储成本。
延迟：同步搜索还是离线批处理？
自己的黄金测试集效果。

5.3 向量维度怎么选

向量维度越高，通常表达能力更强，但存储和计算成本也更高。

维度	优点	缺点	适合场景
64 / 128	成本低、速度快	表达能力弱	标签、短文本、实时低成本场景
256 / 512	成本适中	复杂语义可能不足	一般 FAQ、轻量搜索
768 / 1024	效果与成本平衡	存储成本上升	大多数 RAG / 语义搜索
1536 / 2048+	语义表达更丰富	存储、内存、索引成本高	金融报告、法律合同、复杂文档检索

工程建议：

text 复制代码

不要盲目升维。
如果 1024 维比 768 维只提升不到 1%，但成本增加明显，就不值得。
如果降维后 Recall@K / NDCG 明显下降，例如超过 5%，说明信息损失较大，需要更高维度。

5.4 text-embedding-v4 的当前信息

联网核对阿里云 Model Studio 文档后，text-embedding-v4 适合文本、代码等场景，支持任务指令、稀疏向量等高级能力。

关键点：

支持维度：2048、1536、1024、768、512、256、128、64
默认维度：1024
单次 batch size：10
最大 batch tokens：8192
支持 100+ 主要语言
支持 query / document 不同文本角色
支持 dense、sparse、dense&sparse 三种输出类型

推荐用法：

text 复制代码

文档入库：text_type = document
用户查询：text_type = query
通用 RAG：优先 1024 维
低成本短文本：256 / 512 维
复杂金融/法律/技术文档：1024 / 2048 维
需要关键词 + 语义：dense&sparse

5.5 Jina Embeddings v4 的当前信息

Jina Embeddings v4 是一个多模态、多语言 embedding 模型，适合复杂文档检索，尤其是包含图表、表格、插图的视觉丰富文档。

关键规格：

项目	信息
基础模型	Qwen2.5-VL-3B-Instruct
支持任务	retrieval、text-matching、code
最大序列长度	32768
单向量维度	2048
多向量维度	128
Matryoshka 维度	128、256、512、1024、2048
池化策略	Mean Pooling
注意力机制	FlashAttention2

所谓"俄罗斯套娃"能力，就是模型可以先生成完整的高维向量，然后按需截断成较低维度，并尽量保持较好的检索效果。

场景建议：

场景	建议维度
社交媒体短文本、评论情感分析	128 / 256
普通 FAQ / 商品搜索	512 / 1024
投研报告、财报、法律文档	1024 / 2048
图文混合 PDF / 表格 / 截图检索	优先考虑 Jina v4 多模态能力

6. 向量数据库是什么

向量数据库用于存储和检索 embedding 向量。它的核心能力是：

text 复制代码

给定一个查询向量，在海量向量中找出最相似的 TopK。

在 RAG 系统中，向量数据库相当于大模型的"长期记忆"。

典型流程：

text 复制代码

原始文档
  -> 清洗
  -> 切分 Chunk
  -> 生成 Embedding
  -> 存入向量数据库
  -> 用户提问
  -> 问题向量化
  -> TopK 检索
  -> 重排序
  -> 拼接上下文
  -> LLM 生成答案

7. 向量数据库与传统数据库对比

对比项	传统数据库	向量数据库
数据类型	行、列、结构化数据	高维向量 + 元数据
查询方式	精确匹配、范围查询、SQL	相似度检索、ANN、TopK
典型索引	B+Tree、Hash	HNSW、IVF、PQ、Flat 等
适合场景	订单、用户、支付、库存	RAG、语义搜索、推荐、以图搜图
匹配逻辑	`id = 1`、`status = PAID`	语义接近、向量距离近
是否替代关系库	不能替代	通常和 MySQL/PostgreSQL 配合使用

工程上通常是：

text 复制代码

MySQL / PostgreSQL：存业务主数据、状态、权限、元数据
向量数据库：存向量并做相似度检索
对象存储：存 PDF、图片、Excel、原始文件
Redis：做缓存、任务状态、热点数据

8. 常见向量数据库对比

产品	类型	优点	局限	推荐场景
FAISS	向量检索库，不是完整数据库	性能强、索引算法丰富、支持 GPU	元数据、权限、更新删除、服务化能力需要自己做	算法验证、离线检索、单机高性能召回
Elasticsearch	搜索引擎 + 向量检索	关键词搜索强，适合混合搜索	纯向量性能通常不如专用向量库	已有 ES，文本搜索为主，向量为辅
Milvus	开源向量数据库	分布式、扩展性强、索引丰富、适合海量数据	运维复杂度较高	企业私有化、大规模 RAG / 推荐
Pinecone	托管向量数据库	云原生、低运维、API 简洁	商业托管，私有化受限	快速上线、海外云上生产环境
Qdrant	Rust 向量数据库	过滤能力强、性能好、payload 机制好用	生态规模相对 ES/Milvus 小	需要复杂元数据过滤的 RAG / 电商 / 金融检索
Weaviate	开源向量数据库	自动向量化、开发体验好	复杂生产调优仍需经验	快速构建端到端语义搜索应用

9. FAISS 与元数据管理

PDF 里给出的 FAISS 方案很适合教学和原型验证。

FAISS 本身主要负责：

text 复制代码

向量索引 + 相似度搜索

但它不负责完整的业务元数据管理。所以需要额外维护：

text 复制代码

vector_id -> 原始文本 / 文件名 / 页码 / 章节 / URL / 业务ID

示例结构：

python 复制代码

metadata_store = {
    10001: {
        "doc_id": "doc_001",
        "text": "迪士尼门票退票政策...",
        "source": "official_faq_v1.pdf",
        "page": 3,
        "category": "退票政策"
    }
}

FAISS 检索返回的是向量 ID：

text 复制代码

query -> query_embedding -> faiss.search -> vector_ids -> metadata_store -> 原始文本 + 元数据

生产环境建议：

数据	推荐存储
向量索引	FAISS / Milvus / Qdrant / Elasticsearch
元数据	MySQL / PostgreSQL / MongoDB
原始文件	MinIO / S3 / OSS
热点召回结果	Redis
导入任务状态	MySQL

10. RAG 知识库落地架构

text 复制代码

┌────────────────────────┐
│      原始数据源         │
│ PDF / Word / HTML / DB │
└───────────┬────────────┘
            │
            ▼
┌────────────────────────┐
│      文档解析层         │
│  OCR / PDF解析 / 清洗   │
└───────────┬────────────┘
            │
            ▼
┌────────────────────────┐
│      Chunk 切分层       │
│ 按标题/段落/Token切分   │
└───────────┬────────────┘
            │
            ▼
┌────────────────────────┐
│    Embedding 生成层     │
│ text-embedding-v4/Jina │
└───────────┬────────────┘
            │
            ▼
┌────────────────────────┐
│      向量数据库         │
│ Milvus/Qdrant/ES/FAISS │
└───────────┬────────────┘
            │
            ▼
┌────────────────────────┐
│       检索增强层        │
│ TopK召回 + 元数据过滤   │
│ + Rerank + 去重         │
└───────────┬────────────┘
            │
            ▼
┌────────────────────────┐
│          LLM            │
│  基于上下文生成答案      │
└────────────────────────┘

11. Java 后端落地建议

如果你用 Spring Boot 做企业级 RAG，建议分层如下：

text 复制代码

controller
  -> service
    -> document parser
    -> chunk splitter
    -> embedding client
    -> vector repository
    -> metadata repository
    -> rerank service
    -> llm service

11.1 表设计建议

document_file：文件表

sql 复制代码

CREATE TABLE document_file (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    file_name VARCHAR(255) NOT NULL,
    file_url VARCHAR(512) NOT NULL,
    file_type VARCHAR(50),
    status VARCHAR(32) NOT NULL,
    created_at DATETIME NOT NULL,
    updated_at DATETIME NOT NULL
);

document_chunk：切片表

sql 复制代码

CREATE TABLE document_chunk (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    file_id BIGINT NOT NULL,
    chunk_no INT NOT NULL,
    content TEXT NOT NULL,
    token_count INT,
    page_no INT,
    section_title VARCHAR(255),
    vector_id VARCHAR(128),
    created_at DATETIME NOT NULL,
    updated_at DATETIME NOT NULL,
    INDEX idx_file_id (file_id),
    INDEX idx_vector_id (vector_id)
);

embedding_task：向量化任务表

sql 复制代码

CREATE TABLE embedding_task (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    file_id BIGINT NOT NULL,
    status VARCHAR(32) NOT NULL,
    total_chunks INT DEFAULT 0,
    success_chunks INT DEFAULT 0,
    failed_chunks INT DEFAULT 0,
    error_message TEXT,
    created_at DATETIME NOT NULL,
    updated_at DATETIME NOT NULL,
    INDEX idx_file_id (file_id),
    INDEX idx_status (status)
);

12. 检索质量优化策略

12.1 Chunk 切分优化

常见问题：

text 复制代码

切太大：召回不精准，LLM 上下文浪费
切太小：语义不完整，答案缺上下文

建议：

文档类型	Chunk 策略
FAQ	一问一答为一个 Chunk
技术文档	按标题层级 + 段落切分
合同/法律文档	按条款切分，保留章节编号
PDF 报告	按页 + 标题 + 段落混合切分
表格	保留表头，行记录转结构化文本

12.2 Hybrid Search

纯向量检索容易漏掉精确关键词，例如订单号、SKU、错误码、法规条款编号。

所以生产中推荐：

text 复制代码

向量语义检索 + 关键词检索 + 元数据过滤 + Rerank

常见组合：

检索方式	解决问题
Dense Vector	语义相似，理解同义表达
Sparse Vector / BM25	精确关键词、编号、错误码
Metadata Filter	权限、分类、时间、租户隔离
Reranker	对 TopK 候选结果重新排序

12.3 评估指标

不要只靠人工感觉判断效果。建议建立黄金测试集。

指标	含义
Recall@K	正确答案是否出现在前 K 个召回结果中
Precision@K	前 K 个结果中有多少是相关的
MRR	第一个正确结果排名越靠前越好
NDCG	综合考虑相关性和排序位置
Latency	检索耗时
Cost	embedding 调用成本、存储成本、计算成本

13. 选型建议

13.1 快速实验

text 复制代码

Embedding：text-embedding-v4 1024维
向量库：FAISS / Qdrant
元数据：MySQL
文件：本地 / MinIO

13.2 企业私有化 RAG

text 复制代码

Embedding：bge-m3 / Jina Embeddings v4 / Qwen3-Embedding 系列
向量库：Milvus / Qdrant / Elasticsearch
元数据：MySQL / PostgreSQL
文件：MinIO
任务队列：RabbitMQ / Kafka

13.3 已有 Elasticsearch 的团队

text 复制代码

如果已有 ES，并且搜索业务以关键词检索为主，可以直接使用 Elasticsearch 的 dense_vector + kNN 能力做混合搜索。

13.4 大规模高性能向量检索

text 复制代码

如果数据量很大、需要分布式扩展、批量导入和生产级管理，优先 Milvus / Qdrant。

13.5 海外云上快速上线

text 复制代码

如果不想自建和运维，优先 Pinecone 这类托管向量数据库。

14. 最终结论

Embedding 与向量数据库的本质是：

text 复制代码

把不可直接计算语义的数据，转换成可计算距离的向量；
再用向量数据库高效找到语义最接近的数据。

PDF 里的知识路线非常适合入门：

text 复制代码

N-Gram / TF-IDF
  -> 余弦相似度
  -> Word2Vec
  -> 现代 Embedding 模型
  -> 向量数据库
  -> FAISS + 元数据管理
  -> RAG / 推荐系统落地

工程落地时，真正关键的是：

模型不要只看榜单，要用自己的业务数据评测。
向量维度不要盲目追高，要看效果提升和成本是否匹配。
向量库不能替代业务数据库，元数据、权限、状态仍然要进 MySQL/PostgreSQL。
生产级 RAG 推荐使用 Hybrid Search：Dense + Sparse + Metadata Filter + Rerank。
FAISS 适合原型和算法验证；Milvus/Qdrant/Elasticsearch 更适合服务化生产场景。

15. 参考资料

用户上传 PDF：《1-Embedding与向量数据库.pdf》
MTEB Leaderboard：huggingface.co/spaces/mteb...
MTEB Paper：arxiv.org/abs/2210.07...
Alibaba Cloud Model Studio Embedding：www.alibabacloud.com/help/en/mod...
Jina Embeddings v4 Model Card：huggingface.co/jinaai/jina...
FAISS Documentation：faiss.ai/index.html
Elasticsearch kNN Search：www.elastic.co/docs/soluti...
Milvus Multi-Vector Hybrid Search：milvus.io/docs/multi-...
Pinecone Hybrid Search：docs.pinecone.io/guides/sear...
Pinecone Metadata Filter：docs.pinecone.io/guides/sear...
Qdrant Hybrid Queries：qdrant.tech/documentati...