关于RAG系统在多轮对话中的问题改写(优化)方法—使用历史记录改写问题
“ 基于大模型的RAG多轮对话功能,其检索增强的流程和实际业务的场景可能会存在一定的冲突,而这个平衡点却很难把握。”
在之前的文章中有讲过一个RAG检索优化的方法论,简单来说就是通过对问题进行改写和优化;比如说用户输入一个问题query,但由于我们无法控制用户的行为,因此用户输入的内容query可以是任何东西,包括可能存在错别字,语义错误,甚至是一些无意义内容。
面对这种情况,特别是在多轮对话过程中会导致一个很严重的问题,那就是会严重影响到数据召回的效果。
RAG检索优化——问题改写
关于RAG问题改写的方式有很多,包括但不仅限于问题优化,相似性子问题,假设性回复等等;其本质就是利用大模型的能力来根据完善和增强用户的提问。

但这里存在一个问题就是,在进行问题改写的时候最好能基于历史记录进行改写;为什么要这么做?
举个例子,用户提出一个问题query,怎么学习人工智能技术?然后经过RAG系统的一系列处理,包括文档检索,生成增强等;但用户觉得模型回答的还不够全面;因此,第二个问题是继续,也就是在第一个问题回答的基础之上继续回答,也就是典型的多轮对话场景。
那么随着第二个问题的输入会出现什么情况?
通过数据召回技术,可能会召回一些完全不相关的内容,原因就是其没有完整的上下文,RAG也不知道你这个继续是啥意思,只能根据字面意思进行数据召回,然后再进行生成增强;但我们都知道这是有问题的。
原因在于RAG中,检索和增强是两个步骤而不是一个步骤;检索的目的是使用相似度或其它检索方式从向量库或其它存储中获取参考文档;而增强是在检索回来的文档之上做处理之后,然后让模型使用这些文档做数据增强。

所以,多轮对话中一定要保证上下文的完整性,或者说尽可能的保证上下文的完整性。
虽然说用户之间输入继续可能会召回很多无关文档,但在模型生成阶段依然可以正常的进行回复,这个这个回复更多的是基于模型本身的能力,而不是基于外部知识库;当然,前提是你做了记忆功能。
所以说,这里也体现了问题改写的重要性,如果不进行问题改写,那么基于用户原生的问题,因为丢失上下文因此就会导致文档召回有问题;所以,这里进行改写的时候一定要加入历史记录,这样模型就可以使用历史记录作为上下文,来理解用户的问题;然后生成相关的问题,来进行数据召回,这样就可以大大提升文档召回的准确性,以此来达到增强生成的目的。

但这里同时也存在一个问题,那就是用户的两个问题可能是完全无关的,而这时候使用历史问题来优化用户的当前问题,也可能会导致最终召回的文档不准确;所以,这里还需要想别的方案来解决,然后使其尽可能的达到最优解。
关于我们
看到这里,相信你对本文核心主题已经有了更深入的理解。但 AI 和大模型领域更新迭代极快,单篇文章的内容很难覆盖所有细节,只能算是入门铺垫。
我平时会在【小灰熊大模型】这个公・Z・号里,系统整理 AI 大模型相关的实用资料,比如最新模型技术白皮书、实战调参手册、行业落地案例合集,还会每周更新 AI 前沿动态速递。
里面沉淀的干货具体包括:
- 大模型入门学习路线图,帮新手少走弯路
- 大模型方向必读书籍 PDF 版,方便随时查阅
- 大模型面试题库,覆盖常见考点和高频问题
- 大模型项目源码,可直接参考实操
- 超详细海量大模型 LLM 实战项目,从 0 到 1 带练
- Langchain/RAG/Agent 学习教程,聚焦热门技术方向
- LLM 大模型系统 0 到 1 入门学习教程,适合零基础
- 吴恩达最新大模型视频 + 课件,同步前沿课程内容
一直以来,我都在专注分享 AI 与大模型领域的干货 —— 从基础原理拆解到进阶实战教程,从开源工具测评到商业落地思考,每一篇内容都尽量打磨得细致实用,希望能帮大家快速跟上技术浪潮。
如果需要上述资料,关注后在GZH后台回复关键词【大模型福利】就能获取,后续也会持续更新更多针对性资源,一起在 AI 领域慢慢深耕成长~
更多推荐



所有评论(0)