一种基于滑动窗口扩展上下文的RAG优化实现方案探索
RAG(检索增强生成)是一种结合了检索(通常是知识库或数据库)和生成模型(大语言模型)的技术,目的是在生成文本的时候能够参考相关的外部知识。这样,即使生成模型在训练时没有看到某些信息,它也能在生成时通过检索到的知识来生成更加准确和丰富的回答,这篇文章实现一种基于动态上下文窗口的方案,能够处理大规模文档,保留重要的上下文信息,提升检索效率,同时保持灵活性和可配置性。
我的新书《LangChain编程从入门到实践》 已经开售!推荐正在学习AI应用开发的朋友购买阅读!
RAG(检索增强生成)是一种结合了检索(通常是知识库或数据库)和生成模型(大语言模型)的技术,目的是在生成文本的时候能够参考相关的外部知识。这样,即使生成模型在训练时没有看到某些信息,它也能在生成时通过检索到的知识来生成更加准确和丰富的回答,这篇文章实现一种基于动态上下文窗口的方案,能够处理大规模文档,保留重要的上下文信息,提升检索效率,同时保持灵活性和可配置性。
先看效果
整体方案
整体方案在于文档预处理阶段实现满足上下文窗口的原始文本分块,文档检索阶段实现文本的三次检索,下面逐一进行说明。测试文章来自 大语言模型的安全问题探究-提示词攻击
文档预处理过程
小文本块拆分
以 50 token
大小(可根据自身文档之间的组织规律动态调整粒度)对文本做首次分割
1 | # 小文档块大小 |
下面示例显示了前 7 个分块信息,结果如下:
1 | [Document(page_content='LLM 安全专题 提示词', metadata={'source': './data/一文带你了解提示攻击.pdf', 'page': 0, 'small_chunk_idx': 0}), |
添加窗口
以步长为 3,窗口大小为 6,将上述步骤的小块匹配到不同的上下文窗口。
1 | # 步长定义了窗口移动的速度,具体来说,它是上一个窗口中第一个块和下一个窗口中第一个块之间的距离 |
下面示例显示了前 7 个增加窗口信息后的分块内容,结果如下
1 | [Document(page_content='LLM 安全专题 提示词', metadata={'source': './data/一文带你了解提示攻击.pdf', 'page': 0, 'small_chunk_idx': 0, 'large_chunks_idx_lower_bound': 0, 'large_chunks_idx_upper_bound': 0}), |
中等文本块
以小文本块 3 倍(可动态配置),即150 token
大小对文本做二次分割,形成中等文本块
1 | # 中等大小的文档块大小=BASE_CHUNK_SIZE * CHUNK_SCALE |
下面示例显示了前 3 个中等分块信息,结果如下:
1 | [Document(page_content='LLM 安全专题 提示词是指在训练或与⼤型语⾔模型(Claude,ChatGPT等)进⾏交互时,提供给模型的输⼊⽂本。通过给定特定的', metadata={'source': './data/一文带你了解提示攻击.pdf', 'page': 0, 'large_chunks_idx_lower_bound': 0, 'large_chunks_idx_upper_bound': 0, 'small_chunk_idx_lower_bound': 0, 'small_chunk_idx_upper_bound': 2, 'medium_chunk_idx': 0}), |
文档检索过程
检索器声明
首先声明一个检索器,用于检索文档,这里将 BM25 检索器和嵌入式检索器组合成一个集成检索器,用于检索和评估文档相似度。下面是一些需要相关知识:
- BM25 是一种基于词袋模型的检索方法,它通过考虑单词在文档中的频率和在整个文档集合中的逆文档频率来计算文档之间的相似度
- 嵌入式检索器通常使用预训练的嵌入模型(本案例使用 OpenAI 的 text-embedding-ada-002 模型)将文档转换为密集向量,然后通过计算这些向量之间的相似度来评估文档之间的相似性
- emb_filter: 用于在嵌入式检索过程中过滤结果。例如,可以根据某些标准排除不相关的文档
- k: 这是一个整数,表示要返回的最匹配的前几个结果数量
- weights: 包含两个权重值,分别用于 BM25 检索器和嵌入式检索器在集成检索中的权重。
1 | def get_retriever( |
检索相关文档
文档检索通过采用多阶段(三次)的方式进行
- 第一阶段:小分块检索
使用小文档块(docs_index_small)和小嵌入块(embedding_chunks_small)初始化一个检索器(first_retriever),使用这个检索器检索与查询相关的文档,并将结果存储在 first 变量中,对检索到的文档 ID 进行清理和过滤,确保它们是相关的,并存储在 ids_clean 变量中。 - 第二阶段:移动窗口检索
针对每个唯一的源文档,使用小文档块检索与该源文档相关的所有文档块。使用包含这些文档块的新检索器(second_retriever),再次进行检索,以进一步缩小相关文档的范围,将检索到的文档添加到 docs 列表中。 - 第三阶段:中等分块检索
使用过滤条件从中等文档块(docs_index_medium)检索相关文档,使用包含这些文档块的新检索器(third_retriever)进行检索。从检索到的文档中选择前 third_num_k 个文档,存储在 third 变量中,清理文档的元数据,删除不需要的内容,将最终检索到的文档按文件名分类,并存储在 qa_chunks 字典中。
1 | def get_relevant_documents( |
整个过程是一个分层的检索过程,首先在小文档块中进行粗略检索,然后在特定的源文档中进行更精确的检索,最后在中等文档块中进行最终的检索。这种分层的方法有助于提高检索的效率和准确性,因为它允许系统在更小的文档集上进行更精确的检索,从而减少了在大文档集上进行复杂检索所需的计算量。
该方案的优势
处理大规模文档
由于知识库通常包含大量的文档,直接在这么大的文档集合上进行检索是非常耗时的。通过将文档分割成更小的块(chunk_small
),小块更容易被索引和检索。
保留上下文信息
通过为小块添加窗口信息(add_window
),可以确保在检索时不会丢失重要的上下文信息。这是因为有些信息可能分布在多个小块中,单独检索一个小块可能会遗漏这些信息,窗口机制确保在检索时考虑到足够的上下文,从而生成更准确的回答。
提升检索效率
通过将相邻的小块合并成中等大小的块(chunk_medium
),在保留细粒度特性的同时增加了更大范围的上下文信息。这有助于提升检索的效率和准确性,因为中等大小的块既不会像大块那样导致检索效率下降,也不会像小块那样缺乏足够的上下文信息。
灵活性和可配置性
由于整个流程是模块化的,可以根据具体应用的需求灵活地配置每个步骤的参数(如块的大小、窗口的大小和步长等),以达到最佳的性能和效果平衡。
支持多种检索策略
由于有了不同大小和包含窗口信息的文档块,可以根据查询的需要选择最适合的块来进行检索。对于需要广泛上下文的查询,可以使用包含更多上下文信息的中等大小或大块来进行检索,对于需要快速响应的查询,可以使用小块来提高检索速度。
整体方案在保证生成质量的同时,实现高效处理,在实际应用中效果明显。
不足之处
因为检索阶段经过三次检索,加之使用本地矢量数据库使用 Chroma,整体的响应速率还需进一步改善。
更多内容在公号:LLM 应用全栈开发,回复 RAG 获取源码
一种基于滑动窗口扩展上下文的RAG优化实现方案探索
https://liduos.com/rag-optimisation-implementation-scheme.html