譯者 | 朱先忠

審校 | 重樓

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

簡介

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

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

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

雖然將信息構(gòu)建成知識圖譜具有諸多優(yōu)勢，但是從大型數(shù)據(jù)池中創(chuàng)建知識圖譜的過程往往因高昂的成本和資源需求而受阻。直到最近，構(gòu)建知識圖譜仍然需要大量的人工注釋、領(lǐng)域?qū)I(yè)知識和復雜的流程；因此，只有預算充足的大型組織才能實現(xiàn)。幸運的是，大型語言模型功能的快速發(fā)展，使得自動化知識圖譜創(chuàng)建過程成為可能，其成本和時間僅為人工注釋的一小部分。

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

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

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

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

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

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

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

工作流程

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

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

工作流程的架構(gòu)如下：

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

提取階段

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

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

(subject: entity_type, relation, object: entity_type)

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

我對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）在其答案中列出了關(guān)系三元組。我們使用基于正則表達式的解析器從文本中提取它們。接下來，對它們進行驗證，以確保它們符合所需的格式，并且僅包含允許的實體類型。格式錯誤或類型與允許值不同的三元組將被丟棄。

構(gòu)建階段

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

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

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

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

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

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)
---

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

示例

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

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

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

示例1

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

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

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

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

示例2

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

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

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

示例3

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

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

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

結(jié)論

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

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

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

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

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

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

譯者介紹

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

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