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

โมเดลปัญญาประดิษฐ์ (AI) แบบ 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

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

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

วงจรการใช้งานโมเดล

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

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

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

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

  • สื่อสารกับผู้มีโอกาสเป็นผู้ใช้หลากหลายกลุ่มภายในกลุ่มประชากรเป้าหมายเกี่ยวกับแอปพลิเคชันและวัตถุประสงค์ที่ตั้งใจไว้ เพื่อให้เห็นมุมมองที่กว้างขึ้นเกี่ยวกับความเสี่ยงที่อาจเกิดขึ้น และปรับเกณฑ์ความหลากหลายตามความจำเป็น
  • กรอบการจัดการความเสี่ยงเกี่ยวกับ AI ที่เผยแพร่โดยสถาบันมาตรฐานและเทคโนโลยีแห่งชาติ (National Institute of Standards and Technology หรือ NIST) ของรัฐบาลสหรัฐอเมริกาให้แนวทางที่ละเอียดมากขึ้นและแหล่งข้อมูลการเรียนรู้เพิ่มเติมสำหรับการจัดการความเสี่ยงของ AI
  • สื่อเผยแพร่ของ DeepMind เกี่ยวกับ ความเสี่ยงทางจริยธรรมและสังคมที่จะทำให้เกิดอันตรายจากโมเดลภาษา ได้อธิบายรายละเอียดว่าแอปพลิเคชันโมเดลภาษาอาจก่อให้เกิดอันตรายได้อย่างไร

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ตรวจหาปัญหา

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

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

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

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