化“腐朽”為“神奇”：5 種 RAG 優(yōu)化技術(shù)應(yīng)對(duì)千奇百怪的 Query 原創(chuàng) 精華
編者按：您是否曾經(jīng)遇到這樣的情況：明明構(gòu)建了一個(gè)功能強(qiáng)大的 RAG 系統(tǒng)，但用戶卻頻繁抱怨“找不到想要的信息”或“返回的結(jié)果不夠準(zhǔn)確”？這是許多 RAG 應(yīng)用開發(fā)者面臨的共同挑戰(zhàn)。
這個(gè)問題不僅會(huì)導(dǎo)致用戶體驗(yàn)下降，更可能直接影響 RAG 系統(tǒng)的使用率和實(shí)際價(jià)值。如果未能得到妥善解決，之前的辛苦工作恐將付之東流，甚至影響整個(gè)項(xiàng)目的成功。
這篇文章并非紙上談兵，而是源自作者在實(shí)際項(xiàng)目中的第一手經(jīng)驗(yàn)。文章詳細(xì)介紹了 5 種 Query Translation 技術(shù):
a) Step-back prompting：將具體問題轉(zhuǎn)化為更寬泛的問題，以便獲取更多上下文信息。
b) HyDE (Hypothetical Document Embedding)：利用 LLMs 生成文檔，然后基于這個(gè)文檔檢索相關(guān)信息。
c) Multi-query：使用 LLMs 根據(jù)原始 query 生成多個(gè)版本的 query ，以改進(jìn)基于距離的相似度搜索。
d) RAG-Fusion：與 Multi-query 類似，使用 Reciprocal Rank Fusion 算法對(duì)檢索結(jié)果進(jìn)行重新排序。
e) Decomposition：將復(fù)雜問題分解為多個(gè)子問題，分別檢索答案后再整合。
這些技術(shù)各有優(yōu)勢，在實(shí)際應(yīng)用中可能需要根據(jù)實(shí)際情況結(jié)合使用才能達(dá)到最佳效果。
作者 ?? | Thuwarakesh Murallie
編譯 ?? | 岳揚(yáng)
Photo by travelnow.or.crylater[1] on Unsplash[2]
若認(rèn)為用戶會(huì)每次都向 LLMs 提出完美的問題，那您就大錯(cuò)特錯(cuò)了。與其直接執(zhí)行用戶的 query ，為何不選擇優(yōu)化用戶的 query 呢？這就是所謂的 query translation 技術(shù)。
我們開發(fā)了一款應(yīng)用，用戶可以通過它查詢我們公司歷史上制作過的所有文檔，其中包括PPT、項(xiàng)目提案、進(jìn)度報(bào)告、交付文檔和其他各類文檔等。這一成果非常了不起，因?yàn)檫^去的許多此類嘗試都失敗了。多虧了 RAGs，這一次的效果非常好。
在項(xiàng)目演示階段，我們都對(duì)這款應(yīng)用表現(xiàn)出了極大的熱情。最初，我們只針對(duì)一小部分員工進(jìn)行了推廣。然而，我們觀察到的現(xiàn)象并未讓我們感到非常興奮。
原本以為這款應(yīng)用會(huì)徹底改變大家的工作方式，但大多數(shù)用戶只是嘗試使用了幾次便不再使用了，仿佛這款應(yīng)用只是孩子們的玩具項(xiàng)目一樣。
日志數(shù)據(jù)顯示這款應(yīng)用表現(xiàn)良好，但我們還是與實(shí)際使用過該應(yīng)用的用戶進(jìn)行了交流，以便能夠確定問題所在。通過他們的反饋，我們開始思考如何通過 query translation 技術(shù)來消除 user inputs 中的歧義。
讓我們來看一個(gè)具體的例子。
有位用戶對(duì)我們提供給客戶“XYZ”的關(guān)于收購與時(shí)尚業(yè)務(wù)相關(guān)的企業(yè)的建議感興趣。他輸入的問題是：“合作伙伴 XYZ 進(jìn)行了哪些與時(shí)尚業(yè)務(wù)相關(guān)的收購？（What are the fashion-related acquisitions made by XYZ partners?）”該應(yīng)用程序檢索了相關(guān)用于交付的 PPT 文件，給出了一份包含十幾家公司的清單。但這份清單與用戶的期望大相徑庭，合作伙伴 XYZ 實(shí)際上已經(jīng)收購了（比如）7家時(shí)裝品牌，而清單中只列出了4家。這位用戶同時(shí)也是一名測試人員（tester），他對(duì)實(shí)際收購的數(shù)量了如指掌。
難怪大家會(huì)放棄使用這款工具。幸運(yùn)的是，因?yàn)椴扇×讼蛉w用戶逐步推出的策略，我們還有機(jī)會(huì)挽回失去的信任。
為了解決這一問題，我們對(duì)這款應(yīng)用程序采取了一系列的改進(jìn)措施。其中一項(xiàng)重要更新就是 query translations 技術(shù)。
本文旨在概述我們使用的不同 query translation 技術(shù)，而不進(jìn)行深入的技術(shù)解析。例如，這些技術(shù)可以與 few-shot prompting（譯者注：提供幾個(gè)示例輸入和輸出。） 和 chain of thoughts（譯者注：鼓勵(lì)模型在生成最終答案之前，先產(chǎn)生一系列的中間推理步驟。） 等提示詞技術(shù)相結(jié)合，以優(yōu)化結(jié)果。但這些技術(shù)細(xì)節(jié)將留待后續(xù)文章[3]中詳細(xì)討論。
接下來，我們將逐一研究這些技術(shù)。在此之前，先來看一個(gè)簡單的 RAG 示例。
01 Basic RAG Example
RAG（Retrieval-Augmented Generation）應(yīng)用都至少會(huì)有一個(gè)數(shù)據(jù)庫，通常是一個(gè)向量數(shù)據(jù)庫（vector store）和一個(gè)語言模型（language model）。RAG 的核心概念其實(shí)很簡單：在大語言模型（LLM）利用其已有知識(shí)回答用戶問題之前，它會(huì)先在數(shù)據(jù)庫中搜索相關(guān)的上下文信息，以此來生成更加精確的答案。
下圖展示了一個(gè)最基礎(chǔ)的 RAG 應(yīng)用示例。
Basic RAG application Workflow — Image by the author.
在基礎(chǔ)的 RAG（檢索增強(qiáng)生成）應(yīng)用中，與大語言模型（LLMs）的交互僅發(fā)生一次，可以是 OpenAI 的 GPT 模型[4]、Cohere 模型[5]，也可以是您自行部署在本地的模型。
下面給出的代碼展示了如何實(shí)現(xiàn)上圖的 RAG 基礎(chǔ)工作流。我們將以此代碼為基礎(chǔ)，進(jìn)一步探討本文中提到的其他技術(shù)。
在上述代碼中，我們通過一個(gè)網(wǎng)頁加載器（web-based loader）來獲取 Django 的官方文檔頁面，并將其內(nèi)容存入 Chroma 向量數(shù)據(jù)庫中。我們可以將這一過程應(yīng)用于網(wǎng)頁文檔、本地文本文檔、PDF文檔等不同類型的數(shù)據(jù)資源。
在此例中，我們沒有采用高級(jí)的檢索技術(shù)，而是直接將檢索器整合到了最終的RAG（檢索增強(qiáng)生成）流程中。后續(xù)我們將使用檢索器鏈（retriever chain）來代替單一的檢索器。 文章后續(xù)內(nèi)容將著重講解如何構(gòu)建檢索器鏈。
02 Step-back prompting
該技術(shù)用于確保生成的答案與上下文背景信息保持一致，不發(fā)生沖突。
Step-back prompting 與基本的 RAG 流程非常相似，但在處理用戶提出的問題時(shí)，不是直接針對(duì)用戶提出的初始問題進(jìn)行查詢，而是用一個(gè)更寬泛的問題從數(shù)據(jù)庫中檢索相關(guān)文檔。
與具體問題相比，更寬泛的問題能捕捉到更多的上下文信息。 因此，大語言模型（LLMs）能夠基于這些信息為用戶提供更多有用的信息，且不會(huì)與整體上下文信息相抵觸。
當(dāng)最初的 query 過于具體和詳細(xì)，但又缺乏全局視角時(shí)，這種方法往往非常有用。
Step-back prompting workflow — image by the author.
Step-back prompting 的流程是：語言模型先擴(kuò)展用戶輸入的 query ，然后從向量數(shù)據(jù)庫中檢索相關(guān)文檔，以此提供必要的上下文，并回答用戶最初提出的問題。
下面是 step-back prompting 的代碼實(shí)現(xiàn)。請注意，我們在這里采用了不同的處理方式，與前文的基本 RAG 流程中直接傳遞檢索器的方法不同。
Step-back prompting 對(duì)于那些需要依賴更廣泛的上下文背景信息的應(yīng)用場景極為有用。 通過這種方式，LLMs 能夠?yàn)橄嚓P(guān)問題提供前后一致的答案。
03 HyDE (Hypothetical Document Embedding)
給出的答案不僅僅是直接回答問題，而是包含了與問題相關(guān)的背景信息或其他相關(guān)內(nèi)容，使得答案更加全面和有深度。還會(huì)提供與答案內(nèi)容相關(guān)的可靠信息來源，比如學(xué)術(shù)文獻(xiàn)、研究報(bào)告、官方網(wǎng)站等，以便于驗(yàn)證信息的準(zhǔn)確性和可靠性。
HyDE（Hybrid Document Embedding）是一種近來流行且廣受歡迎的文檔檢索技術(shù)。其核心思想是利用大語言模型（LLMs）的已學(xué)習(xí)的先驗(yàn)知識(shí)（prior knowledge）編寫文檔，然后使用這個(gè)文檔從向量數(shù)據(jù)庫中檢索或提取相關(guān)的上下文信息。
HyDE 特別適用于用戶使用通俗的語言描述問題，而向量數(shù)據(jù)庫中的信息卻極為專業(yè)的情況。 此外，由于 LLMs 生成的文本信息中包含了較多的關(guān)鍵詞或關(guān)鍵短語，使得檢索到的相關(guān)信息更加精準(zhǔn)。
例如，對(duì)于“提高 Django 性能的10種方法（10 ways to improve Django's performance）”這樣的 query ，HyDE 能夠提供一個(gè)涵蓋成本考慮（cost implications）、緩存策略（caching）、數(shù)據(jù)壓縮（compression）等全方位的答案。
HyDE document retrieval process — image by the author.
下列代碼片段是上圖的代碼實(shí)現(xiàn)。這次，我僅提供了使用 HyDE 構(gòu)建檢索器鏈（retrieval chain）的代碼片段。
04 Multi-query
該技術(shù)通過改進(jìn)基于距離的相似度搜索（the distance base similarly search），從而能夠檢索到更多與用戶提出的問題相關(guān)的文檔，從而提高檢索結(jié)果的相關(guān)性和準(zhǔn)確性。
Multi-query 技術(shù)有助于解決在基于距離的相似度搜索中可能遇到的問題。大多數(shù)向量數(shù)據(jù)庫在檢索向量化文檔（vectorized documents）時(shí)使用余弦相似度（cosine similarity）作為度量標(biāo)準(zhǔn)。只要文檔之間的相似度足夠高，這種方法一般都能表現(xiàn)良好。 然而，當(dāng)相似度太低，以至于無法通過基于距離的相似度度量來有效地識(shí)別它們之間的關(guān)聯(lián)時(shí)，檢索過程就可能無法達(dá)到預(yù)期效果。
在 multi-query 方法中，我們要求大語言模型（LLMs）為同一 query 轉(zhuǎn)換多個(gè)版本的 query 。例如， “How to speed up Django apps” 這樣的 query 會(huì)被轉(zhuǎn)換為另一個(gè)版本的 query —— “How to improve Django-based web apps' performance?”。這些 query 合在一起共同作用，從向量數(shù)據(jù)庫中檢索出更多相關(guān)的文檔。
在將這些文檔傳遞給 RAG-LLM 生成最終回答之前，我們需要對(duì)檢索到的文檔進(jìn)行去重處理。 因?yàn)槎鄠€(gè) query 可能會(huì)檢索到相同的文檔。如果傳遞所有文檔，可能會(huì)包含重復(fù)項(xiàng)，超出 LLM 的 tokens 閾值，從而影響最終的回答質(zhì)量。
Multi-query retrieval workflow — image by the author.
下面這個(gè)代碼片段實(shí)現(xiàn)了一個(gè)額外的功能，可用于去除文檔中的重復(fù)項(xiàng)。其余部分與其他方法保持一致。
05 RAG-Fusion
在信息檢索和生成答案的過程中，優(yōu)先考慮和利用與用戶提出的問題更相關(guān)的文檔是非常重要的，因?yàn)檫@些文檔提供的信息更有助于生成準(zhǔn)確和有用的答案。
RAG fusion 和 multi-query 在文檔檢索方面有諸多相似之處。我們在這里再次要求大語言模型（LLM）生成初始 query 的多個(gè)不同版本。然后，我們用這些不同版本 query 分別檢索相應(yīng)的文檔，并將它們合并。
然而，在合并和去重文檔的同時(shí)，我們也會(huì)根據(jù)文檔的相關(guān)度對(duì)它們進(jìn)行排序。下面是 RAG-fusion 工作流程的示意圖。
RAG-fusion workflow — image by the author.
我們不再只進(jìn)行去重操作，而是使用排序系統(tǒng)（ranking system）對(duì)文檔進(jìn)行排序。Reciprocal fusion ranking（RRF）是一種非常巧妙的文檔排序算法。
如果多個(gè)版本的 query 檢索到的同一文檔是最相關(guān)的，那么 RRF 算法就會(huì)把該文檔排在前面。 如果某個(gè)文檔只在其中一個(gè)版本的 query 中出現(xiàn)，且相關(guān)度較低，那么 RRF 將把該文檔排在較低的位置。 這樣，我們就能獲得更相關(guān)的信息并對(duì)其進(jìn)行優(yōu)先排序。
06 Decomposition
在處理復(fù)雜問題時(shí)，大語言模型（LLM）能夠?qū)栴}拆分成多個(gè)部分，然后逐步構(gòu)建出答案。
有些情況下，直接給出答案并不是最佳策略。解決復(fù)雜任務(wù)的高效方法是將問題分解成多個(gè)部分，然后逐個(gè)部分地回答。
這也不僅僅是 LLMs 獨(dú)有的技巧，對(duì)嗎？
是的，我們在分解 query 的過程中試圖將初始問題拆分成多個(gè)子問題?；卮疬@些子問題的過程中將獲得解決初始問題的線索。
Query decomposition in RAG — image by the author.
如圖所示，我們?yōu)槊總€(gè)子問題檢索相關(guān)文檔并分別回答。然后，我們將這些問答對(duì)（question-and-answer pairs）傳遞給 RAG-LLM 。然后，LLM 擁有了更多、更詳細(xì)的信息來解決復(fù)雜問題。
07 Final thoughts
這款應(yīng)用程序從演示版本到部署于生產(chǎn)環(huán)境，中間經(jīng)過了許多優(yōu)化流程。其中不可避免的一步就是使用 query translation 技術(shù)。
我們所解決的問題在復(fù)雜程度上也各不相同。必須得考慮用戶發(fā)送不完美的 query 才是常態(tài)。檢索過程的缺陷也需要得到解決。 這些都是需要考慮的問題。
要選出哪一種 query translation 技術(shù)最佳，并沒有唯一正確的方法。在實(shí)際應(yīng)用中，我們可能需要結(jié)合多種技術(shù)才能獲得理想的輸出結(jié)果。
Thanks for reading!
Hope you have enjoyed and learned new things from this blog!
Thuwarakesh Murallie
Data Science Journalist & Independent Consultant
??https://www.linkedin.com/in/thuwarakesh/??
END
??文中鏈接??
[1]??https://unsplash.com/@travelnow_or_crylater?utm_source=medium&utm_medium=referral??
[2]??https://unsplash.com/?utm_source=medium&utm_medium=referral??
[3]??https://towardsdatascience.com/advanced-retrieval-techniques-for-better-rags-c53e1b03c183??
[4]??https://platform.openai.com/docs/models??
本文經(jīng)原作者授權(quán)，由 Baihai IDP 編譯。如需轉(zhuǎn)載譯文，請聯(lián)系獲取授權(quán)。
原文鏈接：
