How it works
- Create a knowledge base.
- Add documents. Each document is chunked (~1000 chars) and every chunk is embedded.
- Retrieval runs a cosine-similarity search over the chunks with pgvector.
bge-small-en-v1.5,
384-dim), so no external embeddings key is required.
Supported formats
Up to 4MB per file.
Text-family files are decoded immediately. Everything else is queued and
converted by a background worker, so an upload returns as soon as the document
is accepted rather than blocking on conversion - a large PDF becomes searchable
a little after it is uploaded, not instantly.
Documents become Markdown, not flat text
Conversion is done by anydoc, which renders every format through one Markdown serializer. Headings, tables, lists, and speaker notes survive. That matters because a chunk is retrieved on its own, with no surrounding document to explain it. A heading tells the reader what the chunk is about, and a table keeps each figure next to the column that names it -| Q2 | 14 | under
a Quarter | Widgets header answers a question that a bare Q2 14 cannot.
A PDF that is a scan or a photo has no text to convert. Those uploads fail with
an explanation rather than embedding an empty document; OCR is not currently
part of the pipeline.
From the CLI
From an agent
Add a tool with the built-in keyknowledge_search and reference it from an
agent node. At run time the agent calls knowledge_search(query), which embeds
the query and returns the top matching chunks for the model to answer from.
Knowledge graphs
A base can also extract an entity-relationship knowledge graph from its documents, so agents retrieve related facts by traversing the graph, not just by similarity. See Knowledge graphs (GraphRAG).API
POST /v1/knowledge- create a basePOST /v1/knowledge/{kb}/documents- ingest a documentPOST /v1/knowledge/search- search chunks

