​​​​​​​Embedding 的本质：为什么你的知识库 RAG 不准？

很多人第一次做 RAG（Retrieval-Augmented Generation）时，都有同样的体验：你明明把一份 200 页的 PDF、几十个 Markdown、甚至整套 API 文档都塞进了向量数据库，但一问问题，模型却开始胡说八道。

你问它 支付回调接口在哪？
它告诉你：“我猜大概在用户模块下面。”

你问它 合同审批流程怎么走？
它回答：“取决于你的项目架构。”

这类“轻度自信的瞎说”，让人以为 RAG 不靠谱。但真凶往往不是 RAG，而是 Embedding（向量编码）没理解你的内容。

Embedding 的本质比你想象中更“哲学”，也更“物理”。理解它，你才知道为什么 Retrieval 不准、为什么 Chunking 很重要、为什么有些知识永远搜不出。

在接下来的内容里，我会用尽量“人话”的方式，把这个抽象概念拆得足够具象，让你在脑中真的能“看见”向量。

---

一、为什么 RAG 不准？因为你以为模型在“理解”，其实它在“投影”

让我们从一个真实项目说起。

前段时间给一家做智能客服的团队做 RAG 优化，对方说：“我们把全部 FAQ 文档都传了，向量库大小 500MB，为什么用户问【如何修改绑定手机号】还是搜不到？”

我第一反应：Embedding 不是搜索引擎的“理解器”，它是把语言投影到空间里的数学函数。

这句话听起来很抽象？我们马上拆开。

---

二、Embedding 的本质：不是理解，而是把语义投影到一个特定结构的空间

可以把 Embedding 想象成：

把文本压缩成一串数字，让数字之间的“距离”尽量能表达语义关系。

它不是“读懂文本”，而是做“三维空间行为在一千维空间的版本”。