Elasticsearch Java 客户端

• 索引别名（alias）的概念
• 零停机重建的流程
• 别名切换与原子性

ES 的索引别名（alias）是索引的"逻辑名称"，可指向一个或多个索引，应用通过别名访问而非真实索引名。零停机重建流程：原索引 A 加别名 app；创建新索引 B（新的 mapping/分片）；并行写入 A 与 B（或从 A 重建数据到 B）；重建完成后，用"原子切换"把别名从 A 指向 B（_alias 或 POST /_aliases 的 remove+add 原子操作），删除旧索引 A。因为是原子操作，切换瞬间应用无感知，实现零停机。别名还支持多索引（如按月分片索引统一通过别名查询）、过滤别名（alias filter）等。别名切换的关键是"原子性"与"切换后数据一致性"。零停机重建是 ES 变更 mapping/分词等不可变配置的标准方案。

同名索引的 mapping 不可变是痛点，别名 + 原子切换解决"重建索引不中断服务"。关键在于"并行写入/重建 + 别名原子切换"。理解别名机制，是 ES 索引变更与升级的基础。

• keyword 与 text 类型的区别
• 分词器（analyzer）的作用
• 多字段（multi-fields）设计

ES 的 keyword 与 text 是两种核心字符串类型。keyword：不分词，作为整体存储，用于精确匹配、排序、聚合（terms/aggs），如 id、状态、标签；text：会分词，用于全文搜索（match），建立倒排索引，如标题、正文。分词器（analyzer）决定 text 如何被切词，包含字符过滤器（char filter）、分词器（tokenizer）、词元过滤器（token filter），如 standard（英文默认）、ik（中文）、n-gram（模糊）。配置：mapping 中为 text 指定 analyzer 与 search_analyzer（索引与查询可用不同分词器）。常见设计：一个字段用 fields 同时定义为 text（用于搜索）与 keyword（用于精确/聚合），如 "title": {"type":"text","fields":{"keyword":{"type":"keyword"}}}，满足"既搜索又聚合"的需求。理解 keyword/text 与分词器，是 ES mapping 建模的核心。

keyword 与 text 的本质区别是"是否分词"：keyword 精确整体、text 分词全文。多字段（fields）让同一字段兼顾搜索与聚合。分词器决定 text 的检索能力，是 ES 检索质量的基础。

• CDC（Change Data Capture）的概念
• 同步方案（binlog/日志）
• 近实时的延迟与一致性

CDC（Change Data Capture，变更数据捕获）把业务库的数据变更同步到搜索引擎，实现近实时检索。实现方式：一是基于 binlog 的 CDC（如 Canal/Debezium 监听 MySQL binlog，把增删改事件转发到 MQ 或直接写入 ES），实现毫秒到秒级近实时；二是应用双写（业务代码同时写库与 ES），简单但侵入重、易不一致；三是定时批量同步（低频、非实时）。近实时同步链路：业务库 -> binlog -> CDC 工具 -> 解析 -> MQ -> 消费 -> 写入 ES（用 bulk 批量）。关键点：增量同步（binlog 位置管理）、幂等写入（按业务主键 upsert）、失败重试（MQ 保证）、初始全量 + 增量（先全量建索引再增量追平）。一致性：CDC 是最终一致，需要处理删除（软删除/逻辑删除）、字段变更与延迟窗口。CDC 同步是"业务库与检索库解耦 + 近实时"的标准方案。

CDC 同步的核心是"监听 binlog + 增量解析 + 幂等写入"，实现近实时与业务解耦。理解"binlog 位置、幂等、全量+增量、最终一致"，是设计 ES 同步链路的关键。CDC 比双写更可靠、侵入更小。

• 倒排索引的结构与原理
• FST（有限状态机）压缩词典
• 检索效率与压缩

倒排索引（Inverted Index）是 ES 检索的核心：把文档中的词映射到"包含该词的文档列表"（posting list），检索时按词查找文档，避免全文扫描。结构：词典（term dictionary）+ 倒排列表（posting list，含文档 id、词频、位置）。FST（Finite State Transducer，有限状态转换器）用于压缩词典：Lucene 用 FST 表示词条，把公共前缀合并、共享状态，显著压缩词典体积（内存占用低），并支持高效的前缀查询与精确查找。FST 是"有序词典的压缩表示"，通过共享前缀减小存储。倒排索引解决"如何快速找文档"，FST 解决"词典如何压缩存储"。两者结合让 ES 在高召回与低内存间取得平衡。理解倒排索引与 FST，是理解 ES 检索性能的基础。

倒排索引是"词 -> 文档"的映射，FST 是"词典的压缩 + 高效查找"。FST 通过共享前缀压缩词典，是 Lucene 内存优化的关键。理解"倒排映射 + FST 压缩"，是理解 ES 检索原理与性能调优的基础。

• 双写的一致性问题
• binlog 最终一致方案
• 对账与补偿

业务库与 ES 双写（业务代码同时写 MySQL 与 ES）的一致性问题：双写非原子，先写库成功、写 ES 失败，或写 ES 成功、库失败，造成两侧数据不一致；且双写侵入业务代码、耦合高。基于 binlog 的最终一致方案：业务只写 MySQL，ES 通过监听 binlog 异步同步，天然解耦，库是唯一事实源，ES 最终一致。具体：binlog -> Canal/Debezium 解析 -> MQ -> 消费 -> 幂等写入 ES；binlog 保证"库的每次变更都被记录"，即使 ES 暂时失败也可重试补偿。最终一致需要处理：异步窗口内的短暂不一致（可接受）、失败重试（MQ 重试 + 死信）、对账（定期比对库与 ES 数据，修复差异）。相比双写，binlog 方案一致性更高（以库为准）、侵入更小，是主流方案。双写仅在无 binlog 场景（如部分非 MySQL 库）或强一致要求时使用。

双写的问题在于"非原子 + 侵入"，binlog 方案以"库为唯一事实源 + 异步同步"实现最终一致。理解"binlog 记录 + 幂等 + 对账补偿"，是设计库与 ES 数据一致性的关键。最终一致是权衡可用性与一致性的结果。

• 向量检索与标量过滤的联合
• pre-filter 与 post-filter
• 执行计划优化

ES 向量检索常需与标量过滤（如租户、分类、时间）联合执行，优化执行计划是关键。方案：pre-filter（先按标量过滤缩小候选集，再做向量相似度检索）与 post-filter（先做向量检索 top-k，再对结果做标量过滤）。pre-filter 更准（避免过滤后候选不足），但需要在过滤结果上建向量索引（或需重排）；post-filter 快但可能过滤后不足 k 个。优化手段：用 knn 查询的 filter 参数（ES 支持在 knn 查询内做 pre-filter，把过滤条件传给向量索引提高召回准确性）、结合 filter 与 script 权重、用 ANN 索引的过滤感知。ES 8.x 的 knn 支持 filter 参数做 pre-filter，避免"先取 top-k 再过滤导致结果不足"问题。执行计划优化核心是"过滤前移 + 向量与过滤的协同"，平衡召回率与查询延迟。

向量与标量联合的优化关键是"过滤位置"：pre-filter 保证召回但可能慢，post-filter 快但可能结果不足。ES knn 的 filter 参数实现过滤感知的向量检索。理解"过滤前移 + 召回/延迟权衡"，是向量检索优化的核心。

• 索引隔离与字段隔离的差异
• 隔离的隔离度与成本
• 选型考量

ES 多租户隔离有两种方案。索引隔离：每个租户一个索引（或索引组），数据物理隔离，查询天然隔离（按租户索引），性能互不影响、权限隔离清晰，但索引数量多、资源开销大、运维复杂（分片爆炸）。字段隔离：所有租户共享一个索引，在文档中用租户字段（tenant_id）区分，查询时过滤租户字段，资源利用率高、索引少，但隔离性弱（查询需过滤，大数据量过滤性能差）、权限需在查询层控制、单租户数据异常可能影响其他租户。选型考量：租户数量、数据规模、隔离要求、安全等级。租户少、数据量大、隔离要求高用索引隔离；租户多、数据规模小、隔离要求一般用字段隔离。也可用"路由 routing"（按租户路由到指定分片）折中。多租户隔离本质是"隔离强度 vs 资源成本"的权衡。

索引隔离与字段隔离是"强隔离高成本"与"弱隔离低成本"的权衡。索引隔离物理隔离但资源开销大，字段隔离共享但隔离弱。理解"隔离强度、资源、运维"三方权衡，是选型关键。

• 分片数与查询并行度
• 副本数与查询吞吐
• 性能调优的权衡

ES 的分片数、副本数与查询并发影响检索性能。分片数：一个索引分成多个分片（shard），查询会分解到所有分片并行执行（query-then-fetch），分片多并行度高、单分片数据量小、查询快，但分片过多会放大合并、路由与资源开销（分片爆炸）。副本数：副本（replica）是分片的冗余，可承担读流量（负载均衡），副本多查询吞吐高、可用性高，但写放大与磁盘占用大。查询并发：查询在分片间并行，并发受分片数、节点资源与查询复杂度影响。性能调优权衡：分片数要"够用不滥用"（按数据量与节点数合理设置，避免单分片过大或分片过多）；副本数按读多写少与可用性需求设置；查询并发受节点 CPU/内存限制，需配合限流与聚合优化。核心是"分片并行度 × 副本读扩展 × 节点资源"的平衡。

分片决定"并行度与单分片负载"，副本决定"读扩展与可用性"，两者共同影响查询性能。调优的关键是"分片够用不滥用、副本按读需求设"。理解三者的权衡，是 ES 性能调优的基础。

• 一致性校验的方法
• 对账机制
• 数据修复

检索（ES）与数据库的一致性校验与对账，用于发现并修复同步过程中的数据差异。校验方法：按业务主键比对库与 ES 的数据（如按 id 范围抽样比对关键字段、比对文档数量），发现不一致（缺失、多余、字段差异）。对账机制：定期跑对账任务，把库中数据与 ES 比对，列出差异清单；对缺失/差异的文档重新同步（从库拉取写入 ES）。对账频率：按一致性要求，可每天抽样或低峰全量。设计要点：对账要基于"库为事实源"、用批量与游标避免全量扫描压力、差异自动修复（补写、删除多余）、对账告警（发现持续不一致通知）。一致性校验与对账是"最终一致"方案的兜底，弥补 CDC 同步可能遗漏的差异。工程上"同步 + 对账修复"双保险，保证库与 ES 长期一致。

对账是"最终一致"方案的兜底保障：以库为事实源比对 ES，发现并修复差异。理解"抽样比对 + 差异修复 + 告警"，是保证库与 ES 长期一致的关键。同步负责"日常一致"，对账负责"兜底修复"。

• reindex 的概念
• 滚动切换流程
• 与别名配合

ES 的 reindex 是"把数据从一个索引复制到另一个索引"的操作，常用于变更 mapping、分词、分片数等不可变配置。滚动切换流程：创建新索引（目标 mapping/分片）；用 _reindex 把旧索引数据复制到新索引（可异步、可带查询过滤）；复制期间旧索引继续服务，新索引并行构建；完成后用别名切换（原子 remove+add 别名），把查询从旧索引切到新索引；确认无误后删除旧索引。滚动切换的关键：reindex 期间数据一致性（若同步写入，需处理增量）、切换的原子性（别名）、切换后的验证与回滚。reindex 适合"数据量不大、可离线重建"的场景；大数据量可结合"双写 + 增量"或"reindex 后追平"缩短切换窗口。滚动切换实现"零停机变更索引结构"。

reindex 滚动切换的核心是"新建索引 + 复制数据 + 别名原子切换"，实现零停机变更。关键在于"数据一致性 + 原子切换 + 验证回滚"。理解 reindex 流程，是 ES 索引结构变更的标准方案。

• 容量规划（数据量、分片、节点）
• 冷热分层架构
• 成本与性能平衡

ES 检索集群的容量规划与冷热分层，用于平衡成本与性能。容量规划：估算数据量（文档数 × 文档大小 × 副本数）、分片数（按数据量与节点数，避免单分片过大或分片过多）、节点数（按 CPU/内存/磁盘，通常数据节点与主节点分离，考虑查询 QPS 与写入吞吐）。冷热分层：把不同热度的数据放在不同节点（hot 节点内存大、磁盘快，warm 节点磁盘大、成本低，cold 节点冷存储），通过索引生命周期（ILM）自动把数据从热层迁移到冷层。热度分层依据：数据访问频率、时效性（近期数据热、历史数据冷）。收益：热数据用高性能节点保证查询延迟，冷数据用低成本存储降低总成本。设计要点：分片与节点规划要留有弹性与副本冗余、冷热迁移要平滑（避免影响查询）、冷数据可降级。冷热分层是"性能与成本"的经典平衡方案。

容量规划解决"分片与节点资源"，冷热分层解决"按热度降成本"。理解"按数据量算分片节点 + 按热度分层存储 + ILM 自动迁移"，是 ES 集群长期稳定与成本可控的关键。

• 索引模板的作用
• ILM 生命周期管理
• 模板与 ILM 的配合

ES 的索引模板（Index Template）用于自动化索引创建：定义新索引的 mapping、settings、别名等，当创建匹配模板的索引时自动应用（如按月/按类型分片索引）。ILM（Index Lifecycle Management，索引生命周期管理）管理索引的生命周期阶段：hot（热，活跃写入）、warm（温，只读查询）、cold（冷，低成本）、delete（删除），按策略自动迁移（如 hot 7 天 -> warm 30 天 -> cold 90 天 -> delete）。配合方式：索引模板为新索引设置 ILM 策略（index.lifecycle.name），新索引自动进入 hot 阶段，ILM 按策略自动迁移与删除。用途：配合按时间分片索引（date-based index），实现数据自动归档与清理，避免无限增长。模板保证"新索引结构一致"，ILM 保证"数据生命周期自动化"。两者配合是 ES 大规模数据管理的标准做法。

索引模板管"新索引怎么建"，ILM 管"索引怎么演进"。模板设置 ILM 策略，让新索引自动进入生命周期管理。理解"模板 + ILM + 按时间分片"，是 ES 数据自动归档与清理的关键。

• BM25 评分原理
• 相关性权重调整
• 自定义评分方法

BM25 是 ES 默认的相关性评分算法（TF-IDF 的改进）。评分核心：词频（TF，在文档中出现次数，但用饱和函数限制，避免高频词过度主导）、逆文档频率（IDF，越稀有的词权重越高）、文档长度归一化（doc length norm，短文档中命中词权重更高）。公式综合 TF、IDF 与文档长度，参数 k1（词频饱和）、b（长度归一化）可调。自定义权重方法：boost（字段或查询级提升，如标题字段 boost 高于正文）、function_score（自定义打分函数，如脚本、字段值、衰减函数）、constant_score（固定评分）、script_score（脚本自定义评分）。权重调整用于让"更重要的字段/词"在相关性中占比更高。BM25 提供基础相关性，自定义权重提供业务定制。理解 BM25 与权重机制，是调优检索相关性质量的核心。

BM25 用"词频饱和 + 稀有度加权 + 长度归一化"度量相关性，boost 与 function_score 提供业务化定制。理解"BM25 基础评分 + boost/function_score 定制"，是相关性调优的关键。

• from/size 深度分页的代价
• search_after 的原理
• 深度分页的适用场景

ES 的 from/size 深度分页在深页时代价巨大：ES 需要把每个分片的排序结果全量加载到内存并全局排序，才能取 from+size 的区间，深页（如 from=100000）会加载海量文档，内存与耗时飙升，且分片间数据变更会导致结果不稳定。search_after 替代：利用上一页最后一条的排序值作为"游标"，从该位置之后继续取下一页，避免深页的全局排序，适合"滚动翻页"（顺序往下翻）。search_after 需要配合 sort 字段（且排序值唯一，避免分页时数据变更导致不稳定）。适用场景：search_after 适合无限滚动/顺序翻页（如用户下拉加载）；from/size 适合浅页（前几页）与随机跳页。深度分页还可配合 scroll（快照，适合导出）与 PIT（point in time）。search_after 是深度分页的高效替代，避免深页的排序爆炸。

from/size 深页的代价是"全量排序"，search_after 用"游标续页"规避。理解"滚动翻页 vs 随机跳页"的差异，选择正确的分页方式。search_after 是深页优化的关键。

• scroll 的原理与场景
• PIT（point in time）的原理与场景
• 两者的差异

ES 的 scroll 与 point in time（PIT）都用于大批量/深度数据读取，但机制不同。scroll：在首次请求时创建数据快照（把搜索结果固化在内存），后续通过 scroll_id 分批拉取，适合"一次性导出大数据"（如全量同步、数据迁移），但快照在 scroll 期间不反映后续写入，且占用内存。PIT（point in time）：创建时间点快照，后续查询基于该时间点执行，配合 search_after 做稳定分页，且 PIT 会随写入更新（基于时间点的近似视图），适合"深度分页 + 数据变动场景下的稳定翻页"。差异：scroll 是"固化快照 + 批次拉取"，适合导出；PIT 是"时间点视图 + 游标分页"，适合滚动翻页。scroll 离线导出 API 已倾向于被 PIT + search_after 替代。理解差异，按"导出 vs 翻页"选型。

scroll 与 PIT 都是"快照式读取"，但 scroll 适合导出、PIT 适合翻页。scroll 固化快照、PIT 提供时间点视图且配合 search_after。理解"导出 vs 分页"的场景差异，是选型关键。

• bool 查询的 must/should/filter
• 各子句的语义（参与评分/不参与）
• 查询组合

ES 的 bool 查询组合多个子句，包含 must、should、filter、must_not。must：必须匹配的文档，且参与相关性评分（计算得分）；filter：必须匹配但不参与评分（只过滤，评分不变，可缓存，性能好）；should：至少匹配一个（在 must 存在时可选，用于提升相关性；无 must 时至少满足一个）；must_not：必须不匹配（过滤，不参与评分）。语义理解：must/filter 都是"必须满足"，区别是 must 计分、filter 不计分；should 用于"加分项"（可选的额外匹配）。组合示例：bool { must:[{match:title}], filter:[{term:status:"active"}], should:[{term:tag:"hot"}] }——标题匹配且计分、状态过滤、命中的标签加分。使用要点：纯过滤条件用 filter（性能好、可缓存），参与相关性的用 must，可选加分用 should。bool 是 ES 组合查询的核心。

bool 查询的关键是"must 计分、filter 不计分"的差异。filter 适合纯过滤（可缓存、性能好），must 用于参与评分的匹配，should 用于加分。理解各子句语义，是写高效 ES 查询的基础。

• bulk 批量写入
• refresh 策略（实时性）
• 写入性能与实时性权衡

ES 的 bulk 批量写入：把多条写入请求合并为一次 bulk 请求发送，减少网络往返与请求开销，用 Java API 的 BulkRequest 添加多个 index/update/delete 操作一次性提交，显著提升写入吞吐。refresh 策略：ES 写入后数据默认约 1 秒才 refresh（把内存中的段写到可搜索），即"近实时"（NRT）；refresh 可配置为 true（每次写入刷新，实时但性能差）、false（不刷新，靠默认）、interval（定时刷新）。性能权衡：频繁 refresh 会把写入资源消耗在刷新上，降低吞吐；延迟 refresh 提升写入吞吐但检索有延迟。批量写入 + 合理 refresh：批量减少请求数，refresh 按实时性需求设置（低实时场景可调大 refresh interval 或关闭）。bulk 管"请求合并"，refresh 管"实时性"，两者结合是写入性能调优的关键。

bulk 提升"请求效率"，refresh 控制"实时性"。批量写入减少请求，refresh 决定"写入多久可见"。理解"bulk 合并 + refresh 权衡"，是写入性能调优的核心。

• terms 聚合的构建
• date_histogram 聚合的构建
• 聚合结果解析

用 ES Java API Client 构建聚合：SearchRequest 的 aggregations 参数添加聚合。terms 聚合：AggregationBuilders.terms("by_category").field("category").size(10)，按字段的桶统计（如按分类统计文档数）。date_histogram 聚合：AggregationBuilders.dateHistogram("by_date").field("create_time").calendarInterval(DateInterval.DAY)，按时间间隔分桶统计（精确到天/小时，如按天统计文档数）。还可嵌套子聚合（如 subAggregation）。解析结果：通过 SearchResponse 的 getAggregations().get("by_category") 获取 TermsAggregate，遍历 buckets 取 key 与 docCount；date_histogram 用 DateHistogramAggregate 遍历 bucket。Java 构建聚合的意义：在代码中动态构造聚合查询并解析分桶结果，用于统计报表、数据可视化。核心是"构建聚合 + 解析 bucket"。

Java 构建聚合的要点是"AggregationBuilders 构建 + 响应解析 bucket"。terms 按字段分桶，date_histogram 按时间分桶。理解"构建 + 解析"流程，是 Java 中做 ES 聚合统计的基础。

• 两者的定位与演进
• API 风格差异
• 选型建议

ES 的两种 Java 客户端：RestHighLevelClient（旧版高级客户端，基于 Apache 风格 REST 封装，在 ES 7.x 广泛使用，ES 8 已弃用）与 Java API Client（新版官方客户端，ES 8 起推荐，基于 JSON 构建器与类型化请求）。差异：API 风格——RestHighLevelClient 用 SearchSourceBuilder 等构建器，Java API Client 用强类型 DSL（SearchRequest.of(b -> b...) 流式构建，类型安全）；维护状态——RestHighLevelClient 在 ES 8 弃用，Java API Client 是官方主推并持续演进；响应模型——Java API Client 用强类型响应类，RestHighLevelClient 用 SearchResponse 加类型转换。选型建议：新项目用 Java API Client（官方、类型安全、持续演进）；维护旧项目可继续用 RestHighLevelClient（但需考虑迁移）。Java API Client 是 ES 8+ 的 Java 访问标准。

Java API Client 是 ES 8 官方主推的替代品，类型安全；RestHighLevelClient 已弃用。选型核心是"是否新项目 + 是否追求官方支持"。理解 API 演进，是选型与迁移的基础。

• dense_vector 字段
• knn 检索（ANN 算法）
• 向量检索的配置

ES 的 dense_vector 字段类型用于存储稠密向量（如 embedding），可配置维度（dims）、相似度度量（cosine/dot_product/l2_norm）与索引（HNSW 等 ANN 索引）。knn 检索：通过 knn 查询或 knn_search 端点，在向量索引上做近似最近邻（ANN）检索，返回 top-k 相似向量对应的文档。配置要点：dense_vector 声明 index: true 与 similarity、dims 匹配模型向量维度；knn 查询传入查询向量与 k 值；可结合 filter（标量过滤）。向量检索用于语义搜索（RAG）、图像/文本相似、推荐。ES 的 HNSW 索引牺牲少量准确性换取检索速度（近似而非精确）。理解 dense_vector + knn，是 ES 向量检索的基础；向量检索与 BM25 结合可做混合检索（RRF）。

dense_vector 定义"向量字段与索引"，knn 做"ANN 检索"。理解"HNSW 近似索引 + 相似度度量 + 过滤"，是 ES 向量检索的核心。向量检索是语义搜索与 RAG 的基础。

• Embedding 模型选型与维度
• 维度对检索效果与成本的影响
• 降维与量化的取舍

Embedding 模型的选型与向量维度直接影响检索效果与成本。维度影响：维度越高，语义表达能力越强但存储与计算成本越高（存储 = 维度 × 4 字节 × 文档数，计算随维度增长）；维度越低，计算与存储省但可能损失语义区分度。模型选型：通用模型（如 text-embedding）维度适中，领域模型针对特定语义。降维（如 PCA、矩阵分解）与量化（如 PQ 乘积量化、标量量化 int8）用于大规模向量库降成本：降维压缩维度、量化压缩精度（每个向量字节数减少），代价是检索精度（召回率）下降。取舍：维度与字节数决定"成本"，量化/降维决定"精度 vs 成本"的平衡——精度要求高则保留高维/高精度，成本敏感则降维/量化。大规模向量库常用"量化 + 近似索引"（如 HNSW + PQ）在可控精度损失下大幅降低存储与计算。取舍核心是"检索精度 vs 存储/计算成本"。

向量维度的核心是"表达力 vs 成本"的权衡。降维与量化是"用精度换成本"的手段。理解"维度、量化、精度"三者的关系，是大规模向量库成本优化的关键。

• HNSW 的 m 与 ef_construction 参数
• 对连通性、召回率与延迟的影响
• ef_search 的精度/速度权衡

HNSW（Hierarchical Navigable Small World）是 ANN 索引，关键参数影响性能。m：每层节点的最大连接数，决定图的连通性——m 越大图越密集、连通性越好、召回率越高，但构建与查询遍历更多边、延迟升高、内存更大；m 过小图连通差、召回率低。ef_construction：构建阶段候选列表大小，决定搜索的候选数量——越大候选越多、图中插入越精细、召回率越高，但构建耗时与内存增加。ef_search：查询阶段候选列表大小——越大查询候选越多、召回率越高但查询延迟越高；越小查询快但召回率低。三个参数的关系：构建参数（m、ef_construction）决定图质量与索引构建成本，查询参数（ef_search）决定查询精度与速度。权衡：需要在构建/查询延迟与召回率间平衡，m 与 ef_construction 提升索引质量（构建阶段），ef_search 在查询时动态权衡精度与速度。理解这三个参数，是调优 HNSW 检索质量与延迟的关键。

HNSW 的 m 决定图连通性，ef_construction 决定构建质量，ef_search 决定查询精度。三者是"召回率 vs 构建/查询延迟"的权衡旋钮。理解"构建参数定质量、查询参数定速度"，是 HNSW 调优的核心。

• 两者的分叉来源
• 兼容性与差异
• 选型考量

OpenSearch 是 Elasticsearch 的开源分叉（fork）：2021 年 Elasticsearch 从 Apache 2.0 改为 SSPL/Elastic License 后，社区基于 ES 7.10 分叉出 OpenSearch，由 AWS 主导。兼容性：OpenSearch 保持对 ES 7.10 的 API 兼容（大部分 ES 7.x 客户端可迁移），后续版本各自演进，差异逐渐扩大。差异：许可证（OpenSearch 是 Apache 2.0，ES 是 SSPL/Elastic License）、版本演进（ES 8.x 取消 type、推出 knn 等，OpenSearch 有自己的 k-NN 插件与安全插件）、功能（ES 的向量检索、跨集群等与 OpenSearch 的 k-NN/Security 插件实现不同）。选型考量：许可证合规（Apache 2.0 更宽松）、云厂商支持（AWS 支持 OpenSearch）、功能需求（对比两边特性）、迁移成本。多数场景两者 API 兼容，选型取决于许可证、生态与功能。理解分叉背景与差异，是选型与迁移的基础。

OpenSearch 与 ES 的分叉源于许可证，兼容 7.10 但各自演进。选型考量"许可证、云支持、功能差异"。理解分叉背景，是评估兼容性与迁移成本的关键。

• OpenSearch k-NN 插件
• 支持算法（HNSW/IVF）
• 向量检索配置

OpenSearch 的 k-NN 插件提供向量检索能力，支持欧氏距离、余弦相似度等度量，以及 HNSW、IVF（Inverted File）等 ANN 算法。配置：字段类型用 knn_vector（声明维度），索引设置 index.knn: true 与算法（knn.space_type 相似度、knn.engine 算法引擎如 nmslib/faiss/lucene、knn.ef_search/knn.m 等 HNSW 参数）。查询：knn 查询传入 vector 与 k，或用 nearest_neighbor 在脚本中做向量检索；可结合 filter 与布尔查询。OpenSearch 的 k-NN 与 ES 的 dense_vector+knn 功能类似（都是向量检索），但实现与 API 不同（OpenSearch 用 knn_vector、ES 用 dense_vector）。用途：语义搜索、推荐、图像/文本相似。理解 k-NN 插件的配置（字段、算法、参数），是 OpenSearch 向量检索的基础。

OpenSearch k-NN 插件的核心是"knn_vector 字段 + HNSW/IVF 算法 + knn 查询"。理解其与 ES 的 API 差异（knn_vector vs dense_vector），是向量检索选型与迁移的关键。

• 安全插件的功能
• RBAC（基于角色的访问控制）
• 权限与认证

OpenSearch 的安全插件（Security Plugin）提供认证、授权与加密等安全能力。认证：支持内置用户、LDAP、Active Directory、SAML、OIDC 等身份认证。RBAC（基于角色的访问控制）：把权限（对索引/集群/文档的读写权限）绑定到角色，角色绑定到用户，实现"用户 -> 角色 -> 权限"的授权模型。权限粒度：索引级（能否读写某索引）、集群级（管理操作）、文档级（DLS，文档级安全性）、字段级（FLS，字段级安全性）。实现：配置 roles.yml 定义角色与权限，internal_users.yml 定义用户，roles_mapping.yml 把用户映射到角色，或用 REST API 管理。安全插件让 OpenSearch 支持多租户隔离与访问控制。RBAC 的核心是"最小权限"：按角色分配所需权限，避免越权。理解认证与 RBAC 模型，是 OpenSearch 安全治理的基础。

OpenSearch 安全插件的 RBAC 是"用户-角色-权限"模型，支持索引级/文档级/字段级权限。理解"认证 + 授权 + 加密"与 RBAC 粒度，是安全治理与多租户隔离的关键。

• 检索质量与回答准确性的关系
• 检索质量的关键因素
• 提升检索质量的手段

RAG（检索增强生成）中，检索质量直接决定回答准确性：如果检索到的上下文不相关或不完整，LLM 生成的回答就会错误或缺失关键信息（"垃圾进垃圾出"）。检索质量的关键因素：召回率（是否找到相关文档）、相关性排序（相关文档是否排前）、文档切分质量（chunk 是否语义完整）、检索方式（关键词/向量/混合）。提升手段：优化文档切分（按语义切块，避免跨段截断）、用混合检索（向量 + 关键词 + RRF 融合）、选择好的 embedding 模型与向量检索、重排序（ReRank 精排）、元数据过滤（时间/类型/权限过滤）、合理设置 top-k 与阈值。回答准确性受"检索相关性 + 生成质量"共同影响，检索是前端基础。理解"检索质量决定回答质量"，是 RAG 系统优化的核心。

RAG 的瓶颈常在"检索"而非"生成"。检索质量由召回、排序、切分、检索方式共同决定。提升检索质量是提升回答准确性的关键。理解"检索为生成提供上下文"，是 RAG 优化的核心。

• 中文分词的特点
• IK 分词器的作用
• 中文检索召回的优化

中文分词是中文检索的关键，因为中文没有空格分词，需专门的分词器。IK 分词器是常用的中文分词器，支持细粒度与智能分词模式，能识别常用词、专有名词与自定义词典。中文检索召回的优化：选择合适分词器（IK 支持扩展词典与自定义词典，可加入业务术语、人名、地名提升分词准确度）、配置同义词（同义词词典扩展召回，如"电脑"与"计算机"）、优化分词模式（智能分词减少过切分、细粒度提高召回）、结合 n-gram 抓取（避免未登录词漏召回）。优化目标：提升"召回率"（让相关文档被检索到）与"相关性"（分词准确让匹配更准）。IK 的词典配置（IKAnalyzer.cfg.xml 自定义词典）与同义词扩展，是中文检索召回优化的核心手段。中文分词的准确度直接影响检索质量。

中文分词的核心是"词典 + 模式 + 同义词"。IK 的自定义词典与同义词扩展提升分词准确度与召回。理解"分词质量决定中文检索质量"，是中文检索优化与召回提升的关键。

• 混合检索（BM25 + ANN）
• RRF（Reciprocal Rank Fusion）融合
• 混合检索的收益

混合检索结合关键词（BM25）与向量（ANN）两种检索，取长补短：BM25 擅长精确关键词匹配（如专有名词、ID），ANN 擅长语义相似（如同义、语义理解）。RRF（Reciprocal Rank Fusion，倒数排名融合）是融合两种检索结果的方法：对每个文档在各自检索结果的排名取倒数（1/(k+rank)），两路得分相加，按总分排序，得到融合后的结果。RRF 的优点：不依赖各路的评分尺度（BM25 与向量相似度范围不同），只依赖排名，鲁棒且简单。混合检索收益：兼顾精确匹配与语义入口，提升召回与相关性；当关键词检索无结果时向量检索兜底，反之亦然。ES 支持 rrf 参数（retriever）融合 BM25 与 knn 结果。混合检索是 RAG 与语义检索的主流方案。

混合检索的"融合"是核心，RRF 用"排名倒数"融合两路结果，天然适配不同评分的检索。理解"BM25 精确 + ANN 语义 + RRF 融合"，是混合检索的关键。

• 亿级文档的分片规划
• 路由（routing）策略
• 查询与写入的性能

大规模文档（亿级）的 ES 分片与路由策略影响性能与集群健康。分片规划：按总数据量与节点数计算分片数，避免单分片过大（如每分片 30-50GB 上限）或分片过多（分片爆炸）；亿级文档通常需要较多分片与足够节点，节点数按分片数与资源估算。路由策略：用 routing 参数把文档按业务键（如 user_id、tenant_id）路由到固定分片，同一业务键的文档落在同一分片，查询时按 routing 只查对应分片（减少查询范围、提升性能）；写入时按 routing 保证相关文档聚簇。收益：按路由聚簇减少跨分片查询、提升单租户/单用户查询性能；代价：路由不均衡会导致热点分片。设计要点：分片数"够用不滥用"、路由按高频查询维度、监控分片负载均衡。大规模文档的分片与路由是"容量 + 查询性能"的平衡。

分片决定"数据分布与查询并行"，路由决定"数据聚簇与查询范围"。按业务键路由聚簇提升查询性能但需防热点。理解"分片规划 + 路由聚簇"，是亿级文档 ES 性能的关键。

• top-k 截断
• 多样性打散（结果去重/分类均衡）
• 用户体验与相关性平衡

检索结果截断（top-k）与多样性打散用于提升结果质量与用户体验。top-k 截断：检索只返回最相关的 k 条（如 k=10），避免高相关性结果被淹没、控制响应数据量；k 值按场景选择（列表页多、精确搜索少）。多样性打散：避免结果过于集中于单一来源/分类，通过分类限制（每类最多 n 条）、来源去重（同一来源不连续出现）、标签均衡（不同标签分布）让结果更多样。实现：collapse（按字段折叠去重）、terms 聚合后按分类配额、自定义打分（对多样目标加分）。平衡：top-k 保证"相关性"，打散保证"多样性"，两者需权衡——相关性优先需避免过度打散降低精度，多样性优先避免单一化。设计目标是"相关性 + 多样性"的合理组合，提升用户体验与覆盖率。

top-k 截断管"相关性"，打散管"多样性"。过度截断丢失覆盖，过度打散损失精度。理解"截断 + 打散"的平衡，是检索结果质量优化的关键。

• pre-filter 与 post-filter 的概念
• 两者的差异与性能
• 适用场景

混合检索的 pre-filter 与 post-filter 指标量过滤在向量/关键词检索中的位置。pre-filter：先按标量条件（如租户、分类、时间）过滤出候选集，再做向量/关键词检索，保证检索只在符合条件的文档内进行，召回准确（不会因过滤后不足 k 条），但过滤开销与候选集构建可能降低性能。post-filter：先做向量/关键词检索取 top-k，再对结果做标量过滤，简单快速，但可能过滤后不足 k 条（如 top-k 中很多被过滤掉），导致结果不足。差异：pre-filter 召回更准但可能慢，post-filter 快但可能结果不足。适用场景：标量过滤条件严格（如多租户必需）用 pre-filter（保证召回准确）；过滤条件宽松、检索结果充足时可用 post-filter（性能优先）。ES 的 knn 支持 filter 参数做 pre-filter（过滤感知），是混合检索的推荐方式。选择依据是"过滤严格度 vs 性能"。

pre-filter 与 post-filter 的差异是"过滤位置：检索前 vs 检索后"。pre-filter 保证召回准确，post-filter 追求性能但可能结果不足。理解"过滤前置 vs 后置"的权衡，是混合检索过滤优化的关键。

• 混合检索的可观测指标
• 召回率与延迟分解
• 监控与优化

混合检索的可观测性用于评估与优化检索质量，核心指标是召回率与延迟。召回率（Recall）：相关文档被检索到的比例，评估"是否有漏检"；可结合标注集（ground truth）或在线反馈（点击/转化）评估。延迟分解：把混合检索的总延迟拆解为各阶段耗时——BM25 检索耗时、ANN 向量检索耗时、RRF 融合耗时、过滤/打散耗时、重排耗时，定位瓶颈（如向量检索慢、融合阶段慢）。可观测手段：在检索链路埋点（各阶段耗时、各路召回数、融合后 top-k 数）、日志记录查询参数与结果统计、监控召回率与延迟分布（P50/P99）。优化：根据延迟分解优化瓶颈阶段（如向量索引调参、缓存）、根据召回率改进检索策略（如调整混合权重、重排）。混合检索可观测是"数据驱动优化检索"的基础。

混合检索可观测的核心是"召回率评估质量 + 延迟分解定位瓶颈"。理解"各阶段耗时 + 各路召回数"的埋点，是优化混合检索的关键。可观测让检索优化有数据依据。

• ReRank 的概念
• 重排序的模型与方法
• 精度提升的机制

重排序（ReRank）在混合检索的召回阶段之后，对召回结果做精细化重排，提升精度。机制：混合检索（BM25 + ANN）先召回较宽泛的候选集（recall 阶段，追求高召回），ReRank 用更强大的模型（如交叉编码器 cross-encoder、LLM 重排）对召回结果逐条精算相关性，重新排序，把真正相关的排前面（precision 阶段，追求高精度）。两阶段：召回（快、宽、召回率高）+ 精排（慢、准、精度高），兼顾"召回广度"与"排序精度"。ReRank 开销高于召回（逐条计算），所以只对 top-k 候选（如 100 条）重排而非全量。提升精度的机制：ReRank 模型能理解上下文语义（交叉编码比双编码的向量检索更准），纠正召回阶段的相关性排序偏差。重排序是"召回 + 精排"两阶段检索的最后一环，显著提升 RAG 与搜索的精度。

ReRank 是"召回 + 精排"两阶段检索的精排环节：用强模型对召回 top-k 精算相关性，提升精度。理解"宽召回 + 准精排"的机制，是 RAG 与搜索精度优化的关键。