Use Case · Support

RAG knowledge assistant on the Software Lifecycle Cloud

A RAG knowledge assistant on KERNSTACK is a project that stores your source documents in buckets, declares a vector search index over them, embeds questions with the catalogue model text-embed-v1, and answers through a function that returns the retrieved passages with the reply. The corpus, the index, the model calls, and the API are resources of one stack.json — not a vector vendor, a model vendor, and a backend glued together.

The engineering bottleneck with assembled stacks

Support leads answer the same product questions every week because the knowledge sits in help-center articles and release notes nobody can query as one corpus. The usual assembly — a hosted vector database here, a model API key there, a small backend nobody owns — drifts: articles update, embeddings do not, and the assistant confidently cites last quarter’s behaviour.

Architecture on the Software Lifecycle Cloud

Documents land in a bucket; a vector index is declared over that bucket and re-embeds from source when articles change. A Go function behind a gateway route embeds the question, retrieves the closest passages, and calls a catalogue or custom inference endpoint with those passages as context. Query logs go to a table, so unanswered questions become an editorial list.

Keeping the corpus honest

The index is only as true as its source, so the source lives in the project. When a help article is replaced in the bucket, the index rebuilds from the new file; when an article is deleted, its passages leave the index with it. There is no separate upsert pipeline to fall behind, which removes the classic RAG failure — correct model, stale evidence.

  • Chunking is a property of the indexing declaration, reviewed in the same diff as the route that serves answers
  • Answers can cite the passages retrieved, because retrieval happens inside your function, not inside a black-box hosted chat widget
  • Low-confidence questions are logged to a table instead of being answered creatively

What it costs to run

Embedding a typical help-center corpus with text-embed-v1 costs 3 credits per 1,000 tokens, paid once per document change rather than per question. Question traffic pays for function compute at 0.01 credits per GiB-second and for the model call that drafts the answer. An idle assistant — nights, weekends — spends nothing on compute.

Start from the official work-python-minimal starter blueprint or the full-stack platform demo.

Frequently asked questions

By default the catalogue model text-embed-v1 at 3 credits per 1,000 tokens. If you already run a model you prefer, declare it as a custom inference endpoint and point the index and the function at it instead.

Structurally: the function retrieves passages first and instructs the model to answer from them, and questions whose retrieval is weak are logged to a table for a human instead of answered. The corpus being project-owned also means a wrong source document is one bucket upload away from fixed.

Yes. Resolved tickets export into the same bucket or a table listed as an index source. Most teams start with published articles — the corpus they are willing to stand behind — and add ticket text once redaction rules are clear.

Related capabilities, architectures, and comparisons

Ship your stack on the Software Lifecycle Cloud.

Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.