RAG vs Fine-Tuning expliqués : ce qu’ils font réellement et quand les utiliser

j’ai beaucoup écrit sur RAG, en commençant par le Guide du voyageur sur RAG avec l’API ChatGPT et LangChain, puis en explorant divers sujets liés à RAG et à l’IA, comme le chunking, la recherche hybride, le reclassement, la récupération contextuelle et une série en trois parties sur l’évaluation de la qualité de la récupération. En d’autres termes, nous avons parcouru beaucoup de chemin du côté RAG.

Ce dont nous n’avons pas parlé aussi explicitement, c’est l’autre technique majeure utilisée par les gens lorsqu’ils souhaitent améliorer une application LLM pour un domaine spécifique. C’est réglage fin. Et en particulier, nous n’avons pas parlé de ce qui se passe lorsque vous mettez les deux côte à côte et essayez de déterminer lequel vous avez réellement besoin.

Si vous recherchez « RAG vs réglage fin » En ligne, vous trouverez de nombreux contenus qui traitent cela comme une compétition avec un gagnant. Pour certains, RAG gagne parce qu’il est moins cher à mettre en place, pour d’autres, le réglage fin gagne parce qu’il produit de meilleurs résultats, et ainsi de suite. Le problème avec ce cadrage est qu’il est fondamentalement trompeur, puisque RAG et le réglage fin ne sont pas des techniques concurrentes, mais plutôt des techniques qui résolvent différents problèmes à différentes couches d’une application d’IA. Comprendre ce que chacun fait réellement est la condition préalable. pour prendre une bonne décision.

Alors, jetons un coup d’œil !

🍨 Crème de données est une newsletter sur l’IA, les données et la technologie. Si ces sujets vous intéressent, abonnez-vous ici!

Qu’est-ce que RAG et que fait-il réellement ?

Si vous avez suivi cette série, vous avez déjà une solide intuition pour RAG. Mais répétons-le encore une fois, car la définition précise compte pour la comparaison avec le réglage fin qui suit.

Ainsi, RAG, ou Retrieval-Augmented Generation, est une technique qui améliore la réponse d’un LLM en récupérant des informations externes pertinentes au moment de l’inférence et en les injectant dans l’invite. Le modèle lui-même n’est en rien modifié. Ce qui change, c’est ce qu’il considère comme une entrée.

Le pipeline ressemble à ceci :

• Premièrement, les documents externes (la base de connaissances que nous souhaitons utiliser) sont traités en intégrations vectorielles et stockés dans une base de données vectorielles.
• Lorsqu’un utilisateur soumet une requête, celle-ci est également convertie en intégration et les morceaux de document les plus sémantiquement similaires sont récupérés de la base de données.
• Ces morceaux sont ensuite transmis au LLM avec la requête de l’utilisateur, afin que le modèle puisse générer une réponse fondée sur ce contexte spécifique récupéré.

Et c’est tout.

Voici un exemple RAG minimal utilisant l’API OpenAI :

from openai import OpenAI
import numpy as np

client = OpenAI(api_key="your_api_key")

# our tiny knowledge base
documents = [
    "pialgorithms is an AI-powered document management platform.",
    "pialgorithms allows teams to search, extract, and automate document workflows.",
    "pialgorithms was founded in Athens, Greece.",
]

# embed the knowledge base
def embed(texts):
    response = client.embeddings.create(
        model="text-embedding-3-small",
        input=texts
    )
    return [r.embedding for r in response.data]

doc_embeddings = embed(documents)

# embed the user query and retrieve the most relevant chunk
query = "Where is pialgorithms based?"
query_embedding = embed([query])[0]

# cosine similarity
def cosine_similarity(a, b):
    return np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b))

similarities = [cosine_similarity(query_embedding, doc_emb) for doc_emb in doc_embeddings]
best_match = documents[np.argmax(similarities)]

# inject retrieved context into the prompt
response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {
            "role": "system",
            "content": f"Answer the user's question using only the following context:\n\n{best_match}"
        },
        {
            "role": "user",
            "content": query
        }
    ]
)

print(response.choices[0].message.content)
# pialgorithms is based in Athens, Greece.

Prenons un moment pour comprendre ce qui se passe réellement ici. Bien sûr, le modèle n’a aucune idée de ce que pialgorithmes provient de sa formation, mais comme nous avons récupéré le bon morceau de document et l’avons injecté dans l’invite, le modèle est capable de répondre avec précision. La connaissance vient de l’extérieur du modèle, au moment de la requête, et le modèle lui-même reste intact.

C’est le cœur de ce que fait RAG : il donne au modèle l’accès à des connaissances externes sur lesquelles il n’a jamais été formé, de manière dynamique, au moment de l’inférence.

Et selon la façon dont il fonctionne, RAG réussit bien sur des types de tâches spécifiques, comme par exemple :

• Répondre à des questions sur des documents, des bases de connaissances ou des données que le modèle n’a jamais vues
• Rester à jour sans reconversion, puisque la base de connaissances peut être mise à jour de manière indépendante à tout moment
• Fournir des réponses traçables et citables, puisque vous savez exactement quel morceau de document a été récupéré
• Gérer les informations privées ou exclusives en toute sécurité, sans inclure ces informations dans le modèle

D’un autre côté, voici ce que RAG ne fera pas : il ne changera pas le comportement, le ton, le style de raisonnement ou l’exécution des tâches du modèle. Si votre modèle a tendance à être verbeux, RAG ne le rendra pas plus concis. S’il rencontre des difficultés avec un format de sortie particulier, RAG ne résoudra pas ce problème.

Qu’est-ce que le réglage fin et à quoi sert-il réellement ?

Le réglage fin est le processus consistant à prendre un modèle pré-entraîné et à continuer de l’entraîner sur un nouvel ensemble de données spécifique à une tâche, en mettant à jour son poids dans le processus. En d’autres termes, tandis que RAG modifie les entrées du modèle, le réglage fin modifie le modèle lui-même.

Plus précisément, un modèle de base comme GPT-4o-mini est pré-entraîné sur un ensemble de données générales massives. Le réglage fin prend ce modèle et exécute une boucle de formation supplémentaire plus courte sur des exemples spécifiques pertinents pour notre cas d’utilisation spécifique. Ces exemples se présentent généralement sous la forme de paires d’entrées-sorties. De cette façon, les pondérations du modèle sont ajustées afin qu’il produise des résultats qui ressemblent davantage à ces paires d’exemples.

Voici à quoi ressemblerait un travail de réglage fin à l’aide de l’API OpenAI :

from openai import OpenAI
import json

client = OpenAI(api_key="your_api_key")

# Step 1: prepare training data as a JSONL file
# each example is a conversation with a desired output
training_examples = [
    {
        "messages": [
            {"role": "system", "content": "You are a concise technical assistant. Always respond in one sentence."},
            {"role": "user", "content": "What is a vector database?"},
            {"role": "assistant", "content": "A vector database stores and retrieves data as high-dimensional numerical vectors, enabling fast semantic similarity search."}
        ]
    },
    {
        "messages": [
            {"role": "system", "content": "You are a concise technical assistant. Always respond in one sentence."},
            {"role": "user", "content": "What is chunking in RAG?"},
            {"role": "assistant", "content": "Chunking is the process of splitting large documents into smaller pieces before embedding them, so they fit within model context limits and improve retrieval precision."}
        ]
    },
    # in practice you would want at least 50-100 examples
]

# save as JSONL
with open("training_data.jsonl", "w") as f:
    for example in training_examples:
        f.write(json.dumps(example) + "\n")

# upload the training file
with open("training_data.jsonl", "rb") as f:
    training_file = client.files.create(file=f, purpose="fine-tune")

# create the fine-tuning job
fine_tune_job = client.fine_tuning.jobs.create(
    training_file=training_file.id,
    model="gpt-4o-mini-2024-07-18"
)
print(fine_tune_job.id)

Une fois le travail de réglage fin terminé, OpenAI renvoie un identifiant de modèle unique pour votre modèle nouvellement peaufiné, au format ft:base-model:your-org:your-suffix:unique-id. Il s’agit désormais d’un modèle distinct qui réside dans votre compte OpenAI, distinct de la base gpt-4o-mini.

Sur printnous récupérerions un id pour ce modèle affiné, ressemblant à ceci :

ft:gpt-4o-mini-2024-07-18:your-org:your-suffix:abc123

Nous pouvons alors l’appeler exactement comme n’importe quel autre modèle, simplement en passant cet identifiant dans le champ model paramètre:

# once the job is complete, use the fine-tuned model
response = client.chat.completions.create(
    model="ft:gpt-4o-mini-2024-07-18:your-org:your-suffix:abc123",
    messages=[
        {"role": "user", "content": "What is prompt caching?"}
    ]
)
print(response.choices[0].message.content)

La différence est que ce modèle a déjà intériorisé le comportement sur lequel nous l’avons formé : dans notre exemple, il répondra désormais systématiquement dans une phrase concise, sans que nous ayons à lui demander de le faire à chaque invite du système. C’est le genre de choses pour lesquelles le réglage fin est vraiment efficace : un formatage cohérent, un ton spécifique, le respect d’une structure de sortie particulière ou une amélioration des performances sur un type de tâche très spécifique. Et c’est essentiellement ce que fait le réglage fin.

Remarquez comment le réglage fin n’a aucun impact sur l’incorporation d’informations spécifiques dans le modèle. Contrairement à ce que l’on pourrait supposer intuitivement, affiner un modèle sur les documents de votre entreprise ne permettra pas au modèle « d’apprendre » ces informations et d’être capable de répondre de manière fiable aux questions à ce sujet. Cela peut en effet amener le modèle à mémoriser des faits spécifiques à partir d’exemples de formation ici et là, mais cette mémorisation est fragile et peu fiable. Le résultat le plus probable serait un modèle hallucinant sur des sujets apparaissant dans les exemples de formation, plutôt qu’un modèle rappelant avec précision des détails spécifiques apparaissant dans ces exemples. Ainsi, si la récupération de connaissances est ce dont vous avez besoin, RAG est le bon outil, pas un réglage fin.

Plus précisément, le réglage fin donne de bons résultats dans les domaines suivants :

• « Enseigner » au modèle un format, un ton ou un style de sortie cohérent
• Améliorer les performances sur un type de tâche spécifique et restreint (par exemple, toujours générer un JSON valide, toujours résumer en trois puces, etc.)
• Réduire le besoin d’invites système longues et répétitives en intégrant ces instructions dans le modèle
• Adapter le modèle au langage ou à la terminologie spécifique au domaine, afin qu’il comprenne et utilise le bon vocabulaire

Néanmoins, le réglage fin ne donne pas de bons résultats dans :

• En ajoutant des connaissances factuelles fiables, le modèle peut rappeler avec précision
• Garder le modèle à jour avec l’évolution des informations
• Fournir des réponses traçables et citables

Alors, quand utilisons-nous chacun et quand utilisons-nous les deux ?

Maintenant que nous comprenons ce que fait réellement chaque technique, le «RAG vs réglage fin» Il devient beaucoup plus facile de répondre à cette question, car dans la plupart des cas, il ne s’agit pas vraiment d’une question de type « contre ».

RAG et réglage fin fonctionnent à différentes couches d’une application d’IA. RAG fonctionne au niveau de la couche de connaissances, ce qui signifie qu’il contrôle les informations auxquelles le modèle a accès. D’un autre côté, le réglage fin opère au niveau du comportement, ce qui signifie qu’il définit la manière dont le modèle traite les informations fournies et génère des réponses. Ces deux couches sont indépendantes l’une de l’autre, ce qui signifie que vous pouvez utiliser RAG, un réglage fin ou les deux, en fonction de ce que vous essayez d’atteindre.

Voici donc un cadre décisionnel pratique pour décider quoi utiliser :

Le scénario dans lequel nous utilisons à la fois RAG et réglage fin est en fait le plus courant dans les systèmes de production réels. La façon la plus simple de garder les deux droits est la suivante : affiner le comportement, utiliser RAG pour les connaissances.

Imaginez, par exemple, que nous construisions un assistant de support client pour un produit logiciel et que nous en ayons besoin pour :

1. Répondez toujours sur un ton et un format spécifiques, cohérents avec notre marque de logiciel
2. Avoir une connaissance précise et à jour de la documentation de nos produits

Pour une telle tâche, nous devrons utiliser à la fois RAG et le réglage fin. En particulier, un réglage précis répondrait à la première exigence en permettant au modèle d’apprendre à partir d’exemples de réponses idéales du support client, en lui apprenant le bon ton, le bon niveau de détail et le bon format de sortie. La deuxième exigence serait couverte par RAG : au moment de l’inférence, les informations les plus pertinentes de la documentation du produit sont récupérées et injectées dans l’invite, permettant au modèle de fournir des réponses fiables fondées sur la documentation.

Ainsi, en pratique, nous pouvons combiner à la fois le réglage fin et le RAG en appelant un modèle affiné de la même manière que nous appellerions n’importe quel autre modèle, mais également en injectant le contexte récupéré dans l’invite système, exactement comme nous le ferions dans un pipeline RAG standard.

# combining fine-tuned model with RAG
response = client.chat.completions.create(
    model="ft:gpt-4o-mini-2024-07-18:your-org:support-style:abc123",  # fine-tuned for tone/format
    messages=[
        {
            "role": "system",
            "content": f"You are a helpful support assistant for pialgorithms. "
                       f"Use only the following documentation to answer:\n\n{retrieved_context}"  # RAG context
        },
        {
            "role": "user",
            "content": user_question
        }
    ]
)

Le réglage fin permet au modèle de savoir comment réagir de manière appropriée, et RAG lui dit quoi dire. Il ne s’agit donc pas d’une question de « réglage fin ou RAG », mais plutôt de réglage fin et de RAG qui se complètent et font des choses différentes.

Dans mon esprit

Ce que je trouve le plus intéressant dans le débat RAG vs réglage fin, c’est la fréquence à laquelle il est formulé comme une question de savoir quelle technique est la meilleure, alors que la question la plus utile est de savoir quel problème vous essayez réellement de résoudre.

RAG et réglage fin abordent différents modes de défaillance d’un LLM de base. Si un modèle de base échoue parce qu’il ne sait pas quelque chose, c’est un problème de connaissance et RAG le résout. Si un modèle de base échoue parce qu’il se comporte de manière incohérente ou produit des sorties dans un format incorrect, il s’agit d’un problème de comportement et un réglage fin le résout. Si votre modèle échoue pour les deux raisons à la fois, vous aurez peut-être réellement besoin des deux.

✨ Merci d’avoir lu ! ✨

---

Si tu es arrivé jusqu’ici, les pialgorithmes pourraient vous être utiles: une plateforme que nous avons créée qui aide les équipes à gérer en toute sécurité les connaissances organisationnelles en un seul endroit.

---

Vous avez adoré cet article ? Rejoignez-moi sur 💌 Sous-pile et 💼 LinkedIn

---

Toutes les images sont de l’auteur, sauf indication contraire.