- Las pruebas de Ox Alpha deben medir la programación, el razonamiento, el trabajo agéntico y el rendimiento con contexto visual.
- El estado de vista previa pública significa que la identidad del proveedor y las reglas de prueba pueden seguir siendo limitadas.
- Los prompts repetibles hacen que las comparaciones sean más útiles que las respuestas aisladas e impresionantes.
- Las métricas principales incluyen precisión, errores de llamadas a herramientas, latencia, rendimiento y tiempo de actividad.
- La evaluación segura evita los datos confidenciales y verifica cada resultado crítico para producción.
Qué deberían medir las pruebas de Ox Alpha
Las pruebas de Ox Alpha se abordan mejor como una evaluación estructurada de un modelo de razonamiento, en lugar de como una única puntuación de referencia. La información pública del modelo describe Ox Alpha como un sistema diseñado para la programación, el trabajo agéntico prolongado, las cargas de trabajo de producción, el razonamiento complejo y los flujos de trabajo que combinan texto con contexto visual. Este perfil requiere varias categorías de pruebas en lugar de un único prompt general.
El modelo aparece listado como una vista previa sigilosa operada por un proveedor externo anónimo a través de OpenRouter. Esta distinción es importante: OpenRouter enruta las solicitudes, pero no se identifica como desarrollador, propietario o proveedor. Por lo tanto, un informe de pruebas debe separar el comportamiento observado de las afirmaciones confirmadas sobre el producto.
| Área de prueba | Qué evaluar | Evidencia útil |
|---|---|---|
| Programación | Corrección, mantenibilidad, depuración y cobertura de pruebas | Cambios en el repositorio, pruebas superadas, notas de revisión |
| Razonamiento | Precisión y coherencia en varios pasos | Respuestas finales, resultados intermedios de las tareas, cantidad de errores |
| Trabajo agéntico | Planificación, ejecución, iteración y recuperación | Registros de herramientas, finalización de tareas, acciones fallidas |
| Contexto visual | Comprensión de imágenes o vídeos proporcionados junto con texto | Descripciones, detalles extraídos, respuestas fundamentadas |
| Comportamiento en producción | Latencia, rendimiento, disponibilidad y fiabilidad de las llamadas a herramientas | Mediciones de la API recopiladas mediante solicitudes repetidas |
Una evaluación sólida también define el éxito antes de realizar la primera solicitud. Por ejemplo, una tarea de programación puede requerir que todas las pruebas pasen, que no se modifiquen archivos no relacionados y que se incluya una breve explicación de la implementación. Una tarea visual puede requerir que el modelo identifique únicamente los detalles visibles en el contenido proporcionado y marque claramente cualquier incertidumbre.
Pruebas de capacidades
- Programación y depuración
- Planificación a largo plazo
- Contexto textual y visual
Pruebas de fiabilidad
- Coherencia entre prompts repetidos
- Recuperación ante fallos de llamadas a herramientas
- Cumplimiento del formato de salida estructurada
Pruebas operativas
- Latencia de respuesta
- Rendimiento en tokens
- Disponibilidad y tasas de error
Utiliza la misma tarea, prompt, herramientas y criterios de éxito en cada prueba. La coherencia hace que los resultados sean más significativos que una demostración aislada.
Guía de configuración para las pruebas de Ox Alpha
Antes de realizar las pruebas, crea un entorno controlado que registre el identificador del modelo, la configuración de la solicitud, la marca de tiempo, la versión del prompt y el resultado. La ficha pública identifica el modelo como stealth/ox-alpha, proporciona una ruta de API compatible con OpenAI y muestra una ventana de contexto de 1M. La ficha también indica entradas de texto, imagen y vídeo con salida de texto, por lo que los casos de prueba multimodales son apropiados cuando tu cliente los admite.
Comienza con una clave de API independiente para la evaluación. Evita colocar credenciales en el control de código fuente, capturas de pantalla, gestores de incidencias o cuadernos compartidos. Utiliza variables de entorno y mantén los datos de prueba libres de secretos, registros de clientes, repositorios privados o información regulada.
| Elemento de configuración | Práctica recomendada | Por qué es importante |
|---|---|---|
| Identificador del modelo | Usa exactamente stealth/ox-alpha | Evita probar accidentalmente otro modelo |
| Clave de API | Guárdala en una variable de entorno | Reduce la exposición de credenciales |
| Versión del prompt | Asígnale un nombre como coding-v1 | Facilita las comparaciones reproducibles |
| Configuración de la solicitud | Registra temperature, top-p, max tokens y herramientas | La configuración puede cambiar el comportamiento |
| Captura de salida | Guarda la respuesta, los errores y los datos de uso | Permite revisiones posteriores |
| Datos de prueba | Usa datos sintéticos o públicos aprobados | Protege la información confidencial |
Los parámetros disponibles incluyen max_tokens, temperature, top_p, tools, tool_choice, top_k y response_format. No cambies varias variables a la vez al investigar un resultado. Si modificas simultáneamente la temperatura y el texto del prompt, es posible que no sepas cuál de los cambios afectó a la salida.
Prepara un espacio de trabajo de pruebas seguro
Crea un proyecto o cuaderno dedicado, configura OPENROUTER_API_KEY como variable de entorno y elimina los datos confidenciales de cada prompt y archivo adjunto.
Crea un conjunto de prompts
Escribe prompts independientes para programación, razonamiento, planificación agéntica, interpretación visual y salida estructurada. Asigna a cada prompt un identificador estable y criterios de éxito explícitos.
Ejecuta pruebas repetidas
Ejecuta cada tarea varias veces con la misma configuración. Registra las finalizaciones exitosas, los resultados parciales, las negativas, los fallos de llamadas a herramientas y las salidas con formato incorrecto.
Revisa la evidencia
Inspecciona las salidas manualmente y mediante comprobaciones automatizadas. Para el código, ejecuta las pruebas; para los datos estructurados, valida el esquema; para las tareas visuales, compara las afirmaciones con el contenido proporcionado.
Informa de los límites y resultados
Resume los puntos fuertes, los patrones de fallo, la latencia y las observaciones operativas. Marca como desconocidos los detalles no confirmados del proveedor en lugar de presentar suposiciones como hechos.
Para consultar la referencia de la API y la configuración actual del modelo, visita la ficha de Ox Alpha en OpenRouter. Trata las cifras operativas mostradas como mediciones sujetas al momento, no como garantías permanentes.
Ox Alpha se presenta como una vista previa sigilosa de un proveedor externo. No asumas que el comportamiento, la disponibilidad, el precio o la identidad del proveedor se mantendrán sin cambios.
Categorías de referencia y diseño de prompts
Un conjunto útil de pruebas para Ox Alpha equilibra el trabajo realista con tareas de diagnóstico específicas. Las tareas realistas muestran si el modelo puede completar un resultado, mientras que las tareas de diagnóstico ayudan a explicar por qué tuvo éxito o falló.
Para programación, utiliza repositorios pequeños con defectos conocidos, comandos de prueba claros y una lista fija de criterios de aceptación. Incluye tareas de implementación y depuración. Un modelo puede producir código convincente que falle en casos límite, cambie comportamientos no relacionados u omita pruebas, por lo que la corrección debe juzgarse por la ejecución y no solo por la calidad de la explicación.
Para razonamiento, evita prompts que solo premien los datos memorizados. Utiliza preguntas basadas en restricciones, problemas de planificación, clasificaciones con ejemplos ambiguos y tareas que requieran que el modelo identifique información faltante. Registra si la respuesta alcanza la conclusión correcta y si aparecen suposiciones no fundamentadas durante el proceso.
| Referencia | Tarea de ejemplo | Condición de aprobación | Fallo habitual |
|---|---|---|---|
| Reparación de código | Corrige una función defectuosa en un repositorio pequeño | Las pruebas pasan sin cambios no relacionados | El parche parece plausible, pero no contempla casos límite |
| Revisión de código | Identifica defectos de seguridad y lógica | Los hallazgos son precisos y aplicables | Falsos positivos o defectos omitidos |
| Planificación | Divide un proyecto de varias etapas en tareas ejecutables | Las dependencias y los riesgos están claramente ordenados | Plan genérico sin un ciclo de verificación |
| Pregunta visual | Responde preguntas sobre una imagen o vídeo aprobado | Las afirmaciones se basan en detalles visibles | Detalles inventados o contexto ignorado |
| Respuesta estructurada | Devuelve JSON que coincida con un esquema proporcionado | La salida se analiza correctamente y contiene los campos requeridos | Texto adicional o sintaxis no válida |
El diseño de prompts debe hacer explícitos los límites de la evaluación. Indica al modelo qué herramientas están disponibles, qué archivos puede modificar, qué formato de salida se requiere y cómo debe expresar la incertidumbre. Si la tarea incluye una imagen o un vídeo, especifica si el modelo debe describir, comparar, contar o extraer información.
Precisión
¿La respuesta o implementación cumplió la tarea?
Fundamentación
¿Las afirmaciones están respaldadas por el prompt, los archivos o el contenido multimedia?
Coherencia
¿Las pruebas repetidas producen resultados comparables?
Eficiencia
¿Cuánto tiempo, salida y actividad de herramientas requirió la finalización?
Un buen prompt de prueba indica el objetivo, el contexto disponible, las acciones permitidas, el formato de salida y los criterios de aprobación. La ambigüedad debe ser intencional y estar documentada, no ser accidental.
Métricas de rendimiento que debes registrar
Las puntuaciones de capacidad por sí solas no describen cómo se comporta un modelo en una aplicación. La página pública de OpenRouter informa de mediciones operativas como rendimiento, latencia, latencia de extremo a extremo, tasa de errores de llamadas a herramientas, tasa de aciertos de caché, tiempo de actividad y disponibilidad. Estas categorías proporcionan un marco práctico para tu propio registro de pruebas.
La latencia es el tiempo necesario para obtener una respuesta, mientras que el tiempo hasta el primer token indica con qué rapidez comienza la salida. El rendimiento mide los tokens generados por segundo. Para un agente interactivo, el retraso hasta el primer token puede importar más que el tiempo total de finalización. Para trabajos de programación por lotes, pueden ser más importantes el tiempo total de finalización y la tasa de tareas completadas correctamente.
| Métrica | Definición | Cómo utilizarla |
|---|---|---|
| Precisión | Porcentaje de pruebas que cumplen los criterios de aprobación | Compara la calidad de las tareas entre versiones de prompts |
| Latencia | Tiempo de respuesta de ida y vuelta | Evalúa la capacidad de respuesta interactiva |
| TTFT | Tiempo hasta que aparece el primer token | Mide la capacidad de respuesta percibida |
| Rendimiento | Tokens generados por segundo | Estima la velocidad de finalización |
| Tasa de errores de llamadas a herramientas | Porcentaje de acciones de herramientas que fallan | Evalúa la fiabilidad del agente |
| Disponibilidad | Solicitudes atendidas correctamente | Comprueba si el servicio satisface las necesidades operativas |
| Coherencia | Similitud de los resultados entre repeticiones | Identifica comportamientos inestables en las tareas |
La página de origen muestra una cifra de rendimiento a nivel de proveedor de 23 tokens por segundo y una latencia P50 de 5,30 segundos en el momento de la captura, el 22 de agosto de 2026. También muestra cifras recientes de tiempo de actividad y disponibilidad. Estos valores son referencias útiles, pero tu región, el tamaño del prompt, el estado de la caché, el uso de herramientas y el periodo de prueba pueden producir resultados diferentes.
No informes de un único promedio sin datos de distribución. Una mediana puede ocultar valores atípicos lentos, mientras que un percentil alto puede revelar los retrasos que experimentan los usuarios durante solicitudes difíciles. Siempre que sea posible, registra la latencia P50, P90 y P95, junto con las solicitudes fallidas y los reintentos.
| Vista del informe | Datos mínimos que se deben incluir | Interpretación |
|---|---|---|
| Calidad | Tasa de aprobación, tasa de resultados parciales y tasa de fallos | Muestra si el modelo completa el trabajo previsto |
| Velocidad | Latencia P50 y P95, TTFT y rendimiento | Muestra la capacidad de respuesta habitual y en el peor caso |
| Comportamiento del agente | Éxito de las herramientas, reintentos y tasa de recuperación | Muestra si los flujos de trabajo pueden continuar después de los errores |
| Multimodalidad | Respuestas fundamentadas, omisiones y detalles alucinados | Muestra qué tan bien se utiliza el contexto visual |
| Seguridad | Gestión de datos sensibles, calidad de las negativas y necesidad de escalamiento | Muestra si los controles de implementación son adecuados |
Mantén la calidad y la velocidad como puntuaciones independientes. Una respuesta rápida que falla la tarea no debe superar a una respuesta más lenta que cumple los criterios de aceptación.
Lista de evaluación y plantilla de informe
Utiliza una lista de comprobación antes de publicar resultados o pasar de la experimentación hacia la producción. El objetivo no es declarar un ganador universal, sino identificar qué cargas de trabajo se ajustan al comportamiento observado del modelo.
Lista de evaluación de Ox Alpha:
- Registra el identificador del modelo, la fecha, la versión del prompt, los parámetros y la configuración de herramientas
- Ejecuta tareas de programación, razonamiento, trabajo agéntico y multimodales con criterios de aprobación explícitos
- Repite las tareas importantes e informa de la coherencia en lugar de basarte en una única salida
- Mide la latencia, el rendimiento, los errores de llamadas a herramientas, la disponibilidad y las solicitudes fallidas
- Elimina los datos confidenciales y verifica manualmente los resultados críticos para producción
Un informe conciso debe incluir el objetivo de la prueba, el entorno, las categorías de tareas, el tamaño de la muestra, el método de puntuación y las limitaciones. Explica si los resultados proceden de una inspección directa, pruebas automatizadas, validación del esquema o una combinación de métodos. Incluye fallos representativos, no solo ejemplos exitosos.
| Sección del informe | Preguntas que se deben responder |
|---|---|
| Alcance | ¿Qué capacidad o flujo de trabajo se probó? |
| Entorno | ¿Qué ruta de API, configuración, herramientas y datos se utilizaron? |
| Método | ¿Cuántas pruebas se realizaron y cómo se puntuaron? |
| Resultados | ¿Cuáles fueron las mediciones de calidad, velocidad y fiabilidad? |
| Limitaciones | ¿Qué no se probó o qué pudo afectar al resultado? |
| Recomendación | ¿Qué cargas de trabajo parecen adecuadas para la siguiente etapa de evaluación? |
Para las pruebas orientadas a producción, añade un punto de revisión humana. Los cambios de código deben ejecutar pruebas automatizadas y recibir una revisión. El análisis visual debe comprobarse con el contenido multimedia original. Las acciones agénticas deben utilizar herramientas con privilegios mínimos, confirmación explícita para operaciones irreversibles y registros que puedan auditarse.
Un resultado sólido en una tarea de programación no demuestra una fiabilidad amplia en razonamiento o multimodalidad. Publica conclusiones únicamente sobre las cargas de trabajo que tu prueba haya cubierto.
Preguntas frecuentes sobre las pruebas de Ox Alpha
Q: ¿Qué significa probar Ox Alpha?
Significa evaluar el modelo de razonamiento Ox Alpha con tareas y métricas definidas. Una cobertura útil incluye programación, trabajo agéntico prolongado, razonamiento complejo, comprensión del contexto visual, coherencia de las respuestas, latencia, rendimiento y fiabilidad de las llamadas a herramientas.
Q: ¿Existe un programa oficial de pruebas de Ox Alpha?
La ficha pública disponible describe Ox Alpha como una vista previa sigilosa operada por un proveedor externo anónimo a través de OpenRouter. No proporciona información suficiente para confirmar un programa público independiente para evaluadores, un proceso de invitación o un calendario formal de pruebas.
Q: ¿Qué métricas debería registrar primero?
Comienza con la tasa de aprobación de las tareas, las categorías de fallos, la coherencia entre pruebas repetidas, la latencia, el rendimiento y los errores de llamadas a herramientas. Añade la disponibilidad, el tiempo hasta el primer token y la latencia de extremo a extremo al evaluar una aplicación o un flujo de trabajo agéntico.
Q: ¿Puedo utilizar imágenes y vídeos en una evaluación?
La información pública del modelo describe Ox Alpha como compatible con entradas de texto, imágenes y vídeos, y con salida de texto. Utiliza contenido multimedia de prueba aprobado, define qué detalles deben identificarse y verifica cada afirmación con la imagen o el vídeo proporcionado.
Construye primero un pequeño conjunto de pruebas repetible y amplíalo con trazas de flujos de trabajo reales solo después de que las mediciones básicas sean estables.