[ad_1]
Sự định nghĩa: eval (viết tắt của analysis). Một giai đoạn quan trọng trong vòng đời phát triển của mô hình. Quy trình giúp nhóm hiểu được liệu mô hình AI có thực sự làm những gì họ muốn hay không. Quy trình đánh giá áp dụng cho tất cả các loại mô hình từ bộ phân loại cơ bản đến LLM như ChatGPT. Thuật ngữ eval cũng được sử dụng để chỉ tập dữ liệu hoặc danh sách các trường hợp thử nghiệm được sử dụng trong quá trình đánh giá.
Tùy thuộc vào mô hình, một đánh giá có thể bao gồm các đánh giá định lượng, định tính, do con người thực hiện hoặc tất cả các đánh giá trên. Hầu hết các đánh giá mà tôi gặp trong sự nghiệp của mình đều liên quan đến việc chạy mô hình trên một tập dữ liệu được quản lý để tính toán các số liệu quan trọng cần quan tâm, như độ chính xác, độ chính xác và khả năng thu hồi.
Có lẽ vì trước đây việc đánh giá liên quan đến các bảng tính hoặc cơ sở dữ liệu số lớn nên hầu hết các nhóm hiện nay đều giao toàn bộ trách nhiệm thiết kế và chạy đánh giá cho các nhà phát triển mô hình.
Tuy nhiên, tôi tin rằng trong hầu hết các trường hợp, việc đánh giá phải được xác định rõ ràng bởi người quản lý sản phẩm.
Đánh giá nhằm mục đích trả lời những câu hỏi như:
- Liệu mô hình này có đạt được mục tiêu của nó không?
- Liệu mô hình này có tốt hơn các mô hình hiện có khác không?
- Mô hình này sẽ tác động thế nào đến trải nghiệm của người dùng?
- Mẫu này đã sẵn sàng để đưa vào sản xuất chưa? Nếu chưa, cần phải cải thiện những gì?
Đặc biệt đối với bất kỳ mô hình nào hướng đến người dùng, không ai có vị trí tốt hơn PM để xem xét tác động đến trải nghiệm của người dùng và đảm bảo hành trình chính của người dùng được phản ánh trong kế hoạch thử nghiệm. Không ai hiểu người dùng tốt hơn PMPhải?
Cũng là công việc của PM để thiết lập các mục tiêu cho sản phẩm. Theo đó, mục tiêu của một mô hình được triển khai TRONG sản phẩm phải phù hợp chặt chẽ với tầm nhìn của sản phẩm.
Nhưng bạn nên nghĩ thế nào về việc đặt ra “mục tiêu” cho một mô hình? Câu trả lời ngắn gọn là, nó phụ thuộc vào loại mô hình bạn đang xây dựng.
Đặt mục tiêu cho mô hình là bước đầu tiên quan trọng trước khi bạn có thể thiết kế một đánh giá hiệu quả. Khi đã có mục tiêu, chúng ta có thể đảm bảo rằng mình đang bao phủ toàn bộ phạm vi đầu vào với thành phần đánh giá của mình. Hãy xem xét các ví dụ sau.
Phân loại
- Ví dụ về mô hình: Phân loại e-mail là thư rác hay không phải thư rác.
- Mục tiêu sản phẩm: Bảo vệ người dùng khỏi nguy hiểm và đảm bảo họ luôn có thể tin tưởng rằng dịch vụ e-mail là giải pháp đáng tin cậy và hiệu quả để quản lý mọi giao tiếp qua e-mail khác.
- Mục tiêu của mô hình: Xác định càng nhiều e-mail rác càng tốt trong khi giảm thiểu số lượng e-mail không phải thư rác bị gắn nhãn nhầm là thư rác.
- Mục tiêu → đánh giá bản dịch: Chúng tôi muốn tạo lại tập hợp các e-mail mà trình phân loại sẽ gặp phải với người dùng của chúng tôi trong bài kiểm tra của chúng tôi. Chúng tôi cần đảm bảo bao gồm các e-mail do con người viết, e-mail spam và lừa đảo phổ biến, và các e-mail tiếp thị mờ ám mơ hồ hơn. Đừng chỉ dựa vào nhãn người dùng cho nhãn thư rác của bạn. Người dùng mắc lỗi (giống như nghĩ rằng lời mời thực sự tham gia vào video ca nhạc của Drake là thư rác), và việc đưa chúng vào sẽ huấn luyện mô hình mắc phải những lỗi này.
- Thành phần đánh giá: Danh sách các e-mail mẫu bao gồm các thông tin liên lạc hợp pháp, bản tin, chương trình khuyến mại và nhiều loại thư rác như lừa đảo, quảng cáo và nội dung độc hại. Mỗi ví dụ sẽ có nhãn “thực” (tức là “là thư rác”) và nhãn dự đoán được tạo trong quá trình đánh giá. Bạn cũng có thể có thêm ngữ cảnh từ mô hình như điểm số “xác suất thư rác”.
Tạo văn bản — Trợ giúp nhiệm vụ
- Mô hình ví dụ: Một chatbot dịch vụ khách hàng cho phần mềm chuẩn bị khai thuế.
- Mục tiêu sản phẩm: Giảm thời gian người dùng điền và nộp tờ khai thuế bằng cách cung cấp câu trả lời nhanh cho những câu hỏi hỗ trợ thường gặp nhất.
- Mục tiêu mô hình: Tạo câu trả lời chính xác cho các câu hỏi về các tình huống phổ biến nhất mà người dùng gặp phải. Không bao giờ đưa ra lời khuyên không chính xác. Nếu có bất kỳ nghi ngờ nào về câu trả lời đúng, hãy chuyển hướng truy vấn đến một tác nhân con người hoặc trang trợ giúp.
- Mục tiêu → đánh giá bản dịch: Mô phỏng phạm vi các câu hỏi mà chatbot có thể nhận được, đặc biệt là các câu hỏi phổ biến nhất, khó nhất và có nhiều vấn đề nhất mà câu trả lời sai sẽ gây hậu quả tai hại cho người dùng hoặc công ty.
- Thành phần đánh giá: danh sách các truy vấn (ví dụ: “Tôi có thể khấu trừ chi phí văn phòng tại nhà không?”) và các phản hồi lý tưởng (ví dụ: từ các Câu hỏi thường gặp và các nhân viên hỗ trợ khách hàng giàu kinh nghiệm). Khi chatbot không nên đưa ra câu trả lời và/hoặc nên chuyển đến một nhân viên, hãy chỉ định kết quả này. Các truy vấn nên bao gồm nhiều chủ đề với các mức độ phức tạp khác nhau, cảm xúc của người dùng và các trường hợp ngoại lệ. Các ví dụ có vấn đề có thể bao gồm “chính phủ có để ý nếu tôi không đề cập đến khoản thu nhập này không?” và “bạn nghĩ tôi sẽ phải tiếp tục trả tiền chăm sóc tại nhà cho cha tôi trong bao lâu nữa?”
Sự giới thiệu
- Mẫu ví dụ: Đề xuất các sản phẩm dành cho trẻ sơ sinh và trẻ mới biết đi dành cho cha mẹ.
- Mục tiêu sản phẩm: Đơn giản hóa việc mua sắm thiết yếu cho các gia đình có trẻ nhỏ bằng cách gợi ý các sản phẩm phù hợp với từng giai đoạn, phản ánh nhu cầu thay đổi khi trẻ lớn lên.
- Mục tiêu của mô hình: Xác định những sản phẩm có mức độ liên quan cao nhất mà khách hàng có khả năng mua nhiều nhất dựa trên những gì chúng ta biết về chúng.
- Mục tiêu → đánh giá bản dịch: Cố gắng xem trước những gì người dùng sẽ thấy vào ngày đầu tiên khi mô hình ra mắt, xem xét cả những trải nghiệm phổ biến nhất của người dùng, các trường hợp ngoại lệ và cố gắng dự đoán mọi ví dụ mà trong đó mọi thứ có thể trở nên tồi tệ (như đề xuất các sản phẩm nguy hiểm hoặc bất hợp pháp dưới biểu ngữ “dành cho con bạn”).
- Thành phần đánh giá: Đối với kiểm tra cảm quan ngoại tuyến, bạn muốn có một người đánh giá kết quả để xem chúng có hợp lý không. Các ví dụ có thể là danh sách 100 hồ sơ khách hàng và lịch sử mua hàng đa dạng, kết hợp với 10 sản phẩm được đề xuất hàng đầu cho từng hồ sơ. Đối với đánh giá trực tuyến của bạn, thử nghiệm A/B sẽ cho phép bạn so sánh hiệu suất của mô hình với một phương pháp tìm kiếm đơn giản (như đề xuất các sản phẩm bán chạy nhất) hoặc với mô hình hiện tại. Chạy đánh giá ngoại tuyến để dự đoán những gì mọi người sẽ nhấp bằng cách sử dụng hành vi nhấp chuột trong lịch sử cũng là một tùy chọn, nhưng việc có được dữ liệu đánh giá khách quan ở đây có thể khó khăn nếu bạn có một danh mục lớn. Để tìm hiểu thêm về đánh giá trực tuyến và ngoại tuyến, hãy xem bài viết này hoặc hỏi LLM yêu thích của bạn.
Tất nhiên đây là những ví dụ đơn giản hóa và mỗi mô hình đều có các sắc thái sản phẩm và dữ liệu cần được tính đến khi thiết kế một eval. Nếu bạn không chắc chắn nên bắt đầu thiết kế eval của riêng mình từ đâu, tôi khuyên bạn nên mô tả mô hình và mục tiêu cho LLM yêu thích của bạn và xin lời khuyên của họ.
Sau đây là một ví dụ (đơn giản) về cách một tập dữ liệu đánh giá có thể trông như thế nào đối với một mô hình phát hiện thư rác qua e-mail.
Vậy thì… Thủ tướng có vai trò gì? Và tại sao họ nên xem xét dữ liệu?
Hãy tưởng tượng tình huống sau:
Nhà phát triển mô hình: “Chào PM. Mô hình mới của chúng tôi có độ chính xác 96% trong đánh giá, chúng tôi có thể giao hàng không? Mô hình hiện tại chỉ đạt 93%.”
PM AI tệ: “96% tốt hơn 93%. Vậy nên, chúng ta hãy triển khai thôi.”
AI tốt hơn: “Đó là một cải tiến tuyệt vời! Tôi có thể xem dữ liệu đánh giá không? Tôi muốn biết tần suất các e-mail quan trọng được gắn cờ là thư rác và loại thư rác nào được phép đi qua.”
Sau khi dành thời gian với dữ liệu, PM AI giỏi hơn thấy rằng mặc dù nhiều e-mail spam hơn hiện đã được xác định chính xác, nhưng đủ e-mail quan trọng như ví dụ về lời mời làm việc ở trên cũng bị gắn nhãn sai là spam. Họ đánh giá tần suất xảy ra tình trạng này và có bao nhiêu người dùng có thể bị ảnh hưởng. Họ kết luận rằng ngay cả khi điều này chỉ ảnh hưởng đến 1% người dùng, tác động có thể là thảm khốc và sự đánh đổi này không đáng để có ít e-mail spam hơn vượt qua.
PM AI giỏi nhất sẽ tiến thêm một bước nữa để xác định các khoảng trống trong dữ liệu đào tạo, chẳng hạn như thiếu các ví dụ giao tiếp kinh doanh quan trọng. Họ giúp tìm nguồn dữ liệu bổ sung để giảm tỷ lệ dương tính giả. Khi cải tiến mô hình không khả thi, họ đề xuất thay đổi giao diện người dùng của sản phẩm như cảnh báo người dùng khi e-mail “có thể” là thư rác khi mô hình không chắc chắn. Điều này chỉ khả thi vì họ biết dữ liệu Và những ví dụ thực tế nào có ý nghĩa với người dùng.
Hãy nhớ, quản lý sản phẩm AI không làm yêu cầu kiến thức chuyên sâu về kiến trúc mô hình. Tuy nhiên, việc thoải mái xem nhiều ví dụ dữ liệu để hiểu tác động của mô hình đối với người dùng là rất quan trọng. Việc hiểu các trường hợp ngoại lệ quan trọng có thể thoát khỏi các tập dữ liệu đánh giá là đặc biệt quan trọng.
Thuật ngữ “eval” thực sự là một thuật ngữ chung được mọi người sử dụng khác nhau. Không phải tất cả các eval đều tập trung vào các chi tiết liên quan đến trải nghiệm của người dùng. Một số eval giúp nhóm phát triển dự đoán hành vi trong quá trình sản xuất như độ trễ và chi phí. Mặc dù PM có thể là bên liên quan đối với các eval này, nhưng việc đồng thiết kế PM không phải là yếu tố quan trọng và sự tham gia mạnh mẽ của PM thậm chí có thể gây mất tập trung cho mọi người.
Cuối cùng, PM phải chịu trách nhiệm đảm bảo TẤT CẢ các đánh giá đúng đắn đều được phát triển và thực hiện bởi đúng người. Sự đồng phát triển của PM là quan trọng nhất đối với bất kỳ điều gì liên quan đến trải nghiệm người dùng.
Trong kỹ thuật phần mềm truyền thống, người ta mong đợi 100% các bài kiểm tra đơn vị phải vượt qua trước khi bất kỳ mã nào được đưa vào sản xuất. Than ôi, đây không phải là cách mọi thứ hoạt động trong thế giới AI. Đánh giá hầu như luôn tiết lộ điều gì đó không lý tưởng. Vì vậy, nếu bạn không bao giờ có thể đạt được 100% những gì bạn muốn, làm thế nào để quyết định một mô hình đã sẵn sàng để xuất xưởng? Đặt ra tiêu chuẩn này với các nhà phát triển mô hình cũng nên là một phần công việc của một PM AI.
PM nên xác định số liệu đánh giá nào cho thấy mô hình “đủ tốt” để mang lại giá trị cho người dùng với những đánh đổi có thể chấp nhận được.
Tiêu chuẩn “giá trị” của bạn có thể thay đổi. Có nhiều trường hợp mà việc tung ra một thứ gì đó thô sơ ngay từ đầu để xem người dùng tương tác với nó như thế nào (và bắt đầu vòng quay dữ liệu của bạn) có thể là một chiến lược tuyệt vời miễn là bạn không gây hại cho người dùng hoặc thương hiệu của mình.
Hãy xem xét chatbot dịch vụ khách hàng.
Bot sẽ không bao giờ tạo ra câu trả lời phản ánh hoàn hảo phản hồi lý tưởng của bạn. Thay vào đó, PM có thể làm việc với các nhà phát triển mô hình để phát triển một bộ phương pháp đánh giá mức độ gần với câu trả lời lý tưởng. Bài đăng trên blog này bao gồm một số phương pháp tìm kiếm phổ biến. Ngoài ra còn có nhiều mã nguồn mở Và trả các khuôn khổ hỗ trợ phần này của quá trình đánh giá, với nhiều khuôn khổ mới được ra mắt liên tục.
Điều quan trọng nữa là phải ước tính tần suất các phản hồi có khả năng gây hậu quả tai hại có thể gây hiểu lầm cho người dùng hoặc gây tổn hại cho công ty (ví dụ: cung cấp một chuyến bay miễn phí!) và làm việc với các nhà phát triển mô hình để cải thiện nhằm giảm thiểu tần suất này. Đây cũng có thể là cơ hội tốt để kết nối với các nhóm tiếp thị, quan hệ công chúng, pháp lý và an ninh nội bộ của bạn.
Sau khi ra mắt, PM phải đảm bảo việc giám sát được thực hiện để đảm bảo các trường hợp sử dụng quan trọng tiếp tục hoạt động như mong đợi VÀ các công việc trong tương lai sẽ hướng tới việc cải thiện mọi lĩnh vực hoạt động kém hiệu quả.
Tương tự như vậy, không có bộ lọc e-mail rác nào sẵn sàng đưa vào sản xuất đạt được độ chính xác 100% VÀ khả năng thu hồi 100% (và thậm chí nếu có thể, các kỹ thuật thư rác sẽ tiếp tục phát triển), nhưng việc hiểu được mô hình thất bại ở đâu có thể cung cấp thông tin cho việc điều chỉnh sản phẩm và đầu tư vào mô hình trong tương lai.
Các mô hình đề xuất thường yêu cầu nhiều đánh giá, bao gồm đánh giá trực tuyến và ngoại tuyếntrước khi triển khai cho 100% người dùng trong sản xuất. Nếu bạn đang làm việc trên một bề mặt có rủi ro cao, bạn cũng sẽ muốn có một đánh giá sau khi ra mắt để xem xét tác động đến hành vi của người dùng và xác định các ví dụ mới cho bộ đánh giá của bạn.
Quản lý sản phẩm AI tốt không phải là đạt được sự hoàn hảo. Mà là cung cấp sản phẩm tốt nhất cho người dùng của bạn, điều này đòi hỏi:
- Đặt ra các mục tiêu cụ thể về cách mô hình sẽ tác động đến trải nghiệm của người dùng -> đảm bảo các trường hợp sử dụng quan trọng được phản ánh trong quá trình đánh giá
- Hiểu các hạn chế của mô hình và cách chúng tác động đến người dùng -> chú ý đến các vấn đề mà đánh giá phát hiện ra và những vấn đề này có ý nghĩa gì đối với người dùng
- Đưa ra quyết định sáng suốt về các sự đánh đổi có thể chấp nhận được và kế hoạch giảm thiểu rủi ro -> dựa trên các bài học kinh nghiệm từ hành vi mô phỏng của quá trình đánh giá
Việc áp dụng các đánh giá cho phép các nhà quản lý sản phẩm hiểu và sở hữu tác động của mô hình đến trải nghiệm của người dùng và dẫn dắt nhóm đạt được kết quả tốt hơn một cách hiệu quả.
[ad_2]
Source link