CogniFlow

CogniFlow is a vector RAG chatbot. An ingestion job crawls a defined set of sources, normalises the text, splits it into overlapping chunks, embeds each chunk and writes it to a vector collection alongside its source URL. At query time the application retrieves the nearest chunks and answers from them, so responses stay bounded by the corpus rather than by whatever the base model happens to remember.

A general-purpose language model has two failure modes that make it unusable as a knowledge interface: it does not know anything specific to your organisation, and when it does not know something it produces a fluent, confident answer anyway.

Fine-tuning does not solve this well. It is expensive to repeat, it bakes knowledge into weights that cannot be updated cheaply when a document changes, and it still gives you no way to point at where an answer came from.

This is the shape of almost every practical LLM deployment inside a company: a body of knowledge exists — documentation, policies, product data, support history — and people need answers from it in natural language, without a human having to read the source each time.

The constraint that decides whether such a system is adopted is not answer quality in isolation. It is whether a reader can verify an answer. An unverifiable answer transfers risk to the reader, and readers reject it.

Separate the system into two pipelines that can evolve independently: an offline ingestion pipeline that owns the corpus, and an online query pipeline that owns the conversation.

The ingestion pipeline renders each source with a headless browser rather than fetching raw HTML, so client-rendered content is captured. Extracted text is whitespace-normalised, split into 512-character chunks with 100 characters of overlap so a fact spanning a boundary survives in at least one chunk, then embedded in batches with text-embedding-3-small.

Each chunk is stored as a vector alongside its text and originating URL. Retrieval therefore returns not just the supporting text but its provenance, which is what makes an answer checkable.

Ingest — a source is rendered, flattened to text, chunked with overlap, embedded in a single batched call per document, and upserted with its provenance.

Retrieve — the incoming question is embedded with the same model, and the vector collection returns the nearest chunks by cosine similarity. Using one embedding model on both sides is not a detail: mixing models silently destroys retrieval quality because the vectors no longer share a space.

Generate — retrieved chunks become the context for the answer. The model is instructed to answer from context, and the source URLs travel back with the response so the reader can check it.

The chunker is hand-written rather than pulled from a library. It advances by chunk size minus overlap and guards the step so a pathological overlap value cannot produce an infinite loop — a real failure mode in naive implementations.

Embeddings are requested per document rather than per chunk, which collapses dozens of round trips into one and is the difference between an ingestion run measured in minutes and one measured in hours.

The browser is launched and closed inside a try/finally around each page, so a page that hangs or throws cannot leak a Chromium process across a long crawl.

Credentials for the vector store and the model provider are read from the environment only. Nothing is embedded in the client bundle, and the collection is created idempotently with an explicit dimension and metric rather than relying on defaults.