Claude Sonnet 4 รองรับคอนเท็กซ์ 1 ล้านโทเค็นแล้ว
(anthropic.com)- Claude Sonnet 4 ของ Anthropic รองรับคอนเท็กซ์ได้สูงสุด 1 ล้านโทเค็น ทำให้สามารถประมวลผลโค้ดเบสขนาดใหญ่หรือเอกสารจำนวนมากได้ในครั้งเดียว
- คอนเท็กซ์ที่ยาวขึ้นช่วยให้รองรับการใช้งานที่หลากหลาย เช่น การวิเคราะห์โค้ดขนาดใหญ่, การประมวลผลชุดเอกสารมหาศาล และการพัฒนาเอเจนต์ที่รักษาคอนเท็กซ์ต่อเนื่องได้
- สำหรับพรอมป์ต์ที่เกิน 200,000 โทเค็น จะมีการ ปรับขึ้นค่าบริการ API และสามารถลดต้นทุนได้ด้วย prompt caching และการประมวลผลแบบแบตช์
- ลูกค้าจริงอย่าง Bolt.new และ iGent AI ได้เพิ่มประสิทธิภาพการทำงานและความสามารถด้าน AI อย่างมากด้วยฟีเจอร์นี้
- ขณะนี้การรองรับ long context ของ Sonnet 4 เปิดให้ใช้งานแบบเบตาบน Anthropic API และ Amazon Bedrock และมีแผนจะเปิดตัวบน Google Cloud ในเร็ว ๆ นี้
รองรับคอนเท็กซ์ 1 ล้านโทเค็น
- Claude Sonnet 4 ที่ใช้งานผ่าน Anthropic API รองรับคอนเท็กซ์ได้สูงสุด 1 ล้านโทเค็นแล้ว
- ทำให้สามารถประมวลผลโค้ดทั้งชุดที่ยาวเกิน 75,000 บรรทัด หรือรวมวิเคราะห์งานวิจัยหลายฉบับได้ภายในการเรียกใช้งานครั้งเดียว
- ฟีเจอร์เบตาคอนเท็กซ์ 1 ล้านโทเค็นเปิดให้ใช้งานแล้วบน Anthropic API และ Amazon Bedrock ส่วน Vertex AI ของ Google Cloud จะรองรับในเร็ว ๆ นี้
คอนเท็กซ์ที่ยาวขึ้น พร้อมกรณีใช้งานที่กว้างขึ้น
- การวิเคราะห์โค้ดขนาดใหญ่: สามารถโหลดทั้งโค้ดเบส (รวมไฟล์ซอร์ส, เทสต์ และเอกสาร) เข้ามาได้พร้อมกัน เพื่อทำความเข้าใจโครงสร้างโปรเจกต์, วิเคราะห์ความเชื่อมโยงระหว่างไฟล์ และเสนอแนะแนวทางปรับปรุงโค้ดบนพื้นฐานของการออกแบบระบบ
- การสรุปเอกสารแบบรวมศูนย์: วิเคราะห์สัญญากฎหมาย, งานวิจัย และสเปกทางเทคนิคหลายร้อยฉบับพร้อมกัน พร้อมรักษาความสัมพันธ์ระหว่างเอกสารเพื่อสกัดอินไซต์เชิงภาพรวมได้
- เอเจนต์ที่รักษาคอนเท็กซ์ต่อเนื่อง: แม้จะมีการเรียกใช้เครื่องมือหลายร้อยครั้งหรือผ่านเวิร์กโฟลว์หลายขั้นตอน ก็ยังสามารถพัฒนา conversational agent ที่คงสถานะอย่างสม่ำเสมอได้ โดยรวมทั้ง เอกสาร API ทั้งชุด, นิยามเครื่องมือ และประวัติการโต้ตอบ ไว้ในคอนเท็กซ์
นโยบายราคา API
- พรอมป์ต์ไม่เกิน 200,000 โทเค็น: อินพุต $3/ล้านโทเค็น, เอาต์พุต $15/ล้านโทเค็น
- พรอมป์ต์เกิน 200,000 โทเค็น: อินพุต $6/ล้านโทเค็น, เอาต์พุต $22.5/ล้านโทเค็น
- เมื่อใช้ prompt caching จะช่วย ลดทั้งเวลาแฝงและต้นทุนได้
- หากใช้คอนเท็กซ์ 1 ล้านโทเค็นร่วมกับ การประมวลผลแบบแบตช์ จะช่วยลดต้นทุนเพิ่มเติมได้สูงสุด 50%
กรณีใช้งานของลูกค้า
-
Bolt.new
- Bolt.new ผสาน Claude เข้ากับ แพลตฟอร์มพัฒนาแบบเว็บ เพื่อสร้างความเปลี่ยนแปลงให้กับการพัฒนาเว็บ
- "หน้าต่างคอนเท็กซ์ 1 ล้านโทเค็นของ Sonnet 4 ทำให้นักพัฒนาสามารถจัดการโปรเจกต์ที่ใหญ่ขึ้นได้ด้วย ความแม่นยำ ที่สูง"
-
iGent AI
- iGent AI ซึ่งตั้งอยู่ในลอนดอน สหราชอาณาจักร ใช้ AI partner ชื่อ Maestro เพื่อแปลงบทสนทนาให้เป็นโค้ดที่นำไปใช้งานได้จริง
- "ความสามารถด้าน วิศวกรรมซอฟต์แวร์อัตโนมัติ ที่เดิมทำไม่ได้มาก่อน กลายเป็นจริงได้ด้วยคอนเท็กซ์ 1 ล้านโทเค็นของ Sonnet 4 ทำให้สามารถทำงานเป็นเซสชันต่อเนื่องหลายวันบนโค้ดเบสจริงได้"
วิธีใช้งานและแผนในอนาคต
- ฟีเจอร์ long context เปิดให้ลูกค้า Tier 4 และแพ็กเกจราคาแบบคัสตอม ของ Anthropic API ใช้งานแบบเบตาแล้ว และมีแผนขยายให้ผู้ใช้วงกว้างขึ้นภายในไม่กี่สัปดาห์
- ขณะนี้รองรับบน Amazon Bedrock แล้ว และการรองรับบน Google Cloud Vertex AI ก็จะมาในเร็ว ๆ นี้
- มีแผนนำ long context ไปใช้กับ ตระกูลผลิตภัณฑ์ Claude อื่น ๆ ด้วย
- ดูรายละเอียดเพิ่มเติมได้ใน เอกสารทางการและหน้าคำอธิบายราคา
1 ความคิดเห็น
ความเห็นบน Hacker News
รู้สึกอย่างยิ่งว่าในการทำงานวิศวกรรมซอฟต์แวร์ระดับมืออาชีพ การที่ LLM รักษาบริบทได้ดีจริง ๆ เป็นสิ่งจำเป็นมาก ข่าวประกาศว่าโมเดลใหม่ดีขึ้นอีกนิดจึงไม่ค่อยน่าสนใจนักในงานจริง แต่ราคากลับเป็นปัจจัยตัดสินที่ใหญ่ที่สุด การยัด codebase ของฉันเข้าไปใน context window ได้มากพอถือว่าเป็นเรื่องดี แต่พอราคาขึ้นแรงแบบนี้ ตอนนี้ฉันคิดว่าควรบริหารคอนเท็กซ์ให้ดีขึ้นจะเหมาะกว่า การที่ฉันใช้ context window เยอะเป็นผลดีกับผู้ให้บริการก็จริง แต่ Sonnet จะรักษาโฟกัสได้มีประสิทธิภาพแค่ไหนยังต้องประเมินแยกอีกที เลยยังมั่นใจคุณค่าที่แท้จริงได้ยาก
คอนเท็กซ์อยู่ใน repo และเราต้องยอมรับว่า LLM ไม่มีทางมีคอนเท็กซ์ที่ต้องใช้ทั้งหมดได้เสมอ โดยเฉพาะ repo ขนาดใหญ่ที่ใส่ในเครื่องเดียวไม่หมด ถ้าจะทำงานเฉพาะอย่างให้สำเร็จ ก็ต้องตัดข้อมูลที่ไม่จำเป็นออกเพื่อให้โฟกัสได้ การใส่ทุกอย่างเข้าไปกลับทำให้เสียสมาธิ เมื่อก่อนขนาดหน้าต่างเล็กเกินไป และตอนนี้ฉันก็ยังคิดว่าเล็กอยู่ แต่ท้ายที่สุดแล้ว สิ่งที่ต้องมีคือความสามารถในการเข้าใจ repo ผ่านการตั้งคำถามที่ถูกต้อง
ถ้าใส่คอนเท็กซ์มากเกินไป ความเสี่ยงที่ LLM จะสับสนเองก็สูงขึ้น เพราะทำงานต่อเนื่องด้วยคอนเท็กซ์ยาว ๆ โดยไม่รีเซ็ตแล้วโฟกัสจะเริ่มหลุด
คิดว่าควรฝึกให้ AI จัดการเฉพาะข้อมูลเชิงนามธรรม ไม่ใช่ทั้ง codebase เพราะมนุษย์จริง ๆ ก็ไม่ได้ทำงานโดยเก็บโค้ดทั้งหมดไว้ในหัว ดังนั้น LLM ก็ไม่จำเป็นต้องทำแบบนั้น
หลังจากทำงานกับ Claude Code มาหลายสัปดาห์ ไม่นานมานี้ก็สรุปได้ว่ามูลค่าที่ใช้งานได้จริงของ AI แบบเอเจนต์กลับติดลบเสียมากกว่า ถึงอย่างนั้นก็ตั้งใจว่าจะลองใหม่อีกครั้งในอีก 6-8 เดือน
คิดว่าจุดประสงค์ไม่ได้มีแค่การใส่โค้ดให้มากขึ้นในคอนเท็กซ์ในคราวเดียว งานบางอย่างมีบริบทขั้นต่ำที่จำเป็นก็จริง แต่โมเดล 1M context ต้องการวิธีใหม่ในการป้อนข้อมูลเข้าไป จุดแข็งจริงของโมเดลนี้อยู่ที่ปัญหาแบบ deep dive เช่น การสำรวจซ้ำระยะยาว, in-context learning, และการสร้างใหม่ ตัวอย่างเช่น มีทั้งงานแบบกว้างที่ต้องเปลี่ยน API ใน 100 ไฟล์ และงานแบบลึกที่ต้องลอง 15 วิธีเพื่อหาทางแก้ Sonnet 1M เด่นเป็นพิเศษกับงานประเภทหลัง
เสนอเคล็ดลับบางอย่างสำหรับผู้ใช้ที่กังวลเรื่องการใช้โทเค็นกับ Claude Code
/resumeเพื่อเรียก thread เดิม แล้ว double escape กลับไปยังจุดที่คอนเท็กซ์แน่น ๆ เพื่อรีเซ็ตได้ใช้วิธีบอก Claude ว่า “ในเซสชันอื่นคุณเขียนงาน X ไว้” แล้วใช้คอนเท็กซ์นั้นในการถามหรือขอแก้ไข
ฉันก็ทำแบบนั้นบ่อย แต่ก็ไม่ได้เวิร์กเสมอไป บางครั้งการใช้ Claude โดยให้ถือบริบททั้งบทสนทนาไว้กลับช่วยได้มากกว่า
เวลาแฝงลดลงมาก ไม่ต้องรอให้ Claude ตัวใหม่โหลดคอนเท็กซ์ตั้งแต่ต้นอีก
กระบวนการนี้ให้ความรู้สึกเหมือนโหราศาสตร์สำหรับโปรแกรมเมอร์ (astrogy) เพราะถ้าไม่พูดออกไป ก็ไม่มีทางรู้ว่าอะไรจะเกิดขึ้นระหว่างที่เอเจนต์กำลังทำงานกับ codebase
สิ่งที่น่าสนใจคือสงสัยว่าทำไม Claude ถึงหาปัญหาได้มากกว่าเมื่อบอกว่าโค้ดนี้เขียนโดยนักพัฒนาคนอื่น
วิธีใช้ Claude Code ที่ช่วยได้มากที่สุดจนถึงตอนนี้คือถามตรง ๆ ว่า "มีบั๊กใน diff ปัจจุบันไหม?" แล้วแชตบอตจะไล่วิเคราะห์การเปลี่ยนแปลงอย่างละเอียด จับบั๊กเล็ก ๆ ที่ปกติต้องใช้เวลานานและผ่านการ deploy หลายรอบกว่าจะเจอได้อย่างรวดเร็ว พร้อมบอกเป็นข้อ ๆ ว่าจะทำให้โค้ดถูกต้องขึ้นได้อย่างไร
น่าทึ่งตรงที่ไม่ต้องสั่งเพิ่มว่า “ช่วยคิดให้ลึกขึ้น” มันก็ทำได้ตามต้องการอยู่แล้ว
จากประสบการณ์ที่ใช้กับงานที่ไม่ใช่การเขียนโค้ด มันอาจไม่ค่อยสร้างสรรค์ แต่เก่งมากในบทบาทผู้อ่านที่วิจารณ์เก่งและละเอียดรอบคอบ
มีข้อเสนอว่าควรนำความสามารถนี้ไปทำเป็น hook ของ Claude Code แบบเป็นรูปธรรม
เจ้าตัวก็บอกว่าจะลองวิธีนี้ทันทีตั้งแต่พรุ่งนี้
ประสบการณ์ของฉันกับเครื่องมือในตอนนี้เป็นแบบนี้
ฉันก็คล้ายกัน (Cline + Sonnet & Gemini มา 1 ปี) จนมาเจอ Claude Code และที่สำคัญที่สุดคือได้เรียนรู้วิธี “จัดการคอนเท็กซ์ให้สะอาดจริง ๆ” แล้วรู้สึกว่าเจอทางตันที่แตกออกทันที กุญแจคือปฏิบัติกับ AI ไม่ใช่เป็นเครื่องสร้างโค้ด แต่เป็นเหมือนสถาปนิกและผู้ลงมือทำ ช่วงหลังฉันจะให้ CC เขียน design document สำหรับงานที่เรากำลังจะทำก่อนเสมอ แล้วสั่งให้มันอ้างอิงทั้งโค้ดและเอกสารนั้น ฉันตรวจทานเอกสารเพื่อยืนยันทิศทางให้ชัด จากนั้นแบ่งขั้นงานออกเป็น chunk และย่อยแต่ละ chunk อีก พอกำหนดเริ่มต้นเสร็จ ก็ล้างบริบท แล้วให้มันอ่านเอกสารทีละขั้นก่อนลงมือทำ ถ้าจำเป็นก็ปรับทิศทางหรือแก้เอกสารแล้วเริ่มเฉพาะขั้นนั้นใหม่ commit แยกทุกขั้น ล้างบริบท แล้วไปขั้นถัดไป ทำแบบนี้ฟีเจอร์ที่เมื่อก่อนใช้เวลา 2-3 วันก็เสร็จในวันเดียวได้ ผลลัพธ์คือได้งานที่มีเอกสารผ่านการตรวจสอบ, unit test, Storybook, accessibility (
araiเป็นต้น) ครบถ้วน และตอนท้ายก็ให้โมเดลอื่นรีวิวโค้ดอีกที แม้ตอนนี้อาจยังเร็วไม่สุดโต่ง แต่คิดว่าเป็นการลงทุนกับทักษะสำหรับอนาคตของเครื่องมือที่ยังเติบโตอยู่สำหรับฉัน เครื่องมือนี้ให้ความรู้สึกคล้าย scaffolding ของ
rails newใน Ruby on Rails สมัยก่อน LLM เหมาะมากกับงานที่แค่ต้องเข้าใจเอกสารทางการของเครื่องมือเพื่อสร้างโครงเริ่มต้นของโปรเจกต์ แต่จะมีประโยชน์น้อยลงกับระบบ legacy หรือโปรเจกต์ที่มีข้อกำหนดภายนอกเยอะ ๆ และแทบใช้ไม่ได้เลยกับเครื่องมือที่เปลี่ยนเร็วอย่าง Databricks ถ้าชื่อ ไวยากรณ์ หรือฟีเจอร์เปลี่ยนไปหลังช่วงข้อมูลฝึก ก็แทบต้องยัดเอกสารแบบเรียลไทม์เข้าไปในพรอมป์ตอย่างจริงจังถึงจะพอมีหวังเวิร์กโฟลว์ของฉันใช้ Claude desktop คู่กับ filesystem ของ mcp server บอก path ของไฟล์ที่เกี่ยวข้องให้ Claude แล้วสั่งให้แก้งาน Claude จะอ่านไฟล์เอง วิเคราะห์เอง และแก้หรือเพิ่มสิ่งที่ต้องใช้ให้ ปกติฉันแค่แปะ build error สองสามอย่าง มันก็แก้ต่อให้ได้ ที่น่าประทับใจคือมันเขียนโค้ดใหม่โดยรักษาสไตล์โค้ดเดิมไว้ได้ดี ฉันใช้กับ Typescript และ C# และจากประสบการณ์ ผลลัพธ์ไม่ได้หยุดอยู่แค่ระดับงานอดิเรก
ฉันไม่ใช่โปรแกรมเมอร์ แต่ทำงานที่ต้องใช้โค้ด Python กับ bash และยังดูแลโปรเจกต์ส่วนตัวกับเว็บไซต์อยู่หลายตัว Claude Code ทำให้ฉันทำโปรเจกต์เล็ก ๆ ที่เมื่อก่อนทำไม่ได้เพราะทั้งขาดทักษะและเวลาได้แล้ว ตอนนี้ยังปรับแต่งสภาพแวดล้อม emacs เองได้ ให้มันเขียนฟังก์ชัน lisp ก็ทำได้คล่อง นี่คือเครื่องมือที่สมบูรณ์แบบสำหรับฉันจริง ๆ มันช่วยปลดล็อกงานที่เคยติดขัดและทำให้ชีวิตง่ายขึ้น
เคยใช้กับ Typescript, Go, SQL, Rust โดย Rust ซับซ้อนเกินไปจนเต็มไปด้วย error และอยากปิดโปรเจกต์นี้ให้ไว (แม้ตัวโปรเจกต์เองจะยากมากอยู่แล้ว) ส่วน Go นั้นภาษาเรียบง่ายมากจึงทำงานได้มีประสิทธิภาพสุด ๆ เร็วขึ้น 2 เท่า Typescript ก็ใช้กับ React component/animation ได้ดี SQL/PostgreSQL ก็เช่นกัน ฉันเกลียด boilerplate ของ stored procedure แต่ LLM ช่วยลดตรงนี้ลงได้ เลยปวดข้อมือน้อยลง
การมีตัวเลือกมากขึ้นแบบนี้แน่นอนว่าเป็นเรื่องดี แต่ในขณะเดียวกัน ถ้าใส่คอนเท็กซ์มากเกินไป คุณภาพผลลัพธ์ของ LLM ก็อาจลดลงได้ เพราะมันจะเสียสมาธิง่ายขึ้น ถ้าผู้ใช้ไม่เข้าใจ trade-off นี้และพึ่งโหมดอัตโนมัติอย่างเดียว ก็เป็นห่วงคุณภาพโค้ดที่ Claude Code เขียนออกมา
มีการแนะนำลิงก์บทความที่น่าอ้างอิงสองสามชิ้น
ตอนนี้คอนเท็กซ์ยาวยังไม่ได้ถูกรวมเข้าใน Claude Code โดยตรง เขาบอกว่า “กำลังพิจารณาวิธีนำคอนเท็กซ์ยาวไปใช้กับผลิตภัณฑ์อื่น ๆ ด้วย” จึงคิดว่าน่าจะตระหนักถึงปัญหานี้แล้วและกำลังหาทางแก้ ดูเหมือนอยากออกโซลูชันก่อนที่ผู้ใช้จะเริ่มก่อค่าใช้จ่ายเพิ่มบนแพ็กเกจราคาแพง
มีคนถามว่าแล้วจะแนะนำทางเลือกอะไร เพราะเริ่มชินกับ Claude Code แล้ว แต่ยังไม่คล่องเรื่อง best practice
ทีม Chroma กำลังวิจัยปัญหานี้อยู่ และน่าจะมีข้อมูลเชิงตัวเลขออกมาในอนาคต
มีคนถามว่า Opus ไม่ดีกว่าเหรอ และบอกว่าพอใช้โทเค็นหมดแล้วถูกบังคับสลับไป Sonnet จะรู้สึกถึงความต่างชัดมาก ในฐานะคนที่มีประสบการณ์เพิ่มขึ้นและมีไอเดียล้น แต่การเขียนโค้ดยังลำบาก หลัง Claude ปรากฏตัวก็รู้สึกว่าทั้งการสร้างไอเดียให้เป็นจริง การทดสอบ และการแก้บั๊กทำได้คล่องไปหมด
ปัญหาใหญ่ของแอปแชต (ChatGPT, Claude.ai) คือพฤติกรรมแปลก ๆ เกี่ยวกับ context window เช่น ถูกตัดแบบกะทันหัน, ถูกสรุปย่อ, หรือมี “ghost snippet” โผล่กลับมาแทรกใหม่ ผู้ใช้อาจรู้สึกว่าสะดวกกว่าถ้าจะเลือกเองว่าจะรักษาคอนเท็กซ์เดิมต่อหรือเริ่มแชตใหม่ แต่ในความเป็นจริงก็เลี่ยงไม่ได้เพราะข้อจำกัดของแพ็กเกจราคาและคอมพิวต์ จริง ๆ แล้วถ้าจะส่งทั้งคอนเท็กซ์ได้ครบถ้วน ต้องใช้เครื่องมือสำหรับนักพัฒนาอย่าง Google AI Studio หรือแอปแชตที่ครอบ API เอง ถ้าทำ custom chat app ก็สามารถใส่ timestamp ในทุกข้อความ แล้วสั่ง LLM ให้ “ทุก 10 นาที สรุปสิ่งที่คุยกันในช่วงนั้นลงเป็นแถวใหม่ในตาราง Markdown” ได้ด้วย
คิดว่านี่เป็นครั้งแรกที่แพ็กเกจราคาแบบนี้ยอมรับตรง ๆ ว่าต้นทุนจะพุ่งแบบ “ยกกำลัง” ตามจำนวนโทเค็น ดูเหมือนผู้ให้บริการ LLM เริ่มสะท้อนโครงสร้างราคาแบบไม่เป็นเชิงเส้นเป็นครั้งแรก ซึ่งก็คล้ายกับกฎการสเกลของ inference ที่เรารู้กันอยู่แล้ว
มีการชี้ไปยังกระทู้ที่เกี่ยวข้องด้วย
ฟีเจอร์นี้เจ๋งมาก แต่ก็สงสัยว่าจะมีวิธีไหนช่วยให้ความเร็วในการอนุมานดีขึ้นได้บ้าง ส่วนตัวคิดว่า 200K context ก็พอแล้ว ถ้าตอบได้เร็วขึ้นจะดีกว่า และเชื่อว่าหลายคนน่าจะพอใจถ้าเอเจนต์ทำงานได้เร็วขึ้นมาก แม้ขนาดคอนเท็กซ์จะเล็กลงก็ตาม (ตอนนี้ต้องรอ 2-3 นาทีต่อพรอมป์ต)