Extraction pratique des requêtes pour les LLM plus petits

Maud Nalpas

L'efficacité d'un grand modèle de langage dépend en grande partie des instructions que nous lui donnons. L'ingénierie des requêtes consiste à formuler des questions de manière à obtenir le meilleur résultat possible d'un LLM. Il s'agit d'une étape cruciale dans l'implémentation d'une fonctionnalité basée sur un LLM.

L'ingénierie des requêtes est un processus itératif. Si vous avez testé différents LLM, vous avez probablement remarqué que vous deviez ajuster votre requête pour obtenir un meilleur résultat.

Il en va de même pour les modèles de différentes tailles.

Les interfaces de chat reposant sur de grands LLM, comme Gemini ou ChatGPT, peuvent souvent produire des résultats satisfaisants avec un minimum d'effort d'affichage. Toutefois, lorsque vous utilisez un LLM par défaut plus petit qui n'est pas affiné, vous devez adapter votre approche.

Les LLM plus petits sont moins puissants et disposent d'un pool d'informations plus réduit.

Qu'entend-on par "grands LLM plus petits" ?

La définition des tailles LLM est compliquée et n'est pas toujours divulguée par les créateurs.

Dans ce document, les "LLM plus petits" désignent tout modèle inférieur à 30 milliards de paramètres. À l'heure actuelle, les modèles comportant quelques millions à plusieurs milliards de paramètres peuvent être exécutés de manière réaliste dans le navigateur, sur des appareils grand public.

Dans quels cas utiliser des LLM plus petits ?

• IA générative sur l'appareil/dans le navigateur, par exemple si vous utilisez Gemma 2B avec l'API LLM Inference de MediaPipe (même adaptée aux appareils utilisant uniquement le processeur) ou DistilBert dans le navigateur avec Transformers.js. Le téléchargement d'un modèle et l'exécution d'inférences sur l'appareil d'un utilisateur ne sont possibles qu'avec ces grands LLM, afin de maintenir des téléchargements Web raisonnables et de s'adapter aux contraintes de mémoire et de GPU/processeur d'un appareil.
• IA générative générative côté serveur personnalisée De petits modèles à poids ouvert tels que Gemma 2B, Gemma 7B ou Gemma 27B sont disponibles pour que vous puissiez les exécuter sur votre propre serveur (et éventuellement les affiner).

Commencer

Les interfaces de chat reposant sur de grands LLM, comme Gemini ou ChatGPT, peuvent souvent produire des résultats satisfaisants avec un minimum d'effort de requête. Toutefois, lorsque vous travaillez avec de plus petits LLM, vous devez adapter votre approche. Les LLM plus petits sont moins puissants et disposent d'un pool d'informations plus réduit.

Fournissez des instructions contextuelles et des instructions de mise en forme précises

Pour obtenir des résultats optimaux avec de petits LLM, créez des requêtes plus détaillées et spécifiques.

Exemple :

Based on a user review, provide a product rating as an integer between 1 and 5. \n
Only output the integer.

Review: "${review}"
Rating:

Bien que Gemini 1.5 fournisse le résultat souhaité avec cette simple requête, le résultat de Gemma n'est pas satisfaisant:

• Le format est incorrect. Nous avons demandé un nombre entier pour la note.
• L'évaluation ne semble pas tout à fait exacte. Le premier avis est suffisamment enthousiaste pour attribuer une note de 5 étoiles.

Pour résoudre ce problème, nous devons utiliser des techniques d'ingénierie des requêtes, les requêtes one-shot, few-shot et les requêtes en chaîne de pensée. Nous devons également fournir des instructions de mise en forme claires et insister sur le fait que le modèle doit utiliser la gamme complète des notes.

Exemple :

`Analyze a product review, and then based on your analysis give me the
corresponding rating (integer). The rating should be an integer between 1 and
5. 1 is the worst rating, and 5 is the best rating. A strongly dissatisfied
review that only mentions issues should have a rating of 1 (worst). A strongly
satisfied review that only mentions positives and upsides should have a rating
of 5 (best). Be opinionated. Use the full range of possible ratings (1 to
5). \n\n
    \n\n
    Here are some examples of reviews and their corresponding analyses and
    ratings:
    \n\n
    Review: 'Stylish and functional. Not sure how it'll handle rugged outdoor
    use, but it's perfect for urban exploring.'
    Analysis: The reviewer appreciates the product's style and basic
    functionality. They express some uncertainty about its ruggedness but
    overall find it suitable for their intended use, resulting in a positive,
    but not top-tier rating.
    Rating (integer): 4
    \n\n
    Review: 'It's a solid backpack at a decent price. Does the job, but nothing
    particularly amazing about it.'
    Analysis: This reflects an average opinion. The backpack is functional and
    fulfills its essential purpose. However, the reviewer finds it unremarkable
    and lacking any standout features deserving of higher praise.
    Rating (integer): 3
    \n\n
    Review: 'The waist belt broke on my first trip! Customer service was unresponsive too. Would not recommend.'
    Analysis: A serious product defect and poor customer service experience naturally warrants the lowest possible rating. The reviewer is extremely unsatisfied with both the product and the company.
    Rating (integer): 1
    \n\n
    Review: 'Love how many pockets and compartments it has. Keeps everything organized on long trips. Durable too!'
    Analysis: The enthusiastic review highlights specific features the user loves (organization and durability), indicating great satisfaction with the product. This justifies the highest rating.
    Rating (integer): 5
    \n\n
    Review: 'The straps are a bit flimsy, and they started digging into my shoulders under heavy loads.'
    Analysis: While not a totally negative review, a significant comfort issue leads the reviewer to rate the product poorly. The straps are a key component of a backpack, and their failure to perform well under load is a major flaw.
    Rating (integer): 1
    \n\n
    Now, here is the review you need to assess:
    \n
    Review: "${review}" \n`;

Notre requête plus élaborée, combinée à des requêtes few-shot et à des techniques de requête en chaîne de pensée, permet d'obtenir des évaluations plus précises.

Analyse manuelle des résultats attendu

Bien que vous deviez toujours nettoyer et interpréter manuellement la sortie d'un LLM, cela est particulièrement vrai pour les LLM plus petits, qui peuvent produire des résultats moins précis et nécessiter des requêtes en chaîne de pensée.

Dans le premier exemple, nous avons utilisé des requêtes en chaîne de pensée. Le résultat comprenait donc à la fois une analyse et une note, et nous devons l'analyser manuellement. Notez également le format incohérent dans le résultat de la section précédente: le modèle génère parfois des valeurs Markdown, mais pas à chaque fois.

// Use try/catch to catch (parsing) errors
try {
  // Parse the output for a rating
  const int = /[1-5]/;
  const ratingAsString = llmOutput.match(int)[0];
  // Parse as int
  const ratingAsInt = parseInt(ratingAsString);
  // `checkRating` checks the rating is a number between 1 and 5, since the
  // regEx may catch a number like "100"
  const finalRating = checkRating(ratingAsInt);
} catch (e) {
  console.error('Error', e);
}

Différences entre les API Mind

Les API cloud LLM telles que l'API Gemini ou OpenAI, qui sont généralement le point d'entrée de grands LLM, offrent des fonctionnalités d'invites pratiques. Par exemple, Gemini 1.5 Pro propose des instructions système et un mode JSON.

À l'heure actuelle, ces fonctionnalités ne sont pas toujours disponibles pour l'utilisation de modèles personnalisés ni pour les LLM plus petits accessibles à l'aide d'API d'IA intégrées aux navigateurs, telles que l'API LLM Inference MediaPipe ou Transformers.js. Bien qu'il ne s'agisse pas nécessairement d'une limite technique, les API d'IA intégrées aux navigateurs ont tendance à être plus simples.

Limites de jetons d'esprit

Étant donné que votre requête pour des LLM plus petits doit inclure des exemples ou des instructions plus détaillées, elle sera probablement plus longue et occupera une plus grande partie de votre limite de jetons d'entrée, le cas échéant.

De plus, les modèles de petite taille ont tendance à avoir une limite de jetons d'entrée inférieure. Par exemple, Gemini 1.5 Pro présente une limite d'un million de jetons d'entrée, tandis que les modèles Gemma ont une fenêtre de contexte de 8K.

Utilisez des fonctions de comptage de jetons pour éviter d'atteindre la limite.

Adaptez vos estimations de temps

Tenez compte de la conception et des tests des requêtes dans vos estimations de temps d'ingénierie.

En raison des différences d'API et des limites de jetons, vous aurez probablement besoin de plus de temps et d'efforts pour élaborer votre requête pour un LLM plus petit qu'un grand LLM. Tester et valider le résultat du LLM peut également demander davantage d'efforts.

Ingénieur des requêtes ou affinage de requêtes ?

Pour les développeurs Web, l'ingénierie des requêtes est notre moyen privilégié pour exploiter l'IA générative plutôt que l'entraînement personnalisé et l'affinage. Toutefois, même l'ingénierie avancée des requêtes peut ne pas suffire dans certains cas d'utilisation, en particulier si vous employez un LLM de plus petite taille.

Utilisez l'affinage dans les cas suivants:

• Vous avez besoin d'une précision et de performances exceptionnelles pour une tâche spécifique. L'ajustement ajuste directement les paramètres internes du modèle pour obtenir des résultats optimaux.
• Vous disposez de données bien organisées et pertinentes pour votre tâche, déjà étiquetées avec des résultats privilégiés. Vous avez besoin de ces données pour un réglage efficace.
• Vous utilisez le modèle dans le même but à plusieurs reprises. L'affinage peut être effectué une seule fois et réutilisé pour une tâche spécifique.