หากขอให้ LLM "เขียนโค้ดที่ดีกว่า" ซ้ำ ๆ จะช่วยให้ได้โค้ดที่ดีกว่าไหม?

 (minimaxir.com)
8 คะแนน โดย GN⁺ 2025-01-04 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็นการทดลองว่าการขอให้ LLM สั่งว่า “เขียนโค้ดให้ดีขึ้น” ซ้ำ ๆ จะทำให้โค้ดดีขึ้นได้จริงหรือไม่
  • กรณีต้นแบบได้รับแรงบันดาลใจจากมีมในฟีเจอร์สร้างภาพ DALL-E ของ ChatGPT ที่คำสั่งแบบ “ทำให้ดู ... มากขึ้น”

การทดลองพรอมต์แบบซ้ำแบบธรรมดา

  • ใช้ Claude 3.5 Sonnet พร้อมพรอมต์การเขียน Python ให้แก้ปัญหาที่ค่อนข้างเรียบง่ายแต่สามารถปรับให้มีประสิทธิภาพได้
  • การนำไปใช้แบบต้นแบบ
    • ค้นหาค่าความต่างระหว่างค่าน้อยสุดและค่าสูงสุดของตัวเลขที่มีผลรวมหลัก (digit sum) เท่ากับ 30 จากตัวเลขสุ่มหนึ่งล้านค่าระหว่าง 1 ถึง 100,000
    • แบบแก้ไขแบบตรงไปตรงมาใช้เวลา 657ms (ใช้วิธีแปลงด้วย str ของ Python)
  • Iteration #1
    • ขอให้ Claude “เขียนโค้ดให้ดีขึ้น” เพื่อปรับปรุงโค้ด
    • Claude ปรับโครงสร้างโค้ดใหม่เป็นคลาส Python และทำให้เป็นเชิงวัตถุ พร้อมคำนวณ digit sum ของตัวเลขทั้งหมดไว้ล่วงหน้า
    • เร็วขึ้น 2.7 เท่า
  • Iteration #2
    • Claude ใช้การทำงานแบบมัลติเธรดและการคำนวณแบบเวกเตอร์ด้วย numpy เพื่อปรับแต่งโค้ดมากขึ้น
    • เร็วขึ้น 5.1 เท่า
  • Iteration #3
    • โค้ดกลับซับซ้อนขึ้นและเกิดการถอยกลับไปใช้การแปลงเป็นสตริง
    • เร็วขึ้น 4.1 เท่า
  • Iteration #4
    • ใช้ไลบรารี Python อย่าง numba เพื่อเรียกตัวคอมไพล์ JIT และใช้ asyncio ของ Python เพื่อทำงานขนาน
    • เร็วขึ้นได้ถึง 100 เท่า
    • แทนที่จะกลายเป็นโค้ดระดับจักรวาล โค้ดกลับกลายเป็นเวอร์ชันโอเวอร์เอนจิเนียริ่งแบบ "เอ็นเตอร์ไพรส์"

การนำ Prompt Engineering ไปใช้

  • จำเป็นต้องใช้ prompt engineering เพื่อเพิ่มคุณภาพผลลัพธ์ของ LLM
  • Claude 3.5 Sonnet มีความสามารถในการปฏิบัติตามพรอมต์ได้ดีมาก หากให้คำสั่งที่ชัดเจนก็สามารถได้ผลลัพธ์ที่ดีกว่า
  • ใช้ system prompt ที่ใส่คำแนะนำละเอียดแทนการสั่งเพียง “เขียนโค้ดให้ดีขึ้น”
  • พรอมต์เริ่มต้น
    • กำหนดนิยามของ “โค้ดที่ทำให้เหมาะสม” อย่างละเอียด (อัลกอริทึม การขนาน การลดโค้ดที่ไม่จำเป็น ฯลฯ)
    • เริ่มจากการปรับแต่ง digit sum ด้วย Numba ในการนำไปใช้แรก เร็วขึ้น 59 เท่า
  • Iteration #1
    • Claude เพิ่มการขนาน แต่กลับแนะนำให้ใช้การเลื่อนบิตแบบผิดพลาด (สำหรับเลขฐานสิบหก) จนเกิดบั๊ก
    • ประสิทธิภาพกลับลดลงเหลือ 9.1 เท่า
  • Iteration #2
    • Claude พยายามเร่งด้วย SIMD แต่ยังคงใช้การเลื่อนบิตที่ผิด
    • เร็วกว่าเวอร์ชันเริ่มต้น 65 เท่า
  • Iteration #3
    • Claude ใช้ hash table เพื่อเพิ่มประสิทธิภาพ
    • เร็วกว่าเวอร์ชันเริ่มต้น 100 เท่า
  • Iteration #3
    • Claude แก้ไขการเลื่อนบิตที่ผิดทำให้ประสิทธิภาพลดลงเล็กน้อย
    • เร็วกว่าเวอร์ชันเริ่มต้น 95 เท่า

บทสรุป

  • แม้เพียงพรอมต์ที่กว้างและคลุมเครืออย่าง “โค้ดที่ดีขึ้น” ก็ยังอาจช่วยให้เกิดการปรับปรุงแบบขั้นเป็นขั้นไป
  • หากผ่าน prompt engineering ระบุทิศทางที่ต้องการอย่างชัดเจน (เช่น ตัวเลข, JIT, การขนาน ฯลฯ) จะได้โค้ดที่พัฒนายิ่งขึ้นได้เร็วขึ้น
  • แนวคิดการปรับแต่งอัตโนมัติอาจเป็นจุดเริ่มต้นในการค้นพบเครื่องมือใหม่ (เช่น numba) ได้ แต่ผู้วิศวกรยังจำเป็นต้องคัดกรองและใช้อย่างเลือกสรรโดยคำนึงถึงบั๊ก
  • ในระบบที่ใช้งานจริง ไม่ควรคัดลอกโค้ดที่ LLM เสนอทั้งหมดมาใช้ดิบ ๆ เนื่องจากมีข้อจำกัดเฉพาะโดเมนและความจำเป็นในการยืนยันความถูกต้องสูง
  • การทดลองนี้ยึดพื้นฐานโค้ด Python แต่แนวคิดการปรับแต่งของ LLM ก็ยังมีศักยภาพที่จะใช้ได้กับการผสมผสานกับภาษาอื่น เช่น Rust ผ่านทาง PyO3

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

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

 
GN⁺ 2025-01-04
ความคิดเห็นจาก Hacker News

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

  • LLM อย่าง GPT มักให้ผลลัพธ์ระดับกลางในช่วงแรก ๆ และมีการอ้างว่าอาจได้ผลลัพธ์ที่ดีกว่าโดยให้คำแนะนำที่เฉพาะเจาะจง

  • LLM เป็นเหมือนเครื่องจำลองสถานการณ์ตามบริบทที่จำลองแบบจำลองโลกจริงผ่านการคาดเดาข้อความ ความแม่นยำในการคาดเดาข้อความต้องอาศัยแบบจำลองโลกจริงที่แม่นยำ

  • LLM มักโน้มเอียงไปทางการเขียนโค้ดแบบผู้เริ่มต้น และการระบุแพ็กเกจและขอเฉพาะโค้ดแบบง่ายจะได้ผล

  • ChatGPT ใน Android/Kotlin มีความไม่มีประสิทธิภาพและมักเรียกใช้เมธอดที่ไม่ถูกต้องหรือเลิกใช้งานแล้วบ่อยครั้ง

  • สิ่งสำคัญคือการเริ่มเซสชันการเขียนโค้ดด้วย "แผนเปิด" แทนคำสั่ง "เขียนโค้ด" ควรชี้แจงสมมติฐานของ LLM อย่างชัดเจนและปรับแผนก่อนที่คุณจะเริ่มเขียนโค้ด

  • อธิบายการลบ PostgreSQL ออกจาก Debian อย่างสมบูรณ์แล้วติดตั้งใหม่ โดยคงไดเรกทอรีข้อมูลเดิมไว้เพื่อรักษาฐานข้อมูลเดิมไว้

  • การเพิ่มประสิทธิภาพโค้ดอาจไม่ดีหากทำเร็วเกินไป ควรทำการเพิ่มประสิทธิภาพเฉพาะเมื่อต้องการเท่านั้น

  • การขอให้ "เขียนโค้ดให้ดีกว่า" ซ้ำไปซ้ำมาอาจทำให้ประสิทธิภาพลดลง และอาจทำให้โซลูชันใช้งานไม่ได้

  • การคำนวณใน LiveCode เร็วกว่า Python และอธิบายวิธีคำนวณผลรวมด้วยการวนซ้ำ