Học câu lệnh hệ thống: mô hình mới cho các hệ thống AI

Bạn đã bao giờ thấy một câu lệnh vốn hoạt động tốt bỗng nhiên không còn hiệu quả chưa?

Bạn đã bao giờ mắc kẹt trong vòng lặp liên tục vá câu lệnh hệ thống để cải thiện kết quả nhưng rồi nhận ra chẳng cách nào hiệu quả chưa?

Học câu lệnh hệ thống có thể chính là điều bạn cần.

Học câu lệnh hệ thống (SPL) là một lĩnh vực mới nổi đang được cộng đồng AI quan tâm và đã được Andrej Karpathy phổ biến rộng rãi trên X vào tháng 5.

Học câu lệnh hệ thống khắc phục những hạn chế của các hệ thống AI cứng nhắc, dễ lỗi vốn phụ thuộc vào câu lệnh hệ thống tĩnh hoặc quy trình tinh chỉnh cồng kềnh. Đây là một cách khác để hỗ trợ khả năng học hỏi liên tục trong các hệ thống AI.

Trước khi đi sâu hơn, hãy cùng điểm nhanh một số kiến thức cơ bản về cách tạo câu lệnh.

Khi phát triển một tác nhân hoặc mô hình tùy chỉnh, trước tiên chúng ta phải thiết kế hai thành phần chính:

1. Câu lệnh hệ thống

2. Câu lệnh người dùng

Câu lệnh hệ thống thiết lập các quy tắc nền tảng về cách mô hình nên hành xử. Khi được viết cho các giải pháp AI tùy chỉnh, chúng thường bắt đầu như sau:

“You are an intelligent assistant. Your role is to perform <insert task here>.

You must not do (A), (B), or (C).”

Ngược lại, câu lệnh người dùng thường chứa yêu cầu của người dùng và các thông tin liên quan khác, chẳng hạn như múi giờ và tùy chọn của họ. Một câu lệnh người dùng có thể như sau:

I’m in the capital city of Portugal. Can you suggest some things I can do tonight?

Tình trạng rò rỉ câu lệnh hệ thống đã trở nên phổ biến sau khi các phòng thí nghiệm AI lớn phát hành mô hình mới, do người dùng bẻ khóa chatbot để làm lộ các chỉ dẫn nền tảng. Hiện nay, một kho lưu trữ GitHub phổ biến đã tập hợp nhiều câu lệnh hệ thống này tại một nơi. Chúng hé lộ “bí quyết” mà các phòng thí nghiệm AI đã phát triển theo thời gian để khuyến khích mô hình hành xử phù hợp. Ví dụ, câu lệnh hệ thống GPT-5 bị rò rỉ gần đây (được phát hiện trong ChatGPT) dài khoảng 6.000 từ, cho thấy lượng kiến thức và hướng dẫn cần được mã hóa để định hình hành vi của hệ thống.

Những câu lệnh hệ thống toàn diện này thường đề cập đến một số lĩnh vực chính như:

• Hướng dẫn tìm kiếm

• Định nghĩa công cụ

• Tùy chọn của người dùng

• Hướng dẫn trích dẫn

• Các bản vá nhanh cho những vấn đề đã biết

Trong thực tế, khi kiểm thử và hoàn thiện ứng dụng, các nhà phát triển hệ thống AI tùy chỉnh sẽ lặp lại việc vá thủ công câu lệnh hệ thống, chủ yếu dùng các bài đánh giá để định hướng quá trình cải tiến.

Các cách khác để định hướng hành vi của mô hình gồm:

• Kỹ thuật tạo câu lệnh, bao gồm tạo sinh tăng cường truy xuất (RAG), giúp kiểm soát nội dung được cung cấp cho mô hình

• Tinh chỉnh (thay đổi trực tiếp các trọng số nền tảng của mô hình)

Nếu có một cách khác để tác động đến hành vi của mô hình thì sao? Hãy hình dung một hệ thống có thể tự động học hỏi và hoàn thiện câu lệnh hệ thống của chính mình bằng những suy nghĩ, kế hoạch và chiến lược đã tạo trước đó. Hệ thống có thể dựa vào cả phản hồi của người dùng lẫn đánh giá LLM đóng vai trò giám khảo để thẩm định đầu ra.

Hãy nghĩ đến một thách thức kinh doanh dai dẳng mà bạn muốn tự động hóa bằng một hệ thống có tính tác nhân. Các giải pháp hiệu quả đòi hỏi khả năng suy luận vượt xa mức tự động hóa quy trình cơ bản. Trong những trường hợp như vậy, việc tích hợp một thành phần tạo kế hoạch vào hệ thống AI là điều thiết yếu. Nhờ đó, tùy theo tác vụ, hệ thống có thể làm việc với nhiều tác nhân theo những cách khác nhau. Từng bước có thể bao gồm chỉ dẫn truy cập các tác nhân khác để hoàn thành tác vụ con hoặc sử dụng công cụ.

Lưu ý: Công cụ của tác nhân là bất kỳ hàm, API hoặc tài nguyên bên ngoài nào mà tác nhân AI có thể gọi để vượt ra ngoài văn bản và thực hiện hành động thực tế.

Bạn có thể chọn “khởi tạo” câu lệnh hệ thống của mô hình bằng một kế hoạch tuân theo các bước logic mà con người sẽ thực hiện, dù LLM thường cần hướng dẫn cụ thể hơn về cách dùng công cụ, định dạng đầu ra và những yêu cầu liên quan. Đôi khi, chiến lược tối ưu có thể chưa rõ ràng, hoặc bạn đang xử lý một vấn đề chưa được đánh giá lại vì trước đây từng được xem là đã giải quyết xong. Đây chính là lúc học câu lệnh hệ thống (SPL) phát huy tác dụng.

SPL cải thiện câu lệnh hệ thống qua nhiều vòng lặp bằng cách tích hợp các chiến lược đã tạo trước đó. Khi vấn đề mới phát sinh, hệ thống dần tích lũy kiến thức và trở nên vững chắc hơn. Có thể hình dung đây là quá trình xây dựng một cẩm nang giải quyết các vấn đề trong lĩnh vực của bạn.

SPL dần tích hợp những hiểu biết rút ra từ phản hồi của người dùng vào câu lệnh hệ thống. Khi hệ thống trưởng thành, bạn có thể phát hiện những vấn đề lặp lại để chắt lọc thành các nguyên tắc tổng quát hơn, ở cấp độ cao hơn.

Hãy xem xét kỹ hơn cách quy trình vận hành qua từng bước:

1. Bắt đầu bằng yêu cầu của người dùng, trong đó đề nghị hệ thống thực hiện một tác vụ cụ thể.

2. 1. Nếu hệ thống chỉ xử lý một vấn đề, bạn có thể dùng phương pháp “tham lam” bằng cách chọn những chiến lược có điểm cao nhất từ các lần chạy trước. Ngoài ra, bạn có thể khuyến khích khám phá bằng cách lấy mẫu từ một phân phối ưu tiên các chiến lược được đánh giá cao nhưng đôi lúc vẫn chọn chiến lược có điểm thấp hơn. Cách này đặc biệt hữu ích khi bạn mới bắt đầu thu thập chiến lược.

   2. Với các hệ thống được thiết kế để xử lý nhiều nhóm vấn đề, hãy cân nhắc thêm một lớp phân loại hoặc dùng vector nhúng và độ tương đồng cosin (những kỹ thuật thường dùng trong RAG) để xác định phương pháp phù hợp. Điều này giúp bạn chọn chiến lược phù hợp với từng vấn đề cụ thể, chẳng hạn như chiến lược dành riêng cho tác vụ lập trình.

Lưu ý: Vector nhúng khi dùng cùng độ tương đồng cosin cho phép đo mức độ liên quan giữa hai mẩu thông tin, giúp dễ dàng ghép tài liệu, truy vấn hoặc ý tưởng ngay cả khi cách diễn đạt không hoàn toàn giống nhau.

Ví dụ về điểm khởi đầu của một kho chiến lược đơn giản để xử lý các vấn đề lập trình.

Lưu ý: Các “chiến lược khởi tạo” ở đây chỉ mang tính minh họa. Trong các tình huống lập trình thực tế, chúng ta sẽ tiếp tục hoàn thiện chúng. Những vấn đề kinh doanh đặc thù sẽ đòi hỏi thu thập thêm hiểu biết theo thời gian.

3. Sau khi lấy mẫu N, hãy tích hợp chúng vào câu lệnh hệ thống. Nhờ vậy, quá trình tạo kế hoạch dựa trên phản hồi chuyên môn trước đó thay vì để mô hình lập kế hoạch với rất ít chỉ dẫn. Khuyến khích mô hình “tư duy đột phá” và bổ sung bước khi cần thay vì chỉ sao chép nguyên văn các chiến lược mẫu.

4. Với câu lệnh hệ thống được tạo tự động, hãy xây dựng một chiến lược mới để xử lý yêu cầu của người dùng. Quy trình này sẽ tạo ra các tác vụ bổ sung giúp cải thiện đầu ra cuối cùng. Mục tiêu là sự sáng tạo: kết hợp những yếu tố tốt nhất của các chiến lược trước, hợp nhất các bước trùng lặp và bổ sung những bước mới hữu ích khi cần.

Lưu ý: Hãy nhớ rằng nhiệt độ là một tham số có thể điều chỉnh để tạo ra đầu ra đa dạng hơn, ít mang tính tất định hơn, rất hữu ích khi cần sự sáng tạo. Khi nhiệt độ khác 0, mỗi kế hoạch được tạo ra có thể khác nhau.

5. Sau khi nhận đầu ra của mô hình, hãy nhờ người đánh giá hoặc LLM giám khảo thẩm định theo các tiêu chí cụ thể xác định thế nào là một giải pháp tốt cho vấn đề của bạn. Đối với ví dụ về các hoạt động ở Portugal đã nêu, tiêu chí đánh giá có thể gồm:

• Tính súc tích (câu trả lời chỉ gồm một câu)

• Mức độ phù hợp của hoạt động được đề xuất

• Độ chính xác về địa điểm

6. Dựa trên đánh giá này, hãy dùng một mô hình khác để hoàn thiện chiến lược. Một vòng lặp phản hồi tùy chọn có thể tiếp nhận ý kiến con người và hỗ trợ cải tiến cộng tác. Lưu chiến lược đã hoàn thiện vào cơ sở dữ liệu cùng siêu dữ liệu phù hợp để theo dõi các phiên bản và thay đổi.

Vậy tại sao phải tốn công làm tất cả những việc này? Bạn có thể xem xét đầu ra theo cách thủ công rồi điều chỉnh câu lệnh hệ thống cho phù hợp. Tuy nhiên, các mô hình suy luận mạnh có thể hoàn thiện chiến lược dựa trên cả ngữ cảnh đầu ra lẫn phản hồi của con người. Con người có thể dễ dàng phát hiện thiếu sót trong các phương pháp đơn giản, nhưng việc nhận diện chúng sẽ trở nên khó khăn và nhàm chán trong những hệ thống phức tạp xử lý nhiều nhóm vấn đề hơn.

LLM thường cần chỉ dẫn chi tiết và các bước bổ sung để thu thập kiến thức ngữ cảnh mà con người vốn tự nhiên vận dụng khi giải quyết vấn đề. Số lượng tác vụ cần thiết có thể tăng nhanh khi hệ thống mở rộng để xử lý nhiều nhóm vấn đề hơn. Ví dụ, khi xử lý vấn đề lập trình, con người có thể hiểu cơ sở mã xung quanh theo trực giác, còn LLM có thể phải “đọc” nhiều tệp trước.

• Khi hữu ích: Giả sử bạn điều hành một nhóm hỗ trợ khách hàng và một tác nhân AI phụ trách phân loại phiếu yêu cầu. Theo thời gian, SPL có thể khám phá ra một phương pháp phân loại mà nhóm của bạn chưa từng cân nhắc, qua đó giảm tỷ lệ chuyển cấp.

• Khi không hữu ích: Nếu các yêu cầu tuân thủ hoặc quy định đã xác định sẵn quy trình làm việc, chẳng hạn như báo cáo tài chính, SPL có thể không mang lại nhiều giá trị vì sự sáng tạo trở thành rủi ro thay vì lợi thế.

• Khi hữu ích: Trong các vai trò đòi hỏi nhiều nghiên cứu (như tình báo thị trường hoặc chiến lược sản phẩm), bạn có thể cộng tác với AI bằng cách hoàn thiện kế hoạch, làm phong phú đầu ra và tích hợp các cải tiến này để dùng trong tương lai. Mỗi lượt tương tác đều nâng cao hiệu quả của hệ thống.

• Khi không hữu ích: Nếu nhóm của bạn chủ yếu dùng AI cho các quy trình đơn giản, ít cần con người tham gia (ví dụ: xử lý hóa đơn), chi phí cộng tác có thể lớn hơn lợi ích.

• Khi hữu ích: Giả sử bạn mở rộng sang một khu vực mới và AI đột nhiên phải xử lý các câu hỏi về thuế địa phương. SPL cho phép bạn nhanh chóng mã hóa các quy tắc và phương pháp kinh nghiệm mới ngay khi chúng xuất hiện, giúp ngăn lỗi lặp lại.

• Khi không hữu ích: Nếu môi trường của bạn không thay đổi, chẳng hạn như chuyển biên bản cuộc họp thành bản tóm tắt chuẩn hóa, việc liên tục thích ứng chỉ mang lại lợi ích tối thiểu.

Về lý thuyết, tất cả điều này nghe rất hứa hẹn, nhưng việc triển khai SPL đặt ra những thách thức thực tế. Dưới đây là một số thách thức chính:

Trong giai đoạn đầu tạo chiến lược, tiến độ thường đình trệ: đầu ra mới không kế thừa được kết quả trước đó và đà cải tiến chậm lại. Tình trạng này thường bắt nguồn từ hai vấn đề chính:

• • Giải pháp: Mã hóa trước toàn bộ kiến thức kinh doanh hiện có để hệ thống có đủ chiều sâu làm nền tảng.

• • Giải pháp: Thiết kế một thang điểm tinh tế để đánh giá nhiều khía cạnh của câu trả lời, như độ chính xác, rõ ràng và phù hợp; đồng thời điều chỉnh cách lấy mẫu theo các tín hiệu này.

Nếu hệ thống tạo ra hàng trăm chiến lược nhưng nhận được quá ít phản hồi để phân biệt tốt xấu, việc lấy mẫu sẽ nhanh chóng trở nên cồng kềnh. Giải pháp là cắt tỉa.

Khi hoàn thiện kho chiến lược, hãy cân nhắc:

• Tuổi thọ: Loại bỏ chiến lược khi đã vượt quá khoảng thời gian hoặc số thế hệ được xác định.

• Điểm số: Dùng thang điểm đánh giá để loại bỏ những chiến lược liên tục có hiệu suất thấp. Kết hợp tiêu chí này với tuổi thọ sẽ đảm bảo bạn chỉ giữ lại những phương pháp chứng minh được giá trị theo thời gian.

• LLM đánh giá: Định kỳ thẩm định các chiến lược để xác định những chiến lược không còn mang lại góc nhìn độc đáo, vì các yếu tố hữu ích của chúng có thể đã được tích hợp vào phiên bản mới hơn.

Giải pháp: Hãy coi cơ sở dữ liệu chiến lược là một hệ thống sống: thường xuyên cắt tỉa để chỉ giữ lại kiến thức phù hợp, có giá trị cao.

Học câu lệnh hệ thống vẫn đang ở giai đoạn sơ khai, nhưng tiềm năng rất lớn. Các doanh nghiệp chỉ dựa vào câu lệnh tĩnh hoặc tinh chỉnh vô tận sẽ gặp những hạn chế quen thuộc: hệ thống mong manh, chi phí gia tăng và công sức lãng phí. SPL mang đến lối thoát khỏi vòng lặp đó bằng cách xây dựng những hệ thống cải thiện theo thời gian và mã hóa các nguyên tắc cấp cao thay vì những bản vá riêng lẻ.

SPL vẫn đang phát triển, nhưng xu hướng đã rõ: những hệ thống có thể tự học hỏi sẽ vượt xa những hệ thống không thể. Đây là lúc thử nghiệm, bắt đầu từ quy mô nhỏ, ghi lại bài học và xây dựng nền tảng cho những hệ thống AI tiến bộ sau mỗi lượt tương tác.