我自己的原文哦~ https://blog.51cto.com/whaosoft/12413878
#MCTrack
迈驰&旷视最新MCTrack：KITTI/nuScenes/Waymo三榜单SOTA
paper：MCTrack: A Unified 3D Multi-Object Tracking Framework for Autonomous Driving
code：https://github.com/megvii-research/MCTrack
机构：迈驰智行、旷视、国防科大、川大、中科大
1. 写在前面&出发点
自2016年SORT[1]算法提出以来，多目标跟踪任务已经经历了多年的发展，从最初的TBD(Tracking-By-Detection)范式发展到TBA(Tracking-By-Attention), JDT(Joint-Detection-Tracking)等范式，从单模态到多模态跟踪，从2D跟踪发展到3D跟踪，可谓百花齐放，百家争鸣。在3D跟踪领域，KITTI、nuScenes和Waymo是常用的数据集，它们各有特点，数据格式差异显著，采集场景和帧率也尽不相同。迄今为止，几乎没有一种方法能够在这三个数据集上都达到SOTA性能。
而对于评价指标而言，目前主流的包含MOTA, AMOTA, HOTA等，这些指标均是在评价一条轨迹是否能够正确、稳定匹配上，但是对于匹配之后，跟踪这个任务所需要对下游预测规划输出的关键信息（如速度、加速度、角速度）是否合理、是否能满足需求依然打个问号？这也就意味着我们缺乏对运动信息的评测指标。
基于上述问题：
我们的目标是首先提供一种统一的感知结果格式，以便在不同数据集上刷榜时，无需担心数据格式的差异。
其次，我们希望提供一个统一的跟踪框架，能够在KITTI、nuScenes和Waymo这三个常用数据集上都达到SOTA性能。
最后，我们希望建立一套“运动指标”，用以评估跟踪任务输出给下游任务的运动信息（如速度、加速度等）的正确性，这其实在实际工程应用中至关重要。
2. 领域背景
3D多目标跟踪在自动驾驶领域作为感知与预测规划任务之间的桥梁，扮演着至关重要的角色。学术界已经提出了多种跟踪范式，包括基于检测的跟踪（TBD）、基于注意力的跟踪（TBA）和联合检测跟踪（JDT）等。通常情况下，TBD范式在各方面的性能都优于其他范式，并且由于其不需要GPU资源，这极大地推动了该范式在工程中的应用。总体来看，TBD范式的方法主要分为两个步骤：首先是目标检测，然后是数据关联，具体流程如图1所示。
图1
- 检测：通常利用现有的检测器得到感知结果
- 数据关联：利用感知结果与历史轨迹进行多对多的匹配，通常会涉及到代价函数的计算、匹配函数的选择、卡尔曼滤波预测等等。
很显然，这种范式下，跟踪结果很大程度上依赖于感知模块的性能。通常来说，感知性能越出色，跟踪效果也越好。这种范式在某种程度上既有优势也有劣势。其优势在于结构简单明了，不需要复杂的处理步骤，工程落地非常容易。劣势一在于由于跟踪过程基于检测结果而非原始数据（如外观特征等），一旦检测性能下降，跟踪性能也会随之受到影响。劣势二在于这种方式很难处理密集场景，一旦场景中目标数量过多，仅通过空间位置关系来计算相似度会非常困难，但对于自驾场景而言，无论是高速还是城区，障碍物并不会过多，即通过空间位置关系通常是可以hold住的（当然，引入特征是更好的）。尽管目前在各大3D MOT榜单上基于TBD范式的性能已经比较好了，但我们认为依旧没有达到这类范式的上限，可靠稳定的代价函数依然待发掘。
另一方面，在学术研究中，大家对跟踪任务的关注点通常集中在轨迹连接的准确性，而连接后的进一步处理往往被忽视。然而，在工业界，跟踪任务作为感知的最下游，负责汇总和优化各类信息，并将结果传递给预测和规划模块。这其中包括了诸如速度、加速度等重要的运动信息，而这些信息在学术界的跟踪任务中几乎没有涉及。这在一定程度上反映了学术界与工业界的某种脱节。
在以上背景下，诞生了MCTrack（MC--迈驰智行），提供了一套统一的pipeline，一套评估速度的运动指标。
3. MCTrack
3.1 统一数据格式
我们对KITTI、nuScenes和Waymo三大数据集的感知结果格式进行了统一整合，这意味着只要采用TBD范式的方法，便可以直接使用这一统一格式，通过一套pipeline运行三个数据集，无需编写多个预处理脚本来适配不同数据集。我们将按照场景、帧、障碍物、全局信息等维度进行存储，整体格式包含以下内容：
image2024-10-18_19-38-6.png
3.2 整体框架
整体框架遵循简单直接的TBD范式，先进行检测，再进行匹配，并通过不同维度的信息接入卡尔曼滤波器，以确保输出给下游模块的信息稳定性。值得注意的是，在匹配阶段，我们采用了多视角相似度计算方法，首先在BEV平面上进行第一次匹配，然后在RV平面（图像2D平面）上进行第二次匹配。相似度计算过程中，我们提出了更为鲁棒的Ro_GDIoU。
https://picx.zhimg.com/80/v2-436883a9be383d7fb17ad978b7f6ffd9_1440w.png
3.3 Ro_GDIoU
在3D多目标跟踪中，常用的代价矩阵包括IoU、GIoU、DIoU和欧式距离等。在3D空间中，交并比和距离是两种不同的度量方式：交并比及其变体侧重于从体积上衡量两个3D框的相似度，而距离则用于描述两个框之间的相对接近程度。在跟踪任务中，仅使用其中一种度量方式进行匹配，无法确保在各类场景中都取得理想效果。DIoU在某种程度上结合了交并比和欧氏距离，但当两个框之间没有交集时，DIoU退化为纯距离度量，无法同时兼顾体积相似度和中心点接近度。一个显而易见的改进是将GIoU和DIoU融合在一起。
基于此，我们提出了Ro_GDIoU，这是一种融合了旋转角、交并比与中心距离的更强相似度计算方法。旋转角的引入如图所示：当将3D框投影到BEV平面时，这些框通常会呈现不同的角度。如果像在2D检测任务中那样将其“掰正”，将无法准确衡量两个框的真实相似度。因此，需要按照它们的实际朝向来计算交并比，以更准确地反映它们的相似性。
Ro_GDIoU具体计算方式如下面的伪代码所示：
3.4 不同维度的匹配方式
二次匹配其实并非是一个新颖的操作，诸多SOTA方法都有涉及。我们在实验中发现，之所以需要二次匹配，是因为所使用的代价函数无法自调节以适应感知框的抖动，导致无法采用统一相似度阈值来度量，所以自然而然就诞生了二次匹配。通常而言，这些方法都会选择在第二次匹配时使用更加宽松的匹配阈值，但问题在于感知的抖动能通过放大匹配阈值来消除掉吗？在工程中我们发现一个非常有意思的现象，基于图像的3D感知在深度上时常会出现抖动，尤其是对于远距离的小目标而言，有时抖动会达到10m以上。这种情况下，仅通过调整匹配阈值无法完全解决问题，依然会出现frag和idsw。我们尝试将3D框投影到前视平面上（即压缩深度），虽然在一定程度上缓解了问题，但也导致后视目标与前视目标出现错误匹配，这显然是不可接受的。于是，我们进一步尝试在不同相机视角下进行投影，以确保不同视角的目标不会相互匹配，从而形成了本文中的二次匹配模块。整体的匹配流程如下图的伪代码所示：
4. 运动指标
为了解决当前多目标跟踪（MOT）评估指标未能充分考虑运动属性的问题，我们提出了一系列新的运动指标，包括速度角度误差（VAE）、速度范数误差（VNE）、速度角度倒数误差（VAIE）、速度反转比（VIR）、速度平滑度误差（VSE）和速度延迟误差（VDE）。这些运动指标旨在全面评估跟踪系统处理运动特征的性能，涵盖速度、角度及速度平滑度等运动信息的准确性和稳定性。在这里我们主要介绍速度平滑度误差（VSE）和速度延迟误差（VDE）两大指标，这两个指标在自驾工程应用中至关重要。什么样的速度对于下游控制是可接受的？答案是既要响应快速，又需要足够平稳。当前方障碍物急剧减速或加速时，跟踪系统应能迅速响应，并提供准确的速度预测。显然，雷达传感器依赖多普勒效应能够生成相对完美的速度曲线，但实际上，雷达的FP较多，并且并不总是能在每一时刻都匹配上。因此，跟踪模块仍需通过位置采用滤波器来提供一套速度预测。然而，如何衡量速度的优劣便成了一个关键问题。
- 速度延迟误差（VDE）
首先，计算真实速度（gt）的峰值点，并设定窗口大小为 w。在峰值点的前后各取 w/2个点。同时，基于 gt 的峰值点，在计算滤波速度的时候取 w个点，并设定一个滑动窗口 tau。这样可以提取出tau组滤波速度，并计算这tau组数据与 gt 的差值。接着，通过计算差值的均值和方差，选择均值和方差最小的那组tau×帧率，这就是对应的延迟误差（单位：秒）。具体计算过程如下：
借助论文的一幅图来说明该指标的重要性：该图展示了两辆以每小时100公里速度行驶的车辆：红色车辆表示自动驾驶车辆，白色车辆表示前方障碍物。两车之间的初始安全距离设定为100米。假设在时间点 t_m 时，前车开始紧急减速，并在时间点 t_n 时将速度降至每小时60公里。如果自动驾驶车辆在感知前车速度上存在延迟，则可能会错误地认为前车仍然以每小时100公里的速度行驶，这会导致两车之间的安全距离在不知不觉中缩短。直到时间点 t_n 时，自动驾驶车辆才最终感知到前车的减速，但此时安全距离可能已经非常接近极限。
- 速度平滑度误差（VSE）
平滑性误差不涉及到gt，首先对原始dt使用SG滤波器进行平滑，将平滑后的dt与原始dt计算差值并求和，理论上，如果一条曲线足够平滑，那么将该条曲线送到滤波器再次进行平滑其效果并不大，即依然会接近原始曲线，此时平滑性误差最小。
显然，该指标并非越小越好，因为通过越平滑则相应就会越滞后，故该指标需要结合速度滞后性误差一起使用。如下图所示：红色曲线为gt，蓝色和绿色曲线分别表示两种方法求得的速度曲线，显然，蓝色曲线非常平滑，但是滞后，而绿色曲线尽管抖动较大但相应较快。平滑性误差不依赖于真实值（gt）。首先，我们对原始的滤波速度使用SG滤波器（Savitzky-Golay）进行平滑处理，然后计算平滑后的滤波速度与原始滤波速度 之间的差值并进行求和。理论上，如果一条曲线足够平滑，那么将其输入滤波器进行再次平滑的效果就不会明显，结果仍然会接近原始曲线，此时平滑性误差达到最小。
5. 实验
5.1 定量实验
正如前言所述，我们希望提供一套统一的ppl，因此，我们在当前常用的3D MOT数据集上（如KITTI、nuScenes和Waymo）进行了测试。总体而言，我们在KITTI和nuScenes数据集中取得了第一名，而在Waymo数据集中获得了第二名。值得一提的是，Waymo第一名所采用的检测方法在mAP等指标上比本文使用的检测器高出两个点，因此我们认为这两者之间并不具备可比性。
nuScenes跟踪榜单第一
KITTI跟踪榜单第一
Waymo跟踪榜单第二
与SOTA方法对比
****
5.2 运动指标评估在本文中，我们提出了多种速度计算方法，包括差分法、卡尔曼滤波和曲线拟合等。这三种方法各有优缺点。此外，速度的计算并不限于上述几种方式。我们希望能够提供一个完善的评估指标，鼓励大家不仅关注轨迹连接的准确性，还要关注在正确连接后，如何更好地输出下游控制所需的速度等信息。
5.3 消融实验将本文提出的Ro_GDIoU分别融合到当前KITTI和nuScenes的SOTA方法中，其中PolyMOT在当时的nuScenes排名中位居第一。我们发现，将Ro_GDIoU应用于该方法时，MOTA指标提升了1.1个点，同时nuScenes的主要评价指标AMOTA也提升了0.4个点。此外，在另一个数据集KITTI上，使用当时的SOTA方法结合Ro_GDIoU也实现了不同程度的提升。
对于二次匹配，在公开数据集上的提升非常有限。这是因为我们所使用的检测器均基于点云，虽然这类方法在深度方向上相对准确，但值得注意的是，检测器性能较差时，基于RV的二次匹配所带来的提升会更加明显。
6. 总结
在本文中，我们提出了一种简洁且统一适用于自动驾驶领域的3D多目标跟踪方法。我们的方法在多个数据集上均取得了SOTA性能。此外，我们对不同数据集的感知格式进行了标准化处理，这样大家能够专注于多目标跟踪算法的研究，而无需由于数据集格式差异而引发的繁琐预处理工作。最后，我们引入了一组全新的运动评估指标，希望大家关注对下游应用至关重要的运动属性。
#MambaBEV
MambaBEV成功将Mamba2引入BEV目标检测
MambaBEV是一个专为自动驾驶系统设计的基于Mamba2的高效3D检测模型。该模型利用了鸟瞰图（BEV）范式，并整合了时序信息，同时提高了检测的稳定性和准确性。在nuScences数据集上，该模型具有出色的表现。
对于自动驾驶系统而言，更安全、准确地进行3D目标检测至关重要。历史上，这些感知系统主要依赖霍夫变换和关键点提取等技术构建基础框架。然而，深度学习的兴起使得感知精度的重大飞跃。
然而，单目相机的感知方法仍面临诸多挑战，尤其是距离感知误差大和盲区范围广，这些问题对驾驶安全构成了显著威胁。为了解决距离误差问题，研究人员提出了双目立体匹配技术，通过利用一对相机捕获图像之间的视差，在一定程度上改善了距离估计的准确性。然而，这些系统仍然存在关键的局限性：它们无法感知车辆侧面和后部的物体及车道标记，从而在自动驾驶系统的安全范围内留下空白。
为了应对这些局限性，最新的研究探索了使用环视相机系统进行感知，该系统通常包括六个相机。这种方法为每个相机输入部署独立的深度学习模型，并依赖后处理技术将各个输出整合为对环境的一致感知。尽管这种方法克服了单目和双目系统的局限性，但也引入了一系列新挑战，包括大量的GPU内存消耗、感知冗余、跨相机视图的目标重新识别，以及缺乏跨相机的信息交互。这些因素共同影响了感知系统的效率和有效性。
图1 MambaBEV的框架。
为了解决这些障碍，基于鸟瞰图（BEV）的范式作为一种有前景的解决方案应运而生。这种方法将多个相机的输入整合到一个统一的BEV表示中，从而使车辆周围环境的全面理解成为可能。通过直接将图像数据映射到环境的俯视图，BEV方法促进了更准确的距离估计和障碍物检测，同时有效解决了盲区问题。此外，这种方法还促进了不同相机视图之间的信息高效共享，从而增强了感知系统的整体鲁棒性和可靠性。
另一个关键方面是处理时序数据。单帧检测虽然简单，但常常因为帧间目标遮挡和特征不明显而错过检测。为了解决这些问题，整合时序融合技术，利用历史特征来增强当前特征，已被证明可以显著提高模型性能。然而，传统的时序融合范式主要依赖自注意力机制，导致高内存消耗、有限的全局感受野，以及较慢的训练和推理速度。因此，开发一种新的时序融合方法以克服这些缺点具有重要的工程意义。
最近，一个专门处理序列的新模型mamba在多个下游任务中展现出巨大的潜力。Mamba2是mamba的改进版本，在多个任务上显示了更优的性能。这种新方法采用基于块分解的矩阵乘法，并利用GPU的存储层次结构，从而提高了训练速度。将mamba2引入3D自动驾驶感知是一个值得探索的方向。为了解决时序融合模块面临的问题，作者提出了MambaBEV，这是一个基于BEV的3D感知模型，使用了mamba2。据作者所知，这是首次将Mamba2整合到基于相机的3D目标检测网络中。
作者提出了一种基于mamba2的3D目标检测范式，命名为MambaBEV。该方法采用了一个基于mamba-CNN的模块，名为TemporalMamba，用于融合不同帧中的BEV特征。此外，作者在解码器层设计了一种mamba-detr头部，以进一步优化检测效果。
A.预备知识
结构化状态空间模型（SSMs）是一类深度学习模型，特别适用于序列建模任务。通过利用这些结构化公式，SSMs在表达性与计算效率之间提供了一种权衡，成为与基于注意力的模型（如Transformer）的一种有效替代。SSMs的公式代表了推进深度学习中序列建模的一个有前景的方向。作者使用的基模型称为Mamba2，它基于结构化状态空间（S4）序列模型，这些模型根植于连续系统。这些模型通过采取1-D输入序列或函数和一个中间隐藏状态， ，如下所示：
它结合了一个可学习的步长，并采用零阶保持将连续系统转换为离散系统。注意，如果设置D为0，则可以忽略Du(t)。因此，方程（1）可以重写为：
通过应用数学归纳法，的最终输出可以表示为：
其中M定义为：
表示从到的矩阵乘积，索引j和i分别表示第j个和第i个A，B，C矩阵。Mamba2中的变换矩阵M也符合N-序半可分离（SSS）表示的定义。因此，在Mamba2框架内，SSM和SSS的表示是等价的。这种等价性允许在涉及SSM的计算中高效利用结构化矩阵乘法进行SSS。为了实现这种方法，参数矩阵M被分解为对角块和低秩块，分别使用结构化掩码注意力（SMA）二次模式算法和SMA线性模式算法。此外，多头注意力（MHA）被集成以增强模型的性能。
图2 TemporalMamba的总体框架。
B.总体架构
MambaBEV的主要结构在图1中展示。该模型可以总结为四个主要模块：图像特征编码器、后向投影（SCA）、TemporalMamba和Mamba-DETR头部。MambaBEV以六个相机图像为输入，并通过图像特征编码器生成六个多尺度特征图。这些特征图随后被送入名为空间交叉注意力（SCA）的后向投影模块，以生成BEV特征图。
接下来，历史BEV特征与当前BEV特征进行融合，用于指导生成新的当前BEV特征。此过程由作者提出的TemporalMamba块执行。经过多层处理后，最终使用mamba-DETR头部作为3D目标检测的输出模块。
C. 图像特征编码器
图像特征编码器由两部分组成：高效的主干和经典的颈部。针对场景中不同视图的六张图片，作者使用在ImageNet上预训练的经典ResNet-50、从FCOS3D检查点初始化的ResNet-101-DCN，以及非常有效的VoV-99（同样来自FCOS3D检查点）作为主干，以提取每张图片的高级特征。Vmamba也可以作为主干。为了更好地提取特征并提升性能，作者采用经典的特征金字塔网络（FPN）生成多尺度特征。
图3 Query重组。
D. TemporalMamba块
对于传统的基于注意力的时序融合块，作者采用了可变形自注意力。Temporal Self-Attention（TSA）主要遵循以下流程：首先，给定历史BEV特征图和当前特征图，TSA将它们连接，并通过线性层生成注意力权重和偏移量。然后，每个查询（代表BEV特征）根据权重进行并行计算。然而，作者认为这种方法存在一些副作用。尽管可变形注意力可以降低计算成本，但由于每个参考查询仅允许与三个查询交互，导致大尺寸物体特征在跨帧交互中受到限制。
模型使用了mamba以增强全局交互能力。首先，两种模态的特征通过自我旋转角度进行变换，并通过一个卷积块将维度从512压缩到256，如图2所示。
在处理历史BEV特征图和当前特征图（每个维度为256）时，首先在第三维度将它们连接，连接后的特征分别经过两次带有批归一化的3x3卷积层和一次带有批归一化的1x1卷积层，然后将它们相加。
然后，作者对特征图Z进行离散重排，并通过mamba2块处理。典型的mamba2块是为自然语言处理设计的，旨在处理序列，但在应用于视觉数据时面临重大挑战。因此，设计合适的离散重排方法至关重要。基于实验并受到Vmamba的启发，作者设计了四种不同方向的重排方法，并讨论了这些方法在消融研究中的影响。
作者创新性地提出了一种多方向特征序列扫描机制，其中特征图Z被离散序列化，并以四个方向：向前左、向前上、向后左和向后上重新组合，如图3所示，形成新的序列作为Mamba2模型的输入。值得注意的是，作者没有采用蛇形螺旋重组合方法，因为他们认为这种方法会导致相邻特征之间的交互不平衡，一些相邻特征可能过于接近，而其他特征则相距甚远。mamba输出增强的序列特征，然后重新组合并恢复图4中显示的原始顺序。接着，作者计算四个张量的平均值，并将以0.9的dropout率生成的增强融合BEV特征图作为跳跃连接添加到当前BEV特征图中。
图4 Query融合。
E. Mamba-DETR头部
如图1所示，作者重新设计了一个结合mamba和传统DETR编码器的mamba-DETR头部。在此结构中，900个目标查询首先在mamba2块中进行预处理，并相互之间进行交互，承担与自注意力相同的职责。随后，mamba块的输出将像传统的CustomMSDeformableAttention那样，通过可变形注意力进行处理。
在实验中，MambaBEV在nuScenes数据集上表现出色，其基础版本实现了51.7%的NDS（nuScenes Detection Score）。此外，MambaBEV还在端到端自动驾驶范式中进行了测试，展现了良好的性能。在3D对象检测任务中，MambaBEV-base相较于仅使用单帧的BEVFormer-S，在mAP和NDS上分别提高了3.51%和5.97%，充分显示了TemporalMamba块的有效性。当添加TemporalMamba块时，平均速度误差降低了37%，表明历史信息，特别是经过TemporalMamba块处理的信息，可以显著改善速度估计，因为它提供了宝贵的历史位置信息。
表1 在nuScenes验证集上的3D目标检测结果。
表2 开环规划性能。
表3 动态预测。
表4 拼接方法与卷积方法的消融对比。
表5 不同窗口大小造成的影响。
表6 不同重排方法的比较
表7 BEV特征不同分辨率的影响
MambaBEV是一种基于BEV范式和mamba2结构的创新3D目标检测模型，充分利用时序信息以处理动态场景。在nuScenes数据集上实现51.7%的NDS，突出了其有效性和准确性。通过引入TemporalMamba块，MambaBEV有效整合历史信息，改善速度估计和目标检测性能。与传统卷积层和可变形自注意力相比，该模型在全局信息交换上更具优势，并且优化了计算成本。为适应端到端的自动驾驶范式，MambaBEV结合了mamba和传统DETR编码器的特性，展现出良好的潜力，尤其在自动驾驶应用中具有可观的发展前景。
#RAG实战全解析
1. 背景介绍
RAG（Retrieval Augmented Generation，检索增强生成 ）方法是指结合了基于检索的模型和生成模型的能力，以提高生成文本的质量和相关性。该方法是Meta在2020年发表的文章《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》中提出的，该方法让LM（Language Model，语言模型）能够获取内化知识之外的信息，并允许LM在专业知识库的基础上，以更准确的方式回答问题。而在大模型时代，它更是用于解决幻觉问题、知识时效问题、超长文本问题等各种大模型本身制约或不足的必要技术。
2. RAG的挑战
RAG主要面临三个方面的挑战：检索质量、增强过程和生成质量。
2.1 检索质量
语义歧义：向量表示（例如词嵌入）可能无法捕捉概念之间的细微差别。例如，“苹果”一词可能指的是水果或科技公司。嵌入可能会混淆这些含义，导致不相关的结果。
用户输入变复杂：与传统关键词或者短语搜索逻辑不太一致，用户输入问题不再是词或者短句，而是转变成自然对话声知识多轮对话数据，问题形式更加多元，紧密关联上下文，输入风格更加口语化。
文档切分：文档切分主要有两种方式：一种是基于形式的切分，比如利用标点和段落的结束；另一种是基于文档内容的意义进行切分。如何将这些文档块转换成电脑能够理解和比较的形式（即“嵌入”），进而影响这些块与用户搜索内容的匹配程度。
多模内容的提取及表征（例如表格、图表、公式等）：如何对多模内容进行提取及动态表征，是目前面临的现实问题，尤其是处理那些含糊或负面的查询，对 RAG 系统的性能有显著影响。
2.2 增强过程
上下文的集成：这里的挑战是将检索到的段落的上下文与当前的生成任务顺利地集成。如果做得不好，输出可能会显得脱节或缺乏连贯性。
冗余和重复：如果多个检索到的段落包含相似的信息，则生成步骤可能会产生重复的内容。
排名和优先级：确定多个检索到的段落对于生成任务的重要性或相关性可能具有挑战性。增强过程必须适当权衡每个段落的价值。
2.3 生成质量
- 过度依赖检索内容：生成模型可能过于依赖增强信息，导致幻觉问题突出，而不是增加价值或提供合成。
- 无关性：这是另一个令人担忧的问题，即模型生成的答案无法解决查询问题。
- 毒性或偏见：这也是另一个问题，即模型生成的答案有害或令人反感。
3. 整体架构3.1 产品架构
从图上可以清晰的看出，整个产品架构包含如下四层：
- 最底层是模型层。在模型层屏蔽掉了模型的差异，不仅可以支持自研的序列猴子，也可以支持开源的大模型，第三方的模型。此外，为了优化embedding的效果，提出一种跨语言Embedding模型，有效的解决跨语言检索问题，同时提高了模型的效果。
- 离线理解层。在该层，主要围绕智能知识库和搜索增强两个模块设计的。关于智能知识库主要负责将非结构化的文本进行处理，从而转化为检索知识库，主要包括文本解析，表格识别，OCR识别等。搜索增强通过引入问句改写、重排等模块，保证检索的精准度。
- 在线问答层，为了满足产品设计需要，这里支持多文档、多轮次、多模态及安全性与拒识等，在一定程度上提高了产品的竞争力，同时也满足了不同场景的用户需求。
- 场景层，针对不同行业的特点，预制多种场景类角色，降低产品使用门槛。
3.2 技术架构
为了理解检索增强生成框架，我们将其分为三个主要组成部分：query理解、检索模型和生成模型。
- query理解：该模块旨在对用户的query进行理解或者将用户的query生成结构化的查询，既可以查询结构化的数据库也可以查询非结构化的数据，进而提高召回率。该模块包括四部分，他们分别是query改写，query扩写和意图识别等。各个模块的介绍我们将在之后的章节进行详细介绍。
- 检索模型：该模型旨在从给定的文档集或知识库中检索相关信息。他们通常使用信息检索或语义搜索等技术来根据给定的查询识别最相关的信息。基于检索的模型擅长查找准确且具体的信息，但缺乏生成创意或新颖内容的能力。从技术上来讲， 检索模型主要包括文档加载、文本转换、Embedding等模块。我们将在之后的章节中详细介绍。
- 生成模型：该模型旨在根据给定的Prompt或上下文生成新内容。目前，生成模型可以生成富有创意且连贯的文本，但它们可能会在事实准确性或与特定上下文的相关性方面遇到困难。在RAG框架中，生成模型主要包括chat系统（长期记忆和短期记忆）、Prompt优化等。这些内容在之后的章节中也会介绍。
总之，检索增强生成结合了检索模型和生成模型优势，克服它们各自的局限性。在此框架中，基于检索的模型用于根据给定的查询或上下文从知识库或一组文档中检索相关信息。然后，检索到的信息将用作生成模型的输入或附加上下文。通过整合检索到的信息，生成模型可以利用基于检索的模型的准确性和特异性来生成更相关、更准确的文本。这有助于生成模型立足于现有知识，生成与检索信息一致的文本。
4. Query理解
目前，RAG系统可能会遇到从知识库中检索到与用户query不相关的内容。这是由于如下问题：（1）用户问题的措辞可能不利于检索，（2）可能需要从用户问题生成结构化查询。为了解决上述问题，我们引入query理解模块。
4.1 意图识别
意图识别是指接收用户的query和一组"选择"（由元数据定义）并返回一个或多个选定的"选择模块"。它既可以单独使用（作为 "选择器模块"），也可以作为查询引擎或检索器使用（例如，在其他查询引擎/检索器之上）。它是原理简单但功能强大的模块，目前主要利用 LLM 实现决策功能。它可以应用于如下场景：
- 在各种数据源中选择正确的数据源；
- 决定是进行摘要（如使用摘要索引查询引擎）还是进行语义搜索（如使用矢量索引查询引擎）；
- 决定是否一次 "尝试 "多种选择并将结果合并（使用多路由功能）。
核心模块有以下几种形式：
- LLM 选择器将选择作为文本转储到提示中，并使用 LLM 做出决定；
- 构建传统的分类模型，包括基于语义匹配的分类模型、Bert意图分类模型等。
4.2 Query改写
该模块主要利用LLM重新措辞用户query，而不是直接使用原始的用户query进行检索。这是因为对于RAG系统来说，在现实世界中原始query不可能总是最佳的检索条件。
4.2.1 HyDE
Hypothetical Document Embeddings（HyDE）是一种生成文档嵌入以检索相关文档而不需要实际训练数据的技术。首先，LLM创建一个假设答案来响应query。虽然这个答案反映了与query相关的模式，但它包含的信息可能在事实上并不准确。接下来，query和生成的答案都被转换为嵌入。然后，系统从预定义的数据库中识别并检索在向量空间中最接近这些嵌入的实际文档。
4.2.2 Rewrite-Retrieve-Read
这项工作引入了一个新的框架--Rewrite-Retrieve-Read，从query改写的角度改进了检索增强方法。之前的研究主要是调整检索器或LLM。与之不同的是，该方法注重query的适应性。因为对于 LLM 来说，原始query并不总是最佳检索结果，尤其是在现实世界中。首先利用LLM 进行改写query，然后进行检索增强。同时，为了进一步提高改写的效果，应用小语言模型（T5）作为可训练的改写器，改写搜索query以满足冻结检索器和 LLM的需要。为了对改写器进行微调，该方法还使用伪数据进行有监督的热身训练。然后，将 "先检索后生成 "管道建模为强化学习环境。通过最大化管道性能的奖励，改写器被进一步训练为策略模型。
4.3 Query扩写
该模块主要是为了将复杂问题拆解为子问题。该技术使用分而治之的方法来处理复杂的问题。它首先分析问题，并将其分解为更简单的子问题，每个子问题会从提供部分答案的相关文件检索答案。然后，收集这些中间结果，并将所有部分结果合成为最终响应。
4.3.1 Step-Back Prompting
该工作探索了LLM如何通过抽象和推理两个步骤来处理涉及许多低级细节的复杂任务。第一步先是使用 LLM "后退一步"生成高层次的抽象概念，将推理建立在抽象概念的基础上，以减少在中间推理步骤中出错的概率。这种方法即可以在有检索的情况下使用，也可以在无检索的情况下使用。当在有检索情况下使用时，抽象的概念和原始问题都用来进行检索，然后这两个结果都用来作为LLM响应的基础。
4.3.2 CoVe
Chain of Verification (CoVe) 旨在通过系统地验证和完善回答以尽量减少不准确性，从而提高大型语言模型所提供答案的可靠性，特别是在事实性问题和回答场景中。它背后的概念是基于这样一种理念，即大型语言模型（LLM）生成的响应可以用来验证自身。这种自我验证过程可用于评估初始响应的准确性，并使其更加精确。
在RAG系统中，针对用户实际场景中日益复杂的问题，借鉴了 CoVe技术，将复杂 Prompt 拆分为多个独立且能并行检索的搜索友好型query，让LLM对每个子查询进行定向知识库搜索，最终提供更准确详实答案的同时减少幻觉输出。
4.3.3 RAG-Fusion
在这种方法中，原始query经过LLM 生成多个query。然后可以并行执行这些搜索查询，并将检索到的结果一并传递。当一个问题可能依赖于多个子问题时，这种方法就非常有用。RAG-Fusion便是这种方法的代表，它是一种搜索方法，旨在弥合传统搜索范式与人类查询的多面性之间的差距。这种方法先是采用LLM生成多重查询，之后使用倒数排名融合（Reciprocal Rank Fusion，RRF）来重新排序。
4.3.4 ReAct
最近，在RAG系统中，使用ReAct思想，将复杂查询分解成更简单的"子查询"，知识库的不同部分可能会围绕整个查询回答不同的 "子查询"。这对组合图尤其有用。在组成图中，一个查询可以路由到多个子索引，每个子索引代表整个知识语料库的一个子集。通过查询分解，我们可以在任何给定的索引中将查询转化为更合适的问题。
ReAct的模式如上图所示，它是将思维链提示（Chain of Thoughts，简写为CoT）和Action计划生成结合起来，相互补充增强，提升大模型解决问题的能力。其中CoT的Reasoning推理跟踪有助于模型诱导、跟踪和更新行动计划以及处理异常。Action操作允许它与知识库或环境等外部来源接口并收集其他信息。
4.4 Query重构
考虑Query理解模块整体pipeline的效率，参考Query改写和Query扩写核心思想，自研了Query重构模块，该模块强调了通过一次请求，实现对原始用户输入的复杂问题进行改写、拆解和拓展，挖掘用户更深层次的子问题，从而借助子问题检索效果更高的特点来解决复杂问题检索质量偏差的问题，旨在提高查询的准确性和效率。
- 检索模型
5.1 检索模型的挑战
- 依赖于Embedding模型的向量化是否准确
- 依赖于外部数据是否有合理的分割（不能所有的知识转化成一个向量，而是需要分割数据后转化再存入向量数据库）
- 依赖于Prompt拼接，当我们将返回的最相似的文档进行排序后，与用户的问题一起送给大模型，实际上是想让大模型在长上下文中准确识别定位到合适的内容进行回答。
《Lost in the Middle: How Language Models Use Long Contexts》文章指出，当相关信息出现在输入上下文的开头或结尾时，性能往往最高，而当模型必须在长上下文中间获取相关信息时，性能会明显下降，即使对于明确的长上下文模型也是如此。
5.2 架构5.3 文档加载器
文档加载器提供了一种 "加载 "方法，用于从配置源加载文档数据。文档数据是一段文本和相关元数据。文档加载器可从多种不同来源加载文档。例如，有一些文档加载器可以加载简单的 .txt 文件或者加载任何网页的文本内容，甚至加载 YouTube 视频的副本。此外，文档加载器还可以选择实现 "懒加载"，以便将数据懒加载到内存中。
5.4 文本转换器
检索的一个关键部分是只获取文档的相关部分。当加载文档后，通常需要对其进行转换，以便更好地适应应用程序。这涉及几个转换步骤，以便为检索文档做好准备。其中一个主要步骤是将大型文档分割（或分块）成较小的块，即文本转换器。最简单的例子是，当需要处理长篇文本时，有必要将文本分割成若干块，以便能放入模型的上下文窗口中。理想情况下，希望将语义相关的文本片段放在一起。这听起来很简单，但潜在的复杂性却很大。
5.4.1 工作原理
- 将文本分割成语义上有意义的小块（通常是句子）。
- 开始将这些小块组合成一个大块，直到达到一定的大小（用某个函数来衡量）。
- 一旦达到一定大小，就将该语块作为自己的文本，然后开始创建有一定重叠的新语块（以保持语块之间的上下文）。
5.4.2 常见如下文本转换器类型5.4.3 评估文本转换器
你可以使用 Greg Kamradt 创建的 Chunkviz 工具来评估文本转换器。Chunkviz 是可视化文本转换器工作情况的工具。它可以向你展示文本的分割情况，并帮助你调整分割参数。
5.5 文本嵌入模型
检索的另一个关键部分是文档嵌入模型。文档嵌入模型会创建一段文本的向量表示。它可以捕捉文本的语义，让你快速有效地找到文本中相似的其他片段。这非常有用，因为它意味着我们可以在向量空间中思考文本，并进行语义搜索等操作。
理想情况下，检索器应该具备将不同语种的翻译文本做关联的能力（跨语种检索能力），具备将长原文和短摘要进行关联的能力，具备将不同表述但相同语义的文本做关联的能力，具备将不同问题但相同意图的问题进行关联的能力，具备将问题和可能的答案文本进行关联的能力。此外，为了给大模型尽可能高质量的知识片段，检索器还应该给出尽可能多的相关片段，并且真正有用的片段应该在更靠前的位置，可以过滤掉低质量文本片段。最后，期望我们的模型可以覆盖尽可能多的领域和场景，可以实现一个模型打通多个业务场景，让用户获得开箱即用的模型，不需要再做微调。
关于文档嵌入模型，这里向大家推荐看一下《从MTEB看RAG：深入理解embedding评估，让AI更懂你！》文章。
5.6 向量数据库
随着嵌入式的兴起，人们开始需要向量数据库来支持这些嵌入式的高效存储和搜索。存储和搜索非结构化数据的最常见方法之一是嵌入数据并存储由此产生的嵌入向量，然后在查询时嵌入非结构化查询并检索与嵌入查询 "最相似 "的嵌入向量。向量数据库负责存储嵌入数据并执行向量搜索。
关于向量数据库，这里向大家推荐看一下《大模型引发爆发增长的向量数据库》文章。如果对向量数据库已经有认知了，可以直接跳过本节进行阅读。
5.7 索引
经过前面的数据读取和文本分块操作后，接着就需要对处理好的数据进行索引。索引是一种数据结构，用于快速检索出与用户查询相关的文本内容。它是检索增强 LLM 的核心基础组件之一。
下面介绍几种常见的索引结构。为了说明不同的索引结构，引入节点(Node)的概念。在这里，节点就是前面步骤中对文档切分后生成的文本块(Chunk)。下面的索引结构图来自 LlamaIndex 的《 How Each Index Works》。
5.7.1 摘要索引（以前称为链式索引）
摘要索引只是将节点存储为顺序链。在后续的检索和生成阶段，可以简单地顺序遍历所有节点，也可以基于关键词进行过滤。
5.7.2 树索引
树索引将一组节点 ( 文本块 ) 构建成具有层级的树状索引结构，其从叶节点 (原始文本块) 向上构建，每个父节点都是子节点的摘要。在检索阶段，既可以从根节点向下进行遍历，也可以直接利用根节点的信息。树索引提供了一种更高效地查询长文本块的方式，它还可以用于从文本的不同部分提取信息。与链式索引不同，树索引无需按顺序查询。
5.7.3 关键词表索引
关键词表索引从每个节点中提取关键词，构建了每个关键词到相应节点的多对多映射，意味着每个关键词可能指向多个节点，每个节点也可能包含多个关键词。在检索阶段，可以基于用户查询中的关键词对节点进行筛选。
5.7.4 向量索引
向量索引是当前最流行的一种索引方法。这种方法一般利用文本嵌入模型将文本块映射成一个固定长度的向量，然后存储在向量数据库中。检索的时候，对用户查询文本采用同样的Embedding模型映射成向量，然后基于向量相似度计算获取最相似的一个或者多个节点。
5.8 排序和后处理
经过前面的检索过程可能会得到很多相关文档，就需要进行筛选和排序。常用的筛选和排序策略包括：
- 基于相似度分数进行过滤和排序
- 基于关键词进行过滤，比如限定包含或者不包含某些关键词
- 让 LLM 基于返回的相关文档及其相关性得分来重新排序
- 基于时间进行过滤和排序，比如只筛选最新的相关文档
- 基于时间对相似度进行加权，然后进行排序和筛选
6. 生成模型6.1 回复生成策略
检索模块基于用户查询检索出相关的文本块，回复生成模块让 LLM 利用检索出的相关信息来生成对原始查询的回复。这里给出一些不同的回复生成策略。
- 一种策略是依次结合每个检索出的相关文本块，每次不断修正生成的回复。这样的话，有多少个独立的相关文本块，就会产生多少次的 LLM 调用。
- 一种策略是在每次 LLM 调用时，尽可能多地在 Prompt 中填充文本块。如果一个 Prompt 中填充不下，则采用类似的操作构建多个 Prompt，多个 Prompt 的调用可以采用和前一种相同的回复修正策略。
6.2 prompt拼接策略
用于将提示的不同部分组合在一起。您可以使用字符串提示或聊天提示来执行此操作。以这种方式构建提示可以轻松地重用组件。
6.2.1 字符串提示
使用字符串提示时，每个模板都会连接在一起。您可以直接使用提示或字符串（列表中的第一个元素必须是提示）。例如，langchain提供的prompttemplate。
6.2.2 聊天提示
聊天提示由消息列表组成。纯粹为了开发人员体验，我们添加了一种便捷的方式来创建这些提示。在此管道中，每个新元素都是最终提示中的一条新消息。例如，langchain提供的AIMessage, HumanMessage, SystemMessage。
7. 插件（Demonstration Retriever for In-Context Learning，基于演示检索的上下文学习）
上下文学习（In-Context learning）是一种新兴的范式，它是指通过给定一些示范性的输入-输出对（示例），在不更新模型参数的情况下实现对给定测试输入的预测。它独特的无需更新参数能力使得上下文学习的方法可以通过一个语言模型的推理，来统一各种自然语言处理任务，这使其成为监督式微调的一个有前途的替代方案。
虽然，这种方法在各种自然语言处理的任务中都表现不错，但它的表现依赖给定的示范性输入-输出对。在模型的prompt中为每个任务都指定示范性示例会影响prompt的长度，这导致每次调用大语言模型的成本增加，甚至超出模型的输入长度。因此，这带来一个全新的研究方向——基于演示检索的上下文学习。这类方法主要是通过文本（或语义）检索与测试输入在文本或语义上相似的候选示范性示例，将用户的输入与获得相似的示范性示例加入到模型prompt中作为模型的输入，则模型就可以给出正确的预测结果。然而，上述单一的检索策略使得召回率不高，造成示范性示例无法精准召回，致使模型的效果不佳。
为了解决上述问题，我们提出了一种基于混合演示检索的上下文学习方法。该方法充分考虑不同检索模型的优劣，提出一种融合算法，通过利用文本检索（例如，BM25和TF-IDF）和语义检索（例如，OpenAI embedding-ada和sentence-bert）进行多路召回，解决单路召回率不高的问题。然而，这带来全新的挑战，即如何将不同的召回结果进行融合。这是由于不同检索算法分数范围不匹配，例如，文本检索分数通常在 0 和某个最大值之间（这具体取决于查询的相关性）；而语义搜索（例如，余弦相似度）生成 0 到 1 之间的分数，这使得直接对召回结果进行排序变得很棘手。因此，我们又提出一种基于倒序排序融合算法（Reciprocal Rank fusion）的重排方法，该算法在不需要调整模型的情况下，利用位置来组合不同检索算法的结果，同时，考虑到大模型对相关信息出现在输入上下文的开头或结尾时，性能往往最高，设计重排算法，从获得高质量的融合结果。
具体的模型架构如下图所示，它包括检索模块、重排模块和生成模块。
7.1 检索模块
检索模块又分为文本检索和语义检索。
语义检索采用双塔模型，用OpenAI的embedding-ada作为表征模型，分别对用户的输入和每个任务的候选示例进行表征，获取语义向量，之后利用k-近邻算法（K-Nearest Neighbor，KNN）计算语义相似度，并依据相似度对候选结果进行排序。其中，对于每个任务的候选示例我们采用离线表征，并将其存入向量数据库中，这是因为一旦任务确认，每个任务的候选示例是固定不变的。而对于用户的输入，我们采用实时表征，提高计算效率，这是因为用户的输入是多样的、不固定的。
文本检索，我们先是对每个任务的候选示例进行文本预处理，去除掉停用词、特殊符号等。同时，在文本检索中采用倒排索引的技术加速查询，并利用BM25计算文本相似度，最后按相似度进行排序。
7.2 重排模块
对于重排模块，我们提出了一种基于倒序排序融合的重排算法。该方法先是为了解决不同召回算法的分数范围不匹配的问题，我们引入倒序排序融合算法，对多路的召回结果进行融合排序。虽然倒序排序融合算法可以很好将多路召回进行融合排序，但是这种排序无法满足大模型具有对相关信息出现在输入上下文的开头或结尾时性能最高的特性。这使得简简单单的利用倒序排序融合进行输出，效果不好。因此，我们在此基础之上对融合排序后的结果进行重排，排序策略是依据融合排序后的结果进行两端填充排序。例如，原本的顺序为[1,2,3,4,5]，进行重排后的顺序为[1,3,5,4,2]。
7.3 生成模块
生成模块可以生成富有创意且连贯的文本，它旨在根据给定的Prompt或上下文生成新内容，这里我们设计了prompt组装模块，通过将系统prompt与检索到相关信息进行组合。此外，还在组装模块中融入长期对话记录和短期对话记录进行prompt封装。
- 引用或归因（attribution）生成
8.1 什么是引用或归因
在RAG 的知识问答场景下，随着越来越多的文档、网页等信息被注入应用中，越来越多开发者意识到信息来源的重要性，它可以让模型生成的内容能够与参考信息的内容作出对齐，提供证据来源，确保信息准确性，使得大模型的回答更加真实。
这里为了统一，在之后的文章中用“归因”特指“引用或归因”。
8.2 归因的作用
用户角度：能够验证模型的回答是否靠谱。模型角度：提高准确性并减少幻觉。
8.3 如何实现归因
8.3.1 模型生成
直接让模型生成归因信息。可在Prompt 添加类似“每个生成的证据都需在参考信息中进行引用”的话。这种方法最简单，但也对模型的指令遵循能力要求较高，一般会采用GPT-4 回答，或者微调模型让模型学习在生成时附带引用的回答方式。缺点也很明显，极度依赖模型的能力（甚至可能引用也是编的），且针对实际场景中出现的badcase 修复周期长，干预能力弱。
8.3.2 动态计算
在模型生成的过程中进行引用信息的附加。具体的操作为在流式生成的场景下，对生成的文本进行语义单元的判断（比如句号，换行段落等），当出现一个完整的语义单元时，将该语义单元和参考信息中的每个参考源进行匹配（关键字，embedding等），通过卡阈值的办法找到Top-N 的参考源，从而将参考源进行附加返回。这种方法的实现相比方法一简单了很多，badcase 修复周期也短，但受限于匹配方式和阈值，且存在一个前提假设：模型的生成文本来源于参考信息。
更多关于归因研究的工作可以参考：A Survey of Large Language Models Attribution 或 LLM+RAG 中关于回答片段归因的讨论
9. 评估
做开发的同学不管用没用过，对 TDD(Test-Driven Development)的大名总归是听过的，类似的，开发大模型应用的时候也应该有个对应的 MDD(Metrics-Driven Development) 的概念，最舒服的姿势肯定是预先定义好业务的场景、用到的数据、设定的指标以及需要达到的分值，然后按部就班的实现既定目标，员工士气高老板也开心！
但理想和现实之间总是如此纠缠，对大部分的大模型开发任务来讲，更常见的情况是场景定义不清楚，数据光清洗就累死三军，至于需要的指标和目标？想都没想过！这一次，我们来补上本应该在最最开始的就考虑的，大模型应用如何量化业务指标，具体的，如何量化的证明，你的 RAG 就是比隔壁老王他们组的牛？到底该拿哪些量化的指标去说服同行？
影响RAG系统性能的几个方面：
- 位置偏见：LLMs 有可能对文本中特定位置的内容给予更高的关注，比如位于段落开头和结尾的内容更容易被采纳。
- 检索内容相关性：由于query的表达多样性，使得RAG系统可能检索到不相关的内容，这种不相关的内容为LLMs理解带来噪音，增加模型的负担。
9.1 评测指标
- Faithfulness是指用于评测生成的回答是否忠实于contexts，这对于避免幻觉并确保检索到的上下文可以作为生成答案的理由非常重要。
- Answer Relevance是指的生成的答案应解决所提供的实际问题。
- Context Relevance是指检索的上下文应重点突出，尽可能少地包含无关信息。理想情况下，检索到的上下文应该只包含处理所提供查询的基本信息。包含的冗余信息越少，context_relevancy越高。
9.2 评测方法
9.2.1 RGB（Benchmarking Large Language Models in Retrieval-Augmented Generation）
这一工作系统地研究了检索增强生成对大型语言模型的影响。它分析了不同大型语言模型在RAG所需的4项基本能力方面的表现，包括噪声鲁棒性、拒答、信息整合和反事实鲁棒性，并建立了检索增强生成基准。此外，现在做RAG都是做的pipeline，涉及到切块、相关性召回、拒答等多个环节，每个环节都可以单独做评测，文中提到的4个能力其实可以影射到每个环节当中。
9.2.2 RAGAS（RAGAS: Automated Evaluation of Retrieval Augmented Generation）
该工作提出了一种对检索增强生成（RAG）pipeline进行无参考评估的框架。该框架考虑检索系统识别相关和重点上下文段落的能力， LLM以忠实方式利用这些段落的能力，以及生成本身的质量。目前，该方法已经开源，具体可以参见github：GitHub - exploding gradients/ragas: Evaluation framework for your Retrieval Augmented Generation (RAG) pipelines
9.2.3 Llamalindex-Evaluating
LlamaIndex提供了衡量生成结果质量的关键模块。同时，还提供关键模块来衡量检索质量。
10. 总结
LLM这一波，催生的技术真的很多，每一个环节，要真正做好，符合企业应用，都可以让我们研究好长一段时间，并需要不断去实践，才能打磨出精品。本文总结了过去一年在RAG实践的关键模块，希望本文总结对大家有一定的帮助。此外，本文还属于大模型应用——RAG的一个大纲式的技术普及文章，这里面的很多技术细节，我们会在后面一篇篇专门来写。可以让我们研究好长一段时间，并需要不断去实践，才能打磨出精品。但是如果打磨出精品，你肯定可以摘取新技术带来的果实。本文可能还是属于大模型应用——RAG的一个大纲式的技术普及文章，这里面的很多技术细节，我们会在后面一篇篇专门来写。
