Embedding Integrations
Purpose and Scope
Embedding integrations are the model layer that turns text into vectors for retrieval, semantic search, reranking-adjacent workflows, and evaluation. In LlamaIndex, an embedding model is not treated as an isolated utility; it participates in indexing, query-time retrieval, and any component that needs to compare meaning rather than exact tokens. This page orients you to the common embedding contract exposed by the core package and to the provider-specific implementations documented in the API reference for OpenAI, Hugging Face, Bedrock, Cohere, and FastEmbed.
Sources: docs/api_reference/api_reference/embeddings/index.md, docs/api_reference/api_reference/embeddings/openai.md, docs/api_reference/api_reference/embeddings/huggingface.md, docs/api_reference/api_reference/embeddings/bedrock.md, docs/api_reference/api_reference/embeddings/cohere.md, docs/api_reference/api_reference/embeddings/fastembed.md
The key idea is separation between the application-facing abstraction and the concrete provider adapter. Application code should be able to depend on the embedding interface while changing providers for hosted APIs, managed cloud services, local models, or faster inference backends. The generated API reference reflects that split: the shared surface lives under the core embeddings module, while each integration page points to a provider module and its exported embedding class or classes. That is the stable mental model to use when choosing an implementation.
Relevant Source Files
- docs/api_reference/api_reference/embeddings/index.md — Documents the core embedding API reference entry with BaseEmbedding and resolve_embed_model.
- docs/api_reference/api_reference/embeddings/openai.md — Documents the OpenAI embedding integration module and OpenAIEmbedding class.
- docs/api_reference/api_reference/embeddings/huggingface.md — Documents Hugging Face embedding integrations, including HuggingFaceEmbedding and HuggingFaceInferenceAPIEmbedding.
- docs/api_reference/api_reference/embeddings/bedrock.md — Documents the Bedrock embedding integration module and BedrockEmbedding class.
- docs/api_reference/api_reference/embeddings/cohere.md — Documents the Cohere embedding integration module and CohereEmbedding class.
- docs/api_reference/api_reference/embeddings/fastembed.md — Documents the FastEmbed embedding integration module and FastEmbedEmbedding class.
Core API Surface
The core embedding reference exposes BaseEmbedding and resolve_embed_model from the core embeddings module. BaseEmbedding is the common type to look for when a LlamaIndex component asks for an embedding model, and resolve_embed_model is the resolver entry point named by the public docs for converting an embedding model setting into the object used at runtime. Even when you select a provider-specific implementation, the rest of the framework can reason about it through the core embedding abstraction rather than through provider-only APIs.
Sources: docs/api_reference/api_reference/embeddings/index.md
This contract matters most at the boundaries between ingestion and retrieval. During ingestion, documents are parsed into units that can be embedded and placed into a vector-capable index or vector store. During retrieval, the incoming query is embedded with a compatible model so the system can compare the query vector with stored vectors. If those two stages use different dimensions or incompatible models, retrieval quality can degrade or fail. The API reference’s emphasis on BaseEmbedding helps make that dependency explicit without forcing every caller to know provider internals.
Provider Integration Families
The OpenAI integration is represented by OpenAIEmbedding in the llama_index.embeddings.openai module. Use this family when your application standardizes on OpenAI-hosted embedding models and wants a direct provider adapter behind the same LlamaIndex embedding interface. The API reference page is intentionally narrow: it names the integration module and the exported class, which is enough to distinguish it from LLM chat or completion integrations. In application documentation and code review, treat OpenAIEmbedding as the embedding provider, not as a general OpenAI client.
Sources: docs/api_reference/api_reference/embeddings/openai.md
The Hugging Face page exposes two public classes: HuggingFaceEmbedding and HuggingFaceInferenceAPIEmbedding. That distinction is useful because Hugging Face can mean different execution modes: a model running in a local or library-backed environment, or a model accessed through an inference API. The reference does not spell out constructor options in the supplied evidence, but it does establish that LlamaIndex keeps both forms in the same provider family. Choose between them based on whether your deployment owns the model runtime or delegates inference to a hosted endpoint.
Sources: docs/api_reference/api_reference/embeddings/huggingface.md
BedrockEmbedding and CohereEmbedding represent managed-provider integrations for Amazon Bedrock and Cohere respectively. They follow the same pattern as the other provider classes: each lives in its provider module and is documented as the public member for that integration page. FastEmbedEmbedding represents the FastEmbed integration, which is useful to consider when you want an embedding implementation that is packaged as a dedicated embedding backend rather than a broad LLM provider adapter. All of these should be evaluated through the same application questions: model availability, latency, deployment environment, authentication, cost, and vector compatibility.
Sources: docs/api_reference/api_reference/embeddings/bedrock.md, docs/api_reference/api_reference/embeddings/cohere.md, docs/api_reference/api_reference/embeddings/fastembed.md
System-to-Code Mapping
| Reader task | Public entry point shown in the docs | Source page |
|---|---|---|
| Depend on the common embedding abstraction | BaseEmbedding | docs/api_reference/api_reference/embeddings/index.md |
| Resolve configured embedding models | resolve_embed_model | docs/api_reference/api_reference/embeddings/index.md |
| Use OpenAI embeddings | OpenAIEmbedding | docs/api_reference/api_reference/embeddings/openai.md |
| Use Hugging Face embeddings locally or through Hugging Face-specific paths | HuggingFaceEmbedding, HuggingFaceInferenceAPIEmbedding | docs/api_reference/api_reference/embeddings/huggingface.md |
| Use Amazon Bedrock embeddings | BedrockEmbedding | docs/api_reference/api_reference/embeddings/bedrock.md |
| Use Cohere embeddings | CohereEmbedding | docs/api_reference/api_reference/embeddings/cohere.md |
| Use FastEmbed embeddings | FastEmbedEmbedding | docs/api_reference/api_reference/embeddings/fastembed.md |
The practical mapping is simple: application code should configure one embedding implementation, and downstream LlamaIndex components should consume it as an embedding model rather than branching on provider. For example, a vector indexing workflow might start with a provider class such as OpenAIEmbedding or HuggingFaceEmbedding, then pass that model into indexing or settings code elsewhere in the framework. The exact wiring depends on the surrounding guide, but the public API reference tells you which class names are meant to be imported from each provider package.
Selection Guidance and Next Steps
Start by deciding where embeddings will run. If your organization already uses OpenAI, Cohere, or Bedrock, the corresponding provider class keeps LlamaIndex aligned with that platform. If you need Hugging Face model choice, compare the locally oriented Hugging Face class with the inference API class. If you are optimizing for a dedicated embedding backend, evaluate FastEmbedEmbedding. After choosing, verify that the same model family and vector dimensionality are used for both indexing and querying, because embedding consistency is part of the retrieval contract.
For a deeper implementation path, continue with the pages on models and settings, vector store indexing, retrievers, and evaluation. Models and settings explain where embedding objects are configured in a full application. Vector store indexing shows where embeddings are persisted and searched. Retriever documentation explains how query embeddings are used at runtime. Evaluation documentation is the right next stop when you need to measure whether the selected embedding model improves retrieval quality rather than only whether it runs successfully.