76 — Multi-Aspect Indexing

Concept overview

Multi-aspect indexing creates several retrieval representations for one source object. A technical document may have body-text embeddings, a concise summary, extracted questions, a title vector, and structured entity fields. Each representation emphasizes a different route by which users describe the same evidence.

These views should converge on one authoritative source identity and revision. Generated summaries or questions can improve discovery but must not become independent evidence. Combining aspects requires calibrated fusion and deduplication; otherwise documents with more representations receive an unfair ranking advantage simply because they appear more often.

Why it matters in production

Proof of concept

A prototype compares body-only retrieval with one additional aspect on labeled query types.

Production

Production versions every derived view, records source lineage, and evaluates whether each aspect contributes unique relevant hits.

Enterprise scale

At scale, control indexing fan-out, rebuild all dependent aspects on source changes, and monitor representation-specific drift and storage cost.

Architecture components

Source registry

Assigns stable document and revision identifiers across all views.

Aspect builders

Generate body, title, summary, question, or entity representations.

Multi-vector index

Stores aspect-specific vectors and shared metadata.

Fusion policy

Combines aspect rankings without counting duplicates as independent evidence.

Source resolver

Fetches the authoritative passage behind a matched representation.

The architecture, mapped

flowchart TD
 S["Versioned equipment report"] --> B["Body embedding"]
 S --> T["Title and entity view"]
 S --> Q["Generated question view"]
 B --> F["Aspect-aware fusion"]
 T --> F
 Q --> F
 F --> D["Deduplicate source identity"]
 D --> E["Fetch original evidence"]

Runtime flow

1. 1

   Choose useful aspects

   Map observed query patterns to representations with a clear retrieval purpose.

2. 2

   Build derived views

   Generate each aspect from the same approved source revision.

3. 3

   Index with lineage

   Store aspect type, embedding version, source identity, and access metadata.

4. 4

   Search relevant aspects

   Dispatch only the views appropriate to the query under a bounded budget.

5. 5

   Fuse by source

   Combine rankings and deduplicate at the authoritative document or passage level.

6. 6

   Fetch real evidence

   Supply source text rather than generated index summaries as the basis for factual answers.

Finding evidence across varied report language

Insurance underwriting · Illustrative enterprise scenario, not a reported customer outcome.

Business situation

Underwriters search inspection reports by property feature, risk question, or report title.

The problem

One body embedding misses queries phrased as underwriting questions rather than report descriptions.

Agent requirement

Improve discovery while keeping every answer linked to the actual inspection evidence.

Architecture

The index stores body passages, title/entity views, and generated question representations with shared source IDs.

Runtime

• A query about roof condition matches a generated question view.
• The resolver retrieves the original inspection passage and its date before drafting the answer.

Failure scenario

If the generated view invents a property feature, source validation prevents it from supporting the final claim.

Operational impact

Measure marginal recall from each aspect, duplicate-hit rate, and indexing cost; remove views that add volume without useful retrieval coverage.

Architecture tradeoffs

Failure scenarios & recovery

Common architecture mistakes

Counting every view as separate evidence

Fuse and deduplicate by authoritative source.

Creating aspects without query evidence

Add views only for measured retrieval gaps.

Updating body vectors alone

Track the dependency graph of every derived representation.

When to choose this pattern

Choose it when

• Use when users describe the same content in several distinct ways.
• Use for structured reports with meaningful titles and entities.
• Use when additional views improve measured recall.

Avoid it when

• Avoid many views for already easy exact lookup.
• Do not cite generated index text as primary evidence.
• Avoid unbounded representation expansion.

Architecture checklist

• Assign shared source and revision IDs.
• Record aspect and embedding versions.
• Evaluate marginal recall per aspect.
• Deduplicate before evidence assembly.
• Invalidate every view on source change.
• Budget indexing cost per source object.

Related concepts

• 62 — Hybrid Search (Dense + Sparse)
• 64 — Parent-Child Chunking
• 65 — Re-ranking (Cohere/Cross-Encoders)
• 67 — Graph RAG / Knowledge Graphs
• 75 — Chunk Overlap Tuning
• 92 — Pre-Computing Embeddings

Primary references

• Milvus: Multi-vector hybrid search