Knolo vs a Vector Database: Lexical-First Retrieval You Can Verify

Knolo is the open-source, local-first Knowledge Image runtime and format from Hive AI. It is published on npm as @knolo/core (currently 6.2.0) under the Apache-2.0 license. A question we hear a lot is where Knolo sits next to a vector database. The short answer: Knolo is not a vector database, and it does not need one. This post explains what Knolo does instead, where an optional semantic layer fits, and how to pick a retrieval pattern for your corpus.

Knolo starts with lexical retrieval, not embeddings

A typical retrieval stack turns every chunk into an embedding, stores the vectors in a database, and returns the nearest neighbours to a query embedding. Knolo takes a different first step. The default path in @knolo/core is deterministic lexical retrieval over a portable .knolo pack that you build once and mount locally in Node, the browser, Expo or React Native.

import { buildPack, mountPack, query } from '@knolo/core';

const docs = [
  { id: 'billing.refunds', namespace: 'support', heading: 'Refund policy',
    text: 'Refund requests must be submitted within 30 days.' },
];
const bytes = await buildPack(docs, { semantic: { enabled: false } });
const pack = await mountPack({ src: bytes });
const hits = query(pack, 'How long do I have to request a refund?', {
  topK: 5, namespace: 'support',
});

That example comes straight from the Knolo lexical retrieval docs. Same pack, same question, same options: same hits. There is no index service to run and no network call in the query path. Selection, rewriting and answering stay in your application as host adapters; they are not part of @knolo/core.

Where Knolo semantic reranking fits

Lexical search is precise on exact language, but it can miss paraphrases. Knolo handles that with optional semantic reranking, and the order matters: lexical retrieval runs first, then semantic scoring reranks a bounded set of lexical candidates. It does not replace lexical grounding, and no external vector database is required.

const hits = query(pack, question, { topK: 8, semantic: {
  enabled: hasSemantic(pack), mode: 'rerank', topN: 50,
  minLexConfidence: 0.35,
  blend: { enabled: true, wLex: 0.75, wSem: 0.25 }, queryEmbedding,
} });

The semantic data has to exist on the pack, and the caller supplies the query embedding. @knolo/semantic-ollama is an optional local embedding provider for this layer, not a model inside @knolo/core. Semantic sidecars target V4 packs. The details are on the Knolo semantic reranking page.

Knolo vs a vector database: choosing a pattern

The Knolo docs describe three patterns:

Pattern Best fit Lexical only Exact language, policies, code, names, IDs Lexical plus semantic rerank Paraphrases and conceptually related language Lexical plus small-model selector Complex relevance judgments and evidence pruning

If your main job is similarity search over a very large pool of embeddings, a vector database is built for that. If you want a knowledge artifact you can copy, pin, mount offline and check later, that is what Knolo is for. The docs also say to measure whether added reranking latency is worth it on your own corpus, which is good advice either way.

What a Knolo Knowledge Image adds: verification

The bigger difference is not the ranking step but the artifact. A V5 Knowledge Image is a portable, mountable container with immutable object and event segments, a commit record with its roots, per-section bounds and digests, and fail-closed checks for missing sections, overlaps and digest mismatches. See Knolo V5 concepts.

Knolo verification answers a narrow question: do these bytes match the roots they declare? TypeScript and Rust share fixtures for deterministic CBOR and domain-separated SHA-256 digests. A passing check does not mean a source document is correct or an answer is true, and the docs say so plainly. It does mean the knowledge you queried today is the same knowledge you can point to tomorrow.

Try Knolo locally

1. Install with npm install @knolo/core (see the Knolo installation guide).
2. Build a small pack from a handful of documents and run query() with semantic off.
3. Add semantic rerank only if lexical results miss paraphrases you care about.
4. Verify the artifact before you ship it.

The source, issues and releases are in the Knolo core repository on GitHub. For the open specifications, licensing and compatibility side of the project, visit Knolo on knolo.org, and for docs and packages start at Knolo on knolo.dev.