知识库答不准，绝大多数人的第一反应是去改提示词、调切片长度、换大模型。但真正卡住效果的，经常是更底层的两样东西：嵌入模型和向量数据库。这两样一旦选错，上面怎么调都是在错误的召回结果里挑。
尴尬的是，很多教程把这两件事混在一起讲成「选个向量库」。其实它们解决的完全是两个问题：嵌入模型决定「一段文字被翻译成什么坐标」，向量库决定「这些坐标怎么被存下来、怎么被快速找回来」。这篇就把这两件事拆开讲，最后给一份能直接用的清单。
先分清：嵌入模型管「翻译」，向量库管「找」
嵌入模型（embedding）把文字变成一串数字。它决定的是语义空间的质量——「年假怎么申请」和「请假流程是什么」在它眼里是不是靠得近，全靠它。
向量数据库负责存这串数字、建索引、在你提问时快速找出最近的若干条。它决定的是速度、过滤能力和运维成本，不决定语义好坏。
一个常见误区是：花了大力气对比向量库，却随手挑了个英文榜上排名高的嵌入模型——中文效果直接崩掉，换库也救不回来。整条链路怎么调，可以参考 知识库检索怎么做才准确；这一篇只讲最下面那层怎么定。
嵌入模型怎么选：看五个点，不看榜单排名
（1）中文效果要单独验，别拿英文榜当依据。很多模型在英文检索任务上分数很高，切到中文的短查询、成语、行业术语就明显退化。验证方式很简单：拿二十条你业务里的真实问题，人工看前五条召回对不对。这一步花半小时，能省后面两周的调试。
（2）维度不是越高越好。维度高意味着表达空间更细，但也意味着存储更大、索引更慢、成本更高。在几万条文档的量级上，把维度从几百提到一千多，通常换不来肉眼可见的召回提升，只会让检索变慢。先按中等维度起步，效果不够再往上试，不要一上来就顶配。
（3）输入长度上限直接决定你的切片粒度。模型能接受的长度如果偏短，切片就得切得更碎，而切得太碎会让「一段完整逻辑」被拆散，检索时就召不回完整上下文。这是选型时最容易被忽略、又最难事后补救的一条——一旦切片策略跟着定下来，后面换模型等于全部重算。
（4）看它是不是为非对称检索设计的。知识库检索有个天然的不对称：问题短、文档长。有些模型提供了「查询侧加指令前缀」的用法，专门优化这种场景，效果比把问题和文档一视同仁要好。选型时先确认它支不支持，支持的话一定用上。
（5）版本能不能锁住，比最新版有多强更重要。嵌入模型不是「换了更好」，而是「换了就得全部重算」。一个能锁版本、接口稳定的模型，长期价值远高于一个每月更新但向量空间会变的模型。这一点的工程意义，和 AI Agent 怎么选模型 里讲的原则是相通的：可预期比一时领先更值钱。
向量库怎么选：看四个维度，不看功能列表
（1）先看规模，多数项目根本不需要独立向量库。如果文档只有几千到几万条，直接用你已经在用的数据库加一个向量扩展，或者干脆在内存里做暴力检索，速度完全够，还省掉一整个服务要运维。上独立向量库的门槛应该是「数据量到了内存放不下」或者「并发查询量起来了」，而不是「别人都在用」。
（2）混合检索基本是中文场景的必选项。纯向量检索有个天然短板：专有名词、产品编号、人名、合同条款号这类「精确字符串」搜不到。因为它们在语义空间里没有稳定邻居。解决办法是把向量检索和关键词检索的结果做融合排序——这是中文企业知识库里提升感知效果最快的一步，通常比换嵌入模型见效更明显。
（3）元数据过滤要和向量检索一起用。真实知识库的检索从来不只按相似度。还要按权限（这个人能看哪些部门）、按时间（只要现行制度）、按来源（只要已发布的）。如果向量库只能在「全部数据」里找、过滤得靠代码在结果里再筛，那你会在数据量上来之后遇到性能和正确性双重问题。选型时一定确认过滤能不能和检索条件一起下推。
（4）运维成本要算进总账。独立向量库意味着多一个要备份、要监控、要升级、要处理故障的服务。对小团队来说，这一块的隐性成本经常超过省下的检索时间。更详细的成本拆解思路，可以参考 AI Agent 成本怎么算、怎么省。
三个最容易踩的坑
坑一：换了嵌入模型，忘了全量重算向量。新旧向量混在同一个库里，检索结果会变得毫无规律——不是答错，而是「有时候对有时候莫名其妙」。这种问题最难查，因为代码没报错。规则很简单：嵌入模型版本变更必须全量重建，并且新旧两套不能共存于同一次检索。变更怎么留痕、怎么验证，可以参考 变更后验证清单怎么写。
坑二：把维度调高当成提升效果的万能钥匙。召回不准的根因通常是切片不合理、缺少关键词通道、或者文档本身内容就旧了，而不是维度不够。维度只是表达空间的大小，它不能凭空补上原文里没有的信息。顺便提一句，知识库效果不好的另一个常见根因是资料过期，处理方式见 知识库陈旧内容怎么巡检。
坑三：只做向量检索，不做引用校验。混合检索能提高「找得到」，但找得到不等于找对了。上线前应该固定一批问题做回归，并且要求答案必须带来源。谁可以被引用、谁不可以，站内另有一篇 引用白名单怎么设 讲得很细。
落地清单：六条
（1）先建验证集再选型。用二十到五十条真实问题加标准答案，任何模型和库的对比都跑同一套题。没有验证集的选型，本质上是凭感觉。
（2）嵌入模型先锁版本，再谈升级。把模型名、版本号、维度、切片长度写进配置文件并纳入变更记录，让「换了什么」永远可追。
（3）切片粒度跟着模型长度上限定，并对齐语义边界。宁可让片段带一点重叠，也不要把一句话从中间劈开。
（4）向量检索 + 关键词检索一起上。让编号、术语、专有名词有地方被精确命中。
（5）元数据从第一天就带全。来源、部门、生效时间、密级——后面想补，就得重新入库。
（6）把知识库当成有生命周期的资产。入库只是开始，增量更新、过期巡检、引用校验都要排进日常。完整的搭建流程可以参考 OpenClaw 怎么搭企业内部知识库，从入库到带引用的问答一条线走通。
优缺点说清楚
做得对的好处：召回准了，提示词不用再反复堆；答案能带来源，业务方敢用；后面换大模型时效果波动小，因为底座是稳的。
代价和局限：嵌入模型是「一次选型、长期绑定」的决定，改它的成本最高（要全量重算），所以前期验证不能省；混合检索会引入一套新的排序参数需要调；独立向量库对运维能力有要求，小团队上之前要想清楚谁来维护。
适合人群
适合：正在搭或准备重建知识库的团队；知识库已经上线但「经常答非所问、偶尔又答得很准」的项目；需要按权限、按生效时间做精细化过滤的企业场景。不适合：只做几十条 FAQ、内容几乎不变、用全文检索就能满足的场景——这时候上向量检索属于过度设计，先把文档写清楚更划算。
总结
嵌入模型和向量库，一条主线：先分清它们各自决定什么——嵌入模型决定语义空间的质量，向量库决定检索的速度与过滤能力；嵌入模型看中文效果、维度、长度上限、非对称检索和版本可锁定，向量库看规模门槛、混合检索、元数据过滤下推和运维成本；落地先建验证集、锁住版本、切片对齐语义、向量加关键词一起上、元数据带全、并把知识库当长期资产维护。一句心法：这一层选对了，上面的调优是锦上添花；选错了，上面的调优全是在给错误的结果化妆。
