Clase 14 — Simulacro de Examen Completo (I)
Resumen Ejecutivo
Sesión dedicada íntegramente a un simulacro de examen completo: 10 preguntas tipo test + 1 pregunta de desarrollo con 3 subpreguntas. El profesor repasa la estructura y puntuación del examen real, comenta cada pregunta con los alumnos y resuelve dudas sobre cómo afrontar la pregunta de desarrollo. Antes de empezar, breve introducción a la herramienta Maisa, ejemplo de capa sobre LLMs que garantiza repetibilidad y trazabilidad mediante generación de código Python.
Conceptos Clave
- Estructura del examen real: 10 preguntas tipo test (4 pts) + 1 pregunta de desarrollo con 3 subpreguntas (6 pts). ⚠️ EXAMEN
- Tipo test: 10 preguntas × 0,4 pts = 4 pts.
- Desarrollo: 3 subpreguntas × 2 pts = 6 pts.
performativeen FIPA-ACL: único parámetro obligatorio en todos los mensajes ACL, independientemente del contexto. ⚠️ EXAMEN- Parámetros opcionales en FIPA-ACL:
ontology,conversation-id,receiver(en mensajes broadcast no hay receptor explícito). - Maisa: plataforma IA (Valencia) que actúa como capa sobre LLMs generalistas — descompone un problema en subproblemas, genera código Python al vuelo, y garantiza repetibilidad y trazabilidad de las respuestas.
- Prompt engineering vs. código: escribir un buen prompt no garantiza el 100 % de repetibilidad; el código generado sí permite auditabilidad ante reguladores.
Desarrollo del Temario
1. Introducción: Maisa y la capa sobre LLMs
El profesor introduce brevemente Maisa, una herramienta desarrollada en Valencia, antes de comenzar el simulacro.
El problema con los LLMs generalistas (ChatGPT, Claude, Gemini):
- Siempre responden, pero la calidad depende de la calidad del prompt.
- Nace la profesión de Prompt Engineer: redactar prompts ricos y completos para cubrir el mayor número de casos posibles.
- Limitación: con un prompt, aunque sea muy bueno, no se garantiza el 100 % de repetibilidad ni trazabilidad.
Cómo funciona Maisa:
- El usuario describe el problema en lenguaje natural.
- Maisa lo descompone en subproblemas más pequeños.
- Para cada subproblema, usa un LLM para generar código Python al vuelo.
- El código ejecutado es el registro trazable de lo que ocurrió.
Ventajas respecto al prompt directo:
| Prompt directo | Maisa (código Python) | |
|---|---|---|
| Repetibilidad | Parcial | Alta (mismo código = mismo resultado) |
| Trazabilidad / auditoría | Ninguna | Total (el código es el log) |
| Explicabilidad regulatoria | Difícil | Posible (puedes mostrar el código al auditor) |
"Es más importante que sea capaz de justificar ante un auditor o un regulador por qué he dado esa respuesta ante esa pregunta." — Profesor
2. Estructura y puntuación del examen ⚠️ EXAMEN
Examen = Tipo test (4 pts) + Desarrollo (6 pts) = 10 pts
Tipo test: - 10 preguntas. - Cada pregunta vale 0,4 pts. - Preguntas sobre conceptos, no memorización de términos.
Desarrollo: - 1 pregunta con 3 subpreguntas. - Cada subpregunta vale 2 pts. - Se presenta un escenario (contexto) del que se pueden extraer datos, pero lo esencial es responder a las preguntas aplicando los temas vistos.
Consejo del profesor para la parte de desarrollo:
"Aplicad el sentido común primero, y luego lo desarrolláis aplicando los temas que hemos visto. El escenario solo os da contexto; no os enrolléis con él."
3. Pregunta tipo test resuelta: FIPA-ACL — parámetro obligatorio ⚠️ EXAMEN
Pregunta: ¿Cuál es el único parámetro obligatorio en todos los mensajes FIPA-ACL independientemente del contexto?
Opciones discutidas:
- A)
receiver— descartado: en mensajes broadcast no hay receptor explícito. - B)
ontology— descartado: es opcional porque no todos los mensajes requieren una ontología predefinida. - C)
conversation-id— descartado: es útil para correlacionar mensajes, pero FIPA no lo impone como obligatorio; además, la especificación no dicta qué valor concreto debe tener. - D)
performative— CORRECTO.
Respuesta: performative (también llamado acto comunicativo o intención comunicativa).
Razonamiento: el performative indica el para qué del mensaje — INFORM, REQUEST, QUERY-IF, CFP, PROPOSE, ACCEPT-PROPOSAL, etc. Sin él, el mensaje no tiene significado semántico dentro del protocolo ACL. Es el único campo que FIPA exige siempre.
(inform
:sender agent1
:receiver agent2
:content "el precio es 100"
:ontology "mercado-ontologia" ; opcional
:conversation-id "conv-001" ; opcional
)
El performative (inform en el ejemplo) es lo único que no puede faltar.
4. Metodología para afrontar la pregunta de desarrollo
El profesor explica cómo estructurar la respuesta de desarrollo:
- Leer el escenario — extraer los datos que el enunciado da explícitamente.
- Identificar qué se pregunta — las 3 subpreguntas son independientes entre sí.
- Aplicar conceptos del temario — cada subpregunta apunta a uno o más temas de los 3 bloques.
- Desarrollar con sentido común — no inventar, pero sí razonar sobre el escenario.
- No extenderse en el escenario — el escenario es contexto, no hay que parafrasearlo.
Bloques del temario que pueden aparecer en el desarrollo:
| Bloque | Temas | Contenido |
|---|---|---|
| 1 | 1-4 | Conceptos de agentes, arquitecturas, comunicación básica |
| 2 | 5-8 | FIPA (estándares ACL, protocolos), JADE (plataforma), programación de agentes |
| 3 | 9-12 | Visión artificial, imágenes digitales, transformaciones, segmentación, reconocimiento de formas, PLN |
Preguntas Tipo Examen
- ¿Cuál es el único parámetro obligatorio en todos los mensajes FIPA-ACL? ¿Por qué los demás son opcionales?
- ¿Por qué el
conversation-idno es el parámetro obligatorio en FIPA-ACL, si es útil para correlacionar mensajes? - ¿Cuánto vale cada subpregunta de la parte de desarrollo del examen? ¿Y cada pregunta de tipo test?
- ¿Qué diferencia hay entre usar un LLM directamente con un prompt y una herramienta como Maisa en términos de repetibilidad y trazabilidad?
- En un mensaje FIPA-ACL de tipo broadcast (sin receptor específico), ¿qué parámetros están presentes obligatoriamente?
- Si en un examen el enunciado de desarrollo presenta un escenario largo, ¿qué parte del enunciado es lo realmente importante para responder?