構建全公司知識圖以顯著加速代理人工作效率

我們給了一個代理一個整個公司的知識圖譜，並詢問它五個公司範圍內的問題。它的回答同樣準確，具體如下：

73%

更短的回答時間

92%

讀取的輸入 token 更少

66%

更少的模型呼叫

構建圖譜幾乎不消耗模型 token。通用起草規則直接閱讀案件紀錄，僅在需要 LLM 對映時才做增補。

圖譜從公司的案件與檔案細化到單個條款，並延伸至客戶、所依賴的法律、專業知識、電子郵件、截止日期及時間記錄。

你究竟如何構建這張圖譜？

公司許多知識存在於人們腦中，他們很少有時間將其輸入圖譜。有些資訊可以從通訊和檔案之間的連結隱式捕捉。其餘資訊能否被抓取，取決於公司已記錄的資料是否已編碼。例如，在律所案件中，我們已經清楚知道對手方是誰以及哪些檔案屬於他們。

我們將其分為四個層級來思考。首先，知識是否隱含於現有資料結構？其次，規則能否擷取？第三，語言模型在哪些地方能補足規則無法建立的連結，包括語意上的？第四，哪些連結最具價值，如何降低成本，以及哪種圖譜結構最適合？每個答案都依賴領域，且需要實驗驗證。

圖譜的大部分已經存在

公司的系統已經存放了大量圖譜資料。實務管理系統知道每個案件的客戶、對手、合夥人和團隊。公司登入資料提供每家公司母公司，時間記錄顯示誰做了什麼以及是否已開票。將這些載入同一位置，使這些連結變得明確且可解析。稀疏搜尋不會立即顯示 Meridian Grid Services 屬於 Halcyon Group，但網路搜尋會。檔案提供了支撐這些標記的細節。

先用規則，再用模型補足缺漏

規則便宜、快速且可預測，且能準確說明為何找到某項資訊，但它們會漏掉未被編寫的內容。模型能閱讀任何文字，但每句都需要付費，且有時會編造資訊。

因此先使用規則。當一句話顯示出規則無法解讀的事實，例如月份缺少可解析的日期或責任限額缺少數字，僅將該句送給小型模型。模型僅被問及圖譜欄位，並將答案儲存，重建時只需為新文字付費。

為了在沒有我們自己起草協助的情況下測試此方法，我們讓另一個模型以六種不同起草風格重寫所有 245 篇檔案，以及五封包含日期的已提交電子郵件。之後，我們以四種方式構建圖譜，並每次評分。

將 141 條被標記的句子送給模型，佔整篇句子的不到 2%，成本不到 5 分，並使判斷與上限問題達到 100%。而讓模型閱讀所有句子則成本高 27 倍，整體表現也不佳。它找到了所有截止日期，但把每月費用 15% 的服務信用當作責任上限；在我們自己的起草中，它錯過了四個規則已發現的截止日期。

混合模式的遺漏有明顯的原因。兩個截止日期出現在掃描式 PDF 的法院命令中，行尾斷行把「by 4pm」留在短編號行的結尾。規則把那一行當作標題，所以其下方的日期缺乏上下文，僅有日期不算作缺口。

建置成本

圖表可從兩種型別的資料來源構建。第一種是純 JSON 檔案：客戶、案件和收費人登入，並將每份檔案作為文字。JSON 具備平臺中立性，任何公司都可以透過從 CRM、實務管理系統或檔案儲存庫匯出來產生，且我們的測試公司就是以此方式到達。第二種是以案件為中心的平臺，例如 Lexifina，該平臺在使用者工作時捕捉相同事實：案件紀錄、上傳檔案、提交至案件的電子郵件以及財務帳簿。無需匯出，但部分閱讀在檔案上傳時完成。流程圖為每種都有一個分頁。

五個問題，含有圖表與不含圖表

為了確認知識圖譜是否對代理人有幫助，我們讓同一個模型在有圖譜與無圖譜的情況下，分別回答同五個問題。代理人能列舉、搜尋並閱讀資料室內的所有檔案。使用知識圖譜時，它還能呼叫七個圖譜工具：搜尋、開啟節點、檢查衝突、追蹤依賴關係、尋找截止日期、比較條款事實以及計算總時間與帳單。

觀看實際代理人執行結果並排比較

每個格子顯示不使用圖譜時的平均值，然後是使用圖譜時的平均值。在模型的標價下，平均執行成本不使用圖譜約為 17 分，使用圖譜約為 2 分。模型在規則缺口上的支出為 5 分，在第一個問題就已自付。將整個上傳閱讀與圖譜一起計算後，大約在 26 個問題後即可收回成本。

不使用圖譜時，代理人仍能正確回答幾乎所有問題。它合理搜尋、閱讀公司登記簿、追蹤引用並統計帳簿，完成此工作所需時間約為四倍，閱讀的標記數量約為十三倍。唯一的準確度差距出現在帳單問題。沒有圖譜的代理人必須手動加總數十份時間帳簿，且在一次執行中錯過了一位未開票時間略超過門檻的客戶。

這未顯示的內容

重新編寫的資料室測試的是起草風格，而非真實資料室所包含的所有內容。在此實驗中，模型重新撰寫措辭但保留所有事實，其檔案為乾淨文本，而非帶有 OCR 錯誤、表格或追蹤變更的掃描檔。敵對性混亂文字也會使未使用圖譜的代理人錯過更多資訊，因此在真實記錄上的準確度差距可能比我們測量的更大，但我們尚未進行測試。

值得嗎？

知識圖譜不是一次性成本。每份新增或變更的檔案都必須重新閱讀，部分句子會送入模型，因此標記成本會隨公司持續運作而持續。軟體中還有物流成本：每個圖譜讀取的系統需要一個介面卡、維護規則，以及在記錄變更時重新構建的儲存與快取。每一次重建都需要計算時間，圖譜與已儲存的模型答案也需要儲存空間。

因此，我們不斷問自己的問題是：這是否值得。像上述那樣的並排比較檢索資料，若不與每種方法的執行成本（短期與長期）做權衡，意義不大。我們發現，比起把圖譜視為新範式，兩個更簡單的問題更有用：我們的代理人如何最大化利用公司已擁有的結構化資料？以及還剩下哪些結構，既足夠便宜又足夠有用，能夠與語言模型建立或結合？

條款元資料，在此房間約 $3.10，佔模型支出的主要部分，屬於以案件為中心的平臺。圖譜並未讀取它。因此問題是它是否應該被讀取，以及條款元資料是否值得為圖譜計算。我們對兩個版本的房間執行了 Lexifina 的條款元資料步驟，保持不變。我們將其欄位對映到圖譜上：其引用變為引用案例、立法和專業知識，其生效日期以及觸發與到期條件中的日期變為日期，並根據條款型別和條件判斷其型別。接著我們僅使用元資料構建圖譜，並將元資料加入規則後再次構建。

僅靠條款元資料，對於圖譜而言是一個不佳的來源。它沒有負責任上限數額的欄位，因此未找到十個上限中的任何一個。它在兩個版本的房間中均找到 13 個截止日期中的 7 個，因為其日期是生效日期和條件，而非截止日期，且未在電子郵件上執行。加入規則後，它在缺口上表現與模型通過相當。對於重新起草的房間，它恢復了法庭截止日期，該截止日期亦被 gap pass 找到，以及兩個掃描法院命令中的一個，gap pass 未捕捉到，但未能恢復 gap pass 找到的兩個上限。成本為 $3.15 對比 5 分。

因此我們不會為圖譜計算條款元資料。若已為審查和搜尋計算，將其合併不會額外成本，且捕捉到 gap pass 遺漏的一個截止日期。但對於該截止日期的更佳解決方案是更廣泛的標記規則，讓沒有上下文的單獨日期也能送到模型。

連帶應用

圖譜在發生變更時最為有用。若上訴法院偏離早期決定，公司需要知道其哪些活檔案依賴該早期決定。依賴關係很少直接。條款可能引用早期案例，或引用後續遵循或適用該案例的案例，或說明它遵循公司自身通知的先例，而先例的起草備註才是依賴該案例的實際依據。我們將這些邊標記為依賴關係，並從案例向後遍歷：通過遵循該案例的案例、引用該案例的專業知識以及遵循該專業知識的條款，進而到條款、其檔案、其事務以及負責的合夥人。

對於偏離早期案例的判決，遍歷亦從早期案例開始，因為那是公司工作所依據的法律。

Lexifina 沒有引用器，故只能檢視檔案引用哪些案例，無法判斷後續案例是否跟隨或偏離哪個案例。缺少這些連結時，上述新判決問題只能找到其 14 件事務中的 10 件。

原始主張在 LocalLLaMA 上