Conjuntos de datos: división del conjunto de datos original
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Todos los buenos proyectos de ingeniería de software dedican una energía considerable a probar sus apps. Del mismo modo, te recomendamos que pruebes tu
modelo de IA para determinar la exactitud de sus predicciones.
Conjuntos de entrenamiento, validación y prueba
Debes probar un modelo con un conjunto de ejemplos diferente de los que se usaron para entrenarlo. Como aprenderás un poco más adelante, realizar pruebas en diferentes ejemplos es una prueba más sólida de la aptitud de tu modelo que realizar pruebas en el mismo conjunto de ejemplos.
¿De dónde obtienes esos diferentes ejemplos? Tradicionalmente, en el aprendizaje automático,
se obtienen esos diferentes ejemplos dividiendo el conjunto de datos original. Por lo tanto, podrías
imaginar que debes dividir el conjunto de datos original en dos subconjuntos:
Supongamos que entrenas en el conjunto de entrenamiento y evalúas en el conjunto de prueba
en varias rondas. En cada ronda, usas los resultados del conjunto de pruebas para guiarte sobre cómo actualizar los hiperparámetros y el conjunto de características. ¿Puedes ver algo erróneo en este enfoque? Elige una sola respuesta.
Realizar varias rondas de este procedimiento podría provocar que el modelo se ajuste de manera implícita a las peculiaridades del conjunto de prueba.
Sí. Cuanto más uses el mismo conjunto de prueba,
más probabilidades habrá de que el modelo se ajuste estrechamente al conjunto de prueba.
Al igual que un profesor que “enseña para la prueba”, el modelo se ajusta, de forma inadvertida, al conjunto de prueba, lo que podría dificultar que se ajuste a los datos del mundo real.
Este enfoque está bien. Después de todo, entrenas con el conjunto de entrenamiento y evalúas con un conjunto de prueba independiente.
En realidad, hay un problema sutil aquí. Piensa en lo que podría salir mal de a poco.
Este enfoque es ineficiente en términos de procesamiento. No cambies
los hiperparámetros ni los conjuntos de atributos después de cada ronda de pruebas.
Las pruebas frecuentes son costosas, pero fundamentales. Sin embargo, las pruebas frecuentes son mucho menos costosas que la capacitación adicional. La optimización de los hiperparámetros y el conjunto de atributos puede mejorar de forma significativa la calidad del modelo, por lo que siempre debes reservar tiempo y recursos computacionales para trabajar en ellos.
Dividir el conjunto de datos en dos conjuntos es una buena idea, pero un mejor enfoque es dividirlo en tres subconjuntos.
Además del conjunto de entrenamiento y el conjunto de prueba, el tercer subconjunto es el siguiente:
Un conjunto de validación realiza las pruebas iniciales en el modelo a medida que se entrena.
Figura 9: Una división mucho mejor.
Usa el conjunto de validación para evaluar los resultados del conjunto de entrenamiento.
Después de que el uso repetido del conjunto de validación sugiera que tu modelo hace buenas predicciones, usa el conjunto de prueba para verificarlo.
En la siguiente figura, se sugiere este flujo de trabajo.
En la figura, “Ajustar modelo” significa ajustar cualquier aspecto del modelo, desde cambiar la tasa de aprendizaje, agregar o quitar atributos, hasta diseñar un modelo completamente nuevo desde cero.
Figura 10: Un buen flujo de trabajo para el desarrollo y las pruebas
El flujo de trabajo que se muestra en la Figura 10 es óptimo, pero incluso con ese flujo de trabajo, los conjuntos de prueba y los conjuntos de validación siguen “desgastándose” con el uso repetido.
Es decir, cuanto más uses los mismos datos para tomar decisiones sobre la configuración de los hiperparámetros o sobre otras mejoras del modelo, menos confianza tendrás en que el modelo haga buenas predicciones sobre datos nuevos.
Por este motivo, es una buena idea recopilar más datos para “actualizar” el conjunto de pruebas y el conjunto de validación. Comenzar de nuevo es un gran restablecimiento.
Ejercicio: Comprueba tu intuición
Reprobaste todos los ejemplos del conjunto de datos y los dividiste en conjuntos de entrenamiento, validación y prueba. Sin embargo, el valor de pérdida en tu conjunto de prueba es tan asombrosamente bajo
que sospechas que se trata de un error. ¿Qué podría haber salido mal?
Muchos de los ejemplos del conjunto de prueba son duplicados de ejemplos del conjunto de entrenamiento.
Sí. Esto puede ser un problema en un conjunto de datos con muchos ejemplos redundantes. Te recomendamos que borres los ejemplos duplicados del conjunto de pruebas antes de realizar la prueba.
El entrenamiento y las pruebas no son deterministas. A veces, por casualidad,
la pérdida de la prueba es increíblemente baja. Vuelve a ejecutar la prueba para confirmar el resultado.
Aunque la pérdida varía un poco en cada ejecución, no debería variar tanto como para que creas que ganaste la lotería del aprendizaje automático.
Por casualidad, el conjunto de prueba contenía ejemplos en los que el
modelo tuvo un buen rendimiento.
Los ejemplos se mezclaron bien, por lo que es muy poco probable que esto suceda.
Problemas adicionales con las prácticas guiadas
Como se ilustra en la pregunta anterior, los ejemplos duplicados pueden afectar la evaluación del modelo.
Después de dividir un conjunto de datos en conjuntos de entrenamiento, validación y prueba, borra los ejemplos del conjunto de validación o de prueba que sean duplicados de los ejemplos del conjunto de entrenamiento. La única prueba justa de un modelo es con ejemplos nuevos, no con duplicados.
Por ejemplo, considera un modelo que predice si un correo electrónico es spam, usando el asunto, el cuerpo del correo electrónico y la dirección de correo electrónico del remitente como atributos.
Supongamos que divides los datos en conjuntos de entrenamiento y de prueba, con una división de 80/20.
Después del entrenamiento, el modelo logra una precisión del 99% en el conjunto de entrenamiento y en el conjunto de prueba. Es probable que esperes una precisión más baja en el conjunto de prueba, por lo que vuelves a mirar los datos y descubres que muchos de los ejemplos del conjunto de prueba son duplicados de ejemplos del conjunto de entrenamiento. El problema es que no limpiaste las entradas duplicadas del mismo correo electrónico de spam de tu base de datos de entrada antes de dividir los datos. Entrenaste con algunos de tus datos de prueba de forma accidental.
En resumen, un buen conjunto de pruebas o de validación cumple con todos los siguientes criterios:
Suficientemente grande para generar resultados de pruebas estadísticamente significativos.
Representativo de todo el conjunto de datos. En otras palabras, no elijas un conjunto de prueba con características diferentes a las del conjunto de entrenamiento.
Representan los datos del mundo real que el modelo encontrará como parte de su propósito comercial.
Cero ejemplos duplicados en el conjunto de entrenamiento.
Ejercicios: Comprueba tu comprensión
Dado un solo conjunto de datos con una cantidad fija de ejemplos,
¿cuál de las siguientes afirmaciones es verdadera?
Cada ejemplo que se usa para probar el modelo es un ejemplo menos que se usa
para entrenarlo.
Dividir los ejemplos en conjuntos de entrenamiento, prueba y validación es un juego de suma cero.
Esta es la compensación central.
La cantidad de ejemplos en el conjunto de prueba debe ser mayor que la cantidad de ejemplos en el conjunto de validación.
En teoría, el conjunto de validación y la prueba deben contener la misma cantidad de ejemplos o casi la misma.
La cantidad de ejemplos del conjunto de prueba debe ser mayor que la cantidad de ejemplos del conjunto de validación o entrenamiento.
La cantidad de ejemplos en el conjunto de entrenamiento suele ser mayor que la cantidad de ejemplos en el conjunto de validación o prueba. Sin embargo, no hay requisitos de porcentaje para los diferentes conjuntos.
Supongamos que tu conjunto de prueba contiene suficientes ejemplos para realizar una prueba con importancia estadística. Además, las pruebas con el conjunto de prueba generan una baja pérdida. Sin embargo, el modelo tuvo un rendimiento deficiente en el mundo real. ¿Qué deberías hacer?
Determina en qué se diferencia el conjunto de datos original de los datos reales.
Sí. Incluso los mejores conjuntos de datos son solo un resumen de datos reales. La verdad fundamental subyacente tiende a cambiar con el tiempo. Aunque tu conjunto de prueba coincidió con tu conjunto de entrenamiento lo suficiente como para sugerir una buena calidad del modelo, es probable que tu conjunto de datos no coincida de manera adecuada con los datos del mundo real.
Es posible que debas volver a entrenar y realizar pruebas en un conjunto de datos nuevo.
Vuelve a realizar la prueba en el mismo conjunto de pruebas. Es posible que los resultados de la prueba sean una anomalía.
Aunque volver a realizar la prueba podría generar resultados ligeramente diferentes, esta táctica probablemente no sea muy útil.
¿Cuántos ejemplos debe contener el conjunto de pruebas?
Suficientes ejemplos para generar una prueba con importancia estadística
[null,null,["Última actualización: 2025-01-03 (UTC)"],[[["\u003cp\u003eMachine learning models should be tested against a separate dataset, called the test set, to ensure accurate predictions on unseen data.\u003c/p\u003e\n"],["\u003cp\u003eIt's recommended to split the dataset into three subsets: training, validation, and test sets, with the validation set used for initial testing during training and the test set used for final evaluation.\u003c/p\u003e\n"],["\u003cp\u003eThe validation and test sets can "wear out" with repeated use, requiring fresh data to maintain reliable evaluation results.\u003c/p\u003e\n"],["\u003cp\u003eA good test set is statistically significant, representative of the dataset and real-world data, and contains no duplicates from the training set.\u003c/p\u003e\n"],["\u003cp\u003eIt's crucial to address discrepancies between the dataset used for training and testing and the real-world data the model will encounter to achieve satisfactory real-world performance.\u003c/p\u003e\n"]]],[],null,["# Datasets: Dividing the original dataset\n\nAll good software engineering projects devote considerable energy to\n*testing* their apps. Similarly, we strongly recommend testing your\nML model to determine the correctness of its predictions.\n\nTraining, validation, and test sets\n-----------------------------------\n\nYou should test a model against a *different* set of examples than those\nused to train the model. As you'll learn\n[a little later](#additional_problems_with_test_sets), testing\non different examples is stronger proof of your model's fitness than testing\non the same set of examples.\nWhere do you get those different examples? Traditionally in machine learning,\nyou get those different examples by splitting the original dataset. You might\nassume, therefore, that you should split the original dataset into two subsets:\n\n- A [**training set**](/machine-learning/glossary#training-set) that the model trains on.\n- A [**test set**](/machine-learning/glossary#test-set) for evaluation of the trained model.\n\n**Figure 8.** Not an optimal split.\n\n### Exercise: Check your intuition\n\nSuppose you train on the training set and evaluate on the test set over multiple rounds. In each round, you use the test set results to guide how to update hyperparameters and the feature set. Can you see anything wrong with this approach? Pick only one answer. \nDoing many rounds of this procedure might cause the model to implicitly fit the peculiarities of the test set. \nYes! The more often you use the same test set, the more likely the model closely fits the test set. Like a teacher \"teaching to the test,\" the model inadvertently fits the test set, which might make it harder for the model to fit real-world data. \nThis approach is fine. After all, you're training on the training set and evaluating on a separate test set. \nActually, there's a subtle issue here. Think about what might gradually go wrong. \nThis approach is computationally inefficient. Don't change hyperparameters or feature sets after each round of testing. \nFrequent testing is expensive but critical. However, frequent testing is far less expensive than additional training. Optimizing hyperparameters and the feature set can dramatically improve model quality, so always budget time and computational resources to work on these.\n\nDividing the dataset into two sets is a decent idea, but\na better approach is to divide the dataset into *three* subsets.\nIn addition to the training set and the test set, the third subset is:\n\n- A [**validation set**](/machine-learning/glossary#validation-set) performs the initial testing on the model as it is being trained.\n\n**Figure 9.** A much better split.\n\nUse the **validation set** to evaluate results from the training set.\nAfter repeated use of the validation set suggests that your model is\nmaking good predictions, use the test set to double-check your model.\n\nThe following figure suggests this workflow.\nIn the figure, \"Tweak model\" means adjusting anything about the model\n---from changing the learning rate, to adding or removing\nfeatures, to designing a completely new model from scratch.\n**Figure 10.** A good workflow for development and testing. **Note:** When you transform a feature in your training set, you must make the *same* transformation in the validation set, test set, and real-world dataset.\n\nThe workflow shown in Figure 10 is optimal, but even with that workflow,\ntest sets and validation sets still \"wear out\" with repeated use.\nThat is, the more you use the same data to make decisions about\nhyperparameter settings or other model improvements, the less confidence\nthat the model will make good predictions on new data.\nFor this reason, it's a good idea to collect more data to \"refresh\" the test\nset and validation set. Starting anew is a great reset.\n\n### Exercise: Check your intuition\n\nYou shuffled all the examples in the dataset and divided the shuffled examples into training, validation, and test sets. However, the loss value on your test set is so staggeringly low that you suspect a mistake. What might have gone wrong? \nMany of the examples in the test set are duplicates of examples in the training set. \nYes. This can be a problem in a dataset with a lot of redundant examples. We strongly recommend deleting duplicate examples from the test set before testing. \nTraining and testing are nondeterministic. Sometimes, by chance, your test loss is incredibly low. Rerun the test to confirm the result. \nAlthough loss does vary a little on each run, it shouldn't vary so much that you think you won the machine learning lottery. \nBy chance, the test set just happened to contain examples that the model performed well on. \nThe examples were well shuffled, so this is extremely unlikely.\n\nAdditional problems with test sets\n----------------------------------\n\nAs the previous question illustrates, duplicate examples can affect model evaluation.\nAfter splitting a dataset into training, validation, and test sets,\ndelete any examples in the validation set or test set that are duplicates of\nexamples in the training set. The only fair test of a model is against\nnew examples, not duplicates.\n\nFor example, consider a model that predicts whether an email is spam, using\nthe subject line, email body, and sender's email address as features.\nSuppose you divide the data into training and test sets, with an 80-20 split.\nAfter training, the model achieves 99% precision on both the training set and\nthe test set. You'd probably expect a lower precision on the test set, so you\ntake another look at the data and discover that many of the examples in the test\nset are duplicates of examples in the training set. The problem is that you\nneglected to scrub duplicate entries for the same spam email from your input\ndatabase before splitting the data. You've inadvertently trained on some of\nyour test data.\n\nIn summary, a good test set or validation set meets all of the\nfollowing criteria:\n\n- Large enough to yield statistically significant testing results.\n- Representative of the dataset as a whole. In other words, don't pick a test set with different characteristics than the training set.\n- Representative of the real-world data that the model will encounter as part of its business purpose.\n- Zero examples duplicated in the training set.\n\n### Exercises: Check your understanding\n\nGiven a single dataset with a fixed number of examples, which of the following statements is true? \nEvery example used in testing the model is one less example used in training the model. \nDividing examples into train/test/validation sets is a zero-sum game. This is the central trade-off. \nThe number of examples in the test set must be greater than the number of examples in the validation set. \nIn theory, the validation set and test test should contain the same number of examples or nearly so. \nThe number of examples in the test set must be greater than the number of examples in the validation set or training set. \nThe number of examples in the training set is usually greater than the number of examples in the validation set or test set; however, there are no percentage requirements for the different sets. \nSuppose your test set contains enough examples to perform a statistically significant test. Furthermore, testing against the test set yields low loss. However, the model performed poorly in the real world. What should you do? \nDetermine how the original dataset differs from real-life data. \nYes. Even the best datasets are only a snapshot of real-life data; the underlying [ground truth](/machine-learning/glossary#ground-truth) tends to change over time. Although your test set matched your training set well enough to suggest good model quality, your dataset probably doesn't adequately match real-world data. You might have to retrain and retest against a new dataset. \nRetest on the same test set. The test results might have been an anomaly. \nAlthough retesting might yield slightly different results, this tactic probably isn't very helpful. \nHow many examples should the test set contain? \nEnough examples to yield a statistically significant test. \nYes. How many examples is that? You'll need to experiment. \nAt least 15% of the original dataset. \n15% may or may not be enough examples.\n| **Key terms:**\n|\n| - [Test set](/machine-learning/glossary#test-set)\n| - [Training set](/machine-learning/glossary#training-set)\n- [Validation set](/machine-learning/glossary#validation_set) \n[Help Center](https://support.google.com/machinelearningeducation)"]]