Query Playground
The Retrieval Query panel lets you ask a document store a question and see exactly which chunks come back — before any flow depends on it.
Testing what your store returns
Most "the bot gave a wrong answer" problems are retrieval problems, not model problems. The model answered perfectly well from the passages it was given; the passages were the wrong ones.
The playground separates the two. If the right passage comes back here, retrieval is fine and the issue is in the prompt. If it doesn't, no prompt will save you.
Running a query
Open a store, choose Retrieval Query, and type a question the way a customer would ask it — misspellings, missing context, half a sentence. Testing with the phrasing from your own documentation is the classic mistake: of course it matches, you wrote both.
You get back the top matching chunks in relevance order, each with its text. There are no numeric similarity scores on screen — the ranking is the signal.
Reading the results
Read them as an ordered list and ask three things:
| What you see | What it means |
|---|---|
| The right passage is first | Healthy. The store knows the answer |
| The right passage is there, but third or fourth | Chunking or the number of retrieved chunks needs work |
| Related-but-not-useful passages fill the list | The question isn't well covered by what you loaded |
| Nothing relevant at all | The content isn't in the store, or the store was never upserted |
That last case is worth checking before you change anything. Retrieval Query is only selectable once the store is Upserted; and a store edited since its last upsert is still searching the older content, with no badge change to warn you. Upsert and try again.
Tuning retrieval before you wire it into a flow
Work through the levers in this order — the earlier ones matter more:
- Is the content there? Look at the chunks. You can't retrieve what you never loaded.
- Is it chunked sensibly? A passage split across two chunks matches neither well. See Chunking.
- How many chunks come back? Too few and the answer misses context; too many and the real answer is buried in noise. Three to five is a common setting.
- Is the embedding model right for the language? Multilingual content needs a multilingual model.
Test five or six real customer questions — the vague ones especially. When those come back with the right passage on top, wire the store into a Retriever node and build the flow around it.
Keep the questions you test with. When you add documents later, re-running the same set tells you in a minute whether you improved retrieval or quietly broke it.
Related
- Vector store — embeddings and upserting
- Chunking — the setting that most affects these results
- Retriever node — using the store in a flow