UD1 · Análisis del caso de uso y selección del modelo

Objetivos de la unidad

Al finalizar esta unidad el alumno será capaz de:

• Interpretar un caso de uso de negocio para extraer los requisitos técnicos que condicionan la selección del modelo.
• Aplicar criterios técnicos y operativos comparados para elegir el LLM o servicio más adecuado.
• Configurar correctamente los parámetros de generación en función del caso de uso.
• Registrar las limitaciones funcionales y los supuestos del sistema de forma estructurada.

1 · Interpretación del caso de uso (I)

El caso de uso como punto de partida

Antes de seleccionar ningún modelo es imprescindible comprender el problema que se quiere resolver. Un caso de uso de LLM se describe a través de seis dimensiones:

1 · Interpretación del caso de uso (II)

Tipos de tareas y su impacto en la selección

Un mismo proyecto puede combinar varias tareas, lo que obliga a evaluar si se usa un único modelo o una arquitectura multi-modelo.

1 · Interpretación del caso de uso (III)

Análisis de restricciones y condiciones de contorno

Las restricciones delimitan el espacio de soluciones válidas. Se deben identificar antes de evaluar modelos:

Restricciones técnicas:

• Latencia máxima tolerable (ej. < 2 s para un chat de atención al cliente)
• Tamaño máximo de la entrada (documentos de hasta X páginas)
• Formato obligatorio de la salida (ej. siempre JSON para integración con ERP)

Restricciones normativas y de negocio:

• Datos personales que no pueden salir de la UE (RGPD) → descarta APIs en servidores externos
• Información clasificada o secreto comercial → requiere modelo local o VPC privada
• Presupuesto mensual máximo en llamadas a la API

Restricciones de usuario:

• Idioma principal de la interacción
• Nivel de tolerancia a respuestas incorrectas (dominio médico vs. ocio)

2 · Criterios de selección del modelo (I)

Marco de decisión técnica

La selección del modelo es una decisión de ingeniería, no de preferencia. Se evalúan estos criterios:

2 · Criterios de selección del modelo (II)

Comparativa de modalidades de despliegue

La decisión no es definitiva: es posible empezar con una API pública y migrar a un modelo propio cuando el volumen lo justifique.

2 · Criterios de selección del modelo (III)

Evaluación práctica: pasos para comparar modelos

1. Definir el benchmark de referencia con 20-50 entradas representativas del caso de uso real.
2. Ejecutar los modelos candidatos con los mismos prompts y parámetros base.
3. Evaluar las salidas según las dimensiones de calidad relevantes (precisión, formato, completitud).
4. Medir el coste y la latencia de cada modelo en esas mismas pruebas.
5. Registrar los resultados en una tabla comparativa y justificar la selección final.

Modelo           | Precisión | Latencia  | Coste/1M tokens | Idioma ES
-----------------|-----------|-----------|-----------------|----------
Proveedor A (L)  |   87 %    |  1.2 s    |   $3.00/$15.00  |  Bueno
Proveedor B (M)  |   81 %    |  0.6 s    |   $0.60/$2.40   |  Muy bueno
Open source 7B   |   72 %    |  2.1 s*   |   Infra propia  |  Regular

* en hardware propio (A100)

3 · Parámetros de generación (I)

Control del comportamiento del modelo

Los parámetros de generación determinan cómo el modelo produce la respuesta. Deben configurarse específicamente para cada caso de uso:

3 · Parámetros de generación (II)

Configuraciones recomendadas por tipo de tarea

Criterios de parada personalizados:

• Secuencias de parada (stop sequences): cadenas que indican al modelo que debe detenerse (ej. "###", "</respuesta>")
• Útiles para extraer solo la parte relevante de la respuesta en formatos estructurados

3 · Parámetros de generación (III)

Mensajes de sistema y formato de salida

El mensaje de sistema (system prompt) es la instrucción de nivel superior que condiciona toda la interacción:

Eres un asistente especializado en análisis de contratos jurídicos españoles.
Tu tarea es extraer las cláusulas relevantes en formato JSON.
Responde SIEMPRE en español formal.
No inventes información que no esté en el documento proporcionado.
Si no encuentras la información solicitada, devuelve null en ese campo.

Formato de salida estructurado:

• JSON Schema: permite especificar el esquema exacto que debe seguir la respuesta
• Modo JSON nativo (OpenAI, Anthropic): el modelo garantiza salida JSON válida
• Markdown estructurado: útil para documentos con secciones predefinidas

4 · Registro de limitaciones funcionales

Documentar lo que el sistema no puede hacer

El registro de limitaciones es tan importante como la documentación de capacidades. Debe incluir:

Limitaciones del modelo seleccionado:

• Ventana de contexto máxima y cómo afecta al caso de uso
• Idiomas o dominios con rendimiento inferior al esperado
• Tipos de razonamiento donde el modelo comete errores sistemáticos

Supuestos del sistema:

• El usuario proporciona entradas en español (si hay otra lengua, el comportamiento no está garantizado)
• Los documentos de entrada no superan X páginas
• La latencia se mide en condiciones de carga normal, no en picos

Escenarios que requieren supervisión humana:

• Respuestas que afectan a decisiones de alto impacto (médicas, legales, financieras)
• Casos donde la confianza del sistema es baja (sin información suficiente)
• Peticiones fuera del alcance definido del sistema

Actividad practica · UD1

Analisis y seleccion de modelo para un caso real

Enunciado:

Una empresa de logistica quiere desplegar un asistente interno que responda preguntas de sus empleados sobre el manual de procedimientos operativos (500 paginas, actualizado trimestralmente). Las respuestas deben citarse con la seccion del manual de origen. El sistema estara disponible via Slack. La empresa opera en Espana y tiene requisitos RGPD: los datos no pueden salir de la UE.

Tareas:

1. Identifica las seis dimensiones del caso de uso (objetivo, usuarios, interaccion, datos, restricciones, resultados esperados).
2. Determina que modalidad de despliegue es viable dado el requisito RGPD.
3. Propone dos modelos candidatos con justificacion tecnica.
4. Define los parametros de generacion recomendados (temperatura, max tokens, formato de salida).
5. Redacta el registro de limitaciones del sistema propuesto (minimo tres limitaciones y dos supuestos).

Entregable: documento de analisis de una pagina + tabla de comparativa de modelos.

Puntos clave · UD1

• El caso de uso define los requisitos; el modelo se selecciona para cumplirlos, no al contrario.
• Las seis dimensiones de analisis (objetivo, usuarios, interaccion, datos, restricciones, resultados) estructuran cualquier proyecto LLM.
• La modalidad de despliegue (API publica, open source, VPC) es la primera decision condicionada por privacidad y coste.
• La temperatura controla la aleatoriedad: baja para extraccion y clasificacion, alta para generacion creativa.
• Los mensajes de sistema son el mecanismo principal para delimitar el comportamiento del modelo.
• Registrar limitaciones y supuestos es parte del entregable tecnico, no una tarea secundaria.

Criterios de evaluacion · UD1

Navegación

Volver al módulo  ·  UD2 · Componentes de interaccion co… →