Dernière révision : juin 2026
Une référence concise des modèles d'architecture évalués par l'examen C1000-185. Lisez de haut en bas ou sautez à une section.
L'entreprise a besoin d'un modèle capable de suivre les instructions avec une licence permissive et une indemnisation.
Choisissez un modèle d'instruction IBM Granite du catalogue watsonx.ai plutôt qu'un modèle hébergé par un tiers.
Pourquoi: Les modèles Granite sont construits et régis par IBM, et bénéficient de l'indemnisation IP d'IBM - le choix sûr par défaut pour les charges de travail réglementées.
Sélectionner entre une variante optimisée pour le chat et une variante optimisée pour les instructions pour une tâche d'extraction en un seul tour.
Utilisez la variante d'instruction avec une invite directive claire ; réservez les modèles de chat pour les dialogues à plusieurs tours.
Pourquoi: Les modèles de chat s'attendent à des tours structurés par rôle ; pour les tâches ponctuelles, le modèle d'instruction est plus simple et moins cher.
Le résultat doit être déterministe et reproductible pour un rapport de conformité.
Définissez le décodage en mode gourmand (pas d'échantillonnage) afin que le jeton de plus haute probabilité soit toujours choisi.
Pourquoi: Le décodage gourmand élimine l'aléatoire ; l'échantillonnage avec température introduit une variation que vous ne voulez pas dans une sortie auditée.
La génération de textes créatifs semble répétitive et fade.
Passez au décodage par échantillonnage et augmentez la température (par exemple 0,7-1,0) pour élargir la distribution des jetons.
Pourquoi: Une température plus élevée aplatit les probabilités afin que les jetons de rang inférieur soient sélectionnés, augmentant la diversité.
L'échantillonnage produit parfois des résultats hors sujet avec des jetons rares.
Contraignez l'échantillonnage avec top-k ou top-p (nucleus) pour limiter les candidats aux jetons les plus probables.
Pourquoi: top-k limite le nombre de candidats ; top-p limite la masse de probabilité cumulative - les deux coupent la longue traîne qui provoque la dérive.
Le modèle boucle, répétant la même phrase ou proposition.
Augmentez le paramètre de pénalité de répétition pour décourager la réémission des jetons récents.
Pourquoi: La pénalité diminue la probabilité des jetons déjà vus ; les séquences d'arrêt seules ne corrigent pas les boucles en cours de génération.
La génération dépasse la réponse et se poursuit dans un texte de suivi hallucinatoire.
Définissez une ou plusieurs séquences d'arrêt (par exemple "\n\n", "###") afin que la génération s'arrête à une limite connue.
Pourquoi: Les séquences d'arrêt terminent la sortie de manière déterministe ; se fier uniquement au nombre maximal de jetons tronque au milieu d'une phrase.
Les réponses sont tronquées avant de compléter le JSON demandé.
Augmentez le nombre maximum de nouveaux jetons ; définissez le nombre minimum de nouveaux jetons pour forcer une réponse de longueur minimale si nécessaire.
Pourquoi: Le nombre maximum de nouveaux jetons limite la longueur de la sortie ; s'il est trop faible, il tronque la sortie structurée avant l'accolade fermante.
La classification zero-shot attribue de mauvaises étiquettes aux cas limites.
Ajoutez une poignée d'exemples d'entrée/sortie étiquetés (few-shot) directement dans l'invite.
Pourquoi: Les exemples few-shot définissent le format de sortie et la limite de décision en contexte sans aucun ajustement.
L'équipe souhaite itérer sur une invite avant d'écrire du code.
Utilisez Prompt Lab - basculez entre les modes libre, structuré et chat, ajustez les paramètres, puis enregistrez-le comme modèle d'invite.
Pourquoi: Prompt Lab est l'interface d'itération sans code ; le mode structuré sépare clairement l'instruction, les exemples et l'entrée.
Les documents longs dépassent la fenêtre de contexte du modèle choisi.
Découpez et récupérez uniquement les passages pertinents (RAG) ou choisissez un modèle avec un contexte plus long dans le catalogue.
Pourquoi: Vous ne pouvez pas dépasser la limite de jetons du modèle ; insérer plus de texte entraîne des suppressions silencieuses ou des erreurs - la récupération est la solution évolutive.
Le prompt engineering atteint un plateau sur une tâche de domaine étroit qui nécessite un style cohérent.
Exécutez le prompt tuning dans Tuning Studio pour apprendre une invite souple (vecteur ajusté) sur des exemples étiquetés.
Pourquoi: Le prompt tuning adapte le comportement sans modifier les poids de base - moins cher que le fine-tuning, plus fiable que les longues invites.
Le modèle manque de connaissances d'entreprise factuelles et à jour.
Utilisez RAG pour ancrer les réponses dans des documents récupérés plutôt que d'ajuster le modèle sur ces faits.
Pourquoi: L'ajustement enseigne le style/comportement, pas de nouveaux faits ; RAG injecte un contexte actuel ancré et est facile à mettre à jour.
Décider entre le prompt tuning et le fine-tuning complet pour un projet watsonx de niveau associé.
Préférez le prompt tuning : il entraîne beaucoup moins de paramètres, s'exécute plus rapidement et est le chemin pris en charge dans Tuning Studio.
Pourquoi: Le fine-tuning complet est coûteux, nécessite de grands ensembles de données et risque l'oubli catastrophique ; le prompt tuning est la valeur par défaut de watsonx.
Préparer les données pour affiner un modèle de résumé par prompt tuning.
Fournissez des paires entrée/sortie au format JSON/JSONL attendu, divisées en ensembles d'entraînement et de validation.
Pourquoi: Des paires propres et représentatives améliorent la qualité de l'ajustement ; un ensemble de validation conservé est nécessaire pour évaluer la généralisation.
La courbe de perte d'ajustement s'aplatit tôt tandis que la perte de validation commence à augmenter.
Arrêtez ou réduisez les époques - le modèle commence à surajuster l'ensemble d'entraînement.
Pourquoi: La divergence de la perte d'entraînement/validation est le signal classique de surajustement ; plus d'époques mémoriseraient au lieu de généraliser.
Les résultats du prompt tuning sont instables d'une exécution à l'autre.
Ajustez le taux d'apprentissage, le nombre d'époques, la taille du lot et le nombre de jetons virtuels dans la configuration du tuning.
Pourquoi: Un taux d'apprentissage trop élevé déstabilise l'entraînement ; ce sont les leviers que Tuning Studio expose pour la convergence.
Besoin de comparer objectivement deux invites ou actifs ajustés.
Évaluez avec des métriques de tâche (par exemple ROUGE/BLEU pour la résumé, correspondance exacte/F1 pour l'extraction) plus une révision humaine.
Pourquoi: La qualité générative est multidimensionnelle ; les métriques automatisées détectent les régressions, mais l'examen humain juge la fidélité.
Le modèle ajusté invente toujours des faits non présents dans la source.
Ancrez avec RAG, baissez la température et demandez au modèle de répondre uniquement à partir du contexte fourni ou de dire qu'il ne sait pas.
Pourquoi: L'hallucination est plus un problème d'ancrage et de décodage qu'un problème de poids ; la récupération et les contraintes résolvent la majeure partie.
Seules quelques dizaines d'exemples étiquetés sont disponibles pour l'adaptation.
Restez avec le few-shot prompting ou le prompt tuning léger ; ne faites pas de fine-tuning sur de très petites données.
Pourquoi: Les petits ensembles de données surajustent gravement en fine-tuning complet ; les exemples in-context se généralisent mieux à cette échelle.
Choisir le modèle de base à affiner par prompt tuning pour une tâche de classification.
Choisissez un modèle de base Granite réglable que Tuning Studio prend en charge pour le prompt tuning, dimensionné pour la tâche.
Pourquoi: Tous les modèles du catalogue ne sont pas réglables ; l'ajustement d'un modèle pris en charge plus petit est moins cher et souvent suffisant pour la classification.
La qualité de la sortie générative doit être suivie en continu en production.
Configurez les métriques d'évaluation de watsonx.governance (qualité, dérive, métriques d'IA générative) pour le déploiement.
Pourquoi: La gouvernance transforme l'évaluation ponctuelle en seuils surveillés avec des alertes, et non en une vérification manuelle ponctuelle.
La même invite ajustée doit traiter de nombreuses entrées avec des champs différents.
Paramétrez le modèle d'invite avec des variables nommées et fournissez des valeurs au moment de l'inférence.
Pourquoi: Les variables permettent de conserver un modèle réutilisable au lieu de coder en dur les entrées, et elles se mappent proprement aux paramètres de l'API.
Un modèle ignore l'instruction de la tâche et se contente de poursuivre le texte.
Utilisez un modèle optimisé pour les instructions et formulez l'invite comme une directive explicite, et non comme un fragment à compléter.
Pourquoi: Les modèles de complétion de base poursuivent des motifs ; les modèles d'instruction sont entraînés à suivre des directives.
Besoin d'exécuter des requêtes SQL interactives sur des données de stockage d'objets pour la préparation des fonctionnalités d'IA.
Utilisez le moteur Presto de watsonx.data sur des tables Iceberg dans le stockage d'objets.
Pourquoi: Presto offre un SQL fédéré rapide sur des formats de table ouverts sans copier les données dans un entrepôt.
Les données d'analyse nécessitent une évolution de schéma et une navigation temporelle sur le lakehouse.
Stockez-les sous forme de tables Apache Iceberg gérées par watsonx.data.
Pourquoi: Iceberg prend en charge l'évolution de schéma, les instantanés et les opérations ACID sur le stockage d'objets - la valeur par défaut du lakehouse.
Choisir un moteur pour les transformations ETL lourdes par rapport aux requêtes ad-hoc.
Utilisez Spark pour les transformations/ETL par lots importants ; utilisez Presto pour les requêtes SQL interactives à faible latence.
Pourquoi: Spark met à l'échelle le calcul par lots ; Presto est optimisé pour les requêtes fédérées rapides - choisissez en fonction de la forme de la charge de travail.
RAG a besoin d'un magasin de vecteurs pour les embeddings co-localisé avec des données gouvernées.
Provisionnez Milvus dans watsonx.data comme base de données vectorielle pour la recherche de similarité.
Pourquoi: Milvus est le magasin de vecteurs intégré de watsonx.data ; conserver les embeddings dans le lakehouse simplifie la gouvernance.
Décider entre Milvus et watsonx Discovery pour la récupération.
Utilisez Milvus pour la similarité vectorielle brute que vous contrôlez ; utilisez watsonx Discovery (basé sur Elasticsearch) pour la recherche d'entreprise gérée avec récupération hybride.
Pourquoi: Milvus est une base de données vectorielle que vous exploitez ; Discovery est un service de recherche de niveau supérieur avec ingestion et classement intégrés.
Préparer des documents afin qu'un modèle de fondation puisse ancrer les réponses sur ceux-ci.
Découpez les documents, générez des embeddings avec un modèle d'embedding watsonx.ai, et indexez-les dans Milvus.
Pourquoi: La qualité de la récupération dépend d'un découpage judicieux et d'un modèle d'embedding correspondant ; des dimensions non concordantes cassent l'index.
Une fonctionnalité d'IA a besoin de données réparties sur plusieurs bases de données et buckets.
Enregistrez les sources dans watsonx.data et interrogez-les sur place via la fédération du moteur.
Pourquoi: La fédération évite la duplication coûteuse des données et maintient un point d'accès unique et gouverné.
L'équipe de gouvernance exige la lignée et le contrôle d'accès sur les données alimentant les modèles.
Cataloguez les ensembles de données dans le catalogue watsonx.data et appliquez l'accès basé sur IAM/politique.
Pourquoi: Un catalogue gouverné est ce qui lie la lignée des données aux fiches descriptives du modèle plus tard - l'accès ad-hoc aux buckets le contourne.
Un projet watsonx.ai doit lire les tables lakehouse sélectionnées pour RAG.
Ajoutez une connexion watsonx.data au projet et référencez les tables comme actifs de données.
Pourquoi: Les connexions exposent les données lakehouse gouvernées au projet d'IA sans exporter de copies.
Une invite Prompt Lab fonctionnelle doit devenir un actif réutilisable et déployable.
Enregistrez-la comme actif de modèle d'invite dans le projet, puis promouvez-la vers un espace de déploiement.
Pourquoi: Les espaces de déploiement sont la frontière de production ; les invites doivent y être promues avant de pouvoir être servies.
Une application a besoin d'un point d'accès d'inférence à faible latence pour une invite ajustée.
Créez un déploiement en ligne dans l'espace de déploiement ; il expose un point d'accès REST de scoring/génération.
Pourquoi: Les déploiements en ligne fournissent un point d'accès synchrone ; les déploiements par lots sont destinés aux tâches de scoring hors ligne.
Appeler un modèle de fondation à partir du code d'une application Python.
Utilisez la classe ModelInference du SDK Python watsonx.ai et appelez generate_text avec vos paramètres.
Pourquoi: ModelInference encapsule l'authentification, l'ID du modèle, le projet/l'espace et les paramètres dans un seul client - plus propre que le REST brut.
Un service non Python doit appeler l'inférence watsonx.ai.
Appelez le point d'accès REST de génération de texte de watsonx.ai avec l'ID du modèle, l'entrée et les paramètres dans le corps JSON.
Pourquoi: L'API REST est indépendante du langage ; le SDK n'est qu'un wrapper sur les mêmes points d'accès.
Authentifier les appels SDK ou API vers watsonx.ai.
Échangez une clé API IBM Cloud IAM contre un jeton bearer, puis appelez le point d'accès avec ce jeton et votre ID de projet/espace.
Pourquoi: watsonx utilise IBM Cloud IAM ; intégrer la clé API brute à chaque appel ou coder en dur les jetons est incorrect et non sécurisé.
Décider où un actif de modèle réside pendant le développement par rapport à la diffusion.
Développez et expérimentez dans un projet ; promouvez l'actif vers un espace de déploiement pour le servir.
Pourquoi: Les projets sont des bacs à sable de développement collaboratifs ; les espaces de déploiement contiennent des actifs promus en production et contrôlés en accès.
Câbler la récupération et la génération dans un seul flux d'application.
Intégrez la requête, récupérez les k-meilleurs fragments de Milvus/Discovery, injectez-les dans le modèle d'invite, puis appelez le modèle déployé.
Pourquoi: L'ordre récupérer-puis-générer est ce qui ancre la réponse ; appeler le modèle en premier annule RAG.
Mapper une charge de travail GenAI à la famille de produits watsonx.
Développez et ajustez dans watsonx.ai, stockez/interrogez les données dans watsonx.data, gouvernez et surveillez dans watsonx.governance.
Pourquoi: Les trois composants sont complémentaires, pas interchangeables - savoir lequel fait quoi est une connaissance essentielle pour l'examen.
L'entreprise a besoin de watsonx sur site pour des raisons de résidence des données.
Déployez watsonx en tant que logiciel sur Cloud Pak for Data (Red Hat OpenShift) plutôt que l'offre SaaS d'IBM Cloud.
Pourquoi: Le SaaS s'exécute dans IBM Cloud ; le facteur de forme logiciel s'exécute dans votre propre cluster OpenShift pour les besoins de résidence/air-gap.
Organiser le travail collaboratif GenAI et ses artefacts.
Utilisez un projet watsonx comme espace de travail qui contient les actifs de données, les notebooks, les invites et les modèles ajustés avec un accès partagé.
Pourquoi: Les projets sont l'unité de collaboration et de portée des actifs ; les espaces de déploiement sont séparés et orientés production.
Contrôler qui peut accéder à quelles instances et actifs watsonx.
Utilisez les comptes IBM Cloud, les groupes de ressources et les politiques/rôles d'accès IAM pour définir la portée de l'accès.
Pourquoi: L'accès dans watsonx est géré par IAM au niveau du compte/groupe de ressources - et non par un partage ad-hoc par actif seulement.
Estimer le coût d'exécution de l'inférence de modèle de fondation.
Tenez compte de la facturation basée sur les jetons pour l'inférence watsonx.ai, plus les moteurs/stockage provisionnés dans watsonx.data.
Pourquoi: Le coût de GenAI est dominé par les jetons d'entrée/sortie ; le calcul du lakehouse et du magasin de vecteurs sont des postes distincts.
Esquisser une architecture RAG de production sur watsonx.
Données Lakehouse → embeddings dans Milvus → récupération + génération watsonx.ai → application, avec surveillance watsonx.governance tout au long.
Pourquoi: Ce flux de bout en bout est le modèle de référence canonique de watsonx que l'examen s'attend à ce que vous reconnaissiez.
Les auditeurs demandent un enregistrement du cycle de vie et de la provenance d'un modèle déployé.
Utilisez les fiches descriptives d'IA de watsonx.governance pour capturer les métadonnées du modèle, la lignée et les approbations tout au long du cycle de vie.
Pourquoi: Les fiches descriptives sont le système d'enregistrement de watsonx pour la provenance des modèles - la réponse documentée à "d'où vient ce modèle".
Les sorties d'un modèle de production se dégradent avec le temps.
Configurez les moniteurs de dérive et de qualité de watsonx.governance avec des seuils et des alertes sur le déploiement.
Pourquoi: La surveillance continue détecte la dérive avant les utilisateurs ; une validation unique ne peut pas détecter la dégradation post-déploiement.
Un modèle doit être vérifié pour un traitement injuste entre les groupes protégés.
Exécutez des évaluations d'équité/biais dans watsonx.governance et documentez l'atténuation dans la fiche descriptive.
Pourquoi: Les obligations d'IA responsable exigent une équité mesurée et enregistrée - et non une simple hypothèse d'équité non mesurée.
L'équipe de conformité a besoin que le système GenAI soit mappé aux réglementations en matière d'IA.
Utilisez watsonx.governance pour suivre les risques, lier les contrôles aux réglementations et maintenir des preuves prêtes pour l'audit.
Pourquoi: La gouvernance lie le risque modèle aux contrôles réglementaires en un seul endroit, ce que les audits et les principes d'IA responsable d'IBM exigent.