大多數企業的知識儲存在各種文檔、報告中,被放置在各種內容管理工具和平台上;雖然可以透過資料夾分類,但是沒辦法透過語意查詢索引到相關文件。
而 OpenAI GPT-3 模型在給定上下文(context)的情況下用通順語句回答問題的出色能力,可以利用 GPT-3 在來建構知識庫問答系統。
流程圖
大致的步驟如下:
(I) 將文檔資訊抽取出來,透過 GPT-3 轉成 Embeddings
(II) 將查詢 query 與文檔 Embeddings 做相似度比對
(III) 將最相似的前幾項文檔來源當作 Context,搭配查詢 query,丟回給 GPT-3 回傳整理後的資訊
其中有一些技術我們在這詳細探討:
PDF 資訊抽取
通常大多數文檔將內容或主題組織成部分和子部分,以更好地閱讀、組織和理解。此外,商業文檔可能還包含具有不同結構和布局的表格內容。因此,在從文檔中提取內容時,同樣重要的是提取相應的布局語義,以更好地理解內容的相關性和組織性。
要將 PDF 文件中的數據提取成文本形式,可以使用 Adobe PDF API 或 OCR API。可以特別注意這些抽取工具是否能保留段落位置、標題、粗體等資訊,會有助於重組抽取出的文字內容。
針對表格型內容的抽取
通常從表格/表格單元格中提取的文本,因為分隔符號的緣故,無法直接擷取到完整的句子。因此,當我們直接在此類數據上測試 OpenAI GPT-3 模型進行問答時,回答的質量不如理想或不可理解。實際上,真正需要的是根據從表格中提取的以制表符分隔的文本數據生成或構建有意義的句子的能力。
而這一塊正好又能使用到 GPT-3 的能力,我們可以將以制表符分隔的數據以及它們的單元格索引值當作 prompt 、希望產生出的結果當成 completion data,丟給 GPT-3 模型進行 fine-tune,這樣做可以提升表格抽取的質量。
將文字轉為 Embeddings
完成了檔案文字的抽取後,由於 GPT-3 有 max_tokens 的限制,我們需要將文本分 block 創建 embedding;這部分可以使用GPT標記器計算標記的數量,並使用這些數據將文本分成適當的長度,以使每個分塊的標記數不超過嵌入所允許的標記限制。
另一個挑戰是,特定主題的文本數據可能會分散在不同 block 中。對於用戶的查詢,答案可能分佈在不同 block 中,針對此問題,建議是可以維護每個 embedding block 與其相應主題的關聯,便於在進行完相似度匹配後可以調出相關主題的文件作為 context。
相似度匹配 Similarity Match
接著需要匹配用戶查詢與文本 embeddings,挑出和用戶查詢語意最相近的內容作為 context,可以使用餘弦相似度或 FAISS 套件庫來計算 2 個 embeddings 間的相似度。
指令工程 Prompt Engineering
首先在 prompt 中要求 GPT-3 「自文字段落中真實回答問題」,接著在將這些內容組合成一個段落,作為要讓模型回答問題的來源,最後接上用戶的查詢語句。
提醒也別忘了使用 temperature, top_k 等參數調整輸出的變化程度。
結論
- 內容是否被合理地分段(分 block)並相互關聯,好提供最能匹配用戶查詢的結果。
- 如何在 prompt 中提供適當的上下文給 GPT-3 Completion API,從匹配的 block 中返回精煉且正確的回答。