SubQ: ถ้า 12M-token Context ใช้ได้จริง เกม RAG, Coding Agent และต้นทุน AI จะเปลี่ยนหนักมาก

ถ้า SubQ ทำได้จริง โลก AI จะเสียค่าซ่อม workaround น้อยลงเยอะมากครับ

นี่เป็นข่าวที่ต้องอ่านด้วยความตื่นเต้นปนระแวงนิด ๆ

เพราะ Subquadratic เปิดตัว SubQ 1M-Preview พร้อม claim ที่ใหญ่มาก: เป็น LLM ตัวแรกที่สร้างบน architecture แบบ fully subquadratic และทำให้ compute โตใกล้ linear ตาม context length

แปลแบบบ้าน ๆ คือ transformer ปกติ เวลาบริบทใหญ่ขึ้น งาน attention จะหนักขึ้นแบบกำลังสอง

ใส่ context ยาวขึ้น 2 เท่า งานไม่ได้หนักขึ้น 2 เท่า แต่อาจหนักขึ้นประมาณ 4 เท่า

นี่คือเหตุผลว่าทำไมระบบ AI จำนวนมากต้องพึ่ง RAG, chunking, summarization, vector database, prompt engineering, routing และ multi-agent orchestration สารพัด

ไม่ใช่เพราะนักพัฒนาอยากทำระบบให้ยุ่ง

แต่เพราะการยัดข้อมูลทั้งหมดเข้า context แล้วให้ model คิดทีเดียวมันแพง ช้า และมักไม่เสถียร

SubQ บอกว่าปัญหานี้แก้ได้ด้วย SSA หรือ Subquadratic Sparse Attention

แทนที่จะเปรียบเทียบทุก token กับทุก token มันเลือกดูเฉพาะความสัมพันธ์ที่น่าจะสำคัญจริง ๆ แบบ content-dependent

ถ้าทำได้ตาม claim นี่ไม่ใช่แค่ model ใหม่

มันคือการโจมตี cost curve ที่บังคับรูปทรงของ AI product มาหลายปี

1. ปัญหาจริงไม่ใช่ context window เล็ก แต่คือ functional context ใช้ไม่ค่อยได้

ทุกวันนี้เราเห็น model หลายตัวพูดเรื่อง 1M tokens, 2M tokens หรือ context window ใหญ่มาก

แต่คำถามสำคัญกว่า “รับได้กี่ token” คือ:

ใช้ข้อมูลใน token เหล่านั้นได้ดีแค่ไหน?

SubQ แยกเรื่องนี้ชัดมากใน technical post ของเขา

• Nominal context คือจำนวน token ที่ model รับเข้าไปได้
• Functional context คือจำนวน token ที่ model ใช้ reasoning ได้จริงแบบเชื่อถือได้

สองอย่างนี้ไม่เหมือนกันครับ

เหมือนมีห้องประชุมใหญ่ใส่คนได้ 1,000 คน แต่ประธานฟังจริงแค่ 10 คนหน้าเวที

ตัวเลข capacity ดูดี แต่ decision quality ไม่ได้ดีตาม

ในงาน enterprise ปัญหาส่วนใหญ่ไม่ได้เป็นคำถามสั้น ๆ จาก paragraph เดียว

มันเป็นโจทย์แบบนี้มากกว่า:

• codebase ที่ function หนึ่งถูกเรียกจากสิบไฟล์ และถูก constrain ด้วย test อีกที่หนึ่ง
• contract ที่คำตอบขึ้นกับ definition, exception และ clause อื่นที่อยู่คนละหน้า
• support ticket หลายเดือนที่ต้องหา pattern ข้ามลูกค้า ข้ามทีม ข้ามเวลา
• customer history ที่ต้องรวม CRM notes, meeting notes, email, transaction และ complaint เข้าด้วยกัน
• agent session ยาว ๆ ที่ decision เมื่อสัปดาห์ก่อนยังมีผลกับ action วันนี้

นี่ไม่ใช่ lookup problem

มันคือ multi-hop reasoning over distributed evidence

ถ้า model เห็นข้อมูลไม่ครบ หรือเห็นครบแต่ใช้ไม่เป็น เราก็ต้องสร้าง scaffold รอบ ๆ มันเยอะมาก

SubQ จึงน่าสนใจ เพราะมันไม่ได้ขายแค่ prompt ยาว

มันขายแนวคิดว่า long context ต้องถูกลงและต้องใช้ได้จริง

2. ทำไม Transformer ถึงทำให้ RAG และ Vector Database กลายเป็นอุตสาหกรรมใหญ่

Attention คือกลไกสำคัญของ transformer

พูดง่าย ๆ แต่ละ token จะถามว่า “token ไหนใน context สำคัญกับฉันบ้าง?”

ใน dense attention แบบดั้งเดิม ทุก token เทียบกับทุก token

ถ้า context มี token เยอะขึ้น จำนวนความสัมพันธ์ที่ต้องคำนวณจะโตแบบกำลังสอง

นี่คือ quadratic scaling problem

ผลของมันไม่ได้อยู่แค่ใน paper

มันไปกำหนด product architecture จริง ๆ

เพราะถ้าส่งข้อมูลทั้งบริษัทเข้า model ไม่ไหว เราก็ต้องสร้างระบบคัดเลือกก่อนส่ง เช่น:

• RAG เพื่อดึงเฉพาะ chunk ที่น่าจะเกี่ยว
• vector database เพื่อหา semantic similarity
• chunking strategy เพื่อแบ่งเอกสาร
• reranker เพื่อจัดอันดับใหม่
• prompt compression เพื่อย่อบริบท
• agent orchestration เพื่อแบ่งงานเป็น call ย่อย ๆ
• memory summary เพื่อไม่ให้ประวัติยาวเกิน context

ทั้งหมดนี้มีประโยชน์นะครับ

แต่ต้องยอมรับว่าหลายอย่างคือ workaround ของข้อจำกัดเดิม

และ workaround มีต้นทุน

RAG อาจดึงข้อมูลถูก chunk แต่ตัด context รอบข้างทิ้ง

Summary อาจเก็บใจความ แต่เสีย constraint สำคัญ

Agent decomposition อาจช่วยแบ่งงาน แต่ error สามารถสะสมข้าม step

Vector search อาจเจอข้อความที่คล้าย แต่ไม่รู้ hierarchy, permission, version หรือ causal relationship

คำถามของ SubQ คือ:

ถ้า model เห็นบริบทขนาดใหญ่มากได้ใน cost ที่ถูกลง เราจะยังต้องสร้าง workaround หนาขนาดเดิมไหม?

คำตอบของผมคือ RAG ไม่หายครับ

แต่บทบาทจะเปลี่ยน

จาก ทางรอดเพราะ context แพง

เป็น control layer สำหรับ freshness, permission, audit และ data governance

นี่ต่างกันเยอะมาก

3. SSA คืออะไรแบบไม่ต้องเปิดตำรา Math

SSA ในเอกสารของ Subquadratic หมายถึง Subquadratic Sparse Attention หรือใน technical post เรียกว่า Subquadratic Selective Attention

แก่นของมันคือ content-dependent selection

Dense attention สมมติว่าทุกคู่ token อาจสำคัญ จึงคำนวณทุกคู่

SSA สมมติกลับกันว่า ส่วนใหญ่ไม่สำคัญ จึงให้ model เลือกว่าจะ attend ไปยังตำแหน่งไหนบ้างตามความหมายของข้อมูล

Subquadratic บอกว่า SSA มีคุณสมบัติสำคัญ 3 อย่าง:

1. Linear scaling in compute and memory

Attention cost โตตามจำนวนตำแหน่งที่เลือก ไม่ใช่ทุกคู่ความสัมพันธ์ใน sequence

1. Content-dependent routing

Model เลือกว่าจะดูตรงไหนตามความหมาย ไม่ใช่ pattern ตายตัว เช่น sliding window หรือ fixed stride

1. Sparse retrieval from arbitrary positions

ข้อมูลสำคัญจะอยู่ไกลแค่ไหนก็ยังมีโอกาสถูกดึงกลับมาได้ ไม่ใช่ถูกบีบหายไปใน state แบบ recurrent บางชนิด

ในภาษาคนทำงาน:

แทนที่จะให้พนักงานอ่านเอกสาร 10,000 หน้าแบบทุกบรรทัดเท่ากัน

SSA พยายามทำให้ model อ่านแบบรู้ว่า paragraph ไหนควรเปิดดูเมื่อกำลังตอบคำถามนี้

ประเด็นคือมันไม่ได้แค่ทำ attention แบบเดิมให้เร็วขึ้น

FlashAttention ทำให้ dense attention เร็วขึ้นมากก็จริง แต่ยังทำงาน all-pairs อยู่

SSA อ้างว่ามันลดจำนวนงาน attention ที่ต้องทำตั้งแต่แรก

นั่นคือเหตุผลที่ตัวเลข speedup ใหญ่มากเมื่อ context ยาวขึ้น

4. ตัวเลขที่ SubQ claim ใหญ่แค่ไหน

จาก launch post, homepage และ technical post ของ Subquadratic มีตัวเลขที่ควรรู้ดังนี้:

• SubQ 1M-Preview เป็น private beta model สำหรับ long-context workload
• research model ทำงานได้ถึง 12 million tokens
• ที่ 12M tokens บริษัท claim ว่า attention compute ลดเกือบ 1,000x เมื่อเทียบกับ frontier models
• ที่ 1M tokens SSA มี 52.2x prefill speedup เทียบกับ dense attention path บน B200s ตาม technical post
• ที่ 1M tokens มี attention FLOP reduction 62.5x เทียบกับ standard quadratic attention
• RULER @ 128K ได้ 95.0% เทียบกับ Opus 4.6 ที่บริษัทระบุ 94.8%
• MRCR v2 ได้ 65.9%
• SWE-Bench Verified ได้ 81.8%
• Homepage ระบุ 12M-token reasoning, 150 tokens per second และ cost positioning ประมาณ 1/5 ของ leading LLMs
• เปิด early access สำหรับ API, SubQ Code และ SubQ Search

ถ้ามองแค่ตัวเลข นี่คือ “โห” มาก

แต่ต้องอ่านแบบมีวินัยครับ

เพราะตอน verification นี้ SubQ ยังอยู่ใน private beta

technical report และ model card ยังขึ้นว่า coming soon

VentureBeat รายงานว่าชุมชน AI มี reaction ผสมมาก ตั้งแต่สนใจจริงจังไปจนถึงคำแรง ๆ ว่า “AI Theranos”

ผมว่าไม่ต้องเลือกข้างเร็วเกินไป

สิ่งที่ควรทำคือแยกเป็น 2 ชั้น:

• ปัญหาที่ SubQ ชี้นั้นจริงมาก: long context แพงและเปราะบาง
• คำตอบของ SubQ ต้องรอพิสูจน์เพิ่ม: benchmark, pricing, latency, quality, safety และ reproducibility

พูดง่าย ๆ คือเราไม่ควร dismiss เพราะ claim ใหญ่

แต่ก็ไม่ควรเชื่อหมดเพราะ headline มันสวย

5. SubQ Code คือ use case ที่น่าจับตาก่อนสุด

ใน products ที่ Subquadratic เปิดตัว ผมว่าสิ่งที่ practical ที่สุดคือ SubQ Code

เพราะ coding agent มีปัญหา long context ชัดมาก

เวลา agent แก้ codebase จริง มันไม่ได้ต้องอ่านแค่ไฟล์เดียว

มันต้องเข้าใจ:

• dependency ระหว่าง module
• test ที่เกี่ยวข้อง
• interface contract
• naming convention
• previous implementation
• migration path
• hidden coupling
• issue history
• style ของ repo

ถ้า agent เห็นแค่ fragment มันอาจ patch ได้ถูกในไฟล์เดียว แต่พังทั้งระบบ

นี่คือเหตุผลที่ coding agent จำนวนมากต้องใช้ subagent, repo map, grep, search, summarization และ context compaction วนไปเรื่อย ๆ

SubQ Code positioning ชัดว่าอยากเป็น long-context layer ให้ Claude Code, Codex และ Cursor

ให้ agent สามารถ map codebase, gather context และตอบคำถาม token-heavy ได้เร็วขึ้น

ถ้าทำได้จริง impact จะไม่ใช่แค่ “ถูกลง”

แต่คือ workflow เปลี่ยนจาก:

1. search file
2. read partial context
3. guess dependency
4. edit
5. test fail
6. search ใหม่
7. edit ใหม่

ไปใกล้กับ:

1. อ่าน repo ทั้งก้อน
2. plan โดยเห็น constraint หลายชั้น
3. patch แบบเข้าใจระบบ
4. review risk ด้วยบริบทครบกว่าเดิม

แน่นอนว่า “อ่านได้ทั้ง repo” ไม่ได้แปลว่า “แก้ถูกเสมอ”

แต่ context ที่ครบขึ้นมักลด class of mistakes ที่เกิดจากการไม่เห็นภาพรวม

สำหรับทีม software นี่อาจเป็น adoption wedge ที่แข็งแรงมาก

6. Enterprise AI จะได้ประโยชน์ตรงไหน

สำหรับธุรกิจทั่วไป SubQ ไม่ได้สำคัญแค่กับ programmer

มันสำคัญกับงานที่ข้อมูลกระจายยาวและต้อง reasoning ข้ามหลักฐานหลายจุด

ตัวอย่างที่เห็นภาพ:

Contract และ Legal Review

สัญญาหนึ่งฉบับอาจอ้าง definition หน้าแรก exception หน้ากลาง และ obligation อีกหน้า

ถ้ามี 50 ฉบับใน deal เดียว การ review แบบ RAG ธรรมดาอาจดึง clause ถูกแต่พลาดความสัมพันธ์ข้ามเอกสาร

Long-context model ที่ใช้ได้จริงอาจช่วยเห็น pattern, inconsistency และ risk ได้ดีขึ้น

Customer Intelligence

ลูกค้ารายหนึ่งอาจมีข้อมูลใน CRM, email, meeting note, support ticket, invoice, chat log และ proposal version เก่า

ถ้า AI เห็นแค่ summary ล่าสุด มันจะตอบแบบผิว ๆ

แต่ถ้าเห็น history ยาวได้ใน cost ที่รับได้ มันอาจช่วยทำ next best action ได้แม่นขึ้น

Operations และ SOP

บริษัทจำนวนมากมี SOP กระจายอยู่ใน Google Docs, PDF, Notion, Slack, Sheet และระบบภายใน

ปัญหาไม่ได้อยู่ที่ไม่มี knowledge

ปัญหาอยู่ที่ knowledge กระจายและเชื่อมกันไม่ดี

ถ้า model long-context ดีขึ้น เราอาจสร้าง AI assistant ที่อ่าน manual ทั้งชุดแล้วช่วยตรวจ process ได้จริงมากขึ้น

Data และ Spreadsheet Reasoning

งานธุรกิจไทยจำนวนมากยังอยู่ใน spreadsheet

ไม่ใช่ spreadsheet เดียว แต่เป็นหลายไฟล์ หลาย sheet หลาย version

Long-context AI ที่อ่าน table, comment, formula และ history ได้มากขึ้น จะเปลี่ยนงาน analyst และ operations เยอะมาก

Agent Memory และ Persistent State

Agent ที่ทำงานยาวหลายวันมักเสีย context เพราะต้อง summarize ตัวเองเรื่อย ๆ

ถ้า long-context ถูกลงมาก agent อาจเก็บ state, decision, error history และ review note ได้นานขึ้น

นี่คือจุดที่เชื่อมกับโลก “1 Human + 100 AI Agents” โดยตรง

ไม่ใช่ agent ฉลาดขึ้นอย่างเดียว

แต่ agent จำบริบทงานได้นานขึ้นและถูกลง

7. ข้อควรระวัง: อย่าเปลี่ยน Stack เพราะ Headline เดียว

ถึงผมจะตื่นเต้นกับ SubQ แต่ถ้าถามว่าธุรกิจควรรีบย้าย architecture ไหม

คำตอบคือ ยังไม่ควร

อย่างน้อยต้องรอดู 7 เรื่องนี้ก่อน:

1. Independent evaluation

benchmark ควรถูกทดสอบซ้ำโดยคนภายนอก ไม่ใช่แค่ตัวเลขจาก launch

1. Model card และ technical report

ต้องเห็นรายละเอียด architecture, training, limitations, safety, eval methodology และ pricing assumptions

1. General capability

long-context ดีอย่างเดียวไม่พอ ต้องดู reasoning, math, coding, multilingual, Thai, instruction following และ tool use

1. Latency จริง

prefill speedup สำคัญ แต่ production latency รวมถึง output speed, queueing, rate limit และ reliability ด้วย

1. Cost จริง

cost claim ต้องเทียบจาก workload จริง ไม่ใช่ benchmark เฉพาะทาง

1. Data governance

การส่ง context ใหญ่มากเข้า model เพิ่ม risk เรื่อง privacy, permission boundary และ audit trail

1. Failure modes

ถ้า model เห็นข้อมูลเยอะขึ้น แต่เลือก attend ผิดจุด ความผิดพลาดอาจดูน่าเชื่อยิ่งกว่าเดิม

นี่คือ classic AI infrastructure rule:

อย่า redesign production stack จาก benchmark เดียว

ให้เริ่มจาก pilot ที่วัดได้

8. SME ไทยควรเตรียมตัวยังไง

แม้ SubQ ยังไม่พร้อมให้ทุกคนใช้จริงแบบกว้าง ๆ แต่ signal นี้สำคัญมากสำหรับ SME ไทย

เพราะถ้า cost curve ของ long-context AI ลดลงจริง คนที่มีข้อมูลพร้อมจะได้เปรียบก่อน

สิ่งที่ควรทำตอนนี้ไม่ใช่ “รอ SubQ”

แต่คือเตรียมองค์กรให้ใช้ long-context AI ได้เมื่อมันถูกลง

เริ่มจากจัดข้อมูลให้ AI อ่านง่าย

ไฟล์กระจายไม่เป็นไร แต่ต้องมี structure

• ตั้งชื่อไฟล์ให้ชัด
• แยก version ให้รู้ว่าอันไหน current
• มี owner ของเอกสาร
• ลด duplicate doc
• เก็บ decision log
• ทำ glossary ของคำเฉพาะในบริษัท

ทำ SOP ให้กลายเป็น machine-readable operations

SOP ที่เขียนแบบคลุมเครือ คนยังตีความยาก AI ก็ยิ่งยาก

ควรเขียนให้มี:

• trigger
• input
• expected output
• exception
• approval point
• risk level
• escalation path

สร้าง benchmark ของบริษัทเอง

อย่ารอ vendor benchmark อย่างเดียว

ลองเตรียมโจทย์แบบนี้:

• ให้ AI อ่าน support ticket 1,000 เคสแล้วหาปัญหาที่ซ้ำ
• ให้ AI อ่าน contract 20 ฉบับแล้วหา clause ที่ conflict กัน
• ให้ AI อ่าน codebase แล้วตอบว่าแก้ feature นี้ต้องแตะไฟล์ไหน
• ให้ AI อ่าน sales history แล้วเสนอ upsell opportunity พร้อมหลักฐาน

ถ้า model ไหนทำโจทย์จริงของเราได้ดี นั่นสำคัญกว่า leaderboard

แยกงานที่ต้องการ long context จริงออกจากงานทั่วไป

ไม่ใช่ทุกงานต้องใช้ 12M tokens

หลายงานใช้ small model, RAG ธรรมดา หรือ workflow automation ก็พอ

Long-context model ควรใช้กับงานที่ต้องเห็นภาพรวมจริง ๆ เช่น:

• cross-document reasoning
• full-repo code analysis
• long customer history
• regulatory/legal review
• multi-month operations diagnosis
• agent state continuity

ใช้ผิดที่ก็แพงเปล่า ถึง model จะถูกลงแล้วก็ตาม

9. มุมมองส่วนตัว: SubQ สำคัญแม้สุดท้ายจะไม่ชนะ

ในความเห็นของผม SubQ สำคัญมาก แม้สุดท้ายอาจไม่ใช่บริษัทที่ชนะตลาดนี้

เพราะมันชี้จุดปวดที่ถูกต้อง:

AI product จำนวนมากวันนี้ไม่ได้แพ้เพราะ model ไม่ฉลาดพออย่างเดียว

แต่แพ้เพราะ context management แพงและซับซ้อนเกินไป

เรามีข้อมูลเยอะ แต่ model เห็นแค่นิดเดียว

เราอยากให้ agent ทำงานต่อเนื่อง แต่ต้องคอย compress memory

เราอยากให้ AI เข้าใจระบบทั้งก้อน แต่ต้องบังคับให้มันอ่านทีละ fragment

เราอยากลด human curation แต่กลับต้องจ้างคนออกแบบ chunking, routing, evaluation และ guardrails เพิ่ม

ถ้า architecture ใหม่ทำให้ context ถูกลงจริง product design จะเปลี่ยน

จากเดิม:

เลือกข้อมูลชิ้นเล็ก ๆ ที่น่าจะเกี่ยว แล้วหวังว่า model จะตอบถูก

เป็น:

ให้ model เห็นระบบทั้งก้อน แล้วควบคุมสิทธิ์, freshness, reasoning path และ action boundary ให้ดี

นี่คือโลกที่น่าสนใจกว่าเยอะครับ

แต่ผมยังให้คะแนนแบบ cautious optimism

คะแนนความน่าจับตา: 9/10

คะแนนความพร้อมเชื่อทันที: 5/10

เพราะ claim ใหญ่เกินกว่าจะเชื่อจาก launch post อย่างเดียว

ต้องรอดู technical report, model card, public access, independent benchmark และ production user reports

สรุป

SubQ เป็นหนึ่งในข่าว AI infrastructure ที่ควรจับตาที่สุดช่วงนี้

ไม่ใช่เพราะ headline “12M tokens” อย่างเดียว

แต่เพราะมันโจมตีต้นทุนพื้นฐานของ long-context AI

ถ้า Subquadratic Sparse Attention ใช้ได้จริงใน production เราอาจเห็นการเปลี่ยนแปลงใหญ่ใน:

• RAG architecture
• coding agents
• enterprise search
• legal and compliance AI
• customer intelligence
• agent memory
• AI operating systems สำหรับองค์กร

แต่ตอนนี้ยังต้องระวัง

SubQ ยัง private beta

technical report และ model card ยังมาไม่ครบ

benchmark ยังต้องรอ independent validation เพิ่ม

สิ่งที่ธุรกิจควรทำวันนี้คือไม่ใช่รีบเปลี่ยน stack

แต่ควรถามตัวเองว่า:

ถ้าวันหนึ่ง AI อ่านบริบททั้งบริษัทได้ถูกและเร็วขึ้น เรามีข้อมูลที่สะอาดพอ มีสิทธิ์ที่ชัดพอ และมีโจทย์ที่คมพอให้มันช่วยจริงไหม?

เพราะอนาคตของ AI อาจไม่ได้อยู่ที่ model ที่ตอบเก่งขึ้นอย่างเดียว

แต่อยู่ที่ model ที่เห็นบริบททั้งงานได้ถูกกว่า เร็วกว่า และไม่หลุดประเด็นง่าย ๆ ครับ