El equipo de BI de Avito monta dashboards con un agente en 8–10 días en lugar de 20

Cada vez más compañeros llevan a los desarrolladores de BI dashboards montados con ayuda de IA. Tienen muchos gráficos y muy detallados, pero no queda claro adónde mirar ni qué conclusión sacar. Ira Kulbyakina, del equipo de Inmobiliaria de Avito, analizó por qué ocurre y mostró con un ejemplo cómo se lleva uno de esos dashboards a un estado utilizable. Según los autores, con un agente un dashboard complejo se monta en 8–10 días en lugar de 20.

Dónde ayuda el agente y dónde no

El trabajo en un dashboard suele seguir este orden. Primero se recogen los requisitos y después se estudian los datos: qué tablas están vigentes y cómo calcular las métricas. Luego se escriben el SQL y el código de las visualizaciones, y se conectan a mano los filtros con cada gráfico. Estos pasos técnicos los asume el agente. En Avito crearon servidores MCP para Redash y para el almacén de datos en Trino. A través de ellos, el agente busca tablas, extrae datos, escribe consultas y construye gráficos. Aun así, las personas verifican por su cuenta las fuentes y los cálculos.

Los problemas empiezan cuando se le pide al agente que convierta los gráficos en un dashboard completo. Para el modelo, cada gráfico es una tarea independiente, con su propia consulta, su tipo de visualización y sus colores. Los errores dentro de un mismo gráfico (escalas distintas en un mismo panel, suma en lugar de media, el periodo anterior olvidado) se detectan fácilmente con reglas. Las decisiones que afectan a toda la pantalla son más difíciles: qué color corresponde a cada indicador, con qué comparar cada cifra, qué es lo principal y qué no debe aparecer en pantalla.

El experimento: el dashboard del call center

La compañera reconstruyó el encargo técnico a partir de un dashboard existente del call center, que deriva a los compradores de obra nueva hacia los promotores. Después, la autora montó un dashboard nuevo con otro agente, que no había visto la versión original. La pregunta principal del cliente («¿Por qué han disminuido las transferencias objetivo?») no se destacó por separado en el encargo, para que el agente dedujera por sí mismo que era la principal.

La primera versión parecía completa: siete tarjetas, evolución, gráfico de cascada, fuentes, ciudades, mapa de calor, carga y una tabla. Pero no cumplía su cometido. A partir de ahí vinieron las correcciones:

• Evolución. Un único gráfico con proporciones y cantidades en el mismo panel se dividió en cinco. El periodo anterior se mostró con línea discontinua y las semanas incompletas se sombrearon en gris; de lo contrario, el final del mes parecería una caída.
• Mapa de calor. En septiembre hay cinco martes y cinco miércoles, y cuatro del resto de los días, así que las sumas de llamadas distorsionaban la imagen. Se sustituyó la suma por la media, se añadió una leyenda y los números pasaron a una información emergente.
• Fuentes y ciudades. Se convirtieron en tablas con una barra, el valor y la variación respecto al periodo anterior, y se puso «Total» en la primera fila.
• Empleados. Se agruparon por equipos, las filas pequeñas se contrajeron en «Otros» y se pintó a todos del mismo color, para que ningún equipo pareciera rezagado por culpa del rojo.
• Indicadores unificados. En todas partes se dejó la proporción de transferencias no objetivo, en lugar de mostrar aquí las objetivo y allá las no objetivo.

Lo principal no lo hizo el agente por sí solo. La respuesta a la pregunta del cliente la daba el gráfico de cascada, que muestra la contribución de cada factor a la variación de las transferencias objetivo. El agente lo construyó, pero lo colocó en un lateral, a media anchura, y no entendió que esa era precisamente la respuesta. Las personas tuvieron que moverlo bajo las tarjetas, a todo el ancho, y resaltar la única contribución grande: −63 transferencias objetivo por el aumento de la proporción de transferencias no objetivo. Incluso hubo más tareas, pero menos transferencias objetivo, precisamente porque creció la proporción de las no objetivo.

Reglas que conviene fijar

La autora reunió sus conclusiones en una lista que se puede convertir en un skill para el agente:

• La comparación debe ser honesta: una escala por gráfico, periodos incompletos señalados y media en lugar de suma si los periodos tienen distinto número de días.
• Una cifra sin base de comparación no significa nada. Junto al 82,3% hace falta el periodo anterior.
• No duplicar lo que ya se muestra: si hay números sobre las barras, la escala sobra.
• Todo lo necesario para leer el gráfico va rotulado: periodo, base de comparación y unidades.
• El color se asigna a un significado en toda la pantalla. Verde y rojo, solo para la valoración «mejor/peor»; el aumento del volumen de llamadas es neutro y va en gris.

Qué se desprende de esto

Conviene señalar las limitaciones por separado. Todo el artículo se apoya en un único dashboard con datos sintéticos. Las cifras definitivas del ahorro de tiempo no se revelan en el fragmento de texto disponible, así que «8–10 días en lugar de 20» debe entenderse como una afirmación del equipo, no como una medición independiente. Los autores, en cualquier caso, siguen verificando a mano las fuentes y los cálculos.

La conclusión práctica es sencilla. Se le puede encargar al agente la búsqueda de datos, el SQL y la rutina de los filtros, pero la priorización y la jerarquía visual es mejor formularlas de forma explícita. Si las reglas del dashboard se plasman en un skill, el agente cometerá menos errores típicos desde la primera iteración. Y la pregunta «qué es lo principal aquí y por qué» seguirá teniendo que plantearla una persona.