Andrej Karpathy aprendizaje profundo: lecciones para lanzar IA

Por qué el aprendizaje profundo a menudo parece difícil de usar en productos reales

Una demo de aprendizaje profundo puede parecer mágica. Un modelo escribe un párrafo limpio, reconoce un objeto o responde una pregunta complicada. Luego intentas convertir esa demo en un botón que la gente pulse todos los días, y las cosas se complican. El mismo prompt se comporta distinto, surgen casos límite y el momento “wow” termina siendo un ticket de soporte.

Esa brecha es la razón por la que el trabajo de Andrej Karpathy ha conectado con quienes construyen productos. Él impulsó una mentalidad donde las redes neuronales no son artefactos misteriosos. Son sistemas que diseñas, pruebas y mantienes. Los modelos no son inútiles; los productos exigen consistencia.

Cuando los equipos dicen que quieren IA “práctica”, normalmente se refieren a cuatro cosas:

• Repetible: se comporta de forma predecible con entradas comunes, no solo con demos seleccionadas.
• Medible: puedes definir “bueno” con un número, no con una sensación.
• Mantenible: puedes actualizar datos, prompts o modelos sin romperlo todo.
• Operable: puedes monitorizar fallos, coste, latencia y calidad después del lanzamiento.

Los equipos tienen problemas porque el aprendizaje profundo es probabilístico y sensible al contexto, mientras que los productos se juzgan por su fiabilidad. Un chatbot que responde bien al 80% de las preguntas puede seguir pareciendo roto si el otro 20% es seguro, equivocado y difícil de detectar.

Toma un asistente de “respuesta automática” para soporte al cliente. Se ve bien con unos pocos tickets escogidos a mano. En producción, los clientes escriben con jerga, incluyen capturas de pantalla, mezclan idiomas o preguntan sobre casos de política. Ahora necesitas límites, un comportamiento claro de rechazo y una forma de medir si el borrador realmente ayudó al agente.

Trabajo temprano: tratar las redes neuronales como ingeniería, no magia

Mucha gente conoció el trabajo de Karpathy a través de ejemplos prácticos, no de matemáticas abstractas. Incluso en proyectos tempranos se hizo un punto simple: las redes neuronales son útiles cuando las tratas como software que puedes probar, romper y arreglar.

En lugar de quedarse en “el modelo funciona”, el foco cambia a hacerlo funcionar con datos reales y desordenados. Eso incluye pipelines de datos, ejecuciones de entrenamiento que fallan por razones banales y resultados que cambian al tocar algo pequeño. En ese mundo, el aprendizaje profundo deja de sonar místico y empieza a sentirse como ingeniería.

Un enfoque al estilo Karpathy tiene menos que ver con trucos secretos y más con hábitos:

• Empieza con una línea base que puedas superar, aunque sea simple.
• Elige una métrica que decida “mejor” vs “peor”.
• Cambia una cosa a la vez para saber qué causó el resultado.
• Inspecciona errores y ejemplos, no solo la puntuación final.

Esa base importa después porque la IA de producto es mayormente el mismo juego, solo con más riesgo. Si no construyes la artesanía desde temprano (entradas claras, salidas claras, ejecuciones repetibles), lanzar una función de IA se convierte en adivinanza.

Hacer las redes neuronales comprensibles para ingenieros

Una gran parte del impacto de Karpathy fue tratar las redes neuronales como algo sobre lo que puedes razonar. Explicaciones claras convierten el trabajo de un “sistema de creencias” a ingeniería.

Eso importa para los equipos porque la persona que entrega el primer prototipo a menudo no es la que lo mantiene. Si no puedes explicar qué hace un modelo, probablemente no puedes depurarlo y con seguridad no puedes darle soporte en producción.

Explícalo como si fueras a mantenerlo

Obliga a la claridad desde el principio. Antes de construir la función, escribe qué ve el modelo, qué produce y cómo sabrás si mejora. La mayoría de proyectos de IA fallan en lo básico, no en las matemáticas.

Una lista de verificación corta que rinde frutos más tarde:

• ¿Cuál es la entrada y salida exacta (formato, límites, redacciones)?
• ¿Qué baseline debes superar (reglas, búsqueda, plantillas o un modelo más pequeño)?
• ¿Cómo se ve “bueno” (un número, una rúbrica o ambos)?
• ¿Qué fallos son inaceptables (seguridad, privacidad, tono de marca)?
• ¿Quién revisa resultados y con qué frecuencia?

La reproducibilidad es parte de la explicación

El pensamiento claro aparece como experimentos disciplinados: un script que puedes volver a ejecutar, conjuntos de evaluación fijos, prompts versionados y métricas registradas. Las baselines te mantienen honesto y hacen el progreso visible.

De prototipos a producción: qué cambia cuando se lanza

Un prototipo prueba que una idea puede funcionar. Una funcionalidad lanzada prueba que funciona para personas reales, en condiciones desordenadas, cada día. Esa es la brecha donde muchos proyectos de IA se atascan.

Una demo de investigación puede ser lenta, cara y frágil, mientras demuestre capacidad. Producción invierte las prioridades. El sistema debe ser predecible, observable y seguro aun cuando las entradas sean raras, los usuarios impacientes y el tráfico aumente.

Las restricciones que de pronto importan

En producción, la latencia es una característica. Si el modelo tarda 8 segundos, los usuarios lo abandonan o pulsan de nuevo el botón, y pagas por cada reintento. El coste también se convierte en decisión de producto, porque un pequeño cambio de prompt puede duplicar la factura.

La monitorización es innegociable. Necesitas saber no solo que el servicio está arriba, sino que las salidas se mantienen dentro de la calidad aceptable con el tiempo. Los cambios en los datos, el comportamiento de usuarios y cambios upstream pueden romper el rendimiento sin lanzar un error.

Las comprobaciones de seguridad y política pasan de “agradable de tener” a obligatorias. Tienes que manejar peticiones dañinas, datos privados y casos límite de forma consistente y testeable.

Los equipos suelen terminar respondiendo las mismas preguntas:

• ¿Cuál es el tiempo máximo de respuesta y coste aceptable por petición?
• ¿Cuál es el fallback cuando el modelo falla o hace timeout?
• ¿Qué métricas definen la calidad y qué umbrales activan alertas?
• ¿Cómo previenes salidas inseguras o no conformes?
• ¿Cómo haces rollback rápido si la calidad baja?

Hace falta más que habilidad con modelos

Un prototipo puede construirlo una persona. El lanzamiento suele necesitar que producto defina éxito, datos validen entradas y conjuntos de evaluación, infraestructura para ejecutarlo con fiabilidad y QA para probar modos de fallo.

“Funciona en mi máquina” no es criterio de lanzamiento. Un lanzamiento significa que funciona para usuarios bajo carga, con logging, guardrails y una forma de medir si ayuda o perjudica.

La cultura de ingeniería: suposiciones, baselines e iteración

La influencia de Karpathy es cultural, no solo técnica. Él trató las redes neuronales como algo que puedes construir, probar y mejorar con la misma disciplina aplicada a cualquier sistema de ingeniería.

Empieza documentando suposiciones antes de escribir código. Si no puedes decir qué debe ser verdad para que la función funcione, no podrás depurarla después. Ejemplos:

• “Los usuarios aceptarán una respuesta sugerida si es correcta y coincide con su tono.”
• “Se requiere latencia por debajo de 800 ms o la gente deja de usarla.”

Esas son afirmaciones testeables.

Las baselines vienen después. Una baseline es lo más simple que podría funcionar y es tu control de realidad. Puede ser reglas, una plantilla de búsqueda o incluso “no hacer nada” con una buena UI. Las baselines fuertes te protegen de pasar semanas en un modelo elegante que no supera algo simple.

La instrumentación hace posible la iteración. Si solo miras demos, navegas por sensaciones. Para muchas funciones de IA, un pequeño conjunto de números ya te dice si mejoras:

• Adopción (quién lo prueba y sigue usándolo)
• Calidad (tasa de aceptación, ediciones antes de enviar, pulgares arriba/abajo)
• Velocidad (latencia y tiempo hasta la primera salida útil)
• Coste (tokens, cómputo, tiempo de revisión humana)
• Seguridad (violaciones de política, fugas de datos sensibles, intentos de jailbreak)

Luego itera en bucles cortos. Cambia una cosa, compárala con la baseline y lleva un registro simple de lo que intentaste y qué movió. Si el progreso es real, aparece en un gráfico.

Paso a paso: un flujo simple para lanzar una función de IA

Lanzar IA funciona mejor cuando la tratas como ingeniería: objetivos claros, una baseline y bucles de feedback rápidos.

1. Declara el problema del usuario en una frase. Escríbelo como una queja real: “Los agentes de soporte tardan demasiado en redactar respuestas a preguntas comunes.” Si no puedes decirlo en una frase, la función probablemente sea demasiado grande.

2. Elige un resultado medible. Escoge un número que puedas seguir semanalmente. Buenas opciones incluyen tiempo ahorrado por tarea, tasa de aceptación del primer borrador, reducción de ediciones o tasa de desvío de tickets. Decide qué significa “suficiente” antes de construir.

3. Define la baseline que debes superar. Compárala con una plantilla simple, un enfoque basado en reglas o “solo humano”. Si la IA no supera la baseline en tu métrica, no la lances.

4. Diseña una prueba pequeña con datos representativos. Recoge ejemplos que coincidan con la realidad, incluidos los casos desordenados. Mantén un conjunto de evaluación pequeño que no “entrenes mentalmente” releyéndolo cada día. Anota qué cuenta como aprobado y qué como fallo.

5. Lanza detrás de un flag, recoge feedback e itera. Empieza con un grupo interno pequeño o un porcentaje reducido de usuarios. Registra la entrada, la salida y si ayudó. Arregla el modo de fallo principal primero y vuelve a ejecutar la misma prueba para ver progreso real.

Un patrón práctico para herramientas de redacción: mide “segundos hasta enviar” y “porcentaje de borradores usados con ediciones menores”.

Suposiciones claras y salidas medibles (qué escribir)

Muchos fallos de funciones de IA no son fallos de modelo. Son fallos de “nunca acordamos cómo se ve el éxito”. Si quieres que el aprendizaje profundo resulte práctico, escribe las suposiciones y las medidas antes de escribir más prompts o entrenar más modelos.

Empieza con suposiciones que puedan romper tu función en uso real. Las comunes son sobre datos y personas: el texto de entrada está en un idioma, los usuarios piden una intención a la vez, la UI provee suficiente contexto, los casos límite son raros y el patrón de ayer seguirá siendo el de mañana (drift). También escribe lo que no vas a manejar todavía, como sarcasmo, asesoría legal o documentos largos.

Convierte cada suposición en algo que puedas probar. Un formato útil es: “Dado X, el sistema debe hacer Y y podemos verificarlo con Z.” Manténlo concreto.

Cinco cosas que vale la pena escribir en una página:

• Entradas: qué ve el modelo (campos, límites, redacciones) y qué significa “lo suficientemente limpio”
• Contrato de salida: qué debe devolver (formato, tono, acciones permitidas)
• Evaluación offline: un pequeño conjunto etiquetado con reglas de puntuación (aprobado/fallo más una métrica)
• Métrica online: lo que hacen los usuarios (tasa de aceptación, ediciones, tiempo ahorrado, tickets reabiertos)
• Guardrails: cuándo rechazar, preguntar o recurrir a un flujo más simple

Mantén offline y online separados a propósito. Las métricas offline te dicen si el sistema aprendió la tarea. Las métricas online te dicen si la función ayuda a las personas. Un modelo puede puntuar bien offline y aún así molestar a los usuarios porque es lento, demasiado seguro o equivocado en los casos que importan.

Define “suficiente” como umbrales y consecuencias. Ejemplo: “Offline: al menos 85% correcto en el conjunto de evaluación; Online: 30% de borradores aceptados con ediciones mínimas.” Si fallas un umbral, decide antes qué pasa: mantenerlo detrás de un toggle, reducir el despliegue, enrutar casos de baja confianza a una plantilla o pausar y recopilar más datos.

Errores comunes cuando los equipos añaden IA a un producto

Los equipos a menudo tratan una función de IA como un ajuste normal de UI: la lanzan, ven qué pasa y ajustan después. Eso falla rápido porque el comportamiento del modelo puede cambiar con prompts, drift y pequeñas ediciones de configuración. El resultado es mucho esfuerzo sin prueba clara de que ayudó.

Una regla práctica es simple: si no puedes nombrar la baseline y la medición, aún no estás listo para lanzar.

Los modos de fallo más comunes:

• Lanzar sin una baseline no IA, así la mejora no es demostrable.
• Perseguir calidad sin mirar latencia y coste (una mejora del 3% no vale 5x más lento).
• Confiar en feedback vago (“a los usuarios les gusta”) en lugar de instrumentación.
• Afinar en un conjunto pequeño o seleccionado que no coincide con el tráfico real.
• No tener plan de rollback cuando un prompt o actualización de modelo produce salidas extrañas.

Un ejemplo concreto: añades IA para redactar respuestas de soporte. Si solo rastreas pulgares arriba, podrías no notar que los agentes tardan más revisando borradores, o que las respuestas son precisas pero demasiado largas. Medidas mejores son “% enviado con ediciones mínimas” y “mediana de tiempo hasta envío”.

Lista rápida antes del lanzamiento

Trata el día del lanzamiento como una entrega de ingeniería, no una demo. Debes poder explicar, en palabras sencillas, qué hace la función, cómo sabes que funciona y qué harás cuando falle.

Antes de lanzar, asegúrate de tener:

• Un enunciado del problema en un párrafo y usuarios objetivo claros.
• Una baseline medida (aunque sea simple).
• Una métrica online primaria ligada al valor del usuario, además de logs que capturen entradas, salidas y resultados.
• Una revisión de seguridad: modos probables de fallo, quién puede resultar perjudicado y qué hace la UI (advertir, bloquear, pedir confirmación).
• Un plan de rollback con un responsable: qué dispara el rollback y qué se revisa en la primera hora.

También conserva un conjunto de evaluación offline que parezca tráfico real, incluya casos límite y se mantenga estable para comparar entre semanas. Cuando cambies prompts, modelos o limpieza de datos, vuelve a ejecutar el mismo conjunto y observa qué cambió.

Escenario de ejemplo: lanzar una función de redacción para soporte

Un equipo de soporte quiere un asistente que redacte respuestas dentro de la vista de ticket. El agente no envía mensajes por su cuenta. Sugiere un borrador, resalta hechos clave que usó y pide al agente revisar y editar antes de enviar. Esa elección mantiene bajo el riesgo mientras aprendes.

Empieza decidiendo qué significa “mejor” en números. Elige resultados que puedas medir desde el día uno usando logs existentes:

• Tiempo medio de gestión (abierto a resuelto)
• Tasa de edición (cuánto cambian los agentes los borradores antes de enviar)
• Tasa de escalado (tickets llevados a niveles superiores)
• Tasa de reapertura (tickets reabiertos en 7 días)
• Puntuación de satisfacción del cliente (si ya la registras)

Antes de incorporar un modelo, fija una baseline aburrida pero real: plantillas guardadas más una capa simple de reglas (detectar reembolso vs envío vs restablecimiento de contraseña y rellenar la mejor plantilla). Si la IA no vence esa baseline, no está lista.

Haz un piloto pequeño. Hazlo opt-in para un puñado de agentes, limitado a una categoría de ticket primero (por ejemplo, estado de pedido). Añade feedback rápido en cada borrador: “útil” o “no útil”, más una razón corta. Captura lo que el agente cambió, no solo si pulsó un botón.

Define criterios de lanzamiento por adelantado para no adivinar después. Por ejemplo: el tiempo de gestión mejora un 10% sin aumentar escalados o reaperturas, y los agentes aceptan borradores con ediciones mínimas al menos el 30% del tiempo.

Decide también qué disparará el rollback: un pico en escalados, una caída en satisfacción o errores repetidos de política.

Próximos pasos: aplica estas lecciones a tu próximo lanzamiento de IA

Elige una idea de IA que puedas lanzar en 2 a 4 semanas. Manténla lo bastante pequeña para medirla, depurarla y revertirla sin drama. El objetivo no es demostrar que el modelo es inteligente. Es mejorar de forma fiable un resultado de usuario respecto a lo que ya tienes.

Convierte la idea en un plan de una página: qué hace la función, qué no hace y cómo sabrás que funciona. Incluye una baseline y la métrica exacta que vas a rastrear.

Si quieres moverte rápido en la implementación, Koder.ai (koder.ai) está construido alrededor de crear apps web, servidor y móviles mediante una interfaz de chat, con funciones como snapshots/rollback y exportación de código fuente cuando necesitas control más profundo.

El hábito a mantener es simple: cada cambio de IA debe venir con una suposición escrita y una salida medible. Así el aprendizaje profundo deja de parecer magia y empieza a ser trabajo que puedes lanzar.