doraemon0711

我在使用时倒是经常碰到编辑器输入卡顿，吞掉输入的文字等 bug

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

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

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


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

谢谢，准备试试 miniconda ，再问个问题，如果不动 base 环境，但想加一些全局的命令(例如 tldr)该怎么做

@lhx2008 这么说控制反转这个概念只适用于编译型语言吗

好久之前了，lz 找到解决方案了吗，我也遇到了同样的需求，但我的设备是非 root 的

win 上的截图推荐一个 FastStone Capture

@lululau java 一样的