微信扫一扫,关注公众号

  • 科技行者

  • 算力行者

见证连接与计算的「力量」

首页 香港科技大学最新研究:让AI检索系统摆脱"人工标注"束缚,用预测未来的方式学会寻找信息

香港科技大学最新研究:让AI检索系统摆脱"人工标注"束缚,用预测未来的方式学会寻找信息

2026-06-29 09:49
分享至:
----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.-
2026-06-29 09:49 科技行者

这项由香港科技大学研究团队完成的研究,以预印本形式于2026年6月23日发布在arXiv平台,论文编号为arXiv:2606.24667。研究的核心成果是一套名为DREAM(Dense Retrieval Embeddings via Autoregressive Modeling)的训练方法,它试图回答一个颇具挑战性的问题:能否在不依赖人工标注的情况下,训练出高质量的信息检索模型?

当你在搜索引擎里键入一个问题,或者向ChatGPT这类AI助手提问时,背后往往有一个"向导"在悄悄工作——它负责从海量文档中找出最相关的内容,递给负责回答问题的AI。这个"向导"就是信息检索模型,也叫"密集检索器"(dense retriever)。它的好坏直接决定了AI系统最终能给你什么样的答案。

过去训练这种"向导"的方式,有点像在给一个图书管理员做培训:你需要准备大量例子,告诉它"这个问题对应的是这本书(正例),而不是那本书(负例)"。这个过程需要大量人工标注,耗时、耗力,而且标注本身也容易出错——比如有些文档其实也挺相关,却被错误地标为"不相关"(即"假负例"问题)。

香港科技大学的研究团队提出了一条完全不同的路:既然大型语言模型(LLM)天生擅长"预测下一个词",那能不能借助这种预测能力,来判断哪些文档对回答问题真正有帮助?如果一份文档真的包含有用信息,那么把它提供给LLM后,LLM预测后续内容的难度应该会明显降低。反过来,无关文档的存在几乎不会帮到LLM。DREAM正是把这个直觉变成了一套可行的训练方案。

一、为什么"预测下一个词"能教会AI找资料

以一个日常场景来理解这件事会更直观。假设你是一位厨师,正在尝试做一道从未做过的菜,你面前摆着十几张菜谱卡片,但只有其中一张是真正对口的。你的任务是选一张卡片来参考,然后尽可能准确地预测"接下来该往锅里放什么"。如果你选了那张对口的菜谱,你的预测会非常准确;如果你选了一张驴唇不对马嘴的菜谱,你的预测就会一塌糊涂。

DREAM的核心逻辑与这个场景如出一辙。研究团队让一个"检索器"(负责从文档堆里找答案的模型)为每份候选文档打分,分数越高代表该文档与当前问题越相关。然后,这些分数被注入到一个大型语言模型(LLM)里,影响LLM在"阅读"候选文档时分配注意力的方式——分数高的文档会获得更多"关注",分数低的文档则基本被忽视。接下来,LLM尝试预测目标内容(比如正确答案对应的那段文字),预测越准确,损失(loss)越低。如果检索器把高分给了真正有用的文档,LLM的预测损失就会降低,这个降低的信号会反向传递给检索器,告诉它"你这次选对了,继续保持"。

这个过程的妙处在于:LLM本身是冻结的,完全不更新参数,只有检索器在学习。LLM扮演的是一个"固定裁判"的角色,它的评判标准始终如一,使得检索器的学习信号稳定可靠。

二、把"检索分数"注入LLM的大脑——但要注入对地方

仅仅有这个想法还不够,真正的难题在于:LLM是一个黑盒,检索器算出来的分数怎么才能影响LLM内部的计算?

研究团队找到的突破口是"注意力机制"(attention mechanism)——这是现代LLM内部负责决定"读这段文字时,哪些词/段落应该被重点关注"的核心组件。可以把注意力机制理解成LLM的"眼神焦点",它决定了在回答问题时,LLM的"视线"会更多落在哪些文字上。

然而,LLM里有成百上千个注意力"头"(head,可以理解为不同的"视角"或"关注点"),每个头专注于不同类型的信息处理。有些头负责语法结构,有些头负责代词指代,有些头则恰好专注于"从文档中寻找与问题相关的证据"——后者被研究者称为"面向查询的检索头"(query-focused retrieval heads)。

DREAM的关键设计是:只把检索器的分数注入那些"检索头",而不是随意挑几个注意力头来注入。这就像如果你想影响一位侦探的办案思路,你应该把线索递给他用来分析案情的那双眼睛,而不是随便找他身上某个感官来干预。研究团队参考了此前学术界对LLM"检索头"的识别研究,在正式训练之前,先通过一套探针实验(probe experiments)找出哪些注意力头最擅长"根据问题去候选文档里找相关内容",然后只对这些头施加检索分数的影响。

具体的注入方式也颇为精妙:对于每一个被选中的检索头,DREAM把原有的注意力分布拆成两个层次。第一个层次是"选哪篇文档",这个由检索器的分数决定——检索器给某篇文档打了高分,该文档整体上就会获得更多注意力资源。第二个层次是"在选定文档里关注哪些具体词语",这个仍由LLM自己判断,不受检索分数干扰。最终,这两层注意力通过一个可学习的"混合门控"(gate,用sigmoid函数控制,取值在0到1之间)合并在一起,门控值越大,检索器的影响越强。这个门控本身也是训练过程中学到的,让系统自动调整检索器介入的程度。

三、训练数据从哪来?检索头怎么选?

训练数据的构建方式同样值得关注。研究团队从维基百科语料库出发,把每篇文档切成16个片段,形成一个"候选片段池"。从中随机选一个片段作为"目标段落",然后用Qwen3-14B(一个强大的大型语言模型)自动生成一个与该目标段落相关的问题。这样,每个训练样本就包含了:一个自动生成的问题、16个候选片段(其中一个是真正相关的目标片段)、以及目标片段本身。整个过程不需要人工标注相关性,只需要LLM来自动出题。

选择检索头的过程发生在正式训练之前。研究团队用了5000个样本,对冻结的Llama-3.1-8B-Instruct模型里的每一个注意力头进行评估:对于每个头,计算它从问题词元(token,可理解为词语单元)到各候选文档的平均注意力强度,再减去一个"基准值"(用"N/A"这种无意义的假问题替换真实问题时的注意力,以排除位置偏差和格式偏差的干扰),最后用NDCG@10这个检索质量指标来衡量每个头的"检索能力"。得分最高的前16个头被选入"检索头集合",后续训练中只有这些头会接受检索分数的注入。

四、竞争机制:让候选文档互相"争夺"注意力

DREAM的另一个关键设计是候选文档之间的"竞争"。检索器为16个候选文档分别打分后,这些分数通过softmax函数归一化为一个概率分布——所有文档的权重之和恰好为1。这意味着,如果你给某篇文档分配了更多"注意力资源",其余文档就必然得到更少。

这个竞争机制的妙处在于:它自动产生了"负样本"的效果,完全不需要费力去挖掘"困难负例"。当检索器把高分给了真正有用的文档,其余文档的权重被压低,LLM的预测损失下降,这个信号会鼓励检索器继续这样做。反过来,如果检索器误把高分给了无关文档,那篇真正有用的文档的权重被稀释,LLM预测变困难,损失上升,检索器就会受到"惩罚",促使它重新审视打分策略。

用温度参数(temperature,τ)来控制这个概率分布的"尖锐程度"也是系统设计的一部分——温度越低,高分文档和低分文档之间的差距被放大,竞争越激烈;温度越高,差距被平滑,竞争越温和。τ本身也是可学习的参数,在训练中自动调整到最优值。

五、实验结果:新方法到底比旧方法强多少?

研究团队在两个主流信息检索评测基准上进行了全面测试。BEIR涵盖了9个不同领域的检索任务,包括论点挖掘、生物医学、金融、科学和社区问答等;RTEB则涵盖14个任务,涉及法律、金融、代码、结构化数据和医学等领域。评价指标是NDCG@10,这个分数越高代表检索结果越准确(满分为1)。

研究团队用三种规模的嵌入模型(embedding model,即负责把文字转化为向量以便计算相似度的模型)作为检索器的"骨干",分别是参数量约5亿(0.5B)的Qwen2.5-0.5B、约10亿(1B)的Llama-3.2-1B和约30亿(3B)的Llama-3.2-3B。

对比的基线方法包括:BM25(一种传统的基于词频的检索方法,不需要神经网络)、InfoNCE(一种经典的对比学习方法,使用相同的训练数据和候选集,但用正负例对比的方式训练)、RePlug(一种先让LLM对文档打偏好分,再让检索器模仿这些偏好分的"知识蒸馏"方法)、Revela(一种用语言模型的文本预测损失来联合训练检索器和语言模型的方法)。

最终的成绩单令人印象深刻。在BEIR上,DREAM用0.5B骨干达到了0.4163的平均NDCG@10,用1B骨干达到了0.4888,用3B骨干达到了0.5074。相比之下,Revela(目前最强的同类基线)对应的成绩分别是0.4011、0.4075和0.4315。DREAM的提升幅度在0.015到0.081之间。在RTEB上,提升幅度更大,从0.068到0.102不等。这意味着,无论用哪个规模的检索器骨干,DREAM都稳定地超过了所有基线方法。

值得注意的是,DREAM甚至比InfoNCE更强,而InfoNCE和DREAM使用的是完全相同的训练数据和候选集——唯一的区别是训练目标不同。这说明DREAM带来的提升确实来自于训练方式本身,而不是数据优势。

在具体任务上,DREAM的优势并不局限于某一类任务。在BEIR的科学文献检索(SciFact)、生物医学检索(NFCorpus)、社区问答(CQADupStack)等多个子任务上,DREAM随着骨干规模增大而逐渐成为最强方法。在RTEB上,DREAM在代码检索(Apps、MBPP)和结构化数据检索(WikiSQL)上取得了尤为显著的提升——以Llama-3.2-3B为骨干时,WikiSQL上的NDCG@10高达0.8401,远超Revela的0.6196。

六、为什么必须选对检索头?随机注入会怎样?

为了验证"注入哪些注意力头"这个设计选择是否真的关键,研究团队做了一个直接的对比实验。他们分别测试了三种情况:把检索分数注入完全随机选取的注意力头、注入随机选取的中间层注意力头、以及注入用检索能力排名选出的前16个检索头。

结果非常能说明问题。用完全随机头注入时,BEIR上的平均NDCG@10仅有0.0637,RTEB上只有0.0320——几乎等于没有训练。用随机中间层头注入时,成绩有所改善,BEIR达到0.182,RTEB达到0.200,但与选定检索头的0.489和0.551相比,差距依然巨大。

这个结果的背后逻辑并不复杂:LLM是冻结的,不会去学习新的功能。如果你把检索分数注入一个本来负责处理语法的注意力头,你只是在扰乱它原本擅长的事情,产生的梯度信号对检索器来说是噪声,毫无意义。只有当检索分数注入那些本来就在做"从文档里找与问题相关信息"这件事的注意力头时,LLM的预测损失才会对"检索分数是否打对了"这件事敏感,反馈信号才有实际意义。

七、检索头的数量:多了不行,少了也不行

研究团队还测试了选取不同数量的检索头时的效果,从Top 1一直测到Top 64。结果显示了一个清晰的倒U形曲线。只选Top 1个头时,效果最差;随着头的数量增加到Top 16,BEIR和RTEB上的成绩持续上升;但当头的数量继续增加到Top 32和Top 64时,成绩反而下降。

这个现象背后的道理很直观:只有一个检索头,训练信号来源太单薄,容易产生偏差;选取16个头,多个独立的检索信号共同监督,训练更稳定。但如果盲目扩大范围到32个甚至64个头,难免混入一些检索能力较弱的头,它们对检索分数的敏感度不足,反而稀释了有用的训练信号。在Llama-3.2-1B这个骨干上,Top 16是最佳平衡点。

八、嵌入空间的几何形状——DREAM偷偷做到了对比学习的效果

研究团队还做了一个颇有趣味的分析,考察DREAM训练出来的检索器在"嵌入空间"(embedding space,即把文字转化为向量后所在的数学空间)里呈现出什么样的几何形态。

他们用两个指标来衡量:对齐度(Alignment,越低说明问题的向量和正确答案文档的向量越接近,代表检索器把相关内容拉得更近)和均匀性(Uniformity,越低说明所有向量在空间里分布越均匀,不会"扎堆"在某个角落)。理想的检索器应该既有好的对齐(相关内容互相靠近)又有好的均匀性(整体分布不塌陷)。

测试结果显示:RePlug训练出的检索器对齐度很好(问题和答案很近),但均匀性很差(向量空间严重塌陷,所有向量都挤在一起,区分度低)。Revela的均匀性有所改善,但对齐度相对较弱。DREAM则在均匀性上达到了所有方法中最好的水平,同时对齐度与Revela相当。

这个结果耐人寻味,因为均匀性的提升通常被认为是对比学习的专长——对比学习通过同时拉近正例、推远负例来让向量均匀分散。而DREAM完全没有使用对比学习目标,却自然地学出了类似的几何效果。原因可以追溯到候选文档间的竞争机制:因为所有候选文档的权重之和固定为1,检索器不仅要把真正有用的文档往查询方向拉,还要把无用文档往外推,这个隐性的推拉关系在无意间实现了类似对比学习的效果。

九、冻结LLM vs. 微调LLM:固定裁判才是公正裁判

研究团队还测试了一种变体:在训练过程中,不仅更新检索器的参数,也对LLM加上LoRA(一种参数高效微调方法)进行更新,看看两者共同优化是否会更好。

结果明确显示,冻结LLM的方案在所有四个对比(BEIR-1B、BEIR-3B、RTEB-1B、RTEB-3B)中都更优。原因也在情理之中:DREAM的训练逻辑依赖于一个稳定的"评判标准"——LLM的预测损失越低,说明检索器给出的文档越有用。如果LLM本身也在更新,它的预测损失可以通过改变自身行为来降低,而不一定是因为检索器选了更好的文档。这样一来,损失的下降就不再是检索质量提升的可靠信号,训练信号被污染,检索器反而学不好。固定LLM,就是固定了裁判的标准,让检索器只能通过"真正选好文档"来赢得奖励,而没有其他投机取巧的出路。

十、候选文档数量:竞争者越多,训练越充分

研究团队还系统测试了每个训练样本中候选文档数量的影响,分别测试了4个、8个和16个候选文档的设置。结论很一致:候选文档越多,BEIR和RTEB上的成绩越好。从4个增加到8个时提升明显,从8个增加到16个时还有进一步提升。

这与竞争机制的逻辑完全吻合:候选文档越多,每个训练步骤中需要比较的"对手"越多,检索器需要更精细地区分"有用"和"没用",训练信号也更加丰富。以16个候选文档作为默认设置,是在计算成本和训练效果之间取得的合理平衡。

十一、把模型做大:DREAM-8B能和专业级检索模型一较高下吗?

研究团队还尝试了更大规模的实验:以参数量约80亿(8B)的Llama-3.1-8B作为检索器骨干,用同样的训练方案训练出DREAM-8B。这个实验的目的不是刷新榜单,而是验证DREAM的训练范式在更大规模下是否依然有效。

对比对象包括几个业界熟知的强力嵌入模型:BGE-large-en-v1.5(达到BEIR 0.5360,RTEB 0.4943)、Cohere-embed-english-v3.0(BEIR 0.5406,RTEB 0.5083)、E5-mistral-7b-instruct(BEIR 0.5526,RTEB 0.6031)以及Qwen3-Embedding-8B(BEIR 0.6348,RTEB 0.7383)。

DREAM-8B在BEIR上达到0.5531,与E5-mistral-7b-instruct基本持平;在RTEB上达到0.6417,比E5-mistral-7b-instruct高出0.0386。研究团队坦率指出,DREAM-8B与Qwen3-Embedding-8B之间仍有差距,但这一比较需要谨慎解读——Qwen3-Embedding-8B基于不同的预训练骨干,且使用了精心策划的大规模标注数据集。DREAM-8B不依赖任何人工标注,能在如此有限的条件下达到这样的竞争力,本身就说明了autoregressive(自回归式)训练方案的规模可扩展性。

---

说到底,DREAM做的这件事,就是把一个"预测未来"的能力转化成了一个"判断好坏"的能力。大型语言模型天生会预测文字,DREAM让这种预测能力化身为评判信息是否有用的裁判,并通过注意力机制把这个判断信号传递给检索器,让检索器在没有任何人工标注的情况下学会如何找到真正有价值的文档。

这对我们日常使用AI工具意味着什么?未来的AI搜索助手、知识库问答系统可能不再需要依赖昂贵的人工标注数据,只需要大量原始文本和一个预训练好的语言模型,就能训练出可靠的检索核心。这意味着更低的构建成本、更快的迭代速度,以及在专业细分领域(如法律、医疗、代码)中更容易定制高质量的检索系统。

当然,这项研究本身也留下了一些开放问题。DREAM目前的候选文档池是从同一篇维基百科文章的不同片段中产生的,现实检索场景中的候选文档来自更广泛、更嘈杂的来源,这种训练设置与真实场景之间的差距需要进一步研究。此外,DREAM训练依赖于一个强大的冻结LLM作为"裁判",裁判本身的能力上限也在一定程度上决定了检索器能学到多好。这些问题,或许正是下一个研究团队可以着手探索的方向。

有兴趣深入了解完整技术细节的读者,可以通过论文编号arXiv:2606.24667查阅原文。

---

Q&A

Q1:DREAM训练密集检索器时需要人工标注正例和负例吗?

A:不需要。DREAM完全不依赖人工标注的相关性标签。它的训练数据来自维基百科的自动切片,用大语言模型自动生成配套问题,候选文档池由同一篇文章的其他片段构成。训练信号来自冻结LLM的下一词预测损失,而非人工标注的正负例对。

Q2:DREAM为什么只把检索分数注入特定的注意力头,注入所有头不行吗?

A:注入随机头效果极差。实验显示,注入完全随机头时BEIR得分仅约0.064,而注入精选检索头时可达0.489。原因在于LLM是冻结的,无法学习新功能,只有那些原本就在做"从文档中寻找与问题相关证据"的注意力头,才能让预测损失对检索分数是否准确保持敏感,从而为检索器提供有效的训练信号。

Q3:DREAM和RePlug、Revela这两种方法的根本区别是什么?

A:RePlug先让LLM对文档打偏好分,再让检索器模仿这些偏好分,检索分数不进入LLM内部计算。Revela联合训练检索器和语言模型,但针对的是连续文本块序列,没有明确的问题和目标答案。DREAM则把检索分数直接注入冻结LLM的注意力机制,让检索器通过"是否帮助LLM预测目标答案"来接受直接训练,信号路径更短且更精准。

分享至
0赞

好文章,需要你的鼓励

推荐文章
----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.-