Does this work when filtering over both a nested & top level metadata?

Something like:

{ "bool": { "filter" : [{"nested" : {"path": ..., {...}}}, {"term": {"top-level-thing": "foo"}}]}}

?

If we run a query like this where this a filter on both parent and nested metadata, it will NOT work, and return 0 results:

{
    "query": {
        "nested": {
            "path": "paragraphs",
            "query": {
                "knn": {
                    "field": "paragraphs.vector",
                    "query_vector": [
                        1,
                        1,
                        1
                    ],
                    "k": 2,
                    "filter": [
                        {
                            "match": {
                                "paragraphs.language": "FR"
                            }
                        },
                        {
                            "match": {
                                "title": "title2"
                            }
                        }
                    ]
                }
            },
            "inner_hits": {
                "size": 2
            }
        }
    }
}

I can not think of anyway to support both filters like this. I suggest we can document this as a limitation, and advice to use a filter for parent's metadata as a post-filter. What do you think?

Its weird to me that this doesn't work:

POST test/_search 
{
    "query": {
        "nested": {
            "path": "nested",
            "query": {
                "knn": {
                    "field": "nested.vector",
                    "query_vector": [
                        1,
                        1,
                        1,
                        1,
                        1
                    ],
                    "k": 2,
                    "filter": [
                        {
							"nested": {
								"path": "nested",
								"query": {
									"match": {
										"nested.language": "EN"
									}
								}
							}
                        }
                    ]
                }
            },
            "inner_hits": {
                "size": 2
            }
        }
    }
}

It seems to me that filter should have a "top level view" of the docs and allow you to have a separate query that gets executed that just works and joins to the appropriate knn level. I am not sure if that is possible given the current API. If its truly a hard restriction, we should indicate it.

@benwtrent Sorry, I got confused with your last comment.

Why is it weird for you that the query you provided above doesn't work? I think it is mal-formed query, we already provided "nested" context on top, so knn filter should not contain "nested". That's how other nested queries work: inside nested query, we query only on nested metadata, and to my mind , it was wrong to allow filter on parents' metadata.

It seems to me that filter should have a "top level view" of the docs and allow you to have a separate query that gets executed that just works and joins to the appropriate knn level.

Can you please clarify what it means.

@mayya-sharipova I need to think a bit more. Its difficult to fully resolve the user experience between the top-level kNN object (which has NO signal that its nested) and a query which obviously has a nested context as its inside a nested query.

This & simplicity was why I thought (and mostly still do), think filtering on top-level metadata by default is most useful.

I am not even sure how script_score actually works in these various scenarios.

Originally, Jim proposed a new query type that would allow a nested context to join back to the parent docs and then provide a parent level filter (reverse_join_parent type thing). Maybe that is the only way we can do this.

But I do not think we should ship this without the ability to filter on both (parent & nested) at the same time.

Here is that old POC of jim's: main...jimczi:elasticsearch:nested_dense_vector

I honestly am not sure how to square this well.

But, I do think one of the following is going to be necessary:

• The filter for kNN's need to be treated like a top-level query, meaning it completely ignores its nested context and allows for a completely separate set filters. This is admittedly difficult (maybe impossible with how we do parent ID joining while search the graph).
• We detect that somebody is doing nested search and try to rewrite it so that it works :/ (yeah, I am not sure this is actually possible, again)
• We keep the current behavior, but add a reverse_nested query so that folks can do a complex combination of nested & higher level filters. I am unsure if this is possible while maintaining current BWC.

These are some ideas, I realize that they are various levels of impossible/difficult. We can talk synchronously to brain storm further if you want.

Lucene doesn't break here?

I guess we just do the right thing? I know Lucene will complain if we attempt to query things that are or are not child docs vs. parent docs. etc.

Indeed, Lucene ToChildBlockJoinQuery doesn't allow a filter that can also match child docs. But in our ToChildBlockJoinQueryBuilder::doToQuery, I've added extra parentFilter to ensure that only parents docs can match:

// ensure that parentQuery only applies to parent docs by adding parentFilter
return new ToChildBlockJoinQuery(Queries.filtered(parentQuery, parentFilter), parentBitSet);

Could we add a test/scenario where we are doing a filter on another nested field?

so, assume we have

{
  "nested_1": {"properties": {"vector"....}},
  "nested_2": {"properties": {"product_name":....}}
}

Then the filter would be:

filter: [{ nested: {path: nested_2, query: {match: { nested_2.product_name: "FR" }}] or something (unsure if I got all the nesting right...)

Basically, I think our "auto-nested check" should only apply in the case of the filter matching the vectors nested context. Any other filter should be applied as a "top level" filter and return the relevant parent doc ids (I am unsure if this is exactly the case, but it seems to be right now).

of course, replicate such a test in the knn query tests if possible.

Thanks for bringing this up.

In acbfccd I've added a test for nested sibling fields. Currently:

• For nested knn query, we can NOT filter on nested sibling fields, as the query DSL itself doesn't allow it.
• For top level knn search, we can filter on nested sibling fields, and effectively addressing the 128803 issue.

Are you not happy with this behaviour, are you saying we should NOT allow filter on sibling nested fields in nested knn search and throw an exception, which would mean we should close 128803 as not going to implement?

For nested knn query, we can NOT filter on nested sibling fields, as the query DSL itself doesn't allow it.

This is weird. A separate nested field should be able to join up to the parent level, indicate the parents that are filtered and we join back down to the child level to filter on the vectors. I don't know how to express that in the DSL, but we should document it as a limitation.

@benwtrent Notice how for nested query the DSL itself doesn't allow to filter on nested sibling fields, as the top level query:nested:path sets the parent context.

@mayya-sharipova thank you.

I was thinking it would be possible via boolean with two separate nested contexts.

They key issue is that with kNN search, we need to be clear that its within a SINGLE nested context (either top level, or its own context).

That gets tricky, and maybe we can make it better in the future. But the current compromise unblocks some folks.

I can not think of any way to support pre-filtering on nested sibling fields in knn query. We can do the following, but it would be post-filter:

  - do:
      search:
        index: test
        body:
          _source: false
          query:
            bool:
              must:
                - nested:
                    path: nested
                    query:
                      knn:
                        field: nested.vector
                        query_vector: [-0.5, 90.0, -10, 14.8, -156.0]
                        k: 10
              filter:
                - nested:
                    path: nested2
                    query:
                      bool:
                        filter:
                          - match:
                              nested2.key: "category"
                          - match:
                              nested2.value: "domestic"

Here with the current implementation we can query nested sibling fields.

I was sort of hoping that we could do something similar in the nested query since we look to the parent level. But it gets too complicated given the nested context?

I was sort of hoping that we could do something similar in the nested query since we look to the parent level. But it gets too complicated given the nested context?