实战二：筛选 RAG 参考资料

Jev 放在哪里

用户问题 → 有权限的检索器取得候选 → Jev 判断相关性 → 代码保留合适段落 → 生成模型回答并注明出处。

Jev 不替你建立向量库，也不自动拥有所有文档权限。权限过滤应在检索时完成，不能先把无权读取的内容发给模型再删除。

每个候选保留稳定编号

{
  "query": "商品签收后多久可以申请退货？",
  "passages": [
    {"id": "returns-01", "text": "这里放已核实的退货政策原文"},
    {"id": "shipping-02", "text": "这里放运输时效说明原文"}
  ]
}

给每个候选提出“该段是否包含回答这个问题所需的信息？”这样的 Noul 问题；也可用定义清楚的 Score 量表。输出中的编号必须能回到原始文段，代码负责排序与数量限制。

相关，不等于支持结论

某段可能提到了退货，却没有具体天数。它与问题相关，但不一定支持“可在 30 天内退货”。可以独立验证回答中的主张是否有来源依据；证据不足时应说明无法确定，而不是补一个政策。

先建一个小型对照集

为同一批问题准备人工标注的相关段落，对比原检索器、加入 Jev 的排序，以及已有重排序方案。查看 Recall@k、答案证据、延迟和成本；不要只看个别看起来更顺的回答。

适合的后续扩展

政策问答、售前资料筛选、技术支持检索都可以从这个结构开始。每个场景必须重新检查权限、过期资料处理、引用链与没有足够资料时的回退。