ภาพหลอนที่เกิดขึ้นในโค้ดเป็นรูปแบบของข้อผิดพลาดจาก LLM ที่อันตรายน้อยที่สุด

• นักพัฒนาจำนวนมากพยายามใช้ LLM เขียนโค้ดแล้ว เจออาการภาพหลอน (Hallucination) จนหมดความเชื่อมั่น
  • เป็นเรื่องปกติที่ LLM จะสร้างเมธอดหรือไลบรารีที่ไม่มีอยู่จริงขึ้นมา
  • แต่ภาพหลอนในโค้ดเป็น ภาพหลอนประเภทที่อันตรายน้อยที่สุด
• สิ่งที่อันตรายที่สุดคือกรณีที่ LLM สร้างข้อผิดพลาดขึ้นมา แต่คอมไพเลอร์หรืออินเทอร์พรีเตอร์ไม่สามารถตรวจจับได้ทันที
  • เมธอดที่ถูกสร้างขึ้นมาหลอกๆ มักทำให้เกิดข้อผิดพลาดทันทีเมื่อรัน จึงตรวจพบได้ง่าย
  • และยังสามารถนำข้อความ error ป้อนกลับเข้า LLM เพื่อให้แก้ไขอัตโนมัติได้
• ต่างจากภาพหลอนในข้อความทั่วไป โค้ดนั้น ตรวจสอบข้อเท็จจริงได้ด้วยการรันจริง
• LLM ที่มีความสามารถแก้ข้อผิดพลาดอัตโนมัติ
  • เครื่องมืออย่าง ChatGPT Code Interpreter, Claude Code สามารถรันโค้ดที่ LLM เขียน ตรวจจับข้อผิดพลาด และแก้ไขด้วยตัวเองได้
  • การประเมินโค้ดที่ LLM เขียนโดยไม่ลองรันก่อนเป็นเรื่องไม่มีประสิทธิภาพ
• นักพัฒนาบางคนพยายามปฏิเสธเทคโนโลยีนี้ไปเลย เพียงเพราะ LLM สร้างเมธอดหลอนขึ้นมา
  • แต่หากต้องการใช้งานให้มีประสิทธิภาพ การเรียนรู้และการทดลองเป็นสิ่งจำเป็น
  • ผู้เขียนศึกษาการเขียนโค้ดด้วย AI มานานกว่า 2 ปี และยังคงเรียนรู้เทคนิคใหม่ๆ อยู่เสมอ
• การทดสอบโค้ดด้วยตนเองยังจำเป็น
  • แค่โค้ดรันได้ ไม่ได้แปลว่าจะทำงานตรงตามที่คาดหวัง
  • การรีวิวโค้ดหรือการทดสอบอัตโนมัติเพียงอย่างเดียว ไม่สามารถยืนยันความถูกต้องของโค้ดได้ทั้งหมด
  • กระบวนการรันและตรวจสอบด้วยตนเองเป็นสิ่งจำเป็น
  • โค้ดที่ LLM สร้างมักอ่านง่ายมาก จนอาจทำให้เผลอไว้ใจเกินไป
  • โค้ดที่มนุษย์เขียนก็เช่นกัน ไม่ควรเชื่อถือจนกว่าจะได้ลองรันด้วยตัวเอง
• วิธีลดภาพหลอน
  • ใช้โมเดลอื่น: เลือกโมเดลที่มีข้อมูลฝึกเกี่ยวกับแพลตฟอร์มเฉพาะนั้นมากกว่า
    • เช่น Claude 3.7 Sonnet (เปิด thinking mode), OpenAI o3-mini-high, GPT-4o (พร้อม Python Code Interpreter)
  • ใช้บริบท (context): ถึง LLM จะไม่รู้จักไลบรารีบางตัว แต่หากให้โค้ดตัวอย่าง ก็สามารถเรียนรู้รูปแบบได้
    • ช่วงหลังพบว่าได้ผลดีเมื่อใช้ ความสามารถเชื่อมต่อ GitHub ของ Claude
  • เลือกเทคโนโลยีที่เสถียร: หากเลือกใช้ไลบรารีเก่าและมั่นคง LLM มักมีแนวโน้มจะจัดการได้ดีกว่า
    • ใช้แนวคิด Boring Technology
• ความสำคัญของการรีวิวโค้ด
  • ผู้เขียนโต้แย้งคำกล่าวที่ว่า "ถ้าต้องรีวิวโค้ดที่ LLM เขียนทั้งหมด การเขียนเองยังเร็วกว่า"
  • คำพูดนี้อาจสะท้อนถึงการขาดทักษะในการรีวิวโค้ด
  • การรีวิวโค้ดที่ LLM สร้างอาจเป็นโอกาสที่ดีในการพัฒนาฝีมือ
• โบนัส: ฟีดแบ็กจาก Claude 3.7 Sonnet
  • ผู้เขียนขอให้ Claude 3.7 Sonnet ใน "extended thinking mode" ช่วยตรวจร่างบทความบล็อก
  • โดยขอให้ช่วยดูว่า "ตรรกะของบทความนี้น่าเชื่อถือหรือไม่ มีจุดไหนที่ควรปรับปรุง หรือมีอะไรตกหล่นหรือไม่"
  • Claude ช่วยปรับโทนของร่างบทความให้นุ่มนวลขึ้น
  • ลิงก์บทสนทนาฟีดแบ็กจาก Claude

[GN⁺]

ความคิดเห็นจาก Hacker News

• ผู้เขียนเห็นด้วยกับบทความก่อนหน้า แต่ไม่เห็นด้วยกับบทความนี้

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

• ต่อให้โค้ดที่ LLM สร้างจะทำงานได้ดี คนที่ไม่ได้เป็นผู้เขียนก็ยังหาบั๊กหรือข้อบกพร่องเชิงตรรกะได้ยาก

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

• โค้ดที่ LLM สร้างดูสะอาด แต่กลับทำให้ต้องใช้เวลากับ QA และการเก็บงานมากขึ้น

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

• The Primeagen และ Casey Muratori ตรวจดูผลลัพธ์จากเครื่องมือสร้างโค้ด LLM รุ่นล่าสุด

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

• อีกหมวดของความผิดพลาดที่ Simon มองข้ามไป คืออาการหลอนที่ทำให้โมเดลลืมฟังก์ชันบางอย่าง

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

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

  • แต่นี่เป็นสมมติฐานที่ผิดมาก และคนจำนวนมากเห็นอาการหลอนแล้วคิดว่า "ถ้าเรื่องง่ายที่สุดยังทำให้ถูกอย่างสม่ำเสมอไม่ได้ ก็ยิ่งเชื่อใจเรื่องที่ยากกว่านี้ไม่ได้"

• อาการหลอนเองไม่ใช่ความเสี่ยงที่ใหญ่ที่สุดที่ LLM ก่อขึ้น

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

• ถือว่าอันตรายน้อยกว่าเฉพาะในบริบทจำกัดของ error ตอนคอมไพล์เท่านั้น

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

• การจะได้ผลลัพธ์ที่ดีจาก LLM ต้องใช้ความพยายามมาก

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

• ประสบการณ์การเขียนโค้ดเพื่อหา 'คลินิกหลัก' ของผู้ป่วยในศูนย์การแพทย์

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