Hey! I'm your first Markdown document in StackEdit[^stackedit]. Don't delete me, I'm very helpful! I can be recovered anyway in the Utils tab of the Settings dialog.
关键概念: 全文匹配，人工干预排序
- 搜索例如奥德赛雨刷，迈锐宝大灯, 本田机油 => 形如 [车系/品牌]+[车品名称]，结果数量很少甚至为零。当前搜索关键词在ES分词后搜索时做100%匹配，即
C200机油在后台分词后为C200和机油,则在ES的Indexing系统中查找DisplayName 或 CP_ShuXing3字段，['C200', '机油']词条数组的每个元素至少都出现一次才能算结果有效，因为机油目前因此C200机油的搜索结果数为零 - 17寸轮胎，18寸轮胎 , 2255518等等关键字搜索量高，但是搜索结果不理想，结果几乎不靠谱
- 5w-40机油和5w40机油搜索结果差很多(分词并且完全匹配导致的结果)
- 分词库很不完善，例如当前分词库包含了很杂乱的汽车名词（汽车品牌，车品品牌，汽车系列），但是数据又不完整
- 拼音搜索支持差
- 搜索匹配模式启用模糊匹配。即 原来 ATSL轮胎搜不到结果是由于全文100%匹配，ATSL字不存在于标题中，因此搜索不到。
- 对轮胎添加冗余搜索字段，如225/55R18规格的轮胎则在冗余字段中添加2255518、18寸轮胎、18寸信息用于完全匹配用户搜索词,以防用户搜不到结果 对机油添加冗余搜索字段, 如
5W-40的机油, 在创建搜索索引是在冗余字段中添加信息: 5w-40, 5w40信息- 分词库完善：添加了完整的汽车品牌和汽车系列名称作为分词词语
- 添加拼音分词功能，针对有效中文字段内容做拼音索引
- 针对目前有做过原配车型关联的车品，在做ES文档索引的时候做多表查询，将相关车型名称写入搜索索引。例如某轮胎是某辆车原配轮胎，那么用户在搜索车名+轮胎时，此记录的搜索相关性更高，内容排名更靠前。
| 搜索词 | 结果(目前) | 结果(应用解决方案后) |
|---|---|---|
| 欧蓝德轮胎 | 无 | 有且匹配 |
| 18寸轮胎 | 相关性差 | 相关性好 |
| 好轮胎 | 无 | 有 |
| 5W40 | 有 | 有 |
| 5W-40 | 有 | 有 |
| 5W-40机油 | 有不全 | 有且全 |
| 5W40机油 | 有不全 | 有且全 |
| 2255518 | 有（原因是API替换同义词成225/55R18了） | 有 |
| 2255518轮胎 | 无(原因是API无法匹配到同义词, 且ES无2255518相关分词记录) | 有 |
| 2255518马牌 | 无(原因同上) | 有 |
| Guteyi轮胎 | 无 | 有 |
由于之前使用了搜索词分词后100%匹配，也就是欧蓝德轮胎分词后是欧蓝德和轮胎，此两词必须都存在与ES建立索引时对应的某个商品的搜索字段，否则就算不匹配。因此每次搜索的结果数量级很小。
服务将分三次进行搜索:
- 和用户默认车型原配的搜索结果
- 和用户默认车型适配的搜索结果
- 不适配的搜索结果
最终的搜索结果为1.concat 2.concat 3
并且如果是默认排序方式在返回给API之前会对搜索结果中
- 先根据ProductRefer字段*(作用: 例如某机油卖得好，希望用户能第一个看见这个商品，就把这个字段设置为2，导致只要用户的搜索关键字能搜到这个商品，不管相关性多靠后，都会人工往前排到数组第2位。理论上这种做法是不可取的，但是由于之前是全文匹配，所以每次搜索结果数量本身就不大，因此这种操作的影响面并不是太大。然而使用了模糊匹配之后，每个搜索词对应的搜索结果可能达到上千的数量级，如果某个商品排在第一千位[换言之和关键字匹配度稍差])* 对搜索结果中ProductRefer有数值的重新插入结果数组的最前方。
- 对搜索结果商品BIScore字段排序 以上操作在根据价格和销量排序时不受影响