基本信息

本文参考 LangChain 的 LanceMartine和 b 站 upNong_BIN 的RAG 总结和分析

• slide: LangChain LanceMartin

• slide: https://docs.google.com/presentation/d/1mJUiPBdtf58NfuSEQ7pVSEQ2Oqmek7F1i4gBwR6JDss/edit?pli=1#slide=id.g26c0cb8dc66_0_57

• up: Nong_BIN

• 视频链接：https://www.bilibili.com/video/BV1vD421T7aR/?spm_id_from=333.788&vd_source=e333e1088bd7a8147eefd76068b10bc3

Context windows are getting larger

Do we need RAG anymore?

观点提炼：

• 简单的 RAG 可能会消失，但是客制化的 RAG 还是会存在。LLM 自身的检索能力值得信任

• 大部分人不会需要 RAG，等到后续模型 API 支持足够长的上下文后，花费（cost）是唯一的问题

RAG: reasoning & retrieval on multiple chunks of information

RAG 的基础流程：

• 提出问题

• 在文件中相似度检索

• 检索（Retrieval）出来的片段形成新的 Prompt

• 交给模型生成回答(Generation)

Reference：

• https://www.youtube.com/watch?v=wd7TZ4w1mSw

Needle In A Haystack: test reasoning & retrieval in long context LLMs

检测 LLM 对长文本中的事实检索能力

• GitHub 地址：https://github.com/gkamradt/LLMTest_NeedleInAHaystack

• 实验流程：用披萨的秘方来举例

• 在一篇很长的 essays 里面插入了三句话

• Figs 是制作一个完美的披萨的其中一个秘密成分

• Prosciutto 是制作一个完美的披萨的其中一个秘密成分

• Goat cheese 是制作一个完美的披萨的其中一个秘密成分

• 提问：制作一个完美的披萨的秘密成分是什么

• 提问+修改后的 essays 组成 Prompt

• LLM 生成 Answer

• 与答案对比评估

• 找到几个秘密成分就得几分

实验结果：

1. 不管是 retrieve还是 reason 任务，随着隐含事实（needles）数量增多，GPT4 找到的数量越少

2. 随着 Context 越长，检索成功的 needle 数量越少

3. 在上下文长度固定的情况下，越接近 Prompt （or Document）末尾的 needle 越容易被检索到，越接近 Prompt开头的Needle 越难找到

Reference：

• https://github.com/gkamradt/LLMTest_NeedleInAHaystack

• https://youtu.be/UlmyyYQGhzc

• https://blog.langchain.dev/multi-needle-in-a-haystack/

Challenge may be recency bias in LLMs

LLM 会对recent token 记忆更加牢固，但也许相关度更高的信息，或者更重要的信息，会出现在较前面的位置。
启发：RAG 检索结果在并入 LLM 的时候，可以按照倒序排列，相似度最高的放最后，最低的放第一个。

Reference：

• https://arxiv.org/pdf/2310.01427.pdf

RAG will change

RAG today focused on precise retrieval of relevant doc chunks

精确检索：针对long context LLM 对远端 token 记忆问题

chunks 形式：针对 Context 越长，检索成功的 needle 数量越少的问题

Reference：

• https://github.com/langchain-ai/rag-from-scratch

Need to balance system complexity vs latency & token usage

检索过于精确可能导致：

1. 过多的工程设计

2. 高复杂度

3. 低召回率（精确度可能很高，召回率低）

4. 召回chunk 的个数需要小心确定

另一个极端，所有 doc 都丢给 LLM可能导致：

1. 高 token 消耗

2. 高延迟

3. 无法监控检索过程

4. 安全隐患

所以我们需要折中选择

Some idea..

Query analysis: Connect questions to the right document

1. Query Analysis：可以把问题，重写、拆分、提取摘要

2. Routing：导向正确的 DB

3. Query Construction: 构成 SQL，Cypher、VectorDBs

Reference：

• https://python.langchain.com/docs/use_cases/query_analysis/

Indexing:

如何保证检索到的 chunk 是足够有质量的？
如果直接把 full doc全部向量化，然后和 question 的 vector 去做相似度匹配，这样会出现两个问题：

1. 如何保证你的 chunk 是完整语义文本段落？

2. 有些 doc 内容并不精炼，一个 chunk 可能与 question 相似度很高，但并没有降到回答问题的关键所在，回答该问题的答案有可能在在一个 chunk，如何保证能够获取到能够回答问题的关键信息？

Use representations to simplify document retrieval

1. 利用 LLM对 full doc 进行总结，获取 Summary，讲 Summary 进行 Embedding 得到向量库（这里的 Summary 和部分文章（也许是一个章节）是一一对应关系）

2. 向量库相似度检索，检索到高相似度的 Summary，去找到原本的原文部分，提取出来

3. 最后就会得到相关的 Full doc

Reference：

• https://arxiv.org/pdf/2312.06648.pdf

• https://blog.langchain.dev/semi-structured-multi-modal-rag/

• https://python.langchain.com/docs/modules/data_connection/retrievers/parent_document_retriever

Use trees to consolidate info across many documents

将每个文档视为叶子节点，对这些节点进行 Embedding 和聚类

每一簇写一个 Summary，形成新一层的节点，父节点

对这一层的节点继续聚类，知道最后只剩一个节点为止

检索时候，对所有节点都做相似度检索

所以检索出来的可能会有 Summary 的文章，也可能就是原文，这样做的好处是对具体的问题或者宏观的问题都有所帮助

Reference：

• https://arxiv.org/abs/2401.18059

• https://www.youtube.com/watch?v=jbGchdTL7d0

Reasoning

Use reasoning / self-reflection around RAG

检索相关的文章，让LLM 自行打分

选择相关性高的生成结果

对结果进行判断：是否产生幻觉、是否回答了问题

类似的还有：

LLM 自己对于检索结果相关性进行打分，只保留打分高的文章，反复重复

最后只把问题和保留下的高分文章结合成 Prompt

还有：

这个 workflow 就比较简单，就是找到的内容如果不是很相关，那就重写 query 然后去 web 搜索

Reference：

• https://arxiv.org/abs/2310.11511

• https://www.youtube.com/watch?v=E2shqsYwxck

• https://github.com/langchain-ai/langgraph/blob/main/examples/rag/langgraph_self_rag.ipynb

• https://arxiv.org/abs/2401.15884

• https://github.com/langchain-ai/langgraph/blob/main/examples/rag/langgraph_crag.ipynb

Overall picture: Doc-centric, no splits or compression, reason pre/post retrieval

主要观点：

以文本为中心，不去分割、压缩内容

可以在检索前推理，也可以在检索后推理（自我矫正部分）

Reference：

• https://github.com/langchain-ai/rag-from-scratch