Aprendizaje a partir de la experiencia del mundo real

Postentrenamiento de un modelo Perplexity Computer para imitar comportamientos exitosos, reducir la necesidad de correcciones de los usuarios y evitar errores de herramientas.

AutoresPerplexity Research

La forma en que los usuarios interactúan con nuestros productos en el mundo real es una fuente valiosa para el entrenamiento de modelos. Los datos son abundantes, reflejan la distribución real de las tareas de los usuarios y capturan las correcciones de los usuarios y los fallos de las herramientas que los entornos sintéticos pueden pasar por alto.

Una forma común de aprender de los datos del mundo real es el ajuste por muestreo de rechazo: juzgar el resultado de cada sesión, conservar las exitosas y entrenar al modelo para que las imite. Pero un resultado exitoso no significa que cada paso fuera correcto, por lo que imitar toda la trayectoria corre el riesgo de reforzar los malos comportamientos intermedios además de los buenos. Descartar las sesiones sin éxito también hace que se pierda evidencia fundamental de dónde se queda corto el modelo.

Combinamos el ajuste por muestreo de rechazo con la auto-destilación guiada por pistas para aprender tanto de las sesiones exitosas como de las fallidas. Una pista es una breve instrucción correctiva basada en la información que el modelo ya poseía cuando cometió el error. Los pasos útiles de las sesiones exitosas siguen siendo objetivos de imitación, mientras que las pistas fundamentadas transforman los errores evitables en objetivos de corrección.

Las correcciones de los usuarios y los errores de herramientas añaden supervisión sobre lo que salió mal en el camino, además de si la tarea tuvo éxito en última instancia. Aplicamos esta etapa después del aprendizaje por refuerzo en entornos sintéticos para ayudar a cerrar la brecha entre dichos entornos y el uso en el mundo real.

En uso real, un punto de control posterior al entrenamiento de GLM-5.2 redujo los fallos de llamadas a herramientas en un 21,2% en comparación con un punto de control entrenado anteriormente. Para GLM-5.3, el entrenamiento posterior redujo los fallos de llamadas a herramientas en un 33,0% y la probabilidad estimada promedio de insatisfacción media o alta del usuario en un 17,2% en comparación con el modelo base.

De los datos sintéticos a los del mundo real

Las tareas sintéticas nos permiten crear problemas controlados con resultados fáciles de verificar, pero normalmente se limitan a un solo mensaje y solo pueden cubrir los escenarios que diseñamos explícitamente.

Por el contrario, los usuarios en sesiones del mundo real aportan diversas instrucciones, contextos y combinaciones de herramientas en sesiones que se desarrollan a lo largo de varios turnos de interacción. Dicho uso en el mundo real genera de forma natural dos señales valiosas de errores: las correcciones de los usuarios revelan dónde el agente no logró ofrecer lo que querían, y los errores de herramientas muestran dónde sus acciones fracasaron en entornos reales. Nuestro canal de muestreo respeta la privacidad de los usuarios y las opciones de entrenamiento al excluir sesiones con información de identificación personal (PII) y de usuarios que han optado por no participar.

Por lo tanto, los datos del mundo real nos ofrecen casos de fallos que un entorno sintético puede no exponer y a menudo vienen con el lugar donde se produjo el fallo ya integrado.

Imitar los buenos pasos, corregir los malos

Al entrenar con datos del mundo real, el ajuste por muestreo de rechazo (RFT) estándar selecciona las sesiones exitosas en función de sus resultados finales, sin utilizar explícitamente los comentarios de los usuarios y de las herramientas para distinguir las buenas acciones intermedias de las malas. Un agente puede recuperarse de una llamada de herramienta errónea o corregir un error tras los comentarios del usuario y aun así ofrecer la salida correcta al final.

Descartar sesiones fallidas también limita la eficiencia de la muestra. Una sesión que nunca llega a un buen resultado aun así podría revelar un error claro y evitable como señales de entrenamiento útiles.

Abordamos estas limitaciones separando dos decisiones: qué sesiones contienen un comportamiento que vale la pena imitar y qué turnos contienen errores que vale la pena corregir. El canal de datos toma estas decisiones por separado y luego asigna a los turnos del modelo uno de tres tratamientos:

  • Imitar: los turnos sin errores en las sesiones exitosas reciben la pérdida de entropía cruzada (CE) ordinaria, lo que aumenta la probabilidad de los tokens registrados.
  • Correcto: tanto en las sesiones exitosas como en las que no tienen éxito, los turnos de error con una pista válida reciben una pérdida de divergencia de Kullback–Leibler (KL), lo que acerca al modelo a las predicciones del siguiente token que realiza cuando ve la pista.
  • Mantener como contexto: los turnos en sesiones sin éxito que carecen de una pista validada y los turnos incorrectos marcados sin una pista validada en cualquier tipo de sesión sirven como contexto pero no reciben ninguna de las pérdidas.

Como resultado, las sesiones exitosas pueden proporcionar tanto objetivos de imitación como de corrección, mientras que las sesiones sin éxito proporcionan solo objetivos de corrección. Todos los turnos restantes, incluidas las salidas del sistema, del usuario y de las herramientas, permanecen como contexto.

Enrutamiento de sesiones actual y máscaras de contenido del asistente. Las sesiones exitosas aportan objetivos de imitación; los registros de comentarios retenidos pueden aportar correcciones con pistas incluso cuando la sesión no tiene éxito. El otro contenido permanece como contexto. Se excluyen las sesiones incompletas. No se dibuja la excepción CE de rendimiento/token de parada no final, y este diagrama no establece la mezcla utilizada por un punto de control anterior.

La parte de imitación utiliza el RFT estándar. La parte correctora utiliza la autodestilación en política (OPSD): el mismo modelo actúa como profesor y estudiante, y al profesor se le proporciona información privilegiada. En este caso, esa información privilegiada es una breve pista que explica un error evitable. Entrenamos al estudiante para que coincida con las predicciones del siguiente token del profesor sin que se le entregue la pista.

Ambas partes importan. El entrenamiento basado únicamente en correcciones puede exponer un atajo: el profesor y el estudiante pueden coincidir ignorando el contexto en lugar de aprender la corrección. El término CE ancla el entrenamiento a un comportamiento útil, lo que ayuda a desalentar el acuerdo que proviene de ignorar el contexto.

El estudiante postentrenado se convierte entonces en una opción de modelo en Computer. Las sesiones recientes de su uso en vivo pasan a través de los mismos filtros de elegibilidad y privacidad antes de entrar en otra ronda del canal de entrenamiento.

Un ejemplo: una sesión puede enseñar ambas lecciones

A continuación, repasamos un ejemplo concreto que contiene tanto imitación como corrección.

Considere una sesión eventualmente exitosa en la que el usuario solicita una comparación de los cambios de asyncio en Python 3.13 utilizando la documentación oficial. Nuestra documentación de herramientas establece que search.web devuelve una lista de aciertos, cada uno con un campo url.

El modelo primero ejecuta una búsqueda válida para una versión como parte de la recopilación de evidencia para la comparación, lo cual es un buen comportamiento que imitar.

Sin embargo, la siguiente llamada de ejecución de código trata incorrectamente esa lista como un diccionario. La herramienta de código devuelve TypeError: list indices must be integers or slices, not str. Debido a que el tipo de retorno se documentó antes de la llamada, es un error que el modelo debería haber podido evitar. Se puede generar una pista con la llamada correcta para corregir dicha acción.

Una sesión de programación ilustrativa muestra tres roles de entrenamiento: entradas solo de contexto y salidas de herramientas (gris), imitación CE de llamadas registradas útiles (oscuro) y corrección KL de un error marcado (verde azulado). Aquí, el modelo trata incorrectamente una lista de aciertos de búsqueda como un diccionario; una pista exclusiva del profesor fundamentada en la documentación de herramientas anterior guía la corrección. Los objetivos CE se aplican solo cuando se considera que la sesión completada ha tenido éxito, mientras que una sesión sin éxito aún puede proporcionar un objetivo de corrección KL elegible.

Cómo funciona el entrenamiento

El canal de entrenamiento consta de cuatro etapas: seleccionar sesiones y juzgar sus resultados, identificar errores y crear pistas a partir de los comentarios de los usuarios y los errores de herramientas, generar probabilidades de siguiente token tanto del profesor como del estudiante, y entrenar al modelo con una pérdida combinada de CE y KL.

Seleccionar sesiones y luego juzgar el resultado

El proceso de muestreo toma un subconjunto elegible para entrenamiento de sesiones reales de Computer servidas por GLM 5.2. Las exclusiones por rechazo al entrenamiento y las relacionadas con PII del proceso se aplican antes de seleccionar ejemplos para este flujo de trabajo.

El proceso de cribado inicial selecciona los candidatos calificados con 4 o 5 en una escala de dificultad de tareas de cinco puntos por un juez de LLM y los divide en 2 grupos:

  • El grupo de comentarios de los usuarios contiene sesiones con un seguimiento genuino del usuario o un indicador de insatisfacción de media a alta. Encontramos que estos seguimientos de alta intención son especialmente útiles para el aprendizaje: los usuarios intentan activamente completar una tarea y sus correcciones señalan con precisión lo que el modelo pasó por alto.
  • El grupo de errores de herramientas contiene sesiones con llamadas fallidas marcadas mediante comprobaciones basadas en reglas, excluyendo los fallos de infraestructura reconocidos y las autorizaciones denegadas.

Dos jueces de LLM evalúan luego la entrega final en función de la solicitud del usuario; ambos jueces deben emitir un veredicto positivo para etiquetar la sesión como "exitosa". En el caso de las tareas que entregan artefactos, la fase de resultados puede reconstruir e inspeccionar la entrega y recurrir a sus juicios basados en texto si dicha fase falla. Se excluyen las sesiones clasificadas como incompletas, como el trabajo a la espera del usuario.

Este paso identifica fuentes potenciales de señales de aprendizaje; sin embargo, no todos los errores son atribuibles al modelo, ya que algunos surgen de instrucciones ambiguas o fallos de la infraestructura. La anotación posterior determina qué errores candidatos son realmente evitables y adecuados para el entrenamiento.

Encontrar los errores a partir de los comentarios de los usuarios

Considere una sesión de ejemplo en el grupo de comentarios de los usuarios, donde el usuario pregunta: "¿Cómo encuentro mi w3 en paychex?". El modelo trata "w3" como un error tipográfico de W-2, busca instrucciones para W-2 y explica cómo encontrar ese formulario. La pregunta de seguimiento del usuario, "Me refería al formulario de transmisión W-3", identifica el error, incluso si la sesión finalmente tiene éxito.

La queja ayuda a localizar el error, pero la causa raíz es la decisión anterior de reinterpretar "w3" como W-2. La solicitud original hace que el error sea evitable: el modelo podría haber conservado W-3 o haber pedido una aclaración. Resulta que el último turno del asistente antes de la queja es la causa raíz solo aproximadamente la mitad de las veces.

Nuestro canal de anotación mapea la causa y el efecto de forma sistemática dentro de cada sesión de comentarios de los usuarios. El anotador primero examina si hay un requisito omitido o una intención respaldada por el contexto anterior. Tres jueces de LLM identifican luego los turnos responsables, exigiendo que al menos dos coincidan en un turno determinado. A veces, una declaración anterior establece explícitamente el requisito. En otros casos, ninguna declaración previa por sí sola lo hace, pero múltiples piezas de la conversación precedente permiten inferir conjuntamente el comportamiento pretendido. Este diseño les permite conectar una queja con un error raíz anterior en lugar de atribuirla únicamente a la última respuesta.

Antes de aceptar una pista, el canal también comprueba que sus afirmaciones correctoras se deriven de la información disponible antes del turno marcado. Estas comprobaciones pretenden reducir el sesgo retrospectivo, en el que una nueva preferencia revelada en la queja se trata como algo que el modelo ya debería haber sabido.

En este ejemplo, la pista le dice al modelo que busque el formulario de transmisión W-3 en Paychex en lugar de W-2, o que pregunte a qué formulario se refiere el usuario si la solicitud es ambigua. La corrección apunta a la interpretación y a la decisión de búsqueda anteriores, no solo a la respuesta final. El turno original permanece inalterado; la anotación añade is_bad_turn: true y un hint no vacío.

Una sesión real que muestra cómo se rastrea una queja hasta un error anterior, con el procedimiento de anotación superpuesto. El usuario solicitó "w3" en Paychex, pero el modelo lo trató como un error tipográfico de W-2 y buscó el formulario incorrecto. El consenso de los proponentes localiza la causa raíz, mientras que dos comprobaciones de fundamentación evalúan si la evidencia es anterior al error y si las afirmaciones de la pista se derivan de la información disponible en ese momento. Las anotaciones aceptadas conservan el texto original y añaden marcas y pistas, en lugar de reescribir los objetivos.

Encontrar los errores a partir de los errores de herramientas

Considere otra sesión en el grupo de errores de herramientas con una llamada de búsqueda en la que el agente busca con recency_filter: "year", pero la herramienta la rechaza porque los valores permitidos son "day", "week" o "month". Esto es una clara violación del esquema.

La ruta de errores de herramientas utiliza reglas deterministas para errores conocidos y el juicio del modelo para casos ambiguos. Un mensaje de error por sí solo tampoco es suficiente para culpar al modelo; una corrección evaluada debe señalar algo que el modelo podría haber sabido por el esquema de la herramienta, las instrucciones del sistema o una conversación anterior.

El argumento de búsqueda no válido del informe ilustra el procedimiento actual de errores de herramientas. El esquema hace que este error sea evitable; un corte por sí solo no lo haría. La llamada original permanece en el registro y recibe una pista fundamentada. La pista permite un valor de la lista o su omisión si el campo es opcional; no exige "mes" para cada solicitud.

Aquí, la pista nombra la llamada fallida, incluye el error de validación e instruye al modelo a utilizar un valor permitido u omitir el campo si es opcional.

Dos pasadas hacia adelante

Una vez marcado un turno, el sistema de entrenamiento ejecuta el mismo punto de control dos veces: una como profesor y otra como estudiante. El profesor ve la pista; el estudiante no.

Ambas pasadas utilizan forzamiento del profesor, donde alimentamos al modelo con la sesión registrada en lugar de dejar que elija nuevos tokens. La pasada hacia adelante sigue produciendo una distribución completa del siguiente token en cada paso, pero siempre está condicionada al prefijo fijo de la grabación, no a los tokens de despliegue.

Para el ejemplo de búsqueda, el mismo modelo asigna una probabilidad mucho mayor a "mes" y menor a "año" cuando se le proporciona la pista. El entrenamiento utiliza este cambio distribucional como un objetivo blando.

Dos pasadas, un conjunto de pesos. Ambas pasadas puntúan la continuación registrada; solo el profesor recibe pistas. Sus probabilidades de siguiente token desconectadas guían al estudiante a través de KL hacia adelante. Los objetivos CE separados anclan la imitación. Ambas pérdidas alimentan una actualización de peso. Las pistas anteriores pueden permanecer en el segmento actual del profesor; ninguna pasada genera una respuesta de entrenamiento de reemplazo.

Las predicciones del profesor están desconectadas o tienen gradiente detenido: proporcionan un objetivo pero no reciben una actualización a través de la pasada del profesor. Después de la pasada del estudiante, un paso del optimizador actualiza el modelo compartido.

La función de pérdida

La pérdida CE

La pérdida CE trata los tokens registrados seleccionados para la imitación como objetivos de verdad fundamental y penaliza al modelo por asignarles bajas probabilidades. Esto crea un objetivo de imitación rígido.

En la posición de token ii, sea pi(v)p_i(v) la probabilidad del estudiante del token vv en el vocabulario completo VV. El siguiente token registrado en la respuesta o llamada de herramienta es yiy_i, la distribución objetivo one-hot es rir_i.

ri(v)=1[v=yi]r_i(v)=\mathbf{1}[v=y_i]

La entropía cruzada mide qué tan bien predice el estudiante ese token registrado. Con un objetivo one-hot, se reduce a la probabilidad logarítmica negativa asignada a yiy_i.

H(ri,pi)=−∑v∈Vri(v)log⁡pi(v)=−log⁡pi(yi)H(r_i,p_i)=-\sum_{v\in V}r_i(v)\log p_i(v)=-\log p_i(y_i)

La máscara CE miCEm_i^{\mathrm{CE}} es 11 donde el token debe ser imitado y 00 en caso contrario. La suma sobre las posiciones seleccionadas da la pérdida de imitación.

LCE=∑imiCEH(ri,pi)\mathcal{L}_{\mathrm{CE}}=\sum_i m_i^{\mathrm{CE}}H(r_i,p_i)

Pérdida KL

En su lugar, la pérdida KL utiliza la distribución de probabilidad completa del siguiente token del profesor qiq_i como un objetivo de corrección blando. El contexto del profesor incluye la pista actual y cualquier pista anterior conservada en ese segmento de entrenamiento; el contexto del estudiante siempre está libre de pistas.

La máscara KL miKLm_i^{\mathrm{KL}} es 11 donde el token debe ser corregido y 00 en caso contrario; las máscaras de CE y KL no se solapan. En estas posiciones, la KL hacia adelante penaliza el desacuerdo entre el profesor y el estudiante en todo el vocabulario:

LKL=∑imiKLDKL(qi∥pi)=∑imiKL∑v∈Vqi(v)log⁡qi(v)pi(v)\mathcal{L}_{\mathrm{KL}}=\sum_i m_i^{\mathrm{KL}}D_{\mathrm{KL}}(q_i\Vert p_i)=\sum_i m_i^{\mathrm{KL}}\sum_{v\in V}q_i(v)\log\frac{q_i(v)}{p_i(v)}

Pérdida combinada

Ambos términos comparten un denominador en lugar de normalizarse por separado. Este denominador cuenta el total de tokens seleccionados para la imitación en todo el lote de entrenamiento global. El peso λ\lambda controla la contribución del entrenamiento corrector en relación con la imitación.

Esta normalización compartida se ajusta a la interfaz de denominador único de nuestra infraestructura de entrenamiento y recupera la pérdida SFT estándar cuando λ=0\lambda=0, lo que simplifica las comparaciones de referencia. Debido a que los tokens de CE son mucho más abundantes que los tokens de KL, el uso de un denominador compartido también evita dar a los tokens de KL individuales pesos desproporcionadamente grandes en lotes con pocos tokens marcados.

L=LCE+λLKL∑imiCE\mathcal{L}=\frac{\mathcal{L}_{\mathrm{CE}}+\lambda\mathcal{L}_{\mathrm{KL}}}{\sum_i m_i^{\mathrm{CE}}}

Aplicado a los ejemplos anteriores, los turnos que contienen la confusión W-3/W-2 y la llamada de búsqueda no válida reciben KL. El otro contenido del asistente sin marcar en una sesión exitosa todavía recibe CE. Otro contenido del asistente en una sesión sin éxito se retiene como contexto pero no recibe ni CE ni KL.

Lo que muestran las evaluaciones

Nuestras evaluaciones responden a dos preguntas distintas. Primero, ¿una pista ayuda realmente a que el modelo corrija un error cuando está presente? Segundo, ¿el entrenamiento ayuda a que el modelo evite ese error más adelante, sin la pista? La primera prueba si las pistas proporcionan señales de entrenamiento útiles. La segunda prueba si el modelo aprende de ellas.

Las pistas pueden orientar al modelo para que se aleje de los errores

Probamos la primera pregunta antes de que se ejecute el entrenamiento para asegurarnos de que las pistas puedan orientar al modelo para que se aleje de los errores.

Comentarios de los usuarios

Regeneramos los turnos marcados de comentarios de los usuarios con y sin una pista, utilizando el mismo modelo base GLM-5.2 a temperatura cero. Un juez ciego ve la queja posterior, pero ni la pista ni la condición que produjo la respuesta.

En el ejemplo de W-3, la pista desplaza la probabilidad del siguiente token hacia "3" y lejos de "2" después del prefijo "W-".

Una pista preserva el formulario W-3 solicitado. Las barras muestran las probabilidades medias del siguiente token en ocho pasadas hacia adelante; los bigotes muestran el rango observado, no un intervalo de confianza. Ambas condiciones utilizan el modelo base inalterado.

En una muestra retenida más grande de 40 turnos respaldada por evidencia anterior declarada explícitamente, la proporción considerada fija o en buen camino aumenta del 40,0% sin pista al 75,0% con ella. En otros 40 turnos respaldados por una intención inferida, aumenta del 32,5% al 80,0%.

Validación de pistas, no evaluación de postentrenamiento. Los mismos 40 turnos marcados en cada grupo de evidencia se regeneran con y sin pista utilizando el GLM-5.2 sin modificar a temperatura cero. El juez ve la queja pero no la pista ni la condición. Los recuentos se derivan de las tasas y los tamaños de muestra del informe; no se informan los intervalos de confianza.

Errores de herramientas

En el ejemplo de error de la herramienta de búsqueda, una pista efectivamente desplaza la masa de probabilidad del token de año al token de mes.

Una pista desplaza la probabilidad hacia un valor permitido. Las barras muestran las probabilidades medias del siguiente token en ocho pasadas hacia adelante; los bigotes muestran el rango observado, no un intervalo de confianza. Ambas condiciones utilizan el mismo modelo base; no se compara ningún punto de control entrenado.

En una muestra retenida más grande de 985 turnos, regeneramos cada turno cuatro veces con y sin pista utilizando el mismo modelo base. Un juez ciego evalúa si cada regeneración evita el fallo original. Las pistas aumentan la evitación de fallos del 75,1% al 93,7%, una ganancia emparejada de 18,6 puntos porcentuales, y aumentan la proporción que adopta la acción corregida del 60,6% al 82,3%. Las ganancias son mayores en errores que el muestreo repetido por sí solo lucha por solucionar.

Validación de pistas de error de herramienta en 985 turnos retenidos marcados, con cuatro regeneraciones por condición. Las barras muestran la evitación de fallos y las tasas de acciones corregidas para el modelo base inalterado, con y sin pistas. Evitar el error objetivo no establece el éxito de la llamada a la herramienta o de la tarea.

Fiabilidad de las herramientas y comentarios de los usuarios tras el entrenamiento

A continuación, probamos si el modelo entrenado comete menos errores sin recibir pistas. Evaluamos el modelo base y varios puntos de control posentrenados en tareas de referencia sin conexión y en sesiones de usuarios reales, comprobando si hay menos fallos de herramientas y menor insatisfacción de los usuarios.

Evaluación offline

La evaluación offline utiliza BrowseComp, Finch, WideSearch, DRACO, DSQA, SpreadsheetBench, HLE, un conjunto representativo de tareas de Computer y verifica la carga de habilidades, la revisión de documentos y las citas en línea. Medimos la proporción de llamadas a herramientas cuyos resultados se marcan explícitamente como errores a lo largo de las trayectorias de evaluación.

En estas evaluaciones, la tasa de errores de herramientas registrada fue del 2,79% para el GLM 5.2 de serie, del 1,35% para el punto de control de RFT exclusivo y del 0,87% para un punto de control de RFT más OPSD. Estos puntos de control se entrenaron con diferentes datos, por lo que esta no es una ablación de datos emparejados de OPSD. Los resultados de referencia a nivel de tarea fueron mixtos, por lo que menos errores de herramientas por sí solos no se traducen necesariamente en una mejora general en el éxito de las tareas.

Tasas de errores de herramientas offline para los puntos de control de GLM-5.2 de serie, RFT exclusivo y RFT más OPSD. Los datos de entrenamiento difieren entre los puntos de control; esto no es una ablación controlada.

Evaluación en línea: GLM-5.2

Para GLM-5.2, realizamos dos pruebas A/B independientes con unos cien mil usuarios en cada condición. En la primera, un punto de control inicial de RFT con OPSD (RFT-plus-OPSD) obtuvo una tasa de fallos de herramientas ligeramente inferior a la del GLM 5.2 de serie (2,82 % frente a 2,94 %), pero la diferencia no fue estadísticamente significativa.

En la prueba posterior, comparamos dos puntos de control de RFT más OPSD: uno anterior (punto de control uno) y uno posterior (punto de control dos). Los fallos de llamadas a herramientas cayeron del 2,24% al 1,77% de las llamadas con un estado registrado. Esto supuso una reducción relativa estadísticamente significativa del 21,2%. No comparamos directamente el punto de control dos con el GLM 5.2 de serie en línea.

Los resultados de los comentarios de los usuarios fueron menos concluyentes. En el segundo experimento con GLM-5.2, la probabilidad promedio de insatisfacción fuerte (media o alta) fue del 2,58 % para el primer punto de control y del 2,54 % para el segundo, sin diferencias estadísticamente significativas.

Dos pruebas A/B en vivo independientes con GLM-5.2. El punto de control 1 se compara con el GLM-5.2 de serie; el punto de control 2 se compara con el punto de control 1. Dentro de estas dos pruebas, solo la reducción posterior de fallos de herramientas es estadísticamente significativa. Las tasas de MID+ promedian probabilidades estimadas de insatisfacción media o alta, no recuentos de quejas.

Evaluación en línea: GLM-5.3

Para GLM-5.3, comparamos un punto de control con entrenamiento posterior directamente con el GLM-5.3 base. Los fallos de llamadas a herramientas cayeron del 3,56% al 2,38% de las llamadas con un estado registrado, lo que representa una reducción relativa del 33,04%. La tasa MID+, la probabilidad estimada promedio de insatisfacción media o alta, cayó del 4,12% al 3,41%, lo que representa una reducción relativa del 17,2%. Ambas reducciones fueron estadísticamente significativas.

GLM-5.3 con entrenamiento posterior frente a GLM-5.3 base en una prueba A/B en línea separada. Las tasas de fallos de herramientas y MID+, los cambios relativos y los intervalos de confianza secuenciales del 95% utilizan el ajuste CUPED. Ambas reducciones son estadísticamente significativas. Las tasas MID+ son probabilidades estimadas promedio de insatisfacción media o alta en los hilos de seguimiento elegibles puntuados, no recuentos de quejas. Las tasas de fallos de herramientas excluyen las llamadas sin un estado de éxito o fallo registrado.

Conclusión

La idea central es aprender al nivel de la decisión, no solo de la sesión.

Un resultado exitoso puede ocultar errores, y una sesión sin éxito aun así puede revelar cómo mejorar. Conservamos el comportamiento útil de las sesiones exitosas como ancla, utilizamos las quejas y los errores de herramientas para identificar fallos evitables, y entrenamos al modelo hacia las predicciones que realiza cuando esos errores y correcciones se hacen explícitos. El éxito proporciona un comportamiento que preservar; el fallo proporciona una dirección para la mejora.

El uso en el mundo real hace que este enfoque sea especialmente útil. Los usuarios reales aportan objetivos, restricciones y flujos de trabajo que son difíciles de anticipar en un entorno sintético. Sus correcciones revelan requisitos que el modelo pasó por alto, mientras que los errores de herramientas exponen las brechas entre lo que el modelo intentó y lo que permite el entorno. Estas señales complementan el entrenamiento basado en resultados: en lugar de preguntar únicamente si una tarea tuvo éxito, podemos preguntar dónde se equivocó el modelo y qué información podría haberlo ayudado a tomar una mejor decisión.

Los límites son igualmente importantes. Los jueces pueden equivocarse y corregir un turno no garantiza que la tarea completa tenga éxito. El objetivo no es meramente un agente que se recupera tras una corrección, sino un agente que necesita correcciones con menos frecuencia.

Citación

BibTeX
@online{perplexity2026LearningFromRealWorldExperience,
  author = {{Perplexity} and Senzeyu Zhang and Chuan Wang and Hang Wu and Hao Zhang and Yuan Liang and Yunfan Zhong and Phi Hoang and Claire Beamer and Jeremy Yang and Andrew Wilson and Denis Yarats},
  title = {{Learning from real-world experience}},
  date = {2026-09-21},
  url = {https://www.perplexity.ai/hub/blog/learning-from-real-world-experience}
}