从检索到 RAG
切分、过滤、混合检索、RRF、重排与评测
本页解决的问题
先给结论「从检索到 RAG」要解决的关键问题是什么？
切分、过滤、混合检索、RRF、重排与评测
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
Embed Query
用写入时同一个模型编码问题。
Retrieve
租户/权限过滤 + Top-K 向量检索。
Rerank
精排、去重，并控制上下文 Token。
Generate
要求模型只依据证据回答并给出来源。
切分
按标题、段落和语义边界切 chunk，保留少量 overlap。太大噪声多，太小上下文断裂。
元数据
保存 source_id、版本、章节、租户、ACL 与更新时间。引用、过滤和删除都依赖它。
版本
内容或 Embedding 模型变化要重算；蓝绿 collection 切换可避免新旧向量混用。
| 方法 | 解决什么 | 注意 |
|---|---|---|
| 标量 Filter | 租户、权限、时间、语言约束 | 权限必须在检索阶段执行，不能只靠 Prompt |
| 向量 + 关键词混合检索 | 兼顾语义、产品型号、错误码等精确词 | 两种分数尺度不同，不宜直接相加 |
| RRF 融合 | 按排名融合多路结果 | 简单稳健；再用 reranker 精排候选 |
| Partition / TTL | 隔离热点或清理过期数据 | 属于扩展能力，先用清晰的 collection 与 filter 设计 |
「Retrieve」为什么能找到相关内容
「按标题、段落和语义边界切 chunk，保留少量 overlap。太大噪声多，太小上下文断裂」把检索问题从“把资料存起来”推进到“怎样找到真正相关的资料”。这一步决定了 RAG、推荐和以图搜图最后交给模型的输入质量。
相似度不是答案，召回之后还要核对
在「保存 source_id、版本、章节、租户、ACL 与更新时间。引用、过滤和删除都依赖它」对应的流程里，Embedding 负责把对象放到可比较的语义空间，近邻索引负责减少搜索范围，最终的回答仍然依赖召回片段是否覆盖问题、距离指标是否合适，以及内容有没有过期。
先区分找得到和找得准
把「内容或 Embedding 模型变化要重算；蓝绿 collection 切换可避免新旧向量混用」落成一次小测试：准备几条有明确答案的查询，记录召回的相关性、遗漏和无关结果，再决定是否需要换切分方式、索引或重排。
从「Retrieve」走到「Rerank」
「Retrieve」先把问题落在「租户/权限过滤 + Top-K 向量检索。 3」上；到了「Rerank」，讨论继续推进到「精排、去重，并控制上下文 Token。 4」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
检索系统也可以这样看：先确定什么算相关，再观察召回是否覆盖问题，最后检查排序、切分和时效性有没有把真正有用的内容挤出去。
- 「Retrieve」：租户/权限过滤 + Top-K 向量检索。 3
- 「Rerank」：精排、去重，并控制上下文 Token。 4
- 「最后的要点」：内容或 Embedding 模型变化要重算；蓝绿 collection 切换可避免新旧向量混用
最后的「最后的要点」把讨论落到「内容或 Embedding 模型变化要重算；蓝绿 collection 切换可避免新旧向量混用」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。