Agentic RAG vs Fine-Tuning vs LLM Wiki: What Is Actually Different?

One question, three places to do the work

All three give a model knowledge or behaviour it was not trained with. They differ in where that knowledge lives and when the expensive thinking happens.

• Agentic RAG keeps knowledge in source documents and indexes. Work happens at query time, every time.
• Fine-tuning moves knowledge or behaviour into the weights. Work happens once, at training time, and again whenever you retrain.
• LLM wiki keeps knowledge in a set of markdown pages the model writes and maintains. Work happens at ingest time, when a new source arrives.

That timing decides the cost profile, the update path, and the failure mode of each.

Agentic RAG: retrieval with a planner

Plain RAG embeds the question, pulls the nearest chunks, and stuffs them into the prompt. Agentic RAG puts an agent in charge of that loop. It can rewrite the query, choose between indexes or tools, read a result, decide the evidence is thin, and search again.

The cost is that nothing accumulates. The agent re-discovers the same relationships between documents on every question, and each retry is another model call. For a deeper look at the trade-offs against training, see the head-to-head on RAG vs fine-tuning.

Fine-tuning: change the model, not the context

Fine-tuning trains the model further on your examples. It is good at teaching a format, a house style, a classification scheme, or a narrow skill.

It is weak at facts. Knowledge absorbed into weights cannot be cited, is hard to inspect, and goes stale the day the source changes. If the real problem is that the model lacks your documents, fine-tuning is usually the expensive wrong answer.

LLM wiki: compile once, read many times

Karpathy published the LLM wiki idea as a GitHub gist on April 4, 2026. The pattern has three layers: raw sources the model reads but never edits, a wiki of model-written markdown pages (summaries, entity and concept pages, comparisons), and a schema file such as CLAUDE.md or AGENTS.md that sets conventions. An index.md catalogues pages and a log.md records every change.

Three operations run it. Ingest reads a new source and updates every page it touches. Query reads relevant wiki pages and answers with citations, optionally filing good answers back as new pages. Lint checks for contradictions, stale claims, and orphan pages. The gist frames it as "Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase."

The gist itself scopes the simple index approach to moderate scale, roughly 100 sources and hundreds of pages, and suggests adding search beyond that. It offers no benchmarks. The real risk is that the model is now an author: a wrong summary written at ingest is read as truth on every later query unless review catches it.

How to choose

Start from the failure you can least afford.

• Answers must be current and cited, corpus is large: agentic RAG.
• Output format or tone is wrong, facts are fine: fine-tuning.
• A focused domain you keep returning to, where synthesis across sources is the value: an LLM wiki.

They stack well. A wiki is just a curated corpus, so retrieval over it beats loading the whole thing once it outgrows a context window. That is the stacked approach described in stacked retrieval: check curated knowledge first and fall back to the model only when needed. RDK applies it to local vaults, indexing Obsidian or docs folders as encrypted private chunks, which cuts token spend 80 to 90 percent on repeated, reference-heavy work. The wiki debate also echoes the claim that teams have stopped using RAG: reading files by navigation is still retrieval.