LLM對于行業術語出現幻覺怎么解？快來試試Golden Retriever 指代消歧 原創 精華
今天來分享一篇深度好文：《Golden-Retriever: High-Fidelity Agentic Retrieval Augmented Generation for Industrial Knowledge Base》，我們知道企業落地RAG系統有以下常見痛點：
- 技術公司維護著大量的專有文檔，如培訓材料、設計文檔和研究成果。
- 工程師，尤其是新員工，需要快速查詢這些文檔或吸收其中的新知識。
- 這些領域特定的文檔通常包含許多技術社區特有的縮寫和術語，使得導航變得復雜。
而這篇文章提出了一個概念：Golden-Retriever，旨在文檔檢索前增加了一個基于反思的問題增強步驟，并相應地增強問題，以克服傳統的LLM微調和RAG框架在特定領域術語和上下文解釋方面的挑戰。Golden-Retriever通過識別和澄清術語，并增強問題，實現了對文檔檢索前的問題增強。這種全面的增強使RAG框架能夠提供清晰的上下文并解決歧義，從而顯著提高了檢索準確性。通過在特定領域問答數據集上進行評估，證明了Golden-Retriever的優異性能，為高效地整合和查詢工業知識庫提供了有力的解決方案。
介紹
當前的檢索增強生成 (RAG) 技術在處理工業知識庫中特定領域查詢時，往往難以達到理想的效果。例如，對于一個問答問題“三星或海力士NAND芯片的PUC架構是什么？”的場景，RAG 誤解了"PUC"這個專業術語，錯誤地將其解釋為“公共事業委員會（Public Utilities Commission）”而不是正確的“細胞下外圍設備（Periphery Under Cell）”。這種誤解突顯出了幻覺問題，即模型基于模糊的輸入生成了不正確或無意義的信息。
盡管已有技術如Corrective-RAG和Self-RAG試圖通過在文檔檢索步驟后修改響應來改進結果，但如果初始檢索因誤解術語或上下文缺乏而存在缺陷，則這些后處理技術無法完全修正不準確性。
此外，這些方法主要集中在改進檢索后生成的響應上。然而，當檢索到的文檔本身不相關時，這些辦法其實效果有限。它們并未直接解決根源問題，也就是用戶問題和初始檢索過程之間的歧義性。
另一種方法，由Kochedykov等人提出，試圖通過將模糊問題解構為抽象語法樹 (AST)，并據此合成SQL查詢以解決模糊問題。這種方法雖然提升了查詢的保真度，但它只限于SQL查詢，并不能推廣到更廣泛的問答場景。圖示揭示了這一局限性，說明該方法在消除歧義和構造查詢上雖然更有效，但對于重要的上下文和術語解釋的普通檢索任務來說，它并不適用。
我們提出了 Golden-Retriever，這是 RAG 的?種代理衍?產品，其特點是在?檔檢索之前進?基于反射的問題增強，使 RAG 能夠檢索到最相關的?檔，盡管術語含糊不清且缺乏上下?。下面是對這三種方式的流程說明：
image-20240823110951416
方法
Golden-Retriever由離線和在線兩部分組成。離線部分是部署知識庫聊天機器人之前進行的數據預處理步驟。在線部分是每次用戶提問時發生的交互過程，下面給出對應的流程圖，左側是Golden-Retriever在線推理部分的工作流程圖。右側是系統與LLM在工作流程中間步驟的示例交互。系統提示LLM生成中間響應，這些響應被保存、訪問，并用于工作流程的步驟。
2.1 LLM對文檔進行總結
Golden-Retriever的離線部分專注于增強文檔數據庫，以提高檢索到的文檔的相關性。此過程首先收集公司的原始文檔，例如幻燈片、嵌入文本的圖像和表格，以形成知識庫。這些文檔的格式和內容通常各不相同，缺乏清晰的敘述，這會導致使用RAG查詢時相關性得分較低。
為了解決這個問題，我們使用OCR從這些文檔中提取文本，并將其拆分成更小、更易于管理的塊進行處理。對于Meta-Llama-3模型，這些塊每個大約有4,000個標記。然后使用LLM處理每個塊，以從領域專家的角度生成摘要，利用LLM的語義理解和上下文學習能力。這些增強數據被添加到文檔數據庫中，使其在查詢時更可能檢索到相關文檔。
2.2 識別術語
在線流程的第一步是識別用戶問題中的術語和縮寫。此步驟至關重要，因為許多特定領域的問題都包含需要澄清以確保準確解釋的專業術語。為了識別這些術語，我們使用了一個提示模板，該模板旨在指導LLM提取并列出輸入問題中發現的所有術語和縮寫。此過程可以確保識別所有可能產生歧義的術語，從而有助于在后續步驟中解決它們。已識別的術語和縮寫以結構化格式輸出供進一步處理。
2.3 識別背景
在識別出專業術語后，確定提問的上下文非常重要，因為術語的含義在不同上下文中可能有很大差異。例如，“RAG”在人工智能的上下文中可能表示“檢索增強生成”，而在遺傳學中可能表示“重組激活基因”。為了準確解釋上下文，我們使用了與專業術語識別類似的反思步驟，涉及設計提示模板。
雖然可以使用更簡單的方法，例如基于轉換器的文本分類器，對用戶進行分類意圖，但這將需要一個專門的訓練數據集。這對于我們的應用程序來說是不切實際的，因為創建這樣一個數據集需要大量的努力和資源。
相反，我們選擇了“使用LLM作為后端”的方法，盡管會招致較高的計算成本，但無需專用的訓練數據集，可以高效運行在本地服務器上。事先識別上下文可以幫助我們準確理解和處理用戶輸入。
2.4 查詢術語
一旦確定了術語和上下文，下一步就是查詢術語詞典，獲取已識別術語的擴展定義、描述和注釋。此步驟對于向用戶提供術語的準確解釋至關重要，確保擴展問題清晰無歧義。
此過程涉及使用在2.2節中確定的術語列表查詢SQL數據庫。術語列表被插入到SQL查詢模板中，然后經過處理從術語詞典中檢索相關信息。檢索到的信息包括擴展名稱、詳細描述以及任何有關術語的相關注釋。
我們選擇不使用LLM直接生成SQL查詢，使用LLM生成SQL查詢可能會帶來查詢質量和安全性方面的不確定性，并且還會增加推理成本。相反，通過使用基于代碼的方法來合成SQL查詢，我們可以確保查詢是可驗證的安全和可靠的。
從這一步獲得的詳細信息對于補充用戶的原始問題至關重要。它允許準確的上下文和術語解釋，這對于RAG流程檢索最相關的文檔并生成精確的答案至關重要。
2.5 擴充問題
確定了術語定義和上下文后，下一步是擴充用戶的原始問題以包含這些附加信息。此擴充可確保RAG流程通過提供清晰的上下文并解決問題中的任何歧義來檢索最相關的文檔。
此步驟涉及將原始問題與上下文信息以及從2.3和2.4部分獲得的詳細術語定義相結合。增強型問題明確地陳述了上下文，并澄清了任何模棱兩可的術語，從而有助于增強文檔檢索。
該過程是自動化的，代碼將原始問題以及上下文和術語識別步驟的結果組合成一個結構化的模板。然后，增強問題將替換用戶的原始問題，并用作RAG框架的輸入，確保檢索到最相關、最準確的文檔。
2.6 查詢未命中響應
在某些情況下，系統可能在詞典中找不到某些術語的相關信息。為了處理這種情況，GoldenRetriever 有一個后備機制，可以合成一個響應，表明數據庫由于缺少信息無法回答問題。
系統提示用戶檢查術語的拼寫或聯系知識庫管理員添加新術語。此步驟可確保系統保持高保真度并避免生成不正確或誤導性的響應。未識別的術語適合于響應模板，提示用戶檢查拼寫并聯系知識庫管理員添加新術語。
評估
使用針對工程師新員工培訓文檔中的六個不同領域的測驗作為測試問題。所有問題都是多項選擇題。顯示的是五次試驗的平均得分。最佳得分用粗體顯示。
通過在特定領域的問答數據集上的評估，Golden-Retriever在多個開源LLM上表現出色，與傳統的RAG方法相比，顯著提高了答案的準確性。與Vanilla LLM和RAG相比，Golden-Retriever分別將Meta-Llama-3-70B的總分提高了79.2%和40.7%。在測試的所有三種大型語言模型中，平均將得分提高了57.3%。
總結
Golden-Retriever 主要完成了兩項任務：首先，它在構建企業數據庫時利用LLM生成摘要信息來替代原始文檔，以提高檢索的召回率。其次，利用術語庫重構原始問題，進行指代消歧。
在方案實現上，通過術語庫重構問題確實可以避免歧義，但是這需要多次調用LLM進行術語識別、上下文理解和問題重構等操作。在實際工業落地實施中，效率和術語庫的規模可能會成為關鍵考慮因素。
本文轉載自公眾號AI 博物院 作者：longyunfeigu
