common_neighbors

Generic Description

Counts the intersection size of two list-as-set inputs. It is documented separately because similarity orientation, vector dimensions, and set semantics directly affect ranking and interpretation.

Simple example:

RETURN common_neighbors(['a', 'b'], ['b', 'c']) AS value

Consumer-Level Explanation

Use it for transparent structural overlap before choosing a normalized similarity score. Prefer this function when symbolic graph filters and similarity evidence should remain in one auditable Cypher pipeline.

More Detailed Explanation

common_neighbors keeps similarity scoring in the same Cypher pipeline as symbolic graph filters and document metadata checks. That lets a query combine labels, relationships, time filters, and embedding or set overlap scores without asking a client to reconcile separate result sets.

Advanced Example

This example applies common_neighbors after symbolic graph filtering, which keeps hybrid retrieval constraints and similarity scoring in one visible pipeline.

MATCH (d:Document)
WITH d, keys(properties(d.metadata)) AS metadata_keys
RETURN d.title AS document,
       common_neighbors(metadata_keys, ['kind', 'lang', 'owner']) AS matched_metadata_fields
ORDER BY matched_metadata_fields DESC

Real Use Cases

• semantic ranking over embedded documents after graph/time filtering
• link-prediction features based on shared neighbors or metadata overlap
• hybrid retrieval where symbolic constraints and vector scores are both visible

Real Limitations And Tradeoffs

• vector functions require compatible dimensions and meaningful embedding spaces
• set-similarity functions treat lists as sets and may ignore duplicate frequency
• a high similarity score is evidence, not proof of domain equivalence