Lección 0.5 – Cómo crear un proyecto de inteligencia artificial
Lección 0.5 – Cómo crear un proyecto de inteligencia artificial
Curso de inteligencia artificial desde cero
Bloque 0: Fundamentos de inteligencia artificial
Lección 0.5 · Lección 5 de 5 del bloque
Nivel: iniciación · Sin conocimientos previos
Un proyecto de inteligencia artificial empieza con un problema concreto y termina con un sistema cuyo funcionamiento podemos evaluar y mantener.
Elegir un modelo es solo una parte del trabajo. También necesitamos definir qué queremos conseguir, comprobar los datos, comparar alternativas y decidir cómo responder cuando el sistema se equivoca.
En esta última lección del bloque introductorio recorreremos el proceso completo con un ejemplo: estimar el tiempo de una entrega. Además, veremos código Python que separa entrenamiento, validación y prueba.
No necesitas dominar todavía la programación. El propósito es comprender el recorrido antes de estudiar sus herramientas en profundidad.
El ciclo de vida de un proyecto de inteligencia artificial
Podemos organizar el trabajo en estas etapas:
| Etapa | Pregunta principal |
|---|---|
| 1. Definición | ¿Qué problema queremos resolver? |
| 2. Viabilidad | ¿Tenemos datos, recursos y una forma de evaluar? |
| 3. Preparación de datos | ¿Qué información utilizaremos y con qué calidad? |
| 4. Diseño de evaluación | ¿Cómo separaremos los datos y mediremos los resultados? |
| 5. Solución de referencia | ¿Qué consigue una alternativa sencilla? |
| 6. Desarrollo | ¿Qué modelos o configuraciones funcionan mejor? |
| 7. Evaluación final | ¿El sistema elegido cumple los requisitos? |
| 8. Despliegue | ¿Cómo lo utilizaremos dentro de una aplicación? |
| 9. Seguimiento | ¿Cómo detectaremos errores y cambios? |
Estas etapas no forman una secuencia rígida que se recorre una sola vez. Una evaluación puede revelar problemas en los datos y obligarnos a volver atrás.
El proyecto es iterativo, pero sus decisiones deben quedar registradas.
1. Definir el problema antes de elegir herramientas
«Queremos utilizar IA en los repartos» no define una tarea evaluable.
Una formulación más útil sería:
Estimar el tiempo de entrega de un pedido cuando se realiza, utilizando información disponible en ese momento.
Ahora podemos concretar:
- Usuario: la persona que consulta cuándo llegará su pedido.
- Entrada: distancia y otras características disponibles.
- Salida: tiempo estimado en minutos.
- Momento de predicción: al confirmar el pedido.
- Utilidad esperada: ofrecer una estimación más útil que la actual.
El momento de predicción determina qué información podemos utilizar. La hora real de llegada no sirve como entrada porque todavía no la conocemos.
Definir qué significa tener éxito
Necesitamos criterios antes de comparar modelos.
Por ejemplo:
- Mejorar el error de la solución actual.
- Responder dentro del tiempo que necesita la aplicación.
- Evitar estimaciones negativas.
- Ofrecer una alternativa cuando faltan datos.
Podríamos establecer un objetivo de error medio, pero su valor debe justificarse según el uso. No existe un umbral universal que convierta una predicción en aceptable.
Además, un promedio puede ocultar retrasos muy grandes. Conviene estudiar también errores extremos y situaciones concretas.
2. Comprobar la viabilidad
Antes de entrenar, debemos responder algunas preguntas.
¿Disponemos de ejemplos adecuados?
Para aprender de entregas anteriores necesitamos registros de distancias y tiempos, medidos de forma coherente.
También debemos comprobar si cubren las condiciones relevantes:
- Trayectos cortos y largos.
- Diferentes horarios.
- Zonas de reparto.
- Periodos de alta demanda.
Muchos registros de una única situación no sustituyen una cobertura adecuada de las demás.
¿Necesitamos entrenar un modelo?
No todos los proyectos requieren entrenamiento propio.
Podemos:
- Programar una regla.
- Utilizar un método estadístico sencillo.
- Entrenar un modelo con nuestros datos.
- Aprovechar un modelo preentrenado.
- Combinar modelos con búsqueda o herramientas.
La elección depende del problema. Utilizar un modelo existente no elimina la necesidad de evaluar el sistema.
¿Podemos mantener la solución?
Debemos considerar el coste completo: preparación de datos, ejecución, infraestructura, revisión y mantenimiento.
Una mejora pequeña puede no compensar un aumento grande de complejidad.
3. Recopilar y preparar los datos
Supongamos que cada registro contiene:
identificador del pedido distancia en kilómetros fecha y hora del pedido hora de entrega zona de reparto
A partir de las horas podemos calcular el tiempo real que queremos predecir.
Después revisamos errores como:
- Distancias negativas.
- Tiempos imposibles.
- Pedidos duplicados.
- Unidades mezcladas.
- Datos ausentes.
- Cambios en la forma de registrar información.
Documentar el significado de cada columna
Un pequeño diccionario de datos evita muchas confusiones.
| Campo | Significado | Unidad | Disponible al predecir |
|---|---|---|---|
| distancia_km | Distancia estimada del trayecto. | Kilómetros | Sí |
| zona | Área de reparto. | Categoría | Sí |
| tiempo_real_min | Duración observada de la entrega. | Minutos | No: es el objetivo |
También debemos utilizar solo los datos necesarios, con los permisos y las condiciones de uso correspondientes. Evitar información personal innecesaria simplifica el proyecto y reduce exposición.
Los datos atípicos no se eliminan automáticamente
Una entrega de duración excepcional puede ser un error de registro o un caso real importante.
Antes de descartarla necesitamos investigar su origen. Limpiar datos no significa borrar todo lo que resulta incómodo para el modelo.
4. Diseñar la evaluación y separar los datos
La evaluación debe representar la situación en la que utilizaremos el sistema.
En entregas, normalmente queremos aprender del pasado para predecir pedidos futuros. Por eso puede ser adecuado separar cronológicamente:
- Un periodo anterior para entrenamiento.
- Otro posterior para validación.
- El periodo más reciente reservado para prueba.
No hay una proporción obligatoria que sirva para todos los proyectos.
Qué función tiene cada conjunto
| Conjunto | Para qué se utiliza |
|---|---|
| Entrenamiento | Ajustar los parámetros. |
| Validación | Elegir modelos, configuraciones y otras decisiones de desarrollo. |
| Prueba | Evaluar finalmente la solución elegida. |
También hay que evitar que duplicados o registros relacionados creen una separación engañosa.
Las transformaciones también pueden filtrar información
Si necesitamos calcular una media para rellenar datos ausentes, esa media debe aprenderse con el entrenamiento y aplicarse después a los otros conjuntos.
Calcularla con todos los datos antes de separarlos puede introducir información que debería permanecer reservada.
Esta regla también afecta a operaciones como el escalado y la selección de características.
5. Construir una solución de referencia
La solución de referencia, o baseline, permite comprobar si el modelo aporta una mejora.
Para estimar tiempos podríamos utilizar:
- Una duración fija.
- La media histórica.
- Una regla basada en la distancia.
- El sistema que ya utiliza la empresa.
La referencia debe calcularse con información disponible y evaluarse con los mismos ejemplos que el modelo.
Si una solución compleja no mejora una alternativa sencilla, necesitamos entender por qué antes de desplegarla.
6. Entrenar y comparar alternativas
Empezamos con modelos manejables y aumentamos la complejidad cuando hay una razón.
Cada experimento debería registrar:
- Datos utilizados.
- Características de entrada.
- Modelo y configuración.
- Resultados de validación.
- Código y dependencias.
- Observaciones sobre errores.
Esto ayuda a reproducir resultados y evita elegir un modelo porque recordamos vagamente que «parecía funcionar mejor».
Ejemplo en Python: entrenamiento, validación y prueba
Retomaremos el modelo:
tiempo estimado = a × distancia + b
Compararemos tres valores de a. Para cada uno calcularemos b utilizando únicamente el entrenamiento.
El cálculo de b empleado aquí minimiza el error cuadrático de entrenamiento para ese valor fijo de a. Después elegiremos entre las tres alternativas utilizando el error absoluto medio de validación.
Los datos son inventados y muy pequeños: sirven para explicar el procedimiento, no para demostrar la utilidad de un sistema real.
entrenamiento = [
(1, 8),
(2, 11),
(3, 14),
(4, 17),
]
validacion = [
(5, 21),
(6, 22),
]
prueba = [
(7, 27),
(8, 28),
]
def predecir(distancia, modelo):
return modelo["a"] * distancia + modelo["b"]
def calcular_mae(datos, modelo):
error_total = 0
for distancia, tiempo_real in datos:
estimacion = predecir(distancia, modelo)
error_total += abs(estimacion - tiempo_real)
return error_total / len(datos)
mejor_modelo = None
menor_mae = float("inf")
for a in [2, 3, 4]:
suma_residuos = 0
for distancia, tiempo_real in entrenamiento:
suma_residuos += tiempo_real - a * distancia
b = suma_residuos / len(entrenamiento)
modelo = {"a": a, "b": b}
mae = calcular_mae(validacion, modelo)
print(
f"a={a}, b={b:.1f}, "
f"MAE de validación={mae:.1f}"
)
if mae < menor_mae:
menor_mae = mae
mejor_modelo = modelo
# Evaluamos la solución elegida con la prueba reservada.
mae_final = calcular_mae(prueba, mejor_modelo)
# Referencia: predecir siempre la media del entrenamiento.
suma_tiempos = 0
for distancia, tiempo_real in entrenamiento:
suma_tiempos += tiempo_real
media = suma_tiempos / len(entrenamiento)
referencia = {"a": 0, "b": media}
mae_referencia = calcular_mae(prueba, referencia)
print("Modelo elegido:", mejor_modelo)
print("MAE de prueba:", mae_final)
print("MAE de referencia:", mae_referencia)
Resultado esperado
a=2, b=7.5, MAE de validación=3.0
a=3, b=5.0, MAE de validación=1.0
a=4, b=2.5, MAE de validación=3.0
Modelo elegido: {'a': 3, 'b': 5.0}
MAE de prueba: 1.0
MAE de referencia: 15.0
Qué representa cada parte
El diccionario modelo guarda los parámetros mediante nombres:
{"a": 3, "b": 5.0}
La función predecir() los utiliza para calcular una estimación.
Durante el desarrollo:
- Fijamos un candidato para a.
- Ajustamos b con el entrenamiento.
- Calculamos el MAE de validación.
- Conservamos la alternativa con menor error.
Aquí, los candidatos para a forman parte de nuestra búsqueda de configuraciones. En otros procedimientos podríamos aprender conjuntamente a y b.
La expresión :.1f indica que un número se muestre con un decimal.
Finalmente, evaluamos el modelo elegido y la referencia sobre la prueba.
Qué podemos concluir y qué no
En estos dos ejemplos de prueba, el modelo obtiene un MAE de un minuto y la referencia de quince minutos.
Podemos afirmar que el modelo funciona mejor en esos ejemplos. No podemos concluir que mantendrá ese rendimiento en pedidos reales.
Además, las distancias de prueba quedan fuera del intervalo de entrenamiento. Es una pequeña demostración de extrapolación, no una garantía de que extrapolar vaya a funcionar bien.
7. Analizar los errores antes de desplegar
El resultado global es un punto de partida.
También debemos preguntar:
- ¿Falla más en trayectos largos?
- ¿Subestima los tiempos en horas punta?
- ¿Qué sucede con datos incompletos?
- ¿Hay zonas con peores resultados?
- ¿Cuánto tardan las predicciones?
- ¿Produce salidas imposibles?
La evaluación debe incluir tanto el comportamiento del modelo como el de la aplicación que lo utiliza.
Si encontramos un problema y modificamos la solución basándonos en la prueba, ya hemos utilizado esa prueba para desarrollar. Necesitaremos una nueva evaluación independiente para estimar el rendimiento final con el mismo rigor.
8. Integrar el modelo en una aplicación
El despliegue consiste en poner la solución a disposición de sus usuarios o de otros programas.
Una aplicación podría enviar:
{
"distancia_km": 4
}
Y recibir:
{
"tiempo_estimado_min": 17
}
JSON es un formato de intercambio de datos. Todavía no hemos implementado un servidor: estos fragmentos muestran cómo podría ser su contrato de entrada y salida.
La aplicación también necesita:
- Comprobar tipos y unidades.
- Gestionar entradas ausentes o inválidas.
- Usar las mismas transformaciones que en entrenamiento.
- Controlar tiempos de respuesta y errores.
- Identificar qué versión del modelo responde.
Preparar una alternativa
Si el modelo no está disponible, podemos recurrir a una regla o a una estimación histórica.
También conviene conservar una versión anterior que permita revertir un cambio si aparecen problemas.
No es necesario automatizar todo desde el primer día. Podemos empezar mostrando predicciones para revisión antes de utilizarlas directamente.
9. Supervisar el sistema durante su uso
Un modelo que funcionaba bien puede perder utilidad si cambian rutas, procesos o hábitos.
Necesitamos observar dos niveles:
| Nivel | Ejemplos de seguimiento |
|---|---|
| Técnico | Disponibilidad, latencia, errores y consumo de recursos. |
| Predictivo | Desviación de las estimaciones, cambios en los datos y rendimiento por situación. |
En nuestro ejemplo, el error real solo puede calcularse cuando termina la entrega. Por tanto, parte de la evaluación llega con retraso.
Un cambio en los datos es una señal para investigar; no demuestra automáticamente que el modelo haya empeorado.
Reentrenar no es una solución automática
Si el problema está en una unidad incorrecta o en una integración defectuosa, entrenar otra vez no lo arreglará.
Antes de actualizar debemos identificar la causa, preparar datos adecuados y comparar la nueva versión con la anterior.
Documentación mínima de un proyecto de IA
Una ficha breve debería permitir responder:
- Qué problema resuelve y quién lo utiliza.
- Qué entradas necesita.
- De dónde proceden los datos.
- Cómo se han separado y transformado.
- Qué referencia se ha utilizado.
- Qué resultados se han obtenido.
- Qué limitaciones se conocen.
- Cómo se despliega y se revierte.
- Quién revisa su funcionamiento.
La reproducibilidad requiere conservar suficiente información sobre datos, código, configuración y entorno. Algunas operaciones pueden presentar variaciones incluso con controles de aleatoriedad, por lo que también debemos documentar esas condiciones.
Errores frecuentes al empezar
Elegir un modelo antes de concretar la tarea
La herramienta debe responder a las necesidades del problema.
Preparar una demostración y considerarla terminada
Un prototipo no resuelve por sí solo la evaluación, la integración ni el mantenimiento.
Comparar modelos con condiciones distintas
Si cambian los ejemplos o las métricas, la comparación puede resultar engañosa.
Utilizar la prueba para decidir cada mejora
El conjunto reservado deja de ser independiente cuando guía repetidamente el desarrollo.
Desplegar sin una alternativa de recuperación
Los fallos de disponibilidad y las regresiones también forman parte del funcionamiento real.
Ejercicios de autoevaluación
- ¿Por qué debemos definir el momento en el que se realizará una predicción?
- ¿Qué conjunto utilizamos para elegir entre varias configuraciones?
- ¿Para qué sirve una solución de referencia?
- ¿Por qué calculamos las transformaciones aprendidas utilizando solo el entrenamiento?
- Un modelo mejora el error medio, pero produce algunos tiempos negativos. ¿Está listo para desplegarse?
- Tras el despliegue aumenta el error. ¿Debemos reentrenar inmediatamente?
Soluciones explicadas
1. Porque determina qué información estará disponible y ayuda a evitar fugas de información.
2. El conjunto de validación. La prueba se reserva para evaluar la solución elegida.
3. Para comprobar si la propuesta aporta una mejora frente a una alternativa sencilla o al sistema existente.
4. Para evitar que la información de validación o prueba influya en el ajuste del sistema.
5. No basta con mejorar la media. Debemos investigar las salidas imposibles y comprobar que el sistema cumple los requisitos de uso.
6. Primero debemos investigar la causa. Puede haber cambios en los datos, errores de integración o problemas de registro que no se solucionan reentrenando.
Preguntas frecuentes sobre proyectos de inteligencia artificial
¿Siempre necesito entrenar un modelo desde cero?
No. Muchos proyectos utilizan modelos preentrenados o servicios existentes. Aun así, necesitan una evaluación adaptada a su tarea.
¿Cuántos datos necesita un proyecto de IA?
Depende del problema, del modelo, de la variabilidad y del rendimiento necesario. No hay una cifra universal. Podemos estudiar cómo mejora el resultado al aumentar los ejemplos mediante curvas de aprendizaje.
¿Puedo reutilizar un modelo para otra aplicación?
Puede ser posible, pero debemos comprobar sus entradas, condiciones de uso y rendimiento en la nueva tarea. Que funcione en una aplicación no valida automáticamente otra.
¿Cuándo se considera terminado un proyecto?
Una entrega puede darse por completada cuando cumple sus criterios de aceptación. Si el sistema sigue en uso, necesita responsables y un plan de mantenimiento.
Has completado el bloque 0
Has completado la lección 0.5, la última de las cinco lecciones del bloque 0: Fundamentos de inteligencia artificial.
Antes de avanzar, repasa las ideas principales y vuelve a los ejemplos o ejercicios que te hayan resultado más difíciles.
| Navegación | Contenido |
|---|---|
| Anterior | Lección 0.4 – Capacidades y límites de la inteligencia artificial |
| Siguiente | lección 1.1 – Preparar el entorno de Python para inteligencia artificial |