OpenAI ลดขนาด context ของโมเดล Codex จาก 372k เหลือ 272k

 (github.com/openai)
1 คะแนน โดย GN⁺ 1 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • OpenAI ได้อัปเดต metadata ของโมเดลแบบ bundled ของ Codex และ backport การเปลี่ยนแปลงที่ลดขนาด context ของโมเดลจาก 372k เหลือ 272k ไปยัง branch release/0.144
  • PR #33972 ย้ายการเปลี่ยนแปลงจาก branch agent/hotfix-0.144-model-metadata ไปยัง Codex 0.144 release
  • ขอบเขตการเปลี่ยนแปลงมีไฟล์ JSON 1 ไฟล์ โดยสถิติ diff คือ เพิ่ม 64 บรรทัด·ลบ 54 บรรทัด
  • ถูก merge หลังผ่าน 1 commit และ 36 checks โดยไม่มีบทสนทนาหรือเนื้อหา review แยกต่างหาก
  • ในหน้าที่ให้มา file diff ไม่ถูกโหลด จึงไม่สามารถตรวจสอบรายละเอียดการเปลี่ยนแปลง metadata อื่น ๆ นอกจากการลด context ได้

วัตถุประสงค์และขอบเขตของการเปลี่ยนแปลง

  • ชื่อ PR คือการ backport metadata ของโมเดลแบบ bundled ที่อัปเดตแล้ว ไปยัง Codex 0.144
  • ตามชื่อบน Hacker News ขนาด context ของโมเดลถูกลดจาก 372k เหลือ 272k
  • branch เป้าหมายคือ openai:release/0.144 และ branch ต้นทางคือ sayan-oai:agent/hotfix-0.144-model-metadata

ผลลัพธ์การ merge

  • PR #33972 ประกอบด้วย 1 commit b06f4fa
  • ชื่อ commit คือ Backport refreshed bundled model metadata
  • ถูก merge เมื่อวันที่ 18 กรกฎาคม 2026 และแสดงว่ามี 36 checks กับการเปลี่ยนแปลงไฟล์ 1 ไฟล์
  • ปริมาณการเปลี่ยนแปลงคือเพิ่ม 64 บรรทัดและลบ 54 บรรทัด โดยรูปแบบไฟล์เป็น JSON

ข้อจำกัดที่ตรวจสอบได้

  • ส่วนไฟล์และความคิดเห็นในหน้าแสดงข้อผิดพลาดในการโหลด จึงไม่สามารถตรวจสอบ JSON diff จริง ได้จากเนื้อหาที่ให้มา
  • เนื้อหาไม่ได้รวมขั้นตอนการทำซ้ำ เหตุผลของการเปลี่ยนแปลง ผลกระทบด้าน compatibility หรือ feedback จาก review

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 1 일 전
ความเห็นจาก Hacker News

  • หลายคนบอกว่าแก้ได้ด้วยการบีบอัด แต่สำหรับงานที่ฉันทำ รายละเอียดที่หายไปเพราะการบีบอัด มีมากเกินไป
    ถ้าแผนงานเรียบง่ายหรือไม่ได้คุยกันลงรายละเอียดมากก็อาจพอไหว แต่เพราะขาดคอนเท็กซ์ยาว ๆ สุดท้ายเลยยังต้องใช้ Anthropic ต่อไป
    เวลาต้องจำงานวิจัยหลายฉบับหรือข้อมูลชิ้นใหญ่และซับซ้อนทั้งหมด คอนเท็กซ์จะค้างอยู่ที่ 16% ตลอด พอคุยไปประมาณ 5 นาทีก็ถูกบีบอัด แล้วก็วนกลับไปให้มันอ่านข้อมูลใหม่จนถึง 16% อีกครั้ง
    คอนเท็กซ์ 372k ก็ไม่ได้สมบูรณ์แบบ แต่ช่วยเพิ่มพื้นที่เผื่อจากราว 12~20% เป็นประมาณ 40% ซึ่งช่วยได้มาก

    • ปิดการบีบอัดอัตโนมัติไม่ได้ และก็ย้อนกลับไปยังประวัติการสนทนาก่อนบีบอัดไม่ได้ จึงใช้ Codex กับโค้ดเบสที่มีเกิน 5 พันบรรทัดไม่ได้
      มันทำงานแบบสุ่มตอนคอนเท็กซ์เหลือ 10~20% ดังนั้นในทางปฏิบัติจึงใช้ได้แค่ 80% ของ 272k หลังบีบอัดอาการหลอนหนักจนแย่กว่าการเริ่มใหม่ตั้งแต่ต้น และก็ติดลูปอ่านโค้ดเบสใหม่แล้วถูกบีบอัดอีก
    • กระบวนการออกแบบของฉันต่างออกไป plan.md ที่แก้หลายรอบคือหน่วยความจำ และการเริ่มเซสชันใหม่แล้วอ่านกับทบทวนแผนอีกครั้งก็ช่วยให้ได้มุมมองใหม่
    • เพราะการบีบอัดแย่มาก เลยทำเครื่องมือที่ให้ LLM ลบบางส่วนของคอนเท็กซ์แบบเลือกได้แล้วกู้คืนเมื่อจำเป็นขึ้นมา ถ้าคุณชนข้อจำกัดของการบีบอัดอัตโนมัติบ่อย ๆ ลองใช้ context bonsai ดูได้
      https://github.com/Vibecodelicious/context-bonsai-agents
    • โมเดลของ Anthropic ให้ คอนเท็กซ์ 1 ล้านโทเค็น ฉันวางแผนจะย้ายไป OpenAI เดือนหน้า แต่พอรู้ว่ายังอยู่แถว ๆ 300k ก็คงต้องปรับตัวเข้ากับความจริงใหม่
    • ปกติฉันจะแนะนำให้เอเจนต์สร้างหรืออัปเดตไฟล์ .md เป็นครั้งคราวเพื่อจำข้อมูลสำคัญที่เพิ่งเกิดขึ้น แต่ถ้าเอเจนต์รู้ได้แม่นจริงว่าอะไรสำคัญ /compact ก็ควรทำงานได้ดี

  • เพราะมีหน้าต่างคอนเท็กซ์ใหญ่ เลยเลิกคัดว่าจะใส่อะไร และการบีบอัดก็เหมือนใช้ การบีบอัดแบบสูญเสียข้อมูล กับทั้งหมดรวดเดียวจนทำให้รายละเอียดที่จำเป็นหายไปด้วย
    ฉันมองว่าการต้องส่งบทสนทนาทั้งหมดซ้ำทุกครั้งนี่แหละคือปัญหาพื้นฐาน พอใช้ปลั๊กอิน memory·context ที่ฉันทำเองแล้วล้างคอนเท็กซ์ทุกครั้งก่อนฉีดกลับเฉพาะข้อมูลที่เกี่ยวข้อง โมเดลจึงอ่านแค่สถานะที่คัดมาแล้วไม่กี่พันโทเค็น แทนที่จะอ่านประวัติสนทนา 2 แสนโทเค็น ทำให้คอนเท็กซ์เล็กไม่ใช่ปัญหา
    กับ coding agent ยังแก้ไม่ได้ แต่ฉันคิดว่า นโยบายการเก็บรักษา ที่เก็บไว้เฉพาะสิ่งที่ต้องใช้ต่อเพื่อให้งานเสร็จหรือทำงานถัดไป แล้วทิ้งที่เหลือ คือคำตอบที่แท้จริง และน่าจะทำได้ด้วย LLM เฉพาะทาง

    • ผู้เชี่ยวชาญด้านประมวลผลภาษาธรรมชาติหลายคนที่วิจัย LSTM, GRU และอื่น ๆ ก็มองว่าการส่งบทสนทนาทั้งหมดซ้ำเป็นปัญหาพื้นฐาน แต่ในเชิงประจักษ์แล้ว Transformer ชนะ
      น่าสนใจว่าโครงสร้างโมเดลในอนาคตจะกลับมาพิจารณาปัญหานี้อีกไหม ถ้าเทียบกับมนุษย์ สิ่งที่ยังขาดคือความสามารถในการย้ายข้อมูลจากความจำระยะสั้นไปสู่ความจำระยะยาวอย่างมีประสิทธิภาพ ซึ่งการ fine-tuning ก็ทำสิ่งคล้ายกันในเชิงหลักการ แต่ไม่มีประสิทธิภาพ

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

    • ฉันก็ บีบอัดหรือเริ่มใหม่ที่ 250k ขนาดคอนเท็กซ์ที่ต้องใช้แปรตามขนาดโปรเจกต์ ดังนั้นคนที่ต้องการหน้าต่างใหญ่กว่านี้ก็คงแค่กำลังทำโปรเจกต์ที่ใหญ่กว่า
    • ความรู้สึกฉันก็เหมือนกัน และขอบเขตน่าจะอยู่แค่ 100~150k เสียด้วยซ้ำ ถึงโมเดลจะรองรับคอนเท็กซ์ยาว แต่ประสิทธิภาพจริงไม่ค่อยดี
    • เรื่องที่ว่าพอคอนเท็กซ์ใหญ่แล้วโมเดลจะดูโง่ลงอย่างชัดเจนนั้นไม่ตรงกับที่ฉันรู้สึก มันช้าลงและแพงขึ้นก็จริง แต่สำหรับงานซับซ้อน นี่คือต้นทุนที่ต้องยอมรับ
      ฉันให้เอเจนต์หลักใช้เอเจนต์ย่อยค้นคว้าสิ่งที่จำเป็นและเขียนแผน จากนั้นให้เอเจนต์ย่อยอีกชุดตรวจทานแบบเป็นปฏิปักษ์เพื่อเสริมให้แน่นขึ้น พอจบแล้วจะกินพื้นที่ 30~40% ของหน้าต่าง 1 ล้านโทเค็น ซึ่งเป็นเวิร์กโฟลว์ที่ทำไม่ได้ใน 272k
      ใน 5.6 Sol ฉันต้องย่อกระบวนการนี้ลงมาก และนั่นก็น่าจะเป็นเหตุผลว่าทำไมผลลัพธ์ถึงแย่ลง

  • ตอนที่การเปลี่ยนแปลงนี้เกิดขึ้น Tibo ก็โพสต์คำอธิบายไว้ด้วย: https://x.com/thsottiaux/status/2076543065045795309

    • ดูคำตอบได้ที่นี่: https://xcancel.com/thsottiaux/status/2076543065045795309
      ทวีตที่ลิงก์ไว้เป็นคำตอบไม่เป็นทางการต่อข้อมูลทางการของ Tibo และ Tibo ก็แก้ไขเนื้อหาไว้ในคำตอบ
    • ฉันไม่เข้าใจกราฟนี้ ทำไมเส้นถึงยังเพิ่มขึ้นต่อทั้งที่กำลังบีบอัดอยู่ หรือว่ามีความหมายบางอย่างของ “overall trajectory size” ที่ฉันไม่รู้
    • ฉันไม่แน่ใจว่า ความยาว trajectory ทั้งหมด จะเท่ากันได้อย่างไรทั้งที่ความเข้มของการให้เหตุผลต่างกัน ถึงจะตัด reasoning token ออกจากความยาว trajectory ก็ยังดูเป็นไปไม่ได้

  • ฉันไม่ชอบการบีบอัดคอนเท็กซ์แบบนี้ และมองว่าตอนนี้ควรให้มาอย่างน้อย 1 ล้านโทเค็น
    GPT 5.5 และ 5.6 จะหน่วงทุกครั้งที่ถูกบีบอัดจนกว่าจะกลับมาทำงานได้เต็มความเร็ว และยังโฟกัสกับข้อความคำสั่งเก่าที่หลงเหลืออยู่ในคอนเท็กซ์ที่ถูกบีบอัดมากเกินไปด้วย

    • GPT-5.6-Sol มีประสิทธิภาพต่อโทเค็นดีกว่า Opus/Fable ราว 2 เท่า ดังนั้นสูงสุด 258k จึงเทียบได้กับราว 516k ของ Claude
      context corruption ยังเป็นปัญหาอยู่[1][2] และก็มีหลักฐานว่าสำหรับงานเอเจนต์ การบีบอัดให้ผลเทียบเท่าหรือดีกว่าคอนเท็กซ์ยาว[3] ถ้าโมเดลให้เหตุผลได้บนคอนเท็กซ์ 1 ล้านเหมือนที่ทำได้บน 256k ก็คงดีที่สุด แต่ตอนนี้ยังเป็นไปไม่ได้
      [1] https://arxiv.org/abs/2605.12366
      [2] การเปรียบเทียบค่า F1 ของ GraphWalks 256K และ 1M ใน Opus 4.8 System Card: https://www-cdn.anthropic.com/0b4915911bb0d19eca5b5ee635c80f...
      [3] https://context-folding.github.io/
    • ต่างจากเครื่องมือเขียนโค้ดอื่น ๆ ตรงที่ ปิดการบีบอัดอัตโนมัติไม่ได้ เลยน่าหงุดหงิด มันทำงานแบบไม่สม่ำเสมอเมื่อคอนเท็กซ์เหลือ 10~20% ดังนั้นความจุที่การันตีได้จึงมีแค่ 80% ของ 272k
      ตอนทำงานกับโค้ดเบสใหญ่ ๆ งานใกล้เสร็จแล้ว เหลือให้ตอบอีกราว 2,000 โทเค็น แต่พอลดต่ำกว่า 20% มันจะประมวลผลอยู่นานแล้วขึ้น Context compacted พอกลับไปก่อนบีบอัดไม่ได้ ก็ต้องไปสำรวจโค้ดเบสใหม่แล้วถูกบีบอัดอีก สุดท้ายก็ใช้โทเค็นหมด
    • หวังว่าการลดจำนวนโทเค็นจะไม่ใช่กลเม็ดเพื่อเพิ่มการใช้งาน แต่เป็นเพราะต้องการลดต้นทุนเป็นหลัก ที่บริษัทของฉัน คนดูแลงบประมาณก็จำกัดคอนเท็กซ์อย่างหนักจน LLM ภายในที่ตอนแรกยังพอใช้ได้แทบกลายเป็นของไร้ประโยชน์
      เหมือนผู้บริหารมีวงแชร์ แนวปฏิบัติที่แย่ที่สุด กันอยู่
    • เก็บ working memory ไว้ในไฟล์ Markdown ก็ได้ และไม่จำเป็นต้องใช้คอนเท็กซ์ใหญ่ เมื่อคอนเท็กซ์เพิ่มขึ้น attention จะกระจายจนประสิทธิภาพของ LLM ลดลง ดังนั้น คงให้เล็กไว้จะดีกับคุณภาพมากกว่า

  • ฉันใช้ Opus เป็นประจำและรัน /clear บ่อย ๆ แม้จะมีคอนเท็กซ์ 1 ล้าน แต่พอเข้าใกล้ 50% ประสิทธิภาพก็ลดลงอย่างรวดเร็ว จึงมัก รีเซ็ตที่ 30~40% แล้วได้ผลดีกว่ามาก
    การเริ่มใหม่แล้วใส่คอนเท็กซ์ที่จำเป็นตั้งแต่ต้นทำงานได้ดีกว่าการบีบอัด ฉันจัดเอกสาร Markdown แยกตามฟีเจอร์ไว้เป็นชุดความรู้หลายชุด และวิธีที่ได้ผลคือบอกตั้งแต่ตอนโหลดครั้งแรกว่าข้อมูลที่เกี่ยวกับงานควรหาได้จากที่ไหน

  • ใน Codex ฉันไม่เคยรู้สึกว่าขนาดคอนเท็กซ์เป็นปัญหาเลย ไม่รู้ว่ามันบีบอัดแบบไหน แต่ ทำงานต่อได้เหมือนไม่มีข้อจำกัด

    • ดูเหมือนคุณเพิ่งเริ่มใช้ Codex ไม่นาน ช่วงแรกมีข้อผิดพลาด model context size exceeded หนักมากจนกู้คืนไม่ได้แม้จะบีบอัด และเพิ่งหายไปเมื่อไม่กี่เดือนก่อน
      ตอนนี้ดีขึ้นมากแล้ว แต่หลังบีบอัดมันไม่แสดงว่าใน concise summary มีอะไรอยู่บ้าง จึงยากจะรู้ว่าเนื้อหาสำคัญยังถูกเก็บไว้หรือไม่
      Codex ดูเหมือนจะมุ่งไปทางซ่อนสิ่งต่าง ๆ จากผู้ใช้ให้มากที่สุด และเหมือนกับที่ช่วงหลังมันเข้ารหัสพรอมป์ต์ระหว่างเอเจนต์กับเอเจนต์ย่อย ก็อาจเข้ารหัสทั้ง session log ได้ด้วย น่าเสียดาย แต่จนถึงตอนนี้ก็ยังเป็นชุดเครื่องมือ·โมเดลที่ดีที่สุดเท่าที่ฉันเคยใช้
    • เวลามีการบีบอัด Codex มักลืมทำงานล่าสุดให้เสร็จ โดยเฉพาะ เมื่อส่งข้อความไปก่อนการบีบอัดไม่นาน
    • ปัญหาส่วนใหญ่แก้แบบแบ่งแล้วพิชิตได้ ดังนั้น ความต่างระหว่าง 300k กับ 400k แทบไม่ใช่ประเด็น เอเจนต์เขียนโค้ดไม่ใช่บทสนทนาไม่รู้จบ

  • ไม่ว่าการบีบอัดจะดีแค่ไหน ในโปรเจ็กต์ใหญ่ก็ยังต้องอ่านไฟล์จำนวนมากอยู่ดี ช่วงแรก 200,000 โทเค็นหมดเร็วมาก แต่หลังจากนั้นความเร็วจะช้าลง
    เซสชัน Fable ส่วนใหญ่ไม่เกิน 500,000 โทเค็นจึงไม่ต้องบีบอัด แต่ใน Codex ต้องบีบอัดต่อเนื่องในเซสชันเดียว

    • มองว่าที่ต้องอ่านไฟล์มากเป็นเพราะ agents.md ทำไว้ไม่ดี จริง ๆ แค่อ่านไฟล์งานจริงกับไฟล์ที่เกี่ยวข้องไม่กี่ไฟล์ก็พอ ที่เหลือ ควรถูกรวบรวมไว้ในเอกสาร

  • สำหรับงานของฉันนี่ถือว่าค่อนข้างเล็ก ฉันพยายามให้อยู่ต่ำกว่า 200k แต่พอเร่งงานรอบสุดท้ายในเซสชัน DeepSeek และ MiMo ก็อาจขึ้นไปถึง 350k โทเค็น แล้วค่อยบีบอัด
    สงสัยว่า OpenAI จะนำเทคนิค K/V cache ของ DeepSeek ที่อยู่ในงานวิจัยสาธารณะมาใช้เพื่อลดต้นทุนได้มากหรือไม่

    • ดูเหมือนจะไม่มีใคร ทำแคชได้เก่งเท่า DeepSeek จึงน่าจะตามได้ยากเพราะรายละเอียดการทำต่างกันมาก
      ถ้าใช้ DeepSeek ร่วมกับ Reasonix จะมีวิธีเฉพาะเพิ่มเข้ามาให้เข้ากับโครงสร้างแคช ทำให้ในเซสชันยาว ๆ โทเค็น 97~98% ถูกแคช โมเดลที่เดิมก็ถูกอยู่แล้วจึงยิ่งถูกลงไปอีก
    • ในโมเดลเปิดแบบรันโลคัลที่ใช้ llamacpp เอเจนต์จะสั่งให้ บีบอัดช่วง 55k~85k และหากไม่ใช่งานที่ต้องใช้คอนเท็กซ์ใหญ่มากอย่างการไล่ตาม log ที่ซับซ้อน ก็มักไม่ค่อยไปถึง 120k
      ฉันยังปรับ system prompt ให้เอเจนต์สร้างเอเจนต์ย่อยตามงบประมาณการอนุมานและข้อความของ llamacpp แล้วให้บีบอัดเนื้อหาต่อ ใช้ dynamic context pruning ของ opencode เพื่อคงทิศทางไว้โดยไม่เพิ่มขนาดมากเกินไป และโดยรวมก็ใช้ได้ดีสำหรับการพัฒนาองค์ประกอบย่อยหลายตัวแบบวนซ้ำ

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