wyymichael / paoding

Automatically exported from code.google.com/p/paoding
0 stars 0 forks source link

关于paoding和QueryParser一起使用的问题。 #4

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
普通的英文搜索使用" "间隔每个单词,例如"google 
map"被QueryParser解析过后会生成
Query——"google"和"map",例如搜索name这个field,会被切
为"name:google"和"name:map",然后按照默认逻辑对结果进行并,交
。

使用paoding的中文搜索,我用这样的代码:
Paoding paoding = PaodingMaker.make();
QueryParser pName = new QueryParser("name", PaodingAnalyzer.queryMode
(paoding));
Query qName = pName.parse("小宝 康熙");
输入“小宝 康熙”,可以被解析为"name:小宝"和"name:康熙"。

但是直接输入"小宝康熙",
Query qName = pName.parse("小宝康熙");
会被解析为"name:小宝 康熙"

结果完全不是我想要的。

因为这样,我自己想到一个很傻的办法,先利用paoding切成带�
��格的,然后再搜索。。。
两次,现在的代码是这样的:
...
Analyzer an = PaodingAnalyzer.queryMode(paoding);
TokenStream tokens = an.tokenStream("name", new StringReader("小宝康熙"));
StringBuilder sb = new StringBuilder();
Token t = tokens.next();
while (t != null) {
sb.append(t.termText() + " ");
t = tokens.next();
}
String q = sb.toString();
Query qName = pName.parse(q);
这样输入"小宝康熙"就好了

但是我想配合QueryParser的Analyzer应该不是必须这样用吧,应该�
��一气呵成才对,不用我这
样做两道。

我用的lucene2.2.0,
paoding是paoding-analysis-2[1].0.1(UTF-8).zip

Original issue reported on code.google.com by huang.li...@gmail.com on 22 Oct 2007 at 6:04

GoogleCodeExporter commented 9 years ago
没办法:lucene的QueryParser认为你输入的“小宝康熙”是一个短
语,它只会找那些包含"小宝康熙"文字
的文档,1、这个文档必须同时包含"小宝"和"康熙",2、他们��
�须是紧唉的。
这个是QueryParser的要求。我也认为这是良好的。

如果你用程序分词后再用空格隔开,这也是一种需求。不过��
�照做法有可能:只会检索出只含小宝获康熙的文
档,并且康熙没有紧挨着小宝的文档也算是命中。

结论:不管使用QueryParser设定的含义或者我们自己设定的自己
要求的含义,其实和paoding,甚至说和分
词方案是没有关系的,paoding无能为力;但paoding也不会/不应��
�限制你按照自己的意思做事。

:)

Original comment by qieqie.wang on 22 Oct 2007 at 6:41

GoogleCodeExporter commented 9 years ago
拿英文的和中文进行类比,我想"google 
map"不会被lucene理解为google紧接map而是先分别用google和
map得到hits之后再做并和交。
所以我认为中文如果和英文搜索设计理念一致,也不应该理��
�为"小宝康熙"整个为一个短语,而不是两个独立
的词,所以我觉得似乎和原来的lucene的QueryParser的设计理念不
同。
不过中文本身就是很复杂的东西,是切是不切,怎么切都是��
�个问题,搜索的时候是整体当作一个短语还是理
解为几个短语来进行搜索,这个似乎不丹丹是技术,而且是��
�化方面的东西,整个的不切也确实保留了用户的
灵活性,不过我觉得似乎还是应该说明一下这个设计

Original comment by huang.li...@gmail.com on 22 Oct 2007 at 7:23

GoogleCodeExporter commented 9 years ago
我仍然觉得还是保持一致的好,对于短语,带上引号就可以��
�切,所以没必要默认认为不切。

Original comment by huang.li...@gmail.com on 22 Oct 2007 at 7:25

GoogleCodeExporter commented 9 years ago
1、首先纠正一个错误:“小宝康熙”一定会被切的,短语查�
��也是需要切词的。 
2、但是对切的结果,不过的Parser可以有不同的理解,按照Luce
ne提供的QueryParserd的理解,就是原本
紧临的字符,它认为是用户要求目标结果要求包含近邻的那��
�字符串,所以他那样处理。
3、你所说的问题,本质是QueryParser的问题。可以这样说。如��
�这个需求很强烈,我们就必须放弃使用
Lucene自带的QueryParser,而自己开发一个符合你说的那种要求的
QueryParser来处理,这种
QueryParser我们可暂且可以命名为CJKQueryParser。

Original comment by qieqie.wang on 22 Oct 2007 at 7:31

GoogleCodeExporter commented 9 years ago
有些词比如"K歌之王","A片",我直接添加到t-base.dic无法起作�
��,这样的需求该如何呢?

Original comment by huang.li...@gmail.com on 22 Oct 2007 at 8:32

GoogleCodeExporter commented 9 years ago
明天发布2.0.4-alpha2版。

倒时把这些lantin+cjk的词加在x-for-combinatorics.dic即可。

Original comment by qieqie.wang on 22 Oct 2007 at 8:37

GoogleCodeExporter commented 9 years ago
赞!!!!!
帮大忙了!!!

Original comment by huang.li...@gmail.com on 22 Oct 2007 at 8:54

GoogleCodeExporter commented 9 years ago

Original comment by qieqie.wang on 17 Mar 2008 at 3:02

GoogleCodeExporter commented 9 years ago
qieqie 你好,我碰到了类似的问题.
搜索标题:北京三年内将实现高考考场电子监控
用"北京 
高考"能够搜索到.用"北京","高考"单独搜索都可以搜索到这个�
��果.但是如果中间不加空格.用"北
京高考"去搜索.就搜索不到结果了.
我用PaodingAnalyzer.tokenStream()去取分词后的termText(),分成了"北京
","高考"两个词.切分的是
没问题的.但是却搜索不到结果.

我想对这种问题这样处理
将用户输入的短语切分以后理解为AND的关系

北京 高考 = 北京 OR 高考
北京高考  = 北京 AND 高考
北京高考 监控 = (北京 AND 高考) OR 监控

这样出来的结果应该是比较合理.

Original comment by sar...@gmail.com on 22 May 2008 at 4:17

GoogleCodeExporter commented 9 years ago
这和和分词没有关系。
请充分了解Lucene的QueryParser的用法

Original comment by qieqie.wang on 22 May 2008 at 4:21

GoogleCodeExporter commented 9 years ago
还有一个问题,就是"笔记本"在分词的时候,分成了"笔记"和"笔�
��本"两个词.建立索引以后搜索"笔记本"搜索
不到.这样的问题是怎么产生的呢?

Original comment by sar...@gmail.com on 2 Jul 2008 at 6:28

GoogleCodeExporter commented 9 years ago
"笔记本"在分词的时候,分成了"笔记"和"笔记本"两个词.建立索
引以后搜索"笔记本"搜索
不到.这样的问题是怎么产生的呢?
---
不信

Original comment by qieqie.wang on 2 Jul 2008 at 10:42