GPT-5 เปิดตัวสำหรับนักพัฒนา

 (openai.com)
1 คะแนน โดย GN⁺ 2025-08-08 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • GPT-5 API ได้รับการเปิดตัวอย่างเป็นทางการ ให้ระดับใหม่ของประสิทธิภาพสำหรับ การเขียนโค้ดและงานเอเจนต์ ที่ออกแบบมาเพื่อผู้พัฒนา
  • บันทึกสถิติ SOTA (สมรรถนะสูงสุดตามมาตรฐาน) ในการประเมินสำคัญอย่าง SWE-bench Verified และ Aider polyglot และได้รับการยืนยันความยอดเยี่ยมจากกรณีลูกค้าหลายราย เช่น Cursor, Windsurf, Vercel
  • แสดงความแข็งแกร่งในงานเอเจนต์ที่ต้องใช้เวลาทำนาน การ เชื่อมต่อเครื่องมืออย่างละเอียด และการจัดการบริบทข้อความยาวใน งานจริงที่ซับซ้อน
  • สามารถควบคุมตามความต้องการของนักพัฒนาได้ด้วยพารามิเตอร์ละเอียดเช่น verbosity, reasoning_effort และการรองรับเครื่องมือที่กำหนดเอง
  • มีตัวเลือกราคา/ประสิทธิภาพที่หลากหลายด้วย gpt-5, gpt-5-mini, gpt-5-nano และได้รับการผสานเข้ากับ Microsoft และเครื่องมือพัฒนาหลากหลาย

การเปิดตัว GPT-5 และความสำคัญ

  • OpenAI ประกาศเปิดตัว GPT-5 บนแพลตฟอร์ม API โดยเน้นว่ามันคือโมเดลที่ทำได้ดีที่สุดในงาน การเขียนโค้ดและงานเอเจนต์ จากโมเดลทั้งหมดที่เคยปล่อย
  • ทำสถิติ SOTA ในเกณฑ์การเขียนโค้ดหลัก และร่วมฝึกสอนร่วมกับ สตาร์ทอัปและทีมทดสอบขององค์กรจริง
  • แสดงศักยภาพเด่นในงานจริงของนักพัฒนา เช่น การสร้างโค้ด การแก้บั๊ก การแก้ไขโค้ด และการ query codebase ที่ซับซ้อน
  • มีความสามารถในการปฏิบัติตามคำสั่งละเอียดอย่างแม่นยำขึ้น และอธิบายพฤติกรรมรวมถึงแผนงานก่อนและหลังการเรียกเครื่องมือ
  • ประสิทธิภาพด้าน การพัฒนา front-end ก็โดดเด่นเช่นกัน โดยในการทดสอบภายในรับการประเมินว่าดีกว่าโมเดลก่อนหน้า 70%

ลูกค้าหลักและกรณีใช้งานจริง

  • Cursor, Windsurf, Vercel, Manus, Notion, Inditex ให้คะแนนสูงเกี่ยวกับ ความฉลาด ความง่ายในการปรับแต่ง การจัดการข้อผิดพลาดของเครื่องมือ และคุณภาพโค้ด ของ GPT-5
  • ในสภาพแวดล้อมการใช้งานจริง แสดงความเสถียรและประสิทธิภาพที่ดีเด่นกว่ารุ่นก่อนในการทำงานที่มีความซับซ้อน เช่น งานเบื้องหลังจำนวนมาก บทบาทเอเจนต์ที่ทำงานระยะยาว และการเชื่อมต่อเครื่องมืออย่างละเอียด

มาตรฐานการประเมินและตัวชี้วัดประสิทธิภาพ

  • SWE-bench Verified (การแพตช์ปัญหาซอฟต์แวร์จริง): ทำได้เหนือกว่า o3 ด้วย 74.9% และประหยัดโทเค็นได้ 22% และการเรียกเครื่องมือได้ 45% ลดลงเพื่อเพิ่มประสิทธิภาพ
  • Aider polyglot (การประเมินการแก้ไขโค้ด): ทำสถิติ 88% ลดอัตราผิดพลาดลงเหลือประมาณ 1/3 เมื่อเทียบกับ o3
  • วิเคราะห์ codebase ที่ซับซ้อนอย่างละเอียด และสามารถปรับ LLM ขนาดใหญ่ให้เข้ากับคำถามของผู้ใช้ เพื่อให้นักพัฒนา/นักวิจัยใช้ได้ง่ายขึ้น
  • การสร้างโค้ด front-end ได้เปรียบเหนือกว่าในด้านความรู้สึกสวยงามและความแม่นยำถึง 70% ในการทดสอบ

ผลงานด้านงานเอเจนต์และคอนเท็กซ์ระยะยาว

  • ใน τ2-bench telecom (benchmarks การเรียกเครื่องมือ) ทำสถิติ SOTA ล่าสุดที่ 96.7%
  • แสดงความสามารถในการทำงานเสร็จสมบูรณ์สูงเมื่อรันการเรียกเครื่องมือเป็นชุดต่อเนื่องหรือแบบขนานจำนวนมาก
  • ได้คะแนนสูงสุดในการปฏิบัติตามคำสั่งใน COLLIE, Scale MultiChallenge
  • ในงาน Q&A คอนเท็กซ์ยาวเช่น OpenAI-MRCR, BrowseComp Long Context แสดงผลเหนือกว่า o3 และ GPT-4.1
  • รองรับความยาวบริบทได้ถึง 400,000 โทเค็น เหมาะกับการวิเคราะห์เอกสาร/บทสนทนาในระดับใหญ่

ความน่าเชื่อถือและความปลอดภัย

  • ในการประเมิน LongFact, FactScore ลดข้อผิดพลาดทางข้อเท็จจริงได้มากกว่า 80% เมื่อเทียบกับ o3
  • รับรู้และแจ้งเตือนขีดจำกัดของตนเอง และเสริมความแม่นยำเป็นพิเศษในพื้นที่คำถามด้านสุขภาพ
  • ในการใช้งานจริงยังคงแนะนำให้มีการยืนยันผลโดยนักพัฒนาในพื้นที่ที่สำคัญอยู่ดี

การควบคุมสำหรับนักพัฒนาและฟีเจอร์ใหม่ใน API

  • reasoning_effort: ควบคุมการสมดุลระหว่างความเร็วในการตอบกับคุณภาพการให้เหตุผลด้วยค่า minimal/low/medium/high
    • minimal: ตอบสนองเร็ว, high: ให้เหตุผลเชิงตรรกะคุณภาพสูง
  • verbosity: ปรับความยาวผลลัพธ์ได้ด้วย low/medium/high
    • หากมีคำสั่งแบบชัดแจ้ง จะให้ความสำคัญกับคำสั่งนั้นมากกว่าพารามิเตอร์
  • เครื่องมือแบบกำหนดเอง: รองรับรูปแบบ plaintext นอกเหนือจาก JSON และสามารถจำกัดรูปแบบ input ของเครื่องมือด้วย regex หรือ Context-Free Grammar ได้
  • ลดความเสี่ยงปัญหา JSON escape ที่อาจเกิดขึ้นกับ code snippets หรือรายงานขนาดใหญ่ และเพิ่มความง่ายในการผสานระบบเครื่องมือของนักพัฒนา

โมเดล API และนโยบายราคาแบบหลากหลาย

  • gpt-5: $1.25 ต่อ 1 ล้าน input token, $10 ต่อ 1 ล้าน output token
  • gpt-5-mini: $0.25 ต่อ 1 ล้าน input token, $2 ต่อ 1 ล้าน output token
  • gpt-5-nano: $0.05 ต่อ 1 ล้าน input token, $0.40 ต่อ 1 ล้าน output token
  • ทุกโมเดลรองรับ reasoning_effort, verbosity, custom tools, การเรียกเครื่องมือแบบขนาน, เครื่องมือเว็บ/ไฟล์/ภาพแบบในตัว, สตรีมมิ่ง และฟีเจอร์หลักอื่น ๆ
  • gpt-5-chat-latest เปิดตัวเป็นโมเดล non-reasoning สำหรับ ChatGPT ในราคาเดียวกัน

การผสานรวมและความสามารถขยายตัว

  • เปิดตัวการผสานกับแพลตฟอร์ม Microsoft หลากหลายเช่น Microsoft 365 Copilot, GitHub Copilot, Azure AI Foundry
  • ถูกนำมาใช้เป็นเอนจินหลักในระบบเอเจนต์ของนักพัฒนาใน Cursor, Windsurf, GitHub Copilot และ Codex CLI
  • ในการประเมินภายในของ alpha-tester และผลิตภัณฑ์อัตโนมัติด้านโค้ด/งานต่าง ๆ มาจัดเป็นมาตรฐานใหม่เมื่อเทียบกับรุ่นก่อน

ความน่าเชื่อถือ ความปลอดภัย และข้อมูลเพิ่มเติม

  • ความเสี่ยงการตอบผิด (hallucination) ลดลงอย่างมีนัยสำคัญ และอธิบายขั้นตอนการทำงานและข้อจำกัดได้ตรงไปตรงมามากขึ้น
  • ระบบการ์ด (system card), บล็อกวิจัยภายใน และแหล่งข้อมูลอื่น ๆ ให้รายละเอียดการนำไปใช้ การประเมิน และมาตรการความปลอดภัยอย่างโปร่งใส
  • ทำหน้าที่เป็นผู้ช่วยเขียนโค้ดอัตโนมัติระดับสูง และเชี่ยวชาญการทำงานอัตโนมัติของ workflow เชิงเอเจนต์ที่ซับซ้อน

บทสรุป

  • GPT-5 คือโมเดลที่มีสมรรถนะแข็งแกร่งที่สุดที่ OpenAI เคยปล่อยสำหรับงาน การเขียนโค้ดและงานเอเจนต์ และเป็นหุ้นส่วนนวัตกรรมที่เหมาะกับสภาพแวดล้อมพัฒนาจริงและการทำงานอัตโนมัติ
  • ด้วย API และระบบเครื่องมือที่พัฒนาไปอีกขั้น และตัวเลือกปริมาณ/ราคาที่หลากหลาย ผนวกกับผลการประเมินสูง ทำให้ GPT-5 เปิดยุคใหม่แห่งประสิทธิผลให้แก่นักพัฒนาและองค์กร

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

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

 
GN⁺ 2025-08-08
ความคิดเห็นจาก Hacker News
  • ผมยังไม่รู้สึกว่ามีความต่างที่ชัดเจนทางการใช้งานจริงในความเชี่ยวชาญด้านการพัฒนาซอฟต์แวร์ระหว่าง Opus และ GPT-5 แต่สิ่งที่ผมให้ความสำคัญจริงๆ คือมันรักษาบริบทได้นานแค่ไหนและค่อยๆ เดินหน้าไปสู่เป้าหมายที่กำหนดได้มากน้อยเพียงใด ผมเชื่อว่าในงานวิศวกรรมซอฟต์แวร์แบบใช้งานจริง จุดนี้สำคัญที่สุด และผมอยากรู้ว่ามีเมตริกอะไรที่วัด/ยืนยันส่วนนี้ได้อย่างแม่นยำ
    • ในการทดลองช่วงสัปดาห์ที่ผ่านมาเกี่ยวกับความสามารถในการรักษาบริบทในการทำงานระยะยาวของ GPT-5 ที่ Charlie Labs ผมได้ผลลัพธ์ที่ค่อนข้างดีมาก ตอนให้แก้ GitHub issues 10 รายการและเปรียบเทียบกับ Claude Code ผลต่างด้านประสิทธิภาพพุ่งขึ้นชัดเจน ข้อมูลการทดลองมีอยู่ใน ที่นี่ โดยปกติในบริบทที่ซับซ้อน 30~45 นาทีที่เปลี่ยนแนวทางได้ ความแม่นยังคงตามไปได้ และยังจัดการ thread ขนาดใหญ่ของ Linear และ GitHub ได้ดี แม้จำนวน issue ที่ใช้ยังน้อย แต่ผลลัพธ์ประทับใจมาก และจะขยายการวัดผลต่อไป
    • ผมมักต้องสร้างความต้องการที่ซับซ้อนและเปลี่ยนบริบทบ่อยเป็นประจำ ซึ่งต้องการการรักษาบริบทแบบนี้จริงๆ แต่กลับเป็นเรื่องน่าเสียดายที่ GitHub Copilot กลับถูกมองข้ามเมื่อเทียบกับเครื่องมือช่วยเขียนโค้ดอื่นๆ ในความเป็นจริง โดยเฉพาะเมื่อเทียบกับ Anthropic, OpenAI, Google ฯลฯ พอได้ลองใช้ฟีเจอร์เว็บที่ชื่อ spaces มันเหมาะกับงานขนาดใหญ่กว่าการทำงานใน IDE แต่ข้อด้อยคือขั้นตอนการเก็บบริบทและรีวิวผลลัพธ์ใช้เวลานานกว่าที่ผมทำเอง ซึ่งทำให้รู้สึกว่ามันอาจมีจุดแข็งเรื่องการสะสม/เก็บบริบทได้ดี
    • ในปัจจุบัน หาก frontier LLMs ได้รับบริบทที่เพียงพอ มักจะสามารถแก้ปัญหาได้เกือบทั้งหมด เมื่อเกิดความล้มเหลว ผมจะใช้เวลาเกือบทั้งหมดไปกับการหาว่าบริบทส่วนไหนขาดไป ดังนั้นสิ่งที่ผมต้องการจริงๆ คือความสามารถในการเก็บบริบทให้เข้มข้นขึ้น กรณีใช้งานของผมโดยมากต้องโฟกัสไปที่ข้อมูลที่เชื่อมโยงกันจริงๆ จากไฟล์โค้ด, issue, PR และการอภิปราย ดังนั้นผมหวังว่า GPT-5 จะก้าวหน้าในด้านนี้ชัดเจนขึ้น และถ้าราคาถูกกว่า Opus ในขณะที่ผลลัพธ์ใกล้เคียงหรือดีกว่า ก็จะน่าคาดหวังขึ้นอีก
    • นโยบายราคา GPT-5 ดีขึ้นมากเมื่อเทียบกับ Opus มากขึ้นมา และตอนนี้อยู่ในระดับที่ใกล้เคียงกับ Gemini 2.5 Pro
    • ถ้า GPT-5 ทำงานได้ที่ 400k context จริงๆ ผมคิดว่ามันมีศักยภาพพอที่จะก้าวข้าม Opus อย่างมีนัยสำคัญ
  • กำลังทดสอบ scenario RAG ด้วย gpt-5-mini และผลที่เห็นจนถึงตอนนี้ค่อนข้างน่าประทับใจ ตอนนี้ลองใช้ร่วมกับตัวเลือก reasoning_effort="minimal" แล้วพบว่าเป็นตัวเดียวที่หยุดการสร้างข้อมูลปลอมได้ในจุดที่โมเดลตัวอื่นๆ มักหลอกตัวเองเกือบทั้งหมด ภาพตัวอย่างสกรีนช็อตแชร์ไว้ที่ ที่นี่ และจะมีการทดสอบแบบเป็นทางการเพิ่มในอนาคต
    • จากคำถาม “ผู้จัดการผลิตภัณฑ์คือใคร?” GPT-4 ตอบแบบอ้อมๆ พูดถึงการทำงานร่วมกันข้ามทีม ฯลฯ แต่ GPT-5 ตอบสั้นๆ ว่า “ไม่รู้” ซึ่งประโยคเดียวนี้ทำให้ผมรู้สึกว่า AI กำลังตื่นขึ้นมาอย่างจริงจัง
    • phi-4 และ gemma-3n ก็ใน scenario RAG ใช้เฉพาะบริบทที่ให้มา และช่วยให้การป้องกันการตอบนอกบริบทเป็นไปได้ดีขึ้นอย่างชัดเจน
    • ผมมองว่าเป็นการเปลี่ยนแปลงที่สำคัญที่สุด เพราะผมทำงานกับ workflow ที่เรียกใช้เครื่องมือบ่อย และโมเดลเคยมีปัญหาสร้าง “เครื่องมือเทียม” แบบหลอกลวงค่อนข้างมาก บางครั้งยังข้ามการเรียกเครื่องมือแล้วตอบตรงๆ โดยไม่มีหลักฐานเลย การฝึกรอบใหม่ในช่วงหลังดูเหมือนกำลังดันเรื่องการยับยั้งการหยาบ/การ hallucinate และการข้ามการเรียกเครื่องมือได้พัฒนาอย่างมีนัยสำคัญ
  • สัปดาห์ล่าสุดผมทดลองกับ Cursor, Claude Code และเครื่องมืออื่นๆ รวมเกือบ 70 ชั่วโมง สิ่งที่ได้คือต้องยอมรับว่ามีความประทับใจและเชื่อถือได้ขึ้น แต่ในทางปฏิบัติจริงที่ผมใช้ต่อเนื่องแล้ว ตัวที่เดินราบรื่นที่สุดยังคงเป็นโมเดลตระกูล Claude แม้จะต่างจาก benchmark และผมจึงรู้สึกว่าความสำคัญอยู่ที่การใช้งานจริงมากกว่า ตอนนี้รอว่าโมเดล GPT ตัวใหม่จะทำงานได้ดีในเคสนี้ โดยเฉพาะเมื่อการแข่งขันรุนแรงขึ้นและราคาเริ่มลงมา ผมคาดหวังมากขึ้น
    • ด้วยการอัปเดตเครื่องมือล่าสุดของ Cursor(1.4) แม้แต่โมเดลอย่าง Gemini ก็ใช้งานเครื่องมือได้น่าเชื่อถือมากขึ้นชัดเจน มาก่อนเคยพลาดงานพื้นฐานอย่างแก้ไฟล์ได้บ่อย ตอนนี้แทบทุกครั้งที่เรียกก็ทำงานได้ถูกต้อง
    • ผมคิดว่าเรื่องนี้ขึ้นกับ stack ที่ใช้ด้วยเช่นกัน เมื่อเร็วๆ นี้ผมดูวิดีโอแนะนำ Convex จาก t3.gg ที่ วิดีโอ, Convex ในโครงสร้างนั้นช่วยให้ได้ผลตั้งแต่รอบแรกมากกว่าเดิม พอเอาไปลองจริงก็รู้สึกเห็นด้วย ทิศทางพัฒนา workflow ในอนาคตน่าจะเป็นว่าเพื่อใช้ AI หลายตัวทำงานขนานกันเต็มที่ แทนที่จะกระโดดเข้าโค้ดทันที ผมอาจสร้าง ticket หลายใบใน PM tool (Linear ที่ดูเป็นเทรนด์ตอนนี้) แล้วให้ AI กรองว่าสามารถรันขนานได้อันไหน จากนั้นค่อยทำหลาย ticket พร้อมกันใน IDE หรือ Warp ผมเองยังไม่ทำตามรูปแบบนี้เต็มที่ แต่กำลังคิดจะปรับเปลี่ยน และเพื่อรองรับสิ่งนี้ git worktree จำเป็นมาก เอกสารเพิ่มเติม, เอกสาร, บล็อก
    • ผมสงสัยว่าถึงระดับไหนที่สามารถสรุปได้ว่า “ดีและเชื่อถือได้” ผ่านมาหลายมิติแล้ว และ 70 ชั่วโมงย่อมเพียงพอสำหรับ PoC เท่านั้น แต่ยังรอดูกันว่าความสมบูรณ์จะอยู่ที่ไหนเมื่อค่อยๆ เติมฟีเจอร์เพิ่มๆ
    • แม้ว่าโมเดลเชิง reasoning ของ OpenAI จะให้โค้ดและความสามารถแก้ปัญหาดีกว่า แต่ Claude Code ให้ความรู้สึกใช้งานได้จริงมากกว่า ผมเลยคิดว่าแม้โมเดลตัวหลักอาจไม่ถึงระดับสูง แต่เหมาะกับงานใช้จริงมากกว่า
  • ถ้าประสิทธิภาพ benchmark เทียบเท่า ก็ยิ่งทำให้ pricing policy นี้น่าดึงดูด: อินพุต 1.25 ดอลลาร์ต่อ 1 ล้านโทเค็น, อินพุตที่มี cache 0.125 ดอลลาร์ต่อ 1 ล้าน, เอาต์พุต 10 ดอลลาร์ต่อ 1 ล้าน (เทียบว่า Claude Opus 4.1 ยังอยู่ที่อินพุต 15 ดอลลาร์, เอาต์พุต 75 ดอลลาร์ต่อ 1 ล้าน) ตอนนี้สิ่งสำคัญที่ต้องดูคือการใช้งานเครื่องมือเทียบกับ Claude Code ตอนนี้เดโมดูดี แต่ใน Tau2-bench airline ผลกลับยังต่ำกว่า o3 จึงยังไม่กล้าสรุป
    • จากการทดสอบด้วยตัวเองในช่วงไม่กี่ชั่วโมงล่าสุด ผมรู้สึกว่า GPT-5 ค่อยๆ ดีขึ้นเมื่อเทียบกับ Opus 4.1 ผมใช้แผน Claude Code 200 มาหลายเดือน และเห็นว่าผลงานค่อยๆ ทำให้ผิดหวังลงเรื่อยๆ ผมคิดว่า GPT-5 ก้าวไปอีกขั้น
    • เรื่องราคาน่าสนใจตรงว่ามันทำงานแบบผสมโมเดลย่อยมากกว่า 2 แบบ แต่ยังตั้งราคาโทเค็นแบบเดียวกันทั้งหมด ดูเหมือนถูกออกแบบบนสมมติฐานให้โมเดลต้นทุนต่ำถูกใช้มากขึ้น หากผู้ใช้เลือกใช้งานโมเดลที่ดีกว่าเกินไปบ่อยๆ ราคากลไกนี้จะยังคงอยู่หรือไม่ ผมยังสงสัย หรืออาจตั้ง margin ไว้สูงพอจนไม่ต้องกังวล
    • ราคาไม่เท่ากับต้นทุนโดยตรง ผมคิดว่าราคาปัจจุบันถูกตั้งต่ำเพื่อแย่งส่วนแบ่งแพลตฟอร์มมากกว่า จึงอาจไม่สะท้อนต้นทุนรันจริง ในเดือนมีนาคม เงิน 400 ล้านดอลลาร์ที่ได้รับมานั้น ผมคาดว่าจำนวนไม่น้อยจะถูกใช้ในการแข่งขันลดราคาแบบรุนแรง
  • ข่าวระบุว่า “GPT-5 เซ็ตสถิติใหม่สูงสุด 96.7% ในการเรียกใช้เครื่องมือ agentic task บน τ2-bench telecom” แต่ใน benchmark airline กลับทำได้แย่กว่า o3 และดูเหมือนข้อความโฆษณาเน้นแต่ข้อมูลที่เป็นประโยชน์ต่อตัวเอง
    • ในฐานะคนที่เคยเขียนกราฟและ section นี้เอง ผมอยากย้ำว่าข้อมูลประเมินที่ดีจริงๆ อยู่ฝั่ง telecom แน่นอน ส่วน retail กับ airline benchmark ใช้การประเมินอัตโนมัติแบบเข้มเกินไป กำหนดคำตอบเดียวเป็นเกณฑ์จึงทำให้มี solution ที่ดีๆ หลายแบบไม่ได้รับคะแนน ใน telecom benchmark วัดคะแนนตามสถานะผลลัพธ์และยอมรับคำตอบที่หลากหลาย จึงแก้ข้อจำกัดของการประเมินอัตโนมัติ ทำให้สัญญาณประสิทธิภาพจริงชัดขึ้นกว่าเดิม เพราะฉะนั้นจุดเน้นที่ telecom ก็ค่อนข้างสมเหตุสมผล ดูเพิ่มได้จาก เอกสารงานวิจัย tau2-bench โดยการประเมินแบบนี้ไม่มีคะแนนย่อย จึงมีความเสี่ยงว่าความผิดพลาดเล็กน้อยจะแปลงเป็นการตกคะแนนใหญ่ได้ง่าย ทำให้ประสิทธิภาพจริงอาจสูงหรือต่ำกว่าคะแนนที่รายงาน
    • เรื่องต้นทุนก็ยังเป็นคำถามอยู่ เพราะผมได้ยินว่า o3 รันค่อนข้างแพง หาก GPT-5 ถูกกว่า ก็ถือว่าเป็นการปรับปรุงที่มีความหมายได้แม้ performance ใกล้เคียงกัน
    • เพราะตัวบทความเองก็ยอมรับว่าใน airline ได้ผลต่ำกว่า จึงไม่คิดว่าคำถามนี้เป็น “trick question”
  • ผมสนใจการรองรับ CFG (context-free grammar) และ regex เป็นพิเศษ โดยเฉพาะอยากรู้ความต่างระหว่างสิ่งนี้กับการใช้ Lark-like CFG ของ llguidance ที่ใช้สร้าง JSON schema ใน OpenAI API อ่านที่นี่
    • สิ่งที่น่าหวังมากที่สุดจากการเผยแพร่ครั้งนี้คือเรื่อง CFG และ structured output ตอนนี้ที่ API, Google, OpenAI ฯลฯ ยังมีปัญหานี้ในงานใช้งานจริงอยู่ ผมอยากลองให้เร็วที่สุด
  • Cursor ใช้ได้ฟรีไม่กี่วัน สำหรับผมที่ใช้งาน IDE/CLI หลายตัวแบบ power user ของ agentic coding มาตลอด ชุด Cursor + GPT-5 ให้ความรู้สึกดีมาก แนะนำให้ลองใช้ด้วยตัวเองเมื่อมีเวลา
  • นวัตกรรมที่ทำให้บังคับ context-free grammar ในการ output ได้โดยตรงน่าตื่นตาตื่นใจมาก และผมอยากรู้ว่าระบบ sampling บังคับไวยากรณ์ที่ถูกต้องได้อย่างไร
    • ผมเดาว่าเป็นแนวทาง “structured generation” หรือ “guided generation” ซึ่งถ้าคุณเคยใช้ LLM โดยตรงคงเห็นว่าเทคนิคนี้มีการนำไปใช้มานานแล้ว ตัวอย่างที่ 1, ตัวอย่างที่ 2 แก่นคือที่แต่ละขั้นตอนการสร้างโทเค็น เราไม่ให้ vocabulary ทั้งหมด แต่จะให้เฉพาะโทเค็นที่ไวยากรณ์ปัจจุบันอนุญาตเท่านั้น เช่น ในกรณี JSON เมื่อขึ้น { โปรแกรมจะให้อักขระที่เป็นไปได้อย่างถูกต้องเท่านั้น
    • มันใช้ชุดโทเค็นที่เป็นไปตามกฎการสร้างไวยากรณ์เป็นตัวอย่างในการ sampling ทั้งหมด ในโหมดการอนุมาน (inference) โดยตรง
  • การที่ benchmark เปรียบเทียบเฉพาะ GPT-5 กับรุ่นก่อนหน้าโดยไม่เอาโมเดลคู่แข่งมาเปรียบ ทำให้นึกถึงตอน Apple เปรียบ iPhone กับรุ่นก่อนหน้าของตัวเองเท่านั้น
  • เมื่อทดสอบ GPT-5 กับโจทย์ยากๆ ที่ Gemini แก้ไม่ได้ มันทำการวิเคราะห์ปัญหาได้ดีมาก แต่หลังจากนั้นพยายามแก้โค้ดไปถึง 6 ครั้งก็ยังพลาดทั้งหมด พอเอาผลการวิเคราะห์ของ GPT-5 ให้ Google Gemini ทำต่อ มันก็ออกแบบโค้ดแก้ที่ถูกต้องทันที สรุปคือ ChatGPT วิเคราะห์และ code review ได้ดี แต่ความสามารถเขียนโค้ดจริงยังไม่ถึงใจ
    • ผมเองก็เคยพบว่า Gemini(GCA) และ CoPilot(Claude) วิเคราะห์ปัญหาเดียวกันแล้วให้วิธีแก้ที่ผิดแบบเดียวกันหมด บอกให้แก้จุดผิด ๆ กลับยิ่งได้คำตอบที่พลาดมากขึ้น และสำหรับ ChatGPT ผมยังไม่เคยลอง แต่กำลังจะลองในเร็วๆ นี้