[
https://issues.apache.org/jira/browse/SOLR-17736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18046034#comment-18046034
]
Chris M. Hostetter edited comment on SOLR-17736 at 12/18/25 12:40 AM:
----------------------------------------------------------------------
Hi Alessandro...
{quote}the pull request has been updated, starting from your idea.
{quote}
Cool. I'm going to need some time to really dig into it properly, but to
follow up on your one comment...
{quote}I added two parameters though as the Diversifying Knn query is expected
to work on "all parents".
So to support a filter on children based on parents metadata we need another
parameter.
{quote}
If i'm understanding correctly, what you're talking about here is:
* one param for identifying *ALL* the (valid) parent documents
** which your patch currently calls {{allParents}} ?
** which triggers the logic to use an (outer) Diversifying wrapper, and is
passed to the Diversifying wrapper
** equivalent to the {{of}} param of the existing child qparser
* one param for identifying the *desired* parents
** which your patch currently calls {{childrenOf}} ?
** which is optional, and used to augment the filter passed to the (inner) Knn
query prune
** -semi-equivalent to putting the entire (diversified) knn query inside of a
boolean query that has other clauses that filter based on parents...-
*** -except by pushing this down into the knn (child) filter, we help the
graph walk skip non-candidate (child) documents (based on whether their parents
are interesting) and improve the quality of the topK-
** equivilent to the client explicitly passing a {{preFilter="\{!child
of=...}desired_parents_criteria" ?}}
do i have that correctly?
if i am correct, then this added "filtering child vector docs by parent query
clauses" definitely makes sense – but i would really suggest you re-consider
the names.
In the custom plugin i use (modified into my patch) {{"childOf"}} was very
specifically chosen to be as close of a match the {{"of"}} param in the
existing {{"child"}} qparser as possible – so people use to dealing with
searching child docs would understand that it serves an equivalent purpose...
{noformat}
{!child of=$my_parent_filter ...}
{!knn childOf=$my_parent_filter ...}
{noformat}
perhaps something like...
* rename {{childrenOf -> parents.preFilter}}
* rename {{allParents -> childrenOf}}
?
was (Author: hossman):
Hi Alessandro...
{quote}the pull request has been updated, starting from your idea.
{quote}
Cool. I'm going to need some time to really dig into it properly, but to
follow up on your one comment...
{quote}I added two parameters though as the Diversifying Knn query is expected
to work on "all parents".
So to support a filter on children based on parents metadata we need another
parameter.
{quote}
If i'm understanding correctly, what you're talking about here is:
* one param for identifying *ALL* the (valid) parent documents
** which your patch currently calls {{allParents}} ?
** which triggers the logic to use an (outer) Diversifying wrapper, and is
passed to the Diversifying wrapper
** equivalent to the {{of}} param of the existing child qparser
* one param for identifying the *desired* parents
** which your patch currently calls {{childrenOf}} ?
** which is optional, and used to augment the filter passed to the (inner) Knn
query prune
** -semi-equivalent to putting the entire (diversified) knn query inside of a
boolean query that has other clauses that filter based on parents...-
*** -except by pushing this down into the knn (child) filter, we help the
graph walk skip non-candidate (child) documents (based on whether their parents
are interesting) and improve the quality of the topK-
** equivilent to the client explicitly passing a {{preFilter="\{!child of
...}" ?}}
do i have that correctly?
if i am correct, then this added "filtering child vector docs by parent query
clauses" definitely makes sense – but i would really suggest you re-consider
the names.
In the custom plugin i use (modified into my patch) {{"childOf"}} was very
specifically chosen to be as close of a match the {{"of"}} param in the
existing {{"child"}} qparser as possible – so people use to dealing with
searching child docs would understand that it serves an equivalent purpose...
{noformat}
{!child of=$my_parent_filter ...}
{!knn childOf=$my_parent_filter ...}
{noformat}
perhaps something like...
* rename {{childrenOf -> parents.preFilter}}
* rename {{allParents -> childrenOf}}
?
> Introduce support for KNN search on nested vector documents
> -----------------------------------------------------------
>
> Key: SOLR-17736
> URL: https://issues.apache.org/jira/browse/SOLR-17736
> Project: Solr
> Issue Type: New Feature
> Components: vector-search
> Affects Versions: 9.8
> Reporter: Alessandro Benedetti
> Priority: Major
> Labels: pull-request-available
> Attachments: SOLR-17736.patch
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> This issue tracks the work of introducing the support for KNN search on
> nested vector documents, surfacing the Lucene implementation in here:
> https://github.com/apache/lucene/pull/12434
> This allows both:
> -KNN retrieval of children, applying parent filters with no denormalisation
> needed
> -KNN retrieval of parents (based on children KNN, children level prefiltering
> and parent level prefiltering)
> It's one way of having multi-valued vectors per field, per document in Solr.
> More will come soon
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
