Skip to content
Sixnix Desk

The knowledge base

For whoever is running the desk.

What the desk knows about your product, so the assistant can answer from it rather than from imagination. Everything here is plain text: pages from your website, files you upload, documentation in a git repository, and notes your staff write.

It feeds four things: the chat assistant, reply drafts, the AI greeting line, and the “these might help” suggestions on the client’s new-ticket form.

Types

A type is a bucket you define (Public docs, Internal, Pre-sales) and every source and note sits in one or more of them. A type declares:

  • What may read it: the chat assistant, reply drafts, the greeting line, ticket-form suggestions.
  • Which departments it informs, if you want to limit it.

Two starter types exist on every brand: Public docs (readable by all four) and Internal (drafts only). This is how you keep an internal runbook out of a visitor-facing chat answer while still letting agents’ drafts use it.

Sources

Where the text comes from:

A site : Crawl from a start page: the same host plus any hosts you allow, include and exclude path patterns (or regular expressions), a depth and a page cap.

A sitemap : And the sitemaps it points to.

A single page : For the one document that matters.

An uploaded file : Markdown, text or HTML, and PDF where pdftotext is installed.

A repository : The documentation folder of a git branch, read straight from GitHub, GitLab, Gitea/Forgejo or Bitbucket, with no git on the server: one request for the branch’s head, and only when it has moved, one for the archive. Files matching your patterns (Markdown, MDX and text by default, code never enters) become documents whose address is the provider’s page for that file, so citations link to the source. An optional read-only token is stored encrypted. Each repository source gets a push webhook address to paste into the provider, so a push re-reads it at once.

Sources can carry an auth header for documentation behind a login, and a re-read interval; an hourly job picks up the ones that are due, and Run now is always there.

The crawler names itself, honours robots.txt, caps pages at 2 MB, uses ETag and Last-Modified so unchanged pages cost nothing, and re-chunks a page only when its content actually changed. Pages that vanish leave the index.

Notes

Staff-written answers, in the same index. Any staff reply can be saved as a note straight from the ticket, which is how a good answer written once at 2am becomes the answer the assistant gives next time.

How retrieval works

Documents are split on headings into ~2,000-character chunks with overlap, keeping the heading path. A question is matched against the chunks and notes of the types that grant the use, limited to the department where that applies, and cut off by the brand’s minimum score and context cap.

Optionally, matching by meaning: with an embedding key (OpenAI, Gemini or compatible; Anthropic does not offer embeddings), chunks are also stored as vectors and the results are re-scored half by words and half by meaning, so a passage sharing no words with the question can still be found. On MariaDB 11.7+ the database does that search itself; on anything older the desk does it in PHP over the word matches.

Test a question in the Knowledge area shows what would be retrieved, with the scores, and says which path ran.

Set-up by console

Administrators can tell the console “set up the knowledge base from our website https://…”. It looks at the site (nothing is fetched until you confirm the host), asks at most four questions (what you sell and to whom, what is unsupported, the tone, what must never reach visitors), writes a product primer, and proposes types and sources as a checklist. Nothing is written until you confirm, and applying it twice does not duplicate anything.

It is the fastest way from nothing to a working base, and the primer it writes is usually worth keeping.

Citations

  • To staff (on by default): drafts list their sources with links, and you can thumbs-up or -down each one.
  • To visitors (off by default): chat answers end with up to two “Read more” links, for documents that have a public address.

Feedback is stored against the question, which feeds the coverage figures below.

Unanswered questions

The Knowledge area lists the questions that found nothing useful: retrieval misses, and chat hand-overs where the assistant was unsure, grouped, counted, with sample tickets and an Answer this button that opens the note editor prefilled.

Its header shows coverage: the share of chat and draft questions in the last 30 days that found a strong match. That number, over time, is the only honest measure of whether the knowledge base is working.

Settings

Per brand: on or off, chunks per question (6), minimum score (0.15), maximum context (6,000 characters), cite to staff (on), cite to visitors (off), and a daily page cap for crawling (2,000).

Watching it

Logs → Knowledge records every indexing run: the brand, the source, what triggered it (manual, refresh, webhook, upload), how many pages were checked, unchanged, updated, removed and embedded, how long it took, and any error. Brand cards show when each brand was last refreshed, and warn when a source is failing.

Advice

  • Start with one source: your public documentation. Test a dozen real questions against it before adding more.
  • Keep Internal genuinely internal. Check the type’s uses, not its name.
  • Write notes from real tickets. The Unanswered questions list tells you which ones.
  • Do not index your blog unless answers should cite marketing posts.