- Các giám khảo LLM chưa được hiệu chỉnh thường không đáng tin cậy trong môi trường
production, dẫn đến việc các tác nhân AI thất bại mặc dù hệ thống giám sát báo cáo hoạt động tốt. - Để giải quyết vấn đề này, cần xây dựng các giám khảo LLM đã được hiệu chỉnh bằng cách sử dụng tối ưu hóa
lời nhắc(ví dụ: thuật toán GIPA) dựa trên chú thích của con người. - Việc có các giám khảo LLM đã được hiệu chỉnh giúp tăng tốc vòng lặp phát triển AI, cải thiện đánh giá
onlinevàoffline, đồng thời cho phép xây dựngvòng lặp dữ liệuAI tự động.
Judge the Judge: Building LLM Evaluators That Actually Work with GEPA — Mahmoud Mabrouk, Agenta AI
- Vấn đề với Giám khảo LLM chưa Hiệu chỉnh: Giám khảo LLM chung chung (như phát hiện "ảo giác") thường không hiệu quả vì chúng không thể biết liệu đầu ra của tác nhân có đúng hay không nếu không có ngữ cảnh hoặc hiệu chỉnh cụ thể.
- Tầm quan trọng của Hiệu chỉnh: Giám khảo LLM cần được "hiệu chỉnh" (calibrated) dựa trên chú thích của con người để đảm bảo chúng tương quan với đánh giá của con người và mục tiêu kinh doanh.
- Phương pháp Hiệu chỉnh: Sử dụng tối ưu hóa
lời nhắc(prompt optimization) là cách chính để hiệu chỉnh các giám khảo LLM, với GIPA là một thuật toán được đề xuất. - Lợi ích: Các giám khảo LLM đã hiệu chỉnh tăng tốc đáng kể
đánh giá offline(giảm thời gian lặp lại phát triển tác nhân), cải thiệnđánh giá online(phản ứng nhanh với thay đổi trong môi trường production) và là yếu tố then chốt để xây dựngvòng lặp dữ liệuAI tự động. - Thiết kế Metric cụ thể: Cần thiết kế các
metricđánh giá cụ thể theotrường hợp sử dụng(ví dụ:tuân thủ chính sách,kiểu phản hồi), thay vì cácmetricchung chung. Việc sử dụng nhiều giám khảo LLM chuyên biệt cho từng loại lỗi sẽ hiệu quả hơn một giám khảo tổng quát. - Định dạng Chú thích Nhị phân và Lý do: Ưu tiên
phân loại nhị phân(đúng/sai, tuân thủ/không tuân thủ) kèm theolý dochi tiết trong chú thích của con người, thay vì thang điểm (1-5), để giám khảo LLM dễ học và hiệu chỉnh hơn. - Thử thách về Dữ liệu: Thu thập và tuyển chọn
dữ liệuchú thích là phần khó nhất; dữ liệu cần đủ lớn, phân phối tốt và chú thích rõ ràng để thuật toán tối ưu hóa có thể học được mộtrepresentationcó ý nghĩa. - Cách hoạt động của GIPA: Thuật toán GIPA (tương tự
thuật toán di truyền) bắt đầu với mộtlời nhắc gốc, sau đó lặp đi lặp lại việc lấy mẫu các ứng cử viên mới thông quađột biến lời nhắc(prompt mutation) hoặchợp nhất(merge), đánh giá chúng trênmini batches, và chọn cáclời nhắctốt hơn (sử dụngPareto frontier) để tiếp tục tối ưu hóa.
Mô hình Ngôn ngữ Lớn—LLM(Large Language Model)tác nhân—agentảo giác—hallucinationlời nhắc—prompthiệu chỉnh—calibratedtối ưu hóa lời nhắc—prompt optimizationvòng lặp dữ liệu—data flywheelmetric—metrictuân thủ chính sách—policy adherencethuật toán di truyền—genetic algorithmđột biến lời nhắc—prompt mutationPareto frontier—Pareto frontier
Chào mừng tất cả mọi người đến với buổi nói chuyện/workshop của tôi, "Đánh giá người đánh giá." Hôm nay, chúng ta sẽ nói về các Mô hình Ngôn ngữ Lớn (LLM) đóng vai trò là giám khảo.
Thách Thức Trong Giám Sát Độ Tin Cậy của Tác nhân AI
Chắc chắn bạn đã quen với kịch bản này: Bạn có một tác nhân đang chạy trong môi trường production, và ai đó trong nhóm nói, "Chúng ta cần giám sát độ tin cậy." Vì vậy, bạn tìm đến một trong các thư viện, có thể sử dụng giám khảo LLM chuyên phát hiện "ảo giác" (hallucination), đưa nó vào môi trường production trong nền tảng khả năng quan sát (observability) của bạn, và mọi thứ có vẻ ổn. Nhưng khách hàng lại thực sự nói rằng tác nhân không hoạt động. Bạn xem xét các trace – nó không hoạt động. Bây giờ bạn xem xét sâu hơn về giám khảo LLM phát hiện "ảo giác" này, và bạn sẽ tìm thấy một lời nhắc không khác xa lắm so với cái này: "Bạn sẽ được cung cấp đầu ra của một LLM, phải không? Liệu đó có phải là 'ảo giác' hay không?" Rõ ràng, làm thế nào mà tác nhân có thể biết liệu đó có phải là "ảo giác" hay không? Nếu nó có thể, thì đầu ra của bạn đã hoạt động ngay từ ngày đầu tiên rồi.
Xây Dựng LLM Giám Khảo Đã Hiệu Chỉnh
Vì vậy, hôm nay, chúng ta sẽ nói về cách chúng ta có thể xây dựng các LLM đã được hiệu chỉnh (calibrated) để đóng vai trò giám khảo một cách hiệu quả. "Hiệu chỉnh" có nghĩa là hiệu chỉnh dựa trên chú thích của con người. Cách chúng ta hiệu chỉnh chúng là bằng cách sử dụng tối ưu hóa, hoặc cụ thể hơn là tối ưu hóa lời nhắc (prompt optimization). Chúng ta sẽ sử dụng GIPA, một thuật toán khá tốt để tối ưu hóa các lời nhắc. Vậy tại sao chúng ta lại cần điều này? Tại sao chúng ta muốn các LLM giám khảo đã được hiệu chỉnh hoặc các LLM giám khảo tốt?
Tăng Tốc Đánh Giá Offline
Điều đầu tiên là dành cho các đánh giá offline. Như bạn đã biết, thông thường để tạo ra một tác nhân tốt hoặc một lời nhắc tốt, cách bạn làm là thử nghiệm với lời nhắc, sau đó chạy các đánh giá của bạn, xem liệu nó có cải thiện mọi thứ hay không. Nếu có, tốt. Nếu không, bạn quay lại và cải thiện nó một chút, cải thiện khung điều khiển (harness), lời nhắc, và lặp lại nhiều lần. Tốc độ mà bạn chuyển sang môi trường production hoặc thêm tính năng thực chất là tốc độ bạn có thể hoàn thành vòng lặp này. Nút cổ chai trong vòng lặp này chính là đánh giá: Bạn có thể đánh giá nhanh đến mức nào? Rõ ràng, đánh giá chậm nhất có thể là việc có một người chú thích thủ công xem xét toàn bộ tập test set của bạn và chú thích nó bằng tay. Chất lượng khá tốt, nhưng mỗi lần lặp lại sẽ mất rất nhiều thời gian. Bạn có thể có các cách nhanh hơn bằng cách sử dụng một LLM làm giám khảo, nhưng nếu LLM đó không tương quan với chú thích của con người, thì bạn sẽ thường không nhận được tín hiệu nào, và toàn bộ quá trình sẽ diễn ra nhanh chóng nhưng không đi đến đâu. Vì vậy, việc có một LLM đã được hiệu chỉnh làm giám khảo với chất lượng tương tự, ví dụ như một người chú thích bằng tay, sẽ giúp quá trình phát triển nhanh hơn nhiều.
Cải Thiện Đánh Giá Online
Điều thứ hai về cơ bản là đánh giá online. Giống như ví dụ của chúng ta từ đầu, nếu bạn có một đánh giá online, bạn muốn xem về cơ bản trong môi trường production liệu mọi thứ có đang cải thiện hay không. Tương tự, nếu bạn có một LLM làm giám khảo đã được hiệu chỉnh với các mục tiêu kinh doanh của mình, thì bạn có thể nhanh chóng thấy liệu những thay đổi bạn đã thực hiện có đang cải thiện hay không, liệu có sự thay đổi nào trong phân phối dữ liệu (data) hay không, cách mọi người tương tác với tác nhân hoặc mô hình (model) của bạn, và về cơ bản là phản ứng nhanh chóng.
Tối Ưu Hóa Vòng Lặp Dữ Liệu AI
Và cuối cùng, tôi gọi đây là "Chén thánh" của kỹ thuật AI (AI engineering): thực sự xây dựng vòng lặp dữ liệu (data flywheel) này. Nơi bạn tối ưu hóa khung điều khiển của mình, quan sát các trace, và sau đó thêm các đánh giá mới dựa trên các trace này – các trường hợp biên (edge cases) – và lặp lại nhiều lần. Ở đây, nếu bạn có cách để thêm các đánh giá mới một cách nhanh chóng, rõ ràng là các đánh giá tự động, từ các trace, từ các chú thích, dữ liệu, bạn có thể đi qua vòng lặp này nhanh hơn và nhanh hơn đến mức bạn có thể coi đó là một vòng lặp tự động. Đúng vậy, bởi vì bạn có thể tối ưu hóa các khung điều khiển bằng các kỹ thuật tối ưu hóa (optimization techniques) như GIPA, điều mà chúng ta sẽ sử dụng ở đây. Nhưng điều tương tự, bạn có thể làm với các đánh giá, và về cơ bản, theo thời gian, ứng dụng (application) của bạn sẽ cải thiện chỉ với những quan sát mới.
Giới Thiệu Về Diễn Giả và Nền Tảng Agenda
Vì vậy, hôm nay, chúng ta sẽ xây dựng và tối ưu hóa các LLM này để đóng vai trò giám khảo, được hiệu chỉnh với các chú thích của con người. Nhưng trước khi đi sâu vào đó, một lời giới thiệu ngắn gọn về bản thân tôi: Tên tôi là Mahmoud, đồng sáng lập và CEO của Agenda. Agenda là một nền tảng vận hành LLM mã nguồn mở (open source LLM ops platform), về cơ bản cung cấp cho bạn tất cả các công cụ (tool) từ khả năng quan sát, quản lý lời nhắc, đánh giá – bao trùm toàn bộ vòng đời (lifecycle) của việc xây dựng các tác nhân đáng tin cậy. Kinh nghiệm của tôi là trong máy học (machine learning); tôi có hơn 15 năm kinh nghiệm trong lĩnh vực đó. Trước đây, tôi làm việc trong giới học thuật, nghiên cứu về máy học ứng dụng vào sinh học tính toán (computational biology), dự đoán cấu trúc protein (protein structure prediction), và hiện tại, chúng tôi đang tập trung nhiều vào các quy trình lấy mẫu (sampling) và tối ưu hóa tự động (auto-optimization workflows) này. Vì vậy, nếu bạn quan tâm đến điều đó, vui lòng liên hệ; tôi rất muốn có một cuộc trò chuyện và cho bạn thấy những gì chúng tôi đang xây dựng.
Kế Hoạch Cho Buổi Nói Chuyện
Vậy kế hoạch cho buổi nói chuyện này là gì? Về cơ bản, chúng ta sẽ làm việc trên một trường hợp sử dụng (use case) thực tế. Đó là một tác nhân hỗ trợ khách hàng (customer support agent) mà chúng ta muốn đánh giá. Và chúng ta sẽ xây dựng một LLM làm giám khảo được hiệu chỉnh với các chú thích – về cơ bản là chú thích của con người – cho tác nhân hỗ trợ khách hàng đó. Kế hoạch sẽ là đi qua toàn bộ quá trình xây dựng này, bắt đầu từ cách chúng ta thiết kế các metric, cách suy nghĩ về tuyển chọn dữ liệu (data curation), gán nhãn (labeling), nhưng trọng tâm chính sẽ thực sự là phần tối ưu hóa LLM làm giám khảo bằng GIPA, và sau đó rõ ràng là xác thực kết quả. Toàn bộ mã nguồn (code) và dữ liệu (data) được sử dụng trong phần này sẽ có trên GitHub, và bạn có thể tìm thấy chúng trong các liên kết trong video này và trên slide cuối cùng.
Bộ Dữ Liệu TaoBench
Vậy, hãy bắt đầu với các tập dữ liệu (datasets). Chúng ta sẽ sử dụng TaoBench. TaoBench là một điểm chuẩn (benchmark) trong một tập dữ liệu lớn được xây dựng bởi Sierra Customer Support Scala, tôi nghĩ vậy. Và họ có nhiều điểm chuẩn cho các kịch bản thực tế đối với các tác nhân hỗ trợ khách hàng. Một trong số đó là tác nhân hàng không (airline agent), mà chúng ta sẽ sử dụng trong ví dụ này. Về cơ bản, cái họ có là một tác nhân hỗ trợ khách hàng hàng không có quyền truy cập vào nhiều công cụ để quản lý đặt chỗ, truy cập thông tin chuyến bay, truy cập thông tin người dùng, và có một chính sách khá phức tạp cần tuân thủ, chẳng hạn như khi nào cần thay đổi đặt chỗ, khi nào cần cung cấp thông tin, v.v., giống như một tác nhân hỗ trợ khách hàng là con người. Và dữ liệu mà chúng ta có là bản thân tác nhân, nhưng quan trọng hơn, là 599 trace cuộc hội thoại được tạo ra kèm theo các chú thích. Hiện tại, định dạng, định dạng gốc của các chú thích, là ở dạng assertion. Nhưng tôi đã tiền xử lý hoặc bypassed xử lý dữ liệu để chúng ta có một chú thích cho mỗi trace, giống như một chú thích của con người, trong đó nói rằng, ví dụ, trong trường hợp này, bạn có cuộc hội thoại mà bạn thấy ở đây, và sau đó bạn có một chú thích rằng tác nhân không tuân thủ vì nó đã chấp thuận việc hủy mà không xác minh rằng đặt chỗ đã đáp ứng các quy tắc hủy của hãng hàng không. Vì vậy, về cơ bản, đánh giá đã thất bại, và lý do là vì tác nhân đã hủy đặt chỗ mà không xác minh điều gì đó, về cơ bản, nó đã không tuân thủ chính sách. Và dữ liệu nhìn chung không được tốt lắm; nó tuân thủ 62%, không tuân thủ 38%, và nó được tạo ra với nhiều mô hình và thử nghiệm. Nhìn chung, dữ liệu, vấn đề khá phức tạp vì chính sách khá phức tạp. Dữ liệu có những lưu ý (caveats), thành thật mà nói; nó không thực sự sạch sẽ do cách nó cũng được tạo ra. Nhưng đối với trường hợp sử dụng của chúng ta, tôi nghĩ đây là một trường hợp sử dụng rất thú vị để thử nghiệm GIPA và để minh họa cách nó hoạt động trong một trường hợp thử nghiệm (test case).
Quy Trình Đánh Giá và Thiết Kế Metric
Quy trình làm việc mà chúng ta có gồm bốn bước. Điều đầu tiên là thiết kế các metric – tức là, quyết định LLM với vai trò giám khảo sẽ đo lường cái gì, những khía cạnh khác nhau mà nó sẽ xem xét là gì? Điều thứ hai là chú thích dữ liệu. Và sau đó chúng ta sẽ tối ưu hóa giám khảo và xác thực kết quả. Bây giờ, điều quan trọng nhất cần lưu ý ở đây là các metric cần phải đến từ bản thân trường hợp sử dụng. Không có ý nghĩa gì khi có các metric chung chung như "ảo giác" khi bạn đang đánh giá tác nhân AI của mình. Nó thực sự phụ thuộc vào trường hợp sử dụng kinh doanh, và người tốt nhất, những người tốt nhất để xác định các metric này là các chuyên gia về lĩnh vực. Ví dụ, trong trường hợp tác nhân hỗ trợ khách hàng, bạn cần có một chuyên gia về lĩnh vực xem xét cuộc hội thoại, đưa ra phản hồi (feedback). Và tôi nghĩ quy trình làm việc để làm điều đó, người mô tả nó tốt nhất là Hamil từ Hamil Dev. Tôi sẽ chia sẻ blog và video YouTube của anh ấy, và anh ấy thực sự mô tả ý tưởng về phân tích lỗi (error analysis) này rất tốt. Nhưng tôi sẽ nói qua rất nhanh về nó và cả quy trình chú thích (annotation workflow) nữa.
Quy Trình Chú Thích và Xác Định Loại Lỗi
Vì vậy, ý tưởng là bạn cung cấp cho chuyên gia về lĩnh vực của mình tất cả các trace về quỹ đạo của cuộc hội thoại, và họ sẽ chú thích chúng đầu tiên bằng cách bình luận về những gì đã hoạt động hoặc những gì không hoạt động. Nhưng sau đó, từ từ cố gắng phân cụm, tạo ra các cụm (clusters) các loại lỗi (error type), như khi nào nó thất bại, tại sao nó thất bại. Và ở đây, tôi đang trình bày trong Agenda cách nó được thực hiện, và về cơ bản, ở đây tôi có, tôi đã khám phá ra bốn loại lỗi này khi xem xét các trace này: Đôi khi có vấn đề với tuân thủ chính sách (policy adherence), đôi khi có vấn đề với kiểu phản hồi (response style), cung cấp thông tin (information delivery) (về cơ bản là tác nhân không thông báo cho khách hàng rằng họ đã thực hiện thay đổi hoặc đại loại thế), và cuối cùng, một số công cụ đã không được gọi đúng cách. Và ý tưởng là chúng ta sẽ lấy bốn loại lỗi này, và sau đó chúng ta sẽ xây dựng bốn LLM làm giám khảo cho chúng. Vì vậy, việc có một LLM làm giám khảo duy nhất, mà là "thành công" – về cơ bản cố gắng đánh giá tất cả những điều này – là không hợp lý. Nó sẽ làm cho mọi thứ quá phức tạp, và rất khó học. Và bạn sẽ thấy sau một chút rằng ngay cả với một LLM đơn giản, ngay cả khi chúng ta đơn giản hóa nó, vẫn khó để học một LLM giám khảo đã được hiệu chỉnh hoặc tối ưu hóa một LLM giám khảo đã được hiệu chỉnh. Vì vậy, rất hợp lý khi làm cho mọi thứ rất cụ thể trong các metric mà chúng ta muốn đánh giá này. Và điều thứ hai là chuyển khỏi điểm từ một đến năm hoặc tỷ lệ phần trăm, và thay vào đó có một giải pháp thực sự nhị phân, chẳng hạn như liệu nó có tuân thủ chính sách hay không, với rõ ràng là một số lý do (reasoning). Và lý do là, một lần nữa, đã khá khó để hiệu chỉnh một LLM làm giám khảo với một phân loại đúng/sai, như phân loại nhị phân (binary classification). Thêm một lớp nữa và nói, "Được rồi, nó phải là một số từ một đến năm," thì khó. Ngay cả đối với người chú thích bằng tay, cũng khó để có hai người chú thích đồng ý về cùng một điểm số.
Vì vậy, ngay khi chúng ta đã xác định các metric khác nhau này, điểm chú thích bắt đầu. Ở đây, một lần nữa, tôi đang sử dụng Agenda. Về cơ bản, bạn sẽ lấy các trace của mình, tạo một hàng đợi chú thích (annotation queue), và chỉ định cho người chú thích của bạn, chẳng hạn như tên của phản hồi hoặc tuân thủ chính sách của người đánh giá (evaluator policy adherence) ở đây. Và sau đó cung cấp, như họ nên cung cấp cho mỗi người liệu nó có tuân thủ chính sách hay không, và cung cấp lý do. Và lý do ở đây rất quan trọng bởi vì nếu không có lý do, chúng ta sẽ thấy thuật toán tối ưu hóa (optimization algorithm) sẽ cần tự khám phá tại sao nó thất bại, và điều đó sẽ rất khó, trừ khi đó là một loại phản hồi rất cụ thể, ví dụ, lỗi công cụ (tool failure), nơi nó có thể suy luận mọi thứ.
Tầm quan trọng của lý do và dữ liệu chú thích
Rất khó để xác định, ví dụ, từ một cuộc hội thoại, tại sao nó không tuân thủ chính sách nếu không có thông tin ban đầu. Vì vậy, việc có lý do đó là rất quan trọng sau này để Mô hình ngôn ngữ lớn (LLM) đóng vai trò trọng tài học hỏi. Lý do này, như đã trình bày trước đây với chú thích, nó mô tả tại sao, ví dụ, tác nhân ở đây không tuân thủ. Đó là bởi vì nó đã phê duyệt việc hủy mà không xác minh rằng đặt chỗ đáp ứng các quy tắc của Conservatory.
Thách thức trong chuẩn bị dữ liệu
Bây giờ chúng ta đã có các chú thích, chúng ta có thể chuyển sang tối ưu hóa. Nhưng trước khi đi sâu vào đó, tôi muốn bổ sung một lưu ý nhỏ. Mặc dù chúng ta đã lướt qua rất nhanh hai bước đầu tiên, đây thực sự là phần khó nhất của vấn đề. Trong thực tế, như mọi nhà khoa học dữ liệu đều biết, việc thu thập dữ liệu là điều khó khăn nhất. Bạn cần đảm bảo xem xét dữ liệu, xem xét chú thích, đảm bảo rằng phân phối tốt, và rằng chú thích cũng như thông tin trong dữ liệu là đủ để thuật toán học được một representation của LLM đóng vai trò trọng tài có ý nghĩa. Trong trường hợp này, dữ liệu không thực sự tốt. Số lượng traces nhỏ, vấn đề khá phức tạp. Chúng không được phân phối tốt do cách chúng được tạo ra. Ngoài ra, chú thích thực sự được AI tạo sinh dựa trên khẳng định và dữ liệu gốc (bạn có thể xem chi tiết hơn về cách thực hiện trong kho lưu trữ). Điều này làm cho mọi thứ khá phức tạp đối với vấn đề này, nhưng nó vẫn là một minh họa khá tốt về cách nó sẽ hoạt động.
Giới thiệu thuật toán GIPA
Bây giờ chúng ta đã có dữ liệu được chú thích, chúng ta có thể bắt đầu với quá trình tối ưu hóa. Đối với tối ưu hóa, chúng ta sẽ sử dụng thuật toán GIPA. Tôi sẽ giải thích cách hoạt động của thuật toán GIPA ngay từ đầu, sau đó chúng ta có thể chuyển sang Jupyter Notebook và bắt đầu tối ưu hóa dựa trên dữ liệu được chú thích. Việc hiểu cách thuật toán hoạt động là rất quan trọng bởi vì bạn sẽ thấy rằng trên thực tế, bạn cần phải thử nghiệm với các tham số một chút để nó hoạt động được. Và rõ ràng là rất khó để thử nghiệm với các tham số nếu bạn không hiểu chúng làm gì.
Cách hoạt động của thuật toán GIPA
Thuật toán này tương tự như thuật toán di truyền (genetic algorithm). Về cơ bản, ý tưởng là bạn bắt đầu với một lời nhắc gốc (seed prompt), sau đó ở mỗi lần lặp, bạn cố gắng lấy mẫu các lời nhắc mới, xem cái nào hoạt động, sau đó chọn những lời nhắc mới và cải thiện dần theo thời gian. Đó là hình dạng tổng quát của thuật toán, và chúng ta sẽ xem xét từng bước. Về cơ bản có ba bước: bạn lấy mẫu các ứng cử viên mới, đánh giá chúng, xem cái nào hoạt động tốt, sau đó thực hiện một số lọc bằng cách sử dụng loại Pareto frontier này (tôi sẽ nói về nó), và sau đó lặp lại nhiều lần.
Hãy xem nó hoạt động như thế nào. Đầu tiên, bạn bắt đầu với một ứng cử viên gốc (seed candidate). Trong trường hợp của chúng ta, chúng ta sẽ sử dụng một LLM đóng vai trò trọng tài rất đơn giản, như đánh giá xem tác nhân dịch vụ khách hàng này có vi phạm chính sách hay không, và bắt đầu với giả định tác nhân này tuân thủ. Bây giờ, ở mỗi lần lặp, chúng ta sẽ lấy mẫu các ứng cử viên mới từ các ứng cử viên đã lọc từ lần lặp trước. Trong lần lặp đầu tiên này, chúng ta chỉ có một ứng cử viên gốc, nhưng ở lần lặp tiếp theo, chúng ta sẽ có một tập hợp lớn hơn các ứng cử viên.
GIPA có hai chiến lược để lấy mẫu các ứng cử viên mới. Một là prompt mutation (đột biến lời nhắc) và cái còn lại là hợp nhất nhiều ứng cử viên. Đối với prompt mutation (đây là cái chúng ta sẽ sử dụng lúc đầu vì chúng ta chỉ có một ứng cử viên), ý tưởng là bạn sẽ chạy LLM đầu tiên đóng vai trò trọng tài ở đây để kiểm tra trajectory và nếu nó thất bại, LLM đóng vai trò trọng tài này sẽ reflection (suy ngẫm) và đề xuất một lời nhắc mới. Về cơ bản, sẽ có một kiểu reflection, có nghĩa là chúng ta đang sử dụng trí thông minh của LLM để cố gắng cải thiện lời nhắc vì nó xem xét đầu vào, xem xét đầu ra, xem xét kết quả và cố gắng suy luận cách làm cho nó tốt hơn. Chiến lược còn lại là chiến lược hợp nhất (merge strategy), mà chúng ta sẽ sử dụng ở lần lặp tiếp theo. Về cơ bản, nó lấy hai lời nhắc và sau đó kết hợp chúng lại với nhau. Và nếu bạn nghĩ về nó với một LLM đóng vai trò trọng tài, bạn thường có các hướng dẫn này, và về cơ bản, điều nó sẽ cố gắng làm là lấy các hướng dẫn từ lời nhắc A và lời nhắc B và kết hợp chúng lại với nhau.
Bây giờ, sau khi chúng ta đã tạo ra rất nhiều mẫu, chúng ta cần chọn cái nào là tốt. Về cơ bản, cách nó hoạt động là nó sẽ đánh giá các lời nhắc mới này đối với các mini batches của quá trình đánh giá, chứ không phải mọi thứ. Và nếu chúng cải thiện hiệu suất so với điểm khởi đầu, thì chúng ta sẽ chọn chúng. Và chúng sẽ được thêm vào tập hợp các lời nhắc của chúng ta, sau đó bắt đầu lần lặp tiếp theo. Đây là cải tiến khác của thuật toán này, đó là ý tưởng về Pareto frontier. Về cơ bản, cách chúng ta chọn lời nhắc hoặc ứng cử viên nào chúng ta sẽ sử dụng làm seed cho lần lặp mới không phải là chúng ta chọn những cái có điểm trung bình tốt nhất (đó sẽ là giải pháp tầm thường, đúng không? Nhìn vào lời nhắc của tôi, xem cái nào hoạt động tốt nhất bằng cách nhìn vào mức trung bình của mọi thứ, và sau đó chọn chúng). Thay vào đó, điều họ làm là cố gắng tăng tính đa dạng bằng cách cố gắng xem xét đâu là ứng cử viên tốt nhất cho task. Bạn có một tập hợp các task trong quá trình đánh giá của mình, như trong trường hợp của chúng ta, một tập hợp các trajectories, và bạn tìm kiếm đối với mỗi trajectory này, đâu là ứng cử viên tốt nhất, và đó chính là Pareto frontier. Sau đó, bạn cố gắng chọn từ những cái này. Về cơ bản, điều bạn làm là cố gắng chọn một tập hợp cuối cùng bao phủ toàn bộ trường hợp task của bạn. Có nghĩa là, đối với mỗi trường hợp thử nghiệm, có ít nhất một ứng cử viên giải quyết nó. Và rõ ràng, bạn thấy ở đó, ý tưởng là bạn có được một Pareto frontier tốt, sau đó bạn bắt đầu hợp nhất mọi thứ, và cuối cùng, bạn có lời nhắc này giải quyết mọi thứ trong quá trình đào tạo của bạn. Bây giờ bạn đã có tập hợp ứng cử viên đã lọc này, chúng ta lại lấy mẫu các ứng cử viên mới từ những cái này bằng cách sử dụng chiến lược mutation và merge, và chúng ta tiếp tục làm điều này cho đến khi ngân sách tính toán (compute budget) kết thúc.
API tối ưu hóa bất kỳ (optimize anything API)
Có rất nhiều thư viện triển khai thuật toán này. Tôi nghĩ rằng cái nổi tiếng nhất là AutoGPT đã phổ biến ý tưởng tối ưu hóa lời nhắc hoặc khung điều khiển (harness). Nhưng bây giờ có một thư viện mới của các tác giả của GIPA, một phần mềm mã nguồn mở (OSS) gọi là GIPA, và họ đã triển khai vào tháng trước một giao diện lập trình ứng dụng (API) mới gọi là optimize anything. Đây là cái chúng ta sẽ sử dụng và có thể được dùng không chỉ để tối ưu hóa lời nhắc mà thực sự để tối ưu hóa hầu hết mọi thuật toán bằng cách sử dụng cùng ý tưởng này. Nó khá mạnh mẽ.
Hãy để tôi cho bạn thấy cách nó hoạt động. Về cơ bản, API ở đây được gọi là optimize anything. Bạn thấy chức năng này và những gì nó nhận vào là một ứng cử viên gốc (seed candidate). Candidate là cấu hình bạn muốn tối ưu hóa. Trong trường hợp của chúng ta, đó sẽ là lời nhắc của LLM đóng vai trò trọng tài, đúng không? Chúng ta thậm chí có thể làm cho nó trở thành một dictionary nếu muốn, ví dụ, lời nhắc của LLM đóng vai trò trọng tài cộng với temperature. Hoặc nó có thể là một chuỗi suy nghĩ (chain of prompt), v.v. vì vậy nó không bị giới hạn. Sau đó, chúng ta có evaluator (bộ đánh giá), về cơ bản là thứ sẽ được GIPA sử dụng để tối ưu hóa, và kỳ vọng từ evaluator là nó rõ ràng sẽ chạy hệ thống. Trong trường hợp của chúng ta, nó sẽ chạy LLM đóng vai trò trọng tài được tham số hóa bởi ứng cử viên, sau đó nó sẽ ghi lại (log) lỗi, lý do, và bạn có thể thêm bao nhiêu tùy thích. Bạn sẽ thấy đây là cách chúng ta sẽ làm với tối ưu hóa của mình cho LLM đóng vai trò trọng tài. Nhưng ý tưởng là, nếu bạn nhớ ở đây, chúng ta đã sử dụng một số loại reflection và reasoning để cải thiện lời nhắc của mình, và reasoning đó là thứ mà chúng ta sẽ tự xây dựng thông qua evaluator này. Và tất cả những cái đó đều có các cách trong cấu hình, ví dụ, để cấu hình số lượng call để thực hiện mỗi lần lặp, mục tiêu, về cơ bản cung cấp context cho refinement prompt về cách cải thiện, v.v. Nhưng luồng cốt lõi thực sự khá đơn giản.
Thực hành với Jupyter Notebook
Bây giờ hãy chuyển sang Jupyter Notebook và thực sự xem cách thực hiện từng bước. Bạn sẽ tìm thấy Jupyter Notebook này trong kho lưu trữ GitHub mà bạn sẽ tìm thấy trong các liên kết và ở slide cuối cùng.
Chúng ta bắt đầu bằng cách cài đặt thư viện, đó là dot and flight LLM và GIPA. Tôi không cài đặt GIPA ở đây vì tôi đã thực hiện tối ưu hóa, nó mất khá nhiều thời gian, tôi nghĩ vài giờ trước đó, vì vậy tôi sẽ bỏ qua bước này. Nhưng rõ ràng, nếu bạn muốn chạy nó trong kho lưu trữ GitHub và Jupyter Notebook, bạn cũng nên cài đặt nó.
Chúng ta cài đặt cái này và chúng ta thực hiện các import. Chúng ta có một vài chức năng mà tôi đã trích xuất ra ngoài, chúng ta sẽ xem xét chúng sau. Và chúng ta bắt đầu bằng cách tải dữ liệu như đã đề cập.
Tải và chuẩn bị dữ liệu
Chúng ta đang sử dụng dữ liệu từ TaoBench. Tôi chỉ xử lý trước nó ngay từ đầu để thay đổi loại khẳng định để chúng trông giống như chú thích mà tôi đã trình bày trong bản trình bày. Vì vậy, tôi đã chia dữ liệu thành tập huấn luyện (training data set) và tập xác thực (validation data set), một tập sẽ được sử dụng với GIPA và tập còn lại để xác thực ở cuối.
Cách tôi thực hiện việc chia tách này là dựa trên các task khác nhau được tạo ra trong TaoBench. Và nếu chúng ta nhìn vào đây, về cơ bản bạn có một tập huấn luyện với 480 traces với khoảng hai phần ba là tuân thủ, và một tập xác thực với 112 traces là tuân thủ. Như đã đề cập, dữ liệu ở đây không được đẹp cho lắm vì có một số dư thừa. Đôi khi có cùng một task đang được chạy với cùng một mô hình nhiều lần, vì vậy có một chút dư thừa. Nhưng không có dư thừa giữa tập huấn luyện và tập xác thực.
Phân tích chú thích và chính sách
Chúng ta hãy xem chú thích trông như thế nào. Về cơ bản, chúng ta có một ví dụ về chú thích tuân thủ (compliant annotation) hoặc không tuân thủ (non-compliant annotation), về cơ bản là một trajectory tuân thủ chính sách mà LLM đóng vai trò trọng tài muốn học, và một cái khác không tuân thủ. Và chúng ta có thể thấy ở đây về cơ bản nó mô tả như: "ok, nó tuân thủ vì nó đã xác định đúng đặt chỗ basic economy", trong khi ở đây "nó không xác định tư cách thành viên của người dùng là regular".
Chú thích này thực sự khá quan trọng đối với chúng ta để LLM đóng vai trò trọng tài học được chính sách, đặc biệt là trong trường hợp này. Chính sách trong quá trình này là một hệ thống rất phức tạp mà LLM đóng vai trò trọng tài cần phải học. Và nếu không có thông tin về những gì là tuân thủ, tại sao một cái gì đó là đúng hoặc không đúng, sẽ khá bất khả thi để thuật toán GIPA đạt được một LLM đóng vai trò trọng tài tốt, đúng không? Ý tôi là, điều đó cũng sẽ tương tự đối với một con người. Nếu bạn đưa cho tôi tất cả những trajectory này và nói với tôi rằng đây là loại chính xác.
Khởi đầu với Giám khảo Naive và Đánh giá Chính sách
Đây là trường hợp không tuân thủ chính sách, nhưng bạn không cung cấp cho tôi thêm thông tin. Sẽ rất khó để tôi đưa ra đánh giá, để học cách đánh giá các chính sách. Do đó, việc có thông tin này và chất lượng của phần chú thích, như tôi đã đề cập, chất lượng của dữ liệu, thực sự rất quan trọng để có thể học được điều này. Và rõ ràng, đây là một Mô hình ngôn ngữ lớn (LLM) đóng vai trò giám khảo khá phức tạp để học.
Điều đầu tiên chúng tôi bắt đầu là với một giám khảo naive (ngây thơ). Đây là giám khảo seed chúng tôi khởi tạo, và đó là điều mà tôi thực sự đã thiết kế. Tôi sẽ nói thêm một chút về nó sau, cùng với những bài học về cách chúng tôi đạt được điều này một cách chính xác. Về cơ bản, bạn có thể thấy ở đây là nó đánh giá xem tác nhân dịch vụ khách hàng có vi phạm chính sách hay không, và nó nói rằng bạn nên bắt đầu bằng cách giả định rằng tác nhân tuân thủ và chỉ thay đổi thành không tuân thủ nếu có một lý do cụ thể, phải không? Ý tôi là, ở đây chúng ta bắt đầu với một LLM làm giám khảo, điều đó có nghĩa là giám khảo seed, giám khảo ban đầu, theo ý kiến của tôi, nên bắt đầu bằng cách nói rằng mọi thứ đều ổn. Ý tôi là, nếu tôi không có bất kỳ quy tắc nào, nó nên nói rằng mọi thứ đều ổn. Tôi đã bắt đầu, và như trong một ví dụ khác, khi tôi bắt đầu tạo một LLM và các công việc khác mà nói rằng, được rồi, bạn nên kiểm tra xem các tác nhân có vi phạm chính sách hay không. Và kết quả cuối cùng là LLM với những thiên vị riêng của nó cố gắng tự đưa ra quyết định đó, nói rằng, được rồi, điều này vi phạm, điều này không vi phạm mà không có bất kỳ thông tin nào. Vì vậy, nếu không nói cho nó ngay từ đầu rằng bạn nên bắt đầu giả định rằng nó tuân thủ (tức là nếu bạn không có bất kỳ lý do nào để tin rằng nó không tuân thủ, nó nên được coi là tuân thủ). Khi đó, về cơ bản, bạn sẽ bắt đầu với một LLM ngẫu nhiên làm giám khảo mà sẽ rất khó để sửa chữa sau này, trừ khi bạn tìm được một lời nhắc đã phát hiện ra điều này ngay từ đầu của sự tuân thủ. Vì vậy, tôi đã khám phá ra rằng seed ban đầu thực sự rất quan trọng trong trường hợp này. Có thể có những kịch bản đơn giản hơn mà bạn không cần điều này, nhưng trong trường hợp này, nó khá quan trọng.
Đánh giá Hiệu suất ban đầu của Giám khảo LLM
Vì vậy, nếu chúng ta lấy điều này và chạy nó trên tập xác thực (validation set), với LLM ban đầu làm giám khảo, chúng ta cơ bản tìm thấy độ chính xác (accuracy) là 61%. Nhưng chúng ta thấy rằng thiên vị (bias) của nó thực sự hầu hết thời gian là nói rằng nó tuân thủ, điều mà chúng ta mong muốn, phải không? Và nếu đó là, tôi sẽ nói, nói rằng nó tuân thủ 98% thời gian thực sự là điều không có thiên vị để làm, là điểm khởi đầu hợp lý. Vì vậy, chúng ta chạy các chỉ số ngay từ đầu, phải không? Độ chính xác 61%, 98% cho thấy độ nhạy (recall) của sự tuân thủ với độ nhạy rất thấp đối với sự không tuân thủ. Và tôi nghĩ, như tôi đã đề cập, điều này khá ổn. Nó bị thiên vị theo hướng tuân thủ, và tôi đã có những thử nghiệm ban đầu khi nó gần như ngẫu nhiên, nhưng sau đó nó không học được gì cả. Và chúng ta có thể xem xét lý do tại sao hoặc nơi nó mắc lỗi. Và về cơ bản, bằng cách nhìn vào những nơi nó hoạt động, và chúng ta thấy rằng nó nói tuân thủ, nhưng nó không tuân thủ vì nó không biết chính sách.
Tối ưu hóa Giám khảo bằng GEPA và Mẫu Phản hồi Tùy chỉnh
Đúng vậy, vì vậy chúng ta bắt đầu ở đây với phần chính của việc tối ưu hóa giám khảo bằng GEPA. Và điều bạn sẽ thấy là tôi thực sự đã viết một mẫu phản hồi (reflection template). Đó là một lời nhắc (prompt) mà GEPA sử dụng để suy ngẫm và lấy mẫu các ứng viên (candidates) mới. Tôi đã không sử dụng mặc định của họ, mà tôi đã tự viết một cái. Ban đầu tôi đã thử sử dụng lời nhắc mặc định trong GEPA, nhưng kết quả không tốt như tôi mong đợi. Nó rất khó để học. Và điều tôi đã cố gắng làm là cung cấp một thiên vị và tiên nghiệm (prior) trong mẫu phản hồi. Vì vậy, bạn thấy ở đây, ví dụ, tôi đã đề cập rõ ràng rằng giám khảo đang đọc một dịch vụ khách hàng hàng không, và nó cần phải quyết định điều cơ bản. Nhưng sau đó bạn có thể xem xét thêm thông tin, ví dụ, chú thích của chúng tôi mà mẫu phản hồi này xem xét cũng bao gồm phán quyết của giám khảo, sự thật cơ bản (ground truth) như chú thích. Đây là thông tin quan trọng mà mẫu phản hồi nên xem xét và cải thiện. Và về cơ bản, tôi giải thích cho LLM cách làm điều này: bạn có thể thêm quy tắc hoặc cấu trúc lại những quy tắc hiện có, khen thưởng những điều rõ ràng và cố gắng nghĩ rằng mẫu phản hồi về cơ bản nên tạo ra các quy tắc chính sách thực sự, phải không? Nó nên tìm ra các chính sách và khả năng phù hợp. Và tôi nghĩ việc thêm điều đó rất quan trọng để cải thiện chất lượng. Nếu không, mẫu phản hồi mặc định đã không hiểu rằng nó nên cố gắng học chính sách ít nhiều, phải không? Với LLM làm giám khảo ở một mức độ nào đó.
Thực hiện Tối ưu hóa và Đánh giá Kết quả
Vậy đó là điều thứ hai tôi đã thay đổi. Và tôi có thể nói thật, nó chỉ là một thay đổi nhỏ. Sau đó, chúng tôi chạy quá trình tối ưu hóa. Một lần chạy tối ưu hóa về cơ bản là một wrapper xung quanh Optimize Anything, và nó chỉ tham số hóa nó vì tôi đã chạy nhiều thử nghiệm để tìm ra một cái. Và nó thực sự sẽ là một phần của kho lưu trữ GitHub (GitHub repository) và thực sự là một cái gì đó bạn có thể thử nghiệm và bắt đầu khi khám phá không gian thiết kế và GEPA. Và bạn có thể thấy ở đây, về cơ bản nó cố gắng xây dựng cấu hình dựa trên các tham số như kwargs, và sau đó gọi Optimize Anything với các tham số này. Và đối với loại evaluator, về cơ bản nó gọi LLM làm giám khảo và thêm tất cả thông tin phụ. Vì vậy, nó không chỉ cung cấp quỹ đạo (trajectory), mà còn cung cấp chú thích, điều này khá quan trọng. Và sau đó chúng tôi chạy cái này, như tôi đã đề cập, phải mất khoảng một giờ để chạy.
Và bạn có thể thấy ở đây, về cơ bản là kết quả. Đây là Rubik được tối ưu hóa. Và bạn có thể thấy so với mặc định nơi chúng ta bắt đầu, nó đã học được một phần các tiêu chí chính sách như hủy chuyến bay và tái cấp vốn, sửa đổi chuyến bay, cách giao tiếp, v.v. Bây giờ, nếu chúng ta nhìn vào kết quả, giống như với loại evaluator Rubik để đánh giá nó, chúng ta thấy rằng độ chính xác đã tăng từ 69% lên 74%. Và chúng ta đã loại bỏ thiên vị, phải không? Vậy điều gì đặc biệt thay đổi là độ nhạy đối với không tuân thủ và độ chính xác đối với không tuân thủ, ban đầu về cơ bản là bằng không. Bây giờ, LLM làm giám khảo ít thiên vị hơn. Nó là 64% so với 98% và nó thực sự đã học được các phần của chính sách. Vì vậy, nhìn vào kết quả, như tôi đã đề cập, đối với tập xác thực, chúng ta đã có khá nhiều cải thiện, khoảng 14%. Và đối với độ chính xác huấn luyện, nó đã cải thiện 9 điểm. Và bạn có thể thấy rằng Pareto front ở đây một cách thú vị là độ chính xác hiện là 100%, có nghĩa là đối với mỗi nhiệm vụ, có một ứng viên mà chúng tôi đã tạo ra đã giải quyết được nó. Vấn đề mà thuật toán gặp phải là làm thế nào để hợp nhất tất cả các ứng viên này và tất cả thông tin để có một lời nhắc giải quyết mọi thứ. Và nó đã gặp khó khăn trong việc này. Vì vậy, cuối cùng, chúng tôi đã cải thiện LLM làm giám khảo, chúng tôi đã cải thiện độ chính xác. Nhưng nó vẫn còn khá xa so với độ chính xác khoảng 95% hoặc một cái gì đó thực sự phù hợp với đánh giá của con người. Rõ ràng, ở đây tôi không đầu tư quá nhiều thời gian vào nó, và như tôi đã đề cập ở phần đầu, chất lượng dữ liệu cũng sẽ tốt hơn, tôi đoán vậy. Trong các trường hợp khác, đó thực sự là một ví dụ khó. Nhưng dù sao đi nữa, nó thực sự đã mất khá nhiều lần lặp. Tôi nghĩ đó là bài học lớn nhất để đạt được LLM làm giám khảo này. Nó không phải là một thuật toán mà bạn chỉ cần lấy và nó hoạt động ngay từ ngày đầu tiên, và nó xa vời các ví dụ đồ chơi.
Các Thử nghiệm Thất bại và Bài học Kinh nghiệm
Và cuối cùng tôi muốn trình bày một chút về những thử nghiệm tôi đã thử ban đầu đã thất bại và cách tôi suy nghĩ để khắc phục chúng. Điều đầu tiên thực sự là sử dụng mô hình nhỏ hơn hoặc cũ hơn, như sử dụng GPT-4 cho cả refiner (bộ tinh chỉnh) và LLM làm giám khảo. Và đó là một thất bại hoàn toàn. Các mô hình nhỏ hơn thực sự rất kém, ít nhất là trong ví dụ này, để đóng vai trò LLM làm giám khảo hoặc refiner. Đối với LLM làm giám khảo, việc cung cấp tất cả chính sách này, đặc biệt là nó có rất nhiều logic phức tạp, nó chỉ thất bại và không thể cải thiện được. Tôi đã thử các mô hình khác: tôi đã thử Mixtral, Nano, Gemini, và DeepSeek. Và bạn thấy rằng kết quả tốt nhất là khi sử dụng Gemini để phản hồi và Grok làm giám khảo, nhưng tôi cũng phải nói rằng sử dụng GPT-4 Mini cho cả hai cũng khá tốt và kết quả khá ổn.
Điều khác thực sự là cố gắng debug (gỡ lỗi) nó. Và điều tôi đã cố gắng làm ngay từ đầu là thực sự không bắt đầu lấy mẫu, thực hiện các thử nghiệm lớn ngay từ đầu, mà cố gắng trước tiên thực hiện các lần lặp nhỏ, xem xét LLM lý luận, xem xét ứng viên, cách chúng cải thiện, bao nhiêu đã cải thiện, trong việc hiểu điều gì đang xảy ra. Và đó thực sự là điều đã cho phép tôi suy nghĩ về việc cải thiện lời nhắc tinh chỉnh (refinement prompt) và về cơ bản là thêm một số tiên nghiệm vào đó để giúp đỡ. Về cơ bản, điều tôi đã làm là tôi dừng lại ở lần lặp đầu tiên, tìm một số ví dụ, và sau đó xem xét một chút để tinh chỉnh (fine-tune) trong Claude Code lời nhắc tinh chỉnh đó để về cơ bản cho phép nó cải thiện ứng viên. Và như mọi khi trong học máy, điều bạn luôn cố gắng làm là quá khớp (overfit) với dữ liệu huấn luyện (training data), không cố gắng chạy thuật toán cũ, mà thực sự cố gắng tìm ra cách để nó hoạt động. Và tôi nghĩ điều chúng ta đã thấy với các năm rất khác nhau, mỗi năm đạt 100%, là chúng ta gần như quá khớp với dữ liệu huấn luyện, nhưng rõ ràng đối với việc hợp nhất, có những điều tôi nghĩ chúng ta có thể làm để cải thiện.
Và điều cuối cùng là tình huống với lời nhắc seed. Ở đó, tôi thực sự đã lặp lại nhiều lời nhắc seed, và có hai nhóm. Một nhóm, như bạn đã thấy ở đây, không bao gồm bất kỳ thông tin nào về lời nhắc tác nhân (agent prompt) vì chúng tôi có quyền truy cập vào đó, phải không? Và lời nhắc tác nhân có quyền truy cập vào chính sách. Và một nhóm có quyền truy cập vào chính sách. Vì vậy, về cơ bản, đó là lời nhắc mà tôi đã hiển thị, nhưng sau đó chính sách của tác nhân đã được sao chép y nguyên. Và điều thú vị là lời nhắc không có quyền truy cập vào chính sách lại hoạt động tốt hơn bởi vì giả thuyết của tôi là nếu bạn có quyền truy cập vào chính sách tác nhân ngay từ đầu, thì rất khó để tinh chỉnh nó. Bạn đã bị mắc kẹt trong cực tiểu cục bộ (local minima) mà bạn không thể cải thiện được. Nhưng nếu bạn không có quyền truy cập vào chính sách, và rõ ràng bạn có quyền truy cập vào các chú thích mô tả trong trường hợp này tất cả chính sách, hoặc một phần lớn chính sách, thì bạn có thể khám phá không gian của lời nhắc tốt hơn nhiều.
Lưu ý về Chi phí và Thực hành Tốt nhất
Và cuối cùng, điểm cuối cùng là hãy cẩn trọng với chi phí. Ngay cả những thử nghiệm nhỏ mà tôi đã làm, tôi nghĩ chúng đã tốn khoảng hai, ba trăm đô la mã thông báo (tokens), đặc biệt là vì các quỹ đạo dài. Vì vậy, có rất nhiều mã thông báo đầu vào trong trường hợp này. Nhưng các mô hình được sử dụng thực sự khá đắt tiền, phải không? GPT-4 — ý tôi là, tôi đã thử nghiệm một chút với GPT-4, nhưng nó đã tiêu tốn rất nhiều tiền. Vì vậy, tôi đã dừng thử nghiệm. Nhưng ngay cả GPT-4 Mini cũng khá đắt ở một mức độ nào đó. Và sau đó nếu bạn sử dụng Nano, ít nhất là từ những gì tôi thấy, nó không hoạt động, phải không? Ngoài ra, bạn sử dụng mô hình nhỏ hơn, mô hình rẻ hơn, nó không hoạt động. Thông thường, họ nói rằng bạn nên sử dụng một mô hình lớn hơn cho lời nhắc tinh chỉnh và một mô hình nhỏ hơn cho LLM làm giám khảo. Tôi nghĩ điều đó có lý, đặc biệt là nếu bạn đang chạy LLM làm giám khảo đối với nhiều dấu vết (traces) như trong trường hợp đánh giá trực tuyến. Rõ ràng là đáng để đầu tư tiền vào việc tối ưu hóa để giảm chi phí về lâu dài. Tôi nghĩ có rất nhiều trường hợp sử dụng mà nó đã hoạt động.
Vì vậy, một lần nữa, trước tiên hãy quá khớp với dữ liệu huấn luyện, bắt đầu với lần lặp nhỏ, trực quan hóa. Về cơ bản, công cụ hóa (instrument) các dấu vết. Tôi đã công cụ hóa bằng cách sử dụng Agenda trong trường hợp này. Cố gắng xem xét chúng, cố gắng xem xét các lời nhắc đã được tạo và hiểu cách thuật toán hoạt động trước khi tăng lấy mẫu. Và trong trường hợp này, tôi nghĩ chúng tôi đã có khoảng 200, 300 lần lặp cho mỗi thử nghiệm. Ngoài ra, thực sự có một số tham số như kích thước lô (batch size) và nhiều thứ khác mà bạn cần tinh chỉnh để thuật toán hoạt động. Vậy đó là tất cả. Cảm ơn rất nhiều vì đã theo dõi.
Lời Kết và Lời Mời Cộng Tác
Tôi hy vọng điều này hữu ích và bạn sẽ xây dựng được Mô hình ngôn ngữ lớn tốt làm công cụ đánh giá, giúp cải thiện các ứng dụng của mình. Tôi rất mong bạn khám phá Agenda, nền tảng LLM ops platform mã nguồn mở của chúng tôi. Bạn có thể theo dõi tôi trên cả LinkedIn và X. Cuối cùng, nếu bạn đang suy nghĩ và làm việc về auto-optimization, về cách tối ưu hóa lời nhắc, đừng ngần ngại liên hệ hoặc để lại bình luận trên YouTube. Chúc bạn một ngày tốt lành. Xin cảm ơn.
TL;DR
- Các giám khảo LLM chưa được hiệu chỉnh thường không đáng tin cậy trong môi trường
production, dẫn đến việc các tác nhân AI thất bại mặc dù hệ thống giám sát báo cáo hoạt động tốt. - Để giải quyết vấn đề này, cần xây dựng các giám khảo LLM đã được hiệu chỉnh bằng cách sử dụng tối ưu hóa
lời nhắc(ví dụ: thuật toán GIPA) dựa trên chú thích của con người. - Việc có các giám khảo LLM đã được hiệu chỉnh giúp tăng tốc vòng lặp phát triển AI, cải thiện đánh giá
onlinevàoffline, đồng thời cho phép xây dựngvòng lặp dữ liệuAI tự động.
Điểm chính
- Vấn đề với Giám khảo LLM chưa Hiệu chỉnh: Giám khảo LLM chung chung (như phát hiện "ảo giác") thường không hiệu quả vì chúng không thể biết liệu đầu ra của tác nhân có đúng hay không nếu không có ngữ cảnh hoặc hiệu chỉnh cụ thể.
- Tầm quan trọng của Hiệu chỉnh: Giám khảo LLM cần được "hiệu chỉnh" (calibrated) dựa trên chú thích của con người để đảm bảo chúng tương quan với đánh giá của con người và mục tiêu kinh doanh.
- Phương pháp Hiệu chỉnh: Sử dụng tối ưu hóa
lời nhắc(prompt optimization) là cách chính để hiệu chỉnh các giám khảo LLM, với GIPA là một thuật toán được đề xuất. - Lợi ích: Các giám khảo LLM đã hiệu chỉnh tăng tốc đáng kể
đánh giá offline(giảm thời gian lặp lại phát triển tác nhân), cải thiệnđánh giá online(phản ứng nhanh với thay đổi trong môi trường production) và là yếu tố then chốt để xây dựngvòng lặp dữ liệuAI tự động. - Thiết kế Metric cụ thể: Cần thiết kế các
metricđánh giá cụ thể theotrường hợp sử dụng(ví dụ:tuân thủ chính sách,kiểu phản hồi), thay vì cácmetricchung chung. Việc sử dụng nhiều giám khảo LLM chuyên biệt cho từng loại lỗi sẽ hiệu quả hơn một giám khảo tổng quát. - Định dạng Chú thích Nhị phân và Lý do: Ưu tiên
phân loại nhị phân(đúng/sai, tuân thủ/không tuân thủ) kèm theolý dochi tiết trong chú thích của con người, thay vì thang điểm (1-5), để giám khảo LLM dễ học và hiệu chỉnh hơn. - Thử thách về Dữ liệu: Thu thập và tuyển chọn
dữ liệuchú thích là phần khó nhất; dữ liệu cần đủ lớn, phân phối tốt và chú thích rõ ràng để thuật toán tối ưu hóa có thể học được mộtrepresentationcó ý nghĩa. - Cách hoạt động của GIPA: Thuật toán GIPA (tương tự
thuật toán di truyền) bắt đầu với mộtlời nhắc gốc, sau đó lặp đi lặp lại việc lấy mẫu các ứng cử viên mới thông quađột biến lời nhắc(prompt mutation) hoặchợp nhất(merge), đánh giá chúng trênmini batches, và chọn cáclời nhắctốt hơn (sử dụngPareto frontier) để tiếp tục tối ưu hóa.
Từ vựng
Mô hình Ngôn ngữ Lớn—LLM(Large Language Model)tác nhân—agentảo giác—hallucinationlời nhắc—prompthiệu chỉnh—calibratedtối ưu hóa lời nhắc—prompt optimizationvòng lặp dữ liệu—data flywheelmetric—metrictuân thủ chính sách—policy adherencethuật toán di truyền—genetic algorithmđột biến lời nhắc—prompt mutationPareto frontier—Pareto frontier
Nội dung chi tiết
Chào mừng tất cả mọi người đến với buổi nói chuyện/workshop của tôi, "Đánh giá người đánh giá." Hôm nay, chúng ta sẽ nói về các Mô hình Ngôn ngữ Lớn (LLM) đóng vai trò là giám khảo.
Thách Thức Trong Giám Sát Độ Tin Cậy của Tác nhân AI
Chắc chắn bạn đã quen với kịch bản này: Bạn có một tác nhân đang chạy trong môi trường production, và ai đó trong nhóm nói, "Chúng ta cần giám sát độ tin cậy." Vì vậy, bạn tìm đến một trong các thư viện, có thể sử dụng giám khảo LLM chuyên phát hiện "ảo giác" (hallucination), đưa nó vào môi trường production trong nền tảng khả năng quan sát (observability) của bạn, và mọi thứ có vẻ ổn. Nhưng khách hàng lại thực sự nói rằng tác nhân không hoạt động. Bạn xem xét các trace – nó không hoạt động. Bây giờ bạn xem xét sâu hơn về giám khảo LLM phát hiện "ảo giác" này, và bạn sẽ tìm thấy một lời nhắc không khác xa lắm so với cái này: "Bạn sẽ được cung cấp đầu ra của một LLM, phải không? Liệu đó có phải là 'ảo giác' hay không?" Rõ ràng, làm thế nào mà tác nhân có thể biết liệu đó có phải là "ảo giác" hay không? Nếu nó có thể, thì đầu ra của bạn đã hoạt động ngay từ ngày đầu tiên rồi.
Xây Dựng LLM Giám Khảo Đã Hiệu Chỉnh
Vì vậy, hôm nay, chúng ta sẽ nói về cách chúng ta có thể xây dựng các LLM đã được hiệu chỉnh (calibrated) để đóng vai trò giám khảo một cách hiệu quả. "Hiệu chỉnh" có nghĩa là hiệu chỉnh dựa trên chú thích của con người. Cách chúng ta hiệu chỉnh chúng là bằng cách sử dụng tối ưu hóa, hoặc cụ thể hơn là tối ưu hóa lời nhắc (prompt optimization). Chúng ta sẽ sử dụng GIPA, một thuật toán khá tốt để tối ưu hóa các lời nhắc. Vậy tại sao chúng ta lại cần điều này? Tại sao chúng ta muốn các LLM giám khảo đã được hiệu chỉnh hoặc các LLM giám khảo tốt?
Tăng Tốc Đánh Giá Offline
Điều đầu tiên là dành cho các đánh giá offline. Như bạn đã biết, thông thường để tạo ra một tác nhân tốt hoặc một lời nhắc tốt, cách bạn làm là thử nghiệm với lời nhắc, sau đó chạy các đánh giá của bạn, xem liệu nó có cải thiện mọi thứ hay không. Nếu có, tốt. Nếu không, bạn quay lại và cải thiện nó một chút, cải thiện khung điều khiển (harness), lời nhắc, và lặp lại nhiều lần. Tốc độ mà bạn chuyển sang môi trường production hoặc thêm tính năng thực chất là tốc độ bạn có thể hoàn thành vòng lặp này. Nút cổ chai trong vòng lặp này chính là đánh giá: Bạn có thể đánh giá nhanh đến mức nào? Rõ ràng, đánh giá chậm nhất có thể là việc có một người chú thích thủ công xem xét toàn bộ tập test set của bạn và chú thích nó bằng tay. Chất lượng khá tốt, nhưng mỗi lần lặp lại sẽ mất rất nhiều thời gian. Bạn có thể có các cách nhanh hơn bằng cách sử dụng một LLM làm giám khảo, nhưng nếu LLM đó không tương quan với chú thích của con người, thì bạn sẽ thường không nhận được tín hiệu nào, và toàn bộ quá trình sẽ diễn ra nhanh chóng nhưng không đi đến đâu. Vì vậy, việc có một LLM đã được hiệu chỉnh làm giám khảo với chất lượng tương tự, ví dụ như một người chú thích bằng tay, sẽ giúp quá trình phát triển nhanh hơn nhiều.
Cải Thiện Đánh Giá Online
Điều thứ hai về cơ bản là đánh giá online. Giống như ví dụ của chúng ta từ đầu, nếu bạn có một đánh giá online, bạn muốn xem về cơ bản trong môi trường production liệu mọi thứ có đang cải thiện hay không. Tương tự, nếu bạn có một LLM làm giám khảo đã được hiệu chỉnh với các mục tiêu kinh doanh của mình, thì bạn có thể nhanh chóng thấy liệu những thay đổi bạn đã thực hiện có đang cải thiện hay không, liệu có sự thay đổi nào trong phân phối dữ liệu (data) hay không, cách mọi người tương tác với tác nhân hoặc mô hình (model) của bạn, và về cơ bản là phản ứng nhanh chóng.
Tối Ưu Hóa Vòng Lặp Dữ Liệu AI
Và cuối cùng, tôi gọi đây là "Chén thánh" của kỹ thuật AI (AI engineering): thực sự xây dựng vòng lặp dữ liệu (data flywheel) này. Nơi bạn tối ưu hóa khung điều khiển của mình, quan sát các trace, và sau đó thêm các đánh giá mới dựa trên các trace này – các trường hợp biên (edge cases) – và lặp lại nhiều lần. Ở đây, nếu bạn có cách để thêm các đánh giá mới một cách nhanh chóng, rõ ràng là các đánh giá tự động, từ các trace, từ các chú thích, dữ liệu, bạn có thể đi qua vòng lặp này nhanh hơn và nhanh hơn đến mức bạn có thể coi đó là một vòng lặp tự động. Đúng vậy, bởi vì bạn có thể tối ưu hóa các khung điều khiển bằng các kỹ thuật tối ưu hóa (optimization techniques) như GIPA, điều mà chúng ta sẽ sử dụng ở đây. Nhưng điều tương tự, bạn có thể làm với các đánh giá, và về cơ bản, theo thời gian, ứng dụng (application) của bạn sẽ cải thiện chỉ với những quan sát mới.
Giới Thiệu Về Diễn Giả và Nền Tảng Agenda
Vì vậy, hôm nay, chúng ta sẽ xây dựng và tối ưu hóa các LLM này để đóng vai trò giám khảo, được hiệu chỉnh với các chú thích của con người. Nhưng trước khi đi sâu vào đó, một lời giới thiệu ngắn gọn về bản thân tôi: Tên tôi là Mahmoud, đồng sáng lập và CEO của Agenda. Agenda là một nền tảng vận hành LLM mã nguồn mở (open source LLM ops platform), về cơ bản cung cấp cho bạn tất cả các công cụ (tool) từ khả năng quan sát, quản lý lời nhắc, đánh giá – bao trùm toàn bộ vòng đời (lifecycle) của việc xây dựng các tác nhân đáng tin cậy. Kinh nghiệm của tôi là trong máy học (machine learning); tôi có hơn 15 năm kinh nghiệm trong lĩnh vực đó. Trước đây, tôi làm việc trong giới học thuật, nghiên cứu về máy học ứng dụng vào sinh học tính toán (computational biology), dự đoán cấu trúc protein (protein structure prediction), và hiện tại, chúng tôi đang tập trung nhiều vào các quy trình lấy mẫu (sampling) và tối ưu hóa tự động (auto-optimization workflows) này. Vì vậy, nếu bạn quan tâm đến điều đó, vui lòng liên hệ; tôi rất muốn có một cuộc trò chuyện và cho bạn thấy những gì chúng tôi đang xây dựng.
Kế Hoạch Cho Buổi Nói Chuyện
Vậy kế hoạch cho buổi nói chuyện này là gì? Về cơ bản, chúng ta sẽ làm việc trên một trường hợp sử dụng (use case) thực tế. Đó là một tác nhân hỗ trợ khách hàng (customer support agent) mà chúng ta muốn đánh giá. Và chúng ta sẽ xây dựng một LLM làm giám khảo được hiệu chỉnh với các chú thích – về cơ bản là chú thích của con người – cho tác nhân hỗ trợ khách hàng đó. Kế hoạch sẽ là đi qua toàn bộ quá trình xây dựng này, bắt đầu từ cách chúng ta thiết kế các metric, cách suy nghĩ về tuyển chọn dữ liệu (data curation), gán nhãn (labeling), nhưng trọng tâm chính sẽ thực sự là phần tối ưu hóa LLM làm giám khảo bằng GIPA, và sau đó rõ ràng là xác thực kết quả. Toàn bộ mã nguồn (code) và dữ liệu (data) được sử dụng trong phần này sẽ có trên GitHub, và bạn có thể tìm thấy chúng trong các liên kết trong video này và trên slide cuối cùng.
Bộ Dữ Liệu TaoBench
Vậy, hãy bắt đầu với các tập dữ liệu (datasets). Chúng ta sẽ sử dụng TaoBench. TaoBench là một điểm chuẩn (benchmark) trong một tập dữ liệu lớn được xây dựng bởi Sierra Customer Support Scala, tôi nghĩ vậy. Và họ có nhiều điểm chuẩn cho các kịch bản thực tế đối với các tác nhân hỗ trợ khách hàng. Một trong số đó là tác nhân hàng không (airline agent), mà chúng ta sẽ sử dụng trong ví dụ này. Về cơ bản, cái họ có là một tác nhân hỗ trợ khách hàng hàng không có quyền truy cập vào nhiều công cụ để quản lý đặt chỗ, truy cập thông tin chuyến bay, truy cập thông tin người dùng, và có một chính sách khá phức tạp cần tuân thủ, chẳng hạn như khi nào cần thay đổi đặt chỗ, khi nào cần cung cấp thông tin, v.v., giống như một tác nhân hỗ trợ khách hàng là con người. Và dữ liệu mà chúng ta có là bản thân tác nhân, nhưng quan trọng hơn, là 599 trace cuộc hội thoại được tạo ra kèm theo các chú thích. Hiện tại, định dạng, định dạng gốc của các chú thích, là ở dạng assertion. Nhưng tôi đã tiền xử lý hoặc bypassed xử lý dữ liệu để chúng ta có một chú thích cho mỗi trace, giống như một chú thích của con người, trong đó nói rằng, ví dụ, trong trường hợp này, bạn có cuộc hội thoại mà bạn thấy ở đây, và sau đó bạn có một chú thích rằng tác nhân không tuân thủ vì nó đã chấp thuận việc hủy mà không xác minh rằng đặt chỗ đã đáp ứng các quy tắc hủy của hãng hàng không. Vì vậy, về cơ bản, đánh giá đã thất bại, và lý do là vì tác nhân đã hủy đặt chỗ mà không xác minh điều gì đó, về cơ bản, nó đã không tuân thủ chính sách. Và dữ liệu nhìn chung không được tốt lắm; nó tuân thủ 62%, không tuân thủ 38%, và nó được tạo ra với nhiều mô hình và thử nghiệm. Nhìn chung, dữ liệu, vấn đề khá phức tạp vì chính sách khá phức tạp. Dữ liệu có những lưu ý (caveats), thành thật mà nói; nó không thực sự sạch sẽ do cách nó cũng được tạo ra. Nhưng đối với trường hợp sử dụng của chúng ta, tôi nghĩ đây là một trường hợp sử dụng rất thú vị để thử nghiệm GIPA và để minh họa cách nó hoạt động trong một trường hợp thử nghiệm (test case).
Quy Trình Đánh Giá và Thiết Kế Metric
Quy trình làm việc mà chúng ta có gồm bốn bước. Điều đầu tiên là thiết kế các metric – tức là, quyết định LLM với vai trò giám khảo sẽ đo lường cái gì, những khía cạnh khác nhau mà nó sẽ xem xét là gì? Điều thứ hai là chú thích dữ liệu. Và sau đó chúng ta sẽ tối ưu hóa giám khảo và xác thực kết quả. Bây giờ, điều quan trọng nhất cần lưu ý ở đây là các metric cần phải đến từ bản thân trường hợp sử dụng. Không có ý nghĩa gì khi có các metric chung chung như "ảo giác" khi bạn đang đánh giá tác nhân AI của mình. Nó thực sự phụ thuộc vào trường hợp sử dụng kinh doanh, và người tốt nhất, những người tốt nhất để xác định các metric này là các chuyên gia về lĩnh vực. Ví dụ, trong trường hợp tác nhân hỗ trợ khách hàng, bạn cần có một chuyên gia về lĩnh vực xem xét cuộc hội thoại, đưa ra phản hồi (feedback). Và tôi nghĩ quy trình làm việc để làm điều đó, người mô tả nó tốt nhất là Hamil từ Hamil Dev. Tôi sẽ chia sẻ blog và video YouTube của anh ấy, và anh ấy thực sự mô tả ý tưởng về phân tích lỗi (error analysis) này rất tốt. Nhưng tôi sẽ nói qua rất nhanh về nó và cả quy trình chú thích (annotation workflow) nữa.
Quy Trình Chú Thích và Xác Định Loại Lỗi
Vì vậy, ý tưởng là bạn cung cấp cho chuyên gia về lĩnh vực của mình tất cả các trace về quỹ đạo của cuộc hội thoại, và họ sẽ chú thích chúng đầu tiên bằng cách bình luận về những gì đã hoạt động hoặc những gì không hoạt động. Nhưng sau đó, từ từ cố gắng phân cụm, tạo ra các cụm (clusters) các loại lỗi (error type), như khi nào nó thất bại, tại sao nó thất bại. Và ở đây, tôi đang trình bày trong Agenda cách nó được thực hiện, và về cơ bản, ở đây tôi có, tôi đã khám phá ra bốn loại lỗi này khi xem xét các trace này: Đôi khi có vấn đề với tuân thủ chính sách (policy adherence), đôi khi có vấn đề với kiểu phản hồi (response style), cung cấp thông tin (information delivery) (về cơ bản là tác nhân không thông báo cho khách hàng rằng họ đã thực hiện thay đổi hoặc đại loại thế), và cuối cùng, một số công cụ đã không được gọi đúng cách. Và ý tưởng là chúng ta sẽ lấy bốn loại lỗi này, và sau đó chúng ta sẽ xây dựng bốn LLM làm giám khảo cho chúng. Vì vậy, việc có một LLM làm giám khảo duy nhất, mà là "thành công" – về cơ bản cố gắng đánh giá tất cả những điều này – là không hợp lý. Nó sẽ làm cho mọi thứ quá phức tạp, và rất khó học. Và bạn sẽ thấy sau một chút rằng ngay cả với một LLM đơn giản, ngay cả khi chúng ta đơn giản hóa nó, vẫn khó để học một LLM giám khảo đã được hiệu chỉnh hoặc tối ưu hóa một LLM giám khảo đã được hiệu chỉnh. Vì vậy, rất hợp lý khi làm cho mọi thứ rất cụ thể trong các metric mà chúng ta muốn đánh giá này. Và điều thứ hai là chuyển khỏi điểm từ một đến năm hoặc tỷ lệ phần trăm, và thay vào đó có một giải pháp thực sự nhị phân, chẳng hạn như liệu nó có tuân thủ chính sách hay không, với rõ ràng là một số lý do (reasoning). Và lý do là, một lần nữa, đã khá khó để hiệu chỉnh một LLM làm giám khảo với một phân loại đúng/sai, như phân loại nhị phân (binary classification). Thêm một lớp nữa và nói, "Được rồi, nó phải là một số từ một đến năm," thì khó. Ngay cả đối với người chú thích bằng tay, cũng khó để có hai người chú thích đồng ý về cùng một điểm số.
Vì vậy, ngay khi chúng ta đã xác định các metric khác nhau này, điểm chú thích bắt đầu. Ở đây, một lần nữa, tôi đang sử dụng Agenda. Về cơ bản, bạn sẽ lấy các trace của mình, tạo một hàng đợi chú thích (annotation queue), và chỉ định cho người chú thích của bạn, chẳng hạn như tên của phản hồi hoặc tuân thủ chính sách của người đánh giá (evaluator policy adherence) ở đây. Và sau đó cung cấp, như họ nên cung cấp cho mỗi người liệu nó có tuân thủ chính sách hay không, và cung cấp lý do. Và lý do ở đây rất quan trọng bởi vì nếu không có lý do, chúng ta sẽ thấy thuật toán tối ưu hóa (optimization algorithm) sẽ cần tự khám phá tại sao nó thất bại, và điều đó sẽ rất khó, trừ khi đó là một loại phản hồi rất cụ thể, ví dụ, lỗi công cụ (tool failure), nơi nó có thể suy luận mọi thứ.
Tầm quan trọng của lý do và dữ liệu chú thích
Rất khó để xác định, ví dụ, từ một cuộc hội thoại, tại sao nó không tuân thủ chính sách nếu không có thông tin ban đầu. Vì vậy, việc có lý do đó là rất quan trọng sau này để Mô hình ngôn ngữ lớn (LLM) đóng vai trò trọng tài học hỏi. Lý do này, như đã trình bày trước đây với chú thích, nó mô tả tại sao, ví dụ, tác nhân ở đây không tuân thủ. Đó là bởi vì nó đã phê duyệt việc hủy mà không xác minh rằng đặt chỗ đáp ứng các quy tắc của Conservatory.
Thách thức trong chuẩn bị dữ liệu
Bây giờ chúng ta đã có các chú thích, chúng ta có thể chuyển sang tối ưu hóa. Nhưng trước khi đi sâu vào đó, tôi muốn bổ sung một lưu ý nhỏ. Mặc dù chúng ta đã lướt qua rất nhanh hai bước đầu tiên, đây thực sự là phần khó nhất của vấn đề. Trong thực tế, như mọi nhà khoa học dữ liệu đều biết, việc thu thập dữ liệu là điều khó khăn nhất. Bạn cần đảm bảo xem xét dữ liệu, xem xét chú thích, đảm bảo rằng phân phối tốt, và rằng chú thích cũng như thông tin trong dữ liệu là đủ để thuật toán học được một representation của LLM đóng vai trò trọng tài có ý nghĩa. Trong trường hợp này, dữ liệu không thực sự tốt. Số lượng traces nhỏ, vấn đề khá phức tạp. Chúng không được phân phối tốt do cách chúng được tạo ra. Ngoài ra, chú thích thực sự được AI tạo sinh dựa trên khẳng định và dữ liệu gốc (bạn có thể xem chi tiết hơn về cách thực hiện trong kho lưu trữ). Điều này làm cho mọi thứ khá phức tạp đối với vấn đề này, nhưng nó vẫn là một minh họa khá tốt về cách nó sẽ hoạt động.
Giới thiệu thuật toán GIPA
Bây giờ chúng ta đã có dữ liệu được chú thích, chúng ta có thể bắt đầu với quá trình tối ưu hóa. Đối với tối ưu hóa, chúng ta sẽ sử dụng thuật toán GIPA. Tôi sẽ giải thích cách hoạt động của thuật toán GIPA ngay từ đầu, sau đó chúng ta có thể chuyển sang Jupyter Notebook và bắt đầu tối ưu hóa dựa trên dữ liệu được chú thích. Việc hiểu cách thuật toán hoạt động là rất quan trọng bởi vì bạn sẽ thấy rằng trên thực tế, bạn cần phải thử nghiệm với các tham số một chút để nó hoạt động được. Và rõ ràng là rất khó để thử nghiệm với các tham số nếu bạn không hiểu chúng làm gì.
Cách hoạt động của thuật toán GIPA
Thuật toán này tương tự như thuật toán di truyền (genetic algorithm). Về cơ bản, ý tưởng là bạn bắt đầu với một lời nhắc gốc (seed prompt), sau đó ở mỗi lần lặp, bạn cố gắng lấy mẫu các lời nhắc mới, xem cái nào hoạt động, sau đó chọn những lời nhắc mới và cải thiện dần theo thời gian. Đó là hình dạng tổng quát của thuật toán, và chúng ta sẽ xem xét từng bước. Về cơ bản có ba bước: bạn lấy mẫu các ứng cử viên mới, đánh giá chúng, xem cái nào hoạt động tốt, sau đó thực hiện một số lọc bằng cách sử dụng loại Pareto frontier này (tôi sẽ nói về nó), và sau đó lặp lại nhiều lần.
Hãy xem nó hoạt động như thế nào. Đầu tiên, bạn bắt đầu với một ứng cử viên gốc (seed candidate). Trong trường hợp của chúng ta, chúng ta sẽ sử dụng một LLM đóng vai trò trọng tài rất đơn giản, như đánh giá xem tác nhân dịch vụ khách hàng này có vi phạm chính sách hay không, và bắt đầu với giả định tác nhân này tuân thủ. Bây giờ, ở mỗi lần lặp, chúng ta sẽ lấy mẫu các ứng cử viên mới từ các ứng cử viên đã lọc từ lần lặp trước. Trong lần lặp đầu tiên này, chúng ta chỉ có một ứng cử viên gốc, nhưng ở lần lặp tiếp theo, chúng ta sẽ có một tập hợp lớn hơn các ứng cử viên.
GIPA có hai chiến lược để lấy mẫu các ứng cử viên mới. Một là prompt mutation (đột biến lời nhắc) và cái còn lại là hợp nhất nhiều ứng cử viên. Đối với prompt mutation (đây là cái chúng ta sẽ sử dụng lúc đầu vì chúng ta chỉ có một ứng cử viên), ý tưởng là bạn sẽ chạy LLM đầu tiên đóng vai trò trọng tài ở đây để kiểm tra trajectory và nếu nó thất bại, LLM đóng vai trò trọng tài này sẽ reflection (suy ngẫm) và đề xuất một lời nhắc mới. Về cơ bản, sẽ có một kiểu reflection, có nghĩa là chúng ta đang sử dụng trí thông minh của LLM để cố gắng cải thiện lời nhắc vì nó xem xét đầu vào, xem xét đầu ra, xem xét kết quả và cố gắng suy luận cách làm cho nó tốt hơn. Chiến lược còn lại là chiến lược hợp nhất (merge strategy), mà chúng ta sẽ sử dụng ở lần lặp tiếp theo. Về cơ bản, nó lấy hai lời nhắc và sau đó kết hợp chúng lại với nhau. Và nếu bạn nghĩ về nó với một LLM đóng vai trò trọng tài, bạn thường có các hướng dẫn này, và về cơ bản, điều nó sẽ cố gắng làm là lấy các hướng dẫn từ lời nhắc A và lời nhắc B và kết hợp chúng lại với nhau.
Bây giờ, sau khi chúng ta đã tạo ra rất nhiều mẫu, chúng ta cần chọn cái nào là tốt. Về cơ bản, cách nó hoạt động là nó sẽ đánh giá các lời nhắc mới này đối với các mini batches của quá trình đánh giá, chứ không phải mọi thứ. Và nếu chúng cải thiện hiệu suất so với điểm khởi đầu, thì chúng ta sẽ chọn chúng. Và chúng sẽ được thêm vào tập hợp các lời nhắc của chúng ta, sau đó bắt đầu lần lặp tiếp theo. Đây là cải tiến khác của thuật toán này, đó là ý tưởng về Pareto frontier. Về cơ bản, cách chúng ta chọn lời nhắc hoặc ứng cử viên nào chúng ta sẽ sử dụng làm seed cho lần lặp mới không phải là chúng ta chọn những cái có điểm trung bình tốt nhất (đó sẽ là giải pháp tầm thường, đúng không? Nhìn vào lời nhắc của tôi, xem cái nào hoạt động tốt nhất bằng cách nhìn vào mức trung bình của mọi thứ, và sau đó chọn chúng). Thay vào đó, điều họ làm là cố gắng tăng tính đa dạng bằng cách cố gắng xem xét đâu là ứng cử viên tốt nhất cho task. Bạn có một tập hợp các task trong quá trình đánh giá của mình, như trong trường hợp của chúng ta, một tập hợp các trajectories, và bạn tìm kiếm đối với mỗi trajectory này, đâu là ứng cử viên tốt nhất, và đó chính là Pareto frontier. Sau đó, bạn cố gắng chọn từ những cái này. Về cơ bản, điều bạn làm là cố gắng chọn một tập hợp cuối cùng bao phủ toàn bộ trường hợp task của bạn. Có nghĩa là, đối với mỗi trường hợp thử nghiệm, có ít nhất một ứng cử viên giải quyết nó. Và rõ ràng, bạn thấy ở đó, ý tưởng là bạn có được một Pareto frontier tốt, sau đó bạn bắt đầu hợp nhất mọi thứ, và cuối cùng, bạn có lời nhắc này giải quyết mọi thứ trong quá trình đào tạo của bạn. Bây giờ bạn đã có tập hợp ứng cử viên đã lọc này, chúng ta lại lấy mẫu các ứng cử viên mới từ những cái này bằng cách sử dụng chiến lược mutation và merge, và chúng ta tiếp tục làm điều này cho đến khi ngân sách tính toán (compute budget) kết thúc.
API tối ưu hóa bất kỳ (optimize anything API)
Có rất nhiều thư viện triển khai thuật toán này. Tôi nghĩ rằng cái nổi tiếng nhất là AutoGPT đã phổ biến ý tưởng tối ưu hóa lời nhắc hoặc khung điều khiển (harness). Nhưng bây giờ có một thư viện mới của các tác giả của GIPA, một phần mềm mã nguồn mở (OSS) gọi là GIPA, và họ đã triển khai vào tháng trước một giao diện lập trình ứng dụng (API) mới gọi là optimize anything. Đây là cái chúng ta sẽ sử dụng và có thể được dùng không chỉ để tối ưu hóa lời nhắc mà thực sự để tối ưu hóa hầu hết mọi thuật toán bằng cách sử dụng cùng ý tưởng này. Nó khá mạnh mẽ.
Hãy để tôi cho bạn thấy cách nó hoạt động. Về cơ bản, API ở đây được gọi là optimize anything. Bạn thấy chức năng này và những gì nó nhận vào là một ứng cử viên gốc (seed candidate). Candidate là cấu hình bạn muốn tối ưu hóa. Trong trường hợp của chúng ta, đó sẽ là lời nhắc của LLM đóng vai trò trọng tài, đúng không? Chúng ta thậm chí có thể làm cho nó trở thành một dictionary nếu muốn, ví dụ, lời nhắc của LLM đóng vai trò trọng tài cộng với temperature. Hoặc nó có thể là một chuỗi suy nghĩ (chain of prompt), v.v. vì vậy nó không bị giới hạn. Sau đó, chúng ta có evaluator (bộ đánh giá), về cơ bản là thứ sẽ được GIPA sử dụng để tối ưu hóa, và kỳ vọng từ evaluator là nó rõ ràng sẽ chạy hệ thống. Trong trường hợp của chúng ta, nó sẽ chạy LLM đóng vai trò trọng tài được tham số hóa bởi ứng cử viên, sau đó nó sẽ ghi lại (log) lỗi, lý do, và bạn có thể thêm bao nhiêu tùy thích. Bạn sẽ thấy đây là cách chúng ta sẽ làm với tối ưu hóa của mình cho LLM đóng vai trò trọng tài. Nhưng ý tưởng là, nếu bạn nhớ ở đây, chúng ta đã sử dụng một số loại reflection và reasoning để cải thiện lời nhắc của mình, và reasoning đó là thứ mà chúng ta sẽ tự xây dựng thông qua evaluator này. Và tất cả những cái đó đều có các cách trong cấu hình, ví dụ, để cấu hình số lượng call để thực hiện mỗi lần lặp, mục tiêu, về cơ bản cung cấp context cho refinement prompt về cách cải thiện, v.v. Nhưng luồng cốt lõi thực sự khá đơn giản.
Thực hành với Jupyter Notebook
Bây giờ hãy chuyển sang Jupyter Notebook và thực sự xem cách thực hiện từng bước. Bạn sẽ tìm thấy Jupyter Notebook này trong kho lưu trữ GitHub mà bạn sẽ tìm thấy trong các liên kết và ở slide cuối cùng.
Chúng ta bắt đầu bằng cách cài đặt thư viện, đó là dot and flight LLM và GIPA. Tôi không cài đặt GIPA ở đây vì tôi đã thực hiện tối ưu hóa, nó mất khá nhiều thời gian, tôi nghĩ vài giờ trước đó, vì vậy tôi sẽ bỏ qua bước này. Nhưng rõ ràng, nếu bạn muốn chạy nó trong kho lưu trữ GitHub và Jupyter Notebook, bạn cũng nên cài đặt nó.
Chúng ta cài đặt cái này và chúng ta thực hiện các import. Chúng ta có một vài chức năng mà tôi đã trích xuất ra ngoài, chúng ta sẽ xem xét chúng sau. Và chúng ta bắt đầu bằng cách tải dữ liệu như đã đề cập.
Tải và chuẩn bị dữ liệu
Chúng ta đang sử dụng dữ liệu từ TaoBench. Tôi chỉ xử lý trước nó ngay từ đầu để thay đổi loại khẳng định để chúng trông giống như chú thích mà tôi đã trình bày trong bản trình bày. Vì vậy, tôi đã chia dữ liệu thành tập huấn luyện (training data set) và tập xác thực (validation data set), một tập sẽ được sử dụng với GIPA và tập còn lại để xác thực ở cuối.
Cách tôi thực hiện việc chia tách này là dựa trên các task khác nhau được tạo ra trong TaoBench. Và nếu chúng ta nhìn vào đây, về cơ bản bạn có một tập huấn luyện với 480 traces với khoảng hai phần ba là tuân thủ, và một tập xác thực với 112 traces là tuân thủ. Như đã đề cập, dữ liệu ở đây không được đẹp cho lắm vì có một số dư thừa. Đôi khi có cùng một task đang được chạy với cùng một mô hình nhiều lần, vì vậy có một chút dư thừa. Nhưng không có dư thừa giữa tập huấn luyện và tập xác thực.
Phân tích chú thích và chính sách
Chúng ta hãy xem chú thích trông như thế nào. Về cơ bản, chúng ta có một ví dụ về chú thích tuân thủ (compliant annotation) hoặc không tuân thủ (non-compliant annotation), về cơ bản là một trajectory tuân thủ chính sách mà LLM đóng vai trò trọng tài muốn học, và một cái khác không tuân thủ. Và chúng ta có thể thấy ở đây về cơ bản nó mô tả như: "ok, nó tuân thủ vì nó đã xác định đúng đặt chỗ basic economy", trong khi ở đây "nó không xác định tư cách thành viên của người dùng là regular".
Chú thích này thực sự khá quan trọng đối với chúng ta để LLM đóng vai trò trọng tài học được chính sách, đặc biệt là trong trường hợp này. Chính sách trong quá trình này là một hệ thống rất phức tạp mà LLM đóng vai trò trọng tài cần phải học. Và nếu không có thông tin về những gì là tuân thủ, tại sao một cái gì đó là đúng hoặc không đúng, sẽ khá bất khả thi để thuật toán GIPA đạt được một LLM đóng vai trò trọng tài tốt, đúng không? Ý tôi là, điều đó cũng sẽ tương tự đối với một con người. Nếu bạn đưa cho tôi tất cả những trajectory này và nói với tôi rằng đây là loại chính xác.
Khởi đầu với Giám khảo Naive và Đánh giá Chính sách
Đây là trường hợp không tuân thủ chính sách, nhưng bạn không cung cấp cho tôi thêm thông tin. Sẽ rất khó để tôi đưa ra đánh giá, để học cách đánh giá các chính sách. Do đó, việc có thông tin này và chất lượng của phần chú thích, như tôi đã đề cập, chất lượng của dữ liệu, thực sự rất quan trọng để có thể học được điều này. Và rõ ràng, đây là một Mô hình ngôn ngữ lớn (LLM) đóng vai trò giám khảo khá phức tạp để học.
Điều đầu tiên chúng tôi bắt đầu là với một giám khảo naive (ngây thơ). Đây là giám khảo seed chúng tôi khởi tạo, và đó là điều mà tôi thực sự đã thiết kế. Tôi sẽ nói thêm một chút về nó sau, cùng với những bài học về cách chúng tôi đạt được điều này một cách chính xác. Về cơ bản, bạn có thể thấy ở đây là nó đánh giá xem tác nhân dịch vụ khách hàng có vi phạm chính sách hay không, và nó nói rằng bạn nên bắt đầu bằng cách giả định rằng tác nhân tuân thủ và chỉ thay đổi thành không tuân thủ nếu có một lý do cụ thể, phải không? Ý tôi là, ở đây chúng ta bắt đầu với một LLM làm giám khảo, điều đó có nghĩa là giám khảo seed, giám khảo ban đầu, theo ý kiến của tôi, nên bắt đầu bằng cách nói rằng mọi thứ đều ổn. Ý tôi là, nếu tôi không có bất kỳ quy tắc nào, nó nên nói rằng mọi thứ đều ổn. Tôi đã bắt đầu, và như trong một ví dụ khác, khi tôi bắt đầu tạo một LLM và các công việc khác mà nói rằng, được rồi, bạn nên kiểm tra xem các tác nhân có vi phạm chính sách hay không. Và kết quả cuối cùng là LLM với những thiên vị riêng của nó cố gắng tự đưa ra quyết định đó, nói rằng, được rồi, điều này vi phạm, điều này không vi phạm mà không có bất kỳ thông tin nào. Vì vậy, nếu không nói cho nó ngay từ đầu rằng bạn nên bắt đầu giả định rằng nó tuân thủ (tức là nếu bạn không có bất kỳ lý do nào để tin rằng nó không tuân thủ, nó nên được coi là tuân thủ). Khi đó, về cơ bản, bạn sẽ bắt đầu với một LLM ngẫu nhiên làm giám khảo mà sẽ rất khó để sửa chữa sau này, trừ khi bạn tìm được một lời nhắc đã phát hiện ra điều này ngay từ đầu của sự tuân thủ. Vì vậy, tôi đã khám phá ra rằng seed ban đầu thực sự rất quan trọng trong trường hợp này. Có thể có những kịch bản đơn giản hơn mà bạn không cần điều này, nhưng trong trường hợp này, nó khá quan trọng.
Đánh giá Hiệu suất ban đầu của Giám khảo LLM
Vì vậy, nếu chúng ta lấy điều này và chạy nó trên tập xác thực (validation set), với LLM ban đầu làm giám khảo, chúng ta cơ bản tìm thấy độ chính xác (accuracy) là 61%. Nhưng chúng ta thấy rằng thiên vị (bias) của nó thực sự hầu hết thời gian là nói rằng nó tuân thủ, điều mà chúng ta mong muốn, phải không? Và nếu đó là, tôi sẽ nói, nói rằng nó tuân thủ 98% thời gian thực sự là điều không có thiên vị để làm, là điểm khởi đầu hợp lý. Vì vậy, chúng ta chạy các chỉ số ngay từ đầu, phải không? Độ chính xác 61%, 98% cho thấy độ nhạy (recall) của sự tuân thủ với độ nhạy rất thấp đối với sự không tuân thủ. Và tôi nghĩ, như tôi đã đề cập, điều này khá ổn. Nó bị thiên vị theo hướng tuân thủ, và tôi đã có những thử nghiệm ban đầu khi nó gần như ngẫu nhiên, nhưng sau đó nó không học được gì cả. Và chúng ta có thể xem xét lý do tại sao hoặc nơi nó mắc lỗi. Và về cơ bản, bằng cách nhìn vào những nơi nó hoạt động, và chúng ta thấy rằng nó nói tuân thủ, nhưng nó không tuân thủ vì nó không biết chính sách.
Tối ưu hóa Giám khảo bằng GEPA và Mẫu Phản hồi Tùy chỉnh
Đúng vậy, vì vậy chúng ta bắt đầu ở đây với phần chính của việc tối ưu hóa giám khảo bằng GEPA. Và điều bạn sẽ thấy là tôi thực sự đã viết một mẫu phản hồi (reflection template). Đó là một lời nhắc (prompt) mà GEPA sử dụng để suy ngẫm và lấy mẫu các ứng viên (candidates) mới. Tôi đã không sử dụng mặc định của họ, mà tôi đã tự viết một cái. Ban đầu tôi đã thử sử dụng lời nhắc mặc định trong GEPA, nhưng kết quả không tốt như tôi mong đợi. Nó rất khó để học. Và điều tôi đã cố gắng làm là cung cấp một thiên vị và tiên nghiệm (prior) trong mẫu phản hồi. Vì vậy, bạn thấy ở đây, ví dụ, tôi đã đề cập rõ ràng rằng giám khảo đang đọc một dịch vụ khách hàng hàng không, và nó cần phải quyết định điều cơ bản. Nhưng sau đó bạn có thể xem xét thêm thông tin, ví dụ, chú thích của chúng tôi mà mẫu phản hồi này xem xét cũng bao gồm phán quyết của giám khảo, sự thật cơ bản (ground truth) như chú thích. Đây là thông tin quan trọng mà mẫu phản hồi nên xem xét và cải thiện. Và về cơ bản, tôi giải thích cho LLM cách làm điều này: bạn có thể thêm quy tắc hoặc cấu trúc lại những quy tắc hiện có, khen thưởng những điều rõ ràng và cố gắng nghĩ rằng mẫu phản hồi về cơ bản nên tạo ra các quy tắc chính sách thực sự, phải không? Nó nên tìm ra các chính sách và khả năng phù hợp. Và tôi nghĩ việc thêm điều đó rất quan trọng để cải thiện chất lượng. Nếu không, mẫu phản hồi mặc định đã không hiểu rằng nó nên cố gắng học chính sách ít nhiều, phải không? Với LLM làm giám khảo ở một mức độ nào đó.
Thực hiện Tối ưu hóa và Đánh giá Kết quả
Vậy đó là điều thứ hai tôi đã thay đổi. Và tôi có thể nói thật, nó chỉ là một thay đổi nhỏ. Sau đó, chúng tôi chạy quá trình tối ưu hóa. Một lần chạy tối ưu hóa về cơ bản là một wrapper xung quanh Optimize Anything, và nó chỉ tham số hóa nó vì tôi đã chạy nhiều thử nghiệm để tìm ra một cái. Và nó thực sự sẽ là một phần của kho lưu trữ GitHub (GitHub repository) và thực sự là một cái gì đó bạn có thể thử nghiệm và bắt đầu khi khám phá không gian thiết kế và GEPA. Và bạn có thể thấy ở đây, về cơ bản nó cố gắng xây dựng cấu hình dựa trên các tham số như kwargs, và sau đó gọi Optimize Anything với các tham số này. Và đối với loại evaluator, về cơ bản nó gọi LLM làm giám khảo và thêm tất cả thông tin phụ. Vì vậy, nó không chỉ cung cấp quỹ đạo (trajectory), mà còn cung cấp chú thích, điều này khá quan trọng. Và sau đó chúng tôi chạy cái này, như tôi đã đề cập, phải mất khoảng một giờ để chạy.
Và bạn có thể thấy ở đây, về cơ bản là kết quả. Đây là Rubik được tối ưu hóa. Và bạn có thể thấy so với mặc định nơi chúng ta bắt đầu, nó đã học được một phần các tiêu chí chính sách như hủy chuyến bay và tái cấp vốn, sửa đổi chuyến bay, cách giao tiếp, v.v. Bây giờ, nếu chúng ta nhìn vào kết quả, giống như với loại evaluator Rubik để đánh giá nó, chúng ta thấy rằng độ chính xác đã tăng từ 69% lên 74%. Và chúng ta đã loại bỏ thiên vị, phải không? Vậy điều gì đặc biệt thay đổi là độ nhạy đối với không tuân thủ và độ chính xác đối với không tuân thủ, ban đầu về cơ bản là bằng không. Bây giờ, LLM làm giám khảo ít thiên vị hơn. Nó là 64% so với 98% và nó thực sự đã học được các phần của chính sách. Vì vậy, nhìn vào kết quả, như tôi đã đề cập, đối với tập xác thực, chúng ta đã có khá nhiều cải thiện, khoảng 14%. Và đối với độ chính xác huấn luyện, nó đã cải thiện 9 điểm. Và bạn có thể thấy rằng Pareto front ở đây một cách thú vị là độ chính xác hiện là 100%, có nghĩa là đối với mỗi nhiệm vụ, có một ứng viên mà chúng tôi đã tạo ra đã giải quyết được nó. Vấn đề mà thuật toán gặp phải là làm thế nào để hợp nhất tất cả các ứng viên này và tất cả thông tin để có một lời nhắc giải quyết mọi thứ. Và nó đã gặp khó khăn trong việc này. Vì vậy, cuối cùng, chúng tôi đã cải thiện LLM làm giám khảo, chúng tôi đã cải thiện độ chính xác. Nhưng nó vẫn còn khá xa so với độ chính xác khoảng 95% hoặc một cái gì đó thực sự phù hợp với đánh giá của con người. Rõ ràng, ở đây tôi không đầu tư quá nhiều thời gian vào nó, và như tôi đã đề cập ở phần đầu, chất lượng dữ liệu cũng sẽ tốt hơn, tôi đoán vậy. Trong các trường hợp khác, đó thực sự là một ví dụ khó. Nhưng dù sao đi nữa, nó thực sự đã mất khá nhiều lần lặp. Tôi nghĩ đó là bài học lớn nhất để đạt được LLM làm giám khảo này. Nó không phải là một thuật toán mà bạn chỉ cần lấy và nó hoạt động ngay từ ngày đầu tiên, và nó xa vời các ví dụ đồ chơi.
Các Thử nghiệm Thất bại và Bài học Kinh nghiệm
Và cuối cùng tôi muốn trình bày một chút về những thử nghiệm tôi đã thử ban đầu đã thất bại và cách tôi suy nghĩ để khắc phục chúng. Điều đầu tiên thực sự là sử dụng mô hình nhỏ hơn hoặc cũ hơn, như sử dụng GPT-4 cho cả refiner (bộ tinh chỉnh) và LLM làm giám khảo. Và đó là một thất bại hoàn toàn. Các mô hình nhỏ hơn thực sự rất kém, ít nhất là trong ví dụ này, để đóng vai trò LLM làm giám khảo hoặc refiner. Đối với LLM làm giám khảo, việc cung cấp tất cả chính sách này, đặc biệt là nó có rất nhiều logic phức tạp, nó chỉ thất bại và không thể cải thiện được. Tôi đã thử các mô hình khác: tôi đã thử Mixtral, Nano, Gemini, và DeepSeek. Và bạn thấy rằng kết quả tốt nhất là khi sử dụng Gemini để phản hồi và Grok làm giám khảo, nhưng tôi cũng phải nói rằng sử dụng GPT-4 Mini cho cả hai cũng khá tốt và kết quả khá ổn.
Điều khác thực sự là cố gắng debug (gỡ lỗi) nó. Và điều tôi đã cố gắng làm ngay từ đầu là thực sự không bắt đầu lấy mẫu, thực hiện các thử nghiệm lớn ngay từ đầu, mà cố gắng trước tiên thực hiện các lần lặp nhỏ, xem xét LLM lý luận, xem xét ứng viên, cách chúng cải thiện, bao nhiêu đã cải thiện, trong việc hiểu điều gì đang xảy ra. Và đó thực sự là điều đã cho phép tôi suy nghĩ về việc cải thiện lời nhắc tinh chỉnh (refinement prompt) và về cơ bản là thêm một số tiên nghiệm vào đó để giúp đỡ. Về cơ bản, điều tôi đã làm là tôi dừng lại ở lần lặp đầu tiên, tìm một số ví dụ, và sau đó xem xét một chút để tinh chỉnh (fine-tune) trong Claude Code lời nhắc tinh chỉnh đó để về cơ bản cho phép nó cải thiện ứng viên. Và như mọi khi trong học máy, điều bạn luôn cố gắng làm là quá khớp (overfit) với dữ liệu huấn luyện (training data), không cố gắng chạy thuật toán cũ, mà thực sự cố gắng tìm ra cách để nó hoạt động. Và tôi nghĩ điều chúng ta đã thấy với các năm rất khác nhau, mỗi năm đạt 100%, là chúng ta gần như quá khớp với dữ liệu huấn luyện, nhưng rõ ràng đối với việc hợp nhất, có những điều tôi nghĩ chúng ta có thể làm để cải thiện.
Và điều cuối cùng là tình huống với lời nhắc seed. Ở đó, tôi thực sự đã lặp lại nhiều lời nhắc seed, và có hai nhóm. Một nhóm, như bạn đã thấy ở đây, không bao gồm bất kỳ thông tin nào về lời nhắc tác nhân (agent prompt) vì chúng tôi có quyền truy cập vào đó, phải không? Và lời nhắc tác nhân có quyền truy cập vào chính sách. Và một nhóm có quyền truy cập vào chính sách. Vì vậy, về cơ bản, đó là lời nhắc mà tôi đã hiển thị, nhưng sau đó chính sách của tác nhân đã được sao chép y nguyên. Và điều thú vị là lời nhắc không có quyền truy cập vào chính sách lại hoạt động tốt hơn bởi vì giả thuyết của tôi là nếu bạn có quyền truy cập vào chính sách tác nhân ngay từ đầu, thì rất khó để tinh chỉnh nó. Bạn đã bị mắc kẹt trong cực tiểu cục bộ (local minima) mà bạn không thể cải thiện được. Nhưng nếu bạn không có quyền truy cập vào chính sách, và rõ ràng bạn có quyền truy cập vào các chú thích mô tả trong trường hợp này tất cả chính sách, hoặc một phần lớn chính sách, thì bạn có thể khám phá không gian của lời nhắc tốt hơn nhiều.
Lưu ý về Chi phí và Thực hành Tốt nhất
Và cuối cùng, điểm cuối cùng là hãy cẩn trọng với chi phí. Ngay cả những thử nghiệm nhỏ mà tôi đã làm, tôi nghĩ chúng đã tốn khoảng hai, ba trăm đô la mã thông báo (tokens), đặc biệt là vì các quỹ đạo dài. Vì vậy, có rất nhiều mã thông báo đầu vào trong trường hợp này. Nhưng các mô hình được sử dụng thực sự khá đắt tiền, phải không? GPT-4 — ý tôi là, tôi đã thử nghiệm một chút với GPT-4, nhưng nó đã tiêu tốn rất nhiều tiền. Vì vậy, tôi đã dừng thử nghiệm. Nhưng ngay cả GPT-4 Mini cũng khá đắt ở một mức độ nào đó. Và sau đó nếu bạn sử dụng Nano, ít nhất là từ những gì tôi thấy, nó không hoạt động, phải không? Ngoài ra, bạn sử dụng mô hình nhỏ hơn, mô hình rẻ hơn, nó không hoạt động. Thông thường, họ nói rằng bạn nên sử dụng một mô hình lớn hơn cho lời nhắc tinh chỉnh và một mô hình nhỏ hơn cho LLM làm giám khảo. Tôi nghĩ điều đó có lý, đặc biệt là nếu bạn đang chạy LLM làm giám khảo đối với nhiều dấu vết (traces) như trong trường hợp đánh giá trực tuyến. Rõ ràng là đáng để đầu tư tiền vào việc tối ưu hóa để giảm chi phí về lâu dài. Tôi nghĩ có rất nhiều trường hợp sử dụng mà nó đã hoạt động.
Vì vậy, một lần nữa, trước tiên hãy quá khớp với dữ liệu huấn luyện, bắt đầu với lần lặp nhỏ, trực quan hóa. Về cơ bản, công cụ hóa (instrument) các dấu vết. Tôi đã công cụ hóa bằng cách sử dụng Agenda trong trường hợp này. Cố gắng xem xét chúng, cố gắng xem xét các lời nhắc đã được tạo và hiểu cách thuật toán hoạt động trước khi tăng lấy mẫu. Và trong trường hợp này, tôi nghĩ chúng tôi đã có khoảng 200, 300 lần lặp cho mỗi thử nghiệm. Ngoài ra, thực sự có một số tham số như kích thước lô (batch size) và nhiều thứ khác mà bạn cần tinh chỉnh để thuật toán hoạt động. Vậy đó là tất cả. Cảm ơn rất nhiều vì đã theo dõi.
Lời Kết và Lời Mời Cộng Tác
Tôi hy vọng điều này hữu ích và bạn sẽ xây dựng được Mô hình ngôn ngữ lớn tốt làm công cụ đánh giá, giúp cải thiện các ứng dụng của mình. Tôi rất mong bạn khám phá Agenda, nền tảng LLM ops platform mã nguồn mở của chúng tôi. Bạn có thể theo dõi tôi trên cả LinkedIn và X. Cuối cùng, nếu bạn đang suy nghĩ và làm việc về auto-optimization, về cách tối ưu hóa lời nhắc, đừng ngần ngại liên hệ hoặc để lại bình luận trên YouTube. Chúc bạn một ngày tốt lành. Xin cảm ơn.