RAG
A RAG chunking strategy for technical manuals
Splitting a manual into arbitrary-length pieces makes the right answer get searched in the wrong context. Preserve headings, tables and revision information.
RAG vs Fine-Tuning: Building Domain-Specific LLM Assistants
Retrieval-augmented generation and fine-tuning solve different problems. Knowing which to use — and why most production systems need both — prevents expensive mistakes.
Two ways to make an LLM domain-aware
A general-purpose LLM knows a lot about the world but nothing about *your* world: your plant's tag naming, your standard operating procedures, your vendor's register maps. Two techniques close that gap:
- Retrieval-augmented generation (RAG): retrieve relevant documents at query time and inject them into the prompt as context.
- Fine-tuning: continue training the model on domain data so its weights reflect your domain.
They solve different problems. RAG changes *what the model sees*. Fine-tuning changes *how the model thinks*.
What RAG actually does
A RAG pipeline has three parts: an index of documents (chunked and embedded), a retriever that finds the most relevant chunks for a query, and a synthesis step where the LLM answers using those chunks as evidence.
Benefits:
- Grounding: answers can cite sources; the system can point at the exact document behind a claim.
- Freshness: update the index and the assistant knows the new information immediately — no retraining.
- Transparency: retrieval quality is inspectable and testable independently of the model.
- Cost: no training run; the cost is indexing and retrieval.
What fine-tuning actually does
Fine-tuning updates model weights on a curated dataset of domain examples. Benefits:
- Style and behaviour: the model learns your terminology, output format, and interaction rules reliably.
- Latency and cost at inference: a tuned model can be smaller and still perform well, reducing per-query cost.
- Consistency: the behaviour is baked in — no retrieval step to fail.
The costs are real: data curation, training infrastructure, evaluation, and versioning. And fine-tuning does not give the model new facts reliably — it teaches patterns, and it can still hallucinate specifics it never memorized.
Comparing the trade-offs
| Aspect | RAG | Fine-tuning |
|---|---|---|
| Knowledge freshness | Instant (re-index) | Needs retraining |
| Source citation | Natural | Not inherent |
| Failure mode | Bad retrieval → weak context | Hallucination of tuned patterns |
| Cost | Index + retrieval | Training run |
| Best for | Facts, procedures, docs | Tone, format, domain behaviour |
The evidence-first pattern
Production industrial assistants typically use RAG as the spine — ground every answer in retrieved evidence and show the sources — and optionally fine-tune a small model to follow output contracts (clean HTML, tables, step lists) reliably. That is exactly the architecture behind tools like Kutup NQ: curated, versioned datasets are the retrieval corpus; a synthesis model formats the answer; and every response exposes its evidence so engineers can verify it.
Key point: If you need answers you can verify, start with RAG. Add fine-tuning only when a specific behaviour — output format, tone, tool use — is consistently wrong at acceptable retrieval quality.
Keep reading.
Full library
RAG
Industrial RAG: how to measure answer quality
Evaluate answers from engineering manuals with source relevance, device context and appropriate abstention.
RAG
Making LLMs Reliable for Industrial Q&A: Evidence-First Design
General chatbots hallucinate; industrial answers must be verifiable. This article describes the evidence-first design pattern: curated corpora, hybrid retrieval, constrained synthesis, and inspectable output.