链载Ai

标题: 生产中的RAG,为何表现不尽人如意人? [打印本页]

作者: 链载Ai    时间: 4 天前
标题: 生产中的RAG,为何表现不尽人如意人?

RAG(Retrieval Augmented Generation,检索增强生成)是一个将大规模语言模型(LLM)与来自外部知识源的检索相结合的框架,以改进问答能力的工程框架。虽然一切都看起来很美好,在实际应用中,RAG的状态却是“一看就会,一用就废”,总是难堪大用。今天我们就来聊聊RAG,还有那些常见的坑和生产中的困境。


RAG 补充大模型能力


在进入RAG的介绍之前,需要读者首先理解一个概念,LLM的知识更新是很困难的,主要原因在于:

  1. LLM的训练数据集是固定的,一旦训练完成就很难再通过继续训练来更新其知识。

  2. LLM的参数量巨大,随时进行fine-tuning需要消耗大量的资源,并且需要相当长的时间。

  3. LLM的知识是编码在数百亿个参数中的,无法直接查询或编辑其中的知识图谱。

因此,LLM的知识具有静态、封闭和有限的特点。为了赋予LLM持续学习和获取新知识的能力,RAG应运而生。

一般RAG的主要目的是:



工作原理


RAG本质上是通过工程化手段,解决LLM知识更新困难的问题。其核心手段是利用外挂于LLM的知识数据库(通常使用向量数据库)存储未在训练数据集中出现的新数据、领域数据等。通常而言,RAG将知识问答分成三个阶段:索引、知识检索和基于内容的问答。

第一阶段是知识索引,需要事先将文本数据进行处理,通过词嵌入等向量化技术,将文本映射到低维向量空间,并将向量存储到数据库中,构建起可检索的向量索引。在这个阶段,RAG涉及数据加载器、分割器、向量数据库、提示工程等组件以及LLM本身。

第二阶段是知识检索,当输入一个问题时,RAG会对知识库进行检索,找到与问题最相关的一批文档。这需要依赖于第一阶段建立的向量索引,根据向量间的相似性进行快速检索。

第三阶段是生成答案,RAG会把输入问题及相应的检索结果文档一起提供给LLM,让LLM充分把这些外部知识融入上下文,并生成相应的答案。RAG控制生成长度,避免生成无关内容。

这样,LLM就能够充分利用外部知识库的信息,而不需要修改自身的参数。当知识库更新时,新知识也可以通过prompt实时注入到LLM中。这种设计既发挥了LLM强大的语言生成能力,又规避了其知识更新的困境,使之能更智能地回答各类问题,尤其是需要外部知识支持的问题。




RAG的常见坑





ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;">为啥生产中会失败


1. 系统太复杂

把RAG从实验室搬到生产线,就像是把一辆赛车从赛道开到市区。赛车在赛道上跑得飞快,但在市区里就得考虑交通规则、红绿灯,还有各种突发情况。RAG也是这样,它需要处理各种不可预测的负载,保证在高需求下也能稳定运行。

2. 用户互动难以预测

用户会怎么和RAG互动,这事儿可不好说。这就要求RAG得有持续的监控和适应能力,才能保持性能和可靠性。

然而,这种预测用户需求的能力对RAG来说是一个巨大的挑战。用户可能来自不同的背景,有着不同的知识水平和期望,这就要求RAG不仅要有广泛的知识储备,还要具备一定的推理和判断能力。此外,用户的行为模式也可能随时间而变化,RAG系统必须能够适应这些变化,不断学习和优化,以保持其性能和可靠性。



改进思路


由于上诉缺点的存在,直接使用LangChain等框架实现的RAG框架几乎无法直接在生产中使用,需要进行大量的工程化优化,总得来说,至少包括如下内容:


总结


RAG虽然听起来很牛,但要让它在生产环境里稳定运行,还真不是一件容易的事。目前看来它确实有多实际的应用价值,相关的技术也在不断的演进,包括RAG从1.0向2.0的演进,也是在通过探索,不断地去完善这项技术的弱点。






欢迎光临 链载Ai (https://www.lianzai.com/) Powered by Discuz! X3.5