Indexes

Purpose and Scope

An index is the data structure that makes loaded LlamaIndex data queryable. After readers produce Document objects, and after parsing may split those documents into smaller nodes, an index organizes the resulting content for a particular retrieval or synthesis strategy. This page helps you choose among the major index families rather than treating indexes as interchangeable containers. The most important design question is not only “where should my data live?” but “how should the application find, traverse, summarize, or relate the pieces of data when a user asks a question?”

The core API reference identifies BaseIndex as the shared reference entry point for index implementations. That matters because applications normally build a concrete index, then expose it through a query engine or another higher-level interface. The concrete source examples here show three contrasting designs: SummaryIndex stores chunks in a list and synthesizes over them, TreeIndex builds a hierarchy of summaries, and KeywordTableIndex maps extracted keywords to chunks. Official framework docs also position VectorStoreIndex as the most common index for semantic retrieval over embeddings, while graph-oriented indexes support relationship-heavy retrieval patterns. Sources: docs/api_reference/api_reference/indices/index.md, llama-index-core/llama_index/core/indices/list/README.md, llama-index-core/llama_index/core/indices/tree/README.md, llama-index-core/llama_index/core/indices/keyword_table/README.md

Relevant Source Files

• docs/api_reference/api_reference/indices/index.md — Declares the API reference page for llama_index.core.indices.base and the BaseIndex member, anchoring the shared index abstraction.
• llama-index-core/llama_index/core/indices/list/README.md — Documents SummaryIndex, including construction from documents, list-based storage, and create-and-refine query behavior.
• llama-index-core/llama_index/core/indices/tree/README.md — Documents TreeIndex, including bottom-up tree construction, parent summaries, default traversal queries, retrieve mode, and cost/runtime notes.
• llama-index-core/llama_index/core/indices/keyword_table/README.md — Documents KeywordTableIndex, including keyword extraction, keyword-to-chunk lookup, default, simple, and rake query modes, and runtime notes.

Index Families at a Glance

VectorStoreIndex is usually the first index to consider for retrieval-augmented generation. The official indexing guide describes it as splitting documents into nodes, embedding every node, and making those embeddings available for semantic search. Use it when users may ask questions using wording that differs from the original documents, because embeddings compare meaning rather than exact terms. It is also the natural fit when you plan to use a vector database or vector-store integration for persistence, filtering, hybrid retrieval, or production-scale nearest-neighbor search.

SummaryIndex is simpler and more sequential. Its README describes a list-based structure: construction chunks input text and concatenates those chunks into a list, without calling GPT during index construction. Querying then uses a create-and-refine paradigm, where the first chunk produces an initial answer and later chunks refine, edit, preserve, or rewrite that answer. Choose this family when the dataset is small enough to scan in order, when recall is more important than search selectivity, or when you want predictable synthesis across a bounded corpus. Sources: llama-index-core/llama_index/core/indices/list/README.md

TreeIndex is useful when hierarchical summarization is part of the retrieval strategy. The README describes bottom-up construction: documents are chunked, parent nodes summarize child nodes using a summarization prompt, and intermediate nodes contain summaries of the content beneath them. At query time, the default mode traverses top-down by repeatedly selecting the child node that best answers the query, while retrieve mode uses root nodes as context for synthesis. This makes the tree family a good match for large collections where progressive summarization and logarithmic-style traversal are useful. Sources: llama-index-core/llama_index/core/indices/tree/README.md

KeywordTableIndex is the source-backed keyword-oriented option in this page’s evidence. During construction, it chunks documents, extracts relevant keywords or phrases with a keyword extraction prompt, and stores a table from keywords to the referenced chunks. During querying, the default mode extracts keywords from the query, fetches candidate chunk IDs, ranks them by matching keyword count, truncates after a configured cutoff, and then synthesizes with create-and-refine. The simple mode uses regex-style keyword extraction with stopword filtering, while rake uses the RAKE keyword extractor. Sources: llama-index-core/llama_index/core/indices/keyword_table/README.md

Knowledge graph and property graph indexes belong to the relationship-centric side of the index family. Use them when the important retrieval unit is not only a chunk of text but an entity, relationship, path, or graph neighborhood. A knowledge graph index is appropriate when the application benefits from extracted triples or entity relationships; a property graph approach is appropriate when nodes and relationships need richer attributes and graph-store-backed traversal. In practice, graph indexes complement vector retrieval: vectors help find semantically similar passages, while graphs help follow explicit connections across entities, facts, and structured relationships.

System-to-Code Mapping

The shared shape across these families is that construction turns documents into an index-specific organization, and querying turns that organization into context for an LLM-facing response. The difference is where selectivity happens. Vector indexes select by embedding similarity, keyword tables select by term matches, tree indexes select by hierarchical traversal, summary indexes avoid selective retrieval and instead refine over an ordered list, and graph indexes select by relationships. When debugging answer quality, inspect the selection mechanism first: poor embeddings, weak keywords, shallow summaries, or missing relationships all lead to different failure modes.

Construction and Query Flow

A minimal index workflow starts by loading documents, building an index from those documents, creating a query engine, and issuing a query. The README examples for SummaryIndex, TreeIndex, and KeywordTableIndex use the same public pattern, which is valuable because it lets you swap index families while preserving the surrounding application shape. The common example imports the index class and SimpleDirectoryReader, loads a local data directory, calls from_documents, then calls as_query_engine() and query(). Sources: llama-index-core/llama_index/core/indices/list/README.md, llama-index-core/llama_index/core/indices/tree/README.md, llama-index-core/llama_index/core/indices/keyword_table/README.md

from llama_index.core import SummaryIndex, SimpleDirectoryReader
 
documents = SimpleDirectoryReader("data").load_data()
index = SummaryIndex.from_documents(documents)
query_engine = index.as_query_engine()
response = query_engine.query("<question text>")

The same shape works for the tree and keyword examples by replacing the index class. That API consistency is intentional from a user perspective: the index family is an implementation decision, while the query engine becomes the application-facing interface. The construction phase is where the largest behavioral differences appear. SummaryIndex does not call GPT during construction, TreeIndex uses summarization prompts to form parent nodes, and KeywordTableIndex uses a keyword extraction prompt unless a non-GPT query mode is selected later. Those differences affect cost, latency, build-time dependencies, and update strategies.

Choosing an Index

Choose VectorStoreIndex for most new RAG applications, especially when the corpus is unstructured text and users will ask natural-language questions. Choose SummaryIndex when you want comprehensive synthesis over a small or already-filtered set of chunks. Choose TreeIndex when hierarchical summarization can reduce query work or when a summarized outline of the corpus is itself useful. Choose KeywordTableIndex when exact terms, names, phrases, or controlled vocabulary are strong retrieval signals, or when you want a keyword-first retrieval path alongside semantic retrieval.

Cost and runtime should influence the decision as much as answer style. The tree README explicitly discusses why a tree can be cheaper than walking every chunk, because traversal can be closer to logarithmic in the number of nodes, though construction requires summarization. The keyword table README notes a query runtime shaped by extracted keywords and chunks per query, while limiting GPT calls by the configured chunk cutoff. Summary-style querying is easy to understand but can become expensive if too many chunks must be refined through the LLM. Sources: llama-index-core/llama_index/core/indices/tree/README.md, llama-index-core/llama_index/core/indices/keyword_table/README.md, llama-index-core/llama_index/core/indices/list/README.md

For production systems, it is common to combine families rather than pick only one. A vector index can retrieve semantically relevant nodes, a keyword table can preserve precision for product names or codes, and a graph index can expand from a matched entity to related facts. The index is only one layer of the RAG stack: readers, node parsers, embeddings, storage, retrievers, response synthesis, and query engines all shape the final behavior. After choosing an index family, read the retriever and query engine docs next so the selected structure is exposed through the right application interface.