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

Các mô hình trí tuệ nhân tạo tạo sinh là những công cụ mạnh mẽ, nhưng vẫn còn những hạn chế. Tính linh hoạt và khả năng ứng dụng của các công cụ này đôi khi có thể dẫn đến các kết quả không mong muốn, chẳng hạn như kết quả không chính xác, sai lệch hoặc phản cảm. Quy trình hậu xử lý và quy trình đánh giá thủ công nghiêm ngặt là những yếu tố cần thiết để hạn chế rủi ro thiệt hại từ những dữ liệu đầu ra đó.

Các mô hình do Gemini API cung cấp có thể dùng cho nhiều ứng dụng AI tạo sinh và xử lý ngôn ngữ tự nhiên (NLP). Việc sử dụng các chức năng này chỉ có thể thực hiện được thông qua Gemini API hoặc ứng dụng web Google AI Studio. Việc bạn sử dụng Gemini API cũng phải tuân thủ Chính sách về các hành vi bị cấm khi sử dụng AI tạo sinh và Điều khoản dịch vụ của Gemini API.

Một trong những yếu tố làm cho các mô hình ngôn ngữ lớn (LLM) trở nên hữu ích là chúng trở thành những công cụ sáng tạo có thể giải quyết nhiều nhiệm vụ về ngôn ngữ. 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 đầu ra mà bạn không mong đợi, bao gồm cả văn bản phản cảm, thiếu tế nhị hoặc không chính xác trên 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 khiến chúng tôi khó dự đoán chính xác loại đầu ra không mong muốn mà chúng có thể tạo ra. Mặc dù API Gemini được thiết kế dựa trên các nguyên tắc về AI của Google, nhưng trách nhiệm của nhà phát triển là á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 ra các ứng dụng an toàn và có trách nhiệm, Gemini API có một số tính năng lọc nội dung tích hợp sẵn 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. Hãy 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 LLM (mô hình ngôn ngữ lớn), đồng thời đề xuất các đề xuất mới về thiết kế và phát triển liên quan đến an toàn. (Xin lưu ý rằng các luật và quy định cũng có thể áp dụng các quy định hạn chế, nhưng những điểm cần cân nhắc như vậy nằm ngoài phạm vi của hướng dẫn này.)

Bạn nên thực hiện các bước sau đây khi xây dựng ứng dụng bằng LLM:

  • Hiểu được những rủi ro về an toàn của ứng dụng
  • Xem xét các điều chỉnh để giảm thiểu rủi ro về an toàn
  • Tiến hành thử nghiệm tính an toàn phù hợp với trường hợp sử dụng của bạn
  • Thu hút ý kiến phản hồi của người dùng và theo dõi mức sử dụng

Các giai đoạn điều chỉnh và kiểm thử nên được 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.

Chu kỳ triển khai mô hình

Hiểu được những rủi ro về an toàn của ứng dụng

Trong bối cảnh này, an toàn được định nghĩa là khả năng của một LLM (mô hình ngôn ngữ lớn) 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 đó phải tuân thủ 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 đề thường gặp 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 nỗ lực hướng đến sự hoà nhập và tránh các định kiến. Tuy nhiên, mỗi ứng dụng có thể gây ra một loạt rủi ro khác nhau cho người dùng. Vì vậy, với tư cách 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 tác hại tiềm ẩn mà ứng dụng của bạn 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 và xác định mức độ nghiêm trọng cũng như các bước giảm nhẹ. Chẳng hạn, một ứng dụng tạo bài luận dựa trên các sự kiện thực tế sẽ cần phải thận trọng 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 chỉ để giải trí. Một cách hay để bắt đầu khám phá những rủi ro tiềm ẩn về an toà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. Có nhiều hình thức để tìm hiểu, bao gồm nghiên cứu về các nghiên cứu hiện đại trong miền ứng dụng của bạn, quan sát cách mọi người đang 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 hoặc tiến hành các cuộc phỏng vấn không chính thức với người dùng tiềm năng.

Mẹo nâng cao

  • Hãy trao đổi với nhiều người dùng tiềm năng trong cộng đồng mục tiêu về ứng dụng của bạn cũng như mục đích dự định của ứng dụng để có góc nhìn rộng hơn về những rủi ro tiềm ẩn và điều chỉnh các tiêu chí về tính đa dạng khi cần.
  • Khung quản lý rủi ro về AI do Viện Tiêu chuẩn và Công nghệ Quốc gia (NIST) của chính phủ Hoa Kỳ ban hành cung cấp hướng dẫn chi tiết hơn và tài nguyên học tập bổ sung về quản lý rủi ro về AI.
  • Ấn phẩm của DeepMind về các rủi ro gây hại về đạo đức và xã hội từ mô hình ngôn ngữ mô tả chi tiết những cách mà ứng dụng mô hình ngôn ngữ có thể gây hại.

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

Giờ đây, khi đã hiểu rõ các rủi ro, bạn có thể quyết định cách giảm thiểu các 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 để cố gắng ngăn chặn chúng là một quyết định 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 nghĩ đến những loại 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ế ứng dụng, hãy cân nhắc:

  • Điều chỉnh đầu ra của mô hình để phản ánh rõ hơn những nội dung được chấp nhận trong ngữ cảnh ứng dụng của bạn. Việc điều chỉnh có thể giúp kết quả của mô hình dễ dự đoán và nhất quán hơn, nhờ đó có thể giúp giảm thiểu một số rủi ro nhất định.
  • Cung cấp phương thức nhập để thiết bị đầ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 của đầu ra. Việc thử nghiệm các lời nhắc đầu vào để tìm ra nội dung hoạt động an toàn nhất trong trường hợp sử dụng của bạn hoàn toàn xứng đáng với nỗ lực của bạn, vì sau đó, bạn có thể cung cấp một trải nghiệm người dùng hỗ trợ việc này. Ví dụ: bạn có thể hạn chế người dùng chỉ chọn trong danh sách thả xuống gồm các câu lệnh nhập, hoặc cung cấp các đề xuất bật lên có 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.

  • Chặn dữ liệu đầu vào và lọc đầu ra không an toàn trước khi hiển thị cho người dùng. 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 những từ hay 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á chỉnh sửa hay chặn nội dung đó theo cách thủ công.

  • Sử dụng thuật toán phân loại đã qua đào tạo để gắn nhãn cho từng câu lệnh bằng các mối nguy hại tiềm ẩn hoặc tín hiệu nghịch đảo. 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 thông tin đầu vào có tính chất quá nghịch đảo hoặc lạm dụng, thì dữ liệu đó có thể bị chặn và thay vào đó sẽ đưa ra một phản hồi được viết sẵn theo tập lệnh.

    Mẹo nâng cao

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

  • Áp dụng các biện pháp bảo vệ để ngăn chặn hành vi cố ý sử dụng sai mục đích, chẳng hạn như chỉ định cho mỗi người dùng một mã nhận dạng duy nhất 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à bảo vệ khỏi khả năng chèn lời nhắc. Chèn câu lệnh, cũng giống như chèn SQL, là một cách để người dùng độc hại thiết kế lời nhắc đầu vào thao tác với kết quả của mô hình, chẳng hạn như bằng cách gửi 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ề các 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 thành chức năng vốn có mức độ rủi ro vốn đã thấp. Những nhiệm vụ 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 chặt chẽ hơn của con người (ví dụ: tạo nội dung dạng ngắn sẽ để con người đánh giá) thường có rủi ro thấp hơn. Ví dụ: thay vì tạo ứng dụng để viết email trả lời từ đầu, bạn có thể giới hạn việc này trong việc mở rộng dàn ý hoặc đề xuất các cụm từ thay thế.

Tiến hành kiểm thử an toàn theo trường hợp sử dụng của bạn

Kiểm thử là một phần quan trọng trong việc xây dựng các ứng dụng mạnh mẽ và an toàn, nhưng phạm vi, phạm vi và chiến lược kiểm thử sẽ khác nhau. Ví dụ: một trình tạo bài thơ haiku chỉ để vui vẻ có thể gây ra ít rủi ro hơn so với một ứng dụng được các công ty luật thiết kế để 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ơ đối nghịch hoặc thậm chí dữ liệu đầu vào gây hại không chủ ý có thể lớn hơn. Bối cảnh triển khai cũng rất quan trọng. Ví dụ: một ứng dụng có đầu ra được các chuyên gia con người xem xét trước khi thực hiện bất kỳ hành động nào có thể được coi là ít có khả năng tạo ra đầu ra có hại hơn so với ứng dụng tương tự mà không có sự giám sát như vậy.

Nhiều lần bạn sẽ 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. 2 loại kiểm thử đặc biệt hữu ích cho các ứng dụng AI:

  • Quy trình Đo điểm chuẩn an toàn liên quan đến việc thiết kế các chỉ số an toàn phản ánh các cách ứng dụng của bạn có thể không an toàn xét theo khả năng ứng dụng được sử dụng, sau đó kiểm thử hiệu suất của ứng dụng dựa trên các chỉ số bằng tập dữ liệu đánh giá. Bạn nên nghĩ đến các chỉ số an toàn tối thiểu chấp nhận được trước khi kiểm thử để 1) bạn có thể đánh giá kết quả kiểm thử dựa trên 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 việc phụ thuộc quá nhiều vào các phương pháp tiếp cận "ngoài kệ" vì có thể bạn sẽ cần xây dựng các tập dữ liệu kiểm thử của riêng mình bằng cách sử dụng nhân viên đánh giá để hoàn toàn phù hợp với ngữ cảnh ứng dụng của bạn.
    • Nếu có nhiều chỉ số, bạn cần phải quyết định xem mình sẽ đánh đổi như thế nào nếu một thay đổi dẫn đến sự cải thiện của một chỉ số lại gây hại cho một chỉ số khác. Giống như 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 xấu nhất trên tập hợp đá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 phá vỡ ứng dụng của bạn. Mục tiêu là xác định các điểm yếu để bạn có thể thực hiện các bước khắc phục khi phù hợp. Kiểm thử đối nghịch có thể tốn thời gian/công sức đáng kể của những người đánh giá có kiến thức chuyên môn về ứng dụng của bạn. Tuy nhiên, bạn càng làm nhiều thì khả năng phát hiện vấn đề càng lớn, đặc biệt là những vấn đề hiếm khi xảy ra hoặc chỉ xảy ra sau khi ứng dụng chạy lặp đi lặp lại.

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

      Mẹo nâng cao

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

Theo dõi sự cố

Bất kể bạn kiểm thử và giảm thiểu nhiều đến mức nào, bạn cũng không bao giờ đảm bảo được sự hoàn hảo. Vì vậy, hãy lên kế hoạch trước về cách bạn sẽ phát hiện và xử lý các vấn đề phát sinh. Các 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à tiến hành nghiên cứu người dùng để chủ động thu thập ý kiến phản hồi từ nhiều nhóm người dùng — đặc biệt có giá trị nếu thói quen sử dụng không giống như kỳ vọng.

Mẹo nâng cao

  • Khi người dùng đưa ra ý kiến phản hồi về các sản phẩm AI, ý kiến phản hồi của người dùng có thể giúp cải thiện đáng kể hiệu suất của AI và trải nghiệm người dùng theo thời gian, chẳng hạn như giúp bạn chọn các ví dụ phù hợp hơn để điều chỉnh câu lệnh. Chương Phản hồi và Kiểm soát trong sách hướng dẫn về Con người và AI của Google nêu bật những điểm quan trọng cần cân nhắc khi thiết kế cơ chế phản hồi.

Các bước tiếp theo