UD5 · Validación y puesta en servicio

Objetivos de la unidad

Al finalizar esta unidad el alumno sera capaz de:

• Disenar y ejecutar un conjunto de casos de prueba representativo para una solucion basada en LLMs.
• Verificar la calidad de las respuestas segun criterios de pertinencia, coherencia, completitud, trazabilidad y formato.
• Ajustar la solucion —instrucciones, parametros, contexto y fuentes— a partir de los resultados de las pruebas.
• Documentar el proceso de validacion y formalizar la puesta en servicio con los artefactos tecnicos requeridos.

1 · Casos de prueba: definicion y diseno (I)

Por que los casos de prueba son diferentes en LLMs

Los sistemas basados en LLMs no producen salidas deterministas. La validacion no puede limitarse a comparar un resultado esperado exacto: requiere definir criterios de calidad y cubrir el espacio de entradas posibles de forma sistematica.

Un conjunto de casos de prueba solido incluye:

1 · Casos de prueba: definicion y diseno (II)

Estructura de un caso de prueba

Cada caso de prueba debe documentarse con los siguientes campos:

ID:          TC-001
Categoria:   Entrada representativa
Descripcion: Pregunta directa sobre un procedimiento documentado
Entrada:     "¿Cuál es el procedimiento de alta de un proveedor nuevo?"
Contexto:    Fragmento del manual de procedimientos, sección 4.2
Resultado esperado (criterio):
  - La respuesta menciona los pasos 1-5 de la sección 4.2
  - Cita la fuente (sección y número de página)
  - No incluye información de otras secciones
  - Formato: lista numerada
Resultado obtenido: [a completar en ejecucion]
Estado:      PASS / FAIL / PARCIAL
Observaciones:

1 · Casos de prueba: definicion y diseno (III)

Cobertura minima recomendada por categoria

Para un sistema en produccion, el conjunto de pruebas debe garantizar cobertura en todas las categorias. Una distribucion orientativa:

La cobertura no es solo cuantitativa: es mas valioso un caso de prueba que detecta un fallo real que diez que repiten el mismo escenario exitoso.

2 · Evaluacion de soluciones conversacionales (I)

Mantenimiento de contexto en sistemas multiturno

En soluciones conversacionales, la validacion debe evaluar la coherencia a lo largo de la sesion, no solo en respuestas aisladas:

Pruebas de memoria de sesion:

• El sistema recuerda informacion proporcionada en turnos anteriores.
• Las referencias anaforigas se resuelven correctamente ("el contrato del que hablamos antes").
• El historial no contamina la respuesta cuando el tema cambia.

Pruebas de acumulacion de contexto:

• La calidad no degrada al acercarse al limite de la ventana de contexto.
• El sistema no confunde informacion de diferentes documentos proporcionados en la misma sesion.

# Ejemplo: prueba automatizada de coherencia multiturno
turnos = [
    {"role": "user", "content": "Mi pedido es el numero 12345."},
    {"role": "assistant", "content": "..."},
    {"role": "user", "content": "¿Cuál es su estado?"},
]
# La respuesta al segundo turno debe referenciar el pedido 12345
# sin que el usuario lo repita

2 · Evaluacion de soluciones conversacionales (II)

Respuestas fuera de alcance

Uno de los comportamientos mas criticos a validar es la respuesta del sistema cuando recibe una solicitud que esta fuera de su ambito definido:

Indicador de calidad: el porcentaje de respuestas fuera de alcance que el sistema gestiona correctamente (sin inventar, sin ignorar la limitacion) es un KPI clave de robustez.

3 · Verificacion de calidad de las respuestas (I)

Las cinco dimensiones de evaluacion

Toda respuesta generada por el sistema se evalua segun estas dimensiones:

3 · Verificacion de calidad de las respuestas (II)

Evaluacion automatica con LLM-as-judge

Cuando el volumen de pruebas es alto, la evaluacion manual no escala. El patron LLM-as-judge usa un modelo de evaluacion para puntuar las respuestas:

import anthropic

client = anthropic.Anthropic()

def evaluar_respuesta(pregunta: str, respuesta: str, referencia: str) -> dict:
    prompt = f"""Evalúa la siguiente respuesta según estos criterios (0-3 cada uno):
- Pertinencia: ¿responde a la pregunta?
- Coherencia: ¿es lógicamente consistente?
- Completitud: ¿incluye la información relevante de la referencia?
- Trazabilidad: ¿cita las fuentes?

Pregunta: {pregunta}
Respuesta a evaluar: {respuesta}
Referencia: {referencia}

Devuelve un JSON con las puntuaciones y una justificación breve."""

    mensaje = client.messages.create(
        model="claude-opus-4-5",
        max_tokens=512,
        messages=[{"role": "user", "content": prompt}]
    )
    return mensaje.content[0].text

3 · Verificacion de calidad de las respuestas (III)

Umbrales de aceptacion y criterios de rechazo

Los criterios de aceptacion deben definirse antes de ejecutar las pruebas, no despues:

CRITERIOS DE ACEPTACION — Sistema de consulta de procedimientos

Pertinencia:    >= 2.5 / 3.0 en promedio; ningun caso con 0
Coherencia:     100 % de casos >= 2.0 / 3.0
Completitud:    >= 2.0 / 3.0 en promedio
Trazabilidad:   >= 90 % de respuestas incluyen referencia a la fuente
Formato:        100 % de respuestas validas segun el schema definido

CONDICIONES DE RECHAZO AUTOMATICO:
- Cualquier respuesta que invente informacion no presente en el contexto
- Cualquier respuesta que ignore una instruccion de seguridad del system prompt
- Tasa de error de formato > 5 %

Los criterios de aceptacion son el contrato entre el desarrollador y el cliente. Deben acordarse antes de la validacion.

4 · Ajustes sobre la solucion (I)

Tipos de ajuste y cuando aplicarlos

Cuando un caso de prueba falla, el ajuste debe dirigirse a la causa raiz:

4 · Ajustes sobre la solucion (II)

Registro de versiones probadas

Cada ciclo de ajuste genera una nueva version del sistema. El registro de versiones es imprescindible para rastrear la evolucion:

VERSION   FECHA       CAMBIO APLICADO                        RESULTADO
----------------------------------------------------------------------
v0.1      2025-01-10  System prompt inicial                  Pertinencia: 1.8; Formato: 72 %
v0.2      2025-01-12  Agregar ejemplo few-shot de formato    Pertinencia: 2.1; Formato: 91 %
v0.3      2025-01-14  Reducir temperatura 0.7 → 0.3          Coherencia: 2.6; Variabilidad -40 %
v0.4      2025-01-16  Instruccion explicita de no-alucinacion Inventos: 8 % → 1 %
v1.0      2025-01-20  Version candidata a produccion          Todos los criterios superados

Regla de gestion: nunca sobrescribir una version. Mantener el historial completo para poder revertir si una nueva version introduce regresiones.

4 · Ajustes sobre la solucion (III)

Ejemplo de evolucion del system prompt entre versiones

# VERSION v0.1
Eres un asistente que responde preguntas sobre procedimientos internos.

# VERSION v0.3 (tras detectar problemas de formato e invencion)
Eres un asistente especializado en procedimientos internos de la empresa.

REGLAS OBLIGATORIAS:
1. Responde SOLO con informacion presente en el contexto proporcionado.
2. Si no encuentras la informacion, di exactamente: "No dispongo de informacion
   sobre este procedimiento en la documentacion actual."
3. Cita siempre la seccion de origen al final de tu respuesta: [Fuente: Seccion X.Y]
4. Usa siempre formato de lista numerada para procedimientos de mas de un paso.
5. Longitud maxima: 300 palabras.

La diferencia entre v0.1 y v0.3 ilustra como cada regla nueva responde a un fallo especifico detectado en las pruebas.

5 · Documentacion de pruebas (I)

Estructura del informe de validacion

El informe de validacion es el artefacto formal que certifica que el sistema cumple los criterios de aceptacion:

Secciones obligatorias:

1. Configuracion del sistema evaluado — version, modelo, parametros, system prompt
2. Conjunto de pruebas — numero de casos por categoria, criterios de seleccion
3. Metricas obtenidas — puntuaciones por dimension; comparativa con criterios de aceptacion
4. Fallos detectados — descripcion, categoria, severidad
5. Ajustes aplicados — cambios realizados entre versiones
6. Resultado final — APTO / NO APTO con justificacion
7. Pendientes — limitaciones conocidas que se gestionan en produccion

5 · Documentacion de pruebas (II)

Ciclo de resolucion de incidencias

Cuando un caso de prueba falla, se sigue un ciclo estructurado:

FALLO DETECTADO
      |
      v
Clasificar severidad
  CRITICA: el sistema produce informacion falsa peligrosa
  ALTA:    el sistema ignora una instruccion de seguridad
  MEDIA:   el formato es incorrecto o la respuesta es incompleta
  BAJA:    la respuesta es correcta pero podria mejorarse
      |
      v
Identificar causa raiz
(instruccion ambigua / parametro inadecuado / fuente insuficiente / limite del modelo)
      |
      v
Aplicar ajuste minimo necesario
      |
      v
Regresar TODOS los casos de prueba anteriores
      |
      v
Registrar en el historial de versiones

5 · Documentacion de pruebas (III)

Metricas clave del informe de validacion

# Ejemplo de calculo de metricas de validacion
resultados = [
    {"id": "TC-001", "pertinencia": 3, "coherencia": 3,
     "completitud": 2, "trazabilidad": 1, "formato": True},
    {"id": "TC-002", "pertinencia": 2, "coherencia": 3,
     "completitud": 3, "trazabilidad": 1, "formato": True},
    # ...
]

n = len(resultados)
metricas = {
    "pertinencia_media":   sum(r["pertinencia"]  for r in resultados) / n,
    "coherencia_media":    sum(r["coherencia"]   for r in resultados) / n,
    "completitud_media":   sum(r["completitud"]  for r in resultados) / n,
    "trazabilidad_media":  sum(r["trazabilidad"] for r in resultados) / n,
    "formato_ok_pct":      sum(r["formato"]      for r in resultados) / n * 100,
}
print(metricas)

6 · Puesta en servicio (I)

Artefactos de la puesta en servicio

La validacion exitosa abre el proceso de puesta en servicio. Este proceso genera cuatro tipos de artefactos:

6 · Puesta en servicio (II)

Documentacion tecnica: contenido minimo

# ejemplo: ficha tecnica del sistema en produccion

sistema:
  nombre: "Asistente de Procedimientos Internos v1.0"
  fecha_despliegue: "2025-02-01"
  responsable: "Equipo IA"

modelo:
  proveedor: "Anthropic"
  id_modelo: "claude-opus-4-5"
  temperatura: 0.3
  max_tokens: 512
  system_prompt_version: "v1.0"

integraciones:
  - tipo: RAG
    fuente: "SharePoint — Manuales de procedimientos"
    actualizacion: "trimestral"
  - tipo: API
    endpoint: "/api/v1/consulta"
    autenticacion: "Bearer token"

limites:
  ventana_contexto: "200k tokens"
  rate_limit: "100 req/min"
  coste_estimado: "0.50 USD / 1000 consultas"

6 · Puesta en servicio (III)

Soporte continuo: que monitorizar en produccion

Una vez el sistema esta en servicio, la validacion no termina: pasa a ser monitorizacion continua.

Metricas de produccion a seguir:

Actividad practica · UD5

Diseno y ejecucion de un plan de validacion

Enunciado:

Tienes una solucion RAG que responde preguntas sobre la normativa de contratacion publica de una administracion local (documentos de 300 paginas). El sistema esta configurado con temperatura=0.3, max_tokens=600 y un system prompt que instruye al modelo a no inventar informacion y citar siempre la fuente.

Tareas:

1. Disenar un conjunto de 12 casos de prueba distribuidos en las seis categorias (al menos 2 por categoria).
2. Ejecutar los casos documentando el resultado obtenido y el estado (PASS / FAIL / PARCIAL).
3. Identificar al menos dos ajustes necesarios a partir de los fallos detectados y aplicarlos al system prompt.
4. Redactar el informe de validacion con las metricas obtenidas antes y despues de los ajustes.
5. Elaborar la guia de uso del sistema para los funcionarios que lo utilizaran.

Entregable: plan de pruebas + informe de validacion + guia de uso (una pagina).

Puntos clave · UD5

• Los casos de prueba deben cubrir seis categorias: representativas, complejas, errores esperados, ausencia de informacion, variaciones linguisticas y condiciones limite.
• En sistemas conversacionales se evalua ademas el mantenimiento de contexto y las respuestas fuera de alcance.
• La calidad se mide en cinco dimensiones: pertinencia, coherencia, completitud, trazabilidad y formato.
• Los criterios de aceptacion se fijan antes de ejecutar las pruebas, no despues de ver los resultados.
• Cada ajuste genera una nueva version del sistema; el historial de versiones permite rastrear la evolucion y revertir si hay regresiones.
• La puesta en servicio genera cuatro artefactos: documentacion tecnica, manual operativo, guia de uso y registro de aceptacion.
• La monitorizacion en produccion es la continuacion natural de la validacion.

Criterios de evaluacion · UD5

Navegación

← UD4 · Comportamientos agenticos  ·  Volver al módulo  ·  UD6 · Seguridad, privacidad y uso e… →