LightOn ปล่อย mLateOn/mDenseOn โมเดล retrieval หลายภาษา 307M พารามิเตอร์ Apache-2.0 — และพิสูจน์ว่า late interaction ข้ามไปภาษาที่ไม่เคยเทรนได้ดีกว่า dense ถึง 10 จุด

30 กรกฎาคม 2026 LightOn ปล่อยโมเดล retrieval หลายภาษาสองตัว — mDenseOn และ mLateOn — ขนาด 307M พารามิเตอร์ เท่ากัน ใช้ backbone เดียวกันคือ mmBERT-base และเทรนด้วยข้อมูลชุดเดียวกัน ต่างกันแค่วิธีเข้ารหัสและเทียบความคล้าย

การออกแบบแบบนี้ทำให้มันเป็นการทดลองที่สะอาดผิดปกติ และผลที่ได้ก็ตอบคำถามที่ทีม RAG ถกกันมานาน

dense กับ late interaction ต่างกันตรงไหน

โมเดล dense บีบข้อความทั้งชิ้นให้เหลือเวกเตอร์ตัวเดียว แล้วเทียบความคล้ายด้วย dot product — เร็ว เก็บง่าย เข้ากับ vector database ทุกเจ้า

โมเดล late interaction (สายเดียวกับ ColBERT) เก็บ representation ระดับ token ไว้ทั้งหมด แล้วค่อยเทียบกันตอน retrieve — แม่นกว่าแต่กินพื้นที่และต้องใช้ engine เฉพาะ

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

ตัวเลข — และจุดที่น่าสนใจจริง ๆ

mLateOn (late interaction):

• BEIR: 57.56 NDCG@10
• MIRACL ภาษาที่เทรน: 65.61
• MIRACL ภาษาที่ไม่เคยเห็น: 67.59
• MLDR ภาษาที่เทรน: 87.69
• MTEB Code: 73.48

mDenseOn (dense):

• BEIR: 56.70
• MIRACL ภาษาที่เทรน: 59.61
• MLDR ภาษาที่เทรน: 64.98

บน BEIR (ภาษาอังกฤษ) สองตัวนี้ห่างกันไม่ถึงหนึ่งจุด — 57.56 กับ 56.70 ถ้าดูแค่ตรงนี้จะสรุปว่า dense คุ้มกว่าเพราะถูกกว่ามาก

แต่พอข้ามไปภาษาอื่น ช่องว่างเปิดออกทันที และจุดที่แรงที่สุดคือ ภาษาที่ไม่ได้อยู่ในชุดเทรน retrieval เลย: mLateOn ทำได้ 67.59 ขณะที่ mDenseOn ได้ 57.42 — ห่างกันราว 10 จุด ข้อสรุปของผู้เขียนตรงไปตรงมาว่า “โมเดล late interaction generalize ไปยังภาษาที่ไม่เคยเห็นระหว่างการเทรน retrieval ได้ดีกว่ามาก”

สังเกตอีกอย่างที่แปลกดี: mLateOn ทำคะแนนบนภาษาที่ ไม่เคยเทรน (67.59) ได้สูงกว่าภาษาที่เทรน (65.61) เล็กน้อย ซึ่งสะท้อนว่าความสามารถส่วนใหญ่มาจาก backbone หลายภาษาและกลไก late interaction มากกว่าจะมาจากข้อมูล fine-tune รายภาษา

เทรนยังไง และปล่อยอะไรมาบ้าง

ทีมใช้วิธี translate-train — เอาชุดข้อมูล retrieval ภาษาอังกฤษที่คัดมาแล้วไปแปลเป็น 8 ภาษาเป้าหมายด้วย Mistral-Small และ Qwen3 พร้อมสร้างคู่ข้ามภาษา (cross-lingual pairs) ผสมเข้าไป 25%

ภาษาที่ครอบคลุม: อังกฤษ + ฝรั่งเศส เยอรมัน อิตาลี สเปน โปรตุเกส สวีเดน นอร์เวย์ และอาหรับ — บวกโค้ด ข้อมูล: pre-training 2.8 พันล้านคู่, fine-tuning 16.3 ล้านตัวอย่าง

ที่ปล่อยออกมาครบชุดจริง ๆ:

• โมเดล: lightonai/mLateOn, lightonai/mDenseOn และรุ่น unsupervised — ใบอนุญาต Apache-2.0
• รุ่นภาษาอังกฤษ: lightonai/LateOn, lightonai/DenseOn
• ชุดข้อมูล: lightonai/multilingual-embeddings-pre-training-curated และชุด fine-tune แยกรายภาษา ทั้งฉบับกรองแล้วและไม่กรอง
• โค้ดเทรน: github.com/lightonai/mdenseon-mlateon
• เครื่องมือ: ไลบรารี PyLate สำหรับเทรนและ retrieve และ FastPLAID เอนจิน multi-vector search

มุมมอง AI Curator

ประเด็นที่ทีม RAG ในไทยควรหยุดอ่านตรงนี้คือ ตัวเลข 67.59 บนภาษาที่ไม่เคยเทรน

ภาษาไทยไม่อยู่ในรายชื่อ 9 ภาษาที่ LightOn เทรน และนั่นแหละคือเหตุผลที่งานนี้เกี่ยวกับเราโดยตรง เพราะสิ่งที่เขาวัดคือ “ถ้าภาษาของคุณไม่อยู่ในชุดเทรน จะเหลืออะไรบ้าง” — และคำตอบคือถ้าใช้ late interaction จะเหลือเยอะกว่าที่คิด ขณะที่ dense จะร่วงแรง สำหรับตลาดที่ภาษาแทบไม่เคยได้ที่นั่งในชุดข้อมูลหลัก นี่คือความแตกต่างระหว่าง “ต้องรอให้มีคนเทรนโมเดลภาษาไทยโดยเฉพาะ” กับ “หยิบของ open weights มาใช้ได้เลยวันนี้”

ย้ำว่านี่คือการอนุมานจากผลบนภาษาอื่นที่ไม่ได้เทรน ไม่ใช่ตัวเลขภาษาไทยที่ LightOn วัดมา — ใครจะเอาไปใช้จริงควรทดสอบกับคลังเอกสารของตัวเองก่อนเสมอ แต่ถ้าจะเดิมพัน สมมติฐานนี้มีหลักฐานหนุนพอสมควร

เรื่องต้นทุนก็เข้าทาง: 307M พารามิเตอร์ คือโมเดลที่รันบน CPU ได้สบายและใส่ GPU ตัวเล็กได้ทั้งตัว ไม่ใช่ของที่ต้องเช่า H100 ประกอบกับ Apache-2.0 ที่ให้ใช้เชิงพาณิชย์ได้เต็มที่ และการที่เขาปล่อย ชุดข้อมูลเทรนออกมาด้วย ไม่ใช่แค่ weights — ทีมที่อยากต่อยอดไปภาษาไทยสามารถเอา pipeline translate-train ของเขาไปทำซ้ำได้จริง ซึ่งหายากกว่าที่คิด เพราะโมเดล embedding ส่วนใหญ่ปล่อยแค่ weights แล้วปิดสูตร

ข้อควรระวังที่ไม่ควรมองข้าม: late interaction ไม่ใช่ของฟรี การเก็บเวกเตอร์ระดับ token ทำให้ index ใหญ่ขึ้นหลายเท่าเทียบกับ dense และ vector database ทั่วไปอย่าง pgvector หรือ Pinecone ไม่ได้ออกแบบมารองรับ multi-vector search โดยตรง — นั่นคือเหตุผลที่ LightOn ต้องทำ FastPLAID ขึ้นมาเอง ทีมที่จะย้ายจาก dense ไป late interaction ต้องนับต้นทุน infra และการดูแล engine เพิ่มเข้าไปด้วย ไม่ใช่แค่สลับชื่อโมเดล

วิธีที่สมเหตุสมผลที่สุดสำหรับทีมส่วนใหญ่จึงน่าจะเป็น hybrid — ใช้ dense ที่ถูกและเร็วคัดผู้สมัครชั้นแรก แล้วให้ late interaction ทำ rerank ชั้นสอง ได้ความแม่นบนภาษาไทยโดยไม่ต้องแบก index ระดับ token ทั้งคลัง และเนื่องจากสองโมเดลนี้ใช้ backbone เดียวกัน การวางคู่กันในระบบเดียวก็ทำได้ตรงไปตรงมากว่าการผสมโมเดลจากคนละค่าย

แหล่งข่าว

• mDenseOn with the mLateOn: Open Multilingual, Long-Context, and Code Retrieval Models — LightOn บน Hugging Face
• lightonai/mLateOn — โมเดลบน Hugging Face (Apache-2.0)
• lightonai/mDenseOn — โมเดลบน Hugging Face