生成式 AI 和大型語言模型 (LLM) 實現的最令人興奮的模式之一是對話式搜索。 在這篇文章中，我將介紹你為什麼需要對話式搜索、它是如何工作的以及這種搜索模式有哪些限制和變體。

NSDT工具推薦： Three.js AI紋理開發包 - YOLO合成數據生成器 - GLTF/GLB在線編輯 - 3D模型格式在線轉換 - 可編程3D場景編輯器 - REVIT導出3D模型插件 - 3D模型語義搜索引擎 - Three.js虛擬軸心開發包

1、為什麼需要對話式搜索

您希望能夠從您控制的知識庫中回答問題嗎？ 您是否有可以回答您所在領域的問題的文檔？ 是否不可能從您的知識庫中列舉出您希望能夠回答的所有問題？ 如果您對這些問題中的任何一個回答“是”，那麼對話式搜索可能適合您。

簡而言之，對話式搜索可以對您的文檔進行任意問題和答案。 它使用您的文檔來查找與給定問題相關的內容，並使用大型語言模型從相關內容生成文本。 問題和生成的答案都不逐字存在於您的知識庫中。 生成的答案仍然基於您的知識庫。 用戶以對話方式提出問題，答案基於知識庫搜索，因此我們稱之為對話式搜索。

有些人將這種方法稱為檢索增強生成（RAG）。 系統執行以下操作：給定此上下文（從搜索查詢中檢索），回答此問題（使用生成的文本增強搜索結果）。

這是對傳統搜索的改進，傳統搜索給出的是一段話，而不是答案。 例如，我根據我自己和 Marco Noel 撰寫的關於語音定制主題的文章訓練了一個會話搜索系統。 下面是圖 1 中的示例：

圖 1 比較傳統搜索和對話式搜索中對同一問題的回答

傳統搜索返回文檔中的一段內容。 該段落是與問題非常相關的文檔中的關鍵字匹配。 在傳統搜索中，用戶可以單擊文檔並最終找到答案。 在對話式搜索中，系統直接返回答案。 對話式搜索的答案太棒了！ 它源自知識庫，下面來自開發人員工具的圖 2 顯示了使用哪些文檔來構建答案。 提出問題的用戶還可以獲得文檔的鏈接來驗證答案。

圖 2 會話搜索響應示例，突出顯示了答案中的每個單詞使用了哪些文檔。

眾所周知，LLM會通過給出自信但不合理的答案來產生幻覺。 許多LLM都是“在互聯網上接受訓練的”。 如果您從互聯網上獲取一個平均片段，您會相信它嗎？ 然而，會話搜索可以通過首先要求答案的很大一部分直接來自知識庫，然後在無法使用知識庫時回答“我不知道”來減輕幻覺。 其他緩解措施也是可能的，並且可能需要根據您的LLM進行。 如上圖所示，對話式搜索可以提供證據，幫助您決定是否信任其答案。

在文檔集合上使用生成式人工智能比針對您可以枚舉的問題編寫常見問題解答腳本或靜態聊天機器人更容易。 它生成答案，而不是段落，因此它對用戶來說比搜索更有用。 最後，它可以為生成的答案提供出處，為您提供值得信賴的響應。

2、對話式搜索的工作原理

傳統搜索的流程是“用戶查詢”->“知識庫搜索”->“返回相關段落”。

在會話式搜索中，流程是“用戶查詢”->“知識庫搜索加LLM”->“返回答案（帶證據）”。

我們已經了解了純粹的“知識庫搜索”是如何工作的。 純粹的LLM是當你將查詢發送到像 ChatGPT 這樣的界面時，它會根據自己的知識庫（它是訓練數據）而不是你的知識庫來回答問題。 神奇的事情發生在“知識庫搜索加LLM”的結合中。 關鍵步驟如下圖3所示。 假設用戶問一個問題“我該怎麼做 X？”

圖 3 高級對話式搜索流程

對話式搜索從傳統搜索開始，但將搜索結果輸入到大型語言模型中。 LLM使用精心設計的提示，其中包括知識庫中的上下文。 此提示指示LLM生成答案，但將答案限制在知識庫中。 顯示的提示是說明性的 - 您的聊天平臺提供商可能會添加其他說明，例如告訴LLM何時說“我不知道”。

對話式搜索的美妙之處在於，大部分工作都落在聊天平臺提供商身上。

聊天解決方案構建者隻需要：

• 提供相關文檔（或知識庫API 的鏈接）。
• 配置與 LLM 的連接。

聊天平臺提供商做了更繁重的工作：

• 托管LLM。
• 提示工程構建最高效的提示。 LLM對提示的大小有嚴格的限制，導致需要權衡。 應包含多少搜索結果？ 其他提示說明需要詳細到什麼程度？
• 可能會與提示工程一起調整知識庫 API 調用，以檢索相關且簡潔的包。

我在不到一個小時的時間內為自己建立了一個演示對話搜索，其中包括建立我的知識庫！

在圖 3 中，我們看到了會話式搜索如何回答用戶的初始問題。 這種模式也可以在用戶提出後續問題的來回對話中發揮作用。 後續問題如圖 4 所示。

圖4 使用之前的聊天記錄進行對話式搜索

同樣，對話平臺完成了大部分工作。

對話式搜索令人興奮，因為每個企業都有一個知識庫，而對話式搜索可以輕松解鎖該知識庫！ 我預計會話搜索將在幾年內成為知識庫的新基線期望。 用戶會喜歡有證據支持的答案； 知識庫所有者會喜歡從其內容中獲得的增加的價值。

3、對話式搜索有哪些限制和變化

會話式搜索仍處於起步階段。 大規模實施面臨一些挑戰，並且基本主題存在多種變化。

• 挑戰#1：價格昂貴。

會話搜索背後的大型語言模型的計算成本很高，在專用硬件上運行，並且需要專門的技能來調整。

大型人工智能公司擁有大部分LLM，我預計大多數企業會購買而不是構建。 對 LLM 的 API 調用通常比大多數知識庫搜索 API 昂貴得多。

一種變體是使用對話式搜索作為後備選項。 您可以為最常見的問題（“短尾”或“80/20”中的“80”）構建傳統/靜態問答聊天機器人，並回退到對話式搜索以解決任何未預先編程的問題（“長尾”） 。 您可以將靜態問答視為緩存。 在此模式中，您可以使用 LLM 一次性生成常見問題的答案並將其存儲在靜態聊天機器人中。

• 挑戰#2：模型由誰托管？

如上所述，這些模型很昂貴。 許多模型提供商通過保留發送到其模型的請求以用作未來的訓練數據來抵消這一成本。 您的企業可以將他們的問題和知識庫內容發送給第三方嗎？ 我預計企業會要求選擇使用LLM來保護其機密數據。

• 挑戰#3：這種模式隻是問答，還不是事務性的

對話式搜索可以為用戶問題生成出色的答案。 我看到了“如何開設賬戶”、“如何重置密碼”等問題的精彩答案。 為用戶開設帳戶或重置密碼不是很好嗎？ 這是顯而易見的下一步，我想我們很快就會看到它來自平臺提供商。 企業需要一個可以與其 API 集成來完成任務的解決方案。

• 變體 #1：搜索 API

基本的會話式搜索架構可以使用幾乎任何搜索 API。 接收文本查詢並返回文檔和/或段落的傳統搜索 API 無處不在。 對話式搜索受搜索 API 的支配，返回高度相關的內容以輸入到 LLM 提示中。 LLM 提示空間非常寶貴，搜索相關性的微小改進可以帶來更好的答案。 一種變體是使用向量嵌入，而不是搜索 API 的傳統“倒置索引”。

向量嵌入對單詞之間的語義關系進行編碼，從而可以更深入地理解用戶的問題以及知識庫中的文檔。 傳統的搜索方法更接近基於關鍵詞。 圖 1 中的傳統搜索返回的結果與關鍵字相關，但不足以回答問題。 現有的搜索 API 很簡單； 向量嵌入可以給出更好的答案。

• 變體#2：向 LLM 傳遞更多背景信息

這篇文章中的示例 LLM 提示是通用的，適用於任何對話。 提示可以通過附加上下文（例如用戶配置文件）進一步增強。 可以指示LLM“用戶是黃金會員”、“用戶是成年人”或“用戶位於”。 我希望聊天平臺提供商能夠提供一種方法來做到這一點，盡管這需要一些工作才能使解決方案構建者輕松集成。

4、結束語

對話式搜索是一種令人興奮的模式，易於設置且前景廣闊。 我希望這篇文章對您理解該模式有所幫助。 寫這篇文章幫助我鞏固了我的觀點！

原文鏈接：對話式搜索簡明教程 - BimAnt