¡Los modelos grandes no pueden ser agricultores de código! El sorprendente descubrimiento de Princeton: GPT-4 tiene una tasa de éxito de 0 en la resolución de problemas de programación de GitHub
herramientas de codificación de IA como ChatGPT son amenazantes, ¡y Stack Overflow vuelve a despedirse! Sin embargo, Princeton y Chicago descubrieron que GPT-4 tenía una tasa de resolución del 0% para los problemas de GitHub del mundo real.
¡Stack Overflow, ya creado por ChatGPT!
Debido a que los programadores acudieron en masa a ChatGPT y Github Copilot, Stack Overflow tuvo que anunciar el despido de más de 100 empleados hoy, lo que representa casi 1/3 del número de empleados.
Entonces, ¿las herramientas de codificación de IA como ChatGPT realmente van a subvertir toda la industria?
Pero un estudio reciente realizado por Princeton y Chicago encontró que LLM no es tan fácil de hacer como un granjero de código.
Dirección del papel:
Frente a 2294 problemas reales de GitHub, la tasa de aprobación de GPT-4 resolviendo problemas aleatorios de GitHub resultó ser del 0%.
Incluso el mejor modelo, el Claude 2, solo resuelve el 1,96% de ellos.
¿Pueden los programadores perder su trabajo por culpa de ChatGPT? La respuesta es: absolutamente no en este momento.
Adaptarse o perecer
Como el sitio asistido por código favorito de todos los desarrolladores en el mundo, Stack Overflow ha tenido un buen desempeño antes, lo que desencadenó una ola de contrataciones el año pasado, duplicando la fuerza laboral de la compañía a 540.
Sin embargo, todo ha cambiado desde que OpenAI lanzó ChatGPT el pasado mes de noviembre.
La ayuda proporcionada por los chatbots de IA es más específica que la publicación del foro hace 5 años. Con LLM, los desarrolladores pueden corregir instantáneamente el código exacto, las sugerencias de optimización y una descripción de lo que está haciendo cada línea de código.
Si bien LLM no proporciona respuestas 100% confiables, la capacidad única de validar el código de inmediato simplemente probándolo en el entorno de desarrollo integrado IDE hace que escribir código sea un caso de uso ideal para ChatGPT.
Como resultado, el tráfico de Stack Overflow se ha reducido considerablemente, y las herramientas de programación de IA como ChatGPT y Github Copilot con tecnología GPT-4 se han convertido en nuevos lugares para los agricultores de código.
Hoy, el CEO Prashanth Chandrasekar anunció que Stack Overflow ha despedido a más de cien empleados, o el 28% de su fuerza laboral.
La explicación del CEO para los despidos es que Stack Overflow está tratando de encaminarse hacia la rentabilidad bajo presión macroeconómica y continúa introduciendo innovaciones de productos.
** ¿Cruzar el río y derribar el puente? **
La mayor ironía del impacto de ChatGPT en Stack Overflow es que el poder del gran modelo de lenguaje proviene en gran medida de sitios de raspado como Stack Overflow.
¿Qué sucede si los grandes modelos de lenguaje vacían estos datos sin devolver nada, y si todas las fuentes de datos se ven obligadas a salir del negocio?
Ahora, muchas empresas tecnológicas ya tienen un problema inminente: si hay menos programadores, habrá menos datos artificiales.
¿Cómo se entrenan nuevos modelos de IA sin datos actualizados?
¿Quieres usar nuestros datos? Llévate el dinero**
Stack Overflow, por supuesto, no puede quedarse quieto, eligió dos formas de salvarse:
Una es desarrollar su propia herramienta de codificación de IA, OverflowAI, y la otra es buscar asociaciones directamente con empresas tecnológicas como OpenAI, que utilizan los datos de Stack Overflow para crear modelos de IA.
OpenAI está desarrollando controles de rastreo web para ChatGPT para que los datos de sitios como Stack Overflow no puedan ser rastreados.
El CEO dijo que Stack Overflow ha tomado su postura: quien quiera usar nuestros datos para entrenar LLM paga.
Los CEOs creen que sitios como Stack Overflow son fundamentales para el desarrollo de grandes modelos de lenguaje, y para avanzar, necesitan ser entrenados en nuevos conocimientos.
Prashanth Chandrasekar, director ejecutivo de Stack Overflow
LLM quiere obtener el granjero de código, todavía es temprano
Entonces, ¿pueden los grandes modelos de lenguaje realmente tomar a los agricultores de código?
¡Los equipos de Princeton y Chicago descubrieron que no era tan fácil!
En el último artículo, los investigadores proponen un nuevo marco, SWE-bench, para evaluar la capacidad de los grandes modelos para resolver 2.294 problemas del mundo real en GitHub.
Se descubrió que los principales modelos grandes como GPT-4 y Claude 2 tenían menos del 5% de capacidad para resolver problemas reales.
Para ser más específicos, GPT-4 puede resolver problemas aleatorios de GitHub con una tasa de aprobación del 0%, mientras que el mejor modelo, Claude 2, solo puede resolver el 1,96% de ellos.
Lo que es más, al usar el BM-25 para recuperar los archivos de código relevantes para cada problema, solo el 23% de los parches escritos por Claude 2 eran válidos (listos para repositorios), y solo ~ 1% realmente resolvió el problema.
Además, el rendimiento de diferentes modelos en la resolución de problemas con 12 bibliotecas populares de Python también varía.
El modelo GPT-4 ha logrado tal resultado, lo cual es realmente sorprendente, después de todo, muchas personas lo han considerado durante mucho tiempo como un "arma de programación".
Pero para ver con claridad, la verdadera fuerza de la IA, no te dejes anotar y preocuparte.
Algunos internautas dijeron que esta es la mejor respuesta a la pregunta de "si los agricultores de código están desempleados debido a la programación".
Finalmente, alguien creó un conjunto de datos real para el modelo de código, y Hum fue solo la entrevista de leetcode de LLM. Todos sabemos que esta es la medida equivocada para los ingenieros humanos. Menos del 4% suena bien, ya que los modelos grandes aún están lejos de ser totalmente autónomos.
Entonces, ¿es este realmente el caso de los resultados de SWE-bench en la evaluación de las capacidades de los modelos grandes?
SWE-bench: Diseñado para codificar modelos
En este estudio, los autores encontraron que muchos puntos de referencia actuales para medir la capacidad de codificación de modelos grandes se han saturado y no pueden medir la verdadera fuerza de los modelos grandes.
Por ejemplo, en Human, el problema de desafío es demasiado simple y LLM solo necesita unas pocas líneas de código para resolver un problema independiente.
Sin embargo, la ingeniería de software no es tan simple en la realidad.
Corregir un error puede requerir navegar por una enorme biblioteca de recursos, comprender las relaciones entre las funciones en diferentes archivos o encontrar un pequeño error en el intrincado código.
Inspirados por esto, investigadores de Princeton y Chicago introdujeron SWE-bench.
SWE-bench obtiene instancias de tareas de un repositorio real de Python conectando problemas de GitHub y soluciones de solicitud de fusión para resolver pruebas relacionadas.
Como se muestra en la imagen, la tarea del modelo, normalmente un informe de errores o una solicitud de características, es resolver un problema confirmado en el repositorio de GitHub.
Cada tarea requiere generar un parche y describir los cambios que se aplicarán al código base existente.
A continuación, utilice el marco de pruebas SWE-bench del repositorio para evaluar el código base modificado.
Para encontrar ejemplos de alta calidad de tareas a gran escala, los investigadores pasaron por tres etapas de selección:
**Etapa 1: Selección de almacén y búsqueda de datos. **
Las solicitudes de incorporación de cambios (PR) se recopilaron por primera vez de 12 repositorios populares de Python de código abierto en GitHub, generando un total de aproximadamente 90.000 solicitudes de incorporación de cambios.
Los investigadores se centraron en los repositorios populares porque tienden a estar mejor mantenidos, tienen directrices claras para los contribuyentes y tienen una mejor cobertura de pruebas. Cada solicitud de incorporación de cambios tiene una base de código asociada, es decir, el estado del repositorio antes de que se fusionara la solicitud de incorporación de cambios.
**Fase 2: Filtrado basado en atributos. **
La tarea candidata se crea seleccionando una solicitud de incorporación de cambios combinada que cumpla los siguientes criterios: (1) resuelva el problema de GitHub; (2) Se modificó el archivo de prueba del repositorio, que indica que lo más probable es que el usuario haya contribuido con pruebas para verificar si el problema está resuelto.
**Fase 3: Filtrado basado en la ejecución. **
Para cada tarea candidata, se aplica el contenido de la prueba de la solicitud de incorporación de cambios y se aplican los resultados de la prueba relevantes antes y después del resto del contenido de la solicitud de incorporación de cambios.
El investigador filtra las instancias de tareas que no tienen al menos una prueba, y el estado de estas pruebas cambia de no aprobado (en lo sucesivo, "no aprobado la prueba"). Además, se filtran las instancias que provocan errores de instalación u operación.
A través de estas etapas de selección, los 90.000 PR originales se seleccionan en 2.294 instancias de tareas, que conforman el banco SWE.
La clasificación final de estas instancias de tareas en diferentes repositorios se muestra en la Figura 3 a continuación, siendo la tabla la característica principal de las instancias de tareas de SWE-bench.
Los investigadores enfatizan que estas bases de código son grandes, contienen miles de archivos, y que las solicitudes de extracción de referencia a menudo modifican varios archivos al mismo tiempo.
SWE-bench ofrece varias ventajas sobre los puntos de referencia de programación LM existentes.
Estos incluyen configuraciones del mundo real con problemas y soluciones enviados por los usuarios, diversas entradas con preguntas de código únicas de 12 repositorios, un sólido marco de evaluación basado en la ejecución y la capacidad de actualizar continuamente los puntos de referencia con nuevas instancias con una mínima intervención humana.
Tarea LLM: Editar código base, resolver problemas
El investigador le dará al modelo grande una descripción textual del problema, así como una base de código completa.
La tarea del modelo grande es editar el código base para resolver el problema.
En la práctica, los investigadores representan los cambios como archivos de parche, que especifican qué líneas de la base de código modificar para resolver el problema.
¿Cómo evaluar si la solución dada por LLM es buena o no?
Los investigadores utilizan parches de Unix, aplican los parches generados a la base de código y, a continuación, realizan pruebas unitarias y del sistema relacionadas con las instancias de tareas.
Si el parche se aplica correctamente y se superan todas estas pruebas, se puede considerar que el esquema recomendado por LLM ha resuelto correctamente el problema.
Una métrica de la línea base, que es el porcentaje de instancias de tareas resueltas.
Creación de un conjunto de datos único para SWE-bench
Los puntos de referencia tradicionales de NLP generalmente involucran solo secuencias cortas de entrada y salida y consideran algunos problemas "artificiales" creados específicamente para los puntos de referencia.
Por el contrario, para construir el banco SWE, los investigadores inyectaron propiedades únicas en el conjunto de datos.
Por ejemplo, se utilizan tareas reales de ingeniería de software.
Dado que cada instancia de tarea en SWE-bench contiene una base de código grande y compleja y una descripción del problema asociado, la resolución de SWE-bench requiere las habilidades y conocimientos complejos de ingenieros de software experimentados, que a menudo no se evalúan en los puntos de referencia tradicionales de generación de código.
Además, el proceso de recopilación se puede aplicar fácilmente a cualquier repositorio de Python en GitHub con poca o ninguna intervención humana.
Como resultado, los investigadores pueden ampliar el SWE-bench proporcionando nuevas instancias de tareas y evaluar el modelo de lenguaje para los problemas creados después de la fecha de entrenamiento, asegurándose de que el corpus de entrenamiento no contenga una solución.
Además, los investigadores garantizan diferentes entradas largas en el benchmark, evaluación robusta, edición de código cross-context, amplia gama de soluciones, etc.
Puesta a punto de SWE-Llama
A continuación, es el momento de evaluar la eficacia de los modelos abiertos y propietarios en el marco SWE-bench.
Sin embargo, los investigadores descubrieron que los modelos de ajuste fino de CodeLlama listos para usar no podían seguir instrucciones detalladas para generar ediciones de código en toda la biblioteca, a menudo generando respuestas de marcador de posición o código irrelevante.
Para evaluar las capacidades de estos modelos, los investigadores realizaron un ajuste fino supervisado (SFT) en el modelo CodeLlama-Python de 7.000 millones de parámetros y el modelo CodeLlama-Python de 13.000 millones de parámetros.
El modelo resultante es un editor de repositorios especializado que se ejecuta en hardware de nivel de consumidor y resuelve problemas de GitHub.
### Los modelos grandes fallan
A continuación, los investigadores evaluaron GPT-3.5, GPT-4, Cluade 2 y modelos afinados.
Resultó que todos los modelos fallaron, ninguno de ellos resolvió todos los problemas, excepto los más simples.
Por ejemplo, Claude 2 y GPT-4 solo pueden resolver el 4,8% y el 1,7% de las tareas, respectivamente.
Después de usar el retriever BM25, el rendimiento de Claude 2 cayó aún más al 1,96%.
**Las diferentes bibliotecas tienen diferentes niveles de dificultad. **
Si desglosa el rendimiento por repositorio, verá que todos los modelos muestran tendencias similares en todas las bibliotecas.
Sin embargo, los problemas abordados por cada modelo no necesariamente se superponen ampliamente. Por ejemplo, en una configuración de Oracle, Claude 2 y SWE-Llama 13b tienen un rendimiento comparable, resolviendo 110 y 91 instancias por modelo, respectivamente.
**La dificultad depende de la longitud del contexto. **
Los modelos se pueden entrenar previamente en secuencias de código largas, pero normalmente requieren que se genere una sola función a la vez y proporcionan un marco con contexto limitado para determinar el problema.
Como se muestra, se puede ver que el rendimiento de Claude 2 se degrada significativamente a medida que aumenta la longitud total del contexto, lo que también se puede observar en otros modelos.
Incluso si el aumento del tamaño máximo de contexto del BM25 mejorara la recuperación en relación con los archivos de Oracle, el rendimiento seguiría degradándose porque el modelo simplemente no podría localizar el código problemático en el vasto diccionario de sinónimos.
**La dificultad es independiente de la fecha de resolución del problema. **
En la tabla 7 se muestran los resultados del modelo por fecha para las solicitudes de incorporación de cambios creadas antes o después de 2023 en la configuración de búsqueda de "oráculo".
Para la mayoría de los modelos, con la excepción de GPT-4, hay poca diferencia en el rendimiento antes o después de esta fecha.
Además, el estudio encontró que el ajuste fino del modelo es sensible a los cambios en la distribución del contexto, y es más fácil generar un parche que generar un archivo completo. Y los modelos grandes tienden a producir ediciones más cortas y simples.
LLM no es un sustituto de los programadores, pero puede acelerar los flujos de trabajo
Algunos internautas tienen esperanzas y esperanzas para el futuro del "modelo generalista".
Así es, eso es lo que estoy diciendo. El modelo generalista no es lo suficientemente bueno como para tener una longitud de contexto lo suficientemente amplia como para codificar por sí solo, excepto para fragmentos de código relativamente cortos.
Pero creo que es solo cuestión de tiempo. Puedo prever que en un futuro próximo, el LLM generalista con formación específica se convertirá en un modelo muy profesional.
Si bien los modelos grandes no sustituyen a los programadores, pueden acelerar sus flujos de trabajo. Lo que antes tomaba un equipo de 10 personas, ahora solo necesita 4 personas. Esto libera recursos para otros objetivos preparados por la empresa.
En lugar de despedir empleados para ahorrar dinero, ¡deje que los desarrolladores logren grandes cosas a una velocidad vertiginosa!
Recursos:
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
¡Los modelos grandes no pueden ser agricultores de código! El sorprendente descubrimiento de Princeton: GPT-4 tiene una tasa de éxito de 0 en la resolución de problemas de programación de GitHub
Fuente del artículo: Shin Ji Yuan
¡Stack Overflow, ya creado por ChatGPT!
Debido a que los programadores acudieron en masa a ChatGPT y Github Copilot, Stack Overflow tuvo que anunciar el despido de más de 100 empleados hoy, lo que representa casi 1/3 del número de empleados.
Pero un estudio reciente realizado por Princeton y Chicago encontró que LLM no es tan fácil de hacer como un granjero de código.
Frente a 2294 problemas reales de GitHub, la tasa de aprobación de GPT-4 resolviendo problemas aleatorios de GitHub resultó ser del 0%.
Incluso el mejor modelo, el Claude 2, solo resuelve el 1,96% de ellos.
Adaptarse o perecer
Como el sitio asistido por código favorito de todos los desarrolladores en el mundo, Stack Overflow ha tenido un buen desempeño antes, lo que desencadenó una ola de contrataciones el año pasado, duplicando la fuerza laboral de la compañía a 540.
Sin embargo, todo ha cambiado desde que OpenAI lanzó ChatGPT el pasado mes de noviembre.
Si bien LLM no proporciona respuestas 100% confiables, la capacidad única de validar el código de inmediato simplemente probándolo en el entorno de desarrollo integrado IDE hace que escribir código sea un caso de uso ideal para ChatGPT.
Como resultado, el tráfico de Stack Overflow se ha reducido considerablemente, y las herramientas de programación de IA como ChatGPT y Github Copilot con tecnología GPT-4 se han convertido en nuevos lugares para los agricultores de código.
Hoy, el CEO Prashanth Chandrasekar anunció que Stack Overflow ha despedido a más de cien empleados, o el 28% de su fuerza laboral.
** ¿Cruzar el río y derribar el puente? **
La mayor ironía del impacto de ChatGPT en Stack Overflow es que el poder del gran modelo de lenguaje proviene en gran medida de sitios de raspado como Stack Overflow.
¿Qué sucede si los grandes modelos de lenguaje vacían estos datos sin devolver nada, y si todas las fuentes de datos se ven obligadas a salir del negocio?
Ahora, muchas empresas tecnológicas ya tienen un problema inminente: si hay menos programadores, habrá menos datos artificiales.
¿Cómo se entrenan nuevos modelos de IA sin datos actualizados?
¿Quieres usar nuestros datos? Llévate el dinero**
Stack Overflow, por supuesto, no puede quedarse quieto, eligió dos formas de salvarse:
Una es desarrollar su propia herramienta de codificación de IA, OverflowAI, y la otra es buscar asociaciones directamente con empresas tecnológicas como OpenAI, que utilizan los datos de Stack Overflow para crear modelos de IA.
El CEO dijo que Stack Overflow ha tomado su postura: quien quiera usar nuestros datos para entrenar LLM paga.
Los CEOs creen que sitios como Stack Overflow son fundamentales para el desarrollo de grandes modelos de lenguaje, y para avanzar, necesitan ser entrenados en nuevos conocimientos.
LLM quiere obtener el granjero de código, todavía es temprano
Entonces, ¿pueden los grandes modelos de lenguaje realmente tomar a los agricultores de código?
¡Los equipos de Princeton y Chicago descubrieron que no era tan fácil!
Se descubrió que los principales modelos grandes como GPT-4 y Claude 2 tenían menos del 5% de capacidad para resolver problemas reales.
Para ser más específicos, GPT-4 puede resolver problemas aleatorios de GitHub con una tasa de aprobación del 0%, mientras que el mejor modelo, Claude 2, solo puede resolver el 1,96% de ellos.
Además, el rendimiento de diferentes modelos en la resolución de problemas con 12 bibliotecas populares de Python también varía.
Pero para ver con claridad, la verdadera fuerza de la IA, no te dejes anotar y preocuparte.
SWE-bench: Diseñado para codificar modelos
En este estudio, los autores encontraron que muchos puntos de referencia actuales para medir la capacidad de codificación de modelos grandes se han saturado y no pueden medir la verdadera fuerza de los modelos grandes.
Por ejemplo, en Human, el problema de desafío es demasiado simple y LLM solo necesita unas pocas líneas de código para resolver un problema independiente.
Sin embargo, la ingeniería de software no es tan simple en la realidad.
Inspirados por esto, investigadores de Princeton y Chicago introdujeron SWE-bench.
SWE-bench obtiene instancias de tareas de un repositorio real de Python conectando problemas de GitHub y soluciones de solicitud de fusión para resolver pruebas relacionadas.
Como se muestra en la imagen, la tarea del modelo, normalmente un informe de errores o una solicitud de características, es resolver un problema confirmado en el repositorio de GitHub.
Cada tarea requiere generar un parche y describir los cambios que se aplicarán al código base existente.
A continuación, utilice el marco de pruebas SWE-bench del repositorio para evaluar el código base modificado.
Las solicitudes de incorporación de cambios (PR) se recopilaron por primera vez de 12 repositorios populares de Python de código abierto en GitHub, generando un total de aproximadamente 90.000 solicitudes de incorporación de cambios.
Los investigadores se centraron en los repositorios populares porque tienden a estar mejor mantenidos, tienen directrices claras para los contribuyentes y tienen una mejor cobertura de pruebas. Cada solicitud de incorporación de cambios tiene una base de código asociada, es decir, el estado del repositorio antes de que se fusionara la solicitud de incorporación de cambios.
**Fase 2: Filtrado basado en atributos. **
La tarea candidata se crea seleccionando una solicitud de incorporación de cambios combinada que cumpla los siguientes criterios: (1) resuelva el problema de GitHub; (2) Se modificó el archivo de prueba del repositorio, que indica que lo más probable es que el usuario haya contribuido con pruebas para verificar si el problema está resuelto.
**Fase 3: Filtrado basado en la ejecución. **
Para cada tarea candidata, se aplica el contenido de la prueba de la solicitud de incorporación de cambios y se aplican los resultados de la prueba relevantes antes y después del resto del contenido de la solicitud de incorporación de cambios.
El investigador filtra las instancias de tareas que no tienen al menos una prueba, y el estado de estas pruebas cambia de no aprobado (en lo sucesivo, "no aprobado la prueba"). Además, se filtran las instancias que provocan errores de instalación u operación.
A través de estas etapas de selección, los 90.000 PR originales se seleccionan en 2.294 instancias de tareas, que conforman el banco SWE.
La clasificación final de estas instancias de tareas en diferentes repositorios se muestra en la Figura 3 a continuación, siendo la tabla la característica principal de las instancias de tareas de SWE-bench.
Los investigadores enfatizan que estas bases de código son grandes, contienen miles de archivos, y que las solicitudes de extracción de referencia a menudo modifican varios archivos al mismo tiempo.
SWE-bench ofrece varias ventajas sobre los puntos de referencia de programación LM existentes.
Estos incluyen configuraciones del mundo real con problemas y soluciones enviados por los usuarios, diversas entradas con preguntas de código únicas de 12 repositorios, un sólido marco de evaluación basado en la ejecución y la capacidad de actualizar continuamente los puntos de referencia con nuevas instancias con una mínima intervención humana.
Tarea LLM: Editar código base, resolver problemas
El investigador le dará al modelo grande una descripción textual del problema, así como una base de código completa.
La tarea del modelo grande es editar el código base para resolver el problema.
En la práctica, los investigadores representan los cambios como archivos de parche, que especifican qué líneas de la base de código modificar para resolver el problema.
Los investigadores utilizan parches de Unix, aplican los parches generados a la base de código y, a continuación, realizan pruebas unitarias y del sistema relacionadas con las instancias de tareas.
Una métrica de la línea base, que es el porcentaje de instancias de tareas resueltas.
Creación de un conjunto de datos único para SWE-bench
Los puntos de referencia tradicionales de NLP generalmente involucran solo secuencias cortas de entrada y salida y consideran algunos problemas "artificiales" creados específicamente para los puntos de referencia.
Por el contrario, para construir el banco SWE, los investigadores inyectaron propiedades únicas en el conjunto de datos.
Por ejemplo, se utilizan tareas reales de ingeniería de software.
Además, el proceso de recopilación se puede aplicar fácilmente a cualquier repositorio de Python en GitHub con poca o ninguna intervención humana.
Como resultado, los investigadores pueden ampliar el SWE-bench proporcionando nuevas instancias de tareas y evaluar el modelo de lenguaje para los problemas creados después de la fecha de entrenamiento, asegurándose de que el corpus de entrenamiento no contenga una solución.
Además, los investigadores garantizan diferentes entradas largas en el benchmark, evaluación robusta, edición de código cross-context, amplia gama de soluciones, etc.
Puesta a punto de SWE-Llama
A continuación, es el momento de evaluar la eficacia de los modelos abiertos y propietarios en el marco SWE-bench.
Sin embargo, los investigadores descubrieron que los modelos de ajuste fino de CodeLlama listos para usar no podían seguir instrucciones detalladas para generar ediciones de código en toda la biblioteca, a menudo generando respuestas de marcador de posición o código irrelevante.
Para evaluar las capacidades de estos modelos, los investigadores realizaron un ajuste fino supervisado (SFT) en el modelo CodeLlama-Python de 7.000 millones de parámetros y el modelo CodeLlama-Python de 13.000 millones de parámetros.
El modelo resultante es un editor de repositorios especializado que se ejecuta en hardware de nivel de consumidor y resuelve problemas de GitHub.
A continuación, los investigadores evaluaron GPT-3.5, GPT-4, Cluade 2 y modelos afinados.
Resultó que todos los modelos fallaron, ninguno de ellos resolvió todos los problemas, excepto los más simples.
Por ejemplo, Claude 2 y GPT-4 solo pueden resolver el 4,8% y el 1,7% de las tareas, respectivamente.
Después de usar el retriever BM25, el rendimiento de Claude 2 cayó aún más al 1,96%.
**Las diferentes bibliotecas tienen diferentes niveles de dificultad. **
Si desglosa el rendimiento por repositorio, verá que todos los modelos muestran tendencias similares en todas las bibliotecas.
Sin embargo, los problemas abordados por cada modelo no necesariamente se superponen ampliamente. Por ejemplo, en una configuración de Oracle, Claude 2 y SWE-Llama 13b tienen un rendimiento comparable, resolviendo 110 y 91 instancias por modelo, respectivamente.
**La dificultad depende de la longitud del contexto. **
Los modelos se pueden entrenar previamente en secuencias de código largas, pero normalmente requieren que se genere una sola función a la vez y proporcionan un marco con contexto limitado para determinar el problema.
Como se muestra, se puede ver que el rendimiento de Claude 2 se degrada significativamente a medida que aumenta la longitud total del contexto, lo que también se puede observar en otros modelos.
Incluso si el aumento del tamaño máximo de contexto del BM25 mejorara la recuperación en relación con los archivos de Oracle, el rendimiento seguiría degradándose porque el modelo simplemente no podría localizar el código problemático en el vasto diccionario de sinónimos.
En la tabla 7 se muestran los resultados del modelo por fecha para las solicitudes de incorporación de cambios creadas antes o después de 2023 en la configuración de búsqueda de "oráculo".
Para la mayoría de los modelos, con la excepción de GPT-4, hay poca diferencia en el rendimiento antes o después de esta fecha.
LLM no es un sustituto de los programadores, pero puede acelerar los flujos de trabajo
Algunos internautas tienen esperanzas y esperanzas para el futuro del "modelo generalista".
Así es, eso es lo que estoy diciendo. El modelo generalista no es lo suficientemente bueno como para tener una longitud de contexto lo suficientemente amplia como para codificar por sí solo, excepto para fragmentos de código relativamente cortos.
Pero creo que es solo cuestión de tiempo. Puedo prever que en un futuro próximo, el LLM generalista con formación específica se convertirá en un modelo muy profesional.
En lugar de despedir empleados para ahorrar dinero, ¡deje que los desarrolladores logren grandes cosas a una velocidad vertiginosa!