Key facts
| Tool type | Free browser sandbox for document ingestion and retrieval testing |
| Pipeline steps | Upload, chunk, embed, retrieve, generate, inspect |
| Settings to vary | Chunk size, overlap, top k and prompt template |
| Models | 30+ generation models plus embeddings from the catalogue |
| Inspection | Retrieved passages shown alongside the generated answer |
| RAG status | RAG, embeddings and agents are live |
| Free plan | 2 free AI models (plugsky-micro, plugsky-lite), no card required |
| Product status | Live |
TL;DR
- Test retrieval quality with real documents before writing pipeline code.
- Chunking and top-k change answers more than model choice in most systems.
- Inspect retrieved passages, not just the final answer, to find the real failure.
- Export winning settings — chunk size, overlap and k — into production configuration.
- Keep the test set so the same questions can re-run after any change.
How it works, step by step
- Upload a representative slice of your real documents, including messy ones.
- Choose an initial chunk size and overlap, then embed the corpus.
- Ask 10-20 real questions and read the retrieved passages before the answer.
- Adjust chunk size, overlap and top k, and re-run the same questions.
- Note which combination retrieves the gold passage reliably at a sensible rank.
- Test generation prompts on top of the best retrieval settings.
- Export the winning configuration and re-run the same questions in production.
Try it yourself
What the sandbox actually tests
The sandbox isolates the retrieval half of RAG so you can see it working. Documents are chunked and embedded, questions are converted into vectors, and the nearest chunks are returned alongside the generated answer. That view is the point: when an answer is wrong, you can tell within seconds whether the retriever surfaced the wrong passages or the model mishandled the right ones. Testing with a representative slice of real documents — including headers, tables and scanned text — exposes the parsing problems that toy corpora hide.
Iterating on the parameters that matter
Most RAG quality comes from three settings. Chunk size controls how much context each vector carries; too small and answers lack detail, too large and retrieval becomes imprecise. Overlap preserves meaning across boundaries, especially for procedures that span paragraphs. Top k decides how much material reaches the model: more raises recall but adds noise and tokens. Change one parameter at a time, re-run the same questions, and watch both the retrieved passages and the final answer. Embedding model choice is a fourth lever, and since Plugsky serves embeddings alongside 30+ generation models, you can test it without leaving the sandbox.
From sandbox to production
The sandbox is a decision tool, not a hosting environment. When the settings stabilise, export them: chunk size, overlap, top k, embedding model and the prompt template that worked. Recreate that pipeline in your own service, keep the same test questions as a regression suite, and monitor retrieval metrics in production — an index that drifts as documents change will silently degrade answers. Use the prompt diff and evaluator to compare production variants, and revisit settings when your corpus grows or changes shape.
Honest comparison
| Setting | What it changes | Symptom when wrong | First fix to try |
|---|---|---|---|
| Chunk size | Context per vector | Answers lack detail or retrieval misses | Halve or double, then re-test |
| Overlap | Continuity across chunk boundaries | Procedures cut mid-step | Increase overlap modestly |
| Top k | How much context reaches the model | Answer missing or buried in noise | Raise for recall, then trim |
| Embedding model | Semantic matching quality | Queries miss paraphrases | Test multilingual or domain-tuned embeddings |
| Prompt template | How context is used | Right passages, wrong answer | Constrain the prompt to the context |
Frequently asked questions
What is a RAG sandbox?
A browser environment where you upload documents, chunk and embed them, then ask questions and inspect the retrieved passages alongside the generated answer before building a production pipeline.
Do I need to write code?
No. The sandbox handles ingestion, chunking, embedding and retrieval so you can focus on choosing settings and prompts.
Which settings matter most?
Chunk size, overlap and top k usually dominate. Embedding model and generation model come next. Change one variable at a time to keep the comparison honest.
How many documents should I test with?
A representative slice is enough — a few dozen documents that include your messiest real content. Samples that are too clean hide parsing and chunking problems.
Can I reuse the settings in production?
Yes. Export chunk size, overlap, top k, embedding model and prompt, then recreate the pipeline in your own service with the same regression questions.
Does the sandbox support private documents?
Treat any hosted sandbox as a shared environment: use non-sensitive samples, and check the docs for data handling before uploading sensitive material.
How does retrieval relate to model choice?
A better model cannot fix missing context. Test retrieval first in the sandbox, then optimise the generation model on top of good retrieval.
Is there a free way to try it?
Yes. The free plan includes 2 free AI models with no card, and the sandbox is a free tool.