Encore une étude sur les impact du prompt et du format de réponse sur la qualité de la génération.
Ils ont notamment testé les performances de génération en plusieurs formats de sortie:
- JSON (0.77)
- YAML (0.7)
- text (0.69)
- Markdown (0.35)
Dommage qu'ils n'aient pas inclus XML. (et j'ai vérifié cette fois, les prompts sont les mêmes entre chaque format)
Une autre conclusion est que le modèle GPT 3.5 est plus sensible aux variations de prompt que GPT 4.
C'est quelque chose que je remarque aussi, plus un modèle est performant et moins il est sensible aux subtilités du Prompt Engineering.
Le prompt système de Bolt est disponible sur Github et donne pas mal d'info sur la manière dont est organisé leur système:
- création/édition de code avec des GNU diff
- ça tourne dans des WebContainers
- ils contournent la limite de 8K tokens en output avec leur
CONTINUE_PROMPT
Surtout je vois que tout est au format XML (ils utilisent Claude 3.5 Sonnet) plutôt que JSON.
J'aimerais bien savoir pourquoi, sachant que j'avais remarqué que le format XML présentait de meilleures performances de génération que le JSON il y a un an. Je me demande si ils sont arrivés aux mêmes conclusions.
Dans cet article, les chercheurs détaillent plusieurs techniques intéressantes pour un RAG.
Ils utilisent une technique similaire à ce qu'on fait chez Didask avec une première étape qui consiste à extraire les informations pertinentes depuis de longs documents.
Cela permet d'avoir un document cohérent en matière brut plutôt que des chunks découpés arbitrairement dans le texte.
Ils vont ensuite évaluer la pertinence des informations extraites dans une deuxième étape qui utilise un CoT en 2 prompt:
- génération du raisonnement
- vérification de la pertinence du raisonnement
Une partie des prompts est donnée à la fin de l'article.
Une extension de la méthode de la chaine de pensée qui consiste à aussi fournir des exemples d'erreurs dans le prompt en plus des exemples de raisonnement correct.
Les performances sont sensiblement meilleures sur certains modèles: +4% sur Gemini Pro, 7% sur DeepSeek mais par contre sur GPT-4o-mini il n'y a aucune différence.
Une méta étude qui regroupe toutes les méthodes connues de prompting.
Anthropic ont sorti un outil pour aider à la rédaction de prompts.
L'outil met notamment l'accent sur la chaine de pensée et la séparation entre données et instructions.
J'avais fait un article qui donnait aussi des techniques pour améliorer les performances des prompts
Les paramètres "temperature" et "top_p" contrôlent les choix fait par le LLM pour choisir les tokens les plus probable lors de la génération.
Plus la température est haute, plus le LLM sera à même de choisir des tokens ayant une faible probabilité d'apparaitre.
Top_p définit le nombre de tokens considérés pour la génération, ainsi une valeur élevé permettra au LLM de choisir parmi plus de mots.
Une méthode de compression des prompts pour réduire leur taille.
La méthode utilise de plus petit LLMs pour compresser un texte en ne conservant que les informations pertinentes pour un LLM.
La différence de performances avec le prompt compressé est minime mais on peut diviser la taille par 20!
Leur deuxième méthode est aussi de la compression de prompt mais dans le cadre d'un RAG. Le contenu du prompt est compressé et surtout ré-organisé lorsqu'il contient des documents afin d'améliorer le score de retrieval.
Ils affichent des performances de 17% supérieures sur NaturalQuestions avec 4x moins de tokens.
Bref, moins de tokens = plus rapide + moins cher, sans baisse de performances significatives voir de meilleures performances.
Des exemples sont disponibles et utilisable en ligne dans Google Collab https://github.com/microsoft/LLMLingua/tree/main/examples
Claude 2.1 possède une fenêtre de contexte énorme de 200K tokens.
Bien sur, plus il y a de tokens et plus il est difficile pour le modèle de les prendre tous en compte.
Ici, les chercheurs d'Anthropic ont réussi à passer de 27% à 98% de succès sur des tâches de récupération d'informations passées dans les 200K tokens de contexte.
Ça se résume à une seule phrase de prompt engineering placée à la fin: Here is the most relevant sentence in the context:
(Voir aussi cet article qui évalue les performances des instructions dans un prompt en fonction de leur position)
Une technique qui améliore la résolution de problèmes avec du code.
C'est une variante de Chain of Thought pour la résolution de problèmes et c'est d'ailleurs sur ce genre de benchmark qu'ils ont évalué le modèle et non pas des benchmark de pure génération de code.
La méthode consiste à découper le problème en sous étape et ensuite soit:
- de générer le code Python de la sous étape et d'exécuter le tout à la fin
- d'utiliser un LLM pour pseudo exécuter le code de l'étape
Rivet est de loin le meilleur outil que j'ai pu voir pour faire du Prompt Engineering
Franchement j'en ai testé pleins et la rien à redire, on peut tout faire simplement:
- assembler des prompts
- parse les sorties textes
- envoyer ce qu'on a parse dans d'autres prompts
- écrire du code Javascript dans un node (c'est typé et en plus l'éditeur c'est vscode)
Le moteur d'exécution des nodes est super bien fait, par exemple il peut mettre en cache les appels à Open AI si une node fait une erreur plus loin alors on peut corriger et rejouer sans attendre.
L'éditeur de nodes est aussi super intuitif, j'ai pu créer un système complexe de prompts en 15 min sans la documentation
Une méthode de prompt engineering pour améliorer la qualité des réponses.
C'est une utilisation un peu plus avancée d'une chaine de prompt avec une critique et une réponse à la critique générés par le LLM
Un autre outil en NoCode pour faire des applications à base de LLM.
C'est testable en live chez HuggingFace: https://huggingface.co/spaces/Logspace/Langflow
Des leaks de prompt, il y a ceux d'OpenAI mais aussi ceux des assistants GPT.
La plupart des prompts peuvent être leak via la technique de la grand mère https://news.ycombinator.com/item?id=35630801
Un article sur une méthode permettant d'améliorer la qualité des réponses dans un RAG.
Ils proposent notamment une méthode de prompting pour savoir quand il n'y a pas suffisament d'informations pour répondre:
Determine if there is Observation that SUPPORTS
or REFUTES a Claim, or if there is NOT ENOUGH
INFO.
Claim: The Gadsden flag was named by Christo-
pher Gadsden.
A: First, The Gadsden flag is named after politician
Christopher Gadsden. Second, there is no informa-
tion on who named the Gadsden flag. The answer
is NOT ENOUGH INFO.Dans cet article, les auteurs proposent une autre manière de découper une tâche en sous tâche en permettant au LLM de "créer" une sous tâche en écrivant un token spécial.
La sous tâche est ensuite executé par un LLM "enfant" puis le résultat est ré-incorporé dans la tâche principale.
L'article contient de nombreux exemples.
Un article sur une méthode de prompt engineering pour réduire la latence d'un LLM en découpant une tâche en sous tâche puis en générant chaque partie indépendamment avant de merge le tout.
L'article est pleins d'exemples concrets en annexes
Un article sur la méthode du Tree of Thoughts pour résoudre des problèmes complexes avec un LLM.
Cet article a le mérite d'être compréhensible et de fournir des exemples concrets
Toute une liste d'articles sur le Chain Of Thought
Un article qui évalue la performance des LLMs en fonction de l'endroit ou sont les informations dans le prompt.
Avec des prompts de plus en plus long, les LLMs ont tendance à "perdre" de l'information car la complexité du mécanisme d'attention est fonction du carré de la taille du prompt.
Les chercheurs ont trouvé que les informations placées au début et à la fin avaient plus de chance d'être retrouvées/utilisées.
C'est ce qui est placé au début du prompt qui a le plus d'importance pour le LLM, puis ce qui est placé à la fin et tout ce qui est au milieu