Formation et test des modèles
Comprendre comment les modèles de paiement Athia sont entraînés, évalués, mis en service, expérimentés et promus.
Sur cette page
Athia considère un modèle entraîné comme un candidat, et non comme une décision de production. La qualité des données, l'évaluation hors ligne, la compatibilité des artefacts, la préparation au service et les preuves en direct contrôlées doivent être validées avant qu'un modèle ne reçoive un trafic significatif.
Deux systèmes, un cycle de vie#
Athia sépare le développement de modèles hors ligne de l'exécution de modèles en ligne.
| Responsabilité | Pipelines de données et d'entraînement | Plateforme Athia |
|---|---|---|
| Préparer les données d'entraînement | Interroger les données Snowflake gérées, les valider et créer des fonctionnalités spécifiques au modèle | Suivre l'ensemble de données et le contexte d'entraînement exposés avec une version du modèle |
| Entraîner et évaluer | Entraîner des candidats, exécuter des évaluations temporelles ou basées sur des cohortes et empaqueter les artefacts | Enregistrer les versions de modèle et les preuves d'évaluation |
| Tester la compatibilité | Valider les schémas de fonctionnalités, les encodeurs, les métadonnées et les contrats d'artefacts | Vérifier la capacité, la santé et la préparation au service |
| Exécuter des expériences | Produire des artefacts candidats et des métriques attendues | Attribuer un trafic ombragé ou contrôlé, collecter les résultats et comparer les variantes |
| Promouvoir et mettre en service | Reproduire l'entraînement et conserver les preuves | Promouvoir le meilleur, effectuer un rechargement chaud ou le déployer, le surveiller et revenir en arrière si nécessaire |
Le code d'entraînement et les pipelines orientés Snowflake résident dans DATA-Athena-SnowflakeLes contrôles de registre, d'expérimentation, de service et d'exécution résident dans athena-platformCette frontière sépare l'accès aux données d'entraînement des services qui effectuent des prédictions en ligne.
De données gérées à un modèle de production#
Modèles de paiement pris en charge par le cycle de vie#
Le même cycle de vie peut être utilisé pour plusieurs familles de décisions, en fonction de la configuration et de la disponibilité du compte :
Certaines familles de décisions utilisent un seul prédicteur ; d'autres entraînent plusieurs sorties liées ou combinent les preuves de modèle avec des règles d'éligibilité et de sécurité.
Ce qui est testé#
1. Portes de données
Avant de commencer l'entraînement, la pipeline vérifie que la source est utilisable : fraîcheur, volume minimum, champs requis, disponibilité des étiquettes, équilibre de classe et distributions de fonctionnalités. Les divisions temporelles et les vérifications de fuite empêchent que des informations futures n'entrent dans les exemples passés.
2. Qualité du modèle hors ligne
L'évaluation est spécifique à la décision. Elle peut inclure la discrimination, la précision et le rappel, la calibration, la qualité du classement, l'erreur par cohorte et l'effet commercial attendu. Les holdouts temporels montrent si un candidat se généralise au-delà de la période pendant laquelle il a été entraîné.
Les tests de réexécution et de conformité comparent les décisions du modèle avec les résultats historiques ou observés en direct, à condition que les données le permettent. Aucune métrique n'est suffisante pour la promotion.
3. Contrats d'artefacts et de fonctionnalités
Le paquet de modèle comprend l'artefact de modèle ainsi que les métadonnées nécessaires pour reproduire ses entrées et ses sorties. Les tests valident l'ordre et les types de fonctionnalités, les encodeurs, les identificateurs de modèle pris en charge, le schéma de sortie et la compatibilité avec le runtime de service.
4. Préparation au service
Une version enregistrée doit se charger avec succès, exposer des informations sur la santé et la disponibilité, répondre aux requêtes représentatives et respecter les attentes en matière de latence et d'erreurs. La disponibilité est distincte de la qualité du modèle : un candidat qui ne peut pas être mis en œuvre en toute sécurité ne progresse pas.
5. Preuves en direct
Le mode "ombre" enregistre la décision que le modèle aurait prise sans modifier la transaction. Les expériences contrôlées attribuent ensuite une part d'un trafic éligible à un candidat et le comparent à une base de référence. Les "guardrails" surveillent à la fois les résultats des paiements et la santé opérationnelle.
Portails de promotion#
| Portail | Preuves requises |
|---|---|
| Données | Données d'entraînement valides, suffisamment récentes et représentatives |
| Évaluation hors ligne | Seuils spécifiques au modèle, ainsi que le comportement acceptable du groupe et la calibration |
| Contrat | Artefacts reproductibles, métadonnées, schéma de fonctionnalités et tests de charge |
| Déploiement | Déploiement sain avec une latence et un comportement d'erreur acceptables |
| Expérimentation | Preuves contrôlées par rapport à la base de référence active et sans violation des "guardrails" |
| Approbation | Décision de promotion autorisée avec un enregistrement d'audit conservé |
Un modèle promu peut être annulé. Les poids de trafic peuvent être réduits, le modèle précédent peut être restauré, et le mode "ombre" peut être utilisé à nouveau pendant que de nouveaux candidats sont étudiés.
Ce que vous voyez dans Athia#
L'espace de gestion des opérations du modèle regroupe :