開篇

我是孫林，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在業務中的價值探索。在此基礎上，結合京東內部的應用場景，打造更易用的平臺能力，快速將基礎能力復用于不同的業務，以提高用戶開發效率，構建快速服務終端用戶能力。

審核編輯 黃宇