NeoMME: เอ็นโค้ดเดอร์มัลติโมดัล 260M/800M ที่โยน vision tower กับ causal decoder ทิ้ง — Apache 2.0 ชนะทุกตัวที่ต่ำกว่า 800M บน ViDoRe v3 และบีบดัชนีจาก 1.5 MB เหลือ 6 kB ต่อหน้า

โมเดลค้นคืนเอกสารด้วยภาพ (visual document retrieval) ส่วนใหญ่ทุกวันนี้เกิดจากการดัดแปลง VLM เชิงกำเนิดมาใช้ — เอา vision encoder ที่เทรนแยกมาก่อน ต่อ projector แล้วส่งเข้า causal decoder ซึ่งเป็นสถาปัตยกรรมที่ออกแบบมาเพื่อ สร้างข้อความ ทั้งที่งานค้นคืน งานจำแนก และงานติดป้ายโทเคนไม่ต้องสร้างข้อความสักตัว พารามิเตอร์และคอมพิวต์ของ decoder จึงเป็นภาระที่แบกมาฟรี ๆ

NeoMME จาก H Company เลือกรื้อทิ้งทั้งสองชั้น เป็นตระกูลเอ็นโค้ดเดอร์มัลติโมดัลหลายภาษาขนาด 260M และ 800M ที่ใช้ Transformer แบบ bidirectional ตัวเดียวประมวลผลทั้งโทเคนข้อความและ patch ภาพดิบ โดยไม่มี vision tower ไม่มี text encoder และไม่มี decoder ที่เทรนมาก่อน — เทรนทั้งตัวจากศูนย์ ประกาศผ่านบล็อก Hugging Face เมื่อ 3 ก.ย. 2026 พร้อมรายงานเทคนิคบน arXiv (2609.01657 ส่งเมื่อ 31 ส.ค.) โดย Aurélien Lac และ Tony Wu และปล่อยเช็กพอยต์ทั้งหมดใต้ Apache 2.0

เรียนภาพผ่านการเดาข้อความที่ถูกปิด

วิธีเทรนคือจุดที่แปลกที่สุด NeoMME ถูกพรีเทรนเป็น discrete masked-diffusion text denoiser — สุ่มอัตราการปิดบังโทเคนข้อความ แล้วให้โมเดลกู้คืน สำหรับตัวอย่างที่มีแต่ข้อความ อัตราปิดบังสุ่มระหว่าง 0 ถึง 1 แต่สำหรับตัวอย่างมัลติโมดัล อัตราถูกบังคับให้อยู่ระหว่าง 0.3 ถึง 1 โดย patch ภาพเปิดให้เห็นตลอด

เหตุผลตรงไปตรงมา: ถ้าปิดข้อความน้อย โมเดลเดาคำที่หายจากบริบทข้อความรอบ ๆ ได้เอง (“The [MASK] sat on the mat” เดา “cat” ได้โดยไม่ต้องดูภาพ) การบังคับอัตราปิดบังให้สูงจึงเป็นการตัดทางลัดทางภาษาทิ้ง เพื่อบีบให้โมเดลต้องใช้หลักฐานจากภาพจริง ๆ

รายละเอียดสถาปัตยกรรมที่ตรวจสอบได้จาก config.json ของเช็กพอยต์: ภาพถูกหั่นเป็น patch 32×32 แล้วโปรเจกต์ด้วย MLP เล็ก ๆ เข้าเส้นทางเดียวกับข้อความ, คอนเท็กซ์ 16,384 โทเคน (พอสำหรับภาพ 4K UHD สองภาพ), 17 เลเยอร์ที่ใช้ sliding-window attention เป็นหลักโดยมี global attention ทุกเลเยอร์ที่หกและเลเยอร์สุดท้าย, grouped-query attention 16 หัวต่อ 4 KV, activation แบบ squared-ReLU, 2D RoPE และ QK normalization ส่วน tokenizer เป็น BPE 131k คำศัพท์ที่เทรนใหม่จากข้อความหลายภาษา โค้ด คณิตศาสตร์ และ transcript ของภาพ

งบเทรนคือ ~524 พันล้านโทเคนแบบ packed ต่อโมเดล ในจำนวนนี้เป็นตัวอย่างข้อความล้วน 290 พันล้าน ซึ่งทีมยอมรับเองว่าน้อยเมื่อเทียบกับ 2 ล้านล้านโทเคนของ ModernBERT จึงเลือก optimizer NorMuon เพื่อเพิ่มประสิทธิภาพต่อข้อมูล

ตัวเลข ViDoRe และเชิงอรรถที่ต้องอ่าน

NeoMME-Retriever ถูกฟายน์จูนตามแนวทาง page-image ของ ColPali และมีสองหัวที่เทรนพร้อมกัน — หัว dense (mean pooling ได้เวกเตอร์เดียว) และหัว late-interaction (โปรเจกต์ทุกโทเคน/patch เป็นเวกเตอร์ 128 มิติ) — คืนค่าทั้งคู่ใน forward pass เดียว

กลุ่ม	โมเดล	พารามิเตอร์	ViDoRe v3 (@10)	v2 (@5)	v1 (@5)
<300M	ColModernVBERT †	250M	0.261	0.407	0.806
<300M	NeoMME-260M ‡	260M	0.523	0.522	0.860
300M–1B	ColSmol-500M	500M	0.340	0.455	0.825
300M–1B	Vultron Flash †	850M	0.565	0.604	0.882
300M–1B	NeoMME-800M ‡	800M	0.556	0.559	0.874
>1B	ColQwen2.5-v0.2 †	3.75B	0.524	0.601	0.895
>1B	ColPali v1.3 †	2.92B	0.430	0.547	0.848

จุดที่น่าประทับใจจริงคือแถว 260M: 0.523 สูงสุดในบรรดาโมเดลที่เล็กกว่า 800M อย่างชัดเจน และห่างจาก ColQwen2.5-v0.2 ขนาด 3.75B แค่ 0.002 ทั้งที่พารามิเตอร์น้อยกว่าราว 14 เท่า

แต่เชิงอรรถของตารางต้องอ่านให้ครบ: † หมายถึงคะแนนที่ดึงมาจาก MTEB ส่วน ‡ คือผลที่ทีมประเมินเอง — และแถว NeoMME ทั้งสองแถวเป็น ‡ ขณะที่คู่แข่งหลักอย่าง ColModernVBERT และ Vultron Flash เป็น † การเทียบคะแนนที่ตัวเองรันกับคะแนนที่คนอื่นรันในคอลัมน์เดียวกันเป็นเรื่องที่ควรมีคนนอกทวนซ้ำก่อนเชื่อเต็มร้อย และถ้าดูเฉพาะตัวเลขดิบ NeoMME-800M แพ้ Vultron Flash ที่ขนาดใกล้กัน (0.556 ต่อ 0.565) คำว่า “Pareto frontier” ในบล็อกจึงหมายถึงเส้นแลกระหว่างขนาดกับคะแนน ไม่ใช่การชนะคะแนนดิบ

ตัวเลขที่มีผลกับบิลจริง: 51 หน้าต่อวินาที และดัชนี 6 kB ต่อหน้า

สองตัวเลขที่กระทบต้นทุนของคนสร้างระบบมากกว่า nDCG:

ความเร็วอินเด็กซ์ — ที่ขนาดภาพเข้า 2048×2048 เท่ากันบน NVIDIA L40S ใบเดียว NeoMME-Retriever-260M เข้ารหัสได้ราว 51 หน้าต่อวินาที เทียบกับ 26 หน้าต่อวินาทีของ ColModernVBERT หรือเกือบสองเท่า ซึ่งแปลตรง ๆ เป็นชั่วโมง GPU ที่ใช้ตอนสร้างดัชนีคลังเอกสารครั้งแรก

ขนาดดัชนี — นี่คือจุดที่ late-interaction มักพัง เพราะพื้นที่จัดเก็บโตตามจำนวนเวกเตอร์ หน้าขนาด 2048×2048 หนึ่งหน้าให้ 4,200 เวกเตอร์ ≈ 2.1 MB ที่ float32 และค่าเฉลี่ยจริงบน ViDoRe v3 อยู่ที่ราว 1.5 MB ต่อหน้า ทีมแก้ด้วยสองวิธีผสมกัน คือ hierarchical token pooling (จับเวกเตอร์ที่คล้ายกันมารวมเป็นค่าเฉลี่ย) และ asymmetric quantization (บีบเวกเตอร์ฝั่งเอกสารลงเป็น int8 หรือ binary ขณะที่เวกเตอร์ฝั่งคำค้นสร้างสด ๆ จึงคงความละเอียดสูงไว้ได้)

• pooling factor 10 + int8 ทั้งสองฝั่ง → 39 kB ต่อหน้า (เล็กลง 39 เท่า) โดยรักษาคุณภาพไว้เกิน 99%
• pooling factor 8 + คำค้น int8 + เอกสาร binary → 6 kB ต่อหน้า (เล็กลง 255 เท่า) โดยรักษาคุณภาพไว้เกิน 95%

ในทางปฏิบัติคือคลังเอกสารหนึ่งล้านหน้าที่เคยต้องใช้พื้นที่ระดับ 1.5 TB ลงมาเหลือระดับหลักกิกะไบต์ ซึ่งเปลี่ยนคำถามจาก “จ่ายไหวไหม” เป็น “เลือกจุดไหนบนเส้นแลก”

เริ่มใช้จริง

NeoMME มีอิมพลีเมนต์ใน Hugging Face Transformers ตั้งแต่วันแรก (คลาส NeoMMEForRetrieval และ NeoMMEProcessor) แต่ยังต้องติดตั้ง transformers จาก main และ sentence-transformers>=6.0.0:

pip install -U accelerate \
  "transformers @ git+https://github.com/huggingface/transformers.git@main" \
  "sentence-transformers>=6.0.0"

ข้อควรรู้สำหรับคนที่จะฟายน์จูนต่อ: ทีมปล่อยเช็กพอยต์ -ST-dense และ -ST-late แยกกัน เพราะ Sentence Transformers รองรับหัวค้นคืนได้หัวเดียวต่อโมเดล ถ้าอยากเทรนสองหัวพร้อมกันต้องใช้ NeoMMEForRetrieval กับ Trainer ที่เขียนเอง และย้ำอีกครั้งว่านี่คือ เอ็นโค้ดเดอร์ ไม่ใช่โมเดลสนทนา — มันสร้างเวกเตอร์ ไม่ได้ตอบคำถาม ในระบบ visual RAG มันทำหน้าที่ชั้นค้นคืน แล้วส่งภาพหน้าที่เลือกได้ต่อให้ VLM ตอบ

มุมมอง AI Curator

สิ่งที่ทำให้ NeoMME น่าสนใจกว่าโมเดลเปิดทั่วไปที่ออกมาทุกสัปดาห์ ไม่ใช่คะแนน แต่คือการที่มันเป็นหลักฐานว่าสมมติฐาน “เอา VLM ที่มีอยู่มาดัดแปลง” ไม่ได้เป็นทางเดียว ทั้งวงการค้นคืนเอกสารสองปีที่ผ่านมาเดินตาม ColPali ซึ่งแปลว่าทุกคนแบกน้ำหนักของ decoder ที่ไม่เคยถูกใช้สร้างข้อความสักตัว การที่ทีมสองคน — ที่เขียนใน acknowledgements เองว่างานนี้ “เริ่มจากการเป็น side quest ระหว่างเพื่อนสองคน” ด้วยเวลาและคอมพิวต์จำกัด — เทรนสถาปัตยกรรมใหม่จากศูนย์ด้วยงบ 524B โทเคนแล้วไล่ทันโมเดล 3.75B ได้ เป็นสัญญาณว่างานฝั่ง representation ยังมีที่ว่างให้ทีมเล็กเยอะกว่าฝั่งโมเดลกำเนิดมาก

สำหรับไทย ผมคิดว่านี่เป็นหนึ่งในโมเดลที่ควรลองเป็นเรื่องแรก ๆ ของทีมที่ทำระบบเอกสาร เหตุผลไม่ใช่เพราะมันเล็ก แต่เพราะแนวทาง page-image ข้าม OCR ทิ้งทั้งขั้นตอน — และ OCR คือจุดที่ระบบเอกสารไทยพังบ่อยที่สุด ทั้งจากการที่ภาษาไทยไม่มีช่องว่างระหว่างคำ ทั้งจากสระบนล่างที่โมเดล OCR ทั่วไปทำหล่น และทั้งจากเอกสารราชการที่สแกนเบี้ยว การค้นคืนจากภาพหน้าโดยตรงหลบปัญหานี้ได้ทั้งกอง และยังรักษาเลย์เอาต์ ตาราง และตราครุฑที่ OCR ทำหายไว้ด้วย

แต่ต้องพูดให้ตรง: บล็อกและรายงานไม่ได้อ้างว่าทดสอบภาษาไทยโดยเฉพาะ บอกเพียงว่าเป็น multilingual และ ViDoRe v3 เป็นเบนช์มาร์กหลายภาษา ดังนั้นนี่คือ “ควรทดสอบ” ไม่ใช่ “ใช้ได้แน่” ข้อดีคือต้นทุนการทดสอบต่ำมาก — Apache 2.0, 260M พารามิเตอร์รันได้บน GPU ผู้บริโภคหรือแม้แต่ CPU ที่อดทนได้ และมี Space ให้ลองก่อนโหลด ใครมีคลังเอกสารไทยสแกนอยู่ในมือ การรันเทียบกับไปป์ไลน์ OCR ปัจจุบันสัก 500 หน้าใช้เวลาไม่ถึงบ่ายเดียว และผลที่ได้จะบอกได้ทันทีว่าทางนี้คุ้มหรือไม่ — ซึ่งมีค่ากว่าการรอให้ใครสักคนตีพิมพ์เบนช์มาร์กภาษาไทยให้

แหล่งข่าว

• NeoMME: an efficient Multimodal-native and Multilingual Encoder — Hugging Face Blog, 3 ก.ย. 2026
• NeoMME: A Single-Tower Multimodal-Native Multilingual Foundation Encoder — arXiv:2609.01657
• Hcompany/NeoMME-260M-Retriever บน Hugging Face
• เดโม Visual RAG บน Hugging Face Spaces