搜索与检索：从数据库镜像到证据引擎¶
搜索解决的不是“数据库里有没有”，而是“用户能不能高效找到”。在 RAG 时代，搜索更进一步成为了大模型的证据引擎。
1. 检索维度的四象限¶
不要把所有搜索请求混为一谈。第一步是识别请求的工程本质：
| 类型 | 目标 | 核心技术 | 关注点 |
|---|---|---|---|
| 查状态 | 确认权威事实 | 数据库 B-Tree | 事务、准确性 |
| 找内容 | 关键词/标题匹配 | 倒排索引 (ES) | 分词、BM25 评分 |
| 找相似 | 语义相近/意图理解 | 向量检索 (Vector) | Embedding、HNSW |
| 找证据 | 支撑模型回答 | RAG 检索 | Rerank、权限收束 |
2. 索引链：从写入到“可见”¶
数据库写入成功（COMMIT）仅代表数据进入了持久化层，不代表其“可搜”。
- 异步索引化：文档正文需经过
分词 -> 过滤 -> 构建 Segment的过程。这是一个典型的异步流水线，通常由 MQ 驱动。 - Refresh 延迟：在 Lucene/ES 体系中，数据写入内存 Buffer 到变为可查询状态（Refresh）存在秒级延迟。工程直觉：如果详情页能看但搜索不到，首选检查索引刷新频率而非查询逻辑。
- Segment 合并：大量碎片写入会拖慢查询。后台合并（Merge）是资源消耗大户，需平衡写入吞吐与查询 P99。
3. 召回模式：精确与模糊的博弈¶
- 倒排索引 (Keyword)：解决编号、术语、错误码等“稀疏信号”。它是 RAG 系统不幻读的底线。
- 向量检索 (Semantic)：解决“同义词”和“模糊描述”。它是处理自然语言交互的上限。
- Hybrid Search (混合检索)：工业界标准做法是 RRF (Reciprocal Rank Fusion)。将关键词与向量得分加权合并，防止向量模型在处理“工号”、“日期”等强特征时失效。
4. 检索层的“影子副本”与权限¶
搜索索引通常包含部分业务元数据（租户、权限标签）。
- 权限收束：严禁仅靠模型在 Prompt 里过滤。检索层必须在 API 侧强制注入
TenantID和AccessScope。 - 版本一致性：新版文档发布后，索引别名（Alias）的切换必须原子化，否则会出现搜索结果指向已删除旧文档的“僵尸链接”。
5. 排查顺序：第一反应¶
- 查索引链状态：异步 Worker 是否积压？Refresh 任务是否正常？
- 查查询解析（Query DSL）：解析后的分词是否正确？权重（Boost）分配是否导致了噪音干扰？
- 查召回覆盖率：是关键词搜不到，还是向量找偏了？（检查分词器与 Embedding 模型）。
- 查资源瓶颈：Shard 分片是否过大导致查询长尾？JVM 堆内存是否因为缓存过大而频繁 FGC？
结论： 搜索层不是数据库的镜像，是业务真相的“索引投影”。好的检索架构是先分清精确与模糊的边界，再通过异步流水线守住数据时效性。