一、两个模型的本质区别

它们不是同一个东西

RAG流程中存在两种完全不同的模型，各司其职：

┌─────────────────────────────────────────────────────────────────┐
│ RAG 流程中的两个模型 │
│ │
│ │
│ │ │
│ ▼ │
│ ┌──────────────────────┐ │
│ │ ① Embedding 模型 │ ← 本地 CPU，~0.3GB │
│ │ 只管：文字 → 数字 │ 输入一段文字，输出一串数字│
│ │ “Java 垃圾回收” │ 不能对话、不能理解语义 │
│ │ ↓ │ │
│ │ │ ← 个浮点数 │
│ └──────────┬───────────┘ │
│ ▼ │
│ ┌──────────────────────┐ │
│ │ 向量数据库 │ ← 用“语义指纹”去搜索最相似的文档 │
│ │ “这是检索到的3段相关文档片段...” │
│ └──────────┬───────────┘ │
│ ▼ │
│ ┌──────────────────────┐ │
│ │② LLM 大语言模型 │ ← 远程 API，数百 GB │
│ │ 只管：阅读 + 理解 │ 能读文档、能推理、能写答案 │
│ │ 把问题+检索结果一起发给大模型 │
│ └──────────────────────┘ |
└─────────────────────────────────────────────────────────────────┘

类比理解

典型代表  |  BGE‑large‑zh,OpenAI text‑embedding‑3  vs  DeepSeek V4,GPT‑4o,Claude 一句话  |  Embedding = “把文字变成数字标签”，LLM = “阅读上下文写答案”。

对比维度	Embedding 模型	LLM 大语言模型
角色类比	图书管理员	专家教授
能做什么	把一段文字变成一串数字	读上下文、理解意图、生成自然语言回答
不能做什么	直接对话或生成文本	直接输出向量。仅提供语义表示能力较弱
输入	单段文字	完整对话上下文
输出	个浮点数数组	自然语言文本
模型大小	约 0.3 GB，可在 CPU 上离线运行	数百 GB，需要 GPU 集群
运行方式  |  本地下载离线推理  vs  远程 API 调用

为什么不都用远程 API？

很多团队在成本和延迟之间犹豫不决。下面从实际使用频率出发，对比两者：

调用频率 单次调用量 成本敏感度

维度	L​LM	Embedding
每次对话 - N 次	每个文档切片 + 每次检索查询
1 次请求	上传时批量 N 条。检索时单次查询1 次
对话主要体验，高频但可接受一定费用	大规模知识库上传成本不可忽视，批量本地化零费用更具优势

<举例>：一个知识库包含 2000 个 PDF，切出约 100 万 chunk。如果使用远程 Embedding API，每个 chunk 都要付费；而本地 BGE 模型一次加载后可以无限次离线向量化。

# 本地 BGE 示例
from sentence_transformers import SentenceTransformer
model = SentenceTransformer
embeddings = model.encode
# 批量免费
# 若使用远程 API。则按 token × $计费，成本随 chunk 数线性增长。

二、为什么需要专门的向量数据库？话说回来，

MySQL 能存向量吗？但能高效搜索吗，按理说，

The short answer: MySQL 可以存储二进制向量。但没有专门的 ANN 索引，只能全表扫描，性能极差。

# MySQL 示例：只能做精确/模糊文字匹配
SELECT * FROM docs WHERE content LIKE '%Java 垃圾回收%';-- 当使用者问 "JVM GC机制" 时字面不匹配 → 搜不到
# 即便把向量放进 BLOB 列，也没有向量索引 → 必须逐条计算欧氏距离 → 成千上万条记录耗时数十秒。# Milvus 则提供语义相似度搜索：
-- 使用者问 "JVM GC机制"
-- 返回相似度最高的若干文档片段。

性能对比​​​​​​​​​​​​​​​​​​​​​​​​​​​​‍‍‍‍‍‍‍‍‍‍‍‍‍‌​​​‌​​​‌​​​‌​​​‌​​​‌​​​‌​​​‌‌​​​‌‌​​​‏‏‏‏‏‏‏‏‎‎‎‎‎)

MySQL   

But we need a clean table:

Let's rewrite:

*/

数据库/框架	Top‑K 检索耗时
	10 条结果	100 条结果
- ~5–10 s

数据库/框架Top‑10 耗时 Top‑100 耗时 ';说起来， ';...

Will just produce final corrected table after analysis.

We need to present a proper table comparing performance:

Database | Top-10 | Top-100

MySQL | ~500 ms | ~3000 ms

Milvus | ~10 ms | ~50 ms

Let's incorporate that.

Now continue:

在项目中的位置——PrismAI 实际案例

...

Continue with code snippet and explanation.

Need to embed pain points like "难以维护" etc.

Also include downgrade chain and FAQ sections with pain point emphasis.

Make sure all headings use h2 or h3 only as requested. The original used h2 for main sections and h3 for sub-subsections maybe. Let's adopt:

Use h2 for major sections .

---