La inteligencia artificial generativa ha pasado en pocos años de ser un tema de investigación a convertirse en una herramienta cotidiana para los equipos de desarrollo. Autocompletado de código, chatbots capaces de mantener conversaciones coherentes, generación automática de documentación... todo ello se apoya en una misma familia de tecnologías. En esta primera lección vamos a establecer los cimientos del curso: entenderás qué distingue a la IA generativa del machine learning clásico, cómo hemos llegado hasta los grandes modelos de lenguaje (LLMs), qué tipos de contenido pueden generar y, sobre todo, qué casos de uso reales tienen para ti como desarrollador. Además, presentaremos el hilo conductor que nos acompañará durante todo el curso: DocuBot, el asistente de documentación interna que construiremos paso a paso para una empresa ficticia llamada Nubelia.
Contenido
- IA generativa vs. IA discriminativa: dos formas de usar el machine learning
- Breve historia: del ML clásico a los LLMs
- Qué genera la IA generativa: texto, código, imágenes y más
- Casos de uso reales para desarrolladores
- Nuestro caso de curso: Nubelia y la necesidad de DocuBot
- Qué puede y qué no puede hacer un LLM (razonamiento inicial)
IA generativa vs. IA discriminativa: dos formas de usar el machine learning
Durante la mayor parte de la historia del machine learning aplicado, los modelos que usábamos en producción eran discriminativos (también llamados predictivos o de clasificación). Su trabajo consiste en tomar una entrada y asignarle una etiqueta, una puntuación o una categoría de entre un conjunto cerrado de posibilidades.
Algunos ejemplos clásicos:
- Un filtro de spam: recibe un correo y responde
spamono spam. - Un modelo de scoring: recibe los datos de una solicitud y devuelve una probabilidad.
- Un clasificador de imágenes: recibe una foto y responde
gato,perroopájaro.
La IA generativa, en cambio, no elige entre opciones predefinidas: produce contenido nuevo que no existía en sus datos de entrenamiento tal cual. Genera texto, código, imágenes o audio, y el espacio de salidas posibles es prácticamente infinito.
La diferencia se ve muy bien en una tabla:
| Aspecto | IA discriminativa (ML clásico) | IA generativa |
|---|---|---|
| Objetivo | Clasificar o predecir un valor | Crear contenido nuevo |
| Salida | Etiqueta, número o categoría de un conjunto cerrado | Texto, código, imagen... abierto |
| Ejemplo típico | "¿Este correo es spam?" → sí/no | "Redacta una respuesta a este correo" |
| Datos de entrenamiento | Suelen requerir etiquetado manual | Grandes corpus sin etiquetar (más ajustes posteriores) |
| Evaluación | Métricas claras (precisión, recall...) | Más difusa: calidad, utilidad, corrección |
| Interfaz habitual | Función que devuelve una predicción | Conversación o instrucción en lenguaje natural |
Un matiz importante: no son tecnologías enfrentadas, sino complementarias. De hecho, muchos sistemas modernos combinan ambas. Un pipeline de moderación de contenido puede usar un modelo generativo para redactar una respuesta y uno discriminativo para verificar que esa respuesta no contiene lenguaje inapropiado antes de mostrarla.
Como desarrollador, la consecuencia práctica más relevante es esta: con el ML clásico entrenabas (o encargabas entrenar) un modelo específico para cada tarea; con la IA generativa, un mismo modelo de propósito general puede realizar cientos de tareas distintas simplemente describiéndoselas en lenguaje natural. Eso cambia radicalmente cómo se integra la IA en el software, y es el motivo de que este curso exista.
Breve historia: del ML clásico a los LLMs
No necesitas conocer la historia completa de la IA para usar un LLM, pero entender los hitos principales te ayudará a situar la tecnología y a entender por qué funciona como funciona.
- Décadas de 1950–1990 — Sistemas basados en reglas y ML estadístico temprano. Los primeros chatbots (como ELIZA, en los años 60) funcionaban con reglas escritas a mano: detectaban patrones en el texto y respondían con plantillas. No "entendían" nada, y se notaba en cuanto la conversación salía del guion.
- 1990–2010 — Machine learning estadístico. Los modelos aprenden de datos en lugar de reglas manuales: máquinas de vectores soporte, árboles de decisión, modelos n-grama para lenguaje. El procesamiento de lenguaje natural (NLP) avanza, pero cada tarea (traducir, resumir, clasificar) requiere su propio modelo y su propio dataset etiquetado.
- 2010–2017 — Deep learning y redes recurrentes. Las redes neuronales profundas revolucionan primero la visión por computador y después el lenguaje. Las redes recurrentes (RNN, LSTM) procesan texto secuencialmente, palabra a palabra, pero les cuesta manejar textos largos y son lentas de entrenar porque no se pueden paralelizar bien.
- 2017 — El transformer. El artículo "Attention Is All You Need" introduce la arquitectura transformer, que sustituye la recurrencia por un mecanismo llamado atención. Esto permite procesar todas las palabras de un texto en paralelo y capturar relaciones entre palabras distantes. Es el hito técnico clave que hace posibles los LLMs actuales. (Cómo funciona por dentro lo veremos en la siguiente lección, 01-02; de momento quédate con que es la arquitectura sobre la que se construye casi todo lo que sigue.)
- 2018–2022 — Escalado y modelos de lenguaje grandes. Se descubre que, al entrenar transformers cada vez más grandes con cada vez más texto, no solo mejoran gradualmente: aparecen capacidades emergentes como seguir instrucciones, traducir sin haber sido entrenados específicamente para ello, o escribir código. Nacen los LLMs (Large Language Models, grandes modelos de lenguaje).
- 2022 en adelante — La IA generativa llega al gran público y a las empresas. Los LLMs conversacionales demuestran que un modelo de propósito general puede ser útil para tareas reales, y los proveedores publican APIs que permiten integrarlos en cualquier aplicación. Es el momento en el que la IA generativa deja de ser un tema de laboratorio y pasa a ser una pieza más de la arquitectura de software, como una base de datos o una cola de mensajes.
Este último punto es el que nos interesa en este curso: el LLM como componente de tus aplicaciones, accesible mediante una API, con sus capacidades, sus limitaciones y sus patrones de integración.
timeline
title Hitos hacia los LLMs
1966 : ELIZA - chatbot basado en reglas
1990s : ML estadístico - un modelo por tarea
2012 : Deep learning despega
2017 : Transformer - "Attention Is All You Need"
2020 : LLMs con capacidades emergentes
2022+ : IA generativa como componente de software vía APIQué genera la IA generativa: texto, código, imágenes y más
Bajo el paraguas de "IA generativa" conviven modelos que generan distintos tipos de contenido (lo que se llama distintas modalidades):
| Modalidad | Qué genera | Ejemplos de uso |
|---|---|---|
| Texto | Prosa, respuestas, resúmenes, traducciones | Chatbots, redacción, análisis de documentos |
| Código | Programas, tests, scripts, consultas SQL | Asistentes de programación, generación de tests |
| Imágenes | Ilustraciones, fotos sintéticas, diseños | Marketing, prototipado visual |
| Audio | Voz sintética, música | Locuciones, accesibilidad |
| Vídeo | Clips generados a partir de descripciones | Contenido audiovisual |
Este curso se centra en texto y código, por dos razones:
- Son las modalidades donde los LLMs están más maduros y donde existe más experiencia de integración en aplicaciones reales.
- Son las que un desarrollador de backend, frontend o full-stack va a integrar con más frecuencia: chatbots, asistentes, procesamiento de documentos, automatización.
Un detalle que sorprende a mucha gente: para un LLM, el código es texto. El mismo modelo que redacta un correo puede escribir una función en Python, porque durante su entrenamiento vio enormes cantidades de ambos. No hay un "módulo de código" separado; hay un modelo de lenguaje que ha aprendido los patrones del lenguaje natural y de los lenguajes de programación.
Casos de uso reales para desarrolladores
Veamos dónde está aportando valor la IA generativa en equipos de desarrollo reales. No es una lista exhaustiva, pero cubre las categorías principales.
- Asistentes de código
Es probablemente el caso de uso que ya conoces: herramientas integradas en el editor que autocompletan código, explican fragmentos, proponen refactorizaciones o generan tests. Aquí tú eres el usuario de la IA generativa.
- Chatbots y asistentes conversacionales
Aplicaciones que responden preguntas de usuarios o empleados en lenguaje natural: soporte al cliente, asistentes internos, FAQ inteligentes. Aquí tú eres el constructor: integras un LLM en tu aplicación. Este es el caso de uso central de este curso.
- Generación y mantenimiento de documentación
Generar documentación a partir de código, resumir documentos largos, mantener changelogs, redactar descripciones de endpoints a partir de una especificación OpenAPI.
- Procesamiento de texto no estructurado
Extraer datos estructurados de correos, tickets o PDFs; clasificar incidencias; normalizar texto libre a un formato procesable (por ejemplo, JSON). Es una categoría poco vistosa pero enormemente rentable: convierte problemas que antes requerían expresiones regulares frágiles o trabajo manual en una llamada a un modelo.
- Automatización de flujos de trabajo
Encadenar al LLM con otras herramientas: leer un ticket, buscar información relevante, redactar una propuesta de respuesta y dejarla lista para revisión humana. En su forma más avanzada, esto lleva a los agentes (los veremos en el módulo 5).
| Caso de uso | Tú eres... | Ejemplo concreto |
|---|---|---|
| Asistente de código | Usuario | Autocompletar una función en el editor |
| Chatbot / asistente | Constructor | Bot de soporte interno (nuestro DocuBot) |
| Documentación | Constructor / usuario | Generar docs a partir del código |
| Texto no estructurado | Constructor | Extraer campos de tickets en JSON |
| Automatización | Constructor | Clasificar y pre-responder incidencias |
Fíjate en un patrón que se repite en los casos de "constructor": el LLM no sustituye a tu aplicación, sino que se convierte en un componente más que recibe texto y devuelve texto, orquestado por tu código.
Nuestro caso de curso: Nubelia y la necesidad de DocuBot
Para que el curso no se quede en teoría, todo lo que aprendas lo aplicaremos a un caso concreto que iremos construyendo módulo a módulo.
Nubelia es una empresa ficticia de SaaS que ofrece una plataforma de gestión de proyectos: tableros, tareas, informes, integraciones con otras herramientas y una API pública para sus clientes. Como cualquier empresa de software con unos años de recorrido, Nubelia acumula una cantidad considerable de documentación interna:
- Documentación técnica de su API y de la arquitectura de la plataforma.
- Guías de operaciones y runbooks de despliegue.
- Artículos de la base de conocimiento del equipo de soporte.
- Actas de decisiones técnicas y convenciones del equipo de desarrollo.
Y ahí está el problema: esa documentación está repartida entre una wiki, repositorios y carpetas compartidas, y encontrar la respuesta correcta lleva demasiado tiempo. Un desarrollador nuevo tarda semanas en saber dónde buscar. El equipo de soporte escala preguntas a ingeniería que ya estaban respondidas en la wiki. Preguntas como "¿cuál es el límite de peticiones de la API pública?" o "¿cómo se reinicia el servicio de informes?" se responden una y otra vez por chat.
La propuesta que estudiaremos y construiremos a lo largo del curso es DocuBot: un asistente interno al que desarrolladores y personal de soporte de Nubelia puedan preguntar en lenguaje natural, y que responda basándose en la documentación interna de la empresa.
En este primer módulo aún no escribiremos código de integración (eso llega en el módulo 3). Pero DocuBot ya nos sirve para algo muy valioso: razonar sobre qué puede y qué no puede hacer un LLM, que es exactamente lo que haremos a continuación.
Qué puede y qué no puede hacer un LLM (razonamiento inicial)
Imagina que hoy mismo, sin más infraestructura, conectáramos un LLM genérico a un chat interno de Nubelia y lo llamáramos DocuBot. ¿Qué pasaría?
Lo que haría bien desde el primer día:
- Responder preguntas generales de programación ("¿cómo hago una petición HTTP en Python?").
- Explicar conceptos técnicos, redactar y resumir textos, traducir.
- Mantener una conversación coherente y adaptar el tono.
Lo que haría mal o directamente no podría hacer:
- Responder "¿cuál es el límite de peticiones de la API de Nubelia?" — el modelo no ha visto nunca la documentación interna de Nubelia, porque Nubelia no existe en sus datos de entrenamiento. Y lo preocupante: es posible que en lugar de decir "no lo sé", invente una respuesta plausible (una cifra razonable pero falsa). Este fenómeno se llama alucinación y lo estudiaremos a fondo en la lección 01-04.
- Conocer cambios recientes: aunque le diéramos documentación durante el entrenamiento, quedaría desactualizada.
- Ejecutar acciones: consultar el estado real de un servicio, abrir un ticket. Un LLM, por sí solo, solo genera texto.
Podemos resumir este razonamiento en pseudocódigo, que refleja la idea central de todo el curso:
# Lo que un LLM "sabe" tiene dos fuentes:
conocimiento_del_modelo = lo aprendido durante su entrenamiento
(general, amplio, pero congelado en el tiempo
y sin datos privados de tu empresa)
contexto_de_la_peticion = lo que tu aplicación le pasa en cada llamada
(instrucciones, documentos, historial...)
respuesta = modelo(conocimiento_del_modelo + contexto_de_la_peticion)La segunda fuente, contexto_de_la_peticion, es la que controlamos como desarrolladores, y es la clave de casi todo lo que haremos en este curso: aprender a darle al modelo el contexto adecuado (módulo 2, prompting), pasárselo desde nuestra aplicación (módulo 3, integración) y recuperar automáticamente los documentos relevantes de Nubelia para cada pregunta (módulo 4, RAG). Con eso, DocuBot dejará de inventar y empezará a responder con la documentación real delante.
Errores Comunes y Consejos
- Confundir "el modelo parece que entiende" con "el modelo sabe". Un LLM genera texto plausible; que la respuesta suene segura no significa que sea correcta. Adopta desde ya la costumbre de preguntarte: ¿de dónde sacaría el modelo esta información? Si la respuesta es "de ninguna parte" (como con la documentación interna de Nubelia), desconfía.
- Pensar que la IA generativa sustituye al ML clásico. Para clasificar transacciones o predecir demanda, un modelo discriminativo específico suele ser más barato, rápido y fiable. Usa IA generativa cuando la tarea implique producir o transformar lenguaje o código.
- Creer que hace falta ser experto en matemáticas o en deep learning. Para integrar LLMs en aplicaciones necesitas entender su comportamiento (tokens, contexto, limitaciones), no su cálculo interno. Es análogo a usar una base de datos sin haber implementado un motor de almacenamiento.
- Empezar por la tecnología en lugar del problema. "Quiero meter IA en mi producto" es un mal punto de partida. "Soporte pierde horas buscando en la wiki" (el problema de Nubelia) es un buen punto de partida: define el problema, y después evalúa si un LLM es la herramienta adecuada.
- Consejo: durante el curso, mantén una lista de tareas de tu trabajo real que encajen en las cinco categorías de casos de uso. Te servirá para aterrizar cada módulo en tu contexto.
Ejercicios
Ejercicio 1: ¿Generativa o discriminativa?
Clasifica cada una de estas tareas como más adecuada para un enfoque generativo, discriminativo o una combinación de ambos, y justifica brevemente por qué:
- Detectar si una reseña de producto es positiva o negativa.
- Redactar una respuesta personalizada a cada reseña de producto.
- Decidir si un ticket de soporte de Nubelia es urgente y, si lo es, redactar un primer borrador de respuesta.
- Predecir cuántos usuarios se conectarán a la plataforma de Nubelia el próximo lunes.
Ejercicio 2: DocuBot sin contexto
Un compañero de Nubelia propone lanzar DocuBot mañana mismo conectando el chat interno directamente a un LLM genérico, sin darle acceso a ninguna documentación. Escribe una lista de tres preguntas reales que los empleados podrían hacerle y para las que este DocuBot "ingenuo" daría un mal resultado, indicando en cada caso qué tipo de fallo esperarías (respuesta inventada, conocimiento desactualizado, o incapacidad de actuar).
Ejercicio 3: Detectar el caso de uso
Piensa en tu propio equipo o en un proyecto en el que hayas trabajado. Identifica una tarea que encaje en alguna de las cinco categorías de casos de uso de esta lección (asistente de código, chatbot, documentación, texto no estructurado, automatización). Describe: la tarea, la categoría, qué texto recibiría el LLM como entrada y qué texto debería producir como salida.
Soluciones
Solución 1:
- Discriminativa. Es una clasificación binaria clásica (positiva/negativa); un modelo específico es más barato y su rendimiento es fácil de medir. (Un LLM también puede hacerlo, pero sería usar un camión para llevar una carta.)
- Generativa. La salida es texto nuevo y personalizado; no hay un conjunto cerrado de respuestas posibles.
- Combinación. La decisión de urgencia es una clasificación (discriminativa o un LLM clasificando); el borrador de respuesta es generación. Es el patrón híbrido que mencionamos: clasificar primero, generar después, con revisión humana antes de enviar.
- Ninguna de las dos en sentido generativo: es predicción numérica, terreno del ML clásico (series temporales / regresión). Un LLM no es la herramienta adecuada para predecir una cifra a partir de datos históricos.
Solución 2 (ejemplo de respuesta válida; las tuyas pueden variar):
- "¿Cuál es el límite de peticiones por minuto de la API pública de Nubelia?" → Respuesta inventada (alucinación): el modelo no conoce Nubelia, pero puede generar una cifra plausible y falsa.
- "¿Qué cambió en la última versión de la plataforma?" → Conocimiento desactualizado / inexistente: aunque el modelo supiera algo de Nubelia, no conoce los cambios posteriores a su entrenamiento.
- "Reinicia el servicio de informes del entorno de pruebas." → Incapacidad de actuar: un LLM solo genera texto; no puede ejecutar acciones sobre sistemas (conectarlo con herramientas se verá en el módulo 5).
Cualquier pregunta sobre información interna, reciente o que requiera ejecutar acciones es una buena respuesta a este ejercicio.
Solución 3 (ejemplo):
- Tarea: el equipo recibe correos de clientes reportando errores, con formato libre.
- Categoría: procesamiento de texto no estructurado.
- Entrada: el cuerpo del correo del cliente.
- Salida: un JSON con campos como
producto,severidad_estimada,resumenypasos_para_reproducir, listo para crear un ticket automáticamente.
Lo importante es que hayas identificado con claridad la entrada y la salida en forma de texto: ese es el contrato básico de cualquier integración con un LLM.
Conclusión
En esta lección hemos delimitado el terreno de juego: la IA generativa crea contenido nuevo (frente al ML clásico, que clasifica o predice), es el resultado de una evolución cuyo hito clave fue la arquitectura transformer en 2017, y hoy es accesible para cualquier desarrollador como un componente más de sus aplicaciones. Hemos visto los casos de uso principales para desarrolladores y hemos presentado el problema que nos acompañará todo el curso: la documentación dispersa de Nubelia y la propuesta de resolverlo con DocuBot. También hemos hecho un primer razonamiento honesto sobre qué puede y qué no puede hacer un LLM sin ayuda: mucho conocimiento general, cero conocimiento de tu empresa, y tendencia a inventar cuando no sabe.
Hasta ahora hemos tratado el LLM como una caja negra que recibe texto y devuelve texto. En la próxima lección, "Cómo funciona un LLM: tokens, embeddings y atención", abriremos esa caja lo justo y necesario: entenderás qué son los tokens (y por qué determinan los límites y el coste de cada llamada), cómo los embeddings capturan el significado del texto y qué hace realmente el famoso mecanismo de atención. No hará falta ni una sola ecuación, pero saldrás entendiendo por qué el modelo se comporta como se comporta.
Curso de IA Generativa y LLMs para Desarrolladores
Módulo 1: Fundamentos de la IA generativa
- Qué es la IA generativa y por qué importa a los desarrolladores
- Cómo funciona un LLM: tokens, embeddings y atención
- Panorama de modelos y proveedores
- Limitaciones y riesgos: alucinaciones, contexto y costes
Módulo 2: Prompt engineering
- Anatomía de un prompt: roles, instrucciones y contexto
- Técnicas de prompting: few-shot, cadena de razonamiento y plantillas
- Salidas estructuradas: JSON y control de formato
- Iteración y evaluación de prompts
Módulo 3: Integración de LLMs en aplicaciones
- Primera integración con la API de un LLM
- Streaming, errores y reintentos
- Conversaciones y gestión del contexto
- Costes, latencia y caching
Módulo 4: RAG - Generación aumentada por recuperación
- Embeddings y búsqueda semántica
- Bases de datos vectoriales
- Ingesta y chunking de documentos
- Construcción de un pipeline RAG completo
- Evaluación de sistemas RAG
Módulo 5: Function calling y agentes
- Function calling: conectar el LLM con tu código
- De LLM a agente: el bucle de razonamiento y acción
- Frameworks de orquestación
