---
title: jaccard_similarity
url: https://nexyron.tech/docs/cypher/functions/vector-and-similarity/jaccard-similarity
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 a
---

# 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:

```cypher
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.

```cypher
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