Perplejidad entrena a su agente informático sobre errores reales con autodestilación guiada por sugerencias

Perplexity Research publicó un nuevo estudio post-entrenamiento. Entrena un modelo dentro de Perplexity Computer en sesiones de usuarios reales, incluidas las fallidas. El método combina el ajuste del muestreo de rechazo con la autodestilación guiada por sugerencias. En una prueba A/B en vivo, las fallas en las llamadas a herramientas cayeron del 2,24 % al 1,77 % entre 2 puntos de control capacitados. El equipo de Perplexity informa que esto es una reducción relativa estadísticamente significativa del 21,2 %.

¿Es desplegable? No directamente. Perplexity no ha publicado los pesos posteriores al entrenamiento ni el código de entrenamiento. El modelo se ejecuta sólo como una opción de modelo dentro de Perplexity Computer. El modelo base, GLM 5.2, está disponible abiertamente en Hugging Face.

Por qué el filtrado de sólo resultados se queda corto

El ajuste fino de muestreo de rechazo estándar (RFT) juzga cada sesión e imita solo las exitosas. Un resultado exitoso no significa que cada paso fue correcto. Un agente puede recuperarse de una llamada de herramienta incorrecta y aun así brindar la respuesta correcta. Imitar esa trayectoria completa puede reforzar el error. Descartar sesiones fallidas también descarta evidencia clara de errores evitables.

Imitar, corregir o mantener como contexto

El equipo de Perplejidad separa dos decisiones: qué sesiones contienen comportamientos que vale la pena imitar y en qué turnos hay errores que vale la pena corregir.

Cada turno de asistente recibe 1 de 3 tratamientos:

Imita: los turnos sin errores en sesiones exitosas reciben una pérdida de entropía cruzada (CE). Correcto: los giros de error con una sugerencia validada reciben la pérdida de divergencia de Kullback-Leibler (KL), en cualquier sesión. Mantener como contexto: los turnos restantes permanecen en la entrada pero no reciben pérdida.

Las sesiones exitosas pueden proporcionar objetivos tanto de imitación como de corrección. Las sesiones fallidas sólo proporcionan objetivos de corrección.

Cómo una pista se convierte en una señal de entrenamiento

Una pista es una breve instrucción correctiva basada en información que el modelo ya tenía. En un ejemplo, una llamada de búsqueda estableció recency_filter en ‘año’. El esquema sólo permitía “día”, “semana” o “mes”. La sugerencia nombra la llamada fallida, incluye el error de validación y sugiere un valor permitido u omite el campo opcional.

La parte correctiva utiliza la autodestilación basada en políticas (OPSD). El entrenador recorre el mismo punto de control GLM 5.2 dos veces en el turno registrado. El maestro pasa ve la indirecta; el pase de estudiante no. Ambos utilizan el método forzado por el profesor, por lo que no se genera ninguna respuesta de reemplazo. Las probabilidades del siguiente token del maestro están separadas y actúan como un objetivo fácil a través de KL adelantado.

La pérdida combinada es (CE + λ × KL), dividida por el número de tokens imitados. Al establecer λ en 0 se recupera la SFT estándar. El término CE importa. La capacitación basada únicamente en corrección puede permitir que el maestro y el estudiante lleguen a un acuerdo ignorando el contexto.

Rastreando las quejas hasta el verdadero error

El proceso se basa en sesiones informáticas elegibles para capacitación atendidas por GLM 5.2. Se excluyen las sesiones con información de identificación personal y los usuarios que optaron por no participar. Un juez de LLM mantiene las tareas con una calificación de 4 o 5 en una escala de dificultad de 5 puntos. Dos jueces de LLM deben aprobar la entrega final para que una sesión se considere exitosa.

Para recibir comentarios de los usuarios, tres jueces de LLM localizan el turno responsable y al menos 2 deben estar de acuerdo. Esto es importante porque el último turno del asistente antes de una queja es la causa raíz sólo en la mitad de las veces. Cada pista también se compara con la información disponible antes del error. Esa verificación reduce el sesgo retrospectivo.

Un ejemplo: un usuario solicitó su ‘w3’ en Paychex. El modelo asumió un error tipográfico W-2 y buscó el formulario incorrecto. La pista apunta a esa interpretación anterior, no solo a la respuesta final.

Explicador interactivo