如何快速實現(xiàn)REST API集成以優(yōu)化業(yè)務(wù)流程
本文對文本RAG涉及到的主要12種關(guān)鍵“超參數(shù)”進(jìn)行簡單總結(jié)，主要包括攝取階段（數(shù)據(jù)清洗、數(shù)據(jù)分塊、embedding模型選擇、元數(shù)據(jù)過濾、多重索引和索引算法）和推理階段【檢索和生成】（查詢轉(zhuǎn)換、檢索參數(shù)、高級檢索策略、重排序、大模型和Prompt工程）。下面將分別進(jìn)行介紹：
? ? ? ?攝取階段是構(gòu)建RAG管道的準(zhǔn)備步驟，類似于ML管道中的數(shù)據(jù)清理和預(yù)處理步驟。通常，攝入階段包括以下步驟：
? ? ? ?與任何數(shù)據(jù)科學(xué)管道一樣，數(shù)據(jù)的質(zhì)量嚴(yán)重影響RAG管道的結(jié)果。在繼續(xù)執(zhí)行以下任何步驟之前，請確保您的數(shù)據(jù)符合以下標(biāo)準(zhǔn)：
1）數(shù)據(jù)干凈：可以應(yīng)用一些自然語言處理中常用的基本數(shù)據(jù)清理技術(shù)，例如確保所有特殊字符都正確編碼；
2）數(shù)據(jù)準(zhǔn)確：確保信息一致且事實準(zhǔn)確，以避免信息沖突誤導(dǎo)LLM
對文檔進(jìn)行分塊是RAG管道中引入外部知識源的一個重要準(zhǔn)備步驟，通常是將長文檔分解成更小的部分（但它也可以將較小的片段組合成連貫的段落）。
在LangChain中，支持不同的text splitters[1]，比如字符、令牌等。這取決于您擁有的數(shù)據(jù)類型，例如，如果您的輸入數(shù)據(jù)是代碼，而不是Markdown文件，則需要使用不同的分塊技術(shù)。
塊的理想長度（chunk_size）取決于具體用例：如果你的用例是問答，你可能需要更短的塊；但如果你的案例是摘要，你可能會需要更長的塊。此外，如果一個區(qū)塊太短，它可能沒有包含足夠的上下文。另一方面，如果一個塊太長，它可能包含太多不相關(guān)的信息。
此外，還需要考慮塊（重疊）之間的“滾動窗口”，這樣可以保證塊之間的語義連貫性。
嵌入模型是檢索的核心，嵌入的質(zhì)量嚴(yán)重影響檢索結(jié)果。通常，生成嵌入的維度越高，嵌入的精度就越高。
可以在 Massive Text Embedding Benchmark (MTEB)排行榜[2]查看可用的文本嵌入模型，該排行榜涵蓋164個文本嵌入模型（在撰寫本文時）。
雖然可以開箱即用地使用通用嵌入模型，但在某些情況下，可以根據(jù)用戶的特定用例微調(diào)嵌入模型，這樣可以避免領(lǐng)域外問題。根據(jù)LlamaIndex進(jìn)行的實驗，微調(diào)嵌入模型可以使檢索評估指標(biāo)的性能提高5%-10%。
請注意，無法對所有嵌入模型進(jìn)行微調(diào)（例如，OpenAI的text-ebmedding-ada-002目前無法進(jìn)行微調(diào)）。
將矢量嵌入存儲在矢量數(shù)據(jù)庫中時，某些矢量數(shù)據(jù)庫允許將它們與元數(shù)據(jù)（或未矢量化的數(shù)據(jù)）一起存儲。用元數(shù)據(jù)注釋矢量嵌入有助于對搜索結(jié)果進(jìn)行額外的后處理，如元數(shù)據(jù)過濾（添加元數(shù)據(jù)，如日期、章節(jié)或分章引用）。
如果元數(shù)據(jù)不足以提供額外的信息來從邏輯上分離不同類型的上下文，可能需要嘗試使用多個索引，例如，可以對不同類型的文檔使用不同的索引。
為了實現(xiàn)大規(guī)模相似性搜索，矢量數(shù)據(jù)庫和矢量索引庫使用近似最近鄰（ANN）搜索，而不是k最近鄰（kNN）搜索。顧名思義，ANN算法近似于最近的鄰居，因此可能不如kNN算法精確。
這里有不同的ANN算法可以參考，如Facebook Faiss[3]（聚類）、Spotify Annoy[4]（樹）、Google ScaNN[5]（矢量壓縮）和HNSWLIB[6]（接近圖）。此外，這些ANN算法中的許多都有一些參數(shù)可以調(diào)整，例如HNSW[1]的ef、efConstruction和maxConnections。
此外，還可以為這些索引算法啟用矢量壓縮。與人工神經(jīng)網(wǎng)絡(luò)算法類似，矢量壓縮會損失一些精度。然而，根據(jù)矢量壓縮算法的選擇及其調(diào)整，也可以對此進(jìn)行優(yōu)化。
? ? ? 然而，這些參數(shù)已經(jīng)由向量數(shù)據(jù)庫和向量索引庫的研究團(tuán)隊在基準(zhǔn)測試實驗期間進(jìn)行了調(diào)整，而不是由RAG系統(tǒng)的開發(fā)人員進(jìn)行調(diào)整。然而，如果想自己嘗試使用這些參數(shù)來壓榨一點性能，建議可以參考這篇文章[7]。
? ? ? ?RAG管道的主要組成部分是檢索和生成組成部分。本節(jié)主要討論改進(jìn)檢索的策略（查詢轉(zhuǎn)換、檢索參數(shù)、高級檢索策略和重新排序模型），因為這是兩者中更具影響力的組成部分。也會談到了一些改進(jìn)生成的策略（LLM和Prompt工程）。
? ? ? ?由于在RAG管道中檢索附加上下文的搜索查詢也會嵌入到向量空間中，因此其措辭也會影響搜索結(jié)果。因此，如果您的搜索查詢沒有得到令人滿意的搜索結(jié)果，您可以嘗試各種查詢轉(zhuǎn)換技術(shù)[8]，例如：
檢索是RAG管道的重要組成部分。首先要考慮的是語義搜索是否足以滿足您的用例，或者您是否想嘗試混合搜索[9]。
在后一種情況下，需要在混合搜索中對稀疏和密集檢索方法的聚合進(jìn)行加權(quán)實驗。因此，有必要調(diào)整參數(shù)alpha，該參數(shù)控制語義（alpha＝1）和基于關(guān)鍵字的搜索（alpha＝0）之間的權(quán)重。
此外，要檢索的搜索結(jié)果的數(shù)量也將發(fā)揮重要作用。檢索到的上下文的數(shù)量將影響所用上下文窗口的長度。此外，如果您使用的是重新排序模型，則需要考慮向該模型輸入多少上下文。
請注意，雖然用于語義搜索的所用相似性度量是一個可以更改的參數(shù)，不需要進(jìn)行實驗，而應(yīng)該根據(jù)所使用的嵌入模型進(jìn)行設(shè)置（例如，text-embedding-ada-002支持余弦相似性或multi-qa-MiniLM-l6-cos-v1支持余弦相似、點積和歐幾里得距離）。
本節(jié)的基本思想是，用于檢索的塊不一定與用于生成的塊相同。理想情況下，應(yīng)該嵌入較小的塊便于檢索，而應(yīng)該檢索較大的上下文。
雖然語義搜索根據(jù)上下文與搜索查詢的語義相似性來檢索上下文，但“最相似”并不一定意味著“最相關(guān)”。重新排序模型，如Cohere[10]的重新排序模型可以通過計算每個檢索到的上下文的查詢相關(guān)性得分來幫助消除不相關(guān)的搜索結(jié)果。
|“most similar” doesn’t necessarily mean “most relevant”
? ? ? ?如果使用的是重新排序器模型，則可能需要重新調(diào)整重新排序器輸入的搜索結(jié)果數(shù)量，以及希望將多少重新排序的結(jié)果輸入LLM。
與嵌入模型一樣，同樣可以對重新排序器進(jìn)行微調(diào)。
? ? ? ?LLM是生成響應(yīng)的核心組件，根據(jù)用戶的需求，可以有多種LLM可供選擇，可以考慮例如開源模型或?qū)Ｓ心Ｐ汀⑼评沓杀尽⑸舷挛拈L度等因素來選擇大模型。
? ? ? ?如何表達(dá)或設(shè)計你的提示將對LLM的完成產(chǎn)生重大影響。此外，在提示中使用一些few-shot示例可以提高生成的質(zhì)量。
? ? ? ?如Retrieval parameters中所述，輸入到提示中的上下文數(shù)量是一個超參數(shù)。雖然RAG管道的性能可以隨著相關(guān)上下文的增加而提高，但如果相關(guān)上下文位于許多上下文的中間，則LLM也不會識別相關(guān)上下文，因此也可能會遇到“中間丟失”效應(yīng)。
參考文獻(xiàn)：
[1] https://python.langchain.com/docs/modules/data_connection/document_transformers/
[2] https://huggingface.co/spaces/mteb/leaderboard
[3] https://github.com/facebookresearch/faiss
[4] https://github.com/spotify/annoy
[5] https://github.com/google-research/google-research/tree/master/scann
[6] https://github.com/nmslib/hnswlib
[7] https://weaviate.io/blog/rag-evaluation?source=post_page—–7ca646833439——————————–#indexing-knobs
[8] https://gpt-index.readthedocs.io/en/v0.6.9/how_to/query/query_transformations.html
[9] https://towardsdatascience.com/improving-retrieval-performance-in-rag-pipelines-with-hybrid-search-c75203c2f2f5?source=post_page—–7ca646833439——————————–
[10]?https://cohere.com/rerank?ref=txt.cohere.com&__hstc=14363112.8fc20f6b1a1ad8c0f80dcfed3741d271.1697800567394.1701091033915.1701173515537.7&__hssc=14363112.1.1701173515537&__hsfp=3638092843
本文章轉(zhuǎn)載微信公眾號@ArronAI
鍵.png)
