h*i
发帖数: 3446 | |
d********e
发帖数: 321 | 2 show me the code? talk is cheap :D
Thank you for sharing! Orz
【在 h*i 的大作中提到】
: 总算告一段落，总结一下。
: https://yyhh.org/blog/2021/11/t-wand-beat-lucene-in-less-than-600-lines-of-
: code/
|
h*i
发帖数: 3446 | 3 The link to the code is right there
https://github.com/juji-io/datalevin/blob/search/src/datalevin/search.clj
有想发paper的么，我这个工作SIGIR啥的应该可以发一个。我没有空做很多实验，愿意
干这些活的联系我， 我们发一个。
我还有些想法没有实现，你可以来干活，活干得够多，你做第一作者都行。我老已经过
了在乎文章的阶段了。这个工作我觉得还可以，不发表可惜了。
我这个代码是用在我的数据库里面的，你不会Clojure没关系，可以自己写一个。你用C
++， Java啥的都没关系，也搞他个开源项目啥的玩玩嘛。有兴趣的私信。
【在 d********e 的大作中提到】
: show me the code? talk is cheap :D
: Thank you for sharing! Orz
|
s*****w
发帖数: 1527 | |
T*******x
发帖数: 8565 | 5 一个想法到了可以编程的程度，也是很幸福的。恭喜。
用C
【在 h*i 的大作中提到】
: The link to the code is right there
: https://github.com/juji-io/datalevin/blob/search/src/datalevin/search.clj
: 有想发paper的么，我这个工作SIGIR啥的应该可以发一个。我没有空做很多实验，愿意
: 干这些活的联系我， 我们发一个。
: 我还有些想法没有实现，你可以来干活，活干得够多，你做第一作者都行。我老已经过
: 了在乎文章的阶段了。这个工作我觉得还可以，不发表可惜了。
: 我这个代码是用在我的数据库里面的，你不会Clojure没关系，可以自己写一个。你用C
: ++， Java啥的都没关系，也搞他个开源项目啥的玩玩嘛。有兴趣的私信。
|
d*******r
发帖数: 3299 | 6 太牛掰了
用C
【在 h*i 的大作中提到】
: The link to the code is right there
: https://github.com/juji-io/datalevin/blob/search/src/datalevin/search.clj
: 有想发paper的么，我这个工作SIGIR啥的应该可以发一个。我没有空做很多实验，愿意
: 干这些活的联系我， 我们发一个。
: 我还有些想法没有实现，你可以来干活，活干得够多，你做第一作者都行。我老已经过
: 了在乎文章的阶段了。这个工作我觉得还可以，不发表可惜了。
: 我这个代码是用在我的数据库里面的，你不会Clojure没关系，可以自己写一个。你用C
: ++， Java啥的都没关系，也搞他个开源项目啥的玩玩嘛。有兴趣的私信。
|
l*******m
发帖数: 1096 | 7 很牛x. 不过有个问题lucene应该是pure java的. 你的index放到C-based的LMDB里。在
算法角度不是太公平。如果用java-based LMDB，应该更能说明问题
用C
【在 h*i 的大作中提到】
: The link to the code is right there
: https://github.com/juji-io/datalevin/blob/search/src/datalevin/search.clj
: 有想发paper的么，我这个工作SIGIR啥的应该可以发一个。我没有空做很多实验，愿意
: 干这些活的联系我， 我们发一个。
: 我还有些想法没有实现，你可以来干活，活干得够多，你做第一作者都行。我老已经过
: 了在乎文章的阶段了。这个工作我觉得还可以，不发表可惜了。
: 我这个代码是用在我的数据库里面的，你不会Clojure没关系，可以自己写一个。你用C
: ++， Java啥的都没关系，也搞他个开源项目啥的玩玩嘛。有兴趣的私信。
|
h*i
发帖数: 3446 | 8 好问题。不过我觉得关系不大。
我是用Idiomatic Clojure写的，比高度优化的Lucene Java代码要慢太多了。所以我的
这个长尾巴比Lucene长很多。
这些长尾巴query是"s", 这种，就是一个字母。这种query算法再好也没有用，拼的是
硬速度，这个Lucene就快很多。所以我觉得用LMDB不是问题，要是你说Lucene硬速度比
LMDB慢，他们会生气的。你不知道人家做了多少优化。
还有，发文章的话，不会与Lucene比的。没有哪个文章是与Lucene比的。
而会是我们自己实现其他几个算法，然后相互比，比较各种利弊得失，条件都会是一样
的。
【在 l*******m 的大作中提到】
: 很牛x. 不过有个问题lucene应该是pure java的. 你的index放到C-based的LMDB里。在
: 算法角度不是太公平。如果用java-based LMDB，应该更能说明问题
:
: 用C
|
l*******m
发帖数: 1096 | 9 嗯，工程和写文章两码事。这个WAND好像在亚洲国家有些采用，西方似乎没人知道。我
还有一个黑箱问题：每一query, Lucene和你的engine的搜索结果一致度有多少？
【在 h*i 的大作中提到】
: 好问题。不过我觉得关系不大。
: 我是用Idiomatic Clojure写的，比高度优化的Lucene Java代码要慢太多了。所以我的
: 这个长尾巴比Lucene长很多。
: 这些长尾巴query是"s", 这种，就是一个字母。这种query算法再好也没有用，拼的是
: 硬速度，这个Lucene就快很多。所以我觉得用LMDB不是问题，要是你说Lucene硬速度比
: LMDB慢，他们会生气的。你不知道人家做了多少优化。
: 还有，发文章的话，不会与Lucene比的。没有哪个文章是与Lucene比的。
: 而会是我们自己实现其他几个算法，然后相互比，比较各种利弊得失，条件都会是一样
: 的。
|
h*i
发帖数: 3446 | 10 WAND是Lucene的缺省算法。西方没人知道，是因为西方人行会自我保护意识强，IR的人
不会告诉一般马公他们用的算法是啥。比如Lucene吹成神一样，人人都用，但里面的算
法叫啥大家都不知道。这其实不利于科技发展。所以西方被中国反超是肯定的。
我的结果与Lucene肯定不一致啦。要求都不同，我这个必须要保证有更多query terms
的doc要放在前面，Lucene没有这个要求。而且我也不用BM25，我用unique pivot
normalization，教科书说更好，我就用它了呗，我也不知道好不好。
不过这些与算法关系都不太大，非正式比比，足够了。又不是发文章。
【在 l*******m 的大作中提到】
: 嗯，工程和写文章两码事。这个WAND好像在亚洲国家有些采用，西方似乎没人知道。我
: 还有一个黑箱问题：每一query, Lucene和你的engine的搜索结果一致度有多少？
|
s*********y
发帖数: 6151 | 11 Lucene都过时的玩意 为啥要跟他比。 开源的有个vespa 是雅虎以前的开源项目。
这个才代表趋势
【在 h*i 的大作中提到】
: 总算告一段落，总结一下。
: https://yyhh.org/blog/2021/11/t-wand-beat-lucene-in-less-than-600-lines-of-
: code/
|
h*i
发帖数: 3446 | 12 我都没听说过的玩意，我怎么跟它比？
我搞的是数据库系统，数据库系统很多搜索用Lucene来做，我当然更Lucene比。过时没
有我不知道，我只知道大家都是用Lucene。
要说趋势，趋势是不存在独立的搜索，搜索不过是数据库的一个功能，这才是趋势。
【在 s*********y 的大作中提到】
: Lucene都过时的玩意 为啥要跟他比。 开源的有个vespa 是雅虎以前的开源项目。
: 这个才代表趋势
|
d*******r
发帖数: 3299 | 13 """
是因为西方人行会自我保护意识强，IR的人
不会告诉一般马公他们用的算法是啥。比如Lucene吹成神一样，人人都用，但里面的算
法叫啥大家都不知道。这其实不利于科技发展。所以西方被中国反超是肯定的。
"""
能把这个"行会意识"展开说说么?
在美国多年, 感觉无论是学校研究成果, 还是上班打工时学的"时髦技术"
很多都是复杂的垃圾, 就是故意搞得很复杂, 能用, 但是把人搞糊涂那种...
然后自己搞懂深层原理后, 再看它们, 就觉得设计得非蠢既坏
terms
【在 h*i 的大作中提到】
: WAND是Lucene的缺省算法。西方没人知道，是因为西方人行会自我保护意识强，IR的人
: 不会告诉一般马公他们用的算法是啥。比如Lucene吹成神一样，人人都用，但里面的算
: 法叫啥大家都不知道。这其实不利于科技发展。所以西方被中国反超是肯定的。
: 我的结果与Lucene肯定不一致啦。要求都不同，我这个必须要保证有更多query terms
: 的doc要放在前面，Lucene没有这个要求。而且我也不用BM25，我用unique pivot
: normalization，教科书说更好，我就用它了呗，我也不知道好不好。
: 不过这些与算法关系都不太大，非正式比比，足够了。又不是发文章。
|
h*i
发帖数: 3446 | 14 坏是习惯，真正的原因是蠢。如果是很聪明的做法，早就拿出来炫耀了。就是他们自己
也知道这不是最好的，肯定有更好的更简单的办法，但他们自己又搞不定，所以就藏着
掖着。基本就是这么简单一回事。
比如这个搜索，我老花了一两个礼拜，看看文献，就提出简单有效的办法。当然我看的
文献可能比他们IR的人广一些，我不拘泥于IR。
IR的人处于CS鄙视链的比较底端的地方，所以比较defensive。
其实很多证明有效的IR方法都不是IR的人提出的，反而是别人刚提出就被他们据了的，
比如PageRank，WAND，都是文章被他们据了的。结果后来成为了主流。
他们据别人的说法总是一模一样的：“这不是新的，我们做过”。
其实做过个屁。在CS里面，似是而非的想法算个屁，细节稍有不同，结果差之千里。
IR不像其他CS领域那么rigorous，比如人家数据库，一个文章没有几个定理证明是没法
见人的。IR文章里面你是一个定理也看不到的。你写个定理在里面人家可能就知道你是
外来的，立马把你据了：“This is not new".
IR被鄙视是自找的。
【在 d*******r 的大作中提到】
: """
: 是因为西方人行会自我保护意识强，IR的人
: 不会告诉一般马公他们用的算法是啥。比如Lucene吹成神一样，人人都用，但里面的算
: 法叫啥大家都不知道。这其实不利于科技发展。所以西方被中国反超是肯定的。
: """
: 能把这个"行会意识"展开说说么?
: 在美国多年, 感觉无论是学校研究成果, 还是上班打工时学的"时髦技术"
: 很多都是复杂的垃圾, 就是故意搞得很复杂, 能用, 但是把人搞糊涂那种...
: 然后自己搞懂深层原理后, 再看它们, 就觉得设计得非蠢既坏
:
|
d*******r
发帖数: 3299 | 15 IR 在鄙视链中地位这么低... LOL
【在 h*i 的大作中提到】
: 坏是习惯，真正的原因是蠢。如果是很聪明的做法，早就拿出来炫耀了。就是他们自己
: 也知道这不是最好的，肯定有更好的更简单的办法，但他们自己又搞不定，所以就藏着
: 掖着。基本就是这么简单一回事。
: 比如这个搜索，我老花了一两个礼拜，看看文献，就提出简单有效的办法。当然我看的
: 文献可能比他们IR的人广一些，我不拘泥于IR。
: IR的人处于CS鄙视链的比较底端的地方，所以比较defensive。
: 其实很多证明有效的IR方法都不是IR的人提出的，反而是别人刚提出就被他们据了的，
: 比如PageRank，WAND，都是文章被他们据了的。结果后来成为了主流。
: 他们据别人的说法总是一模一样的：“这不是新的，我们做过”。
: 其实做过个屁。在CS里面，似是而非的想法算个屁，细节稍有不同，结果差之千里。
|
s*********y
发帖数: 6151 | 16 技术过于陈旧了还不肯承认。 Lucene一半以上代码现在都是Elasticsearch贡献的吧？
这玩意本身就是个实验室产品。 不然也不会有Apache Solr和后来的Elasticsearch
【在 h*i 的大作中提到】
: 我都没听说过的玩意，我怎么跟它比？
: 我搞的是数据库系统，数据库系统很多搜索用Lucene来做，我当然更Lucene比。过时没
: 有我不知道，我只知道大家都是用Lucene。
: 要说趋势，趋势是不存在独立的搜索，搜索不过是数据库的一个功能，这才是趋势。
|
l*******m
发帖数: 1096 | 17 主要是ir本身没有太多的domain knowledge, 别的领域有了突破都来咬一口。比如现在
的深学bert模型。自从Google search全面采用bert后，search quality 的确变更有机
了。深学真的牛叉？根本不是，主要原因是以前的 rule based SEO很难揣摩ML的模型。
有意思的是，大家都抨击深学不可解释，但用到search, 搞SEO的都抓瞎了，不可解释
变成了优点。Google的search业绩确实有提高
【在 d*******r 的大作中提到】
: IR 在鄙视链中地位这么低... LOL
|
d*******r
发帖数: 3299 | 18 所以Google search算法是有大更新的，真的用上深学了
没搞这个方向，不太知道前沿实践，多谢更新
主要是ir本身没有太多的domain knowledge, 别的领域有了突破都来咬一口。比如现在
型。
【在 l*******m 的大作中提到】
: 主要是ir本身没有太多的domain knowledge, 别的领域有了突破都来咬一口。比如现在
: 的深学bert模型。自从Google search全面采用bert后，search quality 的确变更有机
: 了。深学真的牛叉？根本不是，主要原因是以前的 rule based SEO很难揣摩ML的模型。
: 有意思的是，大家都抨击深学不可解释，但用到search, 搞SEO的都抓瞎了，不可解释
: 变成了优点。Google的search业绩确实有提高
|
h*i
发帖数: 3446 | 19 你脑子糊涂了吧？说啥呢。
Solr和ElasticSearch都是Lucene的用户，是基于Lucene的。这个基本常识应该有吧？
Elasticsearch
【在 s*********y 的大作中提到】
: 技术过于陈旧了还不肯承认。 Lucene一半以上代码现在都是Elasticsearch贡献的吧？
: 这玩意本身就是个实验室产品。 不然也不会有Apache Solr和后来的Elasticsearch
|
h*i
发帖数: 3446 | 20 现在的搜索是分两步执行的。第一步还是传统IR，把相关的doc筛选出来，第二步，才
是神学。因为神学还是太慢了，不可能只用神学来搜索。
正因为下面还有一步呢，所以其实现在对传统IR方法的的速度要求更高了，最近几年每
年SIGIR都有对这个WAND算法家族的改进的文章。
我这个算法，也是属于同样的对WAND算法家族的演进。
【在 d*******r 的大作中提到】
: 所以Google search算法是有大更新的，真的用上深学了
: 没搞这个方向，不太知道前沿实践，多谢更新
:
: 主要是ir本身没有太多的domain knowledge, 别的领域有了突破都来咬一口。比如现在
: 型。
|
k****i
发帖数: 101 | 21 https://web.stanford.edu/class/cs276/handouts/efficient_scoring_cs276_2013_6
.pdf
https://docs.vespa.ai/en/using-wand-with-vespa.html
https://en.wikipedia.org/wiki/Learning_to_rank
"Typically, users expect a search query to complete in a short time (such as
a few hundred milliseconds for web search), which makes it impossible to
evaluate a complex ranking model on each document in the corpus, and so a
two-phase scheme is used. First, a small number of potentially relevant
documents are identified using simpler retrieval models which permit fast
query evaluation, such as the vector space model, boolean model, weighted
AND, or BM25. This phase is called top-k document retrieval and many
heuristics were proposed in the literature to accelerate it, such as using a
document's static quality score and tiered indexes.In the second phase, a
more accurate but computationally expensive machine-learned model is used to
re-rank these documents."
【在 h*i 的大作中提到】
: 现在的搜索是分两步执行的。第一步还是传统IR，把相关的doc筛选出来，第二步，才
: 是神学。因为神学还是太慢了，不可能只用神学来搜索。
: 正因为下面还有一步呢，所以其实现在对传统IR方法的的速度要求更高了，最近几年每
: 年SIGIR都有对这个WAND算法家族的改进的文章。
: 我这个算法，也是属于同样的对WAND算法家族的演进。
|
