Normalized Entities and Context Slices Beyond Chunk Retrieval

Chunking is usually treated as a retrieval-tuning decision. Teams adjust token counts, overlap, boundary rules, metadata filters, top-k values, and rerankers until the returned passages appear relevant enough. That work is necessary, but it assumes the raw document passage is the right unit of context in the first place.

For many agentic operations, it is not. A document chunk is a physical subdivision of source material. The operation performed by an agent is defined by a purpose: compare two obligations, trace a dependency, identify the current owner of a decision, reconcile several descriptions of the same object, or assemble the evidence required for a specific action. The boundaries of the source and the boundaries of the operation rarely coincide.

The standard RAG workflow described by Databricks makes this distinction visible. Raw material is first ingested and normalized, then split into chunks, embedded, retrieved, and assembled into model context. Chunk size creates a familiar trade-off: smaller units improve specificity but can lose surrounding meaning, while larger units preserve more context but dilute the relevant passage. That is a useful tuning model when the answer exists within a reasonably self-contained section of text. It is weaker when the required information is distributed across documents or expressed repeatedly in different forms.

The broader movement from RAG toward context architecture reflects the same pressure. RAGFlow’s 2025 review characterizes retrieval as one tool within an agentic system rather than the whole knowledge-access architecture. Once an agent must sustain state, select tools, reconcile evidence, and act across several steps, returning the nearest passages is no longer equivalent to constructing the context the operation requires.

The diagnostic question is therefore whether this operation needs passages or an assembled representation of objects, relationships, and facts — not only whether the chunks are the right size. When repeated chunk tuning cannot resolve missing links, duplication, contradictory descriptions, or unstable context size, the architecture may be missing an intermediate context model.

A normalized entity layer converts information from document-shaped storage into explicit records about the domain. The entity may be a system, policy, control, obligation, customer, component, decision, event, owner, or any other object that matters to the agent’s work. Relationships capture how those objects connect. Supporting assertions retain provenance to the original source text.

This mirrors normalized data modeling. A database does not ordinarily represent a customer by storing every paragraph in which the customer appears as an independent record. It gives the customer a stable identity, separates attributes and relationships, and preserves the keys needed to join related information. Applying the same reasoning to agentic context means separating the information object from the incidental passage in which it was found.

A practical representation may contain:

• a canonical entity identifier and entity type
• normalized names, aliases, and source-specific labels
• entity-relationship triples such as subject, relationship, and object
• claims or attributes with effective dates, status, and confidence
• source references that preserve the exact supporting wording
• rules for merging duplicates and retaining conflicting assertions

The normalization step is not equivalent to producing an unconstrained summary. A summary compresses source material into prose. A normalized structure identifies reusable information units while retaining the lineage needed to inspect the underlying evidence. The distinction matters because an agent may need the same entity in several operations without needing the same description each time.

Graph-oriented retrieval systems demonstrate this pattern without defining its only possible implementation. Microsoft’s GraphRAG indexing flow begins with text units, then extracts entities, relationships, and optional claims. Repeated entity and relationship instances are merged, community structures are detected, and several resulting artifacts remain available for retrieval. The raw text units still matter for provenance, but they are no longer the sole context primitive.

Research by Min and colleagues also shows that the extraction layer need not depend entirely on expensive model calls. Their GraphRAG work uses dependency-based processing to construct entities and relationships from unstructured text and reports performance at approximately 94 percent of an LLM-generated knowledge graph on the evaluated datasets, alongside a hybrid vector-and-graph retrieval strategy. The architectural point is more important than the specific extraction method: structured retrieval becomes possible only after the system has created something structured to retrieve.

Normalized entities solve the representation problem, but they do not by themselves determine what the model should receive. An agent still needs a context assembly layer that selects and renders the subset required for the current operation. That rendered subset is a context slice.

A context slice is a purpose-built view assembled from normalized entities, relationships, claims, and selected source passages. Its shape follows the operation rather than the storage format. A comparison task may need two entities with aligned attributes and discrepancies. A dependency analysis may need a focal entity, its upstream and downstream relationships, and the evidence supporting each edge. A compliance check may need the applicable requirement, its effective date, the responsible control, the current owner, and the exact source wording.

This changes retrieval from a single ranking event into a sequence of explicit decisions:

1. Identify the operation and the entity or entities in scope
2. Traverse the relationships relevant to that operation
3. Select the required attributes, claims, and temporal state
4. Resolve or expose duplicates and conflicting assertions
5. Attach only the source excerpts needed for verification
6. Render the result into a context format designed for the model’s task

The slice can still use vector search. Semantic retrieval may identify candidate entities, supporting passages, or relevant communities. The difference is that vector similarity becomes one access method inside the assembly process, not the mechanism that determines the final context structure.

Microsoft GraphRAG’s local-search pattern illustrates this separation. A query is first associated with relevant entities, which become access points to connected entities, relationships, claims, community reports, and linked text units. Candidate materials are then prioritized and filtered to fit the available context window. The important pattern is the deliberate construction of context from several typed sources, rather than the direct forwarding of whichever chunks received the highest similarity scores or the product workflow itself.

The strongest case appears when the system repeatedly reasons across document boundaries. An entity may be defined in an architecture document, assigned to an owner in a governance register, constrained by a policy, and updated in a change record. No chunking strategy can make those physically separate passages become one retrieval unit. A normalized layer can associate them with the same entity and let the context assembler select the combination required for a particular decision.

Normalization also creates a direct place to manage duplication. Overlapping chunks, copied boilerplate, repeated definitions, and near-identical source versions can expand an index without adding distinct information. Berdyugina, Cohen, and Rioual report that entity-based chunk filtering reduced vector-index size by approximately 25 to 36 percent in their experiments while maintaining retrieval quality close to the baseline. Their work addresses filtering rather than a complete entity model, but it reinforces the principle that document segmentation can create substantial redundancy and that entity-aware processing can remove some of it.

Structured domains gain another advantage: the system can stop forcing one chunk size to serve incompatible operations. A fine-grained factual check may require a single assertion. A relationship analysis may require several linked assertions. A model preparing an executive explanation may need a compact community-level view with selected evidence. Context slices can produce each representation from the same normalized base rather than selecting a compromise chunk size and accepting its failure modes everywhere.

This is also useful where provenance and temporal state matter. Assertions can retain the source, extraction date, effective period, and status needed to distinguish current facts from historical ones. Conflicting claims do not have to be flattened into one summary; they can remain separate records and be exposed when the operation requires reconciliation. The model receives less incidental text, while the system retains stronger control over why each item was included.

A normalized entity layer adds extraction, identity resolution, schema governance, update logic, and context-assembly code. Those costs are not justified merely because structured retrieval is architecturally possible. Flat chunk retrieval remains the better choice when the source corpus and the task are naturally passage-oriented.

Examples include searching product documentation for a procedure, locating a clause in a small and stable contract set, answering questions whose evidence usually sits within one section, or supporting exploratory access where users genuinely want the surrounding prose. In these cases, careful chunk boundaries, metadata, hybrid retrieval, reranking, and evaluation may provide the required reliability with less operational burden.

The distinction can be tested through failure patterns. A tuning problem is likely when relevant passages exist but rank poorly, boundaries routinely cut through self-contained sections, or returned context includes too much adjacent text. Those symptoms can often be addressed through segmentation, metadata, query rewriting, filters, or reranking.

An architecture problem is more likely when the answer must be assembled from recurring entities across sources, when the same object appears under several names, when relationships matter more than passages, when duplication consumes a significant share of the index, or when different operations require incompatible context granularity. Another signal is repeated application code that retrieves chunks and then reconstructs the same objects and joins at query time. That code is already functioning as an informal entity layer, but without a governed model.

The decision should follow the value of the operations being supported. A low-volume assistant answering self-contained questions may not need structural rework. An agent expected to make repeatable, multi-step decisions across a changing institutional corpus probably does. The threshold is reached when the cost of compensating for document-shaped context exceeds the cost of modeling the information directly.

• Part 1: Architectural Principles for Token-Efficient Agentic Systems
• Part 2: Minimal and Complete Model Context Design
• Part 3: Authoritative State Must Live Outside the Model Context
• Part 5: Preserving Exact Source Wording in LLM Systems
• Part 1: Governing the Digital Investigation Lifecycle Across Systems and Teams
• Part 2: From UAE and Dubai Cybersecurity Controls to Operational Investigation Evidence
• Part 3: A Vendor-Neutral Event Architecture for Digital Investigation Governance
• Part 4: Human Authority in AI-Assisted Digital Investigation Governance

Browse the full Architectural Insights series →

• End-to-End RAG Workflow, Databricks Blog
• From RAG to Context - A 2025 Year-End Review of RAG, RAGFlow
• Towards Practical GraphRAG: Efficient Knowledge Graph Construction and Hybrid Retrieval at Scale, Min et al.
• Dataflow, Microsoft GraphRAG Documentation
• Reducing Redundancy in Retrieval-Augmented Generation through Chunk Filtering, Berdyugina, Cohen and Rioual