AI News · 2026-08-01

DeepSeek ปล่อย DeepSeek-V4-Flash-0731 บน Hugging Face ใต้ MIT License โดยไม่เปลี่ยนสถาปัตยกรรมและไม่ขึ้นราคาป้าย

ขนาดที่ถูกต้องคือ 284B parameters (13B activated) context 1 ล้าน token · ⚠ มีตัวเลขผิดลอยอยู่สองชุดที่ต้องกันไว้: "283B" ที่สำนักข่าวรายงาน และ "304B params" ที่ขึ้นบนหน้า Hugging Face ซึ่งเป็น metadata ที่แพลตฟอร์มนับ tensor ทุกก้อนใน repo (167GB) ให้อัตโนมัติ รวม speculative decoding module ที่แนบมาด้วย ไม่ใช่คำพูดของ DeepSeek

คะแนน (vendor-reported ทั้งหมด · DeepSeek วัดเองและเลือก baseline เอง): Terminal Bench 2.1 = 82.7 (Opus 4.8 = 85.0) · DeepSWE = 54.4 (ขึ้นจาก 12.8 ของ V4 Pro Preview) · แต่ในตารางเดียวกัน DSBench-Hard = 59.6 ขณะที่ Opus 4.8 = 71.7 และ NL2Repo = 54.2 ขณะที่ Opus 4.8 = 69.7

⚠ คำเคลม "ระดับ Claude Sonnet 5" ที่ปรากฏในข่าวไทยเป็น framing ของสื่อ ไม่ใช่ของ DeepSeek · ในตารางของ DeepSeek ไม่มี Claude Sonnet 5 อยู่เลย มี Opus 4.8 ตัวเดียว

ราคา ณ 1 ส.ค.: input cache miss $0.14 · cache hit $0.0028 · output $0.28 (บล็อกของ Simon Willison เขียน output เป็น $0.27 ซึ่งคลาดเคลื่อน)

และนี่คือส่วนที่สำคัญกว่าคะแนน: เชิงอรรถบนหน้าราคาระบุว่า "The DeepSeek API service will soon adopt a peak/off-peak pricing policy. During peak hours, prices will be 2x the regular prices, applicable to all billing items. The effective date will be subject to the official announcement." · ชั่วโมงเร่งด่วนคือ 09:00-12:00 และ 14:00-18:00 เวลาปักกิ่ง ซึ่งคาบเกี่ยวเวลาทำงานไทยเกือบทั้งหมด · ⚠ ยังไม่มีวันเริ่มบังคับ ห้ามพูดว่าเริ่มต้นเดือนสิงหาคม (เชิงอรรถที่พูดถึง "early August" เป็นคนละเรื่อง คือการรองรับโมเดล v4-pro บน Responses API)

▲ ทำไมต้องรู้ · ราคาที่เห็นตอนเลือกใช้โมเดลไม่ใช่ราคาที่จะจ่ายจริงเสมอไป เพราะ DeepSeek ประกาศว่าจะเก็บเงินสองเท่าในช่วงเวลาที่คนใช้งานมากที่สุดซึ่งตรงกับเวลาทำงานพอดี และเมื่อ weights เปิดใต้ MIT License ผู้ให้บริการรายอื่นก็เอาไปเสิร์ฟต่อได้ ราคาของ DeepSeek เองจึงไม่ใช่เพดานของโมเดลนี้ อีกจุดที่ควรระวังคือ benchmark ที่เอามาโชว์มักเลือกเฉพาะคะแนนที่ใกล้เคียงคู่แข่ง ส่วนคะแนนที่ห่างกันมากมักไม่ถูกพูดถึง

Hugging Face · DeepSeek pricing · Simon Willison · Blognone (ไทย) · deepseek-v4-flash-0731

ห้องแล็บของ Mira Murati ปล่อยรุ่นที่สองต่อจาก Inkling ที่ออกกลางเดือน · 276B total / 12B active เป็น Mixture-of-Experts transformer · context สูงสุด 1 ล้าน token

ตัวเลขที่น่าสนใจที่สุดคือมันเล็กกว่ารุ่นพี่มากแต่คะแนนสูงกว่า: Humanity's Last Exam (text-only) = 31.6% เทียบ Inkling ตัวเต็มที่ 29.7% ทั้งที่ Inkling เดิมคือ 975B/41B

คะแนนอื่น: SWEBench Verified = 80.2% · GDPval-AA v2 = 1269 Elo · VoiceBench = 90.1%

รองรับการให้เหตุผลบนเสียงและภาพในตัว โดยใช้ dMel spectrogram สำหรับเสียง และตัดภาพเป็น patch ขนาด 40x40 pixel · weights อยู่บน Hugging Face และใช้ผ่านแพลตฟอร์ม Tinker ได้

เทียบกับ DeepSeek V4 Flash, Qwen3.5-397B-A17B ฝั่ง open-weights และ GPT-5.6 Luna, Gemini 3.5 Flash-Lite ฝั่งปิด

▲ ทำไมต้องรู้ · ข้อนี้กับข่าว DeepSeek ด้านบนเล่าเรื่องเดียวกันจากคนละมุม คือโมเดลกำลังเล็กลงและถูกลงเร็วกว่าที่งบประมาณองค์กรตามทัน ตัวเลขที่สำคัญที่สุดคือ 12B active parameters เพราะเป็นตัวเลขที่กำหนดว่าต้องใช้เครื่องแรงแค่ไหนตอนใช้งานจริง ไม่ใช่ 276B ที่เป็นขนาดรวมของโมเดล อีกจุดที่น่าสนใจคือรุ่นเล็กทำคะแนนแซงรุ่นใหญ่ของตัวเองบน HLE ซึ่งเป็นสัญญาณว่าคุณภาพข้อมูลและวิธีเทรนกำลังสำคัญกว่าขนาดตัวเลข ข้อควรระวังคือคะแนนทั้งหมดเป็นของผู้ผลิตเอง ยังไม่มี independent replication และหน้าประกาศไม่ได้ระบุชื่อ license ชัดเจน บอกแค่ว่าเป็น open-weights

Thinking Machines · inkling-thinking-machines

ทีม Chrome Security เขียนว่า "In the last two milestones, Chrome 149 and 150, we have fixed 1072 security bugs, surpassing the total number of security bugs fixed across the prior 23 milestones combined."

⚠ ห้ามใช้พาดหัวของ Hacker News ที่เขียนว่า "แก้บั๊กในเดือนมิถุนายนมากกว่าสองปีที่ผ่านมา" · นั่นเป็นคำของผู้ส่ง ไม่ใช่ของ Google · Chrome 149 ขึ้น stable 2 มิ.ย. และ Chrome 150 ขึ้น 30 มิ.ย. แต่หน้าต่างของสอง milestone รวมกัน กินเวลาราว 8 สัปดาห์ ไม่ใช่หนึ่งเดือน · ให้ใช้คำของ Google คือ "สอง milestone เทียบ 23 milestone ก่อนหน้ารวมกัน" (≈ 8 สัปดาห์ เทียบ ≈ 2 ปี)

ฝั่งค้นหา: "we built an agent harness that used Gemini to find vulnerabilities across the broader Chrome codebase" และร่วมกับ DeepMind + Project Zero ทำ Big Sleep ที่หาบั๊กใน V8 และ graphics stack ได้ · ตัวอย่างที่ยกคือ sandbox escape ที่ "quietly survived in our codebase for more than 13 years!"

ฝั่งเขียนแพตช์เป็นระบบหลาย agent ที่ตรวจกันเอง: "we run a fixing agent that returns multiple candidate fixes. A critic agent then evaluates which would be the best fit... Test-writing agents help write tests for fixes." · ทั้งหมดฝังใน CI ที่ "running every 24 hours across all CLs"

Google ประเมินผลแบบ hedge ไว้เอง: "While it's hard to measure precisely, we estimate that this new process is saving hundreds of hours of developer time per month" · และระบุว่ากำลังนำร่อง "a shift to two security releases per week"

🔴 สิ่งที่โพสต์ไม่ได้บอกและห้ามเติมเอง: ไม่มีสัดส่วน AI vs คน ในบั๊ก 1,072 ตัวเลยแม้แต่ตัวเดียว · ไม่มีการแจกแจงความรุนแรง ไม่มีข้อมูลว่ากี่ตัวโจมตีได้จริงจากภายนอก ไม่มี false positive rate ไม่มีจำนวนแพตช์ที่ต้องย้อนกลับ · ⚠ กับดักตัวเลขที่ต้องกันไว้: มีสื่อรายงานว่า Chrome 151 แก้ 370 รายการโดย 349 รายการ Google รายงานเอง ตัวเลข 349 นั้นคือ internal vs external ไม่ใช่ AI vs human และเป็นของ 151 ซึ่งไม่ได้อยู่ใน 1,072

▲ ทำไมต้องรู้ · นี่เป็นหลักฐานที่หนักที่สุดชิ้นหนึ่งของปีฝั่งที่บอกว่า AI ช่วยงานได้ผลจริง และมันมาจากงานประเภทที่ตรวจถูกผิดได้ด้วยเครื่อง คือช่องโหว่ความปลอดภัยมีเกณฑ์ชัดว่าแก้แล้วหรือยัง จุดที่ควรระวังคือโพสต์นี้ไม่ได้บอกสัดส่วนงานที่มาจาก AI เทียบกับคน ไม่มีอัตรา false positive และไม่มีจำนวนแพตช์ที่ต้องย้อนกลับ ข้อควรระวังคือ AI ไม่ใช่ปัจจัยเดียวที่ทำให้ตัวเลขนี้เกิดขึ้น ยังมีงาน fuzzing เรื่อง memory safety และการเปลี่ยนจังหวะปล่อยแพตช์ประกอบด้วย

blog.google · HN 478 · BleepingComputer · chrome-ai-security-2026

Google เปิดฟีเจอร์แก้ภาพด้วยโมเดล Nano Banana ใน Google Earth โดยตั้งใจให้ใช้เรนเดอร์สถานที่ในอดีตเพื่อการศึกษา หรือจำลองโครงการพัฒนาอสังหาริมทรัพย์ · แล้วปิดภายในราวหนึ่งวัน

Google ระบุว่าพบการสร้างภาพที่ละเมิดเงื่อนไขการใช้งาน โดยเฉพาะการสร้างข้อมูลบิดเบือนเกี่ยวกับสถานที่ ในพื้นที่ที่มีสถานการณ์รุนแรงต่อเนื่อง เช่น ภาพที่เกี่ยวกับสงคราม

สิ่งที่บอกว่าจะทำก่อนเปิดใหม่: ใส่ลายน้ำบอกว่าเป็นภาพจาก AI ให้ชัด และไม่ให้ภาพที่สร้างขึ้นไปแสดงบน Google Earth โดยตรง

▲ ทำไมต้องรู้ · เหตุการณ์นี้แสดงให้เห็นว่าฟีเจอร์ AI ที่เปิดให้คนทั่วไปใช้ มักถูกใช้ผิดวัตถุประสงค์ให้เห็นภายในวันแรก ไม่ต้องรอเป็นเดือน แผนรับมือความเสี่ยงจึงต้องพร้อมตั้งแต่ก่อนปล่อยฟีเจอร์ อีกจุดที่น่าสนใจคือบริบทของภาพสำคัญกว่าตัวภาพเอง ภาพที่สร้างขึ้นลอยๆ คนยังตั้งคำถามได้ แต่ภาพเดียวกันที่ปรากฏบนแผนที่ซึ่งคนเชื่อว่าแสดงของจริง กลายเป็นหลักฐานทันที ข้อควรระวังคือรายละเอียดทั้งหมดมาจากการรายงานข่าว ยังไม่ได้อ่านแถลงการณ์ฉบับเต็มของ Google โดยตรง

Blognone (ไทย)

สเปก Model Context Protocol ฉบับใหม่เปลี่ยนหลักการพื้นฐาน โดยหน้า Base Protocol ระบุคุณสมบัติว่า "Stateless, self-contained requests" และ "Per-request capability negotiation"

changelog เขียนตรงๆ สองบรรทัด: "Remove protocol-level sessions and the Mcp-Session-Id header" และ "Make MCP stateless: remove the initialize/notifications/initialized handshake" · แบบเดิมต้องยิงสองรอบ (ขอ session ก่อน แล้วค่อยเรียก tool) แบบใหม่ยิงรอบเดียว

⚠ ชื่อ "MCP 2.0" ไม่ใช่ชื่อทางการ · MCP ใช้ระบบเวอร์ชันแบบลงวันที่ ฉบับก่อนหน้าคือ 2025-11-25 · "MCP 2.0" เป็นคำเรียกสั้นของชุมชน ถ้าใช้ต้องบอกด้วยว่าเป็นชื่อเล่น ไม่งั้นคนจะไปค้นหาเวอร์ชันที่ไม่มีอยู่

🔴 จุดที่คนเข้าใจผิดกันมากที่สุดและผู้ดูแลสเปกเตือนเอง: "stateless" หมายถึงโปรโตคอลไม่มี session ไม่ได้แปลว่าแอปเก็บ state ไม่ได้ · "Dropping the protocol-level session doesn't force your application to be stateless. If your server needs to carry state across calls, mint an explicit handle from a tool and have the model pass it back as an argument." · state ย้ายจากชั้นโปรโตคอลไปอยู่ในชั้นข้อมูลของแอป

เป็น breaking change จริง โดย compatibility matrix ระบุว่า client ใหม่ + server เก่า = ใช้ไม่ได้ และ client เก่า + server ใหม่ = ใช้ไม่ได้ · ต้องมีฝั่งใดฝั่งหนึ่งรองรับสองยุค · มี deprecation window 12 เดือน

ฝั่ง extension: Tasks (งาน async ระยะยาว) ถูกย้ายออกจาก core มาเป็น official extension แล้ว และ MCP Apps (UI ในบทสนทนา) เป็น official · ⚠ "Skills over MCP" ยังเป็นแค่ working group ยังไม่ผ่านการรับรอง ห้ามเล่าว่าเป็นมาตรฐานแล้ว

▲ ทำไมต้องรู้ · องค์กรที่ต่อ MCP เข้ากับระบบไปแล้วต้องรู้ว่ามาตรฐานนี้เพิ่งเปลี่ยนวิธีทำงานพื้นฐานของตัวเอง ของที่เขียนไว้เมื่อครึ่งปีก่อนมีวันหมดอายุแล้ว และการอัปเกรดฝั่งเดียวโดยไม่ดูอีกฝั่งจะทำให้ระบบใช้งานไม่ได้ทันที ความเสี่ยงใหม่ที่ต้องระวังคือ state ไม่ได้หายไปไหน แค่ย้ายไปอยู่ในมือคนออกแบบ tool ผ่าน handle ที่ส่งไปมา ถ้า handle นั้นเดาได้หรือไม่ผูกกับสิทธิ์ผู้ใช้ ก็จะกลายเป็นช่องให้เข้าถึงข้อมูลคนอื่นได้เพราะไม่มี session มายืนยันตัวตนอีกแล้ว ข้อควรระวังคือความเห็นที่ว่าโมเดลเล็กจะทำงานกับ MCP แบบใหม่ได้ดีขึ้น ยังเป็นการประเมินจากประสบการณ์ ไม่มี benchmark รองรับ

สเปก 2026-07-28 · changelog · ประกาศของผู้ดูแล · Simon Willison · mcp-stateless-2026

Cursor เขียนบล็อกอธิบายวิธีที่ตัวเองตั้งค่าสภาพแวดล้อมให้ cloud agent ทำงานใน monorepo ของบริษัท · ตัวเลขที่เปิด: "In December, cloud agents authored roughly one in ten PRs merged to the Cursor monorepo. Today, they write more than half." และระบุว่า agent "now author a majority of the code we ship"

⚠ สรุปชุมชนบางฉบับเขียนตัวเลขนี้เป็น "56%" ซึ่งไม่มีในต้นฉบับ · ต้นฉบับเขียนว่า "more than half" เท่านั้น

สิ่งที่บริษัทบอกว่าทำให้ตัวเลขขยับ: ทำให้สภาพแวดล้อมบนคลาวด์ตรงกับเครื่องนักพัฒนา · สร้าง CLI ตัวเดียวที่ agent เรียกใช้แทนที่จะต้องรู้คำสั่งทั้งหมด · ระบบซ่อมสภาพแวดล้อมตัวเอง · และวิเคราะห์ trace ของ agent เพื่อปรับปรุงต่อเนื่อง · ข้อสรุปของบทความคือการมองสภาพแวดล้อมนักพัฒนาเป็น "a product in its own right"

▲ ทำไมต้องรู้ · นี่เป็นตัวเลขที่หายาก เพราะบริษัทเปิดสัดส่วนงานจริงที่ AI ทำในระบบของตัวเองพร้อมจุดเริ่มต้นให้เทียบ สิ่งที่น่าสนใจกว่าตัวเลขคือสิ่งที่ทำให้มันขยับ ซึ่งไม่ใช่การเปลี่ยนไปใช้โมเดลที่เก่งขึ้นเลยสักข้อ แต่เป็นเรื่องสภาพแวดล้อมและเครื่องมือรอบตัว agent ทั้งหมด ข้อควรระวังคือ Cursor เป็นบริษัทเครื่องมือ AI ที่มีแรงจูงใจชัดเจนในการรายงานตัวเลขนี้ และ "เกินครึ่งของ PR ที่ merge" ก็ไม่เท่ากับ "เกินครึ่งของงานวิศวกรรม" เพราะ PR แต่ละอันมีขนาดและความยากต่างกันมาก

Cursor

GitHub เพิ่มฟีเจอร์ Stacked Pull Requests ซึ่งเป็นวิธีทำงานที่แตก PR ย่อยซ้อนกันเป็นชั้น แทนที่จะรวมงานทั้งก้อนไว้ใน PR เดียว

▲ ทำไมต้องรู้ · ไม่ใช่ข่าว AI โดยตรง แต่เกี่ยวข้องกับแนวโน้มที่ agent เขียนโค้ดเพิ่มขึ้นเรื่อยๆ เพราะเมื่องานส่วนใหญ่ถูกเขียนโดย agent สิ่งที่กลายเป็นคอขวดคือการรีวิวโค้ด การแตกงานเป็นชิ้นเล็กที่รีวิวได้เร็วจึงเป็นการแก้ที่คอขวดนั้นโดยตรง หากเพิ่มความเร็วในการผลิตโค้ดโดยไม่เพิ่มความเร็วในการตรวจ งานก็แค่ไปกองสุมที่คนรีวิวแทน ข้อควรระวังคือยังไม่ได้ตรวจรายละเอียดฟีเจอร์จากประกาศของ GitHub เอง อ่านจากการรายงานข่าวเท่านั้น

Blognone (ไทย)

Quanta Magazine รวบรวมงานหลายชิ้นที่ชี้ไปทางเดียวกันว่า chain-of-thought ที่โมเดลแสดงให้ดู อาจไม่ได้เชื่อมโยงเชิงสาเหตุกับคำตอบที่มันให้

ผลการทดลองที่ถูกยกมา: งานที่วัดผลกระทบเชิงสาเหตุของแต่ละขั้นพบว่า ระหว่าง 30-60% ของ "ขั้นตอนการคิด" แทบไม่มีผลต่อคำตอบสุดท้าย · งานอีกชิ้นพบว่า การใส่ token ที่ไม่มีความหมายเลย (จุดเปล่าๆ) ทำงานได้ผลพอกันกับ chain-of-thought ที่คนอ่านรู้เรื่อง · และโมเดลที่เทรนด้วยร่องรอยการให้เหตุผลที่ผิด ก็ไม่ได้ทำงานแย่ลง

คำพูดของนักวิจัยที่บทความอ้าง: Melanie Mitchell (Santa Fe Institute) ว่า chain of thought "isn't necessarily faithful to what's going on [inside]" · Subbarao Kambhampati (Arizona State) ว่า "A fake theory is worse than admitting we don't have a theory." · และ William Merrill ว่า "There's no guarantee the chain of thought has to be meaningful in any sense."

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

▲ ทำไมต้องรู้ · ข่าวนี้ควรอ่านคู่กับข่าว Chrome ด้านบน เพราะข่าวนั้นบอกว่า AI แก้บั๊กได้จริงเป็นพันตัว ส่วนข่าวนี้บอกว่าคำอธิบายที่โมเดลเขียนว่าทำไมถึงตอบแบบนั้น อาจไม่ตรงกับสิ่งที่เกิดขึ้นจริงข้างใน สรุปคือ "ได้คำตอบถูก" กับ "อธิบายได้ว่าทำไม" เป็นคนละเรื่องกันในโมเดลภาษา เวลาสั่งให้ AI อธิบายว่าคิดยังไง สิ่งที่ได้คือข้อความที่หน้าตาเหมือนการอธิบาย ไม่ใช่บันทึกของสิ่งที่มันทำจริง มีประโยชน์ช่วยตรวจคำตอบได้ แต่ไม่ควรใช้เป็นหลักฐานว่ามันเข้าใจ ข้อควรระวังคือเนื้อหานี้อ่านจากบทความรวบรวมของ Quanta ยังไม่ได้ตามไปอ่านเปเปอร์ต้นทางแต่ละชิ้นเอง และผลเหล่านี้ไม่ได้แปลว่า chain-of-thought ไม่มีประโยชน์เลย มันยังทำให้คำตอบดีขึ้นจริง แค่ไม่ได้ดีขึ้นด้วยเหตุผลที่เข้าใจได้ชัดเจน

Quanta Magazine

เปเปอร์เสนอ benchmark ที่วัด personal AI assistant ในสภาพแวดล้อมบริการที่มีสถานะต่อเนื่อง โดยเน้นสถานการณ์ที่ต้องรู้ว่าตอนนี้เรื่องดำเนินไปถึงไหนแล้ว

ผล: แม้แต่โมเดลระดับ frontier ก็ยังทำไม่ถึง 70% ในสถานการณ์ที่ต้องอาศัยความรู้เรื่องสถานะ

▲ ทำไมต้องรู้ · ตรงกับงานที่องค์กรไทยอยากเอา AI ไปใช้มากที่สุดกลุ่มหนึ่ง คือผู้ช่วยที่ดูแลเรื่องของลูกค้าต่อเนื่องหลายรอบ ความยากไม่ได้อยู่ที่การตอบคำถาม แต่อยู่ที่การรู้ว่าเรื่องนี้เคยคุยถึงไหนและตอนนี้อยู่ขั้นตอนไหน ก่อนเลือกใช้ระบบผู้ช่วยอัตโนมัติ ควรทดสอบด้วยเคสที่ต้องคุยหลายรอบ ไม่ใช่แค่คำถามเดี่ยว เรื่องนี้เชื่อมกับข่าวมาตรฐาน MCP ด้านบนด้วย เพราะโปรโตคอลกำลังย้าย state ออกจากชั้นเชื่อมต่อไปให้แอปจัดการเอง ขณะที่งานวิจัยนี้ชี้ว่าการจัดการ state คือจุดที่โมเดลยังอ่อนที่สุด ข้อควรระวังคือตัวเลขนี้เป็น paper-reported ยังไม่มี independent replication

arXiv 2607.27354

benchmark ที่วัดการให้ LLM สร้าง Triton kernel ข้ามหลายแหล่งและหลายชิป

ตัวเลขที่คมที่สุด: วิธีแบบ agent ใช้โทเคนมากกว่า 5 ล้านต่อ operator หนึ่งตัวที่ทำสำเร็จ

▲ ทำไมต้องรู้ · เป็นตัวเลขต้นทุนที่จับต้องได้ที่สุดของคำว่าให้ agent ลองไปเรื่อยๆ จนกว่าจะได้ เพราะ agent ที่ลองผิดลองถูกเองไม่ได้ฟรี ทุกครั้งที่มันลองใหม่คือเงินที่ต้องจ่าย คำถามสำคัญจึงไม่ใช่ว่า AI ทำงานนี้ได้ไหม แต่คือมันต้องลองกี่ครั้งกว่าจะสำเร็จ เรื่องนี้อ่านคู่กับข่าว Cursor ด้านบนได้ดี เพราะฝั่งหนึ่งบอกว่า agent เขียนโค้ดเกินครึ่งแล้ว ส่วนงานวิจัยนี้บอกว่าถ้างานยากพอ ต้นทุนต่อชิ้นพุ่งเป็นล้านโทเคน ทั้งสองอย่างจริงพร้อมกันได้ เส้นแบ่งอยู่ที่ความยากของงาน ข้อควรระวังคือเป็นตัวเลข paper-reported และ Triton kernel เป็นงานเฉพาะทางมาก ไม่ควรโอนตัวเลขนี้ไปใช้กับงานเขียนโค้ดทั่วไป

arXiv 2607.27231

เปเปอร์เสนอเครื่องมือสแกน transcript ของการทดสอบ agent อัตโนมัติ เพื่อหาปัญหาความถูกต้องของตัว benchmark เอง · สิ่งที่พบรวมถึง ground-truth leak คือเฉลยรั่วอยู่ในโจทย์ และความกำกวมของรูปแบบคำตอบ

▲ ทำไมต้องรู้ · แนวคิดที่ว่าคะแนน benchmark เป็นความรู้ที่มีวันหมดอายุ ตอนนี้มีอีกมิติเพิ่มเข้ามาคือบางทีข้อสอบเองก็ผิด เวลาเห็นคะแนนที่สูงผิดปกติ คำอธิบายที่เป็นไปได้จึงไม่ได้มีแค่โมเดลเก่งขึ้นหรือข้อมูลปนเปื้อน แต่อาจเป็นเพราะข้อสอบมีเฉลยรั่วติดมาด้วย ก่อนเชื่อว่าใครได้คะแนนสูงสุดในรายงานเปรียบเทียบเครื่องมือ ควรถามก่อนว่าข้อสอบนี้ใครออกและมีใครตรวจสอบข้อสอบแล้วหรือยัง ข้อควรระวังคือเป็นตัวเลข paper-reported และยังไม่ระบุว่าปัญหาที่พบกระทบ benchmark ตัวไหนที่คนใช้อ้างอิงกันมากที่สุด

arXiv 2607.27518

เปเปอร์ใช้วิธีทางจิตมิติ (psychometrics) ตรวจโครงสร้างของ Humanity's Last Exam พบว่าคะแนนย่อยรายโดเมนไม่ได้วัดสิ่งที่ต่างกันจริง benchmark วัดปัจจัยหลักเพียงตัวเดียว

▲ ทำไมต้องรู้ · กระทบวิธีที่คนทั้งวงการใช้ HLE อยู่ตอนนี้โดยตรง เพราะการเล่าว่าโมเดลนี้เก่งฟิสิกส์แต่อ่อนชีววิทยาโดยอ้างคะแนนย่อย อาจกำลังอ่านความต่างที่เป็นแค่สัญญาณรบกวน การแตกคะแนนเป็นหมวดย่อยทำให้รายงานดูละเอียดขึ้น แต่ไม่ได้แปลว่าหมวดย่อยนั้นวัดของจริงที่ต่างกัน ก่อนเชื่อรายงานที่บอกว่า AI เก่งด้านนี้แต่อ่อนด้านนั้น ควรถามว่ามีการพิสูจน์แล้วหรือยังว่าสองด้านนี้วัดคนละอย่างกันจริง เรื่องนี้อ่านคู่กับข่าวเรื่องข้อสอบรั่วด้านบนได้ดี เพราะแม้ข้อสอบจะดี การแบ่งหมวดคะแนนก็อาจไม่มีความหมายอยู่ดี ข้อควรระวังคือเป็นตัวเลข paper-reported ยังไม่มีการตอบสนองจากผู้ดูแล HLE

arXiv 2607.27420

Amazon รายงานผลประกอบการไตรมาส 2 ปี 2026: รายได้รวม $200,606 ล้าน · กำไรสุทธิ $62,647 ล้าน ซึ่งรวมกำไรจากการลงทุนใน Anthropic $53,415 ล้าน

AWS: รายได้ $42,232 ล้าน โต 37% · กำไรจากการดำเนินงาน $16,621 ล้าน · backlog เพิ่มเป็น $496,000 ล้าน

Andy Jassy ปรับงบลงทุนประจำปีจาก $200,000 ล้าน เป็น $220,000 ล้าน โดยระบุเหตุผลว่าราคาหน่วยความจำแพงขึ้น · ผู้บริหารระบุว่าเซิร์ฟเวอร์ที่มีอยู่ยังไม่พอกับความต้องการ และมองว่าถึงปี 2027 ก็อาจขยายกำลังไม่ทัน โดยความเสี่ยงยืดไปถึงปี 2028

▲ ทำไมต้องรู้ · ตัวเลขนี้ตอบคำถามที่หลายคนสงสัยว่าราคา AI จะถูกลงเรื่อยๆ ไหม คำตอบคือข้อจำกัดกำลังย้ายจากชิปมาที่หน่วยความจำ และนั่นคือเหตุผลที่ Amazon ต้องเพิ่มงบลงทุนอีกสองหมื่นล้านดอลลาร์ ราคาต่อโทเคนถูกลงเรื่อยๆ จริง แต่ต้นทุนของสิ่งที่อยู่ข้างล่างกำลังแพงขึ้น สองอย่างนี้วิ่งสวนทางกันและยังไม่มีใครรู้ว่าอันไหนจะชนะ เรื่องนี้ต่อกับข่าว DeepSeek ด้านบนได้พอดี เพราะทั้งการเก็บราคาสองเท่าในชั่วโมงเร่งด่วนและการที่เซิร์ฟเวอร์ไม่พอไปถึงปี 2028 ล้วนเป็นอาการของภาวะขาดแคลนกำลังประมวลผลเดียวกัน อีกจุดที่น่าสนใจคือกำไรจากการลงทุนใน Anthropic ของ Amazon สูงถึง 53,415 ล้านดอลลาร์ในไตรมาสเดียว สะท้อนภาพการลงทุนไขว้ในวงการ คือบริษัทที่ขายกำลังประมวลผลให้บริษัท AI ก็ถือหุ้นในบริษัท AI นั้นด้วย ข้อควรระวังคือกำไรก้อนนี้มาจากการตีมูลค่าเงินลงทุน ไม่ใช่เงินสดจากการขายของ ไม่ควรเล่าปนกับกำไรจากการดำเนินงาน และตัวเลขทั้งหมดอ่านจากการรายงานข่าว ยังไม่ได้เปิดเอกสารยื่นต่อ ก.ล.ต. สหรัฐโดยตรง

Blognone (ไทย)

วันที่ 31 ก.ค. มีสองรายการเรื่องตลาด AI ขึ้น Hacker News พร้อมกันที่ 140 คะแนนเท่ากัน: รายงานของ Wall Street Journal ว่ากองทุนชื่อ Situational Awareness ติดลบ 67% ในเดือนกรกฎาคม ท่ามกลางการเทขายหุ้นกลุ่ม AI · และบทวิเคราะห์ที่เสนอว่าการลงทุน AI รอบนี้พึ่งพาเงินกู้เป็นหลัก และผู้ให้กู้กำลังปรับราคาความเสี่ยงใหม่

🔴 ข้อจำกัดที่ต้องระบุตรงๆ: เราเข้าถึงได้เฉพาะพาดหัวและคะแนนจากฟีดของ Hacker News เท่านั้น บทความ WSJ อยู่หลัง paywall และเราไม่ได้อ่านเนื้อหา · จึงยืนยันได้แค่ว่า "มีการรายงานเช่นนี้และชุมชนสนใจมาก" ไม่ใช่ตัวเลขที่เราตรวจแล้ว

▲ ทำไมต้องรู้ · ควรเก็บไว้เป็นสัญญาณ ไม่ใช่ข้อสรุป เพราะความเชื่อมั่นของตลาดทุนกับความสามารถของเทคโนโลยีเป็นคนละเรื่องกัน และตอนนี้กำลังวิ่งคนละทาง วันเดียวกับที่ Google รายงานว่า AI ช่วยแก้บั๊กได้เป็นพันตัวและ Amazon เพิ่มงบลงทุนอีกสองหมื่นล้าน หุ้นกลุ่มเดียวกันก็ถูกเทขาย ถ้าตลาดหุ้น AI ปรับฐาน ยังสรุปไม่ได้ว่าเทคโนโลยีไม่เวิร์ก และถ้าตลาดขึ้น ก็ยังสรุปไม่ได้ว่ามันเวิร์ก สองอย่างนี้ตอบคนละคำถามกัน สิ่งที่ควรจับตาต่อคือเรื่องเงินกู้มากกว่าราคาหุ้น เพราะถ้าการขยายดาต้าเซ็นเตอร์พึ่งเงินกู้จริง ต้นทุนการกู้ที่สูงขึ้นจะไปโผล่ที่ราคาบริการในที่สุด

HN q=AI feed

ซีอีโอ Reddit ระบุว่า AI Overviews ของ Google ทำให้ทราฟฟิกที่ถูกส่งต่อมายังแพลตฟอร์มลดลงชัดเจน และกระทบระบบนิเวศของเว็บที่เคยทำงานด้วยการส่งลิงก์ต่อกัน จนต้องปรับกลยุทธ์

▲ ทำไมต้องรู้ · ข้อนี้เพิ่มมุมที่ยังไม่ค่อยมีคนพูดถึง คือเสียงจากฝั่งที่เสียทราฟฟิกจากการค้นหาที่เปลี่ยนไป ไม่ใช่ฝั่งที่ทำเครื่องมือ AI เอง องค์กรที่วางแผนการตลาดโดยอาศัยการติดอันดับค้นหาแล้วรอคนคลิกเข้ามา กำลังยืนอยู่บนสมมติฐานที่เปลี่ยนไปแล้ว เมื่อเครื่องมือค้นหาตอบคำถามให้เสร็จในหน้าเดียว สิ่งที่ต้องวัดใหม่จึงไม่ใช่อันดับ แต่คือถูกอ้างถึงในคำตอบหรือเปล่า ข้อควรระวังคือนี่เป็นคำพูดของผู้บริหารบริษัทที่เสียประโยชน์ ไม่ใช่ข้อมูลวัดอิสระ และไม่มีตัวเลขระบุว่าทราฟฟิกลดลงเท่าไร

Blognone (ไทย)

LinkedIn เพิ่มปุ่มให้ผู้ใช้รายงานโพสต์ที่ "ใช้ AI เขียนเนื้อหาและยังไม่มีคุณภาพ" · ผู้บริหารฝ่ายผลิตภัณฑ์อธิบายว่าบริษัทแยกแนวคิดระหว่าง "ใช้ AI ช่วยเขียน" กับ "เนื้อหา AI ที่ไม่มีคุณภาพ" อย่างชัดเจน โดยไม่ได้ตรวจจับว่าเป็น AI หรือไม่แบบเหมารวม

ตัวเลข 1 ใน 4 มาจากผลการศึกษาที่มีการรายงานก่อนหน้านี้

▲ ทำไมต้องรู้ · หลายคนที่ใช้ AI ช่วยเขียนโพสต์สงสัยว่าคนอื่นจะรู้ไหมและจะโดนมองไม่ดีหรือเปล่า คำตอบจากกรณีนี้คือแพลตฟอร์มที่ใหญ่ที่สุดในโลกวิชาชีพเลือกไม่แบน AI แต่แบนเนื้อหาที่ไม่มีคุณภาพ และให้คนเป็นคนตัดสินแทนเครื่องตรวจจับ ซึ่งเป็นการยอมรับโดยปริยายว่าการตรวจว่าข้อความมาจาก AI หรือไม่ ยังทำได้ไม่ดีพอจะใช้เป็นนโยบาย คำถามที่สำคัญกว่าจึงไม่ใช่ว่าใช้ AI แล้วจะโดนจับไหม แต่คือสิ่งที่โพสต์มีอะไรที่คนอ่านได้ประโยชน์จริงไหม อีกจุดที่น่าสนใจคือเมื่อ 1 ใน 4 ของฟีดมาจาก AI ต้นทุนการผลิตคอนเทนต์ก็ตกลง ความได้เปรียบจึงย้ายไปอยู่ที่ประสบการณ์จริง ข้อมูลเฉพาะที่คนอื่นไม่มี และความน่าเชื่อถือของคนโพสต์แทน ข้อควรระวังคือตัวเลข 1 ใน 4 เป็นการอ้างผลการศึกษาผ่านการรายงานข่าว ยังไม่ได้ตามไปอ่านงานต้นทางโดยตรง จึงไม่ควรยกเป็นตัวเลขทางการของ LinkedIn

Blognone (ไทย)