Redis 向量检索怎样选择距离度量

Redis 向量检索选择距离度量时，我会先服从 embedding 模型的训练目标和使用说明，再确定是否归一化，最后配置索引。只看方向通常比较 COSINE；模型要求点积时采用 IP；向量空间中的坐标差异有意义时考虑 L2。不能因为一组数据在某个度量下“分数好看”就更换规则。

官方地址：https://redis.io/docs/latest/develop/ai/search-and-query/vectors/。本文讨论具有 Redis Search 向量索引能力的环境，不把普通键值查询等同于向量检索；示例未在本机运行，也不代表任何真实线上事故。

排序看起来反常时，我先看距离方向

我最想先排除的误解，是把返回的距离当成“越大越相似”的业务得分。Redis 的这些向量距离按更小表示更近来解释。若应用把返回值倒序展示，用户看到的就可能是“检索成功但答案不相关”，问题还没到模型质量那一层。

下面用一个假设的知识库迁移来讨论：旧应用把点积相似度从大到小排，新接口接入 Redis 的距离字段后仍沿用倒序。随后团队又更换 embedding 模型，却没有同步记录归一化约定。此时改变 HNSW 参数无法解释排序语义，应该先把距离方向、模型与预处理拆开。

对我来说，第一项取舍不是 COSINE 与 IP 谁更高级，而是接口到底返回了距离还是转换后的业务分数。本文代码把字段明确命名为 distance，并显式升序；它不是概率，也不是相关性的百分比。

模型切换比索引参数更早改变含义

沿着这个假设案例回看，迁移前使用旧模型及其预处理；迁移时只保留相同维度；迁移后继续沿用旧阈值。这里最容易忽略的条件是：同样维度不代表同样向量空间。我不会把新模型查询向量与旧模型文档向量直接混在一起比较。

我会在索引配置旁记录模型标识、维度、向量数据类型和预处理约定。若模型文档要求归一化，查询和文档都执行同一约定；若长度携带模型希望保留的信息，则不能为了套用 COSINE 的直觉而擅自消掉长度。

这也解释了我的一个有条件判断：模型说明不清楚时，先补齐模型的相似度约定，而不是默认所有文本向量都该用 COSINE。距离选择属于模型契约，索引算法属于检索实现，两者不应混为同一个开关。

用向量长度解释三种选择

为了看清长度影响，我取三个非零数学示例：查询 q=(1,0)，候选 a=(1,0)、b=(2,0)。a、b 与 q 同方向，因此余弦距离都为零；若直接使用未归一化点积，a 的 IP 距离为零，b 为负一，b 反而更靠前。这是公式推导，不是 Redis 运行输出。IP 距离出现负数本身并不意味着查询失败。

如果三者都按单位长度归一化，a 和 b 就不再靠长度拉开差别。对单位向量，点积与余弦的排序相同，L2 关系也可得到相同的精确近邻排序；但不能因此把不同度量的原始返回值和业务阈值直接互换。有限精度、并列距离及近似检索还可能影响实际返回顺序。

零向量不能按通常的余弦公式解释，我会在生成向量的应用边界拒绝这类输入，而不是让业务阈值替它兜底。本文不讨论具体模型推荐，也不声称某个距离天然提高语义检索质量。

把距离固定在索引，把查询值交给参数

DISTANCE_METRIC 属于向量字段定义。KNN 中的 K 表示目标近邻数，PARAMS 负责把查询向量的二进制数据交给表达式；它不是临时把某字段从 COSINE 切为 IP 的地方。需要比较不同距离时，我会使用独立索引或独立字段，不覆盖现有生产索引。

以下 Python 片段假设测试环境已有名为 idx:notes_cosine 的 HASH 索引：字段 embedding 定义为 VECTOR FLAT 6 TYPE FLOAT32 DIM 3 DISTANCE_METRIC COSINE，并已写入同样编码、同样预处理的三维向量。它只展示查询，不创建、删除或更改索引。三维数值用于说明接口，不是文本模型输出。

import os
import struct
import redis

# 沿用测试环境的连接设置，不把连接凭据写在文章中
client = redis.Redis.from_url(os.environ["REDIS_URL"], decode_responses=False)
try:
    # 此例约定服务端为小端环境；3个FLOAT32对应12字节
    query_blob = struct.pack("[KNN 3 @embedding $vec AS distance]",
        "PARAMS", 2, "vec", query_blob,
        "SORTBY", "distance", "ASC",
        "RETURN", 1, "distance",
        "LIMIT", 0, 3,
        "DIALECT", 2,
    )
    print(result)  # 输出保留原始返回结构，不假定它是相似度百分比
finally:
    # 连接失败或服务端拒绝查询时异常上抛，仍释放客户端资源
    client.close()

PARAMS 2 中的 2 是后续参数名与参数值占用的两个参数项，不是向量维度；维度仍由索引字段的 DIM 3 约束。HASH 中 FLOAT32 向量的二进制编码、字节序和查询表示必须一致，不能把字符串“1,0,0”当作上面的向量字节。

FLAT 与 HNSW 是索引算法选择，不是距离的别名。上例采用 FLAT 表达基础契约；若已有 HNSW 索引，需要再考虑近似搜索的召回取舍，但不能把近似误差和排序方向错误当成同一种问题。

以后换模型时保留哪些约定

我会把“模型、维度、编码、归一化、距离、排序方向、阈值解释”作为一组记录。换模型或距离后，用独立索引和有业务标注的样本重新建立判断依据；旧阈值先不继承，更不会只改一个参数便声称迁移质量已经改善。

这套取舍适合准备接入向量索引、从其他检索接口迁移或解释异常排序的人。它不替代模型评价，也不提供生产性能数字。我的结论是：先让数学含义与模型契约一致，再谈索引算法和查询效率。

COSINE 距离能直接当置信度吗？

不能。距离描述向量关系，不是答案正确的概率。应用若转换为显示分数，需单独说明转换规则，不能伪装成模型置信度。

只增加 K，能修复度量选错吗？

不能。K 改变取多少近邻，不改距离定义；结果数量、排序语义和业务相关性是三项不同约束。

更换距离后，范围查询半径能沿用吗？

不应直接沿用。范围查询的半径按对应字段的度量解释；即使精确排序相同，数值尺度也可能不同。

Redis 官方查询写法：https://redis.io/docs/latest/develop/ai/search-and-query/query/vector-search/；Python 客户端向量示例：https://redis.io/docs/latest/develop/clients/redis-py/vecsearch/。