LLM Une façon plus stable d'écrire du Code est d'abord d'écrire DSL

Il y a quelque temps, j’ai vu la même situation à plusieurs reprises : en appliquant les exigences directement au modèle, la vitesse de génération est très rapide, et la retouche est également rapide ; placez d’abord les exigences dans une couche de DSL, puis laissez le modèle écrire l’implémentation autour de cette couche de modèle sémantique, et la sortie est évidemment stable. Le changement est très direct. La clé n’est pas de savoir si le modèle peut être écrit, mais si l’espace facultatif a été fermé en premier.

Le langage naturel est adapté pour donner des directions, mais pas pour véhiculer trop de décisions implicites. Une exigence apparemment simple sera divisée en de nombreux petits jugements une fois mise en œuvre : comment nommer l’état, si l’échec est considéré comme terminé, combien de fois réessayer, sur quel fuseau horaire la fenêtre horaire est basée et sur quelle couche le journal est écrit. Tant que ces jugements restent cachés dans le processus de génération, le modèle remplira les détails et modifiera en même temps les limites. La version finale écrite peut être exécutée, mais elle est difficile à réviser.

Le langage naturel ne convient que pour parler de problèmes

LLM est très doué pour développer une description vague en un texte complet, et également très doué pour compléter une intention en un brouillon lisible. Ce pour quoi il n’est pas bon, c’est la dénomination stable à long terme et les contraintes pour un ensemble de règles métier. Une fois que les exigences impliquent un flux d’état, des branches anormales, des limites de temps et des limites d’autorisation, ces mots semblent clairs dans l’esprit, mais ils ne sont souvent pas finalisés lorsqu’ils sont réellement insérés dans le code. Le modèle est confronté à un large groupe de problèmes ouverts et le résultat fluctue naturellement en conséquence.

C’est pourquoi les longs mots rapides deviennent souvent plus fatigants à mesure que vous les écrivez. Une fois que le mot d’invite continue de s’allonger, le modèle reçoit toujours un morceau de texte libre, mais le texte libre est plus long. Il se souvient de plus de contexte sans plus de limites. Si la frontière n’est pas fermée, le modèle ne peut que continuer à deviner.

DSL transforme le jugement implicite en entrée explicite

Après avoir modifié l’entrée en DSL, la situation change. Le modèle ne devine plus les affaires sur la base de phrases simples, mais remplit les blancs sur la base d’un modèle sémantique clair. Pour un scénario de test, un processus de publication et une description graphique, les nœuds et les relations sont d’abord définis par le DSL, puis le texte, le code et les graphiques sont complétés par le modèle. Le résultat ressemblera davantage à quelque chose issu du même système.

scenario: payment_timeout
steps:
  - send: order.created
  - wait: 3s
  - if: payment_missing
    then: cancel_order
    audit: required

La plus grande valeur de ce type de définition n’est pas qu’elle semble bonne une fois écrite, mais qu’elle peut être contrôlée, modifiée et révisée. La génération de code, la documentation, les tests et les diagrammes peuvent tous découler du même modèle sémantique. Le modèle ici ressemble plus à un actionneur qu’à un inventeur. Il est chargé de faire respecter les limites établies et n’a pas la responsabilité de les réécrire sur place.

Une fois cette frontière établie, beaucoup de choses qui auraient été bruyantes pendant longtemps deviendront silencieuses. Que doit couvrir le test, si un échec est attendu et qui a le dernier mot sur les conditions de retour en arrière ? Celles-ci ne sont plus expliquées sur place dans un langage naturel, mais écrites dans une structure exécutable. Ce que les humains regardent, c’est la sémantique, ce que les machines exécutent, c’est la sémantique, et ce à quoi nous revenons lors du dépannage, c’est la même sémantique.

LLM est adapté pour participer à la croissance du DSL

LLM ne doit pas seulement être exécuté en dehors d’un DSL. Une utilisation plus appropriée consiste à le laisser participer dans un premier temps à la croissance du DSL. Introduisez-y quelques scénarios réels, laissez-le compléter les mots limites, les valeurs d’énumération, les branches anormales et les contre-exemples, puis laissez les gens l’arrêter. Lorsque le DSL sera finalisé, ce qui sera ensuite transmis au modèle ne sera pas un langage naturel illimité, mais une saisie contrainte.

A ce stade, le LLM est très utile. Il peut aider à aligner des déclarations dispersées dans un ensemble de termes et peut également identifier des problèmes tels que des incohérences de nom, des lacunes de statut et des chemins anormaux manquants au cours de la phase de brouillon. Une fois le modèle sémantique stable, il générera des implémentations, des diagrammes schématiques et des échantillons de test. Le résultat ressemblera davantage à une course sur piste et ne se tournera pas vers d’autres endroits à chaque fois.

Je préférerais mettre LLM derrière DSL. Définissez d’abord les limites clairement, puis laissez-les contribuer à les combler plus tard, afin que le système ne soit pas facilement distrait par l’improvisation encore et encore.

La couche sémantique deviendra également lourde

Plus de DSL n’est pas toujours mieux. Lorsque le domaine est encore en train de changer radicalement, une solidification prématurée enfermera des hypothèses erronées ; si la couche sémantique est conçue de manière trop universelle, elle deviendra un autre cadre lourd. Le scénario véritablement rentable est généralement celui où le même type d’actions se produit de manière répétée, les coûts d’examen sont élevés et le comportement doit être traçable. À ce stade, le DSL n’est plus un fardeau supplémentaire, mais plutôt un ensemble de jugements dispersés dans une entrée stable.

Par conséquent, le jugement le plus pratique n’est pas « LLM peut-il être équipé d’un DSL ? » mais “Est-il nécessaire de fixer d’abord la sémantique de cette affaire ?” Une fois la réponse oui, le mot indicateur ne devrait plus avoir l’entière responsabilité. L’invite est chargée d’expliquer l’intention, le DSL est chargé de supporter les contraintes et le modèle est chargé de transformer les contraintes en résultats exécutables. Ce qui est écrit de cette manière ressemble plus à un système d’ingénierie qu’à une série d’improvisations.