LLM Cách viết mã ổn định hơn là viết DSL trước

Cách đây không lâu, tôi đã thấy tình huống tương tự lặp đi lặp lại: ném yêu cầu trực tiếp vào mô hình, tốc độ tạo rất nhanh và làm lại cũng nhanh; đầu tiên đặt các yêu cầu vào một lớp DSL, sau đó để mô hình viết phần triển khai xung quanh lớp mô hình ngữ nghĩa này và đầu ra rõ ràng là ổn định. Sự thay đổi là rất trực tiếp. Điều quan trọng không phải là mô hình có thể được viết hay không, mà là liệu không gian tùy chọn đã được đóng trước hay chưa.

Ngôn ngữ tự nhiên phù hợp để chỉ đường nhưng không phù hợp để đưa ra quá nhiều quyết định ngầm. Một yêu cầu tưởng chừng đơn giản sẽ được chia thành nhiều phán đoán nhỏ khi thực hiện: cách đặt tên trạng thái, liệu lỗi có được coi là hoàn thành hay không, thử lại bao nhiêu lần, cửa sổ thời gian dựa trên múi giờ nào và nhật ký được ghi trên lớp nào. Miễn là những phán đoán này vẫn còn ẩn trong quá trình tạo, mô hình sẽ điền chi tiết và thay đổi ranh giới cùng một lúc. Văn bản cuối cùng có thể chạy được nhưng rất khó để xem lại.

Ngôn ngữ tự nhiên chỉ thích hợp để nói về vấn đề

LLM rất giỏi trong việc phát triển một mô tả mơ hồ thành một văn bản hoàn chỉnh và cũng rất giỏi trong việc hoàn thành ý định thành một bản nháp dễ đọc. Điểm yếu của nó là cách đặt tên ổn định lâu dài và các ràng buộc đối với một bộ quy tắc kinh doanh. Khi các yêu cầu liên quan đến luồng trạng thái, các nhánh bất thường, ranh giới thời gian và ranh giới quyền, những từ này có vẻ rõ ràng trong đầu, nhưng chúng thường không được hoàn thiện khi chúng thực sự được đưa vào mã. Mô hình phải đối mặt với một nhóm lớn các vấn đề mở và đầu ra sẽ dao động tương ứng một cách tự nhiên.

Đây là lý do tại sao bạn càng viết những từ dài dòng càng trở nên mệt mỏi. Sau khi từ nhắc tiếp tục dài ra, mô hình vẫn nhận được một đoạn văn bản tự do, nhưng văn bản tự do dài hơn. Nó ghi nhớ nhiều bối cảnh hơn mà không có nhiều ranh giới hơn. Nếu ranh giới không bị đóng, mô hình chỉ có thể tiếp tục đoán.

DSL biến phán đoán ngầm thành đầu vào rõ ràng

Sau khi thay đổi đầu vào thành DSL, tình hình sẽ thay đổi. Mô hình không còn đoán hoạt động kinh doanh dựa trên các câu thông thường mà điền vào chỗ trống dựa trên mô hình ngữ nghĩa rõ ràng. Đối với kịch bản thử nghiệm, quy trình phát hành và mô tả đồ họa, các nút và mối quan hệ trước tiên được xác định bởi DSL, sau đó văn bản, mã và biểu đồ được mô hình bổ sung. Kết quả sẽ giống một thứ gì đó được phát triển từ cùng một hệ thống.

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

Giá trị lớn nhất của loại định nghĩa này không phải là nó trông đẹp khi được viết mà là nó có thể được kiểm soát phiên bản, khác biệt và xem xét lại. Việc tạo mã, tài liệu, kiểm tra và sơ đồ đều có thể phát triển từ cùng một mô hình ngữ nghĩa. Mô hình ở đây giống một thiết bị truyền động hơn là một nhà phát minh. Nó có trách nhiệm thực thi các ranh giới đã được thiết lập và không chịu trách nhiệm viết lại chúng ngay tại chỗ.

Một khi ranh giới này được thiết lập, nhiều thứ vốn ồn ào bấy lâu nay sẽ trở nên yên tĩnh. Kiểm thử cần bao gồm những gì, liệu có dự đoán được thất bại hay không và ai là người đưa ra quyết định cuối cùng về các điều kiện khôi phục? Những điều này không còn được giải thích ngay tại chỗ bằng ngôn ngữ tự nhiên mà được viết thành một cấu trúc có thể thực thi được. Những gì con người nhìn vào là ngữ nghĩa, những gì máy thực thi là ngữ nghĩa và những gì chúng ta quay lại khi khắc phục sự cố cũng là những ngữ nghĩa giống nhau.

LLM phù hợp để tham gia vào sự phát triển của DSL

LLM không nhất thiết phải được thực thi bên ngoài DSL. Cách sử dụng phù hợp hơn là để nó tham gia vào sự phát triển của DSL trước. Đưa một số tình huống thực tế vào đó, để nó hoàn thành các từ ranh giới, giá trị liệt kê, các nhánh bất thường và phản ví dụ, sau đó để mọi người dừng nó lại. Khi DSL được hoàn thiện, những gì sau đó được chuyển giao cho mô hình sẽ không phải là ngôn ngữ tự nhiên không giới hạn mà là đầu vào bị hạn chế.

Ở giai đoạn này, LLM khá hữu ích. Nó có thể giúp sắp xếp các tuyên bố rải rác thành một tập hợp các thuật ngữ và cũng có thể xác định các vấn đề như sự không nhất quán trong cách đặt tên, khoảng cách trạng thái và thiếu các đường dẫn bất thường trong giai đoạn dự thảo. Sau khi mô hình ngữ nghĩa ổn định, mô hình sẽ tạo ra các triển khai, sơ đồ và mẫu thử nghiệm. Đầu ra sẽ giống như chạy trên một đường đua và không phải lần nào cũng rẽ sang nơi khác.

Tôi muốn đặt LLM sau DSL. Trước tiên hãy làm rõ các ranh giới, sau đó để chúng giúp lấp đầy các ranh giới sau, để hệ thống không dễ bị phân tâm bởi sự ngẫu hứng lặp đi lặp lại.

Lớp ngữ nghĩa cũng sẽ trở nên khó sử dụng

Nhiều DSL hơn không phải lúc nào cũng tốt hơn. Khi trường vẫn đang thay đổi mạnh mẽ, sự đông đặc sớm sẽ dẫn đến những giả định sai lầm; nếu lớp ngữ nghĩa được thiết kế quá phổ biến, nó sẽ trở thành một framework nặng nề khác. Tình huống thực sự hiệu quả về mặt chi phí thường là khi cùng một loại hành động xảy ra lặp đi lặp lại, chi phí xem xét cao và hành vi phải được theo dõi. Tại thời điểm này, DSL không còn là gánh nặng bổ sung mà là tập hợp các phán đoán rải rác thành một lối vào ổn định.

Vì vậy, nhận định thực tế hơn không phải là “LLM có thể trang bị DSL được không?” nhưng “Có nhất thiết phải sửa lại ngữ nghĩa của vấn đề này trước không?” Một khi câu trả lời là có, từ gợi ý sẽ không còn có toàn bộ trách nhiệm nữa. Lời nhắc có trách nhiệm giải thích ý định, DSL chịu trách nhiệm thực hiện các ràng buộc và mô hình chịu trách nhiệm biến các ràng buộc thành kết quả có thể thực thi được. Những gì được viết theo cách này giống một hệ thống kỹ thuật hơn là một loạt sự ngẫu hứng.