Pensaron que llegaría la "fresa", pero llegó la "col rizada"
Aunque todo el mundo estaba pendiente del "Plan Fresa", parece que el rebelde OpenAI nunca cumple las expectativas. Quieres "fresas", pero ellos te dan "col rizada".
A las 2 de la madrugada del día 14, hora de Pekín, OpenAI publicó en su sitio web oficial que está lanzando un subconjunto verificado manualmente de SWE-bench, que puede evaluar de manera más confiable la capacidad de los modelos de IA para resolver problemas de software del mundo real.
Dirección de SWE-bench en Hugging Face:
https://huggingface.co/datasets/princeton-nlp/SWE-bench_Verified
Como parte del marco de preparación (un conjunto de métodos establecidos por OpenAI para desarrollar y desplegar de manera segura sus modelos de vanguardia), OpenAI ha desarrollado una serie de métricas para rastrear, evaluar y predecir la capacidad de acción autónoma de los modelos.
La capacidad de completar tareas de ingeniería de software de forma autónoma ha sido durante mucho tiempo un componente clave del nivel de riesgo medio en la categoría de riesgos autónomos de los modelos de vanguardia. Evaluar estas capacidades es un desafío debido a la complejidad de las tareas de ingeniería de software, la dificultad de evaluar con precisión el código generado y los desafíos de simular escenarios de desarrollo del mundo real. Por lo tanto, el enfoque de preparación de OpenAI también debe examinar cuidadosamente la evaluación en sí misma, minimizando la posibilidad de sobrestimar o subestimar los factores de riesgo.
Uno de los conjuntos de evaluación de ingeniería de software más populares en este método es SWE-bench. Se puede utilizar para evaluar si los grandes modelos de lenguaje realmente pueden resolver problemas de software reales de GitHub y hasta qué punto pueden resolverlos. La prueba de referencia incluye proporcionar a los agentes un repositorio de código y una descripción del problema, y pedirles que generen un parche para resolver el problema descrito.
Según la clasificación de SWE-bench, hasta el 5 de agosto de 2024, los agentes de codificación han logrado un progreso notable en SWE-bench, con el agente de mayor puntuación obteniendo un 20% en SWE-bench y un 43% en SWE-bench Lite.
Después de las pruebas, se descubrió que algunas tareas en SWE-bench pueden ser difíciles o imposibles de resolver, lo que lleva a que SWE-bench subestime sistemáticamente las capacidades de ingeniería de software autónomas de los modelos. Por lo tanto, OpenAI colaboró con los autores de SWE-bench para abordar estos problemas en una nueva versión de la prueba de referencia, que debería proporcionar una evaluación más precisa.
Entonces, ¿cuál es el trasfondo de SWE-bench?
Cada ejemplo en el conjunto de pruebas SWE-bench se crea a partir de un problema de GitHub resuelto en uno de los 12 repositorios Python de código abierto en GitHub. Cada ejemplo tiene una solicitud de extracción (PR) asociada que incluye el código de la solución y pruebas unitarias para verificar la corrección del código. Estas pruebas unitarias fallan antes de agregar el código de la solución en el PR, pero pasan después, por lo que se denominan pruebas FAIL_TO_PASS. Cada ejemplo también tiene pruebas PASS_TO_PASS asociadas, que pasan tanto antes como después de la fusión del PR, utilizadas para verificar que la funcionalidad existente no relacionada en la base de código no se haya roto por el PR.
Para cada muestra en SWE-bench, el agente recibe el texto original del problema de GitHub (llamado declaración del problema) y se le otorga acceso al repositorio de código. Con esto, el agente debe editar los archivos en el repositorio de código para resolver el problema. Las pruebas no se muestran al agente.
FAIL_TO_PASS evalúa las ediciones propuestas ejecutando y probando PASS_TO_PASS. Si las pruebas pasan, significa que se ha resuelto el problema. Si las pruebas pasan, las ediciones no han roto accidentalmente partes no relacionadas de la base de código. Las ediciones deben pasar ambos conjuntos de pruebas para resolver completamente el problema original de GitHub. FAIL_TO_PASS PASS_TO_PASS
Adopción de SWE-bench como evaluación de preparación
Dada la relevancia potencial de SWE-bench para el marco de preparación, los investigadores buscaron formas de mejorar la robustez y confiabilidad del punto de referencia. Por lo tanto, se identificaron tres áreas principales de mejora:
Las pruebas unitarias utilizadas para evaluar la corrección de las soluciones suelen ser demasiado específicas y, en algunos casos, incluso irrelevantes para el problema. Esto puede llevar al rechazo de soluciones correctas.
Las descripciones de problemas de muchos ejemplos son ambiguas, lo que dificulta identificar claramente cuál es el problema y cómo resolverlo.
A veces es difícil configurar de manera confiable el entorno de desarrollo SWE-bench para los agentes, lo que puede llevar inadvertidamente a que las pruebas unitarias fallen, independientemente de la solución adoptada. En estos casos, soluciones completamente válidas pueden ser calificadas como incorrectas.
A continuación se muestra un ejemplo que ilustra el primer problema.
La tarea del ejemplo scikit-learn__scikit-learn-14520 de SWE-bench es que el agente resuelva un problema en el repositorio de scikit-learn. Esta declaración del problema informa que el parámetro copy de la función puede ser especificado por el usuario, pero es ignorado por la biblioteca (el comportamiento está codificado dentro de la función):
Para resolver el problema anterior, el agente primero debe abordar si el comportamiento de la función es intencional o un error, y luego realizar cambios en la base de código para resolver el problema. Según la configuración de SWE-bench, cualquier solución propuesta por el agente debe pasar la siguiente prueba, extraída del PR que originalmente resolvió el problema:
Esta prueba verifica específicamente si la solución debe generar una DeprecationWarning cuando se usa el parámetro copy, aunque este requisito no se transmite en la declaración del problema original en el texto del problema anterior. Además, incluso si el agente es consciente de que debe generar una DeprecationWarning, la prueba requiere que el agente coincida exactamente con el mensaje de obsolescencia, que se determinó después de algunas discusiones en el PR al que el agente no tiene acceso.
Tenga en cuenta que el agente solo obtiene la descripción del problema del texto del problema principal y no puede ver las pruebas que necesita pasar. En esta configuración, es casi imposible que el agente resuelva este ejemplo en SWE-bench.
Verificado a través de SWE-bench
Para abordar estos problemas, OpenAI inició una campaña de anotación manual con desarrolladores de software profesionales para examinar cada muestra del conjunto de pruebas SWE-bench para obtener pruebas unitarias de alcance apropiado y descripciones de problemas claramente especificadas.
OpenAI, junto con los autores de SWE-bench, lanzó SWE-bench Verified: un subconjunto del conjunto de pruebas original de SWE-bench que contiene 500 muestras verificadas manualmente por anotadores sin problemas. Esta versión reemplaza los conjuntos de pruebas originales de SWE-bench y SWE-bench Lite. Además, OpenAI también publicó anotaciones manuales para todas las muestras de prueba de SWE-bench.
Al mismo tiempo, OpenAI colaboró con los autores de SWE-bench para desarrollar nuevas herramientas de evaluación para SWE-bench. Utiliza un entorno Docker containerizado para facilitar y hacer más confiable la evaluación en SWE-bench.
En SWE-bench Verified, GPT-4o resolvió el 33.2% de las muestras, donde el mejor andamio de código abierto, Agentless, obtuvo una puntuación en SWE-bench que es el doble del 16% anterior.
No llegó el anuncio oficial del "Plan Fresa", este conjunto de pruebas como máximo puede considerarse un aperitivo. Entonces, ¿vale la pena que OpenAI cree expectativas por este conjunto de pruebas?
Hace una semana, el CEO de OpenAI, Sam Altman, publicó un tweet con una imagen de fresas y el texto "Me encanta el verano en el jardín". Las cuatro fresas en la imagen quizás insinuaban que una nueva versión de GPT-4 podría estar diseñada específicamente para el razonamiento, para funcionar junto con GPT-4o, que está diseñado para la creación e interacción. Esto generó varias conjeturas sobre el lanzamiento de un nuevo modelo Strawberry por parte de OpenAI.
En los últimos dos días, el informante @iruletheworldmo en X ha estado publicando frecuentemente mensajes relacionados con el lanzamiento de Strawberry, indicando que OpenAI lanzará su nuevo modelo, un proyecto de IA centrado en el razonamiento llamado "Plan Fresa" (Strawberry), a las 10 a.m. hora del Pacífico del 13 de agosto. Toda la comunidad estaba llena de expectativas.
¿Qué es el misterioso "Plan Fresa"?
El nuevo "Plan Fresa" de OpenAI permitiría a ChatGPT buscar más libremente en la web y resolver problemas complejos.
El "Plan Fresa" se reveló por primera vez en los medios extranjeros el 12 de julio. Según fuentes conocedoras y documentos internos revisados por Reuters, el fabricante de ChatGPT, OpenAI, estaba investigando nuevos enfoques para sus modelos de IA en un proyecto con nombre en clave "Strawberry".
Sin embargo, los detalles del proyecto no se habían informado previamente, mientras que la startup respaldada por Microsoft competía por demostrar que los tipos de modelos que ofrece pueden proporcionar capacidades de razonamiento avanzadas.
Según una copia de un documento interno de OpenAI que Reuters vio en mayo, un equipo interno de OpenAI estaba desarrollando Strawberry. Reuters no pudo determinar la fecha exacta de publicación del documento, que detallaba los planes de OpenAI para usar Strawberry en la investigación. Las fuentes describieron el plan a Reuters como un trabajo en progreso. La agencia de noticias no pudo determinar cuánto faltaba para que Strawberry se lanzara públicamente.
La fuente dijo que incluso dentro de OpenAI, el funcionamiento de Strawberry era un secreto estrictamente guardado.
El documento describía un proyecto que utilizaba el modelo Strawberry con el objetivo de hacer que la IA de la empresa no solo pudiera generar respuestas a consultas, sino también planificar con anticipación y navegar de manera autónoma y confiable por Internet para realizar lo que OpenAI llamaba "investigación profunda", dijeron las fuentes.
Según entrevistas con más de una docena de investigadores de IA, este es un problema que los modelos de IA aún no han resuelto hasta ahora.
En ese momento, cuando se le preguntó sobre Strawberry y los detalles reportados en este artículo, un portavoz de OpenAI dijo en un comunicado: "Esperamos que nuestros modelos de IA puedan ver y entender el mundo como nosotros. La investigación continua de nuevas capacidades de IA es una práctica común en la industria, y todos compartimos la creencia de que las capacidades de razonamiento de estos sistemas mejorarán con el tiempo".
El portavoz no respondió directamente a las preguntas sobre Strawberry.
Google lanza un desafío
Strawberry ha estado "ocultando la mitad de su rostro detrás de un laúd pipa" durante mucho tiempo, y esta vez OpenAI anunció repentinamente la promoción, es difícil decir que no es para perseguir el evento de hardware "Made by Google 2024" de Google que se llevó a cabo casi al mismo tiempo.
En este evento, Google presentó sus propios productos de hardware más recientes, incluidos los teléfonos Pixel de próxima generación tan esperados: Pixel 9, Pixel 9 Pro y el nuevo Pixel 9 Fold, además de nuevos productos de hardware como el Pixel Watch y los Pixel Buds. Aunque fue un lanzamiento de hardware, el tema de la IA llenó todo el evento. Entre ellos, el chatbot de IA de Google, Gemini, es el asistente predeterminado del teléfono Pixel 9.