需求是这样的,我们都知道,在信息检索中,经常要取top-k(一共k,而不是第k)个得分最大的文档,并且从大到小排序。
而且文档规模很大,最少也要上千万。
话说这是一道很可以拿来面试的题啊。
我们不考虑Hadoop神马的,就说说单机怎么搞。
最傻的做法就是把1000万个都存储下来,然后sort,然后取min(k, vec.size())。
这样有两个缺点:
1、内存占用非常大,其实我们只要保留最大的1000个,但这样就要保存N个。在1000万的测试中,它要占用68M[......]
需求是这样的,我们都知道,在信息检索中,经常要取top-k(一共k,而不是第k)个得分最大的文档,并且从大到小排序。
而且文档规模很大,最少也要上千万。
话说这是一道很可以拿来面试的题啊。
我们不考虑Hadoop神马的,就说说单机怎么搞。
最傻的做法就是把1000万个都存储下来,然后sort,然后取min(k, vec.size())。
这样有两个缺点:
1、内存占用非常大,其实我们只要保留最大的1000个,但这样就要保存N个。在1000万的测试中,它要占用68M[......]
SimpleBM25F是BM25F的基础拓展版本,主要用于多个域的拓展,感兴趣的可以看《Simple BM25 Extension to Multiple Weighted Fields》。
主要观点:按照权重将不同域重复相应次数,拼成无结构的混合文本桶,然后只计算一次BM25得分。
而之前很多人采用的各个域先计算不同的BM25,再线性组合的做法,则破坏了词项独立性而效果很差。
传统:bm25.cpp
#include <xapian.h>
#include &[......]
今天下午将Thrift定义的格式生成Java,折腾了3个小时,在依赖包齐全的前提下,死活出一堆编译错误。
最后开始翻代码,终于发现了原因:index是Java接口内部保留字,请不要用它做任何函数名、结构体、变量名……
一行就能搞定,输出32或者64
$ getconf LONG_BIT
$ 64
用在Makefile里非常给力……
OS = $(shell getconf LONG_BIT)
