Análisis en profundidad · Unos 6 min de lectura
La guía de Perplexity exige trazas y jueces calibrados para interpretar la evaluación de agentes
La guía oficial de seis pasos conecta fallos reales, datos fijos y evaluadores contrastados con expertos: una respuesta acertada no demuestra fiabilidad.
- Publicado aquí
- Fecha de la fuente
- Fuente revisada
La guía de Perplexity del 22 de octubre explica cómo organizar evaluaciones de agentes. No anuncia un modelo ni un resultado nuevo de referencia. Su ejemplo de compras muestra por qué una puntuación exige conocer las acciones, la repetibilidad y la calidad del juez.
Escucha las noticias
Escucha este artículo o continúa con las noticias.
Preparando la lectura…
Voz del dispositivo
El navegador o dispositivo procesa la voz. AISubHub no envía el texto a una API de audio. Las voces y la reproducción con pantalla bloqueada dependen del dispositivo.
Al continuar puede repetirse una frase breve.
Resumen
- Una respuesta plausible puede ocultar acciones no autorizadas o respuestas filtradas; importa tanto el resultado como el recorrido.
- Unas 100 trazas son una orientación para analizar errores, no un umbral obligatorio. pass@k significa al menos un éxito en un k declarado.
- Reevaluar la misma ejecución guardada separa la variación del juez; regresión, seguimiento y A/B cumplen funciones distintas.
¿Qué puede ocultar una respuesta correcta?
Un asistente de inventario puede recomendar una pieza aparentemente adecuada y saltarse una regla de aprobación. En el ejemplo industrial de Perplexity, la falta de una pieza autorizada o datos obsoletos del proveedor requieren una respuesta apropiada, no un sustituto injustificado. La guía propone definir tanto el trabajo satisfactorio como las formas inaceptables de completarlo. Los expertos del dominio deben comprobar que los criterios correspondan al trabajo real. La fluidez no acredita el respeto de los permisos.
Por eso se evalúan la información recuperada, las llamadas a herramientas y las decisiones intermedias. Éxito de tarea, corrección de acciones y calidad de respuesta son propiedades distintas; la fiabilidad incluye repeticiones y casos límite. Tiempo, tokens y llamadas influyen en el coste de completar bien una tarea. Nuestro análisis: la decisión de publicar necesita condiciones de aceptación para todo el flujo, no solo preferencia por una respuesta bien redactada.
¿Qué fallos deben convertirse en pruebas?
La guía parte de trazas reales con entradas, evidencias recuperadas, acciones y salidas. Un experto anota el primer error significativo de cada ejecución y agrupa observaciones similares en modos de fallo. Un LLM puede sugerir categorías; frecuencia y gravedad determinan prioridades. Los fallos importantes se guardan como casos con entrada, condiciones iniciales, resultado esperado y criterios de evaluación. Así se conserva el problema que debe repararse, en vez de sustituirlo por una tarea sintética conveniente.
Unas 100 trazas son una referencia práctica, no un requisito universal de muestra ni una garantía de confianza estadística. Puede detenerse antes al alcanzar saturación teórica: más trazas ya no revelan patrones nuevos relevantes. Antes del lanzamiento sirven ejemplos sintéticos, que deben enriquecerse con uso real cuando exista. Las pruebas estandarizadas pueden complementar las propias, pero los aprobados o fallos sorprendentes requieren investigar las tareas y sus respuestas esperadas.
¿Cómo afrontan dos versiones el mismo problema?
La ilustración separa una solicitud de mantenimiento de los datos fijos de inventario y piezas autorizadas. maintenance_request_01.json guarda la entrada y el resultado esperado; inventory_snapshot.json y approved_parts.json aportan los datos de comparación. run_evals.py ejecuta y comprueba el flujo; results conserva salidas, trazas y veredictos de aprobado o fallo. Es una estructura ilustrativa, no un sistema productivo ni un paquete que hayamos ejecutado. Nuestro análisis: si cambia el inventario, también cambia la tarea, no solo el agente.
Hay que guardar recuperaciones y acciones de herramientas, además del texto final. Entradas idénticas pueden producir resultados distintos; las repeticiones deben considerar riesgo, frecuencia y dificultad de reparación. pass@1 describe el éxito en un intento; pass@k, al menos un éxito en un número k de intentos especificado. Debe declararse k. Encontrar una respuesta correcta entre varias no garantiza acertar siempre ni demuestra que el agente sepa elegirla.
¿Quién debe juzgar cada requisito?
Para condiciones exactas, la guía favorece verificadores por código: pieza aprobada, campos válidos, argumentos correctos o estado final esperado de una base de datos. Proporcionan reglas claras, pero no resuelven de forma fiable todo juicio subjetivo. Preguntas contextuales, como si una explicación justifica rechazar un reemplazo, pueden evaluarse con un LLM y una rúbrica explícita. La rúbrica debe definir qué comportamiento es aceptable y qué evidencia sustenta el veredicto.
Los expertos siguen siendo necesarios en asuntos especializados o controvertidos. Una misma ejecución puede combinar distintos jueces; una plataforma no decide qué fallos importan al negocio. Nuestro análisis: separar permisos y calidad de explicación hace más interpretable una puntuación conjunta. Una valoración favorable de la prosa por un LLM no debe sustituir silenciosamente la comprobación exacta de la lista autorizada. La guía no aporta una mejora de precisión medida para esta división.
¿Cómo separar errores del agente y del juez?
La calibración de cinco pasos reúne entradas, salidas y trazas; obtiene juicios independientes del experto; ejecuta el juez LLM; compara decisiones; e investiga discrepancias para revisar la rúbrica antes de probar ejemplos nuevos. El juicio humano es la referencia del proceso, no una afirmación de infalibilidad. Calibrar significa evaluar al evaluador, no volver a ejecutar al agente que se está examinando.
Para medir consistencia del juez, se puntúan varias veces exactamente la misma ejecución guardada y los mismos archivos, sin repetir el agente. De otro modo se mezclan ambas variaciones. Una matriz de confusión permite estudiar errores detectados, errores omitidos y resultados aceptables marcados incorrectamente. La revisión humana también descubre fallos que los jueces actuales no reconocen. La guía enlaza ejemplos de problemas en benchmarks; no leímos independientemente esos estudios ni reprodujimos sus resultados.
¿Cuándo justifica una reparación publicar una versión?
Primero se reproduce el fallo con la entrada guardada, se modifica de forma específica el prompt, modelo o flujo y se confirma la reparación. Después se ejecuta el resto de la batería para detectar comportamientos antes correctos que se han roto. La base y la versión nueva deben usar los mismos casos y criterios. Las aserciones, los marcos de pruebas y CI/CD automatizan controles y umbrales, pero no demuestran que los criterios elegidos cubran los riesgos reales.
Tras desplegar, jueces calibrados pueden revisar muestras de trazas productivas, seguir categorías de fallo y complementarse con inspección humana de errores nuevos o solicitudes inusuales. A/B, cuando procede, añade resultados de negocio como resolución o satisfacción, sin sustituir la evaluación ni explicar todas las causas. Nuestro análisis: el ciclo útil conecta un fallo observado, una comprobación repetible y una decisión de regresión. La guía no acredita nuevas prestaciones ni fiabilidad medida independientemente.
Por qué importa
El enfoque permite conservar fallos, evidencias y jueces para comparar una reparación con el flujo completo y seguir aprendiendo del uso real.
Límites y disponibilidad
Es orientación metodológica de Perplexity con un ejemplo de compras. Revisamos el artículo completo y su diagrama, no estudios externos, un agente desplegado ni derechos de una cuenta; no medimos precisión, ahorro ni umbrales universales.
Fuentes y pruebas
Fecha de la fuente: · Fuente revisada:
Contenido editorial asistido por IA y contrastado con fuentes primarias. Las afirmaciones del proveedor se atribuyen; la inclusión no implica recomendación.