AlphaCodium: a la vanguardia de la generación de código, de la ingeniería de sugerencias a la ingeniería de procesos

Original: [Generación de código de última generación con AlphaCodium: de la ingeniería de instrucciones a la ingeniería de flujo]

Por Tal Ridnik

 

 

 

hojear

 

Los retos de la generación de código son distintos de los del procesamiento ordinario del lenguaje natural: implican seguir estrictamente las reglas sintácticas del lenguaje de programación de destino, identificar casos normales y límite, prestar atención a numerosos detalles en la especificación del problema y hacer frente a otros problemas y requisitos específicos del código. En consecuencia, muchas de las técnicas de optimización utilizadas habitualmente en el campo de la generación de lenguaje natural pueden no ser aplicables a las tareas de generación de código.

 

En este estudio, proponemos un novedoso método de generación de código denominado AlfaCodio -- Un proceso de tratamiento iterativo basado en pruebas, por fases y centrado en el código. Este enfoque mejora significativamente la capacidad del Modelo de Lenguaje Grande (LLM) para tratar los problemas de código.

 

Hemos probado AlphaCodium en un desafiante conjunto de datos de generación de código, CodeContests, que contiene temas de programación de competición de plataformas como Codeforces. Nuestro enfoque consigue de forma consistente importantes mejoras de rendimiento en estas pruebas.

 

Por ejemplo, en el conjunto de datos de validación, la precisión (pass@5) de GPT-4 mejoró de 19% a 44% con una sola pista directa bien diseñada después de utilizar el proceso AlphaCodium. AlphaCodium.

 

Creemos que muchos de los principios y buenas prácticas desarrollados en este trabajo son aplicables en general a una amplia variedad de tareas de generación de código. Nuestro último proyecto de código abierto [AlfaCodioNuestra solución AlphaCodium para CodeContests se comparte en ], con la evaluación completa del conjunto de datos y los scripts de evaluación comparativa para su posterior investigación y exploración por parte de la comunidad.

 

 

Análisis del conjunto de datos de CodeContests

 

[CodeContests] es un desafiante conjunto de datos de programación de Google Deepmind. Se basa en datos como [CodeforcesUna plataforma de programación de concursos como ] cuenta con una selección de unos 10.000 temas de programación diseñados para entrenar y evaluar grandes modelos lingüísticos (como GPT o DeepSeek) Capacidad para resolver problemas complejos de programación.

 

Este estudio no se centra en el desarrollo de un modelo completamente nuevo, sino en la creación de un proceso de programación que sea aplicable a una variedad de grandes modelos lingüísticos que ya son capaces de gestionar tareas de codificación. Por lo tanto, nos centramos en los conjuntos de validación y prueba de CodeContests, que constan de 107 y 165 problemas de programación. La figura 1 muestra un ejemplo de un problema típico del conjunto de datos:

 

 

Cada problema incluye una descripción del problema y algunos datos de prueba disponibles públicamente que pueden utilizarse directamente como entrada del modelo. El reto consiste en escribir un procedimiento que dé la respuesta correcta para cualquier entrada legítima. Además, hay un conjunto de pruebas, que no está disponible públicamente, que se utiliza para evaluar la corrección del programa presentado.

 

¿Por qué los CodeContests son un conjunto de datos ideal para poner a prueba la capacidad de programación de grandes modelos lingüísticos? En primer lugar, a diferencia de otros conjuntos de datos de concursos de programación, CodeContests contiene una gran cantidad de datos de prueba privados (unos 200 casos de prueba por problema) para garantizar la precisión de la evaluación. En segundo lugar, los grandes modelos lingüísticos no suelen ser muy buenos a la hora de detectar detalles en las descripciones de los problemas, que a menudo son fundamentales para encontrar la solución correcta. Este diseño simula la complejidad de los problemas del mundo real, obligando al modelo a tener en cuenta múltiples factores, lo que contrasta con algunos de los conjuntos de datos más simples y directos (por ejemplo, [HumanEval]) contrasta fuertemente. En el Apéndice 1 se ilustra un problema de programación típico de HumanEval.

 

La figura 2 ilustra cómo el modelo analiza en profundidad el problema de la figura 1. Al analizar el problema en profundidad, el problema se vuelve más claro y estructurado, lo que pone de relieve la importancia de tener un conocimiento más profundo del problema durante el proceso de programación.

 

 

 

Metodología propuesta

 

A la hora de afrontar los complejos retos que plantea la generación de código, hemos comprobado que ni la optimización con una sola instrucción ni las instrucciones de pensamiento continuo han mejorado significativamente la eficacia en la resolución de problemas de los modelos de grandes lenguajes (LLM) en CodeContest. Esto se debe a que los modelos a menudo tienen dificultades para comprender completamente el problema y, por lo tanto, producen repetidamente código incorrecto o incapaz de hacer frente a nuevos casos de prueba. Los enfoques aplicables al procesamiento general del lenguaje natural pueden no ser ideales para las tareas de generación de código. Tales tareas esconden un gran potencial, como ejecutar repetidamente el código generado y verificarlo frente a ejemplos conocidos. En contraste con las técnicas de optimización de pistas en el procesamiento habitual del lenguaje natural, descubrimos que la resolución del problema CodeContest mediante la generación de código y la comprobación específica para elflujos de trabajomás eficaz. El proceso gira en torno aiteración (matem.)El proceso se desarrolla, es decir, ejecutamos y ajustamos continuamente el código generado para que supere las pruebas de entrada-salida. Los dos aspectos clave de este proceso específico del código son:

(a) generar datos adicionales en la fase de preprocesamiento, por ejemplo, autorreflexión y razonamiento para casos de prueba abiertos, para apoyar el proceso iterativo, y (b) aumentar los casos de prueba abiertos con casos de prueba adicionales generados por la IA. En la Fig. 3 mostramos el proceso que hemos diseñado para resolver el problema de la programación de carreras:

 

 

 

El proceso de la figura 3 se divide en dos etapas principales:

• preprocesamiento etapa, razonamos sobre el problema utilizando el lenguaje natural, que es un proceso lineal.
• Iteración del código fase, que incluye múltiples sesiones iterativas en las que generamos, ejecutamos y corregimos código para diversas pruebas.

 

En el Cuadro 1, repasamos detalladamente estas diferentes etapas:

Nombre de la etapa	declaración de objetivos
Reflexión sobre el problema	Resuma el problema en forma de viñetas concisas que incluyan los objetivos, las entradas, las salidas, las reglas, las limitaciones y otros detalles importantes del problema.
Análisis lógico de los casos de prueba abiertos	Describa cómo las entradas de cada caso de prueba conducen a una salida determinada.
Conceptualización de posibles soluciones	Proponga 2 ó 3 soluciones posibles y descríbalas en términos sencillos.
Evaluación de soluciones	Evalúe las distintas soluciones posibles y seleccione la mejor, teniendo en cuenta su corrección, sencillez y robustez. (No es necesario limitarse a la opción más eficiente).
Pruebas suplementarias de IA	Complemente el problema con 6-8 tipos diferentes de pruebas de entrada-salida que intenten cubrir situaciones y aspectos no contemplados en los casos de prueba abiertos originales.
Programa inicial de códigos	El objetivo de esta fase es formar un código inicial de solución al problema. Es importante que este código se acerque lo más posible a la respuesta correcta, para que tenga más probabilidades de éxito en el proceso de corrección que sigue. El proceso de funcionamiento es el siguiente: - Seleccione un escenario posible, escriba el código adecuado para él y pruébelo en casos de prueba públicos seleccionados y pruebas de IA. - Repita este proceso hasta que se supere la prueba o se alcance el número máximo de intentos. - El primer código que supere la prueba, o el código cuya salida se acerque más a la respuesta correcta, se utilizará como código base para los pasos siguientes.
Optimización iterativa de los casos de prueba abiertos	Toma el código base como punto de partida, ejecútalo uno a uno en casos de prueba abiertos y optimízalo. Si el código tiene algún problema en una de las pruebas, intenta solucionarlo basándote en el mensaje de error.
Optimización iterativa para pruebas de IA	Continuar la optimización iterativa en las pruebas generadas por IA. Aplicar "anclajes de prueba" (una técnica para fijar elementos específicos en las pruebas con el fin de depurar y mejorar el código con mayor precisión).

 

Cuadro 1. Caracterización de las fases AlfaCodium.

 

Al explorar el proceso propuesto, adquirimos una profunda intuición y perspicacia.

en primer lugarconocimiento acumuladoetapas del proceso: empezaremos con tareas sencillas y gradualmente nos enfrentaremos a problemas más complejos. Por ejemplo, en la primera etapa del proceso, _Auto-reflexión_, aprendemos conocimientos que podemos utilizar en etapas posteriores más difíciles, como por ejemploGenerar posibles soluciones. La fase de preprocesamiento del proceso produce resultados que alimentan la parte más difícil y crítica del proceso: la iteración del código, en la que realmente intentamos escribir código que resuelva el problema correctamente.

 

Siguiente.Generar pruebas de IA adicionales es más fácil que generar un conjunto completo de código de solución -- Este proceso se basa en gran medida en la comprensión del problema y en la resolución básica por fuerza bruta o razonamiento lógico sin tener que resolver completamente el problema para generar pares de prueba de entrada-salida útiles. Esto es diferente de escribir un código de solución completo y correcto, que requiere que ideemos una solución algorítmica completa que pueda responder correctamente a cualquier par de pruebas de entrada-salida. Como resultado, podemos crear más pruebas de IA y utilizarlas para optimizar la fase de creación del código, como se muestra en la figura 4. También mejoramos la eficacia de estas pruebas adicionales pidiendo al modelo que se centre en lo que no cubren los casos de prueba públicos originales, como el manejo de entradas grandes, casos límite, etc.

 

Por fin.Se pueden combinar varios pasos en una única llamada a un modelo lingüístico amplio (LLM). -- El proceso que se muestra en la Figura 3 es una demostración conceptual en la que se destacan las principales etapas del proceso. En la práctica, mediante la estructuración de la salida (véase la sección siguiente), podemos combinar varias etapas en una única gran llamada al modelo lingüístico para conservar recursos o mejorar el rendimiento del modelo cuando se ocupa de tareas específicas al mismo tiempo.

 

 

Los modelos suelen tener dificultades cuando resuelven problemas de código basándose únicamente en pistas directas. La iteración sobre casos de prueba públicos estabiliza y mejora la solución, pero deja "puntos ciegos" porque los casos de prueba públicos no son lo suficientemente completos. Cuando utilizamos el proceso completo de AlphaCodium, incluida la fase de preprocesamiento y la iteración sobre pruebas públicas y generadas por la IA, podemos mejorar aún más la calidad de la solución y aumentar significativamente la tasa de éxito en la resolución de problemas.

 

 

Conceptos de diseño para el código

 

En esta sección presentamos algunos conceptos de diseño, técnicas y buenas prácticas que hemos encontrado útiles a la hora de resolver problemas de generación de código. El proceso AlphaCodium que presentamos en la Figura 3 utiliza ampliamente estos conceptos de diseño:

Salida estructurada YAML: Una parte clave del proceso que proponemos es el uso de resultados estructurados, que exigen que el modelo genere un resultado con formato YAML equivalente a una clase Pydantic específica. Un ejemplo:

...

Tu objetivo es proponer posibles soluciones.

Garantizar que en cada programa se tengan plenamente en cuenta los objetivos, las normas y las limitaciones del problema.

La salida será un objeto YAML correspondiente al tipo $PossibleSolutions, de acuerdo con la siguiente definición Pydantic:

clase Solución(ModeloBase).

nombre: str = Campo(descripción="Nombre de la solución")

contenido: str = Campo(descripción=Descripción de la solución")

why_it_works: str = Field(description="Por qué funciona esta solución. Debe detallarse específicamente para las reglas y objetivos del problema.")

complejidad: str = Field(description="La complejidad de la solución")

clase PosiblesSoluciones(ModeloBase).

possible_solutions: List[Solution] = Field(max_items=3, description="Una lista de posibles soluciones al problema. Asegúrese de que cada solución tiene plenamente en cuenta las normas y objetivos del problema y tiene un tiempo de ejecución razonable en un ordenador moderno - no más de tres segundos para las restricciones del problema con un gran número de entradas.")

Tabla 2. Ejemplos de mensajes de salida estructurados (fase de generación de posibles soluciones).

Los resultados estructurados reducen la complejidad de la "ingeniería de pistas" y la necesidad de pirateo informático, y en su lugar presentan tareas complejas de forma sencilla, similar a un código. También permite obtener respuestas complejas que contienen múltiples etapas, reflejo de procesos de pensamiento lógicos y organizados.

Aunque la nueva versión de GPT soporta [Estilo JSON], pero creemos que, especialmente en tareas de generación de código, la salida YAML es más apropiada, como se detalla en el apéndice.

 

Análisis de viñetas - Cuando se pide a un Modelo de Lenguaje Extenso (LLM) que analice un problema, suelen obtenerse mejores resultados si se le pide el resultado en formato de viñetas. Las viñetas promueven una comprensión más profunda del problema y obligan al modelo a dividir la salida en regiones semánticas lógicas, mejorando así la calidad de los resultados. Por ejemplo, en el caso del problema de autorreflexión en viñetas (véase la Figura 2), cada viñeta representa una comprensión semántica de una parte diferente del problema: descripción general, objetivos y reglas, estructura de entrada y estructura de salida.

 

Los grandes modelos lingüísticos generan mejor código modular - Cuando dejamos que el Modelo de Lenguaje Grande (LLM) se ponga a escribir un largo bloque de funciones individuales, a menudo nos encontramos con problemas: suele haber errores o agujeros lógicos en el código. Peor aún, esos trozos de código tan grandes y monolíticos pueden interferir con las iteraciones posteriores para solucionarlos. Incluso cuando se proporciona información sobre errores, es difícil que el modelo localice y solucione el problema. Sin embargo, si ordenamos explícitamente al modelo "_Dividir el código generado en múltiples pequeños módulos subfuncionales y darles nombres significativos_", los resultados serán mucho mejores, con menos errores en el código generado y una mayor tasa de éxito en la fase de reparación iterativa.

 

La importancia de la flexibilidad en la toma de decisiones y la doble validación - Los grandes modelos lingüísticos suelen tener dificultades con las tareas de codificación que requieren inferencias reflexivas y racionales y la capacidad de tomar decisiones serias y no rutinarias. Por ejemplo, al generar pruebas adicionales para un problema, las pruebas generadas por el modelo suelen contener errores. Para resolver este problema, introducimos el proceso de doble validación. En este proceso, tras generar la salida inicial, se pide al modelo que genere de nuevo la misma salida y la corrija si es necesario. Por ejemplo, tras recibir como entrada sus propias pruebas de IA generadas, el modelo debe regenerar estas pruebas y corregir a tiempo los errores que contengan (si los hay). Hemos comprobado que este doble paso de validación no sólo motiva al modelo a pensar y razonar de forma crítica, sino que también es más eficaz que formular preguntas directas del tipo "¿Es correcta esta prueba?" como las preguntas sí/no.

 

Retrasar la toma de decisiones, evitar preguntas directas, dar espacio para la exploración - Cuando formulamos preguntas complejas directamente al modelo, a menudo obtenemos respuestas erróneas o poco realistas. Por eso adoptamos un enfoque similar al que Karpathy describe en el tuit que aparece a continuación, acumulando datos de forma incremental y pasando gradualmente de tareas sencillas a complejas:

• Empezando por las tareas más sencillas, es decir, la autorreflexión sobre el problema y el razonamiento sobre los casos de prueba abiertos.
• A continuación, pasa a generar pruebas de IA adicionales y posibles soluciones al problema.
• Sólo después de obtener las respuestas del modelo a las tareas anteriores pasamos al proceso iterativo real de generación de código y ejecución de correcciones.

 

 

Otro ejemplo: en lugar de elegir una única solución algorítmica, evaluamos y clasificamos múltiples soluciones posibles, dando prioridad a las mejor valoradas para la escritura inicial del código. Dado que los modelos pueden salir mal, preferimos evitar tomar decisiones irreversibles y dejar espacio para la exploración y las iteraciones de código que prueben distintas soluciones posibles.

 

Pruebas de la tecnología de anclaje - A pesar de haber sido validadas dos veces, algunas pruebas generadas por IA pueden seguir siendo erróneas. Esto plantea un problema: cuando una prueba falla, ¿cómo podemos saber si se trata de un problema con el código o de un error en la propia prueba? Cuando se pregunta directamente al modelo "qué es lo que falla", a menudo se obtienen respuestas poco realistas, que a veces conducen a una modificación incorrecta del código. Para hacer frente a este reto, introdujimos un enfoque denominado "anclas de prueba":

• Primero se itera con las pruebas que están a disposición del público y se sabe que son correctas. Una vez completado este paso, todas las pruebas superadas se designan como pruebas de referencia (pruebas de anclaje).
• A continuación, empiece a comprobar una a una las pruebas generadas por la IA.
• Los que superan la prueba se añaden a la lista de pruebas de anclaje.
• Si la prueba falla, por defecto se considera que el código es incorrecto y se intenta corregirlo. Es importante destacar que el código corregido también debe superar todas las pruebas de anclaje existentes.

 

De este modo, las pruebas de anclaje actúan como una protección contra la corrección incorrecta de nuestro código a medida que lo corregimos. Además, otra mejora para las pruebas de puntos de anclaje consiste en clasificar las pruebas generadas por la IA por orden de dificultad. De este modo, las pruebas de anclaje están disponibles más fácilmente al principio del proceso iterativo, y proporcionan salvaguardas adicionales cuando se trata de pruebas de IA más complejas, especialmente cuando se trata de pruebas de IA que tienen más probabilidades de obtener resultados incorrectos. Esta estrategia mejora la estabilidad y fiabilidad del proceso de pruebas, sobre todo cuando se trata de pruebas complejas y exigentes generadas por IA.

 

 

al final

 

Comparación de las puntas directas con AlphaCodium

En la Figura 5, comparamos los resultados de AlphaCodium con los de un único método de sugerencia directa bien diseñado. El criterio de evaluación es pass@k (tasa de éxito en la resolución del problema), es decir, la proporción de soluciones generadas utilizando k para cada problema.

 

 

Se puede observar que el enfoque AlphaCodium mejora de forma significativa y consistente el rendimiento de los Large Language Models (LLMs) en la resolución de problemas de programación con CodeContests. Esta conclusión se aplica tanto a modelos de código abierto (por ejemplo, DeepSeek) como a modelos de código cerrado (por ejemplo, GPT), tanto en conjuntos de validación como de prueba.

 

Comparación con otros estudios:

En la Tabla 3, mostramos los resultados de AlphaCodium en comparación con otros métodos de la literatura.

 

modelización	conjunto de datos	metodologías	puntuación
GPT-3.5	conjunto de validación	AlfaCodio  (pass@5)	25%
GPT-3.5	conjunto de validación	Cadena de Códigos (pass@5)	17%
GPT-3.5	juego de pruebas	AlfaCodio (pass@5)	17%
GPT-3.5	juego de pruebas	Cadena de Códigos (pass@5)	14%
GPT-4	conjunto de validación	AlfaCodio (pass@5)	44%
Perfeccionamiento de DeepMind	conjunto de validación	Código Alfa (pass@10@1K)	17%
Perfeccionamiento de DeepMind	Código Alfa (pass@10@100K)	24%
GPT-4	juego de pruebas	AlfaCodio (pass@5)	29%
Perfeccionamiento de DeepMind	juego de pruebas	Código Alfa (pass@10@1K)	16%
Perfeccionamiento de DeepMind	juego de pruebas	Código Alfa (pass@10@100K)	28%
Gemini-pro	AlphaCode2: Los resultados de la comparación de AlphaCode2 no aparecen en las versiones existentes de CodeContests. Según Informe técnico sobre AlphaCode2Los investigadores compararon los resultados de AlphaCode con los de AlphaCode2 en un conjunto de datos inédito y observaron una reducción significativa del número de llamadas a grandes modelos lingüísticos (LLM) (@100), AlphaCode2 tiene un rendimiento comparable al de AlphaCode, siendo ambos 29%, pase@10.

 

Cuadro 3: Comparación de AlphaCodium con otros trabajos de investigación de la bibliografía

 

La figura muestra que el enfoque AlphaCodium demuestra un excelente rendimiento bajo una variedad de modelos y criterios de evaluación, especialmente cuando resuelve retos de programación utilizando grandes modelos de lenguaje. Estos resultados comparativos no solo demuestran la innovación técnica de AlphaCodium, sino que también ponen de relieve su eficacia y aplicabilidad en aplicaciones del mundo real.

 

En conjunto, AlphaCodium demuestra su notable potencial en el campo de la programación inteligente, especialmente en la mejora de la capacidad de los grandes modelos de lenguaje para manejar problemas de programación complejos. Estos resultados aportan importantes ideas para la investigación y el desarrollo futuros, y proporcionan valiosas referencias para el desarrollo y la optimización ulteriores de grandes modelos lingüísticos.

 

Figura 6: Comparación de la eficiencia. Así es como AlphaCodium se compara con otras soluciones en términos de precisión frente al número de llamadas al Large Language Model (LLM). En comparación con AlphaCode, AlphaCodium requiere miles de veces menos llamadas LLM para lograr una precisión similar.

Si comparamos AlphaCodium con el mismo modelo GPT-3.5 y el criterio de "tasa de aprobados en 5 intentos" [Cadena de Códigos], está claro que AlphaCodium obtiene mejores resultados en comparación con [ ]. En comparación con [Código AlfaAl comparar los métodos de [AlphaCode], es importante tener en cuenta que AlphaCode emplea una estrategia de generación de código diferente: optimiza un modelo específico para resolver el problema de codificación, genera un gran número de escenarios de codificación, luego los clasifica y, por último, selecciona un número de escenarios para su presentación a partir de las clasificaciones principales. Por ejemplo, "10 intentos superados de 100.000 soluciones" significa que genera 100.000 soluciones, las clasifica y, a continuación, selecciona 10 para presentarlas.AlphaCode utiliza un modelo especialmente optimizado que emplea un mayor número de llamadas LLM, similar a una estrategia exhaustiva. No obstante, AlphaCodium obtuvo mejores resultados.

 

También cabe mencionar que ni AlphaCode ni CodeChain proporcionan soluciones replicables, incluidos scripts completos de evaluación de extremo a extremo. Hay muchos detalles que deben tenerse en cuenta a la hora de evaluar los resultados, como el tratamiento de temas con múltiples soluciones, mecanismos de tolerancia a fallos, problemas de tiempo de espera, etc. Nuestra comparación se basa en los datos de sus artículos, pero para garantizar la fiabilidad y reproducibilidad de futuras comparaciones, ofrecemos un conjunto completo de código reproducible y guiones de evaluación.

 

Comparación de la potencia de cálculo: AlphaCode frente a AlphaCode2

En el proceso de AlphaCodium, la resolución de cada problema requiere unas 15-20 llamadas al Large Language Model (LLM), lo que significa que en el transcurso de la realización de cinco intentos se requieren unas 100 llamadas al LLM.

 

Y AlphaCode no informa explícitamente de cuántas llamadas al modelo de lenguaje grande se necesitan por problema. Si suponemos que se llama una vez por intento (lo que aún se desconoce y en realidad puede ser más), entonces para cada uno de los 10 intentos, filtrados a partir de las 100.000 soluciones, necesitaría llamar al modelo de lenguaje grande 1 millón de veces, lo que supone cuatro órdenes de magnitud más que AlphaCodium. Sin embargo, por los resultados que hemos visto, AlphaCodium rinde mucho mejor, como demuestra claramente la Figura 3.

 

Un estudio publicado recientemente llamado AlphaCode2 ([...Informe técnico]) en el que los investigadores evaluaron un modelo denominado Gemini-Pro ajustado a los problemas de programación. El estudio también exploró la evaluación comparativa de CodeContests, pero utilizando una versión actualizada no publicada. Según el informe de AlphaCode2, con sólo unas 100 muestras, AlphaCode2 alcanza el nivel de rendimiento que AlphaCode logra con millones de muestras, lo que lo hace más de 10.000 veces más eficiente en muestras que AlphaCode. Como resultado, tanto AlphaCode2 como AlphaCodium son mucho más eficientes que AlphaCode en cuanto al número de grandes llamadas al modelo de lenguaje.

 

Sin embargo, AlphaCode2 emplea un elaborado sistema diseñado específicamente para las competiciones de CodeContests.ajuste finoEl modelo AlphaCodium se basa en un modelo de base moderno, mientras que AlphaCodium utiliza un modelo genérico no modificado. Aun así, AlphaCodium mejora el rendimiento del modelo sin datos adicionales ni costosas fases de entrenamiento.

 

apéndice

 

1) Un ejemplo de evaluación manual de un problema de código:

/*

En un conjunto de números, comprueba si hay dos números con una distancia entre ellos inferior a un umbral numérico específico. >>>

has_close_elements({1.0, 2.0, 3.0}, 0.5) false >>>

has_close_elements({1,0, 2,8, 3,0, 4,0, 5,0, 2,0}, 0,3) true

*/

#include

#include

#include

using namespace std;

bool has_close_elements(vector numbers, float threshold){

 

Tabla 4.El problema es relativamente intuitivo y sencillo, sin muchos detalles ni sutilezas que el modelo deba razonar.

 

2) Por qué la salida YAML es más adecuada para tareas de generación de código que la salida JSON

Aunque la nueva versión de GPT tiene [soporte nativo], pero creemos que para la generación de código, la salida YAML es más apropiada. Esto se debe a que el código generado a menudo contiene comillas simples, comillas dobles y caracteres especiales. En formato JSON, es difícil para LLM colocar estos caracteres correctamente porque la salida JSON necesita estar rodeada de comillas dobles. La salida YAML, por otro lado, [Adopción de escalares de bloqueSimplemente siga las reglas de indentación y cualquier texto o código correctamente indentado será legal. Además, la salida YAML tiene menos tokens, lo que significa un menor coste y tiempos de inferencia más rápidos, así como una mayor calidad porque el modelo tiene menos tokens no críticos en los que centrarse. A continuación se muestra un ejemplo en el que se comparan las salidas JSON y YAML (utilizando [https://platform.openai.com/tokenizer] generados):

importar json

importar yaml

s1 = 'print("cadena de comillas dobles")'

s2 = "print('cadena de comillas simples')"

s3 = 'print("""cadena de comillas triples""")'

s4 = f"{s1}\n{s2}\n{s3}"

# Crea un diccionario con claves como nombres de variables y valores como cadenas

datos = {'s1': s1, 's2': s2, 's3': s3, 's4': s4}

# Convertir diccionario en cadena con formato JSON

json_data = json.dumps(data, indent=2)

print(datos_json)

# Convertir diccionarios en cadenas con formato YAML en estilo bloque escalar

yaml_data = yaml.dump(data, indent=2, default_style='|')

print(yaml_data)

Salida.

 

Cuadro 5.

Salida JSON:

 

Figura 7. Ejemplo de recuento de tokens mediante salida JSON.

A continuación se muestra un ejemplo de salida YAML:

 

 

Figura 8. Ejemplo de recuento de tokens mediante salida YAML.

Obviamente, generar código que sólo mantenga la sangría adecuada no sólo es más conciso y claro, sino también eficaz para reducir los errores.