一、一个反直觉的检索事故

去年我在构建一个企业知识库检索系统时，遇到了一个令人费解的现象。用户搜索"如何优化PostgreSQL的写入性能"，系统却将一篇题为《PostgreSQL与MySQL在OLTP场景下的全面对比》的文档排在了第一位，而真正相关的《PostgreSQL写入优化实战指南》反而屈居第三。

两篇文章都提到了PostgreSQL。排名更高的那篇文档更长、覆盖面更广，却并非用户想要的答案。问题出在哪里？是Embedding模型不够强大？还是相似度计算本身存在某种系统性偏差？

经过数周的实验和源码级排查，我逐渐意识到：我们太过迷信"余弦相似度"这个数字了。在向量空间里，文档长度、语义相关性、关键词密度这三股力量从未停止过博弈，而大多数开发者对此浑然不觉。这篇文章，我想把这场博弈的底牌彻底揭开。

---

二、第一重博弈：向量长度——沉默的相似度操纵者

2.1 为什么长度会影响相似度

让我们从一个极简的数学事实出发。假设查询向量是 q，文档向量是 d，余弦相似度的公式是：

cos_sim(q, d) = (q · d) / (||q|| * ||d||)

注意到分母中的 ||d||。当文档向量很长时——也就是说，当文档包含大量token，经过平均池化或累加后得到高模长向量——分母会变大，相似度分数倾向于被压缩。

但等等，这只是一半真相。另一半真相更隐蔽：在Sentence-BERT这类模型中，长文档的向量往往不只是模长更大，其方向分布也更分散。这是因为长文本包含更多语义子空间，不同主题的成分在向量中相互拉扯，导致与单一查询的对齐度下降。

我在 all-MiniLM-L6-v2 上做过一组对照实验：

from sentence_transformers import SentenceTransformer
import numpy as np

model = SentenceTransformer('all-MiniLM-L6-v2')

query = "如何优化数据库写入性能"
short_doc = "优化PostgreSQL写入性能的方法包括批量插入、调整WAL参数、使用UNLOGGED表等。"
long_doc = (
    "PostgreSQL是一个功能强大的开源关系型数据库管理系统，由Michael Stonebraker的团队开发，"
    "支持丰富的数据类型和扩展。在OLTP场景中，它与MySQL各有优劣。优化PostgreSQL写入性能的方法"
    "包括批量插入、调整WAL参数、使用UNLOGGED表等。此外，分区表、连接池和异步提交也能提升吞吐量。"
    "在数据仓库场景下，列存扩展如cstore_fdw可以提供更好的分析性能..."
)

q_vec = model.encode(query)
s_vec = model.encode(short_doc)
l_vec = model.encode(long_doc)

def cos_sim(a, b):
    return float(np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b)))

print(f"短文档相似度: {cos_sim(q_vec, s_vec):.4f}")
print(f"长文档相似度: {cos_sim(q_vec, l_vec):.4f}")
# 典型输出：短文档 0.6823，长文档 0.5912

看到没有？长文档明明包含了短文档的全部内容，相似度反而更低。这不是模型的问题，这是几何的必然。

2.2 L2归一化：解药还是毒药

面对长度偏差，一个常见的解决方案是：对所有向量做L2归一化，然后改用点积（dot product）作为相似度。归一化后，所有向量被强制映射到单位球面上，长度因素被彻底消除。

但这里有一个致命陷阱——归一化消灭了"长度信息"本身，而长度信息有时候恰恰是有价值的。

考虑这个场景：查询是"Python"，文档A是"Python"，文档B是"Python是一种广泛使用的高级编程语言，由Guido van Rossum创建，支持多种编程范式…" 归一化后，两者与查询的点积可能非常接近。但从信息检索的角度，文档B的置信度应该更高，因为它提供了更多上下文验证。

我的建议是：不要无条件归一化。在语义搜索场景，可以尝试一种混合策略——

def hybrid_similarity(q, d, alpha=0.7):
    """
    alpha: 余弦相似度的权重
    1-alpha: 长度对齐项的权重
    """
    cos = np.dot(q, d) / (np.linalg.norm(q) * np.linalg.norm(d))
    # 长度对齐项：惩罚与查询长度差异过大的文档
    len_ratio = min(len_q, len_d) / max(len_q, len_d)
    return alpha * cos + (1 - alpha) * len_ratio

这不是完美的公式，但它提醒我们：长度不是敌人，盲目消除长度信息才是。

---

三、第二重博弈：语义相关性——向量空间的暗流

3.1 当Embedding开始"过度联想"

Embedding模型的核心能力是捕捉语义相关性，但这种能力是把双刃剑。它不仅能识别同义词和近义词，还会建立大量人类难以直觉感知的关联。

举个例子，查询"苹果公司的最新财报"。理想情况下，相关文档应该讨论Apple Inc.的财务数据。但Embedding模型可能会给以下文档打出高分：

• 《苹果种植业的市场趋势分析》（字面包含"苹果"）
• 《科技巨头2024年Q3营收概览》（语义关联"公司+财报"）
• 《乔布斯传：从车库到万亿美元》（人物关联）

第一种是关键词干扰，第二种是理想的语义泛化，第三种则是Embedding的"过度联想"。在向量空间里，"苹果"和"乔布斯"的向量夹角可能出奇地小，因为模型在训练时见过太多两者共现的句子。

3.2 相关性不是单一维度

更麻烦的是，"语义相关性"本身是多维度的。我将其拆解为至少三个层次：

层次	说明	检索风险
主题相关性	讨论同一宏观主题	宽泛匹配，精度低
意图相关性	满足同一信息需求	需要理解查询背后的目的
细粒度相关性	包含具体答案实体	对RAG至关重要，最难捕捉

在标准的密集检索（Dense Retrieval）中，Embedding对"主题相关性"的捕捉最强，对"细粒度相关性"最弱。这就是为什么在RAG系统中，单纯依赖向量检索往往召回大量"说了和查询相关领域的话，但完全没回答具体问题"的文档。

3.3 一个诊断工具：层级相似度分析

我写过一个小工具来诊断相关性错配问题：

import numpy as np
from sklearn.decomposition import PCA

def hierarchical_similarity(query_vec, doc_vec, model_dims=384, n_components=3):
    """
    将向量分解到不同主成分层级，分别计算相似度。
    帮助诊断相关性错配来自哪个语义层级。
    """
    # 模拟不同层级的子空间（实际应用中应使用训练数据拟合PCA）
    results = {}
    
    # 第一层：粗略主题方向（低频主成分）
    coarse_q = query_vec[:model_dims//3]
    coarse_d = doc_vec[:model_dims//3]
    results['coarse'] = np.dot(coarse_q, coarse_d) / (
        np.linalg.norm(coarse_q) * np.linalg.norm(coarse_d)
    )
    
    # 第二层：中粒度语义
    mid_q = query_vec[model_dims//3:2*model_dims//3]
    mid_d = doc_vec[model_dims//3:2*model_dims//3]
    results['mid'] = np.dot(mid_q, mid_d) / (
        np.linalg.norm(mid_q) * np.linalg.norm(mid_d)
    )
    
    # 第三层：细粒度信息
    fine_q = query_vec[2*model_dims//3:]
    fine_d = doc_vec[2*model_dims//3:]
    results['fine'] = np.dot(fine_q, fine_d) / (
        np.linalg.norm(fine_q) * np.linalg.norm(fine_d)
    )
    
    return results

# 使用示例
q = model.encode("苹果公司的营收增长驱动因素")
d1 = model.encode("Apple Inc. reported revenue growth driven by iPhone and services.")
d2 = model.encode("苹果种植业在西北地区的营收增长迅速，主要驱动因素是气候改善。")

print(hierarchical_similarity(q, d1))
# 通常 coarse 和 mid 都较高，fine 也高
print(hierarchical_similarity(q, d2))
# 通常 coarse 高（都有"营收增长"），但 fine 显著降低

这个工具的思想是：Embedding向量的不同维度携带不同粒度的语义信息。通过分层检视，我们可以判断两个文本的相似是"貌合神离"还是"真正灵魂共鸣"。

---

四、第三重博弈：关键词密度——旧时代的幽灵

4.1 TF-IDF思维在向量空间的残留

很多从传统信息检索转过来的工程师，会不自觉地将TF-IDF直觉带入Embedding世界。一个典型的误区是：“文档中包含查询关键词越多，Embedding相似度应该越高。”

错。大错特错。

Embedding模型的输出不是词袋的线性组合。Transformer的自注意力机制会让关键词在上下文中的"角色"和"关系"重塑其向量贡献。重复同一个词十次，并不会让文档向量向该词的方向推进十倍。事实上，由于注意力权重的饱和效应，重复关键词的边际贡献迅速递减。

我做了另一个实验：

base = "如何优化Python代码性能"
repeat_1 = "如何优化Python代码性能，使用更高效的数据结构。"
repeat_3 = "如何优化Python代码性能，Python的性能优化很重要，优化Python需要注意算法复杂度。"
repeat_10 = ("如何优化Python代码性能。" + "Python性能优化至关重要。" * 5)

vecs = [model.encode(t) for t in [base, repeat_1, repeat_3, repeat_10]]
query_vec = model.encode("Python性能优化方法")

for i, vec in enumerate(vecs):
    sim = cos_sim(query_vec, vec)
    print(f"文档{i} 相似度: {sim:.4f} (长度: {len([base, repeat_1, repeat_3, repeat_10][i])})")

# 典型结果：
# 文档0: 0.8234
# 文档1: 0.8456  
# 文档2: 0.8123
# 文档3: 0.7987  <-- 关键词堆砌反而降低了相似度！

4.2 关键词位置的隐秘影响

比频率更值得关注的是位置。在大多数Embedding模型中，由于位置编码和注意力机制的存在，出现在句首或段落首的主题句往往获得更高的全局权重。

这意味着，两篇内容几乎相同的文档，仅仅因为关键词排列顺序不同，可能产生明显不同的向量。

doc_a = "机器学习是人工智能的核心分支。深度学习是机器学习的一个子领域，使用多层神经网络。"
doc_b = "深度学习使用多层神经网络，是机器学习的一个子领域。机器学习是人工智能的核心分支。"

vec_a = model.encode(doc_a)
vec_b = model.encode(doc_b)

print(cos_sim(vec_a, vec_b))  # 通常不是1.0，可能在0.92-0.97之间

这个发现对检索系统的启示是：文档的前128个token（或者说前几句）往往决定了其向量的大致方向。如果你的RAG系统对长文档只做整体编码，那么文档后半部分的精华内容可能在向量空间中"失声"。

---

五、三力交织：构建鲁棒的相似度评估框架

5.1 相似度不是真理，而是信号

经过前面的分析，我们应该建立一个基本认知：没有任何单一相似度指标能够完美捕捉"相关性"。余弦相似度、欧氏距离、点积——它们都只是高维空间中的某种几何投影，必然丢失信息。

在实践中，我采用一个多信号融合框架：

class RobustSimilarityScorer:
    def __init__(self, model, alpha=0.5, beta=0.3, gamma=0.2):
        self.model = model
        self.alpha = alpha  # 余弦相似度权重
        self.beta = beta    # 关键词匹配权重
        self.gamma = gamma  # 长度适配权重
        
    def encode(self, text):
        return self.model.encode(text, normalize_embeddings=False)
    
    def keyword_overlap(self, query, doc):
        """基于分词的关键词重叠度，保留一些传统的精确匹配信号"""
        q_tokens = set(jieba.lcut(query))  # 或使用其他分词器
        d_tokens = set(jieba.lcut(doc))
        if not q_tokens:
            return 0.0
        return len(q_tokens & d_tokens) / len(q_tokens)
    
    def length_awareness(self, query, doc, ideal_ratio_range=(0.5, 2.0)):
        """惩罚长度严重失衡的匹配对"""
        len_q = len(query)
        len_d = len(doc)
        ratio = len_d / len_q if len_q > 0 else 1.0
        if ideal_ratio_range[0] <= ratio <= ideal_ratio_range[1]:
            return 1.0
        elif ratio < ideal_ratio_range[0]:
            return ratio / ideal_ratio_range[0]
        else:
            return ideal_ratio_range[1] / ratio
    
    def score(self, query, doc):
        q_vec = self.encode(query)
        d_vec = self.encode(doc)
        
        cos = np.dot(q_vec, d_vec) / (np.linalg.norm(q_vec) * np.linalg.norm(d_vec))
        kw = self.keyword_overlap(query, doc)
        la = self.length_awareness(query, doc)
        
        return self.alpha * cos + self.beta * kw + self.gamma * la

这个框架的核心哲学是：让不同信号各司其职。Embedding负责语义泛化，关键词负责精确锚定，长度适配负责过滤明显不协调的匹配。权重可以根据业务场景调整——在法律文档检索中，你可能需要提高关键词权重；在开放式问答中，语义权重应该占主导。

5.2 负样本挖掘：让框架学会"不相关"

比计算相似度更重要、也更被忽视的是：系统必须理解什么是不相关。我在训练自定义排序模型时，花了80%的时间在负样本工程上。

一种特别有效的策略是"hard negative mining with length bias"：

def mine_hard_negatives(query, candidates, top_k=10):
    """
    故意在候选集中保留那些：
    1. 余弦相似度高
    2. 但关键词重叠度低或长度严重失衡的文档
    这些就是模型最容易误判的"陷阱文档"
    """
    scored = []
    for doc in candidates:
        q_vec = encode(query)
        d_vec = encode(doc)
        cos = cosine(q_vec, d_vec)
        kw = keyword_overlap(query, doc)
        
        # 相似度高但关键词匹配差 = 潜在的hard negative
        trick_score = cos * (1 - kw)
        scored.append((doc, cos, kw, trick_score))
    
    # 按trick_score排序，前top_k就是最难的负样本
    scored.sort(key=lambda x: x[3], reverse=True)
    return scored[:top_k]

这些hard negatives对训练Cross-Encoder重排序器尤其宝贵。它们教会模型：高相似度不等于高相关性。

---

六、实战中的策略与反模式

6.1 RAG系统的相似度调参指南

在真实RAG系统中，相似度阈值的选择直接决定了召回率和精确率的平衡。我总结了一个基于数据分布的动态阈值策略：

def adaptive_threshold(query_vec, candidate_sims, percentile=75):
    """
    不固定阈值，而是基于候选集分布动态调整。
    如果所有候选相似度都偏低，降低门槛；
    如果头部候选明显优于其余，提高门槛。
    """
    if not candidate_sims:
        return 0.5
    
    p75 = np.percentile(candidate_sims, percentile)
    max_sim = max(candidate_sims)
    
    # 头部优势度：最高分与中位数的差距
    median = np.median(candidate_sims)
    head_advantage = max_sim - median
    
    # 差距大，说明有明确的头部候选，可以提高阈值
    if head_advantage > 0.15:
        return p75
    else:
        return max(0.55, p75 - 0.05)

这个策略避免了一个常见反模式：在数据集A上表现良好的阈值，搬到数据集B上可能完全失效。Embedding相似度的绝对值没有跨数据集的可比性，永远要看相对分布。

6.2 反模式：盲目使用余弦相似度

以下是我见过最危险的三个反模式：

反模式一：跨模型比较相似度
用 text-embedding-ada-002 编码查询，用 all-MiniLM-L6-v2 编码文档，然后计算余弦相似度。不同模型的向量空间完全不同，这相当于比较摄氏度和华氏度的"数值差"。

反模式二：把相似度当概率
相似度0.8绝不意味着"80%的相关概率"。余弦相似度的取值范围和概率没有任何单调对应关系。我见过有产品经理要求"只返回相似度大于0.9的结果"，结果系统什么都召不回——因为在这个向量空间，0.75已经是很好的匹配了。

反模式三：忽视领域漂移
在通用语料上训练的Embedding模型，搬到医疗、法律等专业领域后，相似度分布会发生显著偏移。如果你发现相似度阈值突然"失效"，先检查一下领域是否发生了变化。

6.3 什么时候应该放弃相似度搜索

最后，我想分享一个略显叛逆的观点：并非所有问题都适合用向量相似度解决。

当满足以下任一条件时，请认真考虑回到传统检索方法或混合策略：

1. 查询是结构化标识符：如订单号、身份证号、产品SKU。这些是精确匹配场景，向量搜索只会引入噪音。
2. 相关性高度依赖结构化属性：如"价格
3. 领域术语高度特化且训练语料覆盖不足：某些冷门工程领域的专业同义词，通用模型根本没有学过。
4. 需要可解释的结果：向量检索是黑盒，当业务需要解释"为什么返回这个结果"时，BM25+关键词高亮是更好的选择。

我现在的默认架构是：BM25做初筛，Embedding做召回补充，Cross-Encoder做精排。三者不是替代关系，而是互补关系。偏执于任何一种方法，都是架构上的懒惰。