LLM Uma maneira mais estável de escrever código é escrever primeiro DSL

Há algum tempo, vi repetidamente a mesma situação: jogando os requisitos diretamente no modelo, a velocidade de geração é muito rápida e o retrabalho também é rápido; primeiro coloque os requisitos em uma camada de DSL e, em seguida, deixe o modelo escrever a implementação em torno dessa camada do modelo semântico, e a saída será obviamente estável. A mudança é muito direta. A chave não é se o modelo pode ser escrito, mas se o espaço opcional foi fechado primeiro.

A linguagem natural é adequada para indicar instruções, mas não para transmitir muitas decisões implícitas. Um requisito aparentemente simples será dividido em muitos pequenos julgamentos quando implementado: como nomear o estado, se a falha é considerada concluída, quantas vezes tentar novamente, em qual fuso horário a janela de tempo se baseia e em qual camada o log está escrito. Enquanto esses julgamentos ainda estiverem ocultos no processo de geração, o modelo preencherá detalhes e mudará os limites ao mesmo tempo. O texto final escrito pode ser executado, mas é difícil de revisar.

A linguagem natural só é adequada para falar sobre problemas

O LLM é muito bom em transformar uma descrição vaga em um texto completo e também em transformar uma intenção em um rascunho legível. O que não é bom é a nomenclatura estável a longo prazo e as restrições para um conjunto de regras de negócios. Uma vez que os requisitos envolvem fluxo de estado, ramificações anormais, limites de tempo e limites de permissão, essas palavras parecem claras na mente, mas muitas vezes não são finalizadas quando são realmente colocadas no código. O modelo enfrenta um grande grupo de problemas em aberto e o resultado irá naturalmente flutuar de acordo.

É por isso que palavras longas muitas vezes se tornam mais cansativas quanto mais você as escreve. Depois que a palavra do prompt continua a aumentar, o modelo ainda obtém um pedaço de texto livre, mas o texto livre é mais longo. Ele lembra mais contexto sem ter mais limites. Se a fronteira não for fechada, o modelo só poderá continuar a adivinhar.

DSL transforma julgamento implícito em entrada explícita

Depois de mudar a entrada para DSL, a situação muda. O modelo não adivinha mais os negócios com base em frases casuais, mas preenche as lacunas com base em um modelo semântico claro. Para um cenário de teste, um processo de lançamento e uma descrição gráfica, os nós e relacionamentos são primeiro definidos pela DSL e, em seguida, o texto, o código e os gráficos são complementados pelo modelo. O resultado será mais parecido com algo que surgiu do mesmo sistema.

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

O maior valor deste tipo de definição não é que ela pareça boa quando escrita, mas que possa ser controlada por versão, diferenciada e revisada. A geração de código, documentação, testes e diagramas podem crescer a partir do mesmo modelo semântico. O modelo aqui se parece mais com um atuador do que com um inventor. É responsável por fazer cumprir os limites estabelecidos e não é responsável por reescrevê-los no local.

Uma vez estabelecido esse limite, muitas coisas que seriam barulhentas por muito tempo ficarão silenciosas. O que deve ser coberto pelo teste, se a falha é esperada e quem tem a palavra final sobre as condições de reversão? Eles não são mais explicados imediatamente em linguagem natural, mas escritos em uma estrutura executável. O que os humanos olham é a semântica, o que as máquinas executam é a semântica e o que voltamos quando solucionamos problemas é a mesma semântica.

LLM é adequado para participar do crescimento do DSL

O LLM não precisa apenas ser executado fora de uma DSL. Um uso mais apropriado é deixá-lo participar primeiro do crescimento do DSL. Insira alguns cenários reais nele, deixe-o completar as palavras-limite, valores de enumeração, ramificações anormais e contra-exemplos e, em seguida, deixe as pessoas pará-lo. Quando a DSL for finalizada, o que será subsequentemente entregue ao modelo não será uma linguagem natural ilimitada, mas sim uma entrada restrita.

Nesta fase, o LLM é bastante útil. Ele pode ajudar a alinhar declarações dispersas em um conjunto de termos e também pode identificar problemas como inconsistências de nomenclatura, lacunas de status e falta de caminhos anormais durante a fase de rascunho. Depois que o modelo semântico estiver estável, o modelo gerará implementações, diagramas esquemáticos e amostras de teste. O resultado será mais parecido com correr em uma pista e não irá virar para outros lugares todas as vezes.

Eu preferiria colocar o LLM atrás do DSL. Deixe os limites claros primeiro e depois deixe-os ajudar a preenchê-los mais tarde, para que o sistema não seja facilmente distraído pela improvisação repetidas vezes.

A camada semântica também se tornará difícil de manejar

Mais DSL nem sempre é melhor. Quando o campo ainda está mudando drasticamente, a solidificação prematura irá travar suposições erradas; se a camada semântica for projetada de maneira muito universal, ela se tornará outra estrutura pesada. O cenário verdadeiramente rentável é geralmente quando o mesmo tipo de ações ocorre repetidamente, os custos de revisão são elevados e o comportamento deve ser rastreável. Neste ponto, o DSL não é mais um fardo adicional, mas sim uma coleção de julgamentos dispersos em uma entrada estável.

Portanto, o julgamento mais prático não é “O LLM pode ser equipado com uma DSL?” mas “É necessário corrigir primeiro a semântica deste assunto?” Quando a resposta for sim, a palavra-chave não deverá mais ter total responsabilidade. O prompt é responsável por explicar a intenção, a DSL é responsável por carregar as restrições e o modelo é responsável por transformar as restrições em resultados executáveis. O que é escrito desta forma parece mais um sistema de engenharia do que uma série de improvisações.