[
https://issues.apache.org/jira/browse/LUCENE-8647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sambhav Kothari updated LUCENE-8647:
------------------------------------
Description:
Initial proposal and discussion can be found here -
[http://mail-archives.apache.org/mod_mbox/lucene-java-user/201901.mbox/%3CCADitDkmnv4Vup5VG2ZwLUOv5VM=itu-y8eugxxmtoppzpcy...@mail.gmail.com%3E]
Currently the Explanation class has a toString method, but it doesn't seem to
have any method to output the explanation as a NamedList. Part of the reason is
that NamedList is a Solr only concept and it cannot exist in lucene. But this
leads to utility functions like
([https://github.com/apache/lucene-solr/blob/1d85cd783863f75cea133fb9c452302214165a4d/solr/core/src/java/org/apache/solr/response/transform/ExplainAugmenterFactory.java#L115]
and
[https://github.com/apache/lucene-solr/blob/1d85cd783863f75cea133fb9c452302214165a4d/solr/core/src/java/org/apache/solr/util/SolrPluginUtils.java#L400-L466]
which assume a particular structure about explanations.
Explanation should instead have a toMap method which returns a Map of key-value
pairs which can then be converted to a NamedList in Solr. This can be
exceptionally useful if we have a class inheriting from Explanation that adds
more attributes.
For example for Learning to Rank model explanations we can have a
ModelExplanation class which adds doc-specific feature scores and other machine
learning model explanations to the output. It also allows the ExplainAugmenter
and other classes to have a more generic way of getting an Explanation's data
in a structured format.
The way it currently does so is very ugly -
[https://github.com/apache/lucene-solr/blob/1d85cd783863f75cea133fb9c452302214165a4d/solr/core/src/java/org/apache/solr/response/transform/ExplainAugmenterFactory.java#L115]
This also implies that we shouldn't keep Explanation as a final class anymore.
Storing and parsing things like feature values in the explanation description
doesn't seem like the right way.
was:
Initial proposal and discussion can be found here -
[http://mail-archives.apache.org/mod_mbox/lucene-java-user/201901.mbox/%3CCADitDkmnv4Vup5VG2ZwLUOv5VM=itu-y8eugxxmtoppzpcy...@mail.gmail.com%3E]
Currently the Explanation class has a toString method, but it doesn't seem to
have any method to output the explanation as a NamedList. Part of the reason is
that NamedList is a Solr only concept and it cannot exist in lucene. But this
leads to utility functions like
([https://github.com/apache/lucene-solr/blob/1d85cd783863f75cea133fb9c452302214165a4d/solr/core/src/java/org/apache/solr/response/transform/ExplainAugmenterFactory.java#L115]
and
[https://github.com/apache/lucene-solr/blob/1d85cd783863f75cea133fb9c452302214165a4d/solr/core/src/java/org/apache/solr/util/SolrPluginUtils.java#L400-L466]
which assume a particular structure about explanations.
Explanation should instead have a toMap method which returns a Map of key-value
pairs which can then be converted to a NamedList in Solr. This can be
exceptionally useful if we have a class inheriting from Explanation that adds
more attributes.
For example for Learning to Rank model explanations we can have a
ModelExplanation class which adds doc-specific feature scores and other machine
learning model explanations to the output. It also allows the ExplainAugmenter
and other classes to have a more generic way of getting an Explanation's data
in a structured format.
The way it currently does so is very ugly -
[https://github.com/apache/lucene-solr/blob/1d85cd783863f75cea133fb9c452302214165a4d/solr/core/src/java/org/apache/solr/response/transform/ExplainAugmenterFactory.java#L115]
This also implies that we shouldn't keep Explanation as a final class anymore.
Storing and parsing things in explanation description doesn't seem like the
right way.
> Create a generic method in the Explanation class to get explanation attributes
> ------------------------------------------------------------------------------
>
> Key: LUCENE-8647
> URL: https://issues.apache.org/jira/browse/LUCENE-8647
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
> Affects Versions: 7.5
> Reporter: Sambhav Kothari
> Priority: Minor
>
> Initial proposal and discussion can be found here -
>
> [http://mail-archives.apache.org/mod_mbox/lucene-java-user/201901.mbox/%3CCADitDkmnv4Vup5VG2ZwLUOv5VM=itu-y8eugxxmtoppzpcy...@mail.gmail.com%3E]
>
> Currently the Explanation class has a toString method, but it doesn't seem to
> have any method to output the explanation as a NamedList. Part of the reason
> is that NamedList is a Solr only concept and it cannot exist in lucene. But
> this leads to utility functions like
> ([https://github.com/apache/lucene-solr/blob/1d85cd783863f75cea133fb9c452302214165a4d/solr/core/src/java/org/apache/solr/response/transform/ExplainAugmenterFactory.java#L115]
> and
> [https://github.com/apache/lucene-solr/blob/1d85cd783863f75cea133fb9c452302214165a4d/solr/core/src/java/org/apache/solr/util/SolrPluginUtils.java#L400-L466]
> which assume a particular structure about explanations.
>
> Explanation should instead have a toMap method which returns a Map of
> key-value pairs which can then be converted to a NamedList in Solr. This can
> be exceptionally useful if we have a class inheriting from Explanation that
> adds more attributes.
>
> For example for Learning to Rank model explanations we can have a
> ModelExplanation class which adds doc-specific feature scores and other
> machine learning model explanations to the output. It also allows the
> ExplainAugmenter and other classes to have a more generic way of getting an
> Explanation's data in a structured format.
>
> The way it currently does so is very ugly -
> [https://github.com/apache/lucene-solr/blob/1d85cd783863f75cea133fb9c452302214165a4d/solr/core/src/java/org/apache/solr/response/transform/ExplainAugmenterFactory.java#L115]
>
> This also implies that we shouldn't keep Explanation as a final class
> anymore. Storing and parsing things like feature values in the explanation
> description doesn't seem like the right way.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
