GLiNER2.5 เลิกไล่นับ span แล้วหันไปทำนายหัวท้ายแทน — โมเดลสกัดข้อมูล 74M–287M พารามิเตอร์ Apache-2.0 ที่รันบน CPU อ่านเอกสาร 4,096 คำในครั้งเดียว

ในยุคที่ทุกปัญหาถูกโยนให้ LLM ตัวใหญ่แก้ งานสกัดข้อมูลจากเอกสาร (information extraction) เป็นหนึ่งในไม่กี่งานที่ยังมีคำตอบที่ดีกว่าและถูกกว่ามาก — โมเดล encoder ขนาดไม่กี่ร้อยล้านพารามิเตอร์ที่รันบน CPU ได้ ตอบเป็น JSON ที่ถูกโครงสร้างเสมอ และไม่ต้องเสียเงินต่อโทเคน ตระกูล GLiNER คือหัวหอกของแนวทางนี้มาตั้งแต่ปี 2024

24 สิงหาคม 2026 Fastino ปล่อย GLiNER2.5 พร้อมไลบรารี gliner2 v2.0.0 บน GitHub (Apache-2.0, ~1,790 ดาว) และสามเช็กพอยต์บน Hugging Face โดยสิ่งที่เปลี่ยนไม่ใช่แค่ตัวเลขเบนช์มาร์ก แต่เป็นสถาปัตยกรรมชั้นในทั้งชั้น — และการเปลี่ยนนั้นแก้ข้อจำกัดที่ผู้ใช้ GLiNER ต้องเขียนโค้ดอ้อมมาตลอดสองปี

จาก “ไล่นับทุก span” ไปเป็น “ทำนายหัวกับท้าย”

GLiNER รุ่นเดิมทำงานด้วยการ enumerate span: สร้างผู้สมัครทุกช่วงข้อความที่ยาวไม่เกินเพดานหนึ่ง (ปกติราว 12 คำ) แล้วให้คะแนนทีละอัน วิธีนี้ตรงไปตรงมา แต่มีผลข้างเคียงสองอย่างที่หนักกว่าที่คิด

อย่างแรกคือ เพดานความยาว entity ที่ยาวเกินเพดานไม่ได้ถูกให้คะแนนต่ำ — มันไม่เคยถูกให้คะแนนเลย บล็อกของ Fastino เขียนไว้ตรง ๆ ว่า “The model did not score it poorly; it never scored it at all.” ผลคือที่อยู่เต็มรูปแบบ, ข้อสัญญาความยาวหนึ่งวรรค, ชื่อสินค้าฉบับเต็ม ล้วนมองไม่เห็นในเชิงโครงสร้าง ทางแก้เดิมคือดันเพดานขึ้น ซึ่งแลกมาด้วยคอมพิวต์ที่โตตาม หรือสกัดเป็นชิ้น ๆ แล้วมาต่อเองทีหลัง

อย่างที่สองคือ หน่วยความจำ การเก็บ representation ของทุก span ทำให้เทรนบนลำดับยาว ๆ ไม่ไหว

GLiNER2.5 เปลี่ยนไปใช้ boundary prediction — ให้คะแนนว่า entity เริ่มตรงไหน และ จบตรงไหน แล้วจับคู่หัวท้ายแบบ sparse แทนการไล่กริดความยาว ผลตามมาเป็นลูกโซ่:

• ไม่มีแกนความยาวในสมการอีกต่อไป — clause ยาว 40 คำ มีต้นทุนเท่ากับชื่อคน 2 คำ และไม่ต้องตั้งค่าอะไรเลย
• inference โตเป็นเส้นตรงตามความยาวเอกสาร แทนที่จะโตตามจำนวน span
• หน่วยความจำที่ประหยัดได้จากการทิ้ง span representation ถูกเอาไปแลกเป็นการเทรนบนลำดับยาวถึง 4,096 คำ ซึ่งครอบคลุมสัญญา รายงาน และ transcript ส่วนใหญ่ในการ forward ครั้งเดียว โดยไม่ต้อง chunk

และสำหรับเอกสารที่ยาวกว่านั้น ไลบรารี v2.0.0 เพิ่ม chunking แบบเนทีฟ ทุก task มีตัวแปร long-document พร้อม batch — ตัดเอกสารเป็น chunk ที่ซ้อนกัน สกัดทีละ chunk แล้ว remap ทุก span กลับเป็น character offset ของเอกสารต้นฉบับ พร้อมรวมของซ้ำตาม policy ที่กำหนดได้ ของเดิมผู้ใช้ต้องเขียน remap offset และจัดการ span ซ้ำข้าม chunk เอง

สามเช็กพอยต์ Apache-2.0 ทั้งหมด และตัวเล็กสุด 74M

เช็กพอยต์	พารามิเตอร์	Encoder	ภาษา
fastino/gliner2.5-small-v1	74M	DeBERTa-v3-xsmall	อังกฤษ
fastino/gliner2.5-base-v1	194M	DeBERTa-v3-base	อังกฤษ
fastino/gliner2.5-multi-v1	287M	mDeBERTa-v3-base	หลายภาษา

ทั้งสามตัวเป็น Apache-2.0 ใช้ public API เดียวกัน และรันในเครื่องได้ผ่าน pip install "gliner2[local]" (ต้อง Python 3.10+) รองรับ CPU, CUDA และ MPS — ไม่ต้องเรียก API ภายนอก ข้อควรระวังเล็ก ๆ คือรุ่น 2.5 ต้องโหลดด้วย AutoExtractor ไม่ใช่ GLiNER2.from_pretrained(...) แบบเดิม เพราะตัวหลังเป็น loader ของสถาปัตยกรรม span เก่า

ที่ควรพูดตรง ๆ: ณ ตอนนี้ยังไม่มี inference provider เจ้าไหนโฮสต์เช็กพอยต์ชุดนี้ให้ ต้อง self-host เอง — ซึ่งสำหรับโมเดลขนาดนี้ไม่ใช่ปัญหา แต่ก็ไม่ใช่ “เรียกใช้ได้ทันทีจากคลาวด์”

เบนช์มาร์ก: ได้ความสามารถใหม่โดยไม่เสียของเดิม

Fastino วัดแบบ zero-shot บน 16 ชุดข้อมูลสาธารณะ ครอบคลุมทั้งฝั่ง classification (sentiment, topic, intent, NLI) และฝั่ง extraction (NER ทั่วไป, เฉพาะโดเมน, หลายภาษา) เทียบกับ GLiNER2 ที่ขนาดโมเดลเท่ากัน ตัวเลข macro F1 ที่รายงานไว้:

• ค่าเฉลี่ยรวม 16 ชุด — Multilingual 56.17 (GLiNER2: 56.09), Base 54.87 (GLiNER2: 53.34)
• XNLI (natural language inference) — Multilingual 62.30 เทียบกับ 37.55 คือกระโดดเกือบ 25 จุด; Base 54.49 จาก 49.01
• Few-NERD (NER ทั่วไป) — Base 55.14 จาก 47.22; Multilingual 52.37 จาก 51.49
• RONEC (NER ภาษาโรมาเนีย ซึ่งไม่ได้อยู่ในภาษาเป้าหมายตอนเทรน) — Multilingual 40.13 จาก 38.86; Base 37.01 จาก 31.55

อ่านตัวเลขชุดนี้ให้ถูกต้องคือ: ค่าเฉลี่ยรวมของรุ่น Multilingual ขยับแค่ 0.08 จุด ซึ่งแทบไม่ต่าง ประเด็นของ Fastino ไม่ใช่ “เก่งขึ้นถล่มทลาย” แต่คือ เพิ่มหัว joint relation extraction และ constrained classification เข้าไป โดยคุณภาพการสกัดพื้นฐานไม่ถอย — ส่วนที่ขยับจริงจังคือ NLI และ NER ของรุ่น Base

อีกความเปลี่ยนแปลงที่ Fastino ยกเป็นเหตุผลของผลลัพธ์คือ ข้อมูลเทรนถูกสร้างด้วย Fastino Data Agent แทนการประกอบจากชุดข้อมูลสาธารณะ — ซึ่งเป็นคำอ้างที่ตรวจสอบจากภายนอกไม่ได้ ต่างจากตัวเลขเบนช์มาร์กที่มี per-dataset score ให้ดู

ห้าความสามารถใหม่ที่แปลเป็นโค้ดที่หายไป

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

1. Long-context extraction — สัญญา 300 หน้าไม่ต้องตัดเหลือเฉพาะหน้าต้น
2. Unlimited span length — clause ทั้งวรรคเป็น entity เดียวได้
3. Joint IE — ประกาศ entity type, relation แบบมี type และกฎเชิงโครงสร้าง (เช่น unique_head=True) ในสคีมาเดียว แล้วผลลัพธ์ การันตีว่าตรงตามกฎ ทุก relation ชี้ไปยัง entity ที่มีอยู่จริงในผลลัพธ์ ไม่มี dangling reference ไม่มีวงจรใน relation ที่ควรเป็นต้นไม้ — งานที่เดิมต้องเขียน filter หลังบ้านทุกครั้งก่อนยัดเข้า knowledge graph
4. Constrained classification — เอาต์พุตถูกต้องโดยโครงสร้าง เช่น guardrail ที่ตัดสิน “ปลอดภัย/ไม่ปลอดภัย” กับ “ประเภทความเสี่ยง” พร้อมกันภายใต้กฎเดียวกัน จนคำตอบที่ขัดแย้งกันเองเป็นไปไม่ได้
5. Span attributes — ติด attribute เช่น negation status หรือ sentiment ให้แต่ละ span ใน forward pass เดียว แทนการวนกลับไปจำแนกซ้ำรอบสอง

มุมมอง AI Curator

ผมคิดว่ารีลีสนี้ควรอ่านเป็น ข้อโต้แย้งต่อ default ของยุคนี้ มากกว่าเป็นข่าวโมเดลใหม่

default ปัจจุบันคือ: มีงานสกัดข้อมูล → เขียน prompt → เรียก LLM → ขอ JSON → เขียน validator กันมันตอบเพี้ยน → จ่ายต่อโทเคน → รับ latency หลักวินาที ทางเลือกที่ GLiNER2.5 เสนอคือ: โมเดล 194M รันบน CPU ในเครื่องคุณ ตอบเป็นโครงสร้างที่ถูกโดยการก่อสร้าง ไม่ใช่ถูกเพราะโชคดี และไม่มีค่าใช้จ่ายต่อครั้ง

จุดที่ผมคิดว่าคนมองข้ามคือคำว่า guaranteed ใน joint decoding นั้นมีน้ำหนักจริง เมื่อคุณสร้าง knowledge graph สำหรับ agent memory — ซึ่งกำลังเป็นแพตเทิร์นยอดนิยม — คุณภาพของกราฟถูกกำหนดโดย edge ที่แย่ที่สุด ไม่ใช่ค่าเฉลี่ย การให้ LLM สกัด triple ทีละอันแล้วมาเช็กความสอดคล้องทีหลัง คือการย้ายภาระไปไว้ในโค้ดที่ไม่มีใครอยากดูแล การ decode ทั้งกราฟพร้อมกันภายใต้สคีมาย้ายภาระนั้นกลับเข้าไปในโมเดล นี่คือความต่างเชิงวิศวกรรม ไม่ใช่แค่ความสะดวก

ในบริบทไทยและ SEA ผมเห็นสองประเด็นที่ตรงมาก ประเด็นแรกคือ PDPA และข้อมูลที่ห้ามออกนอกองค์กร งานอย่างการหา PII เพื่อ redact, การสกัดข้อมูลจากเวชระเบียน, การอ่านสัญญา — ล้วนเป็นงานที่การส่งข้อมูลขึ้นคลาวด์ต่างประเทศเป็นปัญหาเชิงกฎหมายก่อนจะเป็นปัญหาเชิงเทคนิค โมเดล 287M ที่รันบนเซิร์ฟเวอร์ CPU ในองค์กรและมีใบอนุญาต Apache-2.0 คือคำตอบที่ตรงกับข้อจำกัดนั้นพอดี

ประเด็นที่สองคือภาษาไทย — และตรงนี้ต้องพูดตรง ๆ ว่าบล็อกของ Fastino ไม่ได้รายงานผลภาษาไทย ชุดข้อมูลหลายภาษาที่ยกมาคือ XNLI และ RONEC (โรมาเนีย) สิ่งที่พอเป็นสัญญาณคือ RONEC เป็นภาษาที่ไม่ได้อยู่ในเป้าหมายตอนเทรนแต่ยังทำได้ 40.13 F1 ซึ่งบอกว่าโมเดลนี้ generalize ข้ามภาษาได้ระดับหนึ่ง แต่ไทยมีปัญหาเฉพาะตัวที่ภาษายุโรปไม่มี — ไม่มีช่องว่างระหว่างคำ ทำให้ boundary prediction ซึ่งทำงานบนตำแหน่งเริ่ม-จบ อาจเจอโจทย์ที่ต่างออกไปพอสมควร ใครจะเอาไปใช้ ควรวัดกับข้อมูลตัวเองก่อน อย่าเชื่อค่าเฉลี่ย 16 ชุดข้อมูล และคำว่า “4,096 words” ก็ต้องระวัง เพราะการนับหน่วยของข้อความไทยไม่เหมือนภาษาที่ตัดคำด้วยช่องว่าง

สุดท้าย ข้อสังเกตเชิงกลยุทธ์: Fastino ปล่อยน้ำหนักฟรีแบบ Apache-2.0 แต่ขายบริการ fine-tune และ deploy นี่คือโมเดลธุรกิจแบบเดียวกับที่ทำให้ตระกูล GLiNER เดิมมียอดดาวน์โหลดหลักแสนต่อเดือน — และเป็นรูปแบบที่ดีต่อนักพัฒนา ตราบใดที่เช็กพอยต์ฐานยังเปิดจริงและใช้ในเชิงพาณิชย์ได้จริง ซึ่งตอนนี้ยังเป็นเช่นนั้น

แหล่งข่าว

• Introducing GLiNER2.5: Efficient Span-Free Information Extraction with Schema-Driven Interface — Fastino, 24 ส.ค. 2026
• fastino-ai/GLiNER2 v2.0.0 — GitHub release, 24 ส.ค. 2026 (Apache-2.0)
• fastino/gliner2.5-multi-v1 — โมเดลการ์ดพร้อมตัวอย่างโค้ด บน Hugging Face
• GLiNER2: An Efficient Multi-Task Information Extraction System — เปเปอร์ของรุ่นก่อนหน้า ใช้อ่านประกอบเพื่อเทียบสถาปัตยกรรม