#ai#data#management

How to give an LLM your knowledge: RAG, llm-wiki, graphs, fine-tuning

Compare RAG, llm-wiki, knowledge graphs, and fine-tuning for giving LLMs your knowledge, including when Obsidian helps and when it becomes unnecessary overhead.

  • Three verbs that get mixed up
  • RAG: runtime retrieval and why it is about tokens
  • The basic RAG formula
  • llm-wiki: discipline, not mechanism

01.07.2026 The base model knows what was in its training corpus at the time of training. It does not know your shipping policy, the history of a specific deal, your 1C architecture, or what you changed in the product last week. A rational decision-maker asks the first question like this: how do we give the model this knowledge without turning it into an expensive black box.

This question is most often reduced to one word - RAG

The narrowing itself is the source of confusion. RAG answers "how to retrieve knowledge at query time."

llm-wiki - for "how to structure knowledge in advance."

A knowledge graph is for "how to connect knowledge for multi-step questions."

Fine-tuning is for "how to bake knowledge and behavior into the model weights."

These are different layers, and they are regularly lined up as competitors, even though half of them work together just fine. This article is a map. Five approaches with honest pros and cons,

Decision tree

and the boundary after which a cloud setup with RAG is no longer sufficient. Canonical details for each approach live on separate pages - here they are linked in so the map stays a map.

5 layersin-context, llm-wiki, RAG, graph, fine-tuning
3 verbsretrieve, structure, embed
usually 1-2A real setup usually uses a couple of layers, not just one

Three verbs that get mixed up

Retrieve

At query time, find the needed piece of knowledge and place it into context. The model does not change - it is given the right reference for the specific question. That is RAG.

Structure (compile)

Pre-shape knowledge so it is easy to find and each fact lives in one place. This is about the discipline of how the knowledge itself is written, not the retrieval mechanism. This is llm-wiki.

Embed (fine-tune)

Change the model weights on your data so that knowledge and behavior become part of the model. To change one fact, you have to touch the weights again. This is fine-tuning.

The "RAG vs llm-wiki" debate is really a debate about whether to search the library or organize it. These are different tasks, and both are needed.

RAG: runtime retrieval and why it is about tokens

  1. RAG (retrieval-augmented generation) works like this.

  2. The corpus is pre-split into fragments (chunks) and each one is converted into a vector - a numeric representation of meaning.

  3. The user query is also turned into a vector, the storage is searched for the closest chunks by meaning, and the top-k of them are placed into the model context.

  4. The model answers based on this curated reference and can cite the source.

  5. The main practical advantage, which is often the real reason to choose RAG, is token minimization.

  6. Instead of stuffing the entire 100,000-page corpus into every query (which would hit the window limit and the cost ceiling), you only bring in the relevant slice for the specific question.

  7. The corpus can be huge - only a few fragments go into context.

  8. The other strengths follow from this.

  9. Instant updates: if a document changes, reindex it and answers follow the new version; the model weights do not need to be touched. Scale: the corpus grows independently of the model, and you work with a slice for each query. Auditability: the answer can be tied to the source - you can see where the fact came from; for policies, contracts, and compliance this is often the deciding argument.

  10. The bottleneck is named plainly: retrieval quality.

  11. If search pulls the wrong chunks, the model will confidently answer from the wrong reference. RAG is weak on "global" questions such as "what cross-cutting themes appear across all meeting minutes over a year" - where the answer is not in a few adjacent fragments but spread across the entire corpus. And it requires infrastructure: vector storage, indexing, and an update pipeline.

  12. How RAG works in detail and how we build it - on the page RAG tool.

  13. If the data contains personal data and work is carried out under Federal Law 152, anonymization is placed between the source and the model - this is the layer LLM Gateway.

llm-wiki: discipline, not mechanism

llm-wiki is not about search

It is about how knowledge is written before anyone starts looking for it. The idea is simple and old, like good engineering documentation.

Knowledge is precompiled into a coherent set of short markdown representations: the root README answers the question "which file should I open first"

, from there the needed file is found, one fact lives in one place, and everything is under git version control. The agent does not search for random snippets for every question - it reads the project map and summaries the way a new employee would: top down, from table of contents to detail. Hence the "No RAG" principle in the product Sloy: for structured corporate memory - "what is happening with the project now," which decisions were made, who owns what - reading the map is more reliable and explainable than fishing out chunks by similarity.

This is not "RAG is bad," but choosing the right tool for the layer; why "No RAG" works for this layer is on the page Sloy. The layers combine: RAG on top of a well-structured llm-wiki extracts from order, not chaos. How portable context is packaged in AGENTS.md, skills, and through MCP is covered in our AI principles.

Dump + similarity search

  • Knowledge is scattered across PDFs, chats, tickets, and people's heads
  • For each question - similarity search, sometimes off target
  • One fact in three places; two versions contradict each other
  • The answer source is not obvious

llm-wiki (compilation)

  • README -> the right file, table of contents findable
  • One fact - one place, git keeps the history
  • The agent reads the map, not guesswork chunks
  • What is outdated is removed immediately, not accumulated

Case

All cases

Sloy: memory for AI agents shows this principle in practice: chats, meetings, Drive, Git, tasks, and finance are turned into machine-readable context that AI agents work with. In the case, the important thing is not the term llm-wiki itself, but the effect: the work trail is linked to projects, clients, people, and money; heavy documents are turned into short AI representations; the agent answers from project memory without a manager manually restating it.

Do you need Obsidian

Obsidian is useful not to the model, but to the people preparing knowledge for the model. Its strengths are local Markdown files, links between notes, backlinks, the graph view, Canvas, and Web Clipper: an expert can turn minutes, decisions, and observations into a coherent base faster, which can later be read by an agent or indexed. The gain appears when corporate knowledge is created by experts and becomes stale quickly: architecture decisions, project diaries, product hypotheses, support FAQs, research notes.

Obsidian lowers the cost of keeping things organized: one fact is easier to keep in one file, relationships between topics stay visible, and sources do not get lost. For a team, this is not an industrial knowledge-delivery system, but an editorial workshop before llm-wiki or RAG. Where Obsidian is not needed. If knowledge already lives in 1C, CRM, ERP, Confluence, HelpDesk, GitLab, or DWH, and there are access rights, owners, and update processes, moving it into a separate repository is harmful: you get a parallel database with no owners and no update rules.

Then Obsidian can be used as a personal expert draft space, while controlled systems remain the source for the LLM.

WorkflowWhere it helpsWhere the line is
Personal and expert notesFaster to assemble a coherent Markdown base and spot gaps through links/backlinksYou need a fact owner, otherwise the notes become just another dump
A small team of researchers or architectsCanvas and a graph help map the links between decisions, documents, and hypothesesThis does not replace access control, review, or a single source of truth
Corporate knowledge base for LLMsObsidian can be an authoring environment before llm-wiki/RAGSearch, audit, and access control should live in a managed environment, not in a personal storage space
Controlled data and pluginsLocal storage and Sync with end-to-end encryption reduce part of the riskThird-party plugins run code on the user's behalf; enterprise environments need control

Conclusion: Obsidian is not a mandatory layer. It is worth using if it reduces authoring friction and helps keep knowledge in portable Markdown. It should not be turned into a corporate knowledge base search layer, a permissions system, or a substitute for data governance.

Assess where AI can deliver impact in your process

clients@kt.team Telegram @kt_team_it

Knowledge graphs and GraphRAG: when the question is multi-step

Ordinary RAG answers local questions: the answer is in one or two fragments, you find them - and you're done.

But there is a class of questions where similarity search gets structurally stuck. "How are this contract, this incident, and this board decision related?"

"What cross-cutting risks run through all the department's projects?" There is no answer in any single chunk - it is assembled from connections between many fragments. Similarity search will pull out a few similar pieces, but it will not see the structure that connects them. A knowledge graph solves this differently. Entities (people, projects, documents, events), the relationships between them, and communities - clusters of tightly connected entities - are extracted from the corpus in advance. Knowledge becomes not a list of fragments, but a network of nodes and edges.

The system answers the question not with a single search, but by traversing the graph: it follows relationships, gathers the relevant community, and uses its summary. That is GraphRAG. What this gives you. Global and multi-step questions: where the answer is a path through several entities, the graph walks that path explicitly. Explainability: you can see the reasoning path itself - which nodes and relationships led to the answer; this is not "the model decided so," but a traceable chain.

Community summaries: for a question about "what is going on overall," the system answers from cluster summaries, not from a random sample of chunks. The price is real: graphs are more expensive to build. Entities, relationships, and communities are usually extracted by the LLM itself as it processes the corpus - this is compute work before the first question is even asked.

If your questions are mostly local ("find a clause in this contract"

), a graph is overengineering: ordinary RAG is cheaper and sufficient. A graph pays off when the value is specifically in relationships and multi-step traversals.

Fine-tuning: knowledge and behavior are embedded in the weights

All previous approaches leave the model frozen and change what is fed into it.

Fine-tuning changes the model itself: its weights are adjusted on your data, and the required knowledge or behavior becomes part of the model.

What this unlocks

Locally, offline, on simple hardware: a small fine-tuned model can run on a modest GPU, on an edge device, or in an air-gapped environment without internet - the knowledge is already inside, so no external search is needed.

Low latency and context savings: you do not have to insert reference material into the prompt on every call; for high-volume scenarios where context cost dominates, this changes the economics.

Style and behavior: fine-tuning embeds not so much facts as manner - answer format, tone, and the domain-specific way of reasoning; RAG does not cover this side.

And the honest downsides that make fine-tuning a poor default for "just give the model our documents."

Knowledge is frozen: an embedded fact becomes stale along with the model - if the price, policy, or document version changes, you have to retrain; RAG simply reindexes here. You need a high-quality dataset: fine-tuning learns from what you provide, dirty data produces dirty behavior, and most teams do not have a clean labeled dataset, while assembling one is often more expensive than the task itself.

Training is expensive and slow, updating a single fact is difficult, there is a risk of forgetting and overfitting, and auditing "why the model answered like that"

harder than tracing a path in RAG or a graph

This is a map, not a fine-tuning manual. The canonical breakdown - when it is actually justified, how to prepare the dataset, and how LoRA differs from full tuning - is in a separate article Model Fine-Tuning: A Short Guide.

Fine-tuning: when it makes sense and when it is not the right tool

When it is justified

  • Privacy and air-gap: data must not leave the environment
  • Edge, weak hardware, offline use, latency is critical
  • High call volume where context cost dominates
  • Stable narrow domain plus specific behavior or format

When it is not needed

  • Knowledge changes often (prices, documentation, policies)
  • There is no clean labeled dataset (most teams do not have one)
  • Need source links and answer auditability
  • You need to be able to quickly fix one fact without touching the rest

In-context: when it is enough to paste it into the prompt

The simplest approach is mentioned last - because it is often the right one when the knowledge is small. In-context means placing the knowledge directly into the prompt: inserting the policy, example, or reference table as text before the question.

No infrastructure, no storage, no training.

For small, stable knowledge for a specific task, this is the least effort-intensive option.

The boundary is simple too: tokens and window

In-context burns tokens on every call - the knowledge is sent into context anew every time.

As the volume grows, you hit the window limit and the cost.

Once knowledge no longer fits comfortably or starts repeating in every call, it is time to look at RAG (retrieve only what is needed) or fine-tuning (bake it in so you do not have to carry it around).

Five approaches at once

At a glance: small stable knowledge - in-context; structured corporate memory - llm-wiki; a large changing corpus with auditability - RAG; questions about relationships - a graph; a stable domain with offline use, privacy, and behavior - fine-tuning. Obsidian sits alongside these not as a sixth approach, but as an authoring environment for preparing knowledge. In real setups, two layers are usually combined.

ApproachWhat it isStrengthWeaknessWhen to adopt
In-contextKnowledge is inserted directly into the promptZero infrastructure, instant startBurns tokens on every call, window limitSmall stable knowledge for one task
llm-wikiKnowledge compiled into coherent markdown: one fact per place, git-trackedOrder and explainability; the agent reads the map instead of guessingRequires authoring discipline; it is not a search mechanismStructured corporate memory, "what is the current status of the project"
RAGRuntime retrieval: top-k relevant chunks into contextMinimized tokens, instant updates, source linksRetrieval quality is the bottleneck; weak on broad questionsLarge changing corpus, freshness and auditability needed
Graph / GraphRAGA graph of entities, relationships, and communities; answer by traversing the graphMulti-step and broad questions, explainable pathsExpensive to build (the graph is built by the LLM); overkill for local questionsMany relationships, cross-cutting and multi-step questions
Fine-tuningKnowledge and behavior are embedded in the model weightsOffline, edge, privacy, low latency, style, and behaviorKnowledge is frozen, a dataset is needed, training is expensive, and facts are hard to updateStable narrow domain, offline, specific behavior

Decision tree

Choose based on the properties of the knowledge and the task, not on the trendiness of the term

Knowledge / task property

Small and stablefor a single task
Structured corporate memory"what is happening with the project now"
Large changing corpusNeed freshness, links, and auditability
Many relationshipsglobal and multi-step questions
Stable narrow domainoffline / edge / privacy / behavior

Approach

In-contextinsert into the prompt
llm-wiki (Sloy)compile knowledge
RAGextract at runtime
Graph / GraphRAGgraph traversal
Fine-tuningbake into the weights
A route by knowledge property: small and stable -> in-context; structured corporate memory -> llm-wiki (Sloy); a large changing corpus with auditing -> RAG; many relationships and multi-step questions -> graph; a stable narrow domain with offline use or privacy needs -> fine-tuning. The branches are not mutually exclusive. A real setup often combines two - llm-wiki as the map plus RAG on top for changing documents; or fine-tuning for behavior plus RAG for fresh facts. The table above shows the properties of the approaches, and the tree shows the path to the choice.

When the "standard" is enough - and where KT.Team helps

  1. For a rational decision-maker, the question is not "which is more advanced," but "where is the threshold after which it is worth paying for a more complex stack."

  2. The boundary is defined by the properties of the knowledge, not by terminology trends, and the when/when-not choice itself is already laid out in the table and in the fine-tuning section above. A short guide.

  3. Cloud-based RAG or llm-wiki is enough when knowledge changes often, source links and auditability are needed, the corpus is large, and there is no clean training dataset (most teams do not have one).

  4. Fine-tuning is justified when you need privacy and an air gap, offline and edge deployment, when call volume is high and context cost dominates, or when a stable narrow domain requires specific behavior to be locked in. And

Key point

, which removes the false choice: often the right answer is both layers.

Fine-tune a small model for the domain and behavior, and supply fresh facts through RAG or keep them in llm-wiki - then the model "knows" what it needs and does not become outdated with every document change. KT.Team builds this setup with a small AI-native team in short iterations, not as a large integrator project: we analyze the properties of your knowledge, calculate the economics for your configuration, and deliver a transferable result - an open-source-first stack that you keep, without vendor lock-in.

We speak plainly about economics and do not misrepresent the numbers: token costs across different models and budget comparisons are in a separate source blog for the figures; the actual token costs live there, instead of being scattered across articles.

For your own environment (on-prem, your own hardware), economics are determined by GPU utilization, not token price: idle hardware makes the setup more expensive, high utilization does the opposite; the bill depends on the configuration and is calculated in calculator, not by an invented "server per year" total.

An approach tailored to your task

We will help choose the layer and build the setup in short iterations

We do not sell "RAG for everything" and we do not push fine-tuning where llm-wiki would be enough. A small AI-native team analyzes the properties of your knowledge, calculates the economics for your configuration, and builds a working setup in iterations - transferable, open-source-first, without vendor lock-in. If simple in-context is enough, we will say that too.

  • Analyzing the properties of the knowledge and choosing the layer - usually 1-2, not "one for everything"
  • The economics of the stack are calculated for the specific configuration, not by a made-up figure
  • A transferable result: you take the stack with you, without vendor lock-in
Choose the layer and the rollout plan →

In your own environment, economics are not determined by token price

Key takeaways

One question - five different answers, and they are not competitors but layers

RAG answers "how to retrieve," llm-wiki answers "how to structure," a graph answers "how to connect," fine-tuning answers "how to bake in," and in-context answers "when you can just insert it."

The confusion starts when they are lined up as rivals; clarity comes when you see that they are about different things and often work together.

The practical guideline remains the same as in any engineering work: do not pay for complexity you do not need.

Small stable knowledge - in-context. Corporate memory - llm-wiki.

A large changing corpus with auditability - RAG. Questions about relationships - a graph.

A stable domain with offline use and privacy - fine-tuning

Use Obsidian when it helps people keep knowledge clean and connected; do not use it when it turns into a parallel database with no owners, access, or updates. And when you want "everything at once," the right answer is almost always two layers, not one for everything. Topic navigation.

Connecting data to the model at the tool level - through MCP.

If the task is not to "choose a layer," but to quickly build working intuition among executives and the first agent prototype - a separate format AI Agent Sprint for Executives.

Sources

Checked on: 2026-07-01

Discuss the article: How to Give LLMs Your Knowledge: RAG, llm-wiki,...

Send via:

By clicking the button, you accept the offer and grant consent to the processing of personal data.

Related solutions

All solutions
AI automation of accounting processesAI Agent Sprint for LeadersAI Assistants for ConstructionEnterprise AI Agent Management

Articles on the topic

All articles

Related videos

All videos
30:49 MEDSI Group President on Medicine, Their App and Hands-On AI Experience | Andrey Sokolov (Podcast) 30:21 Coffeemania IT Director on AI Adoption and the Importance of Clean Data | Nikolay Galkin (Podcast) 34:19 Trends in the Alcohol Industry, Adopting AI in Retail | Roman Nagornyak (Podcast)

News on the topic

All news