Automatic Prompt Engineer (APE) cho phép một mô hình ngôn ngữ viết, kiểm thử và lựa chọn prompt tốt nhất cho một tác vụ cụ thể, biến công việc vốn từng là một nghệ thuật dựa trên thử-và-sai thành một quá trình tìm kiếm dựa trên dữ liệu có thể lặp lại.

Tại sao việc viết prompt đã trở thành một nút thắt cổ chai

Prompt engineering—việc soạn thảo những câu chữ chính xác để chỉ dẫn mô hình phải làm gì—từ lâu đã là sự kết hợp giữa trực giác và may mắn. Những người thực hành sẽ tinh chỉnh một từ ở đây, thay đổi một cụm từ ở kia, chạy mô hình, và dừng lại khi kết quả đầu ra "có vẻ đúng". Cách tiếp cận này kéo dài thời gian, phụ thuộc vào trí tưởng tượng của kỹ sư và giới hạn hiệu suất. Trong môi trường vận hành thực tế (production), điều này đồng nghĩa với chu kỳ phát triển dài hơn, kết quả không ổn định và các chi phí ẩn chỉ xuất hiện sau khi triển khai.

Quy trình làm việc ba bước của APE

APE coi việc tạo prompt như một bài toán tìm kiếm. Người dùng cung cấp một tập hợp nhỏ các ví dụ đầu vào-đầu ra. Sau đó, hệ thống thực hiện ba giai đoạn tự động:

  1. Đề xuất (Propose) – Mô hình quét các ví dụ và đưa ra một loạt các chỉ dẫn ứng viên, chẳng hạn như “trả về kết quả ngược lại” hoặc “viết từ trái nghĩa”.
  2. Chấm điểm (Score) – Hệ thống chạy từng ứng viên trên một tập hợp các ví dụ chưa từng thấy và đếm xem có bao nhiêu câu trả lời khớp với đầu ra mong đợi, từ đó đưa ra một con số độ chính xác thô. Không có sự can thiệp của con người trong bước này.
  3. Lựa chọn (Select) – Chỉ dẫn có độ chính xác cao nhất sẽ trở thành prompt cuối cùng.

Vòng lặp này có thể lặp lại. Prompt chiến thắng sẽ trở thành hạt giống mới, và mô hình sẽ đề xuất các biến thể khác. Trong các lần chạy được báo cáo, một chỉ dẫn chung chung đạt 83% đã được tinh chỉnh thành một phiên bản đạt 100% trên tập kiểm thử.

Điều gì khiến phương pháp này mạnh mẽ hơn con người

  • Độ bao phủ (Coverage) – Một LLM có thể tạo ra hàng chục cách diễn đạt thay thế chỉ trong vài giây, nhiều hơn rất nhiều so với những gì một người có thể kiểm thử.
  • Tính khách quan (Objectivity) – Việc lựa chọn dựa trên độ chính xác có thể đo lường được, chứ không phải dựa trên việc câu chữ nghe có trau chuốt hay không. Một chỉ dẫn theo kiểu sách giáo khoa vẫn có thể thua một biến thể ngắn gọn, nghe có vẻ kỳ lạ nhưng mô hình lại hiểu tốt hơn.

Vì thước đo chấm điểm đến từ người dùng—thường là kiểm tra khớp chính xác hoặc một unit test—hệ thống có thể được điều chỉnh theo bất kỳ yêu cầu hạ nguồn nào, từ tạo mã nguồn đến phân tích cảm xúc.

Cái giá của sự tự động hóa

Sự đánh đổi ở đây là tài nguyên tính toán. Việc chấm điểm cho mọi ứng viên đòi hỏi rất nhiều lượt gọi mô hình, vì vậy giai đoạn phát triển sẽ tiêu tốn một lượng đáng kể dung lượng sử dụng API. APE coi chi phí đó là một khoản đầu tư một lần: một khi prompt tối ưu đã được xác định, bạn có thể tái sử dụng nó mãi mãi mà không tốn thêm chi phí.

Hai điều kiện tiên quyết cũng hạn chế việc áp dụng:

  • Các ví dụ đã được dán nhãn (Labeled examples) – Hệ thống cần một tập hợp các đầu vào và đầu ra chính xác mang tính đại diện.
  • Hàm chấm điểm (Scoring function) – Người dùng phải định nghĩa thế nào là “đúng” cho tác vụ của họ, cho dù đó là khớp chuỗi chính xác, một ngưỡng sai số số học, hay một bộ kiểm tra (validator) tùy chỉnh.

Những điểm mà ý tưởng này có thể vấp ngã

Nếu tập hợp ví dụ ban đầu quá nhỏ hoặc không mang tính đại diện, prompt được chọn có thể bị quá khớp (overfit) và thất bại khi sử dụng trong thực tế.

Những gì cần theo dõi tiếp theo

Công cụ này cung cấp một giải pháp thay thế: cung cấp một vài ví dụ, để mô hình lặp lại, và nhận được một prompt mà hệ thống xếp hạng cao nhất trong các lần thử. Bản demo có tại liên kết trong thông báo gốc, và một cộng đồng học tập đang tập hợp trên Telegram.

Bài học rút ra: Tự động hóa prompt engineering giúp thay thế việc đoán mò bằng hiệu suất có thể đo lường được, nhưng nó đòi hỏi dữ liệu ban đầu, tài nguyên tính toán và một định nghĩa thành công rõ ràng.