jaccard_similarity

Generic Description

Compares two lists as sets using intersection over union. It is documented separately because similarity orientation, vector dimensions, and set semantics directly affect ranking and interpretation.

Simple example:

RETURN jaccard_similarity(['incident', 'runbook'], ['incident', 'guide']) AS value

Consumer-Level Explanation

Use it for tag, neighbor, or capability overlap where duplicate counts should not dominate. Prefer this function when symbolic graph filters and similarity evidence should remain in one auditable Cypher pipeline.

More Detailed Explanation

jaccard_similarity 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 jaccard_similarity 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,
       jaccard_similarity(metadata_keys, ['kind', 'lang', 'owner']) AS metadata_fit
ORDER BY metadata_fit 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