检索要能"先筛后搜"
只靠语义相似度，用户常遇到两类糟糕结果 ✗：过期的（三年前的方案 ✔）与不该看的（别的团队/客户的内容 ✔）。
解法是在检索入口加可筛选维度 ✔：时间、来源、类型、权限 ✔。
先筛后搜（filter-then-search）通常比"搜完再过滤"更准也更快 ✔ ——
尤其当筛选能把候选集缩小一个量级时 ✔。
一、四个必备筛选维度
- 时间：
published_at范围（"只看近一年" ✔）； - 来源/权威度：官方文档 / 内部规范 / 社区帖子 ✔（等级表人工维护 ✔，不要模型猜 ✔）；
- 类型：教程 / 规范 / 会议纪要 / 工单 ✔；
- 权限：谁能看哪些文档 ✔（这一条是硬约束，不是排序因素 ✔）。
二、权限必须做在检索层（不能只在展示层）
最常见的漏洞 ✗：先检索出全部，再在界面上隐藏无权内容 ✔ —— 但模型已经读过了 ✔，
它可能在答案里复述出来 ✔（这就成了越权泄露 ✔）。
正确做法：
- 检索时就带上权限过滤条件 ✔（在向量库/搜索引擎层的 filter ✔）；
- 权限变更要同步到索引 ✔（否则"刚收回权限"的文档还能被搜到 ✔）；
- 记录每次检索的权限判定结果 ✔（便于审计 ✔）。
三、筛选要"可发现、可解释"
- 界面上显式给出筛选器（时间、来源、类型 ✔），别藏在高级选项里 ✗；
- 结果里标注每个片段的来源与时间 ✔（让用户能自己判断 ✔）；
- 被筛选掉的内容给出提示（"另有 3 条较早的资料未展示" ✔），而不是静默丢弃 ✗。
四、三个常见坑
- 时间字段缺失 ✗ → 大量文档没有
published_at✔ → 先做元数据补全 ✔； - 筛选值不统一 ✗（"官方"有五种写法 ✔）→ 先做取值的归一化 ✔；
- 筛选把召回打到极低 ✗ → 要监控筛选后召回率 ✔（见检索回归那篇 ✔）。
五、落地顺序
- 先补元数据（时间、来源、类型 ✔）—— 没有元数据，筛选无从谈起 ✔；
- 再加权限过滤（安全优先 ✔，这一条不能等 ✔）；
- 然后加时间与来源筛选（用户最常用 ✔）；
- 最后做筛选的可见性与解释 ✔（含"被筛掉多少"的提示 ✔）。
一条判据
抽 10 个问题，只看检索层（不看最终答案 ✔），能否保证"无权内容根本没被取到" ✔？
不能，就说明权限做在了错误的位置 ✗。