Constrained Decoding
Giải mã có ràng buộc loại bỏ các token không hợp lệ ở mỗi bước sinh, nhờ đó LLM chỉ có thể xuất ra các nhãn được phép, kết quả khớp regex hoặc JSON hợp lệ theo schema.
Giải mã có ràng buộc là kỹ thuật tạo văn bản giới hạn những token mà model ngôn ngữ có thể tạo ra ở mỗi bước, nhờ đó đầu ra hoàn chỉnh chắc chắn khớp với định dạng bắt buộc: một nhãn trong tập cố định, biểu thức chính quy, ngữ pháp hoặc JSON Schema. Model vẫn chấm điểm mọi token trong từ vựng của nó. Trước khi chọn token, decoder loại bỏ mọi lựa chọn có thể phá vỡ định dạng. Các ứng dụng phân tích cú pháp đầu ra của model, chẳng hạn backend API, AI agent và pipeline trích xuất dữ liệu, sử dụng kỹ thuật này để mọi phản hồi đều phân tích được ngay lần đầu.
Che các token không hợp lệ#
Model ngôn ngữ lớn tạo văn bản từng token một. Ở mỗi bước, model tạo ra một điểm số, hay logit, cho mọi token trong từ vựng; sau đó, softmax chuyển các điểm số đó thành xác suất. Giải mã có ràng buộc thêm một thao tác trước khi lấy mẫu: các token không thể dẫn đến đầu ra hợp lệ được gán logit âm vô cực, khiến xác suất của chúng bằng không, còn xác suất của các token hợp lệ được chuẩn hóa lại.
import torch
# Raw next-token scores from a model over a toy vocabulary
vocab = ["approved", "rejected", "review", "maybe", "{", "}"]
logits = torch.tensor([1.2, 0.4, 0.9, 2.5, 0.1, 0.3])
# The schema allows only the three status labels at this position
allowed = torch.tensor([True, True, True, False, False, False])
masked_logits = logits.masked_fill(~allowed, float("-inf"))
# Softmax renormalizes probability over the valid tokens only
for name, raw, masked in zip(vocab, logits.softmax(-1), masked_logits.softmax(-1)):
print(f"{name:>9}: {raw:.2f} -> {masked:.2f}")Model không có ràng buộc phân bổ 56% xác suất cho “có thể”. Khi áp dụng mask, “có thể” giảm về không và ba nhãn được phép chia sẻ xác suất theo tỷ lệ điểm số ban đầu, khiến “đã phê duyệt” tăng từ 15% lên 46%.
Các inference engine production theo dõi trạng thái ràng buộc khi quá trình sinh diễn ra. Danh sách lựa chọn cố định hoặc biểu thức chính quy được biên dịch thành máy trạng thái hữu hạn. JSON và các định dạng lồng nhau khác cần ngữ pháp có ngăn xếp, vì dấu ngoặc nhọn đóng chỉ hợp lệ sau dấu ngoặc nhọn mở tương ứng. Sau mỗi token, decoder chuyển trạng thái và tính lại tập token được phép. Tokenization tạo ra các mảnh từ con có độ dài khác nhau, vì vậy một token duy nhất như "}, có thể bao quát nhiều bước ngữ pháp cùng lúc. Do đó, các thư viện tính trước những mục từ vựng hợp lệ ở mỗi trạng thái, giúp giảm chi phí cho từng token ngay cả với từ vựng hơn 100.000 token. Năm 2023, Brandon Willard và Rémi Louf mô tả cách lập chỉ mục này cho biểu thức chính quy và ngữ pháp phi ngữ cảnh trong Efficient Guided Generation for Large Language Models, bài báo làm nền tảng cho thư viện Outlines.
Chọn loại ràng buộc#
Ràng buộc phù hợp là ràng buộc khớp với đầu ra mà ứng dụng thực sự sử dụng. Danh sách lựa chọn phù hợp với phân loại và định tuyến, khi câu trả lời phải là một trong vài chuỗi. Biểu thức chính quy dùng cho các giá trị có cấu trúc ngắn như ngày tháng, ID và số điện thoại. Ngữ pháp phi ngữ cảnh mô tả SQL, mã và ngôn ngữ chuyên biệt theo miền; định dạng ngữ pháp GBNF của llama.cpp là một ví dụ được sử dụng rộng rãi. Với các bản ghi có trường được đặt tên, JSON Schema quy định khóa bắt buộc, kiểu dữ liệu, enum và cấu trúc lồng nhau. Các API được lưu trữ như OpenAI Structured Outputs chấp nhận schema và thực thi schema trong quá trình sinh, thường hỗ trợ một tập con được tài liệu hóa của toàn bộ đặc tả JSON Schema.
Giải mã có ràng buộc thường bị nhầm lẫn với các kỹ thuật gần giống:
- Đầu ra có cấu trúc: Mục tiêu rộng hơn là tạo phản hồi máy có thể đọc được, đạt được bằng cách giải mã có ràng buộc trong lúc sinh hoặc xác thực đầu ra sau đó và thử lại nếu thất bại.
- JSON mode: Ràng buộc đầu ra thành JSON hợp lệ về cú pháp với hình dạng bất kỳ, do đó vẫn cần kiểm tra khóa, kiểu dữ liệu và giá trị.
- Prompt engineering: Yêu cầu định dạng trong chỉ dẫn, điều mà các model thường làm theo. Các yêu cầu có ràng buộc schema thường cũng mô tả những trường trong prompt để model biết ý nghĩa của từng trường.
- Gọi hàm: Tên công cụ và đối số là những mục tiêu phổ biến nhất của ràng buộc schema, vì mã gọi công cụ yêu cầu chính xác tên trường.
Các đánh đổi trong thực tế#
Định dạng được bảo đảm không đồng nghĩa nội dung được bảo đảm chính xác. Schema có thể buộc {"total": 1290.00} phải là số, nhưng con số đó vẫn có thể sai; model có ràng buộc vẫn có thể ảo giác một cách trôi chảy trong các trường hợp lệ. Ứng dụng vẫn cần xác thực các quy tắc nghiệp vụ sau khi tạo sinh.
Ràng buộc cũng có thể làm giảm chất lượng câu trả lời khi khiến model đi chệch khỏi cách diễn đạt tự nhiên. Schema yêu cầu câu trả lời cuối cùng là trường đầu tiên sẽ không dành chỗ cho suy luận trung gian, vì vậy schema thường đặt trường suy luận hoặc ghi chú dạng văn bản tự do trước trường câu trả lời. Cũng cần chú ý đến độ dài đầu ra: nếu quá trình sinh chạm giới hạn token giữa chừng trong một object, kết quả sẽ không hợp lệ bất kể có ràng buộc hay không. Vì vậy, các yêu cầu có cấu trúc đặt độ dài tối đa với dư địa đủ cho toàn bộ cấu trúc. Schema rất lớn hoặc đệ quy sâu mất nhiều thời gian biên dịch hơn, điều này quan trọng với các hệ thống tạo schema mới cho mỗi yêu cầu.
Các ứng dụng thị giác sử dụng cùng cơ chế khi model đa phương thức cần trả về các trường mô tả hình ảnh. Giao diện LLM của Ultralytics chuyển tiếp nguyên trạng các đối số yêu cầu đến những API tương thích với OpenAI, vì vậy JSON Schema được truyền cùng yêu cầu có hình ảnh sẽ giới hạn câu trả lời của model thị giác-ngôn ngữ vào các trường như hazard và severity, sẵn sàng kết hợp với các phát hiện từ YOLO26 trên cùng khung hình.










