- Introducción
- ¿Por qué monitorizar y observar un LLM es diferente?
- Tres categorías de métricas que debes supervisar
- Arquitectura sencilla de observabilidad con OpenAI y herramientas OSS
- Ejemplo de código
- Caso de uso: monitorización de alucinaciones
- Buenas prácticas: alertas y flujos de trabajo
- Conclusión
- Preguntas frecuentes (FAQs)
1. Introducción
Cada vez más desarrolladores e ingenieros están construyendo aplicaciones basadas en LLM y llevándolas a producción. El auge de frameworks, APIs y plataformas de hosting hace que lanzar prototipos sea más rápido que nunca. Sin embargo, un reto importante permanece: ¿cómo monitorizamos adecuadamente un LLM para detectar problemas, mantener los costes bajo control y asegurarnos de que su comportamiento se alinee con los objetivos y valores de nuestro producto?
En esta publicación, descubrirás por qué la observabilidad y la monitorización de LLMs difieren de la monitorización tradicional de software, qué categorías de métricas debes contemplar y cómo implementar una arquitectura sencilla usando herramientas de código abierto y la API de OpenAI (aplicable también a otros proveedores). Al final, tendrás mayor claridad acerca de qué y cómo monitorizar, y contarás con ejemplos de código reproducible que podrás personalizar según tus necesidades.
2. ¿Por qué monitorizar y observar un LLM es diferente?
A diferencia del software tradicional, donde los puntos de fallo suelen ser deterministas (excepciones, errores lógicos, etc.), un LLM produce respuestas “no deterministas” basadas en distribuciones de probabilidad. De un día para otro, tu modelo puede:
- Alucinar: genera texto verosímil pero incorrecto.
- Exponer contenido sesgado o tóxico.
- Salir del contexto: por ejemplo, responder con algo irrelevante.
Estas situaciones no necesariamente arrojan un error clásico; el LLM no te “avisa” de que está alucinando o generando contenido cuestionable. Las alertas tradicionales de software (logs de errores, métricas de CPU, etc.) no son suficientes. Necesitas observabilidad más profunda, con métricas que capten la calidad y la confiabilidad del texto generado.
3. Tres categorías de métricas que debes supervisar
Para organizar tu estrategia de monitorización de LLMs, es útil separarla en tres grandes categorías: Costes, Calidad y Salida (Output). Cada categoría aborda un tipo de riesgo y necesidad diferente.
Costes
Calidad
Salida
3.1. Costes
Ejecutar un LLM puede conllevar costes elevados, especialmente si utilizas un modelo de terceros con facturación por token (p. ej., OpenAI, Anthropic). Aun si ejecutas el modelo on-premise, los servidores GPU pueden disparar tus gastos de infraestructura. Entre las métricas clave en costes están:
- Número de trazas: cuántas llamadas se hacen al LLM en un período de tiempo.
- Duración (latencia): la latencia promedio y p95/p99 para cada solicitud.
- Uso de tokens: tokens de entrada y de salida (prompt y respuesta) para entender si tus prompts son demasiado largos o el modelo está devolviendo respuestas excesivas.
- Coste estimado: multiplicar el uso total de tokens por el precio por token.
Monitorizar estos indicadores te permite mantener el ROI bajo control y anticiparte a picos de demanda que encarezcan tu servicio.
3.2. Calidad
En IA generativa, “calidad” no es sólo qué tan “correcta” está la respuesta, sino si se ajusta a límites de seguridad, moderación y experiencia de usuario. Algunas métricas importantes:
- Alucinaciones: si el modelo inventa hechos o datos.
- Moderación: respuestas inapropiadas, ofensivas u hostiles.
- Feedback de usuario: puntuaciones o reseñas que tus usuarios otorguen a las respuestas, así como evaluaciones manuales de tu equipo.
Aunque muchas veces se usan guardrails para filtrar contenido problemático, necesitas vigilancia continua sobre la calidad real de las respuestas. Por ejemplo, una métrica como la tasa de “bloqueo” puede revelar un aumento de prompts maliciosos o tóxicos.
3.3. Salida (output)
El contenido generado por el LLM puede presentar problemas sintácticos, semánticos o de formato. Para monitorizar la calidad específica de tu caso de uso, considera implementar métricas personalizadas, como:
- “LLM as a Judge”: usar otra llamada a un LLM para juzgar la exactitud de la respuesta original (un prompt evaluador que genera un score).
- Métricas de consistencia: valora si el LLM mantiene coherencia factual en resúmenes o en diálogos multi-turn.
- Integridad de formato: la respuesta coincide con un esquema JSON esperado o con un formato predefinido.
No todas estas métricas son baratas de implementar (por ejemplo, cada “LLM as a Judge” conlleva otra llamada), pero ofrecen visibilidad sobre la calidad real del contenido que sirves a tus usuarios.
4. Arquitectura sencilla de observabilidad con OpenAI y herramientas OSS
Veamos un ejemplo práctico de cómo instrumentar tu aplicación con trazas y paneles de control. Imagina que estás construyendo un chatbot que genera recetas de cocina:
- Realizas llamadas al API de LLM: por ejemplo, utilizando gpt-4o o sonnet.
- Registros automáticos: cada interacción se registra automáticamente en una plataforma OSS de observabilidad (por ejemplo, Langfuse, Comet Opik u otra).
- Definición de métricas: estableces tus métricas de costes, calidad y salida (por ejemplo, “hallucination_score”, “token_usage”, “user_feedback”).
- Dashboards con alertas: visualizas todo en paneles de control y configuras alertas (Slack, PagerDuty, correos, etc.).
El paso clave es decorar o interceptar tus llamadas al LLM para que, cada vez que generes una respuesta, la plataforma recoja automáticamente:
- Información de costo: tokens usados, latencia.
- Contenido de entrada y salida: prompts y respuestas (respetando la privacidad).
- Métricas personalizadas: un prompt evaluador que califique la salida.
Así obtendrás trazas detalladas, viendo cada interacción (prompt/respuesta), su costo en tokens, latencia, feedback de usuario y posibles banderas de moderación. Luego podrás configurar alertas para recibir notificaciones ante:
- Picos anormales de latencia.
- Tasa de alucinaciones elevada.
- Aumento repentino en costes.
Aunque cada herramienta difiere en sintaxis, la idea es siempre similar: usar un decorador (o middleware) que capture la llamada al LLM y envíe la información a tu sistema de observabilidad.
5. Ejemplo de código
A continuación, un ejemplo simplificado en Python, usando OpenAI y una librería de observabilidad llamada opik:
import json
import openai
from openai import OpenAI
import opik
from opik import opik_context
from opik.integrations.openai import track_openai
# Instancia del cliente de OpenAI, instrumentado con Opik
cliente = track_openai(OpenAI())
@opik.track(flush=True)
def generar_receta(nombre_plato: str) -> tuple[str, dict]:
"""
Genera una receta de cocina a partir del nombre de un plato, evalúa
su calidad y recopila feedback del usuario. Retorna el texto de la
receta y un diccionario con la evaluación.
"""
# Prompt principal para generar la receta
mensajes = [
{"role": "system", "content": "Eres un chef experto."},
{
"role": "user",
"content": (
f"Eres un chef de primera clase. Genera una receta para {nombre_plato}.\n"
"La receta debe incluir:\n"
"- Lista de ingredientes con cantidades\n"
"- Pasos detallados de preparación\n"
"- Tiempo de cocción\n"
"- Nivel de dificultad\n"
"- Calorías aproximadas"
),
},
]
respuesta = cliente.chat.completions.create(
model="gpt-4o-mini",
messages=mensajes,
max_tokens=500,
temperature=0.7
)
receta_texto = respuesta.choices[0].message.content
# Evalúa la receta generada
evaluacion = evaluar_receta(receta_texto, nombre_plato)
# Muestra la receta en consola
print("\n" + "=" * 50)
print(receta_texto)
print("=" * 50)
# Advertencia en caso de "alucinaciones" detectadas
if evaluacion['tiene_alucinaciones']:
print("⚠️ Advertencia: Esta receta puede contener información incorrecta.")
# Recopila feedback del usuario
feedback, comentario = obtener_feedback_usuario()
# Envía métricas de feedback a Opik
opik_context.update_current_trace(
feedback_scores=[
{
"name": "calidad_receta",
"value": evaluacion["puntuacion"] / 10.0,
"reason": evaluacion["explicacion"],
},
{
"name": "formato_correcto",
"value": 1.0 if evaluacion["formato_correcto"] else 0.0,
},
{
"name": "sin_alucinaciones",
"value": 0.0 if evaluacion["tiene_alucinaciones"] else 1.0,
},
{
"name": "feedback_usuario",
"value": feedback / 5.0 if feedback is not None else 0.0,
"reason": comentario if comentario else "Sin comentarios",
},
]
)
return receta_texto, evaluacion
def evaluar_receta(receta_texto: str, plato_solicitado: str) -> dict:
"""
Envía la receta a un evaluador (otro modelo) para comprobar su
calidad, formato y posibles alucinaciones. Devuelve un diccionario
con los campos:
- puntuacion (int, 1 a 10)
- tiene_alucinaciones (bool)
- formato_correcto (bool)
- explicacion (str)
"""
prompt_evaluador = (
f"Eres un experto evaluador de recetas. Analiza la siguiente receta para {plato_solicitado}:\n\n"
f"{receta_texto}\n\n"
"Evalúa los siguientes aspectos y devuelve un JSON con estos campos:\n"
"1. puntuacion: del 1 al 10, ¿qué tan buena es esta receta?\n"
"2. tiene_alucinaciones: true/false, ¿contiene ingredientes imposibles o pasos irreales?\n"
"3. formato_correcto: true/false, ¿incluye todos los elementos solicitados?\n"
"4. explicacion: breve explicación de tu evaluación\n"
)
try:
evaluacion_respuesta = cliente.chat.completions.create(
model="gpt-4o-mini",
messages=[
{"role": "system", "content": "Eres un evaluador de recetas objetivo."},
{"role": "user", "content": prompt_evaluador},
],
max_tokens=300,
temperature=0.2,
response_format={"type": "json_object"}
)
return json.loads(evaluacion_respuesta.choices[0].message.content)
except Exception as e:
print(f"Error en evaluación: {e}")
return {
"puntuacion": 5,
"tiene_alucinaciones": False,
"formato_correcto": False,
"explicacion": "Error en la evaluación automática"
}
def obtener_feedback_usuario() -> tuple[int | None, str | None]:
"""
Solicita al usuario una puntuación de 1 a 5 y un comentario adicional.
Retorna la puntuación y el comentario (o None si hay error).
"""
print("\n--- Ayúdanos a mejorar ---")
try:
puntuacion = int(input("Del 1 al 5, ¿qué tan útil fue esta receta? "))
comentario = input("¿Algún comentario adicional? (opcional): ")
print(f"Feedback registrado: {puntuacion}/5")
if comentario:
print(f"Comentario: {comentario}")
return puntuacion, comentario
except Exception as e:
print(f"Error al registrar feedback: {e}")
return None, None
def main():
print("🍳 Asistente de Recetas con Observabilidad 🍳")
plato = input("¿Qué plato quieres cocinar?: ")
generar_receta(plato)
if __name__ == "__main__":
main()
El código anterior combina la generación de contenido con un LLM y la captura de métricas de observabilidad mediante la librería opik. Las secciones clave son:
- Inicialización y decoración del cliente:
Se configura el cliente de OpenAI y se aplica un decorador para interceptar cada llamada, permitiendo capturar datos relevantes como uso de tokens, latencia y coste. - Generación y evaluación de recetas:
La función generar_receta arma el prompt, obtiene la respuesta del modelo y evalúa la calidad de la receta a través de la función evaluar_receta. Además, se recoge feedback del usuario y se actualizan las métricas de rendimiento. - Uso de Middleware:
Con la lógica de observabilidad centralizada mediante decoradores y actualizaciones del contexto de trazas, se logra una visión completa de cada interacción, facilitando la monitorización en tiempo real y el análisis histórico.
Para una monitorización efectiva, es fundamental contar con paneles visuales que muestren entre otras cosas:
- Dashboard de métricas en tiempo real:
Visualización del número de llamadas, uso de tokens, latencia, coste estimado y métricas custom.
- Histórico de registros:
Registro detallado de cada interacción para analizar la evolución del sistema, detectar anomalías y realizar troubleshooting.
6. Caso de uso: monitorización de alucinaciones
Las alucinaciones son uno de los mayores dolores de cabeza en LLM. Para mitigarlas, se suelen usar dos enfoques:
- Moderación o clasificación:
Cada respuesta se pasa a un clasificador (otro modelo o un endpoint de moderación) que señala si la respuesta es dudosa o sensible. - Autoevaluación (“LLM as a Judge”):
Tu pipeline llama a un segundo prompt que puntúa qué tan precisa es la primera respuesta.
Ejemplo de prompt evaluador:
evaluation_prompt = f"""
Eres un corrector experto en recetas.
Puntúa del 0 al 10 la veracidad de esta receta:
{receta_generada}
Explica brevemente tu puntuación.
"""
El resultado de esta segunda llamada podría devolverte algo como { «score»: 7, «explanation»: «En general es correcta, pero algunos ingredientes faltan.» }. Con este score, configuras alertas cuando baje de un umbral (por ejemplo, 5) o lo registras como una métrica “hallucination_score”.
Aunque pagas un coste adicional por este enfoque (cada evaluación es otra llamada), obtienes la capacidad de detección proactiva de errores y contenidos falsos que podrían dañar la experiencia de usuario.
7. Buenas prácticas: alertas y flujos de trabajo
A continuación, algunas sugerencias para optimizar tu sistema de monitorización y prevención de problemas:
- Monitorizar costes en tiempo real
- Implementa métricas de uso de tokens, latencia y número de trazas.
- Ajusta la longitud de los prompts y las respuestas para evitar facturas excesivas.
- Compara el rendimiento de distintos modelos o versiones para optimizar la relación coste-beneficio.
- Evaluar la calidad y la moderación
- Aplica guardrails para filtrar contenido inapropiado o potencialmente dañino.
- Utiliza pipelines de moderación o prompts evaluadores para medir la exactitud y detectar sesgos.
- Registra los casos de fallos más críticos y mejora tus prompts o haz fine-tuning de ser necesario.
- Observabilidad de la salida
- Diseña métricas personalizadas: validación de formato JSON, coherencia en diálogos, consistencia factual, etc.
- Asegura la integridad de la estructura en las respuestas, especialmente si se consumen en otros sistemas.
- Sampling vs. evaluación continua
- Considera la posibilidad de aplicar muestreo estadístico (p. ej., 10% de las solicitudes) para equilibrar costes de evaluación y cobertura de calidad.
- Para casos de alto impacto (financieros, médicos), quizá necesites una evaluación más exhaustiva en todas las llamadas.
- Alertas contextualizadas
- Incluye en la alerta información sobre los prompts y las respuestas recientes para facilitar la depuración.
- Conecta tus alertas con Slack, PagerDuty u otros servicios de notificaciones.
- Uso de decoradores/Middleware
- Intercepta las llamadas al LLM para recopilar automáticamente datos de latencia, uso de tokens, coste estimado, etc.
- Extiende esta lógica a todos los endpoints o flujos que llamen a LLM, manteniendo así una visión unificada.
8. Conclusión
Implementar un sistema de monitorización y observabilidad para LLM es fundamental para:
- Controlar costes: saber exactamente cuánto gastas en cada interacción.
- Velar por la calidad: detectar alucinaciones y contenido tóxico o inapropiado.
- Customizar tu salida: agregar métricas propias que reflejen el éxito en tu caso de uso.
Más allá de lo técnico, esto se traduce en responsabilidad, transparencia y eficiencia a la hora de operar aplicaciones de IA generativa. Recuerda que la observabilidad no es un evento puntual, sino un proceso continuo de aprendizaje, medición y refinamiento. Si planeas implementar tu propia estrategia de monitorización, experimenta con las herramientas mencionadas (u otras similares) para elegir la que mejor se ajuste a tus requisitos.
9. Preguntas frecuentes (FAQs)
- ¿Qué herramientas OSS puedo usar para monitorizar LLMs?
Existen varias opciones, como Langfuse, Comet Opik, Langtrace, Langwatch, langsmith entre otras. La elección depende de tu stack tecnológico y de las métricas que desees capturar. - ¿Cómo calculo el costo de ejecución de un LLM en la nube?
Generalmente se basa en el número de tokens utilizados (prompt y respuesta). Multiplica la cantidad total de tokens por el precio por token que cobra el proveedor (p. ej., OpenAI). Asegúrate de monitorizar estas cifras en tiempo real para anticipar picos de coste. Normalmente, la herramienta de observabilidad de LLM calcula esto por ti basándose en el número de tokens utilizados (prompt y respuesta) y el precio por token del proveedor. - ¿Qué significa que un LLM “alucine”?
Se refiere a cuando un LLM genera contenido que parece válido pero que en realidad es falso o inventado. Este fenómeno es común en modelos de lenguaje y puede afectar la credibilidad de las respuestas. - ¿Cuál es la diferencia entre monitorización tradicional y monitorización de LLMs?
La monitorización tradicional se centra en métricas como tiempos de respuesta, errores, logs de sistema, etc. En LLMs, necesitas además métricas de calidad de texto, moderación y consistencia, entre otras, debido a la naturaleza no determinista de las respuestas. - ¿Tengo que pagar doble costo si uso un “LLM as a Judge”?
Sí, cada llamada adicional al modelo (p. ej., para evaluar la exactitud de otra respuesta) conlleva un coste adicional. Sin embargo, puede compensarse con la reducción de riesgos y la mejora en la experiencia de usuario.