Desarrollar aplicaciones empresariales con LLM y APIs: arquitectura, herramientas, seguridad y operación · Módulo 3: Contexto, estado y fiabilidad
Gestionar contexto, recuperación y estado
Arquitectura para ensamblar contexto explícito y mantener estado de dominio, memoria, historial y RAG como conceptos separados.
Objetivo de aprendizaje
Construir el contexto de cada llamada desde identidad, estado, historial relevante y evidencia sin usar la memoria implícita del modelo como fuente de verdad.
Una aplicación LLM no debería reenviar todo el historial y esperar que el modelo «recuerde» lo importante. El contexto debe ensamblarse explícitamente a partir de la tarea, la identidad, el estado de dominio y la evidencia necesaria.
El contexto de una llamada es un recurso finito. La memoria persistente pertenece a la aplicación.
Construye un ensamblador de contexto
Crea un componente que reciba:
- usuario;
- tenant;
- tarea;
- estado actual;
- permisos;
- historial relevante;
- documentos recuperados;
- resultados de herramientas;
- instrucciones;
- presupuesto.
El resultado es el contexto exacto que se envía.
Registra referencias de qué entró y por qué. Si una respuesta falla, necesitas poder distinguir si el problema fue ausencia de contexto, retrieval, prompt o generación.
Separa tipos de estado
Distingue:
Estado de dominio. Pedido, expediente, etapa, identificadores y decisiones confirmadas.
Estado conversacional. Mensajes recientes necesarios para interpretar la interacción.
Resumen generado. Compresión auxiliar; no debe reemplazar datos críticos.
Memoria persistente. Preferencias o hechos guardados deliberadamente.
Conocimiento recuperado. Pasajes externos mediante RAG.
Mezclar estos tipos crea errores difíciles de depurar.
No uses resúmenes como fuente de verdad
Un resumen generado puede omitir condiciones. Si el sistema necesita saber que invoice_id=123 ya fue aprobada, guárdalo estructuradamente.
Usa resúmenes para reducir historial o proporcionar contexto narrativo, no para sustituir el estado que gobierna efectos.
Integra RAG como componente
La recuperación debe devolver:
- fragmentos;
- fuente;
- versión;
- permisos;
- score;
- metadata necesaria.
Filtra autorización antes de enviar al modelo. Conserva la relación entre afirmaciones y evidencia.
No mezcles silenciosamente política interna con conocimiento general. Si el contrato exige respuestas desde fuentes autorizadas, el modelo debe abstenerse cuando falte evidencia.
Controla el presupuesto
Antes de la llamada reserva espacio para salida y prioriza:
- instrucciones críticas;
- estado de dominio;
- evidencia necesaria;
- historial relevante;
- contexto opcional.
No uses truncado ciego por caracteres. Si debes reducir, elimina unidades completas o aplica una estrategia conocida.
Mide tokens, latencia y calidad. Un contexto mayor puede aumentar coste y ruido.
Diseña expiración y eliminación
El estado persistente necesita ciclo de vida:
- creación;
- uso;
- expiración;
- actualización;
- eliminación;
- aislamiento entre usuarios y tenants.
No guardes indefinidamente toda conversación porque sea técnicamente posible.
Ejemplo: conversación de soporte
El usuario consulta un pedido, después pregunta «¿y si lo cancelo?».
El sistema reconstruye:
- identidad;
- pedido seleccionado;
- estado actual;
- política vigente;
- permisos.
No necesita reenviar veinte mensajes anteriores si esos datos ya están estructurados.
Si el usuario cambia de pedido, la selección anterior no debe contaminar la nueva consulta.
Diseña precedencia entre fuentes de contexto
Cuando dos componentes aportan datos sobre el mismo hecho, define cuál manda.
Ejemplo:
- el historial dice «pedido pendiente»;
- la base de datos dice «pedido cancelado».
El estado de dominio debe prevalecer. No permitas que una frase antigua de la conversación sobrescriba el dato actual.
Establece jerarquías explícitas.
Modela referencias, no copias cuando sea posible
En lugar de guardar todo el contenido de un objeto en memoria conversacional, conserva un ID y recupera el estado actual cuando haga falta.
Esto reduce:
- obsolescencia;
- duplicación;
- exposición;
- consumo de contexto.
Usa compaction con criterio
Cuando una conversación es larga puedes resumir o compactar, pero debes conservar:
- decisiones;
- identificadores;
- restricciones;
- tareas pendientes;
- compromisos del usuario.
El resumen puede acompañarse de estado estructurado para evitar depender de una única generación.
Trata resultados de tools como eventos de estado
Si una tool modifica un recurso, actualiza el estado de dominio y no sigas operando únicamente con la versión previa en contexto.
Ejemplo:
crear_tarea() devuelve task_id=981.
Desde ese momento, el estado debe incluir esa entidad de manera estructurada.
Evalúa contaminación de contexto
Prueba:
- instrucciones de una tarea anterior;
- datos de otro recurso;
- contexto de otro tenant;
- resumen antiguo;
- RAG obsoleto.
El sistema debe descartar lo que ya no sea aplicable.
Define tamaños y prioridades por tarea
No existe un contexto óptimo universal.
Una extracción corta puede necesitar:
- instrucción;
- documento;
- schema.
Una tarea de investigación puede necesitar:
- objetivo;
- corpus;
- citas;
- historial.
Diseña perfiles de contexto en lugar de una única plantilla gigante.
Registra decisiones del ensamblador
Para cada petición, guarda qué políticas seleccionaron:
- historial;
- documentos;
- tools;
- estado.
Así puedes reproducir por qué una llamada vio cierta información.
Ejercicio
Diseña un ensamblador y prueba:
- conversación larga;
- cambio de usuario;
- cambio de tenant;
- permiso retirado;
- documento actualizado;
- estado de dominio modificado;
- desbordamiento de contexto;
- resumen incorrecto;
- historial irrelevante.
Para cada caso registra qué contexto entró y qué quedó fuera.
Entregable
El entregable de esta lección es un sistema que construye contexto deliberadamente y guarda el estado crítico fuera del modelo. Esa separación reduce acoplamiento, coste y errores antes de abordar fallos de red, reintentos y asincronía.