Embedding 深度技术解析：从向量空间到 RAG 与 Agent 的语义基础设施
摘要
Embedding 是现代 AI 应用最容易被低估的一项基础技术。
很多人对 Embedding 的理解停留在一句话：
“Embedding 就是把文本转换成向量。”
这句话没有错，但远远不够。
从工程角度看，Embedding 真正解决的问题是：
如何把原本无法直接进行数学比较的非结构化信息，映射到一个具有语义结构的向量空间，使系统能够通过距离、方向和邻近关系判断信息之间的语义关联。
因此，Embedding 是 RAG、Semantic Search、推荐系统、知识库、Agent Memory、代码搜索、多模态检索以及向量数据库的基础设施。
本文将从数学原理、模型训练、向量空间、相似度计算开始，一直到 Chunking、Retrieval、Reranking、Vector Database、RAG、Agent Memory 和生产系统设计，系统理解 Embedding。
一、Embedding 到底是什么？
假设我们有两句话：
A：Redis 是一种内存数据库。
B：Redis 是一种基于内存的数据存储系统。
传统字符串比较可能认为：
A != B
甚至：
String Similarity ≈ 很低
但是人类很容易理解：
A ≈ B
Embedding 的目标就是让机器也能理解这种关系。
例如：
A
↓
Embedding Model
↓
[0.12, -0.34, 0.78, ..., 0.21]
B：
B
↓
Embedding Model
↓
[0.14, -0.31, 0.75, ..., 0.19]
两个向量在空间中比较接近。
于是：
Distance(A, B)
较小。
这意味着：
Embedding 的本质不是“生成数字”，而是建立一个可计算的语义空间。
二、为什么需要 Embedding？
计算机最擅长处理：
Numbers
Strings
Structured Data
但自然语言是：
Semantic Information
例如：
“Java 中如何实现线程安全？”
与：
“Java 并发环境下如何保证共享数据的一致性？”
字符串完全不同。
但语义高度相关。
如果我们希望计算机：
Query
↓
找到语义最相关的信息
就需要：
Natural Language
↓
Embedding
↓
Vector Space
于是问题从：
字符串比较
变成：
向量距离计算
这就是 Embedding 的核心价值。
三、Embedding 的数学本质
可以把 Embedding Model 看成一个函数：
f(x) → v
其中：
x = 原始输入
v = 向量
例如：
f("Redis is an in-memory database")
得到：
v ∈ R^1536
假设模型维度是：
1536
那么：
v =
[
0.123,
-0.238,
0.912,
...
0.041
]
所以一个文本被映射到了：
R^1536
这个空间叫：
Embedding Space / Vector Space
四、向量维度到底意味着什么？
这是一个非常容易产生误解的问题。
如果 Embedding 是：
1536 dimensions
并不意味着：
Dimension 1 = Java
Dimension 2 = Redis
Dimension 3 = Database
通常不是这样。
每一个维度并不一定对应一个人类可以直接解释的概念。
更合理的理解是：
1536-dimensional latent semantic space
模型通过训练学习：
Semantic Relationships
例如：
Java
Spring
JVM
Redis
Kafka
Database
这些信息最终形成某种高维空间中的结构。
五、Embedding 最重要的不是“向量”，而是“空间”
这是理解 Embedding 最关键的地方。
如果只有：
Vector
没有：
Meaningful Geometry
那么 Embedding 就没有价值。
真正重要的是：
Vector Space
假设：
Kafka
●
/
/
Java
●
/
/
Spring
●
Redis ●
\
\
Database
●
这不是实际的二维 Embedding，而只是概念图。
真实空间可能是：
384D
768D
1024D
1536D
3072D
甚至更高。
模型训练的目标之一，就是让：
Semantic Similarity
在这个空间里表现为：
Geometric Proximity
也就是：
语义相似 → 向量接近
六、Cosine Similarity
Embedding 检索最常见的相似度之一是：
Cosine Similarity
公式：
cos(θ) =
(A · B)
────────
||A|| ||B||
其中：
A · B
是向量点积。
而：
||A||
是向量长度。
所以：
Cosine Similarity
主要关注的是：
两个向量的方向是否相似。
七、为什么 Cosine Similarity 很重要？
假设：
A = [1, 2]
B = [2, 4]
B 是 A 的两倍。
欧氏距离：
distance(A,B)
并不为 0。
但它们方向完全一致：
A →
B ↗
Cosine Similarity：
≈ 1
所以 Cosine Similarity 很适合表示：
Semantic Direction
八、Euclidean Distance
另外一种常见方式是欧氏距离：
d(A,B)
=
sqrt(
Σ(Ai-Bi)^2
)
也就是：
A ───────── B
空间中的直线距离。
Embedding 检索中常见：
Cosine Similarity
Euclidean Distance
Dot Product
不同模型和向量数据库对距离函数的支持不同。
因此选择 Embedding Model 时不能只看：
dimension
还要确认：
metric
normalization
index
九、Dot Product
点积：
A · B
=
Σ AiBi
如果两个向量方向相似，并且长度较大：
Dot Product
可能更高。
很多 Embedding 系统会对向量进行：
L2 Normalization
即：
||A|| = 1
这种情况下：
Cosine Similarity
≈
Dot Product
因此工程上经常可以看到：
Cosine
和：
Inner Product
的选择。
十、Embedding Model 是怎么训练出来的？
这是 Embedding 最值得深入理解的部分。
一个 Embedding Model 并不是：
文本
↓
随机算法
↓
向量
而是经过大量训练得到：
文本
↓
Neural Network
↓
Representation
↓
Training Objective
↓
Semantic Space
模型需要学习：
哪些文本应该接近？
哪些文本应该远离？
十一、Contrastive Learning
现代 Embedding 模型大量使用：
Contrastive Learning
例如：
Query:
如何实现 Redis 分布式锁？
Positive:
Redis Distributed Lock Implementation
Negative:
PostgreSQL Index Optimization
模型需要学习：
distance(Query, Positive)
变小。
同时：
distance(Query, Negative)
变大。
于是：
Positive
↑
│
Query
│
↓
Negative
逐渐形成结构化的语义空间。
十二、Triplet Learning
可以进一步抽象成：
Anchor
Positive
Negative
例如：
Anchor:
Java concurrency
Positive:
Java thread synchronization
Negative:
React component lifecycle
目标：
Similarity(anchor, positive)
>
Similarity(anchor, negative)
通常会增加一个 margin：
Similarity(A,P)
>
Similarity(A,N) + margin
这就是典型的 Triplet Learning 思路。
十三、Embedding 的训练目标
可以概括为：
Learning Objective
↓
Semantic Geometry
↓
Useful Vector Space
也就是说：
Embedding Model 真正学习的是“如何组织语义空间”。
所以不同 Embedding Model 最大的区别之一不是：
向量长度
而是：
它学到了什么样的语义空间。
十四、为什么不同 Embedding Model 不能直接混用？
假设：
Document Embedding
使用：
Model A
Query：
Model B
然后直接计算：
CosineSimilarity(A_vector, B_vector)
通常没有意义。
因为：
Model A
学习的是：
Space A
而：
Model B
学习的是：
Space B
即使都是：
1536 dimensions
也不意味着：
Space A == Space B
所以生产系统必须保证：
Document Embedding
↓
Same Embedding Model
↑
Query Embedding
这是一个非常重要的工程原则。
十五、Embedding Dimension 越大越好吗？
不一定。
例如：
384
768
1024
1536
3072
维度越高：
优点：
Representation Capacity
↑
但缺点：
Storage
↑
Memory
↑
Network
↑
Index Size
↑
Search Cost
↑
例如：
1 million vectors
×
1536 dimensions
×
4 bytes
大约需要：
6.1 GB
仅仅是原始 float32 数据，还没有计算：
Index
Metadata
Replication
Overhead
因此：
Embedding Dimension 是准确率与成本之间的工程权衡。
十六、Embedding 的存储成本
假设：
1,000,000 documents
每个向量：
1536 dimensions
float32：
4 bytes
则：
1,000,000 × 1536 × 4
≈ 6.14 GB
如果：
10 million vectors
就是：
≈ 61.4 GB
还没有考虑：
HNSW Index
Metadata
Replication
所以企业级 Vector Database 很快就会进入：
Memory Optimization
Quantization
Sharding
Index Optimization
十七、Quantization
为了降低成本，可以进行：
FP32
↓
FP16
↓
INT8
↓
Binary
例如：
FP32
4 bytes
变成：
INT8
1 byte
理论上存储降低：
4x
但是会产生：
Precision Loss
因此需要通过 Evaluation 判断：
Recall
Latency
Memory
Cost
之间的平衡。
十八、Embedding 与 Chunking
Embedding 本身并不负责：
如何切文档
但 Embedding 的质量高度依赖 Chunking。
例如一份：
100-page PDF
如果直接：
PDF
↓
One Embedding
那么检索：
“Redis timeout 怎么解决？”
会得到一个包含大量无关信息的巨大向量。
所以通常需要：
Document
↓
Chunking
↓
Embedding
↓
Vector DB
十九、Chunk 太大有什么问题？
假设：
Chunk = 10,000 tokens
里面包含：
Redis
Kafka
PostgreSQL
Kubernetes
Embedding 最终表达的是：
综合语义
检索：
Redis timeout
时可能不够精准。
二十、Chunk 太小有什么问题？
例如：
Chunk = 50 tokens
可能导致：
Context 不完整
例如原文：
Redis Cluster 使用 hash slot 将 key 分布到不同节点。
被切成：
Redis Cluster 使用 hash slot
和：
将 key 分布到不同节点。
语义可能被破坏。
所以：
Chunking 是 Embedding Retrieval 的第一层质量控制。
二十一、Overlap
常见方式：
Chunk Size = 500 tokens
Overlap = 100 tokens
例如：
Chunk 1:
0 ───────── 500
Chunk 2:
400 ───────── 900
Chunk 3:
800 ───────── 1300
这样可以避免：
Semantic Boundary
刚好被切断。
二十二、Semantic Chunking
更高级的方法不是：
每 500 tokens 切一次
而是根据：
Paragraph
Section
Heading
Topic
Semantic Boundary
切。
例如：
# Redis Cluster
Redis Cluster provides...
## Hash Slot
Redis Cluster uses...
## Failover
Redis Cluster supports...
可以形成：
Chunk 1:
Redis Cluster Overview
Chunk 2:
Hash Slot
Chunk 3:
Failover
通常比简单固定长度 Chunk 更合理。
二十三、Metadata 比 Embedding 本身还重要
一个优秀的 Vector Record 不应该只有：
vector
还应该有：
{
"id": "doc-001",
"vector": [...],
"content": "...",
"source": "redis-guide",
"document_type": "technical",
"language": "en",
"product": "redis",
"version": "7",
"section": "cluster",
"timestamp": "2026-08-01"
}
这样查询：
Redis Cluster
可以先：
Filter:
product = redis
version = 7
再：
Vector Search
二十四、Vector Search 不等于 Semantic Search
这两个概念经常被混淆。
Vector Search：
Query
↓
Embedding
↓
Nearest Neighbors
Semantic Search 更完整：
Query
↓
Query Understanding
↓
Keyword Search
↓
Vector Search
↓
Metadata Filter
↓
Reranking
↓
Results
所以：
Vector Search 是 Semantic Search 的一个组件。
二十五、为什么 Hybrid Search 很重要？
假设用户搜索：
Spring Boot 3.4.5
Embedding 可能理解：
Spring Boot
但：
3.4.5
这种精确版本号更适合：
Keyword Search
再例如：
Error code: ERR_CONNECTION_RESET
这种字符串：
ERR_CONNECTION_RESET
Embedding 未必比 BM25 更有效。
所以生产 RAG 经常使用：
BM25
+
Vector Search
即：
Hybrid Search
二十六、Reranking
假设：
Vector Search
返回：
Top 50
但是最终只需要：
Top 5
可以使用：
Reranker
流程：
Query
↓
Embedding
↓
Vector Search
↓
Top 50
↓
Reranker
↓
Top 5
↓
LLM
Reranker 可以更加精细地判断：
Query
+
Document
之间的相关性。
因此：
Embedding 负责快速召回，Reranker 负责精确排序。
二十七、Embedding Retrieval 的完整架构
现代 RAG 更接近：
Query
│
┌───────────┴───────────┐
│ │
▼ ▼
Keyword Search Vector Search
│ │
└───────────┬───────────┘
▼
Fusion
│
▼
Top 50/100
│
▼
Reranker
│
▼
Top K
│
▼
Context
│
▼
LLM
Embedding 处在：
Query
↓
Vector Search
这个关键位置。
二十八、Embedding 与 RAG
RAG：
Retrieval-Augmented Generation
核心流程：
User Query
↓
Query Embedding
↓
Vector Search
↓
Relevant Chunks
↓
Context
↓
LLM
↓
Answer
Embedding 解决的是：
Retrieval
而 LLM 解决：
Generation / Reasoning
因此：
RAG Quality
并不只是：
LLM Quality
还包括：
Embedding Quality
+
Chunking Quality
+
Retrieval Quality
+
Reranking Quality
+
Context Construction
二十九、一个非常重要的认知：RAG 的瓶颈可能不是 LLM
假设：
LLM = GPT-level model
但：
Embedding Retrieval
找错了文档：
Query:
如何解决 Redis Cluster 的脑裂问题？
Retrieved:
Redis 基础数据结构
Redis String
Redis List
Redis Set
那么：
LLM
即使很强，也没有正确 Context。
因此：
Garbage In
↓
Garbage Out
在 RAG 系统中尤其明显。
三十、Embedding 与 Agent Memory
Embedding 不仅用于 RAG。
还可以用于：
Agent Memory Retrieval
例如用户过去说过：
我主要使用 Java。
系统存储：
Memory
↓
Embedding
↓
Vector DB
下一次用户问：
帮我设计一个微服务。
系统进行：
Query Embedding
↓
Memory Search
↓
找到：
用户主要使用 Java / Spring Boot
然后：
Context
+
Memory
注入 LLM。
于是 Agent 可以：
Remember Relevant Information
这就是：
Semantic Memory Retrieval
三十一、Embedding 与 Agent Memory 的局限
但是：
Memory = Vector DB
也是错误的。
不同 Memory 类型应该使用不同机制：
Semantic Memory
→ Embedding
Episodic Memory
→ Event Store
Structured Memory
→ SQL / KV
Working Memory
→ Agent State
Long-term Memory
→ Persistent Store
因此：
Embedding 是 Memory Architecture 的一个组件，而不是 Memory 本身。
三十二、代码 Embedding
对于 Code Agent，普通文本 Embedding 可能不够。
代码具有：
Syntax
Structure
Dependency
Call Graph
Type
Symbol
Control Flow
例如：
orderService.createOrder()
真正相关的代码可能是：
OrderService
↓
OrderRepository
↓
InventoryService
↓
PaymentService
所以代码搜索通常需要结合：
Code Embedding
+
Keyword Search
+
AST
+
Symbol Search
+
Dependency Graph
三十三、代码 Embedding 的核心问题
例如：
用户：
找到处理订单退款的代码。
Embedding 可能找到：
refund()
refundOrder()
processRefund()
但还应该找到：
PaymentService
RefundRepository
RefundController
RefundEvent
这就是：
Semantic Retrieval + Structural Retrieval
也是 Code Agent 比普通 RAG 更复杂的原因。
三十四、多语言 Embedding
现代系统可能同时处理：
中文
英文
日文
代码
Markdown
PDF
因此 Embedding Model 是否支持：
Multilingual
非常重要。
例如：
Query:
什么是 Redis Cluster？
Document：
Redis Cluster is a distributed implementation...
如果 Embedding Space 支持跨语言语义对齐：
中文 Query
↓
English Document
仍然可以检索出来。
这就是：
Cross-lingual Semantic Retrieval
三十五、多模态 Embedding
Embedding 不再局限于文本。
例如：
Image
↓
Embedding
以及：
Text
↓
Embedding
如果两个 Embedding 位于共享空间：
Text:
“一个人在海边骑自行车”
可以检索：
Image:
海边骑自行车的人
这就是：
Multimodal Embedding
典型应用：
Image Search
Video Search
Document Search
Visual RAG
Multimodal Agent
三十六、Embedding Model 如何选择？
不要只看：
Dimension
应该至少考虑：
1. Retrieval Quality
2. Language Support
3. Domain Support
4. Dimension
5. Latency
6. Cost
7. Context Length
8. Query/Document Compatibility
9. Licensing
10. Deployment Model
例如：
中文知识库
重点：
Chinese Retrieval
而：
Code Repository
重点：
Code Retrieval
三十七、不要迷信 Benchmark
Embedding Benchmark 很重要。
但：
MTEB Score
不能直接等价：
你的 RAG Quality
原因是：
Benchmark Dataset
≠
Your Dataset
真正可靠的方法是建立自己的：
Evaluation Dataset
例如：
{
"query": "Redis Cluster 如何进行故障转移？",
"relevant_documents": [
"redis-cluster-failover.md"
]
}
然后测试：
Recall@K
Precision@K
MRR
NDCG
三十八、Recall@K
例如：
K = 5
如果正确文档出现在：
Top 5
则：
Recall@5 = 1
否则：
Recall@5 = 0
大量 Query 求平均：
Recall@5
可以很好地衡量：
Retrieval 是否找到了正确内容。
三十九、MRR
MRR：
Mean Reciprocal Rank
如果正确答案：
Rank 1
得分：
1
如果：
Rank 2
得分：
1/2
如果：
Rank 10
得分：
1/10
它非常适合：
Search Ranking
评估。
四十、NDCG
NDCG 更适合：
多个结果具有不同相关程度
例如：
Rank 1 → highly relevant
Rank 2 → relevant
Rank 3 → somewhat relevant
Rank 4 → irrelevant
NDCG 可以衡量：
Ranking Quality
所以生产 Retrieval Evaluation 通常不会只看：
Recall
而会结合：
Recall@K
MRR
NDCG
Precision@K
四十一、Embedding Pipeline 的生产架构
一个企业级系统可以设计成：
Document
│
▼
Parser/OCR
│
▼
Chunker
│
▼
Metadata Enrichment
│
▼
Embedding Model
│
▼
Vector Store
│
┌──────────┴──────────┐
│ │
Metadata Vector Index
Filter │
│ │
└──────────┬──────────┘
▼
Retrieval
│
▼
Rerank
│
▼
Context
│
▼
LLM
四十二、Embedding Pipeline 的版本管理
这是生产环境一个经常被忽略的问题。
假设：
v1 Embedding Model
已经生成：
100 million vectors
现在升级：
v2 Embedding Model
怎么办？
不能简单地：
Query → v2
Document → v1
因为：
Vector Space
已经改变。
正确方式通常是：
Document
↓
v1
↓
Old Index
Document
↓
v2
↓
New Index
然后：
Shadow Testing
↓
Evaluation
↓
Migration
↓
Switch
因此：
Embedding Model Version 是数据 Schema 的一部分。
四十三、Embedding Schema
建议 Vector Record 至少包含：
{
"id": "chunk-123",
"embedding_model": "embedding-v2",
"embedding_dimension": 1536,
"content_hash": "abc123",
"document_id": "doc-001",
"chunk_id": "chunk-003",
"content": "...",
"metadata": {}
}
这样可以支持：
Re-index
Migration
Debugging
A/B Testing
Rollback
四十四、Embedding Cache
如果同一个 Query 重复出现：
How to configure Redis Cluster?
没有必要每次都：
LLM
↓
Embedding API
可以：
Query
↓
Hash
↓
Cache
↓
Embedding
例如：
Redis
Local Cache
CDN-like Cache
这样可以降低：
Latency
Cost
API Load
四十五、Embedding 与 Redis
如果系统已经使用 Redis：
Redis
不仅可以作为：
Cache
还可以用于：
Vector Search
典型架构：
Application
↓
Redis
┌───────────────┐
│ Metadata │
│ Vector │
│ Cache │
└───────────────┘
对于中小规模应用：
Redis Vector Search
可以减少：
Additional Infrastructure
四十六、Embedding 与 PostgreSQL
如果系统已经使用：
PostgreSQL
也可以通过：
pgvector
实现：
Vector Storage
+
Similarity Search
架构：
PostgreSQL
│
├── Business Tables
│
├── Metadata
│
└── Vector Column
这对：
企业内部 RAG
非常实用。
因为：
Business Data
+
Vector Data
可以在同一个数据库体系中管理。
四十七、专用 Vector Database
当规模变大，可以考虑：
Milvus
Qdrant
Weaviate
Pinecone
等专门的 Vector Database。
核心能力包括：
ANN Search
Filtering
Sharding
Replication
Index Management
Metadata
Hybrid Search
但不要因为：
AI Application
就立即引入：
Vector Database
如果：
100K documents
PostgreSQL + pgvector
可能已经足够。
架构设计首先应该考虑：
Scale
Latency
Operational Complexity
Cost
四十八、ANN：为什么向量搜索不能暴力计算？
假设：
10 million vectors
每次 Query 都计算：
Query
↓
10 million × Cosine Similarity
显然成本很高。
因此需要：
Approximate Nearest Neighbor
即：
ANN
目标不是：
100% exact
而是：
Very good recall
+
Much lower latency
四十九、HNSW
HNSW：
Hierarchical Navigable Small World
是现代 Vector Search 中非常重要的 ANN Index。
可以简单理解成：
Layer 2
A ───── D
/ \
B F
Layer 1
A ─ B ─ C ─ D ─ E ─ F
Layer 0
A-B-C-D-E-F-G-H-I...
搜索时：
Top Layer
↓
Find approximate region
↓
Lower Layer
↓
Refine
↓
Nearest Neighbors
从而避免：
Scan all vectors
五十、HNSW 的工程参数
常见参数：
M
efConstruction
efSearch
其中：
M
影响图连接数量。
通常：
M ↑
→ Recall ↑
→ Memory ↑
→ Build Cost ↑
而：
efSearch ↑
→ Recall ↑
→ Latency ↑
所以 Vector Search 本质上也是：
Recall
vs
Latency
vs
Memory
的优化问题。
五十一、Embedding 的三个核心工程层次
如果把整个技术体系压缩，可以分成三层。
第一层：Representation
Text
↓
Embedding
↓
Vector
解决：
如何表达语义？
第二层：Retrieval
Vector
↓
ANN
↓
Top K
↓
Rerank
解决：
如何找到相关信息？
第三层：Context
Retrieved Information
↓
Filtering
↓
Compression
↓
Context Construction
↓
LLM
解决：
如何把相关信息提供给模型？
这三层共同组成现代 RAG：
Embedding
+
Retrieval
+
Context Engineering
五十二、Embedding、RAG、Context Engineering 的关系
可以把三者理解成：
RAG
│
┌───────┴────────┐
│ │
Retrieval Generation
│ │
Embedding LLM
│
Vector Database
而 Context Engineering 又横跨其中：
Embedding
↓
Retrieval
↓
Context Selection
↓
Context Compression
↓
Context Assembly
↓
LLM
所以：
Embedding 是 Context Engineering 的重要基础设施之一。
五十三、Embedding 不是“理解”
这是最后需要强调的一个认知。
Embedding 并不是：
AI 已经理解了这句话。
更准确地说：
Embedding
=
Learned Representation
它把：
High-dimensional semantic information
映射成：
Dense Vector Representation
然后：
Distance
可以作为：
Similarity Signal
但是：
Similarity ≠ Reasoning
例如：
A 和 B 很相似
并不意味着：
A 能推出 B
也不意味着：
A 和 B 逻辑等价
因此：
Embedding
擅长：
Retrieval
Clustering
Matching
Recommendation
Classification
而：
LLM
更擅长：
Reasoning
Generation
Transformation
Planning
两者是互补关系。
五十四、最终架构认知
现代 AI 应用可以抽象成：
User
│
▼
┌─────────────┐
│ Agent / App │
└──────┬──────┘
│
▼
┌─────────────────┐
│ Context Engine │
└────────┬────────┘
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
Memory RAG Tools
│ │
▼ ▼
Embedding Embedding
│ │
└─────────────┘
│
▼
Vector Retrieval
│
▼
Reranker
│
▼
Context
│
▼
LLM
│
▼
Answer
这里可以看到：
Embedding 并不是 RAG 的附属功能，而是现代 AI 系统中的语义基础设施。
五十五、总结：真正理解 Embedding
如果只记住本文最重要的几个观点，可以记住下面这些。
1. Embedding 不只是“文本转向量”
它真正建立的是：
Semantic Vector Space
2. Embedding 的核心是空间关系
Semantic Similarity
↓
Geometric Proximity
3. Embedding Model 决定向量空间
因此：
Document Embedding
和：
Query Embedding
必须使用兼容的 Embedding Model。
4. Embedding Dimension 不是越高越好
需要综合考虑：
Quality
Memory
Latency
Cost
5. Chunking 会直接影响 Retrieval Quality
Bad Chunking
↓
Bad Embedding Retrieval
↓
Bad RAG
6. Vector Search 不等于完整 Semantic Search
生产系统通常需要：
Keyword
+
Vector
+
Metadata
+
Reranker
7. Embedding 是 RAG 的基础，但不是 RAG 的全部
完整链路是：
Document
↓
Chunking
↓
Embedding
↓
Vector Index
↓
Retrieval
↓
Reranking
↓
Context Engineering
↓
LLM
8. Embedding 也是 Agent Memory 的基础设施
Memory
↓
Embedding
↓
Semantic Retrieval
但：
Memory ≠ Vector Database
9. Embedding 需要独立 Evaluation
不要只测试：
LLM Answer
还要测试：
Recall@K
MRR
NDCG
Precision@K
Latency
Cost
10. Embedding 最终属于 AI 基础设施
它连接：
Unstructured Data
↓
Semantic Representation
↓
Retrieval
↓
Context
↓
LLM
↓
Agent
所以可以用一个公式概括：
Embedding
=
Semantic Representation
+
Vector Space
+
Similarity
+
Retrieval Infrastructure
而进一步把它放进你前面学习的 Context Engineering 体系中：
Context Engineering
│
┌─────────────────┼─────────────────┐
│ │ │
Memory RAG Tools
│ │
▼ ▼
Embedding Embedding
│ │
└──────────┬──────┘
▼
Retrieval
│
▼
Context
│
▼
LLM
│
▼
Agent
因此，如果 Prompt Engineering 解决的是“怎么告诉 LLM”，Context Engineering 解决的是“LLM 当前需要知道什么”，那么 Embedding 解决的就是：
“系统如何在海量非结构化信息中找到与当前任务最相关的东西？”
这三者结合起来，才构成现代 RAG 和 Agent 系统真正的技术基础：
Prompt Engineering
↓
Context Engineering
↓
Embedding / Retrieval
↓
RAG
↓
Agent
↓
Agent Runtime / Harness
