En esta página
EN BREVE
Un asistente turístico público y multilingüe construido alrededor de orquestación de agentes, RAG, herramientas externas y modelos de pesos abiertos servidos localmente.
Mi contribución
Arquitectura de IA aplicada · evaluación de modelos · routing y herramientas · infraestructura de inferencia · debugging de producción.
Datos clave
Decisiones de ingeniería
Enrutar por tipo de tarea
Separar la selección de intención, el trabajo de especialistas y la síntesis para evaluar herramientas y modelos en las funciones concretas que cumplen.
Servir pesos abiertos localmente
Usar endpoints de vLLM por función para que el ajuste del modelo, la capacidad, la observabilidad y el reemplazo sean parte del diseño.
Evaluar el comportamiento por capas
Tratar la calidad de respuesta, el uso de herramientas, el enrutamiento y la capacidad concurrente como preguntas separadas, no como un único puntaje.
Investigar la concurrencia en el límite de estado
Las pruebas de carga vincularon los streams interrumpidos con estado mutable compartido entre solicitudes y dejaron visible la restricción real de serving tras aislarlo.
Evolución del proyecto
- Benchmarks de modelos
- Arquitectura de agentes enrutados
- Herramientas MCP y RAG
- Voz multimodal
- Pruebas de carga
- Aislamiento de estado por solicitud
- Optimización de serving
Un servicio público detrás de una conversación
Una persona puede preguntar por un restaurante, una ruta accesible y una actividad cercana en la misma conversación. Cada parte requiere información distinta y la respuesta debe funcionar en varios idiomas y mediante texto o voz. Benidorm reúne esas capacidades en un asistente turístico público para visitantes y residentes.
El pliego técnico iba más allá del chat: contenido oficial, integración con el CMS y el destino turístico inteligente, rutas, acceso multilingüe y multimodal, accesibilidad y medición operativa. El sistema también puso un énfasis poco habitual en modelos de pesos abiertos e infraestructura open source, por lo que la calidad, el uso de herramientas, el ajuste al hardware y la capacidad de servicio se convirtieron en decisiones de producto.
Alcance técnico
Este caso recorre el trabajo de IA aplicada en orquestación, recuperación de conocimiento, herramientas turísticas, interacción multimodal, servicio local de modelos, benchmarking y pruebas operativas. La pregunta central es cómo ajustar distintos modelos de pesos abiertos a funciones específicas manteniendo observable el sistema completo.
De la consulta a una respuesta útil
Arquitectura simplificada
Una vista simplificada del recorrido compartido del asistente. El servicio local de modelos sostiene el enrutamiento y la síntesis; el texto cercano documenta los detalles de implementación.
Consulta
La persona pregunta en su idioma por texto o voz.
Enrutamiento
El sistema identifica qué capacidades y fuentes necesita la consulta.
Conocimiento y servicios
El contenido oficial y las herramientas turísticas aportan contexto relevante y actualizado.
Síntesis
Un modelo asignado a esa función reúne los resultados en una respuesta.
Respuesta
El asistente devuelve una explicación clara por el canal elegido.
La experiencia del visitante
Puedes consultar estas opciones de playas accesibles en Benidorm y abrir su ubicación en Maps:
| Nombre | Tipo | Cómo llegar |
|---|---|---|
| Playas Accesibles de Benidorm | Playa | Ver en Maps |
| Playa de Levante | Playa | Ver en Maps |
| Playa de Poniente | Playa | Ver en Maps |
Una consulta, varias fuentes
La PWA usa CopilotKit para conectar la conversación con FastAPI y LangGraph. Tras preparar el estado y revisar los controles persistentes de seguridad, el grafo detecta el idioma y ejecuta el enrutamiento junto al análisis de sentimiento. El router selecciona especialistas o servicios simples; un sintetizador combina sus resultados en una respuesta.
Las herramientas MCP conectadas a Drupal resuelven consultas turísticas estructuradas. Un servicio RAG separado ingiere contenido oficial, genera embeddings y busca en PostgreSQL con pgvector. Las actualizaciones del CMS pueden activar el reprocesamiento y los hashes evitan volver a generar embeddings de contenido sin cambios. Los servicios de mapas y datos actuales aportan rutas, clima y conjuntos de datos municipales.
El grafo consulta modelos de pesos abiertos por función mediante vLLM. Modelos de la familia Qwen resuelven generación y trabajo con herramientas; Gemma permanece en una etapa final y acotada de parsing. La voz se normaliza mediante STT hacia el mismo flujo de agentes basado en texto y luego se dirige a un modelo TTS apropiado para el idioma. Así, la experiencia multimodal no necesita un único modelo multimodal grande en cada consulta. Las trazas de Langfuse, las métricas y las conversaciones persistidas permiten inspeccionar el recorrido.
Por qué apareció el router
- Decisión
- Separar la selección de intención, el trabajo especializado y la síntesis de la respuesta.
- Motivo
- Las capacidades crecieron entre restaurantes, alojamiento, eventos, transporte, mapas y recuperación de conocimiento. El enrutamiento estructurado hace explícita la selección de herramientas y acota la tarea de cada especialista.
- Compromiso
- Más consultas a modelos agregan latencia e interfaces que mantener. El paralelismo ayuda con tareas independientes, pero la síntesis necesita esperar los resultados relevantes.
- Resultado
- El router devuelve los agentes seleccionados y una consulta para cada uno. LangGraph distribuye esas ramas y reúne sus resultados en un sintetizador compartido.
Enrutamiento de intención
Seleccionar especialistas y preparar sus consultas.
Consulta del visitante
Busca un restaurante y una ruta a pie.
Restaurantes
Herramientas turísticas
Mapas y rutas
Servicios de mapas
Una respuesta
Los pesos abiertos fueron un requisito arquitectónico
- Decisión
- Evaluar y servir modelos de pesos abiertos localmente mediante interfaces estándar y reemplazables.
- Motivo
- El proyecto necesitaba controlar el despliegue, las funciones de cada modelo, la asignación de hardware y los componentes específicos por idioma sin depender de una única API alojada.
- Compromiso
- La inferencia local incorpora el ajuste de modelos, la cuantización, las licencias, la memoria de GPU, el rendimiento, las actualizaciones y el monitoreo al alcance operativo del sistema.
- Resultado
- vLLM expone endpoints compatibles con OpenAI para cargas específicas de Qwen y Gemma. Los componentes open source de recuperación, orquestación, voz, mapas, observabilidad y almacenamiento mantienen portable la plataforma.
Cómo fue creciendo la evaluación
La evaluación evolucionó junto con el sistema. Un primer flujo en n8n comparaba respuestas repetidas a consultas turísticas mediante un juez de IA. Más adelante, las pruebas se ampliaron al uso de herramientas, las salidas estructuradas y el comportamiento integral de los agentes.
Calidad casi igual a una fracción del costo
Puntuación media de Gemma 27B
El modelo Gemma más grande sirvió como referencia para esta tarea de respuestas turísticas.
Benchmark interno de Benidorm; los resultados corresponden a su conjunto de prompts, evaluador, configuración de servicio y rúbrica.Puntuación media de Gemma 4B
Casi igualó a Gemma 27B a una fracción del costo de uso para este caso turístico.
Benchmark interno de Benidorm; no es un ranking universal de familias de modelos.Calidad de las respuestas turísticas
Benchmark interno · calidad de respuesta y uso de herramientas evaluados por separado.
Criterios de evaluación
- Claridad
- Factualidad
- Consistencia
| Gemma 27B | 8,23 |
|---|---|
| Gemma 4B | 8,17 |
Calidad casi igual. Una fracción del costo de uso.
Gemma 4B para este caso turístico.
Las puntuaciones corresponden a este conjunto de prompts y su rúbrica.
Modelos por función
Pruebas de herramientas separadas- Qwen
Generación y herramientas
- Gemma
Parsing final
Gemma: uso inconsistente de herramientas. Qwen: fuerte con herramientas, menor puntuación multilingüe.
La mejor puntuación no eligió todos los roles
- Decisión
- Usar Qwen para generar respuestas y trabajar con herramientas, con Gemma en el parser final acotado.
- Motivo
- Gemma 4B casi igualó a Gemma 27B en esta tarea de respuestas turísticas a una fracción del costo de uso. Sin embargo, la selección y el uso de herramientas de Gemma fueron inconsistentes. Qwen tuvo un desempeño fuerte con herramientas, aunque puntuó menos en las evaluaciones multilingües, por lo que resultó más adecuado para generación y trabajo con herramientas en este flujo de agentes.
- Compromiso
- Elegir Qwen para generación y herramientas priorizó la fiabilidad con herramientas pese a sus puntuaciones multilingües más bajas. Usar varios modelos también agrega complejidad de servicio y depuración, pero permite mantener a Gemma dentro del contrato más acotado del parsing final.
- Resultado
- La selección pasó a ser específica por función: la generación amplia y el comportamiento con herramientas se juzgaron por separado del parsing final. Las puntuaciones agregadas informaron la decisión sin reemplazar el comportamiento observado en cada tarea.
Evaluar el modelo y el sistema
Evaluar la calidad de respuesta
Puntuar claridad, factualidad, tono, consistencia, comportamiento por categoría y la cola de baja calidad sobre consultas turísticas representativas.
Probar herramientas y salida estructurada
Ejercitar enrutamiento, selección de herramientas, argumentos, recuperación ante formatos inválidos y parsing final por separado de la calidad del lenguaje natural.
Ajustar el despliegue
Validar tamaño, cuantización, contexto, longitud de salida y uso de memoria frente al hardware L4 disponible y al presupuesto de latencia de cada función.
Medir la capacidad de servicio
Ejecutar GuideLLM contra cada endpoint de vLLM con entradas y salidas representativas de su función, aumentando las solicitudes concurrentes hasta localizar el punto de quiebre entre rendimiento y latencia.
Reproducir escenarios reales del agente
Probar casos completos con enrutamiento, RAG, herramientas en vivo, síntesis, streaming y fallbacks. Un endpoint rápido solo sirve si el asistente completo conserva la corrección.
Qué falló con la concurrencia
Un síntoma engañoso
Las pruebas de carga en preproducción fallaban con poca concurrencia y parecían señalar un límite de inferencia. Las métricas del servicio de modelos mostraban capacidad disponible y poca cola.
La falla real
Los streams concurrentes compartían una instancia mutable del agente AG-UI. Una solicitud podía sobrescribir la ejecución activa de otra, provocando errores de esquema y respuestas interrumpidas.
El cambio
Crear una instancia del agente por solicitud y compartir el grafo compilado. Mantener el orden por conversación cuando corresponde y aislar el estado mutable del streaming.
El siguiente límite
Las pruebas posteriores dejaron de reproducir esa falla. La inferencia del router pasó a ser el cuello de botella visible y orientó la incorporación de una réplica con balanceo de carga.
Recomendaciones: relevancia y exposición
- Decisión
- Separar el orden de las recomendaciones en una capa configurable de control de sesgos.
- Motivo
- Ordenar solo por calificación o volumen de reseñas favorece repetidamente a los mismos establecimientos. Un asistente turístico público también necesita variedad entre candidatos relevantes.
- Compromiso
- La rotación aleatoria reduce repeticiones, pero puede restar consistencia. Las estrategias por calificación, estratificadas e híbridas tienen compromisos distintos; ninguna demuestra equidad por sí sola.
- Resultado
- El código admite varias estrategias de ordenamiento independientes de las herramientas turísticas. Esto afecta las recomendaciones de establecimientos; la recuperación semántica RAG usa sus propios filtros de similitud.
Un mismo asistente para texto y voz
Arquitectura simplificada
El recorrido de audio se mantiene modular para poder cambiar los componentes de voz sin reemplazar el asistente de texto y herramientas ya evaluado.
Audio
La persona graba una consulta.
Transcripción
La voz se convierte en texto normalizado.
Asistente
El flujo compartido de rutas, herramientas y conocimiento genera una respuesta.
Selección de voz
La respuesta se envía a una voz adecuada para el idioma.
Reproducción
La persona escucha la respuesta y puede continuar la conversación.
Texto y voz
Dos formas de consultar. Un mismo asistente.
Entrada de texto
¿Qué puedo visitar cerca?
Entrada de voz
Voz a texto
«¿Qué puedo visitar cerca?»
faster-whisperAsistente compartido
- Enrutar
- Recuperar y usar herramientas
- Sintetizar
Salida de voz
TTS según el idioma
Selecciona el motor adecuado para el idioma de la respuesta.
Chat multimodal sin un único cuello de botella
- Decisión
- Convertir voz a texto, reutilizar el grafo de agentes y herramientas, y dirigir la respuesta a un modelo de voz específico para el idioma.
- Motivo
- Un recorrido audio → STT → detección de idioma → agente → TTS reutiliza el flujo de texto ya evaluado y permite que cada idioma use un modelo abierto apropiado. Evita mantener un modelo multimodal general y más pesado en el camino crítico de cada consulta.
- Compromiso
- Grabación, cancelación, transcripción, detección de idioma, síntesis y reproducción tienen latencias y estados de error independientes. La calidad también varía por idioma, acento, ruido urbano, nombres propios y hardware del cliente.
- Resultado
- El servicio de audio admite backends locales y APIs reemplazables. La ruta local implementada usa faster-whisper para STT y distribuye TTS entre voces de las familias Kokoro y aHoTTS. La inferencia en navegador o dispositivo queda como optimización opcional con fallback al servidor.
Optimizar el recorrido medido
Medir dónde se consume el tiempo
Las trazas separan enrutamiento, acceso a fuentes y síntesis. Un análisis interno de preproducción identificó la síntesis como el mayor componente promedio y algunas herramientas externas como origen de respuestas lentas.
Reducir trabajo evitable
Los saludos simples pueden evitar la inferencia del router. Los resultados de especialistas se compactan, se eliminan campos irrelevantes y se incluyen instrucciones solo cuando hacen falta. Los límites de salida de herramientas acotan el crecimiento del contexto.
Asignar modelos por función
Los endpoints de vLLM separan enrutamiento, generación, parsing y embeddings. El entorno utiliza GPUs NVIDIA L4 de 24 GB, por lo que la cuantización, el contexto, la longitud de salida, el batching y las cargas concurrentes son restricciones concretas para elegir cada modelo.
Una arquitectura que se puede investigar
El sistema permite mejorar por separado la calidad de los modelos, el comportamiento con herramientas, el ajuste al hardware, el enrutamiento, la actualización de fuentes, las recomendaciones, el audio y la capacidad de inferencia. La investigación de concurrencia muestra por qué importa: aislar las solicitudes permitió ver el verdadero límite del servicio de modelos.
Los pesos abiertos fueron valiosos porque los modelos podían evaluarse, ajustarse al hardware, servirse y reemplazarse por función. También hicieron responsable al equipo de esas decisiones. El trabajo sigue en curso y las cifras describen evaluaciones internas acotadas, no rankings universales ni garantías de capacidad en producción.
Lo que el trabajo dejó claro
- La calidad de respuesta y la fiabilidad con herramientas son capacidades distintas y necesitan evaluaciones separadas.
- Los modelos de pesos abiertos son más útiles cuando se ajustan a una función y a su hardware, no cuando se eligen solo por cantidad de parámetros.
- Las recomendaciones útiles dependen tanto de la diversidad como de la relevancia.
- Separar la voz del lenguaje mantiene cada parte del sistema multimodal reemplazable y más fácil de mejorar.
- Las trazas explican el comportamiento del sistema y las colas revelan límites de capacidad; juntas muestran qué conviene optimizar después.