Comment on EYRE’18

EYRE’18 就是 “1st International Workshop on EntitY REtrieval (EYRE ’18)”

因为我那天在都灵睡过头了,错过了一些 presentation,所以只谈几个我感兴趣的。

1. Graph Analytical Re-ranking for Entity Search. Takahiro Komamizu

文章和之前评论的内容差不多,我甚至有点怀疑作者是看了我的评论才把这个方法叫做 “Personalized Pagerank based score distribution”。这个方法是否本质有效,不想说了,最近心情不好。

(说点不好听的吧,这其实是我三年前玩过的东西,研究我的 github 项目的人会发现,我的框架里面总有一个 createGraph 模块,就是给这个东西用的。为什么我没写文章讲这件事呢?自己想想吧)

Anyway, consider entities together 是有价值的想法。

2.Annotating Domain-Specific Texts with Babelfy: A Case Study. Michael Färber, Kristian Noullet and Boulos El Asmar

对文章内容不评价。讲一些趣闻:年初我参加 ECIR2018 找 Adam Jatowt 尬聊 NTCIR AKG 的时候看到 Michael 也在旁边,当时还以为他是 Adam 的学生,抢占了他几分钟时间,真是抱歉。。。个人看好这个小帅哥,感觉他是个比较踏实的人。

3.Graph-based Reranking Approach for DBpedia Entity Search. Bo Ma, Yating Yang, Tonghai Jiang, Xi Zhou and Lei Wang

我个人认为,作者提出来的方法本质是借鉴 Discounted Cumulative Gain 的思想来 rerank 所有结果。当然,他在 slides 里面说 “more links, more important”这种解释也还算说得过去,其实和 DCG 的思想是一样的。不过比较讽刺的是这个模型在 QALD2 和 SemSearch 上的结果很差,有点违背了他的解释。

为什么大部分模型都会有 “results are dataset specific” 的情况呢? 不想说了,最近心情不好。

update 2019/03. 最近考虑了一下,感觉更像是从 pagerank 这类基于重要性的模型中得到灵感。NDCG 作为一种评价方式和 pagerank 有一些形式上的相同,这反而让我觉得有些意思。

4.Exploring Summary-Expanded Entity Embeddings for Entity Retrieval. Shahrzad Naseri, John Foley, James Allan and Brendan T. O’Connor

训练了一个 word-entity 的 embedding,embedding 的分数和 FSDM 的分数加权平均。不想说什么。

 

我觉得最不高兴的点就是这些人好像根本没有注意到 term-based retrieval model 的地位。另外好像也没读我的 ECIRICTIR 的文章,更别说引用了。(这并不是说我的文章有多么好或多么重要,而是在你准备做相关的研究的时候至少应该看看最近这个领域的人在谈论什么。)

总的来说这次研讨会的 entity search 部分就像一个大型民科自嗨现场,没有特别有效的进展。不过 Prof. Gong Cheng 花了很多时间尽力让这个会议变得正式和专业,作为开拓者劳苦功高,什么都干不了的小弟在此表示衷心感谢和敬意。期待下次变得更好。

Information need & supply

For a fixed  retrieval model that satisfies users’ information need to some extent

Margin: a unit of incremental data size may increase the “dimension” of the data, which makes it more difficult for the model to handle. Thus non-positive margin.

 

For a fixed data producing model that provides “information supply”.

Margin: a unit of incremental data size may increase the “dimension” of the data. In this situation, a new “basis” can be used to generate more “new deep” data. Thus non-negative margin.

 

Intersection: the best performance(utility) bound for a fixed retrieval model and data generator.

Comment On Recent Progress Of Ad-Hoc Entity Retrieval 2

我写文章的时候只引用那些我已经消化过的论文。我引用新文章的时候比较谨慎,因为没时间去了解具体的内容。暌违一年,重新在 google scholar 上浏览了一下最近都有哪些新东西。

Comment On Recent Progress Of Ad-Hoc Entity Retrieval 1 在这里: https://lxsay.com/archives/591

Exploiting Entity Linking in Queries for Entity Retrieval

(ICTIR 2016. Faegheh Hasibi, Krisztian Balog, Svein Erik Bratsberg)

这篇文章把语义标注 (semantic annotation) 整合进了 Markov Random Field 这个框架内,简单的来说就是统计语义标注 在 pseudo document 中的频率,然后通过一个平滑函数 (smoothing based feature function) 来刻画 semantic annotation 的分数。

但我觉得这篇文章更重要的在于它暗示了 Knowledge-based Question Answering 和 entity search 的联系。 这个模型在 Fielded Sequential Dependence Model 的基础上使用了一个称为 “Selective Top Fields” 的技巧:给定一个 query,模型首先会通过计算 query term 的 mapping based probabilities across the whole collection 然后选择分数最高的top-k fields计算 query 和 entity profile 之间的分数。这其实是 graph-based question answering 的方法:给定一个问题,Knowledge graph 中每个关系的权值定义为该问题和该关系的语义相似度,最后选择一条权值最优的路径输出作为答案。 这篇文章提出的模型可以看成是能处理 1-hop 关系的 retrieval-based question answering model.

Ranking Entities for Web Queries Through Text and Knowledge

(CIKM 2015. Michael Schuhmacher, Laura Dietz, Simone Paolo Ponzetto)

当信息检索的研究者说他们对 “knowledge graph” 感兴趣的时候,他们所指的 “knowledge graph” 其实是以下三种的组合:

  1. Knowledge graph = Freebase
  2. Knowledge graph = Freebase or DBpedia or Yago or …
  3. Knowledge graph = Wikipedia

这篇文章考虑的是第2种和第3种的组合,使用基于 learning to rank 的方法。特征主要分成 query-mention features, query-entity features, entity-entity features 还有 knowledge base retrieval. 这个框架既考虑了 knowledge graph 的结构(比如考虑 entity mention 到 candidate entity 的路径),也考虑了文本的内容,水准不俗。比较可惜的是这些特征只停留在“统计个数”这样的层面,没有进一步地理解查询的语义(比如说查询“面积最大的国家”就需要理解“最大”的概念,很多 question answering 的模型都可以做到这点)。这篇文章的引用次数不是很多,没有得到应有的关注,个人觉得很可惜。

Michael Schuhmacher 是少数几位懂得运用 Knowledge graph structure 帮助提升 information retrieval performance 的研究者。其他人也有尝试,但我觉得都只能算是浅尝辄止,顾左右而言他。能够把 Graph Algorithm 和 IR 结合得这么好的人屈指可数(中国大陆的 Gong Cheng 也是一位善于使用图论方法的研究者,但是现在这方面的文章比较少,还看不出成熟的思路)。这也显示出德国人在方法论上面深受欧陆古典哲学的影响:重视整体和理性。第二作者的加入弥补了这篇文章过于注重结构忽视文本信息的弱点。

“Exploiting Entity Linking in Queries for Entity Retrieval” 的作者认为这篇文章的结论 “somewhat inconclusive”。我觉得情有可原,因为 2015 年的时候 entity search 的 benchmark dataset 还比较少。说实话这个模型很值得在现在的数据集上复现。

Intent-Aware Semantic Query Annotation

(SIGIR 2017. Rafael Glater,  Rodrygo L. T. Santos and Nivio Ziviani)

基于 learning to rank 的方法。测试数据用的是 DBpedia-Entity v1,因为 sigir 2017 那个时候 v2 还没有发布。这篇文章比 “an empirical study of learning to rank for entity search” 好的地方在于考虑了语义标注的信息 (semantic annotations),简单的说就是统计了 query 和 entity profile 里面出现了多少 knowledge graph 里面的 type 和 relation 的信息,然后当成特征输入 learning to rank 的框架。本质上还是 term-based (word as a term / semantic annotation as a term) 的语言模型方法,对复杂的查询无能为力。但是我觉得这个框架的设计不错,有启发。作者没有开源,本人准备自己实现一个当作以后的 baseline 。

最后想说下(和这篇文章无关), learning to rank 虽然是实证有效的方法,但也分好坏。好的 letor 框架能够精细的处理输入,让整体锦上添花;坏的 letor 框架缺乏对具体问题的洞察(insight),堆砌特征,好像是在指挥一堆垃圾为它们自己建一个垃圾厂。

Interpreting Fine-Grained Categories from Natural Language Queries of Entity Search

(DASFAA 2018. Denghao Ma,  Yueguo Chen, Xiaoyong Du, Yuanzhe Hao)

这篇文章的框架和 “Improving Context and Category Matching for Entity Search” (Yueguo Chen et. al. ) 里面提出的没什么区别,但是用到的语言模型感觉受到了 “Query modeling for entity search based on terms, categories, and examples” 这篇文章的影响。其次更新了一些处理 Wikipedia Category Tree 的细节,定义了一些新的特征。另外在新的数据集上面更新了一下结果。

Leveraging Fine-Grained Wikipedia Categories for Entity Search

(WWW 2018. Denghao Ma, Yueguo Chen, Kevin Chang and Xiaoyong Du)

这篇文章的框架和 “Improving Context and Category Matching for Entity Search” (Yueguo Chen et. al. ) 里面提出的没什么区别,但是用到的语言模型感觉受到了 “Query modeling for entity search based on terms, categories, and examples” 这篇文章的影响。其次更新了一些处理 Wikipedia Category Tree 的细节,定义了一些新的特征。另外在新的数据集上面更新了一下结果。  (灌水小能手:)

可能是受到了自己导师的影响,这篇文章的作者还是主要在 INEX 2009 之类比较老的数据集上面进行测试。如果能转到 DBpedia-Entity v2 上就更好了(不过这样的话需要和 “On Type-Aware Entity Retrieval” 正面比较,感觉比较悬)。

中国人民大学的这个研究小组这几年对 entity search 问题有独到的贡献,比如用提取维基百科的分类标签(category)的关键词和描述词,并把它们按照自己偏序重新组合成 category tree。但我还是感觉他们使用的方法过于复杂,虽然目前在他们的文章里表现不错,但如果换一个测试数据集的话,很难做出针对性的调整。换句话说,工巧但是略欠“大局观”。BM25 和 sequential dependence model 广受欢迎不是因为它们总能够达到最好的结果,而是设计足够鲁棒,足够简单。在不同的问题上都可以做出针对性的调整。

RWRDoc: Random Walk with Restart based Entity Documentation

(ESWC 2018. Takahiro Komamizu)

这篇文章提出了一种新的表示 Entity profile 的方式。每个 entity 的文本都可以表示成一个 bag-of-words vector 或者 TF-IDF vector,考虑到 entity 在 knowledge graph 中与其他 entity 相连,所以它们的文本应该会有一些相关性,于是作者认为每个 entity 的向量表示都是自身与相关 entity 的向量的线性加权和。我认为,作者把这个建模为随机游走是因为如果想要求解这个大型线性方程的话必须假定这样的表示法能够收敛。这种思想来源于 relevance propagation/page rank 这些传统的方法论,不同的是这篇文章传递的是 entity 的 bag-of-words vector 而不是 relevance score。

另外,这篇文章上所有 baseline 的结果都是从 DBpedia-Entity v2 的发布论文里面复制过来的。这其实提出了一个问题:每个人的建的 index 质量都不一样,于是 baseline 的结果也变得有好有坏。这个领域是否需要一个公开的 standard index 让研究者可以比较不同的方法呢?

Entity Retrieval in the Knowledge Graph with Hierarchical Entity Type and Content

Full Text at ACM Digital Library: https://dl.acm.org/citation.cfm?id=3234963

github: https://github.com/linxinshi/EntityRetrievalPAS

我的文章 “Entity Retrieval in the Knowledge Graph with Hierarchical Entity Type and Content” 被 ICTIR 2018 这个会议接收了。

这是我的 “entity retrieval trilogy” 的第二篇。相比第一篇,这篇文章把之前的方法扩展到 Markov Random Field 上,使得 sequential dependence model 也可以使用结构平滑。另外把维基百科的文章解析成一个树状的形式,仍然使用结构平滑来计算查询和文章的相关程度(考虑一个从根到叶子的路径,最后的结果比整篇文章用 bag of words 表示的结果要好,这其实说明文本中有相当多的信息都被传统的语言模型忽略掉了)。这种推广并不是很难,但这篇文章是想强调在不同的结构化信息来源中信息检索模型可以通过以路径为中心的统一框架来寻找答案。“路径”的概念被推广到一个单纯的序列,序列中的相邻元素不一定是在具体的结构(比如 knowledge graph/type taxonomy)中相连的。只要使用者认为把它们组合在一起是有意义的,就可以使用结构平滑。另外结构平滑还可以用在其他更复杂的模型当中。

这篇文章还有一个细节是我把 BM25F 拿来当 baseline。之前这个模型在 dbpedia-entity v2 上取得了最好的成绩,导致这个领域的同行有一段时间意志消沉,觉得之前提出的模型都成了废柴。本人这次把它的固定参数版本单独拎出来吊打了一遍又一遍,to vent for my peer researchers。。。(原来使用的是 coordinate ascent 来学习参数,但是仍然和我的模型有差距)

最后感谢我们家 Sam 的劳动,各位 reviewer 还有 chair Grace & Fabrizio。

语言模型的偏移

为了描述文档中词的分布,之前的研究者提出了很多的语言模型(比如 N-gram)。

一方面来说,这些模型只是近似地描述了一类分布,所以通过求解这类模型得到的分布只能说是基于对应的语言模型假设下最佳的结果。

另一方面,实践中经常会遇到这类情况,我们选定了一个语言模型来描述特定的文档集合的词的分布。但是有时候,工程人员并不完全依照这些模型的经典形式,而是喜欢在模型里面加入一些微扰项作为某种“分布在当前数据集上的偏移”,以便取得更好的结果。 这种现象反映了语言模型作为信息检索的核心的某些深层次问题。

夜话

Min Flag
痛苦中被迫浮现的字
用有限的时间做无限的事

Min Flag
竖一杆大旗让勇士们绝地起义
精彩的程度让场下观众都全体起立

——— MINSTA <Min Flag>

 

1. 唱过什么歌

最近去参加了学校图书馆和研究生院办的研究海报展览。22幅海报里面,只有我这张海报是来自工程学院的学科,其他都是生物医学社科。参加活动只是走走过场没什么可说的。虽然已经尽力把海报做到“让傻逼也能看懂”的程度,毕竟隔行如隔山,很多IR的精髓难以向普通观众描述。有趣的是图书馆的主管看了海报以后很激动,这两天打了好几通电话想找我做项目。具体来说,就是根据论文的摘要把每篇论文打上标签,这些标签构成一个 Type Taxonomy。这其实是一个简单的 Type Taxonomy classification 问题,之前的知乎“看山杯”和最近 sigir 18 e-commerce workshop 都提到了非常类似的任务。简单的字符级别当作输入的神经网络或者 fasttext 之类现成的分类器就能有合理的结果。(当然我之前想过一个结构平滑的办法,但是老板一贯地觉得我的方法 “cannot publish”,等到 ictir 和  e-commerce workshop 狂发邮件催稿的时候已经来不及了) 我的“研究”能够启发普通人解决一些耗费人力的工作,略感欣慰。 另外,图书馆的工作氛围很轻松,这里的人像是中文大学的“中产阶级”,衣着还算讲究,说话比较有礼貌。不像工程学院的不少人一副又猥琐又没礼貌的样子,走路的时候遇到人总是把头低下去好像囚犯见到监狱的工作人员。

从中学到大学到现在,我遇到了一些hater. 因为我总是用简单的方式揭示他们的愚蠢,总是用愚蠢的方法超越他们的想象。现在 haters 都在期待我延毕或者混不下去滚蛋,这辈子他们也许能看到本人失败一到两次。我在一个比较恶劣的环境下工作,research topic 的局限性明显很难发展,没有同行,计算资源有限,ra很难帮到。如果我哪天受不了拿个硕士学位走人,我也能骄傲地面对我的过去:没有抱大腿认爹,没有靠关系,独立完成,完全原创而不是东拉西扯一堆东西打包。

我的“entity retrieval 三部曲”还剩最后一篇文章没发表,在过去的两篇里面,我让那些快要进棺材的模型可以借着 knowledge graph 的风潮续命,炒了一盘冷饭。至于最后一篇做到了什么程度,不想评价。写完以后打算继续做 TREC Complex Answer Retrieval。今年 sigir 有篇文章讲到了这个task,还引用了我的文章当作baseline吊打。我才发现原来去年我们除了一个不战而胜的第一还有一个第二名(Deepanway, in the end we win a lot and get cited ……. you can write it in your cv now)。其实我那时对 sequential dependence model 的理解和实现都是错的,居然还有这样的成绩。 今年就用结构平滑 bring back the glory 吧.

 

2. ecir 2018

今年三月底去法国的格勒诺布尔参加了 ECIR 2018. 这次会议我认为有几个动向值得注意:

1、高度重视模型的可复现性,国内有一篇在 squad 数据集上做问答的文章因为作者拒绝透露实现细节被参会者口诛笔伐,大家认为这种不可复现的文章应该直接拒稿。

2、信息检索的隐私和公平性问题,这是开幕式上 keynote speaker 的发言主题。

3、结构主义的苗头:这次会议有一些打着 “path aware”, “hierarchical”这样旗号的文章,依托 Knowledge Graph 的结构做一些简单的工作,总的来说结果都不是很好。其实这类方法都可以拓展到一般的语料库上面。

4、neural IR 的发展。其实IR现在最需要发展的是收集标注数据的方法论。最近几个会议上有好几个这方面背景的 keynote speaker ,可惜响应的人很少,因为数据都在大公司手里,而且数据归属权受到法律约束,不能明目张胆地收集和研究。如果再不重视这个问题的话,大家都得完蛋。。。

 

最后,我很幸运遇见了一个女生,我们算是半个同行。相信我们都会找到自己的路。我们还会再见。你在车站送给我的小瓶子还留着:)

Comment on recent progress of ad-hoc entity retrieval

1.An Empirical Study of Learning to Rank for Entity Search (Jing Chen, Chenyan Xiong, Jamie Callan)

这篇文章用 learning to rank 的方法,把之前一些表现比较好的模型的分数拿出来学习权重,然后返回新的混合的分数。

说实话,这篇文章让我挺失望的。这种基于 LTR 的办法纯属是下三滥的鸡肋套路,对本领域的研究几乎没有任何帮助(Empirical 也要讲道理啊!!拿分数当特征,真的不知道意义何在,而且很多模型其实都是基于类似的语言模型,很有过拟合的嫌疑,最后模型完全变成调参数的框架),因为我们可以随便编造出一堆简单的检索模型(比如对每个域都指派一个不同参数的 Language Model 构造的检索模型),然后用 LTR 以后照样可以提高性能,但是这样的性能提升是有限度的。当然,我也非常理解,因为这几位作者和 Learning to rank 的研究者圈子关系密切,所以用这样的方法论思考是很自然的事情。

这篇文章用的是 Balog 的 DBpedia 测试数据集的第一版,质量比较差。 之后在第二版数据 (DBpedia-Entity v2: A Test Collection for Entity Search)里面,这个方法一下就被打回原形了,和一些当前比较好的方法相比没有明显的提高甚至有所下降。

不知道第一作者是不是急着要文章毕业。假如我文章不够不能毕业,我也不会发这种文章凑数。。。

虽然不待见这篇文章,但是考虑到这个领域的文章实在太少,所以能投出去其实也算个好事,毕竟众人拾柴火焰高

2.Entity Search Based on the Representation Learning Model With Different Embedding Strategies  (Shijia E, Yang Xiang)

首先第一作者鄂世嘉的姓挺少见的,看样子似乎是满族,也有可能是汉族鄂氏(我总感觉每个满族人都是以前的皇族(爱新觉罗???)。。。。小的给贝勒爷请安了)。

这篇文章其实应该归类到知识库问答 (Knowledge Based Question Answering)这类文章中,因为 ad hoc entity search 主要还是发展传统信息检索在新的结构化数据上的方法论,KBQA 则是各种奇技淫巧崭新方法的竞技场。 这篇文章用的是 KBQA 里面比较常见的方法(其实就是 Facebook 之前一篇文章里面的方法。。。),学习查询和实体的表示,然后计算他们的相似度。

这篇文章方法并没有很大的突破,所以拉低了它的档次。文章的实验部分比较可疑(按照 ad-hoc entity retrieval 这个领域的标准来看),只用了 ListSearch 和 INEX-LD 两个数据集,按道理应该用上全部四个数据集, 不知道是否是因为结果不佳还是时间不够还是作者“觉得”这两个已经足够有代表性。  这篇文章用的也是 Balog 第一版的数据,如果换上新的测试数据集可能会被打回原形。

这个领域的数据集的标注数据特别少,一般只有几百条,并且有一定的数据集依赖性(比如说 INEX-LD 里面都是关键词组成的查询, QALD2 里面都是符合文法的正规查询,如果打乱这些不同“风格”的查询组成新的测试数据集,很可能会影响模型的性能)。所以深度学习是否能真的学到什么,个人持怀疑态度。

这篇文章还是有一定的价值,起码指了一条新路。博主的评论风格一般比较狂暴,所以看上去好像我全盘否定了这篇文章,但其实不是,因为我知道 IR 的研究工作量是其他领域的十倍以上,像我这样慢手慢脚的猪仔真的很难生存。。。。。

我觉得大部分的文章都没有理解 entity search 和 traditional information retrieval 的区别在哪里,所以导致方法论有偏差,一味想去拟合文本中词的分布。 其实照这个思路发展下去,总有一天会出现这样的文章:我们只要给每个词一个权重,然后找一台超级计算机疯狂运算几个月拟合结果,出来的结果一定是 state of the art 。。。。。

Under the Shadow of Deep Learning

深度学习的概念现在已经是十分火爆了,这种终极的基于优化和统计的函数拟合技术已经征服了计算机科学大部分领域,以至于所有的人都希望自己从事的领域能和神经网络攀上一些关系。成功的人,叫做“XX领域最早使用XX网络的那一批”,久而久之,成了被瞻仰的理由;班门弄斧,应用失败的人,也可以给自己贴上先烈的标签,在机构或者公司里,用壮阔的经历和动人的眼泪谋得一官半职。

我周围的很多人,已经依靠这件宝贝获得了很多的利益。和他们在一起,听他们谈论起各种调整网络结构的技巧以及“会议见闻”的时候,难免会感受到一些压力。在科研机构里面,多发文章才能证明自己的生存能力,才可能获取更多的资源,才更有底气和面子(不管是对同性还是异性。。。)。默默无闻的人,总是被扫进记忆的垃圾桶——即使最终他们忍受了应得的苦难,发现了另外的宝藏,难免带着一身恶臭,不能见人。

在厦门大学,我选了庄宝煌教授的大学物理课程。庄是一个可以熟练地用本质的数学语言描述物理现象的人,也是一个喜欢在大众面前发表各种奇谈怪论的有趣人物。他可以连续数十个昼夜研究黎曼猜想(也许只是他眼中的黎曼猜想:)),也可以在课堂上解读七绝连环诗并且给全物理系的同事发邮件炫耀自己的成果。不过印象最深的还是他一直告诫我们要“随大流”。

对于科学来说,最重要的一直是可解释性,所有的部分都应该像玻璃一样拥有可以触碰的透明。

最近带了两个来自印度的研究助理,他们需要实现一些有点过时而且复杂的信息检索模型,并在有一些混乱的海量文本数据上测试自己的成果。要完成这样的工作需要耐心,特别是对于两位“深度学习爱好者”来说。 他们很尽职,不过在交谈的时候我时刻可以感受到他们对于应用前沿技术的憧憬。

不想耽误别人的青春,也不想浪费自己的时间。我在最后一周做出了一些改变,在可以接受的重要部分使用了一些让他们兴奋的东西。于是他们很开心地在第二天表示已经完成所有部分,在跑数据了。。。。(如果早点发现的话我会让老板扣光他们的工资!!!:))

其实信息检索模型在应用神经网络面对的最大问题是维度爆炸和语义拟合,所以我们都不知道能走多远。。。

我比较欣赏的NLP/IR学者

这里列举的都是已经功成名就或者有一定声望的学者

林钦佑 (Chin-yew Lin):我一直以为微软的“小冰”算数学题的功能是用了很复杂的自然语言理解技术,看了论文以后才明白,他叫了几个RA收集网上解题网站的数据,然后用统计学习的办法提取解答过程的文本特征,生成一些特定的解答模板(未知数和方程)。遇到新的查询的时候,先查找最相似的解答模板,然后把数值填进去,最后解方程得到答案。 这种巧妙避开难点曲线救国的壮举如同欧拉应用韦达定理到无穷级数方程得到巴塞尔问题的解

吕正东:比较喜欢他在利用神经网络处理NLP和IR问题时候采用的符号主义思想。国内很多的研究人员满脑子都是向量表示+神经网络,然后把解决问题的方法论归结到调整神经网络中各种奇怪的激活函数和网络结构。

W. Bruce Croft:有很多基础性的工作。很多人对他的印象停留在十年多前向量空间模型大行其道的时候,其实他们组也探索了不少利用新的表示法的检索模型(比如  paragraph2vector 和 PRMS),虽然结果都不是很理想

Krisztian Balog:巴主席把正常人能想到的 entity retrieval model 都做了一遍。。。。每次我想到一个新的想法要实现的时候,我都很兴奋。几个月之后,当我得到一些结果的时候,发现他和他的马仔已经把论文拿去某个会议投稿了。。。。大大提升了我延期毕业的风险

Install PyLucene 6,7,8 on Windows 10 64bit

update 2021.10: minor fixes. Tested OK with PyLucene 8.9

update 2019.10: add support for PyLucene 8.1.1

update 2019.03: add support for Pylucene 7.7.1+ and clarify some steps

update 2017.07: add support for Python 3

 

Prerequisites

Install Python 2.7.x or Python 3.4+ or Anaconda (Python 2.7.x or Python 3.4+)

Install python packages: numpy, scipy and gensim

Install JDK 1.8 (64 bit) and set environment variables

*The latest JDK 1.8.x is recommended

*JDK 10+ may be incompatible

*Anaconda is recommended since some people seems to have difficulties with raw Python

*If you use raw Python instead of Anaconda, then you may need to add environment variables such as PYTHONHOME and PYTHONPATH to ensure that python can be called on command-line prompt. For Anaconda user, it is recommended to use Anaconda prompt.

  1. JAVA_HOME=C:\jdk1.8.0_06 (or other path)
  2. add %JAVA_HOME%\bin to PATH
  3. CLASSPATH=.;%JAVA_HOME%\lib;%JAVA_HOME%\lib\tools.jar
  4. add CLASSPATH as an environment variable
  5. add %JAVA_HOME%\jre\bin\server to PATH
  6. Install one of the following libraries subject to your environment:
  • Visual C++ library for Python 2.7
    • (www.microsoft.com/en-us/download/details.aspx?id=44266)
  • Visual C++ 2015 Build Tools for Python
    • (http://landinghub.visualstudio.com/visual-cpp-build-tools)
  • Visual Studio 2015+  (community version is enough. Choose c++ related tools and all versions of SDK to install in the VS installer)
    • (https://visualstudio.microsoft.com)

Step 1. Install Apache Ant and set environment variables
1. specify ANT_HOME and add ANT_HOME as an environment variable
2. add %ANT_HOME%\bin to PATH
Step 2. Install cygwin 64 and set environment variables
0. When installing cygwin, choose “Devel” from “Default” to “Installed”
*the space of all packages under “Devel” category are quite large (30~70 GB). “Default” with some basic gcc/g++ tools, libraries and make/cmake utilities are already enough for PyLucene installation.
*choose “Debug” from “INSTALL” to “Unstall” or “Default” can save a lot of space.

1. specify CYGWIN_HOME and add CYGWIN_HOME as an environment variable
2. add %CYGWIN_HOME%\bin to PATH
restart your computer

 

Step 3. Download source code of PyLucene and extract, we obtain a directory named ‘PyLucene-6.5’
* For PyLucene 7 user, the latest Pylucene 7.7.1 is recommended because
the previous PyLucene 7.x may encouter errors during the installation
process.

Step 4. Open Anaconda prompt, execute command under directory JCC
1. python setup.py build
2. python setup.py install
restart your computer
for Linux user, edit line 71 of setup.py to specify your JAVA home (For example, ‘linux’: JAVAHOME) or simply set a JCC_JDK environment variable sharing same value with JAVA_HOME.

Step 5. Edit PyLucene-6.5/Makefile

first comment the default configuration (by adding ‘#’) like the following
# Mac OS X 10.12 (64-bit Python 2.7, Java 1.8)
#PREFIX_PYTHON=/Users/vajda/apache/pylucene/_install
#ANT=/Users/vajda/tmp/apache-ant-1.9.3/bin/ant
#PYTHON=$(PREFIX_PYTHON)/bin/python
#JCC=$(PYTHON) -m jcc.__main__ –shared –arch x86_64
#NUM_FILES=8

And then insert the following configuration (the following are just examples)

PREFIX_PYTHON=D:/Progra~2/Anaconda2
ANT=D:/apache-ant-1.9.7/bin/ant
JAVA_HOME=C:/Progra~1/Java/jdk1.8.0_101
PYTHON=$(PREFIX_PYTHON)/python.exe
JCC=$(PYTHON) -m jcc
NUM_FILES=8

*for PyLucene 8 installation, set NUM_FILES=10. If encounter [WinError 267] when executing ‘make install’, execute ‘make clean’ and then ‘make install’ again.

*if the path contains blank space, you need to replace it by dos path like ‘C:/PROGRA~1’

*if you create a Anaconda environment, then change PREFIX_PYTHON to the root directory of this environment. (e.g Anaconda2/envs/ENVIRONMENT_NAME)

 

Step 6. Execute command ‘make’ under directory ‘PyLucene-6.5.0’ to build the whole project

*use command “make -j2” or “make -j4” to speed up

Step 7. Execute command ‘make install’ under directory ‘PyLucene-6.5.0’

 

Frequently Encountered Problems
1. Python (actually ‘setuptools’ package) cannot call Visual C++ (MSVC) to compile the project
solution: Rewrite PYTHON_PATH\Lib\distutils\distutils.cfg like the following
[build]
compiler=msvc

[build_ext]
compiler=msvc

2. It fails when compiling JCC
solution: open setup.py and
find line ‘win32’: [“/EHsc”, “/D_CRT_SECURE_NO_WARNINGS”],
replace this line by

‘win32’: [“/EHsc”, “/D_CRT_SECURE_NO_WARNINGS”,”/bigobj”],

3. [WinError 267] the directory name is invalid

replace NUM_FILES=8 by NUM_FILES=10 in Makefile.

execute ‘make clean’, and then execute ‘make’ to compile the whole project again

4. JCC_JDK not found (may encounter on Linux)

set “JCC_JDK” as environment variable. The value is  same as JAVA_HOME

5. encounter “dynamic mode does not define module export function” when “import lucene” in Python prompt (may encounter on linux)

remove lucene and jcc packages by execute “pip uninstall lucene” and “pip uninstall jcc”

edit pylucene-6.5/jcc/setup.py. replace the line 71 by ‘linux’:JAVAHOME,

remove jcc/build folder and execute “make clean” under pylucene-6.5 directory.

install jcc and pylucene again