คำแนะนำด้านความปลอดภัยและความถูกต้อง

โมเดลปัญญาประดิษฐ์แบบ 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 มิติของอันตราย เพื่อช่วยนักพัฒนาแอปในการสร้างแอปพลิเคชันที่ปลอดภัยและมีความรับผิดชอบ ดูข้อมูลเพิ่มเติมได้ที่คู่มือการตั้งค่าความปลอดภัย นอกจากนี้ยังมีการเปิดใช้ Grounding with Google Search เพื่อปรับปรุงความถูกต้องของข้อเท็จจริงด้วย แม้ว่าอาจปิดใช้ สำหรับนักพัฒนาแอปที่มีกรณีการใช้งานที่สร้างสรรค์มากกว่าและไม่ได้มุ่งเน้นการค้นหาข้อมูล

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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