Knowledge
A knowledge base is a set of documents cut into chunks and turned into vectors, so a workflow can search by meaning instead of exact wording. In a graph the base is wired with the rag_kb node into rag_query (deterministic search) or into rag_tool (search the agent decides to run). A workflow can also write into a base itself, with kb_write.
Creating a base
- Press New in the list on the left.
- Fill in Name, and a Description if you want one.
- Pick an Embedding Model. The list holds platform models plus the models your connections bring; if it is empty, configure a provider with an API key first.
- Adjust Chunk Size and Chunk Overlap if needed.
- Press Create.
New Knowledge Base
Platform models plus the models your connections bring.
In characters. Allowed range: 100 to 4000.
How many characters neighbouring chunks share. 0 to 500.
Chunk size is measured in characters: the text is split recursively on paragraphs and sentences down to pieces of that length, and the overlap repeats the tail of the previous chunk at the start of the next one so a sentence is not lost on the seam.
On creation the platform calls the chosen model once with a short request: that measures the vector dimensionality, which is then pinned to the base permanently. If the endpoint does not answer, the base is not created — you get an error asking you to check the model id, the connection’s base URL and its API key.
Adding documents
Select a base on the left and press Add Document. The dialog has two tabs — Upload File and Add URL — and a metadata block shared by both.
- File: PDF, DOCX, TXT or MD. The content is checked against the extension, so a file
merely renamed to
.pdfis rejected. - URL: the address must start with
http://orhttps://. The page is fetched, HTML is converted to text (markdown) and then processed like any other document.
Metadata rows are “key / value / type” (string, number, date). They are attached
to every chunk of the source and can later drive hard search filters — team = logistics,
or date > 2026-01-01. The type defines comparison rules, so it matters for numbers and
dates. Rows with an empty key are ignored.
Processing status
A document is processed in the background and moves through several states. While the page is open, the status refreshes every couple of seconds.
Knowledge
Support policies
text-embedding-3-small · chunk 500 / overlap 50
| Document | Status | Chunks |
|---|---|---|
| policy.pdf | Ready | 42 |
| faq.md | Processing | — |
| example.com/prices | Pending | — |
| broken.docx | Failed | — |
- 1The list of bases: name and the number of indexed documents. The trash icon appears on hover.
- 2The model and chunking parameters of the selected base, shown under its name.
- 3A document being processed shows a progress bar and the current step; a ready one shows its chunk count.
- Pending — the document is saved, processing has not started yet.
- Processing — fetching, splitting and indexing; the row shows a progress bar and the current step.
- Ready — a chunk count appears next to the status and the document takes part in search.
- Failed — the error text is printed under the row (a page that could not be fetched, a file that cannot be read).
The counter in the left list counts indexed documents, so it grows when a document turns Ready, not when the file is uploaded.
Deleting
The trash icon on a document row removes the document together with its chunks in the vector store and the uploaded file. The trash icon in the left list removes the whole base — documents, vectors and files included. Both actions are irreversible.
Limits and billing
The number of bases, the volume of uploaded documents and the number of vectors are capped by the workspace owner’s plan; once a quota is used up, uploads are rejected. Indexing is billed by embedding tokens when a platform model is used; models from your own connections are paid for by your provider and are not billed by the platform.