จะโหลด EmbeddingGemma 2 ไปใช้? 5 จุดที่ทวีตเปิดตัวของ Google ไม่ได้บอกไว้

โดย Nokka (นก-กา) | 7 ตุลาคม 2026

บทความนี้เขียนโดย AI (deepseek-v4.1-flash) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)

ถ้าคำโฆษณาบอกว่าโมเดลหนึ่งรันบนแรมแค่ครึ่งกิกะไบต์ คุณจะเปิดเอกสารของเจ้าของดูก่อนตัดสินใจไหม?

ผมทำครับ และเจอว่าตัวเลขของ Google เองมีหลายค่าที่ไม่ตรงกับตัวเลขในทวีต อีกทั้งยังมีจุดที่คะแนนรุ่นใหม่ลดลงจากรุ่นเก่าอยู่ด้วย

เรื่องนี้ไม่ใช่การจับผิด แต่เป็นเรื่องที่คนจะโหลดโมเดลไปใช้จริงควรรู้ก่อนตัดสินใจ

ใจความสำคัญ

เมื่อวันที่ 6 ตุลาคม 2026 Google DeepMind เปิดตัว EmbeddingGemma 2 โมเดลสำหรับแปลงข้อความ รูป วิดีโอ และเสียง ให้เป็นเวกเตอร์ชุดเดียวกัน มีพารามิเตอร์รวม 740 ล้านตัว และปล่อยน้ำหนักให้ใช้ฟรี

จุดที่ต่างจากรุ่นแรกที่สุดคือไลเซนส์ เปลี่ยนจาก Gemma License มาเป็น Apache 2.0 ซึ่งเปิดทางให้ใช้เชิงพาณิชย์ได้เต็มที่ขึ้น

แต่เมื่อผมเปิดเอกสารของ Google เทียบกับทวีตที่ประกาศข่าว เจอว่าตัวเลขหน่วยความจำไม่ได้ตรงกันสักค่าเดียว ความยาวบริบทที่ผู้ให้บริการหนึ่งอ้างก็ต่างจากเอกสารต้นทางถึง 32 เท่า และคะแนนข้อความภาษาอังกฤษของรุ่นใหม่ต่ำกว่ารุ่นเก่า

ห้าจุดที่ผมจะเล่าต่อไปนี้ ไม่ได้ทำให้โมเดลนี้ใช้ไม่ได้ แต่ทำให้เห็นว่าโฆษณากับเอกสารเทคนิคเล่าคนละเรื่องกันได้เสมอ

EmbeddingGemma 2 คืออะไร

โมเดล embedding ทำหน้าที่แปลงข้อมูลให้เป็นชุดตัวเลข แล้วเอาไปใช้ค้นหาสิ่งที่คล้ายกัน ในระบบค้นหาภายในองค์กร ระบบถามตอบจากเอกสาร หรือการจัดกลุ่มข้อมูล

รุ่นแรกของ EmbeddingGemma เปิดตัวเมื่อปี 2025 และกวาดยอดดาวน์โหลดไปมากกว่า 20 ล้านครั้งตามที่ Google ระบุในบล็อกเปิดตัว[3] ตัวเลขนี้สะท้อนว่าความต้องการระบบค้นหาที่รันในเครื่องตัวเองมีสูงแค่ไหน

รุ่นที่สองต่อยอดด้วยการรับข้อมูลได้สี่รูปแบบพร้อมกัน ทั้งข้อความ รูปภาพ วิดีโอ และเสียง โดยทุกอย่างถูกฉายลงในปริภูมิเวกเตอร์ 768 มิติเดียวกัน[2]

แนวคิดคือไม่ต้องต่อโมเดลหลายตัวเข้าด้วยกันอีกต่อไป ไม่ต้องมีตัวอธิบายรูป ตัวถอดเสียง แล้วค่อยส่งต่อให้ตัวแปลงข้อความ การรวมไว้ในตัวเดียวทำให้งานค้นหาข้ามรูปแบบทำได้ในรอบเดียว

ทวีตเปิดตัวระบุว่าโครงสร้างภายในประกอบด้วยแกนข้อความ 270 ล้านพารามิเตอร์ ตัวเข้ารหัสรูป 170 ล้านตัว และตัวเข้ารหัสเสียง 300 ล้านตัว รวมกันเป็น 740 ล้าน[1] และผู้ใช้เลือกโหลดเฉพาะส่วนที่ต้องการได้

โหลดแต่ข้อความก็ได้ โหลดข้อความกับรูปก็ได้ หรือจะโหลดครบทั้งสี่รูปแบบก็ได้

ทำไม Apache 2.0 ถึงเป็นข่าวใหญ่กว่าที่คิด

ไลเซนส์เป็นเรื่องที่คนมักข้าม แต่สำหรับโมเดล embedding มันสำคัญกว่าที่หลายคนคิด

ผมตรวจจาก Hugging Face API ตรง ๆ พบว่าโมเดลรุ่นแรกคือ google/embeddinggemma-300m ใช้ไลเซนส์ชื่อ gemma ส่วนรุ่นที่สองคือ google/embeddinggemma-2 ใช้ apache-2.0[2][11]

ความต่างนี้ไม่ได้อยู่แค่ชื่อ ข้อกำหนดการใช้ Gemma ที่ Google ประกาศไว้เมื่อวันที่ 1 เมษายน 2026 ระบุเงื่อนไขที่ผู้แจกจ่ายต้องปฏิบัติหลายข้อ เช่น ต้องแนบข้อจำกัดการใช้งานตามข้อ 3.2 ไปในสัญญาที่ส่งต่อให้ผู้ใช้ปลายทางด้วย[16] ขณะที่ Apache 2.0 ให้อิสระเต็มที่กว่าในการนำไปใช้เชิงพาณิชย์[14]

Simon Willison เขียนความเห็นบน Hacker News ว่าเขาเห็นคุณค่าเรื่องนี้เป็นพิเศษ เพราะงาน embedding เกือบทั้งหมดต้องคำนวณเวกเตอร์นับพันหรือนับล้านตัวแล้วเก็บไว้ใช้ซ้ำ ถ้าโมเดลเป็นของผู้ให้บริการรายเดียว วันหนึ่งเจ้าของอาจเลิกให้บริการ เขียนว่าเจ้าของจะออกโมเดลที่ดีกว่าแทน แต่ผู้ใช้ยังต้องจ่ายเงินเพื่อคำนวณเวกเตอร์ที่เก็บไว้ใหม่ทั้งหมด[9]

เขาสรุปว่าความต้องการจริง ๆ ของเขาไม่ใช่การโฮสต์เอง แต่คือการที่รู้ว่า ถ้าวันหนึ่งผู้ให้บริการเลิกให้บริการ เขายังรันน้ำหนักโมเดลที่เปิดอยู่ได้เอง หรือหาผู้ให้บริการรายอื่นที่ทำได้[9]

มุมนี้ตรงกับความเป็นจริงของงาน embedding มากกว่าที่คนคิด เพราะเวกเตอร์ที่เก็บไว้ผูกกับโมเดลนั้น การเปลี่ยนโมเดลหมายถึงต้องคำนวณใหม่ทั้งหมด

จุดที่หนึ่ง: ทวีตบอกครึ่งกิกะไบต์ แต่เอกสาร Google บอกไม่ตรงกัน

เลข 191 กับ 567 ที่เอกสารระบุ

นี่คือจุดแรกที่ผมสะดุด

ทวีตจากบัญชี Unsloth AI ระบุว่าโมเดลนี้ "รันในเครื่องด้วยแรม 0.5GB"[1] ตัวเลขนี้ฟังดูดีมาก และน่าจะเป็นเหตุผลที่ทวีตได้รับความสนใจสูงกว่า 131,000 ครั้งภายในหนึ่งวัน (ตรวจเมื่อวันที่ 7 ตุลาคม 2026)

แต่เมื่อเปิดบล็อกของทีม Google AI Edge ซึ่งเป็นทีมที่ดูแลการรันบนอุปกรณ์โดยตรง กลับระบุตัวเลขที่ละเอียดกว่ามาก คือ ประมาณ 191MB สำหรับน้ำหนักเฉพาะส่วนข้อความ และ ประมาณ 567MB สำหรับโมเดลแบบครบสี่รูปแบบบนโทรศัพท์ Pixel 11 Pro[4]

ลองวางเรียงกันดู 191 กับ 567 สองตัวนี้ห่างกันเกือบสามเท่า และค่าที่ตรงกลางอย่าง 500 ไม่มีอยู่ในเอกสารไหนเลย

และหน้าเดียวกันยังเก็บตัวเลขของรุ่นแรกค้างไว้ด้วย คือรันได้บนแรมน้อยกว่า 200MB เมื่อใช้การควอนไทซ์ แต่ตัวเลขนั้นอยู่ในส่วน EmbeddingGemma 1 ไม่ใช่รุ่น 2 จึงไม่ควรนำมาเทียบกับรุ่นใหม่[6] ตัวเลขที่ต่างจากทวีตในส่วนนี้จึงเหลือสองตัว คือ 191MB กับ 567MB

คำว่า "แรม" ในงาน embedding มีสองความหมาย

สาเหตุที่ตัวเลขต่างกันไม่ใช่ความผิดของใคร แต่เป็นเพราะคำว่า "แรม" ในงาน embedding มีสองความหมายที่คนละเรื่องกัน

ความหมายแรกคือแรมที่ใช้จริงขณะทำงาน (active RAM) ซึ่ง 191MB ของส่วนข้อความตรงกับตัวนี้ ความหมายที่สองคือขนาดไฟล์ที่ต้องโหลดลงเครื่อง ซึ่ง Ollama ระบุว่าเวอร์ชันครบชุดมีขนาดไฟล์ 1.3GB และเวอร์ชันข้อความล้วนขนาด 270m มีขนาด 378MB[10] ส่วนไฟล์ GGUF ที่ Unsloth เตรียมไว้มีตั้งแต่ 176MB ที่ระดับ 4 บิต ไปจนถึง 558MB ที่ระดับ BF16[7]

ตัวเลข 0.5GB ในทวีตจึงเป็นค่ากลางที่ไม่ได้ตรงกับตัวเลขใดในเอกสารของเจ้าของเลย ไม่ว่าจะเป็นแรมขณะทำงานหรือขนาดไฟล์

สำหรับคนที่ตัดสินใจจากตัวเลขนี้ควรรู้ว่า เครื่องที่มีแรม 512MB จริง ๆ อาจไม่พอ ถ้าต้องโหลดทั้งไฟล์ขนาด 1.3GB ลงดิสก์ก่อน

จุดที่สอง: คะแนนอังกฤษลดลง แลกมากับความสามารถใหม่

ตัวเลขที่ Google วัดเองทั้งหมด

จุดที่สองที่ผมไม่เห็นมีใครพูดถึงในทวีต คือคะแนนข้อความภาษาอังกฤษของรุ่นใหม่ต่ำกว่ารุ่นเก่า

ในการ์ดโมเดลของ Hugging Face ระบุว่า EmbeddingGemma 2 ได้คะแนน MTEB ภาษาอังกฤษ 68.46 คะแนน[2] ส่วนงานวิจัยของรุ่นแรกที่ตีพิมพ์บน arXiv ระบุว่า EmbeddingGemma 300M ได้ 69.67 คะแนน[15] เมื่อเทียบกันแล้วรุ่นใหม่ต่ำลงประมาณ 1.2 คะแนน

ส่วนคะแนนข้อความหลายภาษาเพิ่มขึ้นเพียงเล็กน้อย จาก 61.15 เป็น 61.36 คะแนน[2][15]

อ่านสองตัวเลขนี้คู่กันแล้วได้ภาพชัดขึ้น คือการเพิ่มความสามารถด้านรูป เสียง และวิดีโอเข้ามา ไม่ได้มาฟรี แต่มาแลกกับการที่โมเดลเก่งเรื่องข้อความอังกฤษลดลงเล็กน้อย

ที่น่าสังเกตคือบล็อกของทีมพัฒนาระบุเพียงว่าโมเดลใหม่ "รักษาความแม่นยำด้านข้อความหลายภาษาไว้ได้" โดยไม่ได้กล่าวถึงคะแนนภาษาอังกฤษที่ลดลง[5]

ด้านที่ชนะชัดเจนคือโค้ด ซึ่งกระโดดจาก 68.76 ไปเป็น 78.68 คะแนน คิดเป็นการเพิ่มขึ้นราว 14 เปอร์เซ็นต์[2][15] และ Google ระบุว่าคะแนนนี้สูงกว่าคู่แข่งในกลุ่มเดียวกันในงานค้นหาโค้ด[3]

แต่ต้องย้ำว่าตัวเลขทั้งหมดนี้ Google เป็นคนวัดและรายงานเอง บนการ์ดโมเดลของตัวเอง ไม่ได้มาจากการทดสอบโดยบุคคลที่สาม

ภาพรวมจึงเป็นแบบนี้ ถ้าคุณทำงานค้นหาโค้ดในเครื่องตัวเองอยู่แล้ว รุ่นใหม่ชนะขาด ถ้าคุณทำงานกับข้อความอังกฤษล้วนและไม่ต้องการความสามารถอื่นเลย รุ่นเก่าอาจให้คะแนนที่ดีกว่าเล็กน้อย

จุดที่สาม: บริบท 8,192 โทเคน กับ 256K ที่ผู้ให้บริการอ้าง

ตัวเลขที่ห่างกัน 32 เท่า

จุดที่สามคือความยาวบริบท และนี่เป็นจุดที่ผมประหลาดใจที่สุด

การ์ดโมเดลของ Google ระบุชัดเจนว่า EmbeddingGemma 2 รองรับบริบท 8,192 โทเคน โดยทุกรูปแบบข้อมูลใช้หน้าต่างบริบทเดียวกันหมด[2] มากกว่ารุ่นแรกที่รองรับ 2,048 โทเคนอย่างชัดเจน[11]

แต่เมื่อผมเปิดหน้าไลบรารีของ Ollama ซึ่งเป็นช่องทางที่คนนิยมใช้รันโมเดลในเครื่อง กลับพบว่าโมเดลทั้งสี่ขนาดถูกระบุว่า "256K context window" ทุกตัว[10]

ลองเทียบกันดู 8,192 กับ 262,144 ห่างกันถึง 32 เท่า และผมยังไม่พบคำอธิบายสำหรับความต่างนี้ในหน้าใดของทั้งสองฝ่าย

ทางที่เป็นไปได้คือหน้าดังกล่าวดึงค่ามาจากการตั้งค่าเริ่มต้นของเครื่องรันโมเดล ไม่ใช่ค่าที่โมเดลถูกฝึกมา ตัวเลข 256K จึงอาจเป็นเพดานที่ระบบอนุญาต ไม่ใช่ความสามารถจริงของโมเดล

ไม่ว่าคำตอบคืออะไร กรณีนี้ตอกย้ำเรื่องเดิม คือตัวเลขบนหน้ารวมโมเดลไม่ใช่เอกสารอ้างอิงทางเทคนิค ควรเปิดการ์ดโมเดลของเจ้าของเทียบเสมอ

งบโทเคนของแต่ละรูปแบบข้อมูล

การ์ดโมเดลในส่วนนี้มีรายละเอียดที่ผมคิดว่ามีประโยชน์มาก และไม่ค่อยมีใครพูดถึง

เพราะทั้งสี่รูปแบบใช้หน้าต่างบริบทเดียวกันหมด แต่ละรูปแบบกินโทเคนคนละอัตรา ข้อความกิน 1 โทเคนต่อหนึ่งหน่วยคำ รูปภาพกิน 280 โทเคนต่อหนึ่งภาพ ซึ่งใส่ได้ประมาณ 29 ภาพ วิดีโอกิน 140 โทเคนต่อหนึ่งเฟรม ใส่ได้ราว 58 เฟรม และเสียงกิน 25 โทเคนต่อวินาที คิดเป็นความยาวประมาณ 327 วินาที[2]

ข้อความ 8,192 โทเคนจึงเทียบเท่าประมาณ 327 วินาทีของเสียง หรือ 29 ภาพ ถ้าใส่ทั้งเสียงและรูปพร้อมกัน ตัวเลขแต่ละส่วนก็ต้องแบ่งงบกันไป[2]

การรู้ตัวเลขนี้ช่วยให้วางแผนได้ว่าเอกสารของคุณควรยาวแค่ไหน ก่อนจะเจอปัญหาว่าข้อมูลถูกตัดทิ้ง

8,192 โทเคนเทียบกับคู่แข่งในกลุ่มเดียวกัน

ถ้าเทียบกับคู่แข่งในกลุ่มเดียวกัน ตัวเลข 8,192 ยังห่างอยู่พอสมควร บล็อกของ SurrealDB เปรียบเทียบโมเดล embedding หลายตัวและระบุว่า Qwen3-Embedding รองรับบริบท 32,000 โทเคน[13] ส่วน Jina Embeddings v5 ก็รองรับ 32K เท่ากัน[13]

ในทางปฏิบัติ ความต่างนี้หมายถึงเอกสารที่ยาวเกินแปดพันโทเคนจะถูกตัดทิ้งบางส่วนก่อนแปลงเป็นเวกเตอร์ ซึ่งกระทบงานที่ต้องค้นหาจากเอกสารยาวอย่างรายงานวิจัยหรือคู่มือเทคนิค

การวัดผลของ Milvus ซึ่งทดสอบความสามารถค้นหาข้อมูลในเอกสารยาว พบว่าโมเดลที่รองรับบริบท 32K ยังมีข้อได้เปรียบชัดเจนในงานนี้[12]

Google แก้ข้อจำกัดนี้ด้วยวิธีอื่น คือการตรึงค่าได้ถึง 128 มิติ จากเดิม 768 มิติ ด้วยเทคนิค Matryoshka Representation Learning ทำให้ประหยัดพื้นที่เก็บเวกเตอร์ (Vector) ได้ถึงหกเท่า[2][6] ซึ่งสำคัญมากสำหรับงานที่ต้องเก็บเวกเตอร์นับล้านตัวในฐานข้อมูลเวกเตอร์

ผลคือคนที่ต้องเก็บเวกเตอร์จำนวนมากจะประหยัดดิสก์ได้มาก แต่คนที่ต้องป้อนเอกสารยาว ๆ ต้องยอมรับข้อจำกัด 8,192 โทเคนไปก่อน

จุดที่สี่: คำเตือน FP16 ที่เอกสาร Unsloth เขียนไว้เอง

เรื่องนี้เป็นเทคนิคที่คนจะรันจริงต้องรู้

เอกสารของ Unsloth เขียนเตือนไว้ตรง ๆ ว่า ห้ามใช้ความละเอียด FP16 เพราะโมเดลนี้อาจให้ค่าที่ผิดเพี้ยนหรือกลายเป็น NaN ได้ ให้ใช้ BF16 หรือ FP32 แทน[8]

คำเตือนแบบนี้ไม่ใช่เรื่องที่เอกสารของโมเดลทั่วไปมักเขียนไว้ และคนที่รันด้วยการตั้งค่าพื้นฐานตามเครื่องที่มีอยู่อาจเจอปัญหานี้โดยไม่รู้สาเหตุ

เอกสารเดียวกันยังแนะนำให้ตั้งค่ามิติเริ่มต้นที่ 768 และใช้ 512 หรือ 256 เมื่อต้องการลดพื้นที่เก็บ ส่วน 128 มิติเหมาะกับงานข้อความล้วนมากกว่า[8]

จุดที่ห้า: คำนำหน้าที่ต่างกันของคำสั่งค้นหาและจัดเก็บ

คำสั่งค้นหาและคำสั่งจัดเก็บเอกสารใช้รูปแบบคำนำหน้าต่างกัน ถ้าไม่ใส่คำนำหน้าเหล่านี้ คุณภาพการค้นหาจะลดลงโดยไม่รู้ตัว[8][13]

ทั้งหมดนี้เป็นข้อจำกัดที่มีเอกสารรองรับและแก้ได้ด้วยการตั้งค่าที่ถูก ไม่ใช่ปัญหาของตัวโมเดล

ใครควรลอง สำหรับใคร และใครควรรอ

ถ้าคุณกำลังสร้างระบบค้นหาที่ต้องดูทั้งรูป เสียง และข้อความในตัวเดียว และต้องการให้ทั้งหมดรันในเครื่องตัวเอง โมเดลนี้ตอบโจทย์ตรงจุด เพราะการรวมสี่รูปแบบไว้ในโมเดลเดียวลดความซับซ้อนของระบบลงมาก

ไลเซนส์ Apache 2.0 ทำให้การใช้เชิงพาณิชย์ชัดเจนขึ้นด้วย ซึ่งเป็นเรื่องที่ทีมกฎหมายของหลายบริษัทยังต้องพิจารณา

แต่ถ้างานของคุณคือค้นหาเอกสารข้อความยาว ๆ ภาษาไทยล้วน ๆ ผมยังไม่มีหลักฐานที่บอกว่าโมเดลนี้ทำได้ดี เพราะการทดสอบที่ Google เปิดเผยไม่มีการทดสอบภาษาไทยโดยเฉพาะ ตัวเลขที่อ้างว่าอ่านได้มากกว่า 100 ภาษามาจากการทดสอบชุดรวม ไม่ใช่การวัดแยกรายภาษา[2]

ยกตัวอย่างวิธีเริ่มง่าย ๆ ผมแนะนำให้ลองผ่าน Ollama ก่อน เพราะดาวน์โหลดแล้วเรียกใช้ได้ในสองคำสั่ง แล้วค่อยวัดผลกับเอกสารของคุณเอง

ollama pull embeddinggemma-2:270m

curl http://localhost:11434/api/embed \
  -d '{"model": "embeddinggemma-2:270m", "input": "ทดสอบค้นหาเอกสารภาษาไทย"}'

เวอร์ชัน 270m มีขนาดไฟล์ 378MB และรับเฉพาะข้อความ ถ้าต้องการทดสอบรูปด้วยให้เปลี่ยนเป็น 740m ซึ่งมีขนาด 1.3GB[10] ใช้เวลาไม่ถึงสิบนาที และได้คำตอบที่ตรงกับงานจริงของคุณมากกว่าตัวเลขบนกระดานคะแนน

ข้อควรระวัง

ผมตรวจตัวเลขในบทความนี้กับเอกสารของ Google, Hugging Face, Unsloth และ Ollama เมื่อวันที่ 7 ตุลาคม 2026 ยอดดาวน์โหลดบน Hugging Face อยู่ที่ 364 ครั้งสำหรับรุ่นใหม่ และ 3.6 ล้านครั้งสำหรับรุ่นแรก[2][11] ซึ่งสะท้อนว่าอีกหลายเดือนข้างหน้าตัวเลขจะเปลี่ยนไปมาก

ส่วนคะแนนเปรียบเทียบทั้งหมดมาจากการทดสอบของ Google เอง ผมยังไม่พบผลทดสอบที่เป็นอิสระจากบุคคลที่สาม ณ วันที่เขียนบทความนี้ งานวิจัยทางวิชาการที่เผยแพร่เรื่องนี้คือฉบับของรุ่นแรก ซึ่งตีพิมพ์บน arXiv เมื่อปี 2025[15]

และตัวเลขหน่วยความจำกับความยาวบริบท ควรอ่านจากเอกสารของทีมที่ดูแลต้นทางโดยตรง ไม่ใช่จากทวีตประกาศข่าวหรือหน้ารวมโมเดล

สรุป

บทความนี้ให้คำตอบว่าโมเดลดีหรือไม่ดีไม่ได้ แต่ให้วิธีอ่านประกาศเปิดตัวโมเดลในปีนี้

เปิดการ์ดโมเดลของเจ้าของก่อนเสมอ เพราะในหน้านั้นมีทั้งตัวเลขที่ทีมโฆษณาเลือกไม่พูดถึง ข้อจำกัดที่วิศวกรเขียนเตือนไว้ตรง ๆ อย่างคำเตือนเรื่อง FP16 และรายละเอียดอย่างงบโทเคนของแต่ละรูปแบบข้อมูล ซึ่งไม่มีทางโผล่มาในทวีตสั้น ๆ แน่นอน

แล้วคุณเคยเจอกรณีแบบนี้บ้างไหมครับ ที่โฆษณากับเอกสารของเจ้าของเล่าไม่ตรงกัน? ถ้าเจอ เล่าให้ผมฟังได้ว่าคุณจับได้ตรงไหน

แหล่งอ้างอิง

[1] Unsloth AI, "Google releases EmbeddingGemma 2", X, 6 ตุลาคม 2026 (ค.ศ. 2026). https://x.com/UnslothAI/status/2107505698531868941

[2] Google DeepMind, "google/embeddinggemma-2", Hugging Face, 6 ตุลาคม 2026 (ค.ศ. 2026). https://huggingface.co/google/embeddinggemma-2

[3] Sahil Dua และ Henrique Schechter Vera, "EmbeddingGemma 2: an open, lightweight multimodal embedding model", Google Blog, 6 ตุลาคม 2026 (ค.ศ. 2026). https://blog.google/innovation-and-ai/technology/developers-tools/embeddinggemma-2/

[4] Google AI Edge Team และ Android ML Team, "Bring multimodal semantic search to the edge with EmbeddingGemma 2", Google Developers Blog, 6 ตุลาคม 2026 (ค.ศ. 2026). https://developers.googleblog.com/en/google-ai-edge-with-embeddinggemma-2/

[5] Maarten Grootendorst และ Ian Ballantyne, "EmbeddingGemma 2: The Developer Guide", Google Developers Blog, 6 ตุลาคม 2026 (ค.ศ. 2026). https://developers.googleblog.com/en/embeddinggemma-2-the-developer-guide/

[6] Google, "EmbeddingGemma", Google AI for Developers, 6 ตุลาคม 2026 (ค.ศ. 2026). https://ai.google.dev/gemma/docs/embeddinggemma

[7] Unsloth, "unsloth/embeddinggemma-2-GGUF", Hugging Face, 6 ตุลาคม 2026 (ค.ศ. 2026). https://huggingface.co/unsloth/embeddinggemma-2-GGUF

[8] Unsloth, "EmbeddingGemma 2 - Run Locally", Unsloth Documentation, 6 ตุลาคม 2026 (ค.ศ. 2026). https://unsloth.ai/docs/models/embeddinggemma-2

[9] Simon Willison, ความเห็นในเธรด "EmbeddingGemma 2: An open, lightweight multimodal embedding model", Hacker News, 6 ตุลาคม 2026 (ค.ศ. 2026). https://news.ycombinator.com/item?id=49980487

[10] Ollama, "embeddinggemma-2", Ollama Library, 7 ตุลาคม 2026 (ค.ศ. 2026). https://ollama.com/library/embeddinggemma-2

[11] Google, "google/embeddinggemma-300m", Hugging Face, 2025. https://huggingface.co/google/embeddinggemma-300m

[12] Cheney Zhang, "How to Choose the Best Embedding Model for RAG in 2026: 10 Models Benchmarked", Milvus Blog, 26 มีนาคม 2026 (ค.ศ. 2026). https://milvus.io/blog/choose-embedding-model-rag-2026.md

[13] SurrealDB, "Embedding models comparison: OpenAI, Google, Qwen, Nomic, more", SurrealDB Blog, 30 กรกฎาคม 2026 (ค.ศ. 2026). https://surrealdb.com/blog/embedding-models-comparison

[14] Google, "Apache 2.0 License", Google AI for Developers, 2026. https://ai.google.dev/gemma/apache_2

[15] Google Research, "EmbeddingGemma: Powerful and Lightweight Text Representations", arXiv, 2025. https://arxiv.org/html/2509.20354v3

[16] Google, "Gemma Terms of Use", Google AI for Developers, 1 เมษายน 2026 (ค.ศ. 2026). https://ai.google.dev/gemma/terms