开篇

我是孙林，2021-京东集团-博士管培生，清华大学软件学院博士，工作期间提交专利5篇，获得北京亦麒麟优秀人才称号。目前，我担任算法中台研发部数据开发工程师，围绕检索增强生成应用领域开展研究工作。

本文将从背景、核心工作、业务实践与反馈以及未来展望等几个方向进行介绍。

背景介绍

大语言模型（LLM）在自然语言处理和自然语言理解方面取得了重大突破。大模型与应用场景的结合有助于可以在降低成本的同时提高效率。在具体场景的落地中，通用领域的大模型缺乏具体的领域知识，需要对其进行微调，这将消耗大量的计算资源。

当前，检索增强生成（RAG）作为大语言应用的一种模式，可以将大语言模型强大的理解能力和领域知识相结合，可以提高模型准确性和效率。RAG主要流程分为两步：1. 从知识库中检索出和问题相关的内容；2.将相关的知识拼接到prompt中，让LLM基于相关知识和用户问题进行回答。以下是一个RAG prompt示例：

你是京东一名资深的商家助理，专注解答用户编成时候遇到的问题。请基于 '---' 之间的相关参考内容对用户的问题进行回答。

相关参考内容：
---
1. 入驻京东万商平台店铺公司资质要求如下：
营业执照：加载“统一社会信用代码”的营业执照，（需确保未在企业经营异常名录中且所售商品在营业执照经营范围内）
企业法人身份证：公司法人身份证正反面，有效期大于60天。
2. 入驻京东万商平台，经营类目为一级类目（京喜供应链中心）鞋包服饰，需要提交品牌资质。
--- 
用户问题：入驻京东万商平台店铺，公司需要什么资质
注意以下要求：
1. 在回答时，尽可能参考原文
2. 若无法提供回答，请回复联系人工客服

在上述示例中，由于添加了相关的知识，大模型可以对公司资质问题给出准确的回答，相对于直接使用LLM进行回答，RAG可以更有效地借助垂域知识。总的来说，RAG的主要流程如下：

我在大模型应用之RAG方向的探索、实践与思考

由于RAG的可解释性、不依赖模型微调、能适应多样化的应用需求等优点，市面上存在着诸多以RAG为核心的解决方案，主要包括框架和应用两类：

框架类：主要提供面向开发者的SDK。用户需要自行对接不同的模型资源，构建自己的应用流程。自定义程度高，但具备一定的上手难度。相关框架如langchain，LlamaIndex, promptflow等
应用类：开箱即用，大多是2C的类知识助手应用，一般流程为用户上传文档（知识库），然后可以基于知识库进行端到端的问答（通常，不同的应用的内置问答流程有在关键环节有一些区别，比如召回策略、是否使用Agent等）。相关应用如Dify，有道QAnything，字节Coze等。

在和业务方的合作中，我们发现业务方通常有高度定制化的需求。已有的框架和应用解决方案无法快速地用于批量解决应用需求，如：

小白类业务方：没有算法开发人员，只关心业务逻辑，希望平台提供存储、算力、策略，并结合应用方数据构建高可用服务；
多输入输出：在特定场景中是多输入多输出的，与主流的RAG链路不兼容；
人工快速干预：在接收到用户的特定输入下返回特定的结果，以保证模型可靠性；
数据链路闭环：除了数据管理，还需要有输入输出管理页面，用于事后的效果评价与bad-case分析及效果优化；
优质数据导出：用于微调模型，达到更高准确率；
开发生产隔离：模型、数据、接口服务需要区分开发环境和生产环境；
其他需求...

在此背景下，我们从零开始创建了RAG平台，希望通过平台的能力，提供基于大模型的全链路端到端问答能力。

对于无需定制化流程的用户：提供知识助手应用，通过平台内置的默认RAG逻辑进行问答；
对于需要定制化需求的用户：提供资源管理和流程编排能力，让用户更方便地结合业务逻辑进行二次开发。

我在大模型应用之RAG方向的探索、实践与思考

技术攻坚突破的核心工作

RAG平台的主要框架如下图所示
我在大模型应用之RAG方向的探索、实践与思考

服务资源打通

从平台视角看，服务资源包括数据存储服务、模型调用服务、模型部署服务等。从用户角度看，用户对服务不关心，用户只关心：“我用大模型对我的数据进行问答”，为了实现这个需求，需要在京东体系内对不同的服务资源进行打通

存储资源：打通京东Vearch向量库，提供相似文本检索、数据过滤等能力；
大语言模型/embedding模型：打通集团大模型网关，提供平台内置大语言模型，支持用户通过EA调用自部署模型；
服务部署：用户构建了自定义Pipeline之后，支持一键发布用于生产环境；
算力资源：支持用户通过平台进行模型微调并无缝替换原有模型。

大语言模型Pipeline构建

我在大模型应用之RAG方向的探索、实践与思考

以上图基本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在业务中的价值探索。在此基础上，结合京东内部的应用场景，打造更易用的平台能力，快速将基础能力复用于不同的业务，以提高用户开发效率，构建快速服务终端用户能力。