Glossary of retrieval terms
Definitions of the terms that appear on the rest of this site: retrieval and ranking, model formats and runtimes, storage in the browser, and the failure modes that come with each of them. Every entry says how the term is used here, with the figures this site actually ships.
Last updated:
This glossary defines 21 terms in the order you tend to meet them when running a retrieval tool on your own machine: what retrieval-augmented generation is, how text becomes numbers, how two different search methods are combined, which file formats and browser APIs carry it, and where each step goes wrong. Definitions describe how this site uses the term, with the values it actually ships.
How to read an entry
Each entry has a definition sentence, the reason the term matters in practice, and a note on the concept it is most often confused with. Where a number is specific to this site it is given rather than described, so a definition you cannot check is rare on this page.
Terms, roughly in the order you meet them
RAG (retrieval-augmented generation)
RAG is the pattern of finding relevant passages in a corpus first and producing an answer from those passages, instead of answering from model weights alone. Here retrieval is a hybrid search over your own chunks, and answering is either extraction of the matching sentences or an optional small local model. It is confused with fine-tuning: RAG adds no knowledge to a model, it supplies text at question time, and removing a document removes it from the answers immediately.
Embedding (vector embedding)
An embedding is a fixed-length list of numbers standing for a piece of text, positioned so that texts with similar meaning sit close together. This site computes one embedding per chunk with a sentence-transformer model, which is why a question can match a passage that shares almost no words with it. It is confused with keyword matching: embeddings capture meaning but lose exact strings, which is the gap BM25 fills.
Chunking
Chunking is splitting a parsed document into passages small enough to embed and specific enough to cite. This site chunks with structure in mind, at roughly 700 characters with 15% overlap, so a sentence that straddles a boundary still appears whole in at least one chunk. It is confused with page splitting: page numbers are kept here as citation anchors, not used as the chunking unit.
Vector dimension
Vector dimension is the number of floats stored per chunk, fixed by the embedding model: 512 for bge-small-zh-v1.5, and 384 for all-MiniLM-L6-v2 and multilingual-e5-small. It decides the storage per chunk and whether two models can share an index at all. It is confused with accuracy: more dimensions are not automatically better, and vectors from two different models cannot be compared, because a 512-value and a 384-value vector have no shared coordinate meaning.
Cosine similarity
Cosine similarity measures the angle between two vectors and ignores their length, returning a value between -1 and 1 where 1 means identical direction. It is the score that ranks chunks in the vector half of the search here. It is confused with a probability: a score of 0.8 does not mean an 80% chance of being correct, and scores are not comparable across different embedding models.
BM25
BM25 is a lexical ranking function that scores a passage by how often your query terms appear in it, weighted by how rare those terms are in the collection and damped by passage length. It is the keyword half of the hybrid search here, and it is what rescues exact strings: error codes, part numbers, names, Chinese terms copied from a contract. It is confused with plain word counting, since the rarity weighting is the substance of it.
RRF (reciprocal rank fusion)
RRF merges two ranked lists by giving each item a score of 1/(k + rank) and summing the scores, with k fixed at 60 here. It works on positions rather than scores, which is what allows a vector search and a BM25 search to be combined without calibrating two inherently incomparable score scales. It is confused with weighted averaging of raw scores, which needs normalisation and drifts whenever one retriever changes its score range.
MMR (maximal marginal relevance)
MMR re-ranks candidate passages to balance relevance against novelty, scoring each new passage as lambda times its relevance minus (1 - lambda) times its similarity to the passages already chosen; this site uses lambda 0.7. The practical effect is that the six passages handed to the reader cover different parts of a document instead of being six restatements of one paragraph. It is confused with deduplication: near-duplicates are pushed down the ranking, not deleted, and lowering lambda is what promotes variety.
top-k
top-k is the number of passages passed to the answering step, and here k is 6. Raising it gives the reader more material and more noise at the same time, and with the optional generator it consumes context window. It is confused with the size of the candidate pool: many more passages are scored during retrieval than the 6 that survive MMR.
Quantisation (q4, q8)
Quantisation stores model weights in fewer bits, q8 at eight bits per weight and q4 at four, shrinking the download and the memory footprint in exchange for some accuracy. The embedders here ship as int8 ONNX builds and the optional Qwen2.5 generator as a 4-bit weight-only build, which is what brings it into the 400 MB to 1.0 GB range. It is confused with ordinary file compression: quantised arithmetic is what the model then executes, so the weights do not return to full precision when loaded.
ONNX
ONNX is an open file format describing a neural network graph, and the .onnx files this site downloads are the embedder and generator weights in that format. It exists so a model trained in one framework can be run by a different runtime, including one that runs inside a browser. It is confused with a runtime: ONNX describes the graph, onnxruntime-web executes it.
WebGPU
WebGPU is the browser API that gives a page access to the graphics processor for general computation, and this site uses it for the optional generation model where the browser offers it. It matters because tokens per second differ by an order of magnitude between the GPU and CPU paths. It is confused with WebGL, which is a graphics API not built for this work, which is why the fallback here is CPU/WASM rather than WebGL.
WASM (WebAssembly)
WebAssembly is a compact binary instruction format that browsers execute close to native speed, and it is the path both models take when WebGPU is unavailable. It runs on the CPU, which is why generation through it lands at roughly 3 to 8 tokens per second. It is confused with JavaScript: the pipeline is JavaScript, and the tensor arithmetic inside it runs as WebAssembly.
Context window
The context window is the maximum number of tokens a generative model can attend to at once, covering the instruction, the retrieved passages and the answer produced so far. It is the ceiling on how much material a generated answer can read, and one reason top-k is not simply raised to twenty. It is confused with the size of your library: only the retrieved passages enter the window, never the whole collection.
Hallucination
A hallucination is a fluent statement a model produces that the material it was given does not support. Extraction mode here cannot invent text it did not retrieve, because it returns retrieved sentences with citations; the optional generator can, which is why a generated answer is meant to be read against its citations. It is confused with a retrieval miss: an answer that cites nothing relevant is a search problem, not a model inventing facts.
Extractive answer
An extractive answer is assembled from the retrieved passages themselves, with every sentence traceable to a document, a page and a chunk. It is the default mode here because it cannot fabricate and needs no generation model, which is what makes the tool usable on a phone or a laptop without WebGPU. It is confused with keyword highlighting: sentences are selected and ordered as an answer, not merely marked in the source text.
Strictness
Strictness is the setting that decides how much interpretation the answering step may apply, and it has two states: “Documents only”, which refuses rather than guesses when the retrieved text does not contain an answer, and “Allow inference”, which may compose sentences that go beyond the source and marks them. It is the first control to change when an answer is wrong, because it separates what was retrieved from what was inferred. It is confused with a quality score: it is a policy you choose, not a measurement of the answer you got.
IndexedDB
IndexedDB is the browser database holding the chunks and their vectors for this site, keyed by knowledge base and document. It is why an index survives a reload and disappears when you clear site data, and it is what keeps the tool working with no network. It is confused with local storage or a cookie: both are small and synchronous, and neither is meant to hold megabytes of vectors.
Service Worker
A service worker is a background script a site can register to intercept network requests and reply from a cache, which is the usual mechanism behind a web page that opens without a connection. The model weights here live in Cache Storage, the same cache API a service worker reads from, and local question answering works offline regardless, because retrieval never needed the network. It is confused with a server: a service worker has no storage beyond caches, cannot answer questions by itself, and is deleted along with site data.
OCR (optical character recognition)
OCR reads text out of an image, which is what turns a scan or a photograph of a page into searchable characters. It is not part of this tool: a scanned PDF without a text layer is refused rather than indexed as an empty document, because bundling an OCR model would add hundreds of megabytes to the download. It is confused with parsing: parsing extracts characters that are already present, OCR has to recognise them, and a poor OCR pass produces text that search will happily retrieve and misquote.
Text layer
The text layer is the invisible text stored alongside the page image inside a digital PDF, and it is what makes selection, copying and searching possible. Its presence or absence decides whether a PDF can be imported here at all. It is confused with the document looking right: a scanned report can render perfectly on screen and contain no text layer whatsoever, which is why the importer checks the file instead of trusting its appearance.
Numbers that recur on this site
| Value | Where it comes from |
|---|---|
| 512 and 384 | Vector dimensions: 512 for bge-small-zh-v1.5, 384 for all-MiniLM-L6-v2 and multilingual-e5-small |
| About 700 characters, 15% overlap | Chunk size and the overlap kept between neighbouring chunks |
| k = 60 | Constant in the RRF formula that fuses the vector and BM25 rankings |
| lambda 0.7 | MMR weight on relevance against novelty |
| 6 | top-k passages passed to the answering step |
| 25 MB, 23 MB, 120 MB | Embedder downloads: bge-small-zh-v1.5, all-MiniLM-L6-v2, multilingual-e5-small |
| 400 MB to 1.0 GB | The optional Qwen2.5 0.5B to 1.5B generator in 4-bit form |
| 3 to 8 tokens/s | Generation speed on the CPU/WASM path |
| 40 files, 200 MB, 20,000 chunks | Per-knowledge-base ceilings, with 10 files on phones |
| int8 and 4-bit | Quantisation used for the embedders and for the generator respectively |
Where the primary source sits elsewhere
This page describes how these terms are used here, not how they are defined by their originators. For model parameters, quantisation and licences, the upstream model page listed on the models page governs. For browser APIs such as IndexedDB, Cache Storage, WebGPU and WebAssembly, the platform documentation is authoritative. Where a figure here disagrees with a primary source, the primary source is right and this page is wrong: tell us at guweiicy@gmail.com and it gets corrected.