3 月的一个周二上午，一位首席执行官问了一个本应只需 30 秒就能回答的问题：我们是否曾同意把责任上限设定在一百万美元以下？

答案确实存在。它已写好、签字、归档，一直存放在共享驱动器里。找到它花了三天时间，而未能及时找到的代价是四万美元。

每个组织都有这样的“周二”。知识是真实的，它留存下来，分散在百万份文件、百种格式里，按当时离文件柜最近的人的习惯整理。组织知道的比任何个人都多，难点在于如何取用。

关键词搜索失败，有具体且可修复的原因

最显而易见的修复方式是索引每个词并搜索。输入“liability cap”，就能得到包含“liability”和“cap”的所有文档。但这种做法会失败，而且失败方式值得精确描述，因为每种失败都指向真正的修复方案。

合同里并没有“liability cap”，而是写着“limitation of liability”。两个短语、一个意思，却零关键词重合。你的搜索返回空结果，你便断定文件不存在。搜索栏无法区分“我们没有这样的合同”和“我们有，只是用了不同措辞”。

匹配词语不等于匹配含义。在员工手册和供应商协议中搜索“termination”，你会得到解雇、合同到期，以及可能涉及软件许可终止的段落，排序依据仅是词频。

人们提出的是问题，而非关键词。没有人用搜索术语思考。他们想的是“我们是否曾同意把责任上限设定在一百万美元以下？”关键词引擎不知道这是个问题，更不知道其中哪些词重要。

真正能弥合差距的办法

修复之道是停止比较词语，转而比较含义，这需要把文本转化为可在其中测量距离的东西。

嵌入模型读取一段文本后返回几百个数值，把这段文本定位在一个空间中，距离代表含义的相似度。关于年假的段落会彼此靠近，关于责任上限的段落则落在完全不同的位置。模型基于语言实际用法而非字符共享情况完成定位。

python
from sentence_transformers import SentenceTransformer

model = SentenceTransformer("all-MiniLM-L6-v2")

texts = [
    "4.2 Annual Leave\nFull-time employees accrue fifteen (15) days...",
    "Remote Work Policy > Schedule\nUp to three (3) days per week...",
    "Appendix B\nLodging: $180 per night, booked via travel portal.",
]
vectors = model.encode(texts)
print(vectors.shape)  # (3, 384): three texts, one map, 384 coordinates each

Enter fullscreen mode Exit fullscreen mode

现在来看有趣的部分。将问题“员工第一年有多少带薪假？”嵌入同一空间，它会落在最接近年假段落的位置。那段文字里一次都没有出现“vacation”。关键词搜索掉落的裂缝，正是因为这两种表述含义相同而在此处被填补，而模型只关注了含义。

这个模型只有 80MB。它可以在笔记本电脑上运行，无需 GPU、无需 API 密钥，这一点比听起来更重要：企业 AI 面临的第一个严肃问题是“我的数据能去哪里”，而本地运行的模型给出的答案是“哪儿也不去”。

没人会提前警告你的部分

教程里跳过的是：在嵌入任何内容之前，你必须先把文本提取出来，而档案会抵抗。

PDF 不是文档，它是一组恰好能生成字母形状的绘图指令，向它索要文本可能被拒绝。电子表格是穿了外衣的数据库，把它压平为字符串，你会得到一串数字，却不知道它们指代什么。1994 年的扫描合同根本没有文本层，只有纸张照片，任何天真的流程都会悄无声息地返回空字符串并继续，导致档案里最重要的文档变得不可见。

然后，提取完文本后，你还得把它切成块。粗暴地按 500 个字符切，可能会在词语中间切断句子，产生以“during thei”开头的块，什么也回答不了。按文档自身的关节切，保留原有标题，同一段落就会变成图书管理员能识别为已归档的内容。

这些都不是有趣的 AI 部分，但它们决定了有趣的 AI 部分能否奏效。

如果你想要完整版
我写了一本书，讲述如何从零开始构建这一系统，跟踪一家虚构的 240 人制造企业，从文件夹中的单个 PDF 一步步建立起可用的检索系统。每一行打印出来的代码都经过实际运行验证。

第 1 章免费，解释整个问题，无需代码：https://leanpub.com/learn2rag