@@ -416,7 +416,7 @@
Lecture de données
Nous allons dans cet exemple, extraire 10 textes pour des raisons de rapidité :
-
+
import json
import numpy as np
import pandas as pd
@@ -445,7 +445,7 @@ Lecture de données
Vectoriser nos textes avec ChromaDB
Pour vectoriser nos textes, nous utilisons ChromaDB qui s’intègre avec Langchain. Nous allons découper en morceau des 3000 caractères à chaque saut à ligne, ce qui correspond à un paragraphe. Les morceaux de textes, ici paragraphes, sont stockés dans une boutique de vecteur avec le numéro de dossier et le numéro de paragraphe en métadonnées.
-
+
text_splitter = CharacterTextSplitter(
separator="\n\n",
chunk_size=3000,
@@ -472,7 +472,7 @@ Vector
Interroger un LLM en mode API
Pour interroger le LLM, nous construisons une classe qui permet de générer les requêtes et de traiter les réponses :
-
+
MODEL="llama3.1"
@@ -493,7 +493,7 @@ Interroger u
llm = LocalOllamaLLM(api_url="http://127.0.0.1:11434")
Nous définissons également un prompt de base, améliorable par la suite, et une chaîne LangChain entre le prompt et le LLM :
-
+
system_prompt = (
" Répondez à la question posée "
" Utilisez le contexte (sélection des meilleurs paragraphes liés à la question) donné pour répondre à la question "
@@ -510,7 +510,7 @@ Interroger u
question_answer_chain = create_stuff_documents_chain(llm, prompt)
Nous définissons une fonction pour effectuer le RAG, avec à la fois la recherche de similarité par rapport à la question, et la soumission augmentée pour une réponse du LLM :
-
+
def search_and_invoke_llm(vector_store,index,query,k=5):
if k==0:
print(f"bug with {index}")
@@ -535,7 +535,7 @@ Interroger u
Automatiser la classification sur l’ensemble des thématiques
Nous automatisons ici la classification sous forme de classification binaire pour chaque thématique, en posant une question “oui ou non” et en inférant oui si la réponse commence par oui, non sinon.
-
+
THEMATIQUES={
"accord_methode_penibilite":"Accords de méthode (pénibilité)",
"accord_methode_pse":"Accords de méthode (PSE)",
@@ -626,7 +626,7 @@
Evaluation
Nous évaluons les performances de cette solution simple, en affichant la matrice de confusion et les différentes métriques, pour chaque thématique :
-
+
import numpy as np
from sklearn.metrics import confusion_matrix
from sklearn.metrics import accuracy_score, precision_score, recall_score, f1_score, classification_report
diff --git a/search.json b/search.json
index a3e9d91..382f9a9 100644
--- a/search.json
+++ b/search.json
@@ -325,7 +325,7 @@
"href": "II-Developpements/2_Utilisation_LLM.html",
"title": "PARTIE II. Développements autour des LLMs (pour les data scientists)",
"section": "",
- "text": "Il faut avant tout garder à l’esprit que le prompt engineering est une discipline très empirique, qui demande beaucoup d’itérations pour obtenir le meilleur prompt par rapport au résultat souhaité. Bien qu’il n’existe pas de méthode systématique et efficace pour optimiser un prompt, certaines pratiques sont devenues la norme. Par exemple, voici quelques bonnes pratiques :\n\nDonner un rôle au modèle : Par exemple, dire au modèle qu’il est un magistrat honnête et impartial pourra l’aider à générer du texte formel, neutre et juridique. Le rôle est bien sûr à adapter en fonction des exigences de chaque tâche.\nStructurer le prompt : Il est important de bien différencier le prompt système du prompt utilisateur. Le premier donnera des instructions générales quant au style, à la tâche, au contexte, etc., alors que le second pourra donner des instructions spécifiques ou un texte à analyser. Il est également pertinent d’organiser ou de séparer clairement les instructions.\nEtre le plus précis possible :\nContraindre le modèle au maximum :\nDonner des exemples : Cf. paragraphe suivant.\n\nLe papier Principled Instructions Are All You Need for Questioning LLaMA-1/2, GPT-3.5/4 donne un certains nombre de principes pour améliorer les prompts. Parmi ces principes (très nombreux), on trouve par exemple :\n\nNe pas etre poli avec le LLM si l’on souhaite une réponse concise.\nDécrire l’audience souhaitée dans le prompt (des experts techniques, des enfants, etc.).\nUtiliser des directives affirmatives (fais ceci), et éviter les tournures négatives (ne fais pas cela).\nEmployer des phrases telles que ‘Ta tache est de’ ou ‘Tu DOIS’.\nRépéter plusieurs fois certains mots ou phrases essentielles.\n\n\n\n\nLa façon la plus intuitive d’adresser une requête à un LLM est de formuler des instructions les plus précises possibles. Ce faisant, on espère que le modèle comprendra ces instructions et répondra en conséquence. Pour des tâches nouvelles, auxquelles le modèle n’a pas nécessairement été confronté durant son (pré)-entraînement, on appelle cette méthode du 0-shot prompting : le modèle n’a pas de référence ou d’exemple de réponse attendue.\nPour pallier ce manque de référence, il est possible (et, en fonction de la tâche, souvent recommandé) d’ajouter des exemples de paires entrée/sortie dans le prompt que l’on adresse au modèle : cela donne du 1-shot (un exemple) ou du few-shot (plusieurs exemples) prompting. Plus les exemples sont proches de la requête initiale, plus le modèle saura précisément comment répondre. Cela permet ainsi au modèle de s’adapter, à moindre coût, à une tâche très spécifique ou particulière.\n\nGuide pratique (avec exemples)\n\n\n\n\nSur certaines tâches qui demandent un raisonnement (par exemple la résolution d’un problème mathématique simple), les LLM naturellement ne sont pas très bons. Pour augmenter leurs capacités de raisonnement, une stratégie classique consiste à leur demander de raisonner et de réfléchir étape par étape.\nLes modèles les plus récents ayant nettement progressé en raisonnement, il est possible qu’ils raisonnent naturellement étape par étape sur des questions simples. Pour des questions ou des raisonnements plus complexes, il sera cependant probablement plus efficace de proposer une logique de raisonnement au modèle, en explicitant les différentes étapes.\nIl est également possible de combiner le CoT reasoning avec du few-shot prompting, i.e. de donner des exemples de raisonnement étape par étape au modèle.\n\nGuide détaillé\n\n\n\n\nUne façon de travailler ses prompts est de profiter des capacités génératives des LLMs pour leur faire créer des prompts. L’idée est de donner au LLM un exemple de sortie souhaitée, et de lui demander de générer le prompt le plus adapté possible pour produire cette sortie.\n\nGuide pratique\n\n\n\n\n\n\n\nLa première question à se poser est la nécessité ou non d’utiliser un LLM. Certaines tâches peuvent se résoudre avec un LLM, mais ce n’est pas toujours la solution la plus pertinente. Par exemple, un LLM est normalement capable de parser un fichier xml sans problème, mais un script naïf sera largement aussi efficace, à bien moindre coût (environnemental, humain, financier). L’utilisation d’un LLM doit venir d’un besoin de compréhension fine du langage naturel.\nDonner quelques exemples de cas d’usages\n\n\n\nBeaucoup d’éléments sont à prendre en compte lors du choix du modèle à utiliser. Parmi les plus importants :\n\nSa taille : Exprimée généralement en milliards (B) de paramètres (Llama-3 8B possède 8 milliards de paramètres, Mistral 7B en possède 7 milliards, etc.), elle influe fortement sur les performances du modèles et les exigences techniques. Un « petit » LLM de 8 milliards de paramètres pourra tourner sur un GPU modeste avec une VRAM de 32 GB (voire moins si l’on utilise un modèle quantifié, cf. …), tandis qu’un LLM de taille moyenne de 70 milliards de paramètres nécessitera 2 GPU puissants avec 80 GB de VRAM.\nSon multilinguisme : La plupart des modèles sont entraînés sur une immense majorité de données anglaises (plus de 90 % pour Llama-2, contre moins de 0,1 % de données françaises). Les modèles incluant plus de français (Mistral ?) dans leurs données d’entraînement sont naturellement plus efficaces sur du français.\nSon temps d’inférence : Généralement directement lié à la taille du modèle, certaines architectures (MoE) permettent cependant d’avoir un temps d’inférence plus court.\nSes performances générales : Beaucoup de benchmarks publics évaluent les LLMs sur des tâches généralistes et variées. Un bon point de départ est de regarder le Leaderboard qui recense la plupart des modèles connus.\nSes performances spécifiques : Les benchmarks généralistes ne sont pas forcément pertinents pour certains cas d’usages, car ils ne sont pas spécifiques à la tâche, aux données, etc. Il peut être intéressant de développer un pipeline d’évaluation spécifique (cf…).\n\nEn juin 2024, un bon point de départ est de regarder les modèles open-source de Meta (Llama-2 7B/13B/70B, Llama-3 8B/70B) et de Mistral AI (Mistral 7B, Mixtral 8x7B).\n\n\n\nSi vous êtes dans l’un des cas suivants, le prompt engineering peut être une bonne option :\n\nPas beaucoup de ressources disponibles\nBesoin d’un outil laissé à la disposition des utilisateurs, avec une grande liberté\nLes réponses requises sont très formattées ou très spécifiques\n\n\n\n\nSi vous êtes dans l’un des cas suivants, la RAG peut être une bonne option :\n\nBesoin de réponses à jour, régulièrement et facilement actualisées\nBesoin de sourcer les réponses ou de diminuer les hallucinations\nBesoin d’enrichir les réponses avec des données spécifiques\nBesoin d’une application qui ne dépend pas d’un modèle spécifique (généralisabilité), et dont les utilisateurs ne connaissent pas l’IA générative\n\n\n\n\nSi vous êtes dans l’un des cas suivants, le fine-tuning peut être une bonne option :\n\nBesoin d’une terminologie ou d’un style spécifique\nBesoin d’enrichir les réponses avec des données spécifiques\nRessources (GPU, data scientists) disponibles\nDonnées disponibles en quantité et qualité suffisantes\nBesoin d’une application qui ne dépend pas d’un modèle spécifique (généralisabilité), et dont les utilisateurs ne connaissent pas l’IA générative\n\n\n\n\nRAG + fine-tuning = RAFT",
+ "text": "Il faut avant tout garder à l’esprit que le prompt engineering est une discipline très empirique, qui demande beaucoup d’itérations pour obtenir le meilleur prompt par rapport au résultat souhaité. Bien qu’il n’existe pas de méthode systématique et efficace pour optimiser un prompt, certaines pratiques sont devenues la norme. Par exemple, voici quelques bonnes pratiques :\n\nDonner un rôle au modèle : Par exemple, dire au modèle qu’il est un magistrat honnête et impartial pourra l’aider à générer du texte formel, neutre et juridique. Le rôle est bien sûr à adapter en fonction des exigences de chaque tâche.\nStructurer le prompt : Il est important de bien différencier le prompt système du prompt utilisateur. Le premier donnera des instructions générales quant au style, à la tâche, au contexte, etc., alors que le second pourra donner des instructions spécifiques ou un texte à analyser. Il est également pertinent d’organiser ou de séparer clairement les instructions.\nEtre le plus précis possible : Rajouter le plus de détails possibles, voire se répéter dans les instructions en changeant de formulation permet de bien insister sur les éléments les plus importants.\nContraindre le modèle au maximum : Si l’on souhaite un format de sortie précis (JSON par exemple), donner un exemple concret de sortie attendue, et insister sur le besoin de se conformer à ce format.\nDonner des exemples : Cf. paragraphe suivant (few-shot prompting).\n\nLe papier Principled Instructions Are All You Need for Questioning LLaMA-1/2, GPT-3.5/4 donne un certains nombre de principes pour améliorer les prompts. Parmi ces principes (très nombreux), on trouve par exemple :\n\nNe pas etre poli avec le LLM si l’on souhaite une réponse concise.\nDécrire l’audience souhaitée dans le prompt (des experts techniques, des enfants, etc.).\nUtiliser des directives affirmatives (fais ceci), et éviter les tournures négatives (ne fais pas cela).\nEmployer des phrases telles que ‘Ta tache est de’ ou ‘Tu DOIS’.\nRépéter plusieurs fois certains mots ou phrases essentielles.\n\n\n\n\nLa façon la plus intuitive d’adresser une requête à un LLM est de formuler des instructions les plus précises possibles. Ce faisant, on espère que le modèle comprendra ces instructions et répondra en conséquence. Pour des tâches nouvelles, auxquelles le modèle n’a pas nécessairement été confronté durant son (pré)-entraînement, on appelle cette méthode du 0-shot prompting : le modèle n’a pas de référence ou d’exemple de réponse attendue.\nPour pallier ce manque de référence, il est possible (et, en fonction de la tâche, souvent recommandé) d’ajouter des exemples de paires entrée/sortie dans le prompt que l’on adresse au modèle : cela donne du 1-shot (un exemple) ou du few-shot (plusieurs exemples) prompting. Plus les exemples sont proches de la requête initiale, plus le modèle saura précisément comment répondre. Cela permet ainsi au modèle de s’adapter, à moindre coût, à une tâche très spécifique ou particulière.\n\nGuide pratique (avec exemples)\n\n\n\n\nSur certaines tâches qui demandent un raisonnement (par exemple la résolution d’un problème mathématique simple), les LLM naturellement ne sont pas très bons. Pour augmenter leurs capacités de raisonnement, une stratégie classique consiste à leur demander de raisonner et de réfléchir étape par étape.\nLes modèles les plus récents ayant nettement progressé en raisonnement, il est possible qu’ils raisonnent naturellement étape par étape sur des questions simples. Pour des questions ou des raisonnements plus complexes, il sera cependant probablement plus efficace de proposer une logique de raisonnement au modèle, en explicitant les différentes étapes.\nIl est également possible de combiner le CoT reasoning avec du few-shot prompting, i.e. de donner des exemples de raisonnement étape par étape au modèle.\n\nGuide détaillé\n\n\n\n\nUne façon de travailler ses prompts est de profiter des capacités génératives des LLMs pour leur faire créer des prompts. L’idée est de donner au LLM un exemple de sortie souhaitée, et de lui demander de générer le prompt le plus adapté possible pour produire cette sortie.\n\nGuide pratique\n\n\n\n\n\n\n\nLa première question à se poser est la nécessité ou non d’utiliser un LLM. Certaines tâches peuvent se résoudre avec un LLM, mais ce n’est pas toujours la solution la plus pertinente. Par exemple, un LLM est normalement capable de parser un fichier xml sans problème, mais un script naïf sera largement aussi efficace, à bien moindre coût (environnemental, humain, financier). L’utilisation d’un LLM doit venir d’un besoin de compréhension fine du langage naturel.\n\n\n\nBeaucoup d’éléments sont à prendre en compte lors du choix du modèle à utiliser. Parmi les plus importants :\n\nSa taille : Exprimée généralement en milliards (B) de paramètres (Llama-3 8B possède 8 milliards de paramètres, Mistral 7B en possède 7 milliards, etc.), elle influe fortement sur les performances du modèles et les exigences techniques. Un « petit » LLM de 8 milliards de paramètres pourra tourner sur un GPU modeste avec une VRAM de 32 GB (voire moins si l’on utilise un modèle quantifié, cf. …), tandis qu’un LLM de taille moyenne de 70 milliards de paramètres nécessitera 2 GPU puissants avec 80 GB de VRAM.\nSon multilinguisme : La plupart des modèles sont entraînés sur une immense majorité de données anglaises (plus de 90 % pour Llama-2, contre moins de 0,1 % de données françaises). Les modèles incluant plus de français (Mistral ?) dans leurs données d’entraînement sont naturellement plus efficaces sur du français.\nSon temps d’inférence : Généralement directement lié à la taille du modèle, certaines architectures (MoE) permettent cependant d’avoir un temps d’inférence plus court.\nSes performances générales : Beaucoup de benchmarks publics évaluent les LLMs sur des tâches généralistes et variées. Un bon point de départ est de regarder le Leaderboard qui recense la plupart des modèles connus.\nSes performances spécifiques : Les benchmarks généralistes ne sont pas forcément pertinents pour certains cas d’usages, car ils ne sont pas spécifiques à la tâche, aux données, etc. Il peut être intéressant de développer un pipeline d’évaluation spécifique (cf…).\n\nEn juin 2024, un bon point de départ est de regarder les modèles open-source de Meta (Llama-2 7B/13B/70B, Llama-3 8B/70B) et de Mistral AI (Mistral 7B, Mixtral 8x7B).\n\n\n\nSi vous êtes dans l’un des cas suivants, le prompt engineering peut être une bonne option :\n\nPas beaucoup de ressources disponibles\nBesoin d’un outil laissé à la disposition des utilisateurs, avec une grande liberté\nLes réponses requises sont très formattées ou très spécifiques\n\n\n\n\nSi vous êtes dans l’un des cas suivants, la RAG peut être une bonne option :\n\nBesoin de réponses à jour, régulièrement et facilement actualisées\nBesoin de sourcer les réponses ou de diminuer les hallucinations\nBesoin d’enrichir les réponses avec des données spécifiques\nBesoin d’une application qui ne dépend pas d’un modèle spécifique (généralisabilité), et dont les utilisateurs ne connaissent pas l’IA générative\n\n\n\n\nSi vous êtes dans l’un des cas suivants, le fine-tuning peut être une bonne option :\n\nBesoin d’une terminologie ou d’un style spécifique\nBesoin d’enrichir les réponses avec des données spécifiques\nRessources (GPU, data scientists) disponibles\nDonnées disponibles en quantité et qualité suffisantes\nBesoin d’une application qui ne dépend pas d’un modèle spécifique (généralisabilité), et dont les utilisateurs ne connaissent pas l’IA générative\n\n\n\n\nIl est tout à fait possible de fine-tuner un LLM sur une tâche de RAG par exemple. Peu de travaux ont été faits sur cette combinaison, mais le papier RAFT (Retrieval Augmented Fine-Tuning) en donne une vision d’ensemble et en propose une méthode.",
"crumbs": [
"II-Développements",
"Techniques d'utilisation d'un LLM"
@@ -336,7 +336,7 @@
"href": "II-Developpements/2_Utilisation_LLM.html#techniques-dutilisation-dun-llm",
"title": "PARTIE II. Développements autour des LLMs (pour les data scientists)",
"section": "",
- "text": "Il faut avant tout garder à l’esprit que le prompt engineering est une discipline très empirique, qui demande beaucoup d’itérations pour obtenir le meilleur prompt par rapport au résultat souhaité. Bien qu’il n’existe pas de méthode systématique et efficace pour optimiser un prompt, certaines pratiques sont devenues la norme. Par exemple, voici quelques bonnes pratiques :\n\nDonner un rôle au modèle : Par exemple, dire au modèle qu’il est un magistrat honnête et impartial pourra l’aider à générer du texte formel, neutre et juridique. Le rôle est bien sûr à adapter en fonction des exigences de chaque tâche.\nStructurer le prompt : Il est important de bien différencier le prompt système du prompt utilisateur. Le premier donnera des instructions générales quant au style, à la tâche, au contexte, etc., alors que le second pourra donner des instructions spécifiques ou un texte à analyser. Il est également pertinent d’organiser ou de séparer clairement les instructions.\nEtre le plus précis possible :\nContraindre le modèle au maximum :\nDonner des exemples : Cf. paragraphe suivant.\n\nLe papier Principled Instructions Are All You Need for Questioning LLaMA-1/2, GPT-3.5/4 donne un certains nombre de principes pour améliorer les prompts. Parmi ces principes (très nombreux), on trouve par exemple :\n\nNe pas etre poli avec le LLM si l’on souhaite une réponse concise.\nDécrire l’audience souhaitée dans le prompt (des experts techniques, des enfants, etc.).\nUtiliser des directives affirmatives (fais ceci), et éviter les tournures négatives (ne fais pas cela).\nEmployer des phrases telles que ‘Ta tache est de’ ou ‘Tu DOIS’.\nRépéter plusieurs fois certains mots ou phrases essentielles.\n\n\n\n\nLa façon la plus intuitive d’adresser une requête à un LLM est de formuler des instructions les plus précises possibles. Ce faisant, on espère que le modèle comprendra ces instructions et répondra en conséquence. Pour des tâches nouvelles, auxquelles le modèle n’a pas nécessairement été confronté durant son (pré)-entraînement, on appelle cette méthode du 0-shot prompting : le modèle n’a pas de référence ou d’exemple de réponse attendue.\nPour pallier ce manque de référence, il est possible (et, en fonction de la tâche, souvent recommandé) d’ajouter des exemples de paires entrée/sortie dans le prompt que l’on adresse au modèle : cela donne du 1-shot (un exemple) ou du few-shot (plusieurs exemples) prompting. Plus les exemples sont proches de la requête initiale, plus le modèle saura précisément comment répondre. Cela permet ainsi au modèle de s’adapter, à moindre coût, à une tâche très spécifique ou particulière.\n\nGuide pratique (avec exemples)\n\n\n\n\nSur certaines tâches qui demandent un raisonnement (par exemple la résolution d’un problème mathématique simple), les LLM naturellement ne sont pas très bons. Pour augmenter leurs capacités de raisonnement, une stratégie classique consiste à leur demander de raisonner et de réfléchir étape par étape.\nLes modèles les plus récents ayant nettement progressé en raisonnement, il est possible qu’ils raisonnent naturellement étape par étape sur des questions simples. Pour des questions ou des raisonnements plus complexes, il sera cependant probablement plus efficace de proposer une logique de raisonnement au modèle, en explicitant les différentes étapes.\nIl est également possible de combiner le CoT reasoning avec du few-shot prompting, i.e. de donner des exemples de raisonnement étape par étape au modèle.\n\nGuide détaillé\n\n\n\n\nUne façon de travailler ses prompts est de profiter des capacités génératives des LLMs pour leur faire créer des prompts. L’idée est de donner au LLM un exemple de sortie souhaitée, et de lui demander de générer le prompt le plus adapté possible pour produire cette sortie.\n\nGuide pratique\n\n\n\n\n\n\n\nLa première question à se poser est la nécessité ou non d’utiliser un LLM. Certaines tâches peuvent se résoudre avec un LLM, mais ce n’est pas toujours la solution la plus pertinente. Par exemple, un LLM est normalement capable de parser un fichier xml sans problème, mais un script naïf sera largement aussi efficace, à bien moindre coût (environnemental, humain, financier). L’utilisation d’un LLM doit venir d’un besoin de compréhension fine du langage naturel.\nDonner quelques exemples de cas d’usages\n\n\n\nBeaucoup d’éléments sont à prendre en compte lors du choix du modèle à utiliser. Parmi les plus importants :\n\nSa taille : Exprimée généralement en milliards (B) de paramètres (Llama-3 8B possède 8 milliards de paramètres, Mistral 7B en possède 7 milliards, etc.), elle influe fortement sur les performances du modèles et les exigences techniques. Un « petit » LLM de 8 milliards de paramètres pourra tourner sur un GPU modeste avec une VRAM de 32 GB (voire moins si l’on utilise un modèle quantifié, cf. …), tandis qu’un LLM de taille moyenne de 70 milliards de paramètres nécessitera 2 GPU puissants avec 80 GB de VRAM.\nSon multilinguisme : La plupart des modèles sont entraînés sur une immense majorité de données anglaises (plus de 90 % pour Llama-2, contre moins de 0,1 % de données françaises). Les modèles incluant plus de français (Mistral ?) dans leurs données d’entraînement sont naturellement plus efficaces sur du français.\nSon temps d’inférence : Généralement directement lié à la taille du modèle, certaines architectures (MoE) permettent cependant d’avoir un temps d’inférence plus court.\nSes performances générales : Beaucoup de benchmarks publics évaluent les LLMs sur des tâches généralistes et variées. Un bon point de départ est de regarder le Leaderboard qui recense la plupart des modèles connus.\nSes performances spécifiques : Les benchmarks généralistes ne sont pas forcément pertinents pour certains cas d’usages, car ils ne sont pas spécifiques à la tâche, aux données, etc. Il peut être intéressant de développer un pipeline d’évaluation spécifique (cf…).\n\nEn juin 2024, un bon point de départ est de regarder les modèles open-source de Meta (Llama-2 7B/13B/70B, Llama-3 8B/70B) et de Mistral AI (Mistral 7B, Mixtral 8x7B).\n\n\n\nSi vous êtes dans l’un des cas suivants, le prompt engineering peut être une bonne option :\n\nPas beaucoup de ressources disponibles\nBesoin d’un outil laissé à la disposition des utilisateurs, avec une grande liberté\nLes réponses requises sont très formattées ou très spécifiques\n\n\n\n\nSi vous êtes dans l’un des cas suivants, la RAG peut être une bonne option :\n\nBesoin de réponses à jour, régulièrement et facilement actualisées\nBesoin de sourcer les réponses ou de diminuer les hallucinations\nBesoin d’enrichir les réponses avec des données spécifiques\nBesoin d’une application qui ne dépend pas d’un modèle spécifique (généralisabilité), et dont les utilisateurs ne connaissent pas l’IA générative\n\n\n\n\nSi vous êtes dans l’un des cas suivants, le fine-tuning peut être une bonne option :\n\nBesoin d’une terminologie ou d’un style spécifique\nBesoin d’enrichir les réponses avec des données spécifiques\nRessources (GPU, data scientists) disponibles\nDonnées disponibles en quantité et qualité suffisantes\nBesoin d’une application qui ne dépend pas d’un modèle spécifique (généralisabilité), et dont les utilisateurs ne connaissent pas l’IA générative\n\n\n\n\nRAG + fine-tuning = RAFT",
+ "text": "Il faut avant tout garder à l’esprit que le prompt engineering est une discipline très empirique, qui demande beaucoup d’itérations pour obtenir le meilleur prompt par rapport au résultat souhaité. Bien qu’il n’existe pas de méthode systématique et efficace pour optimiser un prompt, certaines pratiques sont devenues la norme. Par exemple, voici quelques bonnes pratiques :\n\nDonner un rôle au modèle : Par exemple, dire au modèle qu’il est un magistrat honnête et impartial pourra l’aider à générer du texte formel, neutre et juridique. Le rôle est bien sûr à adapter en fonction des exigences de chaque tâche.\nStructurer le prompt : Il est important de bien différencier le prompt système du prompt utilisateur. Le premier donnera des instructions générales quant au style, à la tâche, au contexte, etc., alors que le second pourra donner des instructions spécifiques ou un texte à analyser. Il est également pertinent d’organiser ou de séparer clairement les instructions.\nEtre le plus précis possible : Rajouter le plus de détails possibles, voire se répéter dans les instructions en changeant de formulation permet de bien insister sur les éléments les plus importants.\nContraindre le modèle au maximum : Si l’on souhaite un format de sortie précis (JSON par exemple), donner un exemple concret de sortie attendue, et insister sur le besoin de se conformer à ce format.\nDonner des exemples : Cf. paragraphe suivant (few-shot prompting).\n\nLe papier Principled Instructions Are All You Need for Questioning LLaMA-1/2, GPT-3.5/4 donne un certains nombre de principes pour améliorer les prompts. Parmi ces principes (très nombreux), on trouve par exemple :\n\nNe pas etre poli avec le LLM si l’on souhaite une réponse concise.\nDécrire l’audience souhaitée dans le prompt (des experts techniques, des enfants, etc.).\nUtiliser des directives affirmatives (fais ceci), et éviter les tournures négatives (ne fais pas cela).\nEmployer des phrases telles que ‘Ta tache est de’ ou ‘Tu DOIS’.\nRépéter plusieurs fois certains mots ou phrases essentielles.\n\n\n\n\nLa façon la plus intuitive d’adresser une requête à un LLM est de formuler des instructions les plus précises possibles. Ce faisant, on espère que le modèle comprendra ces instructions et répondra en conséquence. Pour des tâches nouvelles, auxquelles le modèle n’a pas nécessairement été confronté durant son (pré)-entraînement, on appelle cette méthode du 0-shot prompting : le modèle n’a pas de référence ou d’exemple de réponse attendue.\nPour pallier ce manque de référence, il est possible (et, en fonction de la tâche, souvent recommandé) d’ajouter des exemples de paires entrée/sortie dans le prompt que l’on adresse au modèle : cela donne du 1-shot (un exemple) ou du few-shot (plusieurs exemples) prompting. Plus les exemples sont proches de la requête initiale, plus le modèle saura précisément comment répondre. Cela permet ainsi au modèle de s’adapter, à moindre coût, à une tâche très spécifique ou particulière.\n\nGuide pratique (avec exemples)\n\n\n\n\nSur certaines tâches qui demandent un raisonnement (par exemple la résolution d’un problème mathématique simple), les LLM naturellement ne sont pas très bons. Pour augmenter leurs capacités de raisonnement, une stratégie classique consiste à leur demander de raisonner et de réfléchir étape par étape.\nLes modèles les plus récents ayant nettement progressé en raisonnement, il est possible qu’ils raisonnent naturellement étape par étape sur des questions simples. Pour des questions ou des raisonnements plus complexes, il sera cependant probablement plus efficace de proposer une logique de raisonnement au modèle, en explicitant les différentes étapes.\nIl est également possible de combiner le CoT reasoning avec du few-shot prompting, i.e. de donner des exemples de raisonnement étape par étape au modèle.\n\nGuide détaillé\n\n\n\n\nUne façon de travailler ses prompts est de profiter des capacités génératives des LLMs pour leur faire créer des prompts. L’idée est de donner au LLM un exemple de sortie souhaitée, et de lui demander de générer le prompt le plus adapté possible pour produire cette sortie.\n\nGuide pratique\n\n\n\n\n\n\n\nLa première question à se poser est la nécessité ou non d’utiliser un LLM. Certaines tâches peuvent se résoudre avec un LLM, mais ce n’est pas toujours la solution la plus pertinente. Par exemple, un LLM est normalement capable de parser un fichier xml sans problème, mais un script naïf sera largement aussi efficace, à bien moindre coût (environnemental, humain, financier). L’utilisation d’un LLM doit venir d’un besoin de compréhension fine du langage naturel.\n\n\n\nBeaucoup d’éléments sont à prendre en compte lors du choix du modèle à utiliser. Parmi les plus importants :\n\nSa taille : Exprimée généralement en milliards (B) de paramètres (Llama-3 8B possède 8 milliards de paramètres, Mistral 7B en possède 7 milliards, etc.), elle influe fortement sur les performances du modèles et les exigences techniques. Un « petit » LLM de 8 milliards de paramètres pourra tourner sur un GPU modeste avec une VRAM de 32 GB (voire moins si l’on utilise un modèle quantifié, cf. …), tandis qu’un LLM de taille moyenne de 70 milliards de paramètres nécessitera 2 GPU puissants avec 80 GB de VRAM.\nSon multilinguisme : La plupart des modèles sont entraînés sur une immense majorité de données anglaises (plus de 90 % pour Llama-2, contre moins de 0,1 % de données françaises). Les modèles incluant plus de français (Mistral ?) dans leurs données d’entraînement sont naturellement plus efficaces sur du français.\nSon temps d’inférence : Généralement directement lié à la taille du modèle, certaines architectures (MoE) permettent cependant d’avoir un temps d’inférence plus court.\nSes performances générales : Beaucoup de benchmarks publics évaluent les LLMs sur des tâches généralistes et variées. Un bon point de départ est de regarder le Leaderboard qui recense la plupart des modèles connus.\nSes performances spécifiques : Les benchmarks généralistes ne sont pas forcément pertinents pour certains cas d’usages, car ils ne sont pas spécifiques à la tâche, aux données, etc. Il peut être intéressant de développer un pipeline d’évaluation spécifique (cf…).\n\nEn juin 2024, un bon point de départ est de regarder les modèles open-source de Meta (Llama-2 7B/13B/70B, Llama-3 8B/70B) et de Mistral AI (Mistral 7B, Mixtral 8x7B).\n\n\n\nSi vous êtes dans l’un des cas suivants, le prompt engineering peut être une bonne option :\n\nPas beaucoup de ressources disponibles\nBesoin d’un outil laissé à la disposition des utilisateurs, avec une grande liberté\nLes réponses requises sont très formattées ou très spécifiques\n\n\n\n\nSi vous êtes dans l’un des cas suivants, la RAG peut être une bonne option :\n\nBesoin de réponses à jour, régulièrement et facilement actualisées\nBesoin de sourcer les réponses ou de diminuer les hallucinations\nBesoin d’enrichir les réponses avec des données spécifiques\nBesoin d’une application qui ne dépend pas d’un modèle spécifique (généralisabilité), et dont les utilisateurs ne connaissent pas l’IA générative\n\n\n\n\nSi vous êtes dans l’un des cas suivants, le fine-tuning peut être une bonne option :\n\nBesoin d’une terminologie ou d’un style spécifique\nBesoin d’enrichir les réponses avec des données spécifiques\nRessources (GPU, data scientists) disponibles\nDonnées disponibles en quantité et qualité suffisantes\nBesoin d’une application qui ne dépend pas d’un modèle spécifique (généralisabilité), et dont les utilisateurs ne connaissent pas l’IA générative\n\n\n\n\nIl est tout à fait possible de fine-tuner un LLM sur une tâche de RAG par exemple. Peu de travaux ont été faits sur cette combinaison, mais le papier RAFT (Retrieval Augmented Fine-Tuning) en donne une vision d’ensemble et en propose une méthode.",
"crumbs": [
"II-Développements",
"Techniques d'utilisation d'un LLM"
diff --git a/sitemap.xml b/sitemap.xml
index d3d914c..9c478af 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -2,78 +2,78 @@
https://etalab.github.io/programme10pourcent-kallm/IV-Exemples/2_Classification_accords_entreprise.html
- 2024-11-07T14:42:26.051Z
+ 2024-11-07T14:47:48.087Z
https://etalab.github.io/programme10pourcent-kallm/I-Accompagnement/4_Impacts.html
- 2024-11-07T14:42:26.051Z
+ 2024-11-07T14:47:48.087Z
https://etalab.github.io/programme10pourcent-kallm/I-Accompagnement/2_Deja_Fait_Admin.html
- 2024-11-07T14:42:26.051Z
+ 2024-11-07T14:47:48.087Z
https://etalab.github.io/programme10pourcent-kallm/II-Developpements/4_Evaluations.html
- 2024-11-07T14:42:26.051Z
+ 2024-11-07T14:47:48.087Z
https://etalab.github.io/programme10pourcent-kallm/II-Developpements/0_Introduction.html
- 2024-11-07T14:42:26.051Z
+ 2024-11-07T14:47:48.087Z
https://etalab.github.io/programme10pourcent-kallm/II-Developpements/3_RAG.html
- 2024-11-07T14:42:26.051Z
+ 2024-11-07T14:47:48.087Z
https://etalab.github.io/programme10pourcent-kallm/notebooks/10p_RAG_OLLAMA.html
- 2024-11-07T14:42:26.067Z
+ 2024-11-07T14:47:48.103Z
https://etalab.github.io/programme10pourcent-kallm/III-Deploiements/1_Socle_minimal.html
- 2024-11-07T14:42:26.051Z
+ 2024-11-07T14:47:48.087Z
https://etalab.github.io/programme10pourcent-kallm/III-Deploiements/3_Socle_Production.html
- 2024-11-07T14:42:26.051Z
+ 2024-11-07T14:47:48.087Z
https://etalab.github.io/programme10pourcent-kallm/Reste_a_faire.html
- 2024-11-07T14:42:26.051Z
+ 2024-11-07T14:47:48.091Z
https://etalab.github.io/programme10pourcent-kallm/III-Deploiements/2_Socle_avance.html
- 2024-11-07T14:42:26.051Z
+ 2024-11-07T14:47:48.087Z
https://etalab.github.io/programme10pourcent-kallm/III-Deploiements/4_Infras_administrations.html
- 2024-11-07T14:42:26.051Z
+ 2024-11-07T14:47:48.087Z
https://etalab.github.io/programme10pourcent-kallm/Bibliographie.html
- 2024-11-07T14:42:26.051Z
+ 2024-11-07T14:47:48.087Z
https://etalab.github.io/programme10pourcent-kallm/notebooks/autres/parse_llama31_results.html
- 2024-11-07T14:42:26.067Z
+ 2024-11-07T14:47:48.103Z
https://etalab.github.io/programme10pourcent-kallm/II-Developpements/1_Anatomie_LLM.html
- 2024-11-07T14:42:26.051Z
+ 2024-11-07T14:47:48.087Z
https://etalab.github.io/programme10pourcent-kallm/II-Developpements/2_Utilisation_LLM.html
- 2024-11-07T14:42:26.051Z
+ 2024-11-07T14:47:48.087Z
https://etalab.github.io/programme10pourcent-kallm/index.html
- 2024-11-07T14:42:26.067Z
+ 2024-11-07T14:47:48.103Z
https://etalab.github.io/programme10pourcent-kallm/I-Accompagnement/1_cas_usage.html
- 2024-11-07T14:42:26.051Z
+ 2024-11-07T14:47:48.087Z
https://etalab.github.io/programme10pourcent-kallm/I-Accompagnement/3_Acculturation.html
- 2024-11-07T14:42:26.051Z
+ 2024-11-07T14:47:48.087Z