Extraction pratique des requêtes pour les LLM plus petits

Maud Nalpas

L'efficacité d'un grand modèle de langage dépend fortement des instructions que nous le lui donner. L'ingénierie des requêtes correspond qui consiste à formuler des questions de façon à obtenir les meilleurs résultats 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 déjà testé vous avez probablement remarqué qu'il fallait ajuster sa requête d'obtenir un meilleur résultat.

Cela s'applique également aux modèles de tailles différentes.

Les interfaces Chat alimentées par de grands LLM, comme Gemini ou ChatGPT, peuvent souvent produire des résultats satisfaisants avec un minimum d'efforts de requête. Toutefois, lorsque vous travaillez avec un LLM par défaut plus petit qui n'est pas affiné, vous pouvez devez adapter votre approche.

Les LLM plus petits sont moins puissants et disposent d'un volume d'informations plus restreint.

Qu'entendons-nous par "plus petits LLM" ?

Il est difficile de définir des tailles LLM, et ce n'est pas toujours le cas divulguée par les créateurs.

Dans ce document, le terme "LLM plus petits" c'est-à-dire tout modèle avec des paramètres de 30 milliards. À l'heure actuelle, les modèles comportant quelques millions, voire plusieurs milliards de paramètres, peuvent dans le navigateur, sur des appareils grand public.

Où les grands modèles de langage (LLM) sont-ils utilisés ?

• IA générative sur l'appareil/le navigateur, par exemple si vous utilisez Gemma 2B avec l'API LLM Inference de MediaPipe (même adapté aux appareils avec processeur uniquement) ou DistilBert dans le navigateur avec Transformers.js Vous ne pouvez télécharger un modèle et exécuter une inférence sur l'appareil d'un utilisateur que avec ces LLM plus petits, pour que les téléchargements Web restent raisonnables et adaptés les contraintes de mémoire et de GPU/processeur d'un appareil.
• IA générative côté serveur personnalisée : Les petits modèles à poids ouvert comme Gemma 2B, Les modèles Gemma 7B et Gemma 27B peuvent être exécutés sur votre propre serveur (et éventuellement peaufiner).

Commencer

Les interfaces Chat optimisées par de grands LLM, comme Gemini ou ChatGPT, peuvent souvent produire des résultats satisfaisants avec un minimum d'efforts de requête. Toutefois, lorsque vous travaillez avec des LLM de petite taille, vous devez adapter votre approche. Les LLM plus petits sont moins puissants et disposent d'un volume d'informations plus restreint.

Fournissez du contexte et des instructions précises concernant le format

Pour obtenir des résultats optimaux avec de petits LLM, élaborez 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:

Gemini 1.5 fournit le résultat souhaité avec cette simple requête, le résultat n'est pas satisfaisant:

• Le format est incorrect. Nous avons demandé un nombre entier pour la note.
• La note ne semble pas tout à fait exacte. Le premier avis est suffisamment enthousiaste pour indiquer qu'il s'agit d'une note à 5 étoiles.

Pour résoudre ce problème, nous devons utiliser des techniques d'ingénierie des requêtes, Requêtes one-hot, few-shot et multi-shot et les requêtes de chaîne de pensée. Nous devons également fournir des instructions claires concernant le format et insister pour que le modèle utilisent l'ensemble 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 techniques de requêtes few-shot et en chaîne de pensée, permet d'obtenir des évaluations plus précises.

Analyse manuelle des résultats attendue

Même si vous devez toujours nettoyer et interpréter manuellement la sortie d'un LLM, il s'agit C'est particulièrement vrai pour les LLM de petite taille, qui peuvent produire des résultats moins soignés. peut nécessiter une chaîne de pensée.

Dans le premier exemple, nous avons utilisé des requêtes en chaîne de pensée, de sorte que la sortie incluait à la fois une analyse et une note. Nous devons analyser manuellement la note. Aussi Notez que la mise en forme de la sortie est incohérente par rapport à la section précédente: le modèle génère parfois un élément 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 avec l'API Mind

les API cloud LLM telles que l'API Gemini ou OpenAI, qui sont généralement vers de plus grands LLM, proposent des fonctionnalités de requête pratiques. Par exemple, Gemini 1.5 Pro propose des instructions système et Mode JSON :

Pour le moment, ces fonctionnalités ne sont pas toujours disponibles pour les modèles personnalisés. pour les LLM plus petits, accessibles à l'aide d'API d'IA intégrées au navigateur, comme le API MediaPipe LLM Inference 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 alléger.

Limites de jetons

Votre requête pour des LLM de petite taille doit inclure des exemples ou des requêtes plus détaillées instructions, il sera probablement plus long et occupera plus de place sur votre jeton d'entrée s'il y en a une.

De plus, les modèles plus petits ont tendance à avoir une limite de jetons d'entrée inférieure. Pour Exemple : Gemini 1.5 Pro impose une limite d'un million de jetons d'entrée. tandis que les modèles Gemma ont une fenêtre de contexte 8K.

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

Adaptez vos estimations de délais

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 créer votre requête pour un LLM plus petit qu'un plus grand. Tests et validation la sortie du LLM peut aussi nécessiter un effort plus important.

Ingénieur des requêtes ou réglage ?

Pour les développeurs Web, nous préférons utiliser l'ingénierie des requêtes IA générative avec l'entraînement personnalisé et l'affinage. Mais même une ingénierie des requêtes avancée peut ne pas suffire dans certains cas d'utilisation, surtout si vous utilisez un LLM de plus petite taille.

Utilisez l'affinage dans les cas suivants:

• Pour accomplir une tâche spécifique, vous avez besoin d'une précision et de performances exceptionnelles. Fin 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, pertinentes pour votre tâche, déjà étiquetées avec vos préférences de sortie. Ces données sont nécessaires pour effectuer des réglages efficaces.
• Vous utilisez le modèle plusieurs fois dans le même objectif. L'affinage peut être effectué et réutilisés pour une tâche spécifique.