LLM Una forma más estable de escribir código es escribir DSL primero

Hace un tiempo, vi la misma situación repetidamente: al enviar los requisitos directamente al modelo, la velocidad de generación es muy rápida y la reelaboración también es rápida; Primero coloque los requisitos en una capa de DSL y luego deje que el modelo escriba la implementación alrededor de esta capa de modelo semántico, y el resultado es obviamente estable. El cambio es muy directo. La clave no es si el modelo se puede escribir, sino si el espacio opcional se ha cerrado primero.

El lenguaje natural es adecuado para dar instrucciones, pero no para llevar demasiadas decisiones implícitas. Un requisito aparentemente simple se dividirá en muchos pequeños juicios cuando se implemente: cómo nombrar el estado, si la falla se considera completa, cuántas veces reintentar, en qué zona horaria se basa la ventana de tiempo y en qué capa está escrito el registro. Mientras estos juicios sigan ocultos en el proceso de generación, el modelo completará los detalles y cambiará los límites al mismo tiempo. Lo escrito final se puede ejecutar, pero es difícil de revisar.

El lenguaje natural sólo sirve para hablar de problemas.

LLM es muy bueno para desarrollar una descripción vaga en un texto completo, y también muy bueno para completar una intención en un borrador legible. En lo que no es bueno es en nombres estables a largo plazo y restricciones para un conjunto de reglas comerciales. Una vez que los requisitos involucran flujo de estado, bifurcaciones anormales, límites de tiempo y límites de permisos, estas palabras parecen claras en la mente, pero a menudo no están finalizadas cuando realmente se incluyen en el código. El modelo enfrenta un gran grupo de problemas abiertos y la producción naturalmente fluctuará en consecuencia.

Esta es la razón por la que las palabras largas a menudo se vuelven más agotadoras cuanto más las escribes. Después de que la palabra solicitada continúa alargándose, el modelo aún obtiene un fragmento de texto libre, pero el texto libre es más largo. Recuerda más contexto sin establecer más límites. Si el límite no está cerrado, el modelo sólo puede seguir adivinando.

DSL convierte juicios implícitos en entradas explícitas

Después de cambiar la entrada a DSL, la situación cambia. El modelo ya no adivina negocios basándose en oraciones casuales, sino que completa los espacios en blanco basándose en un modelo semántico claro. Para un escenario de prueba, un proceso de lanzamiento y una descripción gráfica, los nodos y las relaciones se definen primero mediante el DSL y luego el modelo complementa el texto, el código y los gráficos. El resultado será más bien algo surgido del mismo sistema.

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

El mayor valor de este tipo de definición no es que se vea bien cuando se escribe, sino que se puede controlar, diferenciar y revisar la versión. La generación de código, la documentación, las pruebas y los diagramas pueden surgir del mismo modelo semántico. El modelo aquí se parece más a un actuador que a un inventor. Es responsable de hacer cumplir los límites establecidos y no es responsable de reescribirlos en el acto.

Una vez que se establece este límite, muchas cosas que habrían sido ruidosas durante mucho tiempo se volverán silenciosas. ¿Qué debería abarcar la prueba, si se espera una falla y quién tiene la última palabra sobre las condiciones de reversión? Estos ya no se explican en el momento en un lenguaje natural, sino que se escriben en una estructura ejecutable. Lo que miran los humanos es semántica, lo que ejecutan las máquinas es semántica y a lo que volvemos cuando solucionamos problemas es a la misma semántica.

LLM es adecuado para participar en el crecimiento de DSL

LLM no sólo tiene que ejecutarse fuera de un DSL. Un uso más apropiado es dejarlo participar primero en el crecimiento de DSL. Introduzca algunos escenarios reales, déjelo completar las palabras límite, los valores de enumeración, las ramas anormales y los contraejemplos, y luego deje que la gente lo detenga. Cuando se finalice el DSL, lo que posteriormente se entregará al modelo no será un lenguaje natural ilimitado, sino una entrada restringida.

En esta etapa, LLM es bastante útil. Puede ayudar a alinear declaraciones dispersas en un conjunto de términos y también puede identificar problemas como inconsistencias en los nombres, brechas de estado y rutas anormales faltantes durante la etapa de borrador. Una vez que el modelo semántico se estabilice, el modelo generará implementaciones, diagramas esquemáticos y muestras de prueba. La salida será más como correr en una pista y no girará hacia otros lugares cada vez.

Preferiría poner LLM detrás de DSL. Primero deje claros los límites y luego deje que ellos ayuden a completarlos más tarde, para que el sistema no se distraiga fácilmente con la improvisación una y otra vez.

La capa semántica también se volverá difícil de manejar

Más DSL no siempre es mejor. Cuando el campo todavía está cambiando drásticamente, la solidificación prematura bloqueará suposiciones erróneas; Si la capa semántica se diseña de manera demasiado universal, se convertirá en otro marco pesado. El escenario verdaderamente rentable suele ser cuando el mismo tipo de acciones ocurren repetidamente, los costos de revisión son altos y el comportamiento debe ser rastreable. En este punto, DSL ya no es una carga adicional, sino más bien una colección de juicios dispersos en una entrada estable.

Por lo tanto, el criterio más práctico no es “¿Se puede equipar LLM con un DSL?” pero “¿Es necesario arreglar primero la semántica de este asunto?” Una vez que la respuesta es sí, la palabra clave ya no debería tener toda la responsabilidad. El mensaje es responsable de explicar la intención, el DSL es responsable de llevar las restricciones y el modelo es responsable de convertir las restricciones en resultados ejecutables. Lo que está escrito de esta manera se parece más a un sistema de ingeniería que a una serie de improvisaciones.