Graphs have emerged as the go-to business semantic layer, offering a consolidated view of an organization’s suppliers, contracts, products, partners, and more. Over time, they grow organically, expanding to include millions of nodes (entities) and significantly more edges (relationships).
Even with governance controls and ontologies in place, consistency across different data pipelines feeding into the graph is often lacking. New business rules are introduced, naming conventions evolve, and older sections of the graph are frequently left unchanged due to the immense complexity and high computational cost of updating them.
All these factors make maintaining a large graph increasingly challenging. One of the most significant operational hurdles arises at the ingestion layer. For every new document to be added, several recurring questions need answers, such as:
- Does Sony Corp already exist in the graph? If so, under what name?
- Is the “Sony Corp” mentioned in this new document the same entity as “Sony Interactive Entertainment” already in the graph? Or do they have different relationships with our organization, necessitating a separate, new node?
- What relationships are already present? Semantic ambiguities (e.g., supplies, provides, is contracted for) make reconciliation increasingly difficult at scale.
Without an effective tool to narrow down the search space, ingestion pipelines are forced to perform costly global graph searches to identify variations, leading to performance degradation and substantial computational expenses.
What if there were a scalable, low-cost, and rapid method to scan thousands of historical documents already ingested into the graph, identifying likely entities and relationships before querying the knowledge graph? Even better, what if the context gathered could be used for semantic localization —
directing the pipeline to the specific region of the graph that needs updating, rather than requiring it to traverse the entire structure?
The obvious choice for this pre-filtering step is a vector index.
However, traditional Retrieval-Augmented Generation (RAG) is entirely unsuitable for this task. Standard vector chunking breaks a document into isolated snippets, lacking a common structural narrative. While chunks might identify an entity name, they lose the surrounding context necessary for accurately extracting relationships between companies, products, persons, places, etc.
This is where the Proxy-Pointer architecture comes into play.
In this article, I will demonstrate a novel approach to quickly and reliably extract entities and relationships from historical documents. By using vector matches as “pointers” to retrieve intact structural sections of a document, we can shift the burden of entity reconciliation away from the expensive Knowledge Graph and onto a significantly faster, cheaper, and more accurate vector retrieval pipeline.
Quick Recap: What is Proxy-Pointer?
Standard vector RAG divides documents into isolated chunks, embeds them, and retrieves the top-K based on cosine similarity. The synthesizer LLM then encounters fragmented, context-free text — often leading to hallucinations or missed answers.
Proxy-Pointer addresses this with five zero-cost engineering techniques:
- Skeleton Tree — Parse Markdown headings into a hierarchical tree (pure Python, no LLM required)
- Breadcrumb Injection — Prepend the full structural path (e.g.,
AMD > Financial Statements > Cash Flows) to every chunk before embedding - Structure-Guided Chunking — Split text within section boundaries, never across them
- Noise Filtering — Remove distracting sections (TOC, glossary, executive summaries) from the index
- Pointer-Based Context — Use retrieved chunks as pointers to load the full, unbroken document section for the synthesizer
The outcome: every chunk understands where it fits within the document, and the synthesizer processes complete sections — not fragments.
How Knowledge Graphs Handle Reconciliation
While it’s clear why traditional vector databases are unsuitable for reconciliation, it’s worth examining how knowledge graphs approach this problem. Most enterprise graph databases can perform semantic similarity matching over nodes and relationships. Additionally, graph databases employ various tools — ontology matching, alias tables, fuzzy matching, and GNNs. However, the most well-known and widely used technique is embedding similarity.
In a modern graph, nodes and edges carry vector embeddings. Node embeddings include not only the node name (e.g., Sony Corp) but also its metadata (tags like industry) and its localized topology (neighborhood nodes and relationships). In principle, this allows the system to identify nodes that are semantically close even when names differ. For example, a graph search for: Sony + gaming ecosystem + supplier might retrieve nodes such as PlayStation ecosystem, Sony Corp, or Sony Interactive Entertainment.
However, this approach becomes increasingly challenging at enterprise scale. As the number of semantically similar entities grows—whether by design or due to messy historical data—it becomes harder to predict which specific entity node is the correct target for the new relationship being ingested.
Consider this single sentence: “AMD partnered with Sony for PlayStation semi-custom SoCs.” It contains entity identity (AMD, Sony, PlayStation) but also relationship semantics (partnered with), platform context (PlayStation), and business role (semi-custom SoCs). Implicitly, this sentence maps to multiple distinct relationships: AMD is the chip designer/supplier, Sony is the platform owner/customer, and the interaction is hardware-oriented.
In a large knowledge graph, such diverse relationships are not stored together — they are likely distributed across several nodes and complex edge paths. Yet in the source document, they are part of just one section where this sentence occurs.
This makes determining which “Sony-related” node is the correct anchor for the new ingestion a massive, computationally expensive challenge.
So, how does Proxy-Pointer solve this?
The answer lies in treating the vector database not as a store for random bag-of-words (chunks), but as a structural index. Using a two-step pipeline that bridges the gap between an exact match and a semantic search, we can address reconciliation effectively enough to control entity and relationship sprawl.
For this test, I downloaded and embedded the publicly available 10-K filings of AMD for 2020 and 2021 using the Proxy-Pointer tree-based indexing.
Each of these documents exceeds 120 pages, resulting in approximately 1,000 text segments in total. This collection serves as our historical dataset, which we assume has already been processed and stored within the knowledge graph. For testing purposes, I selected AMD’s 2022 10-K filing as the new document to ingest and crafted four test queries based on entities identified within it.
Here’s how the system operates in practice:
1. Constructing the Entity Profile (Query Builder)
As the ingestion pipeline processes a new document—such as a 2022 financial filing—an upstream large language model (LLM) extracts not just entity names but also builds a detailed “Entity Profile.” Rather than simply identifying the name “Sony,” the model gathers key facts and business context related to that entity from the new document.
For instance: “In AMD’s 2022 filing, Sony is cited as the owner of the PlayStation trademark. Within the Gaming segment, AMD notes that both the Sony PlayStation 5 and Microsoft Xbox Series S|X consoles incorporate its RDNA graphics architecture. Under Semi-Custom Products, AMD explains that it designed the custom system-on-chip (SoC) solutions powering these consoles. Furthermore, AMD’s semi-custom SoC revenue depends partly on consumer demand for devices like the Sony PlayStation 5.”
Our Query Builder automatically transforms this profile into a multi-pronged vector search strategy. It creates one query focused solely on the entity name (Sub-Query 1: “Sony”) to locate any sections explicitly mentioning “Sony” or related variations. Then, it analyzes the profile to generate targeted questions aimed at uncovering whether similar relationships exist between “Sony” and other entities. This yields the following additional queries:
- Sub-Query 2:
“Sony owns the PlayStation trademark. Is this or a similar relationship present elsewhere?” - Sub-Query 3:
“Sony uses AMD’s RDNA graphics architecture in the PlayStation 5. Does this or a comparable relationship appear in prior data?”
By submitting both the raw entity name and the decomposed relationship questions, Proxy-Pointer constructs a tailored “semantic net”—increasing the likelihood that the Reconciler retrieves all relevant document sections needed to validate the entity from multiple angles before adding it to the Knowledge Graph. However, locating the correct chunks in the vector database is only part of the challenge. This is where conventional RAG systems fall short, and where the Proxy-Pointer architecture excels.
2. The Vector Hit Acts Only as a “Pointer”
In traditional RAG setups, the vector database returns a small, isolated snippet—perhaps just a single sentence referencing PlayStation. Proxy-Pointer disregards the actual text content of the chunk entirely. Instead, it treats the chunk’s metadata as a “pointer” to fetch the complete, structurally preserved document section (from one heading to the next).
This approach enables the LLM Reconciler to grasp the full semantic context required to infer relationships among entities—for example, recognizing that Sony owns the PlayStation trademark.
3. Strict Reconciliation Driven by LLMs
We compile the top-k unique sections returned by all queries and use them as input context for the Reconciler LLM. The Reconciler is instructed to list all known variations of the entity name and identify any relationships with other entities. Because it reads entire sections rather than fragmented sentences, it can accurately deduce connections without relying on guesswork.
What About Mentions Beyond the Top-k Results?
A reasonable architectural concern arises: what if an entity appears across hundreds of historical documents? Since our vector search retrieves only the top-k (e.g., 3 to 7) most relevant sections, could we be missing crucial historical context?
The answer is: we don’t need to capture everything. The purpose of the Proxy-Pointer filtering pipeline isn’t exhaustive historical analysis—it’s “Semantic Localization” for graph ingestion. By retrieving just a few highly relevant, full-context sections, the Reconciler LLM captures enough entity aliases and business relationships to guide the GraphQL engine toward the correct region in the graph for merging or linking.
As demonstrated in the next section, for the “Sony” example, the system successfully identifies the canonical legal entity “Sony Interactive Entertainment, Inc.” In other cases, it may point to broader contextual clusters—such as gaming systems or AMD itself—which act as anchors to narrow the search within relevant graph neighborhoods.
Test Results
I applied this architecture to several complex ingestion scenarios, achieving strong outcomes.
Resolving Aliases (The “Sony” and “Valve” Tests)
When processing the “Sony” query (Sub-Query 1) described earlier, the Reconciler analyzed the retrieved historical sections and correctly matched it to the formal legal entity already present in the graph: “Sony Interactive Entertainment, Inc.”. It also confirmed the owns trademark PlayStation relationship (Sub-Query 2), verifying its existence in prior disclosures and avoiding duplicate edge creation.
Even more significantly, the system uncovered indirect support for Sub-Query 3 (Sony utilizes AMD’s RDNA graphics architecture) by examining the graph_neighborhood. Drawing from 2020 and 2021 documents, it inferred that AMD leverages its core graphics IP to develop Semi-Custom SoCs used in the PlayStation 5, which is built on the RDNA 2 architecture. Thus, this multi-hop relationship was already represented—effectively preventing the addition of redundant edges.
Below is the complete response:
{
"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",Here is the paraphrased version of the provided HTML content:
When asked about "Valve," the system successfully identified two separate forms—"Valve" and "Valve Corporation"—by examining both a product collaboration (the Steam Deck) and a trademark mention in a single run. Like the Sony query, the candidate_relationships and graph_neighborhood show that the connections in the Query are already captured in the graph.
Below are the complete input query and the corresponding response:
Query: Valve is mentioned in AMD's 2022 filing regarding semi-custom gaming products. AMD notes that it worked with Valve to develop a semi-custom APU tailored for handheld gaming to run the Steam Deck. Steam and the Steam logo are listed as trademarks and/or registered trademarks of Valve. This collaboration is part of AMD's Gaming segment, which mainly consists of discrete GPUs, semi-custom SoC products, and development services.
{
"entity_name": "Valve",
"candidate_matches": [
{
"name": "Valve",
"confidence": "HIGH",
"sources": [
"AMD_2021_10K > The Enterprise, Embedded and Semi-Custom Markets"
],
"reasoning": "The entity is directly 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": "The full legal name is given 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 collaboration 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') appears in the 2021 evidence. It is recognized as a partner of AMD in the 'Semi-Custom' business segment, specifically concerning the development of a custom APU for the 'Steam Deck' product. The evidence also verifies Valve's ownership of the 'Steam' trademark.",
"sources": [
"AMD_2021_10K > The Enterprise, Embedded and Semi-Custom Markets",
"AMD_2021_10K > Additional Information"
]
}
Semantic Localization – 1 (The "Pensando" Test)
This is where the architecture truly excels. We requested the pipeline to reconcile "Pensando Systems" (a company AMD acquired in 2022) against the 2020-2021 corpus. As anticipated, it correctly determined that this is a new node not yet present in the graph. But more importantly, based on the Pensando entity profile, it identified entities from AMD documents — Data center, Networking, and AMD — to which Pensando is likely related. This localizes the graph neighborhood for search, thereby streamlining the ingestion process. Here are the query and response:
Query: Pensando Systems, Inc. was acquired by AMD in May 2022 for approximately $1.9 billion. Through this acquisition, AMD provides high-performance DPUs and next-generation data center solutions. The AMD Pensando DPUs are P4 programmable and designed to help offload data center infrastructure services from the CPU. Combined with a comprehensive software stack, they help enable cloud and enterprise customers to optimize performance for network, storage, and security services at cloud scale. The DPUs are engineered for minimal latency, jitter, and power impact, and can help large Infrastructure as a Service (IaaS) cloud providers improve hosted virtualized and bare-metal workload performance. The DPUs power the Aruba CX 10000 top-of-rack network switch.
{
"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
Semantic Localization – 2 (The "Product Family" Test)
When queried about "AMD EPYC 9004 Series", the system accurately deduced that while this specific model isn't in the graph, it belongs to the broader "AMD EPYC Series" family and succeeds the "AMD EPYC 7003 Series"—which is based on the "Zen 3" architecture—and is likely housed within the "Data Center" product lineup. This makes it far easier to locate at least one related entity in the current graph and insert the new node in the right place. Below are the query and its corresponding response:
Query: AMD EPYC 9004 Series processors are part of AMD's data center computing portfolio, listed under the AMD EPYC Series alongside the AMD EPYC 7003 Series and AMD EPYC 7002 Series. The 4th Gen AMD EPYC 9004 Series processors are built on the "Zen 4" core and are designed to deliver leadership performance and energy efficiency across multiple market segments and workloads. They appear in the Data Center segment, which primarily includes server CPUs, GPUs, DPUs, FPGAs, and Adaptive SoC products. The Data Center segment leverages technology to address computational and visual data processing needs, where different combinations of CPUs, GPUs, DPUs, FPGAs, and Adaptive SoCs enable the optimization of performance and power for a diverse set of workloads.
{
"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": []
}
Conclusion
As enterprise knowledge graphs expand to include hundreds of millions of nodes, entity reconciliation becomes the primary bottleneck during data ingestion. Figuring out whether an entity already exists, what it's called, and how it fits into the business landscape often demands costly, large-scale exploration of the entire graph—especially when relationships are fragmented and meanings inconsistent.
Proxy-Pointer takes a different approach.
Rather than requiring the graph to reconstruct meaning from disconnected nodes and edges, it pulls rich, contextual evidence straight from original documents—where entities, their relationships, roles, and ecosystem context naturally coexist.
In practice, Proxy-Pointer moves much of the reconciliation workload away from the Knowledge Graph and onto a much faster, more affordable vector retrieval system. The graph no longer needs to infer global meaning from scratch. Instead, it can focus on its core strengths: local structural navigation, data persistence, and governance.
Proxy-Pointer doesn’t replace the Knowledge Graph—it simply tells it where to look.
Further Reading
While reconciling entities and relationships in knowledge graphs remains a widespread challenge, the method described here is a practical adaptation of the open-source Proxy-Pointer pipeline, available at the Proxy-Pointer GitHub repository. But Proxy-Pointer’s capabilities go even further. Discover how it tackles one of the most demanding enterprise use cases—comparing complex documents like contracts and research papers with deep domain awareness, using a multi-step version of the original architecture. Read more in the article: Proxy-Pointer RAG — Structure-Aware Document Comparison at Enterprise Scale.
Connect with me and share your thoughts at www.linkedin.com/in/partha-sarkar-lets-talk-AI
All documents used in this benchmark are publicly available 10-K filings from SEC.gov. Code and benchmark results are open-source under the MIT License. Images in this article were generated using Google Gemini.
