คำแนะนำด้านความปลอดภัย

โมเดลปัญญาประดิษฐ์แบบ Generative เป็นเครื่องมือที่มีประสิทธิภาพ แต่ก็มีข้อจำกัด ความสามารถรอบด้านและความสามารถในการนำไปใช้ของโมเดลอาจทำให้เกิดเอาต์พุตที่ไม่คาดคิดได้ในบางครั้ง เช่น เอาต์พุตที่ไม่ถูกต้อง มีอคติ หรือไม่เหมาะสม การประมวลผลภายหลังและการประเมินด้วยตนเองอย่างเข้มงวดเป็นสิ่งจำเป็นเพื่อ จำกัดความเสี่ยงที่จะเกิดอันตรายจากเอาต์พุตดังกล่าว

โมเดลที่ Gemini API มีให้สามารถใช้กับแอปพลิเคชัน Generative AI และการประมวลผลภาษาธรรมชาติ (NLP) ได้หลากหลาย การใช้ฟังก์ชันเหล่านี้จะใช้ได้ผ่าน Gemini API หรือเว็บแอป Google AI Studio เท่านั้น การใช้ Gemini API ของคุณยังเป็นไปตามนโยบายการใช้งานที่ไม่อนุญาตของ Generative AI และข้อกำหนดในการให้บริการของ Gemini API ด้วย

ส่วนหนึ่งที่ทำให้โมเดลภาษาขนาดใหญ่ (LLM) มีประโยชน์มากก็คือเป็น เครื่องมือสร้างสรรค์ที่สามารถจัดการงานด้านภาษาที่แตกต่างกันได้มากมาย อย่างไรก็ตาม นั่นหมายความว่าโมเดลภาษาขนาดใหญ่สามารถสร้างเอาต์พุตที่คุณไม่ คาดคิดได้ รวมถึงข้อความ ที่ไม่เหมาะสม ไม่คำนึงถึงความรู้สึก หรือไม่ถูกต้องตามข้อเท็จจริง ยิ่งไปกว่านั้น ความสามารถรอบด้านที่น่าทึ่งของโมเดลเหล่านี้ยังทำให้คาดเดาได้ยากว่าโมเดลอาจสร้างเอาต์พุตที่ไม่พึงประสงค์ประเภทใด แม้ว่า Gemini API จะได้รับการออกแบบโดยคำนึงถึงหลักการด้าน AI ของ Google แต่ภาระหน้าที่ในการ ใช้โมเดลเหล่านี้อย่างมีความรับผิดชอบก็ยังคงเป็นของนักพัฒนาแอป Gemini API มีการกรองเนื้อหาในตัว รวมถึงการตั้งค่าความปลอดภัยที่ปรับได้ใน 4 มิติของอันตราย เพื่อช่วยนักพัฒนาแอปในการสร้างแอปพลิเคชันที่ปลอดภัยและมีความรับผิดชอบ ดูข้อมูลเพิ่มเติมได้ที่คู่มือการตั้งค่าความปลอดภัย

เอกสารนี้มีจุดประสงค์เพื่อแนะนำความเสี่ยงด้านความปลอดภัยบางอย่างที่อาจเกิดขึ้นเมื่อ ใช้ LLM และแนะนำการออกแบบและการพัฒนาด้านความปลอดภัยที่เกิดขึ้นใหม่ (โปรดทราบว่ากฎหมายและกฎระเบียบอาจกำหนดข้อจำกัดด้วย แต่การพิจารณาดังกล่าวอยู่นอกขอบเขตของคู่มือนี้)

เราขอแนะนำให้ทำตามขั้นตอนต่อไปนี้เมื่อสร้างแอปพลิเคชันด้วย LLM

• ทำความเข้าใจความเสี่ยงด้านความปลอดภัยของแอปพลิเคชัน
• พิจารณาการปรับเพื่อลดความเสี่ยงด้านความปลอดภัย
• ทำการทดสอบความปลอดภัยที่เหมาะสมกับกรณีการใช้งานของคุณ
• ขอความคิดเห็นจากผู้ใช้และตรวจสอบการใช้งาน

ระยะการปรับและการทดสอบควรทำซ้ำจนกว่าคุณจะได้รับ ประสิทธิภาพที่เหมาะสมกับแอปพลิเคชัน

ทำความเข้าใจความเสี่ยงด้านความปลอดภัยของแอปพลิเคชัน

ในบริบทนี้ ความปลอดภัยหมายถึงความสามารถของ LLM ในการหลีกเลี่ยง การก่อให้เกิดอันตรายต่อผู้ใช้ เช่น การสร้างภาษาหรือเนื้อหาที่เป็นพิษ ซึ่งส่งเสริมภาพเหมารวม โมเดลที่พร้อมใช้งานผ่าน Gemini API ได้รับการออกแบบโดยคำนึงถึงหลักการด้าน AI ของ Google และการใช้งานโมเดลดังกล่าวเป็นไปตามนโยบายการใช้งานที่ไม่อนุญาตสำหรับ Generative AI API มีตัวกรองความปลอดภัยในตัวเพื่อช่วยแก้ปัญหาที่พบบ่อยเกี่ยวกับโมเดลภาษา เช่น ภาษาที่ไม่เหมาะสมและคำพูดแสดงความเกลียดชัง รวมถึงมุ่งมั่นที่จะครอบคลุม และหลีกเลี่ยงการเหมารวม อย่างไรก็ตาม แอปพลิเคชันแต่ละรายการอาจก่อให้เกิดความเสี่ยงที่แตกต่างกันต่อผู้ใช้ ดังนั้นในฐานะเจ้าของแอปพลิเคชัน คุณจึงมีหน้าที่ ทำความรู้จักผู้ใช้และอันตรายที่อาจเกิดขึ้นจากแอปพลิเคชันของคุณ และ ตรวจสอบว่าแอปพลิเคชันใช้ LLM อย่างปลอดภัยและมีความรับผิดชอบ

ในการประเมินนี้ คุณควรพิจารณาความเป็นไปได้ที่จะเกิดอันตราย และพิจารณาความร้ายแรงและขั้นตอนการลดความเสี่ยง ตัวอย่างเช่น แอปที่สร้างเรียงความโดยอิงตามเหตุการณ์จริงจะต้องระมัดระวัง ในการหลีกเลี่ยงข้อมูลที่ไม่ถูกต้องมากกว่าแอปที่สร้างเรื่องราว สมมติเพื่อความบันเทิง วิธีที่ดีในการเริ่มต้นสำรวจความเสี่ยงด้านความปลอดภัยที่อาจเกิดขึ้น คือการวิจัยผู้ใช้ปลายทางและบุคคลอื่นๆ ที่อาจได้รับผลกระทบจากผลลัพธ์ของแอปพลิเคชัน ซึ่งอาจใช้รูปแบบต่างๆ ได้แก่ การศึกษาวิจัยเกี่ยวกับสถานะของ การศึกษาที่ทันสมัยในโดเมนแอปของคุณ การสังเกตวิธีที่ผู้คนใช้แอปที่คล้ายกัน หรือการทําการศึกษาวิจัยผู้ใช้ แบบสํารวจ หรือการสัมภาษณ์อย่างไม่เป็นทางการกับ ผู้มีโอกาสเป็นผู้ใช้

พิจารณาการปรับเพื่อลดความเสี่ยงด้านความปลอดภัย

ตอนนี้คุณมีความเข้าใจเกี่ยวกับความเสี่ยงแล้ว คุณสามารถตัดสินใจได้ว่าจะลดความเสี่ยงเหล่านั้นอย่างไร การพิจารณาว่าควรจัดลำดับความสำคัญของความเสี่ยงใดและควรทำมากน้อยเพียงใดเพื่อพยายาม ป้องกันความเสี่ยงเหล่านั้นเป็นการตัดสินใจที่สำคัญ เช่นเดียวกับการจัดลำดับความสำคัญของข้อบกพร่องในโปรเจ็กต์ซอฟต์แวร์ เมื่อกำหนดลำดับความสำคัญแล้ว คุณจะเริ่มคิดถึง ประเภทของการลดความเสี่ยงที่เหมาะสมที่สุดได้ การเปลี่ยนแปลงเล็กๆ น้อยๆ มักจะช่วยสร้างความแตกต่างและลดความเสี่ยงได้

ตัวอย่างเช่น เมื่อออกแบบแอปพลิเคชัน ให้พิจารณาสิ่งต่อไปนี้

• การปรับเอาต์พุตของโมเดลให้สอดคล้องกับสิ่งที่ยอมรับได้ในบริบทของแอปพลิเคชันของคุณมากขึ้น การปรับแต่งจะช่วยให้เอาต์พุตของโมเดลคาดการณ์ได้มากขึ้นและสอดคล้องกัน จึงช่วยลดความเสี่ยงบางอย่างได้
• จัดหาวิธีการป้อนข้อมูลที่ช่วยให้ได้ผลลัพธ์ที่ปลอดภัยยิ่งขึ้น อินพุตที่แน่นอน ที่คุณป้อนให้กับ LLM อาจสร้างความแตกต่างในคุณภาพของเอาต์พุตได้ การทดลองใช้พรอมต์อินพุตเพื่อค้นหาสิ่งที่ทำงานได้อย่างปลอดภัยที่สุดในกรณีการใช้งานของคุณนั้นคุ้มค่ากับความพยายาม เนื่องจากคุณจะสามารถมอบ UX ที่อำนวยความสะดวกในการดำเนินการดังกล่าวได้ เช่น คุณอาจจำกัดให้ผู้ใช้เลือกได้เฉพาะจาก รายการแบบเลื่อนลงของพรอมต์อินพุต หรือแสดงคำแนะนำแบบป๊อปอัปพร้อม วลีอธิบาย ซึ่งคุณพบว่าทำงานได้อย่างปลอดภัยในบริบทของแอปพลิเคชัน

• การบล็อกอินพุตที่ไม่ปลอดภัยและกรองเอาต์พุตก่อนที่จะแสดงต่อผู้ใช้ ในสถานการณ์ที่ไม่ซับซ้อน คุณสามารถใช้รายการที่ถูกบล็อกเพื่อระบุและบล็อกคำหรือวลีที่ไม่ปลอดภัยในพรอมต์หรือคำตอบ หรือกำหนดให้เจ้าหน้าที่ตรวจสอบที่เป็นมนุษย์แก้ไขหรือบล็อกเนื้อหาดังกล่าวด้วยตนเอง

• ใช้ตัวแยกประเภทที่ผ่านการฝึกเพื่อติดป้ายกำกับแต่ละพรอมต์ด้วยอันตรายที่อาจเกิดขึ้นหรือ สัญญาณที่เป็นอันตราย จากนั้นจึงใช้กลยุทธ์ต่างๆ เกี่ยวกับวิธี จัดการคำขอตามประเภทอันตรายที่ตรวจพบ ตัวอย่างเช่น หาก อินพุตมีลักษณะเป็นศัตรูหรือเป็นการละเมิดอย่างโจ่งแจ้ง ระบบอาจบล็อกอินพุตนั้นและ แสดงผลการตอบกลับที่เขียนสคริปต์ไว้ล่วงหน้าแทน

  เคล็ดลับขั้นสูง

  • หากสัญญาณระบุว่าเอาต์พุตเป็นอันตราย แอปพลิเคชันสามารถใช้ตัวเลือกต่อไปนี้
    • ระบุข้อความแสดงข้อผิดพลาดหรือเอาต์พุตที่เขียนสคริปต์ไว้ล่วงหน้า
    • ลองใช้พรอมต์อีกครั้งในกรณีที่ระบบสร้างเอาต์พุตที่ปลอดภัยอื่น เนื่องจากบางครั้งพรอมต์เดียวกันจะทำให้เกิด เอาต์พุตที่แตกต่างกัน

• การใช้มาตรการป้องกันการละเมิดโดยเจตนา เช่น การกำหนดรหัสที่ไม่ซ้ำกันให้ผู้ใช้แต่ละรายและการกำหนดขีดจำกัดปริมาณคำค้นหาของผู้ใช้ ที่ส่งได้ในช่วงเวลาที่กำหนด การป้องกันอีกอย่างคือการพยายาม ป้องกันการแทรกพรอมต์ที่อาจเกิดขึ้น การแทรกพรอมต์ก็เหมือนกับการแทรก SQL ซึ่งเป็นวิธีที่ผู้ใช้ที่เป็นอันตรายใช้ในการออกแบบพรอมต์อินพุตที่ บิดเบือนเอาต์พุตของโมเดล เช่น โดยการส่งพรอมต์อินพุต ที่สั่งให้โมเดลไม่สนใจตัวอย่างก่อนหน้า ดูรายละเอียดเกี่ยวกับการละเมิดโดยเจตนาได้ที่นโยบายการใช้งานที่ไม่อนุญาตสำหรับ Generative AI

• ปรับฟังก์ชันการทำงานให้มีความเสี่ยงต่ำโดยธรรมชาติ โดยทั่วไปแล้ว งานที่มีขอบเขตแคบกว่า (เช่น การแยกคีย์เวิร์ดจากข้อความ) หรือมีการกำกับดูแลจากมนุษย์มากกว่า (เช่น การสร้างเนื้อหาสั้นที่จะได้รับการตรวจสอบจากมนุษย์) มักมีความเสี่ยงต่ำกว่า ดังนั้น ตัวอย่างเช่น แทนที่จะสร้างแอปพลิเคชันเพื่อเขียนการตอบกลับอีเมลตั้งแต่ต้น คุณอาจจำกัดให้แอปพลิเคชันขยายโครงร่างหรือแนะนำการเรียบเรียงคำใหม่แทน

ทำการทดสอบความปลอดภัยที่เหมาะสมกับกรณีการใช้งานของคุณ

การทดสอบเป็นส่วนสำคัญในการสร้างแอปพลิเคชันที่แข็งแกร่งและปลอดภัย แต่ขอบเขต และกลยุทธ์ในการทดสอบจะแตกต่างกันไป ตัวอย่างเช่น ไฮกุ ที่สร้างขึ้นเพื่อความสนุกสนานมีแนวโน้มที่จะก่อให้เกิดความเสี่ยงน้อยกว่าแอปพลิเคชันที่ออกแบบ มาเพื่อใช้โดยบริษัทกฎหมายในการสรุปเอกสารทางกฎหมายและช่วยร่างสัญญา แต่ผู้ใช้จำนวนมากขึ้นอาจใช้โปรแกรมสร้างไฮกุ ซึ่งหมายความว่าอาจมีโอกาสมากขึ้นที่จะเกิดความพยายามที่เป็นการต่อต้านหรือแม้แต่การป้อนข้อมูลที่เป็นอันตรายโดยไม่ตั้งใจ บริบทของการติดตั้งใช้งานก็มีความสำคัญเช่นกัน เช่น แอปพลิเคชัน ที่มีเอาต์พุตซึ่งได้รับการตรวจสอบจากผู้เชี่ยวชาญก่อนที่จะมีการดำเนินการใดๆ อาจถือว่ามีแนวโน้มที่จะสร้างเอาต์พุตที่เป็นอันตรายน้อยกว่าแอปพลิเคชันที่เหมือนกัน ซึ่งไม่มีการกำกับดูแลดังกล่าว

การเปลี่ยนแปลงและการทดสอบหลายครั้งก่อนที่จะมั่นใจว่าพร้อมเปิดตัวเป็นเรื่องที่พบเห็นได้บ่อย แม้แต่กับแอปพลิเคชันที่มีความเสี่ยงค่อนข้างต่ำ การทดสอบ 2 ประเภทต่อไปนี้มีประโยชน์อย่างยิ่งสำหรับแอปพลิเคชัน AI

• การเปรียบเทียบความปลอดภัยเกี่ยวข้องกับการออกแบบเมตริกความปลอดภัยที่สะท้อนถึง วิธีที่แอปพลิเคชันของคุณอาจไม่ปลอดภัยในบริบทของวิธีที่น่าจะ มีการใช้งาน จากนั้นทดสอบประสิทธิภาพของแอปพลิเคชันตามเมตริก โดยใช้ชุดข้อมูลการประเมิน แนวทางปฏิบัติแนะนำคือการพิจารณาระดับต่ำสุดที่ยอมรับได้ของเมตริกความปลอดภัยก่อนทำการทดสอบ เพื่อให้ 1) คุณประเมินผลการทดสอบเทียบกับความคาดหวังเหล่านั้นได้ และ 2) คุณรวบรวมชุดข้อมูลการประเมินตามการทดสอบที่ประเมินเมตริกที่คุณสนใจมากที่สุดได้

  เคล็ดลับขั้นสูง

  • โปรดระวังการพึ่งพาแนวทาง "สำเร็จรูป" มากเกินไป เนื่องจากคุณอาจต้องสร้างชุดข้อมูลการทดสอบของคุณเองโดยใช้ผู้ให้คะแนนที่เป็นมนุษย์เพื่อให้เหมาะกับบริบทของแอปพลิเคชันอย่างเต็มที่
  • หากมีเมตริกมากกว่า 1 รายการ คุณจะต้องตัดสินใจว่าจะ แลกเปลี่ยนอย่างไรหากการเปลี่ยนแปลงทำให้เมตริกหนึ่งดีขึ้น แต่ทำให้อีกเมตริกหนึ่งแย่ลง เช่นเดียวกับการปรับแต่งประสิทธิภาพอื่นๆ คุณอาจต้องการมุ่งเน้นที่ประสิทธิภาพในกรณีที่แย่ที่สุดในชุดการประเมินมากกว่าประสิทธิภาพโดยเฉลี่ย

• การทดสอบการจำลองปัญหาเกี่ยวข้องกับการพยายามทำลายแอปพลิเคชันของคุณในเชิงรุก เป้าหมายคือการระบุจุดอ่อนเพื่อให้คุณดำเนินการ แก้ไขตามความเหมาะสมได้ การทดสอบแบบ Adversarial อาจต้องใช้เวลา/ความพยายามอย่างมากจากผู้ประเมินที่มีความเชี่ยวชาญในแอปพลิเคชันของคุณ แต่ยิ่งคุณทำมากเท่าใด โอกาสในการพบปัญหาจะยิ่งมากขึ้น โดยเฉพาะปัญหาที่เกิดขึ้นไม่บ่อยนักหรือเกิดขึ้นหลังจากเรียกใช้แอปพลิเคชันซ้ำๆ เท่านั้น

  • การทดสอบการจำลองปัญหาเป็นวิธีการประเมินโมเดล ML อย่างเป็นระบบโดยมีจุดประสงค์เพื่อดูว่าโมเดลทำงานอย่างไรเมื่อได้รับอินพุตที่เป็นอันตรายหรือเป็นอันตรายโดยไม่ตั้งใจ
    • อินพุตอาจเป็นอันตรายเมื่อได้รับการออกแบบอย่างชัดเจนเพื่อ สร้างเอาต์พุตที่ไม่ปลอดภัยหรือเป็นอันตราย เช่น การขอให้โมเดล การสร้างข้อความสร้างการระบายความเกลียดชังเกี่ยวกับศาสนาหนึ่งๆ
    • อินพุตเป็นอันตรายโดยไม่ตั้งใจเมื่ออินพุตนั้นอาจไม่มีพิษภัย แต่สร้างเอาต์พุตที่เป็นอันตราย เช่น การขอให้โมเดลสร้างข้อความอธิบายบุคคลที่มีเชื้อชาติหนึ่งๆ แล้วได้รับเอาต์พุตที่เหยียดเชื้อชาติ
  • สิ่งที่ทำให้การทดสอบแบบ Adversarial แตกต่างจากการประเมินมาตรฐานคือ องค์ประกอบของข้อมูลที่ใช้ในการทดสอบ สำหรับการทดสอบแบบ Adversarial ให้เลือก ข้อมูลการทดสอบที่มีแนวโน้มมากที่สุดที่จะกระตุ้นให้โมเดล สร้างเอาต์พุตที่เป็นปัญหา ซึ่งหมายถึงการตรวจสอบลักษณะการทำงานของโมเดลสำหรับอันตรายทุกประเภทที่อาจเกิดขึ้น รวมถึงตัวอย่างที่หายากหรือผิดปกติ และกรณีที่ขอบที่เกี่ยวข้องกับนโยบายด้านความปลอดภัย นอกจากนี้ ควรมี ความหลากหลายในมิติต่างๆ ของประโยค เช่น โครงสร้าง ความหมาย และความยาว โปรดดูรายละเอียดเพิ่มเติมเกี่ยวกับสิ่งที่ควรพิจารณาเมื่อสร้างชุดข้อมูลทดสอบในแนวทางปฏิบัติเกี่ยวกับ AI อย่างมีความรับผิดชอบของ Google ในเรื่อง ความเป็นธรรม

    เคล็ดลับขั้นสูง

    • ใช้ การทดสอบอัตโนมัติ แทนวิธีการดั้งเดิมในการเกณฑ์คนเข้าร่วม "ทีมสีแดง" เพื่อพยายามเจาะแอปพลิเคชันของคุณ ในการทดสอบอัตโนมัติ "ทีมสีแดง" คือโมเดลภาษาอีกโมเดลหนึ่งที่ค้นหาข้อความอินพุตที่กระตุ้นให้โมเดลที่กำลังทดสอบสร้างเอาต์พุตที่เป็นอันตราย

ตรวจสอบปัญหา

ไม่ว่าคุณจะทดสอบและลดความเสี่ยงมากเพียงใด คุณก็ไม่สามารถรับประกันความสมบูรณ์แบบได้ ดังนั้น โปรดวางแผนล่วงหน้าว่าจะระบุและจัดการกับปัญหาที่เกิดขึ้นอย่างไร แนวทางที่ใช้กันโดยทั่วไป ได้แก่ การตั้งค่าช่องที่ตรวจสอบเพื่อให้ผู้ใช้แชร์ความคิดเห็น (เช่น การให้คะแนนชอบ/ไม่ชอบ) และการทําการศึกษาผู้ใช้เพื่อขอความคิดเห็นจากผู้ใช้ที่หลากหลายอย่างเชิงรุก ซึ่งจะมีประโยชน์อย่างยิ่งหากรูปแบบการใช้งานแตกต่างจากที่คาดไว้

ขั้นตอนถัดไป

• ดูข้อมูลเกี่ยวกับการตั้งค่าความปลอดภัยที่ปรับได้ซึ่งพร้อมใช้งานผ่าน Gemini API ได้ในคู่มือการตั้งค่าความปลอดภัย
• ดูข้อมูลเบื้องต้นเกี่ยวกับการเขียนพรอมต์เพื่อเริ่มต้นเขียนพรอมต์แรก