什么是嵌入（embedding）？用简单的话说
嵌入（embedding）是把文本、短语或文档变成一组数字的方法 - 固定长度的向量。嵌入模型会学习让语义相近的表述在这个数字空间里「靠得近」，不同的则离得远。语义搜索、RAG、推荐和文档聚类都建立在这之上。下文说明嵌入是什么、与 token 和 LLM 回答有何不同，以及对企业真正有用的场景。
- 向量 - 几百或几千个数字的列表，文本的「语义指纹」
- Embedding model - 把文本编码成向量的独立神经网络；不是聊天模型
- 语义相近 - 「快递配送」和「加急发货」比「配送」和「纳税申报」更接近
- 主要用途 - 按含义搜索、RAG、去重、分类
- 不要混淆 - 嵌入不生成回答；只帮助找到相关文本片段
- 实践 - 知识库索引一次，查询时检索 Top-K 最近片段
用两句话理解嵌入
想象一座图书馆，书不是按作者排序，而是按主题：物流类放一起，会计类分开，营销类在另一区。嵌入对文本做同样的事，只是在多维数字空间里。
嵌入是编码器模型的输出：输入「如何办理退货」，输出例如 1 536 个数字组成的向量。文档片段、工单、段落各有自己的向量。用户提问时，用同一模型编码，再找最近的匹配。
| 概念 | 含义 | 示例 |
|---|---|---|
| 文本 | 原始文字 | 「配送时间 2-3 天」 |
| Embedding model | 编码神经网络 | text-embedding-3-small、bge-m3 |
| 向量 | 数值表示 | [0.12, -0.04, 0.88, …] |
| Vector DB | 向量存储 + 快速检索 | pgvector、Qdrant、Pinecone |
嵌入不会像人一样「理解」文本，也不会写回答。它提供语义坐标，让计算机快速比较数百万片段。
有关键词搜索，为什么还要向量
传统关键词搜索找精确匹配：查「退货」可能找不到只写「refund policy」或「逆向物流流程」的段落。语义搜索用嵌入比较含义，而不是字母。
典型任务：
- 企业 FAQ 与客服 - 坐席或机器人按客户表述找到对应规章。
- RAG - LLM 回答前从 wiki、PDF、工单拉取相关 chunk。
- 相似工单 - 「我们遇到过这类事故」无需手工打标签。
- 去重 - 过滤几乎相同的文章、评价、商品卡。
- 聚类 - 把咨询、评价、论坛主题分组做分析。
若全部文本能放进模型的上下文窗口且很少更新，嵌入不是必须。一旦语料大、常变、持续更新 - 向量索引几乎总是比每次把整个库塞进 prompt 更划算。
文本如何变成数字
简化流程：
文档 → 分块 → embedding model → 向量 → vector DB
用户查询 → 同一 embedding model → 查询向量 → Top-K 检索 → LLM
1. 分块（Chunking）
长 PDF 或文章库切成 256-1 024 个 token 的片段，带少量重叠，避免段落被拦腰截断。块太小丢上下文；太大则检索变糊。
2. Embedding model
专用模型处理每个 chunk，输出固定维度向量 - 依模型为 384、768、1 536 或 3 072 维。云端：OpenAI text-embedding-3、Cohere、Voyage。开源：BGE、E5、multilingual-e5；也可通过 Ollama 或自建服务器本地运行。
3. 索引与检索
向量存入 vector store - 带 pgvector 的 PostgreSQL、Qdrant、Weaviate、Chroma。查询时计算问题向量与库内向量的距离；常用余弦相似度。返回最近的 Top-K 片段，通常 3 到 10 个。
检索质量约 80% 取决于「分块 + embedding model」，而非最聪明的聊天 LLM。检索 + 生成的详解见 RAG 一文。
语义相近并非魔法
向量的「相近」不是词典同义词。模型在大规模语料上训练，使邻近点对应相似语境。因此：
- 「运费」和「快递服务费用」会靠近；
- 「Python 数据分析」比「动物园里的蛇」更接近「pandas 教程」；
- 多语言模型上，中文查询可能找到英文同义段落。
重要：只能比较同一 embedding model、同一版本得到的向量。在同一索引里混用 OpenAI 与 BGE 向量无效 - 那是不同的「地图」。
嵌入在产品中的位置
| 场景 | 嵌入的作用 |
|---|---|
| 企业聊天机器人 | 调用 LLM 前找到相关文章 |
| IDE 与代码 | 仓库语义搜索（Cursor @Codebase、Copilot 索引） |
| 电商平台 | 「相似商品」、按描述搜索无需精确 SKU |
| 审核 | 垃圾聚类、重复评价检测 |
| CRM | 相似商机匹配、面向销售的知识库 RAG |
模式一致：向量检索 + LLM 推理。嵌入节省上下文窗口和 API 费用：prompt 里只有检索到的 chunk，不是整库。
嵌入 vs token vs 微调
三个常被混淆的机制：
| 嵌入 | LLM token | 微调 | |
|---|---|---|---|
| 任务 | 按含义搜索 | 文本生成 | 改变模型行为 |
| 输出 | 数值向量 | 文本 / 回答 token | 新模型权重 |
| 更新知识 | 重新索引文档 | 新 prompt / RAG | 重新训练 |
| 成本 | 比生成便宜 | 按 input + output 计费 | 贵且慢 |
token 是聊天模型的计费与切分单位。嵌入是另一 API 产品，每 1M 价格与模型都不同。策略对比见上下文窗口 vs RAG vs 微调。
如何选择 embedding model
实践中看四个参数：
- 语言 - 中俄英混合语料需要多语言模型（bge-m3、multilingual-e5、voyage-3）。
- 维度 - 维度越高往往越准，但索引与存储更重。
- 延迟与成本 - 百万级文档要算首次索引与更新时重索引费用。
- 部署 - 云端 API 上手快；本地模型适合不外传的私有数据。
MVP 往往一个成熟模型 + 现有 PostgreSQL 上的 pgvector 就够。检索指标触顶后再上多个 reranker 和 BM25 + 向量混合。
常见错误
- 随便索引 - 不清理 HTML、无分块策略、有重复 - 检索噪声大。
- 换模型不重索引 - 新旧向量不兼容。
- 指望嵌入会推理 - 向量不会回答问题；需要 LLM 或在 chunk 上的模板。
- 不看指标 - 没有「问题 → 期望文档」测试集，凭感觉调参难进生产。
- 与全文检索混淆 - SKU、料号等精确码更适合关键词 + 嵌入混合。
小结
嵌入是文本的数值「语义指纹」。在需要从大语料中找到相关内容时必不可少：RAG、客服、内部 wiki、代码搜索。若只是短对话、单文件在上下文里，向量索引可选。对常更新的知识库，嵌入是基础砖块；LLM 建在其上，而非取代它。
常见问题
嵌入和 token 有什么区别？
Token 是聊天模型的文本片段：决定 prompt 长度和 API 费用。嵌入是整段文本（句、段、chunk）的一个向量，为搜索编码语义。token 用于切分以生成；嵌入用于编码含义以便比较。
已有 ChatGPT 和 Claude，为何还要单独的 embedding model？
聊天模型优化生成回答。嵌入模型优化把含义压缩成紧凑向量并快速检索。专用编码器在大规模索引上更便宜，也不会用昂贵的 output token 去「复述」文档。
能否在同一库里混用不同模型的向量？
不能。 每个模型有自己的坐标空间与维度。索引须用同一 embedding model；更换模型需全量重索引。只比较同一编码器、同一版本的向量。
通过 API 做嵌入要花多少钱？
通常比同厂商生成文本便宜：按 embedding 端点的 input token 计费，无 output。具体取决于模型与规模；估月预算用语料 token 数 × 每 1M 单价，并预留重索引。token 逻辑详见 token 费用。
简单网站聊天机器人需要嵌入吗？
不一定。 若机器人只答十几页固定 FAQ，或一次性把 PDF 放进上下文窗口，prompt 即可。文档多、常更新、且要按用户表述检索时 - 典型 RAG 客服与内部助手场景 - 才需要嵌入。