LLM Bardziej stabilnym sposobem pisania kodu jest najpierw napisanie DSL

Jakiś czas temu wielokrotnie widziałem tę samą sytuację: rzucanie wymagań bezpośrednio na model, prędkość generowania jest bardzo duża, a przeróbka również szybka; najpierw umieść wymagania w warstwie DSL, a następnie pozwól modelowi napisać implementację wokół tej warstwy modelu semantycznego, a wynik będzie oczywiście stabilny. Zmiana jest bardzo bezpośrednia. Kluczem nie jest to, czy model można zapisać, ale czy najpierw została zamknięta opcjonalna przestrzeń.

Język naturalny nadaje się do przekazywania wskazówek, ale nie nadaje się do podejmowania zbyt wielu ukrytych decyzji. Pozornie prosty wymóg zostanie po zaimplementowaniu podzielony na wiele mniejszych ocen: jak nazwać stan, czy awarię uznać za zakończoną, ile razy należy ponowić próbę, na jakiej strefie czasowej opiera się okno czasowe i na której warstwie zapisywany jest dziennik. Dopóki te osądy będą nadal ukryte w procesie generowania, model będzie jednocześnie uzupełniał szczegóły i zmieniał granice. Ostateczną pisemną rzecz można uruchomić, ale trudno ją sprawdzić.

Język naturalny nadaje się tylko do mówienia o problemach

LLM jest bardzo dobry w przekształcaniu niejasnego opisu w pełny tekst, a także bardzo dobrze w uzupełnianiu intencji w czytelną wersję roboczą. To, w czym nie jest dobry, to długoterminowe stabilne nazewnictwo i ograniczenia dotyczące zestawu reguł biznesowych. Gdy wymagania obejmują przepływ stanu, nieprawidłowe gałęzie, granice czasowe i granice uprawnień, słowa te wydają się jasne w umyśle, ale często nie są sfinalizowane, gdy faktycznie zostaną umieszczone w kodzie. Model stoi przed dużą grupą otwartych problemów, a wyniki będą w naturalny sposób się zmieniać.

Dlatego też długie i krótkie słowa często stają się bardziej męczące, im częściej je piszesz. Gdy słowo zachęty będzie się wydłużać, model nadal otrzyma fragment wolnego tekstu, ale ten wolny tekst będzie dłuższy. Zapamiętuje więcej kontekstu bez tworzenia kolejnych granic. Jeżeli granica nie jest zamknięta, model może jedynie zgadywać.

DSL zamienia ukrytą ocenę na jawne dane wejściowe

Po zmianie wejścia na DSL sytuacja się zmienia. Model nie zgaduje już biznesu na podstawie przypadkowych zdań, ale wypełnia luki w oparciu o przejrzysty model semantyczny. W przypadku scenariusza testowego, procesu wydania i opisu graficznego węzły i relacje są najpierw definiowane przez DSL, a następnie tekst, kod i wykresy są uzupełniane przez model. Rezultat będzie bardziej przypominał coś wyhodowanego z tego samego systemu.

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

Największą wartością tego typu definicji nie jest to, że wygląda dobrze po napisaniu, ale to, że można ją kontrolować, różnicować i przeglądać. Generowanie kodu, dokumentacja, testowanie i diagramy mogą wynikać z tego samego modelu semantycznego. Model tutaj bardziej przypomina siłownik niż wynalazcę. Odpowiada za egzekwowanie ustalonych granic i nie odpowiada za ich przepisywanie na miejscu.

Kiedy ta granica zostanie ustalona, ​​wiele rzeczy, które przez długi czas były hałaśliwe, ucichnie. Co powinien obejmować test, czy spodziewana jest awaria i kto ma ostateczny głos w sprawie warunków wycofania? Nie są one już wyjaśniane na miejscu w języku naturalnym, ale zapisywane w wykonywalnej strukturze. To, na co patrzą ludzie, to semantyka, to, co wykonują maszyny, to semantyka, a to, do czego wracamy podczas rozwiązywania problemów, to ta sama semantyka.

LLM nadaje się do udziału w rozwoju DSL

LLM nie musi być wykonywany tylko poza DSL. Bardziej odpowiednim zastosowaniem jest umożliwienie mu najpierw udziału w rozwoju DSL. Wprowadź do niego kilka prawdziwych scenariuszy, pozwól mu uzupełnić słowa graniczne, wartości wyliczeniowe, nieprawidłowe gałęzie i kontrprzykłady, a następnie pozwól ludziom to zatrzymać. Po sfinalizowaniu DSL modelowi zostanie przekazany nie nieograniczony język naturalny, ale ograniczone dane wejściowe.

Na tym etapie LLM jest całkiem przydatny. Może pomóc w uporządkowaniu rozproszonych instrukcji w zestaw terminów, a także zidentyfikować problemy, takie jak niespójności nazewnictwa, luki w statusie i brak nieprawidłowych ścieżek na etapie wersji roboczej. Gdy model semantyczny będzie stabilny, wygeneruje on implementacje, schematy i próbki testowe. Wynik będzie bardziej przypominał bieganie po torze i nie będzie za każdym razem skręcał w inne miejsce.

Wolałbym umieścić LLM za DSL. Najpierw wyraźnie określ granice, a później pozwól im pomóc je wypełnić, aby system nie był łatwo rozpraszany przez wielokrotną improwizację.

Warstwa semantyczna również stanie się nieporęczna

Więcej DSL nie zawsze jest lepsze. Kiedy dziedzina nadal drastycznie się zmienia, przedwczesne utrwalenie się utrwali błędne założenia; jeśli warstwa semantyczna zostanie zaprojektowana zbyt uniwersalnie, stanie się kolejnym ciężkim frameworkiem. Prawdziwie opłacalny scenariusz zakłada zwykle powtarzanie się tego samego rodzaju działań, koszty przeglądu są wysokie, a zachowanie musi być identyfikowalne. W tym momencie DSL nie jest już dodatkowym obciążeniem, a raczej zbiorem rozproszonych orzeczeń na stabilne wejście.

Dlatego bardziej praktyczną oceną nie jest pytanie: „Czy LLM może być wyposażony w DSL?” ale „Czy konieczne jest najpierw ustalenie semantyki tej kwestii?” Gdy odpowiedź brzmi „tak”, słowo wskazujące nie powinno już mieć pełnej odpowiedzialności. Podpowiedź jest odpowiedzialna za wyjaśnienie intencji, DSL jest odpowiedzialny za przenoszenie ograniczeń, a model jest odpowiedzialny za przekształcenie ograniczeń w wykonywalne wyniki. To, co jest napisane w ten sposób, bardziej przypomina system inżynieryjny niż serię improwizacji.