Azure认知搜索：基于拼接字段实现用户姓名多形式建议方案咨询

针对你需要支持名、姓及任意顺序全名搜索/建议的需求，结合你提到的MergeSkill失败、同义词表无法使用的情况，以下是几个可行的方案，按优先级排序：

方案一：修复MergeSkill生成全名，结合跨字段搜索/建议 #

这是最直接的方案，先解决MergeSkill的问题，再利用Azure认知搜索的跨字段能力覆盖所有匹配场景。

1. 排查并修复MergeSkill配置 #

MergeSkill失败通常是因为输入字段映射错误或输出未正确关联到索引字段。以下是正确的技能配置示例（假设Cosmos DB中用户姓名字段为firstname和lastname）：

{
  "@odata.type": "#Microsoft.Skills.Text.MergeSkill",
  "name": "merge-full-name",
  "context": "/document",
  "inputs": [
    {
      "name": "text",
      "source": "/document/firstname"
    },
    {
      "name": "text",
      "source": "/document/lastname"
    }
  ],
  "outputs": [
    {
      "name": "mergedText",
      "targetName": "user_full_name"
    }
  ]
}

同时确保在索引器的字段映射中，将/document/user_full_name映射到索引的user_full_name字段，且该字段设置为searchable: true、suggestable: true。

2. 配置跨字段搜索/建议 #

• 搜索请求：使用searchFields参数指定同时搜索user_first_name、user_last_name、user_full_name三个字段，查询类型设为full以支持短语匹配：

  search=Doe John&queryType=full&searchFields=user_first_name,user_last_name,user_full_name
  

  这样无论输入是单个名、单个姓、名+姓还是姓+名，都会在三个字段中匹配，返回对应的用户。
• 建议器配置：创建建议器时包含这三个字段，确保建议能从所有字段中生成：

  {
    "@odata.type": "#Microsoft.Azure.Search.Suggester",
    "name": "user-suggester",
    "searchMode": "analyzingInfixMatching",
    "sourceFields": ["user_first_name", "user_last_name", "user_full_name"]
  }
  

优缺点：配置简单，依赖内置能力，维护成本低；性能开销对于20k用户量级完全可控。

方案二：使用自定义Shingle分析器处理姓名组合 #

如果不想依赖MergeSkill，可以通过自定义分析器自动生成姓名的单字和组合形式，覆盖所有匹配场景。

配置自定义分析器 #

创建包含Shingle Token Filter的自定义分析器，该过滤器会将姓名拆分为单字词和双字词组合（如John、Doe、John Doe）：

{
  "analyzers": [
    {
      "name": "name-combo-analyzer",
      "@odata.type": "#Microsoft.Azure.Search.CustomAnalyzer",
      "tokenizer": "standard",
      "tokenFilters": [
        "lowercase",
        {
          "@odata.type": "#Microsoft.Azure.Search.ShingleTokenFilter",
          "name": "name-shingle",
          "minShingleSize": 2,
          "maxShingleSize": 2,
          "outputUnigrams": true
        }
      ]
    }
  ]
}

将索引中的user_full_name（或直接拼接名和姓的字段）的analyzer设置为这个自定义分析器。

处理反向顺序匹配 #

为了支持Doe John这类反向输入，可以额外添加一个包含Reverse Token Filter的分析器，或者在搜索时将查询字符串反转后再搜索。例如输入Doe John时，同时搜索原字符串和反转后的John Doe。

优缺点：无需数据预处理，直接通过分析器生成匹配项；但自定义分析器配置稍复杂，反向顺序需要额外处理。

方案三：构造布尔查询实现多维度匹配 #

如果无法修改索引或技能，可以通过构造布尔查询，覆盖所有可能的匹配场景：

对于输入的查询字符串（如Doe John），拆分后生成以下几个匹配条件，放入bool查询的should子句：

• 匹配user_first_name包含Doe或John
• 匹配user_last_name包含Doe或John
• 匹配user_full_name为短语Doe John
• 匹配user_full_name为短语John Doe

示例查询结构：

{
  "queryType": "full",
  "search": "*",
  "filter": "",
  "query": {
    "bool": {
      "should": [
        {"match": {"user_first_name": "Doe John"}},
        {"match": {"user_last_name": "Doe John"}},
        {"match_phrase": {"user_full_name": "Doe John"}},
        {"match_phrase": {"user_full_name": "John Doe"}}
      ]
    }
  }
}

优缺点：无需修改现有索引和技能，仅需调整查询逻辑；但需要在应用层处理查询字符串的拆分和重组，逻辑稍复杂。

内容的提问来源于stack exchange，提问作者ahmed