Hướng dẫn về an toàn

Một trong những điều khiến các mô hình ngôn ngữ lớn (LLM) trở nên hữu ích chính là chúng là các công cụ sáng tạo có thể giải quyết nhiều nhiệm vụ ngôn ngữ khác nhau. Thật không may, điều này cũng có nghĩa là các mô hình ngôn ngữ lớn có thể tạo ra kết quả mà bạn không mong đợi, bao gồm cả văn bản phản cảm, thiếu nhạy cảm hoặc không đúng thực tế. Hơn nữa, tính linh hoạt đáng kinh ngạc của các mô hình này cũng là điều gây khó khăn cho việc dự đoán chính xác loại đầu ra không mong muốn mà các mô hình đó có thể tạo ra. Mặc dù APIGemini được thiết kế theo các nguyên tắc về AI của Google, nhưng nhà phát triển có trách nhiệm áp dụng các mô hình này một cách có trách nhiệm. Để hỗ trợ nhà phát triển tạo ứng dụng an toàn và có trách nhiệm, API Gemini có một số tính năng lọc nội dung tích hợp cũng như các chế độ cài đặt an toàn có thể điều chỉnh theo 4 phương diện gây hại. Vui lòng tham khảo hướng dẫn về chế độ cài đặt an toàn để tìm hiểu thêm.

Tài liệu này nhằm giới thiệu cho bạn một số rủi ro về an toàn có thể phát sinh khi sử dụng các LLM, đồng thời đề xuất các đề xuất về việc phát triển và thiết kế an toàn mới. (Xin lưu ý rằng luật và quy định cũng có thể đặt ra các hạn chế, nhưng những điểm cần cân nhắc đó nằm ngoài phạm vi của hướng dẫn này.)

Sau đây là các bước nên thực hiện khi xây dựng ứng dụng có mô hình ngôn ngữ lớn (LLM):

• Hiểu rõ các rủi ro về an toàn trong ứng dụng
• Cân nhắc việc điều chỉnh để giảm thiểu rủi ro an toàn
• Thực hiện kiểm thử an toàn phù hợp với trường hợp sử dụng của bạn
• Thu thập ý kiến phản hồi của người dùng và theo dõi việc sử dụng

Các giai đoạn điều chỉnh và kiểm thử nên lặp lại cho đến khi bạn đạt được hiệu suất phù hợp với ứng dụng của mình.

Hiểu rõ các rủi ro về an toàn của ứng dụng

Trong bối cảnh này, tính an toàn được định nghĩa là khả năng một LLM có thể tránh gây hại cho người dùng, chẳng hạn như bằng cách tạo ra ngôn từ độc hại hoặc nội dung cổ xuý định kiến. Các mô hình có sẵn thông qua API Gemini đã được thiết kế theo các nguyên tắc về AI của Google và việc bạn sử dụng mô hình này sẽ tuân theo Chính sách về các hành vi bị cấm khi sử dụng AI tạo sinh. API này cung cấp các bộ lọc an toàn tích hợp sẵn để giúp giải quyết một số vấn đề phổ biến về mô hình ngôn ngữ (chẳng hạn như ngôn từ độc hại và lời nói hận thù), đồng thời cố gắng hướng đến sự hoà nhập và tránh định kiến. Tuy nhiên, mỗi ứng dụng có thể gây ra một số rủi ro khác nhau cho người dùng. Vì vậy, là chủ sở hữu ứng dụng, bạn có trách nhiệm hiểu rõ người dùng của mình và những mối nguy hại tiềm ẩn mà ứng dụng có thể gây ra, đồng thời đảm bảo rằng ứng dụng sử dụng các LLM một cách an toàn và có trách nhiệm.

Trong quá trình đánh giá này, bạn nên cân nhắc khả năng xảy ra thiệt hại, đồng thời xác định mức độ nghiêm trọng và các bước giảm nhẹ. Ví dụ: một ứng dụng tạo bài tiểu luận dựa trên các sự kiện thực tế sẽ cần phải cẩn thận hơn trong việc tránh thông tin sai lệch, so với một ứng dụng tạo câu chuyện hư cấu cho mục đích giải trí. Một cách hay để bắt đầu khám phá các rủi ro an toàn tiềm ẩn là nghiên cứu về người dùng cuối và những người khác có thể bị ảnh hưởng bởi kết quả của ứng dụng. Việc này có thể dưới nhiều hình thức, chẳng hạn như nghiên cứu trạng thái của các nghiên cứu về nghệ thuật trong miền ứng dụng, quan sát cách mọi người đang sử dụng các ứng dụng tương tự, hoặc tiến hành nghiên cứu người dùng, khảo sát hay tiến hành phỏng vấn không chính thức với người dùng tiềm năng.

Cân nhắc việc điều chỉnh để giảm thiểu rủi ro về an toàn

Giờ đây, khi đã hiểu rõ về các rủi ro, bạn có thể quyết định cách giảm thiểu rủi ro. Việc xác định những rủi ro cần ưu tiên và mức độ cần làm để ngăn chặn chúng là một quyết định vô cùng quan trọng, tương tự như việc phân loại lỗi trong một dự án phần mềm. Sau khi xác định được mức độ ưu tiên, bạn có thể bắt đầu cân nhắc các loại biện pháp giảm thiểu phù hợp nhất. Thông thường, những thay đổi đơn giản có thể tạo ra sự khác biệt và giảm rủi ro.

Ví dụ: khi thiết kế một ứng dụng, hãy xem xét:

• Điều chỉnh đầu ra của mô hình để phản ánh tốt hơn những gì được chấp nhận trong ngữ cảnh ứng dụng. Việc điều chỉnh có thể làm cho kết quả của mô hình dễ dự đoán và nhất quán hơn, từ đó giúp giảm thiểu một số rủi ro nhất định.
• Cung cấp một phương thức đầu vào giúp đầu ra an toàn hơn. Dữ liệu đầu vào chính xác mà bạn cung cấp cho một LLM có thể tạo ra sự khác biệt về chất lượng đầu ra. Việc thử nghiệm với lời nhắc đầu vào để tìm ra phương thức hoạt động an toàn nhất trong trường hợp sử dụng của bạn sẽ xứng đáng với những nỗ lực này, vì sau đó bạn có thể cung cấp một trải nghiệm người dùng hỗ trợ. Ví dụ: bạn có thể hạn chế người dùng chỉ chọn trong danh sách thả xuống các lời nhắc nhập, hoặc cung cấp đề xuất bật lên kèm theo các cụm từ mô tả mà bạn thấy hoạt động an toàn trong ngữ cảnh ứng dụng của mình.

• Chặn các dữ liệu đầu vào không an toàn và lọc đầu ra trước khi người dùng nhìn thấy. Trong các trường hợp đơn giản, danh sách chặn có thể được dùng để xác định và chặn từ hoặc cụm từ không an toàn trong câu lệnh hoặc câu trả lời, hoặc yêu cầu nhân viên đánh giá thay đổi hoặc chặn nội dung như vậy theo cách thủ công.

• Sử dụng thuật toán phân loại đã qua huấn luyện để gắn nhãn cho từng câu lệnh là có nguy cơ gây hại hoặc tín hiệu đối nghịch. Sau đó, có thể sử dụng các chiến lược khác nhau để xử lý yêu cầu dựa trên loại tác hại được phát hiện. Ví dụ: Nếu dữ liệu đầu vào mang tính công khai đối nghịch hoặc lạm dụng, thì dữ liệu đó có thể bị chặn và thay vào đó sẽ xuất ra một phản hồi có tập lệnh trước.

  Mẹo nâng cao

  • Nếu các tín hiệu xác định đầu ra là có hại, ứng dụng có thể sử dụng các tuỳ chọn sau:
    • Cung cấp thông báo lỗi hoặc kết quả được tập lệnh sẵn.
    • Hãy thử lại lời nhắc, trong trường hợp có một kết quả an toàn thay thế được tạo, vì đôi khi cùng một lời nhắc sẽ cho ra nhiều kết quả đầu ra.

• Áp dụng các biện pháp bảo vệ để ngăn chặn việc cố ý sử dụng sai, chẳng hạn như chỉ định một mã nhận dạng duy nhất cho mỗi người dùng và áp đặt giới hạn về số lượng truy vấn của người dùng có thể được gửi trong một khoảng thời gian nhất định. Một biện pháp bảo vệ khác là thử và ngăn chặn khả năng chèn lời nhắc. Chèn câu lệnh, giống như tính năng chèn SQL, là một cách để người dùng độc hại thiết kế một lời nhắc đầu vào thao tác với kết quả đầu ra của mô hình, chẳng hạn như bằng cách gửi một lời nhắc đầu vào hướng dẫn mô hình bỏ qua mọi ví dụ trước đó. Vui lòng xem Chính sách về hành vi bị cấm khi sử dụng AI tạo sinh để biết thông tin chi tiết về hành vi cố ý sử dụng sai mục đích.

• Điều chỉnh chức năng cho phù hợp với những yếu tố vốn có rủi ro thấp. Những công việc có phạm vi hẹp hơn (ví dụ: trích xuất từ khoá từ các đoạn văn bản) hoặc có sự giám sát của con người ở phạm vi rộng hơn (ví dụ: tạo nội dung dạng ngắn mà con người sẽ xem xét) thường có rủi ro thấp hơn. Ví dụ: thay vì tạo một ứng dụng để viết email trả lời từ đầu, bạn có thể giới hạn ứng dụng bằng cách mở rộng đề cương hoặc đề xuất các cụm từ thay thế.

Thực hiện kiểm thử an toàn phù hợp với trường hợp sử dụng của bạn

Hoạt động kiểm thử là một phần quan trọng trong quá trình xây dựng những ứng dụng mạnh mẽ và an toàn, nhưng mức độ, phạm vi và chiến lược kiểm thử sẽ khác nhau. Ví dụ: một trình tạo haiku chỉ vì mục đích thú vị có khả năng gây ra ít rủi ro hơn so với một ứng dụng được thiết kế cho các công ty luật sử dụng để tóm tắt tài liệu pháp lý và giúp soạn thảo hợp đồng. Tuy nhiên, trình tạo haiku có thể được nhiều người dùng sử dụng hơn. Điều này có nghĩa là nguy cơ gây hại hoặc thậm chí dữ liệu đầu vào có hại ngoài ý muốn có thể lớn hơn. Ngữ cảnh triển khai cũng đóng vai trò quan trọng. Ví dụ: một ứng dụng có đầu ra được các chuyên gia xem xét trước khi thực hiện bất kỳ hành động nào có thể được coi là có ít khả năng tạo ra kết quả gây hại hơn so với cùng một ứng dụng mà không có sự giám sát như vậy.

Thường thì bạn sẽ phải thực hiện thay đổi và kiểm thử nhiều lần trước khi cảm thấy tự tin rằng mình đã sẵn sàng phát hành, ngay cả đối với những ứng dụng có rủi ro tương đối thấp. Có 2 loại quy trình kiểm thử đặc biệt hữu ích cho các ứng dụng AI:

• Đo điểm chuẩn về an toàn bao gồm việc thiết kế các chỉ số về an toàn phản ánh những cách mà ứng dụng của bạn có thể không an toàn trong bối cảnh ứng dụng có khả năng được sử dụng, sau đó kiểm thử hiệu suất của ứng dụng trên các chỉ số bằng cách sử dụng tập dữ liệu đánh giá. Trước khi kiểm thử, bạn nên suy nghĩ về các mức chỉ số an toàn tối thiểu được chấp nhận trước khi kiểm thử để 1) bạn có thể đánh giá kết quả kiểm thử so với những kỳ vọng đó và 2) bạn có thể thu thập tập dữ liệu đánh giá dựa trên các bài kiểm thử đánh giá những chỉ số mà bạn quan tâm nhất.

  Mẹo nâng cao

  • Cảnh giác với các phương pháp phụ thuộc quá nhiều vào các phương pháp "không sẵn sàng" vì có khả năng bạn sẽ cần phải xây dựng tập dữ liệu thử nghiệm của riêng mình bằng cách sử dụng người đánh giá để hoàn toàn phù hợp với bối cảnh của ứng dụng.
  • Nếu có nhiều chỉ số, bạn sẽ cần quyết định cách đánh đổi xem một thay đổi có giúp cải thiện một chỉ số so với một chỉ số bất lợi khác hay không. Giống như với các kỹ thuật cải thiện hiệu suất khác, bạn nên tập trung vào hiệu suất trong trường hợp xấu nhất trong quá trình đánh giá thay vì hiệu suất trung bình.

• Kiểm thử đối nghịch bao gồm việc chủ động tìm cách gây lỗi cho ứng dụng của bạn. Mục tiêu là xác định điểm yếu để bạn có thể thực hiện các bước khắc phục khi thích hợp. Việc kiểm thử đối nghịch có thể làm mất thời gian/công sức đáng kể của những người đánh giá có chuyên môn về ứng dụng của bạn. Tuy nhiên, bạn càng làm nhiều việc kiểm thử thì bạn càng có nhiều khả năng phát hiện vấn đề, đặc biệt là những vấn đề hiếm khi xảy ra hoặc chỉ xảy ra sau khi chạy ứng dụng nhiều lần.

  • Kiểm thử đối nghịch là một phương pháp để đánh giá một cách có hệ thống một mô hình ML, nhằm tìm hiểu cách hoạt động của mô hình đó khi được cung cấp thông tin đầu vào độc hại hoặc vô tình có hại:
    • Dữ liệu đầu vào có thể độc hại khi dữ liệu đầu vào được thiết kế rõ ràng để tạo ra dữ liệu đầu ra không an toàn hoặc có hại – ví dụ: yêu cầu một mô hình tạo văn bản tạo ra một lời hận thù về một tôn giáo cụ thể.
    • Dữ liệu đầu vào vô tình gây hại khi dữ liệu đầu vào đó có thể vô hại nhưng lại tạo ra đầu ra có hại – ví dụ: yêu cầu một mô hình tạo văn bản mô tả một người thuộc một sắc tộc cụ thể và nhận dữ liệu đầu ra phân biệt chủng tộc.
  • Điểm khác biệt giữa kiểm thử đối nghịch với đánh giá tiêu chuẩn là thành phần dữ liệu dùng để kiểm thử. Đối với các kiểm thử đối nghịch, hãy chọn dữ liệu kiểm thử có nhiều khả năng tạo ra đầu ra có vấn đề nhất từ mô hình. Điều này nghĩa là thăm dò hành vi của mô hình đối với tất cả các loại hành vi gây hại có thể xảy ra, bao gồm cả các ví dụ hiếm gặp hoặc bất thường và các trường hợp đặc biệt có liên quan đến chính sách về sự an toàn. Biểu ngữ này cũng nên bao gồm tính đa dạng trong nhiều khía cạnh của câu như cấu trúc, ý nghĩa và độ dài. Bạn có thể tham khảo Các phương pháp sử dụng AI có trách nhiệm của Google về sự công bằng để biết thêm thông tin chi tiết về những điều cần xem xét khi xây dựng tập dữ liệu kiểm thử.

    Mẹo nâng cao

    • Sử dụng kiểm thử tự động thay vì phương pháp truyền thống là tranh thủ những người thuộc "nhóm đỏ" thử và phá vỡ ứng dụng của bạn. Trong hoạt động kiểm thử tự động, "nhóm màu đỏ" là một mô hình ngôn ngữ khác tìm văn bản đầu vào để tạo ra kết quả có hại từ mô hình đang được kiểm thử.

Theo dõi sự cố

Cho dù bạn thử nghiệm và giảm thiểu mức độ hiệu quả, bạn không thể đảm bảo tính hoàn hảo. Vì vậy, hãy lên kế hoạch trước về cách phát hiện và xử lý các vấn đề phát sinh. Một số phương pháp phổ biến bao gồm thiết lập một kênh được giám sát để người dùng chia sẻ ý kiến phản hồi (ví dụ: điểm xếp hạng thích/không thích) và chạy một nghiên cứu về người dùng để chủ động thu thập ý kiến phản hồi của nhiều nhóm người dùng – đặc biệt hữu ích nếu thói quen sử dụng khác với kỳ vọng.

Các bước tiếp theo

• Tham khảo hướng dẫn về chế độ cài đặt an toàn để tìm hiểu về các chế độ cài đặt an toàn có thể điều chỉnh thông qua API Gemini.
• Hãy xem phần giới thiệu về cách nhắc để bắt đầu viết câu lệnh đầu tiên.