Embedding Models

Embeddings turn documents and indexed workspace content into vectors so RealTimeX can retrieve relevant context for chat, query, and retrieval workflows.

Open the embedding selector from Settings > AI Providers > Embedder.

What this setting controls

The Embedding Model page controls how RealTimeX vectorizes content before it is stored in the vector database.

This affects retrieval quality across features that depend on embeddings, including:

• workspace document search
• retrieval-backed chat and query flows
• any feature that relies on semantic similarity instead of exact keyword matching

Current provider types

The current app supports several kinds of embedding provider.

Built-in and managed options

• Native for built-in local embedding models
• RealTimeX Cloud for hosted embedding models without local setup

Hosted providers

Current hosted choices include:

• OpenAI
• Azure OpenAI
• Gemini
• Cohere
• Voyage AI
• Mistral AI

Local and self-hosted providers

Current local or self-hosted choices include:

• Local AI
• Ollama
• LM Studio
• llama.cpp

Compatibility layers and plugins

The current selector also supports:

• LiteLLM
• Generic OpenAI
• plugin-registered embedding providers

What you configure on this page

The fields shown under the selector depend on the provider you choose.

Common examples include:

• API keys
• base URLs
• deployment names
• embedding model names
• loaded model selectors for local runtimes
• maximum embedding chunk length

RealTimeX saves the provider choice and the provider-specific fields together, so you can keep the embedding configuration fully separate from chat model settings.

For the system-wide settings that decide how document text is segmented before vectorization, see Text Splitting & Chunking.

Changing the embedding model is destructive

If your instance already has embeddings or cached embedding data, changing the embedder is not a cosmetic change.

The current product warns that switching the embedding provider or model will:

• clear embeddings from the vector database
• remove documents from workspaces
• keep the uploaded source files available for re-embedding

This is an irreversible operation. Plan the change before switching production workspaces to a new embedder.

Embeddings vs vector database

The embedding model and the vector database solve different parts of retrieval:

• the embedding model decides how content is encoded into vectors
• the vector database decides where those vectors are stored and searched

Change the embedder when you want different retrieval behavior or a different provider.

Change the vector database when you want different storage, scaling, or infrastructure.

For storage choices, see Vector Databases.

Tips for stable retrieval

• Keep the same embedding model across workspaces when you want consistent retrieval behavior.
• Re-embed important workspaces after switching providers or models.
• Confirm local embedding endpoints are reachable before making them the system default.
• Treat chunk-length changes carefully, because they can alter how documents are segmented before embedding. Review Text Splitting & Chunking when you need to tune that behavior directly.