譯者 | 朱先忠

審校 | 重樓

本文介紹一種從零開始構建多源知識圖譜提取器的方法，涵蓋數據采集與清洗、多模態信息抽取、知識融合、圖數據庫存儲及動態更新等核心技術，并給出通過NLP技術實現跨數據源知識整合的結構化表示。

簡介

知識圖譜是表示復雜且相互關聯的信息的強大解決方案。它們將數據建模為由實體（節點）和關系（邊）連接的圖形，從而能夠表示和處理不同事實之間的聯系。

雖然知識圖譜早已應用于搜索和推薦應用，但是最近隨著RAG應用的廣泛采用，人們對知識圖譜的興趣也隨之激增。事實上，GraphRAG是一種在生成之前從知識圖譜中檢索內容以增強大型語言模型上下文的技術，它有助于提升RAG系統的性能。

原始RAG系統依賴于密集向量存儲，利用語義相似性來檢索信息。因此，它們在實體消歧、多跳問答以及整合分散在多個來源的數據方面存在困難。GraphRAG利用知識圖譜增強了檢索過程，從而能夠改進上下文理解，捕捉不同實體之間的關系，并整合來自多個來源的信息。

雖然將信息構建成知識圖譜具有諸多優勢，但是從大型數據池中創建知識圖譜的過程往往因高昂的成本和資源需求而受阻。直到最近，構建知識圖譜仍然需要大量的人工注釋、領域專業知識和復雜的流程；因此，只有預算充足的大型組織才能實現。幸運的是，大型語言模型功能的快速發展，使得自動化知識圖譜創建過程成為可能，其成本和時間僅為人工注釋的一小部分。

雖然LLM自動提取的知識圖譜質量可能低于專業人工注釋者提取的知識圖譜，但當需要以有限的預算構建大量數據時，它們可能是唯一的選擇。畢竟，在很多情況下，一個不完美但足夠完善且內容豐富的知識圖譜往往比沒有知識圖譜要好。例如，在GraphRAG應用中，知識圖譜被用作檢索相關上下文的支持工具。事實上，下游的LLM仍然可以忽略不相關的信息，最終生成答案所需的細節可以直接從原始來源獲取。

當前，已經存在幾種方法可以使用大型語言模型（LLM）自動化構建知識圖譜，每種方法在成本和質量方面都有一些權衡，具體取決于領域和需要結構化的文本數據的特定特征。其中，一種流行的架構模式是使用由提取和聚合階段組成的多步驟流水線。提取階段利用LLM提取形式為（主體、關系、客體）的關系三元組，并可選地指定實體（主體和客體）和關系類型。聚合階段側重于統一提取的實體和關系，因為大型語言模型可以提取具有文本變體的相同實體和關系。例如，在同一個知識圖譜中，指代瑪麗·居里的實體可以同時提取為“瑪麗·居里”和“瑪麗·莎樂美·居里”。

當從多個來源提取信息或使用新信息擴展現有知識圖譜時，實體消歧變得更加重要：在這些情況下，來源本身可能指具有不同術語的相同底層實體和關系，和/或可以使用與現有知識圖譜中已有的不同的術語。

能夠在提取過程中將非常長的或者多個源保存在其上下文中的長上下文模型可能有助于緩解此問題，但它們仍然會遇到一些限制。事實上，盡管最近在長上下文檢索和大海撈針任務方面取得了進展，但LLM的性能往往會在非常長的上下文中下降，尤其是在復雜任務中。此外，能夠處理百萬個詞長的上下文的模型通常支持更小的輸出長度，這可能不足以容納從非常長的上下文中提取的所有關系（除非這些關系在原始源中非常稀疏）。即使情況并非如此，該模型仍然可以提取名稱略有變化的相同實體，尤其是在原始源中存在這些實體的情況下。

此外，僅僅依靠長上下文并不能解決擴展現有知識圖譜的問題，因為提取這些實體的原始源可能并不總是可用；即使可用，仍然需要從頭開始提取整個知識圖譜，這可能會帶來額外的成本。另一個需要考慮的點是，從較小的塊中提取關系可以更好地在原始源中定位關系。這些額外的信息在處理RAG應用程序時特別有用，它允許僅將源中最有意義的部分納入上下文，從而提高LLM的性能，并方便人工評估和驗證生成的答案。

在本文中，我將闡述如何創建一個簡單易懂的代理工作流實現，以便從多個源提取和擴展一致的知識圖譜。該工作流由兩個階段組成：提取和構建。在提取階段，LLM從文本塊中執行（主語、關系、賓語）三元組的基本提取。在構建階段，LLM檢查在提取階段提取的每個關系三元組，并將其逐步添加到正在構建的知識圖譜中。在此過程中，LLM可以決定丟棄知識圖譜中已包含信息的冗余三元組，或者優化三元組以更好地與現有關系對齊。例如，如果某個實體已經以不同的名稱包含在知識圖譜中，則模型可以修改要添加的新三元組的實體名稱，以保持一致性并確保鏈接。

我已經在這個GitHub代碼倉庫上分享了完整的示例工程源代碼，你可以在這個Colab Notebook中使用工作流程。

工作流程

在本節中，我將描述上述架構及其工作流程的主要方面。具體細節我將留給共享GitHub倉庫中的代碼。

為了應對從不同輸入文檔構建一致知識圖譜的挑戰，該流程分為兩個主要階段：提取和構建。這是通過一個協調提取器和構建器LLM的單一代理工作流來實現的。我使用“工作流”一詞，沿用了Anthropic官網博客文章《構建高效代理》中引入的術語，指的是一個受控的代理系統，其行為受預定代碼路徑的約束。

工作流程的架構如下：

代理工作流程的高級架構視圖（圖片來自作者本人）

提取階段

首先，將文檔拆分成更小的文本塊。塊的大小可以根據源文檔中的信息密度進行調整，以滿足知識圖譜其他下游任務的需求。例如，如果知識圖譜稍后用于檢索Graph RAG應用程序的上下文，則應針對此任務優化塊大小。實際上，這些塊將鏈接到提取的關系，以便稍后進行檢索。

每個塊通過大型語言模型進行處理，以提取以下形式的三元組：

(subject: entity_type, relation, object: entity_type)

大型語言模型可以直接選擇實體類型，但在我進行的測試中，如果預先為模型提供需要提取的實體類型，提取質量會顯著提升。這也有助于引導提取過程專注于所需信息。值得注意的是，這三個元素是有向的：第一個元素是關系的主語，最后一個元素是賓語，這與英語中常見的主謂賓結構相符。最終的知識圖譜將以有向圖的形式整合這些信息。

我對Extractor模型使用的提示如下：

You are an expert assistant automatizing knowledge graph creation from text. You are provided a text passage and some allowed entity types: you are tasked with extracting relations between entities of the specified type from the provided passage.
Guidelines:
- Provide your output in triplets (entity1:type1, relation, entity2:type2)
- Only extract triplets involving entities of the types specified by the user, don't extract triplets involving entities of other types.
- Don't produce duplicated triplets
- Don't extract properties or attributes as entities
- Entity names should be concise and contain all the necessary information to uniquely identify the entity
- Keep entity names consistent: the same entity should have the same name in all the triplets it appears in
- Write only the extracted triplets and nothing else

Here are some notional examples:
---
<user>{user_instruction} Gold is a chemical element with the chemical symbol Au (from Latin aurum) and atomic number 79. In its pure form, it is a bright, slightly orange-yellow, dense, soft, malleable, and ductile metal. Chemically, gold is a transition metal, a group 11 element, and one of the noble metals. In 2023, the world's largest gold producer was China, followed by Russia and Australia.
{allowed_types_prompt} 'CHEMICAL', 'COUNTRY'</user>
<assistant>(Gold:CHEMICAL, is a, chemical element:CHEMICAL), (Gold:CHEMICAL, chemical symbol, Au:CHEMICAL), (Gold:CHEMICAL, is one of, transition metals:CHEMICAL), (Gold:CHEMICAL, is one of, noble metals:CHEMICAL), (Gold:CHEMICAL, used in, Jewelry: APPLICATION), (China:COUNTRY, largest producer of, GOLD: CHEMICAL), (Russia: COUNTRY, second-largest producer of, Gold: CHEMICAL), (Australia: COUNTRY, third-largest producer of, Gold:CHEMICAL) </assistant>
---
<user>{user_instruction} The lion (Panthera leo) is a large cat of the genus Panthera, native to Africa and India. It is sexually dimorphic; adult male lions are larger than females and have a prominent mane.
{allowed_types_prompt} 'ANIMAL', 'LOCATION'</user>
<assistant>(lion:ANIMAL, scientific name, Panthera leo:ANIMAL), (lion:ANIMAL, belongs to, genus Panthera:ANIMAL), (lion:ANIMAL, native to, Africa:LOCATION), (lion:ANIMAL, native to, India:LOCATION), (male lion:ANIMAL, larger than, female lion:ANIMAL)</assistant>
---

大型語言模型（LLM）在其答案中列出了關系三元組。我們使用基于正則表達式的解析器從文本中提取它們。接下來，對它們進行驗證，以確保它們符合所需的格式，并且僅包含允許的實體類型。格式錯誤或類型與允許值不同的三元組將被丟棄。

構建階段

在構建階段，對提取階段提取的三元組進行評估，并按順序集成到知識圖譜中。對于每個候選三元組，LLM決定：

• 該關系是否需要添加到知識圖譜中。如果它傳達的信息已經存在，則會被丟棄；
• 是否修改三元組內容，包括實體名稱和類型，以確保與現有關系的一致性。

為了做出這一決定，LLM需要獲得一組已提取的與待檢查三元組最相似的三元組。雖然長上下文模型可能能夠在其上下文中容納整個知識圖譜，但僅提供最相似的關系可以簡化LLM的任務，并降低成本。

為了簡單起見，在代碼實現中，我使用了三元組文本的神經嵌入之間的相似性進行檢索。這并非工作流程的固有部分，可以用最適合所研究問題的檢索方法替代。更具體地說，考慮到圖結構的檢索技術很可能會產生更好的結果，尤其是在稠密的圖中或存在許多高階節點的情況下。然而，這超出了本文的范圍。

我用來添加三元組并構建知識圖譜的提示如下：

You are an expert assistant helping to expand a knowledge graph with new information. You are given a triplet of (subject:type, relation, object:type) and you should check whether the information conveyed by the triplet is already present in the graph. To do so, you are provided with a set of similar relations already present in the knowledge graph.
Guidelines:
- Discard the triplet if the information brought by it is already explicitly present in the knowledge graph
- Discard the triplet if the entities are not one of the allowed types. Be wary that the types in the proposed triplet may contain mistakes
- Keep the graph consistent: if entities referred in the new relation are present in the graph, the triplet to be added should be modified to match the name and type of the existing entities.

Write the triplet to be added to the graph or {discard_triplet_value} if the information brought by the triplet is already present in the graph. Share very brief thoughts before giving your answer.
Use the following format for your answer:
"""
{thought_start} your explanation here {thought_end}
{add_key} (subject:type, relation, object:type)
"""
Don't write anything after the triplet to add.

Here are some notional examples:
---
Similar extracted relations:
(Maria Salomea Sk?odowska-Curie:person, known as, Marie Curie:person)
(Marie Curie:person, nationality, Polish:nationality)
(Marie Curie: person, spouse, Pierre Curie:person)
Allowed entity types: 'person', 'nationality'
Proposed relation: (Marie Curie:person, full name, Maria Salomea Sk?odowska-Curie:person)
{thought_start}The information is already present in the graph as (Maria Salomea Sk?odowska-Curie:person, known as, Marie Curie:person), the triplet should not be added.{thought_end}
{add_key} {discard_triplet_value}
---
Similar extracted relations:
(Marie Curie:person, discovered, polonium:chemical)
(Marie Curie:person, award, Nobel Prize in Chemistry:prize)
(Marie Curie:person, award, Nobel Prize in Physics:prize)
Allowed entity types: 'person', 'chemical', 'prize'
Proposed relation: (Maria Salomea Sk?odowska-Curie: person, discovery, radium:chemical)
{thought_start} The relation is not present in the graph, it should be added to the graph. The subject "Maria Salomea Sk?odowska-Curie" is already present in the graph as "Marie Curie" with type 'person', I will modify the triplet accordingly.{thought_end}
{add_key} (Marie Curie:person, discovered, radium:chemical)
---

最后，知識圖譜中包含的每個關系都會鏈接到提取該關系的原始段落。這對于GraphRAG等其他應用非常有用，這些應用受益于將語義搜索與圖搜索相結合，以及/或者受益于在上下文中接收原始文本。

示例

在本節中，我將使用本文描述的工作流程來展示一些示例。所有示例均使用gemini-2.0-flash作為LLM引擎生成，因為它提供了良好的理解能力、長上下文支持以及豐富的免費實驗層級。我嘗試了各種可以在免費Colab筆記本上運行的“小型”開源模型，但結果并不令人滿意，執行時間成為了瓶頸。

這些示例的源文本是通過維基百科Python包獲取的維基百科頁面摘要。知識圖譜的可視化表示是使用networkx包創建的。

為了保持可視化效果清晰，我僅從每個示例的兩到三個摘要中提取了少量實體類型。

示例1

讓我們從一個簡單的示例開始，看看該工作流是否能夠正確捕捉實體之間的關聯關系。讓我們將同一集團旗下各公司之間的關系可視化。以下知識圖譜是從維基百科頁面“Facebook”、“Instagram”和“WhatsApp”的摘要中提取的，提取了“公司”和“個人”類型的實體。

從維基百科頁面“Facebook”、“Instagram”和“Whatsapp”的摘要中提取的知識圖譜（圖片由作者本人提供）

該工作流程識別了關鍵的公司間聯系。此外，我們可以看到知識圖譜在整合不存在于同一文檔中的實體之間的間接關系方面的有效性。借助于networkx，我們可以輕松提取知識圖譜連通組件中任意兩個實體之間的最短無向路徑。例如，包含Mike Krieger的節點與代表Mark Zuckerberg的節點通過以下關系關聯：

('mike krieger', 'launched', 'instagram'),
 ('facebook', 'acquired', 'instagram'),
 ('mark zuckerberg', 'created', 'facebook')

示例2

接下來，讓我們形象地觀看一下另一個例子，其中的關系是從一些著名的吉卜力工作室電影的維基百科頁面摘要中提取出來的：“哈爾的移動城堡（電影）”、“男孩與蒼鷺”和“千與千尋”。

知識圖譜：從維基百科頁面“哈爾的移動城堡（電影）”、“男孩與蒼鷺”和“千與千尋”的摘要中提取，提取出以下類型的實體：“人物”、“電影”和“公司”。

再次，我們看到了主要實體是如何相互連接的，以及間接關系是如何在知識圖譜中產生的。

示例3

另一個有趣的例子是考慮不同疾病之間的共同癥狀。例如，這可能有助于獲取具有共同癥狀的所有疾病的列表。

以下知識圖譜是根據維基百科頁面“胸痛”、“呼吸急促”的摘要創建的。

知識圖譜：摘自維基百科頁面“胸痛”、“呼吸急促”（圖片由作者本人提供）

結論

在本文中，我演示了如何創建一個知識圖譜提取器，以維護從多個來源提取的實體之間的一致性。該方法包含一個由兩個階段組成的代理工作流：第一階段提取關系，第二階段將其集成到現有的知識圖譜中。在將關系集成到知識圖譜之前添加額外的驗證步驟，可以提高一致性，并減少不同文檔/段落之間提取格式沖突。

與所有基于LLM的工作流程一樣，該方法受到底層模型的功能和局限性的約束。例如，幻覺可能會導致知識圖譜中包含虛構的關系，或者模型可能無法正確識別指向同一實體的兩個不同名稱的節點，從而導致無法糾正的實體重復。

所提出的工作流結構的另一個固有限制是無法修改先前集成到知識圖譜中的三元組。隨著知識圖譜規模的擴大，這對于信息的整合和細化可能至關重要。解決這個問題的一個可能方案是使用修訂機制擴展工作流，使其能夠在構建階段修改現有的三元組。

需要考慮的一個因素是，與單步知識圖譜提取器相比，該工作流程的成本有所增加。事實上，在構建階段，必須先評估每個新提取的關系，然后再將其添加到圖譜中，這會顯著增加計算量/API調用量。因此，評估質量的相對提升是否值得相應的成本增加至關重要。不過，總成本仍然只是人工標注的一小部分。

最后，對于下游應用，值得強調的是，所討論的工作流程將知識圖譜中的關系與提取這些關系的原始文檔/段落關聯起來。這對于像GraphRAG這樣受益于擴展上下文的應用非常有用，同時也使人工評估和校正更加容易。事實上，自動提取技術（例如本文討論的技術）的全部功能在與人工監督相結合時才能充分發揮：LLM可以承擔分析海量文本信息的重任，而人工監督者可以確保事實的正確性并優化提取結果。

隨著大型語言模型性能的不斷提高和成本的不斷降低，自動化知識圖譜創建將變得越來越普遍，從大量非結構化文本數據中釋放出更多價值。

譯者介紹

朱先忠，51CTO社區編輯，51CTO專家博客、講師，濰坊一所高校計算機教師，自由編程界老兵一枚。

原文標題：How To Build a Multi-Source Knowledge Graph Extractor from Scratch，作者：Gabriele Sgroi