ฝึกฝน AI ให้วาดภาพสีน้ำ ด้วย TRL และ OpenEnv

เคยเห็นภาพวาดสีน้ำสวยๆ ที่สร้างสรรค์โดย AI ไหมครับ? เมื่อไม่นานมานี้ ได้มีวิดีโอที่แสดงผลงานสีน้ำที่สร้างโดยโมเดลภาษา ซึ่งเขียนโค้ด JavaScript ผ่านไลบรารี p5.brush ที่ช่วยเพิ่มเครื่องมือวาดภาพธรรมชาติให้กับ p5.js วิดีโอนี้ได้รับความสนใจอย่างรวดเร็ว มียอดวิวสูงถึง 1.5 ล้านวิว!

เบื้องหลังความน่าทึ่งนี้ คือการฝึกฝนโมเดลให้สร้างสรรค์ผลงานศิลปะ โดยมีเป้าหมายที่จะทำให้การพัฒนา AI เป็นไปอย่างเปิดกว้างและเข้าถึงได้ ผ่านการใช้ Open Source และ Open Science บทความนี้จะพาไปทำความเข้าใจเบื้องหลังการสร้างสรรค์ผลงานดังกล่าว โดยใช้เครื่องมืออย่าง TRL (Transformer Reinforcement Learning) และ OpenEnv

แรงบันดาลใจจากศิลปะสู่โค้ด

ไอเดียตั้งต้นมาจากฝั่งศิลปะและการออกแบบ ที่ต้องการสร้างสรรค์ผลงานที่ดูเป็นธรรมชาติ ไม่สมบูรณ์แบบเหมือนภาพที่ AI สร้างขึ้นทั่วไป แต่ให้ความรู้สึกเหมือนภาพวาดด้วยมือ ซึ่งความไม่สมบูรณ์แบบนี้เองที่เป็นเสน่ห์ดึงดูดใจ ทำให้ผู้คนสนใจในผลงานที่แตกต่างนี้

โมเดล AI ไม่ได้เพียงแค่สร้างภาพ แต่เป็นการเขียนโปรแกรม JavaScript ประมาณ 150 บรรทัด เพื่อสั่งให้เกิดการวาดภาพนั้นๆ ผลลัพธ์ที่ได้คือ "โค้ด" ที่เราสามารถอ่าน ทำความเข้าใจ แก้ไข และรันใหม่ได้ การตัดสินใจในแต่ละฝีแปรงจะปรากฏให้เห็นอย่างชัดเจน และสไตล์ของภาพสีน้ำก็มาจากข้อจำกัดในการใช้เมธอดเพียง 10 อย่าง จากไลบรารี p5.brush เท่านั้น

TRL และ OpenEnv: เครื่องมือสู่การสร้างสรรค์

บทความนี้จะพาไปเจาะลึกถึงการนำ TRL และ OpenEnv มาใช้เพื่อจำลองแนวคิดนี้ให้เป็นจริง โดยทุกชิ้นส่วน ตั้งแต่ชุดข้อมูลอ้างอิง (reference pool dataset), สภาพแวดล้อม RL (RL environment), สคริปต์การฝึกฝน (training scripts) ไปจนถึงโมเดลที่ฝึกฝนแล้ว (trained models) ล้วนถูกเปิดเผยเป็น Open Source

กระบวนการทั้งหมดสามารถทำงานได้บน Hugging Face ตั้งแต่ต้นจนจบ:

• สภาพแวดล้อม RL และโมเดลประเมินผล (scorer model): จัดการผ่าน Hugging Face Spaces
• การเปรียบเทียบแบบคู่ (pairwise judge): ผ่าน Inference Providers
• สิ่งประดิษฐ์ทั้งหมด (artifacts): รวบรวมไว้บน Hugging Face Hub ในคอลเลกชันเดียว

เมื่อ Spaces ทั้งสองพร้อมใช้งาน การสร้างสรรค์ก็ง่ายเพียงแค่รันคำสั่งเดียว โดยการจำลองสภาพแวดล้อมและโมเดลประเมินผล ตั้งค่าตัวแปรสภาพแวดล้อมสำหรับการผสมผสานรางวัล (reward mix) แล้วเริ่มการทำงาน

การสร้างสภาพแวดล้อม RL ที่จำเป็น 🛠️

สภาพแวดล้อมนี้จะทำหน้าที่ห่อหุ้มทุกอย่างที่อยู่ระหว่างโมเดลและฟังก์ชันรางวัล (reward function) ซึ่งรวมถึง:

• ไลบรารี JavaScript สำหรับการวาดภาพ: p5.brush ซึ่งจำลองคุณสมบัติของสีน้ำ เช่น การไหลของเม็ดสี, พื้นผิวของกระดาษ, น้ำหนักของฝีแปรง
• System Prompt: กำหนดข้อจำกัดให้กับโมเดล
• Headless Chromium: ใช้สำหรับเรนเดอร์ภาพร่างแต่ละภาพ
• Gate: ตรวจสอบความถูกต้องและป้องกันการโกง

ไลบรารี p5.brush มีเมธอดถึง 47 อย่าง แต่ Prompt ที่ใช้จะจำกัดให้โมเดลใช้เพียง 10 อย่าง เช่น scaleBrushes, noStroke, fill, fillBleed, circle เป็นต้น การจำกัดนี้ช่วยให้โมเดลสร้างภาพที่ดูเหมือนสีน้ำมากขึ้น โดยเฉพาะเมื่อใช้เมธอด fillBleed ที่ควบคุมการไหลของหมึก

Pool: ฟังก์ชันรางวัลเพื่อรสชาติศิลปะ 🎨

Pool นี้ประกอบด้วยภาพวาดที่สร้างโดยโมเดล AI จำนวน 178 ภาพ ซึ่งแบ่งออกเป็น 2 ระดับตามความชอบส่วนตัวของผู้สร้างสรรค์ ได้แก่ "love" และ "okay" ภาพเหล่านี้สร้างขึ้นจากโมเดล Open Weight 4 ตัว โดยใช้ p5.brush sketch และอ้างอิงจากภาพถ่ายดอกชบาที่ได้รับอนุญาตให้ใช้งานได้อย่างเปิดเผย

โมเดล Vision จะให้ข้อเสนอแนะที่เป็นลายลักษณ์อักษรสำหรับแต่ละ sketch และผ่านการปรับปรุง 3 รอบ สุดท้าย ภาพที่เสร็จสมบูรณ์จะถูกให้คะแนนทีละภาพ และ 178 ภาพนี้คือภาพที่ผ่านเกณฑ์

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

การเปรียบเทียบโมเดลประเมินผล 📊

มีโมเดลประเมินผล 2 ตัวที่ทำงานแตกต่างกัน:

1. HPSv3: เป็น Preference Model ขนาด 7B ที่ให้คะแนนว่าคนทั่วไปจะชอบภาพนั้นมากน้อยเพียงใด โดยฝึกฝนจากชุดข้อมูลการเลือกภาพจำนวนมาก
2. Pairwise Judge (Qwen3-VL-30B-A3B-Instruct): เป็นโมเดล Vision ทั่วไปที่เปรียบเทียบภาพที่สร้างขึ้นกับภาพอ้างอิง 4 ภาพจาก Pool และให้คะแนนตามสัดส่วนการชนะการเปรียบเทียบ

ผู้สร้างสรรค์ได้ทดลองฝึกฝน 3 รัน โดยแตกต่างกันที่น้ำหนัก (weight) ที่แบ่งให้กับโมเดลประเมินผลทั้งสองตัว:

• hps-only: ใช้ HPSv3 เพียงอย่างเดียว เพื่อทดสอบว่าไปป์ไลน์สามารถเรียนรู้ได้หรือไม่
• hps + judge (w=0.5): ผสมผสาน HPSv3 และ Pairwise Judge ด้วยน้ำหนักเท่ากัน
• hps + judge (w=0.2): ผสมผสาน HPSv3 และ Pairwise Judge โดย Pairwise Judge มีน้ำหนักน้อยกว่า

ผลการทดลองแสดงให้เห็นว่า Pool ที่สร้างขึ้นด้วยมือสามารถชี้นำนโยบาย (policy) ของโมเดลได้

ข้อควรระวังในการฝึกฝน ⚠️

• การขาดภาพวาดที่มนุษย์สร้างสรรค์: Pool ที่ใช้ส่วนใหญ่เป็นภาพที่สร้างโดย AI ซึ่งเป็นข้อจำกัด เนื่องจากภาพวาดสีน้ำที่ใช้ p5.brush และมีโค้ดให้ศึกษาได้นั้นมีจำนวนจำกัด
• การปรับพารามิเตอร์ LoRA: การตั้งค่า target_modules สำหรับโมเดลประเภท Mixture of Experts (MoE) เช่น Qwen/Qwen3.5-35B-A3B ต้องได้รับการปรับอย่างระมัดระวัง เพื่อให้ Adapter สามารถฝึกฝนกับทุก Layer ที่เกี่ยวข้องได้

สรุป

การฝึกฝนโมเดล AI ให้วาดภาพสีน้ำด้วย TRL และ OpenEnv เป็นตัวอย่างที่น่าสนใจของการนำเทคนิค Reinforcement Learning มาใช้กับความชอบทางศิลปะ แสดงให้เห็นว่า AI สามารถเรียนรู้และสร้างสรรค์ผลงานที่มีสไตล์เฉพาะตัวได้ โดยอาศัยการออกแบบฟังก์ชันรางวัลที่เหมาะสม และการใช้เครื่องมือ Open Source ที่มีประสิทธิภาพ

#AIArt #Watercolour #TRL #OpenAI

ขอบคุณ แหล่งข้อมูล
https://huggingface.co/blog/train-to-paint-with-code

Funes: สร้าง "ความทรงจำ" ให้กับ AI Coding Agent ของคุณเอง

ในโลกของการพัฒนาซอฟต์แวร์ที่ AI Coding Agent เข้ามามีบทบาทสำคัญมากขึ้นเรื่อยๆ การที่ Agent เหล่านี้จะสามารถทำงานได้อย่างมีประสิทธิภาพสูงสุดนั้น จำเป็นต้องมี "ความทรงจำ" ที่ดี เพื่อให้สามารถอ้างอิงข้อมูลในอดีต หรือเข้าใจบริบทของการทำงานที่ผ่านมาได้ "Funes" คือเครื่องมือที่จะเข้ามาตอบโจทย์นี้ โดยทำหน้าที่เป็นชั้นหน่วยความจำที่ทนทาน (Durable Memory Layer) สำหรับ Coding Agent ของคุณ เพื่อให้พวกมันสามารถจดจำและนำข้อมูลที่เคยประมวลผลไปใช้ได้อย่างชาญฉลาด

ทำไม Coding Agent ถึงต้องการ "ความทรงจำ"?

เมื่อ Coding Agent ทำงาน พวกมันจะค้นหาโค้ด ลองใช้วิธีการต่างๆ พบข้อผิดพลาด อ่านเอกสาร และปรับเปลี่ยนทิศทางการทำงาน ซึ่งทั้งหมดนี้จะทิ้งร่องรอย (Traces) หรือบันทึกการทำงานไว้มากมาย ร่องรอยเหล่านี้ไม่ใช่แค่ข้อมูลว่าอะไรเปลี่ยนแปลงไป แต่ยังบอกถึง "เหตุผล" เบื้องหลังการเปลี่ยนแปลงนั้นด้วย

อย่างไรก็ตาม บันทึกการทำงานเหล่านี้เป็นเพียง "ศักยภาพ" ของความทรงจำเท่านั้น หากไม่มีการจัดการที่ดี เช่น การจัดทำดัชนี (Indexing) การดึงข้อมูล (Retrieval) การจัดลำดับ (Ranking) และการอ้างอิงแหล่งที่มาที่ชัดเจน (Provenance) การจะค้นหาข้อมูลที่ต้องการ เช่น "ทำไมเราถึงเลิกใช้ Streaming Parser?" จากบันทึกนับหมื่นเทิร์น ก็แทบจะเป็นไปไม่ได้

Funes คืออะไร และทำงานอย่างไร?

Funes ถูกออกแบบมาเพื่อแก้ปัญหานี้ โดยเป็นชั้นหน่วยความจำที่สร้างขึ้นจากเซสชันการทำงานของ Agent ที่มีอยู่แล้วบนเครื่องของคุณ โดยทำงานแบบ Local และผสานรวมเข้ากับ Workflow ปกติของ Agent ได้ง่ายๆ ด้วยคำสั่งเดียว

การติดตั้งและเพิ่ม Funes ให้กับ Agent:

1. ติดตั้ง Funes:

    pip install funes

1. เพิ่ม Funes ให้กับ Agent:

    funes add --agent 

เมื่อรันคำสั่งนี้ Funes จะสร้าง Index แรกให้กับ Agent, เพิ่มเครื่องมือ Recall และ Get, และติดตั้งระบบอัตโนมัติที่คอย Index ทุกเทิร์นที่เสร็จสมบูรณ์ การ Index เป็นแบบ Incremental หมายความว่า การรันแต่ละครั้งจะเพิ่มเทิร์นใหม่ๆ เข้าไป แทนที่จะต้อง Embed ประวัติทั้งหมดใหม่ทั้งหมด เนื้อหาเก่าๆ ที่มีความลึกสามารถทยอย Backfill ได้

หลังจากนั้น เมื่อ Agent ต้องการอ้างอิงการตัดสินใจในอดีต, เหตุผลเบื้องหลัง, หรือสิ่งที่เคยค้นพบ มันสามารถเรียกใช้ "Recall" ได้เอง โดยที่คุณไม่จำเป็นต้องจำเซสชันเก่า หรือคัดลอกบริบทไปวางในเซสชันใหม่

การทำงานของ Recall

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

• Recall จะคืนค่าข้อความต้นฉบับ ไม่ใช่บทสรุป และแสดงที่มาที่ชัดเจน (Agent, Timestamp, Session, และ Turn)
• ผลลัพธ์แต่ละรายการจะมาพร้อมคำสั่ง Get ซึ่งจะเปิด Turn เต็มๆ และบริบทโดยรอบ

เบื้องหลัง Funes ใช้ Pipeline ที่ทำงานแบบ Deterministic ในการ Parse Trace ที่รองรับให้อยู่ในรูปแบบ Turn-and-Block ที่เหมือนกัน, ทำการ Chunk ข้อมูล, Embed ด้วย Local Model ที่ถูกปักหมุดไว้, และเขียนลงใน Lance Dataset แบบ Local

คุณสมบัติสำคัญของ Funes

Funes มีคุณสมบัติที่น่าสนใจ 3 ประการ:

1. หน่วยความจำเดียวใช้ได้กับหลาย Agent: Claude Code, Codex, pi, และ Hermes สามารถเขียนข้อมูลไปยัง Shape เดียวกันได้ ทำให้ Recall สามารถครอบคลุมประวัติการทำงานของ Agent เหล่านี้ทั้งหมด และแต่ละผลลัพธ์จะบอกได้ว่า Agent ใดเป็นผู้สร้าง
2. รักษาหลักฐานดิบไว้: ข้อมูลจะไม่ถูกสรุปหรือกลั่นกรองเป็นข้อเท็จจริงทันทีที่เขียน ทำให้สามารถย้อนกลับไปยัง Turn ที่สร้างข้อมูลนั้นๆ ได้เสมอ
3. Recall ทำงานแบบ Local เป็นค่าเริ่มต้น: ไม่จำเป็นต้องมีบัญชีหรือ Hub Repository การประมวลผล Embedding และ Reranking จะทำบนเครื่องของคุณเอง Agent ของคุณเป็นผู้ดำเนินการ Reasoning เอง

เมื่อความทรงจำเดินทางข้ามเครื่อง: การใช้งานร่วมกับ Hugging Face Hub

Funes ไม่เพียงทำงานบนเครื่องเดียวได้ แต่ยังสามารถทำให้หน่วยความจำของคุณเดินทางไปกับคุณได้ โดยการผูก (Bind) เข้ากับ Hugging Face Dataset ที่คุณเป็นเจ้าของ (โดยค่าเริ่มต้นจะเป็น Private)

เมื่อคุณต้องการให้หน่วยความจำตามติดการทำงานของคุณ:

funes add --agent  --memory 

คำสั่งนี้จะทำการ Publish หน่วยความจำปัจจุบันของคุณไปยัง Dataset ที่ระบุ และ Funes จะคอยอัปเดตอย่างต่อเนื่อง โดย Index ทุกเทิร์นแบบ Local และ Publish เมื่อจบเซสชัน Agent จะทำการ Recall จากหน่วยความจำนี้ตลอดการทำงาน

ความปลอดภัย: ก่อนที่ข้อมูลจะถูกส่งไปยัง Hub, Funes จะทำการ Redact ข้อมูล Credentials ในระหว่างการ Index และสแกนซ้ำอีกครั้งเพื่อลบข้อมูลที่อาจเป็นความลับ

เมื่อ Agent อ่านหน่วยความจำจากระยะไกล Funes จะ Cache ไฟล์ Dataset ไว้บนเครื่อง ทำให้การ Query รวดเร็วเหมือนทำงานแบบ Local โดย Hub จะทำหน้าที่จัดการเรื่อง Ownership, Access Control, Versioning, และ Distribution

Ask: สอบถามหน่วยความจำด้วยตนเอง

นอกจากการให้ Agent เรียกใช้ Recall เองแล้ว คุณยังสามารถใช้คำสั่ง ask เพื่อสอบถามหน่วยความจำได้โดยตรง

funes ask --memory  "คำถามของคุณ"

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

funes ask จะทำการ Recall ข้อความที่เกี่ยวข้อง, ส่งให้ Coding Agent, และคืนคำตอบที่อ้างอิงแหล่งที่มาได้อย่างชัดเจน หากข้อความที่ Recall ได้ไม่เพียงพอต่อการตอบ Agent จะแจ้งให้ทราบ คุณสามารถลองปรับเปลี่ยนคำถาม หรือเพิ่ม Funes ให้กับ Agent เพื่อให้มันสามารถค้นหาในหน่วยความจำแบบวนซ้ำได้

สลับ Agent โดยไม่เสีย "เส้นเรื่อง"

หน่วยความจำที่เผยแพร่นั้นไม่ได้ผูกติดกับ Agent หรือ Model ที่สร้างมัน คุณสามารถเริ่มทำงานใน Claude Code, กลับมาทำต่อใน Codex สัปดาห์หน้า, และ Agent ที่สองก็จะสามารถ Recall เหตุผลการทำงานของ Agent แรกได้ หรือใช้ pi กับ Local Model แล้วกลับมาใช้ Claude ได้เช่นกัน

ประโยชน์ของหน่วยความจำที่แชร์ได้:

• ข้ามเครื่อง: ผูก Agent แต่ละตัวเข้ากับหน่วยความจำเดียว และ Recall ประวัติจาก Host ใดก็ได้ที่คุณใช้งาน
• ข้ามทีม: สมาชิกใหม่ในทีมสามารถเข้าถึงการตัดสินใจหลายเดือนได้ตั้งแต่วันแรก รวมถึงข้อผิดพลาดและเหตุผลที่อาจไม่ได้ถูกรวมใน Pull Request
• คู่ขนานกับ Open Source Project: ผู้ดูแลโปรเจกต์สามารถเผยแพร่เซสชันเบื้องหลัง Release ต่างๆ ได้ ทำให้เหมือนมี "CLAUDE.md" ที่ค้นหาได้ ซึ่งเก็บประวัติความเป็นมาของโปรเจกต์ แทนที่จะเป็นหน้าเว็บที่ต้องคอยอัปเดตอยู่เสมอ

หน่วยความจำที่เผยแพร่จะมี Dataset Card และ Tag ของ Funes ทำให้สามารถจดจำและค้นหาได้บน Hub Funes เพิ่ม "Open Working Memory" เข้ามาใน Hub ซึ่งเก็บการตัดสินใจ, แนวทางที่ล้มเหลว, และเหตุผลเบื้องหลังโปรเจกต์ ที่ Agent อื่นสามารถ Query ได้ และสามารถ Trace กลับไปยังเซสชันที่สร้างมันขึ้นมาได้

วิธีที่ถูกที่สุดในการหลุดพ้นจากเซสชันยาวๆ

เซสชันการทำงานที่ยาวนานมักทำให้การประมวลผลแต่ละเทิร์นมีค่าใช้จ่ายสูงกว่าการทำงานใหม่ทั้งหมด คำตอบทั่วไปคือการปล่อยให้ Agent ทำการ Compact และดำเนินการต่อ หรือเขียน Handoff แล้วเริ่มต้นใหม่ Funes เสนอทางเลือกที่สามคือ "Recall"

จากการทดสอบ Handoff-vs-Recall Benchmark พบว่า Recall เป็นวิธีที่ ถูกที่สุด ในการจัดการเซสชันยาวๆ โดยถูกกว่าการเขียน Handoff ถึง 4-8 เท่า เพราะ Recall จะคืนค่า Passage ต้นฉบับ ทำให้ข้อมูลสำคัญไม่สูญหายไปกับการสรุป

หยุดการเริ่มต้นจากศูนย์

"การคิดคือการลืมความแตกต่าง, การสรุป, การสร้างนามธรรม" – Jorge Luis Borges, Funes the Memorious

Agent ของคุณได้เขียนบันทึกการทำงานไว้แล้ว Funes ที่อยู่ใน GitHub repository นี้ เพียงแค่คำสั่งเดียว ก็สามารถเปลี่ยนบันทึกนั้นให้กลายเป็น "ความทรงจำ" ที่ Agent ตัวต่อไปสามารถอ่านได้ ไม่ว่าคุณจะใช้งานบนเครื่องใดก็ตาม Funes สร้างขึ้นบนพื้นฐานของ Open Source โดยใช้ประโยชน์จาก Embedding Model, Lance Datasets, และ Hub สำหรับ Caching และ Content-deduplication

Funes เป็น Open Source เช่นกัน คุณสามารถเปิด Issue เพื่อแจ้งปัญหา หรือเสนอแนะ Agent ที่ต้องการให้รองรับได้

#AI #CodingAgent #OpenSource #Memory #HuggingFace

ขอบคุณ แหล่งข้อมูล
https://huggingface.co/blog/funes

ปรับปรุงโมเดล 350M ให้สร้างผลลัพธ์แบบมีโครงสร้างได้ดีขึ้น ด้วย GRPO เพียง 100 ขั้นตอน

การสร้างผลลัพธ์ที่มีโครงสร้าง (Structured Output) เป็นหนึ่งในงานที่ใช้กันทั่วไปสำหรับโมเดลภาษาขนาดใหญ่ (LLMs) ในโลกจริง แต่ส่วนใหญ่แล้ว การทดสอบมาตรฐาน (Benchmarks) มักจะรวมเอาการสร้างผลลัพธ์นี้เข้ากับการวัดผลด้านการให้เหตุผล (Reasoning) หรือการดึงข้อมูล (Extraction) มากกว่าที่จะวัดผลโดยตรง

หัวใจสำคัญคือการที่โมเดลสามารถสร้างผลลัพธ์ที่ถูกต้องและสามารถนำไปประมวลผลต่อได้ตามรูปแบบที่กำหนด (Schema Compliance) ซึ่งมักจะเป็นปัจจัยตัดสินว่าโมเดลนั้นจะสามารถนำไปเชื่อมต่อกับระบบอื่น ๆ ได้หรือไม่

บทความนี้จะแสดงให้เห็นว่า การปรับแต่งโมเดลขนาดเล็กให้เหมาะกับงานเฉพาะทาง (Task-specific Fine-tuning) สามารถเพิ่มประสิทธิภาพ และเทียบเท่ากับโมเดลที่มีขนาดใหญ่กว่ามากได้อย่างไร

การเตรียมความพร้อม: การติดตั้งและตั้งค่า

ก่อนเริ่มต้น เราจำเป็นต้องเตรียมเครื่องมือต่าง ๆ เพื่อให้การทำงานราบรื่น:

• GPU: ส่วนของการ Fine-tuning จะต้องใช้ GPU
• Colab/Kaggle: โน้ตบุ๊กที่ใช้ในการปรับแต่งโมเดลนี้ ถูกออกแบบมาให้สามารถทำงานบน GPU ฟรีของ Colab หรือ Kaggle ได้
• MacBook (สำหรับ Evaluation): ส่วนของการประเมินผล (Evaluation) สามารถรันบน MacBook ได้ โดยใช้ llama.cpp ซึ่งจะเปิดใช้งานเซิร์ฟเวอร์ที่รองรับ OpenAI API เพื่อให้เครื่องมือประเมินผล IFStruct สามารถสื่อสารได้

เครื่องมือที่เราต้องใช้คือ uv สำหรับจัดการเครื่องมือ Python และ llama.cpp สำหรับการให้บริการโมเดล

การติดตั้ง llama.cpp

ทำตามเอกสารของ Liquid AI เกี่ยวกับการติดตั้ง llama.cpp โดยใช้ Homebrew และตรวจสอบว่า llama-server พร้อมใช้งาน

การประเมิน IFStruct บน LFM2.5-350M (โมเดลพื้นฐาน)

ก่อนที่เราจะเริ่มปรับแต่งโมเดล ลองมาประเมิน LFM2.5-350M บน IFStruct Benchmark กันก่อน เพื่อดูว่าเราสามารถทำคะแนนได้ใกล้เคียงกับ 21.1% ที่รายงานไว้หรือไม่

IFStruct คือ Benchmark ที่ใช้ทดสอบความถูกต้องของผลลัพธ์ LLM และการปฏิบัติตาม Schema โดย Benchmark นี้เป็น Open-source อยู่ที่ Liquid4All/ifstruct และชุดข้อมูลสาธารณะสามารถเข้าถึงได้ที่ Hugging Face ในชื่อ LiquidAI/ifstruct-v1.0

สำหรับการเปรียบเทียบผลการประเมิน เราจะให้บริการโมเดลผ่าน llama.cpp บน MacBook โดยใช้โมเดล BF16 GGUF (LiquidAI/LFM2.5-350M-GGUF)

การเริ่มเซิร์ฟเวอร์โมเดลพื้นฐาน

เมื่อติดตั้ง llama.cpp เรียบร้อยแล้ว ให้เริ่มเซิร์ฟเวอร์โมเดลพื้นฐานด้วยคำสั่งต่อไปนี้:

./server -m  --alias IFStruct --ngl 99 -np 4 -c 32768

• --alias: ชื่อโมเดลที่ IFStruct จะส่งไปยัง Endpoint ที่รองรับ OpenAI API
• -ngl 99: สั่งให้ llama.cpp โหลดทุก Layer ไปยัง GPU (หากมี)
• -np 4: ให้บริการคำขอ 4 รายการพร้อมกัน
• -c 32768: ขนาดของ Context Prompt

การรัน Benchmark

เมื่อเซิร์ฟเวอร์พร้อมทำงานแล้ว เราสามารถรัน Benchmark แบบเต็มรูปแบบด้วยตัวอย่าง 2000 รายการ:

python3 -m ifstruct.eval --model-name IFStruct --max-samples 2000

ผลลัพธ์จาก IFStruct Release Blog รายงานคะแนน 21.1% สำหรับ LFM2.5-350M การตั้งค่า llama.cpp/BF16 ของเราวัดผลได้ 22.6% ซึ่งใกล้เคียงกับ 21.1% ที่รายงานใน IFStruct Blog เราจะใช้ผลลัพธ์จากการทดสอบภายในนี้เป็น Baseline สำหรับการเปรียบเทียบภายใต้ Stack การให้บริการเดียวกัน

GRPO Fine-tuning ด้วย TRL บน Structured Outputs

กระบวนการปรับแต่งโมเดลแบบเต็มรูปแบบสามารถดูได้ในโน้ตบุ๊กที่แนบมา ส่วนนี้จะกล่าวถึงเฉพาะส่วนที่สำคัญ

เราใช้ nvidia/Nemotron-RL-instructionfollowing-structuredoutputs ซึ่งจับคู่ Prompt แต่ละอันกับ Target JSON Schema และจำนวน Field ที่คาดหวัง เราใช้ตัวอย่างประมาณ 500 รายการสำหรับการฝึก

เนื่องจากลักษณะการกระจายข้อมูลของ Nemotron แตกต่างจาก IFStruct Evaluation เราจึงทำการเพิ่ม Prompt เพื่อปิดช่องว่างระหว่างทั้งสองส่วน:

• 40% ของ Prompt จะมีการเพิ่มคำสั่ง "return the output inside a fenced code block" เพื่อให้โมเดลเรียนรู้ที่จะทำตามคำสั่งรูปแบบ แทนที่จะปล่อย JSON ดิบเสมอ
• อีก 20% ที่แยกออกมา จะถูกแปลงเป็น Task แบบ Top-level Array (Schema จะถูกห่อหุ้มใน Array ที่มีจำนวน Item ที่ต้องการ) ซึ่งเป็นการฝึกให้โมเดลสามารถสร้าง Output แบบ List และปฏิบัติตามจำนวน Item ที่กำหนด

การสร้าง LoRA Adapter

เราโหลด LiquidAI/LFM2.5-350M และแนบ LoRA Adapter เข้าไป เนื่องจาก LFM2.5 ใช้สถาปัตยกรรมแบบ Hybrid Attention/Convolution เราจึงกำหนดเป้าหมายไปที่ Module Name เฉพาะของ LFM:

# ตัวอย่างโค้ด (ย่อ)

from trl import create_reference_model, AutoModelForCausalLMWithValueHead

from peft import LoraConfig



model = AutoModelForCausalLMWithValueHead.from_pretrained(

    "LiquidAI/LFM2.5-350M",

    load_in_8bit=True,

    device_map="auto",

)

lora_config = LoraConfig(

    r=16,

    lora_alpha=32,

    lora_dropout=0.05,

    bias="none",

    task_type="CAUSAL_LM",

    target_modules=["q_proj", "k_proj", "v_proj", "o_proj", "wi", "wo", "fc1", "fc2"], 

# ตัวอย่าง target modules

)

model.add_adapter(lora_config)

การฝึกนี้จะปรับปรุงพารามิเตอร์ประมาณ 6 ล้านตัว ซึ่งคิดเป็นประมาณ 1.66% ของโมเดลทั้งหมด

การกำหนด Reward Functions

จากนั้น เรากำหนด Reward Functions 3 ตัว โดยแต่ละตัวจะให้คะแนนบนสเกล [0, 1] เพื่อประเมินว่าโครงสร้างที่ดึงออกมานั้นถูกต้องหรือไม่:

• jsonformatreward: ผลลัพธ์สามารถ Parse ได้หรือไม่ และอยู่ในรูปแบบที่ต้องการหรือไม่? ได้คะแนนเต็ม (1.0) สำหรับรูปแบบที่ต้องการ (Fenced Code Block vs Raw JSON), 0.2 สำหรับรูปแบบที่ parse ได้แต่ไม่ถูกต้อง, และ 0.0 สำหรับผลลัพธ์ที่ Parse ไม่ได้
• fieldcountreward: Object มีจำนวน Top-level Fields ตรงตามที่คาดหวังหรือไม่? การตรงกันพอดีจะได้ 1.0 และคะแนนจะลดลงตามความคลาดเคลื่อน
• schemavalidationreward: ผลลัพธ์สามารถ Validate กับ JSON Schema ของ Row ได้หรือไม่? นับจำนวนข้อจำกัดที่ละเมิด และให้คะแนนบางส่วนโดยพิจารณาจาก Key ที่จำเป็น

เรานำทั้งสามมารวมกันเป็น Weighted Sum ด้วย reward_weights=[1.0, 0.5, 2.0]

การฝึกโมเดล

เราทำการฝึกเป็นเวลา 100 ขั้นตอน โดยมีการสร้างผลลัพธ์ 8 ครั้งต่อกลุ่ม Prompt ซึ่งเหมาะสำหรับ GPU ขนาด 16 GB ฟรี:

# ตัวอย่างโค้ด (ย่อ)

from trl import PPOConfig, PPOTrainer

from transformers import AutoTokenizer



tokenizer = AutoTokenizer.from_pretrained("LiquidAI/LFM2.5-350M")

# ... กำหนด Reward Functions และ Dataset ...



config = PPOConfig(

    steps=100,

    mini_batch_size=1, 

# ปรับตามขนาด GPU

    batch_size=8,      

# จำนวน generations per prompt group

    gradient_accumulation_steps=1,

    

# ... อื่นๆ ...

)

trainer = PPOTrainer(config, model, ref_model=None, tokenizer=tokenizer, dataset=dataset)



# ... ลูปการฝึก ...

ดังที่เห็นในโน้ตบุ๊ก ระหว่างการฝึก ส่วนประกอบของ Reward ทั้งสามส่วนจะเพิ่มขึ้น KL จากโมเดลอ้างอิงจะยกตัวขึ้นจากศูนย์หลังช่วง Warm-up และสัดส่วนของ Truncated Completion จะคงที่ใกล้ศูนย์

การรวมและบันทึกโมเดล

สุดท้าย เราทำการรวม LoRA Adapter เข้ากับ Base Weights และบันทึกเป็น Checkpoint ที่สมบูรณ์พร้อมสำหรับการแปลงเป็น GGUF เพื่อให้บริการ

IFStruct Evaluation บน GRPO Tuned LFM2.5-350M

หลังจากการ Fine-tuning ด้วย GRPO เราทำการประเมิน IFStruct อีกครั้ง สำหรับขั้นตอนนี้ เราจำเป็นต้องแปลง Checkpoint ของโมเดลที่รวมแล้วให้เป็น BF16 GGUF ตัวแปลง Script นี้มาพร้อมกับ Source Code ของ llama.cpp ดังนั้นเราจะ Clone Repository และติดตั้ง Package gguf ของตัวแปลง

การเริ่มเซิร์ฟเวอร์โมเดลที่ Fine-tuned

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

./server -m  --alias IFStruct-GRPO --ngl 99 -np 4 -c 32768

การรัน Benchmark อีกครั้ง

จากนั้น เราจะรัน IFStruct Evaluation แบบเต็มอีกครั้งด้วยโมเดลที่ Fine-tuned แล้ว:

python3 -m ifstruct.eval --model-name IFStruct-GRPO --max-samples 2000

การเปรียบเทียบผลลัพธ์

เมื่อเปรียบเทียบผลการรันทั้งสองครั้งบน Stack การให้บริการที่เหมือนกัน:

| Metric | Base Model | GRPO Tuned Model | Gain |
| :------------------ | :--------- | :--------------- | :------- |
| IFStruct JSON Pass Rate | 22.6% | 29.7% | +7.1 pts |
| IFStruct YAML Pass Rate | 19.5% | 21.8% | +2.3 pts |

จะเห็นว่า การปรับปรุงนั้นตรงตามเป้าหมายของการฝึก: อัตราการผ่าน JSON เพิ่มขึ้นเกือบ 7 จุด (22.6% → 29.7%) ในขณะที่ YAML ยังคงใกล้เคียงเดิม แม้ว่าคะแนนนี้จะยังต่ำกว่าคะแนนของ Qwen3.5-2B ที่ 33.15% แต่ก็แสดงให้เห็นว่า การ Fine-tuning ที่เน้นงานเฉพาะทาง แม้จะเล็กน้อย ก็สามารถทำให้โมเดลขนาดเล็กเข้าใกล้โมเดลขนาดใหญ่ได้

การรัน GRPO สั้นๆ ด้วยตัวอย่างประมาณ 500 รายการ และ 100 ขั้นตอน สามารถยกระดับโมเดลขนาดเล็ก 350M พารามิเตอร์ จาก 22.6% เป็น 29.7% บน IFStruct ได้ ข้อคิดที่ได้คือ สัญญาณ Reward ที่ราคาไม่แพงและเฉพาะเจาะจงกับงาน สามารถทำให้โมเดลขนาดเล็กมีความน่าเชื่อถือเกี่ยวกับรูปแบบผลลัพธ์ได้อย่างมาก และช่วยลดช่องว่างกับโมเดลที่มีขนาดใหญ่กว่าหลายเท่าตัว

หากต้องการทำซ้ำหรือต่อยอดงานนี้ โปรดดูที่ IFStruct v1.0 Blog Post, Liquid4All/ifstruct benchmark repo, และ LiquidAI/ifstruct-v1.0 dataset

#AI #LLM #FineTuning #GRPO #StructuredOutput

ขอบคุณ แหล่งข้อมูล
https://huggingface.co/blog/grpo-with-trl-ifstruct

NeoMME: ตัวเข้ารหัสหลายภาษาและหลายรูปแบบที่ทรงประสิทธิภาพ

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

H Company ได้เปิดตัว NeoMME ซึ่งเป็นตระกูลของตัวเข้ารหัส (Encoder) แบบหลายภาษาและหลายรูปแบบ (Multimodal) ที่ออกแบบมาเพื่อตอบโจทย์เหล่านี้โดยเฉพาะ ด้วยสถาปัตยกรรมที่แตกต่างและวิธีการฝึกฝนที่ทันสมัย NeoMME มุ่งมั่นที่จะมอบประสิทธิภาพและความยืดหยุ่นในการประมวลผลข้อมูลที่เหนือกว่า

NeoMME คืออะไร?

NeoMME (อ่านว่า "นี-โอ-มี") ไม่ใช่แค่ตัวเข้ารหัสทั่วไป แต่เป็น Multimodal-native and Multilingual Encoder ที่ถูกสร้างขึ้นมาใหม่ทั้งหมด โดยไม่ได้อาศัยโมเดลที่ฝึกฝนไว้ล่วงหน้า (Pretrained) แยกส่วนสำหรับส่วนการมองเห็น (Vision Tower) หรือโมเดลภาษาแบบถดถอย (Causal Language Model)

หัวใจสำคัญของ NeoMME คือการใช้ Transformer Encoder ตัวเดียว ในการประมวลผลทั้งโทเค็นข้อความและส่วนของภาพ (Image Patches) โดยตรง ทำให้โมเดลสามารถเรียนรู้ความสัมพันธ์ระหว่างข้อความและภาพได้อย่างลึกซึ้งและมีประสิทธิภาพมากกว่า

จุดเด่นที่ทำให้ NeoMME แตกต่าง

1. สถาปัตยกรรมแบบ Multimodal-native

• Transformer ตัวเดียวสำหรับทุกอย่าง: NeoMME ใช้ Transformer Encoder เพียงตัวเดียวในการประมวลผลทั้งข้อความและภาพ ทำให้การทำงานร่วมกันระหว่างสองรูปแบบข้อมูลเป็นไปอย่างราบรื่น ลดความซับซ้อนของสถาปัตยกรรม และเพิ่มประสิทธิภาพในการประมวลผล
• การประมวลผลอินพุตแบบ Native: ข้อความจะถูกแปลงเป็นโทเค็น ส่วนภาพจะถูกแบ่งออกเป็นกลุ่มพิกเซล (Patches) ขนาด 32x32 และประมวลผลด้วย MLP ขนาดเล็ก ก่อนจะเข้าสู่ Transformer Encoder เดียวกัน
• รองรับความละเอียดภาพแบบ Dynamic: โมเดลสามารถจัดการกับภาพที่มีขนาดและอัตราส่วนต่างกันได้อย่างยืดหยุ่น ช่วยให้สามารถจับรายละเอียดในเอกสารความละเอียดสูงได้อย่างเต็มที่

2. การฝึกฝนด้วย Masked Discrete-Diffusion Objective

NeoMME ถูกฝึกฝนตั้งแต่ต้น (From Scratch) ด้วยเทคนิค Masked Discrete-Diffusion ซึ่งแตกต่างจากการใช้โมเดลภาษาขนาดใหญ่ (LLMs) ทั่วไป โดยเฉพาะอย่างยิ่งในการประมวลผลเอกสาร

• การเรียนรู้จากภาพผ่านการปิดบังข้อความ: ในระหว่างการฝึก โมเดลจะถูกฝึกให้ "เติมคำ" ที่หายไป โดยอาศัยบริบทจากข้อความที่เหลือและข้อมูลภาพ การปิดบังข้อความในระดับสูงจะบังคับให้โมเดลต้องเรียนรู้ที่จะอธิบายภาพ โดยอาศัยสัญญาณจากภาพเป็นหลัก
• ข้อมูลการฝึกที่หลากหลาย: โมเดลได้รับการฝึกฝนด้วยข้อมูลทั้งข้อความหลายภาษา โค้ด คณิตศาสตร์ ภาพธรรมชาติ และภาพเอกสาร ทำให้มีความสามารถในการเข้าใจข้อมูลที่หลากหลาย

3. ประสิทธิภาพสูงในการดึงข้อมูลเอกสาร (Visual Document Retrieval)

NeoMME-Retriever ซึ่งเป็นเวอร์ชันที่ปรับแต่ง (Fine-tuned) สำหรับการดึงข้อมูลเอกสารโดยเฉพาะ มีจุดเด่นที่น่าสนใจดังนี้:

• การสร้าง Embeddings แบบคู่: NeoMME-Retriever สามารถสร้าง Dense Embeddings และ Late-Interaction Embeddings ได้พร้อมกันในขั้นตอนเดียว ให้ความยืดหยุ่นในการใช้งาน
• Dense Embeddings: เหมาะสำหรับการค้นหาแบบรวดเร็วด้วยเทคนิค Approximate Nearest Neighbor (ANN)
• Late-Interaction Embeddings: ให้ความแม่นยำสูงขึ้น โดยพิจารณาความสัมพันธ์ระหว่างส่วนย่อยๆ ของข้อความและภาพ
• ความเร็วในการประมวลผล: ที่ขนาดอินพุต 2048x2048 บน GPU NVIDIA L40S โมเดล NeoMME-Retriever ขนาด 260M สามารถประมวลผลได้ประมาณ 51 หน้าต่อวินาที ซึ่งเร็วกว่าโมเดลอื่น ๆ ที่มีขนาดใกล้เคียงกัน
• การลดขนาดพื้นที่จัดเก็บ Late-Interaction Embeddings: ด้วยเทคนิค Hierarchical Token Pooling และ Asymmetric Quantization ทำให้พื้นที่จัดเก็บสำหรับ Late-Interaction Embeddings ลดลงอย่างมหาศาล (จาก 1.5 MB เหลือเพียง 6 kB ต่อหน้า) โดยยังคงรักษาคุณภาพการค้นหาไว้ได้มากกว่า 95%

4. ความสามารถรอบด้าน

• รองรับหลายภาษา: NeoMME ถูกฝึกฝนด้วยชุดข้อมูลข้อความหลายภาษา ทำให้สามารถประมวลผลและสร้าง Embeddings สำหรับภาษาต่างๆ ได้
• ความยืดหยุ่นในการนำไปใช้: สามารถนำไปใช้ได้ทั้งในงาน Visual Document Retrieval, การสร้างระบบ Visual RAG (Retrieval-Augmented Generation) หรือแม้แต่งานอื่นๆ ที่ต้องการการประมวลผลข้อมูลหลายรูปแบบ

NeoMME เหมาะกับใคร?

NeoMME เหมาะสำหรับนักพัฒนา นักวิจัย หรือองค์กรที่ต้องการ:

• ระบบค้นหาข้อมูลจากเอกสารที่รวดเร็วและแม่นยำ
• การประมวลผลเอกสารที่ซับซ้อน โดยคำนึงถึง Layout, ตาราง, กราฟ และองค์ประกอบภาพ
• โมเดลที่สามารถเข้าใจและประมวลผลข้อมูลได้ทั้งข้อความและรูปภาพไปพร้อมกัน
• โซลูชันที่ลดภาระด้านการประมวลผลและพื้นที่จัดเก็บข้อมูล
• การสร้างระบบ AI ที่มีความสามารถในการอ่านและทำความเข้าใจเอกสาร

การเข้าถึงและใช้งาน

NeoMME พร้อมใช้งานบน Hugging Face Transformers และโมเดลทั้งหมดถูกปล่อยภายใต้ Apache 2.0 License ทำให้สามารถนำไปใช้งานและพัฒนาต่อยอดได้อย่างอิสระ

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

#NeoMME #MultimodalAI #NaturalLanguageProcessing #ComputerVision #DocumentRetrieval

ขอบคุณ แหล่งข้อมูล
https://huggingface.co/blog/Hcompany/neomme

เปิดตัวกระดานผู้นำ ASR ภาษาแรกจากกลุ่มประเทศ Global South 🚀

Hugging Face มุ่งมั่นที่จะพัฒนาและทำให้ปัญญาประดิษฐ์ (AI) เป็นประชาธิปไตยผ่านโอเพนซอร์สและวิทยาศาสตร์แบบเปิด ล่าสุด เราได้เพิ่มภาษาแรกจากกลุ่มประเทศ Global South เข้าสู่กระดานผู้นำ Open Automatic Speech Recognition (ASR) Leaderboard ซึ่งเป็นก้าวสำคัญในการส่งเสริมความหลากหลายทางภาษาในโลกของ AI

ASR คืออะไร และทำไมถึงสำคัญ?

Automatic Speech Recognition (ASR) หรือระบบรู้จำเสียงพูดอัตโนมัติ คือเทคโนโลยีที่ช่วยแปลงเสียงพูดของมนุษย์ให้กลายเป็นข้อความ การพัฒนา ASR ที่แม่นยำและครอบคลุมหลากหลายภาษาเป็นสิ่งสำคัญอย่างยิ่ง เนื่องจากช่วยให้:

• เข้าถึงข้อมูลได้ง่ายขึ้น: ผู้คนสามารถโต้ตอบกับเทคโนโลยีด้วยเสียง โดยไม่ต้องพิมพ์
• สนับสนุนภาษาท้องถิ่น: ช่วยรักษาและส่งเสริมภาษาที่มีผู้ใช้น้อย หรือภาษาที่ยังไม่มีเครื่องมือ AI รองรับมากนัก
• สร้างนวัตกรรม: เปิดโอกาสให้เกิดแอปพลิเคชันและบริการใหม่ๆ ที่ขับเคลื่อนด้วยเสียง

ก้าวสำคัญสู่ความเท่าเทียมทางภาษา

การเพิ่มภาษาจากกลุ่มประเทศ Global South เข้าสู่กระดานผู้นำ ASR ถือเป็นความสำเร็จครั้งสำคัญ เพราะเป็นการเน้นย้ำถึงความสำคัญของการพัฒนาเทคโนโลยีให้ครอบคลุมความหลากหลายทางภาษาทั่วโลก การมีส่วนร่วมของชุมชนนักพัฒนาและนักวิจัยจากภูมิภาคเหล่านี้ จะช่วยให้เราสามารถสร้างโมเดล ASR ที่มีประสิทธิภาพและตรงกับบริบทการใช้งานจริงมากยิ่งขึ้น

อะไรคือ Open ASR Leaderboard?

Open ASR Leaderboard คือแพลตฟอร์มที่รวบรวมและจัดอันดับโมเดล ASR แบบโอเพนซอร์สต่างๆ โดยประเมินจากประสิทธิภาพในการรู้จำเสียงพูดตามมาตรฐานที่กำหนด การมีอยู่ของกระดานผู้นำนี้ช่วยส่งเสริมการแข่งขันอย่างสร้างสรรค์และกระตุ้นให้นักพัฒนาปรับปรุงคุณภาพของโมเดลให้ดียิ่งขึ้น

ความท้าทายและการก้าวต่อไป

การพัฒนา ASR สำหรับภาษาในกลุ่มประเทศ Global South มาพร้อมกับความท้าทายหลายประการ เช่น การขาดแคลนข้อมูลเสียงที่มีคุณภาพ การมีสำเนียงและภาษาถิ่นที่หลากหลาย และทรัพยากรในการวิจัยที่จำกัด

อย่างไรก็ตาม Hugging Face และพันธมิตรจะยังคงมุ่งมั่นที่จะ:

• สนับสนุนการสร้างชุดข้อมูล: ส่งเสริมการรวบรวมและแบ่งปันข้อมูลเสียงสำหรับภาษาต่างๆ
• ส่งเสริมการวิจัย: สนับสนุนนักวิจัยในการพัฒนาเทคนิคใหม่ๆ สำหรับ ASR
• สร้างชุมชน: เปิดโอกาสให้ผู้ที่สนใจได้เข้ามามีส่วนร่วมในการพัฒนาและทดสอบโมเดล

การเปิดตัวภาษาแรกจากกลุ่มประเทศ Global South ในครั้งนี้ เป็นเพียงจุดเริ่มต้นของการเดินทางอันยาวไกล เพื่อให้เทคโนโลยี AI สามารถรองรับและสนับสนุนทุกภาษาบนโลกใบนี้ได้อย่างแท้จริง 🌍

ขอบคุณ แหล่งข้อมูล
https://huggingface.co/blog/open-asr-leaderboard-global-south

AprielGuard: เกราะป้องกันความปลอดภัยและความทนทานต่อการโจมตีสำหรับ LLM ยุคใหม่

ในโลกของปัญญาประดิษฐ์ที่พัฒนาไปอย่างรวดเร็ว โมเดลภาษาขนาดใหญ่ (LLM) ได้กลายเป็นเครื่องมือสำคัญที่ขับเคลื่อนนวัตกรรมใหม่ๆ มากมาย อย่างไรก็ตาม พร้อมกับศักยภาพอันมหาศาล ก็มาพร้อมกับความท้าทายด้านความปลอดภัยและความเสี่ยงจากการโจมตีรูปแบบต่างๆ การรับมือกับภัยคุกคามเหล่านี้ในระบบ LLM ที่ซับซ้อนและทำงานแบบอัตโนมัติ (Agentic workflows) จึงเป็นเรื่องที่ซับซ้อนยิ่งขึ้น

เพื่อตอบโจทย์นี้ AprielGuard ได้ถูกพัฒนาขึ้นมาในฐานะ "เกราะป้องกัน" (Guardrail) ที่ออกแบบมาเพื่อเสริมความแข็งแกร่งด้านความปลอดภัยและความทนทานต่อการโจมตีให้กับระบบ LLM ยุคใหม่โดยเฉพาะ

AprielGuard คืออะไร?

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

• ความเสี่ยงด้านความปลอดภัย 16 ประเภท: ครอบคลุมตั้งแต่เนื้อหาที่เป็นพิษ (toxicity), คำพูดแสดงความเกลียดชัง (hate speech), เนื้อหาทางเพศ (sexual content), ข้อมูลบิดเบือน (misinformation), การทำร้ายตนเอง (self-harm), กิจกรรมที่ผิดกฎหมาย (illegal activities) และอื่นๆ อีกมากมาย
• การโจมตีเชิงกลยุทธ์ (Adversarial Attacks) หลากหลายรูปแบบ: เช่น การฉีดพรอมพ์ (prompt injection), การแหกคุก (jailbreaks), การบิดเบือนการให้เหตุผลแบบลูกโซ่ (chain-of-thought corruption), การยึดครองบริบท (context hijacking), การวางยาพิษหน่วยความจำ (memory poisoning) และลำดับการใช้ประโยชน์จากหลายเอเจนต์ (multi-agent exploit sequences)
• การละเมิดความปลอดภัยและการโจมตีใน Agentic Workflows: รวมถึงการเรียกใช้เครื่องมือ (tool calls) และร่องรอยการให้เหตุผลของโมเดล (model reasoning traces)

ทำไม AprielGuard ถึงสำคัญสำหรับ LLM ยุคใหม่?

ระบบ LLM ในปัจจุบันมีความซับซ้อนกว่าเดิมมาก ไม่ได้จำกัดอยู่แค่การสนทนาแบบสั้นๆ แต่มีการใช้งานในรูปแบบที่หลากหลาย เช่น:

• การสนทนาหลายรอบ (Multi-turn conversations): ที่บริบทและการให้เหตุผลต่อเนื่องกัน
• ขั้นตอนการให้เหตุผลแบบโครงสร้าง (Structured reasoning steps): ที่สร้าง "ลูกโซ่แห่งความคิด" (chains of thought)
• เวิร์กโฟลว์หลายขั้นตอนที่ใช้เครื่องมือช่วย (Tool-assisted multi-step workflows): หรือที่เรียกว่า "เอเจนต์" (agents) ซึ่งสามารถโต้ตอบกับเครื่องมือภายนอกได้
• การโจมตีรูปแบบใหม่ๆ: ที่มุ่งเป้าไปที่การให้เหตุผล, เครื่องมือ หรือหน่วยความจำของโมเดล

ด้วยความซับซ้อนเหล่านี้ วิธีการแบบดั้งเดิม เช่น การใช้โมเดลป้องกันหลายตัว, ตัวกรอง regex, กฎคงที่ หรือเทคนิคที่สร้างขึ้นด้วยมือ มักจะเปราะบางและไม่สามารถปรับขนาดได้ AprielGuard จึงเข้ามาแก้ปัญหานี้ด้วยโมเดลแบบครบวงจรที่ครอบคลุมทั้งความปลอดภัยและกลยุทธ์การโจมตี

คุณสมบัติเด่นของ AprielGuard

AprielGuard ทำงานได้กับอินพุต 3 รูปแบบหลัก:

1. การสนทนาหลายรอบ: ตรวจจับความเสี่ยงและความผิดปกติในการโต้ตอบต่อเนื่อง
2. เวิร์กโฟลว์แบบเอเจนต์: วิเคราะห์การเรียกใช้เครื่องมือ, ร่องรอยการให้เหตุผล, หน่วยความจำ และบริบทของระบบ เพื่อหาความเสี่ยง
3. การจำแนกประเภท: สามารถจำแนกได้ทั้งความเสี่ยงด้านความปลอดภัย (พร้อมระบุหมวดหมู่ที่ละเมิด) และการโจมตีเชิงกลยุทธ์ (เป็นการจำแนกแบบ Binary: โจมตี / ไม่โจมตี)
4. โหมดการทำงานแบบคู่ (Dual-mode operation):

• โหมดการให้เหตุผล (Reasoning Mode): ให้คำอธิบายเชิงโครงสร้างที่ชัดเจนเกี่ยวกับผลการตัดสินใจ ทำให้เข้าใจกระบวนการทำงานของโมเดลได้
• โหมดความเร็วสูง (Fast Mode): เน้นการจำแนกประเภทอย่างรวดเร็ว เหมาะสำหรับไปป์ไลน์การผลิตที่ต้องการความหน่วงต่ำ

การสร้างข้อมูลฝึกสอนที่แข็งแกร่ง

AprielGuard ถูกฝึกสอนด้วยชุดข้อมูลสังเคราะห์ขนาดใหญ่ที่สร้างขึ้นอย่างพิถีพิถัน โดยมีกระบวนการสำคัญดังนี้:

• การสังเคราะห์ข้อมูล (Synthetic Data Generation): ใช้โมเดลอย่าง Mixtral-8x7B และโมเดลภายในเพื่อสร้างเนื้อหาที่ไม่ปลอดภัยและรูปแบบการโจมตีที่หลากหลาย ครอบคลุมหัวข้อย่อยใน Taxonomy เพื่อให้โมเดลมีความเข้าใจที่ลึกซึ้ง
• การเพิ่มข้อมูล (Data Augmentation): ใช้เทคนิคต่างๆ เช่น การใส่ข้อผิดพลาดในตัวอักษร, การแทนที่ด้วย Leetspeak, การเปลี่ยนรูปคำ และการเรียงประโยคใหม่ เพื่อเพิ่มความทนทานของโมเดลต่อการเปลี่ยนแปลงเล็กน้อยของอินพุต
• เวิร์กโฟลว์แบบเอเจนต์ (Agentic Workflows): สร้างสถานการณ์จำลองที่ซับซ้อนของการโต้ตอบระหว่างผู้ใช้กับระบบเอเจนต์ รวมถึงการเรียกใช้เครื่องมือ, การให้เหตุผล, และการสื่อสารระหว่างเอเจนต์ เพื่อฝึกโมเดลให้ตรวจจับการโจมตีในบริบทเหล่านี้
• กรณีการใช้งานบริบทขนาดยาว (Long Context Use Cases): รวบรวมข้อมูลจากเวิร์กโฟลว์ RAG, การสนทนาหลายรอบ, รายงานเหตุการณ์ต่างๆ ที่มีข้อความยาว เพื่อให้โมเดลสามารถตรวจจับความเสี่ยงที่อาจแฝงตัวอยู่ในข้อมูลปริมาณมากได้

ประสิทธิภาพที่ได้รับการพิสูจน์

AprielGuard ได้รับการประเมินผลอย่างเข้มข้นในหลากหลายด้าน:

• เกณฑ์มาตรฐานด้านความปลอดภัยสาธารณะ (Public Safety Benchmarks): แสดงให้เห็นถึงประสิทธิภาพที่ยอดเยี่ยมในการตรวจจับความเสี่ยงด้านความปลอดภัย
• เกณฑ์มาตรฐานการโจมตีสาธารณะ (Public Adversarial Benchmarks): พิสูจน์ความสามารถในการรับมือกับการโจมตีรูปแบบต่างๆ
• เกณฑ์มาตรฐานเวิร์กโฟลว์แบบเอเจนต์ภายใน (Internal Agentic Workflow Benchmarks): ประเมินประสิทธิภาพในสภาพแวดล้อมที่ซับซ้อนและสมจริง
• เกณฑ์มาตรฐานกรณีการใช้งานบริบทขนาดยาว (Internal Long-Context Use Case Benchmarks): ทดสอบความสามารถในการทำงานกับข้อมูลยาวสูงสุด 32k โทเค็น
• การประเมินหลายภาษา (Multilingual Evaluation): แสดงให้เห็นถึงประสิทธิภาพใน 8 ภาษาหลัก (ฝรั่งเศส, เยอรมัน, ญี่ปุ่น, ดัตช์, สเปน, โปรตุเกส-บราซิล, อิตาลี)

สรุป

AprielGuard คือก้าวสำคัญในการสร้างระบบ AI ที่น่าเชื่อถือและปลอดภัยยิ่งขึ้น ด้วยการรวมการจำแนกประเภทความเสี่ยงด้านความปลอดภัย, การตรวจจับการโจมตีเชิงกลยุทธ์, และการรองรับเวิร์กโฟลว์แบบเอเจนต์ที่ซับซ้อน เข้าไว้ในโมเดลเดียว AprielGuard ช่วยลดความซับซ้อน, เพิ่มความครอบคลุม, และเป็นรากฐานที่แข็งแกร่งสำหรับการนำ AI ไปใช้งานจริงอย่างมั่นใจ

#AprielGuard #LLMSafety #AIsecurity #Guardrail #AgenticAI

ขอบคุณ แหล่งข้อมูล
https://huggingface.co/blog/ServiceNow-AI/aprielguard

สร้างผู้ช่วย AI ส่วนตัวของคุณเอง: คู่มือฉบับสมบูรณ์ด้วย Reachy Mini และ DGX Spark

ในยุคที่ AI ก้าวหน้าอย่างรวดเร็ว การมีผู้ช่วย AI ส่วนตัวที่สามารถทำงานร่วมกับเราได้อย่างเป็นธรรมชาติ ไม่ใช่เรื่องเพ้อฝันอีกต่อไป NVIDIA ได้เปิดตัวโซลูชันที่น่าทึ่งในการนำ "เอเจนต์ AI" มาสู่ชีวิตจริง ด้วย DGX Spark และ Reachy Mini ทำให้เราสามารถสร้างผู้ช่วย AI ที่ทำงานได้อย่างชาญฉลาด เข้าใจคำสั่งเสียง และโต้ตอบกับโลกจริงได้ ราวกับมี R2D2 น้อยๆ มาอยู่ข้างกาย

บทความนี้จะพาคุณไปสำรวจวิธีการสร้างประสบการณ์นี้ด้วยตัวเอง โดยใช้พลังการประมวลผลของ NVIDIA DGX Spark ร่วมกับ Reachy Mini หุ่นยนต์ที่พร้อมให้คุณปรับแต่งและเชื่อมต่อเข้ากับระบบ AI ของคุณได้อย่างง่ายดาย

ทำไม Reachy Mini และ DGX Spark ถึงน่าสนใจ?

Reachy Mini ไม่ใช่แค่หุ่นยนต์ธรรมดา แต่เป็นแพลตฟอร์มที่ออกแบบมาเพื่อการปรับแต่งและเชื่อมต่อกับระบบ AI ที่ซับซ้อน เมื่อผสานเข้ากับพลังของ DGX Spark ซึ่งเป็นระบบคอมพิวเตอร์ประสิทธิภาพสูงสำหรับการประมวลผล AI ทำให้คุณสามารถ:

• สร้างเอเจนต์ AI ที่มองเห็นและโต้ตอบได้: Reachy Mini มาพร้อมกับเซ็นเซอร์ กล้อง และส่วนควบคุมที่ช่วยให้เอเจนต์ AI ของคุณสามารถรับรู้สภาพแวดล้อม สื่อสารด้วยเสียง และแม้กระทั่งเคลื่อนไหวได้
• ความเป็นส่วนตัวและความปลอดภัย: การประมวลผลข้อมูลบน DGX Spark ของคุณเอง หมายความว่าข้อมูลส่วนตัวของคุณจะถูกเก็บไว้อย่างปลอดภัย ไม่ต้องส่งออกไปภายนอก
• การปรับแต่งอย่างเต็มรูปแบบ: คุณสามารถควบคุมโมเดล AI, คำสั่ง (prompts), เครื่องมือ (tools) และการกระทำของหุ่นยนต์ได้อย่างสมบูรณ์ คุณคือผู้กำหนดทิศทาง
• ระบบเปิดและยืดหยุ่น: แตกต่างจากผู้ช่วยส่วนตัวแบบปิด Reachy Mini และเครื่องมือที่ใช้ร่วมกันเป็นระบบเปิด ทำให้คุณสามารถตรวจสอบ ขยายขีดความสามารถ และปรับเปลี่ยนการทำงานได้ง่าย

ส่วนประกอบสำคัญในการสร้างผู้ช่วย AI ของคุณ

การสร้างผู้ช่วย AI นี้จะเน้นการนำส่วนประกอบที่มีอยู่แล้วมาประกอบเข้าด้วยกันอย่างชาญฉลาด โดยใช้โมเดล AI แบบเปิดสำหรับความสามารถในการคิดวิเคราะห์ (Reasoning) และการมองเห็น (Vision) ควบคู่ไปกับเฟรมเวิร์กสำหรับจัดการการทำงานของเอเจนต์ และเครื่องมือสำหรับสั่งการ

สิ่งที่คุณจะต้องใช้:

• โมเดลสำหรับการคิดวิเคราะห์ (Reasoning Model): เช่น NVIDIA Nemotron 3 Nano
• โมเดลสำหรับการมองเห็น (Vision Model): เช่น NVIDIA Nemotron Nano 2 VL (VLA)
• โมเดลแปลงข้อความเป็นคำพูด (Text-to-Speech): เช่น ElevenLabs
• Reachy Mini: หรือ Reachy Mini Simulation สำหรับการทดสอบ
• สภาพแวดล้อม Python v3.10+: พร้อมเครื่องมือจัดการแพ็กเกจ เช่น uv

ขั้นตอนการสร้างผู้ช่วย AI ส่วนตัวของคุณ

ขั้นตอนที่ 0: การตั้งค่าเบื้องต้นและการเข้าถึงโมเดล

1. โคลน Repository: เริ่มต้นด้วยการโคลน Repository ที่รวบรวมโค้ดทั้งหมดที่คุณต้องการใช้
2. การเข้าถึงโมเดล NVIDIA Nemotron:

• Local Deployment: ติดตั้งโมเดลบนฮาร์ดแวร์ของคุณเอง (DGX Spark หรือ GPU ที่มี VRAM เพียงพอ) โมเดลการคิดวิเคราะห์ต้องการพื้นที่ประมาณ 65GB และโมเดลการมองเห็นต้องการประมาณ 28GB
• Cloud Deployment: นำโมเดลไปใช้งานบน Cloud GPU เช่น ผ่าน NVIDIA Brev หรือ Hugging Face Inference Endpoints
• Serverless Model Endpoints: เชื่อมต่อผ่าน Remote Endpoints ที่มีให้ใช้งาน เช่น build.nvidia.com (บทความนี้จะเน้นที่การใช้ Endpoint)

1. ตั้งค่า API Keys: หากคุณใช้ Nemotron ผ่าน Endpoint ให้สร้างไฟล์ .env ใน Directory หลักและใส่ API keys ของคุณ หากเป็นการ Deploy แบบ Local ให้ข้ามขั้นตอนนี้ไป

ขั้นตอนที่ 1: สร้างส่วนต่อประสานแชทพื้นฐาน

ใช้ NVIDIA NeMo Agent Toolkit เพื่อสร้าง Workflow การแชท LLM พื้นฐานผ่าน API Server

• การทำงาน: NeMo Agent Toolkit รองรับการรัน Workflow ผ่านคำสั่ง nat serve โดยใช้ไฟล์ Config ที่กำหนดค่าการตั้งค่าทั้งหมด รวมถึงโมเดลที่ใช้สำหรับการแชท การทำความเข้าใจภาพ และโมเดล Router
• การเชื่อมต่อ: UI ของ NeMo Agent Toolkit สามารถเชื่อมต่อผ่าน HTTP/WebSocket ทำให้คุณสามารถแชทกับ Workflow ได้เหมือนผลิตภัณฑ์แชททั่วไป
• การตั้งค่า: โดยทั่วไปจะรัน NeMo Agent Toolkit Server บน Port 8001 เพื่อให้บอทและ UI สามารถเรียกใช้งานได้

หลังจากตั้งค่า Server แล้ว ให้ทดสอบการส่ง Prompt ข้อความธรรมดาผ่าน Terminal เพื่อให้แน่ใจว่าทุกอย่างพร้อมใช้งาน

ขั้นตอนที่ 2: เพิ่มความสามารถในการเรียกใช้เครื่องมือ (Tool Calling) ด้วย ReAct Agent

การเรียกใช้เครื่องมือเป็นส่วนสำคัญของ AI Agent โดย NeMo Agent Toolkit มี ReAct Agent ที่สามารถตัดสินใจและเรียกใช้เครื่องมือหลายอย่างก่อนที่จะตอบคำถาม

• การทำงาน: เราจะกำหนดเส้นทาง "คำขอการกระทำ" (Action Requests) ไปยัง ReAct Agent ซึ่งได้รับอนุญาตให้เรียกใช้เครื่องมือต่างๆ เช่น การสั่งการหุ่นยนต์ หรือการดึงข้อมูลสถานะปัจจุบันของหุ่นยนต์
• ข้อควรจำ:
• กำหนด Schema ของเครื่องมือให้ชัดเจน (ชื่อ, คำอธิบาย, Arguments) เพราะ Agent จะใช้ข้อมูลนี้ในการตัดสินใจ
• จำกัดจำนวนการเรียกใช้เครื่องมือสูงสุด (maxtoolcalls) เพื่อป้องกันการทำงานที่ซ้ำซ้อน
• หากใช้หุ่นยนต์จริง ควรมี Pattern "ยืนยันก่อนสั่งการ" (Confirm before actuation) เพื่อความปลอดภัยในการเคลื่อนไหว

ขั้นตอนที่ 3: เพิ่ม Router เพื่อกระจายคำสั่งไปยังโมเดลต่างๆ

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

• คำถามเกี่ยวกับข้อความ: ใช้โมเดลข้อความที่รวดเร็ว
• คำถามเกี่ยวกับภาพ: ประมวลผลผ่าน VLM (Vision-Language Model)
• คำขอการกระทำ/เครื่องมือ: ส่งต่อไปยัง ReAct Agent + Tools

คุณสามารถสร้าง Router ได้หลายวิธี เช่น ใช้ Heuristics, ตัวจำแนกประเภท (Classifier) ขนาดเล็ก หรือบริการ Router โดยเฉพาะ

• ตัวอย่างนโยบายการกระจาย:
• หากผู้ใช้ถามเกี่ยวกับสภาพแวดล้อม ให้ส่งคำขอไปยัง VLM พร้อมภาพจากกล้อง
• หากผู้ใช้ถามคำถามที่ต้องการข้อมูลแบบเรียลไทม์ ให้ส่งไปยัง ReAct Agent เพื่อทำการค้นหาผ่าน Tool Call
• หากผู้ใช้ถามคำถามง่ายๆ ให้ส่งไปยังโมเดลขนาดเล็กที่เร็วและปรับให้เหมาะกับการสนทนา

ขั้นตอนที่ 4: เพิ่ม Pipecat Bot สำหรับการทำงานแบบ Real-time ด้วยเสียงและภาพ

Pipecat เป็นเฟรมเวิร์กที่ออกแบบมาสำหรับเอเจนต์แบบ Multimodal ที่มี Latency ต่ำ ช่วยจัดการสตรีมเสียง/วิดีโอ, บริการ AI และการขนส่งข้อมูล เพื่อให้คุณสามารถสร้างบทสนทนาที่เป็นธรรมชาติ

• หน้าที่ของ Pipecat Bot:
• จับภาพจากกล้องของหุ่นยนต์
• การรู้จำเสียงพูดและการแปลงเสียงเป็นข้อความ (Speech Recognition)
• การแปลงข้อความเป็นเสียงพูด (Text-to-Speech)
• การประสานงานการเคลื่อนไหวและการแสดงออกของหุ่นยนต์

คุณจะพบโค้ด Pipecat Bot ทั้งหมดในโฟลเดอร์ reachy-personal-assistant/bot

ขั้นตอนที่ 5: เชื่อมต่อทุกอย่างเข้ากับ Reachy (Hardware หรือ Simulation)

Reachy Mini จะมี Daemon ที่ส่วนอื่นๆ ของระบบจะเชื่อมต่อเข้าไป

• การตั้งค่า: Repository นี้จะรัน Daemon ในโหมด Simulation เป็นค่าเริ่มต้น (--sim) หากคุณมี Reachy Mini ของจริง สามารถลบ Flag นี้ออกได้ โค้ดเดียวกันจะควบคุมหุ่นยนต์จริงของคุณ

คุณจะต้องใช้ Terminal 3 ตัวในการรันระบบทั้งหมด:

1. Terminal 1: รัน Reachy Daemon (เพิ่ม --sim หากใช้ Simulation)
2. Terminal 2: รัน Pipecat Bot Service
3. Terminal 3: รัน NeMo Agent Toolkit Service (หากยังไม่ได้รันจากขั้นตอนที่ 1)

เมื่อทุก Terminal พร้อมแล้ว ให้ติดตามหน้าต่างหลัก 2 ส่วน:

• Reachy Sim: หน้าต่างนี้จะปรากฏขึ้นอัตโนมัติหากคุณใช้ Reachy Mini Simulation
• Pipecat Playground: เป็น UI ฝั่ง Client ที่คุณสามารถเชื่อมต่อกับ Agent, เปิดใช้งานไมโครโฟนและกล้อง และดู Transcript แบบสดๆ เปิด URL ที่ได้จาก Bot Service (โดยทั่วไปคือ http://localhost:7860/) ในเบราว์เซอร์ของคุณ

เมื่อทั้งสองหน้าต่างพร้อมใช้งาน และสถานะ Client และ Agent แสดงเป็น "READY" คุณก็สามารถเริ่มโต้ตอบกับผู้ช่วย AI ของคุณได้แล้ว!

ลองโต้ตอบกับผู้ช่วย AI ของคุณ

นี่คือตัวอย่าง Prompt ง่ายๆ ที่คุณสามารถใช้ทดสอบผู้ช่วยส่วนตัวของคุณได้:

Text-only prompts:

• "อธิบายว่าคุณทำอะไรได้บ้างในหนึ่งประโยค"
• "สรุปสิ่งที่ฉันพูดล่าสุด"

Vision prompts (เมื่อหันกล้องไป):

• "ฉันกำลังถืออะไรอยู่หน้ากล้อง"
• "อ่านข้อความบนหน้านี้แล้วสรุปให้หน่อย"

ก้าวต่อไป: พัฒนาผู้ช่วย AI ของคุณ

การสร้างผู้ช่วย AI ด้วย Reachy Mini และ DGX Spark นี้ เป็นการวางรากฐานสำหรับระบบส่วนตัวที่สามารถตรวจสอบ ขยายขีดความสามารถ และทำงานได้แบบ Local เต็มรูปแบบ โดยที่คุณสามารถมองเห็นการไหลของข้อมูล, สิทธิ์ในการเข้าถึงเครื่องมือ, และวิธีการรับรู้และดำเนินการของหุ่นยนต์

คุณสามารถสำรวจทิศทางต่อไปนี้เพื่อพัฒนาผู้ช่วย AI ของคุณให้ดียิ่งขึ้น:

• ปรับแต่งประสิทธิภาพ: ใช้ตัวอย่าง Developer ของ LLM Router เพื่อสร้างสมดุลระหว่างต้นทุน Latency และคุณภาพ โดยการกระจายคำขอไปยังโมเดลต่างๆ อย่างชาญฉลาด
• สร้าง RAG Agent ด้วยเสียง: ลองดู Tutorial สำหรับการสร้าง Agent ที่ใช้ RAG (Retrieval-Augmented Generation) พร้อม Guardrails โดยใช้โมเดล Nemotron แบบเปิด
• เรียนรู้การใช้งาน Hardware: สำรวจเอกสาร SDK และ Simulation ของ Reachy Mini เพื่อออกแบบและทดสอบพฤติกรรมหุ่นยนต์ขั้นสูง ก่อนนำไปใช้งานจริง
• สำรวจและร่วมพัฒนา: ดูแอปพลิเคชันที่ชุมชนสร้างขึ้นสำหรับ Reachy

หากคุณต้องการลองใช้งานทันที คุณสามารถ Deploy สภาพแวดล้อมทั้งหมดได้ด้วยคลิกเดียว!

#AI #Robotics #NVIDIA #ReachyMini #DGXSpark #AgentAI

ขอบคุณ แหล่งข้อมูล
https://huggingface.co/blog/nvidia-reachy-mini

Falcon-H1-Arabic: ก้าวข้ามขีดจำกัด AI ภาษาอาหรับ ด้วยสถาปัตยกรรมไฮบริดสุดล้ำ 🚀

การพัฒนาโมเดลภาษาอาหรับระดับโลกเป็นกระบวนการที่เต็มไปด้วยการเรียนรู้และปรับปรุงอย่างต่อเนื่อง วันนี้ เรามีความยินดีที่จะประกาศเปิดตัว Falcon-H1-Arabic ตระกูลโมเดลภาษาอาหรับที่ทันสมัยที่สุดของเรา ซึ่งแสดงถึงความก้าวหน้าครั้งสำคัญทั้งในด้านสถาปัตยกรรมและความสามารถ การเปิดตัวครั้งนี้เกิดจากการวิจัยหลายเดือน การรับฟังความคิดเห็นจากชุมชน และนวัตกรรมทางเทคนิค เพื่อสร้างสรรค์โมเดลทรงพลัง 3 แบบ ที่จะมากำหนดมาตรฐานใหม่สำหรับการประมวลผลภาษาธรรมชาติของภาษาอาหรับ

จาก Falcon-Arabic สู่ Falcon-H1-Arabic: การต่อยอดความสำเร็จ

เมื่อไม่กี่เดือนที่ผ่านมา การเปิดตัว Falcon-Arabic ได้รับการตอบรับอย่างอบอุ่นและให้ข้อคิดที่มีคุณค่าจากชุมชน นักพัฒนา นักวิจัย และนักศึกษาทั่วโลกอาหรับต่างนำโมเดลไปใช้ในสถานการณ์จริง ทำให้เราได้เรียนรู้ว่าโมเดลใดทำได้ดี และที่สำคัญกว่านั้นคือ โมเดลยังมีจุดที่ต้องปรับปรุง โดยเฉพาะอย่างยิ่งในด้านความเข้าใจบริบทที่ยาวนาน ความหลากหลายของภาษาถิ่น การให้เหตุผลเชิงคณิตศาสตร์ และความรู้เฉพาะทาง

เราไม่ได้ต้องการเพียงแค่การปรับปรุงเล็กๆ น้อยๆ แต่เราต้องการคิดทบทวนแนวทางของเราใหม่ทั้งหมด ผลลัพธ์คือ Falcon-H1-Arabic ตระกูลโมเดลที่ตอบสนองทุกข้อเสนอแนะที่เราได้รับ พร้อมทั้งนำเสนอการปรับปรุงสถาปัตยกรรมที่ไม่เคยมีมาก่อนในโมเดลภาษาอาหรับ

Falcon-H1-Arabic 3B, 7B, 34B: ประสิทธิภาพเหนือกว่าโมเดล SOTA ที่ขนาดใกล้เคียงกัน

สถาปัตยกรรมไฮบริด Mamba-Transformer: นวัตกรรมครั้งแรกสำหรับ NLP ภาษาอาหรับ 🌟

Falcon-H1-Arabic สร้างขึ้นบนสถาปัตยกรรมไฮบริด Falcon-H1 ที่ผสานรวม State Space Models (Mamba) และ Transformer attention เข้าไว้ด้วยกันในทุกบล็อก ส่วนประกอบทั้งสองทำงานแบบขนาน และการแสดงผลจะถูกหลอมรวมก่อนส่งออก นี่คือการออกแบบที่ให้ความสามารถในการปรับขนาดเชิงเส้นของ Mamba สำหรับลำดับที่ยาวมาก ในขณะเดียวกันก็ยังคงความสามารถในการสร้างแบบจำลองระยะยาวที่แม่นยำของ attention

สำหรับภาษาอาหรับ ซึ่งมีโครงสร้างคำที่ซับซ้อนและโครงสร้างประโยคที่ยืดหยุ่น แนวทางนี้ช่วยเพิ่มความสอดคล้องและการให้เหตุผลตลอดข้อความที่ยาวได้อย่างมาก เราได้นำสถาปัตยกรรมนี้ไปใช้ในสามขนาด (3 พันล้าน, 7 พันล้าน, และ 34 พันล้านพารามิเตอร์) แต่ละขนาดจะมีความสมดุลระหว่างศักยภาพ ประสิทธิภาพ และความสามารถในการนำไปใช้งาน สำหรับกรณีการใช้งานที่หลากหลาย ตั้งแต่อุปกรณ์พกพาไปจนถึงแอปพลิเคชันระดับองค์กร

ทลายขีดจำกัดด้านบริบท: เข้าใจข้อความได้ยาวขึ้นกว่าเดิม 📚

เราได้เพิ่มขีดความสามารถด้านบริบทอย่างมหาศาล จากขีดจำกัด 32K ของ Falcon-Arabic เป็น 128K tokens สำหรับโมเดล 3B และ 256K tokens สำหรับโมเดล 7B และ 34B ด้วยจำนวน 256K tokens (ประมาณ 200,000 คำ) โมเดลเหล่านี้สามารถประมวลผลนวนิยายหลายเล่ม หรือเอกสารทางเทคนิคหลายร้อยหน้า ทำให้สามารถใช้งานในการวิเคราะห์ทางกฎหมาย บันทึกทางการแพทย์ งานวิจัยทางวิชาการ และการสนทนาที่ยาวนาน ซึ่งก่อนหน้านี้ไม่สามารถทำได้

การปรับแต่งหลังการฝึก (Post-training) ของเราได้แก้ไขปัญหา "หลงลืมกลางทาง" (lost in the middle) โดยเฉพาะ เพื่อให้แน่ใจว่าโมเดลสามารถใช้ประโยชน์จากช่วงบริบททั้งหมดได้อย่างมีประสิทธิภาพ ไม่ใช่เพียงแค่รับอินพุตที่ยาวเท่านั้น

คุณภาพและความหลากหลายของข้อมูล: รากฐานแห่งความเป็นเลิศ 💎

เราได้สร้างกระบวนการข้อมูลการฝึกเบื้องต้น (pre-training data pipeline) ใหม่ทั้งหมด เพื่อสะท้อนความซับซ้อนของภาษาอาหรับได้ดียิ่งขึ้น เริ่มต้นด้วยกระบวนการกรองคุณภาพหลายขั้นตอนที่ปรับแต่งมาเพื่อการสะกดคำ สัณฐานวิทยา การใส่เครื่องหมายสระ และรูปแบบประโยคของภาษาอาหรับ แทนที่จะใช้การกรองแบบฮิวริสติก เราใช้การวิเคราะห์เชิงลึกทางภาษาศาสตร์เพื่อแยกข้อความที่มีโครงสร้างดีและสอดคล้องกัน และกำจัดสัญญาณรบกวนที่มักพบในคลังข้อมูลบนเว็บแบบเปิด ผลลัพธ์คือชุดข้อมูลภาษาอาหรับที่สะอาดและมีสไตล์ที่สม่ำเสมอยิ่งขึ้น

การครอบคลุมภาษาถิ่นเป็นอีกหนึ่งสิ่งสำคัญ ภาษาอาหรับไม่ได้มีรูปแบบเดียว ภาษาอาหรับมาตรฐานสมัยใหม่ (MSA) อยู่ร่วมกับภาษาถิ่นต่างๆ เช่น อียิปต์, เลแวนต์, กัลฟ์, และ มัฆริบ ซึ่งแต่ละภาษามีคำศัพท์และโครงสร้างไวยากรณ์ที่แตกต่างกัน เราได้ขยายแหล่งข้อมูลภาษาถิ่นอย่างมาก เพื่อให้โมเดลสามารถเข้าใจและสร้างภาษาอาหรับในชีวิตจริงได้อย่างเต็มสเปกตรัม แทนที่จะเอนเอียงไปทาง MSA มากเกินไป

เพื่อให้คงไว้ซึ่งการให้เหตุผลทั่วโลกและความหลากหลายของโดเมน เรายังคงรักษาความสามารถหลายภาษาของ Falcon-H1 โดยการฝึกโมเดลภาษาอาหรับด้วยการผสมผสานระหว่างภาษาอาหรับ ภาษาอังกฤษ และเนื้อหาหลายภาษาในสัดส่วนที่เกือบเท่ากัน รวมทั้งหมดประมาณ 300 พันล้านโทเค็น สิ่งนี้ช่วยให้มั่นใจได้ถึงประสิทธิภาพที่แข็งแกร่งในด้านโค้ด STEM และการให้เหตุผลข้ามภาษา

การฝึกอบรมหลังการฝึก (Post-Training): ปรับปรุงความสามารถโดยไม่ลดทอนประสิทธิภาพ 🛠️

หลังจากการฝึกเบื้องต้น Falcon-H1-Arabic จะผ่านกระบวนการฝึกอบรมหลังการฝึก (post-training pipeline) ที่เน้นเฉพาะทาง ประกอบด้วยการปรับแต่งแบบมีผู้สอน (Supervised Fine-Tuning - SFT) ตามด้วยการปรับให้เหมาะสมตามความพึงพอใจโดยตรง (Direct Preference Optimization - DPO)

• SFT: เรานำเสนอโมเดลด้วยคำสั่งภาษาอาหรับคุณภาพสูง ตัวอย่างบริบทที่ยาวนานที่คัดสรรมา และงานการให้เหตุผลที่มีโครงสร้าง เพื่อสอนให้โมเดลปฏิบัติตามคำสั่ง รักษาความสอดคล้องในลำดับที่ยาว และอ้างอิงคำตอบจากข้อมูลที่เกี่ยวข้อง ขั้นตอนนี้มีความสำคัญเพื่อให้แน่ใจว่าโมเดลสามารถใช้ประโยชน์จากหน้าต่างบริบทขนาดใหญ่ได้อย่างแท้จริง ซึ่งไม่ได้เกิดขึ้นโดยอัตโนมัติจากสถาปัตยกรรมเพียงอย่างเดียว
• DPO: เราตามด้วยขั้นตอน DPO ที่ตรงเป้าหมายเพื่อปรับปรุงการจัดตำแหน่ง คุณภาพการสนทนา และความสอดคล้องของความพึงพอใจ DPO ช่วยให้โมเดลสร้างสมดุลระหว่างการให้เหตุผลในบริบทที่ยาวนานกับความสามารถทางภาษาทั่วไป ปรับปรุงความเป็นประโยชน์ และลดโหมดความล้มเหลวทั่วไป เช่น การหลงประเด็น การใช้บริบทมากเกินไป หรือการละเลยข้อมูลก่อนหน้า

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

กระบวนการฝึกอบรมหลังการฝึกของเรายังได้เสริมสร้างความแข็งแกร่งให้กับส่วนต่างๆ ที่การประเมินแบบดั้งเดิมไม่ได้วัดผลอย่างเต็มที่ เช่น ความน่าเชื่อถือในการสนทนา การจัดระเบียบวาทศิลป์ การติดตามผลที่มีโครงสร้าง และความสอดคล้องของวาทกรรม การปรับปรุงเหล่านี้ช่วยเพิ่มประโยชน์ใช้สอยจริงของโมเดล ทำให้ Falcon-H1-Arabic น่าเชื่อถือยิ่งขึ้นในการสนทนาหลายรอบในชีวิตจริง การดำเนินการตามคำสั่ง และการสนทนาในบริบทที่ยาวนาน

ประสิทธิภาพบน Benchmark: กำหนดมาตรฐานใหม่ 📊

ตัวเลขเป็นส่วนสำคัญของเรื่องราว บน Open Arabic LLM Leaderboard (OALL) ซึ่งเป็นการประเมินความเข้าใจภาษาอาหรับในหลากหลายงาน Falcon-H1-Arabic ได้ผลลัพธ์ที่เป็นมาตรฐานใหม่ (state-of-the-art) ในทุกขนาดที่เราทดสอบ

• โมเดล 3B: มีประสิทธิภาพที่ยอดเยี่ยม ทำคะแนนได้ประมาณ 62% บน OALL ซึ่งเหนือกว่าโมเดลขนาดเล็กทั้งหมด รวมถึง Gemma-4B, Qwen3-4B, และ Phi-4-mini ประมาณ 10 จุด บน 3LM ซึ่งเป็น Benchmark STEM ภาษาอาหรับหลัก ทำคะแนนได้ประมาณ 82% (Native split) และ 73% (Synthetic split) นอกจากนี้ยังได้ประมาณ 62% บน ArabCulture และประมาณ 50% ในการประเมินภาษาถิ่น AraDice (อียิปต์, กัลฟ์, และ เลแวนต์) ทำให้ Falcon-H1-Arabic-3B เป็นโมเดลคุณภาพสูงและมีประสิทธิภาพสูง เหมาะสำหรับการใช้งานบนอุปกรณ์พกพา แอปพลิเคชันแบบเรียลไทม์ และระบบ Agentic ที่ความหน่วงและต้นทุนมีความสำคัญ

• โมเดล 7B: ยังคงรักษาแนวโน้มที่สูงขึ้น ด้วยคะแนน 71.7% บน OALL ซึ่งแซงหน้าโมเดลทั้งหมดในกลุ่ม ~10B รวมถึง Fanar-9B, Allam-7B*, และ Qwen3-8B บน 3LM ทำคะแนนได้ประมาณ 92% (Native split) และ 85% (Synthetic split) คะแนน AraDice เพิ่มขึ้นเป็นกลางๆ 50% ในทุกภาษาถิ่น และผลลัพธ์ ArabCulture เข้าใกล้ 80% โมเดลนี้สร้างสมดุลที่สมบูรณ์แบบระหว่างความสามารถและการนำไปใช้งาน ทำให้เป็นตัวเลือกที่ใช้งานได้จริงที่สุดสำหรับ NLP ภาษาอาหรับทั่วไปในสภาพแวดล้อมการผลิต

• โมเดล 34B: เป็นระบบเรือธงของเรา และสร้างมาตรฐานใหม่สำหรับโมเดลภาษาอาหรับ ทำคะแนนได้ประมาณ 75% บน OALL ซึ่งไม่เพียงแต่เหนือกว่าโมเดลขนาดใกล้เคียงกันเท่านั้น แต่ยังเหนือกว่าระบบที่ใหญ่กว่ามาก เช่น Llama-3.3-70B และ AceGPT2-32B อีกด้วย คะแนน 3LM อยู่ที่ประมาณ 96% (Native split) และ 94% (Synthetic split) บน ArabCulture ได้คะแนนเกือบ 80% และบน AraDice ได้ประมาณ 53% ในทุกภาษาถิ่น การที่โมเดลไฮบริดขนาด 34B มีประสิทธิภาพเหนือกว่า Transformer ขนาด 70B แสดงให้เห็นถึงประสิทธิภาพของสถาปัตยกรรม Falcon-H1 คุณภาพของข้อมูล และความแข็งแกร่งของกระบวนการฝึกอบรมหลังการฝึก

ผลลัพธ์ Benchmark เหล่านี้ยืนยันแนวทางของเรา แต่ยังเน้นย้ำถึงความเป็นจริงที่สำคัญ: ขอบเขตของการสร้างโมเดลภาษาอาหรับกำลังก้าวหน้าอย่างรวดเร็ว ทุกๆ เปอร์เซ็นต์ที่เพิ่มขึ้นบน Benchmark เหล่านี้ แสดงถึงความพยายามด้านวิศวกรรม การคัดสรรข้อมูลอย่างระมัดระวัง และการปรับปรุงสถาปัตยกรรมเป็นจำนวนมาก

การใช้งานจริง: จากอุปกรณ์พกพา สู่ระดับองค์กร 🏢

แต่ละโมเดลในตระกูล Falcon-H1-Arabic เหมาะสมกับการใช้งานที่แตกต่างกัน:

• โมเดล 3B: ปรับให้เหมาะสมสำหรับความเร็ว ประสิทธิภาพด้านต้นทุน และระบบที่มีปริมาณงานสูง ทำให้เหมาะสำหรับ Workflow Agentic, แอปพลิเคชันบนอุปกรณ์, แชทที่มีความหน่วงต่ำ และสภาพแวดล้อมที่มีข้อจำกัดด้านทรัพยากร
• โมเดล 7B: ทำหน้าที่เป็นโมเดลหลักทั่วไปสำหรับแอปพลิเคชันการผลิตส่วนใหญ่ ขับเคลื่อนระบบทำความเข้าใจเอกสาร, แชทบอท, ไปป์ไลน์สรุปความ และเครื่องมือสร้างเนื้อหา
• โมเดล 34B: ออกแบบมาสำหรับโดเมนที่มีความสำคัญสูง ซึ่งความแม่นยำและการให้เหตุผลระยะยาวมีความสำคัญสูงสุด รวมถึงการวิเคราะห์ทางกฎหมาย การสรุปทางการแพทย์ งานวิจัยทางวิชาการ และระบบอัตโนมัติระดับองค์กรขนาดใหญ่ หน้าต่างบริบทที่ขยายออกไปทำให้มีความสามารถพิเศษในการวิเคราะห์เอกสารหลายร้อยหน้าในการประมวลผลครั้งเดียว โดยยังคงรักษาความสอดคล้องที่แม่นยำ

AI ที่มีความรับผิดชอบและข้อจำกัด ⚠️

เช่นเดียวกับโมเดลภาษาอื่นๆ Falcon-H1-Arabic อาจสะท้อนอคติจากข้อมูลการฝึก และอาจสร้างข้อมูลที่ถูกสร้างขึ้น (hallucinated information) ผลลัพธ์ของโมเดลไม่ควรใช้เป็นแหล่งอำนาจแต่เพียงผู้เดียวสำหรับการตัดสินใจทางการแพทย์ ก

ขอบคุณ แหล่งข้อมูล
https://huggingface.co/blog/tiiuae/falcon-h1-arabic

เทคนิคการ Fine-tune โมเดล Multi-Vector Embedding ด้วย Sentence Transformers

การสร้างโมเดลที่สามารถค้นหาข้อมูลได้อย่างแม่นยำและมีประสิทธิภาพเป็นสิ่งสำคัญอย่างยิ่งในยุคดิจิทัล โดยเฉพาะอย่างยิ่งในงานที่ต้องเปรียบเทียบข้อความจำนวนมาก เช่น การค้นหาเอกสารทางการแพทย์ งานกฎหมาย หรือการค้นหาโค้ด โมเดลแบบ Multi-Vector Embedding หรือที่เรียกว่า Late-Interaction Model เป็นหนึ่งในเทคนิคที่ช่วยเพิ่มความแม่นยำในการค้นหาได้อย่างมาก

บทความนี้จะพาคุณไปเจาะลึกถึงส่วนประกอบต่างๆ ที่จำเป็นสำหรับการ Fine-tune โมเดล Multi-Vector Embedding ด้วยไลบรารี Sentence Transformers พร้อมตัวอย่างการใช้งานจริง เพื่อให้คุณสามารถสร้างโมเดลที่ตอบโจทย์เฉพาะด้านของคุณได้อย่างมีประสิทธิภาพ

ทำความรู้จักกับ Multi-Vector Models

โมเดลแบบ Dense Embedding ทั่วไปจะบีบอัดข้อความทั้งหมดให้กลายเป็นเวกเตอร์เดียว ซึ่งการเปรียบเทียบความคล้ายคลึงจะทำได้โดยการคำนวณ Dot Product ระหว่างเวกเตอร์เหล่านั้น

แต่สำหรับ Multi-Vector Model (หรือ Late-Interaction Model, ColBERT-style) จะแตกต่างออกไป โดยจะเก็บเวกเตอร์ขนาดเล็กไว้สำหรับ แต่ละ Token ในข้อความ จากนั้นจะใช้ Operator ที่ชื่อว่า MaxSim ในการคำนวณคะแนนความคล้ายคลึงระหว่าง Query กับ Document โดย Query Token แต่ละตัวจะหา Document Token ที่ตรงกันที่สุด แล้วนำคะแนนมารวมกัน วิธีนี้ช่วยรักษาข้อมูลเฉพาะจุด (fine-grained signals) ที่โมเดลแบบเวกเตอร์เดี่ยวอาจสูญเสียไปจากการเฉลี่ย ทำให้ได้ผลลัพธ์การค้นหาที่แม่นยำยิ่งขึ้น แม้ว่าจะมีข้อเสียคือขนาด Index ที่ใหญ่ขึ้นก็ตาม

ทำไมต้อง Fine-tune โมเดล Multi-Vector?

การ Fine-tune โมเดล Multi-Vector ช่วยเพิ่มประสิทธิภาพการค้นหาในโดเมนเฉพาะของคุณได้อย่างมาก เนื่องจาก:

• ความเฉพาะเจาะจงของโดเมน: คำศัพท์ รูปแบบการถาม และความหมายของความเกี่ยวข้องอาจแตกต่างกันไปในแต่ละสาขา เช่น การค้นหาข้อมูลบนเว็บ การสืบสวนคดีความ การค้นหาโค้ด หรือการรีวิวเอกสารทางวิทยาศาสตร์ โมเดลแบบ Multi-Vector สามารถจับสัญญาณเฉพาะของโดเมนได้ดีจากการจับคู่แบบ Token ต่อ Token
• การจัดการกับเอกสารขนาดยาว: โมเดล Retrieval ทั่วไปมักถูกฝึกด้วยข้อมูลที่เป็นข้อความสั้นๆ ทำให้มีการตัดทอนเอกสารที่ยาวเกินไปออกไป หากเอกสารของคุณมีความยาวมาก โมเดลเหล่านี้อาจตัดข้อมูลสำคัญทิ้งไป การ Fine-tune ช่วยให้คุณกำหนดความยาวเอกสารที่เหมาะสมกับข้อมูลของคุณได้

ส่วนประกอบสำคัญสำหรับการ Fine-tune Multi-Vector Models

การ Fine-tune โมเดล Multi-Vector นั้นประกอบด้วยส่วนประกอบหลักๆ ดังนี้:

1. โมเดล (Model)

คุณสามารถเลือกจุดเริ่มต้นได้สองแบบ:

• Fine-tune โมเดล Multi-Vector ที่มีอยู่แล้ว: หากคุณต้องการปรับปรุงโมเดลที่มีอยู่แล้ว คุณไม่จำเป็นต้องกังวลเรื่องสถาปัตยกรรมโมเดลมากนัก เพียงแค่โหลด Checkpoint ที่ต้องการ แล้วปรับการตั้งค่าบางอย่าง เช่น ความยาวสูงสุดของเอกสาร (document length cap) หรือการเพิ่มส่วนประกอบอื่น ๆ เช่น Punctuation Skiplist เพื่อยกเว้น Token ที่เป็นเครื่องหมายวรรคตอนจากการคำนวณ
• การปรับความยาวเอกสาร: โมเดลหลายตัวมีข้อจำกัดเรื่องความยาวเอกสาร (เช่น 180-512 Tokens) หากเอกสารของคุณยาวกว่านั้น ควรปรับค่า modelmaxlength ให้เหมาะสม
• Punctuation Skiplist: การเพิ่มรายการสัญลักษณ์วรรคตอนที่ยกเว้นจากการคำนวณคะแนนบนฝั่ง Document ช่วยลดขนาด Index ได้โดยไม่ส่งผลเสียต่อคุณภาพ

• สร้างโมเดลจาก Transformer พื้นฐาน: คุณสามารถใช้ Transformer ตัวใดก็ได้เป็นพื้นฐาน แล้วเพิ่มส่วนประกอบ Token-level Projection ที่เริ่มต้นแบบสุ่มเข้าไป วิธีนี้จะคล้ายกับขั้นตอนการสร้างโมเดล ColBERT แบบคลาสสิก ที่ประกอบด้วย Transformer, Token-level Dense Projection, MultiVectorMask และ Normalize การเริ่มต้นจาก Projection แบบสุ่มนี้ต้องอาศัยการฝึก (Training) เพื่อให้โมเดลมีประสิทธิภาพ
• การเลือก Backbone: การใช้ Backbone ที่ผ่านการ Pre-trained สำหรับ Retrieval มาแล้ว (เช่น Alibaba-NLP/gte-modernbert-base) จะให้ผลลัพธ์ที่ดี แม้จะเริ่มต้นจาก Projection ที่สุ่มก็ตาม
• เทคนิค Tokenization: เทคนิคคลาสสิก เช่น [MASK] query expansion, [Q] / [D] prefix tokens, document length cap, punctuation skiplist สามารถเปิดใช้งานได้ แต่ไม่จำเป็นต้องใช้ทั้งหมดเสมอไป

จุดเริ่มต้นที่แนะนำ:
จากการทดลองพบว่า โมเดล Checkpoint ที่ผ่านการ Pre-training แบบ Unsupervised จะปรับตัวเข้ากับโดเมนใหม่ได้ดีกว่าโมเดลที่ผ่านการ Fine-tune แบบ Supervised มาแล้ว เพราะโมเดล Unsupervised ยังคงโครงสร้าง Late-Interaction ไว้ครบถ้วน โดยไม่ต้องแก้ไขการปรับจูนทั่วไปที่โมเดล Supervised มีอยู่

2. ชุดข้อมูล (Dataset)

โมเดล MultiVectorEncoderTrainer รองรับการใช้งาน datasets.Dataset หรือ datasets.DatasetDict จากไลบรารี Hugging Face Datasets คุณสามารถโหลดข้อมูลได้จาก:

• Hugging Face Hub: ค้นหาชุดข้อมูลที่ติด Tag sentence-transformers บน Hugging Face Hub ได้ที่ [ขอบคุณ แหล่งข้อมูล
  https://huggingface.co/datasets?other=sentence-transformers](https://huggingface.co/datasets?other=sentence-transformers)
• ข้อมูลภายในเครื่อง (Local Data): รองรับไฟล์ข้อมูลหลากหลายรูปแบบ เช่น CSV, JSON, Parquet, Arrow หรือ SQL

รูปแบบข้อมูลที่สำคัญ:

• สำหรับ Loss Function ทั่วไป: หาก Loss Function ต้องการ Label ชุดข้อมูลของคุณต้องมีคอลัมน์ชื่อ "label" หรือ "score"
• สำหรับ Multi-Vector:
• Positional Query and Document Assignment: คอลัมน์แรกจะถูกใช้เป็น Query และคอลัมน์ที่ตามมาทั้งหมดจะถูกใช้เป็น Document (สามารถปรับเปลี่ยนได้ด้วย router_mapping)
• Knowledge Distillation Format: หนึ่งคอลัมน์ต่อ Document ที่เป็น Candidate (เช่น query, document1, ..., documentN, scores)

3. Loss Function

Loss Function ทำหน้าที่วัดประสิทธิภาพของโมเดลและนำทางกระบวนการ Optimize เพื่อปรับปรุงน้ำหนักของโมเดลให้ค่า Loss ต่ำลง การเลือก Loss Function ที่เหมาะสมขึ้นอยู่กับข้อมูลและเป้าหมายของคุณ

• MultiVectorMultipleNegativesRankingLoss: เป็น Loss Function ที่นิยมใช้สำหรับคู่ Query-Passage โดยเอกสารอื่นๆ ใน Batch เดียวกันจะถูกใช้เป็น Negative Samples สำหรับแต่ละ Query
• CachedMultiVectorMultipleNegativesRankingLoss: เป็นเวอร์ชันที่ช่วยให้สามารถใช้ Batch Size ที่ใหญ่ขึ้นได้ โดยไม่ขึ้นกับขนาดหน่วยความจำ GPU โดยตรง พารามิเตอร์ minibatchsize จะจำกัดหน่วยความจำในการ Encode Document เป็นส่วนๆ แต่ effectivebatchsize สามารถเลือกได้อิสระ

4. Training Arguments (Optional)

พารามิเตอร์เหล่านี้มีผลต่อประสิทธิภาพการฝึก การติดตามผล และการ Debug ในระหว่างการเทรน

5. Evaluator (Optional)

คลาสสำหรับประเมินผลโมเดล ก่อน ระหว่าง หรือหลังการฝึก

6. Trainer

เป็นส่วนประกอบหลักที่รวบรวมทุกอย่างเข้าด้วยกันเพื่อทำการฝึกโมเดล

ตัวอย่างการ Fine-tune โมเดล

สมมติว่าเราต้องการ Fine-tune โมเดลเพื่อการค้นหาเอกสารทางการแพทย์ เราสามารถทำได้ดังนี้:

1. โหลดชุดข้อมูล: ใช้ load_dataset เพื่อโหลดข้อมูลทางการแพทย์ เช่น คู่คำถาม-บทความทางการแพทย์
2. กำหนดโมเดล: เลือกโมเดล Multi-Vector ที่มีอยู่แล้ว หรือสร้างจาก Transformer พื้นฐาน
3. ตั้งค่า Loss Function: ใช้ CachedMultiVectorMultipleNegativesRankingLoss สำหรับการฝึก
4. กำหนด Training Arguments: ตั้งค่าพารามิเตอร์ที่จำเป็น เช่น trainbatchsize, gradientaccumulationsteps, learningrate, numtrain_epochs เป็นต้น
5. สร้าง Trainer: นำส่วนประกอบทั้งหมดมาใส่ใน MultiVectorEncoderTrainer
6. เริ่มการฝึก: เรียกใช้เมธอด trainer.train()

การประเมินผลโมเดล

หลังจาก Fine-tune โมเดลเสร็จสิ้น การประเมินผลเป็นขั้นตอนสำคัญเพื่อดูว่าโมเดลของเราทำงานได้ดีเพียงใดในการค้นหาข้อมูลในโดเมนเฉพาะ

• สร้าง Evaluator: ใช้ InformationRetrievalEvaluator สำหรับการประเมินผลการค้นหา
• กำหนด Corpus และ Queries: เตรียมชุดข้อมูลเอกสาร (Corpus) และชุดคำถาม (Queries) สำหรับการประเมิน
• รันการประเมิน: เรียกใช้เมธอด evaluator.compute_metrics() เพื่อคำนวณ Metric ต่างๆ เช่น NDCG@10, MAP, MRR

จากการทดลองพบว่า โมเดล Multi-Vector ที่ผ่านการ Fine-tune ด้วยข้อมูลทางการแพทย์ สามารถทำงานได้ดีกว่าโมเดล Retrieval ทั่วไปทุกประเภทที่ทดสอบ ทั้งแบบ Dense, Sparse, Lexical และ Multi-Vector เอง

สรุป

การ Fine-tune โมเดล Multi-Vector Embedding ด้วย Sentence Transformers เป็นวิธีที่มีประสิทธิภาพในการเพิ่มความแม่นยำในการค้นหาข้อมูลสำหรับโดเมนเฉพาะ การทำความเข้าใจส่วนประกอบต่างๆ เช่น โมเดล, ชุดข้อมูล, Loss Function และการเลือกจุดเริ่มต้นที่เหมาะสม จะช่วยให้คุณสามารถสร้างโมเดลที่ตอบสนองความต้องการของคุณได้อย่างดีเยี่ยม

#sentencetransformers #multivector #embedding #nlp #retrieval

ขอบคุณ แหล่งข้อมูล
https://huggingface.co/blog/train-multi-vector-encoder

สร้างระบบค้นหาเอกสารวิจัยทรงพลังด้วย Hugging Face: เบื้องหลัง Papers with Code

การเข้าถึงงานวิจัยทางวิทยาศาสตร์เป็นสิ่งสำคัญยิ่งในยุคปัจจุบัน โดยเฉพาะอย่างยิ่งสำหรับวงการ AI ที่มีการพัฒนาอย่างรวดเร็ว การมีระบบค้นหาที่มีประสิทธิภาพจึงเป็นหัวใจหลักที่ช่วยให้นักวิจัยและผู้ที่สนใจสามารถค้นหาข้อมูลที่เกี่ยวข้องได้อย่างรวดเร็ว ทั้งผ่านเว็บไซต์หรือเครื่องมือ command-line Papers with Code (PwC) คือหนึ่งในแพลตฟอร์มที่มุ่งมั่นทำให้งานวิจัย AI เป็นที่เข้าถึงได้ง่ายขึ้น ด้วยการพัฒนาระบบค้นหาที่ผสานจุดแข็งของเทคนิคการค้นหาแบบดั้งเดิมและแบบใช้เวกเตอร์เข้าด้วยกัน

ทำไมการค้นหางานวิจัยจึงแตกต่าง?

การค้นหางานวิจัยนั้นซับซ้อนกว่าการค้นหาข้อความทั่วไป เพราะระบบที่ดีควรจะสามารถ:

• ค้นหาชื่อเรื่องหรือรหัส arXiv ที่ถูกต้องได้
• เข้าใจความหมายของคำถาม เช่น "small language models for code generation" แม้ว่าคำเหล่านั้นจะไม่ได้ปรากฏอยู่ด้วยกันในเอกสาร
• จดจำคำค้นที่ต้องการนำทาง เช่น "the original BERT paper"
• รองรับชื่อเรื่องที่ไม่สมบูรณ์ หรือการพิมพ์ผิดพลาด
• ตอบสนองได้อย่างรวดเร็ว แม้ในขณะที่โมเดลกำลังเริ่มทำงาน (cold start) หรือไม่พร้อมให้บริการชั่วคราว

ระบบค้นหาแบบ Hybrid: ผสานจุดแข็งสองโลก

Papers with Code เลือกใช้ ระบบค้นหาแบบ Hybrid ซึ่งเป็นการผสมผสานระหว่าง:

• Keyword Search: ค้นหาคำที่ตรงกันอย่างแม่นยำ
• Vector Search (Semantic Search): ค้นหาคำที่มีความหมายใกล้เคียงกัน แม้จะใช้คำต่างกัน

การทำงานร่วมกันนี้ช่วยให้ได้ผลลัพธ์ที่ครอบคลุมและแม่นยำกว่าการใช้เทคนิคใดเทคนิคหนึ่งเพียงอย่างเดียว นอกจากนี้ ยังสามารถใช้ Reranker (Cross-encoders) เพื่อปรับปรุงคุณภาพผลลัพธ์ให้ดียิ่งขึ้นไปอีก แม้ว่าจะต้องแลกมาด้วยภาระงานและเวลาในการตอบสนองที่เพิ่มขึ้นก็ตาม

สถาปัตยกรรมเบื้องหลัง: Hugging Face Services คือหัวใจสำคัญ

Papers with Code อาศัยฐานข้อมูล PostgreSQL เป็นหลัก โดยใช้ความสามารถ Full-text search ของ PostgreSQL เป็นพื้นฐานในการค้นหาแบบ Lexical และใช้ pgvector เพื่อเพิ่มความสามารถในการค้นหาเชิงความหมาย (Semantic Recall) โดยใช้ Reciprocal Rank Fusion (RRF) ในการรวมผลลัพธ์จากทั้งสองส่วน

ในการสร้าง Dense Embeddings นั้น Hugging Face ได้เข้ามามีบทบาทสำคัญผ่าน 3 บริการหลัก:

1. Hugging Face Jobs: ให้การประมวลผล GPU ที่ยืดหยุ่นสำหรับการสร้าง Embeddings ให้กับคลังเอกสารทั้งหมด
2. Hugging Face Storage Buckets: ทำหน้าที่เป็นจุดพักข้อมูลที่ทนทานและน่าเชื่อถือ ระหว่างฐานข้อมูล, การทดลอง, และ Jobs
3. Hugging Face Inference Endpoints: ให้บริการ Embeddings ที่มีความหน่วงต่ำ (Low-latency) สำหรับการค้นหาแบบ Real-time และการอัปเดตข้อมูล

ปัจจุบัน ระบบนี้ได้สร้าง Embeddings ให้กับเอกสารวิจัยมากกว่า 110,000 ฉบับ ที่รวบรวมมาจาก arXiv และ Daily Papers

การแบ่งกระบวนการ: Offline Corpus Build และ Online Search Service

เพื่อประสิทธิภาพสูงสุด ระบบถูกแบ่งออกเป็นสองส่วนหลัก:

• Offline Corpus Build: เป็นงานที่ต้องการทรัพยากรสูง เน้นปริมาณการประมวลผล (Throughput-oriented) ดำเนินการผ่าน Jobs โดยผลลัพธ์ที่ได้จะถูกจัดเก็บอย่างถาวรใน Buckets
• Online Search Service: ส่วนนี้จะทำเฉพาะขั้นตอนการสร้าง Embedding สำหรับ Query เท่านั้น โดยให้บริการผ่าน Inference Endpoint ที่ได้รับการป้องกันอย่างดี เพื่อให้การค้นหาออนไลน์มีความรวดเร็ว

การแยกส่วนนี้ทำให้ระบบมีความยืดหยุ่น ทรงพลัง และรวดเร็ว หาก Inference Endpoint มีปัญหา ระบบจะกลับไปใช้ Full-text retrieval โดยอัตโนมัติ

การกำหนดสัญญา Embedding ที่เข้มงวด

ปัญหาที่พบบ่อยในการสร้าง Embedding คือการเปลี่ยนแปลงของโมเดล, การสลับ Prompt ระหว่าง Query กับ Document, การตัด Vector ที่ต่างกัน, หรือ Abstract ที่อัปเดตแล้วไม่ตรงกับ Vector ที่เก็บไว้

เพื่อป้องกันปัญหานี้ รูปแบบของ Embedding ถูกปฏิบัติดูแลเสมือนเป็น API ที่มีการเวอร์ชัน (Versioned API) โดยเอกสารแต่ละฉบับจะถูกเข้ารหัสด้วยข้อมูลสำคัญ เช่น:

• ชื่อ Repository ของโมเดล และ Revision ที่แน่นอน
• มิติของ Output
• เวอร์ชันของ Input Format
• การระบุว่าเป็น Query หรือ Document
• วิธีการ Normalization
• Hash ของเนื้อหา (ชื่อเรื่องและ Abstract)

ใน Production ปัจจุบัน ใช้โมเดล Qwen/Qwen3-Embedding-0.6B ที่ถูก Pin ไว้ที่ Revision ที่แน่นอน ด้วย Vector ขนาด 256 มิติ ที่ผ่านการ L2-normalized มาแล้ว การเลือกโมเดลนี้ทำได้โดยอาศัยข้อมูลจาก MTEB leaderboard ซึ่งเป็น Benchmark ชั้นนำสำหรับการเปรียบเทียบโมเดล Embedding

โมเดล Qwen3 ยังมีความสามารถใหม่ๆ ที่น่าสนใจ:

• Dynamic Embedding Size (Matryoshka Representation Learning - MRL): สามารถกำหนดขนาด Embedding แบบไดนามิกได้ ทำให้สามารถแลกเปลี่ยนระหว่างคุณภาพของผลลัพธ์ กับค่าใช้จ่ายด้านความเร็วและพื้นที่จัดเก็บ ใน Papers with Code เลือกใช้ขนาด 256 มิติ เพื่อความรวดเร็วในการค้นหา
• Instruction Prompt: สามารถระบุ Prompt ได้ โดยโมเดล Qwen รองรับ Document Prompt (สำหรับ Embedding เอกสาร) และ Query Prompt (สำหรับ Embedding คำถามของผู้ใช้)

สัญญาการ Embedding นี้ครอบคลุมตั้งแต่การ Export, การประมวลผลผ่าน GPU, การส่งเข้า PostgreSQL, ไปจนถึงการดึงข้อมูลมาใช้ในการค้นหาออนไลน์

Jobs: แปลงฐานข้อมูลให้เป็นคลัง Vector

การสร้าง Embedding สำหรับคลังเอกสารทั้งหมดเป็นงานแบบ Batch ที่ต้องการ GPU เป็นระยะเวลาสั้นๆ แต่ต้องการ Throughput สูง และไม่ควรใช้ทรัพยากรอย่างต่อเนื่องเมื่อไม่ใช้งาน Hugging Face Jobs จึงเหมาะสมกับลักษณะงานนี้ โดย Jobs จะถูกกำหนดด้วยคำสั่ง (Command), ประเภทฮาร์ดแวร์ (Hardware Flavor), และอาจรวมถึง Docker Image

กระบวนการสร้างคลังเอกสารเริ่มต้นด้วยการ Export ข้อมูลเอกสารล่าสุดจาก Snapshot ของ PostgreSQL แบบ Repeatable-read Exporter จะทำการ Stream ข้อมูลเป็นแถว แทนที่จะโหลดทั้งหมดเข้าหน่วยความจำ จากนั้นจะเขียนเป็นไฟล์ JSONL แบบมีขอบเขต (Bounded) และสร้าง Manifest ที่ระบุจำนวนแถวและ Checksum

Directory ของ Run ที่ไม่สามารถเปลี่ยนแปลงได้ (Immutable Run Directory) จะถูก Sync ไปยัง Storage Bucket ส่วนตัว และ Mount เข้ากับ Job (เช่น l4x1 ที่มี NVIDIA L4 GPU 24GB VRAM) โดยจากมุมมองของ Worker มันจะทำหน้าที่เหมือนระบบไฟล์ทั่วไป:

• ตรวจสอบ Manifest และ Checksum ของทุก Shard
• โหลดโมเดล Revision ที่ Pin ไว้
• เรียงลำดับข้อความตามความยาวเพื่อลด Padding
• เรียกใช้ encode_document เป็น Batch
• ลดขนาด Batch ลงอัตโนมัติหาก GPU เต็ม
• ตัด Matryoshka Representation ให้เหลือ 256 มิติ และ Normalize
• เขียน Parquet Shard แบบ Float16 อย่าง Atomic
• บันทึกข้อมูล Throughput, เวอร์ชั่นแพ็คเกจ, ฮาร์ดแวร์, VRAM สูงสุด, จำนวนแถว, และ Checksum ของ Output

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

ในการทดลองกับเอกสาร 5,000 ฉบับ Qwen Job สามารถสร้าง Embedding ได้ประมาณ 75 ฉบับต่อวินาที ที่มิติ 1024 บน L4 GPU และสามารถสร้างผลลัพธ์เดียวกันที่มิติ 512 และ 256 เพื่อเปรียบเทียบ Trade-off ด้านพื้นที่จัดเก็บและการดึงข้อมูล

Buckets: ตัวเชื่อมประสานระบบ

Storage Buckets คือ Object Storage แบบ S3-like ที่สามารถเปลี่ยนแปลงได้บน Hub ซึ่งปรับแต่งมาเพื่องาน AI โดยเฉพาะ สามารถเข้าถึงผ่าน Path hf://buckets/... และ Mount แบบ Read-write ใน Jobs ได้โดยไม่ต้องสร้าง Integration เพิ่มเติม

สำหรับ Papers with Code, Buckets ไม่ได้เป็นเพียงที่เก็บ Vector แต่เป็น "ขอบเขต" ระหว่าง 3 ระบบที่มีวงจรชีวิตต่างกัน:

• ฐานข้อมูล Production Export ข้อมูลต้นฉบับ
• Jobs แบบชั่วคราว (Ephemeral) รับข้อมูลและสร้าง Vector
• Importer ตรวจสอบความถูกต้องก่อนที่จะนำเข้าสู่ Search Index

การจัดระเบียบ Artifacts จะอยู่ภายใต้ Prefix ของ Run ที่ไม่สามารถเปลี่ยนแปลงได้ (Immutable Run Prefixes) แม้ว่า Buckets จะเปลี่ยนแปลงได้ แต่การกำหนดให้ Run ID ไม่ถูกเขียนทับ และ Artifacts ทุกชิ้นมี Manifest และ Checksum ทำให้ได้คุณสมบัติที่สำคัญ:

• Reproducibility: สามารถย้อนรอยการสร้างฐานข้อมูลไปยัง Snapshot, Model Revision, และ Artifacts ที่แน่นอนได้
• Safe Retries: Jobs สามารถทำงานต่อจาก Shard ที่ทำเสร็จแล้วใน Prefix เดิมได้
• Cheap Experiments: การทดลองกับโมเดลหรือมิติต่างๆ สามารถใช้ Snapshot ข้อมูลนำเข้าที่ผ่านการตรวจสอบแล้วร่วมกันได้
• Controlled Rollout: การนำ Generation ใหม่เข้าใช้งาน จะไม่เปิดใช้งานทันที แต่จะมีการตรวจสอบความครอบคลุมและสร้าง Index ก่อน
• Simple Rollback: Generation ก่อนหน้าและ Artifacts จะยังคงอยู่ จนกว่า Generation ใหม่จะได้รับการพิสูจน์ว่าเสถียร

หลังจากการตรวจสอบ Schema, Checksum, มิติ, Normalization, ID ของเอกสารที่ไม่ซ้ำกัน, และ Hash ของเนื้อหา Importer จะทำการโหลด Vector เข้าสู่ PostgreSQL จากนั้นจะสร้าง HNSW Index สำหรับ Generation ใหม่ และจะทำการ Mark ให้เป็น Active แบบ Atomic เมื่อเอกสารปัจจุบันที่มีสิทธิ์ทั้งหมดถูกครอบคลุมแล้ว

Inference Endpoints: นำ Semantic Search มาสู่ Request Path

การสร้าง Embedding สำหรับคลังเอกสารทั้งหมดทำโดย Jobs แต่ Papers with Code มีการเปลี่ยนแปลงอยู่เสมอ เช่น เอกสารใหม่, การแก้ไข Abstract, หรือเวอร์ชัน arXiv ใหม่

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

สำหรับคำถามของผู้ใช้ (User Query) จะต้องถูกสร้าง Embedding ณ เวลาที่ทำการค้นหา โดยใช้โมเดลเดียวกันกับที่ใช้ในการสร้าง Embedding เอกสาร เรา Deploy โมเดลที่ Pin ไว้เป็น Authenticated Inference Endpoint ซึ่งให้บริการโดย Text Embeddings Inference (TEI) Endpoint จะรับข้อความ Query และส่งคืน Vector ขนาด 256 มิติ ที่ Normalize แล้ว โดยใช้ Query Prompt ของโมเดล

API จะทำการค้นหาแบบ Cosine-distance จาก Generation ที่ Active ใน pgvector HNSW Index ช่วยให้การค้นหารวดเร็ว ในการทดลองกับเอกสาร 5,000 ฉบับ Qwen Index ขนาด 256 มิติ สามารถทำ Recall@20 ได้ 0.9955 เทียบกับการค้นหาแบบ Exact โดยมี Latency การค้นหา HNSW อยู่ที่ 1.31 ms (p50) และ 2.21 ms (p95) นอกจากนี้ Table และ Index ยังใช้พื้นที่เพียงประมาณ 27% ของเวอร์ชัน 1024 มิติ โดยยังคงระดับ ANN Recall ใกล้เคียงกัน

Endpoint นี้ถูกตั้งค่าให้มี Replica สูงสุดเพียง 1 ตัว และสามารถ Scale to Zero ได้เมื่อไม่มีการใช้งาน ซึ่งช่วยประหยัดค่าใช้จ่าย แต่ก็หมายความว่าต้องมีการออกแบบแอปพลิเคชันให้รองรับ Cold Start ได้

Client ที่ทำการ Query จึงมีพฤติกรรมที่เข้มงวด:

• ตั้งค่า Timeout 1 วินาที
• จำกัด Concurrency แบบ Non-blocking
• ตรวจสอบมิติ, ความถูกต้อง, และ Norm ของ Response
• มี Cache สั้นๆ โดยใช้ Query และ Embedding Generation เป็น Key
• มี Circuit Breaker เมื่อเกิดความล้มเหลวซ้ำๆ
• ไม่บันทึกข้อความ Query ดิบๆ ใน Log แต่จะบันทึกเป็น Fingerprint ที่ Normalize แล้ว

หาก Endpoint กำลัง Scale Up, หมดเวลา, คืนค่า Vector ที่ผิดปกติ, หรือไม่มี Concurrency เพียงพอ ระบบจะข้ามการค้นหาแบบ Semantic ไปยังการค้นหาแบบ Lexical ทันที ผู้ใช้จึงยังคงได้รับผลลัพธ์ แทนที่จะต้องรอให้ Dependency ที่ไม่เสถียรพร้อมใช้งาน

Inference Endpoints ทำงานได้อย่างน่าเชื่อถือ และมาพร้อมกับ Dashboard ที่แสดง Analytics ที่สำคัญได้อย่างรวดเร็ว

Hybrid Retrieval: แกร่งกว่าเมื่อรวมกัน

สำหรับการ Query แต่ละครั้ง:

• Lexical Branch: ดึง Candidate ได้สูงสุด 50 รายการโดยใช้ PostgreSQL Full-text search แบบถ่วงน้ำหนัก
• Semantic Branch: ดึง Candidate ได้สูงสุด 50 รายการจาก pgvector

ผลลัพธ์จากทั้งสองส่วนจะถูกรวมเข้าด้วยกันด้วย Reciprocal Rank Fusion (RRF) แบบถ่วงน้ำหนัก:
$score(d) = \sum{r \in \{\text{lexical, semantic}\}} \frac{wr}{k + \text{rank}_r(d)}$

RRF เป็นวิธีที่เรียบง่ายและแข็งแกร่ง เพราะเป็นการ

ขอบคุณ แหล่งข้อมูล
https://huggingface.co/blog/pwc-search

Quantization-Aware Healing: โมเดล 4-bit ที่เล็กกว่าแต่ประสิทธิภาพสูงกว่า

ในโลกของปัญญาประดิษฐ์ (AI) การทำให้โมเดลภาษาขนาดใหญ่ (LLMs) มีขนาดเล็กลงและทำงานได้เร็วขึ้น โดยไม่สูญเสียความสามารถ เป็นเป้าหมายสำคัญที่นักวิจัยและนักพัฒนาต่างมุ่งมั่น การบีบอัดโมเดล (Compression) และการลดทอนความแม่นยำของน้ำหนัก (Quantization) เป็นสองวิธีหลักที่ใช้กันอย่างแพร่หลายในการลดขนาดและต้นทุนการประมวลผล แต่บ่อยครั้งที่กระบวนการเหล่านี้ก็นำมาซึ่งการลดทอนประสิทธิภาพของโมเดลเช่นกัน

ล่าสุด งานวิจัย "Quantization-Aware Healing: A Practical Recipe for Recovering Compressed, 4-Bit LLMs" ได้นำเสนอแนวคิดใหม่ที่ท้าทายความเชื่อเดิม ๆ เกี่ยวกับการบีบอัดโมเดล โดยได้พัฒนาเทคนิคที่เรียกว่า Quantization-Aware Healing (QAH) ซึ่งไม่เพียงแต่ทำให้โมเดลมีขนาดเล็กลง แต่ยังสามารถมีประสิทธิภาพที่เหนือกว่าโมเดลต้นฉบับที่มีความแม่นยำเต็มรูปแบบ (Full-Precision) ได้อีกด้วย

ทำไมวิธีการฟื้นฟูแบบเดิมจึงยังไม่เพียงพอ?

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

1. การบีบอัดสถาปัตยกรรม (Compress the architecture): ลดจำนวนพารามิเตอร์ เช่น การตัดเลเยอร์ (Layers), เฮด (Heads) หรือนิวรอน (Neurons)
2. การลดทอนน้ำหนัก (Quantize the compressed weights): ลดความแม่นยำของค่าน้ำหนัก เช่น จาก bfloat16 (16-bit) เป็น 4-bit
3. การฟื้นฟูความเสียหาย (Heal the damage): ปรับปรุงประสิทธิภาพที่ลดลง

วิธีการฟื้นฟูที่นิยมใช้กันคือ Quantization-Aware Training (QAT) ซึ่งเป็นการฝึกฝนโมเดลซ้ำ โดยใส่ตัวดำเนินการ "Fake-Quantization" เข้าไปในขั้นตอนการประมวลผลไปข้างหน้า (Forward Pass) และปรับจูนโมเดลต่อด้วย Loss Function ของงานนั้น ๆ วิธีนี้มีข้อเสียคือใช้ต้นทุนการฝึกสูงมาก และอาจเกิดความไม่เสถียรหากฝึกนานเกินไป

อีกวิธีคือ Quantization-Aware Distillation (QAD) ซึ่งเป็นการกลั่น (Distill) ความรู้จากโมเดลต้นฉบับ (Teacher) ที่มีความแม่นยำเต็มรูปแบบ ไปยังโมเดลที่ถูกลดทอนความแม่นยำ (Student) โดยใช้ KL-divergence loss กับ Output Logits วิธีนี้ใช้ได้ดีเมื่อการเปลี่ยนแปลงมีเพียงแค่การลดทอนความแม่นยำ แต่เมื่อโมเดลผ่านการบีบอัดสถาปัตยกรรมมาด้วย (จำนวนเลเยอร์น้อยลง) จะไม่มีโมเดลต้นฉบับที่มีสถาปัตยกรรมเดียวกันให้ใช้เป็น Teacher ได้ ทำให้ QAD ไม่สามารถดึงศักยภาพสูงสุดของโมเดลออกมาได้

Quantization-Aware Healing (QAH): กุญแจสู่ประสิทธิภาพที่เหนือกว่า

QAH แก้ปัญหาเหล่านี้ด้วยการเปลี่ยนแปลงที่สำคัญ คือ การกลั่นความรู้โดยตรงจากโมเดลต้นฉบับ (Pre-compression model) แทนที่จะกลั่นจากโมเดลที่ถูกบีบอัดและฟื้นฟูแล้ว

💡 หัวใจหลักของ QAH:

• Teacher-Student ต่างสถาปัตยกรรม: QAH สามารถกลั่นความรู้จากโมเดล Teacher ที่มีขนาดใหญ่และมีความแม่นยำเต็มรูปแบบ ไปยังโมเดล Student ที่มีขนาดเล็กกว่าและทำงานในระดับ 4-bit ได้โดยตรง โดยไม่จำเป็นต้องมีสถาปัตยกรรมเดียวกัน
• KL Divergence Loss: ใช้ KL Divergence Loss กับ Output Logits เพื่อให้โมเดล Student เรียนรู้การกระจายความน่าจะเป็น (Output Distribution) จาก Teacher โดยไม่ต้องเห็น Hard Labels
• Quantization เป็นส่วนหนึ่งของการเรียนรู้: แทนที่จะมองว่าการ Quantization เป็นเพียงขั้นตอนหลังการฟื้นฟู QAH มองว่ามันคือการกลั่นความรู้รอบที่สอง ซึ่งช่วยให้โมเดล Student ได้รับข้อมูลที่อาจขาดหายไปในขั้นตอนการฟื้นฟูครั้งแรก
• ความเสถียรในการฝึก: การกลั่นจาก Teacher ที่คงที่ ช่วยให้โมเดล Student ไม่ถูกกดดันให้เปลี่ยนแปลงไปจากเดิมมากนักเมื่อเรียนรู้ถึงจุดที่ใกล้เคียงกับ Teacher แล้ว ซึ่งต่างจาก Cross-Entropy Loss ที่จะคอยผลักดันโมเดลไปสู่ Hard Labels ตลอดเวลา

ผลลัพธ์ที่น่าทึ่ง: โมเดล 4-bit ที่ชนะโมเดล 16-bit

ในการทดสอบกับโมเดล GPT-OSS ขนาด 120B ที่ถูกบีบอัดเหลือ 60B พารามิเตอร์ และลดทอนความแม่นยำเป็น MXFP4 ด้วย QAH พบว่าโมเดล 4-bit นี้ มีประสิทธิภาพเหนือกว่าโมเดล bfloat16 (16-bit) ที่มีสถาปัตยกรรมเดียวกันใน 7 จาก 9 Benchmark ที่ใช้ทดสอบ

📈 จุดเด่นที่น่าสนใจ:

• ประสิทธิภาพที่สูงขึ้น: โมเดล 4-bit สามารถทำคะแนนได้ดีกว่าโมเดล 16-bit ต้นทางในหลาย Benchmark โดยเฉพาะอย่างยิ่งในความสามารถที่มักถูกกระทบจากการบีบอัด เช่น การให้เหตุผลในบริบทที่ยาว (Long-context reasoning) และคณิตศาสตร์
• ประสิทธิภาพเทียบเท่าโมเดลต้นฉบับ: แม้จะมีขนาดเพียงครึ่งเดียวของโมเดล Teacher ต้นฉบับ (120B) แต่โมเดล QAH ก็สามารถทำคะแนนได้ทัดเทียมหรือดีกว่าโมเดล Teacher ในบาง Benchmark เช่น LiveCodeBench
• ความเร็วและความเสถียร: QAH ใช้เวลาในการฝึกน้อยกว่า QAT อย่างมีนัยสำคัญ (ประมาณ 100 Steps เทียบกับ 700 Steps) และมีเสถียรภาพในการฝึกมากกว่า โดยประสิทธิภาพไม่ลดลงอย่างรวดเร็วหลังจากถึงจุดสูงสุด

สิ่งที่ QAH เปลี่ยนแปลงในทางปฏิบัติ

QAH ไม่เพียงแต่ให้ผลลัพธ์ด้านประสิทธิภาพที่น่าประทับใจ แต่ยังตอบโจทย์ด้านประสิทธิภาพการใช้งานจริง:

• ลดการใช้หน่วยความจำ: โมเดล 4-bit ใช้หน่วยความจำน้อยกว่าโมเดล bfloat16 ถึง 4 เท่า
• ลดต้นทุนการประมวลผล: ด้วยจำนวนพารามิเตอร์ที่น้อยลง ทำให้การประมวลผลต่อ Token ลดลง ส่งผลให้สามารถทำงานบนฮาร์ดแวร์ที่มีขนาดเล็กลงได้
• การใช้งานที่คุ้มค่า: การบีบอัดโมเดลด้วย QAH ทำให้โมเดลมีขนาดเล็กลง ต้นทุนการใช้งานต่ำลง แต่กลับให้ประสิทธิภาพที่สูงขึ้น ซึ่งเป็นข้อได้เปรียบอย่างมากสำหรับการนำ LLMs ไปใช้งานจริง

สรุปได้ว่า Quantization-Aware Healing (QAH) เป็นแนวทางใหม่ที่พลิกโฉมการบีบอัดโมเดล ทำให้การ Quantization ไม่ใช่เพียงแค่การแลกประสิทธิภาพเพื่อความประหยัด แต่กลายเป็นการเพิ่มโอกาสในการสอนโมเดลให้มีศักยภาพที่สูงขึ้นไปอีกขั้น

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

#AI #LLM #ModelCompression #Quantization #QAH

ขอบคุณ แหล่งข้อมูล
https://huggingface.co/blog/MultiverseComputingCAI/quantization-aware-healing

Granite 4.2 LLMs: เจาะลึกเบื้องหลังการสร้างโมเดลภาษาอัจฉริยะ

IBM Granite ได้เปิดตัว Granite 4.2 ซึ่งเป็นตระกูลโมเดลภาษาขนาดใหญ่ (LLMs) แบบ Dense, Decoder-only ที่เน้นความสามารถด้านการให้เหตุผล โดยมีให้เลือก 3 ขนาด คือ 3B, 8B และ 30B โมเดลเหล่านี้ได้รับการฝึกฝนตั้งแต่ต้นบนข้อมูลประมาณ 15 ล้านล้านโทเค็น ผ่านกลยุทธ์ 5 ระยะ ซึ่งขยายหน้าต่างบริบท (Context Window) ได้ถึง 512K โทเค็น พร้อมกับการ Fine-tuning แบบมีผู้สอน (Supervised Fine-Tuning - SFT) ด้วยข้อมูล Chain-of-Thought, การให้เหตุผล และ Agentic Trajectory และปิดท้ายด้วยการ Post-training ด้วย Reinforcement Learning (RL) แบบหลายขั้นตอน ซึ่งรวมถึง Agentic RL ที่โมเดล 8B และ 30B เรียนรู้การใช้งานเครื่องมือในสภาพแวดล้อมจำลองจริง โมเดล Granite 4.2 ทุกรุ่นมีฟังก์ชัน "Thinking/Non-thinking Switch" ที่ช่วยให้เลือกโหมดการคิดแบบประหยัดทรัพยากรสำหรับคำถามง่ายๆ และรองรับการเรียกใช้เครื่องมือ (Tool Calling) แบบ Native ทั้งหมดนี้เผยแพร่ภายใต้ลิขสิทธิ์ Apache 2.0

Granite 4.2: ความสามารถด้านการให้เหตุผลที่เหนือกว่า

Granite 4.2 คือการพัฒนาที่เน้นความสามารถด้านการให้เหตุผลของตระกูล Granite Language Model โดยรุ่นก่อนหน้ามีความโดดเด่นในการทำตามคำสั่ง (Instruction Following) ได้ดีเยี่ยม แต่ Granite 4.2 ได้เพิ่มความสามารถในการให้เหตุผลที่ชัดเจนเข้าไปด้วย ทุกโมเดลสามารถสร้าง "Chain of Thought" ก่อนตอบคำถาม และสามารถทำงานในโหมด "Thinking" หรือ "Non-thinking" ได้ ขึ้นอยู่กับความซับซ้อนของงาน นอกจากนี้ยังมีโหมด "Low-effort" ที่ใช้ทรัพยากรการคิดน้อยลงสำหรับคำถามที่ไม่ซับซ้อน

โมเดลทั้งสามขนาด (3B, 8B, 30B) มีสถาปัตยกรรมและการฝึกฝนที่เหมือนกัน ตั้งแต่ Pre-training, SFT ไปจนถึง Multi-stage RL โดยปรับตามขนาดของแต่ละโมเดล ทั้งหมดนี้มีความสามารถในการให้เหตุผลและทำตามคำสั่งที่แข็งแกร่ง จุดที่แสดงความแตกต่างชัดเจนที่สุดคือในขั้นตอน Post-training โดยโมเดล 8B และ 30B จะผ่านกระบวนการ Agentic RL เพิ่มเติม เพื่อเรียนรู้การทำงานแบบ Agent เช่น การเรียกใช้เครื่องมือ, การแก้ไขและรันโค้ด, การควบคุม Terminal และการค้นหาข้อมูลบนเว็บภายในสภาพแวดล้อมจริง ทุกโมเดลรองรับ Native Tool Calling และสามารถทำงานร่วมกับ API ที่เข้ากันได้กับ OpenAI (เช่น ผ่าน vLLM) โดยส่ง Tool Calls ในรูปแบบ OpenAI Function-Calling และสามารถเชื่อมต่อกับ Agentic Harnesses ได้โดยตรง นอกจากนี้ Granite 4.2 ยังรองรับการใช้งานบน SGLang อีกด้วย

สถาปัตยกรรมเบื้องหลัง Granite 4.2

โมเดล Granite 4.2 สร้างขึ้นบนสถาปัตยกรรม Transformer แบบ Dense Decoder-only ที่ประกอบด้วยส่วนประกอบหลักดังนี้:

• Attention: Grouped Query Attention (GQA) พร้อม 40 Attention Heads และ 8 KV Heads
• Position Embedding: Rotary Position Embedding (RoPE) โดยมีค่า θ = 10,000,000
• Feed-Forward: MLP พร้อม Activation SwiGLU
• Normalization: RMSNorm (ε = 1e-5)
• Embeddings: Input/Output Embeddings แยกกัน (ไม่ผูกติดกัน)

กระบวนการ Pre-training: วางรากฐานความรู้

Granite 4.2 ถูกฝึกฝนตั้งแต่ต้นบนข้อมูลประมาณ 15 ล้านล้านโทเค็น โดยใช้กลยุทธ์การฝึก 5 ระยะ:

• ระยะที่ 1-2: เน้นการ Pre-training พื้นฐาน
• ระยะที่ 3-4: การฝึกกลางทาง (Mid-training) โดยใช้ข้อมูลคุณภาพสูงที่ค่อยๆ ปรับปรุง
• ระยะที่ 5: การฝึก Long-Context เพื่อขยาย Context Window ให้ได้ถึง 512K โทเค็น

แต่ละระยะจะใช้ส่วนผสมของข้อมูล (Data Mixture) และตารางการเรียนรู้ (Learning-Rate Schedule) ที่แตกต่างกัน โดยค่อยๆ เปลี่ยนจากการใช้ข้อมูลขนาดใหญ่บนเว็บไปสู่แหล่งข้อมูลที่มีคุณภาพสูงขึ้น

Supervised Fine-Tuning (SFT): การปรับจูนเพื่อความสามารถที่เฉพาะเจาะจง

SFT เป็นขั้นตอนที่เปลี่ยนโมเดลพื้นฐานให้กลายเป็นผู้ช่วยที่สามารถทำตามคำสั่ง, ให้เหตุผล และใช้งานเครื่องมือได้อย่างน่าเชื่อถือ ชุดข้อมูล SFT ประกอบด้วยข้อมูล Agentic (31.6%) และ Non-agentic (68.4%) รวมประมาณ 7.2 ล้านตัวอย่าง หรือราว 100 พันล้านโทเค็น (โดยมี 65 พันล้านโทเค็นที่สามารถฝึกได้)

• คลังข้อมูล Agentic: ครอบคลุมหลากหลายโดเมน เช่น วิศวกรรมซอฟต์แวร์ (SWE, 69%), การเรียกใช้เครื่องมือ (12.1%), การใช้งาน Terminal (8.0%), คณิตศาสตร์ (3.5%), การค้นหา (0.8%) และการดำเนินการ (0.2%) ข้อมูลเหล่านี้สร้างขึ้นจาก Agent Scaffolds และ Harnesses ที่หลากหลาย เช่น OpenHands, OpenCode, Terminus-2, SWE-agent, OpenResearcher, MiniSWE, OpenSeeker, EnvScaler, Gemini CLI, Hermes, Codex และ Goose ข้อมูล Agentic ผสมผสานระหว่างชุดข้อมูลโอเพนซอร์สและข้อมูลที่สร้างขึ้นเองจากสภาพแวดล้อม RL สังเคราะห์
• คลังข้อมูล Non-agentic: ประกอบด้วยหมวดหมู่หลัก เช่น การทำตามคำสั่ง (18.8%), การเขียนโค้ด (18.8%), คณิตศาสตร์ (14.6%), ภาษาต่างประเทศ (7.0%), วิทยาศาสตร์ (5.4%), การให้เหตุผล (3.0%) และความปลอดภัย (0.8%)

การควบคุมคุณภาพข้อมูล (Data Quality Control)

มีการใช้การควบคุมคุณภาพหลายขั้นตอนก่อนที่ตัวอย่างข้อมูลจะถูกนำเข้าสู่ SFT Mixture:

1. การปรับรูปแบบข้อมูล: ข้อมูลจากแหล่งต่างๆ จะถูกทำให้เป็นมาตรฐานและจัดรูปแบบให้อยู่ในรูปแบบ OpenAI Chat ที่สอดคล้องกัน เพื่อให้โครงสร้างการสนทนาและการโต้ตอบกับเครื่องมือเป็นแบบเดียวกัน
2. การใช้ LLM เป็นผู้ตัดสิน: ใช้ GPT-OSS-120B และ Gemma 4 เป็นผู้ตัดสินในการประเมินคุณภาพของตัวอย่างข้อมูล ตัวอย่างที่มีคะแนนต่ำจะถูกลบออก รวมถึงข้อมูลที่มีการหลอน (Hallucination) หรือข้อมูลที่ถูกสร้างขึ้น, การโต้ตอบกับเครื่องมือที่ไม่ถูกต้อง หรือการเรียกใช้เครื่องมือที่ไม่ได้ถูกกำหนดไว้ในรายการเครื่องมือที่เกี่ยวข้อง
3. กฎ Heuristic เฉพาะ: ใช้กฎ Heuristic ที่ปรับให้เหมาะกับแต่ละชุดข้อมูลเพื่อปรับปรุงคุณภาพและลบแหล่งที่มาของ "Noise" ที่ทราบ
4. การขจัดข้อมูลซ้ำซ้อน (Deduplication): ทำทั้งแบบ Local และ Global โดยใช้ SHA-256 Hash ที่คำนวณจากส่วนของเครื่องมือและข้อความ เพื่อลบตัวอย่างที่ซ้ำกันทั้งภายในแหล่งข้อมูลและทั่วทั้ง SFT Mixture

รายละเอียดการฝึก SFT

คลังข้อมูลทั้งหมดจะถูกสุ่ม (Globally Shuffled) ก่อน เพื่อลดผลกระทบจากลำดับการเรียง และรับประกันว่าตัวอย่างจากโดเมนต่างๆ จะถูกผสมผสานกันอย่างดีในการฝึก จากนั้นจะถูกแบ่งออกเป็น .parquet shards ที่มีขนาดเท่ากัน ซึ่งจะถูก Tokenized โดยใช้ Tokenizer ของโมเดลและ Chat Template และเตรียมพร้อมสำหรับการฝึกแบบกระจายขนาดใหญ่ (Large-scale Distributed Training)

ก่อนเริ่มการฝึกขนาดใหญ่ จะมีการปรับ Hyperparameters บนการตั้งค่าที่เป็นตัวแทน โดยทดสอบ Learning-Rate Schedules, Initial Learning Rates และ Warm-up Ratios เพื่อหาค่าที่ทำให้การฝึกมีเสถียรภาพในทุกขนาดของโมเดล

SFT ระยะที่ 2 สำหรับโมเดล 30B

สำหรับโมเดล 30B จะมีการทำ SFT ระยะที่สองเพิ่มเติม โดยเน้นเฉพาะ Agentic Coding โดยข้อมูล Agentic, SWE และ Coding จะถูก Upsample เพื่อเพิ่มการมีส่วนร่วมใน Distribution การฝึก ในขณะที่ประมาณ 16% ของ Mixture จะคงไว้เป็น Replay Data จาก SFT Corpus เดิม จากนั้นโมเดล 30B จะถูก Fine-tune อีกประมาณหนึ่ง Epoch ด้วย Learning Rate ที่ต่ำลง (3.0e-6) ระยะที่สองนี้ช่วยเพิ่มการเรียนรู้ของโมเดลเกี่ยวกับ Agentic Coding Trajectories โดยไม่สูญเสียความสามารถที่ได้รับจาก SFT ระยะแรก

Reinforcement Learning: กระบวนการหลายขั้นตอน หลายสภาพแวดล้อม

หลัง SFT จะใช้กระบวนการ Reinforcement Learning (RL) แบบหลายขั้นตอนและหลายสภาพแวดล้อม แทนที่จะเป็น RL Pass เดียว แต่ละขั้นตอนจะมุ่งเน้นความสามารถเฉพาะ เช่น คณิตศาสตร์, โค้ด, วิทยาศาสตร์, การทำตามคำสั่ง, การใช้เครื่องมือ, โครงสร้างเอาต์พุต, วิศวกรรมซอฟต์แวร์, การใช้ Terminal และการค้นหาเว็บ แต่ละขั้นตอนคือการรัน RL ที่เป็นอิสระ โดยใช้ Checkpoint จากขั้นตอนก่อนหน้าเป็นจุดเริ่มต้น (Warm-start)

![Diagram of Staged RL Curriculum](ขอบคุณ แหล่งข้อมูล
https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/ibm-granite/granite-4-2-rl-curriculum.png)
รูปภาพ: หลักสูตร RL แบบเป็นขั้นตอน (Staged RL Curriculum) โดย Foundational RL (Verifiable Rewards + Skill Boosters) จะใช้กับทุกขนาด ส่วน Agentic RL Block (SWE → Terminal → Search) ใช้กับโมเดล 8B และ 30B เท่านั้น ทุกโมเดลจะจบด้วย RLHF แต่ละขั้นตอนคือการรัน GRPO ที่แยกกัน โดย Warm-start จาก Checkpoint ก่อนหน้า

วิธีการฝึก (Training Methodology)

ทุกขั้นตอนจะฝึกด้วย Asynchronous GRPO (Group Relative Policy Optimization) เพื่อไม่ให้ Generator และ Trainer บล็อกกันเอง โดย Pool ของ Generation Workers จะสุ่มสร้าง Response และส่ง Trajectories ที่เสร็จแล้วไปยัง Buffer ส่วนกลาง เมื่อ Buffer มีข้อมูลครบหนึ่ง Step, Trainer จะดึง Batch นั้นมา, ทำ Optimizer Step และสตรีม Parameter ที่อัปเดตกลับไปยัง Workers โดยไม่หยุดการทำงาน การ Refresh สามารถเกิดขึ้นระหว่าง Rollout ทำให้ Trajectory เดียวประกอบด้วย Policy สองเวอร์ชันที่อยู่ติดกันได้ โดยอนุญาตให้เกิดสิ่งนี้ขึ้นเพื่อประหยัดทรัพยากร Workers จะใช้ KV Cache เดิมโดยไม่ต้องสร้างใหม่หลังการ Refresh และมี Guardrail จำกัดไม่ให้ล้าหลัง Trainer เกินกว่าหนึ่ง Update เพื่อจำกัดความ Off-policy ของ Sample ใดๆ ส่วนความไม่ตรงกันที่เหลือจะถูกจัดการใน Objective ด้วย Truncated Importance Sampling ซึ่งจะจำกัดอัตราส่วน Log-Probability ระหว่าง Train กับ Generation ให้อยู่ในค่าคงที่ เพื่อป้องกันไม่ให้ Token ที่ล้าสมัยจำนวนเล็กน้อยมีอิทธิพลต่อการ Update มากเกินไป

Advantages จะเป็นแบบ Group-Relative โดยมี Leave-one-out Baseline คือแต่ละ Response จะถูกเปรียบเทียบกับค่าเฉลี่ย Reward ของ Sample อื่นๆ ที่สร้างขึ้นสำหรับ Prompt เดียวกัน ซึ่งช่วยลดความจำเป็นในการใช้ Value Network แยกต่างหาก ตัวอย่างเช่น ใน RLVR ซึ่งเป็น Stage แรกและยาวนานที่สุด แต่ละ Step จะจับคู่ 256 Prompts กับ 16 Sampled Responses ทำให้ได้ Batch ขนาด 4,096 ตัวอย่าง ซึ่ง Trainer จะใช้ในการทำ Optimizer Step เพียงครั้งเดียวก่อนที่ Rollout ถัดไปจะเริ่มขึ้น Stage ต่อๆ ไปจะใช้กลไกนี้เหมือนเดิม และปรับเฉพาะ Shape ของแต่ละ Stage เท่านั้น

Pipeline จะรักษา Backbone ของ Hyperparameters ทั่วทั้งทุก Stage ซึ่งช่วยให้การดำเนินงานและเปรียบเทียบหลักสูตรทำได้ง่ายขึ้น มี Knob จำนวนหนึ่งที่คงที่เสมอ:

| Parameter | 3B, 8B, 30B |
| :------------------ | :---------------------------------------- |
| Optimizer | AdamW |
| Learning Rate | 3.0e-5 |
| Warm-up Ratio | 0.03 |
| Weight Decay | 0.1 |
| Batch Size | 4096 (Global) |
| KL Coefficient | 0.1 (Default, adjusted by schedule) |
| Reward Type | Verifiable, Preference, Agentic Outcome |
| Reward Scaling | 1.0 |
| Value Loss Weight | 0.3 |
| Policy Loss Weight | 1.0 |
| Entropy Bonus | 0 (Default, adjusted by schedule) |
| Rollout Turns | 1024 (Default, adjusted by stage) |
| Max Seq Len | 4096 (Default, adjusted by stage) |
| Generation Batching | Yes |
| Replay Buffer Size | 1024 (Default, adjusted by stage) |

สิ่งที่เปลี่ยนแปลงไปในแต่ละ Stage คือ Shape ของแต่ละ Run: จำนวน Prompts และ Generations ต่อ Step, ความยาวของ Context, การทำงานของ Agent Loop และระดับการดึงกลับไปยัง Reference Policy ตารางด้านล่างแสดงการตั้งค่าที่แน่นอนสำหรับ Chain ของ

ขอบคุณ แหล่งข้อมูล
https://huggingface.co/blog/ibm-granite/granite-4-2