本章内容包括：
- 结构化数据提取
- 不同的数据提取方法
本章将探讨如何利用大型语言模型（LLM）从无结构数据源（如文本文件）构建知识图谱的过程。重点是讲解LLM如何从原始文本中提取并结构化数据，将其转化为构建知识图谱的可用格式。
在前面的章节中，你已经学习了文档拆分、向量嵌入和检索的基础技术（第2章），以及提升检索准确率的高级方法（第3章）。但正如第4章所述，仅依赖文本嵌入在需要结构化数据以支持过滤、计数或聚合等操作时，往往面临挑战。为解决仅用文本嵌入的局限，本章将介绍如何利用LLM将无结构数据自动转成适合知识图谱构建的结构化格式。通过本章学习，你将掌握如何从原始文本中提取结构化信息、设计相应的知识图谱模型，并将数据导入图数据库。
你将从法律文档检索中的一个常见难题入手——管理多份合同及其条款，并了解结构化数据提取如何提供解决方案。全章将通过示例引导你一步步完成从无结构文本构建知识图谱的工作流。
6.1 从文本中提取结构化数据
网络上和企业内部大量信息以无结构形式存在，如各类文档。然而，单纯用文本嵌入检索技术常常难以满足需求。法律文档即是一个典型例子。
例如，当你想查询与ACME公司的合同付款条款时，必须确保条款确实来源于该合同，而非其他合同。若仅对多份法律文档进行拆分和检索，检索结果中的前k个片段可能分别来自不同且无关的文档，造成混淆，如图6.1所示。
图6.1展示了合同文档如何被拆分成文本片段，并通过文本嵌入进行索引。当终端用户提出特定问题（例如关于某份合同的付款条款）时，系统会检索出最相关的文本片段。然而，如果多份合同包含不同的付款条款，检索过程可能会无意中从多个文档中抽取信息，将目标合同中的相关片段与其他合同中的无关片段混合在一起。这是因为系统侧重于根据相似度排名检索文本片段，但并不总能区分这些片段是否来源于正确的合同。因此，包含“payment”（付款）或“terms”（条款）等关键词但属于不同合同的片段可能会被一并检索，导致条款信息呈现支离破碎且不一致。这种混淆会让LLM在尝试将这些混杂片段综合成连贯答案时产生困难，从而增加生成不准确或误导性信息的风险。
另外，考虑这样一个问题：“我们目前与ACME公司有多少份有效合同？”要回答该问题，首先需要基于合同的有效状态进行筛选，然后对相关合同进行计数。这类查询类似于传统的商业智能问题，单纯使用文本嵌入方法难以胜任。
文本嵌入主要用于检索语义相似的内容，不擅长执行诸如筛选、排序或数据聚合等操作。处理这些操作需要结构化数据，仅靠文本嵌入难以满足要求。
对于某些领域来说，构建结构化数据对于实现RAG应用至关重要。幸运的是，LLM在从文本中提取结构化数据方面表现优异，因其对自然语言的深刻理解能够准确识别相关信息。通过微调或设计特定提示，LLM能够定位并抽取所需数据点，将无结构信息转化为表格或键值对等结构化格式。利用LLM进行结构化数据提取尤其适合处理大量文档，否则手动识别和整理将非常耗时且劳动密集。自动化提取使企业能将无结构信息转变为可操作的结构化数据，进而用于更深入的分析或RAG应用。
假设你是某公司的软件工程师，隶属于一个团队，负责开发一个基于公司法律文档回答问题的聊天机器人。鉴于项目规模庞大，团队被划分为两个小组：一组负责数据准备，另一组负责实现第4章和第5章描述的检索系统。你被分配到数据准备组，负责处理法律文档并提取结构化信息。所提取的信息将用于构建知识图谱，整个工作流程如图6.2所示。
图6.2所示的工作流程从合同文档作为输入开始，使用大型语言模型（LLM）对其进行处理以提取结构化信息。在法律领域，可以提取涉及的各方、日期、条款等各种细节信息。这里，结构化的输出以JSON格式表示，随后将这些结构化信息存储到Neo4j中，作为法律聊天机器人数据检索的基础。
这两个例子突出了简单文本嵌入在处理特定结构化查询时的局限性，比如查询合同中的付款条款或统计有效协议数量。在这两种情况下，准确的答案都需要结构化数据，而不能仅仅依赖非结构化文本的语义相似度。在本章剩余部分，我们将深入探讨如何有效利用LLM从复杂文档中提取结构化数据，以及这些结构化输出在构建可靠知识图谱以支持高级检索任务中的关键作用。要跟随实践，你需要访问一个正在运行且为空的Neo4j实例，可以是本地安装也可以是云端，只需确保实例为空。你可以直接参考这里提供的Jupyter笔记本实现：github.com/tomasonjo/k…。
我们开始吧。
6.1.1 结构化输出模型定义
从文本中提取结构化数据并非新概念；多年来一直是数据处理中的重要任务。传统上，这一过程称为信息提取，通常需要复杂的系统，依赖多个机器学习模型协同工作。这些系统通常构建和维护成本高昂，需要一支由技术工程师和领域专家组成的团队确保其正常运行。由于成本和技术门槛，仅有资源丰富的大型组织能够负担这样的解决方案。高昂的费用和技术壁垒让许多企业和个人望而却步。
然而，LLM的发展极大简化了这一过程。如今，用户可以通过给LLM下达提示，低门槛地提取结构化信息，而不必自行构建和训练多个模型。这一转变为结构化数据提取开辟了广泛的应用场景。
利用LLM提取结构化数据已成为常见用例，OpenAI为简化和标准化这一过程，在API中引入了结构化输出（Structured Outputs）功能。该功能允许开发者预先定义期望的输出格式，确保模型响应符合特定结构。结构化输出并非独立库，而是OpenAI API内置能力，可通过函数调用或模式(schema)定义使用。例如，在Python中，开发者常用Pydantic库定义数据模式，然后将其传递给模型，指导模型产生符合指定格式的输出，如下代码所示。
示例 6.1 用Pydantic定义期望输出
from pydantic import BaseModel
class CalendarEvent(BaseModel):
name: str
date: str = Field(..., description="事件日期，格式为 yyyy-MM-dd")
participants: list[str]
示例6.1中的CalendarEvent类以结构化方式捕捉事件详情，包括事件名称、日期和参与者列表。通过显式定义这些属性，确保事件数据符合该结构，便于可靠且一致地提取和处理事件信息。支持的属性类型包括：
- 字符串（String）
- 数字（Number）
- 布尔（Boolean）
- 整数（Integer）
- 对象（Object）
- 数组（Array）
- 枚举（Enum）
- anyOf（多种类型之一）
下面看date属性的定义。
示例 6.2 date属性定义
date: str = Field(..., description="事件日期，格式为 yyyy-MM-dd")
示例6.2代码为提取日期属性提供了说明。属性名为date，提示模型聚焦日期相关信息。类型为str，表明提取内容应为字符串，因为没有内置的日期时间类型。描述中明确期望的日期格式为yyyy-MM-dd，这一步很重要，虽然类型是字符串，但描述引导模型输出符合特定格式。仅靠str类型可能无法完整表达预期格式。
结构化输出功能极大简化了开发流程，确保LLM响应符合预定义的模式(schema)，减少后期处理和验证工作，帮助开发者专注于系统中数据的使用。该功能提供类型安全，保证响应格式正确，且无需复杂提示即可获得稳定一致的输出，从而提升效率和可靠性。
提取法律文档中结构化输出的第一步，是定义需要提取的合同数据模型。作为软件工程师，你不是法律专家，因此需要咨询领域专家确定哪些信息最重要。此外，与终端用户沟通他们关心的具体问题，也能带来有价值的洞见。
经过初步讨论后，你提出了如下合同数据模型。
示例 6.3 用Pydantic定义合同数据模型
class Contract(BaseModel):
"""
代表合同的关键细节。
"""
contract_type: str = Field(
...,
description="合同类型。",
enum=contract_types,
)
parties: List[Organization] = Field(
...,
description="合同涉及的各方及其角色详情。",
)
effective_date: str = Field(
...,
description="合同生效日期，格式为 yyyy-MM-dd。",
)
term: str = Field(
...,
description="协议期限，包括续约或终止条款。",
)
contract_scope: str = Field(
...,
description="合同范围描述，包括权利、义务及限制。",
)
end_date: Optional[str] = Field(
...,
description="合同终止日期，格式为 yyyy-MM-dd。",
)
total_amount: Optional[float] = Field(
..., description="合同总金额。"
)
governing_law: Optional[Location] = Field(
..., description="合同适用的法律辖区。"
)
- #1：类的描述，说明这是合同关键细节。
- #2：通过枚举(enum)限定合同类型可选值。
- #3：属性可以是自定义对象，比如
Organization。 - #4：由于无日期类型，明确规定日期格式。
- #5：使用
Optional标记非必需属性。
类名Contract和简短的文档字符串为LLM提供了高层次语义，指导模型聚焦提取合同类型、涉及方、日期及财务等核心信息。
一般来说，属性分为必需和可选。可选属性用Optional标记，表示信息可能缺失，避免模型为填补空白而“幻想”数据。例如，total_amount为可选，因为有些合同无金额交换；effective_date则为必需，预期每份合同都有生效日期。
注意每个属性都有描述字段，确保LLM准确提取期望信息。即使某些属性看似明显，描述也是良好实践。部分属性还可以通过enum指定允许的值，比如contract_type属性定义了合同类型的枚举值，示例如下。
示例 6.4 合同类型枚举值
contract_types = [
"Service Agreement",
"Licensing Agreement",
"Non-Disclosure Agreement (NDA)",
"Partnership Agreement",
"Lease Agreement"
]
显然，这个列表不是详尽无遗的，还可包括更多类型。
某些属性较复杂，可定义为自定义对象。例如，parties是Organization对象的列表。使用列表是因为合同通常涉及多方，自定义对象允许提取更丰富的结构化信息。以下定义了Organization对象。
示例 6.5 自定义Organization对象
class Organization(BaseModel):
"""
代表一个组织，包括名称和所在地。
"""
name: str = Field(..., description="组织名称。")
location: Location = Field(..., description="组织主要所在地。")
role: str = Field(
...,
description="组织在合同中的角色，例如‘provider’、‘client’、‘supplier’等。"
)
Organization类捕获组织名称、主要位置和角色。位置是嵌套的Location对象，便于将地址结构化为城市、省份和国家等。通常建议避免过深嵌套以提升性能。角色属性提供了示例值，但未使用枚举，避免限制值范围，保证灵活性，因为角色可能多样且不可预测。如此定义有助于LLM提取更详细、结构化的参与方信息。
最后，需要定义Location对象。
示例 6.6 自定义Location对象
class Location(BaseModel):
"""
代表物理位置，包括地址、城市、省份和国家。
"""
address: Optional[str] = Field(..., description="街道地址。")
city: Optional[str] = Field(..., description="所在城市。")
state: Optional[str] = Field(..., description="所在州或省。")
country: str = Field(..., description="所在国家，使用两字母ISO标准。")
Location对象表示物理地址，包含街道、城市、省份和国家信息。除country外，其他属性均为可选，允许部分或不完整地址。对country属性，明确要求使用两字母ISO标准，便于模型输出统一标准化的国家代码，方便跨系统处理。
至此，你已经定义了合同数据模型，用于指导LLM提取公司合同中的相关信息。该模型将作为结构化数据提取的蓝图。理解了数据结构后，接下来将探讨如何有效设计提示语以驱动LLM提取这些信息。
6.1.2 结构化输出的提取请求
在定义好合同数据模型后，你已经拥有了一个LLM可以遵循的数据定义来提取结构化信息。下一步是确保LLM准确理解如何以一致的格式输出这些数据。这时就用到了OpenAI的结构化输出（Structured Outputs）功能。通过使用该功能，你可以引导LLM的行为，严格按照合同模型输出数据，同时仍然使用前几章介绍的聊天模板。
结构化输出的官方文档（mng.bz/oZZp）中提到，可以使用系统消息（system message）进一步指导LLM聚焦当前任务。通过使用系统消息，如下面示例所示，你可以提供明确指令，有效地引导模型行为。
示例 6.7 用于结构化输出提取的系统消息
system_message = """
You are an expert in extracting structured information from legal documents and contracts.
Identify key details such as parties involved, dates, terms, obligations, and legal definitions.
Present the extracted information in a clear, structured format. Be concise, focusing on essential
legal content and ignoring unnecessary boilerplate language. The extracted data will be used to address
any questions that may arise regarding the contracts."""
为系统消息设计精准指令较为困难，但明确的是你应定义领域背景，并向LLM说明输出内容的用途。除此之外，往往需要反复试验调整。
最后，你定义了一个函数，接收任意文本输入，输出符合合同数据模型的字典。
示例 6.8 结构化输出提取函数
def extract(document, model="gpt-4o-2024-08-06", temperature=0):
response = client.beta.chat.completions.parse(
model=model,
temperature=temperature,
messages=[
{"role": "system", "content": system_message}, #1
{"role": "user", "content": document}, #2
],
response_format=Contract, #3
)
return json.loads(response.choices[0].message.content)
- #1：将系统消息作为首条消息传入；
- #2：将文档原文作为用户消息传入，无额外指令；
- #3：通过
response_format参数定义输出格式。
示例6.8中的extract函数处理文本文档，并根据合同数据模型返回字典。它使用了撰写时最新的支持结构化输出的GPT-4o模型。函数先发送系统消息引导LLM，再传入未经修改的用户文档文本。模型的响应按Contract数据模型格式化，最终以字典形式返回。
为了展示此流程的实际效果，接下来我们将使用真实世界的数据集进行演示。由于受限于保密性，获取专有合同数据较为困难，故这里采用一个公开数据集——Contract Understanding Atticus Dataset（CUAD）。
6.1.3 CUAD 数据集
虽然所有公司都有合同和法律文件，但由于其所含信息的敏感性，这些文档通常不公开。为了演示目的，我们将使用来自CUAD数据集（Hendrycks 等，2021）的一份文本文件。CUAD是一个专门为训练AI模型理解和审查法律合同而创建的语料库。
下面的示例展示了一个改进版本的代码。该合同文本可在本书配套的GitHub仓库中获取，无需下载整个数据集。代码负责打开文件并读取其内容。
示例 6.9 读取合同文本文件
with open('../data/license_agreement.txt', 'r') as file:
contents = file.read() #1
- #1：读取文件内容
你现在可以通过执行下面的代码来处理该合同文本。
示例 6.10 从文本中提取结构化信息
data = extract(contents)
print(data)
提取结果类似于以下内容。
示例 6.11 提取结果示例
{
'contract_type': 'Licensing Agreement',
'parties': [
{
'name': 'Mortgage Logic.com, Inc.',
'location': {
'address': 'Two Venture Plaza, 2 Venture',
'city': 'Irvine',
'state': 'California',
'country': 'US'
},
'role': 'Client'
},
{
'name': 'TrueLink, Inc.',
'location': {
'address': '3026 South Higuera',
'city': 'San Luis Obispo',
'state': 'California',
'country': 'US'
},
'role': 'Provider'
}
],
'effective_date': '1999-02-26',
'term': "1 year, with automatic renewal for successive one-year periods unless terminated with 30 days' notice prior to the end of the term.",
'contract_scope': "TrueLink grants Mortgage Logic.com a nonexclusive license to use the Interface for origination, underwriting, processing, and funding of consumer finance receivables. TrueLink will provide hosting services, including storage, response time management, bandwidth, availability, access to usage statistics, backups, internet connection, and domain name assistance. TrueLink will also provide support services and transmit credit data as permitted under applicable agreements and laws.",
'end_date': None,
'total_amount': None,
'governing_law': {
'address': None,
'city': None,
'state': 'California',
'country': 'US'
}
}
提取出的合同数据被组织成结构化字段，但并非所有属性都有完整内容。例如，end_date和total_amount字段为None，表示信息缺失或未说明。同时，contract_scope属性包含了更详细的描述性文本，阐述了协议的具体运作细节，如所提供的服务和双方责任。结构中清晰地划分了涉及方、各自的角色和所在地。合同还指定了生效日期和续约条件，但其他财务或终止细节因合同中缺失而未定义。
练习 6.1
下载CUAD数据集，尝试基于不同合同类型创建多种合同数据模型。定义好不同模型后，可以通过分析它们对合同中关键法律信息的捕捉和分类效果，进行测试和优化。
本节中，你成功使用CUAD数据集和之前定义的合同数据模型，从合同文档中提取了结构化数据。LLM被引导识别关键合同细节，且结果以结构化形式呈现，帮助你整理合同类型、参与方、条款等重要信息。该过程展示了LLM如何高效地将非结构化法律文档转化为可用数据。
接下来一节，将聚焦于如何将这些数据整合进知识图谱中。
6.2 构建知识图谱
作为本章的最后一步，你将把提取的结构化输出导入到Neo4j中。这遵循了导入结构化数据的标准流程。首先，你需要设计一个合适的图模型，用来表示数据中的实体及其关系。图模型设计超出了本书的范围，但你可以借助LLM来辅助定义图模式(schema)，或者参考其他学习资料，如Neo4j Graph Academy。
合同图模型的示例如图6.3所示，该模型将在本步骤中使用。该图模型代表一个合同系统，包含三个主要实体：Contract（合同）、Organization（组织）和Location（地点）。Contract节点存储合同的ID、类型、生效日期、期限、总金额、适用法律和合同范围等详细信息。
组织通过HAS_PARTY关系与合同相连，每个组织又通过HAS_LOCATION关系关联到一个Location节点，后者记录组织的地址、城市、省份和国家。之所以将地点单独作为节点，是考虑到同一组织可能拥有多个地址。
定义好图模型后，下一步便是开始构建知识图谱的过程。该过程包含若干关键步骤，以下小节将逐一讲解。首先，你需要定义唯一约束和索引，以保证数据完整性并提升性能。然后，利用Cypher语句将结构化合同数据导入Neo4j。数据加载完成后，通过图形可视化确认所有实体和关系均正确表示。最后，我们将讨论重要的数据优化工作，如实体消歧（确保同一真实实体的不同表现形式被正确合并），并简要介绍如何在图谱中同时处理结构化和非结构化数据。
6.2.1 数据导入
在适用的地方定义唯一约束和索引是一项最佳实践，因为它不仅保证了图谱的数据完整性，还能提升查询性能。下面代码示例定义了Contract、Organization和Location节点的唯一约束。
示例 6.12 定义唯一约束
neo4j_driver.execute_query(
"CREATE CONSTRAINT IF NOT EXISTS FOR (c:Contract) REQUIRE c.id IS UNIQUE;"
)
neo4j_driver.execute_query(
"CREATE CONSTRAINT IF NOT EXISTS FOR (o:Organization) REQUIRE o.name IS UNIQUE;"
)
neo4j_driver.execute_query(
"CREATE CONSTRAINT IF NOT EXISTS FOR (l:Location) REQUIRE l.fullAddress IS UNIQUE;"
)
接下来，需要准备一个导入用的Cypher语句，将字典格式的数据加载进Neo4j，遵循图6.3中描述的图模型。导入语句示例如下。
示例 6.13 定义导入用的Cypher语句
import_query = """WITH $data AS contract_data
MERGE (contract:Contract {id: randomUUID()}) #1
SET contract += {
contract_type: contract_data.contract_type,
effective_date: contract_data.effective_date,
term: contract_data.term,
contract_scope: contract_data.contract_scope,
end_date: contract_data.end_date,
total_amount: contract_data.total_amount,
governing_law: contract_data.governing_law.state + ' ' +
contract_data.governing_law.country
}
WITH contract, contract_data
UNWIND contract_data.parties AS party #2
MERGE (p:Organization {name: party.name})
MERGE (loc:Location {
fullAddress: party.location.address + ' ' +
party.location.city + ' ' +
party.location.state + ' ' +
party.location.country})
SET loc += {
address: party.location.address,
city: party.location.city,
state: party.location.state,
country: party.location.country
}
MERGE (p)-[:LOCATED_AT]->(loc) #3
MERGE (p)-[r:HAS_PARTY]->(contract) #4
SET r.role = party.role
"""
- #1：使用
randomUUID()为合同节点创建一个唯一标识符； - #2：创建参与方节点及其地址节点；
- #3：将参与方与其地址关联；
- #4：将参与方与合同节点关联。
对示例6.13中的Cypher语句进行详解超出了本书范围，但如果需要，LLM可以帮助你更好地理解这些语句。需要特别注意的是，由于合同ID使用了randomUUID()，该查询语句并非幂等，多次执行会在数据库中创建多个具有不同ID的合同节点，造成重复。
准备就绪后，可以执行下面代码将合同数据导入Neo4j。
示例 6.14 将合同数据导入Neo4j
neo4j_driver.execute_query(import_query, data=data)
导入成功后，你可以打开Neo4j浏览器探索生成的图谱，其结构应与图6.4所示的可视化结果非常相似。
图6.4所示的可视化展示了一个图谱，其中中心节点是“Licensing Agreement”（代表一份合同），该节点通过HAS_PARTY关系连接到两个组织：“Mortgage Logic.com, Inc.” 和 “TrueLink, Inc.”。每个组织又通过LOCATED_AT关系连接到代表其所在地的“US”节点。
6.2.2 实体消歧
虽然你已经成功导入了图谱，但工作还未结束。在大多数情况下，尤其是涉及自然语言处理或LLM驱动的数据处理时，数据清洗是必不可少的步骤。其中最关键的一步就是实体消歧（Entity Resolution）。
实体消歧是指在数据集或知识图谱中识别并合并代表同一真实世界实体的不同表现形式的过程。处理大规模且多样化的数据时，同一实体往往会以多种形式出现，这可能由于拼写差异、命名惯例不同，甚至数据格式上的细微差别等原因导致。
如图6.5所示，图中有三个节点分别代表同一实体的不同变体。三个名称分别是：
- UTI Asset Management Company
- UTI Asset Management Company Limited
- UTI Asset Management Company Ltd
在此背景下，实体消歧的任务是识别所有这些不同的变体其实都指向同一个真实存在的组织，尽管名称中存在细微差别（比如“Limited”与“Ltd”）。实体消歧的目标是将这些不同的引用统一为图谱中的单一且连贯的节点。这不仅提升了数据的完整性，也增强了图谱在推断关系和建立连接时的准确性。
实体消歧常用的技术包括字符串匹配、聚类算法，甚至利用每个实体周围上下文的机器学习方法来检测和解决重复问题。
需要特别注意的是，实体消歧高度依赖具体的用例和领域。通用的一刀切方案很少奏效，因为不同领域有各自的命名惯例、数据模式及实体表现细节。例如，在金融数据集中，适用于机构名称消歧的方法和阈值，可能在医疗领域处理生物实体时效果不佳。因此，最有效的策略之一是开发反映你数据特定上下文的领域本体（ontology）或规则。
此外，借助领域专家定义匹配标准，结合迭代反馈机制（对潜在匹配进行验证或修正），可以显著提升准确率。通过将领域知识与上下文感知的机器学习或聚类技术结合，你能够构建更加稳健且灵活的实体消歧方案，确保捕捉到你数据环境中最关键的细节。
6.2.3 向图谱添加非结构化数据
知识图谱越来越多地用于存储结构化和非结构化数据，随着大型语言模型（LLM）的出现，这种场景愈加普遍。在此语境下，LLM可用于从非结构化来源（如文本文件）中提取结构化数据。
然而，将原始非结构化文档及提取出的结构化数据同时存储在图谱中，可以既保留原始数据的丰富信息，又支持对提取信息的更精确查询与分析。图6.6展示了一个结合结构化和非结构化信息的扩展图谱模式。
在将非结构化数据纳入图谱时，常用的一种简单策略是基于令牌数量或词长将文本切分成可管理的片段。虽然这种朴素的切分方法适用于一般场景，但某些领域（如法律合同）则更适合使用更专业的切分方式。例如，按照合同条款来切分文本，可以保留其语义结构，提升后续分析的质量。这种更智能的切分方式使得图谱能够捕获更有意义的关系，从而带来更丰富的洞察和更精准的推断。
本章引导你使用LLM从非结构化数据构建知识图谱。你了解了文本嵌入在处理结构化查询时的局限，学习了结构化数据提取如何解决这一问题。通过定义数据模型、引导LLM提取信息、并将结果导入图数据库，你见证了如何将原始文本转化为可用的知识图谱数据。此外，我们还涵盖了关键任务，如实体消歧及结构化与非结构化数据的结合，帮助获得更丰富的洞见。掌握了这些知识，你现在可以在实际场景中应用结构化数据提取。
总结
- 单纯切分文档用于检索，尤其是在法律文档等对文档边界敏感的领域，可能导致结果不准确或混乱。
- 检索任务如过滤、排序和聚合需要结构化数据，单靠文本嵌入难以胜任。
- LLM能有效从非结构化文本中提取结构化数据，转化为表格或键值对等可用格式。
- LLM的结构化输出功能允许开发者定义数据模式(schema)，保证响应遵循特定格式，减少后处理工作。
- 明确定义包含合同类型、各方、日期等属性的数据模型，是指导LLM准确提取相关信息的关键。
- 知识图谱中的实体消歧对于合并同一实体的不同表现形式非常重要，能提升数据一致性和准确性。
- 在知识图谱中结合结构化与非结构化数据，既保留了源数据的丰富性，又支持更精准的查询。
