Introducción: por qué orquestar varios LLM para un avatar de recepción

Poner en producción un avatar IA de recepción implica compromisos: capacidad de respuesta ante visitantes presentes físicamente, costes de uso de los modelos, calidad de las respuestas y protección de datos sensibles. Orquestar varios modelos LLM permite equilibrar estas restricciones asignando cada solicitud al motor más adecuado según reglas predefinidas.

Este artículo presenta patrones concretos de enrutamiento, arquitecturas híbridas edge/cloud, escenarios RAG que combinan modelos especializados, así como reglas de fallback y trazabilidad. El objetivo es operativo: proporcionar matrices de decisión y configuraciones tipo aplicables a pantallas y kioscos de recepción.

Criterios de enrutamiento esenciales a definir

Antes de cualquier orquestación, defina criterios de enrutamiento simples y medibles. Los más útiles para un avatar físico son: latencia aceptable (tiempo de respuesta percibido por el visitante), coste por solicitud o por minuto, sensibilidad de los datos en la petición, complejidad esperada (pregunta factual vs generación creativa) y idioma o restricción de cumplimiento.

Estos criterios sirven para componer reglas de decisión que orienten cada solicitud hacia un modelo local, un modelo cloud costoso pero potente, o hacia un tratamiento RAG especializado en la base de conocimientos de la organización.

Patrones de orquestación habituales

Aquí hay cuatro patrones probados para un avatar IA de recepción:

1) Enrutamiento latencia‑first: priorizar un modelo local ligero para interacciones cortas (saludo, horarios, orientación) y cambiar a un modelo cloud para consultas complejas que requieran entendimiento fino. Este patrón favorece la sensación de reactividad del visitante.

2) Coste‑first con caché: usar un modelo económico para la mayoría de solicitudes, complementado por una capa de caché para respuestas frecuentes; invocar un modelo más costoso solo para excepciones. Útil en lugares de alto tráfico.

3) Sensibilidad‑first: dirigir las solicitudes que contienen datos potencialmente sensibles (información personal, expediente de cliente) a modelos aprobados o locales para limitar riesgos de fuga. Esta regla depende de una valoración previa de los flujos de datos y de las políticas internas de privacidad (puede requerirse una DPIA según los tratamientos). 4) RAG‑hybrid: combinar un retriever local sobre la base de conocimientos y uno o varios modelos generativos distintos según la complejidad o el idioma. El retriever aporta las fuentes; el generador produce la respuesta.

Arquitecturas híbridas: edge local + cloud

Una arquitectura híbrida asocia un modelo local (edge) para interacciones básicas y uno o varios modelos cloud para tratamientos más exigentes. El modelo local reduce la latencia y permite procesar algunos datos sin salir del sitio: es una configuración posible según el proyecto.

En lo operativo, es importante prever un orquestador que evalúe la solicitud según los criterios definidos, invoque el modelo elegido y devuelva la respuesta a la interfaz. Según la configuración, se pueden usar varios motores LLM y una persona centralizada define la identidad del avatar (avatar + voz + instrucciones sistema). SANIA permite combinar precisamente una persona, motores LLM e instrucciones sistema en una configuración adaptada.

Escenarios RAG y modelos especializados

Integrar la búsqueda documental (RAG) en una estrategia multi‑LLM suele ser imprescindible para un avatar de recepción que deba apoyarse en contenidos de negocio. Un enfoque práctico consiste en separar el pipeline: un retriever consulta la base de conocimientos de la organización y luego uno o varios modelos generan la respuesta basándose en esos pasajes.

En una orquestación multi‑LLM, puede optar por usar un modelo rápido y económico para sintetizar pasajes cortos y un modelo más potente para reformulaciones complejas o consultas críticas. Recordatorio importante: la conexión al sistema documental y los webhooks de alimentación son integraciones específicas a desarrollar según el proyecto.

Reglas prácticas de fallback y escalado

Defina reglas claras de fallback cuando el modelo seleccionado no pueda responder (puntaje de confianza bajo, latencia demasiado alta, error técnico). Un fallback habitual es: reenviar la solicitud a un modelo alternativo menos costoso pero robusto, o a un RAG simplificado. Evite automatizar transferencias al personal sin normas organizativas previas; es recomendable prever las situaciones en que el avatar debe invitar al usuario a contactar con un equipo humano.

Documente las condiciones que desencadenan el fallback (p. ej., palabras clave, ausencia de fuentes pertinentes, timeouts) y asegúrese de que la persona se mantenga coherente entre modelos mediante instrucciones sistema compartidas.

Mantener la coherencia de la persona en multi‑LLM

El uso de varios modelos puede fragmentar el tono y estilo del avatar. Para preservar una experiencia unificada, centralice: 1) las instrucciones sistema de la persona (rol, tono, reglas de cortesía), 2) las plantillas de frases de salida, 3) las reglas de gestión de información sensible.

SANIA permite configurar una persona que combina avatar, voz, motor LLM e instrucciones sistema en una configuración dada. Aproveche esta centralización para aplicar restricciones estilísticas comunes sea cual sea el modelo invocado.

Trazabilidad, logs y procedencia de las respuestas

Para la gobernanza y el cumplimiento, registre la procedencia de cada respuesta: modelo utilizado, fuentes consultadas (en caso de RAG), prompt o plantilla aplicada y posibles transformaciones de post‑procesado. Estos elementos facilitan las revisiones de calidad y las investigaciones en caso de incidente.

Atención: la conservación de logs, transcripciones de audio o datos personales depende de la configuración y de las obligaciones regulatorias. La necesidad de una evaluación de impacto (DPIA) dependerá de los tratamientos realmente implementados.

Monitorización e indicadores a implantar

SANIA no proporciona indicadores de forma nativa sin configuración específica. No obstante, una organización puede implementar un panel que siga, por ejemplo, latencia media por modelo, tasa de fallback, coste estimado por periodo y muestras de calidad evaluadas por revisores de negocio. Estas métricas requieren un método de recolección definido y herramientas externas o un servicio de observabilidad.

Supervisar conjuntamente costes y calidad permite ajustar las reglas de enrutamiento: si un modelo cloud costoso se usa en exceso para solicitudes simples, reconfigure el enrutamiento para priorizar un modelo local o una caché.

Configuraciones tipo - 4 ejemplos concretos

Configuración A - Kiosco de recepción baja latencia: modelo local ligero para saludo, FAQ y orientaciones; RAG local para documentos técnicos; modelo cloud para consultas largas o ambiguas. Enrutamiento basado en la longitud de la solicitud y la detección de palabras clave de negocio.

Configuración B - Entorno con restricción de confidencialidad: modelo on‑premises para cualquier dato identificado como sensible; modelo cloud únicamente para solicitudes anónimas y creativas. Las reglas de sensibilidad se basan en un pre‑filtro que marca la solicitud antes del enrutamiento (configuración y políticas internas necesarias).

Configuración C - Oficina de turismo multilingüe: modelo local entrenado en los destinos comunes para los idiomas más frecuentes; conmutación a un motor cloud multilingüe para idiomas raros o preguntas complejas; RAG sobre folletos para información práctica.

Configuración D - Retail con flujo variable y control de costes: modelo económico en front para el 80% de las solicitudes, complementado por un modelo más potente ante detectores de intención comercial (consultas de disponibilidad de producto, comparaciones). Añada una caché en el lado del orquestador para respuestas frecuentes.

Checklist operacional antes de la puesta en producción

Antes del despliegue, valide:

  • las reglas de enrutamiento y los criterios disparadores;

  • los escenarios de fallback y la gestión de errores;

  • las pruebas de latencia y de escalado representativas del emplazamiento (afluencia, ruido, red);

  • la conformidad de los flujos de datos sensibles y la evaluación de impacto si procede;

  • la estrategia de monitorización (latencia, coste, tasa de fallback, muestras de calidad) y las responsabilidades de revisión;

  • la coherencia de la persona mediante instrucciones sistema comunes y scripts de aceptación; y la integración técnica de webhooks, llamadas a funciones o conectores necesarios.

Preguntas frecuentes

¿Qué elementos deben permanecer en el sitio en lugar de en la nube? Los datos que su organización considere sensibles, o los tratamientos cuyo tiempo de respuesta sea crítico, pueden procesarse localmente según la configuración elegida. La decisión se basa en criterios internos y en el análisis de riesgos.

¿Cómo evaluar si un modelo cloud está justificado para una solicitud? Priorice el modelo cloud para las peticiones que requieran comprensión fina, alta creatividad o acceso a capacidades no disponibles localmente, y siga después las métricas de coste y calidad para ajustar los umbrales.