一句话定义：对称检索（Symmetric Retrieval）里，查询和候选文本"势均力敌"，比的是像不像；非对称检索（Asymmetric Retrieval）里，查询短、文档长，比的是这段长文能不能回答这个短问题。
先说对称。用户在 FAQ 页面输入"密码忘了怎么办"，系统要去匹配另一条"如何重置密码"。两句话都是短句、都是疑问语气、信息量相当，任务本质是判断相似度。这类场景用一套编码器（encoder）就够了，甚至可以两侧共享权重，因为它们在说"同一种语言"。
非对称则是另一种局面。你在搜索引擎里敲"报销流程"四个字，目标是一整页几千字的公司制度文档。问句里没有"发票""审批人""差旅标准"这些词，但答案藏在文档里。长度差几十倍、语气完全不同、词汇重叠几乎为零——没法靠"像不像"来判断，只能靠语义。
打个比方：对称检索像在通讯录里找一张相似的脸，双方都是"人脸"；非对称检索像拿一张便条去图书馆找对应那本书，便条是"问题语"，书是"答案语"。硬把两者塞进同一套表示里，模型会学出一个谁都不讨好的中间态。
工程上怎么处理？通常采用双塔结构（bi-encoder）：查询侧和文档侧各有一个编码器，把两种不同形态的文本映射到同一个向量空间，再用AI 词典：余弦相似度">余弦相似度比距离。训练数据也不同——对称用同义句、重复问法；非对称用（问题，包含答案的段落）对，并配 BM25 之类的难负例。
前缀为什么不能省：很多 embedding 模型在训练时就给两侧加了不同的前缀或指令，比如查询前加 query:、段落前加 passage:，或者给查询附一句任务说明。模型靠这个标记判断"我现在处理的是问题还是答案"。推理时漏掉、写反，代码照样跑通，但效果会悄悄下滑——这是最容易被忽略的一类 bug。具体该加什么前缀，以模型的官方页面或模型卡为准。
| 维度 | 对称检索 | 非对称检索 |
|---|---|---|
| 两侧形态 | 长度、语气接近 | 短查询 vs 长文档 |
| 典型场景 | 相似问题推荐、去重、聚类 | 搜索、问答、RAG 召回 |
| 编码方式 | 常常共用一套 | 通常双塔，两侧权重/前缀不同 |
| 训练数据 | 同义句、重复问法 | （问题，答案段落）对 + 难负例 |
| 相似度分数 | 可以设绝对阈值 | 一般只用于排序 |
对实际工作的意义：第一，先判断范式再选模型，FAQ 去重用对称，检索召回用非对称，选错会导致阈值怎么调都不对。第二，索引策略不同——非对称场景中文档向量可以离线批量算好，查询向量必须在线实时生成，两侧的模型、前缀、维度必须严格一致，换一侧就得全量重建索引。第三，分数的含义不同：对称任务的相似度可以定阈值（比如 0.9 以上视为重复），非对称任务的分数通常只有排序意义，绝对值不可比。