RAG 绕不开 Embedding。不用数学公式，用 IoT 工程师熟悉的类比讲清楚。
Embedding 就是传感器的特征向量
你做过设备监控，肯定不陌生：一个设备有多个传感器——温度、振动、压力、电流——每个传感器的读数组成一个向量：
CNC-001: [温度=72°C, 振动=4.8mm/s, 压力=0.8MPa, 电流=28A]
Embedding 做的事情一模一样——把一段文字「压缩」成固定长度的数字向量。不同的是，Embedding 的维度更多（通常是 384 或 1536 维），但概念完全相同。
为什么文本可以变成数字？
因为 LLM 训练过程中学到了一种「编码规则」：语义相近的文本，向量距离近。
举个例子：
"CNC-001 轴承温度过高" → [0.23, -0.45, 0.78, ..., 0.12] (384维)
"CNC-001 轴承发热异常" → [0.25, -0.42, 0.75, ..., 0.10] (384维)
"今天天气不错" → [0.87, 0.33, 0.15, ..., -0.65] (384维)
前两个向量的「距离」很近（语义接近），第三个和前两个的「距离」很远（语义无关）。
三个你已经知道的类比
1. 传感器相关性矩阵
做故障诊断时，你不会看所有 100 个传感器——你只看和 CNC-001 最相关的几个。Embedding 检索做的是一样的：在向量空间中找「最近」的 K 个邻居。
2. 时序数据库的降采样
TDEngine 里，你把 10000 个原始采样点降维成 100 个聚合值（min/max/avg）。Embedding 也是「降维」——把一段几百字的文本压缩成 384 个浮点数。
3. MQTT Topic 匹配
MQTT 中，industrial/devices/CNC-001/temperature 和 industrial/devices/CNC-001/vibration 因为 topic 前缀一样被关联。Embedding 用向量距离代替了 topic 层级，关联粒度更细。
Embedding 怎么用在 RAG 里？
检索流程（你的视角）：
"CNC-001 轴承温度过高是什么原因？"
↓
把这句话 Embedding → [0.23, -0.45, 0.78, ...]
↓
在 Milvus 中搜索最接近的 3 个向量
↓
找到：
1. "轴承温度超过70°C时，应立即检查润滑系统..." (距离 0.12)
2. "电机温度偏高通常由过载或散热不良导致..." (距离 0.45)
3. "液压系统油温过高..." (距离 0.68)
↓
把这三条文本拼入 Prompt → 发给 LLM → 生成回答
全程不需要关键词匹配。 即使用户问的是「CNC-001 轴承发热」，知识库里写的是「轴承温度过高」，向量距离也能匹配上——因为 Embedding 理解「发热」和「温度过高」是同一件事。
Embedding 模型选型
| 模型 | 维度 | 语言 | 特点 |
|---|---|---|---|
| AllMiniLmL6V2 | 384 | 多语言 | 本地运行，无 API 费用，体积小（~80MB） |
| BGE-Large-Zh | 1024 | 中文优化 | 中文检索效果好，但体积大（~1.3GB） |
| OpenAI text-embedding-3 | 1536 | 多语言 | 效果最好，但有 API 费用 |
我选了 AllMiniLmL6V2 作为 MVP 起步——本地运行、零成本、384 维对 35 条知识库足够用。等知识库扩展到千条级别，再切换到 BGE-Large-Zh。
一句话总结
Embedding = 文本的传感器读数。向量之间的距离 = 语义的相似程度。RAG 检索本质就是在向量空间中做「最近邻查找」，和你做设备故障定位时筛选「最相关的传感器」是同一套逻辑。
没有魔法，只有数学。只是这次是用神经网络算的距离，不是欧氏距离。
本文由 LaoLiang 原创，首发于掘金/知乎/微信公众号。转载请联系作者。
