Indices API

Purpose and Scope

The Indices API page is the reference entrypoint for the LlamaIndex index classes that turn parsed application data into queryable structures. In LlamaIndex terminology, an index is the data structure that sits between source data and retrieval or query execution. It determines how nodes are organized, what storage backends participate, and which retrieval strategy is natural for an application. This page is intentionally focused on the public reference surface named by the official API pages: the base index abstraction, vector, summary, tree, keyword, and property graph index families.

Sources: docs/api_reference/api_reference/indices/index.md, docs/api_reference/api_reference/indices/vector.md, docs/api_reference/api_reference/indices/summary.md, docs/api_reference/api_reference/indices/tree.md, docs/api_reference/api_reference/indices/keyword.md, docs/api_reference/api_reference/indices/property_graph.md

Use this page when you need to choose the correct index class before reading the deeper conceptual pages. The API reference files expose the classes through mkdocstrings member lists, which means the official docs are organized around importable public classes rather than prose-only tutorials. That matters for developers because the same class names are the objects you will instantiate, configure, persist, convert into retrievers, or wrap with query engines. Treat this page as a map from indexing intent to the reference page where the exact constructor and inherited methods are documented.

Relevant Source Files

• docs/api_reference/api_reference/indices/index.md — exposes the base indices reference page for llama_index.core.indices.base and lists BaseIndex as the documented member.
• docs/api_reference/api_reference/indices/vector.md — exposes the vector index reference page for llama_index.core.indices and lists VectorStoreIndex.
• docs/api_reference/api_reference/indices/summary.md — exposes the summary index reference page for llama_index.core.indices and lists SummaryIndex.
• docs/api_reference/api_reference/indices/tree.md — exposes the tree index reference page for llama_index.core.indices and lists TreeIndex, with the root heading suppressed in that page configuration.
• docs/api_reference/api_reference/indices/keyword.md — exposes the keyword index reference page for llama_index.core.indices and lists KeywordTableIndex, SimpleKeywordTableIndex, and RAKEKeywordTableIndex.
• docs/api_reference/api_reference/indices/property_graph.md — exposes the property graph reference page for llama_index.core.indices and lists the property graph index, retriever classes, and path extractor classes.

Public API Families

The smallest common denominator is BaseIndex, documented from llama_index.core.indices.base. It is the conceptual contract behind the concrete index classes: an index stores or references indexed data and provides the bridge into retrieval-oriented application components. When you read the class-specific pages, look for the behavior inherited from the base class before assuming that an operation belongs only to one index family. This is especially useful when moving from an initial prototype to a production design, because many LlamaIndex examples begin with one concrete index but rely on shared base-index conversion patterns later.

Sources: docs/api_reference/api_reference/indices/index.md

VectorStoreIndex is the reference entry for embedding-backed semantic retrieval. Its API page is generated from llama_index.core.indices, which signals that vector indexing is part of the core index surface rather than only an external vector database adapter. In practice, this index family is the default starting point for RAG applications that need similarity search over chunks or nodes. The index coordinates the relationship between embedded node content, the vector store abstraction, and higher-level retrievers or query engines. Read this page together with vector store and embedding references when tuning storage, metadata filters, or retrieval depth.

Sources: docs/api_reference/api_reference/indices/vector.md

SummaryIndex and TreeIndex represent two non-vector organization strategies. SummaryIndex is documented as a core index member and is useful when the access pattern is closer to sequential summarization, broad synthesis, or small-corpus querying than embedding similarity. TreeIndex is also documented as a core index member and represents hierarchical organization, where query-time traversal can trade off breadth, depth, and LLM calls. The official cost-analysis docs distinguish these families by build-time and query-time cost characteristics: SummaryIndex can be free to build, while TreeIndex uses LLM summarization during construction. That cost profile should influence the class you choose as much as retrieval quality.

Sources: docs/api_reference/api_reference/indices/summary.md, docs/api_reference/api_reference/indices/tree.md

The keyword index reference groups three related classes: KeywordTableIndex, SimpleKeywordTableIndex, and RAKEKeywordTableIndex. They share the idea of mapping keywords to indexed content, but the extraction method differs. The official docs describe SimpleKeywordTableIndex as using a regex keyword extractor and RAKEKeywordTableIndex as using a RAKE keyword extractor, while KeywordTableIndex uses an LLM to extract keywords. This family is a good fit when lexical terms, explicit topic labels, or predictable domain vocabulary are more important than approximate semantic similarity. The API grouping makes it clear that these are alternative implementations within one reference family, not unrelated tools.

Sources: docs/api_reference/api_reference/indices/keyword.md

Property Graph Index and Graph Retrieval Surface

The property graph reference page is broader than a single index class. It lists PropertyGraphIndex, retriever base classes, concrete retrievers, and path extractors in one API page. That grouping is a strong signal about how graph RAG is structured in LlamaIndex: the index is only one part of the graph retrieval system. Applications also need retrievers that decide how graph context is found and extractors that turn source content into graph paths. Developers should read this reference as a small subsystem, not as a single constructor page.

Sources: docs/api_reference/api_reference/indices/property_graph.md

The documented retriever names show the supported graph retrieval styles. PGRetriever and BasePGRetriever establish the property graph retriever surface, while CustomPGRetriever provides an extension point for application-specific graph traversal or context collection. CypherTemplateRetriever and TextToCypherRetriever indicate Cypher-oriented retrieval patterns: one based on a template and another based on translating text into Cypher. LLMSynonymRetriever and VectorContextRetriever point to two complementary strategies, one using language-model synonym expansion and one using vector context. This API layout helps readers choose whether graph retrieval should be symbolic, semantic, LLM-assisted, or custom.

The extractor classes complete the graph indexing workflow. ImplicitPathExtractor, SchemaLLMPathExtractor, and SimpleLLMPathExtractor are listed beside the index and retrievers because graph RAG depends on how relationships are produced from source documents. A property graph index cannot provide useful traversal if the graph was built with the wrong extraction assumptions. Choose an extractor according to the structure of your domain: implicit paths may be suitable when relationships can be inferred from existing structure, schema-driven extraction is better when you need consistent entity and relation shapes, and a simpler LLM extractor can be useful while prototyping.

Compact Reference

Reference page	Public members named by the API docs	Primary use
docs/api_reference/api_reference/indices/index.md	BaseIndex	Shared base index abstraction and inherited index behavior.
docs/api_reference/api_reference/indices/vector.md	VectorStoreIndex	Embedding-backed semantic retrieval over indexed nodes.
docs/api_reference/api_reference/indices/summary.md	SummaryIndex	Sequential or broad synthesis patterns, often simple to build.
docs/api_reference/api_reference/indices/tree.md	TreeIndex	Hierarchical summary and traversal-based querying.
docs/api_reference/api_reference/indices/keyword.md	KeywordTableIndex, SimpleKeywordTableIndex, RAKEKeywordTableIndex	Lexical or keyword-driven lookup with different extraction strategies.
docs/api_reference/api_reference/indices/property_graph.md	PropertyGraphIndex, PGRetriever, BasePGRetriever, CustomPGRetriever, CypherTemplateRetriever, LLMSynonymRetriever, TextToCypherRetriever, VectorContextRetriever, ImplicitPathExtractor, SchemaLLMPathExtractor, SimpleLLMPathExtractor	Graph RAG indexing, retrieval, Cypher retrieval, vector context retrieval, and graph path extraction.

This compact table is a navigation aid rather than a replacement for the generated API pages. The member lists are the key contract visible in the source reference files, and the generated documentation will provide the method-level and signature-level details from the corresponding Python objects. When comparing classes, first decide whether your problem is semantic search, summarization, hierarchy, keyword lookup, or graph traversal. Then follow the matching reference page and inspect constructor arguments, retriever conversion methods, persistence behavior, and integration points with storage or query engines.

Selection and Execution Flow

A typical indexing flow begins after data has already been loaded and parsed into nodes. At that point, choose the index family that matches the retrieval question you expect users to ask. If users ask natural-language questions over unstructured content, VectorStoreIndex is usually the first API page to read. If users need complete corpus coverage or summarization, SummaryIndex may be simpler. If users need hierarchical summarization, TreeIndex becomes relevant. If exact vocabulary matters, start with the keyword page. If relationships among entities are central to the answer, move directly to the property graph API.

The cost characteristics of these choices are not identical. Official docs note that SummaryIndex, SimpleKeywordTableIndex, and RAKEKeywordTableIndex do not require LLM calls during build time, while TreeIndex and KeywordTableIndex do. Querying generally still requires at least one LLM call when synthesizing an answer. This distinction is important when indexing large corpora or running repeated rebuilds in CI, background ingestion, or tenant-specific deployments. API users should therefore treat index selection as both a retrieval-quality decision and an operational cost decision.

After choosing and constructing an index, the next step is usually to expose it through a retriever, query engine, or chat-oriented flow. The indices reference does not replace those downstream references; it identifies the classes that own the indexed representation. For example, graph applications may continue into the property graph retriever classes, while vector applications may continue into vector store integrations and retriever configuration. This separation keeps the mental model clean: index classes organize data, retrievers select context, and synthesis or engine layers produce user-facing answers.

Next Steps

If you are implementing a new RAG application, start with the vector and summary references, then compare keyword or graph APIs only when your data shape requires them. If you are maintaining an existing system, identify the concrete index class first and read its generated API page before changing storage, retriever mode, or query behavior. For broader context, continue to the Indexes, Vector Store Indexing, Retrievers, Query Engines, Storage API, and Property Graph RAG pages. Those pages explain the concepts surrounding this reference entrypoint and show how the index classes participate in full application workflows.