เทคนิคการกลั่นตัวเองที่เรียบง่ายอย่างน่าประหลาด ซึ่งช่วยเพิ่มประสิทธิภาพการสร้างโค้ด

 (arxiv.org)
12 คะแนน โดย GN⁺ 26 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Simple Self-Distillation (SSD) คือวิธีที่ช่วยเพิ่มประสิทธิภาพของโมเดลภาษาขนาดใหญ่ด้วยการนำโค้ดที่โมเดลสร้างขึ้นเองกลับมาใช้ฝึกอีกครั้ง โดยไม่ต้องใช้โมเดลครูหรือการเรียนรู้แบบเสริมกำลัง
  • เพิ่มคะแนน pass@1 ของโมเดล Qwen3-30B-Instruct บน LiveCodeBench v6 จาก 42.4% เป็น 55.3% และปรับปรุงได้เด่นชัดเป็นพิเศษใน ช่วงโจทย์ยากที่ +15.3pp
  • SSD ช่วย บรรเทาความขัดแย้งระหว่างความแม่นยำกับการสำรวจ ระหว่างการสร้างโค้ด โดย กดความน่าจะเป็นส่วนหางตามบริบทและคงความหลากหลายที่มีประโยชน์ไว้
  • ไม่สามารถทำซ้ำผลลัพธ์แบบเดียวกันได้ด้วยการปรับอุณหภูมิหรือเปลี่ยนนโยบายการถอดรหัสอย่างเดียว เพราะ SSD ปรับโครงสร้างการกระจายภายในของโมเดลโดยตรง
  • เป็น ขั้นตอนการฝึกหลังการประมวลผลที่เรียบง่าย ซึ่งนำไปใช้ได้โดยไม่ต้องมีข้อมูลภายนอกหรือการตรวจสอบ และเสนอ ทางเลือกที่ใช้งานได้จริงในการยกระดับคุณภาพการสร้างโค้ดของ LLM

การกลั่นตัวเองแบบเรียบง่าย (Simple Self-Distillation, SSD)

  • SSD (Simple Self-Distillation) คือวิธีที่ทำให้โมเดลภาษาขนาดใหญ่ (LLM) มีประสิทธิภาพดีขึ้นด้วยการใช้ผลลัพธ์โค้ดที่โมเดลสร้างขึ้นเอง โดยไม่ต้องมีโมเดลครู ตัวตรวจสอบ หรือการเรียนรู้แบบเสริมกำลัง
    • โมเดลจะสร้างตัวอย่างด้วยการตั้งค่า temperature และ truncation ที่กำหนดไว้ แล้วนำผลลัพธ์นั้นกลับมาฝึกใหม่ด้วย supervised fine-tuning (SFT) แบบมาตรฐาน
    • ไม่ต้องใช้ข้อมูลที่มีป้ายกำกับจากภายนอก โมเดลรางวัล หรือสภาพแวดล้อมสำหรับรันโค้ดเลย
  • เพิ่มคะแนน pass@1 ของ Qwen3-30B-Instruct บน LiveCodeBench v6 จาก 42.4% → 55.3% (+12.9pp, เพิ่มขึ้นเชิงสัมพัทธ์ +30%)
    • โดยเฉพาะใน โจทย์ยาก (hard split) ที่ปรับปรุงได้มากที่สุด (+15.3pp)
    • ใช้ได้ครอบคลุมกับโมเดลตระกูล Qwen และ Llama ขนาด 4B, 8B, 30B
  • SSD ทำงานด้วยการบรรเทา ความขัดแย้งระหว่างความแม่นยำกับการสำรวจ (precision-exploration conflict)
    • ระหว่างการสร้างโค้ด บางโทเคนต้องการความแม่นยำสูง (“lock”) ขณะที่บางโทเคนต้องการการสำรวจอย่างหลากหลาย (“fork”)
    • SSD ช่วย กดการกระจายส่วนหางที่ไม่จำเป็น ตามบริบท ขณะเดียวกันก็ รักษาความหลากหลายที่มีประโยชน์ไว้

1. ภูมิหลังของงานวิจัย

  • การขาดสัญญาณกำกับดูแลคุณภาพสูง (เช่น โค้ดที่มนุษย์เขียน) ทำให้เกิด ข้อจำกัดในการยกระดับประสิทธิภาพการสร้างโค้ดของ LLM
  • ข้อจำกัดของแนวทางเดิม
    • การกลั่นด้วยโมเดลครู: สืบทอดข้อจำกัดด้านประสิทธิภาพของโมเดลครู
    • การเรียนรู้แบบเสริมกำลัง (RL): ต้องมีโมเดลรางวัลและการตรวจสอบบนฐานการรันจริง อีกทั้งยังไม่เสถียร
    • ทางเลือกแบบไม่กำกับดูแล (เช่น majority voting, entropy minimization): มีความเสี่ยงต่อการพังทลายเมื่อฝึกระยะยาว
  • SSD แสดงให้เห็นว่าสามารถปรับปรุงได้ด้วยผลลัพธ์ของโมเดลเอง โดยไม่ต้องใช้ข้อมูลภายนอกหรือการตรวจสอบ

2. วิธีการของ SSD

  • การสังเคราะห์ข้อมูล

    • สำหรับชุดพรอมป์โจทย์ที่กำหนด X จะสุ่มตัวอย่างจากโมเดล pθ ด้วย อุณหภูมิ Ttrain และ การตั้งค่า truncation ρtrain (top-k, top-p)
    • เอาต์พุตที่สร้างขึ้น (y) จะถูกนำไปใช้เป็นข้อมูลฝึก DSSD ทันที โดยไม่ผ่านการตรวจสอบ
    • ในกรณีส่วนใหญ่ N=1 (หนึ่งตัวอย่างต่อหนึ่งโจทย์) ก็เพียงพอ

  • การฝึก

    • ทำ supervised fine-tuning ด้วย cross-entropy loss แบบมาตรฐาน
    • L(θ) = −E(x,y)∼DSSD Σ log pθ(yt | x, y<t)

  • การอนุมาน

    • ถอดรหัสโมเดลที่ฝึกแล้ว pθ* ด้วย อุณหภูมิสำหรับประเมิน Teval และการตั้งค่า truncation ρeval

3. การทดลอง

  • การตั้งค่าโมเดล

    • ใช้ 5 โมเดล ได้แก่ Llama-3.1-8B-Instruct, Qwen3-4B/30B (Instruct, Thinking) เป็นต้น
    • ครอบคลุม 2 ตระกูล (Llama, Qwen), 3 ขนาด (4B, 8B, 30B), และ 2 สไตล์การให้เหตุผล (Instruct, Thinking)

  • ข้อมูล

    • ใช้โจทย์ competitive programming ราว 10K ข้อจากชุดข้อมูล rSTARcoder
    • ใช้เพียงการกรองไวยากรณ์อย่างง่าย โดยไม่ตรวจสอบคำตอบ

  • การตั้งค่าการฝึก

    • อิงบน Megatron-LM ใช้ GPU 8×B200
    • ใช้ตัวเพิ่มประสิทธิภาพ AdamW, ความยาวลำดับสูงสุด 65,536
    • โมเดล Instruct ฝึก 2,500 step, โมเดล Thinking ฝึก 300 step

  • การประเมิน

    • ใช้ LiveCodeBench v6 (LCB v6) เป็นเบนช์มาร์กหลัก
    • ประเมินแบบแยกย่อยด้วย pass@1, pass@5 และตามระดับความยาก (Easy/Medium/Hard)

4. ผลลัพธ์สำคัญ

  • ประสิทธิภาพโดยรวมดีขึ้น

    • Qwen3-30B-Instruct: 42.4% → 55.3% pass@1 (+12.9pp)
    • Qwen3-4B-Instruct: +7.5pp, Llama-8B: +3.5pp
    • โมเดล Thinking ก็ดีขึ้น +2~3pp เช่นกัน

  • การปรับปรุงตามระดับความยาก

    • Qwen3-30B-Instruct: Easy +6.5pp / Medium +14.2pp / Hard +15.3pp
    • โมเดล Thinking ก็ปรับดีขึ้นมากที่สุดในช่วง Hard เช่นกัน

  • การคงความหลากหลาย

    • การเพิ่มขึ้นของ pass@5 มากกว่า pass@1 → คงและเพิ่มความหลากหลายในการสร้างได้
    • ตัวอย่าง: Qwen3-30B-Instruct pass@5 +18.1pp (Hard +23.0pp)

  • การทั่วไปข้ามโดเมน

    • นอกเหนือจาก competitive programming ยัง คงประสิทธิภาพได้ ในงานคณิตศาสตร์ โค้ดทั่วไป และงานด้านความเข้าใจ

5. การเปรียบเทียบนโยบายการถอดรหัส

  • การปรับอุณหภูมิอย่างเดียวไม่สามารถทำซ้ำผลของ SSD ได้

    • ผลการไล่ค่าอุณหภูมิของโมเดลฐาน: การเปลี่ยนแปลงของ pass@1 อยู่ราว 1.5–3.0pp
    • แต่ SSD ทำให้ดีขึ้นถึง +11.8pp ภายใต้เงื่อนไขเดียวกัน (Qwen3-30B-Instruct)
    • โดยเฉพาะใน โจทย์ Hard และ pass@5 ช่องว่างยิ่งชัดเจนที่สุด
    • SSD เปลี่ยนการกระจายภายในของโมเดลเอง จึงไม่สามารถแทนที่ได้ด้วยการปรับการถอดรหัสอย่างเดียว

6. ปฏิสัมพันธ์ของไฮเปอร์พารามิเตอร์

  • อุณหภูมิระหว่างฝึก (Ttrain) และ อุณหภูมิระหว่างประเมิน (Teval) มีผลต่อประสิทธิภาพผ่านผลคูณ Teff = Ttrain × Teval
    • ประสิทธิภาพดีที่สุดอยู่แถว ๆ Teff ≈ 1.2
    • ยิ่ง Ttrain สูง ก็ยิ่งไวต่อการเปลี่ยนแปลงของ Teval
  • เมื่อเพิ่ม truncation จะช่วยยกระดับเพดานประสิทธิภาพ
    • ค่าที่เหมาะที่สุด: Ttrain=2.0, Teval=1.1, top-k=10 → pass@1 49.7% (+7.3pp)
    • truncation ให้การปรับปรุงเพิ่มขึ้นผ่านการตัดส่วนหางที่มีความน่าจะเป็นต่ำออก

7. กลไกการทำงานของ SSD

  • ความขัดแย้งระหว่างความแม่นยำกับการสำรวจ (Precision–Exploration)

    • Lock: ตำแหน่งที่คำตอบเชิงไวยากรณ์แทบจะตายตัว → ต้องใช้อุณหภูมิต่ำ
    • Fork: ตำแหน่งที่มีวิธีแก้ได้หลายแบบ → ต้องใช้อุณหภูมิสูง
    • การใช้อุณหภูมิเดียวทำให้ตอบโจทย์ทั้งสองแบบพร้อมกันได้ยาก

  • บทบาทของ SSD

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

8. การตรวจสอบเชิงทดลอง

  • การทดลองในสภาพแวดล้อมจำลอง

    • ใช้สภาพแวดล้อมอย่างง่ายที่มีโครงสร้าง Fork 1 ครั้ง + Lock 3 ครั้ง แล้วนำ SSD ไปใช้
    • หลังใช้ SSD ความน่าจะเป็นของความสำเร็จเพิ่มขึ้น และช่วงอุณหภูมิที่เหมาะสมก็กว้างขึ้น
    • ยืนยันได้ว่าการฝึกและการถอดรหัสนั้น เกื้อหนุนกัน

  • การวิเคราะห์โมเดลจริง

    • หลังใช้ SSD พบว่า ความน่าจะเป็นสะสมของโทเคนชั้นบนเพิ่มขึ้น และความน่าจะเป็นส่วนหางลดลง
    • แม้ที่ Teval สูง ก็ยังพบว่า จำนวนตัวเลือกชั้นบนที่ใช้ได้จริงเพิ่มขึ้น และ entropy สูงขึ้น
    • กล่าวคือ SSD สามารถ ตัดส่วนหางออกและขยายการกระจายของตัวเลือกชั้นบนได้พร้อมกัน

9. การวิเคราะห์เชิงทฤษฎี

  • loss ระหว่างการฝึกของ SSD สามารถแยกออกเป็น 3 องค์ประกอบ
    1. Support Compression: ตัดความน่าจะเป็นส่วนหางออก
    2. Within-Support Reshaping: ปรับโครงสร้างการกระจายในส่วนของตัวเลือกหลัก
    3. Alignment to Base Model: คงการจัดแนวกับโมเดลเดิมไว้
  • ใน Lock องค์ประกอบแรกมีอิทธิพลเด่น → ตัดส่วนหาง
  • ใน Fork องค์ประกอบที่สองทำงาน → ทำให้การกระจายของตัวเลือกหลักแบนลง
  • entropy โดยรวมลดลง แต่ entropy ของการสำรวจที่มีประโยชน์ยังคงอยู่
  • การปรับการถอดรหัสแบบง่าย ๆ ไม่สามารถทำการปรับโครงสร้างตามบริบทเช่นนี้ได้

10. การทดลองกับข้อมูลผิดปกติ

  • ในกรณี Ttrain=2.0, ไม่มี truncation ข้อมูลที่สร้างขึ้น 62% เป็น สัญญาณรบกวนไร้ความหมาย (gibberish)
  • ถึงอย่างนั้น หลังใช้ SSD ก็ยังพบว่า
    • pass@1: 42.4% → 48.1% (+5.7pp)
    • pass@5: 53.5% → 64.0% (+10.5pp)
    • โจทย์ Hard ดีขึ้น +7.3pp / +13.8pp
  • สิ่งนี้แสดงให้เห็นว่า SSD สามารถนำไปสู่การปรับปรุงได้ผ่าน การเรียนรู้โครงสร้างของการกระจาย ไม่ใช่เพียงคุณภาพความถูกต้องของคำตอบ

บทสรุป

  • Simple Self-Distillation (SSD)
    • ยกระดับประสิทธิภาพการสร้างโค้ดได้ด้วย ผลลัพธ์ที่โมเดลสร้างเอง โดยไม่ต้องมีโมเดลครูภายนอกหรือการตรวจสอบ
    • บรรเทาความขัดแย้งระหว่างความแม่นยำกับการสำรวจ และทำให้เกิดการปรับปรุงที่ทั่วไปได้ผ่าน การปรับโครงสร้างการกระจาย
  • SSD เป็นวิธีที่เรียบง่ายแต่ทรงพลังซึ่งนำไปใช้ได้ในขั้น post-training และเสนอ ทางเลือกที่ใช้งานได้จริงในการยกระดับคุณภาพการสร้างโค้ดของ LLM

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 26 일 전
ความคิดเห็นจาก Hacker News

  • เหตุผลที่งานวิจัยนี้น่าสนใจคือมันนำแนวคิด context-aware decoding มาทำให้เกิดขึ้นจริง
    มันอธิบายว่าในกระบวนการสร้างโค้ด จะมีจุด ‘fork’ (จุดแตกแขนงเชิงสร้างสรรค์ที่ตีความได้หลายแบบ) และจุด ‘lock’ (การตัดสินใจเชิงไวยากรณ์ที่ต้องการความถูกต้อง) สลับกันไป
    สิ่งที่น่าประทับใจคือเทคนิค SSD (Simple Self-Distillation) ช่วยปรับอันดับโทเคนที่เหมาะสมที่สุดให้ดีขึ้นในทั้งสองสถานการณ์ ทำให้โมเดลทำงานได้ สร้างสรรค์ มากขึ้นตอนที่ต้องสำรวจ และ แม่นยำ มากขึ้นตอนที่ต้องถูกต้อง

    • จริง ๆ แล้วการ ค้นพบคุณสมบัติใหม่ของ LLM แบบนี้รู้สึกว่าเป็นเรื่องปกติมากกว่าน่าประหลาดใจ
      แม้แต่สมองมนุษย์เองก็ถูกศึกษามาหลายพันปี แต่ก็ยังมีส่วนที่เข้าใจไม่ได้อีกมาก
      แม้กระทั่ง emergent behavior ของการไหลของการจราจร เองก็เพิ่งเริ่มเข้าใจกันชัดเจนไม่นานนี้
      ดังนั้นการค้นพบคุณสมบัติใหม่ของ LLM อย่างต่อเนื่องจึงเป็นเรื่องธรรมชาติ
    • สิ่งที่น่าสนใจคือโครงสร้างของโมเดลใช้ปริมาณการคำนวณเท่ากันกับทั้งโทเคน ‘fork’ และ ‘lock’
      ถ้าใช้การสุ่มตัวอย่างตามไวยากรณ์หรือ grammar-aware decoding ก็สามารถแทรกโทเคนที่มีได้เพียงตัวเดียวตามหลักไวยากรณ์เข้าไปตรง ๆ โดยไม่ต้องเรียกโมเดลเลยก็ได้
      แต่ในระบบที่ใช้งานกันแพร่หลายในปัจจุบันกลับแทบไม่ถูกนำมาใช้
      เลยสงสัยว่าจะมีแนวทางแบบทั่วไปที่ใช้ การคำนวณมากขึ้นกับตัวเลือกสำคัญ และใช้น้อยลงกับโทเคนที่ชัดเจนอยู่แล้วได้หรือไม่
    • ตอนฟाइनจูนโมเดลขนาดเล็ก ฉันเคยเจอปัญหา mode collapse แต่พอสุ่มสลับลำดับฟิลด์ระหว่างการฝึกก็แก้ได้
      ตอนนี้กำลังคิดอยู่ว่าควรใช้วิธีเดียวกันตอนอนุมานด้วยหรือไม่
    • สิ่งที่น่าสนใจคือ SSD ได้ผลแม้จะ ไม่ต้องปรับ temperature แบบเรียลไทม์หรือคาดเดาจุด fork/lock ก็ตาม
    • แนวคิดนี้ใช้ได้ไม่ใช่แค่กับโค้ด แต่กับ คอนเทนต์เชิงสร้างสรรค์ประเภทอื่นโดยรวม ด้วย
      ในโค้ดเพียงแค่โครงสร้างชัดเจนกว่า แต่กลไก fork/lock ใช้ได้กับโดเมนปัญหาหลากหลาย

  • Self-Distillation ดูเหมือนจะเป็นทิศทางหลักของการพัฒนา LLM
    งานวิจัย Self-Distillation Fine-Tuning(SDFT) จากทีม MIT และ ETH ก็แสดงให้เห็นประสิทธิภาพสูงไว้แล้ว
    SSD (Simple Self-Distillation) ในงานนี้จริง ๆ ก็แทบจะเป็นภาคต่อของแนวทางนั้น ต่างกันแค่ชื่อ
    การใช้ชื่อ SSD ยังทำให้งงได้ เพราะไปซ้ำกับ SSD (solid-state drive)
    อยากให้มีการ ยอมรับที่มาและสายสืบทอดของแนวคิด จากงาน SDFT ต้นฉบับให้ชัดกว่านี้

  • ไม่นานมานี้ฉันเห็นวิดีโอที่รัน Gemma 4 บนเครื่องโลคัลได้ที่ความเร็ว 50 โทเคนต่อวินาที
    มันแสดงความสามารถได้ในระดับ Sonnet 3x~4 แล้ว
    ถ้าเสริมด้วยเทคนิคอย่าง SSD เข้าไปอีก ก็ดูเหมือนว่าภายในปี 2028 โมเดลโค้ดที่ถูกและทรงพลัง จะกลายเป็นของแพร่หลาย
    นักพัฒนาที่ชำนาญมีแนวโน้มจะรันโมเดลของตัวเองในฐานะ ทรานสไพเลอร์แบบไม่กำหนดแน่ชัด ที่แปลงภาษาธรรมชาติเป็นโค้ด

    • ฉันก็คิดแบบนั้นอยู่บ่อย ๆ ถ้าเทรนโมเดลด้วยแค่เวอร์ชันล่าสุดของภาษาที่ฉันใช้ (PHP, SQL, JS ฯลฯ) มันอาจได้ โมเดลที่เล็กกว่าและเร็วกว่า มากหรือเปล่า
      ตอนนี้มันให้ความรู้สึกเหมือน ‘สร้างบ้านบนตะปู’
    • แน่นอนว่าพอถึงตอนนั้น โมเดล frontier ที่มีหน่วยความจำรายโปรเจกต์และการเรียนรู้แบบ on-demand อาจเหนือกว่าโมเดลส่วนตัวไปเลยก็ได้

  • สมมติฐานหลักของ SSD เรื่อง ความขัดแย้งระหว่าง precision–exploration คล้ายกับปัญหาที่ Adaptive Decoding พยายามแก้

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

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

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

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

  • ความก้าวหน้าครั้งใหญ่ในแมชชีนเลิร์นนิงมักดูเรียบง่ายเมื่อมองจากภายนอก
    Transformer ก็เป็นแบบนั้น และ SSD ครั้งนี้ก็เช่นกัน
    อาจเป็นเพราะเรายังไม่มี รากฐานทางทฤษฎีที่ลึกพอ

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

  • เป็นเรื่องน่าขันที่ Apple ยังคงเผยแพร่งานวิจัย AI ขณะที่ OpenAI ไม่ทำแบบนั้น

    • ฉันก็รู้สึกว่าเรื่องนั้นแปลกเหมือนกัน ดูไม่มีเหตุผลอะไรที่จะต้องปิดไว้
    • บางทีอาจเป็นเพราะ OpenAI ยัง ไม่มี ‘ตลาด’ ที่ต้องปกป้อง ก็ได้

  • มีคนหนึ่งสรุปงานวิจัยนี้ว่าเป็น “โมเดลที่ฟाइनจูนมาเพื่อให้ทำผลลัพธ์บนโค้ด benchmark ได้ดี” แต่จริง ๆ แล้วไม่ใช่แบบนั้น

    • ถ้าอ่านงานจะเห็นว่า ไม่มีการตรวจคำตอบหรือประเมินคุณภาพเลย เพียงแค่ป้อนอินพุต benchmark แล้วนำเอาผลลัพธ์ที่ออกมากลับไปใช้ฝึกซ้ำเท่านั้น
      หลังจากนั้นโมเดลที่ปรับ การตั้งค่าการถอดรหัส (temp, top-k) ก็ให้ผลลัพธ์ดีกว่าต้นฉบับ
      กล่าวคือมันไม่ใช่แค่การฟাইনจูนให้เข้ากับ benchmark แต่เป็น การเพิ่มประสิทธิภาพจากผลลัพธ์ของตัวเอง

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