【AI】embedding模型是干啥用的？

Olafur_zbj

359人浏览 · 2026-06-04 09:55:41

Olafur_zbj · 2026-06-04 09:55:41 发布

搭建自己的RAG系统时，除了配置 Kimi / GLM 等是“Chat 模型”，还需要一个“Embedding 模型”。

可以理解成：

Kimi / GLM / Claude / Qwen Chat
= 负责读检索结果、推理、组织答案

Embedding 模型
= 负责把文档片段和用户问题变成向量，用来搜索相似内容

Reranker 模型，可选但推荐
= 负责把初步搜到的结果重新排序，提高命中率

Embedding 模型到底是什么？

Embedding 模型不是用来聊天的。它的输出不是自然语言，而是一串数字向量，例如：

"setNanoRouteMode -routeTopRoutingLayer 的用法"
        ↓ embedding model
[0.012, -0.238, 0.441, ..., -0.083]

RAG 系统会把你的 Innovus user guide、PDK、design rule 文档切成很多 chunk，然后对每个 chunk 生成 embedding 向量，存进索引里。用户提问时，也把问题生成一个 embedding 向量，再去找“距离最近”的文档片段。Qdrant 官方也把 vectors / embeddings 描述为向量搜索的核心概念，用来定义对象在向量空间中的相似性；相似对象的向量在空间中会更接近。(Qdrant)

所以 RAG 的典型流程是：

离线建库阶段：

PDF / DOC / PDK 文档
        ↓
解析、切 chunk
        ↓
Embedding 模型
        ↓
向量索引 + 关键词索引


在线提问阶段：

用户问题
        ↓
Embedding 模型
        ↓
找相似 chunk
        ↓
可选 reranker 重排
        ↓
把命中的 chunk 交给 Kimi / GLM
        ↓
Kimi / GLM 生成最终回答

那 Kimi / GLM 不能直接做吗？

如果你只是配置了 Kimi / GLM 的 chat/completions 接口，那不够。

它们可以负责最后的回答，例如：

根据下面检索到的 Innovus 文档片段，回答用户问题，并引用 page / section。

但它们通常不会自动承担这几个工作：

1. 把几千页 PDF 切成合适的 chunk
2. 给每个 chunk 生成向量
3. 建向量索引
4. 用户提问时做向量相似度检索
5. 和关键词检索混合排序

RAGFlow 里也明确把 Chat model 和 Embedding model 分开配置。它的 Quickstart 里 System Model Settings 需要选择默认的 Chat model、Embedding model、Image-to-text model 等；Dataset 配置页也要求选择 embedding model 和 chunking method。(RAGFlow)

更关键的是，RAGFlow 文档说明：embedding model 会把 chunks 转成 embeddings，而且一个 dataset 一旦已经有 chunks，就不能直接更换 embedding model；要换 embedding model，必须删除已有 chunks，因为同一个 dataset 里的文件必须用同一个 embedding 空间比较。(RAGFlow)

这说明在 RAGFlow 里，embedding 不是可有可无的“附属设置”，而是知识库索引的基础。

一个简单类比

你可以这样理解：

Embedding 模型 = 图书馆索引员
Kimi / GLM = 专家顾问
Reranker = 二审筛选员
RAGFlow = 图书馆系统
Claude Code = 你操作的 Agent 入口

用户问：

Innovus 里怎么限制 top routing layer？

Embedding 模型负责先从几千页 Innovus manual 里找出可能相关的页面，比如：

routing layer constraint
setNanoRouteMode
routeTopRoutingLayer
routeBottomRoutingLayer

然后 Kimi / GLM 才负责基于这些片段回答：

可以使用 setNanoRouteMode ... 
相关 option 是 ...
出处是 Innovus User Guide 第 xx 页 ...

如果没有 embedding，Kimi / GLM 就像一个专家被丢进几千页 PDF 里，但没有目录、没有索引、没有搜索系统。

对你的 EDA / PDK 文档，Embedding 尤其重要，但不能只靠 Embedding

你的文档类型比较特殊：

Innovus User Guide
Innovus Command Reference
PDK 文档
TSMC N5 design rule
DRC / LVS / antenna / layer map

这些内容有两个特点：

第一，语义检索有用。
比如用户问：

如何限制 Innovus 的 routing metal layer？

文档里可能写的是：

top routing layer
bottom routing layer
routing layer assignment
setNanoRouteMode

这些词不完全一样，但 embedding 能帮你找出语义相关的片段。

第二，关键词精确命中更重要。
比如：

M0.S.1
VIA0 enclosure
CA spacing
M1 pitch
ANT rule
set_db route_design_top_routing_layer

这些不是普通自然语言，embedding 有时会把相似但错误的 rule 找出来。所以你的 RAG 不应该只做向量检索，而应该做：

关键词检索 + 向量检索 + reranker + 引用校验

RAGFlow 的 retrieval 组件默认使用加权关键词相似度和向量余弦相似度组合；如果配置 rerank model，则可以使用关键词相似度和 reranking score 组合。(RAGFlow)

这正好适合 EDA / PDK 文档。

你应该怎么配置

你的配置应该是：

Chat model:
  Kimi / GLM / 你本地 Claude Code 正在用的大模型

Embedding model:
  BGE-M3 或 Qwen3-Embedding

Reranker model:
  BGE reranker 或 Qwen3-Reranker，可选但推荐

RAGFlow:
  负责解析文档、切 chunk、建索引、检索

Claude Code:
  通过 MCP 调 RAGFlow retrieve 工具

我建议你第一版这样选：

Chat model: 你已经部署好的 Kimi / GLM
Embedding model: BGE-M3
Reranker: 先不上，检索效果不够再加
Retrieval: hybrid search，vector weight 不要太高

BGE-M3 是一个很适合作为离线 RAG 起点的 embedding 模型，它支持 dense retrieval、lexical matching 和 multi-vector interaction；官方也强调它的 multi-functionality、multi-linguality 和 multi-granularity。(BGE Model)

如果你们本地已经有 Qwen 系列生态，也可以用 Qwen3-Embedding。Qwen3 Embedding 系列是专门面向 text embedding、retrieval 和 reranking 的模型系列，并且提供 0.6B、4B、8B 等不同大小。(Qwen)

最小可用配置

你可以先这样做：

RAGFlow System Model Settings:

Chat model:
  glm5 或 kimi 2.5

Embedding model:
  bge-m3

Image-to-text model:
  暂时不配，除非 PDF 是扫描件或图片表格

Rerank model:
  暂时不配，第一版先不用

然后每个 dataset 选择：

Innovus manual:
  embedding model = bge-m3
  parse type = Manual / Book / General 逐个测试

PDK design rule:
  embedding model = bge-m3
  parse type = Manual
  如果是表格化 Excel/CSV，则用 Table

注意：同一个 dataset 的 embedding model 后续不要随便换。
RAGFlow 文档明确说，dataset 有 chunks 后不能直接换 embedding model；要换就需要删除已有 chunks 并重新解析。(RAGFlow)

Kimi / GLM 有没有可能同时当 Embedding 模型？

有两种情况。

情况一：你只部署了 chat model。

例如你的本地 endpoint 只有：

/v1/chat/completions

那它只能作为 Chat model，不够做 RAG 建库。

情况二：你的本地推理服务还提供 embedding endpoint。

例如还有：

/v1/embeddings

并且模型本身是 embedding 专用模型，例如：

bge-m3
qwen3-embedding-0.6b
qwen3-embedding-4b
qwen3-embedding-8b

那就可以给 RAGFlow 当 Embedding model。

判断方法很简单：

curl http://127.0.0.1:<port>/v1/models

看返回里有没有类似：

bge-m3
qwen3-embedding
text-embedding-xxx

以及服务是否支持：

curl http://127.0.0.1:<port>/v1/embeddings \
  -H "Content-Type: application/json" \
  -d '{
    "model": "bge-m3",
    "input": "setNanoRouteMode routeTopRoutingLayer"
  }'

如果返回是一堆数字向量，才说明 embedding 可用。

对你现在的问题，直接答案是

Kimi / GLM 够做 RAG 的“生成回答”部分，但不够做完整 RAG。

你至少还需要：

1. 一个 embedding 模型
2. 一个文档解析 / chunking 系统，RAGFlow 负责
3. 一个向量 + 关键词索引，RAGFlow 后端负责
4. 可选 reranker

推荐你这样配：

Claude Code 本地模型:
  Kimi / GLM

RAGFlow Chat model:
  可以也用 Kimi / GLM，但如果你只通过 MCP retrieve 检索，其实不一定让 RAGFlow 负责最终生成

RAGFlow Embedding model:
  BGE-M3，第一推荐
  或 Qwen3-Embedding-0.6B / 4B

RAGFlow Reranker:
  后续加 BGE reranker 或 Qwen3-Reranker

检索策略:
  hybrid retrieval
  keyword 权重大一些
  vector 权重适中

一句话：Kimi / GLM 是“会读资料并回答的人”，Embedding 模型是“帮你从几千页 EDA/PDK 文档里把相关资料先找出来的搜索引擎核心”。RAG 没有 embedding，就只剩下普通聊天模型加全文搜索，效果通常不够稳定。