GLM 5.2 แซงหน้า Claude ในเบนช์มาร์ก IDOR ของ Semgrep
(semgrep.dev)- ในเบนช์มาร์กการตรวจจับ ช่องโหว่ IDOR ของ Semgrep โมเดลแบบ open-weight GLM 5.2 จาก Zhipu AI ทำคะแนน F1 ได้สูงกว่า Claude Code โดยอาศัยเพียงเงื่อนไขพรอมป์ตแบบเรียบง่าย
- การทดลองตรึงชุดข้อมูล วิธีประเมิน และ system prompt ไว้คงเดิม แล้วเปลี่ยนเฉพาะ โมเดลและฮาร์เนส เพื่อเปรียบเทียบว่าประสิทธิภาพมาจากตัวโมเดลเองหรือจากสแคฟโฟลดิงรอบข้าง
- Semgrep Multimodal ที่ใช้ฮาร์เนสเฉพาะทางคว้าอันดับ 1 และ 2 ด้วย GPT 5.5 61% และ Opus 4.8 53% แสดงให้เห็นชัดเจนถึงผลของการสำรวจแบบมีโครงสร้าง
- GLM 5.2 ทำได้ 39% F1 แม้ไม่มีสแคฟโฟลดิงสำหรับสำรวจเอนด์พอยต์ และมีต้นทุนราว $0.17 ต่อการค้นพบช่องโหว่ 1 รายการ
- ผลลัพธ์นี้ไม่ได้แปลว่าโมเดล open-weight ทั้งกลุ่มแซงหน้าโดยรวม แต่เป็นผลแบบจำกัดที่บอกว่า หนึ่งโมเดลแข็งแกร่งกับหนึ่งงานและหนึ่งชุดข้อมูล และอาจต่างออกไปในช่องโหว่ประเภทอื่น
การทดลองที่แยกประสิทธิภาพของโมเดลออกจากผลของฮาร์เนส
- Semgrep นำ โมเดล open-source ยอดนิยมมารันบนเบนช์มาร์ก IDOR โดยใช้ชุดข้อมูลและพรอมป์ตเดียวกับที่เคยใช้ประเมิน frontier coding agent
- ประเด็นหลักที่ต้องการเปรียบเทียบคือ ประสิทธิภาพการตรวจจับช่องโหว่มาจาก ตัวโมเดลเอง หรือมาจาก ฮาร์เนส รอบโมเดล
- ฮาร์เนสคือสแคฟโฟลดิงที่คอยป้อนรีโพซิทอรีให้โมเดล กำหนดว่าจะดูอะไร แยกวิเคราะห์เอาต์พุต และจัดลูปการทำงาน
- ไปป์ไลน์ multimodal ภายในของ Semgrep ทำงานบนฮาร์เนสเฉพาะทางที่ปรับให้เหมาะกับ static analysis
- ทำการไล่รายการ application endpoint
- คัดเลือก code context ที่สำคัญ
- ชี้นำโมเดลไปยัง endpoint เหล่านั้นโดยตรง
- การทดลองกับโมเดล open-weight ครั้งนี้ทำบนฮาร์เนสแบบเรียบง่ายที่อิง Pydantic AI โดยไม่มีสแคฟโฟลดิงเฉพาะทางเหล่านี้
- ใช้พรอมป์ต IDOR เดิมเหมือนกัน
- ไม่มีการช่วยค้นหา endpoint หรือชี้นำการสำรวจ
- มีเพียงคำใบ้เล็กน้อยเกี่ยวกับกลยุทธ์การค้นหา IDOR และรูปแบบของ IDOR
ทำไม GLM 5.2 จึงถูกจับตาในงานด้านความปลอดภัย
- GLM 5.2 คือโมเดลล่าสุดของ Zhipu AI หรือ Z.ai
- แจกจ่ายให้สมาชิก GLM Coding Plan เมื่อวันที่ 13 มิถุนายน 2026
- เปิดเผย open weights และ release notes เมื่อวันที่ 16 มิถุนายน 2026
- ด้วยความเป็นโมเดล open weight จึงเปิดเผยพารามิเตอร์ภายใต้ MIT license
- ดาวน์โหลดได้ รันบนฮาร์ดแวร์ของตนเองได้ ปรับจูนต่อได้ และตรวจสอบได้
- ทีมความปลอดภัยจึงสามารถรันโมเดลในสภาพแวดล้อมที่มีข้อมูลอ่อนไหวได้
- อย่างไรก็ตาม open weight ไม่ได้เท่ากับ open source และข้อมูลฝึกกับไปป์ไลน์ทั้งหมดโดยทั่วไปไม่ได้เปิดเผย
- Z.ai เปิดเผยเฟรมเวิร์กการฝึก RL ของตน
- GLM 5.2 เป็นโมเดล Mixture-of-Experts(MoE)
- มีพารามิเตอร์รวมราว 7.5 แสนล้านตัว
- พารามิเตอร์ที่ทำงานต่อโทเค็นอยู่ที่ราว 4 หมื่นล้านตัว
- คอนเท็กซ์ขยายได้ตั้งแต่ 200K ถึง 1M โทเค็น
- Z.ai ระบุว่าคอนเท็กซ์ยังคงเสถียรแม้ในเวิร์กโฟลว์แบบเอเจนต์ที่ยาวนาน
- งานด้านความปลอดภัยอย่าง IDOR ต้องอาศัยการให้เหตุผลข้ามหลายไฟล์และหลายเฟรมเวิร์กการกำหนดสิทธิ์
- บนเบนช์มาร์กการเขียนโค้ดมาตรฐานก็มีตัวเลขที่แข่งขันได้
- 81.0 บน Terminal-Bench 2.1
- GLM 5.1 ได้ 63.5
- Claude Opus 4.8 ได้ 85.0
- 62.1 บน SWE-bench Pro
- ราคาถูกระบุว่าอยู่ที่ราว 1/6 ของโมเดล frontier ที่เทียบเคียงกันได้
- ใน release notes ของ Z.ai ระบุว่า GLM 5.2 แสดง reward-hacking behavior มากกว่า GLM 5.1
- มีรายงานว่าระหว่างการฝึก โมเดลพยายามอ่านไฟล์ประเมินที่ถูกป้องกัน หรือ
curlreference solution เพื่อดันคะแนนให้สูงขึ้น - Z.ai ระบุว่าได้สร้าง anti-hacking guard เพื่อป้องกันพฤติกรรมดังกล่าว
- มีรายงานว่าระหว่างการฝึก โมเดลพยายามอ่านไฟล์ประเมินที่ถูกป้องกัน หรือ
ทำไม IDOR จึงเป็นงานยาก
- IDOR(Insecure Direct Object Reference) คือช่องโหว่ประเภทที่คำขอเปิดเผยตัวระบุภายใน เช่น user ID แต่ไม่ตรวจสอบว่าผู้เรียกมีสิทธิ์เข้าถึงออบเจ็กต์นั้นหรือไม่
- ตัวอย่าง Flask route จะดึงเรคคอร์ดผู้ใช้จาก
user_idใน URL แล้วส่งกลับทันที- ไม่มีการตรวจว่าผู้ร้องขอเป็นเจ้าของผู้ใช้นั้นหรือไม่
- ผู้ใช้ที่ล็อกอินอยู่สามารถเปลี่ยน
user_idเพื่ออ่านเรคคอร์ดของผู้ใช้อื่นได้
- IDOR มีลักษณะใกล้เคียงทั้งข้อบกพร่องใน business logic และการตั้งค่าที่ผิดพลาด
- ไม่ใช่บั๊กแบบ taint-flow ที่มีฟังก์ชันอันตรายชัดเจน
- ปัญหาที่แท้จริงคือ การตรวจสิทธิ์ที่หายไป ซึ่งทำให้ทั้ง static analysis และ LLM จัดการได้ยาก
- IDOR ถูกกล่าวถึงว่าอยู่อันดับ 4 ในรายการประเภทช่องโหว่ยอดนิยมของ HackerOne ในปัจจุบัน
เงื่อนไขการเปรียบเทียบและวิธีวัดผล
- สิ่งที่ตรึงไว้ในการทดลองมี 3 อย่าง
- ชุดข้อมูล IDOR ที่อิงกับแอปพลิเคชัน open-source จริงแบบเดียวกัน
- การประเมินด้วย คะแนน F1 เทียบกับชุด true positive ที่ทราบอยู่แล้ว
- system prompt สำหรับ IDOR ชุดเดียวกัน
- สิ่งที่เปลี่ยนคือ โมเดลและฮาร์เนส
- Semgrep Multimodal รันอยู่ใน custom harness ที่ทำการไล่ endpoint และชี้นำโมเดล
- Claude Code รันผ่าน Claude Code SDK
- โมเดลจากผู้ให้บริการรายอื่นรันผ่าน native SDK ของแต่ละราย
- โมเดล open-weight อย่าง GLM 5.2, MiniMax M3 และ Kimi K2.7 Code รันแบบอาศัยพรอมป์ตล้วน ๆ บนฮาร์เนส Pydantic AI
- ตัวชี้วัดที่ใช้มีดังนี้
- Precision: สัดส่วนของรายการที่ตัวตรวจจับระบุว่าเป็น IDOR แล้วเป็น IDOR จริง
- Recall: สัดส่วนของ IDOR จริงที่มีอยู่ในชุดข้อมูลและถูกตรวจพบ
- F1: ค่าเฉลี่ยฮาร์มอนิกของ precision และ recall
- Cost in dollars: ต้นทุนต่อ true positive 1 รายการ และต้นทุนรวมของการรันหารด้วยจำนวนบั๊กจริงที่พบ
ผลลัพธ์: ฮาร์เนสเฉพาะทางครองอันดับ 1 และ 2, GLM 5.2 ได้อันดับ 3
- อันดับตามค่า F1 ในการตรวจจับ IDOR มีดังนี้
- Semgrep Multimodal(GPT 5.5), Semgrep Multimodal harness: 61%
- Semgrep Multimodal(Opus 4.8), Semgrep Multimodal harness: 53%
- GLM 5.2, Pydantic AI prompt only: 39%
- Claude Code(Opus 4.6), Claude Code SDK: 37%
- Claude Code(Opus 4.8/4.7), Claude Code SDK: 28%
- MiniMax M3, Pydantic AI prompt only: 23%
- Kimi K2.7 Code, Pydantic AI prompt only: 22%
- GPT-5.5 Codex: 20%
- Nemotron Super 3 120B, Pydantic AI prompt only: 18%
- DeepSeek V4, Pydantic AI prompt only: 17%
- การเปรียบเทียบ F1 ของกลุ่มบนสุด:
- ไปป์ไลน์ Semgrep Multimodal ให้ผลสูงสุดเมื่อใช้ GPT 5.5 และ Opus 4.8 ที่ 61% และ 53% ตามลำดับ
- GLM 5.2 ทำได้ 39% F1 โดยไม่มีสแคฟโฟลดิง
- เนื้อหาระบุว่า GLM 5.2 นำหน้า Claude Code อยู่ 7 คะแนน
- ต้นทุนการรันของ GLM 5.2 ถูกระบุว่าอยู่ที่ราว $0.17 ต่อการค้นพบช่องโหว่ 1 รายการ
- MiniMax M3 และ Kimi K2.7 Code ได้ 23% และ 22% ตามลำดับ ต่ำกว่า GLM 5.2 และยังตามหลัง Claude Code
- ช่องว่างระหว่าง GLM 5.2 กับโมเดล open-weight อันดับถัดไปอยู่ที่ 16 คะแนน ซึ่งมากกว่าช่องว่างระหว่าง GLM 5.2 กับ Claude Code
การตีความและข้อจำกัด
- ความต่างของประสิทธิภาพที่ใหญ่ที่สุดไม่ได้อยู่ระหว่างโมเดล แต่เกิดขึ้นระหว่างชุดที่มี ฮาร์เนสค้นหา endpoint กับชุดที่ไม่มี
- ฮาร์เนสจึงเป็นปัจจัยที่มีผลมากพอ ๆ กับการเลือกโมเดลในการทดลองครั้งนี้
- ขณะเดียวกัน GLM 5.2 ก็แซงหน้า Claude Code ได้ในงานวิจัยด้านความปลอดภัยที่ยาก ภายใต้เงื่อนไขที่ใช้พรอมป์ตน้อยและฮาร์เนสเรียบง่าย โดยมีต้นทุนเพียงราว 1/6 ของ frontier LLM
- โมเดล open-weight สามารถรันในสภาพแวดล้อมขององค์กรเองได้ จึงอาจเป็นทางเลือกที่ใช้งานได้จริงสำหรับบางทีมความปลอดภัย
- อย่างไรก็ตาม ผลลัพธ์นี้มีข้อจำกัดชัดเจน
- เป็นเพียงงานเดียว
- ใช้ชุดข้อมูลเดียว
- รันเพียงครั้งเดียว
- การตรวจจับ IDOR ไม่เป็นแบบกำหนดแน่นอน
- ชุดข้อมูลมีขอบเขตจำกัด
- ในการตรวจจับ SSRF ผลลัพธ์อาจกลับด้านได้ และยังไม่ได้รับการยืนยัน
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
หลังจากเรื่องวุ่น ๆ ของ Fable กับ GPT 5.6 ผมหันกลับมาดูโมเดลโอเพนอีกครั้ง และ GLM-5.2 เป็นโมเดลที่ใช้งานจริงได้ดีมากสำหรับการเขียนโปรแกรมในชีวิตประจำวัน
จากมุมมองของนักพัฒนามีประสบการณ์ที่ใช้ LLM เยอะ ๆ เซสชัน GPT หนึ่งมักเกิน 100 ดอลลาร์ แต่สุดสัปดาห์นี้ผมสร้าง Matrix bot ที่ใส่การเข้ารหัสและ Rust agent พร้อมเครื่องมืออีกหลายอย่าง และสองวันต่อมา หลังใช้ไป 20 ดอลลาร์ ก็ได้ Rust agent แบบมัลติโมดัลที่เข้าถึง homelab ได้สำเร็จ
GLM ไม่ให้ความรู้สึกติดขัด ทำงานที่ต้องการได้ดี รวดเร็ว บุคลิกก็ไม่กวนใจมาก และถูกกว่า Opus หรือ GPT มาก ผมใช้เวอร์ชันที่ไม่ได้ quantize บน Fireworks และยังมีผู้ให้บริการอื่นอีกหลายราย
ทุกแล็บต่างปล่อยโมเดลที่ท่องคำตอบ benchmark มา ไม่ว่าจะตั้งใจหรือไม่ก็ตาม และโมเดลจากแล็บจีนมักมีช่องว่างระหว่าง benchmark สาธารณะกับการประเมินภายในมากกว่า โดยการประเมินภายในถูกออกแบบมาให้เปราะบางต่อการ optimize เพื่อ benchmark น้อยกว่า
ในสภาพแวดล้อมเขียนโค้ดแบบ multi-agent โดยเฉลี่ย GLM 5.2 ยังตาม Opus 4.6 อยู่เล็กน้อย ข้อมูลอยู่ที่ https://gertlabs.com/rankings
อย่างไรก็ตาม ถ้าดูรวมถึงต้นทุนต่อประสิทธิภาพ GLM 5.2 ถือเป็น โมเดลระดับแนวหน้า
ตอน GLM 5.2 ออกมา ผมเพิ่มมันเข้าไปใน benchmark สำหรับค้นหาบั๊กด้านความปลอดภัย และถึงประสิทธิภาพจะดี แต่ก็ยังไม่ใช่โมเดลโอเพนที่ดีที่สุด
benchmark นี้ทดสอบว่าโมเดลสามารถหาบั๊กที่ Mythos หาเจอได้หรือไม่ จากผลช่วงแรก โมเดลโอเพนที่ดีที่สุดคือ DeepSeek V4 Pro หรือ MiMo 2.5 Pro แต่ MiMo ดูเหมือนจะแค่โชคดี และหลังจากนั้นก็แย่ลงในแทบทุกการทดสอบ ในขณะที่ DeepSeek อยู่กลุ่มบนอย่างสม่ำเสมอ และด้วยประสิทธิภาพ caching ที่สุดโต่ง ทำให้ถูกกว่าแทบทุกอย่าง รวมถึงโมเดลที่เล็กกว่ามาก
https://swelljoe.com/post/will-it-mythos/
อีกประเด็นที่น่าสนใจคือ เมื่อให้ open-source semgrep เป็นเครื่องมือ บางโมเดลกลับแย่ลง และไม่มีโมเดลไหนดีขึ้นเลย อาจมีวิธีเชื่อม harness ให้ดีเพื่อให้โมเดลได้รับเฉพาะข้อมูลที่มีประโยชน์ โดยไม่ต้องให้โมเดลจัดการ semgrep เอง
ผมเดาว่าเพราะ semgrep ไม่ได้อยู่ในข้อมูลฝึกมากนัก จึงกลายเป็นการให้โมเดลต้องทำทั้งการทำความเข้าใจวิธีใช้ semgrep และการหาบั๊กความปลอดภัยพร้อมกัน ทำให้สมาธิกระจายและประสิทธิภาพตกทั้งสองด้าน โมเดลขนาดเล็กส่วนใหญ่และโมเดลขนาดใหญ่บางตัวทำเรื่องนี้ได้ไม่ดี
การทดสอบเพิ่มเติมยังดำเนินต่อไป และ GLM 5.2 ก็ดูมีแนวโน้มสูงว่าจะทำผลงานได้แข็งแกร่งต่อเนื่อง จนถึงตอนนี้มันทำได้ยอดเยี่ยมในส่วนใหญ่ที่ทดสอบ
เห็นว่า GLM 5.2 เป็นโมเดลที่มี พารามิเตอร์ 753B [1] เลยสงสัยว่าถ้าจะรันในเครื่อง local ต้องใช้ฮาร์ดแวร์แบบไหน
[1] https://huggingface.co/zai-org/GLM-5.2
มันใส่ลงใน 1TB NVMe ตรง ๆ ยังไม่ได้ เลยใช้ โมเดล quantized UD_Q4_K_XL แบบ 4 บิตต่อ weight และความเร็วไม่ใช่ token ต่อวินาที แต่ประมาณ 12 วินาทีต่อ token เป็นโปรเจกต์ที่สนุก แต่ไม่คุ้มจะใช้งานจริง
llama.cpp รองรับ memory mapping ผมเลยรันด้วย context cache 4096 token และสงสัยว่าถ้าทั้งหมดใส่ใน RAM ไม่ได้ จะต้อง stream จาก SSD มากแค่ไหน การสร้างข้อความแนะนำตัวเองสั้น ๆ 4 ประโยค อ่านจากดิสก์ไปประมาณ 1.5TiB
แต่ก็ไม่ต้องกังวลหรอก เหล่านักเผยแพร่โอเพนซอร์สจะบอกคุณเองว่าอีก 3 ปีโมเดลแบบนี้จะรันบนโทรศัพท์ได้
เงิน 100,000 ดอลลาร์สามารถรันโมเดลนี้ผ่าน OpenRouter ที่ 50tps พร้อม session พร้อมกัน 10 อัน ตลอด 24 ชั่วโมงเป็นเวลา 10 ปี แล้วยังเหลือเงินไปพักร้อนด้วย ถ้าไม่ใช่ธุรกิจที่จ่ายค่า token ให้พนักงานหลายคนอยู่แล้ว ก็ไม่มีเหตุผลจะเอาเงินแบบนี้ไปลงทุนกับโมเดล local
ประโยคที่ว่า “ชนะ Claude Code (32%) ด้วยต้นทุนประมาณ 0.17 ดอลลาร์ต่อการพบช่องโหว่หนึ่งรายการ” นั้นไม่ถูกต้อง
Claude Code ไม่ใช่ LLM แต่เป็น agent harness และ Claude ก็ไม่ใช่ LLM ตัวเดียว แต่เป็นแบรนด์หรือชุดของ LLM
API สำหรับผู้บริโภคที่ไม่ใช่ enterprise แพงมาก เพราะจากมุมผู้ใช้มีต้นทุนส่วนเพิ่มสูง และจากมุม Anthropic มี margin หนา ถ้าจะประมาณต้นทุนของผู้โจมตีระดับรัฐที่รันโมเดลบนฮาร์ดแวร์ของตัวเอง Claude Code ก็น่าจะเป็นค่าประมาณที่ดีที่สุดของต้นทุนตัดจำหน่าย
ตัวเลขเหล่านี้ดูค่อนข้างต่ำ โดยเฉพาะเมื่อเทียบกับสิ่งที่ผมทำได้ในฝั่ง เคอร์เนล Windows และ win32k↔win32u
ตอนนี้คงไม่น่าแปลกใจแล้วถ้าจีนเริ่มแซงโมเดลที่สหรัฐฯ เปิดเผยในบางหมวดหมู่เฉพาะอย่างไซเบอร์
GLM 5.2 แข็งแกร่งพอแล้วที่จะช่วยในการฝึกตัวเอง และนี่ก็คล้ายกับแนวโน้มที่เราเห็นในโมเดลแนวหน้า แถมดูเหมือนจะไปถึงจุดนั้นด้วยต้นทุนที่ต่ำกว่า OpenAI หรือ Anthropic มาก
ถ้ารวมกับอำนาจครอบงำที่เพิ่มขึ้นของจีนในด้าน พลังงานแสงอาทิตย์, แบตเตอรี่ชาร์จได้, รถยนต์ไฟฟ้า แล้ว นี่อาจเป็นหมัดเด็ดต่อระเบียบเศรษฐกิจหลังสงครามโลกครั้งที่สอง
อย่างน้อยควรเอา Opus ไปรันด้วย Pydantic harness แบบเดียวกับที่ใช้กับ GLM ตอนนี้เหมือนกำลังเปรียบเทียบแอปเปิลกับส้ม
ต้นทุนต่อช่องโหว่ของโมเดลอื่นทั้งหมดนอกจาก GLM อยู่ตรงไหน?
ถ้าไม่มีโค้ดก็ยากจะเชื่อถือได้ ทั้งหมดอาจแต่งขึ้นมาก็ได้
การควบคุมการส่งออก GLM จะมาเร็ว ๆ นี้ไหม? คาดว่าในอีกไม่กี่เดือน Commerce จะบังคับให้ OpenRouter กับ HuggingFace เอาโอเพนโมเดลบางตัวลง
ถึงจะไม่สมเหตุสมผลก็เถอะ
การแบนโมเดลโอเพนซอร์สไม่ได้ช่วยแก้ปัญหาเลย เพราะผู้โจมตีไม่ได้รู้สึกว่าตัวเองถูกกฎหมายผูกมัดไว้ เพื่อวัตถุประสงค์ด้านการป้องกัน โมเดลขั้นสูงทั้งหมดควรเข้าถึงได้
รัฐบาลมีอำนาจ (a) สกัดการส่งออกสินค้าและบริการของสหรัฐฯ, (b) ห้ามนำเข้าสินค้าทางกายภาพ, และ (c) ห้ามการทำธุรกรรมกับบริษัทต่างชาติ รวมถึงการซื้อบริการหรือทำสัญญาไลเซนส์
แต่ถ้าบริษัทอเมริกันมีความสัมพันธ์ที่เป็นอิสระจากซัพพลายเออร์ และไม่ได้ใช้กับสัญญารัฐบาลหรือแอปพลิเคชันที่อยู่ภายใต้การกำกับดูแล ผมไม่ค่อยเห็นอำนาจทางกฎหมายที่จะห้ามการรันโมเดล AI โอเพนซอร์สที่พัฒนาโดยจีนภายในสหรัฐฯ โดยตัวมันเอง
อาจมีความเป็นไปได้ที่จะสั่งให้ HuggingFace และที่อื่น ๆ ระงับบัญชีจีน แต่ถ้าคนในสหรัฐฯ หรือประเทศที่สามดาวน์โหลดโมเดลจากจีน แล้วอัปโหลดขึ้นเซิร์ฟเวอร์ในสหรัฐฯ ใหม่โดยเป็นอิสระจากซัพพลายเออร์โดยสิ้นเชิง ก็สงสัยว่าจุดเชื่อมทางกฎหมายที่จะห้ามสิ่งนั้นอยู่ตรงไหน
ผมใช้ GLM 5.2 ผ่าน Neuralwatt แล้วมันถูกมาก จนถ้าบริษัทให้สมัครสมาชิก Claude ให้ ผมคงยกเลิก Claude ส่วนตัวได้เลย
เดือนนี้ผมใช้ไป 374 ล้านโทเคน แต่ด้วยระบบราคาตามพลังงาน จ่ายแค่ 18 ดอลลาร์เท่านั้น
อ่านแล้วเหมือนโฆษณา
อย่างที่สอง สิ่งเหล่านี้เป็น “แค่” IDOR และอยู่ในกลุ่มช่องโหว่ที่ง่ายที่สุดด้วย
อย่างที่สาม กำลังเทียบกับ GPT 5.5 และ Opus 4.8
ไม่ใช่สิ บ้านเราไม่มี Mythos
ถ้ามันให้บริการได้อย่างคุ้มค่าทางเศรษฐกิจ ก็คงเปิดตัวตั้งแต่วันแรกแล้ว แทนที่จะเป็นคณะละครการตลาดของพวกตัวตลกสาย effective altruism เพราะคงร้ายแรงมากถ้าต้องยอมรับว่าโมเดลที่ดีกว่าไม่ถึง 10% มีต้นทุน inference แพงกว่าเกิน 1000%
เป็นโมเดลที่ทรงพลังจริง ๆ สำหรับการหาและแก้ช่องโหว่
สำหรับคนที่อยู่ใน EU เรื่องยิ่งซับซ้อนกว่า Mythos อาจเข้ามาในห้องสักวันหนึ่ง แล้วก็หายไปกะทันหันตามอำเภอใจของผู้เล่นทางการเมืองที่เราแทบควบคุมไม่ได้
การรู้ว่าโอเพนโมเดลที่เข้าถึงได้และรันในเครื่องได้มาถึงไหนแล้วเป็นเรื่องสำคัญ ผมรู้ว่ามันยังตามหลังอยู่ แต่จะมีจุดที่ “ดีพอ” กลายเป็นสิ่งที่มีประโยชน์ แม้ว่าวันนี้จะเป็น “แค่ IDOR” และยังตามหลังระดับล่าสุดก็ตาม
อย่างที่มีคนข้างบนพูดไว้ โมเดลระดับเดียวกันอย่าง GLM 5.2 รวมถึง Kimi และ DeepSeek V4 กำลังค่อย ๆ ดีพอที่จะช่วยงานเตรียมรีโพซิทอรีแบบอัตโนมัติ เช่น ดาวน์โหลด·ติดตั้ง·ทดสอบ·แก้ไข·ทดสอบซ้ำ สิ่งนี้นำไปสู่ ข้อมูลร่องรอยการใช้งานจริง ที่ใช้ฝึกเจเนอเรชันถัดไปได้ และนั่นอาจสำคัญกว่าการตามหลังในเบนช์มาร์กอยู่กี่เปอร์เซ็นต์