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