Gabriel Gordon-Hall, chercheur et rédacteur à Bloop, évalue les grands modèles de langage (LLM) sur COBOL. Il présente COBOLEval, le premier benchmark d'évaluation des LLM pour les complétions de code en COBOL. Il répond notamment à la question sur "Comment les LLM peuvent-ils écrire COBOL ?".Les LLM sont en train de changer rapidement la façon dont on écrit les logiciels. Plus d'un million de développeurs paient maintenant pour GitHub Copilot et les récentes percées dans le raisonnement LLM ont rapproché le rêve d'un ingénieur logiciel entièrement IA de la réalité. Mais s'il n'est pas difficile de trouver une démo d'un LLM codant un site web ou un clone de Flappy Bird, on ne sait pas grand-chose de leur capacité à écrire du code dans des langages plus anciens comme le COBOL.
L'opportunité pour la génération LLM COBOL est énorme. Bien que le langage ait été publié pour la première fois en 1959, il continue à alimenter des systèmes critiques - 95 % des transactions des distributeurs automatiques de billets aux États-Unis sont traitées en COBOL. Mais il n'est pas enseigné dans les cours d'informatique ou dans les camps d'entraînement, et les ingénieurs qui l'écrivent professionnellement partent régulièrement à la retraite. Si les LLM pouvaient comprendre et écrire le COBOL, ils pourraient aider à maintenir les 800 milliards de lignes encore en production aujourd'hui.
Dans quelle mesure les LLM peuvent-ils écrire COBOL ? Pour autant qu'on le sait, personne n'a essayé de répondre publiquement à cette question. Jusqu'à présent...
Présentation de COBOLEval
Aujourd'hui, Bloop publie COBOLEval, le premier benchmark d'évaluation des LLM pour les complétions de code en COBOL. Il se compose de 146 problèmes de codage difficiles qui ont été convertis en COBOL à partir du benchmark de génération HumanEval Python largement utilisé. Chaque problème est associé à une moyenne de 6 cas de test. Une solution générée par LLM doit tous les réussir pour être correcte. Bloop puble également un harnais de test que vous pouvez utiliser pour évaluer vos propres modèles, ainsi que mAInframer-1 - une série de modèles open-source basés sur CodeLlama qu'ils ont affinés spécifiquement pour écrire du COBOL - qui surpassent GPT-4.
De HumanEval à COBOLEval
Les fonctions
Convertir HumanEval en COBOL n'est pas aussi simple qu'il n'y paraît. Chaque problème HumanEval se compose d'une invite, d'une signature de fonction Python typée et d'une docstring, qui est transmise directement à un LLM, qui implémente ensuite le corps de la fonction.
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 | from typing import List
def has_close_elements(numbers: List[float], threshold: float) -> bool:
""" Check if in given list of numbers, are any two numbers closer to each other than
given threshold.
>>> 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
""" |
Il possède cependant des sous-programmes. Nous transformons donc chaque problème en un programme COBOL dans lequel les arguments et les variables de retour sont définis dans la SECTION DE LIEN afin qu'ils puissent être transmis et lus à partir d'un programme appelant.
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 | IDENTIFICATION DIVISION.
PROGRAM-ID. HAS-CLOSE-ELEMENTS.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
DATA DIVISION.
LINKAGE SECTION.
01 LINKED-ITEMS.
05 L-NUMBERS OCCURS 100 TIMES INDEXED BY NI COMP-2.
05 L-THRESHOLD COMP-2.
05 RESULT PIC 9.
* Check if in given list of numbers, are any two numbers closer to each other than
* given threshold.
* >>> 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
*
* Complete the WORKING-STORAGE SECTION and the PROCEDURE DIVISION
* Store the result in the RESULT variable and mark the end of your program with END PROGRAM
WORKING-STORAGE SECTION. |
Les types
Le système de types de COBOL est radicalement différent de celui des langages de programmation modernes. Les variables sont déclarées avec des clauses PICTURE (PIC en abrégé) qui précisent le nombre de caractères qu'elles occupent en mémoire. Par exemple, PIC X(100) est une chaîne de 100 caractères, tandis que PIC S9(10) est un entier signé de 10 chiffres.
Contrairement à Python, COBOL n'a pas de chaînes, d'entiers ou de tableaux de longueur variable, nous fixons donc ces longueurs à des limites supérieures (aucun problème COBOLEval n'accepte ou ne renvoie un tableau d'une longueur supérieure à 100). Nous obtenons ainsi notre correspondance entre les types Python et COBOL.
| Code : | Sélectionner tout |
1 2 3 4 | Int => PIC S9(10) Float => COMP-2 Str => PIC X(100) List[Int] => OCCURS 100 TIMES INDEXED BY I PIC S9(10) |
Section sur le stockage de travail
Les programmeurs COBOL chevronnés auront repéré un bogue dans le programme d'invite ci-dessus. La SECTION DE LIEN et la SECTION DE STOCKAGE DE TRAVAIL sont inversées. Si on essaits de le compiler, on obtient une erreur.
Pourquoi sont-elles dans le mauvais ordre ? Le problème est que - contrairement aux langages modernes (vous avez l'habitude de l'entendre maintenant) - COBOL n'a pas de variables locales. Toutes les variables - même les variables temporaires - utilisées dans la logique du programme doivent être déclarées à l'avance dans la SECTION DE TRAVAIL.
Il est clair que le LLM doit générer la SECTION DE TRAVAIL afin de pouvoir déclarer les variables qu'il utilisera dans sa solution. Mais en même temps, il doit connaître...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.
Envoyé par Aiekick
