Knowledge bases and RAG
A knowledge base is a set of documents cut into chunks. Every chunk is turned into a vector by an embedding model, so search runs on meaning rather than on matching words. A workflow pulls a handful of relevant chunks out of the base and hands them to the model as context — that is RAG.
Getting a document in
Knowledge
Documents
chunk 500 / overlap 50
| Name | Status | Chunks |
|---|---|---|
| policy.pdf | Ready | 42 |
| faq.md | Processing | — |
| https://example.com/pricing | Ready | 11 |
- Open Knowledge and press New. Give the base a name, a description, an embedding model, a chunk size (500 by default) and a chunk overlap (50 by default).
- Press Add Document and either upload a file (PDF, DOCX, TXT, MD) or point at a web page URL.
- In the same dialog add metadata — key/value pairs you can later hard-filter searches by.
- Wait for Ready. A document goes Pending → Processing → Ready; a failure leaves it as Failed with the reason attached.
What a search actually does
The query text is turned into a vector by the same model, and the store returns the nearest chunks. Four parameters shape the result:
- top_k — how many chunks to return, 1 to 20 (5 by default).
- score_threshold — the minimum similarity, 0 to 1. Zero means “keep everything”.
- context_window — how many neighbouring chunks of the same document to glue onto each hit (0 disables it, 10 is the maximum). Neighbours are joined into one text, so the model sees a whole passage instead of a fragment.
- Metadata filters — a hard condition applied on top of the search.
A filter is a key, an operator, a value and a value type (string, number, date).
Operators: =, !=, <, >, <=, >=. Clauses are AND-ed, so every extra filter can
only narrow the result. A chunk that lacks the key passes != and nothing else. Filter and
metadata values are rendered as templates, so {{ variables.session_id }} in a value
scopes the search to one session.
The nodes
- Execute + Data
- Data
- LLM
- rag_kb — the base’s configuration. It never searches by itself:
its values (
kb_id,top_k,score_threshold,context_window) reach the consumer through the KB port and win over the consumer’s own fields. Metadata filters are the exception — they are combined with the consumer’s filters, not substituted for them. - rag_query — the deterministic search step. It takes the query
text on the Query port and returns context either as
text(chunks separated by---) or asjson(an array with metadata and scores). - rag_tool — the same search exposed as an agent tool: wire it into ai_agent and the model calls it when it decides to.
- kb_write — writes into a base from inside a workflow: the text is chunked, embedded and stored. By default it also creates a document visible in the Knowledge section.
- rerank — reorders the hits with a cross-encoder model and keeps
the top
top_n. Put it after rag_query or rrf_fusion; the model comes from the field or from a connected rerank_config node.
Reach for the reranker when vector search returns broadly relevant but badly ordered chunks: it scores the query against each candidate separately, which is more accurate — and more expensive — than the search itself.
What it costs
Embeddings are metered both when a document is written and on every search: the query has to become a vector too. Rerank is billed on its own, higher rate. Models connected with your own API key are not billed per token at all — see Credits and run cost.
The size of a base is bounded by your plan: the number of knowledge bases, the bytes of their documents and the number of vector points — see Plan limits.