Search your documents

A dataset is a named set of your documents that Kortecx can search. You put text or files in; you ask a question in plain language; you get back the passages that answer it, with a pointer to which document each one came from.

This is what people usually mean by "make it answer from my documents". No model is retrained. Your documents are kept in Kortecx's own store.

Put documents in

In the console, open Context, name a dataset, and drop files or paste text into it.

Adding the same document twice is a no-op, and there is no delete subcommand — a dataset only ever grows. To retire a corpus, build a new one under a new name.

Ask it something

Ask in plain language. Each hit carries a snippet of its text, its parent document, and a rank-fusion score.

What "hybrid" retrieval actually does

Two different searches run over your corpus, and their results are merged into one ranking.

• Dense (vector) search compares the meaning of your question to the meaning of each passage. It finds a paraphrase — you ask about "refund window", the passage says "money back within 30 days".
• Sparse (BM25) search compares words. It finds the exact term a meaning-based search fumbles: a product code, a surname, a rare acronym.

Neither is reliably better, and their scores are not on the same scale, so they are not averaged. The two lists are merged by rank rather than by score, so a passage that both searches liked comes out ahead of one only a single search liked.

There is no diversity pass: near-identical paragraphs can take neighbouring slots.

The merge is deterministic. For a fixed index, query and configuration, the same order comes back on any machine.

Chunking, and knowing where an answer came from

A long document is not embedded whole — a single vector for forty pages means nothing. Before embedding, each document is split into overlapping passages, and a search hit is a passage, not the whole file.

The splitter is deterministic. It prefers to break at a paragraph, then a line, then a sentence, then a word, and only cuts mid-word when nothing else fits. Consecutive passages overlap, which is what stops an answer falling down a crack: a sentence that straddles a boundary is still wholly present in at least one passage, so it can still be found.

Every passage keeps its provenance — the parent document it came from, its position within that document (shown as [chunk i/N]), and its exact character range in the parent. That is what lets a result say "this came from section 4 of the handbook" rather than handing you an anonymous fragment. A dataset's document list shows how many passages each document became.

Changing how a dataset is indexed

Search compares your question's vector to the passage vectors already stored. Those vectors only mean anything if they were produced the same way the stored ones were. Change the embedding model, or how documents are split, and the stored vectors now live in a different space — comparing against them produces results that look fine and are quietly wrong.

The managed service does not check this for datasets yet: a dataset does not record the setup it was indexed under, so nothing refuses a mismatched ingest or query. Memory does check it, and refuses — see Memory.

Embedding quality

Retrieval is only as good as its embeddings, and the runtime is candid about this: a general chat model produces weak sentence embeddings. It will mis-rank paraphrases — the thing dense search exists to catch. A dedicated embedding model does better; on the managed service the runtime chooses it.

Retrieval is never blocked by a weak embedder — hybrid search and chunking lift quality either way — but the ceiling is lower.

If there is no embedding model available at all, the search by meaning does not run and a query names it as degraded; the search by words still answers.

Search it from chat

A chat turn already searches your datasets and cites what it used.