

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Préparez les données pour affiner vos modèles
<a name="model-customization-prepare"></a>

Pour préparer des jeux de données d’entraînement et de validation pour votre modèle personnalisé, vous créez des fichiers `.jsonl` dans lesquels chaque ligne est un objet JSON correspondant à un enregistrement. Avant de commencer une tâche de personnalisation d’un modèle, vous devez au minimum préparer un jeu de données d’entraînement. Les fichiers que vous créez doivent respecter le format de la méthode de personnalisation et du modèle que vous avez choisis. Les enregistrements qu’ils contiennent doivent être conformes aux exigences de taille en fonction de votre modèle. 

Pour plus d’informations sur les exigences relatives aux modèles, consultez [Exigences de modèles pour les jeux de données d’entraînement et de validation](#model-training-validation-requirements). Pour connaître les quotas par défaut qui s’appliquent aux jeux de données d’entraînement et de validation utilisés pour personnaliser différents modèles, consultez les quotas **Somme des enregistrements d’entraînement et de validation** dans les [points de terminaison et quotas Amazon Bedrock](https://docs.aws.amazon.com/general/latest/gr/bedrock.html) dans Références générales AWS. 

La prise en charge d’un jeu de données de validation et le format de vos jeux de données d’entraînement et de validation dépendent des facteurs suivants. 
+ Type de tâche de personnalisation de réglage précis.
+ Modalités d’entrée et de sortie des données.

Pour plus d’informations sur le peaufinage des modèles Amazon Nova, consultez [Peaufinage des modèles Amazon Nova](https://docs.aws.amazon.com/nova/latest/userguide/customize-fine-tune.html).

## Modalités prises en charge pour un réglage précis
<a name="model-customization-data-support"></a>

Les sections suivantes décrivent les différentes fonctionnalités de réglage précis prises en charge par chaque modèle, organisées selon leurs modalités d'entrée et de sortie. Pour plus d’informations sur le peaufinage des modèles Amazon Nova, consultez [Peaufinage des modèles Amazon Nova](https://docs.aws.amazon.com/nova/latest/userguide/customize-fine-tune.html).

Modèles **Text-to-Text  **

Text-to-Text les modèles peuvent être affinés pour diverses tâches basées sur du texte, y compris les applications conversationnelles et non conversationnelles. Pour plus d'informations sur la préparation des données pour affiner Text-to-Text les modèles, consultez[Préparer les données pour affiner text-to-text les modèles](#preparing-text-data). 

Les modèles non conversationnels suivants sont optimisés pour des tâches telles que la synthétisation, la traduction et la réponse aux questions :
+ Amazon Titan Text G1 - Express
+ Amazon Titan Text G1 - Lite
+ Amazon Titan Text Premier
+ Cohere Command
+ Cohere Command Light
+ Meta Llama 3.1 8B Instruct
+ Meta Llama 3.1 70B Instruct

Les modèles conversationnels suivants sont conçus pour les interactions à simples ou complexes. Si un modèle utilise l’API Converse, votre jeu de données de peaufinage doit suivre le format de message de l’API Converse et inclure les messages du système, de l’utilisateur et de l’assistant. Pour obtenir des exemples, consultez [Préparer les données pour affiner text-to-text les modèles](#preparing-text-data). Pour plus d’informations sur les opérations d’API Converse, consultez [Mener une conversation avec les opérations d’API Converse](conversation-inference.md).
+ Anthropic Claude 3 Haiku
+ Meta Llama 3.2 1B Instruct (format de l’API Converse)
+ Meta Llama 3.2 3B Instruct (format de l’API Converse)
+ Meta Llama 3.2 11B Instruct Vision (format de l’API Converse)
+ Meta Llama 3.2 90B Instruct Vision (format de l’API Converse)
+ Meta Llama 3.3 70B Vision Instruct (format de l’API Converse)

**Text-Image-to-Text et Text-to-Image modèles** S

Les modèles suivants permettent un peaufinage pour la génération d’images et le traitement des images de texte. Ces modèles traitent ou génèrent des images sur la base d’entrées textuelles, ou génèrent du texte sur la base d’entrées textuelles et d’images. Pour plus d'informations sur la préparation des données pour le réglage fin Text-Image-to-Text et Text-to-Image les modèles de modèles, voir[Préparation des données pour optimiser les modèles de traitement d’image et de texte](#preparing-image-text-data).
+ Amazon Titan Image Generator G1 V1
+ Meta Llama 3.2 11B Instruct Vision
+ Meta Llama 3.2 90B Instruct Vision
+ Meta Llama 3.3 70B Vision Instruct

**Image à vectorisation**

Les modèles suivants permettent d’optimiser des tâches telles que la classification et l’extraction. Ces modèles génèrent des représentations numériques (vectorisations) à partir des entrées d’image. Pour plus d'informations sur la préparation des données pour affiner Image-to-Embeddings les modèles, consultez[Préparation des données pour optimiser la génération d’images et les modèles de vectorisation](#preparing-image-generation-data).
+ Amazon Titan Multimodal Embeddings G1
+ Amazon Titan Image Generator G1 V1

## Exigences de modèles pour les jeux de données d’entraînement et de validation
<a name="model-training-validation-requirements"></a>

Les sections suivantes répertorient les exigences pour les jeux de données d’entraînement et de validation pour un modèle. Pour plus d’informations sur les contraintes des jeux de données pour les modèles Amazon Nova, consultez [Peaufinage des modèles Amazon Nova](https://docs.aws.amazon.com/nova/latest/userguide/customize-fine-tune.html).

### Amazon Titan Text Premier
<a name="quotas-cm-titan-premier"></a>


****  

| Description | Maximum (peaufinage) | 
| --- | --- | 
| Somme des jetons d'entrée et de sortie lorsque la taille du lot est égale à 1 | 4 096 | 
| Somme des jetons d’entrée et de sortie lorsque la taille du lot est égale à 2, 3 ou 4 | N/A | 
| Quota de caractères par échantillon dans le jeu de données | Quota de jetons x 6 (estimé) | 
| Taille de fichier de jeu de données d'entraînement | 1 Go | 
| Taille de fichier de jeu de données de validation | 100 Mo | 

### Amazon Titan Text G1 - Express
<a name="quotas-cm-titan-text"></a>


****  

| Description | Maximum (peaufinage) | 
| --- | --- | 
| Somme des jetons d'entrée et de sortie lorsque la taille du lot est égale à 1 | 4 096 | 
| Somme des jetons d’entrée et de sortie lorsque la taille du lot est égale à 2, 3 ou 4 | 2 048 | 
| Quota de caractères par échantillon dans le jeu de données | Quota de jetons x 6 (estimé) | 
| Taille de fichier de jeu de données d'entraînement | 1 Go | 
| Taille de fichier de jeu de données de validation | 100 Mo | 

### Amazon Titan Text G1 - Lite
<a name="quotas-cm-titan-text-lite"></a>


****  

| Description | Maximum (peaufinage) | 
| --- | --- | 
| Somme des jetons d’entrée et de sortie lorsque la taille du lot est égale à 1 ou 2 | 4 096 | 
| Somme des jetons d’entrée et de sortie lorsque la taille du lot est égale à 3, 4, 5 ou 6 | 2 048 | 
| Quota de caractères par échantillon dans le jeu de données | Quota de jetons x 6 (estimé) | 
| Taille de fichier de jeu de données d'entraînement | 1 Go | 
| Taille de fichier de jeu de données de validation | 100 Mo | 

### Amazon Titan Image Generator G1 V1
<a name="quotas-cm-titan-image"></a>


****  

| Description | Minimum (peaufinage) | Maximum (peaufinage) | 
| --- | --- | --- | 
| Longueur de l’invite de texte dans l’échantillon d’entraînement, en caractères | 3 | 1,024 | 
| Enregistrements dans un jeu de données d’entraînement | 5 | 10 000 | 
| Taille de l’image d’entrée | 0 | 50 Mo | 
| Hauteur de l’image d’entrée en pixels | 512 | 4 096 | 
| Largeur de l’image d’entrée en pixels | 512 | 4 096 | 
| Nombre total de pixels de l’image d’entrée | 0 | 12 582 912 | 
| Proportion de l’image d’entrée | 1:4 | 4:1 | 

### Amazon Titan Multimodal Embeddings G1
<a name="quotas-cm-titan-mm-embed"></a>


****  

| Description | Minimum (peaufinage) | Maximum (peaufinage) | 
| --- | --- | --- | 
| Longueur de l’invite de texte dans l’échantillon d’entraînement, en caractères | 0 | 2 560 | 
| Enregistrements d’un jeu de données d’entraînement | 1 000 | 500 000 | 
| Taille de l’image d’entrée | 0 | 5 Mo | 
| Hauteur de l’image d’entrée en pixels | 128 | 4096 | 
| Largeur de l’image d’entrée en pixels | 128 | 4096 | 
| Nombre total de pixels de l’image d’entrée | 0 | 12 528 912 | 
| Proportion de l’image d’entrée | 1:4 | 4:1 | 

### Meta Llama 3.1
<a name="quotas-cm-meta-llama-3-1"></a>


****  

| Description | Minimum (peaufinage) | Maximum (peaufinage) | 
| --- | --- | --- | 
| Jetons d’entrée | 0 | 16,000 | 
| Jetons de sortie | 0 | 16,000 | 
| Quota de caractères par échantillon dans le jeu de données | 0 | Quota de jetons x 6 (estimé) | 
| Somme des jetons d’entrée et de sortie | 0 | 16,000 | 
| Somme des enregistrements d’entraînement et de validation | 100 | 10 000 (ajustable à l’aide des quotas de service) | 

### Meta Llama 3.2
<a name="quotas-cm-meta-llama-3-2"></a>

Les formats d’image pris en charge pour Meta Llama-3.2 11B Vision Instruct et Meta Llama-3.2 90B Vision Instruct incluent : `gif`, `jpeg`, `png` et `webp`. Pour estimer la image-to-token conversion lors du réglage fin de ces modèles, vous pouvez utiliser cette formule comme approximation :`Tokens = min(2, max(Height // 560, 1)) * min(2, max(Width // 560, 1)) * 1601`. Les images sont converties en environ 1 601 à 6 404 jetons en fonction de leur taille.


****  

| Description | Minimum (peaufinage) | Maximum (peaufinage) | 
| --- | --- | --- | 
| Somme des jetons d’entrée et de sortie | 0 | 16 000 (10 000 pour Meta Llama 3.2 90B) | 
| Somme des enregistrements d’entraînement et de validation | 100 | 10 000 (ajustable à l’aide des quotas de service) | 
| Taille de l’image d’entrée (pour les modèles Meta Llama 11B and 90B instruct) | 0 | 10 Mo | 
| Hauteur de l’image d’entrée en pixels pour les modèles Meta Llama 11B and 90B instruct | 10 | 8192 | 
| Largeur de l’image d’entrée en pixels pour les modèles Meta Llama 11B and 90B90B instruct | 10 | 8192 | 

### Meta Llama 3.3
<a name="quotas-cm-meta-llama-3-3"></a>


****  

| Description | Minimum (peaufinage) | Maximum (peaufinage) | 
| --- | --- | --- | 
| Somme des jetons d’entrée et de sortie | 0 | 16000 | 
| Somme des enregistrements d’entraînement et de validation | 100 | 10 000 (ajustable à l’aide des quotas de service) | 

### CohereCommand
<a name="quotas-cm-cohere-command"></a>


****  

| Description | Maximum (peaufinage) | 
| --- | --- | 
| Jetons d’entrée | 4 096 | 
| Jetons de sortie | 2 048 | 
| Quota de caractères par échantillon dans le jeu de données | Quota de jetons x 6 (estimé) | 
| Enregistrements d’un jeu de données d’entraînement | 10 000 | 
| Enregistrements dans un jeu de données de validation | 1 000 | 

### Anthropic Claude 3 Haiku
<a name="anthropic-claude-3-haiku"></a>


****  

| Description | Maximum (peaufinage) | 
| --- | --- | 
| Nombre minimum d’enregistrements | 32 | 
| Nombre maximum d’enregistrements d’entraînement | 10 000 | 
| Nombre maximum d’enregistrements de validation | 1 000 | 
| Nombre total maximum d’enregistrements | 10 000 (ajustable à l’aide des quotas de service) | 
| Nombre maximal de jetons | 32 000 | 
| Taille maximale de jeu de données d’entraînement | 10 Go | 
| Taille maximale du jeu de données de validation | 1 Go | 

## Préparer les données pour affiner text-to-text les modèles
<a name="preparing-text-data"></a>

**Note**  
Pour plus d’informations sur le peaufinage des modèles Amazon Nova, consultez [Peaufinage des modèles Amazon Nova](https://docs.aws.amazon.com/nova/latest/userguide/customize-fine-tune.html).

Pour affiner les text-to-text modèles, chaque objet JSON est un exemple contenant des champs structurés conçus pour guider le modèle vers la génération de la sortie textuelle souhaitée en fonction d'une invite textuelle fournie. Le format des données varie en fonction du cas d’utilisation, généralement classé en cas d’utilisation non conversationnelle et conversationnelle.

------
#### [ Non-conversational tasks ]

Les tâches non conversationnelles impliquent de générer une sortie unique pour une entrée donnée. Chaque échantillon de jeu de données inclut un champ `prompt` contenant le texte d’entrée et un champ `completion` contenant le résultat attendu. Ce format prend en charge un éventail de tâches telles que la réponse aux questions, la synthèse, la traduction, la complétion de texte et l’extraction d’informations.

Exemple de format

```
{"prompt": "What is the capital of France?", "completion": "The capital of France is Paris."}
{"prompt": "Summarize the article about climate change.", "completion": "Climate change refers to the long-term alteration of temperature and typical weather patterns in a place."}
```

Utilisez environ 6 caractères par jeton pour estimer le nombre de jetons nécessaires à la planification de la taille du jeu de données.

------
#### [ Converse API format (Single turn and Multi turn) ]

Pour utiliser l’API Converse, vous devez appeler les opérations `Converse` ou `ConverseStream` pour envoyer des messages à un modèle. Pour appeler `Converse`, vous devez disposer de l’autorisation sur l’opération `bedrock:InvokeModel`. Pour appeler `ConverseStream`, vous devez disposer de l’autorisation sur l’opération `bedrock:InvokeModelWithResponseStream`. Pour plus d’informations, consultez [Utilisation de l’API Converse](conversation-inference-call.md). Pour plus d’informations sur les opérations d’API Converse, consultez [Mener une conversation avec les opérations d’API Converse](conversation-inference.md).

Exemple de format

```
{
    "schemaVersion": "bedrock-conversation-2024",
    "system": [
        {
            "text": "You are a digital assistant with a friendly personality"
        }
    ],
    "messages": [
        {
            "role": "user",
            "content": [
                {
                    "text": "What is the capital of Mars?"
                }
            ]
        },
        {
            "role": "assistant",
            "content": [
                {
                    "text": "Mars does not have a capital. Perhaps it will one day."
                }
            ]
        }
    ]
}
```

------
#### [ Anthropic Claude 3 Haiku: Single-turn conversations ]

Les tâches conversationnelles simples impliquent des échanges isolés, le modèle générant une réponse basée uniquement sur l’entrée actuelle de l’utilisateur sans tenir compte du contexte antérieur. Chaque exemple de jeu de données utilise un tableau de messages, avec des rôles alternés de `user` et `assistant`.

Format

```
{"system": "<system message>","messages":[{"role": "user", "content": "<user query>"},{"role": "assistant", "content": "<expected generated text>"}]}
```

Exemple

```
{"system": "You are an helpful assistant.","messages":[{"role": "user", "content": "what is AWS"},{"role": "assistant", "content": "it's Amazon Web Services."}]}
```

------
#### [ Anthropic Claude 3 Haiku: Multi-turn conversations ]

Les tâches conversationnelles complexes impliquent des dialogues étendus dans lesquels le modèle doit générer des réponses tout en préservant le contexte des échanges précédents. Ce format reflète la nature dynamique des tâches interactives, telles que le support client ou les discussions complexes.

Format

```
{"system": "<system message>","messages":[{"role": "user", "content": "<user query 1>"},{"role": "assistant", "content": "<expected generated text 1>"}, {"role": "user", "content": "<user query 2>"},{"role": "assistant", "content": "<expected generated text 2>"}]}
```

Exemple

```
{"system": "system message","messages":[{"role": "user", "content": "Hello there."},{"role": "assistant", "content": "Hi, how can I help you?"},{"role": "user", "content": "what are LLMs?"},{"role": "assistant", "content": "LLM means large language model."},]}  
```

------

## Préparation des données pour optimiser les modèles de traitement d’image et de texte
<a name="preparing-image-text-data"></a>

**Note**  
Pour plus d’informations sur le peaufinage des modèles Amazon Nova, consultez [Peaufinage des modèles Amazon Nova](https://docs.aws.amazon.com/nova/latest/userguide/customize-fine-tune.html).

Pour affiner les image-text-to-text modèles, chaque objet JSON est un exemple contenant une conversation structurée sous forme de `messages` tableau, composée d'objets JSON alternés représentant les entrées de l'utilisateur et les réponses de l'assistant. Les entrées de l’utilisateur peuvent inclure à la fois du texte et des images, tandis que les réponses de l’assistant sont toujours textuelles. Cette structure prend en charge les flux de conversation simple et complexe, ce qui permet au modèle de gérer efficacement diverses tâches. Les formats d’image pris en charge pour Meta Llama-3.2 11B Vision Instruct et Meta Llama-3.2 90B Vision Instruct incluent : `gif`, `jpeg`, `png` et `webp`.

Pour autoriser l’accès d’Amazon Bedrock aux fichiers d’images, ajoutez une politique IAM similaire à celle indiquée dans [Autorisations d’accès aux fichiers d’entraînement et de validation et d’écriture de fichiers de sortie dans S3](model-customization-iam-role.md#model-customization-iam-role-s3) au rôle de service de personnalisation du modèle Amazon Bedrock que vous avez configuré ou qui a été automatiquement configuré pour vous dans la console. Les chemins Amazon S3 que vous fournissez dans le jeu de données d’entraînement doivent se trouver dans des dossiers que vous spécifiez dans la politique.

**Conversations simples**

Chaque objet JSON pour les conversations simples se compose d’un message d’utilisateur et d’un message d’assistant. Le message d’utilisateur inclut un champ de rôle défini sur *utilisateur* et un champ *contenu* contenant un tableau avec un champ `type` (*texte* ou *image*) décrivant la modalité d’entrée. Pour les entrées de texte, le champ `content` inclut un champ `text` contenant la question ou l’invite de l’utilisateur. Pour les entrées d’image, le champ `content` spécifie le `format` de l’image (par exemple, *jpeg*, *png*) et sa `source` avec un `uri` pointant vers l’emplacement Amazon S3 de l’image. L’`uri` représente le chemin unique vers l’image stockée dans un compartiment Amazon S3, généralement au format `s3://<bucket-name>/<path-to-file>`. Le message d’assistant comprend un champ `role` défini sur *assistant* et un champ `content` contenant un tableau avec un champ `type` défini sur *texte* et un champ `text` contenant la réponse générée par l’assistant.

Exemple de format

```
{
    "schemaVersion": "bedrock-conversation-2024",
    "system": [{
        "text": "You are a smart assistant that answers questions respectfully"
    }],
    "messages": [{
            "role": "user",
            "content": [{
                    "text": "What does the text in this image say?"
                },
                {
                    "image": {
                        "format": "png",
                        "source": {
                            "s3Location": {
                                "uri": "s3://your-bucket/your-path/your-image.png",
                                "bucketOwner": "your-aws-account-id"
                            }
                        }
                    }
                }
            ]
        },
        {
            "role": "assistant",
            "content": [{
                "text": "The text in the attached image says 'LOL'."
            }]
        }
    ]
}
```

**Conversations complexes**

Chaque objet JSON pour les conversations complexes contient une séquence de messages avec des rôles alternés, dans lesquels les messages d’utilisateur et les messages d’assistant sont structurés de manière cohérente pour permettre des échanges cohérents. Les messages d’utilisateur incluent un champ `role` défini sur *utilisateur* et un champ `content` qui décrit la modalité d’entrée. Pour les entrées de texte, le champ `content` inclut un champ `text` contenant la question ou le suivi de l’utilisateur, tandis que pour les entrées d’images, il indique l’image `format` et son `source` avec un `uri` pointant vers l’emplacement Amazon S3 de l’image. `uri`Il sert d'identifiant unique au format s3 ://<bucket-name>/< path-to-file > et permet au modèle d'accéder à l'image depuis le compartiment Amazon S3 désigné. Les messages d’assistant incluent un champ `role` défini sur *assistant* et un champ `content` contenant un tableau avec un champ `type` défini sur *texte* et un champ `text` contenant la réponse générée par l’assistant. Les conversations peuvent couvrir plusieurs échanges, ce qui permet à l’assistant de maintenir le contexte et de fournir des réponses cohérentes tout au long de la conversation.

Exemple de format

```
{
    "schemaVersion": "bedrock-conversation-2024",
    "system": [{
        "text": "You are a smart assistant that answers questions respectfully"
    }],
    "messages": [{
            "role": "user",
            "content": [{
                    "text": "What does the text in this image say?"
                },
                {
                    "image": {
                        "format": "png",
                        "source": {
                            "s3Location": {
                                "uri": "s3://your-bucket/your-path/your-image.png",
                                "bucketOwner": "your-aws-account-id"
                            }
                        }
                    }
                }
            ]
        },
        {
            "role": "assistant",
            "content": [{
                "text": "The text in the attached image says 'LOL'."
            }]
        },
        {
            "role": "user",
            "content": [{
                    "text": "What does the text in this image say?"
                }
            ]
        },
        {
            "role": "assistant",
            "content": [{
                "text": "The text in the attached image says 'LOL'."
            }]
        }
        
    ]
}
```

## Préparation des données pour optimiser la génération d’images et les modèles de vectorisation
<a name="preparing-image-generation-data"></a>

**Note**  
Les modèles Amazon Nova ont des exigences de peaufinage différentes. Pour optimiser ces modèles, suivez les instructions de la section [Peaufinage des modèles Amazon Nova](https://docs.aws.amazon.com/nova/latest/userguide/customize-fine-tune.html).

Pour nos text-to-image image-to-embedding modèles, préparez un jeu de données d'entraînement. Les jeux de données de validation ne sont pas pris en charge. Chaque objet JSON est un échantillon contenant un élément `image-ref`, l’URI Amazon S3 d’une image et un élément `caption` qui peut être une invite pour cette image.

Les images doivent être au format JPEG ou PNG.

```
{"image-ref": "s3://bucket/path/to/image001.png", "caption": "<prompt text>"}
{"image-ref": "s3://bucket/path/to/image002.png", "caption": "<prompt text>"}{"image-ref": "s3://bucket/path/to/image003.png", "caption": "<prompt text>"}
```

Voici un exemple d’élément :

```
{"image-ref": "s3://amzn-s3-demo-bucket/my-pets/cat.png", "caption": "an orange cat with white spots"}
```

Pour autoriser l’accès d’Amazon Bedrock aux fichiers d’images, ajoutez une politique IAM similaire à celle indiquée dans [Autorisations d’accès aux fichiers d’entraînement et de validation et d’écriture de fichiers de sortie dans S3](model-customization-iam-role.md#model-customization-iam-role-s3) au rôle de service de personnalisation du modèle Amazon Bedrock que vous avez configuré ou qui a été automatiquement configuré pour vous dans la console. Les chemins Amazon S3 que vous fournissez dans le jeu de données d’entraînement doivent se trouver dans des dossiers que vous spécifiez dans la politique.