搜索与检索：从数据库镜像到证据引擎¶

搜索层解决的核心问题不是"数据库中是否存在目标数据"，而是"用户能否高效定位到所需内容"。在 RAG 架构中，检索系统进一步承担了大模型证据引擎的角色——召回质量直接决定模型生成的事实可靠性；召回失败则模型只能依赖自身参数化记忆，幻觉率显著上升。

不同的检索请求在工程本质上存在根本性差异。混用技术栈会导致要么过度工程化，要么召回质量不达标：

类型	目标	核心技术	关注点	典型失效表现
查状态	确认权威事实	数据库 B-Tree / 联合索引	事务、准确性	N/A（确定性查询）
找内容	关键词/标题匹配	倒排索引（ES）+ TF-IDF/BM25	分词、相关性评分	分词器不匹配导致精确术语搜不到
找相似	语义相近/意图理解	向量检索（ANN: HNSW, IVF-PQ）	Embedding 质量、距离度量	向量模型对结构化特征（工号、日期）失效
找证据	支撑模型回答	RAG 混合检索 + 稠密 Rerank	召回率、权限收束	召回证据不全或冲突证据未被过滤

数据库 COMMIT 成功仅表示数据进入持久化层，并不意味着其对检索层可见。写入与"可搜索"之间存在异步索引化的延迟链路。

异步索引化流水线：文档正文需经过 分词 → 停用词过滤 → 构建 Segment 的处理流水线，通常由 MQ 驱动异步完成。索引构建过程中涉及分析器（Analyzer）选择、自定义词典加载和字段映射（Mapping）定义，任何一环配置不当都会导致召回质量下降。
Refresh 延迟与可见性窗口：在 Lucene/ES 体系中，数据写入内存 Buffer 至变为可查询状态（Refresh）存在秒级延迟（默认 refresh_interval=1s）。当出现"详情页数据可见但搜索不到"的现象时，应优先排查索引刷新频率，而非查询逻辑本身。该参数控制着写入吞吐与检索可见性之间的时延折中——降低 refresh_interval 可提升实时性，但会增加 I/O 压力和 Segment 碎片化。
Segment 合并（Merge）：大量小批写入产生的碎片化 Segment 会降低查询性能（每次查询需遍历更多 Segment）。后台合并过程是 CPU 和 I/O 资源的消耗大户。合并策略的选择直接影响写入吞吐与查询 P99 之间的平衡。

倒排索引（Keyword 检索）：基于分词后的 Term 精确匹配，通过 TF-IDF/BM25 评分排序。针对编号、术语、错误码等稀疏离散信号具有高精度，是 RAG 系统防止幻读的基础保障。当模型需要引用特定条款编号或精确数值时，倒排索引是唯一可靠的召回路径。
向量检索（Semantic 检索）：将文本通过 Embedding 模型映射为高维向量，基于余弦相似度（Cosine）或欧氏距离（L2）进行近似最近邻（ANN）搜索。针对同义词替换与模糊描述等自然语言交互场景具备优势。但向量模型对结构化特征（工号、日期、金额等）的表征能力有限，易产生"语义正确但事实错误"的召回。
混合检索（Hybrid Search）：工业界标准实践是 RRF（Reciprocal Rank Fusion）——将关键词检索与向量检索的排名进行倒数融合加权：

\[\text{RRF Score}(d) = \sum_{r \in \text{ranklists}} \frac{1}{k + \text{rank}_r(d)}\]

其中 \(k\) 为平滑常数（通常取 60）。混合检索可有效防止纯向量模型在处理工号、日期等强特征时的语义漂移失效。

搜索索引通常包含部分业务元数据（租户标识、权限标签），构成业务真相的"索引投影"。权限控制必须在检索层硬性执行，不可依赖上层业务逻辑的事后过滤。

前置过滤（Pre-Filtering / Pushdown Filter）：在向量召回阶段，将租户 ID、部门权限、生效状态等元数据作为约束条件与向量相似度计算同步执行。若采用召回后过滤（Post-Filtering），极易因高维召回结果被大面积权限过滤剔除，造成严重的召回空洞（Recall Vacuum）——请求了 Top-20，过滤后只剩 3 条，模型的证据基础严重不足。
版本一致性与原子切换：新版文档发布后，索引别名（Alias）的切换必须以原子操作完成。实践中常用 Blue-Green 索引策略：新版本索引构建完成后，将 Alias 从旧索引原子切换至新索引，旧索引延迟删除。若切换非原子，则可能出现搜索结果指向已删除旧文档的"僵尸链接"问题。

检索层的架构选型应随数据规模与业务复杂度分阶段演进：

阶段一——混合单体方案：业务起步期，推荐使用 pgvector 等数据库扩展。在同一关系数据库内存储业务结构化元数据与高维向量，实现事务级一致性，消除多库同步负担。适用于数据规模在百万级以下、并发压力中等的场景。
阶段二——专用检索层分离：数据规模达千万级且并发度高时，引入独立的 Elasticsearch / OpenSearch 承载全文检索，引入 Milvus / Pinecone 承载专业向量检索，实现读写算力的物理隔离。此阶段需额外建设索引同步管线（通常基于 MQ），并承担多存储系统间的最终一致性治理成本。

查索引链状态：异步索引 Worker 是否存在积压？Refresh 任务是否正常执行？Mapping 变更是否导致新文档字段未被正确索引？
查查询解析（Query DSL）：分词结果是否符合预期？权重（Boost）分配是否引入了噪音干扰？是否存在分析器（Analyzer）与写入时不一致的情况？
查召回覆盖率：是关键词无法命中（分词器配置问题），还是向量检索发生了语义漂移（Embedding 模型质量或维度选择问题）？Hybrid Search 中两路召回的权重是否合理？
查资源瓶颈：Shard 是否过大导致查询长尾？JVM 堆内存是否因 Field Data 缓存过大而频繁触发 Full GC？Segment 数量是否过多导致查询遍历开销过大？

核心结论： 搜索层是业务真相的索引投影，而非数据库的实时镜像。健壮的检索架构以精确/模糊边界的清晰划分为前提，以异步索引流水线维护数据时效性，以检索层的权限硬约束作为多租户安全的最终防线，并通过混合检索与 Rerank 的多阶段过滤实现召回质量与计算成本的工程平衡。