Sources

An assistant is only as good as the passages it can retrieve.

Training is not fine tuning. Nothing about your content changes the model. Your pages are read, split, embedded and stored, and at question time the relevant passages are handed to the model along with the question.

Pages and files become indexed passagesTwo source types are extracted, split and embedded into one searchable index.SplitIndexPages and uploaded files
  • Private launchOnboarding selected teams now
  • Answers from your pages onlyIt refuses when your content does not cover it

What it does

Creobot takes two kinds of source: pages on your site, reached by crawling, and files you upload. Both are converted into passages, each passage is embedded, and the results are stored in an index that can be searched by meaning rather than by keyword.

Why it matters

The distinction matters commercially because it changes what you are buying. Fine tuning bakes information into weights, is expensive to redo, and goes stale silently. Retrieval keeps your content as content, which means a page edit is reflected on the next index rather than at the next training run.

It also changes the failure mode. A fine tuned model that is wrong is wrong invisibly. A retrieval system that is wrong cites the passage it used, so you can see which page misled it and fix that page.

How it works

Discovery

The crawler starts from your sitemap where one exists, because that is a list you already maintain of pages you consider canonical. Where there is no sitemap it follows links from a starting URL.

Extraction

Readable text is pulled from each page. Navigation, footers and repeated chrome are discarded, because indexing your own nav on every page adds hundreds of near identical passages that compete with real content.

Chunking

Text is split into passages on document structure, following headings and paragraph boundaries rather than a fixed character count. A boundary that cuts an answer in half produces two passages, neither of which answers the question.

Embedding

Each passage is converted into a vector representing its meaning, so a question about cost can reach a passage about pricing that never uses the word.

Indexing

Vectors are stored with the metadata needed to attribute an answer back to its source page.

Reindexing

On a schedule, or triggered when you publish. Scheduled is simple and always slightly wrong. Triggered is correct and requires your publishing system to emit an event.

Pages and files become indexed passagesTwo source types are extracted, split and embedded into one searchable index.SplitIndexPages and uploaded files

The tradeoff nobody mentions at setup

Every source you add increases coverage and decreases precision. Those move in opposite directions and there is no setting that fixes it, only a judgement about which failure you would rather have.

A narrow index refuses more. That looks worse on a dashboard and is usually better for the business, because a refusal is honest and a wrong answer is a commitment. A broad index answers almost everything, and a share of those answers come from pages you forgot were published.

The asymmetry is what should decide it. A refusal costs you one visitor who has to look elsewhere. A confidently wrong answer about pricing or a policy costs you a dispute, and it happens in writing where someone can screenshot it.

Start narrow. Let the refusal log tell you what to add. That way every source in the index earned its place by being asked for, rather than by being present on the domain when the crawler ran.

What is built and what is planned

File upload limits are set per plan, from 1 MB on Free to 100 MB on Scale. Publish triggered reindexing is planned for launch; scheduled reindexing is the behaviour to assume until then.

Where the data goes

Page text and uploaded file contents are stored in your index. At question time the retrieved passages are sent to a model provider along with the question. Creobot holds no security certification and claims none. Security and data boundaries.

Questions

No. Nothing about your content changes the model. Your pages are stored as retrievable passages and supplied at question time. That is why an edit to a page shows up on the next index rather than requiring a retraining run.

Anything behind a login, anything rendered only by client side script after load, text inside images, and content in a format the extractor cannot read. These fail silently rather than loudly, which is the dangerous part, so check what was actually indexed rather than assuming.

A text based PDF extracts cleanly. A scanned one does not, because there is no text layer to extract. There is no OCR step, and we would rather say that than let you upload a scan and wonder why it is never cited.

On document structure, following headings and paragraphs, not on a fixed character count. Splitting on character count is the most common way to make retrieval worse, because it cuts answers in half.

Scheduled today. Publish triggered reindexing is planned for launch. The gap matters most for pricing, policy and opening hours, where a stale answer is worse than no answer.

Almost certainly not. More sources produce worse answers unless each one earns its place. Choosing what to train on covers how to decide.

It leaves the index at the next reindex. Until then the assistant can still cite it, which is another argument for publish triggered reindexing.

Signal

Is this the capability you need?

Access is by waitlist, demo request or public-content pilot. Tell us what your site has to answer and we will say honestly whether this covers it.