rag從0到放棄
- 黃帝內經rag問答系統
- RAG 項目版本迭代總覽
- 各版本技術細節
- 如何使用
黃帝內經rag問答系統
本項目使用爬蟲獲取了皇帝內經全文以此為數據構建檢索增強系統
本項目以一個系統的多層迭代不斷更新優化技術,由淺入深逐漸理解rag原理及優化技術
話不多說github地址:https://github.com/good-lwb/rag_learn
(所有代碼均可使用,但是需要自己下載一下模型,或者申請一個阿里云的api用在線的模型也可以)
各位看官大爺覺得有用麻煩github給個star,非常感謝(祝大家的code之路一路無bug)
在本次項目中將rag分為三步:
- indexing索引階段
- retrive檢索階段
- generation生成階段
本項目主要對這三個階段分別展開優化
RAG 項目版本迭代總覽
版本 | 核心目標 | 索引優化 | 檢索優化 | 評估/其他 | 框架/工具鏈 |
---|---|---|---|---|---|
v1.0 | 快速體驗基礎RAG流程 | - 按500token分塊 - BGE-small-zh Embedding - FAISS向量庫 | - 單路向量檢索 - 無召回優化 | - 大量日志打印輔助理解 | LangChain |
v2.0 | 基礎優化技術實踐 | - LangChain分塊(512+128重疊) - 同v1.0 Embedding/FAISS | - 雙路召回(BM25+向量) - 10+10→rerank Top5 | - 支持API/本地模型加載 | LangChain |
v3.0 | 企業級快速測試(平衡質量與效率) | - 同v2.0 | - Qwen-Rag框架內置優化 - 支持多輪對話 | - 本地vLLM加速推理 | Qwen-Rag + vLLM |
v4.0 | 解決長文本信息碎片化問題 | - 父文檔檢索器 - 子塊匹配→返回父塊 - Chroma向量庫+JSON持久化 | - 子塊Top3→父塊返回 - 支持API/本地Embedding | - 引入Logging - 檢索過程存JSON | LangChain + Chroma + vLLM |
v5.0 | 量化評估RAG效果 | - 同v4.0 | - 同v4.0 | - RAGAS評估 (忠實度、相關性等5指標) | Ragas + 自定義模型 |
v6.0 | 探索LlamaIndex生態 | - LlamaIndex基礎分塊/索引 | - 基礎檢索流程 | - 對比LangChain/Qwen-Rag | LlamaIndex |
各版本技術細節
v1.0?
1.0版本旨在快速啟動rag體驗rag流程并且在代碼中使用了大量打印注釋方便理解rag流程
索引:使用最簡單的按500token分塊,未作overlap,bge-samll-zh-v1.5作為embeding模型,使用faiss構架本地向量數據庫
檢索:使用最基礎的huggingface加載器加載模型推理,未做多路召回,未做rerank,無增強檢索技術
v2.0??
2.0版本旨在使用基本的優化技術(非企業級)
提供了api版本(main_api.py)和本地加載模型的版本(main.py)
索引:使用langchain.text_spliter對文檔進行分塊chunk=512、overlap=128,embeding=‘bge-samll-zh-v1.5’,向量數據庫=faiss
檢索:最簡單的雙路召回(關鍵詞檢索(BM25)、向量匹配),召回10+10,rerank取前5
v3.0???
3.0版本使用Qwen-Rag框架進行開發(可以作為企業的快速啟動測試,能在保證質量的前提下體驗Rag帶來的效果提升)
這里還是提供兩個版本的測試腳本,api版本(main_api.py)和本地加載模型的版本(main.py)
對于本地加載模型,在此版本中我們直接使用vllm來加載本地模型給Qwen-Rag使用(直接在終端使用bash start_vllm.sh即可加載模型);
同時在這次測試中考慮到v2版本無記憶對話不支持多輪對話,也在Qwen-rag框架下進行了多輪對話的加入
v4.0????
4.0版本中引入了父文檔檢索器,同時合并api加載模型和本地vllm加載的代碼,并添加logging打印功能
在這里介紹以下父文檔檢索器,父文檔檢索器主要解決,某些任務當chunk設置的比較小的時候檢索到的chunk和question相似度較高,但是由于chunk較小可能導致內容信息不全,就會使模型輸出不準確。而大的chunk雖然會保存較豐富的信息,但是chunk較長可能與question匹配相似度不夠高。
為了解決上述問題所以引入父文檔檢索器,先對文本塊先分割成parent文本塊(chunk較長),在分割較短的child塊(chunk較短);使用child進行相似度匹配,然后塞給模型對應的parent塊,這樣就能使得模型在保證相似度較高的前提下拿到更多的上下文信息。
langchain的父文檔檢索器主要提供了兩種方式:檢索完整文檔 和 檢索較大的文檔塊,我個人更推薦第二種,這里不做科普感興趣的朋友可以自己去看一下父文檔檢索器的原理和詳細的介紹,我這里主要是說明一下方便使用。
索引:使用langchain.retrievers提供的父文檔檢索器(ParentDocumentRetriever)構建Chroma本地向量數據庫。
在這部分在由于ParentDocumentRetriever不支持持久化保存父文檔信息我們單獨構建json將父文檔chunk保存,再通過json在rag檢索時進行加載,使得檢索精度得到極大的提升。
同時,支持兩中加載embedding模型的方式(api/本地),通過參數控制方便使用。
除此之外提供test_chroma_db.py文件支持對本地chroma向量數據庫進行測試。
檢索:父文檔檢索器(檢索top_k=3個相似度最高的子文檔,并根據重構的json返回對應的父文檔片段)
4.0版本中將llm的本地化加載合并為同一main.py中并通過指定remote/local參數進行配置使用阿里云api加載或本地部署的vllm。
日志:在4.0中引入了logging功能,并將檢索信息通過json文件進行保存,方便后續對rag檢索能進行評估。
在這部分我并沒做多路召回+重排序,因為本任務文檔級別較小,如果有需要大量文檔召回的朋友可以去結合v2.0的多路召回策略和rerank自行修改一下代碼。
v5.0?????
5.0版本使用ragas對rag系統進行評估以此驗證在4.0版本rag的提升(其他版本測試代碼這里不給出了,我已經將ragas評估函數封裝,直接傳參進去測試其他版本不難)。
衡量一個rag系統的主要參數有如下五類:
忠實度(faithfulness):衡量了生成的答案(answer)與給定上下文(context)的事實一致性。它是根據answer和檢索到的context計算得出的。并將計算結果縮放到 (0,1) 范圍且越高越好。
答案相關性(Answer relevancy):重點評估生成的答案(answer)與用戶問題(question)之間相關程度。不完整或包含冗余信息的答案將獲得較低分數。該指標是通過計算question和answer獲得的,它的取值范圍在 0 到 1 之間,其中分數越高表示相關性越好。
上下文精度(Context precision):評估所有在上下文(contexts)中呈現的與基本事實(ground-truth)相關的條目是否排名較高。理想情況下,所有相關文檔塊(chunks)必須出現在頂層。該指標使用question和計算contexts,值范圍在 0 到 1 之間,其中分數越高表示精度越高。
上下文召回率(Context recall):衡量檢索到的上下文(Context)與人類提供的真實答案(ground truth)的一致程度。它是根據ground truth和檢索到的Context計算出來的,取值范圍在 0 到 1 之間,值越高表示性能越好。
上下文相關性(Context relevancy):該指標衡量檢索到的上下文(Context)的相關性,根據用戶問題(question)和上下文(Context)計算得到,并且取值范圍在 (0, 1)之間,值越高表示相關性越好。理想情況下,檢索到的Context應只包含解答question的信息。
最終測試結果如下所示(因為ragas默認需要使用opanai的ai,我這里我沒有就硬傳的自己的模型,雖然有結果但是不知道為什么有幾個指標都是零,這個我后續在研究補充):
v6.0??????
6.0版本使用llama_index完成了黃帝內經系統的開發,但只是使用了最基礎的開發框架,沒有進行優化。
llama_index相較于langchain生態更加完善,集成的編碼、檢索優化等手段更加方便,基本都是開箱即用(內部包支持),不像langchain手寫的多。
這里沒給出基于llama_index的優化,llama_index生態文檔很完善可以看文檔,基本優化都很簡單官方集成了很多的優化而且都是換個參數改個函數就能實現。
心得
在這個項目中,我一共使用了三個框架對黃帝內經rag進行開發(langchain、llama_index、Qwen-rag)
說一下我個人感覺:
Qwen-rag的話優化做得很好,而且上手很簡單,官方抽象的很好基本就是把自己的doc扔進去就可以使用而且有不錯的效果,適合想要快速體驗rag給llm帶來的提升效果的同學,或者項目著急出個實體給客戶看一眼也可以使用。
llama_index對于數據庫構建、索引,包括生成其實都有很強的抽象程度,而且用起來真的很方便,感覺很多人都在吹langchain(包括我自己),但實際用下來rag感覺還是llama_index更好一些。
langchain怎么說呢又愛又恨,真的很多都要自己手寫,比如數據庫檢索之類的,但是你說他不行它prompt模板有很好用,而且他還有自己的一套生態比如LCEL(管道符執行,非常有意思),而且她對模型調用、agent、工作流的支持也都不是llama_index能做到的。
綜上沒有說什么好什么不好,干這行你就都得會,都得學,而且其實現在你看langchain和llama_index的文檔可以很明顯的感覺到,他倆越來越像了,就比如文檔加載器都要一摸一樣了,后面他們各自優化其實也會更相似。
如何使用
首先你需要下載bge-small-zh-v1.5;bge-reranker-base;Qwen3-4B三個模型,并保存在項目路徑下.
langchain版本>0.3即可,其余不做版本要求.
!pip install langchain
!pip install langchain-openai
!pip install langchain-community
!pip install faiss-cpu
!pip install openai
!pip install vllm # 可能會下載失敗,可以單獨create一個conda環境只下載vllm,專門用來bash start_vllm.sh使用
!pip install chromadb
!pip install ragas
!pip install -U "qwen-agent[rag,code_interpreter,gui,mcp] #v3版本使用的
!pip install llama-index # 安裝llama_index必須新create虛擬環境,和langchain不兼容
!pip install llama-index-embeddings-huggingface
!pip install llama-index-llms-huggingface