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 never attaches a Collection directly — it gets the knowledge through a Task tool whose revision has the Collection wired in.
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.