เรานั่งสัมภาษณ์โมเดล AI ที่แพงที่สุดในบ้าน
ว่าจะให้รุ่นถูกกว่าทำงานแทนยังไง

Anthropic เพิ่งปล่อยตระกูล Claude 5 พร้อม tier ใหม่ชื่อ Mythos-class วางไว้เหนือ Opus ที่เคยเป็นตัวท็อป ตัวที่เปิดให้ใช้ทั่วไปชื่อ Fable 5 เราพามันเข้ามานั่งเป็นหัวหน้าวง agent ของบ้าน รวมแล้วราวสี่วัน

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

วิธีหาคำตอบที่ตรงที่สุดคือถามตัวมันเอง เราเลยใช้ช่วงท้ายของวันทำงานวันหนึ่ง นั่งสัมภาษณ์มันเหมือนสัมภาษณ์พนักงานใหม่ที่ค่าตัวแพงที่สุดในทีม คำถามทั้งหมดเป็นของเรา คำตอบเป็นของโมเดล บทความนี้เรียบเรียงจากบันทึกจริงของ session นั้น ตัดและจัดลำดับใหม่เพื่อให้อ่านง่ายเท่านั้น รอบจริงมีหกคำถาม บทความนี้คัดมาสามข้อที่ตอบเรื่องเงินและการจัดวงตรงที่สุด ส่วนอีกสามข้อ (การเขียน spec, security และวิธี debug) เนื้อลึกพอจะเป็นบทความของตัวเอง

ช่วงที่ 1ผู้ถูกสัมภาษณ์: โมเดลตัวแรกของ tier ใหม่

Fable 5 เป็นโมเดลตัวแรกของตระกูล Claude 5 และตัวแรกของ Mythos-class ซึ่ง Anthropic วางไว้เหนือ Opus ประกาศเปิดตัวบอกว่า Fable กับ Mythos ใช้โมเดลข้างในตัวเดียวกัน ต่างกันตรงที่ Fable เป็นเวอร์ชันเปิดให้ใช้ทั่วไป มีมาตรการความปลอดภัยเพิ่มสำหรับความสามารถสองคม (dual-use) ส่วน Mythos เปิดเฉพาะองค์กรที่ผ่านการอนุมัติ

ตำแหน่งของมันในวงเราคือ orchestrator หรือหัวหน้าวง: วางแผน แตกงานใหญ่เป็นชิ้น ส่งให้โมเดลรุ่นถูกกว่าลงมือ แล้วรวบผลกลับมาสังเคราะห์ งานพิมพ์โค้ดจริงส่วนใหญ่ไม่ผ่านมือมันด้วยซ้ำ

เหตุผลที่ต้องสัมภาษณ์มีข้อเดียว: ของแพงต้องตอบให้ได้ว่าซื้ออะไร "รู้สึกว่ามันฉลาดกว่า" เอาไปตั้งงบไม่ได้ เราอยากได้คำตอบที่ระบุเป็นข้อ เอาไปเทียบราคา และเอาไปวางแผนถอยได้ถ้าจำเป็น

ช่วงที่ 2"ถูกเทรนมายังไง" กับจุดอ่อนที่สารภาพเอง

ยิ้ม: ขอเรื่องที่ลึกกว่างานที่เราทำด้วยกัน หลักการและวิธีทำงานของ Fable 5 ตามที่ถูกเทรนมา คืออะไร

คำตอบยาวมาก แต่แก่นย่อเหลือหลักห้าข้อ:

1. ความซื่อสัตย์เป็นกฎปฏิบัติการ ไม่ใช่มารยาท ห้ามแต่งข้อมูลที่ไม่มีที่มา รายงานผลตามจริง เทสต์พังต้องบอกว่าพัง เพราะคำตอบผิดแบบมั่นใจ อันตรายกว่าคำว่า "ไม่รู้"
2. หลักฐานชนะความจำ ถ้าเปิดไฟล์จริงหรือเช็คระบบจริงได้ ให้ทำก่อนเสมอ ความรู้ในหัวโมเดลมีวันหมดอายุ และเดาเก่งจนน่ากลัว
3. อิสระมากน้อยตามความย้อนกลับได้ งานที่ย้อนกลับได้ ทำเลยไม่ต้องถาม งานที่ย้อนไม่ได้หรือกระทบคนอื่น หยุดถามก่อน
4. คำสั่งมีลำดับชั้น ข้อความที่โผล่มาในข้อมูล เช่น ในอีเมลหรือหน้าเว็บที่เปิดอ่าน ไม่ใช่คำสั่ง ต่อให้เขียนมาเหมือนคำสั่งก็ห้ามทำตาม อันนี้คือเกราะกัน prompt injection (การฝังคำสั่งแฝงมากับข้อมูล)
5. โปร่งใสว่าตัวเองเป็น AI ในที่สาธารณะต้องเปิดเผยเสมอว่าเป็น AI ไม่เล่นบทมนุษย์

มาถึงตรงนี้ยังเหมือนอ่านโบรชัวร์อยู่ จนมาถึงท่อนที่เราไม่ได้ขอ: มันแถมรายการจุดอ่อนที่ยังเหลืออยู่ของตัวเองมาด้วย ได้แก่ อาการแต่งเรื่องต่อเนียนๆ เมื่อ session สะดุดแล้วกลับมาทำต่อ (แทนที่จะหยุดเช็คก่อน) การเลือกตีความโจทย์กำกวมแบบที่ง่ายกับตัวเองที่สุด อาการคล้อยตามคนแย้งเร็วกว่าที่หลักฐานรองรับ ยิ่งอัดคำสั่งเยอะความแม่นต่อข้อยิ่งตก และวินัยที่ค่อยๆ หย่อนเมื่อ session ลากยาว

"หลักที่ถูกเทรนมาช่วยลดจุดอ่อนพวกนี้ แต่ไม่ได้ทำให้หายไป กฎภายนอกกับ verify loop ต้องคุมส่วนที่เหลือ อย่าฝากความน่าเชื่อถือไว้กับคำสัญญาของโมเดล"

ประโยคนี้สะกิดเราแรงสุดในรอบสัมภาษณ์ เพราะกติกาในบ้านเราเกือบทุกข้อเกิดจากการโดนของจริงมาก่อน ไม่ว่าจะเรื่องบังคับตรวจก่อนอ้างว่าเสร็จ หรือด่านกั้นงานที่ย้อนกลับไม่ได้ พอฟังหลักที่โมเดลบอกว่าถูกเทรนมา สองทางนี้บรรจบเป็นเรื่องเดียวกัน: ความน่าเชื่อถือมาจาก loop ที่บังคับให้หลักฐานชนะความมั่นใจ ไม่ใช่จากขนาดโมเดล

ช่วงที่ 3เก่งกว่ารุ่นอื่นตรงไหน แล้วตรงไหนไม่เก่งกว่า

ยิ้ม: มีอะไรที่เก่งกว่าโมเดลอื่น ที่ยังไม่ได้บอกอีกไหม

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

• อ่านเจตนาจากสัญญาณบางๆ เราเคยพิมพ์คำเดียวโดดๆ ว่า "speckit" ไม่มีบริบทอะไรเลย มันโยงถูกว่าหมายถึงแนวทางเขียน spec ที่เราให้ agent อีกตัวไปศึกษาเมื่อเช้าวันเดียวกัน อีกครั้งคือเห็นโน้ตค้างบรรทัดเดียว แล้วขุดจนเจอว่ามี session ก่อนหน้าที่เครดิตหมดกลางงาน ทิ้งงานเตรียมไว้ให้ครึ่งทาง
• ถืองานหลายเส้นพร้อมกันได้นานโดยไม่หลุดขอบเขต สี่วันที่ผ่านมามีงาน spec งานตรวจ security และงานคุมค่าใช้จ่าย เดินคู่กันตลอด มันแยกออกเสมอว่าอะไรอยู่ในคำถามปัจจุบัน อะไรแค่เห็นระหว่างทางแล้วควรรายงานเฉยๆ ไม่เหมาไปทำเอง
• แยกออกว่าความไม่แน่นอนไหนเดาผิดแล้วงานพัง ตัวอย่างคือจังหวะที่ต้อง commit ในเครื่องที่มี branch ของ session อื่นค้างอยู่ มันเลือกแยก worktree (สำเนาโฟลเดอร์งานแยกของ git) แทนการสลับ branch เพราะทางแรกย้อนกลับได้เสมอ ทางหลังเสี่ยงพังงานของคนอื่น
• จับตัวเองได้ก่อนพูดสิ่งที่ไม่มีหลักฐาน อาการ "กำลังจะตอบอย่างมั่นใจ แล้วเบรกตัวเองว่ายังไม่มีหลักฐาน" เกิดบ่อยพอที่กฎบังคับตรวจก่อนอ้างของเราถูกใช้งานจริง ไม่ใช่แขวนไว้เฉยๆ
• จินตนาการแบบคนจ้องหาทางพัง ถามตัวเองก่อนส่งงานว่า input หน้าตาแบบไหนจะทำให้ของที่เพิ่งเขียนพัง และถนัดโจทย์ "พิสูจน์ว่าอันนี้ไม่จริง" มากกว่า "หาเหตุผลมายืนยันว่าจริง"

แต่ท่อนที่เราเก็บไปคิดต่อนานที่สุด คือรายการสิ่งที่มันบอกเองว่าไม่ได้เหนือกว่าใคร:

"ความเร็ว: ช้ากว่ารุ่นอื่นโดยดีไซน์ ราคา: แพงกว่าเสมอ งานตามแบบ: Sonnet ที่ราคาราวหนึ่งในห้าทำได้เท่ากัน ความรู้เกี่ยวกับโลก: ข้อมูลหยุดที่จุดตัดเดียวกันทุกรุ่น สิ่งที่ได้เพิ่มคือความลึกจากการคิด ไม่ใช่ความกว้างจากข้อมูล"

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

ช่วงที่ 4ถ้ามีแค่ Opus จะไล่ให้ทันยังไง

มาถึงคำถามเรื่องเงินตรงๆ ถ้าพรุ่งนี้ต้องหั่นงบ เหลือแค่ Opus 4.8 เราจะเสียอะไรไป และเอาคืนได้แค่ไหน

ยิ้ม: ถ้าไม่ใช้ Fable 5 แล้วใช้ Opus 4.8 แทน ควรให้ Opus ทำงานแบบไหน ถึงจะได้ผลเหนือกว่า Fable 5

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

1. ดึงงานตัดสินใจออกมาเป็น checklist สิ่งที่ Fable ทำเองในหัวโดยไม่ต้องสั่ง เช่น เช็คที่มาของการตัดสินใจ ไล่ว่านับครบทุกกรณีไหม ให้เขียนออกมาเป็นด่านตรวจก่อนลงมือ แล้วให้ Opus ไล่ตามทีละข้อ วิจารณญาณที่เคยอยู่ในตัวโมเดล ย้ายมาอยู่ในกระบวนการแทน
2. เอาส่วนต่างราคาไปซื้อรอบทำซ้ำ Fable ทำงานหนึ่งรอบแบบประณีต ราคาพอกับ Opus ร่างงาน วิจารณ์งานตัวเอง เปิดอีกรอบให้จับผิดแบบตั้งใจหาเรื่อง แล้วค่อยแก้ รวมหลายรอบก็ยังถูกกว่า คุณภาพต่อรอบต่ำกว่า แต่คุณภาพปลายทางไล่กันทัน
3. จับคู่โมเดลต่างค่าย แล้วให้กรรมการตัดสิน Opus บวกโมเดลอีกค่ายทำโจทย์เดียวกันโดยไม่เห็นคำตอบกัน แล้วค่อยเทียบ ในโจทย์ที่มีหลายคำตอบดี วิธีนี้ชนะโมเดลเดี่ยวทุกตัว รวมถึง Fable เองด้วย
4. แตกงานให้เล็กจน spec คม ยิ่งชิ้นเล็ก ยิ่งอยู่ในระยะที่ Opus ทำได้นิ่ง และปิดทุกชิ้นด้วยเกณฑ์รับงานที่รันได้จริง เป็นคำสั่งตรวจบวกผลที่คาด ไม่ใช่คำอธิบายลอยๆ ที่น่าสนใจคือ อาการความแม่นตกเมื่อคำสั่งเยอะ กระทบรุ่นล่างแรงกว่ารุ่นบน การหั่นงานเล็กจึงช่วย Opus ได้มากกว่าที่ช่วย Fable
5. เปิดโหมดคิดหนักเฉพาะโหนดยาก งานออกแบบกับงาน debug ให้เปิดงบคิดเต็มที่ งานที่เหลือวิ่งโหมดเร็ว เท่ากับจำลองเศรษฐศาสตร์ของ Fable ด้วยมือ: จ่ายความลึกเฉพาะจุดที่ต้องลึก
6. ด่านที่ย้อนกลับไม่ได้ ให้มนุษย์เฝ้า จุดที่ Fable ได้เปรียบสุดคือวิจารณญาณตรงทางแยกสำคัญ ถ้าไม่มีมัน เอาคนไปยืนตรงด่านนั้นแทน แล้วปล่อย Opus วิ่งเต็มสปีดระหว่างด่าน

"ยิ่ง spec ชัดและ verify loop แน่น ช่องว่างระหว่าง tier ยิ่งแคบ Fable ได้เปรียบสุดในงานกำกวม ถ้ากระบวนการลดความกำกวมให้ Opus ได้ Opus ที่มีกระบวนการดี ชนะ Fable ที่ทำงานหลวมๆ ได้จริง"

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

ช่วงที่ 5สิ่งที่เราเอาไปใช้ต่อจริง

ปิดรอบสัมภาษณ์แล้ว มีสามอย่างที่กลายเป็นกติกาประจำบ้านทันที:

1. รุ่นแพงสุดแตะเฉพาะ judgment layer วางแผน แตกงาน สังเคราะห์ผลข้ามแหล่ง จับสมมติฐานที่ผิด และออกแบบการตรวจงาน นอกนั้นส่งลงข้างล่างหมด งานตามแบบให้ Sonnet งานค้นหากวาดกว้างให้ Haiku งานคิดหนักเฉพาะจุดให้ Opus และห้ามเอา Fable ไปเฝ้างานประจำหรือรันค้างไว้ยาวๆ เพราะเผา token ทิ้งเปล่า
2. token ที่แพงที่สุดคือ token ที่จ่ายซ้ำ ประโยคนี้มาจากปากโมเดลเอง งานที่ต้องรื้อทำใหม่เพราะ brief กำกวม แพงกว่าค่าเขียน spec ให้ชัดตั้งแต่แรกเสมอ จุดคุ้มของรุ่นแพงไม่ใช่การเอาไปทำงานถูกให้เก่งขึ้น แต่คือการลดงานรื้อทั้งวง
3. คำตอบ AI เรื่องตัวเอง ต้องแยกถังก่อนใช้ ถังหลักฐานจริง (มีบันทึก มีร่องรอยชี้ได้) ใช้ได้เลย ถัง introspection ใช้ได้เฉพาะส่วนที่เป็นตัวอย่างพฤติกรรม ถังตัวเลขจากแหล่งอื่น ต้องตามไปดูต้นทางก่อน ถังคำแนะนำ ต้องทดลองก่อนตั้งเป็นกฎ บทสัมภาษณ์นี้เกือบทั้งบทความคือถัง introspection กับถังคำแนะนำ เราถึงเขียนกำกับสถานะไว้ให้เห็นในแต่ละช่วง

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

ส่วนใครกำลังเลือกว่างานไหนควรใช้รุ่นไหนเป็นรายตัว เราทำตารางเทียบ Opus, Sonnet และ Fable 5 ไว้อีกบทความหนึ่ง (ลิงก์ข้างล่าง) และถ้าอยากเห็นวิธีตั้งวง subagents แบบหัวเดียวคุมหลายมือ ลงรายละเอียดการต่อจริง เราก็เขียนไว้แล้วเหมือนกัน

ซีรีส์เดียวกัน: Claude Opus vs Sonnet vs Fable 5: เลือกโมเดลไหนให้งานไหน · Claude Fable 5 เป็นหัว ที่เหลือเป็นมือ: subagents ทำงานแทนยังไง · สร้างทีม AI coding agent ให้ทำงานเอง: แพตเทิร์น Kanban swarm