Question on the vector graph search query

[adelanl]

    OPTIONAL MATCH (chunk)-[:HAS_ENTITY]->(e)
    WITH e, count(*) AS numChunks 
    ORDER BY numChunks DESC 
    LIMIT {no_of_entites}

    WITH 
    CASE 
        WHEN e.embedding IS NULL OR ({embedding_match_min} <= vector.similarity.cosine($query_vector, e.embedding) AND vector.similarity.cosine($query_vector, e.embedding) <= {embedding_match_max}) THEN 
            collect {{
                OPTIONAL MATCH path=(e)(()-[rels:!HAS_ENTITY&!PART_OF]-()){{0,1}}(:!Chunk&!Document&!__Community__) 
                RETURN path LIMIT {entity_limit_minmax_case}
            }}
        WHEN e.embedding IS NOT NULL AND vector.similarity.cosine($query_vector, e.embedding) >  {embedding_match_max} THEN
            collect {{
                OPTIONAL MATCH path=(e)(()-[rels:!HAS_ENTITY&!PART_OF]-()){{0,2}}(:!Chunk&!Document&!__Community__) 
                RETURN path LIMIT {entity_limit_max_case} 
            }} 
        ELSE 
            collect {{ 
                MATCH path=(e) 
                RETURN path 
            }}
    END AS paths, e

This is a snippet from the VECTOR_GRAPH_SEARCH_QUERY from data source context retrieval.
From I am able to gather, here is where we take not just the entities, but also the relations between them.
Hence, we have the ELSE here to just return the entities without the relationships if the entity embeddings match the query within a satisfiable threshold. It also looks like we grab more when the entities are well above the satisfaction threshold (by hopping twice? and increasing the limit).

If that understanding is correct, then I guess this might be more of a general cypher question for my learning, but why is the path match denoted by
path = (e)(()-[rels:!HAS_ENTITY&!PART_OF]-()){{0,2}}(:!Chunk&!Document&!__Community__)
?

What would be wrong with rewriting this query as:
path = (e) -[]-{{0,2}} (:__Entity__)
(we can just rely on the landing node restriction since the incoming nodes e are always entities from chunks and we want every relationship between entities, but this is not what I am inquiring about)

I know the current path definition hops on the pattern fragment, rather the other hops within the individual relationship, but we are at most hopping ahead by two entities, and the pattern fragment just defines the restriction. I can't figure a more concise way to ask the question. Is there a particular reason for the current path definition here? Both result in the same output with my toy entity graph.

Thank you

[adelanl]

I have come to understand the effects of the path definition more, and come to discuss them and make a correction.

path = (e) -[!HAS_ENTITY]-{{0,2}} (:__Entity__)
syntax pattern can be kept without incurring changes, except I will point out that at least !HAS_ENTITY has to be kept when the relationship hop counter exceeds 1 (and !PART_OF must also be left in if it exceeds 2). That is because we collect every node along the path. When restricting (:Entity) to (:__Entity) as start to end, a (:Chunk) node may be in the middle. Hence, the need for !HAS_ENTITY (when hopping past 3 into 4+ you would need PART_OF too since you would (ent)-(chunk)-(doc)-(chunk)-(ent)).

the ()-[]-{0,x}() pattern is functionally the same as the ()(()-[]-()){0,x}() since intermediate nodes are anonymous and the pattern fragment is only specifying one relationship hop (extra typing on intermediate nodes would change outputs and function). Only difference is how the two patterns are parsed and executed in query planner...

I would recommend changing path patterns in cases to
path = (e) -[]-{{0,1}} (:__Entity__) and path = (e) -[:!HAS_ENITY]-{{0,2}} (:__Entity__) respectively
for readability and understanding, but it doesn't really matter once you figure it out.

I am still confused as to the motivation case condition logic however, and why we only hop 2 when similarity is high. Are those limits arbitrary? Has there been any testing on the effects on it? Am I digging too deep? I don't know, but I'll leave this open to see if anyone drops some insight on that.
Thanks