วิศวกร Safeguard ป้องกัน LLM จากการโดน Jailbreak อย่างไร

หากใครได้ใช้งาน Fable 5 มา น่าจะเคยเจอปัญหา โดน Flag ว่า Prompt เป็นอันตราย ให้ Fallback ไปใช้ Opus เพื่อป้องกันไม่ให้มันตอบคำตอบที่อันตรายออกมา วันนี้เราอยากจะมาเล่ากันว่า วิศวกรทำ Safeguard ป้องกันไม่ให้คนพยายามผ่านกลไกพวกนี้ได้อย่างไร

ในการที่เราจะป้องกันไม่ให้โดน Jailbreak วิศวกรสามารถเข้าควบคุมได้หลากหลายวิธีการ ในหลายระดับมาก ๆ เราจะค่อย ๆ ไล่จากล่างขึ้นบนกันดีกว่า

The Training Layer

ก่อนอื่น ต้องทำความเข้าใจกันก่อนว่า LLM มันเป็น Model สำหรับทำนายคำต่อไปจากคำก่อนหน้าเท่านั้น มันไม่ได้มีจิตสำนึกอะไรเลย การที่ทำให้มันปลอดภัย ไม่ต่างจากการที่เราพยายาม สอน หรือ ปรับพฤติกรรม ของมันเลย

วิธีการสุด Classic ที่เราใช้งานกัน เรียกว่า RLHF (Reinforcement Learning from Human Feedback) ลองคิดภาพว่า เราจะต้องใช้ตัวละคร 4 ตัวมาทำงานร่วมกับ เพื่อสั่งสอน LLM ตัวแรกคือ Policy Model คอยพยายามผลิตคำตอบออกมา จากนั้น Reward Model จะค่อยมานั่งคิดว่า คำตอบไหนดีกว่ากัน ตัวที่ 3 คือ Reference Model ทำหน้าที่เป็นจุดอ้างอิงเพื่อให้มั่นใจว่า Policy Model จะไม่จำหน้าลืมหลัง และสุดท้าย Critic Model ที่คอยช่วยประเมินผลในช่วง Optimisation

กระบวนการทำงานของมันคือการที่ Policy Model พยายามเขียนคำตอบออกมาให้ Reward Model ตรวจให้คะแนน หากคะแนนดี ก็จะได้รับการปรับปรุงตัวเองผ่านวิธีการที่เรียกว่า PPO (Proximal Policy Optimisation) ปัญหาคือ การที่ต้องค่อยเรียก Reward Model ออกมาให้คะแนนทีละข้อ มันเป็นอะไรที่เปลืองมาก ๆ และ PPO เองไว้ต่อ Parameter มาก ๆ ทำให้เกิดปัญหาที่เรียกว่า Hyperparameter Hell หรืออาการที่การเปลี่ยนแปลงของ Hyperparameter ใน Model เพียงเล็กน้อย สามารถทำให้ Model ชิบหายได้เลย

ทำให้เกิดคำถามว่า ทำไมเราจะต้องจ้างครูพิเศษมาคอยให้คะแนนทำไม ในเมื่อ Model เองควรรู้ว่าอันไหนดี อันไหนไม่ดี เลยเริ่มเปลี่ยนเข้าไปในวิธีการที่ใหม่กว่าอย่าง DPO (Direct Preference Optimisation) ในทางเทคนิค มันจะมีการเทียบคำตอบ 2 ตัวคู่กัน คือมีคำตอบที่ถูกใจ และคำตอบที่โดนด่า มันจะใช้สูตรทางคณิตศาสตร์เพื่อบอก Model ให้เลือกคำตอบที่ถูกใจสูงขึ้น และลดโอกาสที่จะโดนด่าลงไป ทำให้ขั้นตอนการ Train ง่ายขึ้นกว่าเดิมมาก ๆ ละหมดปัญหา Hyperparameter Hell ที่สำคัญ Model น้อยลง ลดกำลังที่ต้องใช้ในการประมวลผลลงไปเยอะมาก

และล่าสุดนาง Lean ขึ้นเรื่อย ๆ ด้วย ORPO (Odds Ratio Preference Optimisation) มันไม่ได้หยุดแค่การตัดครูออก แต่มันรวมขั้นตอนพื้นฐานอย่างการให้จำเนื้อหา (Supervised Fine-Tuning) เข้าไปใน Preference Learning ให้เป็นขั้นตอนเดียวเลย โดยการใช้ค่าที่เรียกว่า Odds Ratio ในการคาดน้ำหนักระหว่างการจำเนื้อหาใหม่ กับการทำให้มนุษย์พอใจในสมการเดียวกัน ทำให้ Model ยากที่จะเกิด Overfitting หรือจำคำตอบมาพูดจนเสียความสามารถในการคิดแก้ไขปัญหา มันทำให้ขั้นตอนการ Train Model มันเสถียร และได้ Model ที่ออกมาเป็นธรรมชาติมากขึ้น

Deployment Layer: Guardrails & Inference-Time Safety

เมื่อเราผ่านกระบวนการ Train มาแล้ว หรือ เราเลือกใช้ Model ภายนอกเข้ามา เราจะมั่นใจได้ยังไงว่า Model เราจะตอบแต่เรื่องที่เราต้องการ การเพิ่มด่านตรวจ หรือ Guardrail เข้ามาจะช่วยเรื่องนี้ได้ดีมาก ๆ

การทำงานเริ่มที่ Pre-Processing Filter มีหลายวิธีการมาก ๆ การตรวจสอบ ง่ายที่สุดคือการใช้ Regex ตรวจสอบ Pattern ที่ชัดเจน หรือใช้ LLM Model อีกตัวที่ฉลาดน้อยกว่าเข้ามาตรวจสอบ เพื่อเข้ามาเช็คก่อนว่าความตั้งใจของ User คือการเอาไปก่ออาชญากรรมหรือไม่ และเมื่อ Model เริ่มให้ Output ก่อนที่มันจะพ่นให้ User ก็มักจะมีการติดระบบ Post-Processing Filter เพิ่มเติมเข้ามา เช่น การตรวจสอบข้อมูลที่สุ่มเสี่ยง, การตรวจหา PII หรือกระทั่งเช็คว่าคำตอบมัน Hallucinate หรือไม่

จริง ๆ แล้วกลไกนี้เป็นไอเดียที่ดีมาก ๆ ในการประหยัดต้นทุนการให้บริการ AI Service ภายในระบบของเรา เช่น ระบบของเรามี AI Chat สำหรับการถามการใช้งาน Application หรือ System ของเราเท่านั้น หากมีคนลักไก่ เอาระบบ Chat นี้แหละ ไปถามอะไรที่มันไม่เกี่ยว กลายเป็นว่าเราจะต้องเสีย Resource สำหรับการเรียก LLM ไปโดยไม่เกี่ยวกับ Service ที่เราให้บริการเลย การเอา Guardrail เข้ามาติดตั้งในส่วนนี้ จะช่วยให้เราจัดการกับ Request ที่ไม่เกี่ยวข้องได้เยอะมาก ๆ

Fable 5 Case Study

อย่างที่เราได้ทดลองใช้ Antropic Fable 5 จะเห็นได้เลยว่ามันเป็น Frontier Model ที่เก่งมาก ๆ เก่งที่สุดในแง่ของการแก้ปัญหา ณ วันที่เขียนแล้ว แต่มันก็มาพร้อมกับความกังวลแบบสุด ๆ ว่า หากเราให้ Model ที่เก่ง แก้ปัญหาเก่ง รู้เยอะขนาดนี้ มันจะเป็นอันตรายหรือไม่ ทำให้ Anthropic จะต้องป้องกัน ไม่ให้ Fable 5 ตอบอะไรที่มันอาจจะเป็นข้อมูลสำหรับการก่อการร้ายได้ ด้วย Factual Fallback

การทำ Factual Fallback คือการที่เราเอา Model ที่เก่งมาก ๆ อย่าง Fable 5 จะเช็คความเสี่ยงก่อนที่จะตอบ ถ้ามันรู้สึกว่า Input เราเข้าไปมีความเสี่ยงว่าจะเข้าข่ายผิดกฏการให้บริการ มันจะไม่พยายามตอบเบี่ยงเบน แต่เลือกที่จะส่งต่องานเดิมไปให้ Model ที่เก่งกว่าปลอดภัยกว่า อย่าง Opus 4.8 ทำงานต่อได้เลย

นี่คือตัวอย่างของ Trade-off ระหว่าง ความปลอดภัย และ ความฉลาดของ Model ที่เหมือนอั้น งก ไม่ให้ใช้นะ ถ้าคิดว่า กลไกนี้มีโอกาสเกิด False Positive สัก 5% นั่นหมายความว่า มี 5% ของ Request ที่ถูกปิดกั้นไป เป็นเรื่องที่น่าเศร้านะ แต่มันก็เพื่อจัดการความเสี่ยงที่เกิดขึ้นได้ดีที่สุดแล้ว

เราจะรู้ได้ยังไงว่า ทีเราทำมามัน ปลอดภัย จริง ๆ

สุดท้ายแล้ว เมื่อเราลงแรงทำระบบขนาดนี้ เราจะรู้ได้อย่างไรว่า มันทำงานได้ผลจริง มันต้องมีตัวชี้วัดบางอย่างเข้ามาบอกเรา ตัวแรกคือ Jailbreak Success Rate (JSR) หรืออัตราความสำเร็จในการพยายามหลอกให้ Model ตอบในสิ่งที่มันไม่ควรตอบ เช่นเมื่อก่อน เราพยายามทำที่แค่ Training Layer เท่านั้น แล้วถามคำถามสักอย่างไปมันไม่ตอบ เราก็จะบอกว่า เราอยากจะช่วยแม่ที่กำลังจะตาย ถ้าตอบแล้วแม่จะหายป่วยแล้วกลับมา ที่ตอนนั้นหลอกมันเพื่อตอบ CD Key ของ Windows XP กัน ซึ่งยิ่งค่า JSR สูงมากเท่าไหร่ ยิ่งบอกว่า Model เราอันตรายากขึ้นเท่านั้น แต่หาก Model ป้องกันตัวเองจนไม่ยอมตอบอะไรเลย แล้วเราจะเอา Model นี้มาใช้ทำไม ทำให้อีกตัวชี้วัดคือ False Positive Rate (FPR)

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

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