Claude Code มีการตั้งค่าสองอย่างที่ดูเหมือนจะ "ทำให้คำตอบดีขึ้น" ได้แก่ โมเดล และระดับความพยายาม (effort level) แต่จริงๆ แล้วสิ่งเหล่านี้ส่งผลต่อผลลัพธ์อย่างไร? และคุณจะรู้ได้อย่างไรว่าเมื่อไหร่ควรเปลี่ยนไปใช้โมเดลอื่น หรือแค่ปรับระดับความพยายาม?
เป็นเรื่องง่ายที่จะคิดว่าการเลือกโมเดลที่ใหญ่กว่าอย่าง Fable จะให้ผลลัพธ์ที่ฉลาดกว่า Sonnet และระดับความพยายามที่สูงขึ้นก็หมายความว่า Claude คิดนานขึ้นก่อนจะตอบ
ข้อสันนิษฐานแรกเป็นความจริง โมเดลที่ใหญ่ที่สุดของเรามี ความสามารถมากกว่า ตามเกณฑ์มาตรฐานที่ยอมรับในอุตสาหกรรม
แต่ความพยายามไม่ได้หมายถึงแค่ "เวลาในการคิด" เท่านั้น ความพยายามควบคุม ปริมาณงานที่ Claude ทำกับคำขอของคุณโดยรวม ซึ่งรวมถึงระยะเวลาที่มันคิด แต่ยังรวมถึง:
- จำนวนไฟล์ที่มันอ่าน
- ปริมาณการตรวจสอบที่มันทำ
- และขอบเขตที่มันจะดำเนินการตามงานที่มีหลายขั้นตอนก่อนที่จะตรวจสอบกับคุณ
ที่ระดับความพยายามสูงขึ้น Claude จะดำเนินการต่างๆ เหล่านี้มากขึ้น (อ่านไฟล์, รันเทสต์, ตรวจสอบซ้ำ) ก่อนที่จะกลับมาหาคุณ ที่ระดับความพยายามต่ำลง มันจะถามคุณเพื่อหาข้อมูลเพิ่มเติม แทนที่จะใช้โทเคนเพื่อคิดหาคำตอบด้วยตัวเอง
วิธีการทำงานของการเลือกโมเดล
เพื่อทำความเข้าใจว่าการตั้งค่าโมเดลควบคุมอะไรกันแน่ ควรเริ่มจากจุดเริ่มต้นที่สุด คือตั้งแต่ตอนที่คุณกด Enter
Claude Code จะรวบรวมข้อความของคุณพร้อมกับ system prompt, คำจำกัดความของเครื่องมือ (tool definitions), CLAUDE.md ของคุณ, ประวัติการสนทนา และไฟล์ที่อยู่ในบริบท ทั้งหมดนี้จะถูกส่งเป็นคำขอเดียวไปยัง API
ทุกสิ่งที่ Claude Code มีจะถูกบรรจุลงในคำขอ API เดียว บนเซิร์ฟเวอร์ ข้อความจะถูกแปลงเป็นโทเคนก่อนที่จะส่งถึงโมเดล
อย่างไรก็ตาม โมเดลจะไม่เห็นสิ่งเหล่านั้นเป็นข้อความธรรมดาเลย สิ่งแรกที่เกิดขึ้นบนเซิร์ฟเวอร์คือการทำ tokenization: ข้อความจะถูกแบ่งออกเป็นส่วนย่อยๆ และแต่ละส่วนจะถูกจับคู่กับจำนวนเต็มจากคำศัพท์คงที่ที่โมเดลได้รับการฝึกฝนมา \const\ อาจถูกจับคู่กับ 1978, \await\ อาจถูกจับคู่กับ 4293 จากจุดนี้เป็นต้นไป prompt ของคุณคืออาร์เรย์ของจำนวนเต็ม
Tokenizer จะแบ่งข้อความของคุณออกเป็นส่วนย่อยๆ และจับคู่แต่ละส่วนกับจำนวนเต็มในคำศัพท์คงที่ แต่ละส่วนในแถวบนจะกลายเป็น token ID (แถวล่าง); ID ที่แสดงเป็นเพียงตัวอย่างเท่านั้น
หน้าที่ของโมเดลคือการนำอาร์เรย์นั้นมาคาดการณ์ว่าโทเคนใดจะมาต่อไป มันทำได้โดยการคำนวณความน่าจะเป็นสำหรับทุกโทเคนในคำศัพท์ และเลือกจากโทเคนที่มีความน่าจะเป็นสูงสุด หลังจาก "const x = await" โมเดลที่ได้รับการฝึกฝนมาอย่างดีจะให้ความน่าจะเป็นสูงกับ "fetch" (เป็นไปได้มาก) และเกือบเป็นศูนย์กับ "banana" (ไม่น่าเป็นไปได้เลย)
การคาดการณ์ของโมเดลคือความน่าจะเป็นสำหรับทุกโทเคนในคำศัพท์ ช่องว่างระหว่างตัวเลือกที่ได้คะแนนสูงสุดกับตัวเลือกที่ไม่เกี่ยวข้องนั้นมีขนาดใหญ่มาก
สิ่งที่เปลี่ยนโทเคนอินพุตของคุณให้กลายเป็นความน่าจะเป็นเหล่านั้นคือน้ำหนัก (weights หรือที่เรียกว่า parameters): ตัวเลขหลายพันล้านตัวที่จัดเรียงอยู่ในเมทริกซ์ขนาดใหญ่ ในการคาดการณ์หนึ่งโทเคน โมเดลจะนำอินพุตของคุณผ่านเมทริกซ์เหล่านั้น (เป็นลูกโซ่ยาวของการคูณเมทริกซ์) และอ่านค่าความน่าจะเป็นที่ปลายทาง น้ำหนักคือที่ที่ทุกสิ่งที่โมเดล "รู้" อาศัยอยู่
น้ำหนักของแต่ละโมเดลถูกกำหนดในระหว่างการฝึก และเมื่อถึงเวลาที่คุณส่งคำขอ มันจะ เป็นแบบอ่านอย่างเดียว (read-only) ไม่มีอะไรใน prompt, CLAUDE.md หรือบริบทของคุณที่เปลี่ยนแปลงมันได้ หากคุณเคยเจอคำว่า inference นั่นคือความหมายทั้งหมด: การใช้โมเดล หลังจาก การฝึกเสร็จสิ้น โดยที่น้ำหนักคงที่
Prompt ของคุณเข้าไป ความน่าจะเป็นออกมา น้ำหนักที่อยู่ตรงกลางไม่เปลี่ยนแปลง
ทุกสิ่งที่ Claude รู้เกี่ยวกับ TypeScript, เฟรมเวิร์กยอดนิยม หรือความรู้ด้านการเขียนโปรแกรมทั่วไปอื่นๆ ถูกเข้ารหัสไว้ในน้ำหนักเหล่านั้นตั้งแต่ตอนฝึก
Prompt และบริบทของคุณยังสามารถ ชี้แนะ การคาดการณ์ได้ การใส่โค้ดจริงของคุณไว้ข้างหน้า Claude คือการชี้แนะ และมันได้ผลดีมาก อย่างไรก็ตาม สิ่งนี้ไม่ได้เพิ่มอะไรลงในน้ำหนักของตัวโมเดลเอง
หากไลบรารีใดไม่มีอยู่ในตอนที่โมเดลถูกฝึก ไลบรารีนั้นก็จะไม่อยู่ในน้ำหนัก คุณสามารถใส่เอกสารในบริบทแล้ว Claude จะใช้มัน แต่นั่นคือ การชี้แนะ ไม่ใช่การสอน การตอบสนองของ Claude จะได้รับอิทธิพลเฉพาะในคำขอนั้นๆ เท่านั้น แต่โมเดลที่อยู่เบื้องหลังไม่ได้จดจำอะไรไว้เลย
เมื่อ Claude เรียก API ที่ไม่มีอยู่จริงอย่างมั่นใจ (อาการหลอนหรือ hallucination) นั่นคือน้ำหนักที่สร้างลำดับโทเคนที่ ดูเหมือน เป็นไปได้จากรูปแบบการฝึก ไม่ใช่การค้นหาที่ล้มเหลว
แล้วการเปลี่ยนโมเดลทำอะไรจริงๆ? มันเปลี่ยนชุดน้ำหนักที่ถูกแช่แข็ง ที่จัดการคำขอของคุณ
โมเดลไม่ได้สร้างคำตอบทั้งหมดในครั้งเดียว มันคาดการณ์หนึ่งโทเคน แนบมันเข้ากับลำดับ แล้วรันการคำนวณทั้งหมดอีกครั้งเพื่อให้ได้โทเคนถัดไป การตอบสนองแบบ 200 โทเคนคือการผ่านน้ำหนัก 200 ครั้งแยกกัน ลูปนี้คือที่มาของเวลารอคอยส่วนใหญ่ของคุณ (และต้นทุนเอาต์พุตของคุณ)
ลำดับจะเพิ่มขึ้นทีละหนึ่งโทเคนต่อขั้นตอน โมเดลจะอ่านอาร์เรย์ทั้งหมดอีกครั้งในแต่ละครั้งเพื่อคาดการณ์ว่าอะไรจะเกิดขึ้นต่อไป
การตั้งค่าโมเดลเป็นตัวตัดสินว่าน้ำหนักชุดใดจะจัดการคำขอของคุณ และยังเป็นตัวตัดสินว่าต้นทุนของเอาต์พุตแต่ละโทเคนคือเท่าไหร่
สิ่งที่มัน ไม่ได้ ตัดสินคือ จำนวนโทเคนที่จะถูกสร้างขึ้น จำนวนนั้นอาจแตกต่างกันอย่างมากสำหรับ prompt เดียวกัน ขึ้นอยู่กับว่า Claude ตัดสินใจทำงานมากน้อยแค่ไหน
ซึ่งนั่นคือสิ่งที่ระดับความพยายามควบคุมนั่นเอง
วิธีการทำงานของความพยายาม
ขณะที่ Claude Code กำลังทำงานในงานหนึ่ง โทเคนที่มันสร้างขึ้นจะแบ่งออกเป็นบางประเภท:
- การคิด (Thinking): การใช้เหตุผลที่คุณเห็นสตรีมมิ่งก่อนและระหว่างการดำเนินการ
- การเรียกใช้เครื่องมือ (Tool calls): บล็อกที่มีโครงสร้างซึ่งระบุชื่อเครื่องมือ เช่น Read หรือ Edit และอาร์กิวเมนต์ของมัน ซึ่ง Claude Code จะแยกวิเคราะห์และดำเนินการ
- ข้อความถึงคุณ (Text to you): แผน, อัปเดตความคืบหน้า, สรุปตอนท้าย
สิ่งเหล่านี้ล้วนเป็นโทเคนเอาต์พุตธรรมดาจากลูปเดียวกัน ซึ่งถูกคิดค่าบริการในอัตราเดียวกัน ตัวอย่างเช่น โทเคนการคิดถูกสร้างขึ้นเหมือนกับโทเคนเอาต์พุตอื่นๆ และคงอยู่ในบริบทสำหรับการเทิร์นนั้นๆ ที่เหลือ
เมื่อถึงเวลาที่ Claude เริ่มเขียนโค้ด การใช้เหตุผลก่อนหน้านี้ของมันก็กลายเป็นส่วนหนึ่งของอินพุต เช่นเดียวกับไฟล์ที่มันอ่าน
เอาต์พุตทั้งหมดของ Claude คือโทเคน การคิด, การเรียกใช้เครื่องมือ, และข้อความถึงคุณ ล้วนถูกสร้างขึ้นจากลูปเดียวกัน
แล้วความพยายามเปลี่ยนสิ่งเหล่านี้ได้อย่างไร? ระดับความพยายามจะ ถูกส่งไปยังโมเดลเป็นส่วนหนึ่งของคำขอ พร้อมกับ prompt ของคุณ โมเดลได้รับการฝึกฝนให้เข้าใจวิธีปฏิบัติตนในแต่ละระดับความพยายาม และพฤติกรรมที่เรียนรู้นี้ถูกฝังอยู่ในน้ำหนักที่ถูกแช่แข็ง
เมื่อคำขอของคุณมาถึง ความพยายามเป็นเพียงอินพุตอีกอย่างหนึ่งที่โมเดลตอบสนอง เช่นเดียวกับที่มันตอบสนองต่อข้อความ prompt ของคุณ มันกำหนดว่าต้องละเอียดถี่ถ้วนแค่ไหน และต้อง แน่ใจ แค่ไหน ก่อนที่ Claude จะถือว่างานเสร็จสมบูรณ์ สิ่งนี้จะถูกชั่งน้ำหนักในทุกเทิร์น และความมั่นใจที่สูงขึ้นต้องใช้โทเคนมากขึ้นเพื่อไปถึง
Prompt เดียวกัน สองระดับความพยายาม เส้นทางที่มีความพยายามสูงสร้างโทเคนมากกว่าประมาณ 7 เท่า เพื่อไปถึงคำตอบที่มีความมั่นใจสูงขึ้น
ที่ระดับความพยายามสูงขึ้น Claude มักจะเริ่มต้นด้วยการสร้างแผน และระดับความพยายามมีอิทธิพลต่อความลึกและขอบเขตของแผนนั้น แต่แผนไม่ได้ถูกตรึงไว้กับที่ เมื่อ Claude ได้รับผลลัพธ์กลับมาจากการกระทำของมัน มันจะอัปเดตภาพของมันว่ามันคืบหน้าไปเท่าไหร่แล้ว และมันแน่ใจแค่ไหนกับผลลัพธ์ที่สะสมมา
เมื่อขั้นตอนที่ 1 ของแผนการดีบักสามสมมติฐานพบจุดบอด "ตรวจสอบสมมติฐานที่ 2 และ 3" อาจไม่จำเป็นอีกต่อไป โดยทั่วไป Claude จะพูดสิ่งนี้อย่างชัดเจน (เช่น "การตรวจสอบครั้งแรกพบแล้ว ดังนั้นการตรวจสอบที่เหลือจึงไม่จำเป็น") และข้ามไปข้างหน้า คุณเห็นสิ่งนี้เกิดขึ้นใน Claude Code เมื่อรายการงานได้รับการแก้ไขระหว่างการทำงาน
ความพยายามที่สูงขึ้นทำให้ Claude มีแนวโน้มที่จะตรวจสอบซ้ำมากขึ้น เช่น การตรวจสอบคำตอบที่มันพบ หรือยังคงตรวจสอบสมมติฐานที่มันอาจข้ามไป อย่างไรก็ตาม โดยทั่วไปแล้วมันจะไม่ทำให้การใช้งานพุ่งสูงเกินจริงในงานง่ายๆ เพียงเพราะระดับความพยายามถูกปรับขึ้น "การคิดมากเกินไป (Overthinking)" เป็นสิ่งที่ทีมของเราคอยสังเกตเป็นพิเศษระหว่างการฝึกโมเดล เนื่องจากมันลดประสิทธิผล
การเลือกระดับความพยายาม
สำหรับงานส่วนใหญ่ ให้ใช้ระดับความพยายามเริ่มต้นของโมเดล ค่าเริ่มต้นคือระดับที่ Claude ปรับขนาดการใช้โทเคนให้ตรงกับสิ่งที่คนส่วนใหญ่ต้องการใช้จ่ายในงานหนึ่งๆ
ให้นึกถึงความพยายามเหมือนโอเวอร์ไรด์แบบแมนนวลว่า Claude จะทำงานหนักและนานแค่ไหน ให้หยิบมันมาใช้อย่างจงใจเมื่อคุณมีความชอบที่ชัดเจนในเรื่องความละเอียดถี่ถ้วนหรือความรวดเร็ว โดยขึ้นอยู่กับโดเมนของคุณหรือประเภทของงานที่คุณทำ และปฏิบัติต่อมันเหมือนความชอบทั่วไป ไม่ใช่การตัดสินใจทีละงาน
ข้อสังเกตในทางปฏิบัติหนึ่งหลังจากเปิดตัว Opus 4.8: ในการทดสอบของเรา การตั้งค่าความพยายามเริ่มต้นบน Opus 4.8 ให้ผลลัพธ์ที่ดีกว่าโดยใช้โทเคนประมาณเท่ากับการตั้งค่าความพยายามเริ่มต้นบน Opus 4.7 สำหรับงานเดียวกัน
จะเปลี่ยนอะไรเมื่อ Claude ทำผิด
เมื่อ Claude ทำอะไรผิด สัญชาตญาณแรกของคุณไม่ควรเป็นการเปลี่ยนการตั้งค่า ควรเป็นการดูบริบทที่คุณให้ไว้ Prompt ของคุณคลุมเครือเกินไปหรือไม่? Claude เชื่อมต่อกับเครื่องมือที่ถูกต้องหรือไม่? มันมีทักษะที่เหมาะสมหรือไม่?
หากคุณกำลังเพิ่มความพยายามในงานที่ไม่ควรต้องการมัน วิธีแก้ไขมักจะอยู่ที่ต้นทาง: ในบริบทของคุณ, ใน CLAUDE.md ของคุณ, หรือวิธีการกำหนดขอบเขตของงาน
แต่สมมติว่าคุณได้ให้บริบทที่ชัดเจนแล้วและ Claude ก็ยังทำผิด คำถามที่คุณต้องถามตัวเองคือ: มันไม่ได้พยายามมากพอ หรือมันไม่มีความรู้เพียงพอ?
โมเดล: ปัญหานั้นยากเกินไป
เลือกโมเดลที่ใหญ่กว่าเมื่อปัญหานั้นยากจริงๆ เช่น บั๊กที่ซับซ้อน, โดเมนที่ไม่คุ้นเคย, การตัดสินใจทางสถาปัตยกรรม โมเดลที่ใหญ่กว่าคือสิ่งที่คุณต้องการเมื่อโมเดลเล็กกว่า มั่นใจแต่ผิด ไม่ว่าคุณจะให้บริบทมากแค่ไหนก็ตาม
โมเดลที่ใหญ่กว่ายังจัดการกับความคลุมเครือได้ดีกว่า สำหรับโมเดลที่เล็กกว่า คำแนะนำเฉพาะที่ชี้แนะการดำเนินการเป็นสูตรสำเร็จที่ดีกว่า
เลือกโมเดลที่เล็กกว่าเมื่องานนั้นเป็นงานประจำ: การแก้ไขที่คุณสามารถอธิบายได้อย่างแม่นยำ, การเปลี่ยนแปลงเชิงกล, คำถามเกี่ยวกับโค้ดที่อยู่ในบริบทแล้ว ไม่มีเหตุผลที่จะจ่ายค่าความสามารถที่งานไม่ต้องการ
หาก Claude มีบริบทที่เกี่ยวข้องทั้งหมด พยายามอย่างชัดเจน และยังคงทำผิด นั่นคือสัญญาณให้เลือกโมเดลที่ใหญ่กว่า และถ้าคุณใช้โมเดลที่ใหญ่กว่าและงานนั้นเป็นงานประจำมาระยะหนึ่งแล้ว การลดขนาดลงจะเพิ่มความเร็วและโดยทั่วไปจะลดต้นทุนโดยไม่กระทบต่อคุณภาพของผลลัพธ์
ความพยายาม: Claude พยายามไม่มากพอ
เลือกระดับความพยายามที่สูงขึ้นหาก Claude ทำผิดเพราะมันไม่พยายามมากพอ: ข้ามไฟล์, ไม่รันเทสต์, หรือไม่ตรวจสอบงานของมันซ้ำ สิ่งนี้เกี่ยวข้องมากที่สุดหากคุณเลือกระดับความพยายามที่ต่ำกว่าค่าเริ่มต้นของโมเดล
ผู้เชี่ยวชาญเฉพาะด้าน ผู้เชี่ยวชาญ และผู้รอบรู้ทั่วไป
วิธีหนึ่งที่ฉันชอบคิดเกี่ยวกับการตั้งค่าทั้งสองแบบนี้คือ Fable คือผู้เชี่ยวชาญเฉพาะด้านที่สามารถจัดการปัญหาที่แทบจะไม่มีใครอื่นทำได้ Opus คือผู้เชี่ยวชาญ และ Sonnet คือผู้รอบรู้ทั่วไปที่เก่งมาก ระดับความพยายามเป็นตัวตัดสินว่าแต่ละคนใช้เวลากับงานของคุณมากแค่ไหน
Opus ที่ความพยายามต่ำก็เหมือนกับการได้เวลาห้านาทีกับผู้เชี่ยวชาญที่มีประสบการณ์ลึกซึ้งกับปัญหาแบบเดียวกับของคุณ พวกเขานำความรู้ที่ไม่มีอยู่ใน codebase ของคุณมาด้วย: รูปแบบที่เคยเห็นมาก่อน, ข้อควรระวังที่รู้ว่าต้องตรวจสอบ, ประสบการณ์แบบที่คุณจะได้รับจากการแก้ปัญหาที่คล้ายกันหลายๆ ครั้งเท่านั้น แต่ห้านาทีหมายถึงการอ่านโค้ดของคุณอย่างรวดเร็ว ไม่ใช่การตรวจสอบอย่างละเอียดทุกไฟล์
Sonnet ที่ความพยายามสูงคือผู้รอบรู้ทั่วไปที่มีเวลาทั้งบ่าย พวกเขาเก่งในการเขียนโค้ด และพวกเขาจะอ่านทุกอย่าง, รันทุกอย่าง, ตรวจสอบงานของตนซ้ำ และสุดท้ายจะเข้าใจโค้ดเฉพาะของคุณอย่างถ่องแท้
Fable คือผู้เชี่ยวชาญเฉพาะด้านที่คุณเรียกหาเมื่อคนอื่นๆ ติดขัด แม้ที่ความพยายามต่ำ พวกเขาจะเห็นสิ่งที่ไม่มีใครอื่นเห็น การจดจำนั้นคือสิ่งที่คุณจ่ายเงินมากที่สุดเช่นกัน ดังนั้นจึงคุ้มค่าที่จะเก็บไว้ใช้สำหรับงานที่ต้องการมันจริงๆ
ไม่มีสิ่งใดในนี้ที่ "ดีกว่า" ในทุกสถานการณ์ การตั้งค่าโมเดลคือ ความสามารถ โดยประมาณ; การตั้งค่าความพยายามคือ ความละเอียดถี่ถ้วน โดยประมาณ งานจริงส่วนใหญ่ต้องการทั้งสองอย่างในระดับหนึ่ง
ความพยายาม โมเดล และการบริโภคโทเคน
แล้วการเลือกโมเดล, ความพยายาม และการบริโภคโทเคนมีปฏิสัมพันธ์กันอย่างไร? ขึ้นอยู่กับงาน
สำหรับงานประจำที่ระดับความพยายามเดียวกัน ทั้งโมเดลที่ใหญ่กว่าและเล็กกว่ามักจะทำได้ถูกต้อง โมเดลที่ใหญ่กว่าใช้โทเคนมากขึ้นกับขั้นตอนการตรวจสอบเพิ่มเติม ในราคาต่อโทเคนที่สูงกว่า นั่นคือสาเหตุที่การลดลงมาใช้โมเดลเล็กกว่าสำหรับงานประจำเป็นช่วงๆ จะช่วยประหยัดเงินจริงโดยไม่สูญเสียคุณภาพ
เส้นโค้งเป็นเพียงภาพประกอบเท่านั้น แสดงสำหรับงานเดียวที่ง่ายพอที่ทั้งสองโมเดลจะทำให้สำเร็จได้อย่างรวดเร็ว ไม่ได้แสดงถึงข้อมูลเกณฑ์มาตรฐานจริง
สำหรับงานที่ยากกว่าและมีหลายขั้นตอน สมการจะพลิกกลับ โมเดลที่เล็กกว่าต้องฝ่าฟันไปจนถึงขีดจำกัดความสามารถของมัน ใช้การทำซ้ำหลายครั้ง ในขณะที่โมเดลที่ใหญ่กว่าถึงเกณฑ์คุณภาพเดียวกันในขั้นตอนที่น้อยกว่า
คุณจ่ายต่อโทเคนมากขึ้นสำหรับโมเดลที่ใหญ่กว่า แต่สำหรับงานที่ท้าทายโมเดลเล็กกว่าอย่างแท้จริง ต้นทุนรวมต่องานอาจ น้อยกว่า และที่สำคัญกว่านั้น: โมเดลที่ใหญ่กว่าสามารถทำงานที่โมเดลเล็กกว่าไม่สามารถทำได้สำเร็จ แม้จะตั้งค่าระดับความพยายายามสูงสุดก็ตาม
สิ่งนี้เด่นชัดที่สุดกับ Fable สำหรับงานที่ยาวและมีหลายขั้นตอน มันจะทำได้ดีกว่ามาก ในการทดสอบของเรา มันทำงานที่ Opus และ Sonnet ไม่สามารถไปถึงได้ในทุกระดับความพยายาม มันยังมีราคาต่อโทเคนสูงที่สุด ซึ่งเป็นอีกเหตุผลที่ควรเก็บไว้ใช้สำหรับงานที่ต้องการมันจริงๆ
เส้นโค้งเป็นเพียงภาพประกอบเท่านั้น แสดงสำหรับงานเดียวที่ยากพอที่จะท้าทายทั้งสองโมเดล ไม่ได้แสดงถึงข้อมูลเกณฑ์มาตรฐานจริง
ประเด็นสำคัญในกราฟด้านบน: ความพยายามกำหนดว่า Claude เต็มใจ ที่จะเดินทางไปไกลแค่ไหนตามเส้นโค้ง นั่นไม่ได้หมายความว่า Claude จำเป็นต้องไปไกลขนาดนั้นเพื่อทำงานให้เสร็จ
สุดท้าย ความพยายามกำหนดรูปแบบการบริโภคโทเคน แต่ไม่ได้ จำกัด มัน ขีดจำกัดแบบตายตัวเพียงอย่างเดียวในระบบคือ max_tokens ซึ่งจะตัดการตอบสนองกลางคันเมื่อถึงขีดจำกัด แต่มันเป็นเครื่องมือที่หยาบและเกี่ยวข้องกับนักพัฒนา API เป็นหลัก การควบคุมที่นุ่มนวลกว่า เช่น task budgets หรือการขอให้ Claude กระชับใน prompt ของคุณนั้นมีประโยชน์มากกว่า มันเป็นคำแนะนำที่โมเดลได้รับการฝึกฝนให้ปฏิบัติตาม (มันจะพยายามสรุปเมื่อใกล้ถึงขีดจำกัด) มากกว่าที่จะเป็นกำแพงที่มันชนเข้าไป
ความพยายามเปลี่ยนปริมาณงานที่ Claude ทำ โมเดลเปลี่ยนสิ่งที่ Claude รู้
เมื่อคุณไม่พอใจกับผลลัพธ์ ให้ตรวจสอบบริบทก่อนที่จะแตะต้องการตั้งค่าใดๆ: ให้ prompt ที่ชัดเจนแก่ Claude, เครื่องมือและทักษะที่เหมาะสม, และวิธีการตรวจสอบงานของตนเอง
หาก Claude ยังคงทำผิด ให้ถามตัวเอง: มันไม่มีความรู้เพียงพอ หรือมันไม่พยายามมากพอ? การไม่มีความรู้เพียงพอเป็นปัญหาเรื่องโมเดล การไม่พยายามมากพอเป็นปัญหาเรื่องความพยายาม
บทความนี้เขียนโดย @lydiahallie สมาชิกทีมปฏิบัติการด้านเทคนิคของทีม Claude Code
