{
  "id": "utilities",
  "title": "Utilities",
  "url": "https://redis.io/docs/latest/develop/ai/redisvl/0.17.0/concepts/utilities/",
  "summary": "",
  "content": "\n\nUtilities are optional components that enhance search workflows. They’re not required—you can bring your own embeddings and skip reranking—but they simplify common tasks.\n\n## Vectorizers\n\nA vectorizer converts text into an embedding vector. Embeddings are dense numerical representations that capture semantic meaning: similar texts produce similar vectors, enabling similarity search.\n\n### Why Vectorizers Matter\n\nCreating embeddings requires calling an embedding model—either a cloud API (OpenAI, Cohere, etc.) or a local model (HuggingFace sentence-transformers). Each provider has different APIs, authentication methods, and response formats.\n\nRedisVL vectorizers provide a unified interface across providers. You choose a provider, configure it once, and use the same methods regardless of which service is behind it. This makes it easy to switch providers, compare models, or use different providers in different environments.\n\n### The Dimensionality Contract\n\nEvery embedding model produces vectors of a specific size (dimensionality). OpenAI’s text-embedding-3-small produces 1536-dimensional vectors. Other models produce 384, 768, 1024, or other sizes.\n\nYour schema’s vector field must specify the same dimensionality as your embedding model. If there’s a mismatch—your model produces 1536-dimensional vectors but your schema expects 768—you’ll get errors when loading data or running queries.\n\nThis constraint means you should choose your embedding model before designing your schema, and changing models requires rebuilding your index.\n\n### Batching and Performance\n\nEmbedding APIs have rate limits and per-request overhead. Embedding one text at a time is inefficient. Vectorizers support batch embedding, sending multiple texts in a single request. This dramatically improves throughput for indexing large datasets.\n\nVectorizers handle batching internally, breaking large batches into provider-appropriate chunks and respecting rate limits. You provide a list of texts; the vectorizer manages the logistics.\n\n### Supported Providers\n\nRedisVL includes vectorizers for OpenAI, Azure OpenAI, Cohere, HuggingFace (local), Mistral, Google Vertex AI, AWS Bedrock, VoyageAI, and others. See the [Vectorizers](../api/vectorizer.md) for the complete list. You can also create custom vectorizers that wrap any embedding function.\n\n## Rerankers\n\nA reranker takes initial search results and reorders them by relevance to the query. It’s a second-stage filter that improves precision after the first-stage retrieval.\n\n### Why Reranking Works\n\nVector search uses bi-encoder models: the query and documents are embedded independently, then compared by vector distance. This is fast but approximate—the embedding captures general meaning, not the specific relationship between query and document.\n\nRerankers use cross-encoder models that score query-document pairs directly. The model sees both the query and document together and predicts a relevance score. This is more accurate but slower, because each candidate requires a separate model inference.\n\nThe combination is powerful: use fast vector search to retrieve a broad set of candidates (high recall), then use the slower but more accurate reranker to select the best results (high precision).\n\n### The Recall-Precision Trade-off\n\nWith only vector search, you might retrieve 10 results and hope the best one is in there. With reranking, you can retrieve 50 candidates—casting a wider net—then rerank to find the 5 best. The initial retrieval prioritizes recall (not missing relevant documents); reranking prioritizes precision (surfacing the most relevant ones).\n\n### Cost and Latency\n\nReranking adds latency (typically 50-200ms depending on the provider and number of candidates) and cost (API-based rerankers charge per request). These trade-offs are usually worthwhile when result quality matters, but you should measure the impact for your use case.\n\n### Supported Providers\n\nRedisVL includes rerankers for HuggingFace cross-encoders (local), Cohere Rerank API, and VoyageAI Rerank API.\n\n## Two-Stage Retrieval\n\nThe most effective retrieval pipelines combine both utilities: vectorize the query, retrieve a candidate set with vector search, then rerank to select the final results.\n\nThis pattern separates recall (finding everything potentially relevant) from precision (selecting the best matches). Vector search handles recall efficiently; reranking handles precision accurately. Together, they deliver better results than either approach alone.\n\n---\n\n**Related concepts:** [Query Types](queries.md) explains how to use embeddings in vector search queries. [Search \u0026 Indexing](search-and-indexing.md) covers schema configuration for vector fields.\n\n**Learn more:** [Create Embeddings with Vectorizers](../user_guide/04_vectorizers.md) covers embedding providers. [Rerank Search Results](../user_guide/06_rerankers.md) explains reranking in practice.\n",
  "tags": [],
  "last_updated": "2026-04-21T14:39:33+02:00"
}