Documents

On a Knowledge Base's Documents tab, drag files onto the upload zone (or click to browse). Each file is stored, then chunked, embedded, and indexed in the background — the file appears in the table immediately with an INDEXING badge and updates on its own as processing completes.

Supported file types

.pdf · .docx · .doc · .csv · .xlsx · .xls · .txt · .md · .json · .jsonl · .pptx · .zip (extracted one level deep — each supported file inside becomes its own document; unsupported files inside a ZIP are skipped, not a failure)

Legacy .doc files are best-effort

.doc (the old binary Word format, not .docx) has no proper parser in this pipeline — it's recovered by scanning the raw file for readable text runs. You get most of the words; you lose all formatting and structure. If you have the option, save as .docx before uploading.

Limits

50 MB per file
1 GB total per Knowledge Base
20 files per upload batch

A batch that would exceed any of these is rejected before anything uploads — nothing is partially stored.

Chunking strategies

Each file is split into chunks before embedding. Pick a strategy per file at upload time (or change it later via Re-chunk, which re-indexes just that file):

Strategy	Best for
`fixed`	General text — fixed-size, overlapping windows. The default.
`recursive`	Structured text like Markdown — splits on natural boundaries first.
`semantic`	Prose where topic shifts matter more than length.
`token`	When you need chunks sized by token count rather than characters.
`row`	CSV/Excel only — one chunk per row.
`json`	JSON files — structure-aware splitting.
`document`	Whole-document pass-through, with semantic section detection where possible.
`late`	Prose, same underlying behavior as `semantic` in the current pipeline.

row chunking requires a CSV or Excel file — applying it to anything else fails clearly rather than producing empty chunks. overlap must be smaller than chunk_size.

Embedding providers per strategy

semantic, document and late call the Knowledge Base's own embedding model while chunking, to find where topics change. The other strategies only call it for the finished chunks. All of them work with every embedding provider a Knowledge Base can use: OpenAI, Google AI Studio (Gemini), Ollama and OpenAI-compatible providers.

The model must be an embedding model that the LLM Configuration's provider actually serves. For example, text-embedding-005 is a Google Vertex model, so an OpenAI configuration cannot run it. Use text-embedding-3-small or text-embedding-3-large with OpenAI. If the provider refuses a request, the file goes to FAILED and its status shows the provider's own reason, such as The embedding provider answered 404: The model … does not exist.

If document cannot find sections, it falls back to the whole file as one chunk. A file too large for the model's input limit is split on paragraph and sentence boundaries instead.

Document status

Status	Meaning
`PENDING`	Queued, not yet started.
`INDEXING`	Extracting, chunking, embedding, and upserting.
`COMPLETED`	Searchable.
`FAILED`	Hover the status badge for the reason.

Per-file operations

From each row's action menu:

Rename — updates the display name only; doesn't touch the index.
Download — the original file, unmodified.
View content — the extracted plain text Elizon actually indexed (paginated for long documents). Useful for confirming extraction quality, especially for .doc or scanned PDFs.
Re-chunk — change chunking strategy, size, or overlap; re-indexes just this file.
Delete — removes the file and every chunk it produced from the index.