Phát triển dựa trên đánh giá

Khi bạn tạo câu lệnh cho các ứng dụng thực tế, một điểm đánh đổi quan trọng sẽ xuất hiện: cân bằng giữa tính ngắn gọn và hiệu quả. Khi tất cả các yếu tố đều bằng nhau, một câu lệnh ngắn gọn sẽ nhanh hơn, rẻ hơn và dễ duy trì hơn so với một câu lệnh dài hơn. Điều này đặc biệt phù hợp trong môi trường web, nơi độ trễ và giới hạn mã thông báo có vai trò quan trọng. Tuy nhiên, nếu câu lệnh của bạn quá ngắn gọn, mô hình có thể thiếu ngữ cảnh, hướng dẫn hoặc ví dụ để tạo ra kết quả chất lượng cao.

Phát triển dựa trên đánh giá (EDD) cho phép bạn theo dõi và tối ưu hoá sự đánh đổi này một cách có hệ thống. EDD cung cấp một quy trình có thể lặp lại và kiểm thử để cải thiện kết quả theo các bước nhỏ và chắc chắn, phát hiện các trường hợp hồi quy và điều chỉnh hành vi của mô hình cho phù hợp với kỳ vọng của người dùng và sản phẩm theo thời gian.

Hãy xem đây là phát triển dựa trên thử nghiệm (TDD), được điều chỉnh cho phù hợp với sự không chắc chắn của AI. Không giống như các kiểm thử đơn vị xác định, bạn không thể mã hoá cứng các quy trình đánh giá AI vì đầu ra (cả đầu ra có dạng thức đúng và đầu ra không thành công) có thể có dạng thức không lường trước được.

Hình 1: Trong EDD, bạn xác định vấn đề, khởi tạo đường cơ sở, đánh giá và tối ưu hoá. Tiếp tục đánh giá và tối ưu hoá cho đến khi quy trình hoàn tất.

EDD cũng hỗ trợ nỗ lực khám phá của bạn. Giống như việc viết các bài kiểm thử giúp làm rõ hành vi của một tính năng, việc xác định tiêu chí đánh giá và xem xét đầu ra của mô hình buộc bạn phải đối mặt với sự thiếu rõ ràng và dần dần thêm nhiều chi tiết cũng như cấu trúc hơn vào các tác vụ mở hoặc không quen thuộc.

Xác định vấn đề

Bạn có thể trình bày vấn đề của mình như một hợp đồng API, bao gồm loại đầu vào, định dạng đầu ra và mọi ràng buộc bổ sung. Ví dụ:

  • Loại dữ liệu đầu vào: bản nháp bài đăng trên blog
  • Định dạng đầu ra: Mảng JSON có 3 tiêu đề bài đăng
  • Quy tắc ràng buộc: ít hơn 128 ký tự, sử dụng giọng điệu thân thiện

Sau đó, hãy thu thập các ví dụ về dữ liệu đầu vào. Để đảm bảo tính đa dạng của dữ liệu, bạn cần đưa cả ví dụ lý tưởng và dữ liệu đầu vào thực tế, lộn xộn. Hãy nghĩ đến các biến thể và trường hợp đặc biệt, chẳng hạn như bài đăng có biểu tượng cảm xúc, cấu trúc lồng nhau và nhiều đoạn mã.

Khởi tạo đường cơ sở

Viết câu lệnh đầu tiên. Bạn có thể bắt đầu bằng zero-shot và bao gồm:

  • Hướng dẫn rõ ràng
  • Định dạng đầu ra
  • Phần giữ chỗ cho biến đầu vào

Bạn tăng độ phức tạp và làm việc với các thành phần khác cũng như các kỹ thuật tạo câu lệnh nâng cao khi đánh giá và tối ưu hoá. Trước tiên, chúng ta cần thiết lập một hệ thống đánh giá để định hướng nỗ lực tối ưu hoá theo đúng hướng.

Tạo hệ thống đánh giá

Trong TDD, bạn bắt đầu viết các bài kiểm thử sau khi biết các yêu cầu. Với AI tạo sinh, không có kết quả đầu ra cụ thể để kiểm thử, vì vậy, bạn cần nỗ lực hơn để tạo vòng lặp đánh giá.

Bạn có thể cần nhiều công cụ đo lường để đánh giá một cách hiệu quả.

Xác định các chỉ số đánh giá

Các chỉ số đánh giá có thể mang tính xác định. Ví dụ: bạn có thể kiểm tra xem mô hình có trả về JSON hợp lệ hay xuất ra đúng số lượng mục hay không.

Tuy nhiên, bạn nên dành nhiều thời gian để xác định và tinh chỉnh các chỉ số chủ quan hoặc định tính, chẳng hạn như độ rõ ràng, mức độ hữu ích, giọng điệu hoặc tính sáng tạo. Bạn có thể bắt đầu với các mục tiêu chung chung nhưng nhanh chóng gặp phải những vấn đề phức tạp hơn.

Ví dụ: giả sử trình tạo tiêu đề của bạn sử dụng quá nhiều cụm từ hoặc mẫu nhất định, dẫn đến kết quả lặp đi lặp lại và khô khan. Trong trường hợp đó, bạn nên xác định các chỉ số mới để khuyến khích sự đa dạng và ngăn chặn việc sử dụng quá nhiều cấu trúc hoặc từ khoá. Theo thời gian, các chỉ số chính của bạn sẽ ổn định và bạn có thể theo dõi những điểm cải thiện.

Quy trình này có thể được hưởng lợi từ những chuyên gia hiểu rõ thế nào là tốt trong miền của ứng dụng và có thể phát hiện các chế độ lỗi tinh vi. Ví dụ: nếu bạn đang phát triển một trợ lý viết, hãy hợp tác với một nhà sản xuất nội dung hoặc biên tập viên để đảm bảo việc đánh giá của bạn phù hợp với quan điểm của họ.

Chọn người đánh giá

Các tiêu chí đánh giá khác nhau đòi hỏi các chuyên gia đánh giá khác nhau:

  • Các quy trình kiểm tra dựa trên mã hoạt động hiệu quả đối với các kết quả đầu ra dựa trên quy tắc hoặc mang tính xác định. Ví dụ: bạn có thể quét tiêu đề để tìm những từ bạn muốn tránh, kiểm tra số lượng ký tự hoặc xác thực cấu trúc JSON. Đây là những thành phần nhanh, có thể lặp lại và hoàn hảo cho các phần tử giao diện người dùng có đầu ra cố định, chẳng hạn như nút hoặc trường biểu mẫu.
  • Ý kiến phản hồi của con người là yếu tố cần thiết để đánh giá những khía cạnh mang tính chủ quan hơn, bao gồm cả giọng điệu, độ rõ ràng hoặc mức độ hữu ích. Đặc biệt là trong giai đoạn đầu, việc tự xem xét kết quả đầu ra của mô hình (hoặc với các chuyên gia trong lĩnh vực) cho phép bạn nhanh chóng lặp lại. Tuy nhiên, phương pháp này không hiệu quả. Sau khi chạy ứng dụng, bạn cũng có thể thu thập các tín hiệu trong ứng dụng, chẳng hạn như điểm xếp hạng bằng sao, nhưng những tín hiệu này thường không rõ ràng và thiếu sắc thái cần thiết để tối ưu hoá chính xác.
  • LLM-as-judge (LLM dưới vai trò là người đánh giá) cung cấp một cách thức có thể mở rộng để đánh giá các tiêu chí chủ quan bằng cách sử dụng một mô hình AI khác để chấm điểm hoặc phê bình các kết quả. Quy trình này nhanh hơn quy trình đánh giá thủ công, nhưng không phải là không có cạm bẫy: trong một quy trình triển khai đơn giản, quy trình này có thể duy trì và thậm chí củng cố những điểm thiên vị và thiếu hụt kiến thức của mô hình.

Ưu tiên chất lượng hơn số lượng. Trong công nghệ học máy và AI dự đoán truyền thống, việc sử dụng nguồn lực cộng đồng để chú thích dữ liệu là một phương pháp phổ biến. Đối với AI tạo sinh, người chú thích từ cộng đồng thường thiếu ngữ cảnh về miền. Việc đánh giá chất lượng cao và giàu ngữ cảnh quan trọng hơn quy mô.

Đánh giá và tối ưu hoá

Bạn càng nhanh chóng kiểm thử và tinh chỉnh câu lệnh thì bạn càng sớm đạt được kết quả phù hợp với kỳ vọng của người dùng. Bạn cần tạo thói quen tối ưu hoá liên tục. Hãy thử cải thiện, đánh giá rồi thử một cách khác.

Sau khi phát hành công khai, hãy tiếp tục quan sát và đánh giá hành vi của người dùng và hệ thống AI. Sau đó, hãy phân tích và chuyển đổi dữ liệu này thành các bước tối ưu hoá.

Tự động hoá quy trình đánh giá

Để giảm bớt khó khăn trong nỗ lực tối ưu hoá, bạn cần có cơ sở hạ tầng vận hành giúp tự động hoá việc đánh giá, theo dõi các thay đổi và kết nối quá trình phát triển với quá trình sản xuất. Đây thường được gọi là LLMOps. Mặc dù có những nền tảng có thể giúp bạn tự động hoá, nhưng bạn nên thiết kế quy trình công việc lý tưởng trước khi cam kết sử dụng một giải pháp của bên thứ ba.

Sau đây là một số thành phần chính cần cân nhắc:

  • Phân phiên bản: Lưu trữ các lời nhắc, chỉ số đánh giá và dữ liệu đầu vào kiểm thử trong tính năng kiểm soát phiên bản. Hãy coi chúng là mã để đảm bảo khả năng tái tạo và nhật ký thay đổi rõ ràng.
  • Đánh giá hàng loạt tự động: Sử dụng quy trình công việc (chẳng hạn như GitHub Actions) để chạy các quy trình đánh giá trên mỗi bản cập nhật câu lệnh và tạo báo cáo so sánh.
  • CI/CD cho câu lệnh: Triển khai cổng bằng các quy trình kiểm tra tự động, chẳng hạn như kiểm thử xác định, điểm số LLM-as-judge hoặc các biện pháp bảo vệ và chặn các thao tác hợp nhất khi chất lượng giảm sút.
  • Ghi nhật ký và khả năng quan sát trong quá trình sản xuất: Ghi lại dữ liệu đầu vào, đầu ra, lỗi, độ trễ và mức sử dụng mã thông báo. Theo dõi sự sai lệch, các mẫu không mong muốn hoặc sự gia tăng đột biến về số lần thất bại.
  • Thu thập ý kiến phản hồi: Thu thập tín hiệu của người dùng (lượt thích, lượt viết lại, lượt bỏ qua) và biến các vấn đề định kỳ thành các trường hợp kiểm thử mới.
  • Theo dõi thử nghiệm: Theo dõi các phiên bản câu lệnh, cấu hình mô hình và kết quả đánh giá.

Lặp lại với những thay đổi nhỏ, có mục tiêu

Việc tinh chỉnh câu lệnh thường bắt đầu bằng cách cải thiện ngôn ngữ của câu lệnh. Điều này có thể có nghĩa là bạn cần đưa ra hướng dẫn cụ thể hơn, làm rõ ý định hoặc loại bỏ sự mơ hồ.

Hãy cẩn thận để không điều chỉnh quá mức. Lỗi thường gặp là thêm các quy tắc quá hẹp để khắc phục các vấn đề về mô hình vá. Ví dụ: nếu trình tạo tiêu đề của bạn liên tục tạo ra những tiêu đề bắt đầu bằng cụm từ Hướng dẫn toàn diện, bạn có thể muốn cấm cụm từ này một cách rõ ràng. Thay vào đó, hãy trừu tượng hoá vấn đề và điều chỉnh chỉ dẫn cấp cao hơn. Điều này có thể có nghĩa là bạn nhấn mạnh tính độc đáo, sự đa dạng hoặc một phong cách biên tập cụ thể, vì vậy, mô hình sẽ học được lựa chọn ưu tiên cơ bản thay vì một trường hợp ngoại lệ duy nhất.

Một cách khác là thử nghiệm thêm các kỹ thuật tạo câu lệnh và kết hợp những nỗ lực này. Khi bạn chọn một kỹ thuật, hãy tự hỏi: liệu nhiệm vụ này có được giải quyết tốt nhất thông qua phép loại suy (few-shot), lập luận từng bước (chuỗi suy luận) hay tinh chỉnh lặp đi lặp lại (tự phản ánh)?

Khi hệ thống của bạn đi vào hoạt động, vòng quay EDD sẽ không bị chậm lại. Nếu có thì nó sẽ tăng tốc. Nếu hệ thống của bạn xử lý và ghi nhật ký thông tin đầu vào của người dùng, thì đây sẽ là nguồn thông tin chi tiết có giá trị nhất của bạn. Thêm các mẫu định kỳ vào bộ đánh giá của bạn, đồng thời liên tục xác định và triển khai các bước tối ưu hoá tốt nhất tiếp theo.

Điểm cần nhớ

Việc phát triển câu lệnh dựa trên đánh giá mang đến cho bạn một cách thức có cấu trúc để vượt qua sự không chắc chắn của AI. Bằng cách xác định rõ vấn đề, xây dựng hệ thống đánh giá phù hợp và lặp lại các điểm cải tiến nhỏ, có mục tiêu, bạn sẽ tạo ra một vòng phản hồi giúp cải thiện đều đặn kết quả của mô hình.

Tài nguyên

Sau đây là một số tài liệu nên đọc nếu bạn muốn triển khai LLM dưới vai trò là giám khảo:

Nếu bạn muốn cải thiện thêm câu lệnh, hãy đọc thêm về hoạt động phát triển dựa trên bối cảnh. Việc này tốt nhất là do kỹ sư học máy thực hiện.

Kiểm tra mức độ hiểu biết của bạn

Mục tiêu chính của quá trình phát triển dựa trên đánh giá là gì?

Để thay thế tất cả quy trình kiểm thử thủ công bằng kiểm thử đơn vị tự động.
Chưa chính xác.
Để theo dõi và tối ưu hoá một cách có hệ thống sự đánh đổi giữa tính ngắn gọn và hiệu quả của câu lệnh bằng cách sử dụng một quy trình có thể lặp lại.
Tuyệt vời, chính xác!
Để tăng độ trễ của ứng dụng nhằm đảm bảo độ chính xác cao hơn.
Chưa chính xác.
Để đảm bảo mô hình vượt qua các điểm chuẩn công khai tiêu chuẩn như MMLU.
Chưa chính xác.

Tại sao nên sử dụng các mô hình lớn hơn để đánh giá một hệ thống phía máy khách?

Các mô hình lớn hơn phù hợp nhất để đánh giá giọng điệu và khả năng sáng tạo.
Chưa chính xác.
Họ đóng vai trò là người tham gia vào quy trình để chấm điểm thủ công từng kết quả.
Chưa chính xác.
Chúng rất phù hợp để xác thực các kết quả có tính xác định, chẳng hạn như xác thực cấu trúc JSON hoặc số lượng ký tự.
Tuyệt vời, chính xác!

Việc sử dụng LLM làm công cụ đánh giá có thể gặp phải những vấn đề gì?

Việc này quá chậm so với quy trình đánh giá thủ công.
Chưa chính xác.
Tính năng này không yêu cầu thiết lập hoặc nhắc nhở.
Chưa chính xác.
Điều này có thể duy trì và củng cố những điểm thiên vị và thiếu hụt kiến thức của mô hình.
Tuyệt vời, chính xác!
Không xử lý được đầu ra văn bản.
Chưa chính xác.

Thành phần nào thuộc quy trình đánh giá tự động được đề xuất?

Sao chép và dán câu lệnh vào bảng tính theo cách thủ công.
Chưa chính xác.
Nhắc nhở, chỉ số và đầu vào kiểm thử theo phiên bản dưới dạng mã.
Tuyệt vời, chính xác!
Xoá nhật ký để tiết kiệm dung lượng.
Chưa chính xác.
Bỏ qua ý kiến phản hồi của người dùng để duy trì tính nhất quán.
Chưa chính xác.

Khi chọn người đánh giá cho hệ thống đánh giá của bạn, hạn chế chính của việc sử dụng ý kiến phản hồi của con người là gì?

Con người không thể đánh giá những phẩm chất chủ quan như giọng điệu hoặc độ rõ ràng.
Chưa chính xác.
Điều này tương đương với việc sử dụng "Kiểm tra dựa trên mã".
Chưa chính xác.
Chế độ này cung cấp lượng dữ liệu lớn nhất nhưng có chất lượng thấp nhất.
Chưa chính xác.
Phương pháp này không điều chỉnh được theo tỷ lệ phù hợp so với các phương pháp tự động.
Tuyệt vời, chính xác!