先看现象。redis-py 5.0 连 Redis Stack 7.4,FT.CREATE 建索引时 DIM 写的 768,写入 bge-m3 的 1024 维向量,报 Vector dimension mismatch,单条写入也一样。

这类报错背后常见的原因有几处,逐个排除就行。模型输出维度与索引声明不一致。也可能是FLOAT32 blob 的字节数按维度算错了。

另外,写入时字段名和索引定义对不上。

少数情况下是改过模型但没有重建索引。

上来先打印向量的实际长度

python -c "import numpy as np;print(np.array(v, dtype=np.float32).shape)"

随后按真实维度重建索引

redis-cli FT.CREATE idx ON HASH PREFIX 1 doc: SCHEMA vec VECTOR FLAT 6 TYPE FLOAT32 DIM 1024 DISTANCE_METRIC COSINE

再往下写入一条再查回来确认维度

python -c "print(r.hset('doc:1', mapping={'vec': v.tobytes()}))"

剩下的就是用 FT.INFO 检查索引的 DIM 配置

redis-cli FT.INFO idx

同事提醒我看一下最近一次发布,时间点确实对得上。

命令输出我都留了记录,免得改完记不清原来的值。

怎么算真的好了,看的是同一批现象。写入不再报维度错误,FT.INFO 里的 DIM 是 1024,KNN 查询能返回预期条数。

Redis 把向量存成二进制 blob,维度只体现在字节长度上,写错时错误信息很笼统,先看数组 shape 再看索引定义最快。线上能稳定复现的问题都不算难,难的是只在大流量下才出现的那种。

作者 9823189