现在用 ES 还推荐通过分词插件的方式对 query 和 doc 进行处理吗？

你这样又多依赖了一个组件，可以尝试把分词直接放到你们数据写入服务里面，将分词的结果用空格拼接，es 里面保留空格分词。

没必要，重复造轮子了，没太理解这么搞得话你 es 里存的是啥东西。ES 已经把你说的做的七七八八了，包括 doc 分词、query 分词，而且中文分词质量也没啥问题，就算你真的要动分词，也是通过 es 分词插件的方式来搞，而不是外置一个服务。

索引前置的服务可以有，但作用一般是做 connector 增强，数据组装、清洗这类工作，分词还是要收敛到 ES 内。

召回前置的 NLP 部分大多是做 query 改写、扩召回的，分词一般不会放里面。

索引重建的话，ES 一个 reindex 就完事儿了，GB 级数据同集群索引重建也就是分钟级的事情，你的方案反而需要你自己手搓整个 ETL 重建流程，感觉得比 ES 慢一两个数量级。

业务复杂度不高时，只用粗排就行了，之后再加精排。一开始复杂度还是别太高比较好。

@heihe 我的想法整体和你一致，就是分词放到 ES 上游，分好的 terms 用空格拼接，ES 内部再用空格分词；只不过我在分词之后额外做一个持久化存储（ mongodb ），原因是我不清楚 es 保留全部_source 会不会对性能产生影响，如果只保留部分 field ，添加新 field 并要刷数据是就要用到（省去重新分词的步骤）


@lix7 其实我主要的问题就是分词要不要从 es 拿出去，一是不清楚分词插件能否满足实际情况，以及维护自定义词典的成本；二是对 query 改写，如果要做实体识别提权等处理，是不是也要先分词才能处理？如果是的话不如就全放到 es 外面来做好了，灵活性还会更高一些，但一想到 es 已经集成了，就比较纠结。
排序这一块不太确定理解的对不对，我理解的是粗排已经由 es 做了，即 es 的主要作用时召回+粗排。精排则需要自己在外部服务去实现，我想法是每次查询请求召回的数量应该比前端请求的数量要多，比如前端传 20 条，我则是查询 es 返回 1000 条，然后再对这 1000 条数据进行精排并添加缓存。但是需求中往往有用户指定按照某个字段排序的情况，这时是不是和粗排精排就没关系了

@doraemon0711 你的目的是干什么呢？当时我们是大数据场景，集群每天几十亿数据写入，集群 TB 级别数据，分词器做了改造，目的是为了减轻 es 集群 CPU 的压力且 ES 只用来检索，如果你数据量不大，像楼下这种偏电商场景，直接用 ES 本身处理即可，至于实体识别，意图识别这个和 ES 本身分词没什么关系，一般是算法测处理，他们存储好，工程测通过关键词直接去拿。

@heihe 我的数据到不了每天几十亿，但是每天几百万的写入请求可能是有的，目的实际上也是减轻 es 的压力，顺便不确定 ik 分词的 ik_max_word 模式是否合适（这个倒是次要的）
不过看你回复的实体识别本身和分词没有关系，是不是可以理解成分词和 NER 是平行两条线，在将 doc 传入 es 前，先通过 NER 提取出关键词然后作为另一个字段额外保存，而文档本身还是在 es 中做分词处理（我一直理解的是 NER 是要基于分词结果做处理）

@doraemon0711 一般在召回之前，会对关键词做意图识别，实体识别的处理，然后拿到这些数据作为召回的条件，这些处理规则一般是算法测的模型在处理，工程这边只是拿到结果，当然具体怎么玩，依据你们公司有无对应的团队呢。

@doraemon0711 你这个规模没必要了，直接放 es 里面就可以了。

@heihe 大概明白了，是不是可以理解成提高召回更多的是对 query 做处理，而 doc 只需要维护好分词词典就可以了，ik 分词器已经解决了大部分中文分词的情况了

@doraemon0711 对的。

借楼，大佬 ner 用什么东西做的，我最近也要提高召回率，想做类目识别改写 query

@heihe 借楼，大佬 ner 用什么东西做呀，我最近也要提高召回率，想做类目识别改写 query

@HetFrame 可以看下这个系列的文章。https://www.zhihu.com/column/c_1345405459457736704

@heihe 哇，谢谢大佬，现在就是没有经验找不到方向。