Capítulo 8 — Programación II
Mapa de la lección
Lección 08 publicada. Mapa, ejemplo, EX022.
flowchart TD
N0["Resultados de aprendizaje"]
N1["8.1 Módulos y responsabilidades"]
N2["8.2 JSON y archivos"]
N3["8.3 Paquetes y archivos de modelo"]
N4["8.4 Pruebas adversarias"]
N5["8.6b Pruebas que protegen el analizador"]
N6["Síntesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX022"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje"]
N1["8.1 Módulos y responsabilidades"]
N2["8.2 JSON y archivos"]
N3["8.3 Paquetes y archivos de modelo"]
N4["8.4 Pruebas adversarias"]
N5["8.6b Pruebas que protegen el analizador"]
N6["Síntesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX022"]
[Resultados de aprendizaje]
|
v
[8.1 Módulos y responsabilidades]
|
v
[8.2 JSON y archivos]
|
v
[8.3 Paquetes y archivos de modelo]
|
v
[8.4 Pruebas adversarias]
|
v
[8.6b Pruebas que protegen el analizador]
|
v
[Síntesis]
|
v
[Ejemplo resuelto] --> [Ejercicio EX022]
Resultados de aprendizaje
Usted podrá (1) organizar programas en módulos y funciones con responsabilidades claras; (2) usar JSON y archivos de forma segura; (3) gestionar paquetes de terceros y archivos de modelo con comprobaciones de integridad; y (4) escribir pruebas que incluyan casos adversarios.
8.1 Módulos y responsabilidades
Divida los programas de modo que cada parte tenga una sola tarea. En una aplicación con LLM: tratamiento de la entrada, recuperación, llamada al modelo, comprobación de políticas, ejecución de herramientas, registro. Mantener la comprobación de políticas en su propio módulo pequeño significa que puede revisarse y probarse con independencia del modelo. La separación también limita el daño: si se manipula el módulo de recuperación para que devuelva un documento hostil, la comprobación de políticas sigue decidiendo por su cuenta si se permite cualquier llamada a herramientas que resulte de ello. En Ask Lumen, las comprobaciones de reservas que Rina escribió en el capítulo de programación viven en un módulo así, con pruebas que se ejecutan en cada cambio. Un revisor puede leer el módulo completo en pocos minutos.
8.2 JSON y archivos
Analice los datos estructurados con analizadores estrictos (json.loads) y valide campos, tipos y rangos. Rechace los campos desconocidos. Nunca use eval sobre datos. Cuando se pide al modelo que produzca JSON, valídelo de la misma manera, porque el modelo puede producir salidas mal formadas o manipuladas. En Ask Lumen, se pide al modelo que devuelva una reserva como JSON con un código de clínica, una fecha y un identificador de paciente. El analizador rechaza cualquier campo adicional, como una instrucción para cancelar otras citas, y cualquier valor fuera de los rangos permitidos. Una respuesta mal formada lleva a un mensaje de fallo cortés para el paciente, nunca a una acción parcial.
8.3 Paquetes y archivos de modelo
Instale paquetes desde fuentes de confianza y con versiones fijadas. Los archivos de modelo son riesgos parecidos al código: algunos formatos de serialización pueden ejecutar código al cargarse. Verifique el hash SHA-256 de un archivo contra un manifiesto de confianza antes de cargarlo; el laboratorio detecta así la manipulación.
"""Lab H: integrity of model artefacts with SHA-256 manifests (stdlib only).
Creates synthetic 'artefact' bytes, records a manifest, then detects a
one-byte tampering and a swapped file. No real models are involved."""
import hashlib, json
files = {"model.bin": bytes(range(256)) * 40, "tokenizer.json": b'{"vocab": ["a", "b"]}',
"config.yaml": b"layers: 4\nheads: 8\n"}
manifest = {n: hashlib.sha256(b).hexdigest() for n, b in files.items()}
print(json.dumps({k: v[:16] for k, v in manifest.items()}, indent=1))
received = dict(files)
tampered = bytearray(received["model.bin"]); tampered[5000] ^= 1
received["model.bin"] = bytes(tampered)
received["config.yaml"] = b"layers: 4\nheads: 8\ntrust_remote_code: true\n"
for n, b in sorted(received.items()):
ok = hashlib.sha256(b).hexdigest() == manifest[n]
print(f"{n:15s} {'OK' if ok else 'MISMATCH'}")
Salida esperada:
{
"model.bin": "e96760a87768717b",
"tokenizer.json": "f63d2ddabc61f2d9",
"config.yaml": "e5bbb570ca0fcb87"
}
config.yaml MISMATCH
model.bin MISMATCH
tokenizer.json OK
En el Laboratorio H, un solo bit invertido en model.bin y una línea añadida en config.yaml cambian sus hashes, mientras que el tokenizer.json intacto sigue coincidiendo. El manifiesto debe proceder de una fuente de confianza, como la versión firmada del proveedor; de lo contrario, un atacante que cambie un archivo podría cambiar también el manifiesto.
8.4 Pruebas adversarias
Añada pruebas que intenten romper su código: entradas de tamaño excesivo, tipos incorrectos, cadenas con forma de inyección, peticiones de datos de otros usuarios. Manténgalas de forma permanente en el conjunto de pruebas. Para el analizador de reservas, las pruebas adversarias incluyen una fecha escrita con palabras, un identificador de paciente que pertenece a otra persona, un código de clínica con espacios al final y una salida del modelo que contiene dos reservas. Cada prueba registra el rechazo esperado. Una vez añadidas, estas pruebas protegen contra las regresiones: un cambio posterior que relaje sin querer una comprobación falla de inmediato, antes de llegar a los pacientes.
8.5 Ejemplo resuelto (caso sintético de LCH)
El proveedor de DocSort envió un modelo actualizado. La comprobación de integridad de Rina comparó el hash con el manifiesto firmado del proveedor y encontró una discrepancia en el archivo de configuración. La investigación mostró que un contratista había editado el archivo para activar un modo de depuración que registraba el texto completo de las cartas. El cambio se revirtió, y LCH exigió que todos los cambios de modelo llegaran por el proceso de publicación firmada. El modo de depuración se corresponde en espíritu con la línea de configuración manipulada del Laboratorio H: un pequeño cambio de texto con un gran efecto sobre la privacidad.
8.6 Errores y límites
- Lógica de políticas mezclada con el texto de la instrucción.
- Cargar archivos de modelo sin comprobaciones de integridad.
- Pruebas solo con entradas benignas.
Una política escrita en la instrucción puede desmontarse con un mensaje astuto, mientras que una política en el código no. Cargar archivos de modelo sin comprobar los hashes habría permitido que el modo de depuración del contratista llegara a producción en LCH. Las pruebas solo con entradas benignas pasan incluso cuando el analizador acepta salidas peligrosas; el archivo de pruebas hostiles del analizador de reservas existe precisamente para evitarlo, y crece con cada incidente.
8.6b Pruebas que protegen el analizador
El módulo que convierte la salida del modelo en una petición de reserva es el código más relevante para la seguridad de Ask Lumen, porque una respuesta mal formada o manipulada podría cancelar la cita equivocada. LCH mantiene un archivo de pruebas con salidas hostiles —campos adicionales, fechas erróneas, dos identificadores de cita— y todo cambio en el analizador debe superarlo antes de fusionarse. Cada salida hostil del archivo procede de un fallo real o de un hallazgo de revisión, así que el archivo registra la historia de ataques al analizador además de protegerlo de ellos. Cuando aparece un nuevo tipo de fallo, se añade una prueba para él antes de la corrección.
Ejercicios
- EX022 — Lectura del laboratorio. ¿Qué archivos fallan la comprobación de hash en el laboratorio y por qué? Rúbrica: 3 = model.bin y config.yaml, ambos modificados; 2 = uno; 1 = vago; 0 = incorrecto.
- EX023 — Validación de JSON. Enumere cuatro comprobaciones para el JSON de reserva producido por el modelo. Rúbrica: 3 = JSON válido, solo campos permitidos, tipos, rangos/titularidad; 2 = tres; 1 = una o dos; 0 = nada.
- EX024 — Modo de depuración. ¿Por qué el cambio al modo de depuración era un problema de seguridad? Rúbrica: 3 = registraba datos de salud sensibles, lo que ampliaba la exposición; cambio no autorizado; 2 = parcial; 1 = vago; 0 = incorrecto.
Síntesis
Los programas estructurados, el análisis estricto, las dependencias verificadas y las pruebas adversarias hacen que las aplicaciones de IA sean más difíciles de romper y más fáciles de confiar.
Siga estudiando — capítulo 08 de 40
← Capítulo 07 (borrador) · Índice de capítulos del curso · Capítulo 09 (borrador) →