Comparez les modèles d'IA ouverts et fermés sans mélanger les questions

Clarifier ce que signifie ouvert pour le candidat

Enregistrez le candidat exact, la version et la voie d'accès proposée. Des poids téléchargeables, une licence permissive et un système d'IA open source complet sont des descriptions différentes. La définition de l'Open Source Initiative comprend des exigences concernant les informations sur les données, le code et les paramètres ; les poids à eux seuls n'établissent pas la conformité à cette définition.

Lisez la licence actuelle du modèle et la documentation de déploiement avant de faire une affirmation sur les droits d’utilisation commerciale ou de modification. Un modèle accessible via un service hébergé est en cours d'évaluation dans les conditions de ce service. Son apparition dans un catalogue ne démontre pas que votre configuration auto-hébergée prévue a été testée.

• Initiative Open Source : Définition de l'IA Open Source 1.0↗

Comparez les réponses dans des conditions visibles et cohérentes

Choisissez une tâche concrète que vous pouvez noter : transformer un document approuvé en une structure requise, répondre à partir du matériel fourni ou extraire des champs spécifiés. Donnez aux candidats disponibles des informations identiques via Ask separately. Enregistrez leurs étiquettes affichées, la date et tous les paramètres visibles pour vous.

Traitez le résultat comme une comparaison des configurations que vous avez réellement utilisées. Les différences dans les outils, le contexte, les instructions système ou la configuration du service peuvent avoir leur importance. N'étiquetez pas un résultat comme une preuve qu'une famille de modèles entière ou tous les modèles ouverts sont supérieurs. Si un candidat requis n'est pas disponible, laissez la comparaison incomplète au lieu de remplacer un modèle sans étiquette.

Exemple : résumer une politique sans inventer d'exception

Tâche fictive : résumer une politique interne de réservation d'équipement. La politique fournie autorise les réservations jusqu'à cinq jours ouvrables et indique que les exceptions nécessitent une approbation. Il ne définit pas qui les approuve. Une réponse utile préserve la limite et marque l'approbateur comme non spécifié. Une réponse amicale qui nomme le chef de service a ajouté un fait.

Exécutez ce cas avec chaque candidat, conservez les sorties et vérifiez les mêmes champs. Évaluez ensuite le déploiement séparément. Le résumé correct d'un candidat ne dit rien sur les ressources nécessaires pour l'héberger ni sur la question de savoir si votre organisation peut utiliser sa licence dans les conditions prévues.

Une invite qui rend visibles les détails non pris en charge

Après avoir vérifié les réponses initiales, demandez une comparaison de leurs différences. Fournissez explicitement la politique d’origine et les résultats étiquetés. Une synthèse doit expliquer quelle formulation est étayée, sans compter combien de modèles répètent le même détail ajouté. Gardez visible une réponse minoritaire correcte.

Résumez cette politique fournie pour les employés : [texte autorisé]. Renvoyez les actions autorisées, les limites, les exceptions et les détails non résolus. Joignez un extrait à l’appui de chaque déclaration de fond. Conservez la distinction entre jours ouvrables et jours calendaires. N’inventez pas de rôles ou de procédures d’approbation. Si la politique omet un détail, indiquez qu'il n'est pas spécifié.

Choisissez un déploiement à piloter, pas une idéologie

Écrivez les conditions dans lesquelles chaque candidat a du sens pour votre produit. Une organisation peut valoriser une voie de déploiement particulière ; un autre peut donner la priorité à un service géré ou à une fonctionnalité requise. Estimez ces compromis en fonction de votre charge de travail et de vos responsabilités plutôt que de traiter l'accès aux poids comme une promesse de coût d'exploitation nul.

Dans Colay, la comparaison initiale utilise les crédits et les limites de votre compte. Cette dépense est distincte d’une future facture d’hébergement ou d’API. Effectuez un petit test du modèle présélectionné dans sa configuration de production prévue, y compris les échecs et le comportement de repli. Conservez la comparaison originale pour indiquer pourquoi elle a obtenu le prochain test.

Questions, réponses