doraemon0711

提供一个思路，临时起意的话可以分区游玩，先了解一下东京的区域划分，八天的话可以考虑上镰仓横滨这些周边地区，然后按照区域去找自己感兴趣的内容

住宿可以考虑一个地区住两晚，这样可以保证一个区域有一整天时间可以游玩，然后话换酒店的那天可以考虑上午在当前区域，下午去目标区域游玩（行李可以放酒店或车站的寄存箱子），举个例子：
比如行程是新宿=>镰仓=>横滨
第一天上午新宿 check out, 中午坐电车到镰仓寄存行李，下午逛镰仓&酒店 check in
第二天一整天可以去镰仓比较耗时的景点（比如江之岛，当然这个季节可能不合适了）
第三天上午镰仓 check out ，可以考虑白天再逛一逛，或者直接做电车去横滨寄存行李，在横滨玩

这样行程会比较宽松不会太累，我当时是去玩了 11 天，去之前也没做攻略，基本上是入住酒店再看小红书规划下个区域的行程，酒店的话只要加钱都有的住，实在不行也可以住网咖

我在使用时倒是经常碰到编辑器输入卡顿，吞掉输入的文字等 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