GEM: A Generative Embedding Model Bridging Reasoning and Retrieval
Zhili Shen, Craig Macdonald
cs.CL, cs.AI, cs.IR
2026-08-13
GEM 把推理和嵌入做进同一个 4B 模型,先生成对用户意图的推理再编码,在 BRIGHT 上拿到 29.1 的 nDCG@10,超过 8B 的 ReasonIR,配 GPT-4 推理后持平更大模型。
用户现在习惯用一句自然语言把复杂需求丢给 AI,比如「这段 Python 语法的名字是什么,顺便举几个简单例子」。可检索系统还停留在关键词和字面相似度的层面,query 和相关文档表面不沾边时,召回就崩。已有的两条修补路线都有短板。一条是上游 LLM 先把 query 推理扩写再交给检索器,要养两个模型,而且说不清提升到底来自真理解还是单纯的词面重叠变多。另一条是让用户自己写「相关文档应该满足什么」的指令,但用户往往写不清。GEM 要解决的是把推理这件事做进检索模型自己,让它理解意图再嵌入。
GEM 建在 Qwen3-4B-Instruct 上,核心是一个先生成后编码的流程。给定 query,模型先按一条 meta-instruction 推理用户意图和相关性标准,生成一段 reasoning;然后在这段 prompt-response 后面接一个 embedding token,把增强后的上下文编码成向量去检索。文档侧只编码,不生成。
让生成和嵌入并存是难点。一般 LLM 嵌入模型做成 bi-encoder 后,生成能力会因灾难性遗忘或双向注意力退化。GEM 用联合训练撑住两条:因果语言建模损失(lambda gen 取 0.1)保住生成,对比 InfoNCE 损失(lambda emb 取 1.0)学嵌入,温度 0.02。
数据对齐是另一处功夫。推理可能跑偏,作者的做法是:对每个 query 采样 8 条 reasoning,用一个相关性分类器过滤掉与正样本矛盾的,只保留对得上的;再以保留下来的 reasoning 为条件,用 Llama-3.1-8B 生成正样本和「同主题但微妙矛盾」的硬负样本,逼模型不能只靠词面匹配。
推理密集检索基准 BRIGHT 上,单模型设置:
| 模型 | 平均 nDCG@10 |
| BM25 | 14.8 |
| Promptriever(7B) | 20.0 |
| Qwen3-4B-Instruct(仅嵌入) | 21.4 |
| ReasonIR-8B | 24.4 |
| GEM(4B) | 29.1 |
同一个 4B 骨干,纯嵌入版只有 21.4,加上自家推理跳到 29.1,定理类任务从 19.8 涨到 32.0。配上 GPT-4 生成的推理(流水线设置),GEM 到 30.0,跟 8B 的 ReasonIR(29.9)和 Rank1-32B(29.4)持平,而它只有 4B。
指令遵循检索(FollowIR)上,GEM 的 p-MRR 是 +11.7,跟体量大得多的 Promptriever(+11.2)持平,把同一骨干的纯嵌入版(+6.8)甩开。测试时还能像普通指令模型一样加算力:在 prompt 里要求生成约 1024 词时,nDCG@10 到 30.1 后趋平。
GEM 证明检索模型自带的生成能力没被浪费,把它和嵌入绑在一起训反而两头都受益。对做 RAG 的人来说,这意味着不用再维护推理模型加检索模型的两段流水线,一个 4B 模型就能在难 query 上追上 8B 加 GPT-4 的组合。测试时加算力的特性也让它能在难问题上临时加大投入。
算力有限,作者没能用 7B 或更大的骨干复现,骨干实验都卡在 4B。数据生成里的 LLM 幻觉只能靠过滤缓解,不能根除。Pony 编程语言任务上 GEM 反而不如纯嵌入版,作者归因于训练数据里没有 Pony,是泛化问题。最有意思的一条来自 RQ4:把 GEM 自己的 reasoning 直接拼到别的模型上做 query 扩展,p-MRR 反而掉,说明收益来自联合训练,不是推理文本本身。