1. 一句话理解
Embedding 是把文本、图片、音频、商品、用户行为等数据转换成固定维度的数字向量。
向量数据库 是专门存储这些向量，并支持按“语义相似度”快速检索的数据库或检索系统。
传统检索更像：
关键词匹配：有没有出现“退款”“退票”“订单”这些词？
Embedding 检索更像：
语义匹配：这句话表达的意思，和哪些文档最接近？
例如：
用户问：我想知道迪士尼门票怎么退？
系统检索：退票政策、退款流程、改期规则、特殊天气退款说明
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 余弦相似度
余弦相似度通过两个向量夹角的余弦值来衡量相似度。
值越接近 1：方向越一致，越相似
值接近 0：相关性弱
值越接近 -1：方向相反
常用于：
- 文本相似度
- 商品相似度
- 用户兴趣相似度
- RAG 文档召回
- 推荐系统召回
4. Word Embedding 与 Word2Vec
4.1 什么是 Word Embedding
Word Embedding 可以理解为：
把词语从离散的 one-hot 编码，映射成低维、稠密、可计算相似度的向量。
例如：
king -> [0.50, -0.61, 0.23, ...]
queen -> [0.48, -0.58, 0.26, ...]
语义接近的词，在向量空间中的距离也更近。
经典例子：
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+ | 语义表达更丰富 | 存储、内存、索引成本高 | 金融报告、法律合同、复杂文档检索 |
工程建议：
不要盲目升维。
如果 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_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 向量。它的核心能力是：
给定一个查询向量，在海量向量中找出最相似的 TopK。
在 RAG 系统中，向量数据库相当于大模型的“长期记忆”。
典型流程：
原始文档
-> 清洗
-> 切分 Chunk
-> 生成 Embedding
-> 存入向量数据库
-> 用户提问
-> 问题向量化
-> TopK 检索
-> 重排序
-> 拼接上下文
-> LLM 生成答案
7. 向量数据库与传统数据库对比
| 对比项 | 传统数据库 | 向量数据库 |
|---|---|---|
| 数据类型 | 行、列、结构化数据 | 高维向量 + 元数据 |
| 查询方式 | 精确匹配、范围查询、SQL | 相似度检索、ANN、TopK |
| 典型索引 | B+Tree、Hash | HNSW、IVF、PQ、Flat 等 |
| 适合场景 | 订单、用户、支付、库存 | RAG、语义搜索、推荐、以图搜图 |
| 匹配逻辑 | id = 1、status = PAID | 语义接近、向量距离近 |
| 是否替代关系库 | 不能替代 | 通常和 MySQL/PostgreSQL 配合使用 |
工程上通常是：
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 本身主要负责：
向量索引 + 相似度搜索
但它不负责完整的业务元数据管理。所以需要额外维护：
vector_id -> 原始文本 / 文件名 / 页码 / 章节 / URL / 业务ID
示例结构：
metadata_store = {
10001: {
"doc_id": "doc_001",
"text": "迪士尼门票退票政策...",
"source": "official_faq_v1.pdf",
"page": 3,
"category": "退票政策"
}
}
FAISS 检索返回的是向量 ID：
query -> query_embedding -> faiss.search -> vector_ids -> metadata_store -> 原始文本 + 元数据
生产环境建议：
| 数据 | 推荐存储 |
|---|---|
| 向量索引 | FAISS / Milvus / Qdrant / Elasticsearch |
| 元数据 | MySQL / PostgreSQL / MongoDB |
| 原始文件 | MinIO / S3 / OSS |
| 热点召回结果 | Redis |
| 导入任务状态 | MySQL |
10. RAG 知识库落地架构
┌────────────────────────┐
│ 原始数据源 │
│ 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，建议分层如下：
controller
-> service
-> document parser
-> chunk splitter
-> embedding client
-> vector repository
-> metadata repository
-> rerank service
-> llm service
11.1 表设计建议
document_file：文件表
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：切片表
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：向量化任务表
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 切分优化
常见问题：
切太大：召回不精准，LLM 上下文浪费
切太小：语义不完整，答案缺上下文
建议：
| 文档类型 | Chunk 策略 |
|---|---|
| FAQ | 一问一答为一个 Chunk |
| 技术文档 | 按标题层级 + 段落切分 |
| 合同/法律文档 | 按条款切分，保留章节编号 |
| PDF 报告 | 按页 + 标题 + 段落混合切分 |
| 表格 | 保留表头，行记录转结构化文本 |
12.2 Hybrid Search
纯向量检索容易漏掉精确关键词，例如订单号、SKU、错误码、法规条款编号。
所以生产中推荐：
向量语义检索 + 关键词检索 + 元数据过滤 + 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 快速实验
Embedding：text-embedding-v4 1024维
向量库：FAISS / Qdrant
元数据：MySQL
文件：本地 / MinIO
13.2 企业私有化 RAG
Embedding：bge-m3 / Jina Embeddings v4 / Qwen3-Embedding 系列
向量库：Milvus / Qdrant / Elasticsearch
元数据：MySQL / PostgreSQL
文件：MinIO
任务队列：RabbitMQ / Kafka
13.3 已有 Elasticsearch 的团队
如果已有 ES，并且搜索业务以关键词检索为主，可以直接使用 Elasticsearch 的 dense_vector + kNN 能力做混合搜索。
13.4 大规模高性能向量检索
如果数据量很大、需要分布式扩展、批量导入和生产级管理，优先 Milvus / Qdrant。
13.5 海外云上快速上线
如果不想自建和运维，优先 Pinecone 这类托管向量数据库。
14. 最终结论
Embedding 与向量数据库的本质是：
把不可直接计算语义的数据，转换成可计算距离的向量；
再用向量数据库高效找到语义最接近的数据。
PDF 里的知识路线非常适合入门：
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…
