I keep running into the same frustration with AI chat tools. You ask a specific question about something you know you read last week, and the model either confidently makes something up or gives you a generic answer that misses the point entirely. That is the hallucination problem in its most annoying, practical form.
RAG (Retrieval-Augmented Generation) is the architectural fix. The core idea: before asking an LLM to generate an answer, retrieve real documents that are relevant to the question and pass them as context. The model then answers based on text you actually provided, rather than reaching into its training weights and pattern-matching its way to something that sounds plausible but might be wrong.
What I find genuinely interesting is that this same architecture can run entirely inside a browser, grounded in the pages you have personally visited. That is what TraceMind does.
What RAG actually is (and is not)
RAG is not a model. It is a pipeline pattern. The three stages are:
- Index — take a corpus of documents, split them into chunks, embed each chunk as a vector, store those vectors.
- Retrieve — when a query arrives, embed the query, find the most semantically similar chunks in the index, return the top-k results.
- Generate — pass the retrieved chunks as context to an LLM, ask it to answer based only on that context.
The "grounding" happens in step three. The model is not being asked to recall facts from training. It is being asked to read the retrieved passages and synthesize an answer. If the retrieved passages do not contain the answer, a well-prompted RAG system will say so, rather than hallucinate.
This is a meaningful shift. Generic LLMs are trained on internet-scale data up to some cutoff date. They know things broadly but not specifically. They do not know what you specifically read. RAG turns your personal reading history into a retrieval corpus that the model can actually cite.
Why hallucinations happen and how retrieval fixes them
LLMs predict the next token based on statistical patterns learned during training. When a model does not have strong training signal for a specific fact, it interpolates from nearby patterns. The result looks fluent and confident, but the underlying grounding is weak.
I have seen this firsthand. Ask a general-purpose LLM about a niche library version, a specific design decision from a documentation page, or a particular finding from a research paper, and it will frequently give you an answer that sounds right but contains subtle (or not-so-subtle) errors.
The fix is to give the model the actual source material. When the retrieved chunks contain the correct answer, the model's job becomes summarization and synthesis, not recall. That is a much easier problem, and the error rate drops accordingly.
The honest caveat: RAG does not eliminate hallucinations entirely. If the retrieval step fails to surface the right documents, the model is back to guessing. Retrieval quality is the critical variable.
How TraceMind implements RAG on-device
TraceMind is a Chrome/Chromium extension (works on Chrome, Brave, and Edge) that passively indexes every page you visit. The indexed content is stored locally in IndexedDB. Mozilla's Readability library strips page content to clean text. SHA-256 deduplication prevents redundant storage. lz-string compression reduces storage footprint by 50-70%.
The embedding model is all-MiniLM-L6-v2, which produces 384-dimensional vectors. Inference runs via WebGPU where available, falling back to WASM. This model runs entirely in the browser with no server-side component.
Retrieval in TraceMind uses Reciprocal Rank Fusion (RRF) to combine two signals:
- Dense vector search — semantic similarity between the query embedding and stored page embeddings. This catches conceptually related pages even when exact keywords differ.
- FlexSearch full-text search — a BM25-like term-frequency index that catches exact keyword matches the semantic model might miss for proper nouns, version numbers, or domain-specific jargon.
RRF merges the ranked lists from both signals into a single ranked list. Pages that rank high in both tend to be genuinely relevant. Pages that only score well on one signal are included but ranked lower.
The top-k retrieved chunks then become context for the generation step. The whole pipeline, from query to answer, targets sub-100ms search latency.
If you want to understand the embedding layer specifically, I covered it in detail in the post on how vector embeddings work in your browser.
The retrieval corpus is your actual reading history
This is the part I think makes browser-based RAG qualitatively different from generic RAG demos.
Most RAG examples use a predefined document set: a product manual, a legal corpus, a company knowledge base. The retrieval pool is static and curated. Browser-based RAG uses a retrieval pool that is deeply personal and continuously growing.
The pages TraceMind indexes are the pages you chose to visit. That means the corpus is already filtered by your interests and work context. When you ask a question, the retrieved documents are not just semantically relevant, they are drawn from sources you found credible enough to read in the first place.
I have found this makes a real practical difference. When I ask about a React pattern I was researching last week, the retrieved context often includes the exact documentation section or blog post I was reading. The LLM's answer is anchored to that specific source, not to a generic interpolation of every React tutorial ever written.
The TraceMind features page covers what gets indexed and how retrieval works end to end.
Chunking strategy matters more than people realize
One implementation detail that significantly affects RAG quality is how you chunk documents before embedding.
If chunks are too large, a single chunk may contain multiple topics and the embedding will be a diluted average. The retrieved chunk will be relevant in one paragraph but noisy in the rest.
If chunks are too small, you lose the context needed to interpret a passage. A sentence that makes perfect sense in context might be ambiguous or misleading in isolation.
TraceMind uses Mozilla Readability to extract clean article text before chunking, which already removes navigation, ads, and boilerplate. The chunking then operates on clean content rather than HTML noise.
The overlap between adjacent chunks matters too. A small overlap (repeating the last sentence or two of the previous chunk in the start of the next) helps prevent important information from falling into a gap between chunk boundaries.
The limitations worth being honest about
RAG in the browser is genuinely useful, but there are tradeoffs worth naming.
Coverage depends on what you have visited. If you have never read a page about a topic, that topic is not in your retrieval corpus. The system can only surface what it has indexed. This is a feature in some ways (the corpus is personal and relevant) but a limitation in others (it cannot answer questions about things you have not browsed).
Embedding quality caps retrieval quality. all-MiniLM-L6-v2 is a good small model, but it is not the most powerful embedding model available. Complex conceptual queries sometimes require larger models to achieve the right semantic match. For a browser extension that needs to run in milliseconds without a GPU server, this is a deliberate engineering tradeoff.
Generation quality still depends on the LLM. RAG improves grounding, but the model still needs to coherently synthesize retrieved context into an answer. A low-quality generation model will produce low-quality answers even with excellent retrieval.
Chunked retrieval can miss document-level relationships. RAG retrieves chunks, not whole documents. If the answer to a question requires synthesizing information spread across multiple sections of a single document, retrieval might miss the connection.
These are not reasons to avoid RAG. They are reasons to have calibrated expectations about what it solves.
Why on-device RAG is worth the constraints
The alternative to on-device RAG is sending your browsing history to a cloud API. You upload your indexed pages to a server, the server embeds and retrieves them, and a hosted LLM generates the answer. The quality ceiling is higher. The privacy floor is much lower.
For a tool that indexes your complete browsing history, cloud processing is a significant privacy concession. Your browsing history is arguably more revealing than your search history. It contains what you actually read, not just what you queried.
TraceMind's zero-telemetry approach means the only network traffic the extension generates is an optional license validation call for Pro users. No page content, no embeddings, no query logs leave your machine.
On-device inference is slower and constrained by the models that fit in a browser runtime. But for personal browsing history, I think the privacy calculus strongly favors keeping everything local. The retrieval corpus is too sensitive to treat casually.
What this looks like in practice
The most common RAG use case in TraceMind is not conversational Q&A. It is semantic search: you describe what you are looking for in natural language, and the system returns the most relevant pages from your history, ranked by a combination of semantic and keyword relevance.
This is RAG with the generation step simplified. The "generation" is essentially ranking and surfacing, rather than synthesizing a prose answer. But the retrieval pipeline is the same: embed the query, find semantically similar chunks, return the source pages.
The practical impact is that you can find pages you visited with descriptions like "that article about CSS container queries and responsive design" even if you do not remember the exact title, URL, or keywords. The semantic embedding bridges the gap between how you remember something and how it was originally written.
This is the everyday version of RAG that, honestly, changes how often I re-Google things I have already read. The answer is usually already in my local index.
For a deeper look at how this fits into the broader question of what a Chrome history extension should do, the post on the best Chrome history extensions in 2026 covers the landscape in more detail.