美食博主阿探最近接了个大活：给整座城市的上千家餐厅做一张“风味地图”。他没有按菜系硬分类，而是给每家店打一组成绩——辣度、甜度、鲜度、人均、上菜速度，一共五项。打完分他发现，川菜馆在辣度上分数接近，粤菜馆在鲜度上分数接近，同口味的店天然在地图上靠在一起。后来客人问“想吃点开胃的”，阿探只要把这句话也打成一套分，在地图上找到最近的那群店就行。 Embedding 模型（嵌入模型）做的就是这件事：把一句人话“打成”一组数字坐标。这组坐标叫向量，而坐标所在的“语义空间”里，意思相近的句子距离近，意思无关的句子距离远。RAG（检索增强生成，让大模型先查资料再回答的技术）正是靠这套坐标实现语义检索：先把资料库每段文字变成向量存好，再把用户的问题变成向量，去库里找出距离最近的几段，交给大模型组织答案。 这篇文章不碰复杂公式，只用一个“按味找店”的比喻带你走完这条路：文本向量化是怎么回事、主流模型有哪些、维度怎么选、编码怎么配、系统怎么落地。

岗位关联

学会为 RAG 系统选择和使用 Embedding 模型，是搭建语义检索的核心技能，也是 AI 应用开发者从入门到上手的基本功。

目录
  1. 可视化演示
  2. 文本向量化：给文字打一套「风味分」
  3. 主流模型：三位评委的评分风格
  4. 维度选择：评分项目不是越多越好
  5. 编码方式：点菜和做菜，方向不同
  6. 选型决策：挑一台合适的打分方案
  7. 检索实战：从风味地图到智能点菜
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

动态演示Embedding模型的核心机制，通过全局/局部/动态/静态四种模式展示关键概念与交互流程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

Embedding模型：文本向量 文本向量化的基本原理与语义空间 主流Embedding模型的技 核心机制可视化 Embedding模型整体架构与关键组件

文本向量化：给文字打一套「风味分」

阿探的风味地图之所以好用，秘密不在分类方法，而在他打分的方式。他把“辣”“甜”“鲜”“锅气”“人均”各列成一栏，每道菜每个维度填一个数字。这些数字组合起来，就是这道菜在一张五维表格里的位置。你问他要“开胃的”，他就去表格里找“辣、酸、开胃”这三个数都高的一组——不用尝，也知道答案。

计算机不认识“苹果”和“香蕉”，只认识数字。Embedding 模型就像一个经过千万次试吃的评委，它看过海量文本后学会了一件事：把每个词、每句话翻译成一串数字，这就是向量。向量里的每一维，就像阿探表格里的一栏，只不过维度往往有几百上千个，人类看不清，但计算机算得飞快。

早期的词袋模型只记录“这段话里出现了哪些词”，相当于只数“店里有没有卖辣椒”，完全不看做法和口味，同义词、语序信息全部丢失。Embedding 则把整段文字映射进高维语义空间，每个词、每句话都占据一个点。有了坐标，就能量化“像不像”，最常用的指标是余弦相似度：

对阿探来说，判断两家店像不像，不看谁家桌子多、谁家装修贵（这些是“模长”），只看口味方向是否一致（这是“夹角”）。向量检索同理：在语义空间里，找方向最接近的那几个点，就是语义最相近的文本。

相似度=u⋅v∥u∥×∥v∥=∑i=1duivi∑i=1dui2×∑i=1dvi2\displaystyle \text{相似度} = \frac{\mathbf{u} \cdot \mathbf{v}}{\|\mathbf{u}\| \times \|\mathbf{v}\|} = \frac{\sum_{i=1}^{d} u_i v_i}{\sqrt{\sum_{i=1}^{d} u_i^2} \times \sqrt{\sum_{i=1}^{d} v_i^2}}
通俗理解：两个向量的方向越一致，余弦值越接近 1，语义越相似；方向越相反，越接近 -1。
  1. 分子逐维相乘再相加：把两个向量的每个对应分量乘起来求和，度量它们“朝同一方向”的程度，数学上叫点积。
    u⋅v=∑i=1duivi\mathbf{u} \cdot \mathbf{v} = \sum_{i=1}^{d} u_i v_i
  2. 分母两个向量的模：每个向量自己各分量的平方和开根号，相当于它的“总长度”。
    ∥u∥=∑i=1dui2\|\mathbf{u}\| = \sqrt{\sum_{i=1}^{d} u_i^2}
  3. 归一化比值去掉长度影响：用两个模的乘积做分母，结果与向量长短无关，只与方向有关，取值落在 -1 到 1 之间。
    相似度=u⋅v∥u∥×∥v∥∈[−1,1]\text{相似度} = \frac{\mathbf{u} \cdot \mathbf{v}}{\|\mathbf{u}\| \times \|\mathbf{v}\|} \in [-1, 1]

主流模型：三位评委的评分风格

同样是打分，不同评委的风格天差地别。目前 RAG 圈最常见的“评委”有三位：OpenAI、BGE、E5。它们各有各的评分表，各有各的适用场景，选错了评委，再好的菜也评不出味来。

OpenAI 像国际连锁点评网站：评分全面、闭源、用一次收一次费。text-embedding-3-small 输出默认 1536 维，text-embedding-3-large 默认 3072 维（API 支持手动缩到更小）。好处是通用性强、几乎不用调；代价是数据要发到海外，且查询量大时账单蹭蹭涨。

BGE（北京智源研究院）像本地吃货协会：中文舌头特别灵，而且评分表开源，可以搬到自家厨房（服务器）用，适合中文业务和数据敏感的 RAG 项目。E5（微软）像国际美食数据库：多语言通用，官网明确要求对文本加前缀——查询文本前加 “query: “，文档前加 ”passage: ”，帮模型分清角色。

选评委就是选口味基准：你的菜谱以中文为主、预算有限，本地协会 BGE 往往最香；跨国多语言、不缺预算，国际平台 OpenAI 更省心。

v=fθ(text),v∈Rd\displaystyle \mathbf{v} = f_{\theta}(\text{text}), \quad \mathbf{v} \in \mathbb{R}^{d}
通俗理解：一段文字（text）经过一个训练好的神经网络 f_θ，吐出一串 d 维数字坐标。
  1. 可训练函数 f_θ带参数 θ 的神经网络，参数在海量文本对上（比如“苹果”配“水果”）学出来的“口味体系”。
    v=fθ(text)\mathbf{v} = f_{\theta}(\text{text})
  2. 输出向量 v模型把文本压缩成 d 个实数，每一维由模型自动决定“在看什么”，人类无需指定。
    v=(v1,v2,…,vd)\mathbf{v} = (v_1, v_2, \ldots, v_d)
  3. 空间归属向量生活在 d 维实数空间，d 是模型预设的固定值（1536、768、384 等）。
    v∈Rd\mathbf{v} \in \mathbb{R}^{d}

维度选择：评分项目不是越多越好

阿探曾犯过贪心的毛病：把评分项目一路加到 30 项——连“盘子颜色”“服务员身高”都列进去，结果表格臃肿，整理起来又慢又累，对找店的准确度却没多大帮助。他这才意识到，评分不是越多越好。

Embedding 的维度就是这个道理。每一维是一项“隐性评分”。维度太少，语义差异会被压扁，比如只有“辣”“不辣”两维，甜辣和香辣根本分不开；维度太多，不仅训练成本高、向量占内存，检索时逐维比较也慢。

OpenAI 默认 1536 维，BGE 常见规格有 384、768、1024 维。实践经验是：维度从 64 涨到 256 收益显著，256 到 768 仍有提升，再往上增长越来越平缓。对绝大多数 RAG 知识库来说，中等维度已经够用，一味追高只会让账单和延迟一起膨胀。

和阿探减掉“盘子颜色”一样，选维度也是做减法：先信模型的默认值（那是调好的甜区），只有评测证明维度不够用时再往上加。

存储占用=N×d×4 字节,检索耗时∝d\displaystyle \text{存储占用} = N \times d \times 4\ \text{字节}, \quad \text{检索耗时} \propto d
通俗理解：文档越多、维度越高，向量库越占磁盘；每次算相似度要扫过所有维度，维度越高越慢。
  1. 文档块数 N切分后入库的文本块总数，通常几十万到千万级，直接决定总存储量。
    N=向量库中的文档块数N = \text{向量库中的文档块数}
  2. 维度 d每个向量的分量个数，直接决定单条向量的体积。
    d=向量维度d = \text{向量维度}
  3. 4 字节行业默认用 float32 单精度浮点数存储每个分量。
    单条向量=d×4 字节\text{单条向量} = d \times 4\ \text{字节}
  4. 耗时正比余弦计算要遍历每个维度，d 翻倍约等于每次比较慢一倍。
    检索耗时∝d\text{检索耗时} \propto d

编码方式：点菜和做菜，方向不同

阿探渐渐发现，比较分两种。比“两家店谁更辣”是面对面比——两边都是给同一张表打分。但客人说一句“想找个适合约会的地方”，要去比店里三百字的点评长文，这是短句比长文，直接比会错位。

对称编码：两段文本长度、形态接近（如“问题 vs 标题”、“句子 vs 句子”），同一个 Embedding 模型直接编码双方即可。非对称编码：一端是用户短查询，另一端是几百字长文档，形态差异大，直接共用一个空间容易对不齐，需要专门的指令前缀或分离的 query/doc 编码器。

BGE 官方按 query / passage 两种指令区分编码，E5 要求加 "query: " / “passage: “ 前缀，OpenAI 模型则靠通用表现撑住两端，但对齐精度相对粗。RAG 场景里”用户一句话 + 库里长文档”是典型非对称结构，务必按模型规范配好前缀。

对称像“同台竞技”，非对称像“跨级比拼”。RAG 里用户问一句、库里有几百字长文，十有八九是非对称场景，别拿同一张表硬比。

q=Eq(query),d=Ed(doc),sim=cos⁡(q,d)\displaystyle \mathbf{q} = E_{q}(\text{query}), \quad \mathbf{d} = E_{d}(\text{doc}), \quad \text{sim} = \cos(\mathbf{q}, \mathbf{d})
通俗理解：查询和文档分别用两种“偏置”的编码器投影到同一空间，再算余弦相似度。
  1. 查询向量 q用户问题经查询编码器得到，是短文本的坐标。
    q=Eq(query)\mathbf{q} = E_{q}(\text{query})
  2. 文档向量 d长文档经文档编码器得到，是长文本的坐标。
    d=Ed(doc)\mathbf{d} = E_{d}(\text{doc})
  3. 同空间比较两个编码器刻意把短句和长文拉到同一坐标系，最终可以直接比较。
    sim=cos⁡(q,d)\text{sim} = \cos(\mathbf{q}, \mathbf{d})

选型决策：挑一台合适的打分方案

面对三位评委，阿探从不问“谁最厉害”，只问三个问题：我的菜是给谁吃的？一年付多少外请费？配方能不能给别人看？这三个问题同样是 RAG 选型的决策框架。

语言支持：纯中文业务，BGE 的舌头最灵；多语言、英文为主，OpenAI 或 E5 更稳。成本预算：OpenAI 按 Token 计费，每次查询和每块文档都要花钱，量大了是持续开支；开源模型一次性部署成本，之后近乎免费，但需要 GPU 和运维。数据隐私：涉密文档必须能私有化部署，直接排除闭源 API。

榜单分数（MTEB 等）只是通用参考，真正靠谱的是拿自己的 100 条问答对跑一遍 Recall@K：候选模型分别把问题向量化去知识库检索，看正确答案被召回的比率，谁高选谁。

没有最好的评委，只有最合适的评委。先用自家数据实测，再算清年账单，最后看能不能接受数据出门——三条都过，就是你的真命天“模”。

年总费用=(N文档Token+N年查询Token)×P每千Token÷1000\displaystyle \text{年总费用} = \left(N_{\text{文档Token}} + N_{\text{年查询Token}}\right) \times P_{\text{每千Token}} \div 1000
通俗理解：一年花的钱 =（全部文档的 Token 数 + 所有用户提问的 Token 数）× 每千 Token 单价。
  1. 文档 Token 总量切分后全部文档块加起来的 Token 数，入库时只编码一次。
    N文档Token=∑k第k块的Token数N_{\text{文档Token}} = \sum_k \text{第}k\text{块的Token数}
  2. 年查询 Token 总量所有用户提问一年累计的 Token 数，每次提问都要现场编码。
    N年查询Token=年提问次数×平均提问长度N_{\text{年查询Token}} = \text{年提问次数} \times \text{平均提问长度}
  3. API 计价OpenAI 按每 1000 个 Token 收费，除以 1000 才是单价倍数。
    费用=总Token数×P每千Token÷1000\text{费用} = \text{总Token数} \times P_{\text{每千Token}} \div 1000

检索实战：从风味地图到智能点菜

万事俱备，阿探把风味地图做成了 App。用户输入“想吃点清淡的”，App 先把这句话变成坐标，再在地图上画圈圈出最近的几家店——这就是一次完整的语义检索。

离线入库：文档切成 200 到 500 字的小块，调 Embedding 模型逐块向量化，把向量和原文一起写进向量数据库（如 Milvus、Chroma、pgvector）。在线查询：用户问题向量化，向量库用近似最近邻（ANN）算法秒级返回 Top-K 相似文档块，最后把这些块和问题拼进 Prompt，交给大模型生成答案。

效果怎么量化？最常用的是 Recall@K：对每个测试问题，人工标好“应该被召回”的文档集合，看系统返回的前 K 条里真正命中了几条。指标上来了，用户才觉得“这机器人真的懂我”。

阿探的 App 上线后把 Recall@10 从 60% 刷到 90%，靠的正是本文四板斧：选对评委（模型）、调好维度、配对编码、测准指标。地图准了，客人满意；检索准了，大模型答得才漂亮。

Recall@K=前K条中命中的相关文档数相关文档总数\displaystyle \text{Recall@K} = \frac{\text{前}K\text{条中命中的相关文档数}}{\text{相关文档总数}}
通俗理解：50 篇真正相关的文档，系统前 10 条里捞回 8 篇，Recall@10 = 8/50 = 16%。
  1. 前 K 条结果向量数据库返回的相似度最高的 K 篇文档块。
    前K条=Top-K检索结果\text{前}K\text{条} = \text{Top-}K \text{检索结果}
  2. 命中数这 K 条中和测试问题真正相关的数量，即检索结果与人工标注的交集大小。
    命中数=∣前K条∩相关文档∣\text{命中数} = |\text{前}K\text{条} \cap \text{相关文档}|
  3. 相关文档总数人工为这个问题标注的全部正确答案数，是分母。
    相关总数=∣相关文档∣\text{相关总数} = |\text{相关文档}|
  4. 比值趋近 1召回率越接近 1，说明相关文档越容易被捞到前排。
    Recall@K→1\text{Recall@K} \to 1

AI 应用场景

电商智能客服知识库

阶段：离线索引构建 + 在线查询召回

解决的问题：传统关键词客服系统把“退款要多久”和“何时原路退回”当作两回事，用户换个说法就答非所问。用 Embedding 把 FAQ 变成向量，提问按语义召回，命中率明显上升。

具体案例：某电商平台用 bge-large-zh-v1.5 将 5 万条 FAQ 分块向量化存入 Milvus，用户抱怨“钱什么时候退”能直接命中“退货后 7 个工作日原路退回”的问答，转人工率下降约三成。

企业内部知识库跨语言检索

阶段：多语索引 + 语义检索

解决的问题：跨国企业文档混杂中英日文，关键词检索无法跨语言。用 OpenAI text-embedding-3-small 将全语种文档统一向量化，中文提问可以召回英文文档。

具体案例：某外资药企内部 SOP 库用 OpenAI 嵌入统一向量化，员工用“药品稳定性测试流程”提问，能召回英文原版 SOP 片段，再由大模型翻译总结。

法律文书语义搜索

阶段：非对称编码 + 召回评估

解决的问题：律师查判例，习惯用一句话事实描述（短查询）去匹配整篇判决书（长文档），形态极不对称。用支持 query/passage 指令的 BGE 模型做非对称编码，并用 Recall@K 调参。

具体案例：某法律科技公司用 BGE 非对称模式建立判例库，输入“开发商逾期交房违约”能召回数千字判决书中的相关段落，检索速度和准确率明显优于关键词方案。

Python 演示

python50 行
import mathimport re  class HashEmbedding:    """简易文本向量化: 把每个汉字哈希到固定维度, 演示 Embedding 原理"""     def __init__(self, dim=64):        self.dim = dim  # 向量维度, 类比评分项目数     def embed(self, text):        """把一段文本变成 dim 维向量(仅统计中文字符)"""        vec = [0.0] * self.dim        for ch in text:            if "\u4e00" <= ch <= "\u9fff":                vec[ord(ch) % self.dim] += 1.0        norm = math.sqrt(sum(v * v for v in vec))        if norm > 0:            vec = [v / norm for v in vec]        return vec  def cosine_sim(a, b):    """余弦相似度: 返回 0~1, 越大代表语义越接近"""    return sum(x * y for x, y in zip(a, b))  if __name__ == "__main__":    model = HashEmbedding(dim=64)    docs = [        "苹果手机支持面容解锁",        "香蕉和苹果都是常见水果",        "跑鞋适合日常健身运动",        "平板电脑可以画画记笔记",        "葡萄汁是夏日解暑饮料",    ]    doc_vecs = [model.embed(d) for d in docs]  # 离线入库: 文档全部向量化     queries = ["苹果", "跑步", "解暑水果"]    for query in queries:        qv = model.embed(query)  # 在线查询: 问题现场向量化        rank = sorted(            range(len(docs)),            key=lambda i: cosine_sim(qv, doc_vecs[i]),            reverse=True,        )        top = [docs[i] for i in rank[:2]]        print("查询「%s」最相关的 2 篇:" % query)        for t in top:            print("  -", t)
目的：用纯 Python 实现一个迷你 Embedding + 语义检索 Demo，完整走一遍“文档向量化入库 → 查询向量化 → 相似度排序 → Top-K 召回”的 RAG 检索链路。
  1. model = HashEmbedding(dim=64)定义了一个 64 维的迷你嵌入模型，dim 就是“评分项目数”。
  2. vec[ord(ch) % self.dim] += 1.0把每个汉字哈希到某一维并计数，相当于“这一项上加一分”。
  3. vec = [v / norm for v in vec]L2 归一化，消除句子长短的影响，只留“口味方向”。
  4. def cosine_sim(a, b):余弦相似度函数，值越大代表两段文本语义越接近。
  5. doc_vecs = [model.embed(d) for d in docs]离线入库：文档全部提前向量化，对应索引构建阶段。
  6. qv = model.embed(query)在线查询：用户问题现场向量化，与库里的文档向量实时比较。
  7. rank = sorted(range(len(docs)), key=..., reverse=True)按相似度从高到低给全部文档排序。
  8. top = [docs[i] for i in rank[:2]]取最相似的 Top-2 文档，模拟向量库的 Top-K 召回。

常见误区

误区“Embedding 维度当然是越大越好，我直接把 OpenAI 的 3072 维拉满，效果肯定比 1536 维强。”

正解维度收益递减是铁律。64 到 256 维提升明显，256 到 768 仍有收益，768 以上每翻一倍效果只涨零点几个百分点，成本和耗时却接近翻倍。就像阿探把评分项目从“辣度、甜度”加到“盘子颜色、服务员身高”，表格臃肿，找店却不会更准。模型默认维度就是官方调过的甜区，先信默认。

为何常见：人类直觉是“信息越多越精确”，但没看到边际收益递减曲线和存储开销的线性增长。

误区“Embedding 就是把每个词对应一个唯一编号，像字典 ID 一样，遇到就查表。”

正解编号只解决“认得出”，不携带任何语义关系。“苹果=17 号”和“香蕉=89 号”，看不出它们都是水果。Embedding 的每一维都是语义维度上的数值，组合起来形成坐标，语义相近的词坐标接近，这才是它能做检索的原因。编号是给菜编桌号，Embedding 是给菜打分。

为何常见：“嵌入”这个词太抽象，初学者容易套用熟悉的“编码表”直觉，忽略了向量是多维坐标。

误区“反正都是同一个 Embedding 模型，查询和文档怎么编码不都一样吗？”

正解短查询和长文档形态差异极大，一个 10 字的问句和一个 500 字的文档块，在同一空间里天然不对齐。支持对称/非对称的模型（BGE、E5）通过指令前缀或双编码器把两者拉进同一坐标系。类比：同台比厨艺用一张评分表；让一句广告语和一篇食评同场竞技，就得专门校准规则。

为何常见：对称场景（句子 vs 句子）在教程中最常见，容易给人“一套方案通用”的错觉。

误区“MTEB 榜单第一名闭眼选，反正分数高就是好。”

正解排行榜是几十个通用数据集的平均分，你的业务数据（法言法语、客服黑话）未必在分布内。正确流程是：用 100 条真实问答，让候选模型各自跑一遍 Recall@K，再结合语言支持、年费用、部署条件综合决策。

为何常见：榜单零成本可得，自建评测要写代码做标注，“省事”心理导致以偏概全。

面试题

Q1. 以下哪一项最符合 Embedding 向量的本质？

单选题 · easy

  • A.给词语分配的随机编号
  • B.文本在语义空间的坐标← 正确答案
  • C.压缩后的文本摘要
  • D.分词后的词频统计表

答案：B。Embedding 把文本映射成多维坐标，语义相近的文本坐标靠近，这是它能做检索的根本原因。A 是字典 ID 的做法，不携带语义；C 是摘要任务；D 是词袋模型，只统计出现与否，故选 B。

Q2. 两个语义相近的句子，其向量最可能满足？

单选题 · easy

  • A.向量完全相等
  • B.余弦相似度更高← 正确答案
  • C.向量维度更高
  • D.向量模长更大

答案：B。语义相近意味着在语义空间里方向接近，即夹角小、余弦相似度高。完全相等几乎不可能，维度和模长与语义相似与否无关，故选 B。

Q3. OpenAI text-embedding-3-small 的默认输出维度是？

单选题 · easy

  • A.256 维
  • B.512 维
  • C.1024 维
  • D.1536 维← 正确答案

答案：D。text-embedding-3-small 默认输出 1536 维，text-embedding-3-large 默认 3072 维，这是 OpenAI 官方文档的取值，也是面试常考的硬知识。

Q4. RAG 中“用户短问题检索长文档”应使用？

单选题 · mid

  • A.对称编码方式
  • B.非对称编码方式← 正确答案
  • C.不需要任何编码
  • D.哈希编码方式

答案：B。短查询和长文档形态差异大，属于典型的非对称场景，需要用 query/passage 双指令或双编码器对齐。对称编码适合两端形态接近的短文本比较，故选 B。

Q5. BGE 系列模型最突出的优势是？

单选题 · mid

  • A.仅支持英文语料
  • B.中文效果好且开源← 正确答案
  • C.输出维度高达万维
  • D.运行不需要任何显存

答案：B。BGE 由智源研究院开源，中文语义效果领先，可私有化部署，是国内 RAG 项目的高频选择。它不是英文专用，维度也非万级，运行仍需 GPU/NPU，故选 B。

Q6. 余弦相似度的数学本质是？

单选题 · mid

  • A.两个向量长度的比值
  • B.两个向量的夹角余弦← 正确答案
  • C.向量各维度数值之和
  • D.两点间的欧氏距离

答案：B。余弦相似度公式是点积除以两个模的乘积，几何意义就是两个向量夹角的余弦值，与向量长度无关。长度比值、维度求和、欧氏距离都不是它的定义，故选 B。

Q7. 文档入库阶段向量化发生在哪个环节？

单选题 · mid

  • A.用户提问之后的召回环节
  • B.离线索引构建的入库环节← 正确答案
  • C.大模型生成答案的环节
  • D.训练权重更新的环节

答案：B。离线入库时先把文档切成小块并向量化，连同原文一起存入向量数据库；用户提问后才对查询做在线向量化。A、C、D 都发生在入库之后，故选 B。

Q8. 选择合适的 Embedding 模型应考虑？

多选题 · mid

  • A.业务语言支持← 正确答案
  • B.推理成本预算← 正确答案
  • C.语义检索效果← 正确答案
  • D.服务器机房租期

答案：ABC。选型三问是语言支持、成本预算、效果评测，三者缺一不可。服务器机房租期属于运维细节，与模型选型无直接关系，故选 A、B、C。

Q9. 关于向量维度选择，正确的说法有？

多选题 · hard

  • A.维度越高信息越丰富← 正确答案
  • B.维度越高成本随之上升← 正确答案
  • C.维度越低效果永远最好
  • D.维度收益会逐渐递减← 正确答案

答案：ABD。维度高确实承载更多信息，但存储、显存、检索耗时都随维度上升，且收益递减——从 64 到 768 提升明显，再往上增益很小。C 说“维度越低永远最好”过于绝对，与收益递减规律矛盾，故选 A、B、D。

Q10. 提升 RAG 系统检索效果的手段有？

多选题 · hard

  • A.匹配语言合适的模型← 正确答案
  • B.选择对应编码方式← 正确答案
  • C.一味加大向量维度
  • D.用 Recall@K 实测调参← 正确答案

答案：ABD。选对模型语言、配对称/非对称编码、用自家数据跑 Recall@K 实测调参，是 RAG 检索调优的核心三板斧。一味加大维度收益有限且成本飙升，不是推荐手段，故选 A、B、D。