Global properties for BatchRetrieve

[seanmacavaney]

Describe the bug

It seems that when building multiple BatchRetrieve objects, only the properties from the newest one are applied. E.g., if I do:

bm25_nostem = pt.BatchRetrieve(index_nostem, wmodel='BM25', verbose=True, properties={
    'tokeniser': 'UTFTokeniser',
    'termpipelines': '',
})
bm25_stem = pt.BatchRetrieve(index_stem, wmodel='BM25', verbose=True, properties={
    'tokeniser': 'UTFTokeniser',
    'termpipelines': 'SpanishSnowballStemmer',
})

termpipelines=SpanishSnowballStemmer is applied to both retrievers.

To Reproduce
Steps to reproduce the behavior:

1. Which index: E.g., any two indices that used different termpipelines when constructed
2. Which retrieval: Observed with BM25
3. What pipeline: BatchRetrieve

Expected behavior

The properties should be applied to the corresponding retrievers only.

Documentation and Issues

• I have checked the PyTerrier documentation for relevant content
• I have checked for previous relevant PyTerrier issues

Additional context
Observed when conducting experiments on irds:wikir/es13k/test, but this behavior seems like it would happen regardless of language.

[cmacdonald]

20 years of technical debt around a global configuration state... 👎

I think the workaround is if you start using the bm25_nostem before instantiating bm25_stem, the problem goes away.

Stemming variations are the most common places where this can arise for BatchRetrieve. There may be other cases for FeaturesBatchRetrieve

The upstream issue is terrier-org/terrier-core#122

[cmacdonald]

@seanmacavaney when you have a chance, could you review terrier-org/terrier-core#181

[cmacdonald]

So I think this is now addressed, and the notebooks could be updated. Two points:

• I dont think the tokeniser property needs to be adjusted during retrieval?
• termpipelines are identified automatically from the index, and can be overridden by controls.

Does the documentation need updated?

[cmacdonald]

notebook now updated.