【全文检索引擎】选型与阅读地图：决策树、RAG 回链与开放问题

本系列前 17 篇从 Lucene 段、BM25、IndexWriter 写到 Elasticsearch 分片、混合 kNN 与生产排障。读者最后常问一句：「我的场景到底该用哪一层？」——不是「ES 全球最快」，而是 倒排引擎、RDBMS GIN、列存全文、专用向量库、日志栈 在问题栈上的位置。本文给出 扩展决策树、站内阅读地图 与 仍开放的问题，作为全系列收束；不替代官方容量规划，不排名未实测吞吐。

本文是「全文检索引擎」系列第 18 篇（共 18 篇）。→ 系列目录

一、决策树（扩展版）

flowchart TD
  start["Need to find documents by text or vector?"]
  start -->|"no, only metrics/traces"| obs["Use metrics/traces stack<br/>out of scope"]
  start -->|"yes"| logGate["Primary workload: log analytics at TB/day?"]

  logGate -->|"yes, filter by labels + aggregate"| logsPath["Read observability/08<br/>Loki / CH / OpenObserve<br/>NOT default ES"]
  logGate -->|"no"| ftsGate["Need rich full-text + agg + NRT?"]

  ftsGate -->|"moderate scale, must stay in SQL TX"| pg["PostgreSQL GIN / tsvector<br/>见 PG kernel 16, 本系列 04"]
  ftsGate -->|"yes"| esGate["Dedicated search cluster OK?"]

  esGate -->|"no"| embed["Embedded Lucene / small OS single node<br/>本系列 01-10 库路径"]
  esGate -->|"yes"| hybridGate["BM25 + kNN same product?"]

  hybridGate -->|"yes, mostly text + some vector"| es["Elasticsearch or OpenSearch<br/>本系列 11-17"]
  hybridGate -->|"vector-dominant, billion-scale ANN"| vec["Dedicated vector engine<br/>vector-engine 01-18"]
  hybridGate -->|"OLAP text + heavy GROUP BY"| ch["ClickHouse text functions / inverted exp.<br/>analytics path"]

  es --> license["ES vs OS: license /托管<br/>见第 16 篇"]

相对第 15 篇「单引擎混合」，这棵树多了 日志主场景、SQL 事务同进程、向量主导、OLAP 聚合 四个分叉——任一轴翻转都可能推翻上一轮直觉。

1.1 边界表

表内 不填 虚假 QPS 数字；代价类型须映射到团队能力（是否会运维 shard、是否会调 GIN、是否有对象存储）。

1.2 PostgreSQL GIN：何时留在 SQL 里

postgresql-kernel/16 拆的是 GIN 倒排 在单进程内的页结构与 WAL。选型上，GIN 适合：

• 数据量 未 到需要独立搜索集群；
• 查询要与 JOIN、行级锁、同一快照 原子；
• 全文形态以 tsvector + 简单排序为主，而非复杂聚合仪表盘。

GIN 的 写放大 与 词典膨胀 在百万级以上全文会显现；此时不是「GIN 错了」，而是 问题栈长出了独立搜索 SLA——沿决策树迁到 ES/OS 或只把搜索副本外置。

1.3 ClickHouse：OLAP 文本而非搜索服务

ClickHouse 提供 tokenbf_v1、ngram 等 实验性/演进中 的全文索引能力（须查当前版本文档），强项仍是 列存扫描 + 聚合：

• 适合「日志已进 CH，偶尔 hasToken / 字符串函数过滤」；
• 不适合替代 ES 的 复杂 BM25 打分、短语查询、高亮、per-shard collector 细调（第 6、9 篇能力集）。

observability/08 中 知乎/B 站 ClickHouse 日志 实践属于这一类；勿与 商品搜索 混为同一选型。

二、最小故事：三类场景的落点

场景 A — 企业知识库 RAG：既要关键词命中规章编号，又要语义召回。应用层编排见 llm-infra；引擎层若 百万级段落、要强 BM25+过滤+聚合，ES/OpenSearch 单栈混合（第 15 篇）常见。若 向量十亿级、过滤选择度极低，应沿决策树转到 vector-engine，ES 只保留稀疏侧或外置。

场景 B — 订单库内商品名搜索：数据量在单库可承受范围，必须与订单 同一事务 可见。PostgreSQL tsvector + GIN（第 4 篇 FST 对照）足够；不应 为百万行商品单独上 ES，除非搜索团队与 DBA 分裂已成组织事实。

场景 C — 微服务 JSON 日志、每天数 TB、查询以 service+level 过滤再 GROUP BY 为主：这是 observability/08 的主场。默认 不是「为了可观测性上 ES」——除非故障排查明确要求亚秒级交互式全文且团队已有 ES 运维债。

三、「只要日志检索」：别默认 ES

observability/08 已按场景矩阵比较 Elasticsearch/OpenSearch、Loki、ClickHouse、OpenObserve：日志量、查询模型、存储成本、多租户 与 商品搜索 不是同一问题。本系列 18 篇钉的是 倒排引擎内核；当日志主路径是 标签选择器 + 流式聚合 时，应优先读该文决策矩阵，而非把 ES 当作可观测性默认后端。

flowchart LR
  logs["TB/day logs"]
  logs --> q1["Need interactive full-text on arbitrary JSON keys?"]
  q1 -->|"rare"| lokiCH["Loki / CH path<br/>observability/08"]
  q1 -->|"yes, team has ES ops"| esLog["ES/OS with strict mapping<br/>本系列 14、17"]

四、回到五个关键问题

五、站内阅读地图

flowchart LR
  arch["architecture/42<br/>system design"]
  storage["storage/29<br/>inverted intro"]
  subgraph series ["This series 01-18"]
    direction TB
    lib["01-10 Lucene core"]
    dist["11-14 ES layer"]
    endgame["15-18 hybrid / ops / select"]
    lib --> dist --> endgame
  end
  vec["vector-engine<br/>ANN internals"]
  frontier["db-frontier/08<br/>HNSW etc."]
  rag["llm-infra<br/>RAG app"]
  obs["observability/08<br/>logs"]
  pg["postgresql-kernel/16<br/>GIN"]

  arch --> lib
  storage --> lib
  frontier --> endgame
  vec --> endgame
  endgame --> rag
  obs --> endgame
  pg --> endgame

六、RAG 回链：应用与引擎分工

llm-infra 讲 chunk、embedding、重排与评测；本系列讲 BM25 如何落到 postings（第 6 篇）与 kNN 接口（第 15 篇）。分工表：

RAG 不要求 全栈 ES；但 误判「向量库可以替代一切稀疏召回」时，应回第 6 篇看 IDF 与短语查询在向量距离里 无直接对应。

七、学术谱系收束

争论仍活跃：learned sparse/dense 是否在生产替代 BM25（见 frontier 与工业实验，无统一共识）；统一段上向量+倒排 merge 代价（第 15 篇开放问题）——选型时按 可运维性 与 证据等级 决策，不用「AI 将统一一切」收尾。

八、开放问题（全系列）

1. Lucene 上向量与倒排的统一 merge 代价模型——缺 peer-reviewed 与生产阈值对照（第 15 篇）。
2. ES/OpenSearch API 与 Lucene 次版本漂移——跨发行版兼容须逐版验证（第 16 篇）。
3. 混合检索在极低选择度过滤下的召回——与 vector-engine/11、db-frontier/09 同构，全文栈上 knn+filter 的 \(k'\) 自适应无公开标准。
4. 日志 vs 搜索 index 的 mapping 纪律——observability/08 与第 14 篇动态 mapping 的治理能否模板化。
5. PG GIN 与 ES 双写的一致性——HTAP 式「搜索副本」无通用协议，组织级开放题。

8.1 后续阅读（按角色）

九、系列完成状态

实验台账（PLAN）中单节点 refresh_interval、explain 等实测可按需补强；正文机制不依赖未跑数字。

十、常见误解

误解一：上 RAG 就必须上 ES。 稀疏侧可用 PG GIN、甚至应用内小索引；向量侧常用专用引擎。ES 是 全功能倒排+可选 kNN 的一条路径，非唯一。

误解二：日志用 ES 是行业标准，因此可观测性默认 ES。 observability/08 明确 TB 级日志 下 Loki/CH 等往往更贴场景；ES 适合 强交互全文+聚合 且团队能承担成本。

误解三：ClickHouse 可以替代一切搜索。 CH 强在列存聚合与压缩；交互式短语搜索、复杂 scoring 与 ES 不同类，须按查询模型选型。

误解四：读完 18 篇就能替代官方 Reference。 本系列钉 机制与决策边界；版本升级、API 细节仍以 Lucene / ES / OpenSearch 官方文档为准。

十一、小结

三句话小结：

1. 选型是按问题栈选层：事务内全文 → GIN；富搜索+NRT → ES/OS；向量主导 → vector-engine；TB 日志 → observability/08——不是按产品热词。
2. RAG 横跨 llm-infra（应用）、本系列（BM25/kNN 接口）、vector-engine（ANN 内核）；缺一层会在召回或运维上踩坑。
3. 全系列 18 篇 已齐；从 系列目录 可按角色路径回看，开放问题留在 统一段 merge、跨发行版漂移、混合过滤召回 三条线上。

感谢读完本系列——倒排引擎内核层至此与 architecture/42、vector-engine、observability/08 的分工已对齐。

参考资料

1. 本系列第 1–17 篇及 index。
2. observability/08 日志栈、llm-infra、vector-engine、postgresql-kernel/16 GIN.
3. Robertson & Zaragoza, FnTIR 2009；Cormack et al., RRF, SIGIR 2009.
4. PLAN.md（实验台账与完成记录）。

返回 系列目录 ｜ 上一篇：生产排障