Saltar al contenido principal

Curso completo

Desarrollador Backend + IA

Capacidades de IA en sistemas backend fiables

APIs de LLM, RAG, herramientas, colas, observabilidad, evaluación y arquitectura de producción.

Termina el curso con algo más que una demo que sobrevive a una única solicitud correcta: construye un paquete de evidencias de producción para un backend de IA con contratos tipados, reintentos e idempotencia, streaming controlado, RAG con comprobaciones de ACL y frescura, acciones de herramientas acotadas, puerta de evaluación, observabilidad, presupuestos de coste y una ruta de rollback probada.

0%0/9 lecciones

El progreso se guarda localmente en tu navegador.

10–16 semanas3 módulos9 lecciones1 evaluaciones

Sistema operativo de estudio

Cómo completar el curso y conservar un resultado real

1. Empezar por el contrato

Para cada función de IA define primero el esquema de entrada/salida, presupuesto de timeout, política de reintentos, clave de idempotencia, taxonomía de errores y fuente autoritativa. Un prompt sin contrato de transporte y aplicación todavía no es un backend.

2. Reproducir el fallo

Añade al happy path timeout, 429/5xx del proveedor, salida estructurada malformada, solicitud duplicada, cancelación del cliente y retrieval obsoleto. Cada fallo debe terminar en un estado de sistema predecible.

3. Verificar el efecto lateral

Si el modelo propone una acción de herramienta, la capa de aplicación verifica de forma independiente identidad, autoridad, esquema, precondiciones e idempotencia. El texto del modelo no es permiso para ejecutar una acción.

4. Conservar evidencia de producción

Registra trazas, latencia, reintentos, evidencia de retrieval, decisiones de herramientas, coste por tarea exitosa y resultados de regresión. “Respondió en local” es un stack de observabilidad sorprendentemente modesto.

Reglas del curso

No basta con leer: hay que demostrarlo

  • HTTP 200 del proveedor del modelo no significa que el resultado de dominio sea correcto; transporte, esquema, semántica y autoridad se validan en capas separadas.
  • Retry sin idempotencia y reconciliación genera efectos laterales duplicados; no es un patrón de reliability.
  • No otorgues al modelo autoridad que el caller autenticado no posee; un tool schema no sustituye una comprobación de permisos.
  • Evalúa RAG por separado en retrieval y respuesta: una respuesta relevante desde el ACL scope de otra persona sigue siendo un fallo.
  • Después de un incidente de producción, la reproducción mínima se convierte en un caso de regresión permanente antes del siguiente cambio de modelo, prompt, retrieval o herramienta.

Módulo 1

Núcleo común de IA

Fundamentos y control de los resultados.

ResultadoUso seguro y verificable de la IA.
  1. Alfabetización en IA y límites de los modelos

    Principal

    Capacidades, alucinaciones, límites de contexto, privacidad y uso responsable.

  2. Ingeniería de prompts y contexto

    Principal

    Instrucciones, restricciones, ejemplos y verificación de resultados.

    Prerrequisitos: Alfabetización en IA y límites de los modelos

  3. Salidas estructuradas y evaluación

    Principal

    Esquemas de respuesta, checks deterministas y casos de prueba.

    Prerrequisitos: Ingeniería de prompts y contexto

Checkpoint después del módulo

Línea base del contrato backend de IA

  • ✓ los contratos de entrada/salida y la taxonomía de fallos están documentados
  • ✓ cada respuesta de IA tiene una señal de verificación definida
  • ✓ los límites de privacidad y autoridad están marcados antes de la integración

Laboratorio de transferencia de escenario

Laboratorio de transferencia: convertir un endpoint de IA en un contrato backend

Toma un endpoint que hoy solo reenvía un prompt al modelo. Descompónlo en contrato de transporte, contrato del modelo, verificación, límite de datos y estados de fallo para que otro ingeniero backend pueda implementar el cliente sin conocer el prompt mágico.

Entregable

Contrato API + diagrama de secuencia + matriz de fallos con timeout, retry, salida malformada, cancelación, límite de privacidad y propietario de cada comprobación autoritativa.

  • ✓ la validación de esquema ocurre antes de la lógica de dominio
  • ✓ retry solo está permitido para clases de fallo definidas explícitamente
  • ✓ el límite de privacidad y autoridad no se delega al prompt
  • ✓ los campos críticos tienen una señal de verificación determinista o autoritativa

Módulo 2

Integración de APIs LLM

Contratos, streaming y fiabilidad.

ResultadoUn cliente de IA listo para producción.
  1. Contratos de API LLM

    Principal

    Esquemas tipados, validación, timeouts, reintentos e idempotencia.

  2. Streaming y backpressure

    Principal

    Respuestas parciales, cancelación y control de flujo.

  3. Proyecto: API de IA en producción

    Proyectopráctica + evaluación

    Salidas estructuradas, reintentos, trazas, pruebas e informe de costes.

Checkpoint después del módulo

Cliente resiliente para API de LLM

  • ✓ timeouts, reintentos, backoff y cancelación tienen pruebas ejecutables
  • ✓ una solicitud duplicada no crea un efecto lateral duplicado
  • ✓ la salida estructurada se valida antes de la lógica de dominio y el streaming no evita la validación final

Laboratorio de transferencia de escenario

Laboratorio de transferencia: reintentos, idempotencia y streaming bajo carga

Construye un cliente resiliente para API de IA y rompe deliberadamente la red y la ruta del proveedor: 429, 5xx, stream lento, desconexión tras una respuesta parcial y solicitud repetida después de un resultado desconocido. Demuestra que retry no multiplica efectos laterales ni oculta un fallo terminal.

Entregable

Cliente ejecutable + pruebas de inyección de fallos + informe de trazas con intentos, backoff, cancelación, clave de idempotencia, estado final, latencia p95 y coste por tarea exitosa.

  • ✓ la entrega duplicada no crea una escritura o acción duplicada
  • ✓ la cancelación del cliente realmente detiene o reconcilia el trabajo
  • ✓ la salida parcial del stream nunca se trata como resultado final validado
  • ✓ latencia y coste se miden por tarea exitosa incluyendo reintentos

Módulo 3

RAG, herramientas y producción

Conocimiento, acciones, quality gates y monitorización.

ResultadoUna función de IA con SLO, evaluaciones y rollback.
  1. Arquitectura de servicio RAG

    Principal

    Retrieval, citas, ACL y frescura.

  2. Tool calling y permisos

    Principal

    Herramientas tipadas, aprobaciones y audit trail.

  3. Hito: función de IA en producción

    Hito

    Evaluaciones, revisión de seguridad, monitorización y rollback.

Checkpoint después del módulo

Función de IA de producción gobernada

  • ✓ RAG comprueba ACL, frescura y citas
  • ✓ las acciones de herramientas tienen autoridad explícita y una postcondición autoritativa
  • ✓ las puertas de calidad, latencia, coste y seguridad pueden detener el rollout y el rollback está probado

Laboratorio de transferencia de escenario

Laboratorio de transferencia: RAG + acción de herramienta con puerta de producción

Construye un flujo backend donde retrieval forma un paquete de evidencia, el modelo propone una acción de herramienta acotada y la capa de aplicación verifica permiso y estado final. Después cambia retrieval o la configuración del modelo y ejecuta regresiones antes del canary.

Entregable

Traza end-to-end: identidad → consulta → ACL/filtro → evidencia ordenada → decisión estructurada → precondiciones de herramienta → acción → postcondición autoritativa → resultado de evaluación → decisión de release.

  • ✓ retrieval no devuelve un ACL scope prohibido y la evidencia obsoleta tiene una política explícita
  • ✓ la salida del modelo no ejecuta una herramienta sin comprobación de autoridad en la aplicación
  • ✓ el efecto lateral queda confirmado por una postcondición autoritativa o pasa a estado de reconciliación
  • ✓ una regresión crítica bloquea el rollout independientemente de lo bonita que sea la demo

Contrato capstone

Capstone: servicio backend de IA gobernado

Construye una función de IA estilo producción como servicio backend con contrato API, etapa de proveedor/modelo, retrieval o herramientas, controles deterministas, evaluación, observabilidad y rollback. El objetivo es demostrar comportamiento controlado ante fallos, no crear otro chat con tema oscuro.

Qué entregar

  • — contrato OpenAPI o API tipada, esquemas de dominio, taxonomía de errores y política de timeout/retry/idempotencia
  • — arquitectura + diagrama de secuencia con límites de identidad, datos, modelo, retrieval/herramientas y sistema autoritativo
  • — suite ejecutable de inyección de fallos para 429/5xx, timeout, cancelación, salida malformada, entrega duplicada, retrieval obsoleto y efectos laterales parciales
  • — evidencia RAG/herramientas para ACL, frescura y citas o trazas de permiso, precondición y postcondición
  • — dataset de evaluación + informe de regresión con umbrales de calidad, seguridad y corrección de dominio
  • — paquete de observabilidad con latencia, errores, reintentos, coste de tokens/proveedor, coste por tarea exitosa y trazas muestreadas
  • — rollout por etapas + criterios de canary, rollback y kill + runbook de incidente a regresión

Cuándo puede considerarse terminado

  • ✓ la API devuelve un resultado de dominio validado o un fallo tipado controlado, no “casi JSON”
  • ✓ retry, idempotencia y reconciliación evitan efectos laterales duplicados ocultos
  • ✓ la ruta RAG/herramientas conserva identidad, ACL y límites de autoridad desde la solicitud hasta el estado final
  • ✓ una regresión crítica de calidad o seguridad bloquea el release antes del canary
  • ✓ SLO y presupuesto se evalúan por tarea exitosa incluyendo reintentos y coste de revisión
  • ✓ rollback o fallback restaura un envelope conocido y funcional y conserva evidencia de auditoría

Práctica final y evaluación

El curso termina con un artefacto práctico y una rúbrica de aceptación. El resultado se considera completo después de cumplir los criterios de aceptación, no solo de leer los materiales.