知识工程进阶之二：切块、索引、Embedding 与 Reranker：检索不是只建向量库
很多 RAG 问题，不是模型不会答，而是你喂进去的候选材料一开始就选错了。
检索质量，常常比生成质量更决定最终体验。
先给结论
知识检索至少包含这几个环节：
- 切块
- 建索引
- 生成向量表示
- 检索召回
- 重排序
如果只做了“上传文档+向量搜索”，那通常只做了其中一半。
为什么切块很关键
chunk 不是机械切字数。
chunk 的目标是：
- 单块信息足够完整
- 单块不要塞太多无关内容
- 查询命中后，模型能直接理解
如果切得太碎：
- 上下文不完整
- 句子前后断开
如果切得太大：
- 噪声变多
- 排名更不准
- token 更贵
所以切块最怕“一刀切”。
更稳的做法是按语义边界切，而不是只看固定长度。
embedding 解决的是“像不像”
embedding 的价值，是把语义相近的内容拉近。
但它有天然局限：
- 对精确关键词不一定敏感
- 对版本号、型号、错误码这类内容不一定稳
所以很多真实系统里，光靠向量检索不够，还要配：
- 关键词检索
- 元信息过滤
- reranker
这也是为什么 OpenAI 的 file search 和很多工程框架里，都不是只做单一路径召回。
reranker 解决的是“谁更像真正该给模型看的内容”
召回阶段往往是“先多拿一些”。
reranker 再把这些候选按当前问题重新排序。
你可以把它理解成两层：
- 粗筛：先找一批可能相关的
- 精排：再决定最值得看的前几块
很多 RAG 效果不好，本质上不是没搜到，而是排在前面的不是最该给模型看的。
一个常见误区：向量库不是知识库本身
向量库只是其中一层。
它解决的是检索基础设施问题，不等于解决了：
- 资料质量
- 版本冲突
- 权威判断
- 上下文组装
如果把“建了向量库”误当成“知识系统完成”，后面几乎一定会返工。
一句带走
好的知识检索，不是把文件变向量，而是把“候选材料的质量”一步步做高。
切块、索引、召回、重排，缺一层，结果都可能发飘。