Why a RAG project starts with preparing knowledge, not choosing a model
RAGnar and the RAGnar Knowledge Processor show why a good AI system starts with tidy preparation of documents, chunks and sources.
Uploading a PDF is not the same as having a knowledge system
In early RAG experiments the easiest thing is the one that sounds fastest: take a large PDF, upload it and expect precise answers straight away. In practice that is rarely enough.
A PDF can have a poor layout, overlong blocks of text, mixed headings, tables, headers, footnotes and content that is readable to a person but too noisy for a model and a vector database. Retrieval then returns chunks that are too broad or wrong, and a small local model tries to assemble an answer from the noise.
RAGnar as a private AI layer
RAGnar is a self-hosted, local RAG platform for building specialised assistants over private documentation. It uses Docker, FastAPI, Open WebUI, Ollama, Qdrant and NGINX to work with documents, embeddings, sources and retrieval settings locally.
The point is not that the model "knows everything". The point is that the system finds the relevant parts of internal documentation, passes them to the model and shows the source the answer came from.
The Knowledge Processor as a preparation layer
The RAGnar Knowledge Processor came from a practical problem: documents that are good to read are not necessarily good for retrieval.
The idea is simple. Take a PDF or DOCX, extract the text, clean it, recognise sections and turn one large document into smaller topical Markdown files. Instead of one large source you get a set of shorter, clearer and more searchable knowledge units.
What this gives you
When documents are split into smaller, meaningful units, retrieval becomes more precise. The model gets less noise, answers are shorter and tied to the source, and the user can see why the system answered the way it did.
This matters most for internal assistants covering HR, IT, security procedures, Linux guides, networking documentation or onboarding. There it is not enough for an answer to sound convincing. It has to be tied to a document the organisation really uses.
The key settings are not only technical
Chunk size, top-k, similarity threshold and temperature all matter. But they cannot fix a badly structured document. If a single chunk mixes ten topics, the model will easily join parts that do not belong in the same answer.
A good RAG project therefore has two parts: a system that answers and a process that prepares knowledge. RAGnar covers the first. The Knowledge Processor covers the second.
Conclusion
A good RAG system does not start with "which model should we use?" It starts with "what does our knowledge look like?"
If documents are clean, short, clear in topic and well labelled, even smaller local models can give useful answers. If documents are chaotic, a bigger model will not keep rescuing a bad input.
There is also a security side. Whatever goes into the knowledge base can influence the answers, which is why documents are part of the attack surface of every RAG system. That is the next thing worth testing.