คลัสเตอร์โทเค็นการให้เหตุผลของ GPT-5.5 Codex อาจนำไปสู่ประสิทธิภาพที่ลดลง

 (github.com/openai)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • OpenAI Codex issue #30364 รายงานว่าปรากฏการณ์ที่ reasoning_output_tokens ของคำตอบ gpt-5.5 กระจุกตัวอยู่ที่ค่าคงที่อย่าง 516, 1034, 1552 อาจเกี่ยวข้องกับคุณภาพที่ลดลงในงาน Codex ที่ซับซ้อน
  • ข้อมูลที่ใช้วิเคราะห์คือเมทาดาทา token_count ของ Codex ช่วง 1 กุมภาพันธ์ 2026 ถึง 27 มิถุนายน 2026 ตามเวลา UTC โดยยืนยันเหตุการณ์ exact 516 ได้ 3,363 ครั้ง จาก เรคอร์ดคำตอบ 390,195 รายการ และ 865 เซสชัน
  • แม้ gpt-5.5 จะคิดเป็น 19.3% ของคำตอบทั้งหมด แต่กลับคิดเป็น 82.0% ของเหตุการณ์ exact-516 และในกลุ่ม reasoning_output_tokens >= 516 สัดส่วนที่เป็น exact 516 อยู่ที่ 44.0% สูงกว่า non-GPT-5.5 ที่ 1.3% มาก
  • สัดส่วน exact-516 รายเดือนเพิ่มจาก 0.11% ในเดือนกุมภาพันธ์ 2026 เป็น 53.30% ในเดือนพฤษภาคม และ 35.84% ในเดือนมิถุนายน แต่จำนวนโทเค็นการให้เหตุผลเฉลี่ยและ P90 ในช่วงเดียวกันกลับลดลง จึงไม่ใช่เพียงปรากฏการณ์การใช้โทเค็นการให้เหตุผลเพิ่มขึ้นอย่างเดียว
  • คอมเมนต์ถัดมามีการแชร์การพบคลัสเตอร์ 516 ลักษณะเดียวกันและการทำซ้ำคำตอบผิดบางกรณีใน Codex CLI, Codex Desktop และ OpenCode พร้อมข้อเสนอวิธีรับมือชั่วคราวด้วย local proxy ที่ตรวจจับแพตเทิร์น 518·n−2 แล้วให้โมเดลให้เหตุผลต่อ

ประเด็นหลักของ issue

  • Codex issue #30364 รายงานแพตเทิร์นที่ reasoning_output_tokens = 516 กระจุกตัวผิดปกติในเมทาดาทา token_count ของคำตอบ gpt-5.5
  • นอกจากนี้ยังบอกว่ามีสไปก์ใกล้ค่า 1034, 1552 ที่ดูเหมือนขอบเขตคงที่เพิ่มเติม
  • ขอบเขตของข้อสังเกตนี้ ไม่ได้อ้างว่าพิสูจน์การตัด hidden chain-of-thought ได้
    • ข้ออ้างที่แคบกว่าคือ ใน telemetry ของ Codex มี ความผิดปกติแบบ fixed token clustering ที่เฉพาะกับ gpt-5.5
    • เป็นเพียงการตั้งข้อสังเกตว่ารูปแบบนี้ดูสอดคล้องกับพฤติกรรมของ reasoning budget ที่อิง threshold
  • issue ที่เกี่ยวข้อง #29353 กล่าวถึงเคสทำซ้ำระดับหน่วยงานที่การรัน gpt-5.5 จบลงที่ 516 reasoning tokens พอดีและให้คำตอบผิด ส่วน issue นี้เพิ่มหลักฐานเชิงสรุปจากข้อมูลช่วงเวลาที่กว้างกว่า

สภาพแวดล้อมและข้อมูลที่ใช้วิเคราะห์

  • ผลิตภัณฑ์คือ Codex และโมเดลที่เกี่ยวข้องมากที่สุดคือ gpt-5.5
  • แหล่งข้อมูลคือเมทาดาทา token_count ของ Codex
  • ช่วงเวลาวิเคราะห์คือ 1 กุมภาพันธ์ 2026 ถึง 27 มิถุนายน 2026 ตามเวลา UTC
  • ตัวเลขสรุป:
    • เรคอร์ดโทเค็นระดับคำตอบ: 390,195 รายการ
    • เซสชัน: 865 รายการ
    • เหตุการณ์ exact reasoning_output_tokens = 516: 3,363 ครั้ง
    • สัดส่วนคำตอบทั้งหมดของ gpt-5.5: 19.3%
    • สัดส่วนเหตุการณ์ exact-516 ของ gpt-5.5: 82.0%
    • อัตราส่วน gpt-5.5 exact-516 / >=516: 44.0%
    • อัตราส่วน non-GPT-5.5 exact-516 / >=516: 1.3%

รูปแบบตามโมเดลและรายเดือน

  • อัตราส่วน exact 516 / >=516 เด่นชัดที่สุดใน gpt-5.5
    • gpt-5.5: 75,401 เรคอร์ด, 44.0%
    • gpt-5.4: 25,214 เรคอร์ด, 19.8%
    • gpt-5.2: 247,575 เรคอร์ด, 0.34%
    • gpt-5.3-codex: 13,333 เรคอร์ด, 0.0%
    • gpt-5.3-codex-spark: 26,179 เรคอร์ด, 0.0%
  • การกระจุกตัวแบบ exact-516 รายเดือนพุ่งขึ้นมากในเดือนพฤษภาคม 2026
    • กุมภาพันธ์: 0.11%
    • มีนาคม: 2.45%
    • เมษายน: 4.25%
    • พฤษภาคม: 53.30%
    • มิถุนายน: 35.84%
  • ในช่วงเดียวกัน ความเข้มข้นของโทเค็นการให้เหตุผลโดยรวมกลับลดลง
    • reasoning tokens เฉลี่ย: กุมภาพันธ์ 268.1 → พฤษภาคม 106.9 → มิถุนายน 168.5
    • P90 reasoning tokens: กุมภาพันธ์ 772 → พฤษภาคม 344 → มิถุนายน 515
  • การจับคู่ของตัวเลขนี้ทำให้เกิดข้อสังเกตว่า การเพิ่มขึ้นของ exact-516 อธิบายได้ยากว่าเป็นเพียงการใช้โทเค็นการให้เหตุผลมากขึ้นแบบธรรมดา

รายการตรวจสอบภายในที่ร้องขอ

  • มีการขอให้ทีม Codex ตรวจสอบว่า reasoning budget, routing, truncation, fallback และการทำงานของ scheduler ใน gpt-5.5 เป็นสาเหตุให้จบใกล้ 516/1034/1552 หรือไม่
  • หากพฤติกรรมนี้เป็นสิ่งที่ตั้งใจไว้ ก็มีคำขอให้ชี้แจงว่า exact 516 เป็นจุดจบปกติ, เพดานงบประมาณ, degraded tier หรือ threshold ภายในแบบอื่น
  • ขั้นตอนตรวจสอบที่เสนอ:
    • ดึง token_count events ที่มี reasoning_output_tokens แยกตามโมเดล
    • เปรียบเทียบจำนวน exact-value ของ 0, 516, 1034, 1552
    • คำนวณ count(reasoning_output_tokens = 516) / count(reasoning_output_tokens >= 516) แยกตามโมเดลและวันที่
    • เปรียบเทียบ gpt-5.5 กับ gpt-5.2, gpt-5.4 และรุ่นดัดแปลงเฉพาะ Codex
    • รันงานซับซ้อนซ้ำบน GPT-5.2 และ GPT-5.5 แล้วแยกประเมินคุณภาพระหว่างคำตอบ exact-516 กับคำตอบที่ใช้ reasoning ยาวกว่า

การทำซ้ำเพิ่มเติมและข้อมูลข้ามแหล่งจากคอมเมนต์

  • GitHub Actions แสดง #29353 เป็นตัวเลือกที่อาจซ้ำกัน
  • มีผู้ใช้หลายคนคอมเมนต์ว่าพบปัญหาเดียวกัน และมีผู้ใช้หนึ่งรายประเมินว่า issue นี้เป็นรายงานที่ อิงข้อมูลมากกว่า issue ก่อนหน้า
  • sinnet3000 นำเสนอข้อมูลข้ามไคลเอนต์จาก local session store ของ Codex CLI และ OpenCode
    • จาก ~/.codex/sessions และ archived_sessions ของ Codex มี token_count events ราว 22.7k รายการ โดย gpt-5.5 มี 4,300 records, >=516 จำนวน 156, exact 516 จำนวน 88, สัดส่วน 56.4%
    • จาก assistant messages ราว 32.1k รายการใน opencode.db ของ OpenCode, gpt-5.5 มี 6,977 records, >=516 จำนวน 126, exact 516 จำนวน 90, สัดส่วน 71.4%
    • เมื่อรวม non-OpenAI models ที่มีปริมาณข้อมูลอย่าง Kimi, DeepSeek, MiMo, MiniMax, Gemini, Qwen, GLM เป็นต้น ราว 24k records พบ exact 516 เป็น 0 ครั้ง
    • ข้อมูลนี้มี caveat ว่าไม่ได้ประเมินว่าคำตอบถูกหรือผิด แต่ตรวจสอบเพียงการมีอยู่ของคลัสเตอร์ exact 516 เท่านั้น
  • kyleboddy รายงานความแตกต่างของพฤติกรรมที่เกี่ยวข้องใน Codex Desktop บน Windows 11
    • รัน candy prompt เดียวกันใน 5 fresh projectless Codex Desktop threads
    • การรันแบบ direct-final_answer ที่เร็วให้คำตอบ 29 ซึ่งผิด
    • การรันที่ช้ากว่าและมี commentary ออกมาก่อนให้คำตอบ 21 ซึ่งถูก
    • แต่เขาระบุว่าใน fresh Windows-host Desktop threads ยังดึง exact reasoning_output_tokens ออกมาไม่ได้ จึงบอกไม่ได้ว่าการรันผิดนั้นเป็น 516 พอดีหรือไม่
  • ผู้ใช้คนเดิมยังสรุปคลัสเตอร์ค่าคงที่ของ gpt-5.5 / xhigh จาก local session metadata ด้วย
    • records 16,141, sessions 51, reasoning เฉลี่ย 149.7, P90 เท่ากับ 429
    • =516 จำนวน 438, >=516 จำนวน 1,298, สัดส่วน 33.74%
    • =1034 จำนวน 52, =1552 จำนวน 14, =2070 จำนวน 16, =2588 จำนวน 12, =3106 จำนวน 5

ผลการทำซ้ำบน Codex Linux CLI

  • kyleboddy บอกว่าทำซ้ำด้วย candy prompt เดียวกันบน Codex Linux CLI ได้เช่นกัน
  • สภาพแวดล้อม:
    • ผลิตภัณฑ์: Codex CLI
    • เวอร์ชัน: codex-cli 0.142.5
    • แพลตฟอร์ม: Ubuntu Linux 6.8.0-111-generic, x86_64
    • Node: v24.14.0
    • โหมดการยืนยันตัวตน: ChatGPT
    • โมเดลที่ทดสอบ: gpt-5.5
    • reasoning efforts: xhigh, high
    • โมเดลควบคุมเปรียบเทียบ: gpt-5.4 xhigh
  • prompt ถามจำนวนครั้งในการหยิบขั้นต่ำของปัญหาถุงลูกกวาด โดยห้ามใช้เครื่องมือภายนอก และสามารถแยกรูปร่างด้วยการสัมผัสได้
  • คำตอบที่คาดหวังคือ 21 ซึ่งตรวจยืนยันแยกต่างหากด้วย brute-force enumeration
    • มีคำอธิบายว่าเพราะสามารถแยกรูปร่างด้วยการสัมผัสได้ จึงวางแผนเป็น 9 round + 12 star candies ได้
  • ผลลัพธ์:
    • gpt-5.5 xhigh ที่รันจบ 4 ครั้ง ทั้งหมดมี reasoning_output_tokens = 516 และให้คำตอบสุดท้าย 23, 26, 28, 15 ซึ่งผิดทั้งหมด
    • gpt-5.5 high ที่รัน 3 ครั้งก็เป็น 516 ทั้งหมด และได้คำตอบ 22, 21, 27 ถูกเพียง 1 ครั้ง
    • gpt-5.4 xhigh ที่รัน 3 ครั้ง ใช้ reasoning tokens 6211, 12274, 10876 และตอบ 21 ถูกทั้งหมด
  • ผลลัพธ์นี้ช่วยหนุนข้ออ้างในกรอบแคบว่า gpt-5.5 อาจเข้าสู่ เส้นทาง 516-token แบบคงที่ ใน Codex และเส้นทางนั้นอาจสัมพันธ์กับคุณภาพงานที่ลดลง

ข้อเสนอวิธีเลี่ยงชั่วคราว

  • dzshzx เสนอ local Responses proxy codexcomp สำหรับวางไว้หน้า Codex ระหว่างรอ upstream fix
  • วิธีทำงานคือถือว่าแพตเทิร์น 518·n−2 เป็นการถูกตัด แล้วให้เหตุผลต่อ
    • มองรอบที่ reasoning_tokens == 518·n − 2 เช่น 516, 1034, 1552 ว่าเป็น truncated
    • ทิ้ง tentative output แล้ว replay reasoning items และ encrypted_content ของรอบนั้นเป็นอินพุตถัดไป
    • ใส่ phase:"commentary" พร้อมข้อความ "Continue thinking..."
    • รวมทุกรอบเป็น downstream response เดียว เพื่อให้ Codex มองเหมือนเป็นคำตอบที่เสร็จสมบูรณ์แล้ว
  • การตั้งค่าใช้คีย์ top-level openai_base_url อย่างเป็นทางการ
    • ตัวอย่าง: openai_base_url = "http://127.0.0.1:8787/v1";
    • ระบุว่ายังใช้ provider openai แบบ built-in ต่อไปได้ จึงทำให้ session grouping, remote compaction และ remote-control ยังทำงานต่อ
  • ตัวอย่างล็อกจริงแสดงกรณีที่หลังจาก 516 สองรอบติดกัน รอบที่สามจบแบบ clean และได้คำตอบสุดท้ายถูกต้อง
    • round 1: reason=516 → continue
    • round 2: reason=516 → continue
    • round 3: reason=291 → clean
  • caveat:
    • เป็นวิธีเลี่ยง ที่ไม่เป็นทางการ และพึ่งพาพฤติกรรมที่ upstream ไม่ได้รับประกัน
    • continuation rounds ใช้โทเค็นจริงเพิ่ม
    • จำกัดด้วยหน้าต่าง n และ cap การ continue 3 ครั้ง
    • ทำงานแบบ loopback-only, auth passthrough และระบุว่าไม่อ่านหรือเก็บ credentials

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

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

 
GN⁺ 4 시간 전
ความคิดเห็นบน Hacker News

  • เรื่องนี้ดูค่อนข้างร้ายแรง และทำซ้ำได้ง่ายด้วย codex cli
    ถ้าให้พรอมป์ปริศนาที่ต้องใช้การให้เหตุผล บางครั้งมันเหมือนถูกตัดจบกะทันหัน ใช้เพียง โทเค็นความคิด 516 โทเค็น พอดี แล้วให้คำตอบผิด
    ในกรณีที่ใช้โทเค็นความคิด 6,000–8,000 โทเค็น จะให้คำตอบถูก
    อาจเป็นปัญหาฝั่ง adaptive thinking และนี่ก็เป็นอีกเหตุผลหนึ่งที่ทำให้เทใจให้โมเดลโลคัล เพราะไม่ต้องกังวลกับการเปลี่ยนแปลงฝั่งเซิร์ฟเวอร์แบบเงียบ ๆ
    ลองรันพรอมป์เดียวกัน 10 ครั้ง มี 4 ครั้งที่เจอปัญหา 516 โทเค็นนี้ และทั้ง 4 ครั้งนั้นตอบผิดทั้งหมด แม้ตัวอย่างจะน้อย แต่ดูเหมือน 5.5 xhigh อาจถูกตัดสั้นจนประสิทธิภาพลดลงได้เกือบครึ่งหนึ่งของเวลา

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

  • ผมเจอคุณภาพตกลงแบบเป็นขั้น ๆ แทบทุกวัน และปกติใช้ xhigh
    ประสบการณ์ที่เคยพึ่งพาการเขียนโค้ดของ Codex ที่ละเอียดรอบคอบอย่างยอดเยี่ยมเมื่อต้นปีนี้หายไปแล้ว และมีการ implement ที่โง่จนเหลือเชื่อโผล่มาเป็นระยะ ๆ จนผมย้ายไปใช้ Claude จนกว่า OpenAI จะจัดการปัญหานี้อย่างจริงจัง
    ส่วนตัวผมเห็นมาหลายเดือนแล้ว แต่ไม่รู้สึกว่า OpenAI รับเรื่องนี้เป็นเรื่องร้ายแรง

    • 3 เดือนก่อน Claude โง่ลงมากจนผมย้ายมาใช้ Codex และ 6 เดือนก่อนหน้านั้นก็กลับกัน ไม่ว่าจะ Codex หรือ Claude สุดท้ายทั้งคู่ก็ทำให้ปวดหัวได้ แต่ Codex ก็น่าจะยังน้อยกว่า
    • ตั้งแต่ต้นเดือนมิถุนายน ผมรู้สึกจากประสบการณ์ของตัวเองว่า ความน่าเชื่อถือของ 5.5 ตกลงมาอยู่ระดับเดียวกับ Claude
      เลยย้ายจาก 5.5 high → 5.5 xhigh → 5.4 high
      5.4 high เสถียรสนิทตลอด 3 สัปดาห์ที่ผ่านมา และตอนนี้ผมพอใจกับตัวนั้น
      บางครั้งยังลองส่งงานให้ 5.5 xhigh ทำเพื่อดูว่ากลับมาเสถียร 100% หรือยัง แต่ตอนนี้ผมมองว่าพวกเขาน่าจะรอปล่อย 5.6 มากกว่าจะแก้ปัญหาความน่าเชื่อถือนี้
    • ผมไม่เชื่อว่านี่เป็นปัญหาเชิงเทคนิค การจะแก้ต้องใช้เงินมาก แต่ผู้ใช้ไม่ได้จ่ายมากพอ ดังนั้นผมมองว่าเป็น การตัดสินใจทางธุรกิจเพื่อลดประสิทธิภาพ

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

    • ผมเองก็มีปฏิกิริยาแบบเดียวกันกับการคิดเงินต่อโทเค็น แต่พอเห็นว่าทั้งสองแล็บได้ประโยชน์ทางเศรษฐกิจจากการย้ายลูกค้าไปสู่ การใช้งานแบบคิดตามโทเค็น ก็ทำให้อยากหลีกเลี่ยงโดยหลักการ
      แม้จะไม่ได้ตั้งใจก็ตาม ผมไม่อยากยอมรับหรือทำให้โครงสร้างที่ได้กำไรจากผลิตภัณฑ์คุณภาพตกต่ำเกิดขึ้นได้
      เอาเข้าจริง ตอนนี้ โมเดลโอเพนซอร์ส และสภาพแวดล้อมการรันแบบเปิด เช่น Pi ดูน่าสนใจกว่าช่วงไหน ๆ นับตั้งแต่ ChatGPT เปิดตัว
    • ใช่ ผมก็เลิกใช้ Claude Code แล้วเปลี่ยนมา Codex เพราะเรื่องนั้นเหมือนกัน
      ตอนนี้กำลังคิดอยู่ว่าจะหาเงินเพิ่ม 65,000 ดอลลาร์ ได้อย่างไร เพื่อจะได้ไม่ต้องกังวลเรื่องบ้าบอแบบนี้อีก ผมรู้เรื่องความคุ้มค่าของของอย่าง OpenRouter อยู่แล้ว
      นึกถึงราวปี 2008 ตอนที่คำว่า “คลาวด์” เริ่มผุดขึ้นมาเป็นศัพท์การตลาด มันดูเหมือนการหีบห่อโมเดลสมัครสมาชิกที่ลดความคาดหวังต่อ rich client และบั่นทอนความเป็นเจ้าของแบบโลคัล เพื่อเพิ่มมาร์จินให้บริษัท
      หลังจากนั้นผมก็เอือมกับความคลั่งไคล้และความสุดโต่งต่อ “ซอฟต์แวร์เสรีและโอเพนซอร์สของแท้” แล้วคิดว่าตอนนั้นตัวเองยังเด็กและปล่อยผ่านไป
      จริง ๆ แล้วผมเข้าใจหรือพอทนกับโมเดลสมัครสมาชิกจำนวนมากได้ในระดับหนึ่ง การทำซอฟต์แวร์ใช้เงินมาก และการมองว่าการอัปเกรด Photoshop รายปีในปี 2026 มีมูลค่า 200 ดอลลาร์อาจไม่ยุติธรรมก็ได้ แต่การเปลี่ยน UI ที่ใช้งานได้ดีมา 20 ปีตามอำเภอใจ และถึงขั้นเอาของอย่างชุดสีคลาสสิกออกไปเลยนั้นเป็นเรื่องโง่
      แบบนั้นผมก็สามารถใช้ Codex ซึ่งเป็นเครื่องมือจำเป็นในการทำงานราคาเดือนละ 200 ดอลลาร์ มาทำปลั๊กอินชุดสีคลาสสิกได้
      แล้วเดือนละ 200 ดอลลาร์ยุติธรรมไหมสำหรับปริมาณโทเค็นที่ผมใช้? เดือนที่ใช้หนักมาก ผมอาจใช้ไปราวหนึ่งพันล้านโทเค็นก็ได้
      แต่นั่นแหละคือปัญหา พวกเขาจะคอยดึงคันโยกไปเรื่อย ๆ โดยไม่รู้แน่ชัดว่าความสามารถทำกำไรรูปแบบไหนถึงจะเหมาะสม และดูจากการอ่านใบชาอย่างกำหนดครบกำหนดหนี้แล้ว อย่างน้อยก็น่าจะเป็นแบบนั้นไปจนถึงปี 2030 หรือ 2032
      ผมไม่อยากคิดเรื่องแบบนั้นเลย ไม่อยากคอยประเมินความชอบต่อโมเดลกับการเสื่อมของประสิทธิภาพ และอัปเดตน้ำเสียงที่ใช้คุยกับ AI อยู่เรื่อย ๆ ให้สอดคล้องกับการทดลองแบ็กเอนด์ลึกลับที่กำลังทำกับเอาต์พุตที่ผมใช้สร้างและดูแลผลงานที่รับเงินจริง ๆ
      AI อยู่กึ่งกลางระหว่างเครื่องมือกับผู้ร่วมงาน แต่การเปลี่ยน “บุคลิก” แบบเอาแน่เอานอนไม่ได้จากการไปหมุนปุ่มและคันโยกที่ยังไม่เข้าใจดีในขั้นตอนการให้เหตุผลนั้นทำให้แทบคลั่ง ดังนั้นผมอยากชี้ไปที่กล่องตรงมุมห้อง แล้วรู้คุณภาพเอาต์พุตอย่างแน่นอนว่าไม่มีใครเปลี่ยนมันนอกจากผม
    • Fireworks?
    • หมายถึงการถดถอยของประสิทธิภาพ Claude Code แบบ “อิงความรู้สึก” ใช่ไหม ในระบบที่ไม่กำหนดแน่นอน ไม่ควรคาดหวัง ประสิทธิภาพที่สม่ำเสมอ อยู่แล้ว ไม่มีข้อมูลเชิงประจักษ์ใด ๆ ที่สนับสนุนว่าประสิทธิภาพลดลง
      สิ่งที่เปลี่ยนแบบเป็นขั้น ๆ เมื่อเร็ว ๆ นี้ไม่ใช่ประสิทธิภาพของโมเดล แต่เป็นปริมาณการคร่ำครวญและบ่นของเหล่าโค้ดเดอร์

  • ชอบตรงที่ Codex เป็นโอเพนซอร์ส ทำให้ประเด็นแบบนี้ถูกเปิดเผยและถูกจัดการอย่างสาธารณะได้

    • แต่เรื่องนี้เป็นพฤติกรรมของโมเดล และการมีตัวติดตาม issue สาธารณะก็ดูเหมือน Claude Code ต่างกันแค่ไม่มีโค้ดไม่ใช่หรือ ในปัญหาแบบนี้ผมไม่รู้ว่ามันต่างจาก https://github.com/anthropics/claude-code ตรงไหน
      โดยรวมแล้วรู้สึกขอบคุณที่ Codex เป็นโอเพนซอร์ส แต่สำหรับปัญหาประเภทนี้ โมเดลยังคงปิดอยู่ จึงดูไม่มีความหมายมากนัก
    • โดยรวมแล้วรู้สึกว่า OpenAI เปิดกว้างกว่า Anthropic มาก และเหมือนบริษัทจริง ๆ มากกว่า ส่วน Anthropic เป็นแค่ กล่องดำ

  • อาจจะจำผิดก็ได้ แต่ถ้าดูจากการใช้โทเคนและคุณภาพโค้ด ผมว่า 5.3 ดีที่สุด 5.5 ทำงานได้ดีกว่าก็จริง แต่กินโทเคนแบบถล่มทลาย

    • ไม่ใช่แค่ผมคนเดียว 5.3-codex เป็นโมเดลที่ยอดเยี่ยมในแง่สมดุลระหว่างคุณภาพผลลัพธ์กับต้นทุน
      ต่างจาก 5.5 หรือ Opus ตรงที่มันถูกและมีประสิทธิภาพพอจะใช้ได้กับแทบทุกงาน แต่ก็ยังค่อนข้างดี และผมชอบมากกว่า Sonnet
    • เมื่อไม่กี่สัปดาห์ก่อน 5.3 กลายเป็นใช้ไม่ได้ตามมาตรฐานผม มันแค่ค้างไป หรือไม่ก็ตอบแย่มาก

  • เหมือนเมื่อไม่กี่วันก่อนมีคนที่นี่บอกว่า OpenAI ลด ต้นทุนการประมวลผลลงครึ่งหนึ่ง ด้วยการปรับแต่งแบบก้าวกระโดด นี่คือเรื่องนั้นหรือเปล่า?

    • นั่นเป็นบทความของ The Information แต่ดูไม่เหมือนบทความที่เขียนดีเท่าไร ผมไม่ได้รู้สึกว่าผู้เขียนเป็นผู้เชี่ยวชาญด้านเทคนิคที่เข้าใจการทำงานของ LLM ดีพอจะประเมินข่าวลือภายในได้อย่างน่าเชื่อถือ: https://www.theinformation.com/newsletters/ai-agenda/openai-...
      เนื้อหาคือมีคนที่รู้เรื่องการพูดคุยนั้นเล่าว่า “วิศวกร OpenAI บอกกับเพื่อนร่วมงานบางคนเมื่อต้นเดือนนี้ว่า ด้วยการปรับแต่งที่เพิ่งค้นพบ พวกเขาพบวิธีลดต้นทุนการรันโมเดลเดิม หรือก็คือการ inference ลงได้มากกว่าครึ่ง”
    • ผมเข้าใจข่าวลือนั้นว่าไม่ใช่ OpenAI เอง แต่เป็นหนึ่งในกลุ่มที่แยกออกมาจาก OpenAI หลังเหตุการณ์นั้น อาจเป็น Thinking Machines ที่ทำ breakthrough ได้และกำลังเสนอให้ OpenAI ผมไม่คิดว่า OpenAI ได้นำไปใช้งานจริงแล้ว

  • ในกรณีของผม ถ้าดูเนื้อหา reasoning ที่เข้ารหัสแล้วจากความยาวสตริง base64 จะเห็นเอฟเฟกต์นี้ แต่จะไม่เห็นใน โทเคน reasoning ที่เซิร์ฟเวอร์รายงาน
    เลยคิดว่าเป็นส่วนหนึ่งของการเข้ารหัสหรือการทำให้คลุมเครือล้วน ๆ และไม่ใช่ปัญหาจริง
    ข้อเสียใหญ่ที่สุดของ GPT คือกระบวนการคิดถูกเข้ารหัสไว้ ทำให้เป็นกล่องดำมากกว่า Kimi, GLM, DeepSeek ถึงอย่างนั้นก็ยังขอสรุปการคิดได้ เลยอึดอัดแต่ก็พอใช้ได้

  • นี่เป็นกรณีหายากที่คำว่า “ทำให้โมเดลโง่ลง” ไม่ใช่อาการเพ้อของผู้ใช้ตามปกติ แต่เป็นกรณีที่ ทำให้โมเดลโง่ลงจริง ๆ หรือเปล่า?

    • เรื่องนี้ดูเหมือนเป็นข้อบกพร่องหรือการตั้งค่าผิดของเอนจิน inference หรือสภาพแวดล้อมรันเอเจนต์มากกว่า
      รายละเอียดของ issue ไม่ได้เป็นหลักฐานของการแอบลดความสามารถโดยตั้งใจ แต่ค่อนข้างจะตรงกันข้าม สาเหตุรากดูหยาบ ๆ และก็ไม่ได้ลับลมคมในนัก ถึงขั้นที่ผู้ใช้ทั่วไปสามารถรายงานรายละเอียดที่แม่นยำและตรวจสอบซ้ำได้อย่างอิสระ
      คำว่า “อาการเพ้อของผู้ใช้ตามปกติ” ไม่ยุติธรรมและไม่ถูกใจผม ถ้ามีแค่ API endpoint เหมือนอ่างล้างจานวิเศษที่กลืน context window แล้วคายเอาต์พุตถัดไปออกมา สิ่งที่เหลืออยู่ก็มีแค่การตัดสินเชิงอัตวิสัย การคาดเดา และความสงสัย
      ต่อให้มีชุดทดสอบโมเดลที่เป็นมาตรฐาน การอ้างว่าเป็นการแอบลดความสามารถก็ยังเป็นการอ่านเจตนาของคนในบริษัทนั้นอยู่ดี คุณภาพโมเดลอาจตกลงได้แม้ไม่มีเจตนาชัดเจนหรือไม่มีการดาวน์เกรดโครงสร้างพื้นฐานเบื้องหลัง
      การเล่นมุกทฤษฎีสมคบคิดหรือการพิจารณาความเป็นไปได้ของการลดความสามารถจริง ๆ ไม่ใช่อาการทางจิต ผมไม่ชอบกระแสที่นำศัพท์วินิจฉัยทางจิตวิทยามาใช้ผิด ๆ แบบนี้
      แน่นอนว่าก็อาจมีคนที่มั่นใจเกินไปกับการตัดสินแบบนี้ และกับคนเหล่านั้นคำนี้อาจใช้ได้ แต่นั่นเป็นส่วนน้อย สุดท้ายแล้วมันก็เป็นแค่การพูดเกินจริง และไม่เป็นประโยชน์กับใคร

  • ตลกดีที่ขาย subscription สำหรับ frontier model แล้วค่อย ๆ nerf อย่างรวดเร็วเมื่อเวลาผ่านไป แต่ไม่มีใครพูดถึง
    ถ้าฝั่งเซิร์ฟเวอร์แอบลด ระดับความเข้มของ reasoning ลง ก็ควรให้ส่วนลดบ้าง
    ในทางกลับกัน ผมใช้ 5.5-high ทุกวันใน workflow แบบทำหลายงานขนานกัน และก็แทบจะใช้โควตารายสัปดาห์หมดพอดี ผมในฐานะ Human-as-a-Service ยังเร็วไม่พอที่จะอ่านตามทั้งแผนและการ implement ทั้งหมดได้ ก็มีแง่นั้นเหมือนกัน

  • ดูค่อนข้างชัดว่าเพื่อ optimize throughput จึงรวม reasoning inference เป็นแบตช์ตามหน่วยทวีคูณของ 512 โทเคน

    • ความคิดแรกของผมคือถ้าเทียบกับ llama.cpp การปรับ พารามิเตอร์งบประมาณ reasoning อาจทำให้เกิดผลแบบนี้ได้ แต่ถ้าไม่มีประกาศจาก OpenAI ก็ไม่มีทางรู้แน่ชัด
      มันอาจเป็นวิธีที่ไม่ซื่อสัตย์อย่างมากในการ scale ให้รับดีมานด์ช่วงพีคก็ได้ ผมรู้ว่ามีคนในหัวข้อนี้ล้อเลียนความเป็นอัตวิสัยของความรู้สึกเรื่องประสิทธิภาพโมเดลอยู่แล้ว แต่จากการทดสอบของผมอย่างน้อยตลอดเดือนพฤษภาคม โมเดลดูลดความฉลาดลงในช่วงเวลาที่สหรัฐฯ เริ่มออนไลน์
      ในบล็อกโพสต์ของบริษัทเมื่อไม่กี่สัปดาห์ก่อน ผมก็รู้สึกถึงแพตเทิร์นที่สม่ำเสมอมากขึ้นในช่วงเวลาที่ทับซ้อนกัน จนคิดว่าควรชี้ประเด็นนี้ไว้ น่าจะเก็บ session log ไว้เพื่อวิเคราะห์เพิ่มเติม https://webesque.agency/blog/2026-06-19-llms.html
    • มาตรฐานไม่ใช่การใช้ continuous batching หรอกหรือ? ถ้าใช้ continuous batching ผมสงสัยว่าทำไมความยาวของโทเคนที่สร้างจึงสำคัญ และทำไมต้องจัดกลุ่มตามความยาว ถ้าไม่ได้ใช้ ก็สงสัยว่าทำไมไม่ใช้และมี trade-off อะไรบ้าง