01 / THE PROBLEM
What needed to change
Finding an answer in large technical documentation takes time, and a plain LLM chat with no document grounding can give a plausible but wrong answer — the model answers from its guesses, not from fact.
04AI assistantReadyDemo project
DocuMind
An AI assistant for technical documentation: semantic search, source-grounded answers, free local inference.
DocuMind is an AI assistant for documentation: it answers only from indexed sources, cites them, and honestly declines when the answer isn't in the knowledge base.
Next.jsTypeScriptPostgreSQL (pgvector)OllamaSupabase
02 / THE SOLUTION
How the solution works
DocuMind searches by meaning (semantic search via pgvector) inside the indexed document corpus and builds its answer strictly from what it found. If nothing relevant is found, the model isn't called at all — the refusal happens at the retrieval layer, not as something the model decides. Every citation the model returns is then checked against what was actually retrieved: a source that doesn't exist is dropped, and an answer with zero confirmed citations is shown as an honest refusal, not as a grounded answer.
03 / KEY FEATURES
Key capabilities
Only the capabilities that support the core user journey.
- 01Semantic search over the document corpus via pgvector (real embeddings, not keyword matching)
- 02Answers grounded in retrieved sources (RAG), with source cards — document, section, excerpt
- 03Retrieval-layer refusal: the model is never called when nothing relevant is found
- 04Citation validation: a nonexistent source is dropped, and an answer with no confirmed citations isn't shown as grounded
- 05Prompt-injection resistant: document content is explicitly marked as untrusted data, not instructions
- 06Free local inference (Ollama, qwen3:4b + nomic-embed-text) — no external API calls or per-request cost; a cloud provider (OpenAI) is supported as a separate option
- 07Answers in Russian regardless of the corpus language, with sources and citations kept in the original for verification
- 08Chat history with sources preserved — reopening a past conversation never calls the model again
- 09A knowledge-base browser listing the indexed documents and their sections
05 / ARCHITECTURE
What happens beneath the interface
Documents are split into meaning-aware chunks (by heading, paragraph, and sentence — not an arbitrary length) and turned into embeddings, either locally via Ollama (nomic-embed-text) or via OpenAI, selected by a single setting. Chunks are stored in PostgreSQL with pgvector and an HNSW index. A user's question is embedded the same way and matched via cosine similarity inside Postgres; if nothing clears a measured similarity threshold, the language model isn't called at all. When it is called, generation is grounded in the retrieved chunks and returned in a structured, schema-validated form; the model's citations are intersected with what was actually retrieved before the answer reaches the user.
06 / VERIFICATION
A result you can verify
These figures refer to the recorded, verified version of the project.
0Lintfindings
0Typecheckerrors
32 / 32Unit tests (Vitest)passed, 11 files
SuccessfulBuild
100%Top-1/3/5 retrieval hit rate16 eval questions, real Ollama embeddings
19 / 20RAG evaluation (real generation)citation integrity 100%
07 / LIMITATIONS
Demo boundaries
- —A demo implementation over a small, fixed synthetic document corpus — not a tool for arbitrary file uploads.
- —Local CPU inference (Ollama) is noticeably slower than a cloud API — single-digit to tens of seconds per answer; an accepted tradeoff for free, fully local operation.
- —The OpenAI provider is implemented behind the same interface but not live-verified (account quota during development) — the actually measured, working path is local Ollama.
NEXT STEP
Have a similar task?
Describe it in your own words — I'll reply with how I'd approach it.