問答系統的精髓：以文件為中心
每家公司都圍繞著一組小範圍的問題運轉，這些問題沒有人能迅速給出答案。例如：「我們在葡萄牙的育嬰假政策是什麼？」「我們是否與這位供應商簽署了保密協議（NDA）？」「去年我們為這個客戶報價時是否包括安裝服務？」「目前有效的安全程序版本是哪一個？」
人們不會直接搜索這些問題，而是向同事詢問，因為搜索結果會產生四十份文件，而同事卻只提供一句話。這種習慣浪費了寶貴的時間，並將知識集中在最長時間在公司工作的人身上。
一個內部助理解決了這個問題，而不是改進搜索框。你用簡單的語言提問，就能得到這句話以及來自哪段文字的鏈接。
引文是產品
一個不提供來源的助理並不會移走你的工時，而是讓你自己檢查。檢查意味著找到文件本身，而這正是你試圖避免的事情。有了段落、頁面和版本號的鏈接，檢查只需四秒鐘，然後你就可以繼續前進。
還有更重要的原因，隨著時間的推移會越來越明顯。沒有引文的答案是不可驗證的。如果答案錯誤，你就無法確定是來源文件錯誤、過時，還是被正確閱讀但摘要不準確。每種情況都有不同的解決方案和負責人。引文將一個關於AI的模糊抱怨轉化為具體且可關閉的工單。
簡而言之，背後的運作
這個系統由三個部分組成：文件的副本，分為段落；一個檢索步驟，用於提取最可能包含答案的幾個段落；一個模型，使用這些段落來撰寫答案並標明來源。
該模型沒有在你的數據上進行訓練，也不記住它。它只讀取檢索給它的內容，就像新分析員閱讀你放在他們桌上的文件一樣。如果今天更改文件，明天的答案也會相應更新。如果移除某人的訪問權限，他們的答案範圍也會相應縮小。
行業將此稱為「檢索增強生成」。從商業角度來看，這個詞最重要的部分不是技術層面：項目中最昂貴的部分並非模型，而是你的文件。
工作體現在文件中
這些項目的成敗在很大程度上取決於文件集（corpus）之前，任何人寫下提示之前。重複的工作流程如下：
- 選擇一個有界限的文件集。一個部門、一個目的。「所有SharePoint」不是文件集，而是垃圾場。
- 在檢索階段先設置權限。如果某人無法打開文件，助理就不應該引用它。直到實現此功能會非常痛苦，否則系統將存在漏洞。
- 解決重複問題。六份幾乎相同的合同範本會產生六份幾乎相同的答案，而助理沒有辦法知道人力資源實際使用的是哪一份。標記權威版本。
- 處理抗拒格式的文件：掃描PDF需要OCR，表格和幻燈片在扁平化為文本時失去意義，電子郵件線程大多是噪音。
- 為每個文件指定所有者和審核日期。一個有引文的助理可以讓過期內容顯而易見，有時會令人不適。
系統無能為力的地方
需要在整個檔案庫中進行計數或比較類型的問題。例如：「第三季有多少合同到期」是一個穿著搜索外衣的數據庫問題，檢索將自信但錯誤地回答它。「我們對這個供應商的總曝光度是多少？」將這些問題轉移到報告系統。
它也無法回答沒有人記錄下來的問題。如果定價規則僅存在於某個人的腦海中，誠實的輸出是沒有來源。一個承認自己不知道就是正確的系統，你應該設計這個答案而不是懲罰它。
測量第三個數字
從將要使用該系統的實際用戶那裡取出五十到一百個問題。這些不是虛構的問題。然後測量三個百分比：有正確引文回答的問題、因缺乏來源而拒絕的問題以及自信但錯誤回答的問題。
第三個數字是決定系統是否被使用的唯一因素。一個包含鏈接但不支持答案的問題會讓你失去更多信任，而不是二十個有幫助的答案所獲得的信任。盡量將這個數字降到最低，即使這意味著助理更頻繁地拒絕回答問題。
從一塊書架開始，而非整個圖書館
選擇一個具有清晰文件集和每周提出相同問題的一個團隊。八週時間足以讓他們擁有一手實物，包括權限設置工作。只有當該群體反對失去這些文件時才擴大範圍。
我們為中型公司建造這樣的系統，模式保持一致：每天使用的引文系統，而雄心勃勃但最終被遺忘的系統在三月就被靜靜地放棄了。