在线工具Online FlowChart & Diagrams Editor - Mermaid Live Editor
来源：CherryStudio 知识库搭建保姆级教程与api接入_cherry studio 知识库-CSDN博客
💡 关键点
- EmbeddingModel 是"翻译"角色：同一个模型必须同时用于文档和问题的向量化，否则向量不在同一语义空间，无法比较。
- VectorDB 是"检索"角色：不只是存，还要能快速查。普通数据库做不了高维向量的相似度搜索（计算量太大），所以需要专门的向量数据库。
- 存储的是"向量+元数据"：VectorDB 不仅存向量数组，还存对应的原始文本、文档来源、页码等信息，便于后续展示引用来源。
RAG 知识库工作原理
ai-检索增强生成RAG知识库工作原理与数据流转过程
ai-检索增强生成RAG 的数据流转过程
ai_RAG数据存储-数据流转关系图
知识库搭建执行流程2
向量库（VectorDB）与传统数据库的对比
这是个很好的问题！VectorDB 不完全像 MySQL 或 MongoDB，但在某些层面又有相似之处。我用一个表格帮你快速看清：
📊 核心对比
| 维度 | MySQL | MongoDB | VectorDB（如 Milvus） |
|---|---|---|---|
| 数据模型 | 结构化表格（行+列） | JSON 文档（BSON） | 向量数组 + 标量字段 |
| 存储内容 | 数字、字符串、日期等 | 嵌套 JSON 对象 | 高维向量（如 [0.12, -0.34, ...]）+ 元数据 |
| 查询方式 | SQL（精确匹配、范围查询） | MongoDB Query API | 向量相似度搜索（ANN 检索） |
| 核心能力 | 精确查询、事务、关联查询 | 灵活 Schema、水平扩展 | 语义搜索、推荐、RAG |
| 索引类型 | B-Tree、Hash、全文索引 | B-Tree、地理空间索引 | HNSW、IVF、PQ（专为向量设计） |
| 距离计算 | 不支持 | 不支持 | 余弦相似度、欧氏距离、内积 |
🔍 更直观的对比示例
MySQL 的查询
-- 精确查询：找到 age=25 的用户
SELECT * FROM users WHERE age = 25;
MongoDB 的查询
// 精确查询：找到 name="张三" 的文档
db.users.find({ name: "张三" });
VectorDB 的查询
# 语义搜索：找到与 "什么是RAG" 最相似的文本块
results = vector_db.search(
query_vector=[0.12, -0.34, 0.56, ...], # 问题向量
top_k=5, # 返回最相似的5个
metric="cosine" # 用余弦相似度计算
)
# 返回：最相关的文档块（不是完全匹配，而是语义相近）
💡 关键区别
| 对比维度 | 传统 DB（MySQL/MongoDB） | VectorDB |
|---|---|---|
| 匹配逻辑 | 精确匹配（=、LIKE、范围） | 模糊匹配（按相似度排序） |
| 查询条件 | "年龄 = 25" | "和'什么是RAG'语义最像的" |
| 返回结果 | 精确命中（有或无） | Top-K 最相似（永远有返回） |
| 数据结构 | 固定 Schema / 灵活 Schema | 固定维度向量 + 可变元数据 |
🏗️ 实际存储示例
// MySQL 的一条记录
{
"id": 1,
"title": "RAG介绍",
"content": "RAG是检索增强生成...",
"create_time": "2026-08-14"
}
// MongoDB 的一条文档
{
"_id": ObjectId("..."),
"title": "RAG介绍",
"content": "RAG是检索增强生成...",
"tags": ["AI", "LLM"]
}
// VectorDB 的一条记录
{
"id": "vec_001",
"vector": [0.12, -0.34, 0.56, 0.78, -0.21, ...], // 768维向量
"metadata": {
"text": "RAG是检索增强生成...",
"source": "rag_guide.pdf",
"page": 3
}
}
🎯 用一句话总结
| 数据库 | 一句话类比 |
|---|---|
| MySQL | 像 Excel 表格，擅长精确查询和关系管理 |
| MongoDB | 像 JSON 文件夹，擅长存储灵活结构的文档 |
| VectorDB | 像 图书馆按语义找书，你描述一个概念，它给你最相关的书 |
🔗 实际应用中的组合
在实际 RAG 系统中，这三者不是互斥的，而是配合使用：
┌────────────────────────────────────────────────────────┐
│ MySQL / MongoDB │
│ ├── 存储用户信息、文档元数据（标题、作者、上传时间） │
│ └── 管理业务逻辑（权限、计费、日志） │
└────────────────────────────────────────────────────────┘
↓ 关联
┌────────────────────────────────────────────────────────┐
│ VectorDB │
│ ├── 存储文档的向量 + 元数据引用（如 document_id） │
│ └── 执行相似度搜索，返回最相关的文档块 │
└────────────────────────────────────────────────────────┘
举例：用户问"RAG是什么" → VectorDB 返回 top-5 相关文本块 → Application 用这些块 + 用户问题组装 Prompt → LLM 生成答案 → 同时从 MySQL 查出这些文档的原始信息（作者、来源），标注引用。
如果还想了解 VectorDB 的索引原理（HNSW 为什么快） 或 如何选择适合的 VectorDB 产品，随时告诉我！
