Capítulo 9 — Programación II
Mapa de la lección
Lección 09 publicada. Mapa, ejemplo, EX025.
flowchart TD
N0["Resultados de aprendizaje"]
N1["9.1 Módulos e interfaces"]
N2["9.2 Dependencias y cadena de suministro"]
N3["9.3 Pruebas más allá de los ejemplos"]
N4["9.4 Un entorno de evaluación"]
N5["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX025"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje"]
N1["9.1 Módulos e interfaces"]
N2["9.2 Dependencias y cadena de suministro"]
N3["9.3 Pruebas más allá de los ejemplos"]
N4["9.4 Un entorno de evaluación"]
N5["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX025"]
[Resultados de aprendizaje]
|
v
[9.1 Módulos e interfaces]
|
v
[9.2 Dependencias y cadena de suministro]
|
v
[9.3 Pruebas más allá de los ejemplos]
|
v
[9.4 Un entorno de evaluación]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX025]
Resultados de aprendizaje
Usted será capaz de (1) estructurar programas más grandes en módulos con interfaces claras; (2) gestionar las dependencias y sus riesgos de cadena de suministro; (3) escribir pruebas, incluidas las basadas en propiedades y las de regresión; y (4) construir un pequeño entorno de evaluación para un componente de IA.
9.1 Módulos e interfaces
Los programas grandes se dividen en módulos con interfaces estrechas. En los sistemas de IA, separe la carga de datos, la inferencia del modelo, la aplicación de la política y la ejecución de herramientas. El módulo de política debe ser pequeño, revisable e independiente del modelo: decide lo que está permitido con independencia de lo que diga el modelo. Es la forma en software del mínimo privilegio. Si la política depende del propio juicio del modelo, una inyección de prompts que tenga éxito también burla la política. Mantenerla en código separado hace que aplique las mismas reglas sea cual sea la forma en que se persuadió al modelo. Las interfaces estrechas también hacen posibles las revisiones: un revisor puede leer con atención un módulo de 80 líneas, pero no un sistema cuyas comprobaciones están repartidas entre prompts y scripts.
9.2 Dependencias y cadena de suministro
Los proyectos de IA incorporan muchas bibliotecas y archivos de modelos. Fije las versiones, verifique los hashes y prefiera la serialización segura: cargar archivos pickle no confiables en Python puede ejecutar código arbitrario, y por eso se prefieren, para los pesos de los modelos, formatos diseñados para contener solo tensores. OWASP LLM 2025 incluye la cadena de suministro (LLM03) y el envenenamiento de datos y modelos (LLM04). Gu et al. (arXiv:1708.06733) mostraron que un modelo con puerta trasera obtenido de un tercero puede comportarse con normalidad ante entradas limpias.
Fijar las versiones impide que una actualización cambie el comportamiento en silencio, y la comprobación de hashes impide cargar un archivo sustituido. Un modelo con puerta trasera es más difícil: puede superar todas las pruebas ordinarias, porque su comportamiento dañino solo aparece con un disparador concreto. Los ingenieros reducen este riesgo prefiriendo fuentes con procedencia publicada, registrando de dónde procede cada modelo y probando si hay comportamientos inesperados con entradas ajenas a la distribución habitual.
9.3 Pruebas más allá de los ejemplos
Las pruebas de regresión congelan el comportamiento conocido como correcto para que los cambios no puedan romperlo en silencio. Las pruebas basadas en propiedades generan muchas entradas y comprueban invariantes («la política nunca permite create_work_order sin un indicador de confirmación»). Para los componentes de IA, un conjunto dorado de entradas con salidas esperadas detecta la deriva de comportamiento cuando cambia un modelo o un prompt. Cada tipo detecta algo distinto. Las pruebas de regresión impiden que vuelvan fallos antiguos, las pruebas de propiedades encuentran entradas en las que nadie había pensado, y los conjuntos dorados muestran cuándo la edición de un prompt o la actualización de un modelo cambia respuestas que antes eran correctas. Los conjuntos dorados requieren cuidado, porque las salidas de los modelos varían; Sam comprueba propiedades de las respuestas, como qué herramienta se propuso, en lugar de la redacción exacta.
9.4 Un entorno de evaluación
Un entorno de evaluación carga un conjunto de prueba, ejecuta el componente, registra las salidas y calcula métricas con intervalos. Debe ser determinista dada una semilla, registrar las versiones (hash del modelo, versión del prompt, commit del código) y mantener los datos de prueba separados de los de desarrollo. Sin versiones registradas, un resultado no puede vincularse al sistema que describe, y una regresión posterior no puede rastrearse. El determinismo hace comparables las nuevas ejecuciones, de modo que un cambio en las métricas refleja un cambio en el sistema y no en el muestreo aleatorio. Mantener separados los datos de prueba y de desarrollo impide ajustar el sistema con los mismos ejemplos que se usan para juzgarlo, lo que haría que los resultados parecieran mejores de lo que son.
9.5 Ejemplo resuelto (caso sintético de NRS)
Sam reestructuró Wrench en cuatro módulos. El módulo policy (80 líneas) comprueba cada llamada a herramienta propuesta frente al rol del usuario y exige un token de confirmación para las órdenes de trabajo. Una prueba basada en propiedades generó 10.000 solicitudes aleatorias de llamadas a herramientas y confirmó que ninguna pasaba sin token. La revisión de dependencias encontró un script de conversión de modelos que cargaba archivos pickle desde una carpeta compartida; Sam lo sustituyó por un cargador de un formato solo de tensores y añadió la verificación de hashes. La prueba de propiedades muestrea el espacio de llamadas a herramientas de forma mucho más amplia de lo que permitirían los casos escritos a mano, aunque no demuestra que no exista ninguna llamada insegura.
9.6 Errores y límites
- Lógica de política incrustada en los prompts en lugar de en el código.
- Dependencias sin fijar y archivos de modelos sin verificar.
- Conjuntos dorados reutilizados para el ajuste (dejan de detectar la deriva).
Una política escrita en un prompt puede sortearse mediante la entrada del modelo; una política en código, no. Las dependencias sin fijar hacen que los resultados de las pruebas de ayer no signifiquen nada hoy. Un conjunto dorado usado durante el ajuste deja poco a poco de ser una comprobación independiente, porque el sistema se ha adaptado a él. Sam conserva un segundo conjunto, intacto, para las decisiones de publicación y lo renueva cuando cambia el uso del sistema.
Ejercicios — capítulo 9
- EX025 — División en módulos. Proponga una estructura de módulos para un asistente basado en LLM con herramientas y diga qué módulo aplica la seguridad. Rúbrica: 3 = datos, inferencia, política, herramientas; política fuera del modelo; 2 = parcial; 1 = vago; 0 = nada.
- EX026 — Pickle. ¿Por qué es peligroso cargar un modelo no confiable en formato pickle, y cuál es la alternativa? Rúbrica: 3 = ejecución de código arbitrario al cargar; formato solo de tensores más verificación de hash; 2 = una parte; 1 = vago; 0 = incorrecto.
- EX027 — Prueba de propiedades. Escriba en una frase el invariante que probó Sam y otro invariante más. Rúbrica: 3 = ambos precisos; 2 = uno; 1 = vago; 0 = nada.
Síntesis del capítulo
Una buena estructura sitúa las decisiones de seguridad en código pequeño y comprobable fuera del modelo; la disciplina con las dependencias y las pruebas mantiene esa estructura digna de confianza a medida que el sistema crece.
Siga estudiando — capítulo 09 de 50
← Capítulo 08 (borrador) · Índice de capítulos del curso · Capítulo 10 (borrador) →