LLM 코드를 작성하는 보다 안정적인 방법은 DSL을 먼저 작성하는 것입니다.

얼마 전 같은 상황을 반복해서 보았습니다. 요구 사항을 모델에 직접 던지고 생성 속도가 매우 빠르며 재작업도 빠릅니다. 먼저 요구 사항을 DSL 계층에 넣은 다음 모델이 이 의미 체계 모델 계층을 중심으로 구현을 작성하도록 하면 출력이 확실히 안정적입니다. 변화는 매우 직접적입니다. 핵심은 모델을 작성할 수 있는지 여부가 아니라 선택적 공간이 먼저 닫혔는지 여부입니다.

자연어는 방향을 알려주는 데 적합하지만 너무 많은 암시적 결정을 내리는 데는 적합하지 않습니다. 겉보기에 단순해 보이는 요구 사항은 구현 시 여러 가지 작은 판단으로 분할됩니다. 상태 이름 지정 방법, 실패가 완료된 것으로 간주되는지 여부, 재시도 횟수, 시간 창의 기반이 되는 시간대, 로그가 기록되는 계층은 무엇입니까? 이러한 판단이 생성 과정에 여전히 숨겨져 있는 한 모델은 세부 사항을 채우고 동시에 경계를 변경합니다. 최종 작성된 것은 실행은 가능하지만 검토가 어렵습니다.

자연어는 문제에 관해 이야기하는 데에만 적합합니다.

LLM은 모호한 설명을 완전한 텍스트로 발전시키는 데 매우 능숙하며, 의도를 읽을 수 있는 초안으로 완성하는 데에도 매우 능숙합니다. 그것이 좋지 않은 것은 일련의 비즈니스 규칙에 대한 장기적으로 안정적인 이름 지정 및 제약입니다. 요구 사항에 상태 흐름, 비정상적인 분기, 시간 경계, 권한 경계가 포함되면 이러한 단어가 마음으로는 명확해 보이지만 실제로 코드에 넣을 때 확정되지 않는 경우가 많습니다. 모델은 공개된 대규모 문제 그룹에 직면해 있으며 그에 따라 출력이 자연스럽게 변동됩니다.

그렇기 때문에 긴 프롬프트 단어를 쓰면 쓸수록 더 피곤해지는 경우가 많습니다. 프롬프트 단어가 계속 길어진 후에도 모델은 여전히 ​​자유 텍스트를 얻지만 자유 텍스트는 더 길어집니다. 더 많은 경계를 확보하지 않고도 더 많은 맥락을 기억합니다. 경계가 닫혀 있지 않으면 모델은 계속해서 추측만 할 수 있습니다.

DSL은 암시적 판단을 명시적 입력으로 바꿉니다.

입력을 DSL로 변경하면 상황이 변경됩니다. 모델은 더 이상 일상적인 문장을 기반으로 비즈니스를 추측하지 않고 명확한 의미 모델을 기반으로 공백을 채웁니다. 테스트 시나리오, 릴리스 프로세스 및 그래픽 설명의 경우 노드와 관계는 먼저 DSL에 의해 정의된 다음 텍스트, 코드 및 차트가 모델에 의해 보완됩니다. 결과는 동일한 시스템에서 성장한 것과 비슷할 것입니다.

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

이러한 유형의 정의의 가장 큰 가치는 작성 시 보기에 좋다는 것이 아니라 버전을 제어하고 비교하고 검토할 수 있다는 것입니다. 코드 생성, 문서화, 테스트 및 다이어그램은 모두 동일한 의미 체계 모델에서 성장할 수 있습니다. 여기서 모델은 발명가라기보다는 액추에이터에 가깝습니다. 설정된 경계를 시행할 책임이 있으며 그 자리에서 다시 작성할 책임은 없습니다.

이 경계가 확립되면 오랫동안 시끄러웠던 많은 것들이 조용해질 것입니다. 테스트에서 무엇을 다루어야 하는지, 실패가 예상되는지, 롤백 조건에 대한 최종 결정권자는 누구입니까? 이는 더 이상 자연어로 즉석에서 설명되지 않고 실행 가능한 구조로 작성됩니다. 인간이 보는 것은 의미론이고, 기계가 실행하는 것은 의미론이며, 문제를 해결할 때 우리가 돌아가는 것도 동일한 의미론입니다.

LLM은 DSL의 성장에 참여하기에 적합합니다.

LLM은 DSL 외부에서 실행될 필요가 없습니다. 보다 적절한 사용법은 먼저 DSL의 성장에 참여하도록 하는 것입니다. 몇 가지 실제 시나리오를 입력하고 경계 단어, 열거 값, 비정상적인 분기 및 반례를 완성한 다음 사람들이 중지하도록 합니다. DSL이 완성되면 이후에 모델에 전달되는 것은 무제한의 자연어가 아니라 제한된 입력이 됩니다.

이 단계에서는 LLM이 매우 유용합니다. 흩어져 있는 설명을 일련의 용어로 정렬하는 데 도움이 될 수 있으며, 초안 단계에서 명명 불일치, 상태 차이, 비정상적인 경로 누락과 같은 문제를 식별할 수도 있습니다. 의미론적 모델이 안정되면 모델은 구현, 회로도 및 테스트 샘플을 생성합니다. 출력은 트랙에서 달리는 것과 비슷하며 매번 다른 장소로 향하지 않습니다.

나는 DSL 뒤에 LLM을 두는 것을 선호합니다. 먼저 경계를 명확히 한 다음 나중에 경계를 채우는 데 도움을 주어 즉흥적인 작업으로 인해 시스템이 쉽게 산만해지지 않도록 하십시오.

의미 계층도 다루기 어려워질 것입니다

더 많은 DSL이 항상 더 나은 것은 아닙니다. 현장이 여전히 급격하게 변할 때 조기 응고는 잘못된 가정에 갇힐 것입니다. 의미 계층이 너무 보편적으로 설계되면 또 다른 무거운 프레임워크가 될 것입니다. 실제로 비용 효율적인 시나리오는 일반적으로 동일한 유형의 작업이 반복적으로 발생하고 검토 비용이 높으며 동작을 추적할 수 있어야 하는 경우입니다. 이 시점에서 DSL은 더 이상 추가적인 부담이 아니며 오히려 흩어진 판단을 모아 안정된 입구로 들어가는 것입니다.

그러므로 보다 현실적인 판단은 "LLM에 DSL을 탑재할 수 있는가?"가 아니다. 하지만 “먼저 이 문제의 의미를 고쳐야 할까요?” 대답이 '예’이면 큐 단어는 더 이상 전적인 책임을 지지 않아야 합니다. 프롬프트는 의도를 설명하는 역할을 담당하고, DSL은 제약 조건을 전달하는 역할을 하며, 모델은 제약 조건을 실행 가능한 결과로 바꾸는 역할을 담당합니다. 이런 방식으로 작성된 것은 일련의 즉흥 연주라기보다는 엔지니어링 시스템에 더 가깝습니다.