SPARSEUP: sparse retriever 149M พารามิเตอร์ Apache-2.0 จาก Linkup — BEIR-13 56.4 nDCG@10 นำ SPLADE-v3 ที่ 51.7 และค้นเร็วระดับ 380 ไมโครวินาทีต่อคำค้น

16–17 ก.ย. 2026 Linkup Research ปล่อย SPARSEUP ขึ้น Hugging Face ภายใต้ Apache-2.0 — โมเดล learned sparse embedding ขนาด 149M พารามิเตอร์ ที่ทีมเคลมว่าเป็น sparse retriever แบบอิง vocabulary ที่แรงที่สุดเท่าที่เผยแพร่กันอยู่ในระดับต่ำกว่า 150M (น้ำหนักขึ้น HF วันที่ 16 บล็อกประกาศวันที่ 17 และ MarkTechPost หยิบไปเขียนต่อวันที่ 19)

สำหรับคนทำ RAG นี่ไม่ใช่โมเดล “ตอบคำถาม” แต่เป็นชิ้นส่วนที่อยู่ก่อนหน้านั้น — ตัวที่ตัดสินว่าเอกสารไหนจะถูกส่งเข้า context ของ LLM และเป็นตำแหน่งที่คุณภาพกับต้นทุนของทั้งระบบถูกล็อกไว้ตั้งแต่ต้น

เหตุผลที่มันเกิด: เติมช่องว่างให้เทียบสามสถาปัตยกรรมได้ยุติธรรม

ก่อนหน้านี้ LightOn ปล่อยข้อมูลเปิดพร้อมสูตรเทรนสำหรับ DenseOn (single-vector) และ LateOn (late interaction) ออกมา SPARSEUP เข้ามาเติมช่องที่ขาด คือฝั่ง learned sparse โดยใช้ backbone และข้อมูลชุดเดียวกัน ทำให้เปรียบเทียบสามสถาปัตยกรรมได้โดยคุมตัวแปรอื่นไว้คงที่ — ซึ่งเป็นสิ่งที่วงการ retrieval ขาดมานาน เพราะปกติแต่ละค่ายเทรนบนข้อมูลคนละชุดแล้วเอาตัวเลขมาวางข้างกัน

ทางเทคนิค โมเดลเริ่มจาก LateOn-unsupervised แล้ว graft หัว MLM ของ ModernBERT (head / decoder.bias) กลับเข้าไป โดย decoder.weight ยังผูกกับ embedding ของ LateOn ต่อ จากนั้น fine-tune แบบ contrastive บน mixture ของ LightOn ด้วย hard negative 7 ตัวที่สุ่มมาจาก 50 ตัว บวก in-batch negative — ไม่มีการ distill จาก cross-encoder ซึ่งเป็นทางลัดที่โมเดล sparse หลายตัวใช้เพื่อดันคะแนน

สามปุ่มที่ต่างจาก SPLADE แบบมาตรฐาน

• logit_shift=15 — ใช้ log(1 + ReLU(x − 15)) เพื่อให้ ReLU เริ่มมี support แบบ sparse ตั้งแต่ต้น แทนที่จะปล่อยให้เวกเตอร์หนาแล้วค่อยลงโทษทีหลัง
• position_top_k=12 — แต่ละ token เก็บได้ไม่เกิน 12 มิติของ vocabulary ก่อนเข้า pooling เป็นการกำหนด “งบการขยายคำ” ต่อ token ไว้ตรง ๆ
• vocab_fold=case_space — ยุบรูปผิว เช่น ตัวพิมพ์ใหญ่/เล็กและ Ġ ให้เป็น id เดียวกันหลัง pooling ทำให้ vocabulary ลดจาก 50k เหลือราว 34k

ผลรวมคือเวกเตอร์ที่ sparse จริงโดยไม่ต้องพึ่ง regularization หนัก ๆ และบนงาน MS MARCO ทีมวัดได้ราว 47 non-zero ต่อคำค้น และ 190 ต่อเอกสาร ส่วนการให้คะแนนใช้ dot product โดยใส่ prefix [Q] / [D] ซึ่งถูก attend แต่ไม่ถูก pool

ตัวเลข: นำกลุ่ม sparse ด้วยกัน แต่ยังตามหลัง dense บน backbone เดียวกัน

เทียบกับ sparse encoder ที่แข่งกันอยู่ (BEIR, nDCG@10 เฉลี่ยแบบไม่รวม MS MARCO):

โมเดล	Avg (ไม่รวม MS MARCO)
granite-embedding-30m-sparse	50.6
splade-v3	51.7
ModernBERT-VT	52.4
opensearch-neural-sparse-encoding-v1	52.44
opensearch-neural-sparse-encoding-doc-v3-gte	54.6
SPARSEUP (149M)	56.4
LACONIC-1B	58.7

แต่เมื่อเทียบแบบคุมตัวแปร (backbone และข้อมูลเดียวกัน) กับพี่น้องของมันเอง SPARSEUP ยังตามหลัง:

โมเดล	Avg	Avg (ไม่รวม MS MARCO)
LateOn (late interaction)	57.9	58.9
DenseOn (single-vector)	56.9	57.9
SPARSEUP (sparse)	55.4	56.4

ทีมระบุเงื่อนไขการวัดไว้ตรงไปตรงมาว่า SPARSEUP ใช้ Seismic ซึ่งเป็นการค้นแบบประมาณ ส่วนตัวเลขของ LateOn และ DenseOn มาจากการค้นแบบ exact — นั่นแปลว่าช่องว่างจริงแคบกว่าที่ตารางแสดงเล็กน้อย แต่ก็แปลว่า SPARSEUP ไม่ได้ชนะ dense บนคุณภาพล้วน ๆ

จุดที่มันชนะคือความเร็ว: บน MS MARCO ด้วย Seismic ทีมวัด latency ได้ราว 380 ไมโครวินาทีต่อคำค้น (single-threaded) ที่ recall เกิน 97% เทียบกับการค้นแบบ exact

สิ่งที่ต้องรู้ก่อนเอาไปใช้จริง

• ภาษาอังกฤษเท่านั้น โมเดลการ์ดระบุ language: en ชัดเจน
• ความยาวสูงสุดตอน eval: คำค้น 128 token, เอกสาร 512 token
• ต้องโหลดด้วย trust_remote_code=True เพราะสถาปัตยกรรม sparse head อยู่ในโค้ดของ repo ไม่ใช่ใน transformers มาตรฐาน — ข้อนี้สำคัญสำหรับทีมที่มีนโยบายห้ามรันโค้ดจากภายนอกในไปป์ไลน์ production
• API ใช้งานหลักคือ encode_to_dict(texts, kind="document"|"query", top_k=None) ซึ่งคืนค่าเป็น dict {token: weight} ต่อหนึ่งข้อความ เรียงตามน้ำหนักจากมากไปน้อย — เป็นรูปแบบที่เสียบเข้ากับ inverted index อย่าง Elasticsearch/OpenSearch ได้ตรง ๆ
• output เป็นเวกเตอร์ sparse ราว 34k มิติ ไม่ใช่ dense vector ดังนั้นโครงสร้าง index ฝั่งคุณต้องรองรับ

มุมมอง AI Curator

ช่วงสองปีที่ผ่านมา คำว่า “embedding” ในบทสนทนา RAG แทบจะหมายถึง dense vector อย่างเดียว และคนจำนวนมากข้ามฝั่ง sparse ไปเลยเพราะคิดว่ามันคือ BM25 เวอร์ชันแต่งหน้า SPARSEUP เป็นโอกาสดีที่จะทบทวนข้อนั้น — ไม่ใช่เพราะมันแรงกว่า dense (ตารางบอกชัดว่ามันไม่) แต่เพราะมันแรงพอในราคาที่คุณสมบัติทางวิศวกรรมต่างออกไปมาก

ข้อได้เปรียบที่ไม่ได้อยู่ในตารางคือ มันเสียบเข้า inverted index ที่ทีมคุณมีอยู่แล้วได้เลย องค์กรไทยจำนวนมากรัน Elasticsearch หรือ OpenSearch อยู่แล้วสำหรับ log และการค้นหาในระบบ การเพิ่ม sparse retrieval คือการเพิ่มฟิลด์กับน้ำหนัก ไม่ใช่การจัดหาและดูแล vector database ใหม่ทั้งระบบ สำหรับทีม 3-5 คนที่มี infra จำกัด ความต่างตรงนี้มักใหญ่กว่าความต่าง 1.5 nDCG point

ข้อได้เปรียบที่สองคือเรื่องที่ dense vector ทำได้แย่มาโดยตลอด: การจับคำที่ตรงตัวแต่ไม่มีในข้อมูลเทรน — รหัสสินค้า, เลขที่เอกสาร, ชื่อยา, ชื่อรุ่นอุปกรณ์ เวกเตอร์ 34k มิติที่แต่ละมิติคือคำจริงในพจนานุกรม ทำให้ debug ได้ด้วยตาเปล่า: คุณเปิดดูได้เลยว่าโมเดลขยายคำค้นออกไปเป็นคำอะไรบ้างและด้วยน้ำหนักเท่าไร ซึ่งเป็นสิ่งที่ทำกับ dense vector ไม่ได้ ใครที่เคยนั่งงงว่า “ทำไมเอกสารนี้ถึงถูกดึงมา” จะเข้าใจว่าคุณสมบัตินี้มีค่าแค่ไหนตอนขึ้น production

ข้อจำกัดที่ต้องพูดให้ตรงสำหรับผู้อ่านชาวไทยคือ มันเป็นโมเดลภาษาอังกฤษ และสถาปัตยกรรมแบบ vocabulary-based ยิ่งทำให้ย้ายข้ามภาษาได้ยากกว่า dense encoder เพราะมิติของเวกเตอร์ผูกกับ vocabulary ของ tokenizer โดยตรง ขณะที่ภาษาไทยไม่มีช่องว่างระหว่างคำและ tokenizer ของ ModernBERT ก็ไม่ได้ออกแบบมาเพื่อมัน การเอา SPARSEUP ไปใช้กับคลังเอกสารภาษาไทยตรง ๆ จะให้ผลแย่กว่าที่ตัวเลขบอกมาก

แต่ สูตรนั้นย้ายได้ และนี่คือคุณค่าที่แท้จริงของรีลีสแบบนี้ ทั้ง logit shift, per-position top-k และ vocabulary folding ไม่ผูกกับภาษา — สำหรับใครที่ทำ retrieval ภาษาไทยอยู่ (WangchanBERTa, typhoon embeddings หรือ backbone หลายภาษา) นี่คือสูตรที่อ่านได้ ทำซ้ำได้ และมีเบสไลน์ที่วัดแบบคุมตัวแปรไว้ให้เทียบแล้ว ผมอยากเห็นใครสักคนในไทยลองสูตรนี้กับ backbone ภาษาไทยมากกว่าจะเห็นคนเอา SPARSEUP ไปเสียบใช้ตรง ๆ แล้วสรุปว่า sparse retrieval ใช้กับภาษาไทยไม่ได้

แหล่งข่าว

• Linkup — Introducing SPARSEUP
• Hugging Face — Linkup-Platform/linkup-sparseup-embed-v1
• MarkTechPost — Linkup Research Releases SPARSEUP