LLM Un modo più stabile per scrivere codice è scrivere prima DSL

Qualche tempo fa, ho visto ripetutamente la stessa situazione: inserendo i requisiti direttamente nel modello, la velocità di generazione è molto elevata e anche la rielaborazione è rapida; prima inserisci i requisiti in uno strato di DSL, quindi lascia che il modello scriva l’implementazione attorno a questo strato di modello semantico e l’output è ovviamente stabile. Il cambiamento è molto diretto. La chiave non è se il modello può essere scritto, ma se lo spazio opzionale è stato chiuso prima.

Il linguaggio naturale è adatto a dare indicazioni, ma non a portare troppe decisioni implicite. Un requisito apparentemente semplice verrà suddiviso in tanti piccoli giudizi una volta implementato: come nominare lo stato, se l’errore è considerato completato, quante volte riprovare, su quale fuso orario si basa la finestra temporale e su quale livello è scritto il registro. Finché questi giudizi sono ancora nascosti nel processo di generazione, il modello completerà i dettagli e allo stesso tempo cambierà i confini. La cosa scritta finale può essere eseguita, ma è difficile da rivedere.

Il linguaggio naturale è adatto solo per parlare di problemi

LLM è molto bravo a sviluppare una descrizione vaga in un testo completo ed è anche molto bravo a completare un’intenzione in una bozza leggibile. Ciò in cui non è bravo è la denominazione stabile a lungo termine e i vincoli per un insieme di regole aziendali. Una volta che i requisiti coinvolgono il flusso di stato, i rami anomali, i limiti temporali e i limiti dei permessi, queste parole sembrano chiare nella mente, ma spesso non sono finalizzate quando vengono effettivamente inserite nel codice. Il modello affronta un ampio gruppo di problemi aperti e l’output fluttuerà naturalmente di conseguenza.

Questo è il motivo per cui le parole lunghe e tempestive spesso diventano più stancanti quanto più le si scrive. Dopo che la parola del prompt continua ad allungarsi, il modello riceve ancora una parte di testo libero, ma il testo libero è più lungo. Ricorda più contesto senza ottenere più confini. Se il confine non è chiuso, il modello può solo continuare a indovinare.

DSL trasforma il giudizio implicito in input esplicito

Dopo aver cambiato l’ingresso in DSL, la situazione cambia. Il modello non indovina più gli affari sulla base di frasi casuali, ma riempie gli spazi vuoti sulla base di un modello semantico chiaro. Per uno scenario di test, un processo di rilascio e una descrizione grafica, i nodi e le relazioni vengono prima definiti dal DSL, quindi il testo, il codice e i grafici vengono integrati dal modello. Il risultato sarà più simile a qualcosa cresciuto dallo stesso sistema.

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

Il valore più grande di questo tipo di definizione non è che abbia un bell’aspetto una volta scritta, ma che possa essere controllata, modificata e rivista. La generazione del codice, la documentazione, i test e i diagrammi possono tutti svilupparsi dallo stesso modello semantico. Il modello qui è più simile a un attuatore che a un inventore. È responsabile del rispetto dei confini stabiliti e non è responsabile di riscriverli sul posto.

Una volta stabilito questo confine, molte cose che sarebbero state rumorose per molto tempo diventeranno silenziose. Cosa dovrebbe essere coperto dal test, se è previsto il fallimento e chi ha l’ultima parola sulle condizioni di rollback? Questi non vengono più spiegati sul posto in un linguaggio naturale, ma scritti in una struttura eseguibile. Ciò che gli esseri umani guardano è la semantica, ciò che le macchine eseguono è la semantica e ciò a cui torniamo quando risolviamo i problemi è la stessa semantica.

LLM è adatto per partecipare alla crescita di DSL

LLM non deve essere eseguito solo al di fuori di una DSL. Un utilizzo più appropriato è lasciarlo partecipare prima alla crescita della DSL. Inserisci alcuni scenari reali, lascia che completi le parole di confine, i valori di enumerazione, i rami anomali e i controesempi, e poi lascia che le persone lo fermino. Una volta finalizzato il DSL, ciò che verrà successivamente consegnato al modello non sarà un linguaggio naturale illimitato, ma un input limitato.

In questa fase, LLM è abbastanza utile. Può aiutare ad allineare affermazioni sparse in una serie di termini e può anche identificare problemi come incoerenze nei nomi, lacune di stato e percorsi anomali mancanti durante la fase di bozza. Una volta che il modello semantico è stabile, il modello genererà implementazioni, diagrammi schematici ed esempi di test. L’output sarà più simile a correre su una pista e non si trasformerà ogni volta in altri posti.

Preferirei mettere LLM dietro DSL. Prima di tutto rendi chiari i confini, e poi lascia che ti aiutino a riempirli in seguito, in modo che il sistema non venga facilmente distratto dall’improvvisazione ancora e ancora.

Anche il livello semantico diventerà ingombrante

Più DSL non è sempre meglio. Quando il campo sta ancora cambiando drasticamente, una solidificazione prematura bloccherà ipotesi errate; se lo strato semantico è progettato in modo troppo universale, diventerà un’altra struttura pesante. Lo scenario veramente conveniente è solitamente quello in cui lo stesso tipo di azioni si verifica ripetutamente, i costi di revisione sono elevati e il comportamento deve essere tracciabile. A questo punto l’DSL non è più un peso aggiuntivo, ma piuttosto una raccolta di giudizi sparsi in un ingresso stabile.

Pertanto, il giudizio più pratico non è “È possibile dotare LLM di una DSL?” ma “È necessario prima fissare la semantica di questa questione?” Una volta che la risposta è sì, la parola chiave non dovrebbe più avere la piena responsabilità. Il prompt è responsabile di spiegare l’intenzione, il DSL è responsabile di sopportare i vincoli e il modello è responsabile di trasformare i vincoli in risultati eseguibili. Ciò che è scritto in questo modo è più simile a un sistema di ingegneria piuttosto che a una serie di improvvisazioni.