Glossary

A piece of a document’s text — for example a paragraph, a few sentences or a table row. Each piece is stored on its own. So the search can return only the passages that fit a question, not whole documents. Every chunk remembers which file it came from. The Sources below an answer are built from this.

How a document is cut into chunks during upload. You can change it on a running Topic. A change applies to the next upload, and no restart is needed.

See Creation step by step.

What the SEMANTIC chunking strategy does: one extra call to the Language Model for each chunk, which adds a short note about the chunk’s place in the document. The search then finds pieces better that would make little sense on their own. The cost is upload time — one model call per chunk. It does not change where documents are cut. Its prompt is "Chunk enrichment" on the Prompts tab.

Both are fixed when the Topic is created. Chunk Size is the maximum length of one chunk, in characters. Larger chunks give more context per search hit, but less exact hits. Smaller chunks give more exact hits, but each one says less on its own. Chunk Overlap is how many characters at the end of one chunk are repeated at the start of the next. More overlap means a sentence cut in two is still found in one piece, but more is stored. The overlap must be smaller than the chunk size.

Which files can be uploaded to a Topic: text files, documents (PDF, DOCX, PPTX) and images. You can combine them. Other files are refused at upload. If you tick none, every file is accepted.

The service that turns PDF, DOCX and PPTX files into text. It is needed as soon as a Topic accepts documents — as uploads or as chat attachments. Without a Docling server, such files are refused at upload and in the chat. Docling servers are registered under Admin → Docling Servers.

Advanced settings for how Docling reads PDF and Office files, for example text recognition in scans (OCR), its languages and tables. They are kept per Topic and sent with every upload, not with chat attachments. A change applies to the next upload. Files already uploaded stay as they are until you upload them again. The template switches nothing on, so Docling keeps the settings of its server.

How JSON, XML, YAML, TOML, CSV and TSV files are handled. They are always split into records — for example one table row each — so a record is never cut in the middle.

During upload, a vision model can describe each picture in a document, and each uploaded image file. The description is placed in the text where the picture was, so the content of pictures can be found. Uploads get slower. With the setting off, only a picture’s caption can be found. The setting is Describe pictures with a vision model. It is always on while image files can be uploaded.

The model that writes the picture descriptions during upload. It can be its own model, or the Topic’s Language Model (Use the topic’s Language Model). Either way, it must be able to read images. A larger model sees more details, but makes uploads slower. It is not used for images attached to a chat message — those go straight to the Topic’s Language Model.

Two settings under Image Handling. Store pictures in the database keeps each picture, so an answer can show it and name it as a source; this needs more storage. Show pictures in answers then lets answers show stored pictures inside the text. With it off, answers are text only.

EMBEDDED stores the content of each file in the Topic. It is the only option the wizard offers. EXTERNAL stores only a link to the file. It needs that link with every upload, so it works only through the REST interface.

Turns text into numbers that the search compares — for documents and for questions. It is fixed once the Topic is created, because the stored data only makes sense to the model that created it. To use another one, create a new Topic and upload again. See Overview — the building blocks.

The size of the number list an embedding model produces. Usually it is found automatically. If not — for example when you enter a model by hand — the wizard asks for it. You find it in the model’s documentation. The value must match the model exactly, and it cannot be changed later.

The Topic’s main model, also called the Language Model. It writes the answers. It also does the optional model steps of the Topic: routing, reranking, keyword writing with LLM keyword enrichment, and contextual enrichment. It can describe pictures too, if you choose so.

Where the searchable form of your documents is stored: a database you register under Admin → Vector Databases. Every Topic needs one, and the wizard does not let you continue without it. The choice is fixed once the Topic is created. See Connect a Vector DB.

How the chat searches your documents.

See Creation step by step.

Only with Retrieval Strategy HYBRID. Decides which keywords the keyword search uses for each chunk.

A change applies to documents uploaded after the next restart. Earlier documents keep their keywords.

Before searching, the Language Model decides whether a chat message needs a search at all. Thanks, small talk or "make it shorter" are answered from the conversation (a direct answer). A question only about an attached file is answered from that file. Everything else searches your documents. This makes such messages faster. The setting is Route before retrieval, on by default. With it off, every message searches your documents — one model call less, but small talk is slower.

How sure the model must be (0.0–1.0, default 0.9) before a message is answered without a search. Higher means fewer messages skip the search: safer, but slower. Lower means more messages skip it: faster, but a real question may be answered without your documents. Only used while routing is on.

How many found chunks the model gets for one answer (1–50, default 3). Higher gives more complete answers, but they are slower and can include unrelated content. Lower is faster and more focused, but facts can be missing.

NONE (default) keeps the order of the search. LLM lets the Language Model read the found chunks again and sort them by how well they answer the question, so the best ones are used. Answers get more exact, but each question needs one more model call and takes longer.

How similar a chunk must be to the question to be used (0.0–1.0). Higher means only close matches: answers are more exact, but say "I don’t know" more often. Lower means weak matches are used too. Leave it empty to use every match.

How many earlier messages of a chat the model sees with each new question. Higher means follow-up questions like "and what about the second one?" are understood better, but every answer costs more and takes a bit longer. Lower is faster, but the model forgets earlier parts of the chat sooner. The global default is 3. You can change it per Topic under LLM Overrides (Context Memory (messages)). If the conversation has simply moved to a new subject, start a New Chat instead.

The system prompt sets the role, tone and style of the answers. A shared one for all Topics is set under Admin → LLM Configuration. Each Topic can replace it on the Prompts tab. The Custom System Prompt holds extra instructions for one Topic only, for example "Always answer in German." It is inserted into the system prompt at the {{USER_EDITABLE_PROMPT}} placeholder. You write it in the first wizard step or on the Configuration tab. It changes how answers sound, not which content is found. It takes effect after a restart. See Global LLM Configuration.

The text around the found passages that is sent to the model with the question. Use it to say how the passages should be used, for example "Answer only from these passages." Stricter wording keeps answers close to your documents, but they say "I don’t know" more often. Looser wording gives more complete answers, but the model may add its own knowledge. It must contain {context}, which is replaced with the found passages. Set per Topic on the Prompts tab; the default comes from Admin → LLM Configuration.

The fixed text shown when the search found nothing that fits, instead of letting the model invent an answer. It is shown exactly as written. Set per Topic on the Prompts tab; the default comes from Admin → LLM Configuration.

The instructions the Topic sends to its models — for example for routing, reranking, contextual enrichment, keyword writing, picture description and the answer itself. Each one can be changed per Topic on the Prompts tab. A change takes effect after a restart.

The answer appears word by word while the model writes it. You can stop waiting for an answer with the stop button next to Send. A stopped answer is not shown or saved.

The documents an answer actually used, shown as Sources below the answer. They make an answer checkable instead of only plausible. Each source is a download link that works for about 10 minutes. After that, it greys out and says why, instead of opening a broken page. Ask again to get fresh links. See Chat window.

A check after the answer is written. It decides which of the found passages the answer really used. Only those are shown as sources. Its prompt is "Source filter check" on the Prompts tab.

Files a user attaches to one chat message. They are used for that one answer only and are never added to the Topic’s documents. Which types are allowed is set per Topic (Allowed Chat Attachment Types on the Configuration tab), separately from the upload file types. Text files are allowed by default. Documents need a Docling server. Images go straight to the Topic’s Language Model, so that model must be able to read images — this is not checked automatically. With no type allowed, the chat shows no attachment button. See Chat window.

When a Topic asks another Topic as a tool, the answer can show that other Topic’s sources and pictures. They open through the other Topic, so they work only if you have access to it. If you have no access to the other Topic, the answer leaves it out and shows a note.

A standard that lets a Topic’s language model call tools while it answers, instead of relying only on its own documents — including asking another Topic or GraphRAG topic. It needs a Language Model that can call tools. Without one, connected tools are silently never used. See Overview — MCP.

The port where a Topic is reached on the server, set in the first wizard step. Every Topic needs its own port, and no other program on the server may use it. With Docker, this is what makes the REST interface reachable directly, without the browser UI.

Where a Topic is reachable from outside, for other programs. Links the Topic hands out — for example download links of sources — use it. An administrator sets a pattern for all Topics under Admin → Public Endpoints. A single Topic can use its own value (Public Address Override on the Configuration tab). A change applies after the next restart. See Public Endpoints.

Most settings reach the Topic only when it starts — models, prompts, timeouts, search settings. After such a change, a running Topic keeps the old settings until it is restarted. The Configuration tab offers Save & Restart for this. The Chunking Strategy, the Docling Settings and MCP connections apply without a restart.

An action on the Actions tab. It deletes this app’s list of uploaded files and all chats of the Topic, for example after testing. The documents stay in the Topic, and the chat can still find them. Settings are not changed. It cannot be undone.

A detailed report of one upload or one answer, for developers and support. It shows each step, each decision with the settings behind it, every model call with its full prompt and answer, and how long each part took. You switch reporting on and read the reports on the DEV Reports tab while the Topic runs. All switches are off after a start. Reports contain full prompts and document text, so share them with care. Using them needs the permission "Use DEV Reporting".

The REST interface’s conversation identifier. There is no separate session endpoint. Reusing the same memoryId across calls is what keeps the context, and a new value starts a new conversation. See REST interface.