如何快速實(shí)現(xiàn)REST API集成以?xún)?yōu)化業(yè)務(wù)流程
Vanilla RAG 使用最簡(jiǎn)單的方式大致如下所示：1）將文本分割成塊；2）然后使用Transformer編碼器模型將這些塊編碼成向量，并將這些所有向量存儲(chǔ)到向量數(shù)據(jù)庫(kù)中；3）最后創(chuàng)建一個(gè)LLM提示，并讓模型根據(jù)搜索到的上下文來(lái)回答用戶(hù)的查詢(xún)。
在執(zhí)行交互時(shí)，使用相同的編碼器模型對(duì)用戶(hù)的查詢(xún)進(jìn)行向量化，然后執(zhí)行向量索引，找到相關(guān)性最高的top-k個(gè)結(jié)果，從向量數(shù)據(jù)庫(kù)中檢索出這些索引對(duì)應(yīng)的文本塊，并將它們作為上下文提供給LLM Prompt。
? ? ? ?Prompt示例如下所示：
def question_answering(context, query):
prompt = f"""
Give the answer to the user query delimited by triple backticks ``{query}``\
using the information given in context delimited by triple backticks ``{context}``.\
If there is no relevant information in the provided context, try to answer yourself,
but tell user that you did not have any relevant context to base your answer on.
Be concise and output the answer of size less than 80 tokens.
"""
response = get_completion(instruction, prompt, model="gpt-3.5-turbo")
answer = response.choices[0].message["content"]
return answer提高RAG pipeline最經(jīng)濟(jì)的方式就是Prompt工程，可以參考OpenAI提示工程指南（https://platform.openai.com/docs/guides/prompt-engineering/strategy-write-clear-instructions）。
? ? ? ?現(xiàn)在我們將深入了解一下高級(jí)RAG技術(shù)的概述。下圖描述了高級(jí)RAG的核心步驟和算法。為了保證方案的可讀性，省略了一些邏輯循環(huán)和復(fù)雜的多步驟代理行為。
方案中的綠色元素是需要進(jìn)一步討論的核心RAG技術(shù)，藍(lán)色元素是文本。上述方案也并沒(méi)有包括高級(jí)RAG的所有技術(shù)，例如，省略了各種上下文擴(kuò)展方法——我們將在后面深入探討。
首先，我們要?jiǎng)?chuàng)建一個(gè)表示文檔內(nèi)容的向量索引，然后在運(yùn)行時(shí)會(huì)從這些向量索引中搜索與查詢(xún)向量最小余弦距離的向量。
2.1.1 Chunking
Transformer模型輸入序列長(zhǎng)度一般是固定的，即使輸入上下文窗口較大，一個(gè)句子或幾個(gè)句子的向量也比幾頁(yè)文本上平均的向量能更好地表示其語(yǔ)義，因此，最好將原始文檔分為若干大小的塊，盡量不丟失其含義（將文本分為句子或段落，而不是將單個(gè)句子分為兩部分）。
? ? ? 分塊的大小是一個(gè)超參數(shù)，它取決于使用的嵌入模型以及在token的容量。標(biāo)準(zhǔn)的transformer編碼器模型（如基于BERT的sentence?transformer）最多可以使用512個(gè)tokens，OpenAI ada-002能夠處理更長(zhǎng)的序列，比如8191個(gè)tokens，但是，這里需要對(duì)LLM在足夠的上下文中推理和有效地執(zhí)行搜索進(jìn)行權(quán)衡。在（https://www.pinecone.io/learn/chunking-strategies/）可以找到分塊大小選擇問(wèn)題的研究。在LlamaIndex中，NodeParser類(lèi)提供了一些高級(jí)選項(xiàng)，如定義自己的文本拆分器、元數(shù)據(jù)、節(jié)點(diǎn)/塊關(guān)系等。
2.1.2 Vectorisation
接下來(lái)需要選擇一個(gè)模型來(lái)嵌入分塊，優(yōu)先選擇經(jīng)過(guò)搜索優(yōu)化的模型，比如bge-large（https://huggingface.co/BAAI/bge-large-en-v1.5）或E5 Embeddengs系列（https://huggingface.co/intfloat/multilingual-e5-large）。最新的模型可以查看MTEB排行榜（https://huggingface.co/spaces/mteb/leaderboard）。
對(duì)于分塊和向量化步驟end2end的實(shí)現(xiàn)，可以查看LlamaIndex中完整的示例（https://docs.llamaindex.ai/en/latest/module_guides/loading/ingestion_pipeline/root.html#）。
2.2.1 Vector store index
RAG管道的關(guān)鍵部分是搜索索引，它存儲(chǔ)我們?cè)谏弦徊街蝎@得的矢量化內(nèi)容。最簡(jiǎn)單的實(shí)現(xiàn)是使用一個(gè)平面索引——暴力計(jì)算查詢(xún)向量和所有塊向量之間的距離。
如果向量數(shù)量超過(guò)10000多個(gè)時(shí)，可以采用為高效檢索而優(yōu)化的向量索引，如faiss、nmslib或annoy，使用一些近似近鄰實(shí)現(xiàn)，如clustring、trees或HNSW算法。當(dāng)然還有一些托管解決方案，如OpenSearch或ElasticSearch和vector數(shù)據(jù)庫(kù)（比如Pinecone、Weaviate或Chroma）。
根據(jù)索引選擇、數(shù)據(jù)和搜索需要，還可以將元數(shù)據(jù)與向量一起存儲(chǔ)，然后使用元數(shù)據(jù)過(guò)濾器可以搜索例如：某些日期或源中的信息。
LlamaIndex支持許多向量存儲(chǔ)索引，但也支持其他更簡(jiǎn)單的索引實(shí)現(xiàn)，如列表索引、樹(shù)索引和關(guān)鍵字表索引—我們將在融合檢索部分討論后者。
2.2.2 Hierarchical indices
如果有許多文檔要從中檢索，需要能夠有效地在其中搜索，找到相關(guān)信息，并在最終的一個(gè)答案中綜合這些信息，并引用搜索來(lái)源。對(duì)于大型數(shù)據(jù)庫(kù)，一種有效的方法是創(chuàng)建兩個(gè)索引（一個(gè)由摘要組成，另一個(gè)由文檔塊組成），并分兩步進(jìn)行搜索，首先通過(guò)摘要過(guò)濾出相關(guān)文檔，然后在該相關(guān)組中進(jìn)行搜索。
2.2.3 Hypothetical Questions and HyDE
? ? ? ?另一種方法是要求LLM為每個(gè)分塊生成一個(gè)問(wèn)題并將這些問(wèn)題嵌入向量中，在運(yùn)行時(shí)對(duì)問(wèn)題向量的索引執(zhí)行查詢(xún)搜索（將分塊向量替換為索引中的問(wèn)題向量），然后在檢索后路由到原始文本區(qū)塊并將其作為上下文發(fā)送給LLM以獲得答案。這種方法提高了搜索質(zhì)量，因?yàn)椴樵?xún)和假設(shè)問(wèn)題之間的語(yǔ)義相似度比實(shí)際塊更高。
? ? ? 還有一種稱(chēng)為HyDE的反向邏輯方法—您要求LLM生成給定查詢(xún)的假設(shè)響應(yīng)，然后使用其向量和查詢(xún)向量來(lái)提高搜索質(zhì)量。
2.2.4 Context enrichment
? ? ? 這里的概念是檢索更小的塊以獲得更好的搜索質(zhì)量，但要將周?chē)纳舷挛南嗉右怨?a href="http://cnzze.cn/blog/llm-content-creation-capability-evaluation/">LLM推理。
有兩種選擇—通過(guò)圍繞較小檢索塊的語(yǔ)句擴(kuò)展上下文，或者遞歸地將文檔拆分為若干較大的父塊（包含較小的子塊）。
a） Sentence Window Retrieval
在該方案中，文檔中的每個(gè)句子都被單獨(dú)嵌入，這為上下文余弦距離搜索提供了很高的查詢(xún)精度。
? ? ? 為了在獲取最相關(guān)的單個(gè)句子后更好地對(duì)所發(fā)現(xiàn)的上下文進(jìn)行推理，我們?cè)跈z索到的句子前后對(duì)上下文窗口進(jìn)行k個(gè)句子的擴(kuò)展，然后將擴(kuò)展后的上下文發(fā)送給LLM。
綠色部分是在索引中搜索時(shí)發(fā)現(xiàn)的嵌入句子，整個(gè)黑色+綠色段落喂給LLM，以擴(kuò)大其上下文，同時(shí)對(duì)提供的查詢(xún)進(jìn)行推理
b） Auto-merging Retriever (aka Parent Document Retriever)
? ? ? ?這里的想法非常類(lèi)似于句子窗口檢索器——搜索更細(xì)粒度的信息片段，然后在將所述上下文提供給LLM進(jìn)行推理之前擴(kuò)展上下文窗口。文檔被分割成更小的子塊，引用更大的父塊。
首先在檢索過(guò)程中獲取較小的塊，然后如果前k個(gè)檢索到的塊中有n個(gè)以上的塊鏈接到同一父節(jié)點(diǎn)（較大的塊），我們將替換由該父節(jié)點(diǎn)提供給LLM的上下文-工作方式類(lèi)似于將幾個(gè)檢索到的塊自動(dòng)合并到較大的父塊中，從而得到方法名稱(chēng)。只需注意-搜索僅在子節(jié)點(diǎn)索引中執(zhí)行。關(guān)于遞歸檢索器+節(jié)點(diǎn)引用，可以參考LlamaIndex教程（https://docs.llamaindex.ai/en/stable/examples/retrievers/recursive_retriever_nodes.html）。
2.2.5 Fusion retrieval or hybrid search
一個(gè)相對(duì)傳統(tǒng)的想法是，可以從兩個(gè)世界中取其精華-基于關(guān)鍵字的老式搜索-稀疏檢索算法，如tf-idf或搜索行業(yè)標(biāo)準(zhǔn)BM25-和現(xiàn)代語(yǔ)義或向量搜索，并將其組合到一個(gè)檢索結(jié)果。
? ? ? 這里唯一的技巧是將檢索到的結(jié)果與不同的相似性分?jǐn)?shù)正確地結(jié)合起來(lái)——這個(gè)問(wèn)題通常通過(guò)使用?Reciprocal Rank Fusion算法來(lái)解決，將檢索到的結(jié)果重新排序以獲得最終輸出。
在LangChain中，這是在Ensemble Retriever類(lèi)（https://python.langchain.com/docs/modules/data_connection/retrievers/ensemble）中實(shí)現(xiàn)的，將用戶(hù)定義的檢索器列表（例如faiss向量索引和基于BM25的檢索器）結(jié)合起來(lái)，并使用RRF重新排序。
在LlamaIndex中，也是以非常類(lèi)似的方式完成的，請(qǐng)參考：https://docs.llamaindex.ai/en/stable/examples/retrievers/reciprocal_rerank_fusion.html。
混合或融合搜索通常通過(guò)兩種互補(bǔ)的搜索算法相結(jié)合，同時(shí)考慮查詢(xún)與存儲(chǔ)文檔之間的語(yǔ)義相似度和關(guān)鍵字匹配，從而提供更好的檢索結(jié)果。
? ? ? ?根據(jù)上面章節(jié)，我們得到了檢索結(jié)果，但結(jié)果可能是錯(cuò)誤的或者是冗余的。本小節(jié)我們繼續(xù)介紹一些后處理操作，比如過(guò)濾，重新排序或一些轉(zhuǎn)換。在LlamaIndex中，有各種可用的后處理器（https://docs.llamaindex.ai/en/stable/module_guides/querying/node_postprocessors/root.html），根據(jù)相似度得分、關(guān)鍵字、元數(shù)據(jù)過(guò)濾出結(jié)果，或者使用其他模型對(duì)其重新排序，比如LLM，sentence-transformer cross-encoder，重排序端點(diǎn)或者基于元數(shù)據(jù)，比如日期。常見(jiàn)的方法基本上都可以。
這是將檢索到的上下文提供給LLM以獲得結(jié)果答案之前的最后一步。
? ? ? ?現(xiàn)在是時(shí)候使用更復(fù)雜的RAG技術(shù)了，比如查詢(xún)轉(zhuǎn)換和路由，這兩種技術(shù)都涉及LLM，因此代表了代理行為——在RAG管道中涉及LLM推理的一些復(fù)雜邏輯。
? ? ? 查詢(xún)轉(zhuǎn)換是一系列使用LLM作為推理引擎修改用戶(hù)輸入以提高檢索質(zhì)量的技術(shù)。
如果查詢(xún)很復(fù)雜，LLM可以將其分解為多個(gè)子查詢(xún)。例如，如果您詢(xún)問(wèn)：
-“What framework has more stars on Github, Langchain or LlamaIndex?”，
而且，我們不太可能在語(yǔ)料庫(kù)中的某些文本中找到直接比較，因此將此問(wèn)題分解為兩個(gè)子查詢(xún)是有意義的，前提是信息檢索更簡(jiǎn)單、更具體：
-“How many stars does Langchain have on Github?”
-“How many stars does Llamaindex have on Github?”
? ? ? ?它們將并行執(zhí)行，然后檢索到的上下文將組合在一個(gè)單獨(dú)的提示中，供LLM合成初始查詢(xún)的最終答案。這兩個(gè)庫(kù)都實(shí)現(xiàn)了這個(gè)功能——在Langchain中?使用Multi Query Retriever（https://python.langchain.com/docs/modules/data_connection/retrievers/MultiQueryRetriever?ref=blog.langchain.dev），在Llamaindex中使用Sub Question Query Engine（https://docs.llamaindex.ai/en/stable/examples/query_engine/sub_question_query_engine.html）。
有時(shí)間，我們不僅僅要求RAG完成一個(gè)任務(wù)，也需要進(jìn)行多輪對(duì)話聊天，它與經(jīng)典的聊天機(jī)器人一樣可以考慮對(duì)話上下文。這需要跟蹤會(huì)話、回指或記錄歷史聊天記錄。該方法采用查詢(xún)壓縮技術(shù)，結(jié)合聊天環(huán)境和用戶(hù)查詢(xún)，解決了該問(wèn)題。
? ? ? 通常，有幾種方法可以實(shí)現(xiàn)上述上下文壓縮-一種流行且相對(duì)簡(jiǎn)單的ContextChatEngine（https://docs.llamaindex.ai/en/stable/examples/chat_engine/chat_engine_context.html），首先檢索與用戶(hù)查詢(xún)相關(guān)的上下文，然后將其與緩存中的聊天歷史一起輸入給LLM，以便LLM在生成下一個(gè)答案的同時(shí)考慮歷史聊天記錄。
? ? ? 更復(fù)雜一點(diǎn)的例子是CondensePlusContextMode（https://docs.llamaindex.ai/en/stable/examples/chat_engine/chat_engine_condense_plus_context.html）——在每個(gè)交互中，聊天歷史和最后一條消息被壓縮成一個(gè)新的查詢(xún)，然后將這個(gè)查詢(xún)建立索引再進(jìn)行檢索，檢索到的上下文與原始用戶(hù)消息一起傳遞給LLM以生成答案。
? ? ? ?需要注意的是，LlamaIndex中還支持基于OpenAI代理的聊天引擎（https://docs.llamaindex.ai/en/stable/examples/chat_engine/chat_engine_openai.html），提供了更靈活的聊天模式，Langchain也支持OpenAI函數(shù)API（https://python.langchain.com/docs/modules/agents/agent_types/openai_multi_functions_agent）。
還有其他聊天引擎類(lèi)型，比如ReAct Agent（https://docs.llamaindex.ai/en/stable/examples/chat_engine/chat_engine_react.html），我們將在第7節(jié)中介紹Agent。
? ? ? ?查詢(xún)路由是LLM支持的決策步驟，決定在給定用戶(hù)查詢(xún)的情況下接下來(lái)要做什么——通常是匯總、對(duì)某些數(shù)據(jù)索引執(zhí)行搜索或嘗試多個(gè)不同的路由，然后在單個(gè)答案中綜合它們的輸出。
查詢(xún)路由器可以選擇一個(gè)索引或者數(shù)據(jù)存儲(chǔ)來(lái)發(fā)送用戶(hù)的查詢(xún)。或者有多個(gè)數(shù)據(jù)源，例如，經(jīng)典向量存儲(chǔ)和圖形數(shù)據(jù)庫(kù)或關(guān)系數(shù)據(jù)庫(kù)，或者您有一個(gè)索引層次結(jié)構(gòu)—對(duì)于多文檔存儲(chǔ)來(lái)說(shuō)，一個(gè)非常經(jīng)典的例子是摘要索引和另一個(gè)文檔塊向量索引。
? ? ? ?定義查詢(xún)路由器包括設(shè)置它可以做出的選擇。通過(guò)LLM調(diào)用執(zhí)行路由選項(xiàng)的選擇，以預(yù)定義格式返回其結(jié)果，將查詢(xún)路由到給定的索引，或者，如果我們采用不相關(guān)行為，則路由到子鏈或甚至其他代理，如下面的多文檔代理方案所示。
LlamaIndex（https://docs.llamaindex.ai/en/stable/module_guides/querying/router/root.html）和LangChain（https://python.langchain.com/docs/expression_language/how_to/routing?ref=blog.langchain.dev）都支持查詢(xún)路由器。
? ? ? 代理（由Langchain和LlamaIndex支持）幾乎自第一個(gè)LLM API發(fā)布以來(lái)就一直存在——其思想是提供一個(gè)LLM，能夠推理，具有一組工具和要完成的任務(wù)。這些工具可能包括一些確定性函數(shù)，比如任何代碼函數(shù)、外部API甚至其他代理——這種LLM鏈接思想就是LangChain得名的地方。
? ? ? ?代理本身是一個(gè)龐大的東西，在RAG概述中不可能對(duì)這個(gè)主題進(jìn)行足夠深入的研究，因此將繼續(xù)介紹基于代理的多文檔檢索案例，在OpenAI助手站稍作停留，因?yàn)檫@是一個(gè)相對(duì)較新的東西，在最近的OpenAI 的 dev conference as GPTs中介紹（https://openai.com/blog/new-models-and-developer-products-announced-at-devday）的。
? ? ? ?OpenAI助手（https://platform.openai.com/docs/assistants/overview）基本上已經(jīng)實(shí)現(xiàn)了我們以前在開(kāi)源中使用的LLM所需的許多工具，比如聊天歷史、知識(shí)存儲(chǔ)、文檔上傳接口，以及最重要的函數(shù)調(diào)用API。后者提供了將自然語(yǔ)言轉(zhuǎn)換為對(duì)外部工具或數(shù)據(jù)庫(kù)查詢(xún)的API調(diào)用的功能。
? ? ? 在LlamaIndex中，有一個(gè)OpenAIgent類(lèi)（https://docs.llamaindex.ai/en/stable/examples/agent/openai_agent.html）將這種高級(jí)邏輯與ChatEngine和QueryEngine類(lèi)相結(jié)合，提供基于知識(shí)和上下文感知的聊天，以及在一次會(huì)話中調(diào)用多個(gè)OpenAI函數(shù)的能力，這真正帶來(lái)了智能代理行為。
讓我們看一看多文檔代理方案（https://docs.llamaindex.ai/en/stable/examples/agent/multi_document_agents.html）——一個(gè)非常復(fù)雜的設(shè)置，包括在每個(gè)文檔上初始化一個(gè)代理（OpenAIAgent（https://docs.llamaindex.ai/en/stable/examples/agent/openai_agent.html）），能夠進(jìn)行文檔摘要和經(jīng)典的QA機(jī)制，以及一個(gè)頂級(jí)代理，負(fù)責(zé)將查詢(xún)路由到文檔代理并進(jìn)行最終答案合成。
每個(gè)文檔代理都有兩個(gè)工具—向量存儲(chǔ)索引和摘要索引，并根據(jù)路由查詢(xún)決定使用哪個(gè)工具。對(duì)于頂級(jí)代理，所有文檔代理都是工具。
? ? ? ?該方案展示了一種先進(jìn)的RAG體系結(jié)構(gòu)，每個(gè)代理都會(huì)做出大量的路由決策。這種方法的好處是能夠比較不同的解決方案或?qū)嶓w，在不同的文檔及其摘要中進(jìn)行描述，以及經(jīng)典的單文檔摘要和QA機(jī)制—這基本上涵蓋了與文檔用例集合最頻繁的聊天。
??這樣一個(gè)復(fù)雜方案的缺點(diǎn)可以從圖中猜測(cè)出來(lái)——由于在代理中使用LLM進(jìn)行多次來(lái)回迭代，所以有點(diǎn)慢。以防萬(wàn)一，LLM調(diào)用始終是RAG管道中最長(zhǎng)的操作-設(shè)計(jì)優(yōu)化了搜索速度。因此，對(duì)于大型多文檔存儲(chǔ)，建議考慮對(duì)該方案進(jìn)行一些簡(jiǎn)化，使其具有可擴(kuò)展性。
2.8 Response synthesiser
這是任何RAG管道的最后一步——根據(jù)檢索的所有上下文和初始用戶(hù)查詢(xún)生成答案。
? ? ? ?最簡(jiǎn)單的方法是將所有獲取的上下文（高于某個(gè)相關(guān)閾值）與查詢(xún)一起串聯(lián)并同時(shí)提供給LLM。
? ? ? ?但是，還有其他更復(fù)雜的選項(xiàng)涉及多個(gè)LLM調(diào)用，以?xún)?yōu)化檢索到的上下文并生成更好的答案。
響應(yīng)綜合的主要方法有：
1、通過(guò)逐塊向LLM發(fā)送檢索到的上下文，迭代地細(xì)化答案；
2、總結(jié)檢索到的上下文以適應(yīng)提示；
3、根據(jù)不同的上下文塊生成多個(gè)答案，并將其串聯(lián)或匯總。
有關(guān)更多詳細(xì)信息，請(qǐng)查看響應(yīng)合成器模塊文檔（https://docs.llamaindex.ai/en/stable/module_guides/querying/response_synthesizers/root.html）。
? ? ? ?前面兩章介紹了直接使用現(xiàn)有模型來(lái)完成RAG，那么有時(shí)候底座模型的性能未必會(huì)滿足需求，這時(shí)可以考慮對(duì)其進(jìn)行微調(diào)。RAG管道中主要涉及到兩個(gè)模型，分別是負(fù)責(zé)嵌入質(zhì)量和上下文檢索質(zhì)量的Transformer編碼器，另一個(gè)是負(fù)責(zé)最好地使用所提供的上下文來(lái)回答用戶(hù)查詢(xún)的LLM——幸運(yùn)的是，后者是一個(gè)很好的少量學(xué)習(xí)者。
? ? ? 現(xiàn)在的一大優(yōu)勢(shì)是可以使用GPT-4等高端LLM生成高質(zhì)量的合成數(shù)據(jù)集。
需要注意的是：使用專(zhuān)業(yè)研究團(tuán)隊(duì)訓(xùn)練開(kāi)源模型收集、清理和驗(yàn)證的大型數(shù)據(jù)集，并使用小型合成數(shù)據(jù)集進(jìn)行快速微調(diào)，可能會(huì)降低模型的通用能力。
在LlamaIndex notebook（https://docs.llamaindex.ai/en/stable/examples/finetuning/embeddings/finetune_embedding.html）中測(cè)試了bge-large-en-v1.5（撰寫(xiě)本文時(shí)MTEB排行榜的前4名）的微調(diào)所帶來(lái)的性能提升，結(jié)果顯示檢索質(zhì)量提高了2%。
另一個(gè)很好的選擇是，如果您不完全信任基本編碼器，那么可以使用交叉編碼器對(duì)檢索到的結(jié)果進(jìn)行重新排序。它的工作方式如下：將查詢(xún)和前k個(gè)檢索到的文本塊傳遞給交叉編碼器，并用SEP token分隔，然后對(duì)其進(jìn)行微調(diào)，將相關(guān)塊輸出1，將不相關(guān)塊輸出0。這里有個(gè)例子（https://docs.llamaindex.ai/en/latest/examples/finetuning/cross_encoder_finetuning/cross_encoder_finetuning.html#），結(jié)果顯示，對(duì)交叉編碼器微調(diào)，評(píng)分提高了4%。
? ? ? ?最近OpenAI開(kāi)始提供LLM FineTunning API（https://platform.openai.com/docs/guides/fine-tuning），LlamaIndex有一個(gè)關(guān)于在RAG設(shè)置中微調(diào)GPT-3.5-turbo的教程（https://docs.llamaindex.ai/en/stable/examples/finetuning/openai_fine_tuning.html），可以“蒸餾”一些GPT-4知識(shí)。這里的想法是獲取一個(gè)文檔，使用GPT-3.5-turbo生成許多問(wèn)題，然后使用GPT-4根據(jù)文檔內(nèi)容生成這些問(wèn)題的答案（構(gòu)建GPT4支持的RAG管道），然后在該問(wèn)答對(duì)數(shù)據(jù)集上微調(diào)GPT-3.5-turbo。用于RAG管道評(píng)估的ragas框架（https://docs.ragas.io/en/latest/index.html）顯示忠實(shí)性度量增加了5%，這意味著經(jīng)過(guò)微調(diào)的GPT 3.5-turbo模型比原始模型更好地利用了提供的上下文來(lái)生成其答案。
? ? ? 最近Meta AI的一篇論文《RA-DIT: Retrieval Augmented Dual Instruction Tuning》提出了一種在查詢(xún)、上下文和答案的三元組上同時(shí)微調(diào)LLM和檢索器的方法，原論文采用一個(gè)雙編碼器結(jié)構(gòu)，實(shí)現(xiàn)細(xì)節(jié)可以參考：https://docs.llamaindex.ai/en/stable/examples/finetuning/knowledge/finetune_retrieval_aug.html#fine-tuning-with-retrieval-augmentation。該技術(shù)用于通過(guò)微調(diào)API和Llama2開(kāi)源模型來(lái)微調(diào)OpenAI LLMs，從而使知識(shí)密集型任務(wù)度量增加了約5%（相比于使用RAG的Llama2 65B），并使常識(shí)推理任務(wù)增加了兩個(gè)百分點(diǎn)。
有幾個(gè)RAG系統(tǒng)性能評(píng)估框架，他們思路類(lèi)似，都采用以下指標(biāo)來(lái)進(jìn)行評(píng)估：比如總體答案相關(guān)性、答案有根據(jù)性、可信度和檢索到的上下文相關(guān)性。
如前一節(jié)所述，Ragas使用信度和答案相關(guān)性作為生成的答案質(zhì)量度量，并使用經(jīng)典上下文精度P和召回率R作為RAG方案的檢索部分。
在Andrew NG、LlamaIndex和評(píng)估框架Truelens（https://github.com/truera/trulens/tree/main）最近發(fā)布的一個(gè)大型短期課程“構(gòu)建和評(píng)估高級(jí)RAG（https://learn.deeplearning.ai/building-evaluating-advanced-rag/）”中，他們提出了RAG三元組——檢索到的與查詢(xún)相關(guān)的上下文、有根據(jù)性（所提供的上下文支持LLM答案的多少）和與查詢(xún)相關(guān)的答案。
? ? ? ?關(guān)鍵且最可控的度量是檢索到的上下文相關(guān)性——基本上，上面描述的高級(jí)RAG管道的第1–7部分以及編碼器和Ranker微調(diào)部分旨在改進(jìn)此度量，而第8部分和LLM微調(diào)則側(cè)重于答案相關(guān)性和基礎(chǔ)性。
? ? ? ?這里（https://github.com/run-llama/finetune-embedding/blob/main/evaluate.ipynb）可以找到一個(gè)非常簡(jiǎn)單的檢索器評(píng)估Pipeline的例子，并將其應(yīng)用于編碼器微調(diào)部分。OpenAI cookbook（https://github.com/openai/openai-cookbook/blob/main/examples/evaluation/Evaluate_RAG_with_LlamaIndex.ipynb）中展示了一種更高級(jí)的方法，該方法不僅考慮了命中率，而且還考慮了平均倒數(shù)秩（一種常見(jiàn)的搜索引擎度量）以及生成的答案度量（如忠實(shí)度和相關(guān)性）。
LangChain有一個(gè)非常高級(jí)的評(píng)估框架LangSmith（https://docs.smith.langchain.com/），其中可以實(shí)現(xiàn)定制的評(píng)估器，并監(jiān)視RAG管道中的運(yùn)行狀況，以使系統(tǒng)更加透明。
在LlamaIndex中，有一個(gè)rag_evaluator llama pack包（https://github.com/run-llama/llama-hub/tree/dac193254456df699b4c73dd98cdbab3d1dc89b0/llama_hub/llama_packs/rag_evaluator），它提供了一個(gè)快速工具，可以使用公共數(shù)據(jù)集評(píng)估管道。
試圖勾勒出RAG的核心算法方法，并舉例說(shuō)明其中的一些方法，希望這可能會(huì)激發(fā)一些新的想法，嘗試在RAG管道中，或?qū)⒁恍┫到y(tǒng)引入到今年發(fā)明的各種各樣的技術(shù)中——對(duì)我來(lái)說(shuō)，2023年是ML迄今為止最激動(dòng)人心的一年。
? ? ?還有很多其他的東西需要考慮，比如基于web搜索的RAG（由LlamaIndex、webLangChain等開(kāi)發(fā)的RAG），深入研究代理架構(gòu)（以及最近在游戲中的OpenAI stake），以及一些關(guān)于LLMs長(zhǎng)期記憶的想法。
? ? ? ?對(duì)于RAG系統(tǒng)來(lái)說(shuō)，除了答案的相關(guān)性和忠實(shí)性之外，主要的生產(chǎn)挑戰(zhàn)是速度，特別是當(dāng)使用更靈活的基于代理的方案時(shí)。ChatGPT和大多數(shù)其他助手使用的這種流式功能不是一種隨機(jī)的cyberpunk風(fēng)格，而只是一種縮短感知答案生成時(shí)間的方法。這就是為什么我看到了一個(gè)非常光明的未來(lái)，較小的LLM和最近發(fā)布的Mixtral和Phi-2是引導(dǎo)我們?cè)谶@個(gè)方向前進(jìn)。
參考文獻(xiàn)：
[1]?https://pub.towardsai.net/advanced-rag-techniques-an-illustrated-overview-04d193d8fec6?source=email-c63e4493b83d-1703617670645-digest.reader-98111c9905da-04d193d8fec6—-0-98——————585a2b75_5c50_49b0_a73f_79ae0baec16e-1
本文章轉(zhuǎn)載微信公眾號(hào)@ArronAI
對(duì)比大模型API的內(nèi)容創(chuàng)意新穎性、情感共鳴力、商業(yè)轉(zhuǎn)化潛力
一鍵對(duì)比試用API 限時(shí)免費(fèi)
安全的關(guān)鍵.png)
