ความรู้สึกในการทำงานกับ Mythos เป็นแบบนี้
(oneusefulthing.org)- Claude 5 Fable ระดับ Mythos รุ่นแรกที่เปิดให้ใช้งานสาธารณะ สามารถรับสเปกหลายขั้นตอนและทำงานด้วยตัวเองได้นานสูงสุดกว่าสิบชั่วโมง พร้อมทำผลงานเหนือกว่าทุกรุ่นที่เคยลองใช้ก่อนหน้านี้อย่างชัดเจน
- ด้วยพรอมป์เดียวและฟีดแบ็กเพียงครั้งเดียว ก็สามารถสร้างได้ทั้งบทความวิชาการด้านสังคมศาสตร์ที่ประณีต และบทกวีสัมผัสยาว 10 หน้า ที่ทุกคำขึ้นต้นด้วยตัวอักษร s
- ระหว่างทำงานยังเรียกใช้ AI ตัวอื่นโดยตรง (ส่วนใหญ่เป็น Claude Sonnet ที่ต้นทุนต่ำกว่า) เพื่อแบ่งงานค้นคว้า เขียนโค้ด และตรวจสอบ พร้อมรวบรวมข้อมูลเที่ยวบินและตารางรถไฟมากกว่า 2,200 รายการ รวมถึงข้อมูลความเร็วถนนของแต่ละประเทศ
- บทบาทของผู้ใช้ถูกย่อลงเหลือการสั่งงานและตัดสินผลลัพธ์ ขณะที่กระบวนการตัดสินใจของโมเดลไม่ถูกเปิดเผย ทำให้มันทำงานเสมือนเป็นกล่องดำขั้นสุด
- ความสัมพันธ์กับ AI กำลังเปลี่ยนจากการเป็น 'พ่อมด' ที่ลงมือทำเอง มาเป็น**'ผู้ว่าจ้าง (patron)'** ที่มอบหมายงานและตัดสินผลงาน และยิ่งความสามารถของโมเดลสูงขึ้น มนุษย์ก็อาจยิ่งมีพื้นที่ให้แทรกแซงน้อยลง
ประสิทธิภาพและประสบการณ์ใช้งาน Claude 5 Fable - Ethan Mollick
- ได้มีโอกาสลองใช้งาน Claude 5 Fable ล่วงหน้า (Early Access) ซึ่งเป็นโมเดล AI ระดับ Mythos รุ่นแรกที่เปิดสู่สาธารณะ
- Claude 5 Fable เป็นโมเดล AI ระดับ Mythos ตัวแรกที่เปิดตัวสู่สาธารณะ แม้จะมีการพูดถึงผลกระทบด้านความปลอดภัยซอฟต์แวร์มาก แต่การทดสอบครั้งนี้ไม่ได้ครอบคลุมด้านนั้น
- guardrail ของ Fable ทำงานเข้มงวดถึงระดับที่แทบไม่สามารถนำไปใช้ด้านไซเบอร์ซีเคียวริตี้ได้เลย
- ในหลายการทดลอง Fable แสดงประสิทธิภาพสูงกว่าแทบทุกรุ่นสาธารณะที่เคยใช้อย่างเห็นได้ชัด
- Fable แสดงความสามารถในหลายโจทย์ และสามารถทำงานต่อเนื่องจากสเปกหลายหน้าได้นานราว 12 ชั่วโมง
ประสิทธิภาพและผลลัพธ์ของ Fable
- ในทุกการทดลองที่ทำ มันเหนือกว่าโมเดลสาธารณะอื่น ๆ แบบทิ้งห่าง และยืนยันได้ว่าประสิทธิภาพโดยรวมดีขึ้นในทุกประเภทงาน
- ด้วยพรอมป์เดียวและการให้ฟีดแบ็กเพียงหนึ่งครั้ง มันสร้าง บทความวิชาการด้านสังคมศาสตร์ ที่ประณีตที่สุดเท่าที่เคยเห็นจาก AI
- รวมถึง บทกวีสัมผัสยาว 10 หน้าเกี่ยวกับการตัดผม ที่ทุกคำขึ้นต้นด้วยตัวอักษร s
- ใน Claude Code เพียงให้พรอมป์เริ่มต้นที่คลุมเครือและฟีดแบ็กเพิ่มเล็กน้อยอย่าง "make it better" ก็สามารถสร้างเกมที่เล่นได้
- เกมโยนเหรียญ เริ่มจากพรอมป์ว่า “Balatro, but for the game of coin flips”
- เกมงูที่มีการตระหนักรู้ในตัวเอง เป็นโครงสร้างที่งูรับรู้ตัวเองและมีเรื่องแปลก ๆ เกิดขึ้น
- เกมที่ค่อย ๆ ลงไปสู่ความลึก เป็นโครงสร้างที่ผู้เล่นลงไปด้านล่างเพื่อดูว่ามีอะไรอยู่บ้าง
- เนื่องจาก Claude สร้างภาพไม่ได้ งานศิลป์และวัตถุ 3D ทั้งหมดจึงถูกสร้างขึ้นด้วยการคำนวณทางคณิตศาสตร์ล้วน ๆ โดยไม่ใช้งาน asset ภายนอก
- ยิ่งเป็นงานจริงจังมากขึ้น ประสบการณ์การใช้เครื่องมือนี้ยิ่งอยู่กึ่งกลางระหว่างความสนุกกับความไม่สบายใจ — เพราะเมื่อขออะไรไป มันก็ทำสิ่งนั้นออกมาจริง ๆ
Maps and Methods — กรณีศึกษาการสร้างแผนที่ isochrone
- แผนที่ isochrone คือแผนที่ที่แสดงระยะทางซึ่งสามารถเดินทางได้ภายในเวลาที่กำหนด โดยตัวอย่างแรกถูกสร้างขึ้นในปี 1881 เพื่อแสดงเวลาเดินทางจากลอนดอน
- โมเดลก่อนหน้านี้ไม่สามารถสร้างแผนที่ประเภทนี้ให้ใช้งานได้ดีพอแม้เพียงครึ่งเดียว เพราะต้องสำรวจระยะทางการเดินทางที่เป็นไปได้หลายพันจุดและต้องใช้การตัดสินใจย่อยจำนวนมาก
-
วิธีดำเนินงาน
- ป้อนพรอมป์เพื่อขอแผนที่ดีไซน์เฉพาะตัว โดยเลือกเมืองและใช้ข้อมูลจริงที่สะท้อนสนามบิน รถไฟ การเดินเท้า และการขับรถ พร้อมกำชับว่าข้อมูลไม่จำเป็นต้องเป็นแบบเรียลไทม์ แต่ต้องเป็นข้อมูลจริงจากการค้นคว้า
- โมเดลเสนอเองก่อนว่าจะสร้างในสไตล์ต้นฉบับปี 1881 และเมื่อเห็นด้วยจึงเริ่มลงมือ
- ระหว่างเซสชัน build ที่กินเวลาหลายชั่วโมง มันรัน AI อื่นจำนวนมาก (ส่วนใหญ่เป็น Claude Sonnet ที่ต้นทุนต่ำกว่า) เพื่อค้นคว้าเวลาเดินทาง
- รวบรวมทั้งตารางรถไฟตั้งแต่ TGV ถึง Shinkansen, ความเร็วถนนของแต่ละประเทศจากงานวิชาการหลายชิ้น และข้อมูลเที่ยวบินเฉพาะเจาะจงมากกว่า 2,200 รายการ
- ระหว่างที่เอเจนต์วิจัยกำลังทำงาน ก็เริ่มเขียนโค้ดไปพร้อมกัน พร้อมรันเอเจนต์เพิ่มเติมและการทดสอบเพื่อตรวจสอบโค้ด และบันทึกความคืบหน้า
-
การแก้ข้อมูลพื้นที่ห่างไกลและการใช้โทเค็น
- พื้นที่ห่างไกลอย่าง Greenland มีเพียงค่าประมาณแทนตัวเลขจริง จึงสั่งให้แก้เพื่อให้ได้เวลาเดินทางจริง
- ครั้งนี้มีการใช้เวิร์กโฟลว์แบบกลุ่มเอเจนต์เชิงปฏิปักษ์ (adversarial groups) ที่ให้แต่ละฝ่ายค้นคว้าและตรวจสอบผลลัพธ์กันเอง
- คำนวณได้ทั้งความถี่เรือไปยัง Pitcairn Island ในแปซิฟิก และเส้นทางจาก Ottawa ไปยัง Grise Fjord
- ใช้โทเค็นจำนวนมหาศาลภายในเวลาอันสั้น
- สิ่งที่ผู้ใช้ทำมีเพียงการสั่งงานอย่างทะเยอทะยานและให้ฟีดแบ็กเล็กน้อย ส่วนการตัดสินใจย่อยนับร้อยครั้งเป็นสิ่งที่โมเดลทำเองทั้งหมด และไม่มีโอกาสให้เข้าใจหรือแทรกแซงการเลือกเหล่านั้น
- ไม่ได้จำกัดแค่ปริมาณงาน แต่ยังรวมถึงการควบคุมวิธีทำงาน วิธีเลือกแนวทาง และความลึกของผลลัพธ์ด้วย
- ผลลัพธ์ถูกเผยแพร่เป็น แผนที่ isochrone แบบคลิกได้ และสามารถดูวิธีการกับแหล่งที่มาที่ด้านล่างของกราฟได้
Working with a Mythos-class model — กรณีของ Concord
- โปรเจ็กต์ที่ทะเยอทะยานที่สุดคือโจทย์วิจัยในการจัดหมวดหมู่คำตอบที่ยุ่งเหยิงแบบที่มนุษย์สร้างขึ้นอย่างเหมาะสม — เช่น ไอเดียนั้นสร้างสรรค์แค่ไหน หรือทำไมผู้คนถึงชอบหนังสือบางเล่ม
- ก่อนหน้านี้นักวิจัยมนุษย์ต้องเป็นผู้ตัดสิน แล้วนำไปเทียบกับคำตอบอื่นและสถิติ เพื่อยืนยันความน่าเชื่อถือของข้อมูล
- การปรับเทียบ (calibration) ระหว่างการตัดสินของ AI กับมนุษย์ทำได้ยากและมีต้นทุนสูง
- จึงขอให้ Fable ช่วยแก้ปัญหานี้ โดยมันสร้าง เอกสารออกแบบซับซ้อนยาว 19 หน้า ขึ้นมาก่อน แล้วจึงลงมือทำงาน
- Fable ใช้เวลาทำงานกับสิ่งนี้นาน 9 ชั่วโมง 30 นาที
- ผลลัพธ์คือซอฟต์แวร์ที่ AI ตั้งชื่อว่า Concord ซึ่งรับหลายชุดข้อมูลเข้ามา ปรับเทียบคำตอบของมนุษย์และ AI และทำการวิเคราะห์ข้อมูลที่ซับซ้อน
- มันยังไม่สมบูรณ์ และในมุมมองของผู้เชี่ยวชาญพบข้อผิดพลาดและช่องตกหล่นบางส่วน (บางส่วนมีสาเหตุมาจากแบบออกแบบที่ร้องขอเอง) จึงสั่งให้แก้ไข
- ขอบเขตของสิ่งที่ส่งมอบนั้นเกินกว่าสิ่งใด ๆ ที่เคยเห็นมาก่อน และเป็นซอฟต์แวร์ที่นักวิจัยต้องการมาหลายปีแต่ไม่เคยมีใครสร้าง เพราะไม่คุ้มในเชิงรายได้
- บั๊กที่อาจยังเหลืออยู่สามารถให้วิศวกรซอฟต์แวร์แก้ต่อได้ และหากต้องรองรับการระเบิดของการใช้งานซอฟต์แวร์แบบใหม่ ก็อาจต้องการคนเขียนโค้ดมากขึ้นด้วย
- โค้ดของ Concord สามารถนำไปใช้หรือแก้ไขได้ใน GitHub repository
ข้อจำกัดและเงื่อนไข
- ความทรงพลังของ Fable มาพร้อมความแปลกใหม่และข้อจำกัด
-
ต้นทุนโทเค็น
- Fable แพงกว่า Opus 2 เท่า และต้นทุนระดับ production ก็ใช้โทเค็นอย่างรวดเร็วในระดับที่เรียกได้ว่า "มากพอสมควร (a lot)"
- แต่การมอบหมายงานอย่างชาญฉลาดไปยังโมเดลที่ถูกกว่าก็อาจช่วยลดต้นทุนจริงลงได้มาก
-
guardrail และสไตล์
- หากมีแม้เพียงสัญญาณเล็กน้อยของปัญหาด้านความปลอดภัย guardrail จะทำงานและสลับไปใช้ Claude 4.8 Opus ที่ประสิทธิภาพต่ำกว่า ซึ่งเกิดขึ้นบ่อยเกินไป
- การพูดถึง Mythos ส่วนใหญ่เน้นที่ผลกระทบด้านความปลอดภัยซอฟต์แวร์ แต่ guardrail ของ Fable แทบจะปิดกั้นการใช้งานด้านไซเบอร์ซีเคียวริตี้ทั้งหมด
- ยังคงมีลักษณะของ jagged frontier อยู่ และในผลลัพธ์กับรายงานความคืบหน้าก็ยังเห็นสำนวนเฉพาะแบบ "Claudism"
จากพ่อมดสู่ผู้ว่าจ้าง — บทบาทมนุษย์ที่เปลี่ยนไป
- เมื่อปีก่อน ประสบการณ์นี้ถูกเปรียบว่าเป็นแบบ พ่อมด (wizard) ที่ร่ายคาถาแล้วบางสิ่งก็เกิดขึ้น
- แต่ใน Fable คาถานั้นทรงพลังมากพอจนผู้ใช้ไม่ใช่พ่อมดอีกต่อไป หากใกล้เคียงกับการเป็นผู้ว่าจ้าง (patron) มากกว่า
- ผู้ใช้เพียงอธิบายสิ่งที่ต้องการ จ่ายต้นทุน และตัดสินผลลัพธ์ — ส่วนการร่ายเวทจริง ๆ เกิดขึ้นในที่ที่มองไม่เห็น ผ่านการตัดสินใจย่อยนับร้อยครั้ง
- งานกำลังเปลี่ยนจากกระบวนการไปสู่ผลลัพธ์ และจากการบังคับทิศทาง (steer) ไปเป็นการว่าจ้าง (commission)
-
ความเป็นไปได้สองทาง
- อาจเป็นเพียงภาวะชั่วคราวที่อินเทอร์เฟซยังตามไม่ทัน และในอนาคตอาจมีวิธีที่ดีกว่าในการมองเข้าไปในพฤติกรรมของโมเดลและควบคุมระหว่างทาง
- หรือในทางกลับกัน ยิ่งโมเดลมีความสามารถมากขึ้น มนุษย์ก็อาจยิ่งมีงานที่ทำได้อย่างมีความหมายน้อยลง และความเป็นกล่องดำอาจเป็นราคาที่ต้องจ่ายเพื่อให้ได้ความสามารถนั้น
- ไม่ได้หมายถึงการสูญเสียการควบคุมอย่างชัดเจน เพราะยังคงสั่งทิศทางได้และมันทำตามคำสั่งได้ดีมาก — และยิ่งคำสั่งทะเยอทะยาน ผลลัพธ์ก็ยิ่งดี
- แต่การควบคุมไม่ได้เท่ากับการลงมือทำเองอีกต่อไป เพราะโมเดลจะเปิดเอเจนต์ของตัวเองเพื่อค้นคว้า เขียน ตรวจสอบไขว้กัน และสุดท้ายส่งชิ้นงานสำเร็จกลับมา
- ผู้ว่าจ้างไม่ได้จ้างศิลปินเพียงคนเดียว แต่ Fable มีลักษณะใกล้เคียงกับทั้งสตูดิโอ ที่ผู้ว่าจ้างไม่เคยก้าวเข้าไปในพื้นที่ทำงานเลย และมีหน้าที่แค่อนุมัติผลลัพธ์สุดท้าย
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
น่าสนใจที่บทความนี้แทบไม่มีเนื้อหาจริงเกี่ยวกับ คุณภาพของโค้ดที่สร้างขึ้น และตัวกลางเลย
อยากรู้ว่าโค้ดมีเอกสารและการทดสอบหรือไม่, เข้าใจและขยายต่อได้ไหม, ปลอดภัยหรือเปล่า, ใช้ภาษา·เฟรมเวิร์ก·ฐานข้อมูลอะไรบ้าง ผู้เขียนพูดถึงวิจารณญาณและรสนิยม แต่ก็ไม่รู้ว่าโค้ดจริงเขียนออกมามีรสนิยมด้วยหรือไม่ ถ้าขอให้เพิ่มฟีเจอร์ใหม่ โมเดลจะรื้อสถาปัตยกรรมทั้งหมดอีกครั้งแล้วใช้โทเค็นไปอีก 9.5 ชั่วโมงหรือเปล่าก็น่าสงสัย ส่วนงานวิจัยน่าจะเป็นเรื่องความรู้โดเมน เช่น แปลงเวลาอย่างไรตามประเภทการเดินทางให้ดูเข้าใจง่าย และก็อยากรู้ว่าผู้เขียนตรวจสอบสิ่งนี้อย่างไร
คำถามพวกนี้ไม่ได้ใช้กับ AI อย่างเดียว ถ้าจ่ายเงินให้เอเจนซีที่เป็นคนแล้วได้ของที่ “ใช้งานได้” มาก็จะถามเหมือนกัน ถ้าประเมินไม่เป็นก็คงต้องจ้างคนที่ประเมินเป็น สำหรับ LLM จุดที่ติดขัดที่สุดคือ การตรวจสอบความถูกต้อง
ผู้เขียนคนนี้ดูเหมือนจะเป็นอาจารย์ที่ Wharton School of Management คนกลุ่มนี้ไม่จำเป็นต้องปล่อยผลิตภัณฑ์จริงหรือดูแลรักษามันจริง ๆ แค่ใกล้เคียงกับการทำโปรเจกต์ข้าง ๆ มากกว่า
มุมมองด้านวิศวกรรมซอฟต์แวร์ที่จริงจัง มีแทบแค่ Mitchell Hashimoto ที่เคยเห็น
คำถามข้างบนส่วนใหญ่ตั้งอยู่บนสมมติฐานของความเสี่ยงที่สูงกว่า เช่น ซอฟต์แวร์ต้องอยู่ยาว ข้อกำหนดเปลี่ยนแปลงไปเรื่อย ๆ และความผิดพลาดยอมรับไม่ได้
เคล็ดลับของการใช้ LLM กับซอฟต์แวร์ให้ดี ดูเหมือนจะเป็นการเรียนรู้วิธีทำให้ทุกโปรเจกต์กลายเป็นความเสี่ยงต่ำ
พอเรียกร้องเนื้อหาที่จับต้องได้ ก็จะมีคนพูดว่า “คนเองก็ทำเรื่องนี้ไม่เก่งไม่ใช่เหรอ!” ออกมารัว ๆ มีหลักฐานเชิงปริมาณน้อยมาก และมีแต่วาทกรรมล้วน ๆ
ถ้าพฤติกรรมที่สังเกตได้ของซอฟต์แวร์ดี ซอฟต์แวร์นั้นก็ดี ไม่ว่าบั๊กจะเป็นแบบไหน ถ้าโมเดลแก้ได้ใน codebase ที่ทำแบบ vibe coding ก็เป็นบั๊กที่แก้ได้ ถ้าไม่มีช่องโหว่ที่ถูกนำไปใช้โจมตีได้ ก็เป็นโค้ดที่ปลอดภัย และถ้าประสิทธิภาพเพียงพอ ก็เป็นโค้ดที่มีประสิทธิภาพดี
ถ้าภายนอกทำสิ่งที่ควรทำได้ และเมื่อพบปัญหาภายในแล้วโมเดลแก้ได้ รูปร่างหน้าตาของโค้ดก็ไม่สำคัญ วิศวกรรมซอฟต์แวร์ยิ่งกว่าเวลาไหน ๆ กลายเป็นงานตรวจสอบว่าโค้ดทำงานตามเจตนาหรือไม่
ต่อให้รูปร่างหน้าตาของโค้ดสำคัญ ก็ยังให้โมเดลแก้มันได้อยู่ดี
ไม่รู้ว่าฉันพลาดอะไรไป “จิตสำนึกในตัวเอง” หมายถึงข้อความตลก ๆ ไม่กี่บรรทัดด้านล่างจอหรือ? แล้ว “เรื่องประหลาด” คืออะไรก็ไม่รู้
ฉันลองเอาโมเดลที่เคยตรวจด้วยมือไปใส่ใน Fable
โดยคร่าว ๆ คือให้ Opus สร้างแบบจำลองสถานการณ์ ขอให้แสดงคณิตศาสตร์ออกมา แล้วค่อยแก้และวนซ้ำ ก่อนจะกลับมาตรวจอีกทีว่าโค้ดสอดคล้องกับตรรกะของโมเดลหรือไม่ Fable หาเจอแทบทุกข้อผิดพลาดที่ฉันเจอ และยังเสนอไอเดียที่น่าสนใจเกี่ยวกับตัวแปรเพิ่มเติมด้วย
แต่ก็เผา โควตาการใช้งาน ราวกับ Hummer ช่วงปลายยุค 90
ยังรีวิวไม่จบเลย และสุดท้ายในส่วนสำคัญเรื่อง memory safety ที่ฉันต้องการ Fable จริง ๆ ก็ต้องกลับไปใช้ Opus 4.8
เริ่มรู้สึกว่าเดี๋ยวคงใช้โมเดลพวกนี้ต่อไม่ได้เพราะราคา คงต้องรีด Fable ให้คุ้มที่สุดก่อนวันที่ 22 มิถุนายน
วันนี้ฉันลองใช้ Fable กับโปรเจกต์ส่วนตัว มันดูค่อนข้างแน่น แต่ก็ไม่ได้ห่างจาก 4.8 มากนัก
ยังมีอาการหลอนแบบเดิม บั๊กประเภทเดิม และในโปรเจกต์ใหญ่ก็ยังมีแนวโน้มจะทำแค่สิ่งที่ขอ โดยไม่สนใจส่วนที่อาจถูกแตะ ทำพัง หรือได้รับผลกระทบ ตอนแรกมันจะรันเทสต์ แต่พอบริบทใหญ่ขึ้นก็จะบอกว่า “ไว้ค่อยรันทีหลัง” และถ้าไม่สั่งแบบด่า ๆ สุดท้ายก็จะไม่รันจนจบ
ฉันจะใช้ต่ออยู่ แต่ตอนนี้ดูเป็นการปรับปรุงแบบค่อยเป็นค่อยไป ไม่ใช่ระดับ “OMG OMG OMG Mythos มาแล้ว!”
น่าประทับใจมากและร่วมงานด้วยแล้วดี
มันก็ไม่ใช่ปรากฏการณ์แปลก เพราะตอนฉันสมัครใหม่ ๆ Opus ก็เป็นแบบนี้พอดี มีมีมแพร่หลายว่า Anthropic ทำให้ Opus แย่ลงเพราะขาดแคลนทรัพยากร แต่ไม่รู้จริงไหม แค่อยากรู้ว่า Fable จะเจอชะตาเดียวกันหรือเปล่า
แต่หลังจากทำให้ฉันทึ่งกับการข้ามปัญหาเหล่านั้นไปเป็นทอด ๆ ได้ไม่นาน มันก็กลับไปติดลูปไม่รู้จบแบบเดิม คือพูดอยู่นั่นแทนที่จะลงมือทำอะไรสักอย่าง และบางครั้งก็หยุดไปเลยจนฉันต้องคอยเร่งใหม่
เพราะงั้นมันยังไม่ใช่ AGI แต่ก็เป็นการพัฒนาที่ชัดเจนแน่นอน
ประโยคสั้น ๆ ในบทความนี้ชวนหวาดเสียวมาก: “แต่วิศวกรซอฟต์แวร์จะมาขัดเกลาบั๊กที่อาจยังเหลืออยู่ซึ่งผมหาไม่เจอได้อย่างรวดเร็ว”
นักพัฒนาซอฟต์แวร์ทุกคนรู้ว่านี่เป็นสมมติฐานที่อันตรายมากและไม่สมจริง
ฉันลองอ่านไม่กี่ย่อหน้าแรกของบทความที่ผู้เขียนเรียกว่า “งานวิจัยสังคมศาสตร์เชิงวิชาการที่ซับซ้อนที่สุดซึ่ง AI สร้างขึ้น” แล้ว แต่ก็ไม่ได้น่าประทับใจเท่าที่คาด
มันประมาณว่า “ความเชื่อภายหลังต่ออุปสงค์ตลาดขึ้นอยู่กับจุดอ้างอิงล้วน ๆ เมื่อคงยอดระดมทุนไว้ ผู้ก่อตั้งจะติดตามเฉพาะผลงานเทียบกับเป้าหมายที่ตนตั้งไว้เอง มันกระโดดขึ้นครึ่งหนึ่งของส่วนเบี่ยงเบนมาตรฐานที่จุด threshold และตอบสนองอย่างชันใน 10 คะแนนแรกหลังจากนั้น ก่อนจะแบนราบลง”
ปกติคนเราไม่ค่อยอธิบายข้อมูลออกมาเป็นคำพูดแบบนี้ และเอกสารสรุปก็ให้ความรู้สึก เติมน้ำหนักให้เนื้อหาเกินจริง พอสมควร
นี่คือจุดที่ปัญหาปรากฏออกมาอย่างสมบูรณ์ที่สุด
ผู้เขียนใส่พรอมป์ต์ว่าข้อมูลทั้งหมดต้องเป็นของจริงและต้องผ่านการตรวจสอบ แล้วก็เชื่อไปเลยว่าเป็นเช่นนั้น ทั้งที่เป็นโปรเจกต์ที่ขับเคลื่อนด้วยข้อมูลแท้ ๆ ผู้คนจะทำแบบเดียวกันนี้กับงานนับไม่ถ้วน แม้แต่งานสำคัญก็ด้วย
สิ่งที่สะดุดตาคือช่วงที่บอกว่า “ทำงานอยู่ 9 ชั่วโมงครึ่ง” กับส่วนที่ว่า “มันไม่ได้สมบูรณ์แบบ ฉันพบข้อผิดพลาดและสิ่งที่ตกหล่นบางอย่างในฐานะผู้เชี่ยวชาญ และให้ AI แก้ไข”
ปกติผมไม่ได้คาดหวังว่าจะใช้เวลานานขนาดนั้นกับปัญหาเดียวในหนึ่งวัน และก็ไม่ได้คาดหวังว่าจะต้องใช้เวลานานขนาดนั้นเพื่อกลับไปแก้งานที่วงจรรางวัลหลักกินเวลาเป็นชั่วโมง ๆ
ตอนนี้ลูกค้าของผมกำลังกดดันให้ลดเวลาในการตอบสนองของเอเจนต์จาก 85 วินาทีให้ต่ำกว่า 20 วินาที
พอเห็นว่าในขณะเดียวกันอุตสาหกรรมกำลังมุ่งไปสู่ เวิร์กโฟลว์ที่ยาวเกินหนึ่งชั่วโมง ผ่านเอเจนต์ ก็รู้สึกขัดแย้งอย่างมาก
เราอาจจะกลับไปสู่ยุคที่หัวหน้าถามว่าทำไมถึงนั่งเฉย ๆ อีกครั้ง เพียงแต่แทนที่จะตอบว่า “กำลังคอมไพล์อยู่” ก็จะเป็น “กำลังรอ Claude อยู่”
โดยทั่วไปจะดีกว่าถ้ากำหนดกระบวนการด้วยโค้ดเอง แล้วให้โค้ดนั้นมอบหมายชิ้นงานไปยังโมเดลต่าง ๆ ปัญหาจริงมีอยู่ข้อเดียวคือมันทำให้ใช้ส่วนลดแบบสมัครสมาชิกของผู้ให้บริการได้ยากขึ้น
ในทางกลับกัน การทำ model routing ด้วยตัวเองกลับง่ายขึ้น ผมยังไม่เคยเห็นวิธีที่แชตบอตทั่วไปจะรักษาความสม่ำเสมอได้ในเวิร์กโฟลว์ที่กินเวลาเป็นวันหรือเป็นสัปดาห์
ถ้าจัดโครงสร้างโปรเจ็กต์ให้ดีพอ คุณก็สามารถชี้ไปยังจุดที่อยากขยาย แล้วปล่อยให้มันรันราว 30 นาทีเพื่อขยายฟีเจอร์ได้ มันยังไม่สามารถทำ “โหมดพระเจ้า” กับทั้งโค้ดเบสได้อย่างมีประสิทธิภาพ แต่ถ้าเป็นผู้สังเกตการณ์ที่รอบคอบและเป็นผู้เชี่ยวชาญด้านโค้ด ก็ไม่จำเป็นต้องมี VRAM มากกว่า 128GB
น่าทึ่งที่โมเดลรุ่นใหม่ที่ไม่ใช่แบบสนทนาไปได้ไกลขนาดนี้ และถ้าจีนเริ่มผลิตซิลิคอนสำหรับโมเดลพวกนี้ออกมาเอง ผมว่าเกมคงจบ
อยากรู้มากว่าพรอมป์ต์บทกวีนั้นคืออะไร
ไอเดียมันคุ้น ๆ เลยลองขุดดู แล้วก็ไปเจอบทกวีจาก reddit เมื่อ 14 ปีก่อน: [https://www.reddit.com/r/RedditDayOf/comments/tjjw2/may_12_a...]
ถึงจะไม่ยาวเท่าที่ผู้เขียนแชร์ แต่เป็นไอเดียเดียวกัน
นี่มาจาก “The Cyberiad” รวมเรื่องอุปมาวิทยาศาสตร์ของนักเขียนชาวโปแลนด์ Stanislaw Lem ในเรื่องหนึ่ง นักประดิษฐ์หุ่นยนต์ชื่อ Trurl สร้างเครื่องแต่งบทกวีขึ้นมา และคู่แข่งขี้อิจฉาชื่อ Klapaucian ก็ท้าทายเครื่องนั้นว่า “บทกวีเกี่ยวกับการตัดผม! แต่ต้องสูงส่ง สูงศักดิ์ โศกนาฏกรรม ชั่วนิรันดร์ ว่าด้วยความรัก การทรยศ การตอบโต้ วีรกรรมอันเงียบงัน เมื่อเผชิญหน้ากับหายนะที่แน่นอน! หกบรรทัด สัมผัสอย่างชาญฉลาด และทุกคำต้องขึ้นต้นด้วย s!”
คอมพิวเตอร์ก็ตอบว่า:
“Seduced, shaggy Samson snored.
She scissored short. Sorely shorn,
Soon shackled slave, Samson sighed.
Silently scheming,
Sightlessly seeking
Some savage, spectacular suicide”
ดูแล้วผู้เขียนน่าจะต้องอ้างอิงฉากนี้แน่ ๆ ตอนโยนโจทย์ท้าทายให้ Fable/Mythos อยากรู้ว่าพรอมป์ต์ที่ใช้จริงคืออะไร
ฉบับแปลภาษาอังกฤษใช้ตัวอักษรขึ้นต้นและคำที่ต่างจากต้นฉบับภาษาโปแลนด์:
Cyprian cyberotoman, cynik, ceniąc czule
Czarnej córy cesarskiej cud ciemnego ciała,
Ciągle cytrą czarował. Czerwieniała cała,
Cicha, co-dzień czekała, cierpiała, czuwała...
... Cyprian ciotkę całuje, cisnąwszy czarnulę!!
เราอาจนำงานของนักแปลมาเทียบกับ LLM ได้ ทั้งคู่เป็นงานต่อยอด ทำงานภายใต้ข้อจำกัด แต่ยังมีพื้นที่ให้ใช้ความคิดสร้างสรรค์
พวกเขายังใช้เวลาไม่ถึงชั่วโมงเลย จึงต้องเผื่อไว้ด้วยว่ากำลังตื่นเต้นกับเทคโนโลยีใหม่
สำหรับโปรเจ็กต์ของผมเอง (https://github.com/tsz-org/tsz) ผมหงุดหงิดมาตลอดที่โมเดลมักจะค้นคว้าไม่พอและไม่คำนึงถึงบริบทอื่น ๆ โมเดลจะสร้างโค้ดมาแก้อย่างหนึ่ง แล้วก็ทำเทสต์อีกสองตัวที่ “ดูเหมือนไม่เกี่ยวกัน” พังซ้ำ ๆ
Fable ดูเหมือนจะใช้เวลาทำงานนานกว่ามาก และผมก็ยังไม่เคยเห็น pull request เต็ม ๆ จากเซสชัน Fable แต่พออ่านบันทึกเซสชันแล้วจะเห็นว่ามันกำลังทำสิ่งที่ถูกต้องแบบ ไม่ปล่อยให้มีแม้แต่ก้อนหินก้อนเดียวที่ไม่ได้พลิกดู
อย่างที่บทความบอก ความ “รู้สึก” ของโมเดลแบบนี้ต่างกันมากในแต่ละโปรเจ็กต์จนถ่ายทอดได้ยาก แต่ก็ขอแชร์ไว้
อยากรู้จริง ๆ ว่าทุกคนกำลังทำงานอะไรกันอยู่ ถึงได้รู้สึกว่าระหว่าง Mythos กับ Opus ต่างกันมากขนาดนั้น
ฉันก็คิดว่าตัวเองทำงานค่อนข้างระดับสูงนะ แต่หลายครั้งแค่ Deepseek ก็พอแล้ว คนที่นี่เป็นอัจฉริยะกันหมดเลยหรือไง?
ถ้าคุณพยายามสร้างวิดีโอเกมระดับอินดี้คุณภาพดีแบบ Hades หรือ Baazar พร้อมองค์ประกอบ UI ที่ให้ความรู้สึกเป็นธรรมชาติ โต้ตอบได้ มีแอนิเมชัน เอฟเฟ็กต์ภาพ หรือเชดเดอร์ซับซ้อน ๆ ก็ไม่มีโมเดลไหนที่เก่งพอจะทำจบได้ง่าย ๆ เลย ปัญหาจำนวนมากที่เจอในเกมระดับท็อป 3% นั้นยากมากสำหรับทุกโมเดลถ้าใช้แค่พรอมป์ต์ธรรมดา
ส่วนตัวฉันชอบเขียนโค้ดเองและชอบเรียนรู้ เลยไม่ได้ใส่ใจมาก DeepSeek Flash ระดับนั้นก็พอแล้ว ถึงอย่างนั้นก็ง่ายมากที่จะสร้างเบนช์มาร์กจำนวนมากที่แม้แต่โมเดลที่ดีที่สุดก็ยังเข้าไม่ถึงเลย และฉันก็ชอบทดสอบว่าโมเดลพัฒนาขึ้นแค่ไหนกับปัญหาแบบนั้น
อ้างอิงไว้ก่อนว่า Fable 5 ดีกว่า 4.8 อย่างเห็นได้ชัดเล็กน้อย
ทั้งที่ความจริง 90% น่าจะยังใช้ Macbook Neo ไปได้สบาย
เป็นความพยายามจะสร้างตัวแทน nginx ที่ปลอดภัยด้านหน่วยความจำ หรืออย่างน้อยก็ใกล้เคียง โดยใช้พื้นฐานดี ๆ ของ Rust อย่าง rustls และ Tokio เยอะพอสมควร
ส่วนหนึ่งของงานนี้คือกำลังทำรีโพ Lua in Rust คุณภาพสูงด้วย กำลังใช้ Mythos แก้ปัญหาประสิทธิภาพใน Lua interpreter ของฉันที่ gpt 5.5 กับ Opus 4.8 ไปต่อไม่ได้
ยังไม่รู้ว่า Mythos จะแก้ได้ไหม แต่รันมาหลายชั่วโมงแล้วและผลลัพธ์ก็ดูมีแววทีเดียว
ถ้าอยากดูก็มีกราฟประสิทธิภาพอยู่ที่นี่: https://github.com/ianm199/lua-rs
แล้วก็กำลังมองหาโอเพนซอร์สโปรเจกต์ที่น่าจะมีส่วนร่วมได้ด้วย กำลังหาบางอย่างที่อาจช่วยให้เปลี่ยนจากนักพัฒนางานอดิเรกไปเป็นมืออาชีพได้ แต่ก็ไม่รู้ว่าในยุคนี้มันยังเป็นไปได้ไหม
Fable 5 เจอปัญหาในการรีวิวโค้ดได้ค่อนข้างเยอะที่ Opus 4.8 มองข้ามไป ทั้งที่โมเดลถูกลดความสามารถลงเพราะข้อจำกัดด้านไซเบอร์ซีเคียวริตี้แบบงี่เง่า พูดมากกว่านี้ก็ยาก เพราะใน Max 5x ฉันได้แค่หนึ่งเซสชันต่อทุกหน้าต่างเวลา 5 ชั่วโมง จนถึงตอนนี้เพิ่งใช้ไปแค่สองเซสชัน
เอาแบบสุดโต่งเลย สมมติพรอมป์ต์คือ “สร้าง Facebook clone ที่ฟังก์ชันครบและงานเสร็จสมบูรณ์” Facebook นั้นซับซ้อนก็จริง แต่ในเชิงเทคนิคอาจไม่ได้โหดหินมากนัก ถึงอย่างนั้นพอเผาโทเค็นไปพอสมควรแล้ว คุณก็น่าจะเห็น ความแตกต่างที่มากพอสมควร ในหลายด้านจากผลลัพธ์ของโมเดลต่าง ๆ ต่อพรอมป์ต์นั้น
แน่นอนว่าคำขอแบบนั้นไม่ได้มีประโยชน์จริง ๆ แต่ถ้าจะโยนงานก้อนใหญ่ขึ้นไปเรื่อย ๆ จนเกือบถึงขีดจำกัด มันจะมีเหตุผลอะไรที่ทำไม่ได้ล่ะ? สักจุดหนึ่งมันก็จะชนเส้นแบ่ง และความแตกต่างจะชัดเจนเอง