Context Graph Building and the Monograph

Everyone says "context is king." But what are we really talking about? If all you needed to do was retrieve text chunks, Vector RAG would have solved these problems. Then why are we talking about graphs now?

The real problem isn't just context. It's how you build it. How you store it. How you get it back.

This article explores why graphs solve what LLMs cannot. We'll examine the process of building context graphs with TrustGraph. We'll discuss why one graph is all you need. We'll explore precision retrieval with ontologies. And we'll confront an uncomfortable truth: long context windows don't work. They never did.

The Process Matters More Than the Product

Context isn't a thing. It's a process.

You can have all the context in the world. If you can't retrieve the right piece at the right time, you have nothing. This is the fundamental problem with modern AI systems. They confuse volume with value.

Building context means creating structure. Structure means graphs. Not just any graphs. Knowledge graphs built with intention. TrustGraph transforms raw data into structured relationships. It combines knowledge graphs with vector embeddings. The result is a system that understands connections. Not just words.

The process has three steps. First, extract knowledge from your sources. Second, build relationships between concepts. Third, store those relationships in a way that enables precise retrieval. Each step matters. Skip one and the whole thing fails.

This is why Vector RAG systems struggle. They skip the relationship step. They go straight from extraction to storage. No structure. No precision.

One Graph to Rule Them All

People ask: should I build separate graphs for different domains? Different projects? Different teams?

No.

The power of a graph comes from connections. Connections across domains. Across projects. Across what you thought were boundaries. When you split your data into multiple graphs, you destroy this power.

Think about how knowledge actually works. A concept in finance connects to operations. Operations connect to technology. Technology connects back to finance. These aren't separate domains. They're one connected system.

A single graph lets you discover relationships you didn't know existed. It lets you traverse from any concept to any other concept. This is called graph traversal. It's the fundamental operation that makes graphs powerful.

Multiple graphs force you to choose. Which graph do I query? Which graph has my answer? A single graph eliminates the choice. Query once. Get everything.

Storage isn't the limiting factor anymore. Scale isn't the problem. The problem is fragmentation. One graph solves it.

Collections and Context Cores: Organization Without Fragmentation

You don't need separate graphs. But you do need organization.

This seems like a contradiction. How do you keep enterprise data organized in one graph without it becoming chaos? TrustGraph solves this with collections and context cores. Two features that provide structure without splitting your graph apart.

A collection is a logical grouping within the graph. Think of it as a tag, but more powerful. You can assign nodes and edges to collections. "Finance data." "Customer records." "Product catalog." All in the same graph. All queryable separately or together.

Here's the key difference from separate graphs: collections share the underlying structure. A customer node in the "Sales" collection can connect to a product node in the "Inventory" collection. The relationship exists. It's queryable. But you can still scope your queries when you need to.

Context cores take this further. A context core is a modular subgraph that is not only logically separate in the graph, but can be dynamically added and removed from the system entirely. When an LLM needs context for a query, you don't send the entire graph. You load the relevant context core. The relevant nodes. The relevant edges. Nothing more.

This solves the context window problem from a different angle. Instead of chunking documents, you're selecting graph neighborhoods. Precise. Bounded. Exactly what the LLM needs to answer the query.

The monograph remains intact. You never split it. But you interact with it through collections and context cores. This is how scale works. Not by dividing the graph. By dividing attention to it.

Precision Through Ontologies

An ontology is a formal specification of concepts and relationships. That's the technical definition. Here's the simple one: an ontology is a map of what things are and how they connect.

This map provides precision. When you query for a "director," the ontology knows if you mean a film director or a board director. When you ask about "Paris," it knows if you mean the city or the person from Greek mythology.

RDF graphs support ontologies natively. They use standards like OWL and SKOS. These aren't just formats. They're shared vocabularies. Shared meaning.

Property graphs lack this feature. In a property graph, properties are just key-value pairs. No shared meaning. No formal specification. Every graph invents its own vocabulary. This works for single applications. It fails at scale.

Ontologies enable reasoning. If you know that "CEO" is a type of "Executive" and "Executive" is a type of "Employee," you can query for employees and automatically include CEOs. The ontology handles the inference. This is precision. This is power.

Why Context Must Be a Graph

LLMs fail at single-value problems.

Ask an LLM "What is the population of Tokyo?" It gives you a number. Maybe the right number. Maybe not. There's no way to know without checking. The LLM generates text. It doesn't retrieve facts.

This is where graphs excel. A graph stores "Tokyo" as a node. Population as a property with 37.4 million as the value. With a source. With a timestamp. When you query the graph, you get the exact value. Not a generated approximation. The actual value.

LLMs are brilliant at language tasks. At generation. At tasks where many combinations of words achieve the same goal. They're terrible at precision. At singular values. At facts that must be exact.

Context stored as text favors the LLM's weaknesses. Context stored as a graph favors its strengths. Use the LLM for what it's good at: understanding the query, interpreting intent, generating natural language. Use the graph for what it's good at: storing and retrieving precise values.

This is the foundation of GraphRAG. Graphs provide the facts. LLMs provide the interface. Together they solve what neither can solve alone.

The Vector RAG Problem

Vector RAG seemed promising. Embed documents. Match similar vectors. Retrieve relevant chunks.

It doesn't work well. Here's why.

Vectors capture semantic similarity. They don't capture specific values. When you embed "The population of Tokyo is 37.4 million," you get a vector. When you embed "Tokyo has about 35 million people," you get a similar vector. But which is correct?

The LLM can't tell. It sees both chunks. Both are semantically similar to the query. The LLM generates something between them. Maybe 36 million. It's wrong. But the system has no way to know.

Graphs solve this. The graph stores one value. The correct value. The sourced value. No ambiguity. No averaging. No hallucination.

Vector RAG treats everything as similar or dissimilar. Graphs treat things as connected or not connected. Connection is more precise than similarity. Connection preserves structure. Similarity loses it.

This is why GraphRAG outperforms Vector RAG for factual retrieval. Vectors for finding relevant context. Graphs for extracting precise values. Use both. Don't choose one.

The Long Context Window Myth

LLM providers keep expanding context windows. 100k tokens. 200k tokens. 1 million tokens. They claim longer is better.

The data says otherwise.

I posted two articles on this topic, “Chunk Smaller” and “A Tale of Two Trends”, where I tested Claude Haiku’s ability to extract a graph from chunks of different sizes. The model has a 200k token context window. Even at 8000-token chunks, they were using only 4% of the window. Surely chunk size wouldn't matter. It did.

Chunks of 1000 tokens extracted 2,153 graph edges. Chunks of 8000 tokens extracted 1,352 edges. A 59% increase just from chunking smaller. At 500 tokens, the system extracted 2,975 edges. A 120% increase over 8000-token chunks.

This pattern held across eight different models from six companies. Claude. Gemini. Mistral. Cohere. Llama. All showed the same behavior. Smaller chunks, better extraction. The drop-off from 500-token to 4000-token chunks ranged from 45% to 59%.

Long context windows don't work. The "lost in the middle" problem is real. It hasn't improved.

The Lost in the Middle Problem

Research has documented this for years. Information in the middle of long contexts gets ignored. LLMs focus on the beginning. On the end. The middle disappears.

I showed this problem in my article, “Yes, You Still Need RAG” (although what you really need is GraphRAG), where feeding frontier models with a highly complex, long document, showed how details in the middle were either lost, or simply hallucinated.

As models improve, the thinking was - this problem would get better. It hasn't. Better models. Same problem. Consistent across providers. This behavior seems to be inherent to the transformer architecture itself.

Even Anthropic acknowledges this. Their Model Context Protocol (MCP) blogs warn against giving LLMs too many tools. Too many options overwhelm the model. It's the same problem. Long context. Lost information. Failed retrieval. I’ve even had Anthropic employees admit to me - in person - that they have an internal context limit, that once you cross, reliability quickly drops off. This known limit is nowhere near the full advertised context window.

The solution isn't longer windows. It's better structure. Graphs provide structure. They let you retrieve exactly what you need. Small, focused context. The LLM can actually use it.

This is why chunking at 500-1000 tokens works. It's not about the size of the window. It's about the size of the useful context. Keep it small. Keep it focused. Keep it structured.

Semantic Relationships at Small Scale

LLMs can associate values with semantic relationships. But only when the context is tiny.

Give an LLM a paragraph about Tokyo. Ask about population. It finds the value. Give it ten paragraphs. The accuracy drops. Give it a hundred paragraphs. It fails.

This isn't a training problem. It's an attention problem. Transformers attend to all tokens. More tokens mean diluted attention. Important values get lost in the noise.

Graphs solve this through structure. The graph knows which nodes connect to which properties. Query for Tokyo's population. The graph traverses one edge. Done. No attention mechanism. No lost information. Direct retrieval.

The LLM still plays a role. It interprets the user's query. "How many people live in Tokyo?" becomes a structured query for Tokyo's population property. The LLM provides the interface. The graph provides the answer.

This division of labor is crucial. LLMs for language. Graphs for structure. Each doing what it does best. This is the future of AI systems. Not LLMs alone. Not graphs alone. Both together.

Conclusion: The Monograph

The title promised discussion of the monograph. Here it is.

"Mono" means one. One graph. One structure. One source of truth. This is the monograph approach. All your context in one place. Structured. Ontologized. Queryable with precision.

Context is king. But only if you can retrieve it. Only if it's accurate. Only if it's precise. The monograph makes this possible. One graph to build. One graph to query. One graph to trust.

Build your graph with intention. Build it with ontologies. Build it with RDF. Build it with TrustGraph. And build it small—chunk your data into pieces LLMs can actually process.

The tools exist. The methods work. The data proves it. Stop relying on long context windows. Stop fragmenting your data across multiple graphs. Stop treating LLMs as databases.

Build the monograph. Build it right. Build it now. Build it with TrustGraph.

For more information:

• Documentation: https://docs.trustgraph.ai
• GitHub Repository: https://github.com/trustgraph-ai/trustgraph
• Discord Community: https://discord.gg/sQMwkRz5GX
• Website: https://trustgraph.ai