【论文阅读】Seven Failure Points When Engineering a Retrieval Augmented Generation System

论文从软件工程的角度，通过对3个case study的研究，总结出rag的7个故障点。

Case Studies

3个case study的具体情况如下：

Cognitive Reviewer：论文文献阅读和问答，主要用于做linterature reviews.

AI Tutor: 学习助手，针对课程学习内容作答，包括文本和视频等内容.

BiosASQ：医学知识问答，数据量远大于两外两个case，包含专业的医学领域知识和医学问答对.

Failure points of RAG system

下图说明了整个RAG系统中的组件组成，以及每个组件输入输出情况，值的注意的是下图中的红框，标识了每个故障点，以及它们出现在哪些环节。

FP1 Missing Content：数据库里并不存在query对应的标准答案，但LLM容易根据检索出来的相关内容误答

FP2 Missed the Top Ranked Documents：最相关的文档排序靠后，比如在返回TOP K文档之后

FP3 Not in Context: 文档被检索和正确排序，但文档中的最相关chunk的并没有被整合到参考信息上下文中（猜测是chunk排序靠后，overlap影响等因素）

FP4 Not Extracted: 最相关chunk包含在上下文中，但噪音多，distracted information过多时，LLM可能无法从上下文中推断出正确答案

FP5 Wrong Format: LLM提取信息格式错误，比如在instruction中要求LLM提取表格或者列表，大模型没有按指令输出对应格式

FP6 Incorrect Specify： 在某些场景下，比如教学场景，可能存在期望输出结果，但模型的返回的回答可能出现太泛泛而谈，或者过于具体，和期望不符。当用户不知道如何提问，或者问题太笼统时，这种情况也可能出现。这种情况最好返回answer + answer对应的具体课程内容

FP7 回答不完整：即使上下文中包含了完整信息，模型也可能给出不完整的回答。这里论文给的例子是问“A，B，C各有什么特点？”，可能得到的答案只有A的特征，这里可以考虑COT的方式，分别去对A，B，C询问，再组合这个答案。这里还有一种情况是上下文格式的影响。

具体的一些经验教训都在下表中呈现：

对于上表，读者也还有一些疑惑，比如continuous calibration是指业务运行时的实际点赞点踩数据？ 另外组装RAG组件来提供解决方案是次优的，更需要端到端的训练优化，那RAG效果提升其实很难通过通用模型实现，还是得走定制吗？

Future research direction

chunking & embedding

RAG vs finetuning

Testing and Monitoring RAG systems

前两个方向都比较熟悉，所以读者主要关注了第三个方向RAG评估和监控

RAG评估需要数据和评价指标。验证数据采集方式目前已有了一些研究，包括通过LLM提取QA对，但是如何保证提取的数据接近真实的用户问题是一个难题。

另外大模型的响应速度以及性能也会随着LLM版本更新而变化，要如何监控和适应这些变化。论文提到了一个idea "incorporate ideas from self-adaptive systems to support monitoring and adapting RAG systems"。