Agentes de AI con prioridad en la evaluación: cómo Zepto escala la atención al cliente en Databricks y MLflow

El impulso de Zepto hacia un soporte al cliente confiable y en tiempo real

Zepto es una de las plataformas de comercio rápido (quick-commerce) de más rápido crecimiento en la India, con miles de productos, presencia en más de 60 ciudades y plazos de entrega medidos en minutos. En un negocio donde la velocidad es el producto, el soporte al cliente debe moverse igual de rápido.

Para cumplir con esa expectativa, Zepto gestiona el soporte al cliente mediante un sistema de AI multiagente que procesa más de cien mil tickets al día. Al principio, el equipo podía desarrollar e implementar agentes rápidamente. La pregunta más difícil era cómo mantener la confiabilidad de esos agentes a medida que crecía el volumen, se expandían las categorías y el comportamiento de los clientes seguía cambiando. Zepto se asoció con Databricks para responder a esa pregunta, no implementando más agentes, sino haciendo de la evaluación la forma principal en que se crean, prueban y operan los agentes.

Este blog recorre ese camino: la arquitectura del sistema, el marco de evaluación en Databricks y MLflow, las historias de producción donde demostró su valor, y los resultados y lecciones que surgieron de ello.

Por qué "simplemente lanzar el agente" falla a gran escala

En un negocio de alta velocidad, "simplemente lanzar el agente" funciona justo hasta que falla a gran escala. Con más de 100,000 tickets de agentes de AI al día, incluso una tasa de error del 1% genera miles de malos resultados y una pérdida real de ingresos cada día.

La presión llegaba en oleadas desiguales. Los eventos climáticos, el Diwali y el inicio del verano provocaron fuertes picos en el volumen de tickets. La expansión desde productos de alimentación hacia ropa, electrónica y belleza introdujo nuevos procesos de reembolso, cambio y devolución. Mientras tanto, una base de clientes más diversa y multilingüe trajo una gama más amplia de solicitudes de soporte, y surgían nuevos modos de fallo cada pocas semanas.

El problema de fondo es la brecha de garantía. Los sistemas basados en agentes operan como flujos de trabajo de varios pasos (clasificación de la intención, recuperación de conocimiento, análisis de entradas, razonamiento de decisiones, llamada a herramientas transaccionales y generación de respuestas), por lo que los fallos pueden surgir en cualquier punto del camino, no solo en la respuesta final.

Esta brecha de garantía se tradujo en problemas concretos:

• Los fallos eran invisibles hasta que los clientes se quejaban
• Las correcciones eran lentas
• La respuesta final ocultaba errores internos
• Se carecía de una forma sistemática de equilibrar el costo, el rendimiento y la calidad del agente
• El diseño del agente no reflejaba todas las perspectivas críticas de las partes interesadas
• La confiabilidad era difícil de garantizar ante la rápida evolución de los agentes

El objetivo quedó claro: diseñar un marco de evaluación en Databricks y MLflow para que funcione como la infraestructura central de AI sobre la cual se crean y operan los agentes.

Por qué un marco de evaluación y sus resultados

Un marco de evaluación sólido afecta directamente a cinco ejes de la preparación para producción:

• Confiabilidad: garantías a nivel de sistema de que los agentes se comportan correctamente en todos los pasos, no solo que "suenen bien"
• Velocidad: iteración más rápida y segura en prompts, políticas y modelos, ya que los cambios se someten a pruebas de regresión de forma automática
• Control de costo vs. calidad vs. rendimiento: capacidad de elegir modelos óptimos, estrategias de prompts o estrategias de enrutamiento híbrido para encontrar el punto ideal según las restricciones, con el respaldo de datos de evaluación objetivos
• Gobernanza: trazas auditables, líneas base de evaluación con control de versiones y umbrales bien definidos para la implementación y reversión. Pasar de tomar decisiones basadas en la intuición ("esta versión parece mejor") a basarse en la evidencia ("esta versión supera la línea base en las métricas acordadas")
• Colaboración de las partes interesadas: capturar los criterios de éxito y confiabilidad desde la perspectiva de los interesados, y hacer que las compensaciones sean explícitas y medibles para todos

Con Databricks + MLflow como base de evaluación y una arquitectura de agentes centrada en la evaluación, Zepto logró

Costo y eficiencia

• Más del 80% de los tickets gestionados en su totalidad por agentes de AI con supervisión humana
• Reducción del 65% en costos de soporte o tickets de soporte
• Período de recuperación de la inversión de menos de un mes

Calidad y reputación

• Mejora del 20% en la satisfacción del cliente (CSAT)
• Mejora del 8% en la precisión

Rendimiento y operaciones

• Ciclos de desarrollo 3 veces más rápidos
• Tiempo de resolución 4 veces más rápido

Construcción del marco: un doble bucle para la confianza y el control

En el núcleo de este enfoque se encuentra el modelo de doble bucle: un bucle de desarrollo y un bucle de producción, conectados por una puerta de calidad. Esta sección describe cómo funcionan estos bucles en conjunto.

• Bucle de desarrollo: donde diseña, itera y evalúa las versiones de los agentes para crearlos con confianza antes de implementarlos
• Bucle de producción: donde monitorea el comportamiento en vivo y detecta fallos para operar los agentes con confianza
• Bucle de retroalimentación: donde los fallos de producción se envían de vuelta al desarrollo para enriquecer la siguiente iteración
• Puerta de calidad: controla el movimiento entre bucles, decide qué versiones se permiten en producción y cuáles se devuelven al desarrollo para realizar mejores iteraciones

Juntos, estos dos bucles garantizan que los agentes se creen y operen bajo control. Cualquier fallo se captura, se retroalimenta y se corrige automáticamente. Como resultado, los agentes se desarrollan con confianza, se ejecutan con control y mejoran continuamente para gestionar mejor los fallos de producción a lo largo del tiempo. El doble bucle se encuentra en el núcleo de nuestro marco de trabajo.

Fase 0: Habilitar el rastreo: agentes transparentes por diseño

Cada invocación del agente emite una traza de ejecución detallada que captura prompts, completados, documentos recuperados, llamadas a herramientas, latencias y rutas de decisión, de modo que todo el flujo de trabajo es observable a un nivel granular en lugar de limitarse a una entrada y una salida final.

Habilitamos esto con un enfoque híbrido utilizando MLflow. Una sola línea, mlflow.<library>.autolog(), activa el rastreo automático, y el decorador @mlflow.trace añade spans personalizados dondequiera que necesitemos más detalles. Las trazas se emiten en tiempo real como spans de OpenTelemetry con IDs únicos para que sigan siendo combinables, y la integración de MLflow con Unity Catalog centraliza el registro en tablas Delta.

Fase 1: Establecer dimensiones de evaluación: pilares y puertas

Con el rastreo habilitado, el siguiente paso es capturar, desde la perspectiva de cada parte interesada, “¿Qué significa el éxito de este agente para usted?”. Formalizamos esto como pilares de evaluación, cada uno con puertas de control específicas.

Esto convierte un debate entre múltiples partes interesadas en un contrato compartido y medible. Los agentes se evalúan según las dimensiones que realmente importan para cada parte interesada. Los pilares típicos incluyen la experiencia del cliente, la eficiencia operativa, el riesgo y cumplimiento, y el impacto financiero; cada pilar tiene umbrales numéricos claros que deben cumplirse antes de la implementación.

Fase 2: El conjunto de datos de referencia (Golden Dataset): piedra angular de la confiabilidad

El conjunto de datos de referencia (golden dataset) es la única fuente de verdad para evaluar el comportamiento de los agentes en el bucle de desarrollo. Debe:

• Cubrir casos normales, extremos (edge cases) y de fallo que el agente debe gestionar
• Incluir las expectativas de las diferentes partes interesadas capturadas como ejemplos
• Estar ampliamente anotado con metadatos (tipo de escenario, línea de negocio, nivel de riesgo, etc.)

Todos los interesados colaboran para dar forma al conjunto de datos; por ejemplo, el equipo de seguridad aporta ejemplos de patrones adversarios como la inyección de prompts, ataques de identidad e intentos de filtración de datos. Esto garantiza que la confiabilidad se mida tanto en escenarios del mundo real como en el uso habitual.

Los conjuntos de datos son un activo vivo y su calidad se acumula con el tiempo. La brecha de precisión entre el desarrollo y la producción es, en sí misma, una señal de la calidad del conjunto de datos. Zepto invirtió de forma constante en conjuntos de datos de evaluación de MLflow durante seis meses, pasando de 500 ejemplos y una brecha de precisión de 8 puntos entre desarrollo y producción, a 2,000 ejemplos y una brecha de 2 puntos, y finalmente a 5,247 ejemplos y una brecha de 0.4 puntos. Cada hora dedicada a la calidad del conjunto de datos ahorra aproximadamente diez horas de depuración en producción, por lo que el golden dataset se convierte en un multiplicador de 10x: cada fallo en producción añade trazas de error al golden dataset y hace que el sistema sea más robusto para todas las versiones futuras.

Fase 3: Automatizar la ingeniería de prompts: autogeneración y autooptimización

En lugar de escribir los prompts a mano, convertimos la ingeniería de prompts en un proceso automatizado y basado en datos. El diseño de prompts es la fase crítica en la que los ingenieros pasan la mayor parte de su tiempo, y la calidad de los prompts tiene un impacto desproporcionado en la calidad y el rendimiento de los resultados de los agentes.

Mediante la optimización de prompts de MLflow, registramos un prompt inicial, generamos y optimizamos variantes frente a los mismos evaluadores que controlan la implementación, ejecutamos evaluaciones A/B de forma automática y desplegamos el mejor resultado. El optimizador reflexiona con un modelo potente y califica a los candidatos en producción con uno más económico, de modo que la propia búsqueda siga controlando los costos en producción. Esto redujo la experimentación manual de prompts, mejoró la precisión y garantizó que las mejoras de los prompts se midieran siempre con respecto al golden dataset antes de llegar a producción.

Fase 4: Definir evaluadores y configurar el jurado de IA

Con las trazas fluyendo en el bucle de producción, necesitamos evaluarlas según las dimensiones que importan para la calidad del agente (dimensiones de evaluación). Piense en esto como un jurado de IA, donde cada evaluador aprovecha sus puntos fuertes. MLflow ofrece tres opciones para crear evaluadores.

• Jueces integrados: evaluadores listos para usar
• Jueces personalizados: cree jueces personalizados para satisfacer necesidades específicas
• Evaluadores basados en código: para métricas deterministas como la latencia de la herramienta o el número de llamadas a la herramienta

Utilizamos evaluadores basados en LLM solo cuando es necesario un juicio similar al humano y recurrimos a reglas sencillas cuando la lógica determinista es suficiente. Calibramos los jueces con etiquetas humanas para alcanzar un acuerdo del 80-90% y utilizamos varios jueces para decisiones de gran importancia.

Fase 5: Configurar la opcionalidad de modelos

La opcionalidad de modelos es un componente crítico que permite al entorno de trabajo cambiar entre múltiples modelos propietarios y de código abierto simplemente modificando los nombres de los modelos en Databricks. Esto significa que el bucle de desarrollo puede buscar continuamente una mejor combinación para encontrar el equilibrio óptimo entre costo, rendimiento y calidad.

Fase 6: Crear la autorregresión

Automatizamos la evaluación de regresión para crear un bucle de desarrollo repetible, configurable y escalable. Cualquier cambio activa la autorregresión y, cuando se garantiza la confiabilidad, el autodespliegue.

Al unir todas las piezas, un cambio típico sigue este camino:

1. Alguien cambia la lógica, el prompt o el modelo del agente.
2. El flujo de trabajo de evaluación se activa automáticamente con tres entradas: la nueva versión del agente, el golden dataset y la línea base de producción actual.
3. El sistema ejecuta evaluaciones y genera métricas en todos los evaluadores y pilares.
4. El control de calidad verifica:
   • ¿Cumple la nueva versión con todos los controles (costo, calidad, rendimiento, etc.)?
   • ¿Funciona al menos tan bien o mejor que la línea base de producción?
5. En caso afirmativo, la nueva versión se promueve a producción; si no, se rechaza y el agente existente sigue atendiendo el tráfico.

Fase 7: Crear el bucle de producción: configurar una red de seguridad en tiempo real

Evaluar el 100% del tráfico es costoso, pero un muestreo uniforme e ingenuo del 10% pasa por alto la mayoría de los casos extremos. Implementamos un muestreo estratificado donde las tasas de muestreo de evaluación dependen de clientes de alto valor, nuevas funciones o flujos modificados recientemente, sentimiento negativo o alto riesgo de escalación, e interacciones basadas en imágenes o propensas al fraude. Esto genera una muestra de evaluación efectiva del 18-20% (~14,400 trazas al día) a un costo manejable, al tiempo que captura entre el 45% y el 60% de los casos extremos y detecta problemas en un plazo de 4 a 6 minutos.

La lógica financiera es contundente: en comparación con un enfoque de muestreo uniforme, la metodología estratificada logró una reducción del 86% en el costo de revisión por problema identificado, al tiempo que ofreció una mejora de 9 veces en la detección de casos extremos, lo que hace que el proceso de control de calidad sea significativamente más eficiente y escalable.

Los resultados de la evaluación se escriben en tablas Delta y se muestran a través de paneles y reglas de alerta en Databricks. Las alertas críticas (que se revisan cada 5 minutos) monitorean caídas en la precisión de la intención, violaciones de fundamentación (groundedness), alto riesgo de escalación e infracciones de latencia P95. Las alertas altas/medias realizan un seguimiento de la degradación de la empatía, picos de costos, tasas de fallo de herramientas, tendencias de CSAT, tasa de detección de fraudes y latencia multimodal. Esto permite operaciones similares a SRE para agentes de IA: detección rápida, clasificación y mitigación.

La pila de agentes de arquitectura componible

Un buen entorno de evaluación funciona mucho mejor cuando la arquitectura del agente está diseñada para ser observable y descomponible desde el principio. La pila de soporte de Zepto se basa en esa idea.

La consulta de un cliente, ya sea en forma de chat o de imagen, pasa primero por un enrutador y orquestador de agentes. El enrutador puede transferir la consulta a un humano en cualquier momento. Por debajo de este, el sistema se divide en dos tipos de agentes.

Los agentes verticales son especialistas, y cada uno se encarga de una única familia de intenciones bien definida:

• WIMO: para el seguimiento de pedidos y preguntas sobre la ETA
• Faltantes: para pedidos no entregados o parciales
• Vencimiento: para productos envasados vencidos
• Devoluciones: para el estado y procesamiento de reembolsos
• Calidad: para productos frescos en mal estado o podridos
• No se puede pagar: para fallos en la billetera virtual, promociones y pagos
• General, como alternativa de respaldo

Los agentes horizontales actúan como capas de supervisión que abarcan diversos casos de uso:

• Deduplicación de imágenes: detecta imágenes reutilizadas en diferentes reclamaciones
• Coincidencia de artículos y detección de manipulación de imágenes: verifican que las imágenes subidas coincidan con los artículos del catálogo y no hayan sido editadas

Esta separación rinde frutos por partida doble. Las métricas se pueden calcular por agente vertical, como la F1 de intención de WIMO o la precisión de OCR de vencimiento, y los agentes horizontales se pueden evaluar en aspectos transversales como la precisión de fraude, la reutilización de imágenes y la detección de manipulación. Cada pieza se puede medir de forma aislada y en combinación.

El framework en acción

Cuando lanzas por primera vez un agente de AI a producción, se siente como enviar a un pasante brillante pero impredecible a representar a tu empresa. Le das instrucciones y esperas lo mejor, pero hasta que no está bajo presión, básicamente estás volando a ciegas.

Al principio, nos dimos cuenta de que el monitoreo de software tradicional es completamente útil para la AI. Un agente puede tener un tiempo de actividad del servidor perfecto y cero errores mientras repite exactamente la misma respuesta incorrecta a un cliente frustrado. Para los ingenieros, el panel de control se ve verde. Para el cliente, es un desastre.

Sabíamos que no podíamos escalar nuestra AI basándonos solo en la esperanza. Necesitábamos un framework de evaluación que no solo rastreara si la AI estaba hablando, sino que realmente entendiera lo que decía y dónde estaba fallando. Las siguientes historias son los momentos en que ese framework demostró su valor, probando que un buen sistema de evaluación desbloquea características de producto completamente nuevas.

Historia 1: El ETA que nunca se movió

Un problema de producción dejó a los repartidores atrapados en el tráfico mientras el agente seguía respondiendo "llegando en 10 min" en un bucle, porque estaba leyendo datos almacenados en caché. El cliente preguntó dónde estaba su pedido, recibió la misma respuesta, volvió a preguntar y recibió la misma respuesta otra vez.

El contador de tokens (que monitorea el uso de tokens) y los evaluadores de advertencias detectaron la repetición y el alto riesgo de escalación en menos de 5 minutos, mostrando trazas de repartidores estacionarios con ETAs sin cambios. Eso activó un cambio de regla. Si un repartidor permanece estacionario durante más de 10 minutos, el agente ahora ofrece una actualización honesta y propone proactivamente la cancelación para un reembolso completo, en lugar de repetir una promesa obsoleta.

Un hallazgo, detectado por la evaluación en línea, se convirtió en toda una línea de funciones: cancelación por retraso, una propuesta proactiva para cancelar durante la escasez de repartidores, cancelación automática si no se asigna ningún repartidor dentro de un plazo establecido y cancelación sin preguntas para clientes de alto valor.

Historia 2: Detectar la regresión de cancelación antes que los clientes

Cuando Zepto agregó la gestión de cancelaciones al agente WIMO, el modelo comenzó a confundir tres intenciones muy diferentes: "dónde está mi pedido", "quiero cancelar" y "¿se canceló mi pedido?".

La evaluación de MLflow en la fase de desarrollo lo detectó de inmediato. La precisión general de la intención cayó de aproximadamente el 92.1 por ciento al 87.4 por ciento, con un F1 deficiente en las nuevas intenciones WIMO_CANCEL y WIMO_CANCEL_STATUS. Debido a que la regresión apareció frente al conjunto de datos de referencia (golden dataset), ningún cliente llegó a verla. La optimización de prompts y las actualizaciones del conjunto de datos restauraron la precisión general a aproximadamente el 94.2 por ciento, mejor que la línea base original, con un F1 de llamada a herramientas casi perfecto en las APIs de cancelación. La función se lanzó en vivo con cero rollbacks.

Historia 3: Calibrar agentes multimodales frente al juicio humano

La calidad de los productos frescos es realmente difícil de calificar y los humanos no siempre están de acuerdo. La misma imagen de champiñones podría obtener un 2 de 5 de un evaluador y un 3 de 5 de otro. Medimos ese desacuerdo con el Kappa de Cohen y lo tratamos como nuestro límite máximo de confiabilidad, ya que ningún modelo puede ser más consistente que los humanos de los que aprende.

También descubrimos que la AI iba a lo seguro. Por sí sola, acumulaba puntuaciones en 3 para evitar tomar una decisión difícil, mientras que las puntuaciones humanas alcanzaban su punto máximo en 4 y 5. Así que no solo minimizamos el error frente al promedio, sino que igualamos la forma de la distribución de las puntuaciones humanas. La evaluación en línea también reveló casos para los que el sistema no estaba diseñado, como la leche cortada que se almacena como un producto envasado pero debe juzgarse como un producto fresco, y las quejas de sabor u olor que una foto simplemente no puede mostrar, las cuales se redirigieron a una ruta separada.

Esta línea base calibrada nos permite decidir qué modelos usar por tipo de producto, cómo iterar los prompts frente al juicio humano y cómo ajustar la política de reembolsos por segmento de clientes en función del rendimiento real del agente.

Historia 4: Cerrar las puertas traseras de abuso

Los intentos de abuso de reembolsos utilizaban imágenes de catálogo, fotos editadas e imágenes reutilizadas en diferentes reclamaciones. El pipeline de evaluación multimodal pasaba las imágenes por controles de preprocesamiento de desenfoque, brillo y resolución, las validaba con OCR y luego utilizaba un jurado de tres modelos de visión con reglas de consenso para decidir entre la aprobación automática y la revisión humana. Por encima de esto, se aplicaron capas de detección de desenfoque, detección de capturas de pantalla, detección de duplicados, coincidencia de imagen contra SKU, verificaciones de imagen contra el motivo declarado y validación de prueba de entrega.

Lo que aprendimos al ejecutar esto a escala

Operar este framework a escala nos enseñó algunos principios que se generalizan más allá del comercio rápido (quick commerce).

• Nunca optimices una sola métrica. Una vez perseguimos la precisión de la intención de forma aislada y vimos caer el CSAT. Optimizar solo la intención ganó 5 puntos de precisión de intención, pero aumentó la latencia en un 133 por ciento y costó 0.4 puntos de CSAT. Una puntuación compuesta y multiobjetivo ganó 3 puntos de intención con solo un 17 por ciento más de latencia y sumó 0.2 puntos de CSAT. Múltiples perspectivas, jueces de LLM, controles basados en reglas, etiquetas humanas y métricas de producción crean la verdad en conjunto. Esa redundancia es un seguro, no un desperdicio.
• Los conjuntos de datos de referencia (golden datasets) son la base. Invierte temprano para lograr miles de ejemplos diversos y de alta calidad. Realiza un seguimiento de la brecha entre la precisión de desarrollo y la de producción, y ajusta hasta que converjan. La brecha entre desarrollo y producción es una señal de calidad del conjunto de datos, no un misterio.
• Los jueces de LLM necesitan calibración. Trata a los jueces como modelos con su propia evaluación. Mide su nivel de acuerdo con los humanos, utiliza ensambles para casos de alto riesgo y recalibra a medida que cambian los modelos base.
• La estrategia de muestreo importa más que la tasa de muestreo. El muestreo uniforme simple es económico pero ciego. El muestreo estratificado enfocado en flujos de alto riesgo ofrece una detección de problemas un orden de magnitud mejor por cada dólar invertido.
• Automatiza el bucle de retroalimentación desde el primer día. Detectar, etiquetar, reentrenar, implementar y monitorear debe estar automatizado, de modo que cada falla enriquezca automáticamente la siguiente ronda de entrenamiento. Para nosotros, esto ahorró alrededor de 155 horas al mes, el equivalente a dos ingenieros de tiempo completo reasignados a tareas de desarrollo de funciones.
• Trata la evaluación como una superficie de producto. Los paneles de control y las métricas son utilizados por los equipos de soporte, producto, fraude y operaciones. Tienen que ser interpretables y accionables, no solo técnicamente correctos.

Recomendaciones para creadores de agentes

Para las organizaciones que crean sistemas basados en agentes en Databricks, la experiencia de Zepto sugiere la siguiente hoja de ruta:

• Comienza a partir de trazas, no solo de modelos: impón un esquema de trazas compartido y regístralo todo en Delta
• Haz que las evaluaciones de MLflow sean un filtro obligatorio en CI/CD: sin implementación si no se supera la línea base en las métricas acordadas
• Crea conjuntos de datos de referencia (golden datasets) como un activo, con sus propios KPIs (tamaño, brecha entre desarrollo y producción, cobertura de casos extremos)
• Usa LLM como juez para lo que los humanos juzgan hoy en día (calidad, empatía, fundamentación), pero calíbralo y limítalo a los segmentos adecuados
• Implementa el muestreo estratificado y las alertas en tiempo real lo antes posible; adaptar la visibilidad operativa más tarde es costoso
• Diseña los agentes para que puedan ser verticales (especializados) y horizontales (de supervisión), de modo que puedas evaluarlos de forma aislada y en conjunto

Conclusión

En la transición de demostraciones experimentales a infraestructura de misión crítica, la restricción principal ha pasado de la capacidad bruta del modelo a la garantía del sistema. El trayecto de Zepto demuestra que, al establecer la evaluación como la primitiva de desarrollo fundamental, las organizaciones pueden escalar agentes de manera confiable para gestionar decenas de miles de interacciones diarias complejas a través de entradas multimodales, respaldadas por rigurosas garantías de calidad, costo y mitigación de riesgos.

Databricks y MLflow sirven como el sustrato esencial para esta evolución, proporcionando una infraestructura de datos centrada en trazas en Unity Catalog y Delta, junto con una evaluación escalable, optimización automatizada de prompts e integración fluida de CI/CD. Esta pila componible, combinada con la opcionalidad de modelos, permite a los equipos ajustar con precisión el equilibrio entre el rendimiento y el gasto para cada tarea específica.

En última instancia, la ventaja competitiva radica en la decisión estratégica de tratar la evaluación no como una comprobación final, sino como infraestructura de AI central. El plan para operar agentes a escala de producción ya no es un misterio; Zepto y Databricks han proporcionado la respuesta. El desafío ahora es la velocidad de adopción. En el panorama de la AI en rápida evolución, los líderes no serán quienes esperen una certeza absoluta, sino quienes diseñen para la confiabilidad desde el primer día.

Para los desarrolladores que crean agentes que deben ganarse la confianza en entornos de producción, estos mismos componentes fundamentales ya están listos en Databricks y MLflow 3. Las organizaciones que definan la próxima frontera serán aquellas que comiencen hoy mismo su viaje dando prioridad a la evaluación.

Crear agentes en Databricks
Comience con la evaluación y el monitoreo de MLflow

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original