Traducido del inglés al español - www.onlinedoctranslator.
com
Generación automática de documentación de código mediante GPT-3
Junaed Younus Khan y Gias Uddin
Laboratorio DISA, Universidad de Calgary
ABSTRACTO
La documentación del código fuente es un artefacto importante para el desarrollo de
software eficiente. La documentación del código podría beneficiarse enormemente de
la automatización, ya que la documentación manual suele requerir mucha mano de
obra, recursos y tiempo. En este artículo, utilizamos Codex para la creación
automática de documentación de código. Codex es un modelo basado en GPT-3
previamente entrenado en lenguajes naturales y de programación. Descubrimos que
Codex supera a las técnicas existentes incluso con configuraciones básicas como el
aprendizaje de una sola vez (es decir, proporcionando solo un ejemplo para la
arXiv:2209.02235v1 [cs.SE] 6 de septiembre de 2022
capacitación). Codex logra una puntuación BLEU general de 20,6 para seis lenguajes
de programación diferentes (una mejora del 11,2% con respecto a técnicas de
vanguardia anteriores). Por lo tanto, Codex es prometedor y garantiza estudios
futuros en profundidad para la generación automática de documentación de código
para respaldar diversas tareas de desarrollo.
CONCEPTOS DE CCS
• El software y su ingeniería.→Documentación;•Metodologías
informáticas→Generación de lenguaje natural.
PALABRAS CLAVE
documentación de código, GPT-3, aprendizaje automático.
Formato de referencia ACM:
Junaed Younus Khan y Gias Uddin. 2022. Generación automática de documentación
de código mediante GPT-3. En37.ª Conferencia internacional IEEE/ACM sobre
ingeniería de software automatizada (ASE '22), del 10 al 14 de octubre de 2022,
Rochester, MI, EE. UU.ACM, Nueva York, NY, EE.UU., 6 páginas. https://doi.org/
10.1145/3551349. 3559548
1. INTRODUCCIÓN
En Ingeniería de Software (SE), los desarrolladores a menudo intentan descubrir qué
hace una unidad de código específica (por ejemplo, un método) y cómo utilizarla [59].
Pueden hacerlo leyendo la documentación del código fuente. La documentación bien
escrita es crucial para un desarrollo de software eficaz [14]. El cambio repentino al
trabajo desde casa durante COVID-19 mostró aún más la necesidad de una buena
documentación para los desarrolladores, cuando el experto en la materia del código
base puede estar ausente o no disponible [49]. Sin embargo, crear y mantener dicha
documentación es costoso y lleva mucho tiempo. La mayoría de los desarrolladores a
menudo muestran falta de voluntad para escribir documentación, ya que la
encuentran menos productiva y menos gratificante [33, 37]. Como resultado, la
documentación manual a menudo
El permiso para hacer copias digitales o impresas de todo o parte de este trabajo para uso personal o
en el aula se otorga sin cargo, siempre que las copias no se hagan ni distribuyan con fines de lucro o
ventaja comercial y que las copias lleven este aviso y la cita completa en la primera página. . Se deben
respetar los derechos de autor de los componentes de este trabajo que no pertenecen a ACM. Se
permite realizar resúmenes con crédito. Para copiarlo de otra manera, o republicarlo, publicarlo en
servidores o redistribuirlo en listas, se requiere un permiso específico previo y/o una tarifa. Solicite
permisos a permisos@acm.org .
ASE '22, del 10 al 14 de octubre de 2022, Rochester, MI, EE. UU.
© 2022 Asociación de Maquinaria de Computación.
ACM ISBN 978-1-4503-9475-22/8/10. . .$15.00
https://doi.org/10.1145/3551349.3559548
se vuelve problemático o inutilizable [2, 3, 45, 51]. Además, la documentación
se vuelve obsoleta con el tiempo debido a modificaciones o actualizaciones
continuas del sistema (es decir, código base) [26, 50, 52].
Actualmente, la generación automatizada de documentación de
código está atrayendo mucha atención por parte de la comunidad de
investigadores para sustituir o complementar los esfuerzos de
documentación manual. Trabajos anteriores en esta dirección se
centraron principalmente en estrategias basadas en plantillas [1, 34, 35,
43, 44, 47] y basadas en recuperación de información (IR) [16, 21, 22, 53,
57, 58]. Los enfoques basados en plantillas se limitan al conjunto
subyacente de plantillas y, por lo tanto, son finitos/limitados, mientras
que las medidas de similitud en los enfoques basados en RI pueden ser
erróneas [42]. Recientemente, los investigadores están investigando
varios enfoques basados en el aprendizaje (por ejemplo, aprendizaje
profundo) para la generación de documentación. Por ejemplo, CODE-NN,
presentado por Iyer et al., puede generar documentación de código C# y
SQL utilizando redes de atención LSTM [27]. Allamanis et al. También
utilizó una red neuronal de atención para el resumen de código [6]. Hu et
al.
El reciente éxito de los modelos de transformadores previamente entrenados en
varios dominios alentó a los investigadores a utilizarlos también para la generación
automatizada de documentación. De hecho, se considera que son los artistas más
avanzados en esta tarea. CodeBERT, un modelo basado en BERT previamente
entrenado en datos de lenguajes de programación y naturales a gran escala, mostró
un gran rendimiento en la generación automatizada de documentación [17]. Algunos
otros modelos pre-entrenados basados en transformadores, es decir, PLBART [5],
CoTexT [40] recientemente superaron a CodeBERT en el contexto de la generación de
documentación.
Aunque los modelos de transformadores previamente entrenados se han mostrado prometedores en la
generación de documentación de código, no conocemos ningún estudio para evaluar la efectividad de GPT-3 en
esta dirección. GPT-3 es el modelo de transformador generativo preentrenado de tercera generación desarrollado
por OpenAI. GPT-3 tiene 175B de parámetros y está entrenado con datos de Internet a muy gran escala [8]. Se ha
descubierto que logra un alto rendimiento en diferentes tareas de clasificación y generación [11-13, 19]. Al igual
que otros modelos de transformadores, la arquitectura GPT-3 también se puede utilizar en diferentes tareas de
ingeniería de software que implican la comprensión tanto del lenguaje natural como de programación. De hecho,
OpenAI lanzó un modelo dedicado, Codex, para esta tarea. Codex es un modelo similar a GPT-3 que se entrena con
datos de GitHub a gran escala. Codex está capacitado en más de una docena de lenguajes de programación como
Python, Java, PHP, JavaScript, etc. [9]. El vídeo de demostración de OpenAI muestra que Codex podría generar
código fuente a partir de un requisito determinado especificado en lenguaje natural. Desde entonces, los
investigadores han estado investigando Codex para la automatización de varias tareas de SE, como generación de
código [18], reparación de código [41], corrección de errores de seguridad [39] y modelado de simulación [28]. La
documentación oficial de Codex menciona que también es capaz de generar documentación automáticamente. Sin
embargo, no conocemos ninguna evaluación sistemática del Codex para producir documentación de código.
modelado de simulación [28]. La documentación oficial de Codex menciona que también es capaz de generar
documentación automáticamente. Sin embargo, no conocemos ninguna evaluación sistemática del Codex para
producir documentación de código. modelado de simulación [28]. La documentación oficial de Codex menciona
que también es capaz de generar documentación automáticamente. Sin embargo, no conocemos ninguna
evaluación sistemática del Codex para producir documentación de código.
ASE '22, del 10 al 14 de octubre de 2022, Rochester, MI, EE. UU.
En este artículo, realizamos un estudio de caso preliminar para investigar la
eficacia de Codex en la documentación de códigos. Analizamos la
documentación del código producida automáticamente por Codex para seis
lenguajes de programación: Python, Java, PHP, GO, JavaScript, Go y Ruby. Para
ser específicos, evaluamos Codex en el conjunto de datos CodeSearchNet [25] y
comparamos su rendimiento con los modelos existentes [5, 17, 38, 40]. A
diferencia de otros modelos de transformadores previamente entrenados,
GPT-3 a menudo funciona bien en diferentes tareas posteriores sin ningún tipo
de reentrenamiento o ajuste. En cambio, se adapta a una tarea mediante un
aprendizaje de una (o varias) tomas en el que se proporciona al modelo una
descripción de la tarea y uno (o algunos) ejemplos de esa tarea. De hecho,
simplemente proporcionar la descripción de la tarea sin ningún ejemplo
(aprendizaje de disparo cero) a menudo produce buenos resultados. En este
estudio, Hemos experimentado Codex con aprendizaje cero y de una sola vez.
Descubrimos que Codex con aprendizaje de una sola vez muestra un
rendimiento general de última generación en la generación de documentación,
superando a todos los modelos anteriores con una puntuación BLEU promedio
de 20,63. En cuanto al rendimiento específico del lenguaje, supera a todos los
modelos en cuatro de seis lenguajes (es decir, Python, Ruby, JavaScript, GO) con
un buen margen. Para los otros dos lenguajes, es decir, Java y PHP, se convierte
en el segundo con mejor desempeño, donde fue ligeramente superado por
REDCODER y CodeBERT, respectivamente. También realizamos varios análisis
cualitativos de la documentación del Codex en términos de nivel de grado
Flesch-Kincaid (legibilidad), longitud de la documentación (cantidad) y TF-IDF
(informatividad). Descubrimos que la documentación generada se acerca a la
real según estas métricas. De hecho, Observamos que parte de la
documentación generada por el Codex podría contener información más
comprensible que la actual. Descubrimos que incluso con una configuración
muy básica (aprendizaje de una sola vez), Codex es capaz de ofrecer un
rendimiento de última generación en este campo. Hasta donde sabemos, la
nuestra es la primera evaluación sistemática del modelo GPT-3 Codex en la
generación automatizada de documentación de código.
Paquete de replicación.https://github.com/disa-lab/
CodeDoc_GPT-3_ASE22
2. TRABAJO RELACIONADO
El trabajo relacionado con la documentación automática de código puede ser de tres tipos:
plantilla, recuperación de información y basado en aprendizaje.
Basado en plantillasutiliza una herramienta automática para insertar
información de acuerdo con reglas y diseños predefinidos. Sridhara et al.
utilizó plantillas de lenguaje natural para capturar las declaraciones clave
de un método Java y crear un resumen a nivel de método [47]. Rastkar et
al. y Moreno et al. utilizó heurística para extraer y resumir información del
código fuente [35, 44]. Mcburney y cols. información contextual fusionada
con declaraciones de método [34]. Abid et al. produjo un resumen de los
métodos de C++ estereotipándolos con su marco de análisis de código
fuente (srcML) [1]. Rai et al. Código Java resumido que utiliza
nanopatrones a nivel de código [43].
Recuperación de informaciónHaiduc et al. han empleado enfoques como la
indexación semántica latente (LSI) y el modelado del espacio vectorial (VSM).
para generar documentación para clases y métodos [21, 22]. Eddy y cols.
ampliaron su trabajo explotando un modelo de tema jerárquico [16]. Wong et
al. empleó detección de clones de código para encontrar fragmentos de código
similares de StackOverflow y extrajo automáticamente descripciones del
código fuente para la generación de comentarios [57, 58].
Junaed Younus Khan y Gias Uddin
GPT-3
Datos Modelo y
Documentación Análisis de resultados
Generación y
Preprocesamiento Parámetro
con GPT-3 Comparación
Configuración
Figura 1: Una descripción esquemática de nuestro estudio
Basado en el aprendizajeLos enfoques utilizan principalmente técnicas de aprendizaje profundo para
aprender características latentes del código fuente. Iyer et al. propuso una red basada en LSTM, CODE-
NN, que fue entrenada con datos de Stack Overflow para generar resúmenes de código C# y SQL [27].
Allamanis et al. utilizó una red neuronal de atención que emplea convolución para aprender
características locales invariantes en el tiempo [6]. Barone et al. construyó un conjunto de datos de
funciones de Python y sus cadenas de documentos utilizando datos de GitHub y empleó traducción
automática neuronal (NMT) para generar cadenas de documentos a partir de funciones determinadas
[7]. Wan et al. propuso un marco de aprendizaje por refuerzo que incorpora el árbol de sintaxis
abstracta (AST) junto con el contenido del código secuencial [55]. Hu et al. desarrolló DeepCom e
Hybrid-Deepcom para generar comentarios de código aprendiendo de un gran corpus y combinando
información léxica y estructural del código [23, 24]. Chen y Zhou diseñaron un marco neuronal llamado
BVAE para mejorar las tareas de recuperación y resumen de código [10]. Varios estudios emplearon
modelos basados en transformadores, por ejemplo, Ahmad et al. utilizó un modelo transformador
basado en la autoatención [4], mientras que Wang et al. desarrolló un modelo basado en BERT llamado
Fret [56]. Feng et al. presentó CodeBERT, previamente entrenado en 2,1 millones de puntos de datos
bimodales (códigos y descripciones) y 6,4 millones de códigos unimodales en seis lenguajes (Python,
Java, JavaScript, PHP, Ruby y Go) [17]. Evaluaron CodeBERT en dos tareas NL-PL posteriores (búsqueda
de código y documentación) ajustando los parámetros del modelo. Gao et al. propuso el concepto de
Transformador guiado por estructura de código para el resumen de código fuente que incorpora
propiedades estructurales del código en el transformador para mejorar el rendimiento [20]. Phan et al.
presentó CoTexT que aprende el contexto representativo entre el lenguaje natural y el de
programación y realiza varias tareas posteriores, incluido el resumen de código [40]. Ahmad et al.
desarrolló PLBART, un modelo de secuencia a secuencia, previamente entrenado en un gran conjunto
de funciones de Java y Python y sus descripciones textuales recopiladas de Github y Stack Overflow [5].
Posteriormente, Parvez et al. demostró que la adición de códigos/resúmenes relevantes recuperados
de una base de datos (como GitHub y Stack Overflow) puede mejorar la calidad de la documentación
producida por un modelo generador [38]. previamente entrenado en un gran conjunto de funciones de
Java y Python y sus descripciones textuales recopiladas de Github y Stack Overflow [5]. Posteriormente,
Parvez et al. demostró que la adición de códigos/resúmenes relevantes recuperados de una base de
datos (como GitHub y Stack Overflow) puede mejorar la calidad de la documentación producida por un
modelo generador [38]. previamente entrenado en un gran conjunto de funciones de Java y Python y
sus descripciones textuales recopiladas de Github y Stack Overflow [5]. Posteriormente, Parvez et al.
demostró que la adición de códigos/resúmenes relevantes recuperados de una base de datos (como
GitHub y Stack Overflow) puede mejorar la calidad de la documentación producida por un modelo
generador [38].
Aunque los modelos basados en transformadores se mostraron prometedores
en la generación de documentación, el modelo GPT-3 aún no había sido evaluado
sistemáticamente para esta tarea a pesar de su éxito y popularidad. Nuestro estudio
empleó el modelo Codex basado en GPT-3 para la generación de documentación y
comparó su rendimiento con los enfoques existentes.
3 EXPERIMENTO
En esta sección, presentamos los resultados de nuestra investigación preliminar sobre
la efectividad de GPT-3 para la generación de documentación de código fuente. En la
Figura 1 se muestra una descripción esquemática de los pasos principales de nuestro
estudio y se describen a continuación.
3.1 Recopilación y preprocesamiento de conjuntos de datos
Para evaluar la efectividad de nuestro método, utilizamos CodeSearch-Net [25], un
conjunto de datos ampliamente utilizado para diferentes tareas de SE posteriores.
Este conjunto de datos también se incluye en CodeXGLUE [32], un conjunto de datos
de referencia de aprendizaje automático para la comprensión y generación de código.
Incorpora una gran cantidad de pares de código y documentación provenientes
Generación automática de documentación de código mediante GPT-3
Tabla 1: Estadísticas de CodeSearchNet [25]
Idioma Tren Válido Prueba
Java 164,923 5.183 10.955
Pitón 251.820 13,914 14,918
PHP 241,241 12,982 14.014
IR 167,288 7.325 8.122
javascript 58.025 3.885 3.291
Rubí 24.927 1.400 1.261
de seis lenguajes diferentes, es decir, Java, Python, PHP, GO, JavaScript y Ruby.
Aplicamos el mismo procesamiento de datos recomendado por Feng et al.
donde evaluaron CodeBERT para la generación de documentación [17].
Primero eliminamos los comentarios de todos los códigos y luego eliminamos
los ejemplos en los que i) los códigos no se pueden analizar en un árbol de
sintaxis abstracta, ii) la cantidad de tokens en la documentación es menor que
3 o mayor que 256, iii) la documentación contiene tokens especiales. como<
imagen>, https://, etc., iv) el idioma no es el inglés. Las estadísticas del conjunto
de datos limpios están disponibles en la Tabla 1.
3.2 Configuración de parámetros y modelo GPT-3
Modelo.Generative Pre-trained Transformer-3 (GPT-3) [8], desarrollado por OpenAI, es
un modelo de lenguaje autorregresivo que emplea aprendizaje profundo para
generar texto similar al humano. Tiene 175 mil millones de parámetros y 96 capas
entrenadas en∼45 TB de datos de texto provenientes de diferentes contenidos web
(como Wikipedia). Tiene resultados prometedores en varios tipos de tareas de PNL,
por ejemplo, respuesta a preguntas, resúmenes y traducción. No solo eso, GPT-3
también ha demostrado un gran éxito en tareas de ingeniería de software como la
generación de código a partir de comandos en lenguaje natural. Por lo tanto, nos
sentimos motivados a evaluar también su eficacia en la generación de documentación
de código. Para nuestro experimento, utilizamos Codex, un descendiente de GPT-3,
que está entrenado tanto en lenguaje natural como en miles de millones de líneas de
código público de GitHub. Codex puede comprender varios lenguajes de
programación como Python, Java, JavaScript, Go, Perl, PHP, Ruby, etc. Codex ya se ha
utilizado con éxito para automatizar varias tareas de SE, por ejemplo, generación de
código [18], reparación de código [41], seguridad. corrección de errores [39].
Ingeniería inmediata.La interacción con GPT-3/Codex se realiza a través de ingeniería
rápida, donde se proporciona una descripción de la tarea como entrada (solicitud) y el
modelo (GPT-3) realiza la tarea deseada (genera texto) en consecuencia. Hay varias
formas de solicitar mensajes con los modelos GPT-3, es decir,aprendizaje de disparo
cero, de un disparo y de pocos disparos. En aprendizaje de tiro cero, se espera que el
modelo genere una respuesta sin proporcionar ningún ejemplo. De hecho, en el
mensaje no se proporciona ninguna información adicional aparte de la descripción de
la tarea. Por otro lado,un tragoyaprendizaje de pocas oportunidadesImplica dar uno
(es decir, una sola vez) o más de un ejemplo (es decir, pocas veces) en la indicación,
respectivamente. En este estudio hemos experimentado con tiro ceroyaprendizaje de
una sola vez. En el aprendizaje de disparo cero, simplemente le decimos al modelo
que genere una documentación para un código fuente determinado en el mensaje. En
el aprendizaje de una sola vez, seleccionamos aleatoriamente una muestra (es decir,
un par código-documentación) del conjunto de trenes del lenguaje correspondiente
(de CodeSearchNet), la proporcionamos en el mensaje (como ejemplo) y luego le
pedimos al modelo que genere una documentación. para otro código fuente
aprendiendo del ejemplo proporcionado de par códigodocumentación. La Figura 2
muestra el formato de solicitud única que utilizamos para la generación de
documentación.
Configuración de parámetros.Hay una serie de parámetros relacionados con
los modelos basados en GPT-3. Uno de esos parámetros esTemperaturaeso
ASE '22, del 10 al 14 de octubre de 2022, Rochester, MI, EE. UU.
Código:
def agregar(x, y):
regresar x+y
Documentación:Suma dos números.
Código:
def restar(x, y):
regresar xy
Documentación:[Para ser generado por el Codex]
Figura 2: Ejemplo de formato de mensaje para el aprendizaje de una sola vez
controla la aleatoriedad de la salida generada (rango de 0 a 1). Otro parámetro
de aleatoriedad esarriba-p(rango de 0 a 1) que controla qué tan improbables se
pueden eliminar las palabras del grupo de muestreo eligiendo entre el
conjunto (de palabras) más pequeño posible cuya probabilidad acumulada
excedapag. Según lo recomendado por la documentación oficial del Codex,
configuramos la temperatura en un valor bajo (0,2) mientras mantenemos top-
P en su valor predeterminado (1,0). También mantenemosFrecuenciay
Sanciones de presenciaen sus valores predeterminados (0.0) que controlan el
nivel de repetición de palabras en el texto generado penalizándolas en función
de su frecuencia y presencia existente. Usamos eltamaño máximo de tokens
como 256 ya que nuestro conjunto de datos formateado no contiene ningún
tamaño mayor (>256) documentación (ver Sección 3.1).
3.3 Evaluación de la documentación generada
Dado que los modelos GPT-3 actualmente están sujetos a límites de respuesta y costos,
utilizamos un tamaño de muestra estadísticamente significativo para este estudio en lugar de
utilizar conjuntos de prueba completos para diferentes idiomas. Como se muestra en la Tabla
1, el conjunto de pruebas más grande en CodeSearchNet pertenece a Python y consta de
14,918 muestras y un tamaño de muestra estadísticamente significativo sería 375 con un
intervalo de confianza del 95 % y un margen de error del 5 %. Sin embargo, seleccionamos
aleatoriamente 1000 (>375) muestras de cada conjunto de prueba (es decir, un total de 6
conjuntos de muestras de 1K para 6 idiomas) y se evaluó el modelo del Codex en ellas. Para la
evaluación, utilizamos la puntuación BLEU [36], una métrica de evaluación popular para texto
generado por máquina que calcula la similitud de n-gramas de un texto generado y de
referencia. Dado que la documentación generada a veces puede ser corta y es posible que los
ngramas de orden superior no se superpongan, utilizamos la puntuación BLEU suavizada [30]
como lo recomiendan trabajos anteriores [5, 17, 38].
3.3.1 Análisis de desempeño.La Tabla 2 compara el rendimiento de Codex
con varios modelos SOTA para la generación de documentación: Seq2Seq
[48], Transformer [54], RoBERTa [31], CodeBERT [17], PLBART
[5], CoTexT [40], REDCODER [38]. Observamos que, aunque Codex con el
aprendizaje de una sola vez no pudo lograr resultados satisfactorios
(principalmente porque no logra aprender el formato de documentación
esperado), el rendimiento mejora enormemente con el aprendizaje de una sola
vez. De hecho, Codex (con one-shot) muestra el mejor rendimiento general
entre todos los enfoques con una puntuación BLEU promedio de 20,63,
mientras que el competidor más cercano, CoTexT, logra 18,55 (mejora del
11,21%). En rendimiento específico del lenguaje, supera significativamente a
otros modelos en todos los lenguajes excepto dos, es decir, Java y PHP. En Java
y PHP, Codex logra puntuaciones BLEU de 22,81 y 25,13, ligeramente
superadas por REDCODER (22,95) y CodeBERT (25,16) respectivamente. En este
caso, REDCODER no es un modelo individual en sí mismo, más bien es un
enfoque de recuperación que se puede utilizar con otros modelos generativos
para mejorar su desempeño. En el artículo original [38], los autores utilizaron
PLBART [5] como modelo base para REDCODER donde recuperaron resúmenes
relevantes de StackOverflow, GitHub, etc. y les proporcionaron información de
PLBART para mejorar su rendimiento. Por lo tanto, tiene algunos gastos
generales adicionales (tiempo y recursos), mientras que el Codex es en sí
mismo un modelo integral. Además, el Códice
ASE '22, del 10 al 14 de octubre de 2022, Rochester, MI, EE. UU. Junaed Younus Khan y Gias Uddin

Tabla 2: Resultados en la generación de documentación (puntuación BLEU) Java ................................................. .................................... ImageIcon protegido createImageIcon
(ruta de cadena, descripción de cadena) {
java.net.URL imgURL = getClass().getResource(ruta); si
Modelo Rubí javascript IR Python Java PHP en general (imgURL! = nulo) {
devolver nuevo ImageIcon(imgURL, descripción); }
Sec2Seq [48] 9.64 10.21 13,98 15,93 15,09 21,08 14.32
demás {
Transformador [54] 11.18 11.59 16,38 15,81 16,26 22,12 15.56 System.err.println("No se pudo encontrar el archivo: " + ruta);
ROBERTA [31] 11.17 11.90 17,72 18,14 16,47 24,02 16.57 devolver nulo;
CódigoBERT [17] 12.16 14,90 18,07 19,06 17,65 25,16 17,83 }
}
PLBART [5] 14.11 15.56 18,91 19,30 18,45 23,58 18,32 Actual:Devuelve un ImageIcon, o nulo si la ruta no era válida.
CoTexto (2-CC) [40] 13.07 14.77 19,37 19,52 19,1 24,47 18,38 Códice:Devuelve un ImageIcon, o nulo si la ruta no era válida.
CoTexto (1-CC) [40] 14.02 14,96 18,86 19,73 19,06 24,58 18.55
Pitón................................................. ................................. def check_for_file(self, file_path):
CODIFICADOR ROJO [38] - - - 21.01 22,94 - N/A
REDCODER-EXT [38] - - - 20.91 22,95 - N/A intentar:
archivos = self.connection.glob (ruta_archivo, detalles = Falso,
Códice (disparo 0) 5.41 9,83 15,80 18,93 13,59 13,32 12.81
invalidate_cache=Verdadero)
Códice (1 disparo) 16.04 16,58 20,94 22,28 22,81 25,13 20.63 devolver len(archivos) == 1
excepto FileNotFoundError:
falso retorno
puede funcionar aún mejor si se utiliza con dicho enfoque de recuperación Actual:Comprobar si un archivo existe en Azure Data Lake.
Códice:Comprobar si un archivo existe en la máquina remota.
adicional (es decir, REDCODER). Por otro lado, CodeBERT y la mayoría de los
PHP................................................ .................................... función estática pública
otros modelos reportados habían sido (re)entrenados o ajustados en conjuntos base256ToDec($número) {
de datos específicos de tareas y lenguajes, mientras que Codex recibió solo
Validar::canCastAsString($número, 'número');
cero o un ejemplo en nuestra evaluación. $resultado = 0;
$base = 1;
para ($i = strlen($número) - 1; $i >= 0; $i--) {
3.3.2 Análisis Cualitativo.Como lo sugieren Schreck et al. [46], utilizamos la longitud de la documentación y el nivel de grado de $resultado = bcadd($resultado, bcmul(ord($número[$i]), $base));
$base = bcmul($base, 256);
Flesch-Kincaid [15] para medir la cantidad y legibilidad de la documentación generada. Encontramos que la puntuación Flesch- }
devolver $resultado;
Kincaid promedio de las documentaciones generadas por el Codex es 5,97 con una longitud promedio de 8 palabras (por }
Actual:Convierte un número base 256 a un número decimal.
documentación), mientras que la puntuación Flesch-Kincaid promedio de las documentaciones reales es 6,77 con una longitud
Códice:Convierte un número de base 256 a un número de base 10.
promedio de 12 palabras. Por tanto, la documentación generada se aproxima a la real en términos de cantidad y legibilidad.
Javascript ................................................. ................................. función
Analizamos además el contenido informativo de la documentación generada con respecto a la real utilizando TF-IDF. Para validarProtocolOptions(protocolOptions) {
si (! opciones de protocolo) {
calcular el TF-IDF de una documentación en particular, sumamos las puntuaciones TF-IDF de todas las palabras de la throw new TypeError('protocolOptions no definido en opciones'); }

documentación (excepto las palabras vacías). El TF-IDF promedio de la documentación generada por el Codex es 1. 94 mientras versión constante = protocoloOptions.maxVersion; if
(versión && (tipo de versión!== 'número' ||
que para la documentación real es 2,28. Por lo tanto, el contenido informativo de la documentación generada es satisfactorio en !types.protocolVersion.isSupported(versión))) {
lanzar nuevo TypeError(util.format('protocolOptions.maxVersion proporcionada (%s)
términos de TF-IDF comparativo con los reales. Mostramos algunos ejemplos de documentaciones generadas por Codex en la
no es válida', versión));
Figura 3. Vemos que en algunos casos, Codex puede generar información más comprensible o adicional en comparación con la
}
}
real. En el ejemplo de PHP mencionado en la Figura 3, Codex menciona "número base 10" en lugar de "decimal", lo cual es más Actual:Valida las opciones del protocolo.
Códice:Validar opciones de protocolo.
comprensible para los usuarios. En el ejemplo de Ruby, Codex proporciona información adicional "Si la ruta no está presente,
Rubí ................................................. ................................. def remove_file(*rutas)
aparece un noop". es interpretado." lo cual es correcto pero no estaba presente en la documentación real. Mostramos algunos
ruta = File.join(*paths) log.debug(log_key)
ejemplos de documentaciones generadas por Codex en la Figura 3. Vemos que en algunos casos, Codex puede generar { "Eliminando archivo {ruta}'" } FileUtils .rm_f(ruta)
información más comprensible o adicional en comparación con la real. En el ejemplo de PHP mencionado en la Figura 3, Codex
camino

menciona "número base 10" en lugar de "decimal", lo cual es más comprensible para los usuarios. En el ejemplo de Ruby, Codex fin
Actual:Elimine el archivo en la ruta indicada.
proporciona información adicional "Si la ruta no está presente, aparece un noop". es interpretado." lo cual es correcto pero no Códice:Elimina el archivo ubicado en la ruta indicada. Si la ruta no está presente,
se realiza un noop.
estaba presente en la documentación real. Mostramos algunos ejemplos de documentaciones generadas por Codex en la Figura
IR................................................. ......................................... func (os *orderedSet) append(s string)
3. Vemos que en algunos casos, Codex puede generar información más comprensible o adicional en comparación con la real. En { if _, ok := os.included[s]; !ok { os.lista = agregar(os.lista, s)
el ejemplo de PHP mencionado en la Figura 3, Codex menciona "número base 10" en lugar de "decimal", lo cual es más

comprensible para los usuarios. En el ejemplo de Ruby, Codex proporciona información adicional "Si la ruta no está presente,
os.incluido[s] = estructura{}{}
}
aparece un noop". es interpretado." lo cual es correcto pero no estaba presente en la documentación real. }
Actual:append agrega s al final de os, solo si aún no está incluido.
Códice:append agrega s al conjunto ordenado si aún no está presente.

Figura 3: Ejemplos de documentación del Codex (1-shot)

4 CONCLUSIÓN Y TRABAJO FUTURO
Ampliará la investigación analizando también el aprendizaje de pocas oportunidades.
Exploramos el Codex GPT-3 para la generación automática de documentación y
En tercer lugar, elegimos aleatoriamente una muestra del conjunto de trenes
comparamos su rendimiento con los enfoques existentes. Mientras que los enfoques
correspondiente para usarla en el aprendizaje único. Sin embargo, el uso de
anteriores están sujetos a reentrenamiento o ajuste específico de la tarea/idioma,
diferentes muestras en el aprendizaje de una sola vez podría producir resultados
Codex muestra el rendimiento de SOTA incluso con configuraciones muy básicas. En
diferentes que no se han explorado. En cuarto lugar, al igual que otros modelos de
el futuro, tenemos la intención de investigar el Codex más en profundidad en
transformadores previamente entrenados, GPT-3 también admite ajustes. Sin
términos de ajuste de parámetros, aprendizaje de pocas tomas y ajuste fino para
embargo, las últimas versiones de los modelos GPT-3 (por ejemplo, text-davinci,
mejorar aún más su rendimiento. También planeamos emplear Codex para solucionar
Codex) no están disponibles para realizar ajustes. Podríamos ajustar GPT-3 cuando
problemas de documentación (por ejemplo, olores de documentos) que encontramos
esté disponible para hacerlo. Finalmente, en este estudio no se ha realizado una
en nuestro estudio anterior [29]. En particular, este estudio tiene una serie de
investigación sistemática del efecto de diferentes parámetros asociados con GPT-3.
limitaciones que queremos abordar en el futuro. Primero, utilizamos muestras de 1K
Elegimos los valores de los parámetros según la documentación oficial.
para cada idioma para evaluar la documentación generada por Codex. Aunque el
Reconocimiento.Este trabajo fue financiado por el Consejo de Investigación de
tamaño de la muestra es estadísticamente significativo, tenemos la intención de
Ingeniería y Ciencias Naturales de Canadá, la Universidad de Calgary, Alberta
probar el Codex en más muestras en el futuro. Segundo, Limitamos nuestra
Innovates y la Beca de Excelencia para Graduados de Alberta.
investigación sólo al aprendizaje cero y de una sola vez. Nosotros
Generación automática de documentación de código mediante GPT-3
REFERENCIAS
[1] Nahla J Abid, Natalia Dragan, Michael L Collard y Jonathan I Maletic. 2015. Uso de
estereotipos en la generación automática de resúmenes en lenguaje natural para
métodos c++. EnConferencia internacional IEEE 2015 sobre mantenimiento y evolución
del software (ICSME). IEEE, 561–565.
[2] Emad Aghajani, Csaba Nagy, Mario Linares-Vásquez, Laura Moreno, Gabriele Bavota,
Michele Lanza y David C. Shepherd. 2020. Documentación de software: la perspectiva
de los profesionales. En42a Conferencia Internacional sobre Ingeniería de Software. 12.
[3] Emad Aghajani, Csaba Nagy, Olga Lucero Vega-Márquez, Mario Linares-Vásquez, Laura
Moreno, Gabriele Bavota y Michele Lanza. 2019. Se revelan problemas con la
documentación del software. En41a Conferencia Internacional sobre Ingeniería de
Software. 1199-1210.
[4] Wasi Uddin Ahmad, Saikat Chakraborty, Baishakhi Ray y Kai-Wei Chang. 2020. Un
enfoque basado en transformadores para el resumen de código fuente.preimpresión
de arXiv arXiv:2005.00653(2020).
[5] Wasi Uddin Ahmad, Saikat Chakraborty, Baishakhi Ray y Kai-Wei Chang. 2021.
Preformación unificada para la comprensión y generación de programas.preimpresión
de arXiv arXiv:2103.06333(2021).
[6] Miltiadis Allamanis, Hao Peng y Charles Sutton. 2016. Una red de atención convolucional
para un resumen extremo del código fuente. EnConferencia internacional sobre
aprendizaje automático. PMLR, 2091-2100.
[7] Antonio Valerio Miceli Barone y Rico Sennrich. 2017. Un corpus paralelo de funciones de
Python y cadenas de documentación para la documentación y generación de código
automatizadas.preimpresión de arXiv arXiv:1707.02275(2017).
[8] Tom Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared D Kaplan, Prafulla Dhariwal,
Arvind Neelakantan, Pranav Shyam, Girish Sastry, Amanda Askell, et al. 2020. Los modelos
lingüísticos aprenden con pocas posibilidades.Avances en los sistemas de procesamiento de
información neuronal.33 (2020), 1877–1901.
[9] Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde de Oliveira Pinto,
Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, et al. 2021.
Evaluación de modelos de lenguaje grandes entrenados en código.preimpresión de
arXiv arXiv:2107.03374(2021).
[10] Qingying Chen y Minghui Zhou. 2018. Un marco neuronal para la recuperación y
resumen de código fuente. En2018 33a Conferencia Internacional IEEE/ACM sobre
Ingeniería de Software Automatizada (ASE). IEEE, 826–831.
[11] Bharath Chintagunta, Namit Katariya, Xavier Amatriain y Anitha Kannan. 2021. GPT-3 con
conciencia médica como generador de datos para resumir diálogos médicos. En
Conferencia sobre aprendizaje automático para la atención sanitaria. PMLR, 354–372.
[12] Ke-Li Chiu y Rohan Alexander. 2021. Detección de discursos de odio con gpt-3.preimpresión de
arXiv arXiv:2103.12407(2021).
[13] Robert Dale. 2021. GPT-3: ¿Para qué sirve?Ingeniería del lenguaje natural27, 1
(2021), 113–118.
[14] Sergio Cozzetti B. de Souza, Nicolas Anquetil y Káthia M. de Oliveira. 2005. Un estudio de
la documentación esencial para el mantenimiento del software. En23a conferencia
internacional anual sobre Diseño de comunicación: documentación y diseño para
información omnipresente. 68–75.
[15] William H. DuBay. 2004. Los principios de legibilidad.Envío en línea(2004).
[16] Brian P Eddy, Jeffrey A Robinson, Nicholas A Kraft y Jeffrey C Carver. 2013.
Evaluación de técnicas de resumen de código fuente: replicación y expansión.
En2013 XXI Conferencia Internacional sobre Comprensión de Programas (CIPC). IEEE,
13-22.
[17] Zhangyin Feng, Daya Guo, Duyu Tang, Nan Duan, Xiaocheng Feng, Ming Gong, Linjun Shou, Bing
Qin, Ting Liu, Daxin Jiang, et al. 2020. Codebert: un modelo previamente entrenado para
programación y lenguajes naturales.preimpresión de arXiv arXiv:2002.08155 (2020).
[18] James Finnie-Ansley, Paul Denny, Brett A Becker, Andrew Luxton-Reilly y James Prather.
2022. Los robots están llegando: explorando las implicaciones del Codex OpenAI en la
programación introductoria. EnConferencia de educación informática de Australasia.
10-19.
[19] Luciano Floridi y Massimo Chiriatti. 2020. GPT-3: Su naturaleza, alcance, límites y
consecuencias.Mentes y máquinas30, 4 (2020), 681–694.
[20] Shuzheng Gao, Cuiyun Gao, Yulan He, Jichuan Zeng, Lun Yiu Nie y Xin Xia. 2021.
Transformador guiado por estructura de código para resumen de código fuente.
preimpresión de arXiv arXiv:2104.09340(2021).
[21] Sonia Haiduc, Jairo Aponte y Andrian Marcus. 2010. Apoyo a la comprensión del
programa con resumen del código fuente. En2010 acm/ieee 32ª conferencia
internacional sobre ingeniería de software, vol. 2.IEEE, 223–226.
[22] Sonia Haiduc, Jairo Aponte, Laura Moreno y Andrian Marcus. 2010. Sobre el uso
de técnicas automatizadas de resumen de texto para resumir el código fuente.
En2010 17ª Jornada de Trabajo sobre Ingeniería Inversa. IEEE, 35–44.
[23] Xing Hu, Ge Li, Xin Xia, David Lo y Zhi Jin. 2018. Generación de comentarios de código profundo. En
2018 IEEE/ACM 26.ª Conferencia Internacional sobre Comprensión de Programas (ICPC). IEEE,
200–20010.
[24] Xing Hu, Ge Li, Xin Xia, David Lo y Zhi Jin. 2020. Generación de comentarios de
código profundo con información léxica y sintáctica híbrida.Ingeniería de
software empírica25, 3 (2020), 2179–2217.
ASE '22, del 10 al 14 de octubre de 2022, Rochester, MI, EE. UU.
[25] Hamel Husain, Ho-Hsiang Wu, Tiferet Gazit, Miltiadis Allamanis y Marc Brockschmidt.
2019. Desafío Codesearchnet: Evaluación del estado de la búsqueda de código
semántico.preimpresión de arXiv arXiv:1909.09436(2019).
[26] Walid M Ibrahim, Nicolas Bettenburg, Bram Adams y Ahmed E Hassan. 2012. Sobre la
relación entre las prácticas de actualización de comentarios y los errores de software.
Revista de sistemas y software85, 10 (2012), 2293–2304.
[27] Srinivasan Iyer, Ioannis Konstas, Alvin Cheung y Luke Zettlemoyer. 2016. Resumiendo el
código fuente utilizando un modelo de atención neuronal. EnActas de la 54ª Reunión
Anual de la Asociación de Lingüística Computacional (Volumen 1: Artículos extensos).
2073–2083.
[28] Ilya Jackson y María Jesús Sáenz. 2022. Del lenguaje natural a las simulaciones: aplicación del
códice GPT-3 para automatizar el modelado de simulación de sistemas logísticos. preimpresión
de arXiv arXiv:2202.12107(2022).
[29] Junaed Younus Khan, Md Tawkat Islam Khondaker, Gias Uddin y Anindya Iqbal. 2021.
Detección automática de cinco olores de documentación de API: perspectivas de los
profesionales. EnConferencia internacional IEEE 2021 sobre análisis, evolución y
reingeniería de software (SANER). IEEE, 318–329.
[30] Chin-Yew Lin y Franz Josef Och. 2004. Naranja: un método para evaluar métricas de
evaluación automática para traducción automática. EnCOLING 2004: Actas de la XX
Conferencia Internacional sobre Lingüística Computacional. 501–507.
[31] Yinhan Liu, Myle Ott, Naman Goyal, Jingfei Du, Mandar Joshi, Danqi Chen, Omer Levy,
Mike Lewis, Luke Zettlemoyer y Veselin Stoyanov. 2019. Roberta: Un enfoque de
preentrenamiento de bert sólidamente optimizado.preimpresión de arXiv
arXiv:1907.11692 (2019).
[32] Shuai Lu, Daya Guo, Shuo Ren, Junjie Huang, Alexey Svyatkovskiy, Ambrosio Blanco, Colin
Clement, Dawn Drain, Daxin Jiang, Duyu Tang, et al. 2021. Codexglue: un conjunto de
datos de referencia de aprendizaje automático para la comprensión y generación de
código.preimpresión de arXiv arXiv:2102.04664(2021).
[33] Paul W McBurney, Siyuan Jiang, Marouane Kessentini, Nicholas A Kraft, Ameer
Armaly, Mohamed Wiem Mkaouer y Collin McMillan. 2017. Hacia priorizar el
esfuerzo de documentación.Transacciones IEEE sobre ingeniería de software44,
9 (2017), 897–913.
[34] Paul W. McBurney y Collin McMillan. 2014. Generación automática de documentación
mediante resumen del código fuente del contexto del método. EnActas de la 22ª
Conferencia Internacional sobre Comprensión de Programas. 279–290.
[35] Laura Moreno, Jairo Aponte, Giriprasad Sridhara, Andrian Marcus, Lori Pollock y K Vijay-
Shanker. 2013. Generación automática de resúmenes en lenguaje natural para clases
de java. En2013 XXI Conferencia Internacional sobre Comprensión de Programas (CIPC)
. IEEE, 23–32.
[36] Kishore Papineni, Salim Roukos, Todd Ward y Wei-Jing Zhu. 2002. Bleu: un
método para la evaluación automática de la traducción automática. EnActas de
la 40.ª reunión anual de la Asociación de Lingüística Computacional. 311–318.
[37] David Lorge Parnas. 2011. Documentación precisa: la clave para un mejor software. En El
futuro de la ingeniería de software. Saltador, 125-148.
[38] Md Rizwan Parvez, Wasi Uddin Ahmad, Saikat Chakraborty, Baishakhi Ray y Kai-Wei
Chang. 2021. Recuperación, generación y resumen de código aumentado. preimpresión
de arXiv arXiv:2108.11601(2021).
[39] Hammond Pearce, Benjamin Tan, Baleegh Ahmad, Ramesh Karri y Brendan Dolan-Gavitt.
2021. ¿Pueden ayudar OpenAI Codex y otros modelos de lenguajes grandes?
¿Nosotros solucionamos errores de seguridad?preimpresión de arXiv arXiv:2112.02125(2021).
[40] Long Phan, Hieu Tran, Daniel Le, Hieu Nguyen, James Anibal, Alec Peltekian y Yanfang Ye.
2021. Cotext: aprendizaje multitarea con transformador de código-texto. preimpresión
de arXiv arXiv:2105.08645(2021).
[41] Julian Aron Prenner y Romain Robbes. 2021. Reparación automática de programas con el Codex
de OpenAI: evaluación de QuixBugs.preimpresión de arXiv arXiv:2111.03922(2021).
[42] Sawan Rai, Ramesh Chandra Belwal y Atul Gupta. 2022. Una revisión de la
documentación del código fuente.Transacciones ACM sobre sistemas y tecnología
inteligentes (TIST)(2022).
[43] Sawan Rai, Tejaswini Gaikwad, Sparshi Jain y Atul Gupta. 2017. Resumen de texto a nivel
de método para código Java utilizando nanopatrones. En2017 24a Conferencia de
Ingeniería de Software de Asia y el Pacífico (APSEC). IEEE, 199–208.
[44] Sarah Rastkar, Gail C Murphy y Alexander WJ Bradley. 2011. Generación de resúmenes en lenguaje
natural para inquietudes transversales sobre el código fuente. En2011 27a Conferencia
Internacional IEEE sobre Mantenimiento de Software (ICSM). IEEE, 103–112.
[45] Martín P. Robillard. 2009. ¿Qué hace que las API sean difíciles de aprender? Respuestas de los
desarrolladores.Software IEEE26, 6 (2009), 26–34.
[46] Daniel Schreck, Valentin Dallmeier y Thomas Zimmermann. 2007. Cómo evoluciona la
documentación con el tiempo. EnNoveno taller internacional sobre Principios de la
evolución del software: en conjunto con la 6ª reunión conjunta ESEC/FSE. 4–10.
[47] Giriprasad Sridhara, Emily Hill, Divya Muppaneni, Lori Pollock y K Vijay-Shanker.
2010. Hacia la generación automática de comentarios resumidos para métodos
java. EnActas de la conferencia internacional IEEE/ACM sobre ingeniería de
software automatizada. 43–52.
[48] Ilya Sutskever, Oriol Vinyals y Quoc V Le. 2014. Aprendizaje secuencia a secuencia con redes
neuronales.Avances en los sistemas de procesamiento de información neuronal.27 (2014).
[49] Gias Uddin, Omar Alam y Alexander Serebrenik. 2022. Un estudio cualitativo de las discusiones de
los desarrolladores sobre sus problemas y alegrías durante los inicios del COVID-19.
ASE '22, del 10 al 14 de octubre de 2022, Rochester, MI, EE. UU.
meses.Ingeniería de software empírica27, 5 (2022), 1–52.
Temporal
[50] Gias Uddin, Barthélémy Dagenais y Martin P. Robillard. 2012. Análisis de conceptos de
uso de API. EnProc. 34° Internacional IEEE/ACM Conf. en Ingeniería de Software. 804–
814.
[51] Gias Uddin, Foutse Khomh y Chanchal K Roy. 2021. Documentación automática de escenarios de
uso de API de sitios técnicos de preguntas y respuestas.Transacciones ACM sobre Ingeniería y
Metodología de Software30, 3 (2021), 1–45.
[52] Gias Uddin y Martín P. Robillard. 2015. Cómo falla la documentación API.Software
IEEE32, 4 (2015), 76–83.
[53] Carmine Vassallo, Sebastiano Panichella, Massimiliano Di Penta y Gerardo Canfora. 2014.
Códigos: descripciones del código fuente de minería de discusiones de desarrolladores.
EnActas de la 22ª Conferencia Internacional sobre Comprensión de Programas. 106–
109.
[54] Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N
Gomez, Łukasz Kaiser e Illia Polosukhin. 2017. Atención es todo lo que necesitas.
Avances en los sistemas de procesamiento de información neuronal.30 (2017).
Junaed Younus Khan y Gias Uddin
[55] Yao Wan, Zhou Zhao, Min Yang, Guandong Xu, Haochao Ying, Jian Wu y Philip S Yu. 2018.
Mejora del resumen automático del código fuente mediante el aprendizaje por refuerzo
profundo. EnActas de la 33ª Conferencia Internacional ACM/IEEE sobre Ingeniería de
Software Automatizada. 397–407.
[56] Ruyun Wang, Hanwen Zhang, Guoliang Lu, Lei Lyu y Chen Lyu. 2020. Traste:
Transformador funcional reforzado con bert para resumen de código.Acceso
IEEE 8 (2020), 135591–135604.
[57] Edmund Wong, Taiyue Liu y Lin Tan. 2015. Clocom: extracción de código fuente existente
para la generación automática de comentarios. En22a Conferencia Internacional IEEE
2015 sobre Análisis, Evolución y Reingeniería de Software (SANER). IEEE, 380–389.
[58] Edmund Wong, Jinqiu Yang y Lin Tan. 2013. Autocomment: minería de sitios de
preguntas y respuestas para la generación automática de comentarios. En2013 28a
Conferencia Internacional IEEE/ACM sobre Ingeniería de Software Automatizada (ASE).
IEEE, 562–567.
[59] Xin Xia, Lingfeng Bao, David Lo, Zhenchang Xing, Ahmed E Hassan y Shanping Li. 2017.
Medición de la comprensión del programa: un estudio de campo a gran escala con
profesionales.Transacciones IEEE sobre ingeniería de software44, 10 (2017), 951–976.