# Similarity search returns chunks that all have exactly the same distance value

**URL:** <https://forum.weaviate.io/t/similarity-search-returns-chunks-that-all-have-exactly-the-same-distance-value/1015>\
**Category:** Support\
**Tags:** bug\
**Created:** [November 24, 2023, 11:03am UTC](https://forum.weaviate.io/t/similarity-search-returns-chunks-that-all-have-exactly-the-same-distance-value/1015 "2023-11-24T11:03:06Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![A\_S](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.weaviate.io/a_s/32/690_2.png) [@A\_S](https://forum.weaviate.io/u/A_S)\
**Post date:** [November 24, 2023, 11:03am UTC](https://forum.weaviate.io/t/similarity-search-returns-chunks-that-all-have-exactly-the-same-distance-value/1015/1 "2023-11-24T11:03:06Z")

</div>

There is something not quite right with the matches I’m getting when using the weaviate similarity search. After making the following query, the resulting chunks I get all have the same distance value (up to the very last decimal) - it doesn’t matter which max\_matches value I choose, the distance for every chunk is still the same. The chunks themselves are quite different though, and if I manually perform a regular dot product between the embedded query and the embedded chunks, I get different resulting dot product for the every chunk.

```auto
result = self.client.query \
            .get(.....chunks with some properties.....) \
            .with_where(where_clause) \
            .with_near_vector({"vector": embedded_query}) \
            .with_limit(max_matches) \
            .with_additional(['distance', 'id']) \
            .do()

```

In the schema, distance is defined as “dot”. Also, I’m using ada-002 openai embeddings to embed the chunks and the queries. (however, the chunks are not being vectorized by weaviate text2vec openai but separately by calling on openai embedding endpoint- could that maybe be an issue?)

In general, what exactly happens underneath with\_near\_vector?

---

<div class="post-metadata">

**Author:** ![jphwang](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.weaviate.io/jphwang/32/38_2.png) [@jphwang](https://forum.weaviate.io/u/jphwang)\
**Post date:** [November 24, 2023, 2:58pm UTC](https://forum.weaviate.io/t/similarity-search-returns-chunks-that-all-have-exactly-the-same-distance-value/1015/2 "2023-11-24T14:58:06Z")

</div>

Hi @A_S and welcome!

From what you describe, it sounds as though maybe something went awry with the vector generation when adding the data to Weaviate, and the underlying vectors might have been identical somehow.

Could you try retrieving the stored vectors back (like shown [here](https://weaviate.io/developers/weaviate/search/basics#retrieve-the-object-vector)), with `.with_additional(['distance', 'id', 'vector'])` and see if the vectors are different underneath?

If so I would suspect there was an issue with the vector generation script, or with the insertion script while looping through the dataset.

Let us know how you go, and if it’s not those issues we can tackle them further.

Cheers!  
JP

---

<div class="post-metadata">

**Author:** ![A\_S](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.weaviate.io/a_s/32/690_2.png) [@A\_S](https://forum.weaviate.io/u/A_S)\
**Post date:** [November 27, 2023, 7:31am UTC](https://forum.weaviate.io/t/similarity-search-returns-chunks-that-all-have-exactly-the-same-distance-value/1015/3 "2023-11-27T07:31:37Z")

</div>

Thank you for your quick response! You are right, the vectors underneath were identical for different text-chunks, thus the same distance score makes sense. Will tackle the vector script.

---

<div class="post-metadata">

**Author:** ![jphwang](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.weaviate.io/jphwang/32/38_2.png) [@jphwang](https://forum.weaviate.io/u/jphwang)\
**Post date:** [November 29, 2023, 10:41am UTC](https://forum.weaviate.io/t/similarity-search-returns-chunks-that-all-have-exactly-the-same-distance-value/1015/4 "2023-11-29T10:41:25Z")

</div>

Yay, I’m glad we got to the bottom of that. Cheers!