OpenAI的ChatGPT在不到一周的時間內(nèi)就達到了百萬用戶，并且在不到兩個月的時間內(nèi)就突破了1億用戶大關(guān)。圍繞這項技術(shù)的興趣和興奮是顯著的。世界各地的用戶看到了將這些大型語言模型應(yīng)用于廣泛場景的潛力。

?

在企業(yè)應(yīng)用程序環(huán)境中，我們常聽到的問題是“我如何構(gòu)建像ChatGPT這樣的東西，使用我自己的數(shù)據(jù)作為其響應(yīng)的基礎(chǔ)？”

?

的組合Azure認(rèn)知搜索和Azure OpenAI服務(wù)為這種情況提供了一種有效的解決方案。它集成了Azure的企業(yè)級特性、跨大型知識庫索引、理解和檢索您自己的正確數(shù)據(jù)的認(rèn)知搜索能力，以及ChatGPT以自然語言回答問題或輪流對話的令人印象深刻的交互能力。

?

在這篇博文中，我們將描述上述解決方案模式，從編排對話和知識庫的內(nèi)部因素，到幫助最終用戶正確判斷響應(yīng)及其支持事實所需的用戶體驗考慮因素。我們的目標(biāo)是從今天開始，使用預(yù)覽版中的“gpt-35-turbo”模型，為您提供構(gòu)建基于ChatGPT的應(yīng)用程序所必需的工具。我們還發(fā)布了一個GitHub repo示例，包括UX、配器、提示等。，您可以使用它來了解更多信息或作為您自己的應(yīng)用程序的起點。

?

與您自己的數(shù)據(jù)聊天

與ChatGPT這樣的大型語言模型交互的方式是使用自然語言，給模型一個“提示”并請求它完成它。這可能是一個問題，一個談話的轉(zhuǎn)折，一個延伸的模式，等等。當(dāng)以這種方式使用時，您得到的響應(yīng)是基于模型在訓(xùn)練期間學(xué)到的東西，這對于一般的知識問題或非正式的聊天可能是有用的，但如果您正在構(gòu)建一個應(yīng)用程序，用戶應(yīng)該根據(jù)您自己的數(shù)據(jù)看到響應(yīng)，這不是您想要的。在本例(詢問員工醫(yī)療保健計劃)中，您可以看到使用基本ChatGPT模型的回答(綠色)沒有用，因為它沒有說明公司自己的福利政策:

<|im_start|>system
Assistant?helps?Contoso?Inc?employees?with?their?internal?healthcare?plan?questions.?
<|im_end|>
<|im_start|>user
Does?my?plan?cover?annual?eye?exams?
<|im_end|>
<|im_start|>assistantI'm?sorry,?I'm?not?able?to?access?your?specific?healthcare?plan?information.?However,?many?healthcare?plans?do?cover?annual?eye?exams.?I?recommend?checking?your?plan's?summary?of?benefits?or?contacting?your?plan?administrator?for?more?information.

?

讓ChatGPT基于您自己的數(shù)據(jù)生成響應(yīng)的一種方法很簡單:將這些信息注入到提示中。ChatGPT可以讀取信息以及任何指令、上下文或問題，并做出相應(yīng)的響應(yīng)。這種方法不需要對模型進行重新訓(xùn)練或微調(diào)，并且響應(yīng)可以立即反映底層數(shù)據(jù)的任何變化。

?

這帶來了一個新的挑戰(zhàn):這些模型對它們支持的“上下文長度”有限制(當(dāng)前的ChatGPT模型在一個提示中可以接受多達4000個令牌)，即使它們沒有這些限制，在每次交互中向文本提示中注入GBs的數(shù)據(jù)也是不實際的。另一種方法是將所有數(shù)據(jù)保存在一個外部知識庫中，這樣可以快速檢索到相關(guān)的數(shù)據(jù)，這正是認(rèn)知搜索的設(shè)計目的。下面是一個起點提示和響應(yīng)的樣子:

?

<|im_start|>system
Assistant?helps?Contoso?Inc?employees?with?their?internal?healthcare?plan?questions.?Only?answer?questions?based?on?the?fact?listed?below.?If?the?facts?below?don't?answer?the?question,?say?you?don't?know.?Each?fact?sentence?is?numbered.?Always?include?a?reference?to?the?fact?number?in?the?form?[number]?when?you?answer.?
1.?Employees?have?a?choice?of?two?plans,?PlanA?and?PlanB,?and?they?have?different?benefits.
2.?PlanA?includes?coverage?for?annual?eye?and?hearing?exams.
3.?Those?with?PlanB?have?a?co-payment?for?routine?eye?exams?and?vision-related?purchases?such?as?glasses.
4.?Both?PlanA?and?PlanB?cover?preventive?care?visits.<|im_end|>
<|im_start|>user
Does?my?plan?cover?annual?eye?exams?
<|im_end|>
<|im_start|>assistantPlanA?includes?coverage?for?annual?eye?and?hearing?exams.?[2]

?

在示例中，藍色部分是基于用戶的問題和任何可能適用的累積上下文從認(rèn)知搜索中檢索的，綠色部分是模型生成的響應(yīng)，其余部分是我們用來給模型指示的提示模板。

?

這種檢索增強的生成方法為從簡單開始并根據(jù)需要變得更加復(fù)雜打開了大門。對于如何構(gòu)造提示、如何從知識庫中制定有效檢索的查詢以及如何編排ChatGPT和知識庫之間的來回交互，有許多選項。在我們深入探討這些之前，讓我們先談?wù)劻硪粋€需求:幫助用戶驗證響應(yīng)是否可信。

?

產(chǎn)生可信的響應(yīng)

我們假設(shè)這些大型語言模型、提示和編排系統(tǒng)并不完美，并將它們生成的響應(yīng)視為候選響應(yīng)，這些響應(yīng)應(yīng)該包含最終用戶需要驗證的正確信息。作為探索這個主題的一部分，我們實現(xiàn)了3個簡單的體驗作為起點。這并不是說只有這些。我們歡迎為用戶提供更好的工具來驗證系統(tǒng)結(jié)果是否真實正確的最佳方式的想法和反饋。

?

如下圖所示，當(dāng)我們在示例中生成響應(yīng)時，我們還為用戶提供了3種“深入”工具:

1. 引文:回復(fù)中的每條陳述都包含一條引文，并帶有指向源內(nèi)容的鏈接。你可以看到上下文中的引用(上標(biāo)數(shù)字)以及底部的鏈接。當(dāng)你點擊一個，我們顯示原始內(nèi)容，讓用戶可以檢查它。

2. 支持內(nèi)容:ChatGPT生成的每個響應(yīng)或聊天氣泡都有一個選項(筆記本圖標(biāo)),用于顯示作為事實輸入到提示中的所有原始內(nèi)容。

3. 編排流程:我們還在每個回復(fù)或聊天氣泡中提供了一個選項(燈泡圖標(biāo))來查看整個交互過程，包括中間結(jié)果和生成的提示。

根據(jù)受眾的不同，這些選項對用戶可能有用，也可能沒用。還有其他選項可以為用戶提供透明和驗證工具，讓他們對回答有信心。特別是，在這篇博客文章和示例代碼的初始版本中，我們并沒有討論在應(yīng)用程序中可以實現(xiàn)的方法的關(guān)鍵主題，這些方法用于評估響應(yīng)的質(zhì)量，并可能拒絕或重試不符合特定標(biāo)準(zhǔn)的情況。我們鼓勵應(yīng)用程序開發(fā)人員在每個應(yīng)用程序體驗的上下文中明確探索這個主題。

?

新興互動模式

更有效的提示設(shè)計、檢索查詢構(gòu)造和組件間交互模型的方法正在迅速出現(xiàn)。這是一個新生的領(lǐng)域，我們期待看到許多快速的進步。這里是提示和查詢生成的起點的一個小樣本，并為那些對更多細(xì)節(jié)感興趣的人提供了參考文獻:

• 檢索然后閱讀:單次問答場景的簡單起點，其中用戶問題包含足夠的信息，可以從搜索索引中檢索候選項。這種方法簡單地使用問題從索引中檢索，取前幾個候選項，將它們與指令和問題本身一起嵌入到提示中。

• 在檢索之前閱讀內(nèi)容和上下文:在許多情況下，用戶問題本身不足以進行檢索。例如，在會話設(shè)置中，最后的用戶話輪可能只是代表后續(xù)要點或問題的幾個詞，不能用于有效地檢索相關(guān)知識。即使在單次交互中，也需要考慮上下文。在這些情況下，一種有趣的方法是使用ChatGPT生成搜索查詢，方法是要求該工具為檢索目的創(chuàng)建一個對話摘要，并考慮您想要注入的任何上下文。

• 動作、工具等:通常用戶輸入、提示指令和知識庫之間的單個交互是不夠的。例如，已經(jīng)證明，要求大型語言模型將響應(yīng)分解成小步驟可以提高響應(yīng)的質(zhì)量，并避免某些錯誤模式。一旦問題被分解，可以向外部來源詢問更小和更有針對性的問題，或者作為我們迄今為止所做的非結(jié)構(gòu)化搜索，或者作為仿真問答步驟(例如，在認(rèn)知搜索中由語義答案支持)，或者作為外部系統(tǒng)中的查找(例如，內(nèi)部應(yīng)用程序中的雇員表，或者客戶支持應(yīng)用程序中的事件表)。這是一個廣闊的探索空間，許多早期的實驗工作正在進行。一些有趣的閱讀包括引入CoT(思維鏈)提示和后續(xù)工作反應(yīng)方法將嬰兒床與工具結(jié)合在一起工具成型方法教導(dǎo)模型如何使用多種工具做出反應(yīng)。

這篇博文附帶的示例實現(xiàn)了其中的一些，或者直接實現(xiàn)，或者通過開源庫實現(xiàn)，比如朗查恩。僅舉一個特定的例子，在下面的截圖中，用戶聊天轉(zhuǎn)向“我有plus計劃”使用簡單的檢索然后閱讀的方法不會產(chǎn)生好的答案，但是使用稍微復(fù)雜一點的實現(xiàn)可以很好地工作，該實現(xiàn)攜帶對話的上下文:

?

改進知識庫檢索

由于回答最終將基于我們能夠從知識庫中檢索到的內(nèi)容，因此檢索質(zhì)量成為這些解決方案的一個重要方面。以下是一些注意事項:

1. 語義排序:默認(rèn)情況下，認(rèn)知搜索將使用關(guān)鍵字搜索結(jié)合簡單的概率模型進行評分。你可以選擇啟用語義排名，這將使用復(fù)雜的深度學(xué)習(xí)二級排名層來提高精確度。

2. 文檔分塊:當(dāng)在Cognitive Search中為支持ChatGPT場景的特定目的而索引內(nèi)容時，您希望內(nèi)容具有正確的長度。如果每個文檔都太短，就會缺乏上下文。如果太長，就很難找到合適的部分讓ChatGPT“讀取”。如果您的數(shù)據(jù)允許，我們建議以幾個句子(例如，頁面的1/4到1/3)為目標(biāo)，以文本的滑動窗口為起點。在某些情況下，例如零件目錄，合理的做法是不要將數(shù)據(jù)分塊，讓每個文檔包含單個零件的完整描述。

3. 摘要:即使在分塊之后，有時您可能希望在提示中包含更多的候選項，方法是縮短每個候選項的長度。您可以通過使用總結(jié)步驟來實現(xiàn)這一點。這方面的幾個選項包括使用語義字幕(認(rèn)知搜索中直接支持的基于查詢上下文的摘要步驟)，使用點擊突出顯示(一種更詞匯化而不是語義化的提取片段的機制)，或者用外部摘要模型對搜索結(jié)果進行后處理。

附帶的示例代碼包括一些功能，可以輕松地試驗上面的一些選項(單擊窗口右上角的設(shè)置圖標(biāo))。

?

更多場景

在這篇博文中，我們重點關(guān)注了對話和問答場景，這些場景將Azure OpenAI的ChatGPT與Azure Cognitive Search相結(jié)合，作為一個知識庫和檢索系統(tǒng)。還有其他方法可以將Azure OpenAI服務(wù)和認(rèn)知搜索結(jié)合起來，以改善現(xiàn)有的場景或?qū)崿F(xiàn)新的場景。示例包括使用自然語言進行查詢，增強目錄瀏覽體驗，以及在索引時使用Azure OpenAI來豐富數(shù)據(jù)。我們計劃繼續(xù)發(fā)布指南和示例來說明如何實現(xiàn)這些目標(biāo)。

?

今天就用你自己的數(shù)據(jù)或我們的數(shù)據(jù)來試試吧

我們貼出了一些例子，包括這篇博文中展示的完整的UXGitHub回購。我們計劃繼續(xù)擴大回購，重點是覆蓋更多場景。

?

您可以克隆這個repo，或者使用包含的示例數(shù)據(jù)，或者對其進行修改以使用您自己的數(shù)據(jù)。我們鼓勵你采取迭代的方法。數(shù)據(jù)準(zhǔn)備需要幾次嘗試。從上傳你所擁有的開始，嘗試體驗。

?

大型語言模型結(jié)合信息檢索技術(shù)的可用性推動了改進和全新場景的前景，我們對此感到興奮。我們期待看到你會用Azure OpenAI和Azure認(rèn)知搜索構(gòu)建什么。

以上內(nèi)容來源?Azure AI博客