Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.
Gli esperimenti contribuiscono alla fattibilità di un progetto. Si tratta di ipotesi verificabili e riproducibili. Quando esegui esperimenti, l'obiettivo è apportare miglioramenti continui e incrementali valutando una serie di funzionalità e architetture del modello. Quando esegui esperimenti, ti consigliamo di procedere come segue:
Determina il rendimento di riferimento. Per iniziare, stabilisci una metrica di riferimento. La base di riferimento funge da metro di misura per confrontare gli esperimenti.
In alcuni casi, l'attuale soluzione non ML può fornire la prima metrica di riferimento. Se al momento non esiste una soluzione, crea un modello di ML con un'architettura semplice, alcune funzionalità e utilizza le relative metriche come linea di base.
Apporta piccole modifiche singole. Apporta una sola piccola modifica alla volta, ad esempio agli iperparametri, all'architettura o alle funzionalità. Se la modifica migliora il modello, le metriche del modello diventano la nuova linea di base rispetto alla quale confrontare gli esperimenti futuri.
Di seguito sono riportati alcuni esempi di esperimenti che apportano una singola piccola modifica:
includono la funzionalità X.
Utilizza un tasso di dropout di 0,5 nel primo livello nascosto.
esegui la trasformazione logaritmica della funzionalità Y.
imposta il tasso di apprendimento su 0,001.
Registra l'avanzamento degli esperimenti. Molto probabilmente dovrai fare molti esperimenti. Gli esperimenti con una qualità di previsione scarsa (o neutra) rispetto al valore di riferimento sono comunque utili da monitorare. Indicano quali approcci non funzioneranno. Poiché i progressi sono in genere non lineari, è importante mostrare che stai lavorando al problema evidenziando tutti i metodi che hai trovato non funzionanti, oltre ai tuoi progressi nell'aumento della qualità di riferimento.
Poiché ogni addestramento completo su un set di dati reale può richiedere ore (o giorni), valuta la possibilità di eseguire contemporaneamente più esperimenti indipendenti per esplorare rapidamente lo spazio. Man mano che continui a eseguire l'iterazione, dovresti avvicinarti sempre più al livello di qualità necessario per la produzione.
Rumore nei risultati sperimentali
Tieni presente che potresti riscontrare rumore nei risultati sperimentali che non provengono da modifiche al modello o ai dati, il che rende difficile determinare se una modifica apportata ha effettivamente migliorato il modello. Di seguito sono riportati alcuni esempi di elementi che possono produrre rumore nei risultati sperimentali:
Shuffling dei dati: l'ordine in cui i dati vengono presentati al modello può influire sul rendimento del modello.
Inizializzazione delle variabili: il modo in cui vengono inizializzate le variabili del modello può influire anche sul suo rendimento.
Parallelismo asincrono: se il modello viene addestrato utilizzando il parallelismo asincrono, anche l'ordine in cui vengono aggiornate le diverse parti del modello può influire sulle sue prestazioni.
Set di valutazione piccoli: se il set di valutazione è troppo piccolo, potrebbe non essere rappresentativo delle prestazioni complessive del modello, producendo variazioni non uniformi della qualità del modello.
L'esecuzione di un esperimento più volte consente di confermare i risultati sperimentali.
Allineamento alle pratiche di sperimentazione
Il tuo team deve avere una comprensione chiara di cosa sia esattamente un "esperimento", con un insieme definito di pratiche e artefatti. Ti consigliamo di fornire una documentazione che illustri quanto segue:
Artefatti. Che cosa sono gli elementi di un esperimento? Nella maggior parte dei casi, un esperimento è un'ipotesi testata che può essere riprodotta, in genere registrando i metadati (come le funzionalità e gli iperparametri) che indicano le variazioni tra gli esperimenti e il modo in cui influiscono sulla qualità del modello.
Pratiche di codifica. Tutti utilizzeranno i propri ambienti sperimentali? Quanto sarà possibile (o facile) unificare il lavoro di tutti in librerie condivise?
Riproducibilità e monitoraggio. Quali sono gli standard per la riproducibilità? Ad esempio, il team deve utilizzare la stessa pipeline di dati e le stesse pratiche di gestione delle versioni o è sufficiente mostrare solo i grafici? Come verranno salvati i dati sperimentali: come query SQL o come istantanee del modello? Dove verranno documentati i log di ogni esperimento: in un documento, in un foglio di lavoro o in un CMS per la gestione degli esperimenti?
Previsioni sbagliate
Nessun modello reale è perfetto. In che modo il sistema gestirà le previsioni sbagliate? Inizia a pensare in anticipo a come gestirli.
Una strategia di best practice incoraggia gli utenti a etichettare correttamente le previsioni sbagliate. Ad esempio, le app di posta acquisiscono le email classificate erroneamente registrando la posta che gli utenti muovono nella cartella Spam e viceversa. Acquisendo le etichette basate su dati empirici reali dagli utenti, puoi progettare loop di feedback automatici per la raccolta dei dati e la ricollocazione dei modelli.
Tieni presente che, sebbene i sondaggi incorporati nell'interfaccia utente acquisiscano il feedback degli utenti, i dati sono tipicamente qualitativi e non possono essere incorporati nei dati di ricollocazione.
Implementare una soluzione end-to-end
Mentre il team esegue esperimenti sul modello, è buona norma iniziare a sviluppare parti della pipeline finale (se disponi delle risorse necessarie).
Stabilire componenti diversi della pipeline, come l'importazione dei dati e il retraining del modello, semplifica il trasferimento del modello finale in produzione. Ad esempio, disporre di una pipeline end-to-end per l'importazione dei dati e la pubblicazione delle previsioni può aiutare il team a iniziare a integrare il modello nel prodotto e a iniziare a eseguire test utente nelle prime fasi.
Risolvere i problemi relativi ai progetti in stallo
Potresti trovarti in scenari in cui l'avanzamento di un progetto si blocca. Forse il tuo team sta lavorando a un esperimento promettente, ma non riesce a migliorare il modello da settimane. Cosa dovresti fare? Di seguito sono riportati alcuni possibili approcci:
Strategiche. Potresti dover riformulare il problema. Dopo aver trascorso del tempo nella fase di sperimentazione, probabilmente comprendi meglio il problema, i dati e le possibili soluzioni. Con una conoscenza più approfondita del dominio, probabilmente puoi definire il problema in modo più preciso.
Ad esempio, inizialmente potresti voler utilizzare la regressione lineare per predire un valore numerico. Purtroppo, i dati non erano sufficientemente buoni per addestrare un modello di regressione lineare valido. Forse un'ulteriore analisi rivela che il problema può essere risolto prevedendo se un esempio è superiore o inferiore a un valore specifico. In questo modo puoi riformulare il problema come un problema di classificazione binaria.
Se i progressi sono più lenti del previsto, non mollare. I miglioramenti incrementali nel tempo potrebbero essere l'unico modo per risolvere il problema. Come accennato in precedenza, non aspettarti lo stesso livello di avanzamento settimana dopo settimana. Spesso, ottenere una versione di un modello pronta per la produzione richiede molto tempo. Il miglioramento del modello può essere irregolare e imprevedibile. I periodi di avanzamento lento possono essere seguiti da picchi di miglioramento o viceversa.
Tecnico. Devi dedicare tempo alla diagnosi e all'analisi delle previsioni sbagliate. In alcuni casi, puoi trovare il problema isolando alcune previsioni sbagliate e diagnosticando il comportamento del modello in queste istanze. Ad esempio, potresti scoprire problemi con l'architettura o i dati. In altri casi, la raccolta di ulteriori dati può essere utile. Potresti ricevere un segnale più chiaro che ti suggerisca di essere sulla strada giusta oppure potrebbe produrre più rumore, indicando la presenza di altri problemi nell'approccio.
Se stai lavorando a un problema che richiede set di dati etichettati da persone, potrebbe essere difficile ottenere un set di dati etichettato per la valutazione del modello. Trova risorse per ottenere i set di dati di cui hai bisogno per la valutazione.
È possibile che non sia possibile trovare una soluzione. Definisci un periodo di tempo per il tuo approccio e fermati se non hai compiuto progressi entro il periodo di tempo stabilito. Tuttavia, se hai una dichiarazione del problema chiara, probabilmente merita una soluzione.
Verifica di aver compreso
Un membro del team ha trovato una combinazione di iperparametri che migliora la metrica del modello di riferimento. Cosa devono fare gli altri membri del team?
Potrebbe incorporare un iperparametro, ma continuare con i suoi esperimenti.
risposta esatta. Se uno dei suoi iperparametri sembra una scelta ragionevole, provalo. Tuttavia, non tutte le scelte degli iperparametri hanno senso in ogni contesto sperimentale.
Modificare tutti gli iperparametri nell'esperimento corrente in modo che corrispondano a quelli del collega.
Gli iperparametri che hanno migliorato un modello non miglioreranno necessariamente anche un altro modello. Gli altri membri del team devono continuare con i loro esperimenti, che potrebbero effettivamente migliorare il valore di riferimento in un secondo momento.
Inizia a creare una pipeline end-to-end che verrà utilizzata per implementare il modello.
Un modello che migliora la linea di base non significa che sia il modello che verrà utilizzato in produzione. Dovrebbero continuare con i loro esperimenti, che potrebbero effettivamente migliorare il valore di riferimento anche in un secondo momento.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Mancano le informazioni di cui ho bisogno","missingTheInformationINeed","thumb-down"],["Troppo complicato/troppi passaggi","tooComplicatedTooManySteps","thumb-down"],["Obsoleti","outOfDate","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Problema relativo a esempi/codice","samplesCodeIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-07-27 UTC."],[[["\u003cp\u003eExperiments involve making single, small, iterative changes to model features, architecture, or hyperparameters to improve performance compared to a baseline.\u003c/p\u003e\n"],["\u003cp\u003eIt's crucial to track all experimental results, including unsuccessful ones, to understand which approaches work and which don't.\u003c/p\u003e\n"],["\u003cp\u003eTeams should establish clear experimentation practices, including defining artifacts, coding standards, reproducibility measures, and tracking methods.\u003c/p\u003e\n"],["\u003cp\u003ePlan for handling wrong predictions early on, potentially by incorporating user feedback for model improvement.\u003c/p\u003e\n"],["\u003cp\u003eConsider building parts of the final pipeline alongside experimentation to facilitate a smoother transition to production.\u003c/p\u003e\n"]]],[],null,["# Experiments drive a project toward viability. They are testable and\nreproducible hypotheses. When running experiments, the\ngoal is to make continual, incremental improvements by evaluating a variety of\nmodel architectures and features. When experimenting, you'll want to do\nthe following:\n\n- **Determine baseline performance.** Start by establishing a\n [baseline](/machine-learning/glossary#baseline) metric. The baseline\n acts as a measuring stick to compare experiments against.\n\n In some cases, the current non-ML solution can provide the first baseline\n metric. If no solution currently exists, create a ML model with a simple\n architecture, a few features, and use its metrics as the baseline.\n- **Make single, small changes.** Make only a single, small change at a time,\n for example, to the hyperparameters, architecture, or features. If the\n change improves the model, that model's metrics become the new baseline to\n compare future experiments against.\n\n The following are examples of experiments that make a single, small change:\n - include feature *X*.\n - use 0.5 dropout on the first hidden layer.\n - take the log transform of feature *Y*.\n - change the learning rate to 0.001.\n- **Record the progress of the experiments.** You'll most likely need to do\n lots of experiments. Experiments with poor (or neutral) prediction quality\n compared to the baseline are still useful to track. They signal which\n approaches won't work. Because progress is typically non-linear, it's\n important to show that you're working on the problem by highlighting all\n the ways you found that don't work---in addition to your progress at\n increasing the baseline quality.\n\nBecause each full training on a real-world dataset can take hours (or days),\nconsider running multiple independent experiments concurrently to explore the\nspace quickly. As you continue to iterate, you'll hopefully get closer and\ncloser to the level of quality you'll need for production.\n\n### Noise in experimental results\n\nNote that you might encounter noise in experimental results that aren't from\nchanges to the model or the data, making it difficult to determine if a change\nyou made actually improved the model. The following are examples of things that\ncan produce noise in experimental results:\n\n- Data shuffling: The order in which the data is presented to the model can\n affect the model's performance.\n\n- Variable initialization: The way in which the model's\n variables are initialized can also affect its performance.\n\n- Asynchronous parallelism: If the model is trained using asynchronous\n parallelism, the order in which the different parts of the model are updated\n can also affect its performance.\n\n- Small evaluation sets: If the evaluation set is too small, it may\n not be representative of the overall performance of the model, producing\n uneven variations in the model's quality.\n\nRunning an experiment multiple times helps confirm experimental results.\n\n### Align on experimentation practices\n\nYour team should have a clear understanding of what exactly an \"experiment\" is,\nwith a defined set of practices and artifacts. You'll want documentation that\noutlines the following:\n\n- **Artifacts.** What are the artifacts for an experiment? In most cases, an\n experiment is a tested hypothesis that can be reproduced, typically by\n logging the metadata (like the features and hyperparameters) that indicate\n the changes between experiments and how they affect model quality.\n\n- **Coding practices.** Will everyone use their own experimental environments?\n How possible (or easy) will it be to unify everyone's work into shared\n libraries?\n\n- **Reproducibility and tracking.** What are the standards for\n reproducibility? For instance, should the team use the same data pipeline\n and versioning practices, or is it OK to show only plots? How will\n experimental data be saved: as SQL queries or as model snapshots? Where will\n the logs from each experiment be documented: in a doc, a spreadsheet, or a\n CMS for managing experiments?\n\nWrong predictions\n-----------------\n\nNo real-world model is perfect. How will your system handle wrong predictions?\nBegin thinking early on about how to deal with them.\n\nA best-practices strategy encourages users to correctly label wrong predictions.\nFor example, mail apps capture misclassified email by logging the mail users\nmove into their spam folder, as well as the reverse. By capturing ground truth\nlabels from users, you can design automated feedback loops for data collection\nand model retraining.\n\nNote that although UI-embedded surveys capture user feedback, the data is\ntypically qualitative and can't be incorporated into the retraining data.\n\nImplement an end-to-end solution\n--------------------------------\n\nWhile your team is experimenting on the model, it's a good idea to start\nbuilding out parts of the final pipeline (if you have the resources to do so).\n\nEstablishing different pieces of the pipeline---like data intake and model\nretraining---makes it easier to move the final model to production. For\nexample, getting an end-to-end pipeline for ingesting data and serving\npredictions can help the team start integrating the model into the product and\nto begin conducting early-stage user testing.\n\nTroubleshooting stalled projects\n--------------------------------\n\nYou might be in scenarios where a project's progress stalls. Maybe your\nteam has been working on a promising experiment but hasn't had success\nimproving the model for weeks. What should you do? The following are some\npossible approaches:\n\n- **Strategic.** You might need to reframe the problem. After spending time in\n the experimentation phase, you probably understand the problem, the data,\n and the possible solutions better. With a deeper knowledge of the domain,\n you can probably frame the problem more precisely.\n\n For instance, maybe you initially wanted to use linear regression to predict\n a numeric value. Unfortunately, the data wasn't good enough to train a\n viable linear regression model. Maybe further analysis reveals the problem\n can be solved by predicting whether an example is above or below a specific\n value. This lets you reframe the problem as a binary classification one.\n\n If progress is slower than expected, don't give up. Incremental improvements\n over time might be the only way to solve the problem. As noted earlier,\n don't expect the same amount of progress week over week. Often, getting a\n production-ready version of a model requires substantial amounts of time.\n Model improvement can be irregular and unpredictable. Periods of slow\n progress can be followed by spikes in improvement, or the reverse.\n- **Technical.** Spend time diagnosing and analyzing wrong predictions. In\n some cases, you can find the issue by isolating a few wrong predictions and\n diagnosing the model's behavior in those instances. For example, you might\n uncover problems with the architecture or the data. In other cases,\n getting more data can help. You might get a clearer signal that suggests\n you're on the right path, or it might produce more noise, indicating other\n issues exist in the approach.\n\n If you're working on a problem that requires human-labeled datasets,\n getting a labeled dataset for model evaluation might be hard to obtain. Find\n resources to get the datasets you'll need for evaluation.\n\nMaybe no solution is possible. Time-box your approach, stopping if you haven't\nmade progress within the timeframe. However, if you have a strong problem\nstatement, then it probably warrants a solution.\n\n### Check Your Understanding\n\nA team member found a combination of hyperparameters that improves the baseline model metric. What should the other members of the team do? \nMaybe incorporate one hyperparameter, but continue with their experiments. \nCorrect. If one of their hyperparameters seems like a reasonable choice, try it. However, not all hyperparameter choices make sense in every experimental context. \nChange all their hyperparameters in their current experiment to match their co-worker's. \nHyperparameters that improved one model doesn't mean they'll also improve a different model. The other teammates should continue with their experiments, which might actually improve the baseline even more later on. \nStart building an end-to-end pipeline that will be used to implement the model. \nA model that improves the baseline doesn't mean it's the model that will ultimately be used in production. They should continue with their experiments, which might actually improve the baseline even more later on.\n| **Key Terms:**\n|\n| - [baseline](/machine-learning/glossary#baseline)"]]
