LlamaIndex Indexes¶
📖 Overview¶
In LlamaIndex, an Index is the data structure that organizes documents and nodes so they can be efficiently retrieved for downstream RAG workflows.
A useful mental model is:
The index is therefore an important boundary between:
and:
LlamaIndex provides different index structures for different retrieval requirements.
The most important concept is not simply memorizing index classes.
It is understanding:
Which index structure is appropriate for the information-retrieval problem being solved?
🎯 Learning Objectives¶
After completing this chapter, you will be able to:
- Understand the purpose of indexes in LlamaIndex
- Understand the relationship between Documents, Nodes, Indexes, and Retrievers
- Understand
VectorStoreIndex - Understand
SummaryIndex - Understand keyword-oriented indexes
- Understand knowledge-graph-oriented indexing
- Understand how indexes interact with retrievers
- Understand index construction and persistence
- Understand index storage concepts
- Understand metadata and index design
- Understand how index choice affects retrieval
- Understand when to use vector, summary, keyword, or graph-oriented indexes
- Understand index composition in enterprise RAG
- Design framework-aware index adapters
- Avoid common index design mistakes
1. What Is an Index?¶
An index organizes information so that retrieval can happen efficiently.
Consider a large enterprise knowledge base:
Without an appropriate retrieval structure, searching the entire corpus for every query becomes inefficient.
An index provides a representation optimized for a particular retrieval strategy.
2. Index in the RAG Pipeline¶
flowchart TD
A["Source Documents"] --> B["Document Processing"]
B --> C["Nodes"]
C --> D["Index Construction"]
D --> E["Index"]
F["User Query"] --> G["Retriever"]
E --> G
G --> H["Relevant Nodes"]
H --> I["Context"]
I --> J["LLM"]
J --> K["Response"]The index is queried indirectly through a retriever.
3. Documents → Nodes → Index¶
A common LlamaIndex ingestion flow is:
Example:
Payment Architecture Document
↓
Node Parser
↓
┌───────────┼───────────┐
↓ ↓ ↓
Node 1 Node 2 Node 3
↓
Index
The exact indexing behavior depends on the selected index type.
4. Why Different Indexes?¶
Different retrieval problems require different structures.
For semantic retrieval:
For summarization-oriented retrieval:
For keyword-oriented retrieval:
For relationship-oriented retrieval:
Conceptually:
flowchart TD
A["Retrieval Requirement"] --> B{"Information Structure"}
B -->|Semantic Similarity| C["Vector Index"]
B -->|Sequential / Summarization| D["Summary Index"]
B -->|Keyword Matching| E["Keyword Index"]
B -->|Entity Relationships| F["Graph-Oriented Index"]5. Major LlamaIndex Index Concepts¶
A practical overview includes:
The exact classes and available integrations can vary across LlamaIndex releases.
The important architectural distinction is:
Each represents information differently.
6. VectorStoreIndex¶
VectorStoreIndex is the most common index for modern semantic RAG.
Its architecture is:
Query:
7. VectorStoreIndex Architecture¶
flowchart TD
A["Documents"] --> B["Nodes"]
B --> C["Embedding Model"]
C --> D["Vector Store"]
D --> E["Vector Index"]
F["User Query"] --> G["Query Embedding"]
G --> H["Similarity Search"]
E --> H
H --> I["Top-K Nodes"]The vector index represents semantic relationships through embeddings.
8. Basic VectorStoreIndex Example¶
from llama_index.core import (
Document,
VectorStoreIndex
)
documents = [
Document(
text="Payment authentication uses OAuth."
),
Document(
text="Payment failures are retried."
)
]
index = VectorStoreIndex.from_documents(
documents
)
retriever = index.as_retriever(
similarity_top_k=3
)
results = retriever.retrieve(
"How does payment authentication work?"
)
for result in results:
print(result.node.text)
print(result.score)
The exact API can vary with the LlamaIndex version and configured embedding/vector-store integration.
9. What Does VectorStoreIndex Store?¶
Conceptually, the retrieval system needs access to:
The vector store primarily provides efficient similarity search over embeddings, while associated document/node storage may be handled separately depending on the configuration.
10. Embedding Model and Index¶
The embedding model is critical.
During indexing:
During retrieval:
A mismatch between indexing and query embedding spaces can severely degrade retrieval.
11. Embedding Consistency¶
Suppose documents were indexed with:
but queries are embedded with:
The resulting vectors may not be directly compatible.
Production principle:
unless the retrieval architecture explicitly supports compatible embedding spaces.
12. Vector Dimension¶
Embedding models generate vectors with a specific dimension.
Example:
with:
The vector store/index configuration must support that dimensionality.
Changing the embedding model may require rebuilding the index.
13. Index Construction¶
A simplified indexing pipeline:
This is an ingestion-time operation.
It should generally not happen on every user query.
14. Indexing vs Retrieval Time¶
Indexing Time¶
Query Time¶
Separating these phases is fundamental to scalable RAG architecture.
15. SummaryIndex¶
A SummaryIndex organizes nodes in a way that supports retrieval through node traversal and response synthesis rather than relying primarily on vector similarity.
Conceptually:
This can be useful when:
The corpus is relatively small
+
The query requires broad context
+
Sequential or comprehensive processing is acceptable
16. SummaryIndex Mental Model¶
flowchart TD
A["Documents"] --> B["Nodes"]
B --> C["SummaryIndex"]
D["User Query"] --> E["Query Engine"]
C --> E
E --> F["Node Selection / Traversal"]
F --> G["Response Synthesis"]
G --> H["LLM"]The important distinction is that this is not the same retrieval mechanism as dense vector similarity search.
17. When Summary-Oriented Retrieval Can Help¶
Consider a small document:
A question may require information spread across:
A broad retrieval/synthesis strategy may be more appropriate than retrieving only a handful of semantically similar chunks.
Potential use cases include:
18. SummaryIndex Trade-Off¶
The primary trade-off is:
For large enterprise corpora, blindly processing many nodes for every query can become expensive.
Therefore:
Small Corpus
→ Broad Processing May Be Acceptable
Large Corpus
→ Targeted Retrieval Usually Preferred
19. KeywordTableIndex¶
Keyword-oriented indexing focuses on explicit terms.
Conceptually:
Query:
may identify nodes associated with:
20. Keyword Index Architecture¶
flowchart TD
A["Documents"] --> B["Nodes"]
B --> C["Keyword Extraction"]
C --> D["Keyword Index"]
E["Query"] --> F["Keyword Extraction"]
F --> G["Keyword Lookup"]
D --> G
G --> H["Candidate Nodes"]Keyword-oriented retrieval is particularly useful for exact terminology.
21. Why Keywords Still Matter¶
Enterprise knowledge bases contain many identifiers:
Exact lexical matching can be extremely valuable.
Semantic search alone should not be assumed to be optimal for these cases.
22. Keyword vs Vector Retrieval¶
| Characteristic | Keyword | Vector |
|---|---|---|
| Exact identifiers | Strong | Variable |
| Semantic similarity | Limited | Strong |
| Synonyms | Limited | Strong |
| Acronyms | Strong | Variable |
| Natural language concepts | Moderate | Strong |
| Error codes | Strong | Variable |
| Vocabulary mismatch | Weak | Strong |
This is one reason enterprise RAG frequently uses hybrid retrieval.
23. Knowledge Graph-Oriented Indexing¶
Some information is inherently relational.
Example:
A graph-oriented representation captures these relationships explicitly.
24. Graph Index Architecture¶
flowchart TD
A["Documents"] --> B["Entity Extraction"]
B --> C["Entities"]
B --> D["Relationships"]
C --> E["Knowledge Graph"]
D --> E
F["User Query"] --> G["Entity / Relationship Query"]
G --> E
E --> H["Related Entities / Facts"]This differs from pure vector similarity.
25. Vector vs Graph Representation¶
Vector retrieval:
Graph retrieval:
The vector approach emphasizes:
The graph approach emphasizes:
26. Index Choice Is a Retrieval Decision¶
Do not ask:
"Which LlamaIndex index should I always use?"
Ask:
"What information structure does this problem require?"
For example:
Semantic knowledge
→ Vector
Exact identifiers
→ Keyword / Hybrid
Broad document analysis
→ Summary-oriented
Relationships
→ Graph
27. Index + Retriever¶
An index does not necessarily mean the application directly queries the index.
The normal abstraction is:
Example:
The retriever becomes the query-time interface.
28. Why the Retriever Layer Matters¶
The retriever can add:
Therefore:
This distinction is fundamental.
29. Index and Query Engine¶
A query engine usually combines:
Conceptually:
This allows the same index to potentially support multiple query-time retrieval configurations.
30. Index Persistence¶
Large indexes should not normally be rebuilt every time an application starts.
Production flow:
This reduces:
31. Storage Context¶
LlamaIndex supports storage abstractions for persisting components of an indexed system.
Conceptually:
The actual components used depend on the application configuration.
32. Persistent Architecture¶
flowchart TD
A["Source Documents"] --> B["Ingestion"]
B --> C["Nodes"]
C --> D["Index Construction"]
D --> E["Persistent Storage"]
E --> F["Application Startup"]
F --> G["Load Index"]
G --> H["Retriever"]
H --> I["Query"]This separates one-time indexing from repeated retrieval.
33. Persistence Example¶
A simplified local persistence pattern can look like:
from llama_index.core import (
StorageContext,
VectorStoreIndex,
load_index_from_storage
)
storage_context = StorageContext.from_defaults(
persist_dir="./storage"
)
index = load_index_from_storage(
storage_context
)
The exact persistence configuration depends on the index and storage backend.
34. Persistence Directory¶
A local persistence directory may contain information needed to reconstruct the index and associated storage state.
Conceptually:
Do not assume every deployment stores every component locally; external vector stores may hold the vectors separately.
35. External Vector Store¶
Production deployments commonly use external vector databases.
Architecture:
Examples of vector backends may include:
The exact supported integration depends on the LlamaIndex ecosystem and deployed versions.
36. Enterprise Vector Architecture¶
flowchart LR
A["LlamaIndex"] --> B["Vector Store Adapter"]
B --> C["Vector Database"]
C --> D["Vectors"]
C --> E["Metadata"]
A --> F["Document / Node Storage"]
F --> G["Node Content"]This separation allows:
and:
to evolve independently.
37. Index Construction with Custom Embeddings¶
A production application often configures its embedding model explicitly.
Conceptually:
Then:
The important architectural principle is:
must be deterministic and versioned.
38. Embedding Configuration as Infrastructure¶
Treat embedding configuration as part of the index contract.
Record:
Example:
{
"embedding_model": "example-model",
"dimension": 1536,
"distance_metric": "cosine",
"chunk_size": 512,
"chunk_overlap": 50
}
39. Why Index Configuration Must Be Versioned¶
Suppose you change:
or:
the resulting vectors and retrieval behavior may change.
Therefore:
should capture the configuration that produced it.
Example:
40. Chunking and Index Quality¶
Index quality depends heavily on node quality.
Bad chunks:
can create poor embeddings.
Better:
produce more meaningful retrieval units.
Therefore:
It depends on:
41. Metadata During Indexing¶
Example:
from llama_index.core import Document
document = Document(
text="Payment authentication...",
metadata={
"department": "payments",
"document_type": "architecture",
"status": "approved",
"region": "EU"
}
)
Metadata becomes part of the retrieval context associated with the node.
42. Metadata and Index Design¶
Metadata can support:
For enterprise systems:
should be designed together.
43. Tenant-Aware Indexing¶
A multi-tenant platform might store:
Each node should carry tenant context:
However, metadata is not itself an authorization system.
The application must enforce trusted tenant boundaries.
44. Tenant Isolation¶
flowchart TD
A["User"] --> B["Authentication"]
B --> C["Authorization"]
C --> D["Trusted Tenant Context"]
D --> E["Retrieval Layer"]
E --> F["Tenant-Scoped Index / Filter"]
F --> G["Relevant Nodes"]This prevents cross-tenant retrieval.
45. One Index or Multiple Indexes?¶
Enterprise systems may choose:
with:
or:
The correct approach depends on:
There is no universal answer.
46. Shared Index¶
Advantages:
Challenges:
47. Tenant-Specific Indexes¶
Advantages:
Challenges:
48. Index Sharding¶
Large systems may partition indexes by:
Example:
This can reduce search scope and support independent scaling.
49. Index Routing¶
Instead of searching every shard:
Example:
This can improve:
50. Index Routing Architecture¶
flowchart TD
A["Query"] --> B["Query Planner"]
B --> C["Region"]
B --> D["Domain"]
B --> E["Tenant"]
C --> F["Index Router"]
D --> F
E --> F
F --> G["Target Index"]
G --> H["Retriever"]
H --> I["Candidates"]51. Multiple Indexes¶
A sophisticated RAG platform may maintain:
The router determines where to search.
This is often more scalable than forcing every document into a single retrieval strategy.
52. Index Composition¶
Indexes can also be combined at query time.
This becomes an important pattern for enterprise RAG.
53. Index Composition Architecture¶
flowchart TD
A["User Query"] --> B["Query Router"]
B --> C["Architecture Index"]
B --> D["API Index"]
B --> E["Incident Index"]
C --> F["Candidates"]
D --> F
E --> F
F --> G["Fusion"]
G --> H["Re-ranking"]
H --> I["Context"]54. Index Lifecycle¶
Indexes should be treated as production assets.
Lifecycle:
This is especially important for enterprise knowledge bases.
55. Index Build Pipeline¶
flowchart LR
A["Source Data"] --> B["Extract"]
B --> C["Normalize"]
C --> D["Chunk"]
D --> E["Metadata"]
E --> F["Embedding"]
F --> G["Index"]
G --> H["Validation"]
H --> I["Publish"]The index should be validated before becoming the active production version.
56. Blue-Green Index Deployment¶
A production system can maintain:
Build:
validate it, then switch traffic:
This reduces deployment risk.
57. Index Versioning¶
Example:
Each version may correspond to:
This makes rollback possible.
58. Index Rollback¶
If retrieval quality degrades:
This is much safer than rebuilding production data manually.
59. Index Validation¶
Before publishing an index, validate:
Document Count
Node Count
Embedding Dimension
Metadata Completeness
Duplicate Rate
Missing Content
Search Quality
Latency
Security Isolation
Example:
Production validation should be significantly more comprehensive.
60. Index Health¶
Monitor:
Index Size
Node Count
Vector Count
Metadata Coverage
Update Lag
Search Latency
No-Result Rate
Retrieval Quality
Example:
Index Health
────────────────────────
Nodes 4.2M
Vectors 4.2M
Metadata Coverage 98.7%
Update Lag 4 min
P95 Search 110 ms
No-Result Rate 2.1%
61. Index Freshness¶
Enterprise knowledge changes continuously.
Track:
and calculate:
62. Incremental Indexing¶
Rebuilding an entire enterprise index after every document change is expensive.
Instead:
This reduces:
63. Incremental Indexing Architecture¶
flowchart TD
A["Source Change"] --> B["Change Detection"]
B --> C["Changed Documents"]
C --> D["Re-parse"]
D --> E["Re-chunk"]
E --> F["Re-embed"]
F --> G["Update Index"]
G --> H["Validate"]
H --> I["Publish"]This is the preferred pattern for frequently changing knowledge bases.
64. Deleted Documents¶
Index lifecycle must also handle deletion.
Example:
Source Document Deleted
↓
Change Event
↓
Identify Nodes
↓
Delete from Index
↓
Delete / Update Metadata
A stale document in the index can produce incorrect or unauthorized answers.
65. Document Version Changes¶
Suppose:
becomes:
The indexing system must decide whether to:
or:
The decision depends on business requirements.
66. Current vs Historical Indexing¶
One possible design:
Then:
routes to:
while:
can route to:
67. Index and Retrieval Quality¶
A poor index can produce poor retrieval even when the retriever is correctly implemented.
Common causes:
Bad Chunking
Bad Embeddings
Missing Metadata
Duplicate Nodes
Stale Documents
Wrong Index Type
Poor Source Parsing
Therefore retrieval quality is an end-to-end property.
68. Index Quality Equation¶
A useful conceptual model is:
Retrieval Quality
=
Content Quality
+
Chunking Quality
+
Metadata Quality
+
Embedding Quality
+
Index Quality
+
Retriever Quality
These components interact rather than acting independently.
69. Index Selection Matrix¶
| Requirement | Preferred Index Concept |
|---|---|
| Semantic retrieval | VectorStoreIndex |
| Exact lexical matching | Keyword-oriented index |
| Broad node processing | SummaryIndex |
| Entity relationships | Graph-oriented index |
| Mixed retrieval | Multiple / composed indexes |
| Enterprise routing | Specialized indexes + router |
This is a conceptual guide, not a universal rule.
70. Vector Index Example: Architecture Documents¶
documents = [
Document(
text="""
The payment gateway uses Kafka
for asynchronous transaction events.
""",
metadata={
"document_type": "architecture",
"service": "payment-gateway"
}
)
]
index = VectorStoreIndex.from_documents(
documents
)
A vector index is useful because the query may use different wording:
while the document says:
71. Keyword Index Example¶
A keyword-oriented approach may be useful for:
or:
because exact terms are important.
This is one reason enterprise systems frequently combine:
rather than relying on one index type.
72. Multiple Indexes for One Corpus¶
The same source documents can potentially contribute to multiple representations:
At query time:
This is a powerful enterprise architecture.
73. Multi-Index Architecture¶
flowchart TD
A["Enterprise Documents"] --> B["Node Pipeline"]
B --> C["Vector Index"]
B --> D["Keyword Index"]
B --> E["Summary Representation"]
B --> F["Knowledge Graph"]
G["User Query"] --> H["Query Planner"]
H --> C
H --> D
H --> E
H --> F
C --> I["Evidence"]
D --> I
E --> I
F --> I
I --> J["Fusion"]
J --> K["Re-ranking"]
K --> L["Context"]This moves beyond single-index RAG toward retrieval orchestration.
74. Indexes and Cost¶
Every additional index can introduce:
Therefore:
Only build indexes that solve real retrieval problems.
75. Indexes and Latency¶
Searching multiple indexes may increase latency.
Example:
Potential pipeline latency:
versus:
Parallel execution can help, but introduces infrastructure complexity.
76. Parallel Multi-Index Retrieval¶
flowchart TD
A["Query"] --> B["Query Planner"]
B --> C["Vector Index"]
B --> D["Keyword Index"]
B --> E["Graph Index"]
C --> F["Results"]
D --> F
E --> F
F --> G["Fusion"]
G --> H["Re-ranking"]This is a common production pattern.
77. Index Failure Isolation¶
If one index is unavailable:
the system may still use:
if the business requirement allows degraded retrieval.
This is an important production resilience consideration.
78. Retrieval Fallback¶
Example:
Fallback behavior should be explicit and observable.
79. Index Security¶
Indexes may contain sensitive information.
Security controls should include:
Do not assume that embedding a document removes its sensitivity.
Embeddings and retrieved content can still represent sensitive information.
80. Index and Compliance¶
Enterprise requirements may include:
Index architecture must support the required lifecycle.
Example:
81. Index and Data Deletion¶
Deletion is more complicated than deleting the original file.
You may need to remove:
A production ingestion pipeline should track these relationships.
82. Index Observability¶
Track:
Index Build Time
Index Version
Document Count
Node Count
Embedding Count
Failed Documents
Failed Embeddings
Metadata Errors
Index Update Lag
Query-time metrics:
83. Index Build Observability¶
Example:
{
"index_version": "payment-kb-v4",
"documents": 120000,
"nodes": 850000,
"embeddings": 850000,
"failed_documents": 42,
"metadata_errors": 18,
"build_duration_seconds": 8420
}
This makes index builds auditable and debuggable.
84. Index Evaluation¶
Before publishing an index:
Compare:
using the same evaluation dataset.
Measure:
85. Index Experimentation¶
You may experiment with:
Chunk Size
Chunk Overlap
Embedding Model
Embedding Dimension
Metadata Schema
Vector Database
Index Type
Top-K
Treat these as controlled experiments.
86. Index Experiment Matrix¶
| Version | Chunk Size | Embedding | Index | Recall@10 |
|---|---|---|---|---|
| V1 | 256 | Model A | Vector | 0.71 |
| V2 | 512 | Model A | Vector | 0.78 |
| V3 | 512 | Model B | Vector | 0.83 |
| V4 | 512 | Model B | Hybrid | 0.89 |
The values are illustrative.
The important idea is:
87. Index Rebuild Triggers¶
A full rebuild may be required after major changes such as:
Embedding Model Change
Embedding Dimension Change
Chunking Strategy Change
Major Metadata Schema Change
Index Type Change
Source Reprocessing
Incremental updates are preferable for normal content changes when supported.
88. Index Build Pipeline in CI/CD¶
flowchart LR
A["Source Snapshot"] --> B["Build Index"]
B --> C["Validation"]
C --> D["Retrieval Evaluation"]
D --> E{"Quality Gate"}
E -->|Pass| F["Publish Index"]
E -->|Fail| G["Reject"]This brings retrieval engineering into a production deployment workflow.
89. Retrieval Quality Gate¶
Example:
Recall@10 >= baseline
NDCG@10 >= baseline
No-result rate <= threshold
Security tests = 100% pass
Metadata completeness >= threshold
An index should not be promoted simply because it successfully built.
90. Index Registry¶
A production platform can maintain an index registry:
{
"name": "payment-knowledge",
"active_version": "v4",
"embedding_model": "model-b",
"chunking_version": "v3",
"created_at": "2026-08-10"
}
This supports:
91. Index Registry Architecture¶
flowchart TD
A["Index Build"] --> B["Validation"]
B --> C["Index Registry"]
C --> D["Active Index"]
C --> E["Previous Index"]
D --> F["Retrieval Service"]
E --> G["Rollback"]This is a useful production pattern.
92. Index Aliases¶
Instead of hardcoding:
applications can reference:
The alias points to:
and can later switch to:
This simplifies deployment.
93. Index Warm-Up¶
After deployment, the system may need to:
before accepting full traffic.
This reduces first-request latency.
94. Index Cold Start¶
A cold application may experience:
leading to high first-request latency.
Production systems can use:
where appropriate.
95. Index Caching¶
Potential cache layers include:
Example:
Cache keys must account for:
to avoid cross-context data leakage.
96. Index and Caching Security¶
Never use:
without considering:
Two users asking the same query may have different permitted results.
97. Index and Metadata Filtering¶
A strong retrieval architecture is:
not:
Security boundaries should be enforced as early as practical.
98. Index and Query Rewriting¶
The previous chapter introduced query rewriting.
The complete flow becomes:
The rewritten query should be optimized for the selected index.
99. Query Type → Index Type¶
Example:
Another:
Another:
100. Query Planner + Index Router¶
flowchart TD
A["User Query"] --> B["Query Planner"]
B --> C["Intent"]
B --> D["Entities"]
B --> E["Constraints"]
C --> F["Index Router"]
D --> F
E --> F
F --> G["Vector Index"]
F --> H["Keyword Index"]
F --> I["Graph Index"]
G --> J["Results"]
H --> J
I --> J
J --> K["Fusion"]This architecture provides a foundation for multi-index enterprise retrieval.
101. Framework Adapter¶
If the enterprise application wants framework independence:
class IndexProvider:
def build(self, documents):
raise NotImplementedError
def load(self, version):
raise NotImplementedError
Then:
This prevents LlamaIndex-specific APIs from leaking throughout the application.
102. Capability-Based Index Architecture¶
Instead of exposing:
the enterprise platform can expose:
Then:
becomes one implementation.
This keeps the architecture aligned with business capabilities rather than framework classes.
103. Example Architecture¶
flowchart TD
A["Enterprise Retrieval Service"] --> B["Index Capability"]
B --> C["Semantic Index Adapter"]
B --> D["Keyword Index Adapter"]
B --> E["Graph Index Adapter"]
C --> F["LlamaIndex VectorStoreIndex"]
D --> G["LlamaIndex Keyword Retrieval"]
E --> H["Graph Backend"]This architecture is easier to evolve.
104. Common Index Anti-Patterns¶
Anti-Pattern 1 — One Index for Everything¶
This may be too simplistic for complex enterprise knowledge.
Anti-Pattern 2 — Rebuilding on Every Startup¶
This wastes time and money.
Anti-Pattern 3 — No Index Versioning¶
Changing embeddings or chunking without tracking the resulting index makes debugging difficult.
105. Common Anti-Patterns — Continued¶
Anti-Pattern 4 — Ignoring Metadata¶
A vector index without useful metadata can make:
much harder.
Anti-Pattern 5 — No Evaluation¶
An index that builds successfully can still produce poor retrieval.
Anti-Pattern 6 — No Deletion Strategy¶
Deleted or revoked documents can remain searchable.
Anti-Pattern 7 — Framework Coupling¶
Application logic directly depends on framework-specific index classes everywhere.
106. Production Checklist¶
☐ Define retrieval requirements
☐ Choose appropriate index type
☐ Define node/chunk strategy
☐ Define metadata schema
☐ Configure embedding model
☐ Record embedding version
☐ Record vector dimension
☐ Define index version
☐ Persist index state
☐ Implement incremental updates
☐ Implement deletion
☐ Validate index before publication
☐ Evaluate retrieval quality
☐ Implement security isolation
☐ Monitor index freshness
☐ Monitor index health
☐ Support rollback
☐ Track index lineage
☐ Avoid unnecessary index duplication
☐ Keep application architecture framework-agnostic
107. Practical Decision Framework¶
When designing a new RAG system, ask:
Question 1¶
Is the primary retrieval problem semantic?
Question 2¶
Are exact identifiers important?
Question 3¶
Does the question require relationships?
Question 4¶
Does the query require broad document understanding?
Question 5¶
Do multiple retrieval strategies help?
108. Enterprise Index Strategy¶
A mature enterprise RAG platform may use:
Enterprise Knowledge
│
┌──────────────┼──────────────┐
↓ ↓ ↓
Documents Databases Graphs
│ │ │
↓ ↓ ↓
Vector Index SQL Layer Graph Index
│ │ │
└──────────────┼──────────────┘
↓
Query Planner
↓
Retrieval Router
↓
Candidate Fusion
↓
Re-ranking
↓
Context Engineering
LlamaIndex can participate in multiple parts of this architecture.
109. Key Takeaways¶
- An index organizes information for efficient retrieval.
- LlamaIndex supports multiple index concepts for different information needs.
VectorStoreIndexis central to semantic RAG.- Vector indexes depend on compatible embedding configurations.
- Nodes are the fundamental units that indexes organize and retrieve.
SummaryIndexsupports broad or summary-oriented retrieval workflows.- Keyword-oriented indexing is useful for exact terms and identifiers.
- Graph-oriented indexing represents entities and relationships.
- Index choice should follow the retrieval problem rather than framework popularity.
- Indexes and retrievers are different architectural concerns.
- An index organizes information; a retriever performs query-time retrieval.
- Query engines combine retrieval with response synthesis.
- Indexing occurs primarily during ingestion, while retrieval occurs at query time.
- Persistent indexes avoid rebuilding the corpus for every application startup.
- External vector stores can provide scalable persistence for embeddings.
- Metadata should be designed together with index architecture.
- Tenant isolation must be enforced by trusted application security controls.
- One shared index and multiple tenant-specific indexes have different trade-offs.
- Large systems may use index sharding and routing.
- Multiple specialized indexes can be composed into an enterprise retrieval system.
- Incremental indexing reduces the cost of frequent source changes.
- Deletion and document revocation are critical parts of index lifecycle management.
- Index versions enable safe deployments and rollback.
- Index quality depends on parsing, chunking, metadata, embeddings, and retrieval configuration.
- Indexes should be evaluated using retrieval metrics before production publication.
- Index build pipelines can use quality gates similar to software deployment pipelines.
- Index observability should track build health, freshness, size, failures, and retrieval performance.
- Caching must include security and index-version context.
- Enterprise applications should avoid becoming tightly coupled to framework-specific index classes.
- Capability-based index abstractions provide a cleaner architecture.
- LlamaIndex should be treated as an implementation toolkit inside the enterprise RAG architecture, not as the architecture itself.
The central model is:
SOURCE KNOWLEDGE
│
▼
Document Processing
│
▼
Nodes
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Vector Index Keyword Index Graph Index
│ │ │
└─────────────┼─────────────┘
▼
Query Planning
│
▼
Retrieval Router
│
▼
Candidate Results
│
▼
Re-ranking
│
▼
Context Selection
│
▼
LLM
│
▼
Validated Enterprise
Response
An index is not simply a database of embeddings. It is a retrieval-oriented representation of enterprise knowledge.
🧭 Chapter Navigation¶
Part V — Advanced Retrieval-Augmented Generation¶
Previous:
01. LlamaIndex Retrievers Overview
Next:
03. Vector Index Retriever
Section:
03 — LlamaIndex Retrieval Engineering
LlamaIndex Retrieval Engineering Path¶
01 LlamaIndex Retrievers Overview
↓
02 LlamaIndex Indexes
↓
03 Vector Index Retriever
↓
04 BM25 Retriever
↓
05 Document Summary Retriever
↓
06 Recursive Retriever
↓
07 Query Fusion Retriever
↓
08 Auto-Merging Retriever
↓
04 Vector Search Engineering
Enterprise AI Engineering Handbook
Building Production-Grade Enterprise AI Systems — One Chapter at a Time.