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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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