Étude de cas sur le fine-tuning de Llama-2 pour adapter des modèles personnalisés

 (anyscale.com)
1 points par GN⁺ 2023-08-13 | 1 commentaires | Partager sur WhatsApp
  • Lorsque les LLM généralistes sont surdimensionnés pour des tâches spécialisées, fine-tuner directement Llama-2 peut améliorer à la fois la qualité, les coûts et la latence avec un modèle plus petit et moins cher
  • Après fine-tuning, Llama-2 13B voit la précision des représentations fonctionnelles ViGGO passer de 58 % à 98 %, la génération SQL de 42 % à 89 %, et GSM8k de 28 % à 47 %
  • Pour les tâches où le format de sortie est important, comme ViGGO et la génération SQL, les petits modèles Llama-2 ont obtenu de meilleurs résultats que GPT-4, mais ils n’ont pas atteint le niveau de GPT-4 en raisonnement mathématique
  • Les expériences ont été menées avec des scripts basés sur Ray Train, Ray Data, DeepSpeed et Accelerate ; les modèles 7B et 13B ont été entraînés sur 16xA10G, et le 70B sur 32xA10G
  • La clé de l’amélioration des performances tient davantage à la qualité des données et au pipeline d’évaluation qu’à la taille du modèle ; il faut comparer, tâche par tâche, les compromis coût/qualité entre prompt engineering et fine-tuning

Les effets du fine-tuning observés sur trois tâches

  • Les grands modèles généralistes comme GPT-4 et Claude-2 sont utiles pour le prototypage rapide, mais peuvent être excessifs en coût comme en performances pour des besoins étroits, par exemple résumer et classer des tickets de support
  • L’expérience compare l’ampleur des gains obtenus en appliquant un fine-tuning full-parameter à des modèles Llama-2 sur trois tâches proches de cas réels
    • ViGGO : extraction de représentations fonctionnelles à partir de texte non structuré
    • SQL-create-context : génération de SQL à partir de langage naturel et d’un contexte CREATE TABLE
    • GSM8k : résolution de problèmes de mathématiques de niveau primaire
  • Les évolutions de précision pour Llama-2 13B sont les suivantes
    • Représentations fonctionnelles ViGGO : 58 % → 98 %
    • Génération SQL : 42 % → 89 %
    • GSM8k : 28 % → 47 %
  • Sur ViGGO et la génération SQL, les petits modèles Llama-2 ont obtenu de meilleurs résultats que GPT-4 ; sur les tâches de raisonnement mathématique comme GSM8k, même après fine-tuning, ils restent en dessous des performances de GPT-4

Méthode de fine-tuning et infrastructure d’entraînement

  • Les trois tâches utilisent toutes un fine-tuning full-parameter standard
    • L’entraînement se fait par prédiction du token suivant
    • Tous les paramètres du modèle sont soumis aux mises à jour de gradient
    • LoRA et les méthodes consistant à figer une partie des blocs transformer sont exclus du périmètre de l’expérience
  • Les scripts expérimentaux sont construits sur Ray Train, Ray Data, DeepSpeed et Accelerate
    • Ils prennent en charge les exécutions Llama-2 7B, 13B et 70B
    • Le TorchTrainer de Ray Train distribue la boucle d’entraînement sur plusieurs processus worker et ressources GPU
    • Le sharding des données est pris en charge par Ray Train, et chaque worker accède aux fragments de données qui lui sont attribués via session.get_dataset_shard("train") et session.get_dataset_shard("valid")
  • Le sharding du modèle est géré avec DeepSpeed ZeRO stage 3 et l’offloading de l’état de l’optimizer
    • Comme les fragments du modèle sont répartis entre plusieurs workers, lorsqu’il faut accéder au modèle complet, par exemple pour sauvegarder un checkpoint, il faut déplier le modèle avec accelerator.unwrap_model(model)
  • Les ressources de calcul sont les suivantes
    • 7B et 13B : 16xA10G
    • 70B : 32xA10G, sur 4 instances g5.48xlarge
    • Avec Ray, le fine-tuning full-parameter ne nécessite pas forcément des A100
  • L’entraînement a été mené jusqu’à 10 epochs au maximum, et le checkpoint avec la perplexity la plus basse sur l’ensemble de validation a été sélectionné

Figer la structure entrée/sortie avec des tokens spéciaux

  • Les données de fine-tuning représentent la structure de la tâche avec des tokens spéciaux, plutôt qu’avec des prompts d’instruction
    • Exemple : <START_Q>{question}<END_Q><START_A>{answer}<END_A>
  • Les tokens spéciaux aident le modèle à distinguer les segments d’entrée et de sortie, et à apprendre clairement le point d’arrêt de la génération
    • Dans l’exemple, <END_A> est défini comme stopping token pour arrêter la sortie à la fin de la tâche
  • Le tokenizer Llama produit par défaut 32 000 IDs de tokens
    • L’ajout de quatre tokens spéciaux porte la sortie à 32 004 IDs
    • De nouveaux IDs sont attribués, par exemple 32000 pour <START_Q> et 32001 pour <END_Q>
  • Le script ajoute les tokens spéciaux avec tokenizer.add_tokens(special_tokens, special_tokens=True) et crée de nouveaux paramètres d’entraînement avec model.resize_token_embeddings(len(tokenizer))

ViGGO : transformer du texte non structuré en représentations fonctionnelles

  • ViGGO est à l’origine un dataset anglais qui transforme des représentations fonctionnelles basées sur des paires attribut-valeur en texte en langage naturel ; dans l’expérience, la direction est inversée pour transformer du texte non structuré en représentations fonctionnelles structurées
    • Le domaine est celui des avis sur les jeux vidéo
    • La représentation résultante peut servir à l’indexation et à des applications en aval
  • Le modèle doit générer la fonction et les valeurs d’attributs correspondant à la phrase
    • Les fonctions candidates incluent inform, request, give_opinion, confirm, verify_attribute, suggest, request_explanation, recommend et request_attribute
    • Les attributs candidats incluent name, release_year, esrb, genres, platforms, available_on_steam, has_linux_release, has_mac_release, specifier, rating, player_perspective, has_multiplayer, developer, exp_release_date, etc.
  • Pour l’entrée d’exemple What's a really fast-paced game with multiplayer that you like to play?, la sortie attendue est request(has_multiplayer[yes], specifier[fast-paced])
  • Les modèles généralistes ne respectaient pas bien le format de sortie attendu, et le long contexte d’entrée posait un problème : le traitement de l’entrée prenait plus de temps que la génération de la sortie
  • Cette tâche repose surtout sur la reconnaissance de motifs et la compréhension linguistique de base, plutôt que sur un raisonnement logique complexe
    • C’est une grounded task, où tous les faits nécessaires sont inclus dans l’entrée
    • Le fait que les prompts few-shot aident sert d’indice indiquant que de petits modèles Llama-2 peuvent aussi s’améliorer via fine-tuning

Évaluation et résultats de ViGGO

  • L’évaluation n’utilise pas uniquement la correspondance exacte des caractères
    • Elle vérifie que la fonction de sortie est correcte
    • Elle vérifie que le type des attributs est correct
    • Elle vérifie que les attributs dans la fonction respectent un ordre de priorité défini
  • Pour les modèles instruction-following comme GPT et Llama-2-chat, la règle d’ordre des attributs étant explicitement indiquée dans le prompt, ils sont évalués sous la condition qu’ils doivent respecter cette règle
  • Pour accélérer l’évaluation, l’API de batch inference de Ray est utilisée avec Aviary d’Anyscale
    • Elle enchaîne la génération LLM et le post-traitement, puis les distribue sur plusieurs machines
  • Les modèles 7B et 13B voient leur précision augmenter fortement après fine-tuning
    • La précision de GPT-4 chute nettement lorsque la priorité des attributs est incluse dans l’évaluation
    • Les modèles fine-tunés respectent toujours la priorité, et l’ajout de cette contrainte ne modifie pas leur précision
  • Les résultats sur ViGGO montrent que le fine-tuning peut être un moyen stable et efficace pour les tâches nécessitant un format structuré
    • Il ne s’agit pas simplement de respecter une regex ou un format JSON : il faut décider quels arguments inclure et respecter jusqu’à l’ordre des arguments inclus
    • Les résultats étant obtenus avec des modèles 7B et 13B, le coût de serving peut être inférieur à celui d’appels à l’endpoint GPT-4

Génération SQL : créer des requêtes à partir du langage naturel et du contexte de table

  • La tâche de génération SQL consiste à recevoir une requête en langage naturel et une instruction SQL CREATE TABLE, puis à générer une requête SQL exécutable
  • Le dataset utilisé, b-mc2/sql-create-context, est un dataset Hugging Face combinant WikiSQL et Spider
    • Chaque point de données se compose d’une requête en langage naturel, d’une instruction SQL CREATE TABLE et de la requête SQL correspondante
    • L’ensemble contient 78 577 points de données
  • Le dataset présentait des problèmes dans les SQL de référence
    • Dans CREATE TABLE, des attributs entiers étaient indiqués comme VARCHAR, alors que les requêtes SQL les traitaient souvent comme des entiers
    • Toutes les requêtes SQL supposant des attributs entiers ont été supprimées, réduisant le dataset d’environ 70k à 45k
  • Cette tâche convient elle aussi au fine-tuning, puisqu’il s’agit de transformer du langage naturel en une représentation structurée, ici du SQL
    • Contrairement à ViGGO, elle est plus ambiguë, car plusieurs requêtes SQL peuvent produire le bon résultat d’exécution

Évaluation et résultats SQL

  • Pour évaluer la génération SQL, une simple comparaison de chaînes est inadaptée
    • Une comparaison caractère par caractère peut produire de nombreux faux négatifs
    • Une comparaison d’AST peut également être sensible à des facteurs comme l’ordre des noms de variables
    • La méthode la plus fiable consiste à exécuter le code sur un faux dataset et à comparer si les sorties sont identiques
  • Dans l’expérience, l’endpoint GPT-3.5 d’OpenAI est utilisé pour générer de fausses tables destinées à des tests unitaires sur plusieurs centaines d’exemples
    • GPT-3.5 observe la question, le schéma de table et la réponse de référence, puis crée une fausse table de 10 points de données
    • sqlglot.executor.execute exécute le SQL de référence et le SQL du modèle afin de comparer les résultats
  • Pour vérifier la qualité des tables de données générées par GPT-3.5, le SQL de référence est d’abord exécuté
    • Si la table de résultats est vide ou a la même longueur que la table d’origine, l’exemple est écarté
    • Au cours de ce processus, environ 50 % des tables de données créées par GPT sont filtrées
  • Les Llama-2 7B et 13B fine-tunés obtiennent de meilleures performances que 70B-chat et GPT-4
    • Une erreur fréquente des modèles Llama chat était de ne pas placer systématiquement le SQL dans des balises <SQL>, contrairement aux instructions du prompt
    • Ce problème est plus fréquent sur les modèles chat 7B et 13B que sur le 70B
  • Certaines requêtes en langage naturel du dataset SQL n’étaient pas rédigées dans un anglais parfait, et ce bruit a pu influencer les résultats de GPT-4
    • Les modèles fine-tunés s’adaptent rapidement aux particularités du dataset

GSM8k : un raisonnement mathématique plus difficile que l’apprentissage de structure

  • GSM8k est un benchmark académique standard pour évaluer les capacités de raisonnement et de compréhension mathématiques
  • Alors que les deux tâches précédentes portaient surtout sur l’apprentissage de structure, GSM8k vise à mesurer dans quelle mesure on peut améliorer le processus de raisonnement du modèle pour résoudre des problèmes mathématiques
  • L’exemple de problème demande le total des ventes si 48 unités sont vendues en avril puis la moitié de ce nombre en mai ; la réponse se termine au format #### 72, avec les calculs intermédiaires
  • Les LLM actuels doivent générer le processus de réflexion comme une partie de la sortie afin que la génération des tokens suivants puisse s’appuyer sur un processus logique, plutôt que de calculer en interne uniquement la réponse finale et de la produire directement
  • Cette tâche exige non seulement des calculs simples, mais aussi une chain of thought logique allant des prémisses aux conclusions intermédiaires puis à la réponse finale

Méthode d’évaluation et baselines pour GSM8k

  • L’évaluation nécessite une méthode capable d’extraire de manière fiable la réponse finale depuis la sortie du modèle
  • Les modèles de langage généralistes peuvent ne pas respecter de façon cohérente le format de sortie souhaité, ce qui complique l’évaluation automatique
    • Pour cela, l’API function calling d’OpenAI est utilisée
    • gpt-3.5-turbo-0613 appelle une fonction report_answer pour extraire la réponse entière finale depuis les générations d’autres modèles
    • Par exemple, même si le modèle répond « The answer is four », cela peut être parsé en 4
  • Cette méthode a été validée en la testant sur les réponses du dataset, mais elle a l’inconvénient d’entraîner un coût en tokens OpenAI pour l’évaluation
  • Les modèles fine-tunés apprennent rapidement le motif de réponse cible, ce qui rend la structure de sortie prévisible même lorsqu’ils se trompent
    • L’évaluation des modèles fine-tunés est traitée avec l’expression régulière #### {answer}, évitant le post-traitement via un endpoint OpenAI
  • Les baselines sont les suivantes
    • Les résultats de 8-shot prompting des modèles base pre-trained publiés dans l’article
    • Plusieurs templates prompt-engineered pour les variantes Llama-2 chat-tuned que Meta a entraînées par RLHF afin d’en faire des assistants généralistes

Résultats GSM8k et fine-tuning en deux étapes

  • Le fine-tuning des modèles base améliore de manière cohérente les performances sur GSM8k, mais ne produit pas toujours des résultats nettement meilleurs que les modèles chat-tuned
    • Les modèles chat ont probablement été entraînés sur des exemples mathématiques pendant le chat-tuning, ce qui leur donne une précision supérieure à celle des modèles base
  • L’ajout de prompts aux modèles fine-tunés ne donne pas toujours de meilleurs résultats que les modèles base
    • Par exemple, Llama-2-70B-chat peut être inférieur au modèle base avec un prompt d’exemples 8-shot
    • Les modèles fine-tunés sont systématiquement meilleurs que les modèles base avec 8-shot prompting
  • Côté coût de serving, les modèles fine-tunés peuvent être avantageux
    • Les approches basées sur des prompts ajoutent un coût en tokens de prompt à chaque requête
    • Avec les modèles fine-tunés, le coût reflète en pratique essentiellement le nombre de tokens de la question
  • Les données d’entraînement GSM8k comptent environ 8k exemples, ce qui est relativement faible ; il a été jugé difficile d’exploiter pleinement le potentiel de Llama-13B avec ce seul volume
  • Une méthode en deux étapes, consistant à fine-tuner d’abord le modèle Llama-13B base sur MathQA puis à le fine-tuner à nouveau sur GSM8k, apporte une amélioration supplémentaire
    • Le fine-tuning utilisant seulement GSM8k améliore le modèle base de 10 points de pourcentage
    • Le fine-tuning en deux étapes, avec MathQA puis GSM8k, ajoute 10 points de pourcentage aux premiers résultats de fine-tuning, soit 20 points de pourcentage au total par rapport au base
  • MathQA comporte 30 000 paires question/réponse, mais est plus bruité que GSM8k et possède une structure différente
    • La qualité des réponses est faible, et la réponse finale est au format multiple choice
    • Malgré cela, le fine-tuning en deux étapes s’est révélé efficace pour exploiter MathQA afin d’améliorer le résultat final sur GSM8k

Critères à examiner pour une application en production

  • Les modèles fermés comme GPT-4 et Claude-2 sont forts pour le prototypage et la validation initiale de valeur, mais ne suffisent pas toujours pour exploiter des applications LLM en production
  • Le fine-tuning de LLM pour des niche tasks peut être utile non seulement pour la confidentialité, mais aussi en matière de latence, coût et qualité
    • Dans les exemples ViGGO et SQL, les résultats sont aussi meilleurs que ceux de GPT-4 sur le plan de la qualité
  • Dans le fine-tuning, le point d’attention principal n’est pas tant l’implémentation détaillée de l’infrastructure que la collecte de données et la construction d’un pipeline d’évaluation
    • Le pipeline d’évaluation sert de base pour comparer les trade-offs entre différentes solutions au regard des besoins métier
  • Les expériences ont été menées avec la plateforme de fine-tuning et de serving d’Anyscale, ainsi qu’avec Anyscale Endpoints
  • Le même processus est organisé sous forme de solutions de fine-tuning et de serving Anyscale sur Ray, afin de pouvoir être répété avec ses propres données et dans son propre cloud

À lire aussi

1 commentaires

 
GN⁺ 2023-08-13
Avis sur Hacker News

  • Il y a quelques semaines, dans un live de coding, j’ai beaucoup parlé de fine-tuning de Llama 2 avec mon propre dataset, et je l’ai fait sur un seul GPU dans Colab
    Dans mon cas, le dataset était mon code.
    Fine-tuning Llama stream: https://www.youtube.com/watch?v=TYgtG2Th6fI&t=2282s
    J’ai aussi quelques autres sessions de fine-tuning QLoRA, où j’explique les concepts du point de vue d’un ingénieur logiciel avec 8 ans d’expérience qui s’est récemment mis au machine learning en autodidacte
    QloRa fine-tuning stream: https://www.youtube.com/watch?v=LitybCiLhSc&t=4584s
    J’essaie de rendre aussi accessible que possible la façon dont j’aborde ça dans mes projets personnels et dans la startup basée sur l’IA sur laquelle je travaille actuellement. La série où je fine-tune le plus petit LLM pour le développement web semble aussi plutôt bien reçue ; je streame depuis environ un mois et je compte en publier beaucoup plus

    • Je me demande quels sont les critères généraux pour savoir quand il vaut mieux utiliser respectivement RAG ou le fine-tuning
      Je ne comprends pas très bien non plus l’idée de répartir plusieurs modèles fine-tunés. Faut-il un LLM Terraform, un LLM SQL, un LLM Python séparés, ou bien un seul LLM « code » suffit-il ?
    • On a vraiment besoin d’une application/d’un module/d’une bibliothèque simple du genre « mettez les documents sources dans ce répertoire, appuyez sur un bouton, puis discutez avec leur contenu »
      Il faut tellement de détails d’implémentation que, sauf cas d’usage vraiment significatif, ce n’est pas très accessible. privateGPT finira sans doute par arriver lentement à ce niveau
    • C’était bien, et j’aimerais aussi voir une série sur la préparation de datasets personnalisés pour le fine-tuning
      C’est une partie que beaucoup d’autres tutoriels survolent. Je suis particulièrement curieux de savoir comment les préparer selon des objectifs différents, comme la sécurité ou la précision
    • Est-ce faisable avec un seul GPU ? Je me demande si c’est réaliste même avec une seule 3060

  • Je rencontre le même problème avec Llama 2. Il est presque impossible de lui faire sortir uniquement le texte voulu, il ajoute toujours quelque chose avant ou après la réponse
    Je me demande s’il existe des techniques de prompting pour corriger ça

    • Mieux vaut utiliser un meilleur modèle
      airoboros prend en charge un token PLAINFORMAT pour éviter les backticks, les explications, etc., et ne sortir que le code
      https://huggingface.co/TheBloke/airoboros-l2-70B-GPT4-2.0-GG...
    • Les modèles Llama-2-chat sont sur-fine-tunés de cette manière. On peut essayer le prompting few-shot, mais cela ne garantit pas la sortie voulue
      Pour garantir le résultat, le mieux est de faire un fine-tuning sur un petit dataset, environ 1 000 exemples, puis d’améliorer à partir de là
    • Cela dépend de l’objectif, mais j’ai réussi à reproduire un format de sortie précis en fine-tunant le modèle LLaMA2 de base plutôt qu’un modèle avec RLHF
      Mon cas d’usage était une tâche simple d’extraction/synthèse d’informations à partir de texte, plutôt que de l’écriture créative. Le modèle de base ne conviendra peut-être pas à toutes les tâches
    • Il suffit de prompter le modèle pour qu’il affiche toujours les réponses ou le code dans une chaîne content ou dans du JSON
      S’il s’agit de JSON, on peut en identifier le début et la fin, puis supprimer ce qui se trouve en dehors du JSON

  • Je suis content de voir ce genre d’article. Il y a eu tellement de discussions en ligne sur la personnalisation des modèles, et celui-ci élimine plutôt bien le bruit
    J’aime aussi la méthodologie d’évaluation, et l’article me semble bien écrit

  • Je trouve étrange que LoRA et l’entraînement quantifié ne soient pas pris plus au sérieux. C’est beaucoup moins cher, moins long, et il existe pas mal d’éléments montrant que ça fonctionne assez bien
    À mon avis, ce n’est pas quelque chose à repousser comme une option secondaire à tester plus tard

  • Je suis content de voir que les tâches proches du NER obtiennent les meilleures performances. J’étais justement sur le point de faire un test similaire pour comparer avec un modèle BERT fine-tuné
    Je me demande quel est le coût d’entraînement de cette tâche

    • Je suis coauteur de l’article. Les données d’entraînement ViGGO comptent environ 5,1 k lignes, et nous avons entraîné avec une taille de bloc de 512
      On aurait pu réduire la taille de bloc, mais il était plus simple de ne pas modifier le code, donc nous l’avons laissée telle quelle. Le 7B a pris environ 15 minutes par époque sur 16xA10G, et le 13B environ 25 minutes. Donc le coût à la demande par époque est d’environ 7,2 $ pour le 7B et 12 $ pour le 13B. Ces chiffres ne tiennent compte que du temps utilisé pour l’entraînement, pas du temps de démarrage/arrêt du cluster
    • Bonne question. Dommage qu’ils n’aient pas indiqué combien de temps les 10 époques ont pris, on aurait pu calculer le coût. Idéalement, j’aurais aimé qu’ils publient à la fois le temps et le coût
      Il est indiqué qu’ils ont utilisé 16xA10G pour les 7B et 13B, et 32xA10G pour le 70B, répartis sur 4 instances g5.48xlarge. Avec Ray, il n’est pas nécessaire de réserver des A100 pour faire un fine-tuning complet de tous les paramètres de ces modèles, et le même processus est répété pour chaque tâche. Sur le dataset GSM8k, ils montrent un exemple d’exécution avec une longueur de contexte de 512 et 3,7 millions de tokens effectifs par époque
      Ils disent avoir entraîné jusqu’à 10 époques et choisi le checkpoint présentant la perplexité minimale sur l’ensemble de validation

  • L’une des difficultés, c’est qu’il faut soit une petite armée, soit un très puissant modèle existant pour créer un dataset personnalisé suffisamment grand
    Au final, il y a de fortes chances qu’il faille utiliser OpenAI, mais générer des données d’entraînement pour un autre modèle avec OpenAI viole leurs conditions d’utilisation. Je me demande si cela a déjà été jusqu’au procès. Est-ce que les gens considèrent simplement que c’est injuste et l’ignorent ?

    • Ce n’est pas vrai pour toutes les tâches. Pour beaucoup de tâches de traitement automatique du langage naturel, il suffit de reformater des données existantes pour les adapter au format LLM
    • Y a-t-il une raison de ne pas ignorer les conditions d’utilisation ? Au pire, on perd l’accès

  • Je vois de plus en plus d’exemples de NER ces temps-ci, et je me demande pourquoi les gens n’utilisent pas spaCy pour ce genre de tâches

    • spaCy ne fonctionne pas bien avec les données d’entraînement multilingues, et je l’ai vu casser de façons plus nombreuses et plus étranges que les modèles de la famille transformers
    • Je pense plutôt à faire labelliser les données par un modèle coûteux, puis à entraîner un modèle plus petit comme SpaCy ou BERT selon une approche enseignant/élève, afin de maîtriser les coûts et la vitesse
    • Pour le NER, j’utilise des modèles de la famille BERT fine-tunés, mais j’aimerais comparer les performances

  • Je travaille chez Anyscale
    Ce blog semble avoir suscité un bel intérêt, donc nous prévoyons de l’inclure au Ray Summit : https://raysummit.anyscale.com/agenda
    Si vous avez des idées sur le type de contenu que vous aimeriez voir davantage au Ray Summit, dites-le-nous

  • Il est indiqué que pour 3,5 millions de tokens, le 7B prend environ 14 minutes par époque et le 13B environ 26 minutes par époque
    Il paraît que, pour le 7B comme pour le 13B, il faut au minimum 1xg5.16xlarge comme nœud head et 15xg5.4xlarge comme nœuds worker ; je me demande combien cela coûte sur AWS

  • Je me demande s’il est possible de fine-tuner Llama-2 localement sur un M1 Ultra 64 Go. La plupart des ressources concernent le cloud ou l’utilisation de Nvidia CUDA sous Linux, donc j’aimerais avoir des références utiles

    • Je ne pense pas. J’utilise un M1 Max 64 Go et certaines inférences tournent correctement
      Pour l’entraînement, je compte acheter quelques crédits RunPod, et je pense que quelques dizaines de dollars devraient suffire