实习经历（1）

1. 一开始为什么商城旅馆搜索结果大量为空

答：因为分词+100%匹配度，也就是说文档里面必须包括搜索分词。同时用户可能是输入的是地址，但是我的地址在索引里面是单独的一个address字段，所以就无法进行精确的文本匹配。

2. 你是如何通过调整分词策略来改善搜索效果的？

答：在索引阶段，对文档使用ik_max_word分词，保留更多的词项，在召回的时候，灵活切换分词方式，对用户输入先尝试ik_smart（精准切分），若召回为空再使用ik_max_word（模糊切分）,然后进行重拍，基础分：ES 默认的_score（词频、逆文档频率等计算的相关度）；业务分：根据酒店的业务属性加分，比如：评分高的酒店（score > 4.5）加 0.2 分，可预订的酒店（bookable: true）加 0.1 分，距离用户位置近的酒店（distance < 3km）加 0.3 分。同时设置最小得分限制，过滤低相关度数据。
对于地址类的是，建立独立的landmark 索引，存储地址中的地标信息（如 “中关村”“浦东机场”）。当文本召回为空时，先基于 landmark 索引匹配地标关键词。
landmark索引：

PUT /landmark
{
  "settings": {
    "number_of_shards": 1,
    "number_of_replicas": 1,
    "analysis": {
      "analyzer": {
        "ik_max_word": {
          "type": "custom",
          "tokenizer": "ik_max_word"
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "name": {
        "type": "text",
        "analyzer": "ik_max_word",
        "fields": {
          "keyword": { "type": "keyword" }
        }
      },
      "location": {
        "type": "geo_point"
      },
      "city": {
        "type": "keyword"
      },
      "province": {
        "type": "keyword"
      },
      "confidence": {
        "type": "float"
      },
      "source": {
        "type": "keyword"
      },
      "created_at": {
        "type": "date"
      },
      "updated_at": {
        "type": "date"
      }
    }
  }
}

1. name：地标名称，用 ik_max_word 分词，支持各种写法的匹配（如 “东方明珠塔”“东方明珠”）。
2. location：经纬度（geo_point），用于地理范围召回。
3. city/province：行政层级，用于过滤和优化召回范围。
4. confidence：匹配度（0~1），来自地图 API 或内部算法。
5. source：数据来源（如 baidu_map、manual）。
6. created_at / updated_at：时间戳，用于数据更新和淘汰策略。
   协作细节：

• 触发时机：landmark 索引不是主流程，而是兜底机制。
• 数据回流：百度地图 API 返回的地标会写入本地 landmark 索引，后续相同关键词直接命中，减少外部依赖和延迟。
• 范围召回参数：
  • 半径可以根据城市类型动态调整（例如一线城市 3km，二三线 5km）。
  • 结合 city 字段过滤，避免跨城市误召回。
• 重排策略：
  • 先用距离排序确保用户位置相关性。
  • 再叠加酒店评分、价格等业务权重做二次排序。

1. 同义词 / 形似词映射库
   ○ 手动维护单向映射关系（如 “麓枫”→“麗枫”、“维也”→“维也纳”），在用户输入时自动扩展查询词。
   ○ 实现方式：在查询阶段增加预处理层，将输入词与映射库匹配，生成扩展查询列表。
2. 同音词模糊匹配
   ○ 通过拼音转换（如 “酷点”→“kudian”、“酷电”→“kudian”），建立同音词关联，提升匹配概率。

○ 引入深度学习模型（如 BERT）进行语义理解，提升模糊词、同音词的智能联想能力。
○ 构建自动学习机制，通过用户搜索日志动态更新同义词库与分词规则。

3. 在优化过程中，你们如何评估分词策略和landmark机制的实际效果？除了召回率提升和无结果率下降，还关注哪些指标？能否介绍具体的验证方法？

1. 精确匹配率
   定义：召回结果中，酒店名称 / 地址与用户输入关键词的重合度（如 “上海外滩” 是否召回真实位于外滩的酒店）。
   计算：人工抽样 100 条查询，统计 “完全相关”“部分相关”“不相关” 的占比，重点看 “完全相关” 比例是否提升。
2. 点击率（CTR）
   定义：用户点击结果数 / 展示结果数。
   意义：如果分词策略或 landmark 机制召回的结果更相关，用户点击率会显著提升（反之，即使召回率高，点击率低也说明结果质量差）。
3. 平均点击位置（ACP）
   定义：用户点击的结果在列表中的平均位置（越小越好）。
   意义：如果重排策略有效，用户会更快找到满意结果，ACP 会降低。
4. 搜索修正率
   定义：用户首次搜索无结果 / 不满意后，修改关键词重新搜索的比例。
   意义：landmark 机制和分词优化的终极目标是减少用户 “二次搜索”，此指标直接反映搜索体验是否流畅。

4.在你优化ES搜索的实习项目中，是否遇到过与同事（比如产品经理、前端工程师）意见不一致的情况？你是如何沟通并推动技术方案落地的？请举例说明。

在落地 “landmark 地标机制” 时，我和产品经理就 “百度地图 API 调用时机” 产生了分歧：
我的技术方案：仅当本地 landmark 索引完全无结果时，才调用百度 API（减少外部依赖和延迟）。
产品经理的诉求：即使本地有结果，但匹配度低于 0.8，也要调用百度 API 做二次验证（担心本地数据过时导致位置不准）。

技术视角

频繁调用百度 API 会增加 200-300ms 的响应时间（当时我们的搜索性能要求是 “首屏加载≤500ms”），且 API 有调用配额限制，高并发时可能被限流。

解决方案

基于数据，我提出了 “分级触发” 策略：
本地匹配度≥0.7：直接用本地数据（覆盖 90% 以上场景，保证性能）。
0.5≤匹配度 < 0.7：异步调用百度 API，用本地数据先返回，后续用 API 结果更新本地索引（不阻塞用户，兼顾准确性）。
匹配度 < 0.5：同步调用百度 API（确保核心准确性，这类场景仅占 3%）。
产品视角：酒店搜索的核心是 “位置准确性”，如果因为本地数据过时（比如新地标未更新）导致召回的酒店离用户实际位置很远，会严重影响转化。