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 |
| Minimisation | Redact identifiers before embedding clinical text where policy allows |
| Retrieval quality | Pair vector search with keyword matching and reranking |
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 a sensitive clinical dataset.
- Validate retrieval against real clinical questions before go-live.
- 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.
- De-identify content before embedding where policy allows.
- Evaluate retrieval with clinicians on a labelled question set.
- Enforce RBAC and retrieval auditing on the vector store.
Original data
Try it yourself
Open the embedding API tester →
Embeddings for healthcare teams: what changes
Healthcare retrieval runs across clinical notes, guidelines, policies and research, with strict rules about who may read what. Embeddings improve recall, but a vector store can become a shadow copy of sensitive text, so the pipeline must inherit the same protections as the source.
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
De-identify or redact before embedding where policy allows, keep vectors in the approved region or on-prem boundary, and enforce RBAC on retrieval so results respect the requester's access rights. Log retrieval events for audit.
Integration pattern and rollout
Validate on a labelled clinical question set before production: check whether the right passage arrives in the top results, and keep citations in metadata so clinicians can verify. Pair vector search with keyword matching for drug names, codes and rare terms.
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
Retrieval quality is corpus-specific and cannot be assumed from generic benchmarks. De-identification reduces but does not eliminate re-identification risk, so treat embeddings as sensitive and govern them accordingly.
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 text | Redaction plus boundary controls on vectors | Varies by provider | You own de-identification |
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.
How do we reduce PHI exposure in embeddings?
Redact identifiers before embedding where policy allows, restrict access to the vector store, and log retrieval events for audit.
Will retrieval find clinical terms reliably?
Add keyword matching for drug names, codes and rare terms, and evaluate against real clinical questions before relying on vector search alone.
Where should the vector store live?
In the same approved boundary as the source documents — region-locked, in your VPC, or on-prem.