MAI-Code-1-Flash

 (microsoft.ai)
2 คะแนน โดย GN⁺ 2 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • MAI-Code-1-Flash คือโมเดลเขียนโค้ดใหม่ของ Microsoft ที่มุ่งช่วยงานเขียนโค้ดได้รวดเร็วและมีประสิทธิภาพในเวิร์กโฟลว์ประจำวันของนักพัฒนา และกำลังทยอยเปิดให้ผู้ใช้ GitHub Copilot แบบบุคคลทั่วไปบน VS Code ใช้งาน
  • Microsoft ฝึกโมเดลนี้โดยตรงบน GitHub Copilot harness เพื่อให้ออกแบบมาสำหรับการโต้ตอบกับเครื่องมือและระบบในสภาพแวดล้อมการพัฒนาจริงได้ดียิ่งขึ้น
  • ด้วย การควบคุมความยาวคำตอบแบบปรับตามสถานการณ์ โมเดลจะตอบสั้นสำหรับคำขอที่เรียบง่าย และใช้ budget การให้เหตุผลมากขึ้นกับงานที่ซับซ้อนกว่า โดยแก้ปัญหาที่ยากขึ้นได้ด้วยโทเค็นน้อยลงสูงสุด 60% {p:60}
  • ในการประเมิน production harness ของ Microsoft โมเดลนี้มีอัตราผ่านสูงกว่า Claude Haiku 4.5 ใน benchmark การเขียนโค้ดหลักทั้ง 4 รายการ และใน SWE-Bench Pro นำอยู่ 16 จุดที่ 51.2% เทียบกับ 35.2%
  • ใน benchmark การให้เหตุผลเชิงปฏิปักษ์แยกต่างหาก โมเดลทำ ความแม่นยำแบบปรับค่า 85.8% จาก 186 ข้อใน 34 หมวดหมู่ แต่ในหมวดปฏิปักษ์สำคัญอย่าง Einstellung trap ยังมีความแม่นยำต่ำกว่า 50% จึงยังมีพื้นที่ให้ปรับปรุง

การเปิดตัวและการปล่อยใช้งาน

  • MAI-Code-1-Flash คือโมเดลเขียนโค้ดใหม่ของ Microsoft ที่สร้างมาเพื่อช่วยงานนักพัฒนาในชีวิตประจำวันได้อย่างรวดเร็วและมีประสิทธิภาพ
  • Microsoft สร้างขึ้นเองทั้งหมดตั้งแต่ต้นจนจบ และใช้ข้อมูลที่สะอาดและมีไลเซนส์เหมาะสม
  • กำลังทยอยเปิดให้ผู้ใช้ GitHub Copilot แบบบุคคลทั่วไปบน VS Code ใช้งาน โดยเข้าถึงได้จากตัวเลือกโมเดลและภายใต้ Auto picker เริ่มต้น
  • ไม่ต้องตั้งค่าเพิ่มเติม และเมื่อการปล่อยใช้งานมาถึง GitHub Copilot จะ route งานไปยัง MAI-Code-1-Flash ผ่าน Auto picker หรือแสดงโมเดลนี้ในตัวเลือกโมเดลโดยตรง
  • จะเปิดรับความคิดเห็นผ่าน GitHub Community

การออกแบบที่ยึดเวิร์กโฟลว์นักพัฒนาเป็นศูนย์กลาง

  • MAI-Code-1-Flash ไม่ได้ถูกสร้างมาเพื่อปรับแต่ง benchmark อย่างเดียว แต่ให้เวิร์กโฟลว์การทำงานจริงที่นักพัฒนาใช้ทุกวันเป็นแกนหลัก
  • โมเดลถูกฝึกโดยตรงด้วย GitHub Copilot harness ที่ใช้ใน production เพื่อให้เรียนรู้วิธีจัดการเครื่องมือและระบบรอบข้างในงานเขียนโค้ดแบบเอเจนต์
  • ระหว่างการฝึก มีการประเมิน checkpoint ด้วยงานด้านวิศวกรรมซอฟต์แวร์หลัก การถามตอบกับ repository การรีแฟกเตอร์ และงานจาก telemetry ที่ดัดแปลงมาจากการใช้งาน GitHub Copilot จริง
  • เป้าหมายของแนวทางนี้คือทำให้สภาพแวดล้อมการฝึก การประเมิน และ production สอดคล้องกัน เพื่อให้การปรับปรุงแบบออฟไลน์ส่งผลต่อคุณภาพที่นักพัฒนาสัมผัสได้จริง

ประสิทธิภาพการใช้โทเค็นและรูปแบบการตอบ

  • โมเดลเรียนรู้การควบคุมความยาวของคำตอบแบบปรับตามลักษณะงาน เพื่อปรับระดับความลึกของคำตอบตามความยากของโจทย์
  • สำหรับคำขอที่เรียบง่ายจะตอบอย่างกระชับ ส่วนปัญหาที่ต้องการการวิเคราะห์ลึกขึ้นหรือการแก้ไขโค้ดในวงกว้างจะใช้ budget การให้เหตุผลมากขึ้น
  • นักพัฒนาจึงสามารถเริ่มเห็นผลลัพธ์ที่มีประโยชน์ได้เร็วขึ้น
  • MAI-Code-1-Flash แก้ปัญหาที่ยากกว่าได้ด้วยโทเค็นน้อยลงสูงสุด 60% โดยมุ่งลด latency ลดต้นทุน ปรับปรุงผลตอบแทนต่อโทเค็น และทำให้เวิร์กโฟลว์แบบโต้ตอบลื่นไหลขึ้น

ผลลัพธ์บน benchmark การเขียนโค้ด

  • Microsoft ประเมิน MAI-Code-1-Flash และ Claude Haiku 4.5 ด้วย production harness เดียวกันบน SWE-Bench Verified, SWE-Bench Pro, SWE-Bench Multilingual และ Terminal Bench 2
  • การประเมินวัดทั้งอัตราความสำเร็จของงานและจำนวนโทเค็นเฉลี่ยของคำตอบที่ใช้เพื่อทำแต่ละงานให้เสร็จ
  • MAI-Code-1-Flash มีอัตราผ่านสูงกว่า Claude Haiku 4.5 ใน benchmark การเขียนโค้ดหลักทั้ง 4 รายการที่ทดสอบ
  • ในงานจริงที่หลากหลายของ SWE-Bench Pro โมเดลนำอยู่ 16 จุดที่ 51.2% เทียบกับ 35.2%
  • ใน SWE-Bench Verified โมเดลแก้ปัญหาที่ยากกว่าได้ด้วยโทเค็นน้อยลงสูงสุด 60% แสดงให้เห็นว่าความแม่นยำและประสิทธิภาพสามารถดีขึ้นพร้อมกันได้

การทำตามคำสั่ง การให้เหตุผล และข้อจำกัด

  • MAI-Code-1-Flash ทำได้ดีกว่า Claude Haiku 4.5 ในทุก benchmark ที่อยู่ในตาราง และในด้านการทำตามคำสั่งอย่างแม่นยำของ IF Bench มีช่องว่างมากที่สุดที่ +28.9
  • ในการประเมินแบบ rubric-based ของ Advanced IF มีช่องว่างแคบที่สุดที่ +14.5
  • ความสามารถด้านการทำตามคำสั่งที่แข็งแกร่งยังต่อยอดไปถึงการใช้เครื่องมือแบบเอเจนต์
  • โมเดลยังทำได้ดีกว่า Claude Haiku 4.5 ในความสามารถการให้เหตุผลหลักสำหรับคณิตศาสตร์ วิทยาศาสตร์ และการเขียนโค้ดเพื่อการสร้างภาพ
  • benchmark มาตรฐานอาจให้รางวัลกับการท่องจำพอ ๆ กับการให้เหตุผล เช่น โมเดลที่เคยเห็นโจทย์ Monty Hall อาจตอบถูก แต่ถ้าพลิกเงื่อนไขรางวัลกลับด้านอาจล้มเหลวได้
  • Microsoft ได้สร้าง benchmark จำนวน 186 ข้อใน 34 หมวดหมู่ โดยเน้นกับดักเชิงปฏิปักษ์อย่าง inverted classics, impossible tasks และ underdetermined scenarios
  • MAI-Code-1-Flash ทำได้ดีกว่า Claude Haiku 4.5 โดยรวมบน benchmark เชิงปฏิปักษ์นี้ และทำความแม่นยำแบบปรับค่าได้ 85.8%
  • โมเดลโดดเด่นเป็นพิเศษด้านการให้เหตุผล การทำตามคำสั่ง และการรับรู้ปัญหาที่เป็นไปไม่ได้ แต่ในหมวดปฏิปักษ์สำคัญอย่าง Einstellung trap ยังมีความแม่นยำต่ำกว่า 50% จึงยังมีพื้นที่ให้ปรับปรุง

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

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

 
GN⁺ 2 시간 전
ความคิดเห็นจาก Hacker News

  • ตาม model card นี่คือโมเดลขนาด 137B พารามิเตอร์ โดยรวมแล้วประสิทธิภาพดูไม่ได้ดีนัก: MAI-Code-1-Flash (137B-A5B) ได้ SWE-bench pro 51%, ส่วน Qwen3.6-35B-A3B ได้ SWE-bench pro 49.5%(https://huggingface.co/Qwen/Qwen3.6-35B-A3B)
    เขาเอาไปเทียบกับ Claude Haiku แต่ Haiku ก็ไม่ใช่โมเดลที่ดีนัก และยังสู้โมเดลเปิดขนาดเล็กที่รันได้ทั้งแบบ local หรือผ่าน API ด้วยต้นทุนราว 10% ไม่ได้

    • ประเด็นสำคัญน่าจะเป็นว่าโมเดลนี้คือ โมเดลเล็กที่แข่งกับ Haiku และหวังว่าถัดไปจะมีรุ่นที่แข่งระดับ "Sonnet" แล้วต่อด้วยรุ่นที่แข่งระดับ Opus ออกมา
      ก่อนหน้านี้สงสัยมาตลอดว่าทำไม Microsoft ถึงช้ามากในการเอาโมเดลที่ตัวเองทำมาใส่ใน Copilot ตอนนี้เลยคิดว่าอาจเป็นส่วนหนึ่งของข้อตกลงกับ OpenAI ก็ได้
    • ถ้าเป็น 137B-A5B ก็ไม่ใช่โมเดล 5B พารามิเตอร์อย่างที่ชื่อพาดหัวก่อนหน้านี้ชวนให้เข้าใจ

  • ถือว่าเป็นการเริ่มต้นที่ดีและการแข่งขันก็เป็นเรื่องน่ายินดี แต่แทบไม่เคยใช้ โมเดลคลาวด์ขนาดเล็ก อย่าง Haiku 4.5 สำหรับงานเขียนโค้ดเลย
    มันดูน่ารักดีแต่สำหรับการเขียนโค้ดแบบจริงจังมักเสียเวลาอันมีค่าของผมไปเปล่า ๆ และยังไม่มากพอจะทำให้กลับไปใช้ GitHub Copilot ที่เพิ่งยกเลิกไปเมื่อวาน
    GitHub Copilot ก่อนหน้านี้ถึงเมื่อวานยังถือว่าคุ้มราคา แต่ตอนนี้เปลี่ยนเป็นระบบโควตาต่อโทเค็นในกลุ่มที่แพงที่สุดแบบคิดเงินตามคำขอ ถ้าอยากขำก็ไปดูซับเรดดิตที่กำลังลุกเป็นไฟได้: https://www.reddit.com/r/GithubCopilot
    หลังจากนั้นก็เปลี่ยนไปใช้ DeepSeek Flash high ที่แทบจะฟรีและระดับ Sonnet+ และถ้าต้องการโมเดลที่ฉลาดกว่านี้ก็คงสมัคร Codex เดือนละ $20 เพื่อใช้ GPT 5.5 ที่มองว่าตอนนี้ดีที่สุดเท่าที่เข้าถึงได้

    • จัดงานด้วยโมเดลใหญ่ให้เป็น กราฟงานแบบ topological sort แล้วจับคู่โมเดลเล็กให้แต่ละงานตามความซับซ้อน จากนั้นให้โมเดลใหญ่ประเมินและแก้จุดที่จำเป็น
      ในวิธีนี้ผมใช้ Haiku กับงานประจำวันค่อนข้างบ่อย และแม้งานซับซ้อนสูงที่กินเวลาหลายชั่วโมงก็ทำได้ผลลัพธ์ดีกว่าและต้นทุนต่ำกว่ามาก โดยมีตัว orchestrator หลักคอยจัดระเบียบงาน ตรวจคุณภาพ และรวมผลในจุดที่จำเป็น ทำให้เกิดแรงงานขนาดมหาศาลภายใน context window เดียว
      ผมไม่ได้ใช้ Haiku โดยตรง แต่บ่อยครั้งมันกิน 30~40% ของการใช้โทเค็นในงานใหญ่ ๆ ทั้งเวลาเสร็จงานและต้นทุนก็ดีขึ้น และ Haiku ดีกว่าในแง่การทำตามคำสั่งและแผนแบบตรงตัวโดยไม่ “ตีความใหม่” ขณะที่โมเดลระดับ Opus มักจะคอยตั้งข้อสงสัยและย้อนถามระหว่างกระบวนการคิด
      เพราะงั้น Haiku ไม่ได้เสียเวลา แต่ช่วยประหยัดเวลาอย่างมหาศาล เพียงแต่กว่าจะมาถึงจุดนี้ก็ต้องใช้เวลามากในการสร้างระบบ orchestration ขึ้นมาก่อน แล้วค่อย ๆ ปรับปรุงซ้ำต่อเนื่อง ที่น่าสนใจก็คือประสบการณ์จากการเป็น director และต่อมาเป็น distinguished engineer ช่วยให้มีเครื่องมือพอจะทำให้สิ่งนี้เดินได้อย่างเสถียรจนสุดทาง และโฟลว์ multi-agent ที่มีความสามารถหลากหลายก็แทบไม่ต่างจากพลวัตขององค์กรวิศวกร 1,000 คน
    • พอลอง benchmark หลายโมเดลเพื่อใช้ค้นหา security bug ที่ยาก ๆ ความ เชื่อมั่นต่อ Haiku และ Sonnet ก็ลดลงอย่างรวดเร็ว
      Qwen 3.6 27B ที่โฮสต์เองทำได้ดีกว่าทั้งสองตัวอย่างสม่ำเสมอในการตรวจจับ security bug ซึ่งเป็นผลลัพธ์ที่ค่อนข้างน่าตกใจ เดิมคิดว่า Qwen น่าจะอยู่ระดับเดียวกับ Haiku หรือด้อยกว่านิดหน่อย และน่าจะแพ้ Sonnet ชัดเจน
      DeepSeek และ MiMo ทำได้ดีกว่า Haiku และ Sonnet มาก ในขณะที่ต้นทุนเป็นเพียงเศษเสี้ยว และเข้าใกล้ระดับ Opus/GPT 5.5
      ถ้าไม่ได้ใช้ฟรีหรือไม่ได้รวมอยู่ในค่าสมาชิกที่ปกติก็ใช้ไม่หมดอยู่แล้ว ก็ดูแทบไม่มีเหตุผลให้ใช้ Haiku หรือ Sonnet
    • ผมก็แทบจะเจอสถานการณ์เดียวกัน DeepSeek แทบไม่ค่อยปฏิเสธ และด้วยค่านิยมแบบจีน ทำให้มีแรงเสียดทานน้อยกว่ามากในงานอย่าง reverse engineering, การหาไฟล์ที่มีลิขสิทธิ์, หรือการทำงานกับ source code ที่แหล่งที่มาชวนสงสัย
      ต่อให้ Copilot ลดราคา 90% ก็คงไม่กลับไปใช้
    • นี่ดูอยู่ในช่วงเดียวกับ Qwen 3.6, Gemma 4, Nemotron 3 Super
      มีโมเดลที่แข่งกับ Haiku ได้อีกมาก และบางตัวก็เล็กและถูกกว่ามาก เช่น Qwen 3.6 35B-A3B แบบนี้รันบนโน้ตบุ๊กได้ จึงไม่จำเป็นต้องไปเช่าจาก Microsoft
      ผมตกใจกับบิล Copilot แบบใหม่เหมือนกัน แต่มันอาจยังเป็นตัวเลือกสำหรับคนที่อยากอยู่ใน ecosystem ต่อไป ทว่าสำหรับคนส่วนใหญ่มีตัวเลือกที่ดีกว่าอยู่เต็มไปหมด
    • แพ็กเกจ ChatGPT เดือนละ $20 ที่รวม Codex มาด้วยถือว่าคุ้มมาก
      แค่มี ChatGPT แบบพรีเมียมก็ใช้งานได้ดี แม้จะชนลิมิตการใช้งานเป็นประจำ แต่สำหรับงานส่วนใหญ่ก็ยังเอาอยู่

  • มีใครใช้ โมเดลเล็กแบบนี้กับงานเขียนโค้ด จริง ๆ ไหม? ถ้ามี อยากรู้ว่าใช้งานกันยังไง
    ปกติผมจัดการทุกอย่างด้วย Opus ทั้งหมด อยากฟังความเห็นจากคนที่ลองทั้งสองแบบและทดสอบมาแล้ว ว่าใช้โมเดลที่หนักกว่าสำหรับวางแผน/ออกแบบ/สถาปัตยกรรม แล้วมอบงานที่มีโครงสร้างให้โมเดลเล็กทำต่อหรือเปล่า

    • ที่ทำงานผมใช้ Opus 4.x ส่วนที่บ้านใช้โมเดล “เล็ก” พวกนี้ (20~80B, active 3~4B)
      น่าเสียดายที่ตอนนี้ยังเทียบกันไม่ได้
      กับ Opus คุณสามารถเชื่อใจให้มันช่วยออกแบบ เสนอแนวทางสถาปัตยกรรม และแก้โค้ดได้ แม้ในโค้ดเบสที่ซับซ้อน
      ส่วนโมเดลเล็ก ๆ จะให้ความรู้สึกว่าแค่ “พยายาม” ทำอยู่ งานเล็ก ๆ พอไหว แต่พอเป็นงานซับซ้อนก็มักกลายเป็นว่ามีงานเพิ่มมากกว่าทำเอง
      ก็หวังว่ามันจะต่างออกไป และอีก 1~2 ปีข้างหน้าอาจจะต่างก็ได้
    • การใช้โมเดลที่หนักกว่าสำหรับวางแผน/ออกแบบ/สถาปัตยกรรม แล้วให้โมเดลเล็กทำงานที่มีโครงสร้างต่อ เป็น แนวทางแบบนี้มาตลอด
      ใน claude code มี opusplan ซึ่งจะใช้ Opus ตอนอยู่ในโหมดวางแผน แล้วสลับไปใช้ Sonnet ตอนลงมือทำ
      https://code.claude.com/docs/en/model-config#opusplan-model-...
      แก้ไข: จะตั้งเป็นให้วางแผนด้วย Sonnet แล้วให้ Haiku ลงมือทำ หรือจัดชุดอื่นตามต้องการก็ได้
      https://code.claude.com/docs/en/model-config#control-the-mod...
    • Haiku ค่อนข้างถูกและไม่ค่อยพังหนัก เลยเคยใช้กับ การเขียนโค้ดแบบโต้ตอบ บนโปรเจ็กต์เดิมในแผน Copilot รุ่นก่อน
      ถ้าเป็นฟีเจอร์ง่าย ๆ ก็ไม่ได้วางแผนแบบเต็มรูปแบบ แค่เขียนโค้ดไปนิดหน่อย แล้วใช้พรอมป์สั้น ๆ บรรทัดเดียวบอกโมเดลว่าต้องทำอะไร บางครั้งก็ใส่คอมเมนต์ชั่วคราวในโค้ดเพื่อบอกทิศทาง
      โดยทั่วไป ถ้าการแก้โค้ดยังอยู่ในไฟล์หรือแพ็กเกจเดียว Haiku ก็พอตามคำขอได้และไม่เละเทะเกินไป ช่วงเวลาที่ใช้ GitHub Copilot หลายเดือนนั้น ผมยังพัฒนาทักษะในการคอยชี้ทิศทางมันไปเรื่อย ๆ ด้วย และบางครั้งก็เคยรีบใช้เครดิตที่เหลือตอนสิ้นเดือนแบบลน ๆ
      แค่การเติมโค้ดอัตโนมัติด้วย AI อย่างเดียวก็มีหลายครั้งที่ดีใช้ได้ แค่เขียนคอมเมนต์ชั่วคราวว่าโค้ดต้องทำอะไร แล้วกด Tab-Tab-Tab ก็อาจได้ทั้งฟังก์ชันออกมาเลย
      คนมักโน้มไปหาโมเดลระดับสูงกว่าเพราะคิดว่ามันจะพังน้อยกว่า แต่ถ้าคุณเข้าใจโค้ดจริง ๆ การทำงานแบบโต้ตอบกับโมเดลระดับล่างกลับง่ายกว่า
    • ผมแยกการลงมือแก้ไขออกเป็นความรับผิดชอบอีกชั้นหนึ่ง
      ตั้งแชตหลักให้ Opus เป็น “orchestrator” กำหนดเป้าหมาย แล้วให้มันผลักไปจนกว่าจะถึงเป้าหมายโดยใช้ sub-agent ต่อไปนี้ตามลำดับ
      1. ลงมือทำเป็นขั้นตอน (Sonnet): ทำงานตามคำสั่งของ orchestrator เป็นเวลา 30 นาที/100k โทเคน
      2. ตรวจทาน (Opus): ตรวจหาข้อผิดพลาดและความสอดคล้องกับคำสั่งจากงานของขั้นก่อนหน้าอย่างละเอียด จากนั้นแก้ไข และบันทึกโอกาสในการปรับปรุงการตั้งค่า agent+เครื่องมือเพื่อลดข้อผิดพลาดและการใช้โทเคนไว้ในไฟล์
      3. ปรับปรุงตัวเอง (Opus): ลงมือทำรายการ self-improvement ที่มีผลกระทบสูงและไม่ต้องอาศัยการแทรกแซงจากผู้ใช้
        ทำซ้ำ: ดำเนินต่อไปจนกว่า budget โทเคนของเซสชัน orchestrator จะหมด ตั้งไว้เป็น 1M อะไรทำนองนั้นได้
        ตรรกะพื้นฐานคือรักษาให้แต่ละขั้นมีขนาดที่จัดการได้ เพื่อเพิ่มอัตราการทำตามคำสั่งและลดต้นทุน เพราะแม้แต่โทเคนที่แคชไว้ก็ยังมีค่าใช้จ่าย โทเคนในพรอมป์ต์ถูกกว่าโทเคนที่สร้างออกมามาก ดังนั้นยิ่งทำให้ Opus เน้นตรวจทานมากกว่านำลงมือเอง ก็ยิ่งประหยัดค่าใช้จ่ายได้มาก
        ขั้น self-improvement แพงมาก แต่การปรับปรุงจะสะสม ถ้าคุณจะรันงานที่กินเวลาหลายวันหรือหลายสัปดาห์ การไม่ทำขั้นนี้จะแพงกว่ามาก
        แก้ไข: ทำทั้งกับโมเดล Anthropic ใน Claude Code และกับโมเดลสาย Qwen สำหรับการใช้งานออฟไลน์
    • ตัว Claude Code เองก็เรียกใช้ sub-agent จำนวนมากด้วย Haiku
      โมเดลนี้ อัตราหลอนต่ำ จึงเหมาะกับงานสำรวจ และดูเหมือนโมเดลนี้ก็น่าจะเหมาะกับการใช้งานคล้ายกัน งานหลายอย่างเริ่มจากปล่อย agent สำรวจหลายตัวก่อนวางแผนหรือแก้ไข และหลังจากนั้นมักจบด้วยการเรียกเครื่องมือไม่กี่ครั้ง เลยใช้โทเคนเยอะด้วย

  • กำลังเอาโมเดลนี้ไปเทียบกับ Haiku 4.5
    ไม่ใช่ทั้ง Opus หรือ Sonnet แต่เป็น Haiku ซึ่งเป็นโมเดลที่เล็กที่สุดของ Anthropic แถมยังเป็นเวอร์ชันเมื่อ 3 รุ่นก่อนด้วย

    • 4.5 ยังเป็น Haiku รุ่นล่าสุดอยู่

  • ทำไมทุกคนถึงชอบเอาการเลื่อนหน้าต่างมาทำใหม่แบบเละเทะแบบนี้กันนะ?

    • น่าจะทำด้วย vibe coding มั้ง ผมบล็อกด้วย StopTheMadness ไว้
    • เห็นปุ๊บก็ปิดทันทีเลย

  • แปลกมากที่ benchmark ยังต่ำขนาดนี้ แต่กลับทำการตลาดเหมือนโมเดลปฏิวัติวงการ
    ถ้าจะบอกว่าแม้ความสามารถด้านโค้ดจะต่ำก็ไม่เป็นไร งั้นก็ควรดูคู่กับการขึ้นราคาโทเคนและการตั้งให้เป็นโมเดล “ใช้งานทั่วไป”
    ทำไมไม่ขายมันเป็นเอเจนต์คณิตศาสตร์ไปเลยล่ะ? ทำไมผมต้องตั้ง เอเจนต์ 4 ตัว ให้คอยตรวจงานกันเองด้วย?

    • เท่าที่ผมเข้าใจ ต่างจากโมเดลอื่น ๆ ตรงที่ โมเดล MAI ยังไม่ได้ผ่านการ fine-tune ด้วยชุดข้อมูลสังเคราะห์ที่ออกแบบมาเป็นพิเศษเพื่อดันคะแนน benchmark
    • ประเด็นสำคัญคือ ประสิทธิภาพต่อราคา
      ถ้าได้คะแนนระดับนั้นจาก 5B พารามิเตอร์ ก็ถือว่าดีมาก และเมื่อไม่นานมานี้ยังแทบไม่น่าเชื่ออยู่เลย
      ผมคิดว่าโมเดลเล็กจะยิ่งดีขึ้นเรื่อย ๆ และโมเดลล้ำหน้าบนคลาวด์ก็จะเล็กลงด้วย
      นี่ก็เป็นอีกเหตุผลหนึ่งที่การขยายโครงสร้างพื้นฐานขนาดใหญ่ตอนนี้ให้ความรู้สึกเหมือนทางรถไฟ

  • บล็อกโพสต์เปิดตัวมีข้อมูลเยอะกว่ามาก
    https://microsoft.ai/news/introducingmai-code-1-flash/
    และก็มี model card ด้วย
    https://microsoft.ai/pdf/MAI-Code-1-Flash-Model-Card.PDF
    active 5B ในชื่อเรื่องน่าจะมาจากประกาศที่กว้างกว่านั้นเกี่ยวกับ MAI ทั้ง 7 โมเดล
    https://microsoft.ai/news/building-a-hillclimbing-machine-la...

  • ต้องนึกย้อนกลับไปก่อนว่าเดิมที Haiku ถูกสร้างมาเพื่ออะไร
    ช่วงหลัง Anthropic ไม่ได้ทุ่มแรงกับการทำตลาดให้ Haiku มากนัก
    ถ้าต้องการโมเดลเบา ๆ ก็ใช้ Sonnet ได้เลย ในแพ็กเกจ Max แทบจะฟรีและก็ค่อนข้างเร็ว สำหรับงานเขียนโค้ดทั่วไปยังมองไม่ค่อยเห็นว่ามีตรงไหนที่ Haiku จะมีที่ยืน
    ดูเหมือนว่า Haiku จะเป็นโมเดลที่ใช้ตอนต้องการ สรุป/จัดประเภท ในปริมาณมาก
    การที่ Microsoft ใช้ Haiku เป็นจุดอ้างอิงถือว่าเป็นมาตรฐานที่ต่ำ

    • คำว่า “แทบจะฟรีในแพ็กเกจ Max” เป็นความขัดแย้งที่ชวนขำ

  • อยากให้ทดสอบเว็บไซต์บน Safari ด้วย
    ผู้ใช้ iOS แทบทั้งหมดใช้ Safari เป็นค่าเริ่มต้นอยู่แล้ว และประสบการณ์บนเดสก์ท็อปก็คล้ายกับบนมือถือพอสมควร เลยทดสอบได้ง่าย
    เอฟเฟกต์การเลื่อนนั้นกระตุกหนักมากในสภาพแวดล้อมของฉัน เข้าใจนะว่าใน Chrome/Edge มันทำงานได้ดี

    • บน Firefox+macOS ก็มีอาการเหมือน แย่งการเลื่อนหน้าจอ อยู่ชัดเจน และความรู้สึกแย่มาก

  • ถ้าเปิดตัวตั้งแต่เมื่อวาน อย่างน้อยก็คงเลี่ยงไม่ให้ระบบเลือกโมเดลอัตโนมัติของ Copilot ไปใช้ โมเดลที่แพงกว่า 9 เท่า จนเผาโควตารายเดือนไปเงียบ ๆ ภายในบ่ายเดียวได้