Chunking-free RAG

发布于:2025-07-07 ⋅ 阅读:(30) ⋅ 点赞:(0)

参考:

  • BGE Landmark Embedding原论文:《https://arxiv.org/pdf/2402.11573》

  • Chunking-Free In-Context Retrieval原论文:《https://arxiv.org/pdf/2402.09760》

RAG中chunk大小的选择很重要,过大会丧失文本的精确语义,过小会导致文本不连贯。与此同时,RAG存在不可避免地的限制:一方面,输入序列被划分为不连贯的块,从而破坏了上下文的连贯性,不利于嵌入质量。另一方面,连续信息也很可能被分割到不同的块中。突出的块可以很容易地被检索到,但其他有用但不太突出的块可能会被忽略,导致必要信息检索的不完整性

所以,这两篇工作尝试探索不需要分块的RAG工作流。

BGE Landmark Embedding

这篇文章没有对长文本进行分块,而是在每句话的末尾都加一个标志这句话结束的符号<LMK>,并在尝试用这个符号去代表前面整句话的语义(当<LMK>输入到embedding模型中时,会返回一个代表这个句子语义的向量)。那倘若这句话的长度超过max_token数量怎么办?->作者设置一个滑动窗口去采样。【问:此处作者设置的步长为1,这是否会导致有大量重复存储呢?

那么这个思路的符号化表达就是:

无滑动窗口的情况下,将这段话+LMK标志都输入到embedding模型中,并取他的最后一个向量(LMK的embedding)作为这句话的语义;再将query+LMK标志输入到embedding模型中,并取他的最后一个向量(LMK的embedding)作为这句话的语义。二者作余弦相似度的计算。

在有滑动窗口的情况下:

现有的embedding对于<LMK>,输出的肯定是其本身的语义向量,而非这句话的语义向量,因此还需要训练。

那训练的优化目标是啥呢?->正确的提取文本的余弦相似度的softmax。

但不妨看下面这个例子

在查询“Bill在星期天下午去哪了”这个问题时,我们很有可能因为检测到“Billl”和"Sunday"而错误的检测到第一句话,从而给出答案:埃菲尔铁塔。然而事实上,Bill早上去了埃菲尔铁塔,但他在星期天下午去的是卢浮宫。

就像在做英语阅读理解的时候,我们找关键字往往不是直接找出来的,还需要联系上下文进行一定的推理,因此文章提出:对于每个QA对,在损失函数中,我们不单单考虑正确语句的<LMK>的embedding,我们还需要考虑它前文的embedding,但是又不是所有的语句的重要性都一样,于是我们默认离正确答案越近的语句越重要,从而乘以一个权重\omega被相加。

但这样的话,我们又没有了有标签的数据(常有的数据集多是针对查询与单一语句结果的),因此我们还需要重新构建数据集再微调,分三步:远程监督->弱监督->微调。

Chunking-Free In-Context Retrieval

主要分以下几个步骤

  1. 编码阶段:文档 A 被编码为隐藏状态 h 并缓存。

  2. 解码阶段

    • 约束前缀解码:生成Top-k 句子前缀候选(如“Bach was...”)。

    • 跳跃解码:对每个前缀,在文档中定位匹配的句子,直接计算其结尾的 [eos] 概率,跳过中间token生成。

  3. 输出:合并重叠证据文本,得到最终检索结果。

具体如何选取的topk呢?

每个候选前缀的得分s是其token对数概率的均值,如下,其中 h 是文档的缓存隐藏状态,q 是查询。

如何计算句子结束位置([eos])的概率?

给定前缀 b,模型在文档中所有以 b 开头的句子中,计算每个句子结尾处 [eos] 的概率,选择概率最高的位置终止:

其中 l 是前缀后的token序列,d 是最大解码长度(默认256)。

感觉这个方向比较奇怪,说不上来...