Indexing (in LlamaIndex)

Indexing is what LlamaIndex is named for. An index is a structure over your data that makes it queryable by an LLM — it takes your loaded documents, splits them into nodes, and organises them so the right ones can be found later. Crucially, LlamaIndex offers several index types, and picking the right one shapes both how retrieval works and what it costs.

💡 In one line: An index structures your documents into retrievable nodes — and LlamaIndex offers several types, each with a different retrieval strategy.

What is an Index?

An index is a data structure built over your documents that lets an LLM query them. Building one means: parse documents into nodes, process them (usually embed), and organise them for retrieval.

Documents & Nodes

• Document — a source (a PDF, a page, a row).
• Node — a chunk of a document, plus metadata and relationships (to its source, previous/next node, and parent).

The node is LlamaIndex's core unit — indexes store nodes, retrievers return nodes, and query engines synthesise from nodes.

Index Types

Different structures suit different questions:

VectorStoreIndex (the Default)

The workhorse: chunk → embed → store, then retrieve by similarity. It backs onto any vector store — in-memory for dev, or Pinecone, Weaviate, Chroma, Qdrant, Milvus, pgvector in production.

Choosing an Index

Whiteboard

Node parsers control chunking — SentenceSplitter (the default, with chunk_size and chunk_overlap), sentence-window, semantic, and hierarchical parsers. As always, chunking quality drives retrieval quality.

Storage & Persistence

Indexes can be persisted and reloaded so you don't rebuild every run:

A StorageContext holds three stores: the docstore (nodes), the vector store (embeddings), and the index store (metadata).

Composability

You can combine indexes — several indexes as query-engine tools behind a router, or a hierarchical index over sub-indexes. This is how multi-corpus RAG systems get built.

Cost Note

Building a VectorStoreIndex embeds every node, so it costs tokens and time on large corpora. Persist the index and reuse it, rather than rebuilding on every run.

Best Practices

• VectorStoreIndex is the right default.
• Tune chunk size and overlap; keep metadata on nodes.
• Persist indexes; use a real vector store in production.
• Match the index type to the question type — and combine them when needed.

Summary

• An index structures documents into nodes so an LLM can query them.
• The node — a chunk with metadata and relationships — is LlamaIndex's core unit.
• VectorStoreIndex is the default; summary, tree, keyword, and property-graph indexes suit other question types.
• Node parsers control chunking; StorageContext persists the index.
• Indexes are composable — and embedding costs, so persist and reuse. EOF echo created