Observabilidad para aplicaciones LLM: Un caso práctico

El Auge de las Aplicaciones de LLM y la Necesidad de Observabilidad

El panorama del desarrollo de software ha sido drásticamente transformado por la revolución de los modelos de lenguaje grande (LLM). Desde chatbots sofisticados y generadores de contenido inteligente hasta asistentes de código y herramientas de análisis de datos, los LLM están siendo integrados en una variedad cada vez mayor de aplicaciones. Esta rápida adopción, aunque emocionante, introduce una nueva clase de desafíos, particularmente en lo que respecta a comprender y mantener estos sistemas en producción. Las herramientas de monitoreo tradicionales, diseñadas para software determinista y basado en reglas, a menudo no capturan las sutilezas del comportamiento de los LLM.

Aquí entra la observabilidad. La observabilidad, en el contexto de las aplicaciones de LLM, es la capacidad de entender el estado interno de un sistema potenciado por LLM a partir de sus salidas externas. Va más allá de simples verificaciones de salud para proporcionar profundas percepciones sobre cómo el LLM interpreta solicitudes, genera respuestas, gestiona el contexto e interactúa con herramientas o fuentes de datos externas. Sin una observabilidad adecuada, depurar problemas de rendimiento, garantizar equidad, identificar alucinaciones u optimizar costos puede convertirse en una tarea abrumadora, casi imposible. Este artículo presenta un estudio de caso práctico sobre la implementación de observabilidad para una aplicación LLM, demostrando principios y herramientas clave.

Estudio de Caso: ‘DocuChat’ – Un Asistente Interno de Base de Conocimientos

Consideremos una aplicación hipotética llamada ‘DocuChat’. DocuChat es un asistente interno de base de conocimientos diseñado para ayudar a los empleados a encontrar rápidamente respuestas dentro de una vasta colección de documentos internos (páginas de Confluence, archivos de Slack, wikis internos, etc.). Se basa en una arquitectura de Generación Aumentada por Recuperación (RAG):

1. Consulta del Usuario: Un empleado formula una pregunta (por ejemplo, “¿Cómo solicito una nueva computadora portátil?”).
2. Recuperación: El sistema busca en una base de datos vectorial (poblada con incrustaciones de documentos internos) para encontrar fragmentos de documentos relevantes.
3. Aumento: Estos fragmentos recuperados, junto con la consulta original del usuario, se proporcionan como contexto a un LLM.
4. Generación: El LLM sintetiza una respuesta basada en el contexto proporcionado y la consulta del usuario.

DocuChat utiliza GPT-4 de OpenAI para la generación y un modelo de incrustación auto-alojado para la recuperación. Fue construido utilizando Python, LangChain, y una base de datos vectorial como Pinecone o Weaviate. Inicialmente, el equipo de desarrollo se centró en la funcionalidad, pero a medida que la aplicación ganó usuarios, surgió una serie de preguntas operativas:

• ¿Por qué algunas respuestas son lentas?
• ¿Está el LLM alucinando, o está fallando la recuperación?
• ¿Están satisfechos los usuarios con las respuestas?
• ¿Cuánto nos cuesta esto por consulta?
• ¿Estamos alcanzando los límites de tasa de la API?
• ¿Qué tipos de preguntas están haciendo los usuarios con más frecuencia?

Estas preguntas destacan la necesidad crítica de observabilidad.

Pilares de la Observabilidad de LLM para DocuChat

Para DocuChat, nos centraremos en los tres pilares tradicionales de la observabilidad, adaptados para aplicaciones de LLM:

1. Registros: Registros estructurados de eventos.
2. Métricas: Medidas numéricas agregadas a lo largo del tiempo.
3. Rastros: Vistas de extremo a extremo de solicitudes a través de sistemas distribuidos.

Además, consideraremos un cuarto pilar crucial para los LLM: Retroalimentación/Evaluación Humana.

1. Registros: El ‘Qué Sucedió’

Los registros de aplicaciones tradicionales son vitales, pero para las aplicaciones LLM, necesitan capturar detalles específicos centrados en LLM. Para DocuChat, instrumentamos varias etapas de la tubería RAG para emitir registros estructurados.

Estructura de Registro de Ejemplo (JSON):

{
 "timestamp": "2023-10-27T10:30:00Z",
 "service": "docuchat-rag-api",
 "level": "INFO",
 "event_type": "user_query",
 "session_id": "abcd-1234-efgh",
 "user_id": "user_123",
 "query": "¿Cómo solicito una nueva computadora portátil?",
 "metadata": {
 "user_agent": "Mozilla/5.0...",
 "ip_address": "192.168.1.10"
 }
},
{
 "timestamp": "2023-10-27T10:30:01Z",
 "service": "docuchat-rag-api",
 "level": "INFO",
 "event_type": "retrieval_start",
 "session_id": "abcd-1234-efgh",
 "query": "¿Cómo solicito una nueva computadora portátil?",
 "vector_db_query": "política de solicitud de computadora portátil",
 "k_value": 5
},
{
 "timestamp": "2023-10-27T10:30:02Z",
 "service": "docuchat-rag-api",
 "level": "INFO",
 "event_type": "retrieval_complete",
 "session_id": "abcd-1234-efgh",
 "retrieved_docs_count": 3,
 "retrieved_docs": [
 {"id": "doc-456", "source": "confluence/policy-computadora-portátil", "score": 0.89},
 {"id": "doc-789", "source": "slack/anuncios-it", "score": 0.81}
 ],
 "retrieval_duration_ms": 1000
},
{
 "timestamp": "2023-10-27T10:30:03Z",
 "service": "docuchat-rag-api",
 "level": "INFO",
 "event_type": "llm_generation_start",
 "session_id": "abcd-1234-efgh",
 "model_name": "gpt-4",
 "temperature": 0.7,
 "prompt_tokens": 500,
 "system_prompt_hash": "abc123def456" 
},
{
 "timestamp": "2023-10-27T10:30:08Z",
 "service": "docuchat-rag-api",
 "level": "INFO",
 "event_type": "llm_generation_complete",
 "session_id": "abcd-1234-efgh",
 "response": "Para solicitar una nueva computadora portátil, por favor visita el portal de IT...",
 "completion_tokens": 150,
 "total_tokens": 650,
 "llm_duration_ms": 5000,
 "finish_reason": "stop"
},
{
 "timestamp": "2023-10-27T10:30:09Z",
 "service": "docuchat-rag-api",
 "level": "INFO",
 "event_type": "response_sent",
 "session_id": "abcd-1234-efgh",
 "total_request_duration_ms": 9000
}

Al centralizar estos registros (por ejemplo, utilizando ELK Stack, Splunk, Datadog), el equipo puede:

• Filtrar por session_id para reconstruir toda una interacción.
• Identificar recuperaciones lentas o llamadas al LLM lentas.
• Analizar consultas comunes y sus resultados.
• Depurar problemas examinando el prompt exacto proporcionado al LLM y los documentos recuperados.

2. Métricas: El ‘Cuánto’ y el ‘Qué Tan Rápido’

Las métricas proporcionan información agregada y cuantificable sobre el rendimiento y uso del sistema. Para DocuChat, rastreamos métricas clave usando Prometheus y las visualizamos con Grafana.

Métricas Específicas de LLM Clave:

• Latencia:
  • docuchat_total_request_duration_seconds_sum/_count (tiempo de respuesta general del sistema)
  • docuchat_retrieval_duration_seconds_sum/_count
  • docuchat_llm_api_duration_seconds_sum/_count
• Uso de Tokens & Costo:
  • docuchat_llm_prompt_tokens_total (contador)
  • docuchat_llm_completion_tokens_total (contador)
  • docuchat_llm_total_tokens_cost_usd_total (calculado según el precio del modelo)
• Salud de la API:
  • docuchat_llm_api_calls_total (contador, etiquetado por model_name, status_code)
  • docuchat_vector_db_queries_total (contador, etiquetado por status_code)
  • docuchat_llm_api_rate_limit_errors_total (contador)
• Rendimiento de Recuperación:
  • docuchat_retrieved_documents_count_sum/_count (promedio de documentos recuperados por consulta)
  • docuchat_retrieved_documents_avg_score (medida/resumen)
• Participación del Usuario:
  • docuchat_successful_responses_total (contador)
  • docuchat_failed_responses_total (contador)

Estas métricas permiten al equipo:

• Configurar alertas para alta latencia o tasas de error crecientes.
• Monitorear el costo financiero del uso del LLM en tiempo real.
• Identificar cuellos de botella en la tubería RAG (por ejemplo, recuperación lenta vs. LLM lento).
• Entender la distribución de las puntuaciones de los documentos recuperados, lo que indica la efectividad de la recuperación.

3. Rastros: El ‘Camino Tomado’

Los rastros proporcionan una vista holística del viaje de una sola solicitud a través de un sistema distribuido. Para DocuChat, se utiliza OpenTelemetry para instrumentar la tubería de LangChain y cualquier llamada a APIs externas. Cada paso en el proceso RAG se convierte en un rango dentro de un rastro.

Flujo de Trazado de Ejemplo para DocuChat:

1. Rango: Solicitud del Usuario (Rango Raíz)
   • Atributos: user_id, query, session_id
2. Rango: Recuperación
   • Atributos: vector_db_query, k_value, retrieval_engine
   • Rango Hijo: Consulta a la Base de Datos Vectorial
     • Atributos: query_vector_size, response_time_ms
   • Rango Hijo: Pre-procesamiento de Documentos (si hay alguno)
     • Atributos: num_docs_processed
   • Eventos: “Se recuperaron 3 documentos”, “No se encontraron documentos relevantes”
3. Rango: Generación de LLM
   • Atributos: model_name, temperature, prompt_tokens, completion_tokens
   • Rango Hijo: Llamada a la API de OpenAI
     • Atributos: api_endpoint, status_code, request_id
   • Eventos: “El LLM comenzó la generación”, “El LLM terminó la generación”, “Se detectó alucinación en el LLM (baja confianza)”
4. Rango: Post-procesamiento & Respuesta
   • Atributos: response_length_chars, sentiment_score

Utilizando un backend de rastreo (como Jaeger, Honeycomb, Datadog APM), el equipo puede:

• Inspeccionar visualmente la secuencia exacta de operaciones para cualquier consulta dada.
• Identificar qué etapa del pipeline RAG consume más tiempo.
• Entender el contexto pasado al LLM (documentos recuperados) para un rastro específico.
• Identificar errores o comportamientos inesperados dentro de intervalos específicos.

4. Retroalimentación Humana & Evaluación: El ‘Qué Tan Bueno’

Los LLM, por su naturaleza, son probabilísticos. Mientras que los registros, métricas y rastros nos dicen sobre la mecánica del sistema, no siempre nos informan sobre la calidad de la salida del LLM. Aquí es donde la retroalimentación humana y las métricas de evaluación automatizada se vuelven cruciales.

Para DocuChat, implementamos:

1. Botones de Voto/Antivoto de Usuario: Mecanismo de retroalimentación simple en cada respuesta. Los antivotos activan una alerta para revisión manual si se cumple un cierto umbral.
2. Función de “Reportar Problema”: Permite a los usuarios proporcionar retroalimentación en texto libre sobre alucinaciones, respuestas incorrectas o información irrelevante.
3. Evaluación de Conjunto de Datos Oro: Un conjunto de preguntas conocidas con respuestas verificadas por expertos. Ejecutar regularmente DocuChat contra este conjunto de datos y evaluar las respuestas utilizando métricas como:
   • RAGAS: Un marco específicamente para la evaluación RAG, midiendo aspectos como fidelidad, relevancia de respuestas, precisión de contexto y recuerdo de contexto.
   • Semejanza Semántica: Utilizando modelos de embeddings para comparar la respuesta generada con la respuesta de oro.
   • Sobreposición de Palabras Clave: Comprobaciones simples para la presencia de términos clave.
4. LLM como Juez: En algunos casos, un LLM más potente (por ejemplo, GPT-4) puede ser usado para evaluar la salida de un LLM menos potente (por ejemplo, GPT-3.5) contra un referente o para criterios específicos (por ejemplo, concisión, tono).

Integrar esta retroalimentación permite al equipo:

• Medir directamente la satisfacción del usuario e identificar áreas problemáticas.
• Mejorar iterativamente el pipeline RAG (por ejemplo, refinar la estrategia de segmentación, mejorar el modelo de embeddings, ajustar la ingeniería de prompts).
• Rastrear el rendimiento de diferentes versiones de LLM o algoritmos de recuperación a lo largo del tiempo.

Implementación Práctica y Herramientas

La pila de observabilidad para DocuChat utiliza una combinación de herramientas de código abierto y comerciales:

• Registro: El módulo logging de Python, configurado para emitir JSON, enviado a Loki (el sistema de agregación de registros de Grafana Labs).
• Métricas: Prometheus para la recolección de datos de series temporales, expuesto a través de un endpoint personalizado de FastAPI con prometheus_client. Grafana para paneles y alertas.
• Rastreo: SDK de Python de OpenTelemetry para instrumentación, enviando rastros a Jaeger. LangChain ofrece callbacks integrados que pueden adaptarse a OpenTelemetry.
• Plataformas Específicas para LLM: Herramientas como LangSmith (para rastreo y evaluación de LangChain), Weights & Biases (para seguimiento de experimentos y evaluación de modelos), o Arize AI (para observabilidad y monitoreo de LLM) pueden agilizar significativamente el proceso, especialmente para casos de uso avanzados y equipos grandes. Para este estudio de caso, optamos por un enfoque más DIY utilizando componentes de código abierto para ilustrar los fundamentos.
• Retroalimentación Humana: Elementos de UI personalizados integrados con un servicio de retroalimentación dedicado que registra en Loki y actualiza un contador de métricas.

Beneficios y Resultados para DocuChat

Implementar esta estrategia de observabilidad integral produjo beneficios significativos para el equipo de DocuChat:

• Depuración Más Rápida: Cuando un usuario reportó una respuesta incorrecta, los ingenieros pudieron rastrear rápidamente la consulta, examinar los documentos recuperados, el prompt exacto y la respuesta del LLM, generalmente identificando problemas en minutos.
• Optimización de Costos: Al monitorear el uso de tokens, el equipo identificó oportunidades para reducir el tamaño de los prompts y experimentar con modelos de LLM más económicos para casos de uso específicos, lo que llevó a una reducción del 15% en costos de API.
• Mejor Rendimiento: Las métricas revelaron que la base de datos vectorial era ocasionalmente lenta. Esto condujo a optimizar la estrategia de indexación vectorial y escalar la base de datos, resultando en una mejora del 20% en el tiempo de respuesta promedio.
• Mayor Confiabilidad: Las alertas por errores API de LLM o altas tasas de alucinaciones permitieron una intervención proactiva, previniendo la insatisfacción generalizada de los usuarios.
• Iteración Basada en Datos: La retroalimentación humana y las métricas de evaluación proporcionaron evidencia concreta sobre qué cambios en el pipeline RAG o ingeniería de prompts fueron más efectivos, impulsando la mejora continua.
• Transparencia: Los interesados obtuvieron una mejor visión del rendimiento del sistema y del valor que estaba entregando.

Desafíos y Trabajo Futuro

A pesar de su éxito, la implementación no estuvo exenta de desafíos:

• Volumen de Datos: Las interacciones con LLM pueden generar una gran cantidad de datos (prompts, respuestas, contexto). Gestionar y almacenar estos datos de manera eficiente es crucial.
• Comprensión Contextual: Interpretar las salidas de LLM aún a menudo requiere juicio humano. La evaluación automatizada está mejorando pero no es perfecta.
• Cambios en la Ingeniería de Prompts: Cambios frecuentes en los prompts requieren un versionado cuidadoso y asegurar que las métricas de evaluación sigan siendo relevantes.
• Detección de Alucinaciones: Aunque algunas métricas (como la fidelidad de RAGAS) ayudan, la detección solida y en tiempo real de alucinaciones sigue siendo un área de investigación activa.

El trabajo futuro para DocuChat incluye:

• Integrar detección avanzada de anomalías para salidas de LLM.
• Desarrollar marcos de prueba A/B más sofisticados para diferentes configuraciones de RAG.
• Explorar la detección proactiva de prompts adversariales o intentos de inyección de prompts.
• Aprovechar modelos más pequeños ajustados para tareas específicas para optimizar aún más costos y latencia.

Conclusión

La observabilidad no es simplemente un bonito extra, sino un requisito fundamental para construir aplicaciones LLM confiables, de alto rendimiento y rentables. Como se demostró en el estudio de caso de DocuChat, una estrategia integral que incorpora registros estructurados, métricas detalladas, rastros de extremo a extremo y retroalimentación humana crucial proporciona las perspectivas necesarias para navegar las complejidades únicas de los sistemas impulsados por LLM. Al invertir en observabilidad desde el principio, los equipos de desarrollo pueden ganar confianza en sus aplicaciones LLM, depurar problemas rápidamente, optimizar el rendimiento y, en última instancia, ofrecer una experiencia de usuario superior.

🕒 Last updated: March 26, 2026  ·  Originally published: March 25, 2026