Build a Prompt Learning Loop - SallyAnn DeLucia & Fuad Ali, Arize

• Các tác nhân AI hiện nay thường thất bại không phải do mô hình yếu kém mà do hướng dẫn kém, kế hoạch cứng nhắc, thiếu công cụ và đặc biệt là kỹ thuật ngữ cảnh chưa hiệu quả.
• Prompt learning là phương pháp tối ưu hóa lời nhắc bằng cách sử dụng phản hồi phong phú, có giải thích (từ con người hoặc LLM) về lý do tác nhân thất bại, thay vì chỉ dựa vào nhãn đúng/sai.
• Việc bổ sung các quy tắc rõ ràng vào lời nhắc hệ thống có thể mang lại cải thiện hiệu suất đáng kể (ví dụ: 18% cho tác nhân viết mã) mà không cần thay đổi kiến trúc hay chi phí lớn, biến tối ưu hóa lời nhắc thành chiến lược hiệu quả và tiết kiệm.

• Tăng cường độ tin cậy của tác nhân AI bằng cách cải thiện môi trường, xây dựng kế hoạch linh hoạt, cung cấp công cụ đầy đủ và nâng cao kỹ năng kỹ thuật ngữ cảnh (context engineering).
• Áp dụng prompt learning bằng cách thu thập dữ liệu về các thất bại của tác nhân và sử dụng các giải thích chi tiết (do chuyên gia nghiệp vụ hoặc LLM cung cấp) về lý do thất bại để cập nhật lời nhắc.
• Thiết kế lời nhắc hệ thống (system prompt) mạnh mẽ, bao gồm các quy tắc cụ thể và hướng dẫn xử lý lỗi/ngoại lệ, để cải thiện đáng kể hiệu suất tác nhân.
• Coi trọng tối ưu hóa lời nhắc (prompt optimization) như một phương pháp hiệu quả và ít tốn kém nhất để đạt được những cải tiến lớn trong hiệu suất của tác nhân.
• Triển khai quy trình prompt learning liên tục, nơi các trường hợp thất bại mới được thu thập và phân tích để cập nhật và tinh chỉnh lời nhắc theo thời gian, coi "học vẹt" trong ngữ cảnh này là xây dựng "chuyên môn".
• Khi đánh giá tác nhân, không chỉ tập trung vào các nhãn dự đoán mà còn vào các giải thích về lý do thất bại, vì thông tin này cực kỳ giá trị cho việc tối ưu hóa.
• Khám phá các phương pháp tối ưu hóa tiến hóa (evolutionary optimization) như AutoPrompt, sử dụng phản hồi tích cực và hợp nhất lời nhắc để tìm ra bộ lời nhắc tối ưu một cách lặp lại.

• tác nhân — agent
• lời nhắc — prompt
• prompt learning — prompt learning
• kỹ thuật ngữ cảnh — context engineering
• chuyên gia nghiệp vụ — subject matter expert (SME)
• học tăng cường — reinforcement learning
• đánh giá — evaluation
• lời nhắc hệ thống — system prompt
• tối ưu hóa lời nhắc — prompt optimization
• học vẹt — overfit
• tối ưu hóa tiến hóa — evolutionary optimization

Lời giới thiệu và Mục tiêu trình bày

Tôi xin phép bắt đầu. Cảm ơn quý vị rất nhiều vì đã tham gia cùng chúng tôi hôm nay. Tôi là Celia, Giám đốc bộ phận Public Advise. Tôi sẽ trình bày với quý vị về một số kiến thức sản phẩm của chúng tôi. Thực tế, chúng tôi sẽ xây dựng một tính năng tối ưu hóa tài liệu cho sản phẩm. Tôi đã từng làm trong lĩnh vực khoa học dữ liệu trước khi chuyển sang mảng sản phẩm. Tôi vẫn rất thích được động chạm đến mã nguồn ngày hôm nay. Tôi nghĩ một trong những dự án yêu thích của tôi là xây dựng tác nhân riêng của chúng tôi vào nền tảng. Vì vậy, tôi rất quen thuộc với tất cả các khó khăn và tầm quan trọng của việc tối ưu hóa lời nhắc của bạn.

Vì vậy, tôi sẽ trình bày một vài slide để đặt bối cảnh. Mọi người ở đây đều có ngữ cảnh về những gì chúng ta sẽ làm và sau đó chúng ta sẽ đi sâu vào mã nguồn. Tôi rất hoan nghênh. Bây giờ tôi sẽ để Boa giới thiệu một chút. Vâng, cảm ơn Celia rất nhiều. Rất vui được gặp tất cả quý vị. Tôi rất hào hứng khi được cùng quý vị tìm hiểu về prompt learning. Tôi biết quý vị đã có cơ hội xem bài nói chuyện của đối tác ngày hôm qua, nhưng hy vọng điều đó đã cung cấp cho quý vị một số kiến thức nền tốt về sức mạnh của việc prompting trong prompt learning. Tên tôi là Boa. Tôi cũng là một quản lý sản phẩm tại Arise. Như Celia đã nói, chúng tôi thích gắn bó với mã nguồn, chúng tôi sẽ trình bày vài slide và sau đó sẽ đi qua mã nguồn. Chúng tôi sẽ có mặt xung quanh để hỗ trợ những vấn đề tương tự. Chào mọi người, tôi cũng là dân kỹ thuật, có kinh nghiệm lâu năm trong việc triển khai các hệ thống. Vì vậy, tôi hiểu rõ tầm quan trọng của một cơ sở hạ tầng observability. Và tôi nghĩ đây là một bối cảnh phù hợp trong AWS. Vâng, rất mong được đi sâu vào prompt learning cùng quý vị. Cảm ơn.

Được rồi, vậy thì về ngữ cảnh. Để tóm tắt những gì tôi sẽ trình bày: Chúng ta sẽ nói về lý do tại sao các tác nhân thất bại ngày nay. Prompt learning thực sự là gì? Tôi muốn đi qua một case study (nghiên cứu điển hình) và cho quý vị thấy tại sao điều này thực sự hiệu quả. Chúng ta sẽ nói về việc chúng ta đã bỏ qua điều gì trong một thời gian dài. Tôi nghĩ nhiều người đã hỏi tôi tại hội nghị về Kappa? Chúng tôi có một số ý kiến thông minh hơn về vấn đề đó. Sau đó, chúng ta sẽ chuyển sang workshop của mình. Nhưng trước hết, tôi muốn hỏi: Có bao nhiêu người đang xây dựng tác nhân ngày nay? (Khá nhiều). Và có bao nhiêu người thực sự cảm thấy các tác nhân họ đang xây dựng là đáng tin cậy? (Ít hơn nhiều). Vâng, đó cũng là điều tôi nghĩ.

Tại sao các Tác nhân AI thất bại?

Vậy hãy nói một chút về lý do tại sao các tác nhân thất bại ngày nay. Tại sao chúng lại thất bại? Có một xu hướng lớn mà chúng tôi đang thấy với nhiều người và thậm chí là nội bộ khi chúng tôi xây dựng với các LLM về lý do tại sao các tác nhân đang gặp khó khăn. Tôi nghĩ rằng không phải lúc nào cũng do các mô hình yếu kém. Mà rất nhiều khi là do môi trường và các hướng dẫn yếu. Ví dụ, không có hướng dẫn từ môi trường mà chúng học, không có kế hoạch hoặc kế hoạch quá tĩnh. Tôi cảm thấy nhiều tác nhân hiện nay không có kế hoạch. Chúng ta có một số ví dụ tốt về lập kế hoạch, như Cody và Cursor. Đó là những ví dụ rất tốt, nhưng tôi không thấy nó được áp dụng vào mọi tác nhân mà tôi gặp. Thiếu công cụ là một vấn đề lớn. Đôi khi bạn chỉ không có sẵn các công cụ hoặc thiếu các hướng dẫn sử dụng công cụ – kiểu như, chúng ta nên chọn công cụ nào? Và sau đó, context engineering (kỹ thuật ngữ cảnh) tiếp tục là một cuộc đấu tranh lớn đối với nhiều người.

Thách thức cốt lõi: Khả năng thích ứng, Lập kế hoạch và Xử lý ngữ cảnh

Nếu tôi phải tổng kết, tôi nghĩ có ba vấn đề cốt lõi sau: Khả năng thích ứng và tự học – tức là không có hướng dẫn hệ thống để học hỏi từ môi trường. Sau đó là sự cân bằng giữa tính xác định và không xác định. Việc có kế hoạch hoặc không có kế hoạch, so với việc chỉ có một kế hoạch rất tĩnh (static planning) – bạn muốn có một số sự linh hoạt ở đó. Và cuối cùng là context engineering. Tôi nghĩ đây là một thuật ngữ chỉ mới xuất hiện trong sáu đến tám tháng qua, nhưng nó thực sự rất, rất quan trọng. Chúng ta thường thấy thiếu công cụ, thiếu hướng dẫn sử dụng công cụ, không có đủ ngữ cảnh hoặc dữ liệu, và không cung cấp đủ ngữ cảnh cho LLM. Vì vậy, đây là những vấn đề cốt lõi mà chúng ta vẫn đang đối mặt, nhưng tôi nghĩ còn một điều quan trọng khác. Đó là sự phân chia trách nhiệm về việc ai sẽ làm gì.

Phân chia trách nhiệm: Kỹ sư vs. Chuyên gia nghiệp vụ

Có những người dùng kỹ thuật, như kỹ sư, nhà khoa học dữ liệu và nhà phát triển. Họ chịu trách nhiệm về tự động hóa mã nguồn, đường ống (pipeline), quản lý các yếu tố tính toán và chi phí. Mặt khác, chúng ta có các chuyên gia nghiệp vụ (subject matter expert), quản lý sản phẩm (product manager). Họ là những người thực sự hiểu người dùng muốn gì. Họ rất quen thuộc với các nguyên tắc mà chúng ta đang cố gắng xây dựng vào ứng dụng của mình, theo dõi (tracking) và đánh giá (evaluation) của chúng ta, và họ thực sự cố gắng đảm bảo rằng sản phẩm thành công. Vì vậy, có một sự phân chia trách nhiệm, nhưng mọi người đều đóng góp. Đôi khi có sự khác biệt về khả năng kỹ thuật. Do đó, giải pháp sẽ là sự kết hợp của tất cả những yếu tố này, nơi mọi người sẽ thực sự cần phải tham gia và chúng ta có thể nói thêm về điều đó một chút.

Prompt Learning là gì?

Vậy Prompt learning là gì? Đầu tiên, chúng ta sẽ xem xét một số cách tiếp cận mà chúng tôi đã tham khảo để xây dựng prompt learning. Đây là lĩnh vực mà chúng tôi đã dành rất nhiều nỗ lực nghiên cứu. Một trong những điều đầu tiên chúng tôi tham khảo là reinforcement learning (học tăng cường). Có bao nhiêu người ở đây quen thuộc với cách reinforcement learning hoạt động? Được rồi, rất tốt. Nếu tôi dùng một phép ẩn dụ đơn giản, chúng ta đang nói về bộ não của một học sinh mà chúng ta đang cố gắng nâng cao. Học sinh đó sẽ thực hiện một hành động, ví dụ như làm một bài kiểm tra. Sẽ có một điểm số. Giáo viên sẽ chấm bài kiểm tra. Đó sẽ là một tín hiệu, giống như một phần thưởng (reward) vô hướng. Và giả sử học sinh có một thuật toán trong não có thể lấy những điểm số đó và cập nhật trọng số trong não của mình, từ đó điều chỉnh hành vi học tập, và quá trình này lặp lại. Vì vậy, trong reinforcement learning kiểu này, chúng ta cập nhật trọng số dựa trên các giá trị vô hướng (scalar). Nhưng thực sự rất khó để cập nhật trọng số, đặc biệt là trong thế giới LLM. Vì vậy, reinforcement learning sẽ không hoạt động tốt khi chúng ta đang làm những việc như prompting.

Có cách tiếp cận meta-prompting (tự cải thiện lời nhắc), rất gần với những gì chúng ta làm với prompt learning, nhưng vẫn chưa hoàn toàn đúng. Với meta-prompting ở đây, chúng ta yêu cầu LLM tự cải thiện lời nhắc. Lại một lần nữa, chúng ta sử dụng ví dụ về học sinh. Chúng ta có một tác nhân là học sinh của chúng ta và nó sẽ tạo ra một loại đầu ra nào đó. Ví dụ, nếu bạn đặt một câu hỏi và nhận được câu trả lời, đó là trường hợp thử nghiệm của chúng ta. Và sau đó, chúng ta sẽ chấm điểm. Đánh giá (Eval) chính là điều bạn có thể hình dung ở đây. Chúng ta sẽ đưa ra một điểm số. Và từ đó, chúng ta có meta-prompting. Vì vậy, bây giờ giáo viên giống như meta-prompt sẽ lấy kết quả từ điểm số của chúng ta và cập nhật lời nhắc dựa trên đó. Nhưng vẫn chưa hoàn toàn là điều chúng ta muốn làm. Và đó là lúc chúng ta giới thiệu ý tưởng về prompt learning.

Sức mạnh của Phản hồi có giải thích

Prompt learning sẽ lấy dữ liệu đầu vào, tạo ra đầu ra. Chúng ta sẽ có các đánh giá (evaluation) của riêng mình, nhưng cũng có một yếu tố rất quan trọng khác là phản hồi phong phú (enriched feedback). Tức là, câu trả lời nào sai? Tại sao chúng sai? Nơi mà học sinh cần thực sự học để xác định chính xác những vấn đề đó. Và chúng ta vẫn chưa sử dụng cách tiếp cận đó. Chúng ta vẫn chưa yêu cầu một LLM tự cải thiện lời nhắc. Chỉ là thông tin mà chúng ta cung cấp cho LLM là khá khác biệt. Và vì vậy, chúng ta sẽ cập nhật lời nhắc với tất cả các loại phản hồi này. Từ các đánh giá của chúng tôi, cũng như từ các chuyên gia gắn nhãn thủ công, chúng ta sử dụng những thông tin đó để nâng cao lời nhắc của mình bằng các hướng dẫn tốt hơn và đôi khi là các ví dụ.

Vì vậy, đây giống như tối ưu hóa lời nhắc truyền thống, nơi chúng ta coi nó như một mô hình ML (Machine Learning), chúng ta có dữ liệu và có lời nhắc, chúng ta nói hãy tối ưu hóa lời nhắc này và tối đa hóa độ chính xác dự đoán của các biến. Nhưng điều đó không hoàn toàn hiệu quả với các LLM. Chúng ta đang thiếu rất nhiều ngữ cảnh. Vì vậy, điều chúng tôi thực sự tìm thấy là các giải thích của con người về lý do tại sao nó thất bại. Hãy hình dung bạn có dữ liệu ứng dụng (application data), các dấu vết (trace), tập dữ liệu (data set) của bạn, dù là gì đi nữa, chuyên gia nghiệp vụ (subject matter expert) của bạn sẽ xem xét. Và họ không chỉ dán nhãn đúng hay sai. Họ nói 'đây là lý do tại sao nó sai.' Nó không tuân thủ hướng dẫn chính này. Nó không tuân thủ ngữ cảnh. Nó thiếu thông tin cần thiết. Và sau đó, bạn cũng có thể có các giải thích từ LLM đóng vai trò là một thẩm phán, về cơ bản là cùng một nguyên tắc, thay vì chỉ là nhãn (label), nó cung cấp lý do đằng sau nhãn đó.

Và sau đó chúng ta chỉ ra chính xác các hướng dẫn cần thay đổi. Chúng ta đang thay đổi lời nhắc hệ thống (system prompt) để giúp nó cải thiện, nhờ đó chúng ta không chỉ nhận được các nhãn dự đoán (prediction label) mà còn nhận được các đánh giá (evaluation) và giải thích về chủ đề đó. Vì vậy, ở đây chúng ta đang tối ưu hóa nhiều hơn chỉ là đầu ra của chúng ta. Và tôi nghĩ bài học thực sự quan trọng mà chúng tôi đã có là các giải thích trong hướng dẫn của con người hoặc thông qua LLM đóng vai trò là thẩm phán – những văn bản đó thực sự, thực sự có giá trị. Tôi nghĩ đó là điều chúng ta thấy không được tận dụng trong nhiều phương pháp tối ưu hóa lời nhắc khác. Ở đó, bạn chỉ đang tối ưu hóa cho một điểm số, nơi họ chỉ chú ý đến đầu ra. Nhưng bạn có thể hình dung rằng các LLM này đang hoạt động trong miền văn bản (text domain). Vì vậy, chúng ta có tất cả văn bản phong phú này cho chúng ta biết chính xác những gì nó cần làm để cải thiện. Tại sao chúng ta không sử dụng điều đó để thực sự cải thiện đầu ra của mình? Đó là những kiến thức cơ bản về prompting. Nhưng mọi người thường hỏi, 'Nghe có vẻ hay đấy, nhưng liệu nó có thực sự hoạt động trong thực tế không?' Và chúng tôi có một số ví dụ về những gì chúng tôi làm. Chúng tôi đã thực hiện một case study nhỏ. Tôi nghĩ các tác nhân viết mã (coding agent) hiện nay hầu như ai cũng đang sử dụng.

Nghiên cứu điển hình: Cải thiện tác nhân viết mã

Tại thời điểm này, có khá nhiều tác nhân đã rất thành công. Tôi nghĩ Cody và Cursor là những ví dụ tuyệt vời. Nhưng cũng có một tác nhân khác, ví dụ như Clanker, là một phiên bản mã nguồn mở hơn của loại này. Vì vậy, chúng tôi quyết định xem xét và so sánh để xem liệu chúng tôi có thể làm gì để cải thiện chúng hay không. Đây là điểm khởi đầu của chúng tôi. Bạn có thể thấy sự khác biệt giữa các mô hình khác nhau. Cody rõ ràng đang sử dụng GPT-4 và đạt được hiệu suất tiên tiến nhất tại đó. Nhưng chúng tôi cũng có cơ hội thử nghiệm khi Cody sử dụng GPT-4 hoặc GPT-3.5. Và nó hoạt động, dường như đạt khoảng 30% so với 40% (của một mô hình khác). Và có một cuộc thảo luận xung quanh vấn đề này. Đây là nơi chúng tôi bắt đầu. Và chúng tôi đã bắt tay vào tối ưu hóa. Đây là một số lỗi lời nhắc (trước đây). Bạn có thể thấy lời nhắc cũ trông như thế nào. Nó không có phần quy tắc nào cả. Nó chỉ rất đơn giản như 'Bạn là một tác nhân hữu ích. Bạn được xây dựng trên mô hình này. Bạn ở đây để thực hiện viết mã.' Nhưng không có quy tắc nào. Và vì vậy, chúng tôi đã thử cập nhật lời nhắc hệ thống. Vì vậy, đã có tất cả những quy tắc khác nhau. Ví dụ, khi xử lý lỗi hoặc ngoại lệ (exception), hãy xử lý chúng theo một cách cụ thể. Đảm bảo rằng các thay đổi phù hợp với thiết kế hệ thống (systems design) và các thay đổi phải đi kèm với các kiểm thử (test). Thực sự chỉ là xây dựng các quy tắc mà một kỹ sư giỏi sẽ có, điều mà trước đây hoàn toàn thiếu.

Kết quả và bài học chính

Và vì vậy, chúng tôi nhận thấy rằng các quy tắc, cùng với lời nhắc hệ thống được cập nhật của chúng tôi, khá đơn giản. Đó là toàn bộ khái niệm ở đây. Vì vậy, bạn có thể thấy các vấn đề khác nhau (ví dụ về lời nhắc). Và chúng tôi đang thấy những điều trước đây không chính xác nay đã được thực hiện đúng chỉ bằng cách đơn giản thêm nhiều hướng dẫn hơn. Điều này thực sự cho thấy rất rõ ràng cách mà các lời nhắc hệ thống đó có thể cải thiện. Và chúng tôi đã sử dụng benchmark SWE-bench một cách thông minh. Một lần nữa, có các tác vụ viết mã để kiểm tra các tác nhân viết mã này. Và chúng tôi đã có thể cải thiện 18% chỉ thông qua việc thêm các quy tắc. Vì vậy, tôi nghĩ điều đó khá mạnh mẽ. Không cần tăng ngân sách, không thay đổi công cụ, không thay đổi kiến trúc. Tôi nghĩ đó là những điều lớn mà mọi người thường tìm kiếm khi cố gắng cải thiện các tác nhân của họ.

Tối ưu hóa Lời nhắc: Cách tiếp cận hiệu quả

Đôi khi, vấn đề chỉ nằm ở lời nhắc hệ thống (system prompt) của bạn. Việc thêm các quy tắc đã cho thấy hiệu quả rõ rệt. Đó là lý do tại sao chúng tôi rất tâm huyết với việc học hỏi từ tối ưu hóa lời nhắc (prompt optimization) nói chung. Đây vẫn là cách ít tốn công sức nhất để đạt được những cải tiến lớn về hiệu suất của tác nhân (agent) của bạn. Đối với các tác vụ mã hóa, hiệu suất, dạng rắn và năm, vốn được coi là hiện đại nhất (state of the art) trong các câu hỏi mã hóa, chi phí giảm đi hai phần ba, điều này luôn tốt hơn.

Đây là một số người sẽ phân phối thông tin này để bạn có thể xem xét kỹ hơn. Nhưng tôi nghĩ điểm chính mà tôi muốn tất cả các bạn nắm được là việc cải thiện 15% hiệu suất là khá ấn tượng.

Quy trình học lời nhắc và Khái niệm "Học vẹt" trong AI

Chúng tôi luôn áp dụng các ví dụ này vào quá trình học lời nhắc (prompt learning). Vậy quy trình này diễn ra như thế nào? Chúng tôi sẽ sử dụng một tập dữ liệu (data set). Thông thường, tập dữ liệu đó sẽ chứa các ví dụ mà tác nhân đã hoạt động không tốt. Các chuyên gia con người sẽ chú thích (label) chúng và xác định rằng chúng không chính xác, hoặc bạn có các công cụ đánh giá (evaluators) chú thích chúng là không chính xác. Như vậy, bạn có tất cả các ví dụ này, và đó là cơ sở chúng tôi sử dụng để tối ưu hóa lời nhắc.

Tôi thường xuyên nhận được câu hỏi: "Liệu bạn có học vẹt (overfit) dựa trên những ví dụ kém chất lượng này không?" Nhưng có một vai trò của khái quát hóa (generalization), nơi việc điều chỉnh phù hợp sẽ củng cố các quy tắc mã hóa ở cấp độ cao hoặc khả dụng, thay vì chỉ sửa các lỗi cụ thể. Chúng tôi đang thực hiện việc chia tập huấn luyện và kiểm thử (training test split) để đảm bảo rằng các quy tắc sẽ được phân tích vượt ra ngoài những đặc điểm cục bộ và dữ liệu huấn luyện của chúng tôi.

Tuy nhiên, nếu bạn hình dung việc này giống như việc thuê một kỹ sư vào công ty, bạn sẽ muốn họ học vẹt với cơ sở mã (codebase) mà họ đang làm việc. Vì vậy, chúng tôi cảm thấy rằng học vẹt có lẽ là một thuật ngữ tốt hơn cho chuyên môn (expertise). Chúng tôi không huấn luyện dữ liệu theo cách đang cố gắng xây dựng chuyên môn. Và như chúng ta sẽ thảo luận, đây không phải là điều mà chúng tôi nghĩ bạn muốn. Bạn sẽ thực sự chạy quy trình này liên tục. Do đó, sẽ có nhiều trường hợp mới phát sinh. Chúng tôi sẽ tối ưu hóa lời nhắc cho những gì ứng dụng đang thấy hiện tại. Vì vậy, chúng tôi không nghĩ đó là một lỗi. Chúng tôi cảm thấy đó là chuyên môn. Chúng tôi có thể điều chỉnh khi cần thiết, giống như cách con người sẽ làm nếu họ tự thực hiện một nhiệm vụ.

Kết quả đánh giá và Cải tiến

Đây chỉ là một bộ điểm chuẩn (benchmark) khác, một lần nữa chứng minh rằng những vi phạm đa dạng mà chúng tôi có đã được xem xét cho các tác vụ khó đối với mô hình ngôn ngữ (language models). Và chúng tôi lại thấy thành công với những cải tiến của mình.

Phương pháp tối ưu hóa mới

Gần đây chúng tôi đã phát triển một phương pháp mới và tôi nghĩ mọi người đều rất hào hứng với nó. Tôi nghĩ các công cụ tối ưu hóa DS5 trước đây tập trung nhiều hơn vào việc tối ưu hóa một chỉ số (metric). Như chúng ta đã thảo luận, chúng tôi thực sự muốn sử dụng phương thức tác vụ (task modality) mà các ứng dụng này đang hoạt động, vì đó là nơi chứa nhiều lý do và cách thức chúng ta cần cải thiện. Vì vậy, chúng tôi chắc chắn muốn thực hiện một số điểm chuẩn ở đây.

Tối ưu hóa tiến hóa và Chu trình đánh giá

Có bao nhiêu bạn quen thuộc hoặc đang cố gắng thực hiện AutoPrompt? Được rồi, tốt. Tôi sẽ chỉ nói ở mức độ tổng quan. Tôi chỉ biết rằng sự khác biệt chính giữa và liệu bạn có nên sử dụng các công cụ tối ưu hóa chuyên nghiệp (pro optimizers) hay không là chúng thực sự sử dụng phản hồi tích cực (positive reflection) trong quá trình đánh giá (evaluation) khi chúng thực hiện tối ưu hóa. Vì vậy, đây là một tối ưu hóa tiến hóa (evolutionary optimization), nơi có sự lựa chọn ứng viên (candidate selection) dựa trên "cha mẹ" và việc hợp nhất các lời nhắc (merging of prompts).

Điều này thực sự có nghĩa là chúng tôi lấy các lời nhắc ứng viên, đánh giá chúng. Sau đó, có một phản hồi về chúng để xem xét các đánh giá và sau đó thực hiện một số thay đổi mới và lặp lại cho đến khi cảm thấy có được bộ lời nhắc phù hợp. Tôi nghĩ một điều quan trọng cần lưu ý là nó không thực sự chỉ chọn. Nó cố gắng giữ các ứng viên hàng đầu và thực hiện việc hợp nhất từ đó. Nhưng chúng tôi đã đánh dấu nó và nó thực sự làm tốt hơn một chút, và tôi nghĩ một điều thực sự quan trọng là nó thực hiện điều đó với số lượng nhóm ít hơn.

Tầm quan trọng của lời nhắc đánh giá chất lượng cao

Và tôi nghĩ điều chúng ta sẽ nói đến trong giây lát ở đây là thực sự quan trọng việc đánh giá của bạn click như thế nào và độ tin cậy của chúng. Tôi nghĩ đó là điều chúng tôi thực sự cảm thấy mạnh mẽ tại công ty chúng tôi là bạn chắc chắn muốn tối ưu hóa các lời nhắc của tác nhân (agent prompts). Nhưng tôi nghĩ nhiều người quên rằng bạn cũng nên tối ưu hóa các lời nhắc đánh giá (e-bounce prompts) của mình, bởi vì nếu bạn đang sử dụng công cụ đánh giá (evaluator) làm tín hiệu (signal), bạn không thể thực sự tin tưởng vào chúng nếu bạn không cảm thấy tự tin.

Vì vậy, điều quan trọng là phải đầu tư vào đó, đảm bảo bạn dựa vào các nguyên tắc tương tự như lời nhắc tác nhân của mình. Giống như lời nhắc đánh giá của bạn, bạn có một tín hiệu thực sự đáng tin cậy mà bạn có thể tin tưởng và sau đó đưa vào quá trình tạo lời nhắc (promptization) của mình. Nhưng trong cả hai biểu đồ này, đường màu hồng là học lời nhắc. Chúng tôi cũng đã hợp tác với một kỹ thuật tối ưu hóa cũ hơn mà tôi đã đề cập, có chức năng như tối ưu hóa xung quanh điều này. Và công cụ đánh giá thực sự tạo ra sự khác biệt. Vì vậy, tôi đã nhấn mạnh trên slide này, với kỹ thuật đánh giá (e-bounce engineering), chúng tôi đã có thể làm được điều này. Vì vậy, chúng tôi phải đảm bảo rằng các công cụ đánh giá mà chúng tôi sử dụng như một phần của học lời nhắc có chất lượng thực sự cao, bởi vì một lần nữa, nó chỉ tệ hơn nếu chính công cụ đánh giá là hoàn hảo. Vì vậy, công cụ đánh giá tạo ra tất cả sự khác biệt. Đôi khi tối ưu hóa lời nhắc ở đây. Một lần nữa, tất cả là về việc đảm bảo bạn có hướng dẫn phù hợp (proper instructions), áp dụng các quy tắc tương tự.

Tổng kết và Q&A

Tôi muốn trình bày chi tiết với nhiều nội dung. Tôi nghĩ việc có ngữ cảnh (context) là thực sự quan trọng. Nhưng trước khi chúng ta đi sâu vào bất kỳ buổi workshop nào, có bất kỳ câu hỏi nào mà tôi có thể trả lời về những gì tôi đã thảo luận cho đến nay không?

Câu hỏi: Đánh giá cho các tác vụ phi định lượng

Tôi có một câu hỏi hoặc một nhận xét chung. Tôi nghĩ mã hóa là ví dụ tuyệt vời nhất về việc có một cấu trúc trong đánh giá (evaluations). Một điều tôi hơi tò mò là liệu bạn có các ví dụ khác, các lời nhắc chung cho các tương tác bổ sung với các hệ thống không dễ dàng định lượng (quantifiable) hay không, và chúng tôi tò mò về kinh nghiệm của các bạn ở đó. Vâng, đó là cho đánh giá hay chỉ là lời nhắc nói chung?

Thiết lập đánh giá cho các tác vụ phức tạp và chủ quan

Vâng, tôi nghĩ rõ ràng là bạn sẽ thiết lập đánh giá trông như thế nào. Tôi chỉ tự hỏi làm thế nào bạn sẽ làm điều đó cho các loại việc khác. Đó là câu hỏi, liệu có bất kỳ loại hướng dẫn nào mà việc đánh giá mã hóa của bạn có vẻ là một ví dụ rất đơn giản không? Bạn muốn đảm bảo mã là đúng, phải không? Nhưng với một số tác vụ tác nhân (agent tasks) khác thì khó hơn một chút, tôi nghĩ lời khuyên mà tôi thường đưa ra cho mọi người là chúng tôi có một bộ công cụ có sẵn (out of box). Bạn luôn có thể bắt đầu với những thứ như độ chính xác của QA (QA correctness) hoặc tập trung vào các tác vụ. Nhưng điều tôi luôn đề xuất là tập hợp tất cả các bên liên quan (stakeholders) vào phòng. Tức là mời các chuyên gia giỏi hơn, lãnh đạo bảo mật và thực sự định nghĩa thành công sẽ trông như thế nào, sau đó bắt đầu chuyển đổi điều đó thành các đánh giá khác nhau.

Vì vậy, tôi nghĩ một ví dụ, chắc chắn Alex, tôi có một số đánh giá cấp tác vụ (task level evaluations), ví dụ như tôi thực sự quan tâm, nó có tìm thấy dữ liệu đúng mà nó nên có không? Nó có tạo một bộ lọc (filter) bằng cách sử dụng tìm kiếm ngữ nghĩa (semantic search) hay có cấu trúc giống như thực hiện lời gọi công cụ (making the right tool call) không? Và sau đó tôi quan tâm liệu nó có thực hiện một vài điều theo đúng thứ tự không, ví dụ như kế hoạch là gì? Vì vậy, hãy nghĩ về từng bước là gì và sau đó ngay cả bảo mật cũng sẽ nói rằng, chúng tôi quan tâm đến việc mọi người cố gắng vượt rào bảo vệ Alex (jailbreak Alex) thường xuyên như thế nào. Vì vậy, đó chỉ là việc lấy từng tiêu chí thành công (success criteria) và chuyển đổi chúng thành các đánh giá, và chúng tôi có các công cụ khác nhau có thể giúp bạn. Nhưng đó thường là khuôn khổ tôi đưa ra cho mọi người là hãy bắt đầu với thành công và sau đó lo lắng về việc chuyển đổi thành đánh giá.

Vâng, và chỉ thêm vào đó, tôi sẽ nói rằng có lẽ giống như một chủ đề của các trường hợp sử dụng, ví dụ như Booking.com là một trong những khách hàng của chúng tôi. Và khi họ hỏi "thế nào là một nơi lưu trú tốt cho một bất động sản?" hoặc "thế nào là một bức ảnh đẹp?" Việc định nghĩa điều đó thực sự khó, phải không? Với bạn, bạn có thể nghĩ một thứ gì đó là một nơi lưu trú rất hấp dẫn cho một khách sạn hoặc đại loại thế, phải không? Nhưng với người khác, nó có thể trông rất khác. Và đôi khi, như thời gian đã chứng minh, tôi thấy đủ để chỉ đánh giá nó là "tốt" hoặc "xấu" và sau đó tiếp tục từ đó. Vậy thì, liệu đó là một bức ảnh tốt hay một bức ảnh xấu, hãy quyết định và sau đó phân loại từ đó thành các chi tiết cụ thể như "ồ, đây là nắp mới", "bố cục căn phòng khác biệt", vân vân và vân vân. Vâng. Vâng, cảm ơn. Thực ra cảm ơn bạn. Bill, tôi định hỏi đó là kết quả nhị phân (binary outcome) dạng "bơ đậu phộng" không nhất thiết mang lại cho bạn một sự tiến bộ lớn. Bạn có thực sự sử dụng những câu hỏi đó như được số hóa không, không phải để có được một không gian liên tục (continuous space) hơn? Đúng vậy, chính xác, phải không? Và từ đó, khi bạn nhận được thêm tín hiệu (signal), bạn có thể tinh chỉnh công cụ đánh giá của mình xa hơn nữa và sau đó sử dụng những dữ liệu đó. Và bạn thực sự có thể đưa rất nhiều điều đó vào chính lời nhắc của mình, phải không? Vâng. Vâng.

Tinh chỉnh Quy tắc và Đánh giá: Hai vòng lặp cùng tiến hóa

Được rồi. Tôi có hai câu hỏi. Tôi không chắc liệu tôi có nên hỏi cả hai hay có lẽ workshop của bạn sẽ trả lời. Một câu hỏi là về các quy tắc và phần quy tắc hoặc như quy trình vận hành (operating procedures). Tôi tò mò làm thế nào bạn liên tục tinh chỉnh điều đó thành ngôn ngữ tiếng Anh và có lẽ giảm bớt xung đột giữa bất kỳ quy tắc mâu thuẫn (contradictory rules) nào? Đó là câu hỏi đầu tiên. Và sau đó, câu hỏi thứ hai là tôi rất muốn xem slide này về đánh giá. Và nếu bạn có thể nói thêm một chút về cách bạn tiếp cận điều đó, bởi vì vấn đề của tôi khi thực hiện công việc này là liệu có nên có một trình giả lập sản phẩm (simulator of the product) và sau đó trình giả lập đó đánh giá hay làm những gì tôi muốn làm, đó là một đánh giá cuối cùng (end evaluation) mà tôi xây dựng. Nhưng tôi rất muốn bạn nói về điều đó nếu có thể.

Vâng, chắc chắn rồi. Vậy thì, về câu hỏi đầu tiên, về cách các hướng dẫn (instructions) là một điều mà tôi nghĩ bạn lặp đi lặp lại theo thời gian. Vì vậy, rất nhiều lần tôi nghĩ chúng ta cố gắng hết sức để viết chúng bằng tay, phải không? Và tôi nghĩ điều chúng ta đang cố gắng làm với tối ưu hóa lời nhắc là để dữ liệu thay đổi động (dynamically change) chúng. Và như tôi nghĩ, nó rất tốt trong việc loại bỏ các hướng dẫn dư thừa (redundant instructions) và những thứ tương tự. Nhưng mục tiêu là chúng ta muốn loại bỏ các hướng dẫn tĩnh (static instructions). Chúng tôi rất tự tin rằng điều đó sẽ không thực sự mở rộng. Nó sẽ không dẫn đến hiệu suất bền vững (sustainable performance). Ý tưởng chính xác với học lời nhắc là một điều bạn có thể chạy theo thời gian. Chúng tôi thấy điều này ngay cả trong một tác vụ chạy lâu dài cuối cùng, nơi bạn đang xây dựng các ví dụ về những thứ không chính xác, có thể yêu cầu con người chú thích chúng. Và sau đó tác vụ luôn chạy, tạo ra các lời nhắc đã tối ưu (optimized prompts) mà bạn có thể đưa vào môi trường sản phẩm (production). Và nó giống như một chu trình (cycle) lặp lại theo thời gian. Xin lỗi, chỉ để xen vào. Vậy ý bạn là khi bạn làm điều này trong một thời gian dài và sau đó bạn có các ví dụ, bạn chỉ chạy lại các ví dụ đó vào phần quy tắc của mình. Đúng vậy. Và sau đó chúng ta đến vòng lặp tối ưu hóa (optimization loop) thực tế mà chúng ta sẽ xây dựng. Loại dữ liệu đó giống như bạn đang đưa dữ liệu vào. Điều đó sẽ xây dựng một bộ hướng dẫn mới mà bạn sau đó sẽ đưa vào môi trường sản phẩm. Tốt. Và tôi nghĩ câu hỏi của bạn là về đánh giá và cách bắt đầu, cách viết chúng và cách tối ưu hóa chúng, phải không? Vâng. Vâng, đó là một cách tiếp cận rất giống nhau. Tôi nghĩ nó giống như dữ liệu bạn đang xem xét hơi khác một chút. Vì vậy, tôi lẽ ra nên kéo các vòng lặp lên. Tôi không biết bạn có thể tìm thấy nó không. Tôi chỉ thử nhanh một cái gì đó để hiển thị điều này. Đây rồi. Vì vậy, đây là cách chúng tôi thấy nó là bạn có hai vòng lặp cùng tiến hóa (co-evolving loops). Tôi đã nói nhiều về cái bên trái, cái màu xanh, về việc cải thiện tác nhân, chúng tôi đang thu thập các lỗi (collecting failures). Giống như một cái gì đó để thực hiện tinh chỉnh (fine-tuning) hoặc học lời nhắc.

Tối Ưu Hóa eVal và Vòng Lặp Phản Hồi

Bạn về cơ bản muốn làm điều tương tự với các eVals của mình, nơi chúng ta thu thập các ý tưởng và thất bại. Nhưng thay vì nghĩ rằng thất bại là kết quả đầu ra của tác nhân của bạn, chúng ta thực sự đang nói về eVal. Vì vậy, việc có ai đó đánh giá các công cụ đánh giá, hoặc sử dụng những thứ như log probabilities làm điểm tin cậy, hoặc một bồi thẩm đoàn làm trọng tài để xác định những điểm không tự tin – chúng ta sẽ làm điều tương tự. Tức là, xác định nơi eVal có độ tin cậy thấp, sau đó bạn thu thập và chú thích điều đó (có thể nhờ ai đó xem xét và nói, "OK, đây là chỗ eVal sai").

Và như vậy, đó gần như là cùng một quy trình để tối ưu hóa prompt của eVal. Tôi nghĩ mọi người thường nghĩ rằng họ có thể mô tả mọi thứ sẵn có hoặc viết một cái gì đó một lần rồi quên nó đi. Nhưng vòng lặp này – tôi đã nói vài lần rồi – vòng lặp này chỉ hoạt động hiệu quả như eVal của bạn đã làm cho đến nay.

Vậy câu hỏi của tôi thực ra mang tính tĩnh và cơ bản hơn: Bạn đang nói về vòng tròn màu cam này như thể bạn đang xây dựng một hệ thống hoặc simulator cho eVal, hay bạn chỉ đang nói về một system prompt, user prompt, eVal?

Tôi nghĩ rằng hiện tại, những gì chúng ta đang nói đến chỉ là các prompt khác nhau. Bạn chắc chắn có thể thực hiện simulations; tôi nghĩ đó là một buổi workshop hoàn toàn khác. Cảm ơn bạn. Có thêm câu hỏi nào không? Có thể tiếp tục với buổi workshop. Có ai không? Tốt, một sự thật thú vị nhỏ.

Thiết Lập Prompt Learning với OpenAI

Được rồi. Đây sẽ là một đoạn mã ngắn cho prompt learning repo của chúng ta. Vậy, tất cả các đơn vị của bạn (để bắt đầu), chúng ta làm điều đó bằng cách nào? Lấy chúng trong kho lưu trữ GitHub của bạn. Tôi biết nó hơi clunky. Cái tĩnh mà bạn đang làm như Air Java. Tôi không chắc có cách nào tốt hơn. Tôi cũng có thể chỉ cho bạn ở đây. Bạn muốn tìm nó, nó sẽ là một AI repo được tổ chức ở đây. Và prompt learning của bạn. Bạn chỉ cần pull cái đó. Chúng ta sẽ chạy nó locally ở đây. Bạn quay lại trang của riêng bạn. Vâng, xin lỗi về điều đó. Tôi biết trang với URL. Ồ, tôi muốn cho mọi người vài phút để thiết lập.

Quy Trình Xây Dựng Agent Mới

Quy trình của bạn là gì? Khi chúng ta xây dựng một tác nhân mới hoặc một biểu mẫu mới – bất cứ điều gì có thể được thực hiện bằng AI – bạn có bắt đầu bằng cách tạo ra một prototype rồi xem xét những điểm yếu của nó và sau đó thực hiện eVals không?

Vâng, tôi nghĩ có nhiều quan điểm khác nhau về điều này. Quan điểm của chúng tôi là eVals không bao giờ nên cản trở bạn. Bạn cần bắt đầu và bạn cần xây dựng một cái gì đó thật scrappy. Chúng tôi không nghĩ bạn nên lãng phí thời gian làm eVals. Tôi nghĩ đôi khi việc lấy một cái gì đó có sẵn trong những tình huống đó là hữu ích, chỉ vì việc xem xét dữ liệu của bạn rất khó khăn. Và đó là điều bạn đã trải nghiệm với Alex. Nếu bạn mới bắt đầu, việc chạy thử nghiệm thủ công hoặc xem xét nó sẽ khá khó khăn.

Vì vậy, tôi nghĩ rằng việc có eVals là hữu ích, nhưng không nên là một blocker. Hãy lấy một cái gì đó có sẵn. Có thể bắt đầu với điều đó. Sau đó, khi bạn viết những thứ khác, nơi có vấn đề của bạn, bạn sẽ cố gắng tinh chỉnh eVals khi bạn tinh chỉnh các tính năng của mình. Vì vậy, việc tối ưu hóa điều này đôi khi là hợp lý. Và chúng tôi sử dụng nó như một blocker cho các sub-agents sắp ra mắt.

Vậy bạn nghĩ sao? Từ tất cả những gì tôi phải làm.

Tối Ưu Hóa Prompt Độc Lập cho Agent Đơn và Đa Agent

Vâng, câu hỏi là: Bạn chỉ đang làm một prompt duy nhất hay bạn nghĩ về một hệ thống đa tác nhân lớn hơn?

Tôi nghĩ hiện tại chúng tôi đang coi đây là các nhiệm vụ độc lập có thể tối ưu hóa các prompt của bạn một cách độc lập, và các nhiệm vụ riêng của bạn để đi vào mô phỏng tác nhân, viết chúng cùng nhau. Nhưng hiện tại, cách tiếp cận của chúng tôi hơi cô lập. Nhưng tôi chắc chắn thấy một tương lai nơi chúng ta sẽ đáp ứng tiêu chuẩn của một số tác nhân và mọi thứ khác đang diễn ra hiện nay.

Không, tôi nghĩ điều đó khá chính xác. Và cũng như, ngay cả trong trường hợp sử dụng tác nhân đơn lẻ so với trường hợp sử dụng đa tác nhân, thì cuối cùng, mỗi tác nhân đó có thể được chuyên biệt hóa và họ có các prompt riêng để học hỏi. Vì vậy, tôi nghĩ rằng việc thực hiện điều này một cách cô lập vẫn có lợi ích cho toàn bộ hệ thống đa tác nhân theo thời gian, đặc biệt trong các kịch bản như AdAlver, v.v. Và tạo ra một cái gì đó thực sự, thực sự đơn giản. Vì vậy, tôi nghĩ rằng những gì chúng ta đang nói đến cũng là overfitting. Một lần nữa, giống như câu hỏi chúng ta nhận được mọi lúc, nhưng thực sự bạn muốn overfitting trên cơ sở mã của chính mình như một kỹ sư. Bạn không muốn quá tổng quát đến mức không còn hiệu quả nữa. Tôi nghĩ nó hoạt động cụ thể ở đây. Nhưng vâng. Mọi người có thể chuyển sang chế độ chỉ đọc, OK? Có ai cần giúp đỡ không?

Ví Dụ JSON Webpage Prompt và Cấu Hình Thử Nghiệm

Được rồi. Vậy chúng ta sẽ sử dụng OpenAI cho việc này. Tôi nghĩ điều tiếp theo tôi sẽ yêu cầu mọi người làm có lẽ là chỉ mô tả một hàng rào bảo vệ rất chính xác. Giữ mọi thứ đúng. Và sau đó tôi sẽ bắt đầu hướng dẫn qua notebook của chúng ta ở đây.

Vậy chúng ta sẽ làm các ví dụ JSON webpage prompt. Bạn sẽ tìm thấy nó trong thư mục notebooks ở đây. Chúng ta sẽ cho mọi người một chút thời gian ở đó. Vì vậy, bạn chỉ cần chuyển sang slide này. Và chỉ cần thêm vào ví dụ này để nó chạy nhanh hơn một chút và hoạt động tốt hơn một chút.

Điều đầu tiên là: Cái này thậm chí còn làm gì? Đây sẽ là một ví dụ rất đơn giản cho một JSON webpage prompt đơn giản. Nếu bất kỳ ai có prompt hoặc trường hợp sử dụng mà họ muốn code along (cứ thoải mái làm theo!), tôi chắc chắn sẽ rất vui khi giúp bạn đưa công việc của mình vào trường hợp sử dụng đó. Đây là một cái gì đó rất đơn giản, chỉ để minh họa các nguyên tắc. Và chúng ta sẽ sử dụng Forem. Chúng ta chắc chắn có thể thử nghiệm nếu bạn muốn thay đổi bất kỳ nhà cung cấp nào khác mà bạn muốn sử dụng. Chúng ta cũng có thể giúp bạn làm điều đó. Nhưng mục tiêu của việc này về cơ bản là lặp lại qua các phiên bản khác nhau của một prompt bằng cách sử dụng một tập dữ liệu. Và chúng ta sẽ tối ưu hóa.

Cài Đặt và Cấu Hình Thử Nghiệm

Điều đầu tiên là rõ ràng chúng ta cần thực hiện một số cài đặt. Tôi sẽ yêu cầu tất cả các bạn cập nhật nó. Nó ghi là lớn hơn 2.0.0, nhưng chúng ta thực sự sẽ chỉ sử dụng, tôi nghĩ là 2.2. Và sau đó điều tiếp theo là chỉ để làm cho cái này chạy nhanh hơn một chút: Chúng ta sẽ chạy mọi thứ async, cái này hiện đang thiếu. Vì vậy, bạn có thể thêm các dòng này vào ô (cell) đó.

Được rồi. Mọi thứ đã được thiết lập. Tôi không bao giờ biết. Sẽ không ai di chuyển đến đó. Dường như không. Tuyệt vời. Hãy nói về biến thể.

Tôi đã nói về nó một chút khi tôi lướt qua các slide. Chúng ta sẽ thực hiện một số vòng lặp. Vì vậy, ý tưởng chung là chúng ta bắt đầu với một tập dữ liệu với một số phản hồi. Và chúng ta sẽ xem xét tập dữ liệu đó một khi chúng ta có nó. Nhưng bạn sẽ muốn có đánh giá của con người hoặc chú thích (các nhãn văn bản tự do). Hoặc bạn sẽ muốn có một số dữ liệu đánh giá. Nhưng phản hồi rất quan trọng; đó là điều làm cho việc này có tác dụng. Sau đó, chúng ta sẽ chuyển nó cho Alán để thực hiện tối ưu hóa. Và nó về cơ bản sẽ có eVals trong vòng lặp. Vì vậy, khi nó đang tối ưu hóa, nó đang sử dụng loại tập dữ liệu đó để chạy và đánh giá xem liệu nó có nên tiếp tục tối ưu hóa hay không. Và sau đó nó cũng cung cấp cho bạn dữ liệu mà bạn có thể sử dụng để đánh giá prompt nào nó xuất ra trong môi trường sản xuất.

Vì vậy, chúng ta sẽ thực hiện một số cấu hình. Tôi đã viết ra ở đây ý nghĩa của từng cái.

Chúng ta có số lượng mẫu (number of samples). Vì vậy, điều này sẽ cho chúng ta biết số hàng của tập dữ liệu mẫu. Bạn có thể đặt nó thành 0 để sử dụng tất cả dữ liệu. Bạn có thể sử dụng một số dương để thử nghiệm nhanh hơn. Vì vậy, tôi nghĩ rằng đôi khi mọi người sử dụng các cách tiếp cận khác nhau ở đây. Đôi khi bạn muốn di chuyển rất nhanh, vì vậy một mẫu nhỏ. Đôi khi bạn muốn đại diện hơn một chút, vì vậy bạn có nó. Tôi có nó ở đây được đặt là 100. Bạn cứ thoải mái điều chỉnh.

Và điều tiếp theo là phân tách huấn luyện (train split). Vì vậy, tôi nghĩ mọi người khá quen thuộc với khái niệm phân tách huấn luyện-kiểm thử (train-test split) ở đây. Nhưng nó chỉ là bao nhiêu dữ liệu chúng ta muốn sử dụng cho huấn luyện của mình? Một lần nữa, đó là những gì chúng ta đang sử dụng để thực sự tối ưu hóa. Sau đó, bao nhiêu dữ liệu chúng ta muốn sử dụng khi kiểm thử? Và chúng ta đang chạy eVal trên prompt mới.

Và có số lần chạy thử (number of rollouts). Về cơ bản, số lượng lần chạy thử cụ thể sẽ được sử dụng cho đánh giá. Điều này chỉ để chỉ ra prompt nào sẽ sử dụng. Và vì vậy, điều này giống như khi chúng ta chạy các vòng lặp này để xuất ra một loạt các prompt khác nhau. Và điều này chỉ nói rằng chúng ta nên sử dụng bao nhiêu cho đánh giá.

Và sau đó, k là số vòng lặp tối ưu hóa (number of optimization loops) của bạn. Vì vậy, điều này đặt ra số lần lặp tối ưu hóa (optimization iterations) cho thử nghiệm của chúng ta. Và mỗi vòng lặp về cơ bản chỉ tạo ra các đầu ra đó, đánh giá chúng và tinh chỉnh prompt.

Và vì vậy, đây chỉ là các tham số trung tâm cho thử nghiệm của chúng ta, nơi chúng ta chạy thử nghiệm này một cách flooding, chỉ không khớp nhiều với toàn bộ vòng lặp học prompt và lượng dữ liệu chúng ta muốn sử dụng.

Vì vậy, bạn có thể chạy chúng như hiện tại nếu bạn muốn tiến hành tự do. Và sau đó bộ tiếp theo đã được thiết lập. Chúng ta chỉ cần lấy Khóa API (API Key) đó. Nếu bạn chưa thiết lập nó. Vì vậy, một lần nữa, chỉ cần chuyển nó cho một số cửa sổ bật lên. Tôi sẽ cho bạn xem nhanh ở đây. Nó sẽ bật lên ở đó. Bạn chỉ cần dán Khóa API của mình vào.

Sau một số nghiên cứu sơ bộ, hãy xem xét dữ liệu một chút. Và chỉ là một thư viện, thay vì nói cho bạn biết vấn đề, bạn chỉ cần làm điều này một chút. Nhưng tôi nghĩ phần quan trọng là phải xem. Hy vọng chúng ta sẽ vượt qua điều này. Tôi sẽ chạy các Khóa API của mình. Nó rất hay. Tôi đang làm tốt. Nhưng nếu bạn có một cái miễn phí, bạn muốn giúp tôi một việc. Đó có phải là điều đầu tiên không?

Làm Việc với Dữ Liệu và Phản Hồi

Được rồi. Tôi sẽ bắt đầu với dữ liệu. Vì vậy, chúng tôi đã cung cấp dữ liệu cho bạn với các truy vấn. Bạn có thể thấy ở đây rằng chúng ta đang thực hiện phân tách 80/20 dựa trên cấu hình chúng ta đã thiết lập ở trên. Chúng ta sẽ chỉ lấy tập huấn luyện này ở đây. Và hãy... Vâng. Tôi chạy huấn luyện vì tôi cần sử dụng công cụ của mình. Vâng. Vâng, bạn đúng. Đó là một sai lầm của tôi. Vâng. Đó là 50. Hãy xem xét điều này. Nó trông giống như... Không. Chỉ để mọi người có thể hiểu.

Vì vậy, bắt đầu ở đây với một số đầu vào cơ bản. Nhưng... in ra... Chúng ta sẽ có bất kỳ phản hồi nào trong các hàng được in ra ở đây. Nhưng bạn có thể tưởng tượng bạn có thể có các mức độ chính xác khác nhau ở đây. Giải thích và kiến thức thực tế. Bạn có thể sử dụng bất cứ điều gì bạn đã thu thập. Một số người sử dụng nhiều eVals và một số chỉ một. Đôi khi đó là phản hồi của con người. Đôi khi đó là sự kết hợp. Bạn thực sự muốn có dữ liệu đầu vào và đầu ra của mình.

Đầu ra của tôi có giống với của bạn không? Không nhất thiết. Vâng. Tôi không biết liệu nó có giống hay không. Vâng. Vâng. Và tất cả mọi thứ đều giống với... Nhưng chúng ta có thể nhìn vào nó như thế này: bạn biết đấy, nếu tôi làm điều này, điều này sẽ giống với bạn. Có thể. Chỉ một chút. Vâng, đó là điều bạn đang nói. OK. Vâng. Câu hỏi: Đầu vào có thể là một lịch sử trò chuyện chứ không chỉ là một lời nhắc duy nhất.

Câu hỏi tuyệt vời. Vì vậy, tôi nghĩ nó phụ thuộc vào những gì bạn đang cố gắng làm. Nếu bạn chỉ đang làm một loại hệ thống đơn giản, vâng, nếu bạn chỉ đưa cái gốc... cái... xác suất bạn gặp một lỗi ở giữa... Vâng, không dễ để nói điều đó trông như thế nào. Không phải là họ không cố gắng theo cách đó. Điều này khá giống với chúng ta. Không dễ để đánh giá chúng ta. Nó ổn và không dễ. OK. Vâng, tôi đồng ý với bạn. Và khi bạn nhìn vào đó, chúng ta đến ngay đây. Bạn có bất kỳ suy nghĩ nào về điều gì được gọi là và chúng ta sẽ thảo luận điều đó trong một bài giảng không? Và làm thế nào chúng ta có thể áp dụng cho chúng ta như Easter và mặt khác chúng ta cũng có một số ngữ cảnh (context).

Vâng, vì vậy không chỉ là ngữ cảnh; nó chỉ nên thao túng bất cứ số liệu nào và tất cả các lời nhắc. Ngữ cảnh sẽ là trạng thái mà nó sẽ giống như. Dựa trên câu trả lời, bạn đã thay đổi ngữ cảnh của tôi. Bạn đang nói, với đầu vào, và tôi sẵn sàng gọi đó là ngữ cảnh để truyền đi? Bạn hoàn toàn có thể đưa điều đó vào tập dữ liệu của mình. Để học prompt có thể hiểu tất cả dữ liệu, đó là toàn bộ ý tưởng.

Dữ liệu đầu vào và Xử lý ngữ cảnh

Bạn chỉ cần truyền dữ liệu đó vào một cột đặc biệt nếu muốn. Hầu hết mọi người bắt đầu chỉ với việc nhập dữ liệu và phản hồi. Nhưng bạn hoàn toàn có thể có dữ liệu khác mà bạn cho là sai. Và nó đang chờ chạy tự do khi chúng tôi thực hiện thử nghiệm. Bạn chắc chắn sẽ luôn muốn có dữ liệu cần thiết. Và điều đó rất thú vị. Tôi đã thực hiện một số dự án bằng cách đưa vào các lời gọi API. Bất kể dự án đang làm gì, nó phải dựa trên kết quả đầu ra. Và bất kể context là gì, vấn đề của tôi ít liên quan đến các tool là gì. Tôi có các lời gọi API cho tất cả các phần của kỹ thuật context, và cuối cùng. Vâng, một lần nữa, bằng cách này, chúng tôi chỉ có một lời nhắc và không phải là một quá trình end-to-end. Nhưng bạn chắc chắn muốn có mọi thứ chảy vào lời nhắc mà bạn đang tối ưu hóa. Vì vậy, lời nhắc hệ thống của bạn nhận đầu vào từ người dùng và, ví dụ, một số dữ liệu từ bên ngoài. Vâng, bạn chắc chắn muốn cung cấp tất cả dữ liệu đó. Điều đó có hợp lý không? Bởi vì bạn đang nói rằng, bạn thích quỹ đạo không? Có hai lời gọi và tác nhân sẽ làm gì. Và bạn biết tool đã gọi gì. Đó có phải là điều bạn đang cố gắng nhắc hay làm không? Vâng, bạn muốn giống như chúng ta sẽ cố gắng phát lại như một bước của nó. Chúng tôi không muốn làm điều đó hoàn toàn trong môi trường cô lập. Vì vậy, nếu có dữ liệu chảy vào lời nhắc đó. Đó là cách nó nói rằng việc sử dụng chúng ta tạo ra đầu ra, phải không? Vì vậy, chúng tôi muốn đảm bảo rằng chúng tôi đang bao gồm điều đó. Chúng tôi không muốn loại trừ bất cứ điều gì. Nhưng nếu đó là dữ liệu đến từ một bộ khác, thì có lẽ không hẳn. Bạn không muốn làm điều đó theo cách đó. Chỉ cần nghĩ về những gì phù hợp cho bước chúng ta đang cố gắng tối ưu hóa.

Thiết lập Prompt hệ thống ban đầu

Và sau đó câu hỏi là. Với hệ thống ban đầu, tôi đang nói chuyện với bạn. Đây là một thứ rất, rất cơ bản. Chắc chắn, tôi nghĩ bạn sẽ làm tốt hơn nhiều, nhưng tôi chỉ muốn minh họa một điều gì đó mà chúng ta sẽ kiểm tra và tối ưu hóa. Vì vậy, chúng tôi chỉ nói rằng bạn là một chuyên gia trong việc tạo trang web JSON. Nhiệm vụ của bạn là nhập liệu. Và tất cả các đầu vào mà chúng ta đang thấy sẽ là những gì chúng ta thực sự đang tạo ra. Tôi sẽ đưa điều này cho bạn và cố gắng tối ưu hóa.

Tầm quan trọng của Bộ đánh giá (Evaluator)

Tôi đã đề cập đến điều này. Bộ đánh giá là cực kỳ quan trọng để làm cho tất cả những điều này hoạt động đúng. Vì vậy, chúng ta sẽ có. Và giống như hai bộ đánh giá gần như sử dụng một thẩm phán để đánh giá chất lượng của các phản hồi được tạo ra. Vì vậy, chúng ta sẽ đánh giá nếu bạn có bất kỳ đánh giá dựa trên mã nào khác, bất cứ điều gì bạn cần làm để đánh giá. Bạn có thể. Hoán đổi những thứ đó. Nhưng chúng ta sẽ đánh giá đầu ra. Đây sẽ là một bộ đánh giá toàn diện đánh giá tính đúng đắn của trang web JSON. Một lần nữa, đó là truy vấn đầu vào và các quy tắc đánh giá. Nó sẽ cung cấp một nhãn đầu ra là đúng hoặc sai. Khá đơn giản, nhị phân. Một lần nữa, bạn có thể sử dụng đa nhãn. Và sau đó nó cũng sẽ có các ước tính chi tiết.

Bộ kiểm tra quy tắc và Vòng lặp tối ưu hóa

Và sau đó chúng tôi có một bộ kiểm tra quy tắc. Đây là một bộ đánh giá chuyên biệt hơn. Nó thực hiện phân tích chi tiết từng quy tắc. Và một người kiểm tra xem liệu mỗi quy tắc có tuân thủ hay không. Và sau đó cả hai điều này sẽ cung cấp phản hồi đúng đi vào vòng lặp tối ưu hóa của chúng tôi để cải thiện lời nhắc hệ thống một cách lặp đi lặp lại. Quy tắc xuất sắc theo hướng dẫn. Và chúng ta sẽ đến bộ tối ưu hóa học lời nhắc và tạo ra nhiều hơn.

Chi tiết Bộ đánh giá đầu ra

Vậy là nó hoạt động ở đây. Hãy xem đầu ra giá trị thực tế có gì. Chúng tôi có một số quy tắc có sẵn ở đây. Xin lỗi, chúng sẽ có trong kho lưu trữ GitHub. Vì vậy, chúng ta sẽ mở nó dưới dạng một tệp. Chúng tôi có trình cung cấp phần tử này và chúng tôi đang sử dụng OpenAI ở đây. Và sau đó chúng tôi sẽ thực hiện bộ đánh giá phân loại của mình. Vì vậy, chúng ta chỉ cần gọi nó. Chúng tôi có một mẫu đánh giá mà chúng tôi đang đọc tệp ở đây. Sau đó, chúng ta chỉ có các lựa chọn đúng và sai. Bây giờ chúng ta không thể nguồn. Và sau đó chúng ta sẽ có thể thêm hoặc sắp xếp một số con số dễ dàng hơn là chỉ nhìn vào một loạt các nhãn. Đó là tùy chọn. Bạn muốn ánh xạ những thứ này nếu bạn có trường hợp sử dụng đa lớp. Bạn có thể đặt điểm số. Nhưng đây sẽ chỉ là những lựa chọn của chúng ta như tập hợp thực sự mà chúng ta muốn là quá nhiều. Và sau đó tất cả những gì chúng ta đang làm ở đây là nhận được một kết quả. Xem nếu tôi có nó đang được in ra để bạn có thể xem. Vì vậy, đây sẽ là thứ bạn đang thấy ở giữa. Vì vậy, tôi sẽ tạm dừng ở đây. Và sau đó chúng ta sẽ thực hiện các thay đổi mã để những gì bạn đang thấy trong phiên bản của mình. Đây là thời điểm tốt cho việc đó. Chỉ cần thiết lập bộ đánh giá. Hợp lý. Và các điểm chính. Đó sẽ là các hàng rào bảo vệ. Đó sẽ là đầu ra. Và tất nhiên, mẫu của chúng ta. Vâng, bạn sẽ muốn lấy khóa API OpenAI của riêng mình ở đây. Thiết lập này. Và chúng tôi có thể giúp bạn nếu bạn muốn sử dụng một trình viết khác có thể giúp bạn hoán đổi điều này.

Logic tạo kết quả và Thử nghiệm

Vì vậy, tôi sẽ nói về bất cứ ai. Tôi sẽ bắt đầu đi sâu vào quá trình tạo mở. Vì vậy, đây là kiểu, bạn có thể tưởng tượng đây là logic tác nhân của riêng bạn hoặc phần mà bạn đang lưu trữ. Đây chỉ là về một loạt thực sự tạo ra JSON. Tôi sẽ chuyển. Chúng tôi đang sử dụng gpt-4-0125-preview ở đây với JSON. Đối với ai đó. Vì vậy, bạn đang đến đây để có đầu ra nhất quán. Nó đang lấy một tập dữ liệu, lời nhắc trợ lý tạo ra đầu ra cho tất cả các hàng để chuyển kết quả cho giá trị. Và nó được gọi mỗi lần lặp để tạo ra đầu ra. Vì vậy, đây là hàm thử nghiệm mà chúng tôi đang chạy. Vì vậy, khi chúng tôi đang truyền một dữ liệu tạo ra các lời nhắc mới, chúng tôi cần một cách để kiểm tra nó và tôi hiểu làm thế nào chúng ta đang tiến bộ ở đây. Vì vậy, đó là tất cả hệ thống. Hàm khá đơn giản. Chỉ cần gọi tạo đầu ra. Chúng tôi có mô hình đầu ra đó. Một lần nữa, chúng tôi đang sử dụng OpenAI nếu bất cứ ai muốn thay đổi bất cứ điều gì thì rất vui. Chúng tôi đang sử dụng định dạng phản hồi vì chúng tôi đang xử lý JSON ở đây. Vì vậy, chúng tôi biết rằng khi bạn vừa tìm thấy, ý tôi là một số mô hình mới hơn khá tốt ở đó. Nhưng việc sử dụng định dạng phản hồi thực sự hữu ích. Và sau đó chúng tôi cũng đang đặt nhiệt độ về 0. Và ở đây chỉ là nơi chúng ta đang truyền tất cả dữ liệu vào. Vì vậy, tập dữ liệu bởi vì một lần nữa, chúng tôi muốn chạy điều này trên tất cả dữ liệu thử nghiệm. Đây là một vấn đề sẽ là đầu vào. Vì vậy, khi chúng ta đến vòng lặp tối ưu hóa, chúng ta sẽ truyền một lời nhắc mới vào đây với tập dữ liệu. Và sau đó đánh giá. Chúng tôi có mô hình đầu ra của chúng tôi mà chúng tôi đã truyền và tiền tệ tất cả những thứ tốt đẹp đó. Và nó chỉ trả về tất cả các đầu ra ở đó. Bạn sẽ khuyến nghị nhiệt độ bằng 0 cho các mô hình thế hệ hiện tại trong điều kiện AI là H không? Bạn có thực sự muốn cố gắng khuyến khích sự sáng tạo không? Vì vậy, và bạn có thể sử dụng điều này. Đợi đã. Của bạn. Bạn chắc chắn có thể thử nghiệm điều đó và xem xét nó dưới góc độ làm thế nào để có được sự nhất quán cao nhất để sử dụng một thứ như trang web JSON. Tôi cảm thấy như điều này có lẽ nhiệt độ bằng 0 là hợp lý. Nhưng tôi chắc chắn nghĩ rằng không phải mọi tác nhân nào cũng nên sử dụng 0. Có bất kỳ lựa chọn nào để di chuyển không?

Các chỉ số (Metrics) để tối ưu hóa

Được rồi. Vì vậy, chúng ta sẽ nói về trước đó, chúng ta đang sử dụng một số tỷ lệ điểm số. Phần này là tùy chọn. Bạn muốn sử dụng các chỉ số phù hợp với bạn. Chúng tôi không trực tiếp sử dụng điều này như kiểu chúng tôi. Dễ dàng và để biết khi nào và làm thế nào chúng ta tối ưu hóa nhưng nó không giống như chúng ta, bạn biết đấy. Sử dụng điều này như là chỉ số thành công duy nhất của chúng tôi. Ở đây, chúng ta sẽ chỉ có các chỉ số rất cơ bản. Chỉ là, bạn biết đấy, chọn một cái gì đó như độ chính xác. Tôi có độ chính xác, độ thu hồi chỉ là một số chỉ số phân loại cơ bản để chúng ta hiểu một lần nữa vì chúng ta đang sử dụng điểm số ánh xạ nhị phân. Chúng ta có thể làm điều đó. Và đó là những gì bạn đang thấy xảy ra ở đây. Tôi đang chia thành nhị phân và sau đó chỉ dựa trên điểm số. Chúng tôi tính toán các chỉ số. Rất đơn giản. Hàm của chúng tôi ở đây.

Thuật toán tối ưu hóa cốt lõi

Được rồi. Những thứ tốt. Vị trí của ý kiến. Được rồi. Vì vậy, đây là thuật toán tối ưu hóa cốt lõi. Đó là một quá trình ba phần. Vì vậy, chúng ta muốn tạo và đánh giá. Vì vậy, tạo đầu ra bằng cách sử dụng palm hiện tại trên bộ kiểm tra. Xem bộ và đánh giá tính đúng đắn của chúng. Chúng ta muốn huấn luyện và tối ưu hóa nếu kết quả không đạt yêu cầu, tạo. Tôi đã ở trên tập huấn luyện đánh giá chúng sử dụng phản hồi để cải thiện lời nhắc. Và sau đó lặp lại. Vì vậy, chúng ta muốn lặp lại cho đến khi ngưỡng được đáp ứng hoặc tất cả các lần chạy đã được lặp lại. Kiểu như hoàn thành. Vì vậy, nếu bạn nhớ về. Và sau đó chúng ta có thể lặp lại. Dựa trên điều đó hoặc lần đầu tiên. Nó sẽ lấy các chỉ số của chúng ta để giải quyết lần lặp. Vì vậy, nó trả về các kết quả chi tiết, bao gồm điểm độ chính xác của kiểm tra huấn luyện, các lời nhắc đã tối ưu hóa. Và điều sai. Vì vậy, như tôi đã đề cập ở phần đầu, khi chúng ta chạy các vòng lặp khác nhau trên các thử nghiệm, chúng ta sẽ tạo ra rất nhiều vai trò khác nhau. Và vì vậy, chúng ta đang nhận lại thông tin mà bạn có thể sử dụng. Và sau đó đây là các kết quả. Và vì vậy, chúng ta đang nhận lại thông tin mà bạn có thể sử dụng. Và đây là các đối tác chính của chúng ta. Tôi sẽ đi qua chúng, bạn biết đấy, khi chúng ta đến với mã nguồn, nhưng chỉ để cho bạn biết trước. Đây là điểm độ chính xác mục tiêu để ngừng tối ưu hóa. Nó cũng có thể là bất kỳ chỉ số nào khác mà bạn sẽ thấy. Chúng tôi có một điểm số. Vì vậy, bạn có thể xác định số vòng lặp của các lần lặp tối ưu hóa. Chúng tôi đã đặt điểm số đó và số quy tắc. Một lần nữa, đây là một số cấu hình mà chúng tôi đã đặt.

Vòng lặp tối ưu hóa và Phản hồi

Vì vậy, vòng lặp tối ưu hóa, điều này sẽ lấy tất cả các tham số mà tôi đã đề cập, sau đó nó chỉ bắt đầu nói rằng, "Này, chúng ta đang bắt đầu." Nó sẽ thực hiện đánh giá ban đầu. Vì vậy, chúng ta hiểu mọi thứ đang bắt đầu như thế nào. Bạn có thể truyền dữ liệu để bỏ qua đánh giá ban đầu này. Chúng ta đang chạy nó vào đầu năm ở đây. Nhưng nếu bạn đang viết trong một môi trường sản xuất, bạn có thể có một giá trị. Bạn có thể đã có phản hồi. Bạn có thể điều chỉnh điều này cho phù hợp. Và sau đó nó sẽ đánh giá ngưỡng so với đánh giá ban đầu của chúng ta. Một lần nữa, điều này có thể bị bỏ qua khi đến từ môi trường sản xuất. Nhưng một trong những lệnh đầu tiên từ đầu, để chúng ta có thể có cảm giác thực sự về điều này. Và sau đó nó bắt đầu vòng lặp. Vì vậy, chúng ta đang tạo ra đầu ra. Nó đang gửi điều đó làm đầu ra huấn luyện. Vì vậy, khi tôi in huấn luyện, bạn đã thấy các đầu ra đó đã gắn bó ở đó. Và chúng tôi cũng sẽ đặt, bạn biết đấy, một giải thích đồ họa, bất kỳ vi phạm quy tắc nào. Và sau đó chúng tôi sẽ thực sự sử dụng bộ điều khiển học lời nhắc của chúng tôi. Vì vậy, điều này đi kèm với SDK, vấn đề trong SDK mà bạn có thể sử dụng với rise. Vì vậy, chúng tôi đang gửi triển khai lời nhắc đó của tất cả các công cụ. Và sau đó API. Vì vậy, ngầm định như chúng ta đã nói về kích thước, lấy phản hồi đó, lấy lời nhắc gốc của bạn và cố gắng tối ưu hóa để có được kết quả tốt hơn. Và sau đó đặt lời nhắc. Và sau đó cũng có thể thêm một giá trị, vì vậy một lần nữa, ba cột phản hồi đó. Chúng ta đang tìm cách nhận lại giải thích tính đúng đắn cho điều đó. Nếu có bất kỳ vi phạm quy tắc nào. Và sau đó từ đó, chúng ta chỉ cần giữ bộ ủy quyền và không nhiều tập huấn luyện của chúng ta. Các cột phản hồi đó một lần nữa. Và sau đó bạn biết đấy, bất kỳ kích thước ngữ cảnh, các giới hạn bạn muốn thêm. Bước tiếp theo. Vì vậy, bộ ủy quyền sẽ lấy lời nhắc sản xuất. Và sau đó chúng ta muốn đánh giá. Vì vậy, chúng ta hiểu chúng ta đang làm như thế nào với khối mã này. Điều đang làm ở đây. Vì vậy, cố gắng đưa công ty mới đó vào một lần nữa với tất cả dữ liệu, hiểu kết quả của chúng ta. Và sau đó chúng ta làm điều đó với tập kiểm tra của chúng ta. Hiệu quả. Và sau đó chúng ta nhận lại điểm số của chúng ta. Và sau đó thực hiện các kiểm tra. Và sau đó chúng ta lặp lại tất cả một lần nữa. Chúng ta đến đó để nhận lại kết quả của chúng ta. Hoặc chúng ta đạt số lần di chuyển tối đa. Và sau đó trả về kết quả của chúng ta. Vì vậy, nó sẽ có một lần nữa ở đây. Có bất kỳ câu hỏi nào về điều đó không? Chỉ một số kết quả. Và nhiều câu hỏi trợ giúp ở đây.

Xem xét và Lưu trữ kết quả

Vì vậy, chúng ta muốn hiển nhiên thấy tất cả các kết quả này. Chúng ta không cần phải tăng tốc. Emory. Chúng ta không bao giờ có thể truy cập lại. Vì vậy, chỉ cần lưu chúng lại. Bạn cũng có thể xem tất cả các thử nghiệm đơn lẻ. Vì vậy, bạn có tất cả dữ liệu đó. Berksian sẽ kéo điều này.

Đánh giá Kết quả và Quy trình Chạy

Và bạn có thể làm việc với những gì tốt nhất. Nhưng những thứ này chỉ rất cơ bản. Tôi sẽ dành quá nhiều thời gian chỉ để lưu chúng cho đến cuối ngày. Sau đó, chúng ta sẽ bắt đầu nhận được kết quả. Vì vậy, đây là vấn đề: định dạng CSC. Nó bao gồm số lượng đóng góp, số lượng quy tắc, nguồn độ chính xác của quá trình huấn luyện kiểm thử – tất cả dữ liệu mà chúng ta thực sự sẽ đánh giá xem [giải pháp] có thành công hay không. Và sau đó, chúng ta sẽ bắt đầu nhận được kết quả ở đây.

Vì vậy, đây là điểm của tất cả các lần chạy. Khi bạn chạy nó, bạn sẽ bắt đầu thấy các loop khác nhau, cũng như những gì đang xuất hiện. Và vâng, chúng ta sẽ làm việc với nó khi nó chạy. Có lẽ sẽ mất khoảng 20 hoặc 30 phút để mọi thứ chạy xong. Nhưng tôi rất vui được giải đáp mọi thắc mắc và giúp đỡ mọi người khi họ gặp sự cố.

Khắc phục Sự cố và Cấu hình

Một điều này, bạn có thể cuộn xuống phần mà chúng ta cần thay đổi dữ liệu không? Ồ vâng. Vâng, bạn có thể. Nó sẽ là... Vì vậy, khi bạn chạy cái này, và chúng ta làm... Vậy thì dòng này, khi bạn làm mọi thứ, bạn muốn đặt nó bằng 2.2. Bởi vì tôi nghĩ có một chút vấn đề về package. Vì vậy, chỉ cần đảm bảo rằng [bạn xử lý] dữ liệu và các lỗi. Nhưng ebound có lẽ là lý do, nếu không, tại sao bạn không nhận được nhiều sự tín nhiệm hơn cho nó? Đây là lý do tại sao. Nó sử dụng một evaluation chung chung. Vâng.

Và bạn có thể thấy manager... nếu bạn đi đến... Chúng tôi đã loại bỏ phần đó ra khỏi đây. Chúng ta chắc chắn có thể xem xét điều đó. Vì vậy, nếu bạn đi đến đây, và dòng này, chúng ta đang đọc vào phần lời nhắc ở đây, bạn có thể tìm thấy một số [thông tin] về [chủ đề] bạn đang tò mò.

Tối ưu hóa Lời nhắc cho Hội thảo

Và đây là lý do tại sao mọi người ghét Docker. Đây là lý do tại sao chúng tôi sử dụng Docker. Vâng, hoàn toàn chính xác. Tôi không làm việc nhiều. Noble xảy ra với tất cả chúng ta. Vì vậy, tôi cũng khuyên bạn, nếu bạn chưa [làm điều đó], nó sẽ giúp chạy nhanh hơn rất nhiều. Ngoài ra, vì mục đích của hội thảo, chỉ cần đặt loop của chúng ta thành một. [Nếu không, nó sẽ mất] 36 phút để chạy. Vì vậy, chúng tôi khuyên bạn cũng nên làm điều đó. Thay vì tốn thời gian. Rõ ràng, chúng tôi sẽ khuyên bạn làm điều đó. Và các hành động của bạn: tối ưu hóa lời nhắc của bạn ngay bây giờ. Nó sẽ giúp bạn hoàn thành hội thảo.

Lưu trữ và Tối ưu hóa Kết quả

Được rồi, tôi chỉ muốn đề cập đến một điểm cuối cùng ở đây. Bước cuối cùng, trước khi [chúng ta hoàn thành], chỉ là đóng dự án. Để đạt được độ chính xác tốt nhất: Như tôi đã đề cập, cách chúng tôi lưu trữ tất cả các kết quả. Chúng tôi chỉ có một function về cơ bản lấy phiên bản cuối cùng, hoặc phiên bản tốt nhất của nó, cho bạn thấy phiên bản gốc và sau đó là phiên bản tối ưu hóa tốt nhất. Sau đó bạn có thể sử dụng, lấy và đưa vào cơ sở mã của mình.

Giải pháp Tối ưu hóa Lời nhắc Cấp Doanh nghiệp

Tôi muốn đưa ra một lưu ý. Vì nó có thể khó quản lý. Và vì vậy, tôi muốn lưu ý đến những bạn có thể đang tìm kiếm một giải pháp cấp doanh nghiệp cho vấn đề này. Bạn có một task tối ưu hóa lời nhắc. Bạn có thể lưu trữ các lời nhắc của mình trong trung tâm lời nhắc của chúng tôi, với các dataset kèm theo tất cả các chú thích của con người hoặc e-bals của bạn. Nó có thể tạo từ các trace hoặc quyết định và chỉ [tích hợp chúng] vào một [nền tảng như] Arise. Và sau đó, tất cả những gì bạn thực sự cần làm là đưa cho nó một task. Chọn training data set bạn muốn, nơi output được lưu trữ, nơi tất cả các feedback columns của bạn. Và sau đó bạn chỉ cần khởi chạy, và nó sẽ tạo ra một lời nhắc được tối ưu hóa trong trung tâm cho bạn. Vì vậy, nếu tôi ở đây, tôi nghĩ tôi có một số... Rõ ràng nó sẽ tạo ra một phiên bản mới ở đây nói rằng đó là một lời nhắc được tối ưu hóa với tất cả các kết quả. Và chúng tôi đang phát triển dựa trên điều này. Bạn có thể thêm tất cả các e-bals của mình vào đó. Hãy để tất cả chạy trong loop. Điều này để lưu ý rằng nếu bạn không quan tâm đến việc duy trì các code loops và phải tự xây dựng [mọi thứ], thì bạn có thể chỉ cần thêm một task và tự cấu trúc. Đó là điều chúng tôi cung cấp trong Arise. Hy vọng vậy, mọi người, mọi thứ. Chúng tôi sẽ ở đây một lúc để giúp bạn giải quyết các vấn đề, nhưng. Cảm ơn rất nhiều vì đã tham gia cùng chúng tôi. Hy vọng bạn đã học được điều gì đó hữu ích.