我在大模型应用之RAG方向的探索、实践与思考
开篇
我是孙林,2021-京东集团-博士管培生,清华大学软件学院博士,工作期间提交专利5篇,获得北京亦麒麟优秀人才称号。目前,我担任算法中台研发部数据开发工程师,围绕检索增强生成应用领域开展研究工作。
本文将从背景、核心工作、业务实践与反馈以及未来展望等几个方向进行介绍。
背景介绍
大语言模型(LLM)在自然语言处理和自然语言理解方面取得了重大突破。大模型与应用场景的结合有助于可以在降低成本的同时提高效率。在具体场景的落地中,通用领域的大模型缺乏具体的领域知识,需要对其进行微调,这将消耗大量的计算资源。
当前,检索增强生成(RAG)作为大语言应用的一种模式,可以将大语言模型强大的理解能力和领域知识相结合,可以提高模型准确性和效率。RAG主要流程分为两步:1. 从知识库中检索出和问题相关的内容;2.将相关的知识拼接到prompt中,让LLM基于相关知识和用户问题进行回答。以下是一个RAG prompt示例:
你是京东一名资深的商家助理,专注解答用户编成时候遇到的问题。请基于 '---' 之间的相关参考内容对用户的问题进行回答。
相关参考内容:
---
1. 入驻京东万商平台店铺公司资质要求如下:
营业执照:加载“统一社会信用代码”的营业执照,(需确保未在企业经营异常名录中且所售商品在营业执照经营范围内)
企业法人身份证:公司法人身份证正反面,有效期大于60天。
2. 入驻京东万商平台,经营类目为一级类目(京喜供应链中心)鞋包服饰,需要提交品牌资质。
---
用户问题:入驻京东万商平台店铺,公司需要什么资质
注意以下要求:
1. 在回答时,尽可能参考原文
2. 若无法提供回答,请回复联系人工客服
在上述示例中,由于添加了相关的知识,大模型可以对公司资质问题给出准确的回答,相对于直接使用LLM进行回答,RAG可以更有效地借助垂域知识。总的来说,RAG的主要流程如下:
由于RAG的可解释性、不依赖模型微调、能适应多样化的应用需求等优点,市面上存在着诸多以RAG为核心的解决方案,主要包括框架和应用两类:
-
框架类:主要提供面向开发者的SDK。用户需要自行对接不同的模型资源,构建自己的应用流程。自定义程度高,但具备一定的上手难度。相关框架如langchain,LlamaIndex, promptflow等
-
应用类:开箱即用,大多是2C的类知识助手应用,一般流程为用户上传文档(知识库),然后可以基于知识库进行端到端的问答(通常,不同的应用的内置问答流程有在关键环节有一些区别,比如召回策略、是否使用Agent等)。相关应用如Dify,有道QAnything,字节Coze等。
在和业务方的合作中,我们发现业务方通常有高度定制化的需求。已有的框架和应用解决方案无法快速地用于批量解决应用需求,如:
-
小白类业务方:没有算法开发人员,只关心业务逻辑,希望平台提供存储、算力、策略,并结合应用方数据构建高可用服务;
-
多输入输出:在特定场景中是多输入多输出的,与主流的RAG链路不兼容;
-
人工快速干预:在接收到用户的特定输入下返回特定的结果,以保证模型可靠性;
-
数据链路闭环:除了数据管理,还需要有输入输出管理页面,用于事后的效果评价与bad-case分析及效果优化;
-
优质数据导出:用于微调模型,达到更高准确率;
-
开发生产隔离:模型、数据、接口服务需要区分开发环境和生产环境;
-
其他需求...
在此背景下,我们从零开始创建了RAG平台,希望通过平台的能力,提供基于大模型的全链路端到端问答能力。
-
对于无需定制化流程的用户:提供知识助手应用,通过平台内置的默认RAG逻辑进行问答;
-
对于需要定制化需求的用户:提供资源管理和流程编排能力,让用户更方便地结合业务逻辑进行二次开发。
技术攻坚突破的核心工作
RAG平台的主要框架如下图所示
服务资源打通
从平台视角看,服务资源包括数据存储服务、模型调用服务、模型部署服务等。从用户角度看,用户对服务不关心,用户只关心:“我用大模型对我的数据进行问答”,为了实现这个需求,需要在京东体系内对不同的服务资源进行打通
-
存储资源:打通京东Vearch向量库,提供相似文本检索、数据过滤等能力;
-
大语言模型/embedding模型:打通集团大模型网关,提供平台内置大语言模型,支持用户通过EA调用自部署模型;
-
服务部署:用户构建了自定义Pipeline之后,支持一键发布用于生产环境;
-
算力资源:支持用户通过平台进行模型微调并无缝替换原有模型。
大语言模型Pipeline构建
以上图基本RAG流程为例,以下代码框架表示了用户如何通过组件化方式构建自定义RAG流程:
rag = Pipeline()
rag.add_component(Input("in", input_keys=["query"]))
rag.add_component(VectorStore("vectorstore"))
rag.add_component(Prompt("prompt", preset="PlainRAG"))
rag.add_component(ChatModel("llm"))
rag.add_component(Output("output"))
rag.connect("in.query", "vectorstore")
rag.connect("in.query", "prompt.question")
rag.connect("vectorstore", "prompt.context")
rag.connect("prompt", "llm")
rag.connect("llm", "output")
rag.deploy()
通过组件化方式构建Pipeline,用户只需要定义块和块之间的连接关系。相对于基于开源框架构建Pipeline,此方式可以使得用户重点关心业务流程,大大降低了用户自定义流程中的使用门槛。当前,平台内置支持以下组件能力:
-
输入输出组件:支持自定义多输入/多输出;
-
知识库组件:支持模糊匹配与关键字匹配,用于召回相似内容;
-
大模型组件:提供大模型访问接口;
-
Prompt组件:提供默认Prompt模版与自定义Prompt能力;
-
Python函数组件:用户可通过Python函数构建任何自定义功能块;
-
分支组件:支持特定输出情况下运行特定的子流程;
-
Agent组件:提供Agent能力(如ReAct);
-
一键部署:支持本地运行Pipeline与一键部署,提供访问接口。
看板&效果优化
当前,用户的一打痛点是:构建了RAG流程之后,无法对效果进行调优。实现效果调优,主要包含以下几个角度:
-
全链路数据回流:B端用户通常会对服务历史进行收集以查看服务质量。对于一个请求,平台对运行时的Pipeline中间状态进行保存,用户可以回溯每个步骤得到了什么结果以进行进一步分析。通过完整的运行时支持中间数据跟踪,全链路的数据得以收集;
-
数据工程:"garbage in, garbage out"也适用于本场景,数据工程是一个大方向。从数据类型角度,平台支持了txt、docx、pdf、oss文件等多种数据类型,从分割策略来看,平台支持递归分割、固定长度分割等策略,从数据增强角度,平台支持qa抽取,语义理解等;
-
关键组件/能力优化:当前有多种策略用于对RAG效果进行提升,平台将优化策略沉淀成基础组件方便用户快速调用,如在检索前提供语义理解、步骤拆解等,在检索时提供对话检索、self-query等能力,检索后提供标签过滤、重排等能力;
-
路由:提供缓存路由模块,对于配置的问答进行快速干预能力;
-
评估体系&模型迭代:传统场景效果无法提升的一个主要原因是,提供了端到端的问答服务之后,不知道什么情况下回答的好,什么情况下回答的不好。通过全链路数据回流和评估体系的打通,平台可以自动触发embedding、LLM等关键模型的微调,使得效果优化可以自动化进行。
业务实践与反馈
当前,RAG平台已经服务多个项目,部分项目列举如下:
-
B商城商家AI助理应用(23年黑马二等奖项目):解决平台商家与一线人员的业务、数据、流程等问题,当前已在多个业务线投入使用,对上千家店铺提供服务。我为此项目提供后端RAG服务,收获项目合作方感谢信。相关核心链路为:
-
商品型号规范化:基于标准型号库中的型号对外包清洗的JD型号进行相似度匹配,避免因商品型号不一致导致纠缠。型号规范化效率从400sku/人日提高至750sku/人日,提效87%,获得项目合作方感谢信。
-
知识助手应用:对C端用户提供服务,提供开箱即用产品页面。本季度对知识助手存量用户进行迁移,支持日活用户约7000,日访问量2-3w,目前灰度测试中。
-
其他:暂略。
未来展望
大模型的发展能够在多个业务场景中进行落地,RAG由于其能让LLM拥有更丰富的知识,已在多种应用场合中进行验证。在此基础上,Agent由于具备一定的“观察思考”能力和工具调用能力未来将更大地丰富LLM的能力。未来我将投身于RAG业务落地效果提升及单/多Agent在业务中的价值探索。在此基础上,结合京东内部的应用场景,打造更易用的平台能力,快速将基础能力复用于不同的业务,以提高用户开发效率,构建快速服务终端用户能力。