Mô hình ngôn ngữ viết DSL: Cách giảm ảo giác bằng 'định vị kiểu dữ liệu'

Các mô hình ngôn ngữ lớn (LLM) ngày càng được tin dùng để sinh mã, nhưng khi mục tiêu là ngôn ngữ đặc thù miền (DSL) — như Terraform, Kubernetes YAML hay các ngôn ngữ cấu hình hạ tầng — thì độ chính xác lại tụt dốc thấy rõ. Vấn đề không nằm ở việc mô hình "không biết viết", mà ở chỗ nó không có cách nào tự kiểm chứng rằng thứ mình vừa viết ra là hợp lệ.

Vì sao LLM hay "bịa" khi viết DSL?

DSL thường có ba đặc điểm khiến mô hình dễ sai:

• Dữ liệu huấn luyện thưa thớt: số lượng mẫu DSL đúng chuẩn ít hơn hàng nghìn lần so với mã Python hay JavaScript.
• Cú pháp và ngữ nghĩa tách rời: một khối YAML có thể trông hoàn toàn hợp lệ nhưng tham chiếu tới trường không tồn tại.
• Không có phản hồi tức thời: khác với mã nguồn thông thường, DSL hiếm khi được kiểm tra kiểu (type-check) ngay khi viết.

Kết quả là mô hình tạo ra những cấu hình trông rất thuyết phục nhưng khi triển khai thì lỗi hàng loạt — kiểu ảo giác tốn kém nhất trong môi trường production.

Typed Domain Grounding: nhúng DSL vào ngôn ngữ có kiểu mạnh

Ý tưởng cốt lõi của Typed Domain Grounding khá đơn giản: thay vì để mô hình sinh trực tiếp DSL dạng văn bản tự do, ta nhúng miền nghiệp vụ đó vào một ngôn ngữ lập trình có hệ thống kiểu mạnh — ví dụ TypeScript, Rust hay Kotlin.

Nói cách khác, mô hình không viết YAML thô, mà viết mã có kiểu. Trình biên dịch sau đó đóng vai trò như một người gác cổng khách quan: nếu mã biên dịch được, khả năng cao nó đúng về mặt ngữ nghĩa; nếu không, ta nhận được thông báo lỗi cụ thể thay vì một thất bại im lặng trên môi trường thật.

Điểm mấu chốt là biến trình biên dịch thành một phần của vòng lặp sinh mã, chứ không chỉ là công cụ kiểm tra sau cùng.

Vòng lặp sinh - biên dịch - sửa lỗi

Quy trình này gồm ba bước lặp đi lặp lại:

1. Sinh (Generate): mô hình tạo mã dựa trên yêu cầu và các ràng buộc kiểu.
2. Biên dịch (Compile): hệ thống chạy kiểm tra kiểu và biên dịch thật.
3. Sửa lỗi (Repair): thông báo lỗi từ trình biên dịch được đưa ngược lại cho mô hình để nó chỉnh sửa.

Mỗi vòng lặp thu hẹp khoảng cách giữa ý định ban đầu và mã thực thi được. Điều đáng chú ý là trình biên dịch cung cấp tín hiệu phản hồi có cấu trúc, khác hẳn với việc chỉ hỏi lại mô hình "bạn có chắc không?".

Bằng chứng từ benchmark kUML

Để kiểm chứng cách tiếp cận này, tác giả sử dụng kUML — bộ benchmark dành cho các tác vụ sinh DSL trong lĩnh vực hạ tầng. Kết quả cho thấy tỷ lệ mã chạy được tăng đáng kể khi áp dụng Typed Domain Grounding so với việc sinh DSL trực tiếp.

Ví dụ minh họa là bài toán infrastructure-as-code: mô hình được yêu cầu tạo cấu hình triển khai dịch vụ lên cloud. Khi sinh YAML thuần, tỷ lệ lỗi cao; khi nhúng vào một ngôn ngữ có kiểu rồi trải qua vòng lặp sinh - biên dịch - sửa, phần lớn lỗi bị chặn lại trước khi chạm tới môi trường thật.

Ý nghĩa với đội ngũ kỹ thuật tại Việt Nam

Với các đội DevOps và platform engineering đang ngày càng dựa vào AI để viết Terraform, Helm chart hay manifest Kubernetes, bài học này rất thực tế:

• Đừng tin vào DSL sinh ra trực tiếp nếu không có bước xác thực tự động.
• Đầu tư vào pipeline kiểm tra — lint, validate, dry-run — chính là đầu tư vào độ tin cậy của AI.
• Cân nhắc lớp trừu tượng có kiểu thay vì để mô hình chạm trực tiếp vào cấu hình thô.

Nói cách khác, tương lai không phải là mô hình viết DSL giỏi hơn trong chân không, mà là mô hình được đặt trong một môi trường có phản hồi kiểm chứng được. Trình biên dịch, với tất cả sự khô khan của nó, có thể chính là người bạn đồng hành đáng tin nhất của LLM.