Error parsing vector similarity query: query vector blob size (16384) does not match index's expected size (4096).

[mingMens]

Spring AI 0.8.1 + ollama + redis

return vectorStore.similaritySearch(searchRequest) .stream() .map(Documents::fromDocument) .toList();

[dispatcherServlet] : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed: redis.clients.jedis.exceptions.JedisDataException: Error parsing vector similarity query: query vector blob size (16384) does not match index's expected size (4096).] with root cause

redis.clients.jedis.exceptions.JedisDataException: Error parsing vector similarity query: query vector blob size (16384) does not match index's expected size (4096).

[tzolov]

@mingMens, can you please share what model did you use with Ollama and what is Redis version?

Did you start with a fresh/empty Redis or you had some embeddings already stored from pervious models?

I'm not familiar with Redis's vector store support and the documentation doesn't mention the upper dim limits? is there any reference.

In the meantime you can pick any other Embedding Client that offers a lower dimensionality.

For example you can add the local embedding client by adding its dependency:

<dependency>
   <groupId>org.springframework.ai</groupId>
   <artifactId>spring-ai-transformers-spring-boot-starter</artifactId>
</dependency>

and disable the Ollama embedding client: spring.ai.ollama.embedding.enabled=false.

make sure that you have clean Redis DB.

[tzolov]

@mingMens , also you try to switch to Spring AI 1.0.0-SNAPSH ?

[mingMens]

Thank you for your reply. Mine is a new redis

version: "3"
services:
  redis-stack:
    image: redis/redis-stack
    volumes:
      - redis-data:/data
    ports:
      - "6379:6379"
      - "8001:8001"
  postgres:
    image: postgres
    volumes:
      - postgresql-data:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: "interview-assistant"
      POSTGRES_USER: "postgres"
      POSTGRES_PASSWORD: "postgres"
    ports:
      - "5432:5432"
volumes:
  redis-data:
  postgresql-data:

spring:
  ai:
    ollama:     
      base-url: http://127.0.0.1:11434
      chat:
        model: qwen:1.8b

How to reduce dimensions？

[tzolov]

@mingMens I'm afraid that the Ollama API EmbeddingRequest doesn't provide any options for controlling the embedding dimensions. You can try to raise an issue on their GH.

Also, I'm not sure what is the Redis embedding size limit? Is it possible to configure a lagers size?

Currently, the only option I can suggest is to use one of the other embedding clients. For example add the ONNX, Local EmbeddingClient

<dependency>
   <groupId>org.springframework.ai</groupId>
   <artifactId>spring-ai-transformers-spring-boot-starter</artifactId>
</dependency>

and disable the Ollama Embedding Client:

spring.ai.ollama.embedding.enabled=false

Please, let me know if this help?

[walkingcoding]

I have the same issue, debugging found that create index and query must use the same model. otherwise, this issue may occur.

[tzolov]

As explained above, there is nothing we can do on the Spring AI side to control the dimensionality of the Ollama API, please raise issue on their GH repo to support this.

[flevance]

I also encountered this issue before, which was caused by junk data in Redis. You can try executing the Redis command 'FT. LIST' to view the index, and then 'FT-INFO spring ai index' to find the result for the DIM item. Your DIM should be 4096. This is not equal to the dimension you used with Ollama. You need to delete the spring ai index in Redis and rebuild the data. Then re vectorize. As shown in line 409 of Figure, if ftList exists, it will not be created. So you need to delete and recreate it 我之前也遇到了这个问题，是因为Redis里面存在垃圾数据导致的，你可以尝试执行Redis命令 FT._LIST 查看索引，然后 FT.INFO spring-ai-index，找到DIM这项的结果，你的DIM应该是4096。这和你使用ollama的dimension不相等。你需要在Redis中把spring-ai-index这个索引删除掉，重建数据。然后再重新向量化。如图409行所示，如果ftList存在，就不会创建。所以你要删除后重新创建

[markpollack]

Doesn't look like anything we can do, mismatches between embedding model vector sizes and what sizes are allowed to be stored in vector databases will be an ongoing issue.