向量数据库里塞了 3000 条产品文档，用户问“如何重置密码”，返回的前三条结果分别是“欢迎使用我们的产品”、“2021年服务条款更新”、“如何修改头像”。这他妈叫检索？这叫随机抽样。我盯着 API 返回的 JSON，血压直接上来了。这就是我过去三个月搞 AI 自动化交付时，每天都要面对的狗屎现实。向量相似度检索，听起来很性感，cosine 相似度算得飞起，但落到业务场景里，它就是个瞎子。它只认“词”，不认“意”，更不认“你要干嘛”。
问题出在 embedding 模型上。我用的 text-embedding-ada-002，它把句子压成 1536 维的向量，这个向量空间里，“重置密码”和“修改头像”的距离，可能比和“忘记密码怎么办”还近。因为“修改”和“重置”都是动词，“密码”和“头像”都是名词，从纯语义组合上看，它们就是邻居。但用户要的是解决方案，不是近义词辨析。更操蛋的是，那些又长又空洞的“欢迎文档”，因为包含了“产品”、“使用”、“功能”这些高频通用词，相似度得分居然也不低。结果就是，真正有用的、步骤具体的“密码重置操作指南第 3.2 节”，被挤到了第五六条，而大模型调用时通常只取前三条上下文。完蛋，生成的内容驴唇不对马嘴，客户直接在群里开骂。
我查了一圈，发现业内老早就踩过这个坑了。光靠向量检索的“召回”不够，必须加一个“精排”环节。这就是 Rerank（重排序）。它的逻辑很简单：先用向量数据库快速召回 20 条可能相关的候选文档（Recall），然后用一个专门的、更牛逼的模型，对这 20 条文档和用户问题，进行一对一的“相关性打分”，最后按这个新分数重新排序，只取 Top 3 给大模型。这个专门打分的模型，比如 Cohere 的 rerank 或者百度的，它干的就是阅读理解判卷老师的活儿：问题在这，答案片段在这，你给判个分，0 到 1，告诉我它到底答没答到点子上。
技术栈立刻就复杂了。原来流程是：用户问题 -> embedding -> 向量数据库查询 -> 返回 Top K -> 塞进 Prompt -> GPT 生成。现在得改成：用户问题 -> embedding -> 向量数据库查询 -> 返回 Top 20 -> 调用 Rerank API（问题，[文档1, 文档2…文档20]）-> 拿到重排序后的 Top 3 -> 塞进 Prompt。延迟增加了，成本也增加了，因为每次查询得多调用一次 Rerank 的 API。但这是必须交的学费。我在 n8n 里把这个流程搭出来测试，用同样的“重置密码”问题，重排序后，Top 3 终于变成了“密码重置流程”、“常见问题：密码错误”、“账户安全设置指南”。生成的结果立刻就能用了。
这让我想起十年前做 SEO 的时候，拼命研究百度算法，琢磨怎么让目标页面排到第一。现在无非是把战场从公开搜索引擎，搬到了我自己搭建的私有知识库内部。核心矛盾没变：如何让最匹配的信息，以最低的摩擦，出现在最需要它的人面前。只是工具从关键词密度、外链，换成了 embedding 模型和 rerank 模型。AI 时代的产品经理，尤其是做自动化交付的，早就不是画原型写 PRD 了。你必须是这个微型数据系统的架构师。你得懂向量空间的局限性，得知道召回率和准确率的 trade-off，得会设计检索链路，得为每一次 API 调用的成本和效果负责。不然，你交付的不是智能，是一坨随机组合的文本垃圾，客户分分钟教你做人。
搞定了这个 rerank 的集成，我那个自动化客服助手的准确率，从大概 60% 的胡言乱语，提升到了 85% 以上的可用。剩下的 15%，是知识库本身没覆盖，或者问题太模糊。这就有得搞了，可以转人工或者让 GPT 承认不知道。至少，我不会再因为检索系统犯蠢而背锅了。下一步该头疼的是，怎么把知识库的 chunk（切片）切得更科学，以及，要不要上更贵的 embedding 模型。这坑，真是越挖越深。
