การคิดเชิงปฏิปักษ์: สิ่งที่ GANs สอนเราเกี่ยวกับลูปแอป AI

แนวคิดง่าย ๆ: สองระบบที่ผลักดันกันให้ดีขึ้น

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

สิ่งนี้ปรากฏอยู่แล้วในการทำงานซอฟต์แวร์ประจำวัน ฟีเจอร์ถูกปล่อย แล้วเทสต์พยายามทำลายมัน ทีมความปลอดภัยเพิ่มการป้องกัน แล้วผู้โจมตี (หรือ red team) ล่าหาช่องโหว่ เวิร์กโฟลว์ฝ่ายสนับสนุนดูดีบนกระดาษ แต่คำร้องเรียนจากผู้ใช้จริงจะเปิดเผยว่ามันล้มเหลวตรงไหน การต่อต้านนี่แหละที่เปลี่ยนร่างแรกให้เป็นสิ่งที่ไว้ใจได้

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

ลูปที่ต้องการควรเล็กและวนได้:\n

• กำหนดสิ่งที่ถือว่า “ดี” (เป้าหมายและเกณฑ์ผ่านที่ชัดเจน)\n- สร้างผลลัพธ์ (การตอบของโมเดล พฤติกรรมฟีเจอร์ การตัดสินใจ)\n- โจมตีผลลัพธ์เหล่านั้นด้วยกรณีความล้มเหลวที่สมจริง\n- วัดสิ่งที่พังและทำไม แล้วอัปเดตระบบ\n- ทำซ้ำตามตารางเพื่อให้การปรับปรุงเป็นกิจวัตร

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

Ian Goodfellow และ GANs แบบภาษาเรียบง่าย

Ian Goodfellow แนะนำ Generative Adversarial Networks (GANs) ในปี 2014

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

บทบาทโดยทั่วไปคือ:\n

• Generator: สร้างตัวอย่างใหม่ที่มุ่งหวังจะดูเหมือนจริง\n- Discriminator: ตัดสินแต่ละตัวอย่างว่า “จริง” หรือ “ปลอม”\n ลูปฟีดแบ็กคือจุดประสงค์ทั้งหมด เมื่อ discriminator จับ generator ได้ generator ก็เรียนรู้ว่าสิ่งไหนทำให้ออกโฉนด เมื่อ generator หลอก discriminator ได้ discriminator ก็เรียนรู้สิ่งที่มันพลาด ผ่านรอบจำนวนมาก สัญญาณที่ง่าย ๆ จะใช้ไม่ได้แล้ว ดังนั้น generator ถูกผลักไปสู่ผลลัพธ์ที่สมจริงขึ้นเรื่อย ๆ

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

ทำไมการฝึกแบบปฏิปักษ์ได้ผล (และเมื่อไหร่มันพัง)

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

คู่แข่งที่มีประโยชน์มีสองคุณสมบัติ: เป้าหมายชัดเจนและการให้คะแนนสม่ำเสมอ ใน GAN งานของ discriminator ง่าย: บอกจริงหรือปลอม เมื่อตัดสินใจนั้นคงที่พอ generator จะได้ฟีดแบ็กที่ใช้ได้จริงเกี่ยวกับสิ่งที่ดูผิด แม้จะไม่มีใครเขียนกฎสมบูรณ์ได้

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

ความไม่เสถียรมักเกิดเมื่อคู่แข่งไม่สมดุล:\n

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

ข้อจำกัดเชิงปฏิบัติที่สำคัญคือ: ลูปอาจจะปรับไปยังเป้าหมายผิด หากผู้ตัดสินให้รางวัล "ฟังดูสมเหตุสมผล" แทน "ถูกต้อง" ระบบจะเรียนรู้ที่จะฟังดูถูกต้อง บอทฝ่ายสนับสนุนที่ถูกฝึกเพียงโทนและความลื่นไหลอาจให้คำตอบที่มั่นใจแต่พลาดรายละเอียดนโยบาย ลูปทำงาน แต่ไม่ใช่งานที่คุณต้องการ

แพตเทิร์นทั่วไป: ผลิต vs ตัดสิน

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

สิ่งที่สำคัญคือวงจร:\n

1. ผลิตผลลัพธ์ (การพยากรณ์ คำตอบ ฟลูว์ UI ตัวอย่างพร้อมปล่อย)\n2. ตัดสินเทียบกับเป้าหมาย (ความถูกต้อง กฎความปลอดภัย สไตล์ ความหน่วง ความต้านทานการละเมิด)\n3. เรียนรู้จากความล้มเหลว (แก้โค้ด ปรับ prompt เพิ่มการป้องกัน อัปเดตข้อมูล)\n4. ทำซ้ำ

สร้างด้วยข้อสมมติฐานว่ารุ่นแรกจะถูกหลอก ถูกใช้ผิด หรือถูกเข้าใจผิด แล้วออกแบบวิธีหากรณีเหล่านั้นอย่างรวดเร็ว

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

คุณเห็นรูปทรงเดียวกันนี้ในการทำงานปกติ: unit tests ขยายหลังจากบัก QA เพิ่มกรณีขอบเมื่อความซับซ้อนเพิ่ม การตรวจจับการฉ้อโกงวิวัฒนาการตามที่คนฉ้อโกงปรับตัว คุณไม่จำเป็นต้องมีผู้ตัดสินที่สมบูรณ์ในวันแรก แค่ผู้ตัดสินที่เรียนรู้ต่อ และนิสัยในการเปลี่ยนทุกความล้มเหลวให้เป็นเช็คลิสต์ใหม่

ลูป prompt vs eval ในแอปที่สร้างด้วย AI

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

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

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

แล้วรันวงจร: เปลี่ยน prompt รัน eval เปรียบเทียบผล เก็บหรือย้อนกลับ ส่วนเชิงปฏิปักษ์คือ eval ของคุณพยายามจับความล้มเหลวที่คุณอาจพลาด

การถดถอยคือกับดักหลัก การปรับ prompt อาจแก้เคสหนึ่งและเงียบ ๆ พังสองเคสเก่า อย่าเชื่อการสนทนาดี ๆ เพียงครั้งเดียว เชื่อบัตรคะแนนทั้งชุด

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

ถ้าคุณสร้างบนแพลตฟอร์ม chat-to-app อย่าง Koder.ai ช่วยได้ที่จะปฏิบัติต่อเวอร์ชัน prompt เหมือน release: ถ่ายสแนปช็อตสิ่งที่ใช้ได้ รัน eval และโปรโมตเฉพาะเมื่อการสกอร์ดีขึ้นโดยไม่ทำให้เคสเก่าเสีย