Key facts
| Pipeline | Article ingestion → chunking → embeddings → cited answers |
| Embeddings | plugsky-embed and plugsky-embed-multilingual via /v1/embeddings (live) |
| Generation | Streaming and JSON mode on /v1/chat/completions (live) |
| Metadata | Product, version, locale and updated date stored per chunk |
| Models | 30+ models behind one endpoint, mix per workflow |
| Persistence | Vector database choice remains yours; standard float vectors |
| Residency | Region-locked planes, VPC, on-prem and air-gapped options |
| Free tier | plugsky-micro and plugsky-lite on the free plan, no card required |
TL;DR
- Chunk by article and section so retrieval returns complete, coherent guidance.
- Tag product, version and locale metadata to keep answers specific to the user.
- Embed once per content change and re-index on publish, not on a slow schedule.
- Require citations and let the assistant link every claim back to the article.
- Use unanswered questions to drive content fixes, not just prompt tweaks.
How it works, step by step
- Export the knowledge corpus — help articles, product docs, internal guides — with canonical URLs, owners and update timestamps.
- Chunk by article and heading, keeping titles and section labels in each chunk for context.
- Embed chunks with plugsky-embed and store vectors with product, version, locale and updated-date metadata.
- Build retrieval that filters by product and locale, ranks with a blend of keyword and vector scores, and returns passages with source IDs.
- Generate answers that must cite their sources, admit when the corpus is silent, and present conflicting guidance side by side.
- Return a structured response with the answer, source links and a fallback list for low-confidence cases.
- Review zero-result and low-rated queries monthly, update content, and re-index automatically on publication.
Original data
Try it yourself
Open the vector database comparison →
Indexing a knowledge corpus properly
Knowledge corpora have natural units: the article and its sections. Chunking along those boundaries keeps each retrieved passage understandable on its own, and carrying the article title into every chunk preserves context that a fixed-size splitter destroys. Store the canonical URL so answers can cite and link precisely.
Metadata does the heavy lifting for specificity. Product, version, locale and updated date let retrieval return the article that matches the reader's situation rather than the most similar text in the whole corpus. The model layer is live on Plugsky through /v1/embeddings and /v1/chat/completions; your content store and vector database stay under your control.
Ranking, citations and conflict handling
Pure vector similarity will surface an outdated article that reads like the answer. Blend in keyword matching for product names and error codes, then apply recency and status signals so current, approved articles win. When two passages disagree, the assistant should show both with links rather than pick silently — readers can judge, and content owners get a signal.
- Citations: require a source for every claim and render deep links next to the answer.
- Refusals: train the behaviour to admit gaps and offer the closest articles instead of improvising.
- Feedback: capture thumbs-down with the retrieved passages to distinguish bad content from bad retrieval.
Keeping the assistant current
Freshness is an operational discipline, not a model feature. Re-index automatically when an article is published or retired, keep the previous version until the new one is live, and mark deprecated content so retrieval can demote it. Locale variants should be tagged, not merged, so a French question retrieves French content when it exists.
Evaluate on a question set drawn from real support traffic: citation accuracy, resolution rate, and correctness of routing when the answer is not in the corpus. Route simple lookups to plugsky-micro or plugsky-lite and reserve larger models for multi-article synthesis. Where content cannot leave your environment, the same pipeline runs in a region-locked plane or fully on-prem with Plugsky deployments.
Honest comparison
| Capability | Plugsky RAG assistant | FAQ widget | Fine-tuned support model |
|---|---|---|---|
| Answer basis | Retrieved articles with citations | Pre-written entries | Learned weights |
| Update process | Re-index on article publish | Manual edits | Retrain and redeploy |
| Locale handling | Metadata filters per locale | Separate pages | Varies |
| Model choice | 30+ models behind one endpoint | None | One fixed model |
| Residency | Region-locked planes, VPC, on-prem, air-gapped | Static hosting | Vendor-controlled |
Frequently asked questions
How should we chunk help articles?
By article and section, keeping titles and headings in the chunk. This preserves meaning per passage and produces citations that point to the right section rather than the whole article.
Which embedding model fits knowledge bases?
plugsky-embed covers English-heavy corpora; plugsky-embed-multilingual is the better fit when help content and questions span languages such as Arabic and English.
Do we need to re-embed everything when an article changes?
Only the affected chunks. Incremental re-indexing by document ID keeps the operation cheap and lets publish events trigger updates.
Can the assistant answer version-specific questions?
Yes, if you store product and version metadata and filter retrieval by the user's context. Without those filters the most similar text may come from the wrong version.
How do we handle languages?
Tag chunks with locale, filter at retrieval, and use the multilingual embedding model so cross-language questions still land on the right article.
What should happen when nothing matches?
The assistant should say the knowledge base lacks the answer, offer the closest articles and log the query. Those logs become the content backlog.
Can it run on-prem?
Yes. Plugsky supports region-locked cloud planes plus VPC, on-prem and air-gapped deployment, so knowledge content can stay within your environment.