Machine Learning Fundamentals
Aprender una relación a partir de evidencia
Machine Learning es un conjunto de enfoques que ajustan modelos a partir de datos o experiencia para realizar tareas, en lugar de especificar manualmente todas las reglas que relacionan cada entrada con su resultado. El aprendizaje necesita una tarea, evidencia y un criterio de mejora. No elimina el software programado: preparación de datos, ejecución, interfaces y decisiones alrededor del modelo siguen teniendo contratos de ingeniería.
Un equipo puede escribir una regla exacta para validar un formato conocido. Puede también entrenar un modelo para estimar una categoría a partir de descripciones cuya variedad hace difícil enumerar todas las expresiones. Elegir ML no garantiza resolver mejor el problema. Conviene preguntar qué relación se desea aprender, si existe evidencia pertinente y qué errores serían aceptables o perjudiciales.
AI es más amplia que ML: puede incluir búsqueda, planificación y sistemas basados en reglas, entre otros enfoques. ML no equivale a AI generativa ni a modelos de lenguaje. Predicción de cantidades, clasificación, agrupamiento y aprendizaje de representaciones son tareas posibles que no necesitan producir texto. LLM Fundamentals desarrolla una familia importante, sin convertirla en la definición de todo aprendizaje.
La contribución del aprendizaje no reside en que el programa cambie mágicamente mientras se utiliza. Muchos sistemas entrenan una versión y mantienen sus parámetros fijos durante la inferencia. Otros incorporan actualizaciones bajo un procedimiento explícito. La capacidad de guardar datos, recordar contexto o recibir feedback no demuestra por sí sola que se estén ajustando parámetros.
Datos, ejemplos y representaciones
Los datos aportan observaciones o experiencias utilizadas para ajustar y examinar el modelo. Un ejemplo puede combinar una entrada con un resultado objetivo, una secuencia sin etiqueta externa o una interacción con consecuencias. Qué constituye un ejemplo depende de la tarea. Una fila de una tabla no es una unidad universal de aprendizaje: una conversación, una imagen o una secuencia temporal pueden necesitar otra representación.
Las features o características son aspectos utilizados para representar la entrada: cantidades, categorías, indicadores, fragmentos de texto o vectores aprendidos. No son hechos automáticamente suficientes sobre el mundo. Una feature ausente puede hacer imposible distinguir dos situaciones que requieren respuestas diferentes. Una feature construida después del resultado puede introducir información que no estará disponible al decidir.
Las etiquetas expresan un objetivo de aprendizaje cuando corresponde. Pueden contener errores, desacuerdo o políticas históricas que ya no representan la necesidad actual. Entrenar con ellas puede reproducir esas limitaciones con gran consistencia. Mejorar el ajuste a una etiqueta no demuestra que la organización haya elegido correctamente qué quiere predecir.
La representación también determina qué regularidades resultan accesibles. Dos entradas comercialmente distintas pueden quedar representadas de la misma forma si se descarta una variable relevante. Un identificador arbitrario puede producir correlaciones accidentales en un conjunto pequeño. Embeddings desarrolla representaciones vectoriales; no toda representación necesita ser un embedding ni toda tarea necesita una red neuronal.
Modelo, parámetros y objetivo
Un modelo define una familia de relaciones entre entradas y salidas. Sus parámetros ajustables permiten seleccionar una instancia dentro de esa familia. En una relación lineal pueden ser coeficientes; en una red, pesos y otros valores entrenables. El modelo aprendido incluye esos valores junto con estructura y configuración pertinentes; el nombre del algoritmo por sí solo no identifica una versión utilizable.
Una función de pérdida, o loss, expresa cómo se penalizan ciertas diferencias entre predicción y objetivo. El objetivo de entrenamiento puede combinar esa pérdida con otras condiciones. Minimizarlo es una operación sobre una formulación concreta del problema. Si esa formulación omite una consecuencia importante, optimizarla con éxito no añade por sí mismo la intención faltante.
La métrica de interés para el producto puede diferir de la loss. Un objetivo diferenciable puede facilitar entrenamiento, mientras el equipo observa errores específicos o utilidad sobre casos representativos. Conviene conocer esa relación en lugar de interpretar cualquier reducción numérica como mejora del sistema completo. El costo de falsos positivos y falsos negativos puede ser asimétrico.
Los hiperparámetros configuran aspectos del modelo o del procedimiento de ajuste, como regularización, tamaño de ciertos componentes o ritmo de actualización. Se distinguen de los parámetros aprendidos dentro del proceso considerado. La frontera depende del nivel de optimización: una búsqueda externa puede ajustar una configuración que otro procedimiento trata como fija. No es una clasificación universal basada solo en el nombre de una variable.
Training, validation, test e inference
Training ajusta parámetros o comportamiento a partir de datos y un objetivo. Inference utiliza un modelo entrenado para producir resultados ante entradas. El término inferencia aquí no significa deducción lógica formal ni garantía de que una conclusión sea verdadera. Un sistema puede estimar un resultado plausible y equivocarse respecto del caso concreto.
Validation o development ayuda a elegir variantes, configuraciones y condiciones de detención durante el desarrollo. Test intenta aportar una estimación final sobre evidencia separada de esas decisiones. Son roles de los datos, no extensiones de archivo ni porcentajes universales. Si se utiliza repetidamente el supuesto test para seleccionar cambios, su independencia práctica se deteriora aunque conserve el mismo nombre.
Una evaluación de ML y una suite convencional no son equivalentes. Las pruebas de software pueden comprobar parsing, dimensiones, contratos y condiciones conocidas. Un conjunto de ejemplos de evaluación puede estimar comportamiento sobre una población relevante. Ambas evidencias pueden coexistir. Tener una partición llamada test no reemplaza comprobar que el servicio carga el modelo correcto o que interpreta sus salidas según contrato.
Durante inferencia suele ejecutarse una transformación con parámetros ya fijados. Agregar información al contexto de un modelo no implica reentrenarlo. Un mecanismo que actualiza parámetros durante uso debe especificar cómo, con qué datos y bajo qué controles. No conviene deducir aprendizaje continuo a partir de que una aplicación personalice su respuesta o conserve un historial.
Generalización frente a ajuste observado
Generalización es desempeño sobre ejemplos o tareas relevantes que no fueron utilizados de la misma manera para ajustar el modelo. No equivale a responder cualquier pregunta nunca vista. Su significado depende de qué población, condiciones y tarea se consideran pertinentes. Un resultado útil en una distribución puede no mantenerse al cambiar idioma, canal de entrada o proceso comercial.
El capítulo Machine Learning Basics de Goodfellow, Bengio y Courville distingue el problema de optimizar sobre entrenamiento del de funcionar bien sobre nuevas entradas. Es una referencia académica para esta separación. Un bajo error en entrenamiento no basta para demostrar generalización; la evidencia nueva necesita representar razonablemente el uso que se pretende sostener.
Una correlación aprendida puede dejar de ser útil cuando cambia la situación. Si un modelo identifica incidencias urgentes por el nombre del equipo que antes las atendía, puede funcionar mientras esa asignación siga estable y fallar después de una reorganización. El desempeño observado no explica automáticamente qué relación causal se aprendió ni garantiza que todas las regularidades sean apropiadas para decidir.
La evidencia de generalización tiene incertidumbre. Un conjunto finito puede omitir casos raros o condiciones difíciles. Evaluar únicamente ejemplos cómodos produce una impresión favorable sin sostener el alcance pretendido. Reconocer ese límite no exige materializar aquí Evaluation Datasets o Monitoring; basta distinguir lo observado de la promesa más amplia.
Overfitting y underfitting
Overfitting ocurre cuando el ajuste se adapta demasiado a particularidades de la evidencia utilizada respecto de la generalización deseada. Puede aprender ruido, asociaciones accidentales o detalles de una partición. No se define simplemente porque el modelo tenga muchos parámetros. La cantidad y calidad de datos, la regularización, el procedimiento y el problema afectan esa relación.
Underfitting describe un ajuste insuficiente para la relación que se intenta capturar. Puede haber una representación limitada, capacidad inadecuada, entrenamiento insuficiente o una formulación incapaz de representar el objetivo. Aumentar tamaño no es una solución universal: si falta una variable esencial o las etiquetas son contradictorias, otra arquitectura puede conservar el mismo límite de evidencia.
Comparar comportamiento sobre entrenamiento y evidencia separada ayuda a formular hipótesis, sin convertir una forma particular de curva en diagnóstico infalible. Un resultado malo en ambas partes puede requerir revisar datos u objetivo, no solo ejecutar más iteraciones. Una diferencia amplia puede necesitar examinar fuga de información, particiones o condiciones distintas, además del ajuste.
La complejidad adecuada es contextual. Un modelo sencillo puede ser una base útil para entender qué evidencia aporta realmente una alternativa más costosa. Un sistema más expresivo puede captar relaciones necesarias que una regla rígida no representa. No existe una escala donde más complejidad, más datos o más entrenamiento aseguren por separado mejor ingeniería.
Paradigmas de aprendizaje
En aprendizaje supervisado se utilizan ejemplos con objetivos o etiquetas para ajustar una relación. Predecir una cantidad y clasificar una entrada son posibilidades distintas. La calidad del aprendizaje depende también de qué significa la etiqueta y de cuándo está disponible. Un resultado inferido por una persona no es una verdad incuestionable por haberse almacenado como target.
El aprendizaje no supervisado busca estructura sin el mismo tipo de objetivo externo por ejemplo. Agrupar observaciones o reducir una representación puede ayudar a explorar datos, pero encontrar un grupo no demuestra que corresponda a una categoría útil del negocio. La interpretación y el uso de ese resultado conservan decisiones humanas y técnicas propias.
Self-supervised learning construye señales de aprendizaje a partir de los propios datos, como predecir parte de una secuencia desde otra parte. No significa aprendizaje sin objetivo, sin diseño o sin intervención humana. El procedimiento especifica qué se oculta, predice o contrasta; esas elecciones condicionan las representaciones que se favorecen.
Reinforcement learning estudia aprendizaje mediante interacción, acciones y señales de recompensa relacionadas con consecuencias. No equivale a cualquier feedback ni a volver a ejecutar un test fallido. La señal puede ser incompleta respecto del propósito y las decisiones pueden tener efectos diferidos. Estas familias orientan la lectura; no son necesariamente exhaustivas ni mutuamente excluyentes en todo sistema de investigación.
Particiones, fuga de información y alcance
Separar conjuntos necesita respetar la unidad de independencia importante para la tarea. Si versiones del mismo documento aparecen en entrenamiento y test, el resultado puede medir reconocimiento de material muy cercano en lugar de generalización buscada. Una partición aleatoria tampoco responde siempre a una pregunta temporal sobre datos que solo llegarán después.
Data leakage introduce información en desarrollo o evaluación que no corresponde al escenario pretendido. Puede provenir de features calculadas con datos futuros, duplicados entre particiones o decisiones tomadas después de examinar resultados reservados. No exige una copia literal del target. También importa si el proceso de preparación utiliza información de todo el conjunto antes de separarlo.
No hay un porcentaje de split que resuelva automáticamente esas condiciones. El tamaño disponible, la variación y el objetivo pueden justificar protocolos diferentes. Lo importante es poder explicar qué afirmación permite cada partición y cómo se evitó que las decisiones de ajuste consumieran la evidencia presentada como independiente.
Estas consideraciones no convierten el documento en una guía de entrenamiento completa. Son necesarias para interpretar honestamente qué se aprendió y qué se comprobó. La evaluación detallada y la operación de modelos conservan alcances futuros del Atlas.
ML, redes neuronales y sistemas completos
Un ejemplo permite separar ajuste y utilidad. Una colección contiene muchas solicitudes habituales y pocas urgentes. Predecir siempre la categoría habitual puede acertar una gran proporción de ejemplos y fallar precisamente los casos que motivaron el sistema. Antes de celebrar el resultado agregado, el equipo necesita definir qué consecuencia tiene cada error y si la evidencia incluye situaciones críticas.
Agregar una feature que solo existe después de resolver la solicitud puede mejorar aparentemente la evaluación y resultar inútil al ingresar una nueva. Si además se mezclan versiones del mismo caso entre particiones, el experimento puede parecer más sólido de lo que es. El problema no se reduce a elegir otra arquitectura: corresponde revisar disponibilidad temporal, unidad de separación y objetivo.
Una comparación útil conserva una base comprensible, utiliza evidencia pertinente y distingue hipótesis de observaciones. Un modelo complejo puede aportar una mejora real, pero necesita demostrarla bajo condiciones que representen el uso previsto. Esa disciplina evita tratar cualquier score alto como generalización o cualquier incremento de tamaño como progreso inevitable.
Neural Networks es una familia de modelos dentro de ML. Existen otros enfoques, como modelos lineales o árboles, con propiedades distintas. Deep learning suele utilizar representaciones neuronales de varias capas; no es sinónimo de todo ML. Transformers pertenece a esa familia amplia, sin reemplazar todas las arquitecturas o algoritmos anteriores.
Un modelo tampoco es la aplicación que lo utiliza. Puede necesitar representaciones de entrada, una política para interpretar salidas y componentes que ejecuten efectos. El comportamiento del producto depende de esa composición. probabilistic-vs-deterministic-software permite examinar sus propiedades sin asumir que toda inferencia muestrea o que todo software convencional es perfectamente reproducible.
Como ejemplo, un modelo aprende a clasificar solicitudes y un servicio decide su destino. El entrenamiento necesita ejemplos y objetivos; la validación ayuda a elegir la versión; la inferencia produce la clasificación. El servicio todavía debe comprobar formatos, manejar entradas fuera de alcance y preservar permisos. Una buena puntuación del modelo no demuestra corrección de esas responsabilidades externas.
Una entrega comprensible identifica tarea, datos pertinentes, representación, versión y evidencia, con sus límites. Esa información ayuda a distinguir un error de integración de una limitación del aprendizaje. No hace falta convertir todos los parámetros del proceso en documentación permanente, pero sí conservar lo necesario para sostener las afirmaciones importantes.
Fuentes y alcance
Referencia académica: Deep Learning, capítulo 5: Machine Learning Basics, Goodfellow, Bengio y Courville, 2016; consultado el 2026-10-30. Los ejemplos de incidencias, responsabilidades de integración y decisiones de ingeniería son síntesis del Atlas. No se prescriben frameworks, ratios de partición ni una receta de entrenamiento. Neural Networks, LLM Fundamentals y las futuras prácticas de evaluación u operación conservan sus propios hogares.