Giới hạn không gian đầu ra để tối ưu hóa tự động hóa hẹp cho SLM

Constraining Output Space for SLM Narrow Automation Optimization - KDnuggets Blog Bài viết hàng đầu Giới thiệu Chủ đề AI Lời khuyên nghề nghiệp Thị giác máy tính Kỹ thuật dữ liệu Khoa học dữ liệu Mô hình ngôn ngữ Học máy MLOps Xử lý ngôn ngữ tự nhiên (NLP) Lập trình Python SQL Bộ dữ liệu Sự kiện Tài nguyên Tóm tắt nhanh Đề xuất Bản tin công nghệ Quảng cáo Tham gia Bản tin Hạn chế không gian đầu ra để tối ưu hóa tự động hóa hẹp cho SLM Bài viết này sẽ mở đầu một loạt bài về tối ưu hóa tự động hóa hẹp cho các mô hình ngôn ngữ nhỏ (SLM). Là bài viết đầu tiên, nó sẽ đề cập đến một trong những kỹ thuật hữu ích nhất để thực hiện điều này: hạn chế không gian đầu ra thay vì phân tích cú pháp văn bản được tạo ra. Bởi Matthew Mayo, Biên tập viên quản lý của KDnuggets vào ngày 13/8/2026 trong chuyên mục Mô hình ngôn ngữ Phần lớn sự chú ý trong AI ứng dụng tập trung vào khả năng suy luận quy mô tiên tiến. Tuy nhiên, một phần lớn nhu cầu khối lượng công việc sản xuất thực tế trong ngành lại ít hào nhoáng hơn: tự động hóa hẹp. Các tác vụ thuộc loại này bao gồm định tuyến chính xác một phiếu hỗ trợ, trích xuất một trường từ biểu mẫu, gắn thẻ tài liệu và đánh dấu một bản ghi để con người xem xét. Các tác vụ này đều có những đặc điểm chung: đầu vào bị hạn chế, không gian đầu ra cố định và khối lượng cuộc gọi khổng lồ. Chúng cũng chính xác là những loại tác vụ rất phù hợp với các mô hình ngôn ngữ nhỏ (SLM). Một mô hình có thể chạy thoải mái trên một GPU, hoặc thậm chí bị giới hạn bởi CPU, và có khả năng trả về câu trả lời trong mili giây thường là lựa chọn kỹ thuật đúng đắn hơn so với việc gọi API tới một mô hình ngôn ngữ lớn (LLM) có thể tốn kém gấp hàng nghìn lần cho mỗi mục. Vấn đề là các nhóm có xu hướng mang thói quen sử dụng mô hình tiên tiến sang các mô hình nhỏ. Họ viết các lời nhắc hội thoại dài và để mô hình tạo văn bản tự do trước khi tìm kiếm thông tin trong đó bằng các biểu thức chính quy. Họ gọi mô hình từng lần một từ bên trong một vòng lặp Python. Đối với một SLM cục bộ, những loại kém hiệu quả này càng trở nên rõ rệt: khi một lần truyền tiến (forward pass) mất mười mili giây, mọi thứ bạn bao bọc xung quanh lần truyền tiến đó đều trở thành nút thắt cổ chai; việc xử lý đầu ra lỏng lẻo trực tiếp biến thành tỷ lệ lỗi có thể đo lường được. Bài viết này sẽ mở đầu một loạt bài về tối ưu hóa tự động hóa hẹp cho các SLM. Là bài viết đầu tiên, nó sẽ đề cập đến một trong những kỹ thuật hữu ích nhất để thực hiện điều này: hạn chế không gian đầu ra thay vì phân tích cú pháp văn bản được tạo ra. Để thiết lập một sân chơi bình đẳng, tất cả các điểm chuẩn dưới đây đều sử dụng Qwen2.5-0.5B-Instruct ở định dạng float16 thông qua Hugging Face Transformers, chạy trên M2 Macbook Air với 24GB RAM và Neural Engine 16 lõi. Đầu tiên, thiết lập môi trường Python và cài đặt các yêu cầu: pip install torch transformers accelerate # Tại sao phải hạn chế không gian đầu ra? Một tác vụ phân loại có một tập hợp câu trả lời cố định. Nếu bạn đang định tuyến các phiếu hỗ trợ vào các danh mục thanh toán, kỹ thuật hoặc tài khoản, thì chỉ có chính xác ba đầu ra hợp lệ và không có đầu ra nào khác. Tuy nhiên, mô hình tiêu chuẩn là yêu cầu mô hình viết câu trả lời, tạo ra một vài token, sau đó tìm kiếm trong chuỗi kết quả để tìm thứ gì đó có thể nhận dạng được. Điều này thất bại đồng thời ở hai khía cạnh. Thứ nhất, nó chậm: hàm `generate()` chạy một lượt chuyển tiếp tuần tự cho mỗi token đầu ra, vì vậy việc yêu cầu tám token tốn kém tính toán gấp khoảng tám lần so với việc yêu cầu câu trả lời trực tiếp. Thứ hai, nó không đáng tin cậy: một mô hình nhỏ sẽ vui vẻ trả lời "Chắc chắn rồi! Đây có vẻ là vấn đề thanh toán.", hoặc "Thanh toán/Tài khoản", hoặc một danh mục mà bạn chưa từng định nghĩa. Mỗi phản hồi đó đều yêu cầu một quy tắc dự phòng hoặc một lần thử lại, và mỗi quy tắc dự phòng là một nơi tích lũy lỗi. Giải pháp là ngừng tạo và bắt đầu chấm điểm. Chạy một lượt chuyển tiếp, đọc phân phối token tiếp theo của mô hình và giới hạn quyết định của bạn trong các ID token của các nhãn ứng cử viên. Câu trả lời trở nên không thể sai về mặt cấu trúc, và bạn nhận được một điểm tin cậy đã được hiệu chỉnh như một sản phẩm phụ. # Phân tích văn bản tự do Đây là phiên bản đơn giản, tạo văn bản tự do và phân tích nó sau đó. Lưu nó vào tệp và chạy từ dòng lệnh. ```python import os import time import torch from transformers import AutoTokenizer, AutoModelForCausalLM MODEL_ID = "Qwen/Qwen2.5-0.5B-Instruct" torch.set_num_threads(os.cpu_count() or 1) tokenizer = AutoTokenizer.from_pretrained(MODEL_ID) if tokenizer.pad_token is None: tokenizer.pad_token = tokenizer.eos_token model = AutoModelForCausalLM.from_pretrained(MODEL_ID, dtype=torch.float32) model.eval() # dữ liệu thử nghiệm của chúng ta để phân loại (600 bản ghi) LABELS = ["billing", "technical", "account"] tickets = [ "My card was charged twice for the same invoice.", "The mobile app crashes whenever I open the settings page.", "I need to change the email address on my profile.", ] * 200 def build_prompt(ticket): messages = [ { "role": "system", "content": "You classify support tickets. Answer with exactly one of: billing, technical, account.", }, {"role": "user", "content": f"Ticket: {ticket}\nCategory:"}, ] return tokenizer.apply_chat_template( messages, tokenize=False, add_generation_prompt=True ) # không có gì ràng buộc đầu ra ở đây, vì vậy chúng ta để mô hình viết một câu trả lời ngắn và tìm kiếm nhãn trong đó (tăng token) # mỗi token mới tốn một lượt chuyển tiếp riêng, và một ticket mỗi lần gọi có nghĩa là không có batching để bù đắp chi phí đó (tăng thời gian) prompts = [build_prompt(t) for t in tickets] predictions = [] # thời gian suy luận start = time.time() for n, prompt in enumerate(prompts, start=1): # vòng lặp này chạy trong nhiều phút trên CPU, vì vậy hãy báo cáo tiến độ thay vì im lặng if n % 50 == 0: rate = (time.time() - start) / n print(f" {n}/{len(prompts)} tickets ({rate:.2f}s each)", flush=True) inputs = tokenizer(prompt, return_tensors="pt").to(model.device) with torch.inference_mode(): output = model.generate( **inputs, max_n ```