Évaluation des Techniques de Suggestion
Maintenant que nous avons mené une revue systématique des techniques de suggestion, nous allons analyser les performances empiriques des différentes techniques de deux manières : via une évaluation formelle sur un benchmark et en illustrant en détail le processus d'ingénierie des suggestions sur un problème réel complexe.
6.1 Évaluation des Techniques de Suggestion
Une évaluation formelle des techniques de suggestion pourrait être réalisée dans une étude large comparant plusieurs centaines de techniques sur plusieurs centaines de modèles et de benchmarks. Cela dépasse notre portée actuelle, mais comme cela n'a pas encore été fait auparavant, nous fournissons une première étape dans cette direction. Nous choisissons un sous-ensemble de techniques de suggestion et les exécutons sur le benchmark largement utilisé MMLU (Hendrycks et al., 2021). Nous avons travaillé sur un sous-ensemble représentatif de 2 800 questions MMLU (20 % des questions de chaque catégorie) et avons utilisé gpt-3.5-turbo pour toutes les expériences.
6.1.1 Comparaison des Techniques de Suggestion
Nous évaluons six techniques de suggestion distinctes en utilisant le même modèle de suggestion général (Figure 6.2). Ce modèle montre l'emplacement des différents composants des suggestions. Seules les instructions de base et la question existent dans chaque suggestion. L'instruction de base est une phrase comme "Résolvez le problème et retournez (A), (B), (C) ou (D)." que nous modifions dans certains cas. Nous testons également deux formats de question (Figures 6.3 et 6.4). Le format de la question est inséré dans le modèle de suggestion à la place de "{QUESTION}". Nous testons chaque technique de suggestion avec six variations totales, sauf celles qui utilisent l'auto-consistance.
-
Zero-Shot
En tant que baseline, nous avons passé directement les questions au modèle sans aucune technique de suggestion spéciale, uniquement avec l'instruction de base et la question. Pour cette baseline, nous avons utilisé les deux formats ainsi que trois variations de formulation de l'instruction de base. Ainsi, il y avait six exécutions totales sur les 2 800 questions pour ce benchmark. Cela n'incluait aucun exemple ni aucun déclencheur de pensée. -
Techniques Zero-Shot-CoT
Nous avons également exécuté Zero-Shot-CoT. Parmi les trois variations, nous avons utilisé trois déclencheurs de pensée (instructions qui poussent le modèle à générer des étapes de raisonnement), y compris la chaîne de pensée standard "Pensons étape par étape" (Kojima et al., 2022), ainsi que ThoT (Zhou et al., 2023) et Plan and Solve (Wang et al., 2023f). Ensuite, nous avons sélectionné la meilleure de ces techniques et l'avons exécutée avec l'auto-consistance en trois itérations, en prenant la réponse majoritaire. -
Setups Few-Shot
Nous avons également exécuté des suggestions Few-Shot et Few-Shot-CoT, avec des exemples générés par l'un de nos auteurs. Pour chacun, nous avons utilisé trois variations de l'instruction de base ainsi que les deux formats de question (également appliqués aux exemples). Ensuite, nous avons utilisé la formulation la mieux performante avec l'auto-consistance en trois itérations, en prenant la réponse majoritaire.
Voir la légende
Figure 6.1 : Les valeurs de précision sont montrées pour chaque technique de suggestion, avec le modèle utilisé étant gpt-3.5-turbo. Les barres d'erreur violettes illustrent le minimum et le maximum pour chaque technique, car elles ont été exécutées sur différentes formulations et formats (sauf pour SC).
6.1.2 Formats de Questions
Nous expérimentons deux choix de format issus de Sclar et al. (2023b), qui ont exploré comment les choix de format peuvent affecter les résultats des benchmarks. Nous utilisons deux formats qui conduisent à des résultats variés sur leur tâche (Figures 6.3 et 6.4).
{INSTRUCTION_DE_BASE} {EXEMPLAIRES} {QUESTION} {INDUCTEUR_DE_PENSÉE}
Figure 6.2 : Modèle de suggestion pour le benchmarking.
Problème {QUESTION} Options (A)::{A} (B)::{B} (C)::{C} (D)::{D} Réponse
Figure 6.3 : Format de question 1.
PROBLÈME::{QUESTION}, OPTIONS:: (A): {A} (B): {B} (C): {C} (D): {D}, RÉPONSE::
Figure 6.4 : Format de question 2.
6.1.3 Auto-Consistance
Pour les deux résultats d'auto-consistance, nous avons fixé la température à 0,5, conformément aux lignes directrices de Wang et al. (2022). Pour toutes les autres suggestions, une température de 0 a été utilisée.
6.1.4 Évaluation des Réponses
Évaluer si un LLM a correctement répondu à une question est une tâche difficile (Section 2.5). Nous marquions les réponses comme correctes si elles suivaient certains motifs identifiables, tels qu'une seule lettre majuscule (A-D) entre parenthèses ou suivant une phrase comme "La bonne réponse est".
6.1.5 Résultats
Les performances se sont généralement améliorées à mesure que les techniques devenaient plus complexes (Figure 6.1). Cependant, Zero-Shot-CoT a chuté brutalement par rapport à Zero-Shot. Bien qu'il ait eu une grande amplitude, pour toutes ses variantes, Zero-Shot a performé mieux. Dans les deux cas d'auto-consistance, ils avaient naturellement une amplitude plus faible puisqu'ils répétaient une seule technique, mais cela n'a amélioré la précision que pour les suggestions Zero-Shot. Few-Shot CoT performe le mieux, et les baisses de performance inexpliquées de certaines techniques nécessitent des recherches supplémentaires. Comme le choix des techniques de suggestion ressemble à une recherche de hyperparamètres, c'est une tâche très difficile (Khattab et al., 2023). Cependant, nous espérons que cette petite étude stimulera des recherches dans la direction de techniques de suggestion plus performantes et robustes.
6.2 Étude de Cas en Ingénierie des Suggestions
L'ingénierie des suggestions émerge comme un art que de nombreuses personnes ont commencé à pratiquer professionnellement, mais la littérature ne contient pas encore de guidances détaillées sur le processus. En guise de premier pas dans cette direction, nous présentons une étude annotée d'ingénierie des suggestions pour un problème réel difficile. Cette étude n'a pas pour but de constituer une contribution empirique en termes de résolution effective du problème. Au contraire, elle offre une illustration de la manière dont un ingénieur expérimenté aborderait une tâche de ce type, ainsi que les leçons tirées.
6.2.1 Problème
Notre problème illustratif concerne la détection de signaux prédictifs du risque suicidaire de crise chez un individu potentiellement suicidaire. Le suicide est un problème sévère dans le monde entier, exacerbé, comme la plupart des problèmes de santé mentale, par un manque désespéré de ressources en santé mentale. Aux États-Unis, plus de la moitié de la population nationale vit dans des zones fédéralement définies comme ayant un manque de professionnels de la santé mentale (National Center for Health Workforce Analysis, 2023). De plus, de nombreux professionnels de la santé mentale manquent de compétences fondamentales en prévention du suicide (Cramer et al., 2023). En 2021, 12,3 millions d'Américains ont sérieusement envisagé le suicide, avec 1,7 million ayant effectivement tenté de se suicider, entraînant plus de 48 000 décès (CDC, 2023). Aux États-Unis, le suicide était la deuxième cause de décès (après les accidents) chez les personnes âgées de 10 à 14 ans, 15 à 24 ans ou 25 à 34 ans selon les statistiques de 2021, et la cinquième cause de décès chez les personnes âgées de 35 à 54 ans (Garnett et Curtin, 2023).
Des recherches récentes suggèrent qu'il existe une valeur significative dans les évaluations de la potentialité suicidaire qui se concentrent spécifiquement sur l'identification de la crise suicidaire, c'est-à-dire l'état de détresse aiguë associé à un risque élevé de comportement suicidaire imminent. Cependant, les évaluations validées pour les approches diagnostiques telles que le Syndrome de Crise Suicidaire (SCS) (Schuck et al., 2019b ; Melzer et al., 2024) et le Trouble Affectif Suicidaire Aigu (Rogers et al., 2019) nécessitent soit des interactions cliniques personnelles, soit la complétion de questionnaires auto-rapportés contenant des dizaines de questions. La capacité à identifier précisément les indicateurs de crise suicidaire dans le langage des individus pourrait donc avoir un impact important dans l'écosystème de la santé mentale, non pas en remplacement du jugement clinique, mais comme moyen de compléter les pratiques existantes (Resnik et al., 2021).
En point de départ, nous nous concentrons ici sur le facteur prédictif le plus important dans les évaluations du Syndrome de Crise Suicidaire, appelé dans la littérature soit l'espoir frénétique, soit l'enfermement, défini comme "le désir de s'échapper d'une situation insupportable, lié à la perception que toutes les issues sont bloquées" (Melzer et al., 2024). Cette caractéristique de ce que vit un individu est également centrale dans d'autres caractérisations des processus mentaux aboutissant au suicide.
6.2.2 Le Jeu de Données
Nous avons travaillé avec un sous-ensemble de données provenant du Reddit Suicidality Dataset de l'Université du Maryland (Shing et al., 2018), construit à partir de publications sur r/SuicideWatch, un subreddit offrant un soutien peer-to-peer pour toute personne luttant contre des pensées suicidaires. Deux codeurs formés à la reconnaissance des facteurs du Syndrome de Crise Suicidaire ont codé un ensemble de 221 publications pour la présence ou l'absence d'enfermement, atteignant une fiabilité inter-codeurs solide (alpha de Krippendorff = 0,72).
6.2.3 Le Processus
Un expert en ingénierie des suggestions, auteur d'un guide largement utilisé sur les suggestions (Schulhoff, 2022), a pris en charge la tâche d'utiliser un LLM pour identifier l'enfermement dans les publications. L'ingénieur en suggestions a reçu un bref résumé verbal et écrit du Syndrome de Crise Suicidaire et de l'enfermement, ainsi que 121 publications de développement avec leurs étiquettes positives/négatives (où "positif" signifie que l'enfermement est présent), les autres 100 publications étiquetées étant réservées pour les tests. Cette information limitée reflète des scénarios fréquents dans la vie réelle où les suggestions sont développées à partir d'une description de la tâche et des données. Plus généralement, cela est cohérent avec une tendance en traitement du langage naturel et en IA à considérer le codage (annotation) comme une tâche d'étiquetage sans explorer en profondeur le fait que les étiquettes peuvent, en réalité, faire référence à des concepts sociaux scientifiques nuancés et complexes.
Nous avons documenté le processus d'ingénierie des suggestions afin d'illustrer la manière dont un ingénieur expérimenté mène son travail. L'exercice a progressé à travers 47 étapes de développement enregistrées, cumulant environ 20 heures de travail. À partir d'un démarrage froid avec une performance de 0 % (la suggestion ne retournait pas de réponses structurées), la performance a été boostée jusqu'à un F1 de 0,53, où cet F1 est la moyenne harmonique d'une précision de 0,86 et d'un rappel de 0,38.
Voir la légende
Figure 6.5 : Les scores F1 ont varié largement entre les suggestions les moins performantes et les meilleures, mais la plupart des suggestions ont obtenu des scores similaires.
Voir la légende
Figure 6.6 : Des progrès en termes de score F1 étaient difficiles à obtenir, souvent impliquant le test de plusieurs suggestions sous-performantes avant de trouver une performante. Les lignes vertes montrent des améliorations par rapport au score F1 le plus élevé actuel, tandis que les lignes rouges montrent des détériorations.
6.2.3.1 Exploration du Jeu de Données (2 étapes)
Le processus a commencé par l'examen par l'ingénieur en suggestions d'une description de l'enfermement (Figure 6.7). Cette description avait été utilisée comme premier critère d'évaluation pour les codeurs humains au début du processus de codage, notant toutefois qu'ils étaient familiers avec le SCS et savaient que ce n'était ni une définition formelle ni exhaustive. L'ingénieur en suggestions a ensuite chargé le jeu de données dans un notebook Python à des fins d'exploration. Il a commencé par demander à gpt-4-turbo-preview s'il connaissait l'enfermement (Figure 6.8), mais a constaté que la réponse du LLM n'était pas similaire à la description donnée. Par conséquent, l'ingénieur en suggestions a inclus la description de Figure 6.7 dans toutes les suggestions ultérieures.
Enfermement :
- Sentiment de ne pas avoir d'issue
- Sentiment d'espoir perdu
- Sentiment de ne pas voir de solution
- Peur que les choses ne redeviennent jamais normales
- Sentiment d'impuissance à changer
- Sentiment d'être piégé
- Sentiment de destin fatal
- Pensée ou sentiment que les choses ne changeront jamais
- Sentiment de ne pas avoir d'échappatoire
- Sentiment de ne pas avoir de bonnes solutions aux problèmes
Figure 6.7 : Description de l'enfermement utilisée par l'ingénieur en suggestions.
Qu'est-ce que l'enfermement en ce qui concerne le Syndrome de Crise Suicidaire ?
Figure 6.8 : Question posée au LLM pour déterminer si ses données d'apprentissage fournissaient des connaissances pertinentes sur l'enfermement (ce qui n'était pas le cas).
6.2.3.2 Obtention d'une Étiquette (8 étapes)
Comme mentionné dans la Section 6.1 concernant le sous-ensemble human_sexuality de MMLU, les LLMs montrent des comportements imprévisibles et difficiles à contrôler dans les domaines sensibles. Pendant plusieurs étapes du processus d'ingénierie des suggestions, l'ingénieur en suggestions a constaté que le LLM donnait des conseils en santé mentale (par exemple, Figure 6.9) plutôt que d'étiqueter l'entrée. Cela a été résolu en passant au modèle GPT-4-32K.
Si vous êtes en danger immédiat de vous faire du mal, veuillez contacter les services d'urgence ou une ligne d'assistance en crise dans votre région. Ils peuvent fournir un soutien immédiat et garantir votre sécurité.
Figure 6.9 : Extrait d'une sortie qui n'étiquette pas le point de données, mais tente plutôt de fournir un soutien en santé mentale à l'utilisateur. De telles sorties sont souvent cinq fois plus longues que cet extrait.
Un enseignement tiré de cette phase initiale est que les "barrières" associées à certains grands modèles linguistiques peuvent interférer avec la capacité de progresser dans une tâche de suggestion, influençant ainsi le choix du modèle pour des raisons autres que la qualité potentielle du LLM.
6.2.3.3 Techniques de Suggestion (32 étapes)
L'ingénieur en suggestions a ensuite consacré la majeure partie de son temps à améliorer la technique de suggestion utilisée. Cela incluait des techniques telles que Few-Shot, Chain-of-Thought, AutoCoT, Contrastive CoT et des techniques multiples d'extraction de réponses. Nous rapportons des statistiques pour les premières exécutions de ces techniques ; les scores F1 pouvaient varier de 0,04 lors des exécutions ultérieures, même avec la température et le top p fixés à zéro.
- Zero-Shot + Contexte
C'était la première technique évaluée (Figure 6.10), en utilisant la description de la Figure 6.7. Remarquez la définition du mot dans la suggestion, bien que la Figure 6.7 ne soit pas une définition formelle.
Pour obtenir une réponse finale du LLM utilisable pour calculer les métriques de performance, il a fallu extraire une étiquette de la sortie du LLM. L'ingénieur en suggestions a testé deux extracteurs : l'un vérifiant si la sortie est exactement "Oui" ou "Non", et l'autre vérifiant simplement si ces mots correspondent aux premiers caractères de la sortie. Le second a donné de meilleurs résultats et a été utilisé pour le reste de cette section jusqu'à ce que nous arrivions à CoT. Cette approche a obtenu un F1 de 0,40, un rappel de 1,0 et une précision de 0,25, évaluée sur tous les échantillons de l'ensemble d'entraînement/développement, puisque aucun échantillon n'avait été utilisé comme exemple.
{DESCRIPTION_ENFERMEMENT (Figure 6.7)} {qinf} Est-ce de l'enfermement ? Oui ou non.
Figure 6.10 : Une suggestion Zero-Shot + Contexte, la plus simple de toutes les suggestions explorées dans cette étude de cas.
- 10-Shot + Contexte
Ensuite, l'ingénieur en suggestions a ajouté les 10 premiers échantillons de données (avec étiquettes) dans la suggestion, au format Q: (question) A: (réponse) (Figure 6.11). Il a évalué cette suggestion 10-shot sur les éléments restants de l'ensemble d'entraînement/développement, obtenant un F1 ↑0,05 (0,45), un rappel ↓0,09 (0,91) et une précision ↑0,05 (0,30), par rapport à la meilleure suggestion précédente.
{DESCRIPTION_ENFERMEMENT (Figure 6.7)} Q: {q1} A: {a1} ... Q: {q10} A: {a10} Q: {qinf} A:
Figure 6.11 : Suggestion 10-Shot + Contexte.
- One-Shot AutoDiCot + Contexte Complet
Après avoir effectué une suggestion 10-shot, l'ingénieur en suggestions a observé que le 12ᵉ élément de l'ensemble de développement était incorrectement étiqueté comme une instance positive, et a commencé à expérimenter des façons de modifier la suggestion pour que le modèle identifie correctement cet élément. Pour comprendre pourquoi cet étiquetage erroné avait lieu, l'ingénieur en suggestions a incité le LLM à générer une explication de pourquoi le 12ᵉ élément avait été étiqueté de cette manière (Figure 6.12).
Figure 6.12 montre une version de ce processus généralisé pour produire des explications pour tous les éléments question/réponse (qi, ai) d'un ensemble T plutôt que pour l'élément 12 seulement. Informé par les étapes de raisonnement r12 obtenues concernant le q12 étiqueté incorrectement, la suggestion précédente a été modifiée en incluant r12 dans un exemple One-Shot CoT avec un raisonnement incorrect, comme exemple de ce qu'il ne faut pas faire (Figure 6.13).
Finalement, la suggestion a été étendue avec deux pièces contextuelles/instructions supplémentaires. La première était un message email que l'ingénieur en suggestions avait reçu, expliquant les objectifs généraux du projet, fournissant plus de contexte autour du concept d'enfermement et des raisons de vouloir l'étiqueter. La seconde addition a été inspirée par l'observation que le modèle attribuait fréquemment une étiquette positive excessive pour l'enfermement. En supposant que le modèle était trop agressif dans ses inférences basées sur l'apprentissage initial à partir du langage explicite, il a instruit le modèle de se limiter aux déclarations explicites d'enfermement (Figure 6.13). Nous appelons ces deux morceaux de contexte, fournis en plus de la description de l'enfermement, le contexte complet.
Un nouvel extracteur a également été utilisé pour cette suggestion, vérifiant si le dernier mot de la sortie est "Oui" ou "Non", au lieu du premier mot. Cette suggestion mise à jour a été testée sur tous les échantillons de l'ensemble de développement, à l'exception des 20 premiers. Elle n'a pas amélioré le F1, ↓0,09 (0,36) F1, mais elle a orienté l'ingénieur en suggestions vers une direction qui l'a finalement amélioré, comme discuté ci-dessous. Le rappel a chuté à ↓0,58 (0,33) et la précision s'est améliorée à ↑0,09 (0,39).
À ce stade, il est important de noter que, bien que ces étapes aient finalement conduit à une amélioration du score F1, elles n'étaient pas en accord avec les objectifs à long terme. L'enfermement n'a pas besoin d'être exprimé explicitement pour être présent (par exemple, à travers des phrases comme "Je me sens piégé" ou "Il n'y a pas de solution"). De plus, dans la plupart des cas d'utilisation pour détecter automatiquement l'enfermement dans le langage d'une personne, la précision et le rappel ne sont pas nécessairement égaux en importance, et, des deux, le rappel/sensibilité (c'est-à-dire ne pas manquer les personnes qui devraient être signalées comme à risque) peut compter davantage en raison du coût élevé d'un faux négatif.
L'enseignement principal ici, bien que l'insight soit venu plus tard, est qu'il est facile pour le processus de développement de suggestion de diverger des objectifs réels à moins que des engagements réguliers ne soient encouragés entre l'ingénieur en suggestions et des experts du domaine qui comprennent mieux l'utilisation réelle.
{EMAIL_DU_PROFESSEUR} {DESCRIPTION_ENFERMEMENT (Figure 6.7)} IMPORTANT : Étiquetez le post comme enfermement seulement s'ils disent explicitement qu'ils se sentent piégés. Q: {q12} R: Bien que "Aujourd'hui, j'ai appris que j'ai 10 jours pour évacuer mon appartement ou je serai officiellement expulsé... Je suis probablement sans-abri" semble exprimer des sentiments de prisonnier/ coincé, ce n'est pas suffisamment explicite pour être étiqueté comme Enfermement. A: {a12} Q: {qinf}
Figure 6.13 : One-Shot AutoDiCot + Contexte Complet.
6.2.3.4 Suppression de l'Email
Les résultats des changements précédents étaient prometteurs, mais ils impliquaient la création d'une suggestion incluant des informations provenant d'un email qui n'avait pas été créé à cette fin et contenait des informations sur le projet et le jeu de données qui n'étaient pas destinées à être divulguées à un large public. Curieusement, supprimer cet email a considérablement diminué les performances, ↓0,27 (0,18) F1, ↓0,75 (0,17) rappel et ↓0,1 (0,20) précision. Nous attribuons cela au fait que l'email fournissait des informations de contexte plus riches sur les objectifs de l'étiquetage. Bien que nous ne recommanderions pas d'inclure des emails ou toute autre information potentiellement identifiable dans une suggestion LLM, nous avons choisi de laisser l'email dans la suggestion, conformément à des scénarios typiques où les suggestions ne sont pas exposées à d'autres.
6.2.3.5 10-Shot AutoDiCot
La prochaine étape consistait à créer plus d'exemples AutoDiCot selon l'algorithme de la Figure 6.12. Un total de dix nouveaux exemples AutoDiCot ont été ajoutés à la suggestion avec contexte complet (Figure 6.16). Cela a produit la suggestion la plus réussie de cette exercice d'ingénierie des suggestions, en termes de score F1, ↑0,08 (0,53) F1, ↓0,05 (0,86) rappel, ↑0,08 (0,38) précision.
6.2.3.6 Expérimentations Supplémentaires
Plusieurs autres expérimentations ont été menées, notamment :
- 20-Shot AutoDiCot : Ajout de 10 exemples supplémentaires, mais résultats moins bons que 10-Shot.
- Duplication de l'Email : Dupliquer accidentellement l'email a amélioré les performances, rappelant la technique de relecture (Xu et al., 2023).
- Anonymisation de l'Email : Anonymiser l'email en remplaçant les noms personnels par d'autres noms aléatoires a diminué les performances, ↓0,08 (0,45) F1, ↓0,14 (0,72) rappel, ↓0,06 (0,33) précision.
- DSPy : Utilisation d'un cadre automatisé pour optimiser les suggestions LLM, atteignant un F1 de 0,548 sans utiliser l'email du professeur ni l'instruction incorrecte sur l'explicitude de l'enfermement.
6.2.4 Discussion
L'ingénierie des suggestions est un processus non trivial, les nuances duquel ne sont pas encore bien décrites dans la littérature. À partir du processus entièrement manuel illustré ci-dessus, plusieurs enseignements méritent d'être résumés. Premièrement, l'ingénierie des suggestions est fondamentalement différente des autres méthodes pour faire fonctionner un ordinateur comme souhaité : ces systèmes sont convaincus, non programmés, et peuvent être extrêmement sensibles aux détails spécifiques des suggestions sans qu'il y ait de raison évidente pour que ces détails importent. Deuxièmement, il est crucial de creuser dans les données (par exemple, générer des explications potentielles pour le raisonnement LLM qui conduit à des réponses incorrectes). Troisièmement, et surtout, l'ingénierie des suggestions devrait impliquer une collaboration entre l'ingénieur en suggestions, qui a l'expertise pour guider les LLMs vers un comportement souhaité, et les experts du domaine, qui comprennent ce que sont ces comportements souhaités et pourquoi.
Finalement, nous avons trouvé un grand potentiel dans une méthode automatisée pour explorer l'espace des suggestions, mais aussi que combiner cette automatisation avec la révision humaine était l'approche la plus réussie. Nous espérons que cette étude servira de base pour des examens plus robustes sur la manière de réaliser l'ingénierie des suggestions.