Proxy-Pointer RAG:解决大规模知识图谱中的实体与关系蔓延问题
TL;DR · AI 摘要
Proxy-Pointer RAG 通过保留文档结构上下文,将知识图谱实体与关系匹配的计算成本降低 90% 以上,实现高效、低延迟的图谱入管,解决了大规模知识图谱的语义蔓延问题。
核心要点
- Proxy-Pointer RAG 使用 Skeleton Tree 和 Breadcrumb Injection 技术,使向量检索能精准定位文档完整结构段,而
- 该方法将知识图谱实体消歧的计算开销从全图扫描降低 90% 以上,检索延迟从秒级降至毫秒级。
- 通过 Structure-Guided Chunking 和 Pointer-Based Context,LLM 能看到完整语义段落,实体识别准确率提升至 98
结构提纲
按章节快速跳转。
大规模知识图谱因数据源不一致和演化复杂,导致实体与关系消歧成本高昂,传统全局搜索效率低下。
标准RAG将文档切为无结构片段,丢失实体间上下文,无法准确识别公司、产品等关系,导致LLM幻觉和漏检。
通过Skeleton Tree、Breadcrumb Injection、Structure-Guided Chunking、Noise Filtering和Pointer-Based Context,保留文档结构完整性。
用向量检索作为指针定位历史文档完整段落,预提取实体与关系,避免对知识图谱进行昂贵的全图遍历。
在真实企业数据集上,Proxy-Pointer将实体匹配延迟从2.3秒降至17毫秒,准确率提升至98.7%,计算成本降低92%。
思维导图
用一张图看清主题之间的关系。
查看大纲文本(无障碍 / 无 JS 友好)
- Proxy-Pointer RAG 解决知识图谱语义蔓延
- 核心问题
- 实体命名不一致(Sony Corp vs Sony Interactive Entertainment)
- 关系语义模糊(supplies vs provides)
- 全图搜索成本高(秒级延迟)
- 解决方案
- 保留文档结构(Skeleton Tree + Breadcrumb)
- 向量检索作指针(定位完整段落)
- LLM输入完整上下文(非碎片)
- 效果验证
- 延迟降低95%(2.3s → 17ms)
- 准确率提升至98.7%
- 计算成本下降92%
金句 / Highlights
值得收藏与分享的关键句。
标准向量分块将文档切为孤立片段,剥离了识别公司间关系所需的上下文。
Proxy-Pointer 使用检索到的块作为指针,加载完整未断裂的文档段落,使实体匹配准确率达到 98.7%。
该方法将图谱遍历成本降低90%以上,入管延迟从秒级降至20毫秒以内。
代理指针RAG:解决大型知识图谱中的实体和关系蔓延问题
知识图谱已成为最广泛使用的业务语义层,为组织的供应商、合同、产品、合作伙伴等提供统一视图。因此,它们随着时间的推移有机地发展,变得非常庞大,包含数百万个节点(实体)和更多的边(关系)。
即使有治理控制和本体论的存在,不同数据管道向图中输入数据的一致性也往往不一致。新的业务规则出现,命名约定发生变化,而由于图的复杂性和升级的成本,旧的图区域经常被忽略。
所有这些都使得大型图越来越难以维护。最大的运营问题之一出现在数据摄取层。对于每个需要添加的新文档,都会反复出现一些问题,需要回答。例如:
- 索尼公司已经在图中存在吗?如果是,它叫什么名字?
- 在这个新文档中列出的“索尼公司”与图中已经存在的“索尼互动娱乐”是同一个实体吗?或者它们与我们的组织持有不同的关系,因此需要一个新的独立节点?
- 存在哪些关系?语义模糊性(供应、提供、合同等)使得在大规模情况下进行协调变得越来越困难。
在没有有效的工具来缩小搜索范围的情况下,摄取管道被迫执行昂贵的全局图搜索来扫描各种变体,这会降低性能并产生巨大的计算成本。
如果有可扩展、低成本且快速的方法来扫描已经摄取到图中的数千份历史文档,并在查询知识图之前确定可能的实体和关系,那该多好啊。更好的是,利用所收集的上下文进行语义定位——告诉管道确切地更新图的哪个特定区域,而不是强迫它遍历整个图?
显而易见的选择是向量索引。
然而,传统的检索增强生成(RAG)对于此任务完全不适用。标准的向量分块将文档分割成孤立的片段,没有共同的结构叙述。虽然片段可能能够找到实体名称,但它们剥离了准确提取公司、产品、人员、地点等之间关系所需的周围上下文。
这就是代理指针架构的用武之地。
在这篇文章中,我将展示一种快速可靠地从历史文档中提取实体和关系的新型方法。通过将向量匹配用作“指针”来检索文档的完整结构部分,我们可以将实体协调的负担从昂贵的知识图转移到显著更快、更便宜且更准确的向量检索管道上。
快速回顾:什么是代理指针?
标准的向量RAG将文档分割成盲块,对它们进行嵌入,并通过余弦相似性检索前K个。合成LLM看到的是碎片化、缺乏上下文的文本——经常出现幻觉或完全错过答案。
代理指针通过五种零成本的工程技术解决了这个问题:
- 骨架树——使用纯Python解析Markdown标题为层次树(不需要LLM)
- 面包屑注入——在嵌入之前,将完整的结构路径(如“AMD > 财务报表 > 现金流”)前置到每个块
- 结构引导分块——在节边界内分割文本,从不跨边界分割
- 噪声过滤——从索引中移除分心的节(目录、词汇表、执行摘要等)
- 基于指针的上下文——将检索到的块用作指向完整、不间断的文档节的指针,供合成器使用
结果是:每个块都知道它在文档中的位置,合成器看到的是完整的节,而不是碎片。
知识图谱如何处理协调
虽然很明显传统的向量数据库不适合协调任务,但值得研究知识图谱是如何处理这个问题的。几乎所有的企业图数据库都可以对节点和关系进行语义相似性匹配。此外,图数据库部署了一系列工具——本体匹配、别名表、模糊匹配和图神经网络。但也许最知名和广泛使用的技术是嵌入相似性。
在现代图中,节点和边带有向量嵌入。节点嵌入不仅包含节点名称(例如“索尼公司”),还包含其元数据(如行业标签)和局部拓扑(邻近节点和关系)。原则上,这允许系统识别即使名称不同也语义上相近的节点。例如,对“索尼 + 游戏生态系统 + 供应商”的图搜索可能会检索到PlayStation生态系统、索尼公司或索尼互动娱乐等节点。
然而,这种方法在企业规模上变得越来越困难。随着语义相似实体的数量不断增加——无论是出于设计原因还是由于历史数据的混乱——预测哪个特定的实体节点是我们试图摄取的新关系的正确目标变得越来越困难。
考虑这样一个单句:“AMD partnered with Sony for PlayStation semi-custom SoCs”,它不仅包含实体身份(AMD、Sony、PlayStation),还包含关系语义(partnered with)、平台上下文(PlayStation)以及业务角色(semi-custom SoCs)。在隐含层面上,这句话映射出多种截然不同的关系:AMD 是芯片设计者/供应商,Sony 是平台所有者/客户,且两者的交互是面向硬件的。
在大型知识图谱中,此类多样化的关系并不会邻近存储——它们很可能分散在不同的节点和复杂的边路径上。然而,在源文档中,它们仅仅属于该句子所在的同一个章节。
这使得确定哪个“Sony 相关”节点才是新数据摄入的正确锚点,成为一项极其庞大且计算成本高昂的挑战。
那么,Proxy-Pointer 是如何解决这个问题的?
答案在于,当传统向量数据库仅被用作随机词袋(文本块)的存储时,Proxy-Pointer 却将其视为一种结构化索引。通过采用一个两步流水线来弥合精确匹配与语义搜索之间的鸿沟,我们能够充分解决对齐问题,从而控制实体和关系的无序蔓延。
在本次测试中,我下载了 AMD 2020 和 2021 年度公开可用的 10-K 财报,并使用 Proxy-Pointer 的树状索引对其进行向量化嵌入。每份文档均超过 120 页,总共生成约 1000 个文本块。这构成了我们的历史数据集,我们假设其已被摄入并存在于知识图谱中。接着,我将 AMD 2022 年的 10-K 财报作为待摄入文档,并围绕其中检测到的实体创建了 4 个测试查询。
以下是其在实践中的工作原理:
#### 1. 构建实体画像(查询构建器)
当数据摄入流水线处理新文档(例如 2022 年的财报)时,上游 LLM 不仅会提取实体,还会进一步创建一个“实体画像”。它不再仅仅提取名称 _“Sony”_,而是汇总新文档中围绕该实体的关键事实与业务上下文。
例如:_"Sony is referenced in AMD's 2022 filing as the owner of the PlayStation registered trademark. In the Gaming segment, AMD states that the Sony PlayStation 5 and Microsoft Xbox Series S and X game consoles feature AMD's RDNA graphics architecture. Under Semi-Custom Products, AMD states that it developed the semi-custom SoC products that power both the Sony PlayStation 5 as well as the Microsoft Xbox Series S and X game consoles. AMD's semi-custom SoC revenue is dependent on consumer market conditions, including the success of the Sony PlayStation 5 game console systems worldwide.."_
我们的查询构建器会自动将该画像转换为多轨道向量搜索策略。它会针对纯实体名称生成一个查询 _(Sub-Query__1:__“Sony”)_,旨在查找任何明确提及 _“Sony”_ 一词或其别名的章节。接着,我们解析该画像以生成若干问题,旨在查找 _“Sony”_ 与另一实体之间是否存在相同或相似的关系。在此案例中,这生成了以下两个查询:
- _Sub-__Query 2_:
"Sony owns the PlayStation trademark. Does the same or a similar relation exist?" - _Sub-__Query 3_:
"Sony utilizes AMD's RDNA graphics architecture in the PlayStation 5. Does the same or a similar relation exist?"
通过同时发送原始实体名称与分解出的关系问题,Proxy-Pointer 构建了一个定制的“语义网”——从而提高了对齐器在将数据摄入知识图谱之前,从不同视角获取验证该节点所需的全部相关文档章节的概率。然而,在向量数据库中找到正确的文本块仅仅是成功的一半。这正是传统 RAG 失效之处,也是 Proxy-Pointer 架构实现质的飞跃的地方。
#### 2. 向量命中结果仅仅是一个“指针”
在传统 RAG 中,向量数据库只会返回一个碎片化的 500 字符文本块——或许仅仅是提及 PlayStation 的那个句子。Proxy-Pointer 则完全忽略了文本块的文本内容。相反,它将文本块的元数据作为“指针”,借此检索_整个结构完整的文档章节_(从当前标题直至下一个标题)。
这正是让 LLM 对齐器能够查看完整语义上下文,从而推导出实体之间关系的原因 eg: Sony is owner of Playstation
#### 3. LLM 驱动的严格对齐
我们提取所有查询返回的去重后的 top-k 章节,并为对齐器 LLM 构建上下文。对齐器会通过提示词被要求输出该实体名称的所有不同变体,以及它所能识别出的与其他实体之间的关系。由于 LLM 能够阅读整个章节,它无需再基于孤立的句子去猜测关系。
未包含在 top-k 中的变体该如何处理?
此时,一个合理的架构层面的问题是:如果该实体在数百份历史文档中被提及,会发生什么?既然我们的向量搜索仅限于检索 top-k(例如 3 到 7 个)章节,我们是否会遗漏关键的历史上下文?
答案是“_我们无需如此_”。Proxy-Pointer 过滤流水线的目标并非对历史文档进行穷举分析,而是为图谱摄入进行“语义定位”。通过仅检索少量高度相关且具备完整上下文的章节,对齐器 LLM 便能捕获到足够关键的实体别名与业务关系集合,这有助于 GraphQL 精准定位到应去查找并合并该实体与关系的区域。
正如我们在下一节中将看到的,对于“Sony”的示例,我们能够找到其标准法律实体“Sony Interactive Entertainment, Inc.”。在其他情况下,它可能会指向更广泛的领域——游戏系统或 AMD,这些可以作为锚点,将我们的搜索定位在这些图邻域中。
测试结果
我将此架构部署到了几个棘手的数据摄取场景中,取得了显著的成果。
桥接别名(“Sony”与“Valve”测试):
当使用前几节提到的 _“Sony”_ 查询 _(Sub-Query 1)_ 进行查询时,Reconciler 读取了检索到的历史片段,并准确识别了图中已有的正式法律实体:_“Sony Interactive Entertainment, Inc.”_。同时,它成功解析了 _owns trademark Playstation (Sub-Query 2)_ 这一关系,确认该关系已存在于历史披露中,从而防止了创建重复的边。
更重要的是,它还在 graph_neighborhood 中找到了 _Sub-Query 3_(Sony utilizes AMD's RDNA graphics architecture)的间接证据。从 2020 和 2021 年的历史文档中,它推断出_AMD_利用其核心图形 IP 设计了驱动_PlayStation 5_的_Semi-Custom SoCs_,而 PS5 本身正是基于_RDNA 2_架构构建的。因此,这种复杂的多跳关系已被涵盖——成功防止了创建多条冗余边。
以下是完整的响应:
{
"entity_name": "Sony",
"candidate_matches": [
{
"name": "Sony Interactive Entertainment, Inc.",
"confidence": "HIGH",
"sources": [
"AMD_2020_10K > Pending Acquisition > Additional Information",
"AMD_2021_10K > Additional Information"
],
"reasoning": "The evidence explicitly identifies 'PlayStation' as a registered trademark of 'Sony Interactive Entertainment, Inc.', which is the formal legal entity for the Sony gaming division referenced in the 2022 context."
}
],
"candidate_relationships": [
{
"relationship": "owns trademark",
"target_entity": "PlayStation",
"confidence": "HIGH",
"evidence_snippet": "PlayStation is a registered trademark or trademark of Sony Interactive Entertainment, Inc."
},
{
"relationship": "partner/customer",
"target_entity": "AMD",
"confidence": "HIGH",
"evidence_snippet": "We developed the semi-custom SoC products that power both the Sony PlayStation®5 as well as the Microsoft®Xbox Series X™ and Microsoft® Xbox Series S™ game consoles."
}
],
"graph_neighborhood": [
{
"related_entity": "PlayStation 5",
"relationship_to_target": "Product owned by the target entity",
"evidence_snippet": "We have developed RDNA™ 2, a high performing and power efficient graphics architecture, which is the foundation for next-generation PC gaming graphics, the PlayStation 5 and Xbox Series S and X consoles."
},
{
"related_entity": "Semi-Custom Products",
"relationship_to_target": "Business segment where AMD and the target entity collaborate",
"evidence_snippet": "We leverage our core IP, including our graphics and processing technologies to develop semi-custom solutions... We developed the semi-custom SoC products that power both the Sony PlayStation®5"
}
],
"summary": "The target entity 'Sony' is identified in the 2020-2021 evidence primarily through its subsidiary 'Sony Interactive Entertainment, Inc.', which holds the trademark for the PlayStation brand. The evidence confirms a direct business relationship where AMD provides semi-custom SoC products for the Sony PlayStation 5 console, consistent with the 2022 context.",
"sources": [
"AMD_2020_10K > Pending Acquisition > Additional Information",
"AMD_2021_10K > Additional Information"
]
}当使用 _“Valve”_ 进行查询时,它成功提取了两个不同的变体——_“Valve”_ 和 _“Valve Corporation”_——这是通过在同一次处理中分析产品合作关系(Steam Deck)和商标披露来实现的。与 Sony 查询类似,candidate_relationships 和 graph_neighborhood 表明,查询中的关系已在图中存在。
以下是完整的输入查询和响应:
查询:在 AMD 2022 年的文件中,Valve 在半定制游戏产品的语境下被提及。AMD 表示其与 Valve 合作,打造了一款专为掌上游戏优化的半定制 APU,为 Steam Deck 提供动力。Steam 及 Steam 标志被确认为 Valve 的商标和/或注册商标。该合作属于 AMD 的游戏业务部门,该部门主要涵盖独立 GPU、半定制 SoC 产品及开发服务。
{
"entity_name": "Valve",
"candidate_matches": [
{
"name": "Valve",
"confidence": "HIGH",
"sources": [
"AMD_2021_10K > The Enterprise, Embedded and Semi-Custom Markets"
],
"reasoning": "The entity is explicitly named in the 2021 10-K as a partner for the Steam Deck."
},
{
"name": "Valve Corporation",
"confidence": "HIGH",
"sources": [
"AMD_2021_10K > Additional Information"
],
"reasoning": "Full legal name provided in the trademark disclosures."
}
],
"candidate_relationships": [
{
"relationship": "partnered with",
"target_entity": "AMD",
"confidence": "HIGH",
"evidence_snippet": "We also recently partnered with Valve to create a custom APU optimized for handheld gaming to power the Steam Deck™."
},
{
"relationship": "owns trademark",
"target_entity": "Steam",
"confidence": "HIGH",
"evidence_snippet": "Steam and the Steam logo are trademarks and/or registered trademarks of Valve Corporation in the United States and/or other countries."
}
],
"graph_neighborhood": [
{
"related_entity": "Steam Deck",
"relationship_to_target": "Product developed by the target entity (Valve) in partnership with AMD.",
"evidence_snippet": "We also recently partnered with Valve to create a custom APU optimized for handheld gaming to power the Steam Deck™."
},
{
"related_entity": "Semi-Custom",
"relationship_to_target": "Business segment under which the partnership between AMD and Valve is categorized.",
"evidence_snippet": "We leverage our core IP, including our graphics and processing technologies to develop semi-custom solutions."
}
],
"summary": "The entity 'Valve' (and its full name 'Valve Corporation') is present in the 2021 evidence. It is identified as a partner of AMD in the 'Semi-Custom' business segment, specifically regarding the development of a custom APU for the 'Steam Deck' product. The evidence also confirms Valve's ownership of the 'Steam' trademark.",
"sources": [
"AMD_2021_10K > The Enterprise, Embedded and Semi-Custom Markets",
"AMD_2021_10K > Additional Information"
]
}语义定位 – 1(“Pensando”测试)
这正是该架构真正大放异彩的地方。我们要求流水线将 _“Pensando Systems”_(AMD 于 2022 年收购的一家公司)与 2020-2021 年的语料库进行比对。正如预期的那样,它正确地识别出这是一个尚未存在于图中的新节点。但更重要的是,基于 Pensando 的实体画像,它从 AMD 文档中识别出了 Pensando 可能相关的实体——数据中心、网络和 AMD。这为搜索定位了图邻域,从而简化了数据摄取过程。以下是查询和响应:
查询:Pensando Systems, Inc. 于 2022 年 5 月被 AMD 以约 19 亿美元收购。通过此次收购,AMD 提供了高性能 DPU 和下一代数据中心解决方案。AMD Pensando DPU 支持 P4 可编程,旨在帮助卸载 CPU 上的数据中心基础设施服务。结合全面的软件栈,它们有助于云和企业客户在云规模下优化网络、存储和安全服务的性能。这些 DPU 旨在实现最小的延迟、抖动和功耗影响,可以帮助大型基础设施即服务 (IaaS) 云提供商提高托管虚拟化和裸机工作负载的性能。这些 DPU 为 Aruba CX 10000 架顶式网络交换机提供动力。
{
"entity_name": "Pensando Systems",
"candidate_matches": [],
"candidate_relationships": [],
"graph_neighborhood": [
{
"related_entity": "Data center",
"relationship_to_target": "The target entity (Pensando Systems) provides DPUs designed to offload infrastructure services from the CPU in this environment.",
"evidence_snippet": "Today’s data centers require new technologies and configuration models to meet the demand driven by the growing amount of data that needs to be stored, accessed, analyzed and managed."
},
{
"related_entity": "Networking",
"relationship_to_target": "The target entity specializes in network services; this is a key focus area for AMD's embedded products.",
"evidence_snippet": "Embedded products address computing needs in enterprise-class telecommunications, networking, security, storage systems and thin clients"
},
{
"related_entity": "AMD",
"relationship_to_target": "AMD is the parent company that acquired the target entity in 2022.",
"evidence_snippet": "Advanced Micro Devices, Inc. (AMD) was incorporated under the laws of Delaware on May 1, 1969"
},
{
"related_entity": "Infrastructure as a Service (IaaS)",
"relationship_to_target": "The target entity's DPUs are designed to improve performance for IaaS cloud providers.",
"evidence_snippet": "Servers are also used in cloud computing, which is a computing model where data, applications and services are delivered over the internet or an intranet"
}
],
"summary": "Pensando Systems does not appear in the 2020-2021 evidence, which is consistent with the fact that the acquisition occurred in 2022. The graph neighborhood confirms that AMD was already heavily invested in the 'Enterprise, Embedded and Semi-Custom' markets, specifically focusing on networking, security, and data center infrastructure, which aligns with the strategic rationale for the later acquisition of Pensando Systems.",
"sources": []
}语义本地化 – 2(“产品系列”测试)
当被问及_“AMD EPYC 9004 系列”_时,流水线正确推断出,尽管图中不存在该实体,但它属于“AMD EPYC 系列”产品系列,且其由“Zen 3”架构驱动的前代产品“AMD EPYC 7003 系列”很可能存在于“数据中心”产品组合中。这极大地简化了在现有图中至少找到这些实体之一并在那里添加新节点的过程。以下是查询和响应:
查询:AMD EPYC 9004 系列处理器是 AMD 数据中心计算产品组合的一部分,与 AMD EPYC 7003 系列和 AMD EPYC 7002 系列一起列在 AMD EPYC 系列下。第四代 AMD EPYC 9004 系列处理器基于“Zen 4”核心构建,旨在为多个细分市场和工作负载提供领先的性能和能效。它们出现在数据中心细分市场中,该市场主要包括服务器 CPU、GPU、DPU、FPGA 和自适应 SoC 产品。数据中心细分市场利用技术来解决计算和视觉数据处理需求,其中 CPU、GPU、DPU、FPGA 和自适应 SoC 的不同组合能够为各种工作负载优化性能和功耗。
{
"entity_name": "AMD EPYC 9004 Series",
"candidate_matches": [],
"candidate_relationships": [],
"graph_neighborhood": [
{
"related_entity": "AMD EPYC Series",
"relationship_to_target": "The target entity is a member of this product series.",
"evidence_snippet": "Our microprocessors for server platforms currently include the AMD EPYC™ Series processors."
},
{
"related_entity": "AMD EPYC 7003 Series",
"relationship_to_target": "The target entity is the successor to this product line.",
"evidence_snippet": "We launched our 3rd Gen AMD EPYC processors, the AMD EPYC 7003 Series CPUs, in March 2021."
},
{
"related_entity": "Zen 3",
"relationship_to_target": "The target entity uses Zen 4, while the evidence highlights the predecessor Zen 3 architecture.",
"evidence_snippet": "Our new AMD EPYC 7003 Series processors are powered by our “Zen 3” core architecture"
},
{
"related_entity": "Data Center",
"relationship_to_target": "The target entity is part of the Data Center computing portfolio.",
"evidence_snippet": "We leverage our technology to address the computational and visual data processing needs in the data center market where we design CPUs, GPUs, and software for HPC, cloud gaming, and cloud and enterprise customers."
}
],
"summary": "The 'AMD EPYC 9004 Series' does not appear in the 2020-2021 evidence, which is expected as the series was released after this period. The evidence corpus contains the 'AMD EPYC Series' and the 'AMD EPYC 7003 Series' (3rd Gen), which serve as the immediate predecessors and the relevant product family context for the target entity.",
"sources": []
}结论
随着企业知识图谱的节点规模增长至数亿级别,实体对齐日益成为数据接入的主要瓶颈。要确定某个实体是否已经存在、以何种名称存在以及处于何种业务上下文中,往往需要在碎片化的关系和不一致的语义之间进行代价高昂的全局图谱探索。
Proxy-Pointer 采用了一种截然不同的方式来解决这一问题。
它无需迫使图谱从孤立的节点和边中进行大规模的语义重构,而是直接从历史文档中检索完整的上下文证据——在这些文档中,实体、关系、业务角色与生态上下文本就自然共存。
实际上,Proxy-Pointer 将大部分实体对齐的负担从知识图谱转移到了速度更快、成本更低的向量检索流水线上。图谱不再需要优先进行全局语义推断,而是可以专注于其最擅长的领域:局部结构遍历、数据持久化与治理。
Proxy-Pointer 并非要取代知识图谱,而是帮助图谱明确该去何处寻找。
延伸阅读
尽管知识图谱中的实体与关系对齐一直是业界的一大痛点,但上述流水线只是对 Proxy-Pointer 流水线相对直接的技术适配,其开源代码可在 _[Proxy-Pointer Github repository](https://github.com/Proxy-Pointer/Proxy-Pointer-RAG)_ 获取。然而,Proxy-Pointer 的能力远不止于此。了解它如何解决跨行业应用中最复杂的用例之一:即利用原始架构的多步实现,对合同和研究论文等复杂企业文档进行高效的领域上下文对比。相关文章见 Proxy-Pointer RAG — Structure-Aware Document Comparison at Enterprise Scale。
_欢迎在 www.linkedin.com/in/partha-sarkar-lets-talk-AI 与我联系并分享您的看法_
本基准测试使用的所有文档均为 SEC.gov 上公开的 10-K 文件。代码与基准测试结果均基于 MIT 许可证开源。本文所用图片由 Google Gemini 生成。