LLM Een stabielere manier om code te schrijven is door eerst DSL te schrijven

Een tijdje geleden zag ik dezelfde situatie herhaaldelijk: door de vereisten rechtstreeks naar het model te gooien, is de generatiesnelheid erg snel en is het herwerken ook snel; plaats eerst de vereisten in een laag DSL en laat het model vervolgens de implementatie rond deze laag semantisch model schrijven, en de uitvoer is duidelijk stabiel. De verandering is heel direct. De sleutel is niet of het model kan worden geschreven, maar of de optionele ruimte eerst is gesloten.

Natuurlijke taal is geschikt om aanwijzingen te geven, maar niet om te veel impliciete beslissingen te nemen. Een ogenschijnlijk eenvoudige vereiste zal bij implementatie worden opgesplitst in vele kleine beslissingen: hoe de status te benoemen, of de fout als voltooid wordt beschouwd, hoe vaak opnieuw moet worden geprobeerd, op wiens tijdzone het tijdvenster is gebaseerd en op welke laag het logboek is geschreven. Zolang deze oordelen nog verborgen zijn in het generatieproces, zal het model tegelijkertijd details invullen en grenzen verleggen. Het laatste schriftelijke ding kan worden uitgevoerd, maar het is moeilijk te beoordelen.

Natuurlijke taal is alleen geschikt om over problemen te praten

LLM is erg goed in het uitwerken van een vage beschrijving tot een volledige tekst, maar ook erg goed in het omzetten van een intentie tot een leesbaar concept. Waar het niet goed in is, is het langdurig stabiel benoemen en beperken van een reeks bedrijfsregels. Zodra de vereisten betrekking hebben op statusstromen, abnormale vertakkingen, tijdsgrenzen en toestemmingsgrenzen, lijken deze woorden duidelijk in de geest, maar worden ze vaak niet definitief wanneer ze daadwerkelijk in de code worden geplaatst. Het model wordt geconfronteerd met een grote groep openstaande problemen, en de output zal uiteraard dienovereenkomstig fluctueren.

Dit is de reden waarom lange promptwoorden vaak vermoeiender worden naarmate je ze vaker schrijft. Nadat het promptwoord langer wordt, krijgt het model nog steeds een stuk vrije tekst, maar de vrije tekst is langer. Het onthoudt meer context zonder meer grenzen te krijgen. Als de grens niet gesloten is, kan het model alleen maar blijven raden.

DSL zet impliciet oordeel om in expliciete input

Na het wijzigen van de ingang naar DSL verandert de situatie. Het model gokt niet langer zaken op basis van losse zinnen, maar vult de lege plekken in op basis van een duidelijk semantisch model. Voor een testscenario, een releaseproces en een grafische beschrijving worden de knooppunten en relaties eerst gedefinieerd door de DSL, en vervolgens worden de tekst, code en grafieken aangevuld door het model. Het resultaat zal meer lijken op iets dat uit hetzelfde systeem is voortgekomen.

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

De grootste waarde van dit type definitie is niet dat het er goed uitziet als het geschreven is, maar dat er versiebeheer, differentiatie en beoordeling van mogelijk zijn. Het genereren van code, documentatie, testen en diagrammen kunnen allemaal voortkomen uit hetzelfde semantische model. Het model hier lijkt meer op een actuator dan op een uitvinder. Het is verantwoordelijk voor het handhaven van de vastgestelde grenzen en is niet verantwoordelijk voor het ter plekke herschrijven ervan.

Als deze grens eenmaal is vastgesteld, zullen veel dingen die lange tijd luidruchtig zouden zijn geweest, stil worden. Waar moet de test aan voldoen, of er een mislukking wordt verwacht en wie het laatste woord heeft over de terugdraaivoorwaarden? Deze worden niet meer ter plekke in natuurlijke taal uitgelegd, maar in een uitvoerbare structuur geschreven. Waar mensen naar kijken is semantiek, wat machines uitvoeren is semantiek, en waar we naar terugkeren bij het oplossen van problemen is dezelfde semantiek.

LLM is geschikt om deel te nemen aan de groei van DSL

LLM hoeft niet alleen buiten een DSL te worden uitgevoerd. Een passender gebruik is om het eerst te laten participeren in de groei van DSL. Voer er een paar echte scenario’s in, laat het de grenswoorden, opsommingswaarden, abnormale vertakkingen en tegenvoorbeelden aanvullen, en laat mensen er dan mee stoppen. Wanneer de DSL voltooid is, zal wat vervolgens aan het model wordt overgedragen geen onbeperkte natuurlijke taal zijn, maar beperkte invoer.

In dit stadium is LLM behoorlijk nuttig. Het kan helpen verspreide verklaringen in een reeks termen op één lijn te brengen, en kan ook problemen identificeren zoals inconsistenties in de naamgeving, hiaten in de status en ontbrekende abnormale paden tijdens de conceptfase. Nadat het semantische model stabiel is, genereert het model implementaties, schematische diagrammen en testvoorbeelden. De output zal meer lijken op rennen op een baan en zal niet elke keer naar andere plaatsen gaan.

Ik zou LLM liever achter DSL plaatsen. Maak eerst de grenzen duidelijk, en laat ze dan later helpen bij het invullen van de grenzen, zodat het systeem niet snel wordt afgeleid door steeds maar weer te improviseren.

De semantische laag zal ook onpraktisch worden

Meer DSL is niet altijd beter. Wanneer het veld nog steeds drastisch verandert, zal voortijdige verharding leiden tot verkeerde aannames; als de semantische laag te universeel wordt ontworpen, wordt het weer een zwaar raamwerk. Het echt kosteneffectieve scenario is meestal wanneer hetzelfde soort acties herhaaldelijk plaatsvinden, de beoordelingskosten hoog zijn en het gedrag traceerbaar moet zijn. Op dit moment is DSL niet langer een extra last, maar eerder een verzameling verspreide oordelen die leiden tot een stabiele entree.

Daarom is het meer praktische oordeel niet: “Kan LLM worden uitgerust met een DSL?” maar “Is het nodig om eerst de semantiek van deze kwestie op te lossen?” Zodra het antwoord ja is, zou het signaalwoord niet langer de volledige verantwoordelijkheid moeten hebben. De prompt is verantwoordelijk voor het uitleggen van de bedoeling, de DSL is verantwoordelijk voor het overbrengen van de beperkingen, en het model is verantwoordelijk voor het omzetten van de beperkingen in uitvoerbare resultaten. Wat op deze manier is geschreven, lijkt meer op een technisch systeem dan op een reeks improvisaties.