Collections
Document knowledge bases for retrieval-augmented runs
A Collection is a knowledge base for retrieval-augmented generation (RAG). You add documents to it, Rightbrain embeds them, and a Task can retrieve the most relevant passages at run time to ground its answer in your own content.
Collections are how you get grounded, source-backed output without stuffing everything into a prompt.
When to use a Collection
Use a Collection when a Task needs to answer from a specific body of knowledge — a product manual, a policy handbook, a support archive, a contract set — rather than the model’s general training. Wire the Collection into the Task’s RAG config and the Task retrieves the relevant chunks each time it runs.
Think of a support Collection for a product line: a return-policy document, a product manual, and warranty terms. A Task backed by it answers “can I return a blender after 45 days?” from your actual policy, synthesizes across documents when a question spans them, and correctly declines an out-of-scope question (“what’s the capital of France?”) instead of guessing.
Curate, don’t dump. A Collection of 10–50 well-structured documents will consistently outperform a bulk load of thousands of pages — retrieval quality comes from clean, well-scoped sources, not volume.
How it connects to Tasks and agents
This is the key relationship to get right:
- A Collection plugs into a Task through that Task’s revision RAG config (its per-collection retrieval options).
- An agent gets a Collection’s knowledge indirectly — through a Task tool whose revision has the Collection wired in.
Collections do not attach directly to an agent. Agents reach knowledge bases through Task tools. If you want an agent to use a Collection, put the Collection on a Task and attach that Task to the agent.
How a Collection is structured
A Collection groups embedded documents and carries a title, a summary, and optional metadata. Documents get there two ways:
- Direct upload — add files to the Collection.
- Datasource connectors — sync from a connected source: Box, Confluence, Dropbox, Google Drive, Notion, OneDrive, or SharePoint.
Once added, documents are embedded into a vector store (pgvector) and become queryable. You can query a Collection directly, inspect its stats, and refresh its summary.
Retrieval and tuning
At run time, retrieval is a short pipeline: the Task’s RAG config can first rewrite the incoming question into a cleaner search query, then a vector search pulls candidate chunks, the best of them are fitted to a context budget, and only that context reaches the Task’s model. The RAG config exposes the knobs — among them rewrite_mode, how many candidates to fetch (candidate_k) and keep (final_k), a max_context_tokens budget, and include_sources. The defaults are sensible; tune them only when a Task is retrieving too little or too much.
When include_sources is on, a run reports which document chunks it retrieved and used to build its answer — the attribution you need to render citations in a support or research UI.
Minimal example
Create a Collection, add a document, then query it. (In practice you’ll usually wire the Collection into a Task’s RAG config rather than querying it directly — but a direct query is the quickest way to confirm retrieval works.)
The query returns a synthesized answer grounded in the collection’s documents — the same retrieval a task performs through its RAG config, condensed into a single response string.
To ground a Task, wire the Collection into that Task’s revision RAG config rather than querying it directly — retrieval then happens automatically on every run, and no {context} placeholder is needed in the prompt.