Synonym behavior with highlighting and multiple terms

ppearcy · October 26, 2011, 6:48pm

Hey,
I'm seeing a couple of issues that I have pointed out in this gist:

gist.github.com

https://gist.github.com/ppearcy/1317149

gistfile1.txt

curl -XDELETE 'http://localhost:9200/syntest/'

curl -XPOST localhost:9200/syntest -d '{
    "settings" : {
        "number_of_shards" : 1,
        "analysis" : {"analyzer": {"syntest_analyzer":{"type":"custom","tokenizer":"standard","filter":["standard", "lowercase", "syntest_synonym", "stop", "english_snowball"]}, "dr_no_syn" : {"type":"custom","tokenizer":"standard","filter":["standard", "lowercase", "stop", "english_snowball"]}},"filter":{"syntest_synonym":{"type":"synonym","synonyms" : ["atripla, efavirenz emtricitabine, efavirenz/emtricitabine", "emtricitabine tenofovir, emtricitabine/tenofovir, truvada", "tenofovir disoproxil, viread"],"ignore_case":true,"expand":true, "tokenizer":"standard"},"english_snowball":{"type":"snowball","language" : "English"}}}
    },
    "mappings" : {
        "syntest" : {
            "properties" : {

This file has been truncated. show original

The first issue that appears to be a bug is that highlighting can be
incorrect in the case of multi-term synonyms. The returned data for
the 2nd result is:
atripla

I reproduced this with term_vectors no and with_positions_offsets, so
appears to affect both highlighting paths.

Next, it appears that synonym expansion occurs to the query string,
which gives some unexpected results, as all the terms in the synonym
list are injected into the query. So, looking at the 2nd result again,
atripla is returned because it is a synonym with "efavirenz
emtricitabine" and truvada is a synonym with "emtricitabine
tenofovir", which doesn't seem to be the correct behavior. I
understand why this is occurring, the synonym term expansion is
occurring both index side and query side, but that doesn't seem right.
When I specify to use an analyzer without the synonym filter, this
goes away.

I am going to play around more with expand=false and see if the
behavior is any better.

Thanks,
Paul

kimchy · October 26, 2011, 8:45pm

I will have a look at it and try and see where the problem is. Just a quick
note, you can configure a different index and search analyzer on a field (or
explicitly an analyzer when you search).

On Wed, Oct 26, 2011 at 8:48 PM, ppearcy ppearcy@gmail.com wrote:

Hey,
I'm seeing a couple of issues that I have pointed out in this gist:
1317149’s gists · GitHub

The first issue that appears to be a bug is that highlighting can be
incorrect in the case of multi-term synonyms. The returned data for
the 2nd result is:
atripla

I reproduced this with term_vectors no and with_positions_offsets, so
appears to affect both highlighting paths.

Next, it appears that synonym expansion occurs to the query string,
which gives some unexpected results, as all the terms in the synonym
list are injected into the query. So, looking at the 2nd result again,
atripla is returned because it is a synonym with "efavirenz
emtricitabine" and truvada is a synonym with "emtricitabine
tenofovir", which doesn't seem to be the correct behavior. I
understand why this is occurring, the synonym term expansion is
occurring both index side and query side, but that doesn't seem right.
When I specify to use an analyzer without the synonym filter, this
goes away.

I am going to play around more with expand=false and see if the
behavior is any better.

Thanks,
Paul

ppearcy · November 7, 2011, 7:13pm

FYI, setting the search analyzer not to have the synonym filter and
only having this applied index time, does help with the poor search
results due to the search time synonym expansion.

However, the highlighting issue is still present. I opened a ticket to
track:

I hope to find some time to debug this and will update the ticket with
any details I find out.

Thanks,
Paul

On Oct 26, 1:45 pm, Shay Banon kim...@gmail.com wrote:

I will have a look at it and try and see where the problem is. Just a quick
note, you can configure a different index and search analyzer on a field (or
explicitly an analyzer when you search).

On Wed, Oct 26, 2011 at 8:48 PM, ppearcy ppea...@gmail.com wrote:

Hey,
I'm seeing a couple of issues that I have pointed out in this gist:
1317149’s gists · GitHub

The first issue that appears to be a bug is that highlighting can be
incorrect in the case of multi-term synonyms. The returned data for
the 2nd result is:
atripla

I reproduced this with term_vectors no and with_positions_offsets, so
appears to affect both highlighting paths.

Next, it appears that synonym expansion occurs to the query string,
which gives some unexpected results, as all the terms in the synonym
list are injected into the query. So, looking at the 2nd result again,
atripla is returned because it is a synonym with "efavirenz
emtricitabine" and truvada is a synonym with "emtricitabine
tenofovir", which doesn't seem to be the correct behavior. I
understand why this is occurring, the synonym term expansion is
occurring both index side and query side, but that doesn't seem right.
When I specify to use an analyzer without the synonym filter, this
goes away.

I am going to play around more with expand=false and see if the
behavior is any better.

Thanks,
Paul

ppearcy · November 9, 2011, 12:00am

FYI, now hitting a case where the search is actually failing. My guess
is that this and the other issue I mentioned in this thread are
related. To reproduce:

gist.github.com

https://gist.github.com/ppearcy/1349777

gistfile1.txt

curl -XDELETE 'http://localhost:9200/syntest/'

curl -XPOST localhost:9200/syntest -d '{
    "settings" : {
        "number_of_shards" : 1,
       "analysis" : {
              "analyzer": {
                     "syntest_analyzer":{"type":"custom","tokenizer":"standard","filter":["standard", "lowercase", "syntest_synonym", "stop", "english_snowball"]}, 
                     "syntest_analyzer_nosyn":{"type":"custom","tokenizer":"standard","filter":["standard", "lowercase", "stop", "english_snowball"]}, "dr_no_syn" : {"type":"custom","tokenizer":"standard","filter":["standard", "lowercase", "stop", "english_snowball"]}
              },

This file has been truncated. show original

On Nov 7, 12:13 pm, ppearcy ppea...@gmail.com wrote:

FYI, setting the search analyzer not to have thesynonymfilter and
only having this applied index time, does help with the poor search
results due to the search timesynonymexpansion.

However, the highlighting issue is still present. I opened a ticket to
track:Multi-term synonyms not highlighting correctly · Issue #1444 · elastic/elasticsearch · GitHub

I hope to find some time to debug this and will update the ticket with
any details I find out.

Thanks,
Paul

On Oct 26, 1:45 pm, Shay Banon kim...@gmail.com wrote:

I will have a look at it and try and see where the problem is. Just a quick
note, you can configure a different index and search analyzer on a field (or
explicitly an analyzer when you search).

On Wed, Oct 26, 2011 at 8:48 PM, ppearcy ppea...@gmail.com wrote:

Hey,
I'm seeing a couple of issues that I have pointed out in this gist:
1317149’s gists · GitHub

The first issue that appears to be a bug is that highlighting can be
incorrect in the case of multi-term synonyms. The returned data for
the 2nd result is:
atripla

I reproduced this with term_vectors no and with_positions_offsets, so
appears to affect both highlighting paths.

Next, it appears thatsynonymexpansion occurs to the query string,
which gives some unexpected results, as all the terms in thesynonym
list are injected into the query. So, looking at the 2nd result again,
atripla is returned because it is asynonymwith "efavirenz
emtricitabine" and truvada is asynonymwith "emtricitabine
tenofovir", which doesn't seem to be the correct behavior. I
understand why this is occurring, thesynonymterm expansion is
occurring both index side and query side, but that doesn't seem right.
When I specify to use an analyzer without thesynonymfilter, this
goes away.

I am going to play around more with expand=false and see if the
behavior is any better.

Thanks,
Paul