Lattice: โมเดล retrieval ขนาด 7.94 MB ที่ฝัง Wikipedia อังกฤษทั้ง 6.4 ล้านบทความบน MacBook Air ได้ใน 7 นาที

Erik Kaunismäki เผยแพร่ Lattice เมื่อ 7 สิงหาคม 2026 — โมเดล retrieval ภาษาอังกฤษที่จงใจย้อนศรกระแสทั้งหมดของวงการ embedding ปัจจุบัน คือ ไม่มี transformer อยู่ในนั้นเลย สถาปัตยกรรมทั้งหมดคือตาราง embedding ขนาด 30,522 × 1,024 หนึ่งตาราง การเข้ารหัสข้อความคือ “เปิดตารางหาเวกเตอร์ของแต่ละโทเคน แล้วเฉลี่ย” จบ

ผลลัพธ์คือโมเดลที่บีบเหลือ 7.94 MB ในเวอร์ชัน int4 และวิ่งได้ 9.52 ล้านโทเคนต่อวินาทีบน CPU — เร็วพอที่จะฝัง Wikipedia ภาษาอังกฤษทั้ง 6.4 ล้านบทความจบใน 7 นาที 26 วินาที บน MacBook Air M2 โดยไม่ต้องแตะ GPU สักตัว

ตัวเลขที่ทำให้เรื่องนี้ไม่ใช่แค่ของเล่น

ของแบบนี้จะน่าสนใจก็ต่อเมื่อคุณภาพไม่พังลงเหว และตรงนี้คือจุดที่ Lattice เอาตัวรอดได้

• เทรนบนคู่ query/document ที่คัดแล้วราว 660 ล้านคู่
• ได้ 0.4749 NDCG@10 บน BEIR 12 งานที่ decontaminate แล้ว
• เวอร์ชัน quantize ที่ 7.94 MB ได้ 0.4697 NDCG@10 — คุณภาพหล่นไปราว 1% แลกกับขนาดที่เล็กลงจาก 125 MB

จุดสำคัญคือการที่ผู้เขียนใช้ BEIR แบบ decontaminated ซึ่งเข้มกว่าตัวเลขที่หลายโมเดลชอบรายงาน — ตัวเลขนี้ไม่ได้ไล่ทัน embedding model ระดับบนที่ใช้ transformer เต็มตัว และผู้เขียนก็ไม่ได้อ้างแบบนั้น เขาวางตำแหน่งมันไว้ตรงจุดที่มันเก่งจริง: first-stage retriever ที่กะทัดรัดและเร็วมหาศาล สำหรับกรองผู้สมัครก่อนส่งต่อให้ reranker หรือสำหรับขุด/จัดกลุ่มคลังข้อมูลขนาดมหึมาที่แต่ก่อนต้องใช้คลัสเตอร์ GPU

ปล่อยของครบทั้งสายพาน ไม่ใช่แค่ weights

repo ErikKaum/lattice ปล่อยภายใต้ MIT และให้มาครบทั้งสายการผลิต ไม่ใช่แค่ไฟล์น้ำหนัก

• ไปป์ไลน์ preprocessing และเทรนระดับใหญ่ เขียนด้วย Rust
• ตัว slicer/quantizer หลังเทรน เขียนด้วย Python
• runtime สำหรับ inference ที่เป็น Rust ล้วน
• เอกสารวิธี eval และผลลัพธ์

runtime ที่เป็น Rust ล้วนคือส่วนที่มีค่าที่สุดในทางปฏิบัติ เพราะมันแปลว่า retrieval ตัวนี้ยัดลงไปได้ในที่ที่ Python stack เข้าไม่ถึง — CLI tool, service ขนาดเล็ก, แอปเดสก์ท็อป, edge device, หรือ WASM ในเบราว์เซอร์ โดยไม่ต้องลาก PyTorch หรือ ONNX runtime ไปด้วย

มุมมอง AI Curator

Lattice น่าสนใจในฐานะการเตือนความจำมากกว่าในฐานะโมเดล — ว่า ต้นทุนส่วนใหญ่ในระบบ RAG ที่เราสร้างกันทุกวันนี้ ไม่ได้จ่ายไปกับคุณภาพ แต่จ่ายไปกับความสะดวก ทีมส่วนใหญ่เริ่มโปรเจกต์ด้วยการเรียก embedding API ต่อบรรทัด จ่ายเงินและเวลารอเน็ตต่อเอกสารหนึ่งชิ้น ทั้งที่งานจริงในขั้นแรกคือแค่ “ตัดเอกสาร 10 ล้านชิ้นให้เหลือ 100 ชิ้น” ซึ่งไม่ต้องการความละเอียดระดับ transformer เลย ตัวเลข 6.4 ล้านบทความใน 7 นาทีบนแล็ปท็อปคือการบอกว่าขั้นตอนนั้นควรมีต้นทุนใกล้ศูนย์ และสถาปัตยกรรมที่ถูกคือ static retriever กรองหยาบ + reranker ที่แพงกว่าทำงานเฉพาะบนผู้รอดชีวิต

สำหรับทีมไทยมีทั้งข่าวดีและข้อจำกัดที่ต้องพูดให้ชัด ข้อจำกัดก่อน: Lattice เป็นโมเดล ภาษาอังกฤษ และ vocab 30,522 คือขนาดของ BERT-base ดั้งเดิม ซึ่งแปลว่าใช้กับข้อความไทยตรง ๆ ไม่ได้ผล — อย่าเพิ่งเอาไปเสียบแทน embedding ที่ใช้อยู่แล้วคาดหวังว่าจะรอด แต่ข่าวดีที่ใหญ่กว่าคือ สูตรทั้งสูตรถูกปล่อยมาใต้ MIT ตั้งแต่ pipeline เทรนยัน quantizer และสถาปัตยกรรมแบบตารางค้นหานี้ไม่ต้องใช้ GPU ระดับแล็บชั้นนำในการเทรนซ้ำ — งบประมาณระดับที่มหาวิทยาลัยไทยหรือทีม 3-4 คนหาได้จริงเพียงพอที่จะสร้าง “Lattice ภาษาไทย” ขึ้นมาเอง ถ้ามีคู่ query/document ภาษาไทยที่ดีพอ ที่จริงภาษาไทยยิ่งได้ประโยชน์จากแนวทางนี้มากกว่าอังกฤษด้วยซ้ำ เพราะปัญหาการตัดคำทำให้ค่า inference ต่อเอกสารของเราแพงกว่าปกติอยู่แล้ว การมี first-stage ที่ราคาเกือบศูนย์จึงคุ้มกว่า นี่เป็นโจทย์ open-source ไทยที่ขอบเขตชัด ทำเสร็จได้จริง และมีคนใช้แน่นอน — น่าทำกว่าการไล่เทรน LLM ตัวใหม่แข่งกันอีกตัวหนึ่งมาก

แหล่งข่าว

• Hugging Face Blog — Lattice: an 8 MB static retriever that embeds Wikipedia in 7 minutes (7 ส.ค. 2026)
• GitHub — ErikKaum/lattice