Key facts
| Endpoint | POST /v1/embeddings (OpenAI-compatible) |
| Models | plugsky-embed, plugsky-embed-multilingual and plugsky-embed-nim in a 30+ model catalogue |
| Input limit | 8K-class text per request; live limits published per model |
| Vector dimension | Published per model on /models — read it before creating a collection |
| Use cases | RAG, semantic search, clustering and recommendations |
| Indexing | Batch embeddings for large corpora; re-embed when the model version changes |
| Sensitive retrieval | Region-locked vectors with scoped keys and retrieval audit metadata |
| Governance | Scoped keys and audit metadata for retrieval pipelines |
TL;DR
- OpenAI-compatible /v1/embeddings with the plugsky-embed family in a 30+ model catalogue.
- Dimension is published per model — read it before creating the collection.
- Treat the vector store as sensitive data, not a cache.
- Prove retrieval on policy content before indexing customer data.
- Start free with plugsky-micro and plugsky-lite; a 14-day full-access trial covers larger models.
How it works, step by step
- Read the model's live vector dimension from the catalogue and create the collection with it.
- Chunk by document structure, embed in batches, and store metadata for citations.
- Validate retrieval on a labelled question set before moving to production traffic.
- Pilot on policy and procedure content with a labelled question set.
- Redact identifiers before embedding and scope keys per pipeline.
- Plan re-embedding as a migration whenever the model changes.
Original data
Try it yourself
Open the embedding model comparison →
Embeddings for banks: what changes
Banks use embeddings for document search, policy retrieval, KYC review and internal assistant workflows, all of which touch sensitive text. The architecture question is not the vector math but where vectors, metadata and logs live, and how retrieval access is governed.
Plugsky exposes an OpenAI-compatible /v1/embeddings endpoint with the plugsky-embed family inside a 30+ model catalogue: plugsky-embed for English-dominant corpora, plugsky-embed-multilingual for mixed languages such as Arabic and English, and plugsky-embed-nim for teams standardised on NVIDIA-style profiles. Inputs are 8K-class per request, and each model's vector dimension is published on the model catalogue — read it before you create the collection.
Architecture and controls
Pin embedding workloads to an approved plane, scope keys per pipeline, and keep vector stores inside the same boundary as the source documents. Redact account identifiers before embedding, and log retrieval activity so decisions can be reconstructed.
Integration pattern and rollout
Start with policy and procedure search, where sensitivity is lower and success is easy to measure. Chunk by document structure, store citations as metadata, and validate retrieval with a labelled question set before widening to customer data.
Treat the dimension as a schema contract. When you change embedding models the vectors change, so plan a new collection and a backfill rather than an in-place swap. Chunk by document structure, store metadata alongside vectors, and combine vector similarity with keyword search and a reranker for production retrieval. Batch indexing jobs and re-embed only when the model version or chunking strategy changes.
Limits, evidence and cost
Embeddings are not encryption: vectors can leak information about their source text, so treat the vector store as sensitive data. Plan re-embedding as a project when models change, because dimensions and similarity behaviour change with the model.
Embeddings are available on platform plans — see the live pricing page for current tiers. Start free with plugsky-micro and plugsky-lite and no card to build the application layer, then add the indexing workload when retrieval is on the roadmap. The 14-day full-access trial covers larger models.
Honest comparison
| Concern | Plugsky embeddings | Typical API provider | Self-hosted embedder |
|---|---|---|---|
| API shape | OpenAI-compatible /v1/embeddings | Usually compatible, varies | Custom serving stack |
| Model choice | plugsky-embed family inside a 30+ model catalogue | Provider catalogue only | You package each model |
| Residency | Region-locked planes; VPC, on-prem and air-gapped | Limited region choices | Wherever you deploy |
| Dimension changes | Read live dimension from /models; plan new collections | Varies by provider | You manage every migration |
| Operational load | Managed endpoint with batching | Managed endpoint | GPU capacity, patching and autoscaling |
| Sensitive retrieval | Region-locked vectors with scoped keys and audit | Varies by provider | You govern the store |
Frequently asked questions
Do we need to re-embed when we change models?
Yes. Vectors depend on the model and dimensions can change. Plan a new collection, backfill, validate, then cut over — re-embedding is a data migration, not a config flip.
Are embeddings region-locked?
Yes, when the workload is pinned to a region-locked plane. Keep the vector store, backups and logs in the same jurisdiction as the source data.
Which embedding model should we start with?
plugsky-embed for English-dominant corpora, plugsky-embed-multilingual for mixed languages, and plugsky-embed-nim for NVIDIA-style profiles. Evaluate on your own content.
Are vectors as sensitive as source documents?
They can reveal information about their source, so treat the vector store as sensitive data: region-lock it, scope access and log retrieval.
Which model should we start with?
Use the default plugsky-embed for English-dominant policy and procedure content, and evaluate on a labelled question set before wider rollout.
How do we migrate when models change?
Build a new collection, backfill with the new model, validate retrieval, then switch over. Do not overwrite vectors in place.