What is the difference between RAG and fine-tuning?

RAG retrieves relevant information at question time and gives it to the model as context, so the answer reflects whatever your data says right now. Fine-tuning adjusts the model's own weights to change how it responds, which suits consistent formatting or behaviour but does not teach it facts that change. RAG is cheaper to update, and its answers can be traced back to a source.

Can you add AI features to an application we already have?

Yes — that is most of this work. The retrieval and model layers are added behind your existing API and reuse your current authentication, roles and database. No rebuild is required.

Which models and providers do you work with?

OpenAI most often, with the model layer kept behind an interface so a provider can be swapped without touching application code. That boundary matters more than the initial choice — pricing and capability in this space change faster than most products ship a release.

RAG and LLM application developmentService — RAG & LLM Applications

Retrieval-augmented generation and LLM features built into real products — chunking, embeddings, evaluation and cost control, not a wrapper around a prompt.

When RAG is the right answer

RAG suits the case where the model needs to answer from information it was never trained on, and where that information changes. Fine-tuning suits the case where you need the model to adopt a consistent format or behaviour that prompting cannot reach. Most products that think they need fine-tuning need retrieval, and most that need both should build retrieval first — it is cheaper to change, and it makes the answers checkable.

Chunking, embeddings and the vector store

Retrieval quality is decided long before the model is called. Chunk boundaries that split a table or a clause in half will return fragments that make no sense in isolation, and no amount of prompt engineering recovers from that.

Chunking strategy chosen against the actual document structure
Embedding model selected for the domain, not by default
Vector store sized to the corpus — pgvector, Chroma or a managed service
Metadata filtering, so retrieval can be scoped by tenant, date or source
Re-ranking where the first-pass results are close together

Grounding, citations and evaluation

Every answer carries a path back to the passages it came from, which is what makes the output auditable rather than merely fluent. Evaluation runs against a fixed question set with known-good answers, so a change to chunking, the prompt or the model can be measured instead of eyeballed — the alternative is shipping a regression nobody notices until a customer does.

Adding LLM features to an existing product

Most of this work is integration, not greenfield. The retrieval layer and model calls sit behind your existing API, the vector store runs alongside your current database, and the feature ships as an addition to the product rather than a parallel system. Existing authentication, roles and tenancy rules apply to the AI features exactly as they do to everything else.

Controlling inference cost

Inference cost is an architecture problem. Retrieving the right three passages instead of stuffing twenty into the context window is the largest single saving; caching deterministic responses, routing simple requests to a smaller model, and trimming system prompts that grew organically all follow from there.

Where I’ve done this

Shipped projects that use the work described above.

Common questions

What is the difference between RAG and fine-tuning?: RAG retrieves relevant information at question time and gives it to the model as context, so the answer reflects whatever your data says right now. Fine-tuning adjusts the model's own weights to change how it responds, which suits consistent formatting or behaviour but does not teach it facts that change. RAG is cheaper to update, and its answers can be traced back to a source.
Can you add AI features to an application we already have?: Yes — that is most of this work. The retrieval and model layers are added behind your existing API and reuse your current authentication, roles and database. No rebuild is required.
Which models and providers do you work with?: OpenAI most often, with the model layer kept behind an interface so a provider can be swapped without touching application code. That boundary matters more than the initial choice — pricing and capability in this space change faster than most products ship a release.