Skip to main content
An Embedding Model converts text (and, for multimodal models, images, videos, and other media) into dense vectors that power semantic search, RAG, and memory retrieval. AgentScope currently ships the following embedding model classes:

Create Embedding Model

Every embedding model takes a credential, a model name, and an optional Parameters object, the same pattern as chat models. Parameters carries dimensions, the output vector size:
Common constructor arguments shared by every embedding model:
Valid dimensions values differ per model: each model card pins the default via its top-level dimensions field and the allowed values via supported_dimensions (e.g. text-embedding-v4 accepts 2048 / 1536 / 1024 / … / 64). See EmbeddingModelCard.

Call Embedding Model

Invoke the model by calling it with a list of inputs. Text-only models accept list[str]; multimodal models also accept DataBlock elements:
Batching and retry are handled for you:
  1. Inputs are split into chunks of the model’s batch size (10 for DashScope text, 2048 for OpenAI, 100 for Gemini, 512 for Ollama).
  2. All chunks are dispatched concurrently via asyncio.gather.
  3. Each chunk is retried independently up to max_retries times on provider-specific retryable errors.
  4. Results are merged into a single EmbeddingResponse, preserving input order.
Each EmbeddingResponse carries:

Multimodal Embedding

Multimodal models (DashScopeEmbeddingModel with qwen3-vl-embedding etc., GeminiEmbeddingModel with gemini-embedding-2) accept DataBlock inputs alongside strings (images as URL or base64, videos as URL):
Multimodal models replace the plain batch-size split with content-aware batching: inputs are greedily packed into batches that respect the model’s per-request limits on total elements, images, and videos (e.g. qwen3-vl-embedding allows 20 elements / 5 images / 1 video per request, tongyi-embedding-vision-plus allows 20 / 64 / 8). You never need to split inputs yourself.

Embedding Cache

Pass an EmbeddingCacheBase implementation through the embedding_cache argument to reuse previously computed vectors. The built-in FileEmbeddingCache stores each result as a .npy file keyed by the SHA-256 hash of the request:
When max_file_number or max_cache_size is exceeded, the oldest files are evicted first. To use a different backend (Redis, SQLite, …), subclass EmbeddingCacheBase and implement its four methods: store, retrieve, remove, and clear.

Custom Embedding Provider

Adding an embedding provider follows the same steps as a custom chat provider. Override get_embedding_model_class() on your credential (the base implementation returns None, meaning “no embedding support”):

Step 2: Implement the Embedding Model

Subclass EmbeddingModelBase and implement _call_api for a single batch; batching, concurrency, and retry are inherited from the base class. Declare provider-specific transient errors via _get_retryable_exceptions:
Bind the generic parameter to the input type your provider supports: EmbeddingModelBase[str] for text-only, EmbeddingModelBase[str | DataBlock] for multimodal, so IDEs surface the correct inputs type to callers.

Step 3: Add Model Cards (optional)

Drop YAML files into a _models/ directory next to your implementation; MyProviderEmbeddingModel.list_models() then picks them up, exactly like chat model cards.

EmbeddingModelCard

EmbeddingModelCard mirrors the general ModelCard for the frontend, with embedding-specific defaults: the output type application/x-embedding marks a model as producing dense vectors. A typical YAML card (the real card for text-embedding-v4):
Retrieve cards from the model class directly, or discover the class from a credential via get_embedding_model_class():