这两年做大模型应用，尤其是RAG（检索增强生成）相关项目的人越来越多了。不管你是用LangChain、LlamaIndex，还是自己手写一套检索流程，有个东西你是绕不开的，那就是Embedding模型。我见过不少朋友在调RAG效果的时候，拼命调Prompt、换大模型参数，结果效果还是差强人意，折腾半天发现瓶颈出在Embedding上——向量化之后相似度算不准，文档召回的准确率直接拉垮，后面做得再花哨也是空中楼阁。这一节内容，我想把Embedding模型这件事从头到尾捋一遍，把概念、选型、实战用法和踩坑经验放在一起，供你参考。
这篇文章适合正在做RAG、知识库问答、语义检索、文本相似度匹配这类任务的开发者，尤其是打算自己搭一套向量检索管线的朋友。看完你可以搞清楚Embedding到底在工作流的哪一环、怎么选合适的模型、怎么调用、怎么打分，以及那些文档里不怎么会写的坑。
1. Embedding模型的定位：它到底解决什么问题
1.1 为什么几乎所有RAG项目里都有它的身影
先说一个最直观的场景。你有一个知识库，里面是几万篇文档，用户问"工资什么时候发"，你的系统需要找到跟这个问题最相关的几段文字，然后丢给大模型去生成答案。如果只是做关键词匹配，用户说的是"薪资发放时间"，而你文档里写的是"薪酬到账日期"，那关键词对不上，检索结果就是空的。这就是传统倒排索引的尴尬所在——字面不一样，语义一样，但它判断不了。
Embedding模型干的事情，就是把文字变成一串数字，也就是向量。而且它不是随便变的，它经过大规模训练，能够把语义相近的文本映射到向量空间里相近的位置。这样，"工资什么时候发""薪资发放时间""薪酬到账日期"这几句话的向量距离就会很近，系统就能顺利召回。
所以Embedding模型在整个RAG链路里的角色，相当于一个翻译官加定位器。它把人类的语言翻译成计算机能算距离的向量，再通过距离计算完成语义层面的定位。没有这一步，后面的向量数据库、相似度检索、重排序全部无从谈起。
1.2 Embedding、向量数据库和RAG的关系
很多人刚接触RAG的时候，把Embedding和向量数据库混为一谈，觉得"我用了向量数据库不就有Embedding了吗"。这个误会挺常见的。你实际拆开看，这其实是两层完全不同的东西：
- Embedding模型只负责"文本到向量"的转换，它是一个模型，有自己的参数和推理逻辑。
- 向量数据库负责"存向量 + 算相似度"，它接收Embedding模型产出的向量，建立索引，然后支持查询。
如果你用的是某云厂商的向量数据库，它可能会提供配套的Embedding能力，但那是数据库产品提供的扩展功能，不代表Embedding模型本身可以省掉。换一个场景，如果你的项目规模不大，几千条文本而已，你完全可以不用向量数据库，直接把向量存内存里，用NumPy算余弦相似度。但Embedding这一步是省不了的——你得先把文本变成向量，才有后面的相似度可言。
我在给某项目做知识库问答的时候，开始就想着走全套云端方案，后来发现数据量不大，就自己用开源Embedding模型生成向量，再用内存数组做检索，效果一样好，还省了运维成本。后来数据量上去了，才迁移到专门的向量数据库。这个演进路线我觉得是比较务实的。
1.3 语义检索的基本单位：向量的距离到底代表什么
理解Embedding不能停留在"文本变成向量"这个层面，你得知道怎么去用这个向量。向量就是一个多维空间里的点，两个点的位置越接近，说明它们对应的文本语义越接近。那怎么衡量接近程度？工程上最常用的是余弦相似度。
余弦相似度的公式看起来复杂，其实你可以类比成两个人看问题的角度：A说工资，B说薪酬，C说天气。A和B的观点方向基本一致，夹角很小，余弦相似度就高；C跟他们方向完全不一样，夹角接近90度，相似度就趋近于0。这个思路很直观，也是目前大部分Embedding应用默认的距离度量方式。
实际操作中需要注意，余弦相似度关注的是方向而不是长度。有些模型产出的向量模长本身也有意义（比如代表信息的丰富程度），但在做相似度检索时，我们通常只关心方向。所以用余弦距离的场合，标准化向量往往是一个标准的预处理步骤。这一点你在后面看代码的时候会深有体会。
2. 核心概念拆解：嵌入模型的原理、与分词的关系、关键参数
2.1 从词到向量：Embedding模型是怎么"理解"语义的
Embedding模型的前身是词向量，比如Word2Vec时代，模型会给每个词一个固定向量，但这个词向量是静态的——同一个词在不同的上下文里，向量一模一样，这就有一个明显的缺陷："苹果"在"苹果手机"和"削苹果"这两个语境中含义完全不同，但静态词向量无法区分。
现在的Embedding模型基本都建立在Transformer架构之上，走的是动态编码路线。文本输入模型后，每个词（实际上是Token，也就是子词）的向量表示会根据它所在的上下文动态调整。这就是为什么现代Embedding模型能捕捉到一词多义：模型看到"苹果手机"时，"苹果"这个Token的向量会融入"电子设备"的语义信息；看到"削苹果"时，它会融入"水果"的语义信息。
这个机制背后的关键叫注意力机制。你可以把它理解成模型在读一句话的时候，会自动判断哪些词和哪些词之间有强关联。比如"猫坐在垫子上"，模型会发现"猫"和"垫子"之间有一个空间关系的关联，这种关联会通过注意力权重体现出来，从而影响向量的生成。注意力机制让模型的输出不再是一个个孤立的词向量，而是一个融合了整句语境的整体表示。
2.2 语境和Token化：为什么Embedding不是简单的"查表"
很多人以为Embedding就是拿个现成的词表，每个词查一个编号，再映射成一个向量。这种想法停留在静态词向量的时代。你现在用的Embedding模型，在推理时大概经历了这么几步：
第一步是分词（Tokenization）。模型会把输入文本切分成Token，比如"Embedding模型真香"，可能被切成若干个子词片段。不同的模型用的分词器不一样，有些模型对中文比较友好，可能一个汉字一个Token或一个词一个Token，有些模型用BPE（字节对编码）算法，切出来的Token边界和中文词语边界并不一致。
第二步是查初始向量表。每个Token都会对应一个初始向量，但这个向量只是一个起点，它本身不包含上下文信息。
第三步是多层Transformer编码。这是最核心的步骤，Token向量在Transformer的各层之间流转，每一层都会结合注意力机制更新表示。经过足够多的层数之后，每个Token的向量都包含了整个句子的上下文信息。
第四步是池化。模型最后会输出每个Token的向量，但我们需要的是整个序列的一个向量。常见的池化方式有取CLS标志位的向量、取所有Token向量的平均值、或者取最大值等。不同的模型会选择不同的池化策略，这也会影响最终向量的语义表达能力。
知道了这个过程，你就明白为什么Embedding模型不能简单粗暴地"查表"了——它本质上是动态推理，同样的文字放在不同语境里，输出向量天差地别。
2.3 Embedding维度、文本长度和归一化：三个必须搞清楚的参数
实际调用Embedding模型的时候，你一定会碰到三个参数：输出维度、最大输入长度、是否归一化。这三个参数不搞清楚，后面很容易掉坑里。
输出维度决定了每条文本变成多长的向量。常见的有384维、512维、768维、1024维、1536维等。维度越高，理论上能容纳的语义信息越丰富，但存储开销和计算开销都会上升。你做一个百万级文档的向量库，用1536维和用384维相比，存储成本差出4倍。所以在选模型的时候要想清楚：你的任务到底需要多细的语义粒度？如果你的业务场景就是短文本匹配，384维通常够用了；如果你要处理的是长文档的复杂语义，那1024维或以上会更稳妥。
最大输入长度决定了模型一次能吃进多少文本。有的Embedding模型只有128个Token的输入上限，有的可以到8192。这个参数很关键，因为如果你的文档段落超过模型输入上限，直接传进去通常会被截断，截断所带来的后果是尾部信息丢失。我的建议是：在建库之前就确定好你的切片策略，让每片文本长度在模型有效输入范围内。另外别太贪心，把输入撑满。给模型输入过长文本，一方面推理速度会变慢，另一方面很多模型的语义聚合效果在超长文本上会下降，反而不如切成中等长度的片段效果好。
归一化则更直接地影响相似度计算。Embedding模型的原始输出向量，如果两个向量的长度不一致，余弦相似度的计算本身不要求归一化——因为余弦只关心夹角。但很多模型在输出端已经做了归一化处理，也就是说向量模长为1。这样做的好处是余弦相似度和内积（点积）完全等价，而内积运算在很多向量索引里比余弦更高效。所以你应该确认你的模型输出是否归一化，然后选择配套的相似度计算方式。
2.4 Embedding模型的分类与选型思路
Embedding模型可以从几个维度分类。按开源程度分，有商业API模型（比如某些大厂的文本向量化接口）和开源模型（比如HuggingFace上的各种Embedding模型）；按语言能力分，有纯中文模型、纯英文模型、多语言模型；按场景分，有通用领域模型和针对特定领域（如代码、金融、医疗）微调的模型。
怎么选？我的经验是三条原则：
第一，适配你的语料语言。如果你的文档以中文为主，优先选中文表现好的模型；如果中英混合，选多语言模型。很多通用英文模型直接拿来处理中文，效果会让你怀疑人生——不是不能用，而是语义距离的表达能力明显弱一截。
第二，适配你的数据规模。数据量不大、对性能要求不高，直接调用API最省事；数据量大、成本敏感、需要离线部署，选开源模型自己跑。
第三，考虑生态兼容性。你打算用什么向量数据库，它一般会列出官方支持的Embedding模型清单，优先选兼容性好的，省去格式转换的麻烦。
3. 实战：从模型选择到代码实现，搭建完整的向量化管线
3.1 用开源的国产中文Embedding模型，还是商业API？
这个问题没有标准答案，完全取决于你的场景和资源。以中文场景为例，HuggingFace上有不少优秀的中文Embedding模型，有些在中文语义匹配的公开评测上表现甚至超过一些商业API。开源的好处是数据不出内网、无调用费用、可私有化部署；坏处是你需要自己维护推理服务——GPU不够的话，还得考虑量化、并发、缓存这些工程问题。
商业API的好处是省心，你传文本过去它返回向量，并发和稳定性它们负责。坏处一是有成本和限流；二是数据要过外网，某些行业（比如医疗、金融、政务）的数据合规要求根本不允许这么做。
我的建议是：如果只是自己学习或者做Demo，开源模型就够了，一台还算可以的显卡就能跑起来；如果业务量很大且在线要求高，可以先评估一下私有化部署的成本，再和API方案做对比。实战下来，不少场景用开源模型配合量化部署，效果完全能打。
3.2 一个最小的调用示例：生成文本向量
光说概念不写代码等于耍流氓。下面我用HuggingFace生态写一个最小的调用示例，选用一个开源的中文Embedding模型（以某典型的轻量中文模型为例，具体名称你可以在HuggingFace搜索相关排行榜选择）。
from sentence_transformers import SentenceTransformer # 加载模型，首次运行会自动下载权重 model = SentenceTransformer("例/某中文Embedding模型名称") # 输入文本 sentences = [ "今天天气怎么样", "查询一下今天的天气情况", "我要订一份外卖" ] # 生成向量 embeddings = model.encode(sentences, normalize_embeddings=True) # 打印向量维度 print(embeddings.shape) # 例如 (3, 768) # 打印第一个句子的向量 print(embeddings[0])这段代码看着简单，但有几处细节值得展开说说。
在调用model.encode时，我传了normalize_embeddings=True，这个参数会把输出的向量归一化为单位长度。为什么这么做？因为在向量检索的场景中，归一化后余弦相似度和内积结果等价，后面接FAISS等索引库时可以用IP（内积）计算，性能优于显式算余弦。
sentences列表里三条文本，前两条语义高度相似，第三条和它们明显不同。你可以打印出两两之间的向量相似度验证一下效果。这也是我建议你上手第一个模型之后最该做的事——先不要急着搭系统，拿几条典型的文本跑一下，感受一下模型对语义的判断是否符合直觉。
3.3 计算相似度：余弦相似度的实现
向量生成之后，计算文本相似度是最常用的操作。代码很简单：
import numpy as np def cosine_similarity(vec_a, vec_b): # 如果向量已经归一化，直接算内积即可 return float(np.dot(vec_a, vec_b)) # 示例：计算第一句和第二句的相似度 sim = cosine_similarity(embeddings[0], embeddings[1]) print(f"相似度: {sim:.4f}") sim2 = cosine_similarity(embeddings[0], embeddings[2]) print(f"相似度: {sim2:.4f}")跑完你会发现，前两条句子的相似度很高（比如0.85以上），第一条和第三条的相似度很低（比如0.3左右）。这就是Embedding模型的语义区分能力——它不会因为字面都包含"天气"二字就把"外卖"混进来。
工程上的注意事项是：如果你没有归一化，就要用完整的余弦公式，分母是向量模长的乘积。不过大多数现代模型库都支持归一化选项，建议直接开启。我在实际项目中，遇到过有同事没注意归一化，导致后面相似度分数整体偏高或偏低分布不理想的情况，排查了半天发现是没有归一化造成的。
3.4 批量编码与文档切片的实操处理
实际业务中的文本不是清清爽爽的一句话，而是一篇篇长短不一的文档。你需要先把文档切块，再逐批编码。这一步有不少讲究。
文档切片的粒度直接决定检索精度。切得太粗，一块文本包含多个主题，向量表达"四不像"，检索时会召回一些不相关的内容；切得太细，上下文信息不完整，语义表达单薄。实操中常用的策略是：优先按章节标题切分，其次是按段落，段落过长再按固定长度切并且要保留少量重叠。
以固定长度切分为例，伪代码如下：
def split_text(text, chunk_size=300, overlap=50): """ 按大致长度切分文本，带重叠。 这里假设中文按字符数切分，英文则建议按Token数切分。 """ chunks = [] start = 0 while start < len(text): end = start + chunk_size chunk = text[start:end] chunks.append(chunk) if end >= len(text): break start = end - overlap return chunksoverlap的作用是避免一句话正好被从中间切断，导致前半句在上一块、后半句在下一块，两块的语义都不完整。重叠区域让上下文信息有一定的连续性。不过重叠也不是越大越好，重叠太多会导致数据膨胀，存储和计算成本上升。
批量编码的时候，要注意模型的max_seq_length。你可以先把切片后的文本分批，每批尽量控制在模型能力范围内。有些模型库会自动截断，有些会报错，你要先确认清楚。我之前测试某开源模型时，默认最大长度是256个Token，而我的切片平均有400个字符，直接跑导致大部分文档的后半段被截掉，召回效果变得很奇怪。后来把切片长度调下来，或者改模型的max_seq_length配置，问题才解决。
3.5 从向量化到存储、检索的闭环代码
向量生成出来后，下一步是存储和检索。我以FAISS为例，给出一个构建索引和查询的完整例子，这样你可以看到一个最小的闭环。
import faiss import numpy as np # 假设你已经把一批文档切片并编码为向量 # doc_embeddings: shape = (num_docs, dim) doc_embeddings = model.encode(all_chunks, normalize_embeddings=True) dim = doc_embeddings.shape[1] index = faiss.IndexFlatIP(dim) index.add(doc_embeddings.astype("float32")) # 查询 query_embedding = model.encode(["今天天气怎么样"], normalize_embeddings=True) D, I = index.search(query_embedding.astype("float32"), k=5) for idx, score in zip(I[0], D[0]): print(f"文档块索引: {idx}, 相似度: {score:.4f}") print(all_chunks[idx]) print("---")IndexFlatIP是暴力精确检索，数据量大了可以用IndexIVFFlat或IndexHNSW加速。但我要提醒你，在数据量小于十万这个量级时，暴力检索的速度完全可以接受，不必过度设计。很多新手一上来就整个HNSW，参数没调好反而精度下降，先精确检索把流程跑通，再考虑优化索引。
另外，astype("float32")这步不是多余的。Embedding模型输出的通常是float32已经是，但有的库会输出float64或默认的Python浮点，FAISS只接受指定类型，这一步是为了避免类型不匹配报错。
至此，一个最小的Embedding加RAG检索链路就跑通了：文本切片、向量化、建索引、查索引。后面再接上大模型做生成，就是一个完整的问答系统。
4. Embedding模型实操中常见的坑与排查思路
4.1 相似度分数异常偏低，甚至出现负值
有朋友跑完相似度计算，发现两条明显相关的文本相似度只有0.1甚至为负，第一反应是模型不行。其实先别急着换模型，多数情况是余弦相似度和模型默认的距离度量不匹配导致的。
有些模型训练时用的相似度标准是余弦相似度，但有些用的是内积，还有些模型内部做的是其他形式的距离计算。如果你拿一个为内积检索训练的模型去算余弦，分数分布就会很不正常。解决办法很简单：先看模型的说明文档，确认它的推荐用法，用配套的方式计算相似度。还有一个考量是query和document的向量可能由不同的模型或不同的池化方式生成，导致向量空间不对齐，这时需要检查两端模型是否一致。
4.2 中文效果差：分词器不匹配，还是语料领域太偏？
模型在中文上表现不佳，通常有两个原因。第一个原因是模型本身是面向英文或多语言的，中文只是"能处理"而不是"擅长处理"——这个只能换模型。第二个原因是你的语料领域太专业，比如医学、法律、代码，而模型训练语料里这类内容覆盖不足。
对于第二个原因，除了换更针对性微调的模型之外，还有一个轻量化的思路：在切分文档时，把领域术语尽量保持在同一个片段内。这样模型在编码时至少能看到完整的术语上下文，比术语被切得七零八落要好很多。如果预算允许，也可以考虑用领域语料对开源Embedding模型做持续训练，这个属于进阶玩法了，我这里不展开讲。
还有一点值得注意，很多时候中文效果"差"是因为query写得太短了。比如用户输入"劳动合同纠纷怎么处理"，但你的文档片段写的是"用人单位与劳动者因合同解除产生的争议处理流程"，二者语义虽然相关，但query缺少足够的上下文。工程上常见的做法是做query扩展，把短查询改写得更完整一些再检索。这个优化往往比换Embedding模型更立竿见影。
4.3 数据量大了以后索引和查询性能下降
随着文档量增长，暴力索引的查询延迟会逐渐不可接受。这时需要切换到近似最近邻（ANN）索引。但是用这类索引的过程中，我遇到过两个常见问题：其一是索引参数没调好，召回率明显下降；其二是索引构建后没有定期更新。
以IVF索引为例，nlist代表聚类的数量，nprobe代表查询时搜索的聚类个数。nprobe越大，召回越准但越慢；nlist越大，建索引越慢但初始筛选质量越高。新手容易把nlist设置得过大，导致每个聚类里样本太少，聚类失真。我的经验是先按文档数量开平方来估算nlist，再根据召回率实测调nprobe。
对于HNSW图索引，核心参数是M（每个节点的最大连接数）和efSearch（查询时搜索的候选集大小）。M大则图更稠密，精度高但内存开销大；efSearch大则查询越精细但延迟增加。这方面没有银弹，只能做一组对照实验，或者做一个较小的验证集来评估召回的准确性。
4.4 批量Embedding时显存和内存不足
开源模型虽然香，但一次性把所有文档全部编码，显存或内存很容易爆掉。我见过有人加载一个大一点的Embedding模型后，直接用整个文档列表调model.encode，结果内存占用飙升，甚至进程被系统杀掉。
正确的做法是分批处理，比如每批256条文本，编码一批保存一批，再释放内存。还可以视情况关闭梯度计算，并用推理模式减少显存占用：
import torch model = SentenceTransformer("例/某中文Embedding模型名称") batch_size = 256 all_chunks = [...] # 你的切片 embeddings = [] for i in range(0, len(all_chunks), batch_size): batch = all_chunks[i:i+batch_size] with torch.no_grad(): batch_embeddings = model.encode(batch, normalize_embeddings=True) embeddings.append(batch_embeddings) import numpy as np embeddings = np.vstack(embeddings)此外，如果你的服务是常驻的，最好把Embedding模型加载逻辑做成单例，不要每次请求都重复加载模型。这个问题在生产环境非常常见，每次请求都从硬盘加载模型会带来不可接受的延迟。模型加载一次放内存里，后面做纯推理就好。
4.5 长文档的表征：平均池化还是特殊Token？
长文本的向量表征质量，是Embedding应用里的一个经典难题。很多模型默认对所有输出Token取平均，这在短文本上效果不错，但在长文本上，关键信息会被大量无关内容稀释。
遇到这种问题，有几个处理思路：第一个思路是前面提到的切片策略，别让模型吃一整篇长文，切成若干有语义独立性的片段；第二个思路是，如果模型支持，可以尝试用加权池化的方式，对重要Token赋予更高权重；第三个思路是在检索阶段做一个粗排加精排的两级流程——Embedding先召回候选，再用重排序模型（例如基于交叉编码器的模型）对候选做精排。重排模型虽然更慢，但只作用于少量候选，整体流程的性能仍可控。
我在一个实际项目中，最初只用Embedding做相似度排序，结果top5结果里总混入一些"表面相关但不精确"的内容。加上重排之后，准确率提升非常明显。所以如果你的场景对精度要求很高，一定要把重排纳入方案，而不是指望Embedding模型一步到位。
5. Embedding效果评估的方法：不是看着像就行
5.1 为什么不能凭感觉判断模型好坏
很多人在选Embedding模型的时候，就是拿几条文本跑一下，看看相似度分数合不合理，觉得"好像挺准的"就定了。这在Demo阶段没什么问题，做正式项目就危险了——你的直觉只覆盖了你试过的几条样本，而真实线上数据分布要复杂得多。
正规的评估思路是构造一个评估集，里面包含一组查询（query），以及从你的文档库里人工标注的对应正相关文档和负相关文档。然后跑一遍检索流程，算出召回率、准确率、MRR（平均倒数排名）或NDCG（归一化折损累计增益）之类的指标。
我建议每一个打算长期做RAG的项目，都用这种评估方式记录基线和每次变更后的效果变化，否则你调整切片长度、调换Embedding模型时，完全无法判断改动是变得更好还是更差，这会让你在优化过程中寸步难行。
5.2 构造最小可行评估集的实践
最小可行的评估集不必很大，50条query、每条标注3到5个相关文档块，就够了。关键在于覆盖你业务里真实出现的query类型，不需要追求均衡分布——真实业务长什么样，评估集就长什么样。
构造时可以把query按难度分类：字面匹配就能命中的、需要同义改写才能命中的、需要跨段落理解才能命中的、答案分散在多处的。分类之后你会更清楚自己系统的短板在哪：如果同义改写类query召回差，问题多半在Embedding模型；如果跨段落理解类query召回差，也许切片策略的问题更大一些。这比笼统地说一句"效果不好"有用得多。
5.3 从指标到决策：如何根据评估结果调整方案
当你有了评估集并跑出了指标，接下来的决策逻辑就比较清晰了：
- 如果整体召回率低，且各类query都差，优先检查切片长度和文档预处理，再考虑换Embedding模型。
- 如果只有复杂语义类query差，优先考虑换更强的Embedding模型，或者引入重排器。
- 如果是因为中文专有名词、术语导致的问题，可以尝试保留术语上下文的切片方式或领域微调。
- 如果检索精度尚可，但召回的排序不够理想，可以加入重排策略。
这一套流程走下来，你会发现优化RAG不是拍脑袋的事情，而是有迹可循的。Embedding模型只是其中一环，但它是最基础的一环——地基打得稳不稳，直接决定了上面所有环节的发挥空间。
6. 写在最后的实践经验
我个人在实际项目中摸索下来，有几条经验值得沉淀一下。
第一，Embedding模型不是越新越强，而是要跟你的数据特征匹配。有些新发布的大模型确实很强，但参数量大、推理慢；有些老一些的轻量模型在特定领域表现反而更稳。先拿小规模真实数据跑一轮评估，再决定用哪个。
第二，向量维度不是越高越好。我看到有些团队动不动就选1024维以上的模型，结果数据量一大，存储成本跟着暴涨，而检索精度并没有实质性提升。在能满足业务精度的大前提下，尽量选择更低维度的模型。
第三，文本切片粒度对效果的影响，常常比换模型还大。同样一个Embedding模型，好的切片和坏的切片，检索效果能差出几个档次。这块值得你花时间精细打磨。
第四，工具链的适配性很重要。你选定的Embedding模型和你准备用的向量数据库、检索库之间，是否兼容、是否支持直接接入，这些细节最好在选型阶段就确认清楚，否则后面对接时会耗费大量时间在格式转换和数据适配上。
Embedding模型这个东西，看起来只是一个文本向量化的工具，但它在RAG链路里承担的语义理解功能，决定了你的检索系统是"能搜到"还是"搜得准"。希望这一节内容能帮你少走一些弯路，把向量化这一步走扎实。后面再遇到检索效果不佳，你也可以有条理地排查是Embedding的问题，还是下游环节的问题了。
