Key AI Concepts (2): Fine-tuning / RAG / Function Calling / MCP#

This chapter organizes the key concepts you frequently run into when “attaching a pre-trained LLM to a service,” centered on Fine-tuning, RAG, Function Calling, and MCP. All four start from the same question: “How do we get the model to handle things it does not originally know?” They are presented in order: changing the model itself (Fine-tuning), giving it something to read (RAG), giving it work to do (Function Calling), and the protocol that standardizes how that work is assigned (MCP).

Fine-tuning#

Fine-tuning is the process of further training a pre-trained model so that it fits a specific purpose better. Thanks to open-source culture, training datasets and the models pre-trained on them are often published, and you can apply fine-tuning on top of them to improve performance or specialize in a particular domain. For example, if you build an AI chatbot for an e-commerce site selling clothing and use a public model as-is, it may handle general conversation but give unsatisfying answers to product questions, because it knows nothing about that service’s internal information such as its products and policies. Fine-tuning can be one alternative in such cases.

Fine-tuning comes in two forms: retraining the entire model (Full Fine-tuning), and efficiently training only a subset of the parameters (Parameter-Efficient Fine-tuning, PEFT). The former costs a lot of time and money and carries the risk of warping the model in unwanted directions, so research and adoption have recently focused on the latter.

To be honest from a one-person startup’s perspective, though, fine-tuning is rarely the first choice. Fine-tuning is strong at changing how the model behaves, such as “making the tone and format consistent” or “handling a specific classification task cheaply with a small model,” and weak at “teaching it the latest information or internal documents.” For the latter, RAG, described next, is far cheaper and safer.

RAG (Retrieval-Augmented Generation)#

RAG is a method in which, when the LLM generates an answer, it first “retrieves” relevant external material, then “attaches” the results to the question as reference material (context), and “generates” the answer. In other words, it is an approach that lets the LLM consult external documents (knowledge) directly, improving its output in terms of freshness, accuracy, and the ability to show evidence.

As ChatGPT launched and its user base exploded, one limitation came up again and again: it was hard to guarantee accurate or well-grounded answers about recent information outside the training range (the training cutoff) or internal organizational / domain knowledge. Because services that use LLMs are fundamentally built on pre-trained models, answers about recent data the model never trained on, or specialized data in a particular field, can be shaky in accuracy or come without evidence. RAG is one of the representative approaches that emerged to compensate for this limitation.

RAG is built on the embeddings explained in the previous chapter. You split documents into small chunks, convert them into embeddings, and store them (indexing); when a question comes in, you find the chunks closest to the question’s embedding (retrieval), then attach those chunks to the prompt and send it to the model (generation).

To sum up, there are two main ways to improve a model’s output on content beyond its pre-trained range: fine-tuning and RAG. Fine-tuning further trains the model itself, while RAG leaves the model alone and instead includes externally retrieved documents in the context for it to consult. In human terms, fine-tuning is like a support agent receiving extra training from the company to strengthen their knowledge and skills, while RAG is like handing that agent a laptop with internet search. RAG adds a retrieval / context-building step, so it can increase latency depending on the situation, but it can flexibly bring in recent information and domain knowledge to improve output without the cost and risk of retraining the model. The two techniques are not mutually exclusive, so you can also combine them depending on the situation and purpose.

Function Calling#

If RAG is “finding reference material and attaching it,” Function Calling (also called Tool Calling) is “actually executing the needed work and bringing back the result.” That is, while generating an answer, the LLM decides on its own to call a predefined tool (function), receives the execution result, and completes the final answer with it. Here, “tools” means API calls, DB queries, calculation functions, internal system actions, and so on that the developer has wired up in advance.

Let me clear up one misconception first: the LLM does not execute the function itself. The LLM only outputs a request as text (structured JSON) saying “this function should be called with these arguments”; the actual execution is done by the developer’s server. Feed the execution result back to the model, and the model produces the final answer. You need to understand this round trip to make sense of MCP and agents later on.

When to use RAG, and when to use Function Calling?#

• RAG: when the answer must be based on documents or knowledge, such as “which one is correct / what the policy is / what needs explaining”
• Function Calling: when lookup, calculation, or execution is needed, such as “what the current figure is / what must be executed”

In one sentence: RAG answers by reading; Function Calling answers by executing. Take a customer-support chatbot: “Tell me the refund policy” uses RAG to retrieve and quote the refund policy document, while “Process the refund too” uses Function Calling to call the order / payment system and report the outcome. In real services you use both together: policies / manuals / knowledge are backed by document retrieval, while real-time lookups / calculations / business operations are performed through tool calls.

The advantage of Function Calling is that it reduces the model’s tendency to answer “plausibly, in words only,” and lets it produce more accurate and consistent answers grounded in actual system data or external service (API) results. And making the model call tools repeatedly, over and over until the job is done is what we call an agent, covered in Chapter 4.

MCP (Model Context Protocol)#

To make broad use of Function Calling in a real service, you eventually face the question: “Which tools do we connect, and how?” MCP (Model Context Protocol) is a standard connection method (protocol) that emerged to solve this, providing a consistent specification for letting LLMs access a wide range of tools / data sources.

By analogy, electronic devices used to have all kinds of ports, which made cables and adapters a mess; once “let’s standardize on USB!” took hold, the peripheral ecosystem grew explosively. By standardizing how LLMs connect to external capabilities, MCP creates the conditions for “connectable tools” to be easier to build and easier to attach.

In fact, the API specs of LLM services like ChatGPT and Gemini have included Function Calling for a long time. But each service had its own protocol for things like “how function definitions are passed in and in what format the call results are fed back,” so the people building tools and the apps using them had a lot to align on. With the arrival of MCP, the way tools are connected became standardized, and a “connectable tool ecosystem” began forming quickly. As a result, Function Calling has risen from being an add-on feature of a particular vendor’s API to something closer to the basic interface for attaching diverse services / systems to an LLM.

How does MCP relate to Function Calling?#

• Function Calling: the act itself of the LLM “calling a tool (function)”
• MCP: the standard (connection method) for “in what specification those tools are connected and provided”

In other words, if Function Calling is “making a phone call,” MCP is closer to “the telephone network standard.”

MCP Client / MCP Server#

For an LLM to communicate with the outside world through MCP, you broadly need an MCP client and an MCP server.

• MCP client: receives the user’s request, composes it in a form the LLM can understand including the “list of available capabilities (specs)” of the connected MCP servers, actually executes the tool calls the LLM selects, and passes the results back to the LLM. Tools like the Claude app, Cursor, and Claude Code have an MCP client built in.
• MCP server: a server that exposes a specific external capability (e.g., document search / editing, data lookup, business operations) according to the MCP protocol. It can be provided officially by an external service, or implemented and deployed by an individual / team.

In many cases, users work inside an app that contains an MCP client and find and connect the MCP servers they need. For example, if a user connects the Notion MCP server to the Claude app and asks, “Find the chatbot-related tasks assigned to me in Notion and summarize them,” the app sends the request to the LLM along with the capability specs of the connected servers; if the LLM decides “I need to call the Notion server’s document-browsing capability,” the app calls that capability and fetches the result, and the LLM writes the summary based on it.

To sum up, we can combine existing MCP clients / servers to use capabilities quickly, implement an MCP client in our own backend to attach external capabilities, or, in the opposite direction, implement an MCP server to offer our own data / capabilities to the outside. That last direction is especially important for a one-person startup. It becomes a distribution channel that brings your product into the agents your users are already using, and it comes up again in the Execution section, in “Adding AI Features to Your Product.”

Summary#

The four are not competitors but tools at different layers. The next chapter looks at prompt engineering and context engineering, which deal with “how to explain these tools to the model and what material to feed it.”