Caso práctico II — Asistente corporativo con RAG y herramientas

Caso práctico II (Bloque II — IA Agéntica) — Asistente corporativo con RAG y herramientas

Asignatura: Deep Learning para Business Analytics — Comillas (ICADE). Profesor: Eduardo C. Garrido-Merchán · ecgarrido@comillas.edu. Curso: 2026–2027. Bloque: II — IA Agéntica (Temas 4–6, semanas 8–13). Modalidad: en grupo (los mismos grupos del proyecto final). Peso: caso práctico evaluado con la rúbrica común del curso (ver §8).

1. Contexto de negocio

Una organización grande (banca, energía, aseguradora, administración) tiene miles de empleados que pierden tiempo buscando en documentación interna: normativa, contratos, manuales de producto, procedimientos. BBVA ya tiene un copiloto interno para sus empleados; Iberdrola coordina agentes para mantenimiento y planificación. La dirección de datos os pide un asistente corporativo que responda preguntas sobre un corpus interno citando la fuente, que sepa usar al menos una herramienta externa (una búsqueda, una API, un cálculo) y que no invente: cuando no está en los documentos, lo dice.

El reto no es montar un chatbot bonito. Es construir un sistema medible y defendible: ¿con qué fiabilidad recupera el documento correcto? ¿cuánto cuesta por consulta? ¿dónde necesita un humano en el bucle (HITL)? ¿conviene RAG, fine-tuning, o ambos?

2. Objetivo

Construir un asistente sobre un corpus propio (≥ 30 documentos) que integre recuperación (RAG), uso de al menos una herramienta y una decisión de control (cuándo responder, cuándo abstenerse, cuándo escalar a humano). Medir la calidad de recuperación y la calidad de respuesta con métricas reproducibles, y argumentar la arquitectura frente a alternativas.

3. Alcance técnico mínimo

El sistema debe demostrar, como mínimo:

Ingesta + retrieval: troceado de documentos, embeddings, base vectorial, recuperación top-k. Puede ser 100 % local (Ollama + Chroma, receta del Día 15) o vía API; ambas valen y la elección se justifica por coste/latencia/privacidad.
Uso de herramienta: el agente invoca al menos una tool real (búsqueda, API de negocio, calculadora, lectura de fichero) y usa su salida en la respuesta. Patrón objetivo → razona → actúa → observa (Día 13).
Control y HITL: una política explícita de abstención o escalado cuando la evidencia recuperada es débil. No basta con responder siempre.
Medición: Recall@k (o hit-rate) sobre un conjunto de ≥ 10 preguntas con respuesta conocida, y una evaluación de faithfulness (¿la respuesta se apoya en lo recuperado o alucina?).

Opcionalmente, y suma en calidad técnica: reranking, multi-agente (un agente que delega en otro), o una adaptación ligera (LoRA/SFT) comparada contra RAG puro.

4. Datos sugeridos

Corpus propio del grupo (lo ideal: documentación de un sector real, anonimizada) o, del repositorio validado:

EUR-Lex (legislación europea) o BOE (legislación española) — asistente de cumplimiento normativo. https://eur-lex.europa.eu · https://www.boe.es/datosabiertos/
SEC Edgar (reportes financieros) — RAG financiero / due diligence. https://www.sec.gov/edgar/searchedgar/companysearch
MS MARCO — para entrenar/evaluar el retriever o un reranker. https://microsoft.github.io/msmarco/
Wikipedia en español — RAG y evaluación de modelos abiertos en castellano. https://huggingface.co/datasets/wikimedia/wikipedia

Restricciones de dataset propio: §10 del repositorio (datasets/README.md).

5. Qué se entrega

Una carpeta comprimida grupoNN_caso_2.zip con:

Memoria (memoria_caso_2.pdf, máx. 6 páginas): problema, arquitectura (diagrama del flujo agente ↔︎ herramientas ↔︎ retrieval), corpus, protocolo de evaluación, resultados, coste por consulta y recomendación. Incluye la tabla del §7.
Prototipo funcional (caso_2/ con código y README de arranque): debe levantarse con instrucciones claras y responder a una consulta de demo en local o con la clave del propio grupo. Semillas fijadas donde aplique.
Conjunto de evaluación (eval_set.jsonl): las ≥ 10 preguntas con su respuesta/documento esperado, para que el resultado sea reproducible.
Slides de defensa (caso_2_slides.pdf, 6–8 diapositivas) para 8 minutos.
Declaración de IA (DECLARACION_IA.md).

6. Tareas

6.1 — Ingesta y retrieval (técnica). Construir la base vectorial y medir Recall@5 sobre el conjunto de evaluación. Reportar el número.
6.2 — Agente con herramienta (técnica). Conectar al menos una tool y mostrar una traza completa (objetivo, llamada, observación, respuesta).
6.3 — Control / HITL (técnica + negocio). Implementar y justificar la política de abstención o escalado. Mostrar un caso donde el sistema se niega a responder correctamente.
6.4 — Faithfulness y coste (negocio). Evaluar cuántas respuestas se apoyan de verdad en lo recuperado y estimar el coste por consulta (tokens o tiempo). ¿Cuánto ahorra de tiempo de empleado? ROI.
6.5 — Análisis SIN IA (condición de aprobación). Ver §9.

7. Tabla Concepto → Aplicación → Entradas → Salidas → KPI

Concepto	Aplicación	Entradas	Salidas	KPI
RAG corporativo	Búsqueda interna citada	Consulta + corpus	Respuesta + fuentes	Recall@5; faithfulness
Uso de herramienta	Acción real del agente	Objetivo + tool	Observación usada	% consultas que invocan tool con éxito
Control / HITL	Evitar la alucinación cara	Evidencia recuperada	Responder / abstenerse / escalar	% abstenciones correctas; coste/consulta

8. Rúbrica común del curso (10 pts → escala 0–10)

Dimensión	Peso	Qué se valora
Calidad técnica	30 %	Retrieval + agente + control funcionan; métricas reproducibles; código que arranca.
Relevancia de negocio	25 %	Problema bien planteado, KPI alineado, coste/ROI argumentado.
Comunicación	20 %	Slides claras, diagrama de arquitectura legible, narrativa, tiempo respetado.
Defensa oral	15 %	Respuestas correctas, dominio del sistema, capacidad de explicar la traza.
Trazabilidad de IA	10 %	Herramientas declaradas, prompts conservados cuando proceda.

Esta rúbrica es idéntica en los tres casos y en el proyecto final.

9. Sección sin IA (obligatoria, condición de aprobación)

El §6.5 se redacta y se defiende sin ninguna herramienta de IA generativa. Una página de autoría propia que responda, frente a la directora de datos:

RAG vs fine-tuning para vuestro caso. ¿Por qué elegisteis lo que elegisteis? ¿Cuándo cambiaría la respuesta? (la pregunta exacta del Día 15, ahora aplicada a vuestro sector).
El riesgo de la alucinación con autoridad. ¿Qué pasa si el asistente responde con seguridad algo falso a un empleado que actúa en consecuencia? ¿Cómo lo mitiga vuestra política de control?
Dónde NO pondríais el agente. Una tarea de vuestro sector donde un asistente de este tipo sería irresponsable, y por qué.

El profesor preguntará sobre esta sección en la defensa. Texto generado por IA o incapacidad de defenderlo sin IA = cero en el caso (regla C, Día 01).

10. Política de IA

Permitida y fomentada para el código, los prompts del sistema y las slides, con declaración de trazabilidad. Es además el caso donde más se espera que uséis agentes (Claude Code / opencode) para construir: declaradlo. Prohibida solo en la sección §9.

11. Fechas

Publicación: semana 11 (durante el Tema 6).
Entrega: fin de la semana 13, antes del Bloque III.
Defensa oral: en clase, semana 13 (8 minutos por grupo + preguntas).
Feedback: una semana tras la defensa.

12. Ayudas

Foro primero, profesor después. La receta RAG canónica del Día 15 y el primer agente del Día 13 son el andamiaje directo de este caso. Las 4 horas de mentorización del proyecto cubren también dudas de aquí.