LFM2.5 Q4_0: ตรวจสอบจุดแข็งของโมเดล AI ที่พัฒนาด้วย Quantization-Aware Distillation

ในโลกของปัญญาประดิษฐ์ (AI) ที่ก้าวหน้าอย่างรวดเร็ว การทำให้โมเดล AI มีประสิทธิภาพสูงขึ้น ประหยัดทรัพยากร และใช้งานได้จริงบนอุปกรณ์ที่หลากหลายเป็นสิ่งสำคัญอย่างยิ่ง ล่าสุด Liquid AI ได้เปิดตัว LFM2.5 Q4_0 ซึ่งเป็นโมเดลที่พัฒนาขึ้นด้วยเทคนิค Quantization-Aware Distillation (QAD) ที่น่าสนใจอย่างยิ่ง มาดูกันว่าโมเดลนี้มีอะไรดีบ้าง

Quantization-Aware Distillation (QAD) คืออะไร?

QAD เป็นเทคนิคที่ใช้ในการฝึกฝนโมเดล AI โดยมีหลักการคือการถ่ายทอดความรู้ (Distillation) จากโมเดล "ครู" ที่มีความแม่นยำสูง (High-precision teacher model) ไปยังโมเดล "นักเรียน" ที่มีขนาดเล็กลงและใช้ทรัพยากรน้อยลง (Quantized student model) เป้าหมายหลักคือการรักษาความสามารถของโมเดลครูไว้ให้ได้มากที่สุด แม้ว่าโมเดลนักเรียนจะถูกบีบอัดให้มีขนาดเล็กลงก็ตาม

จุดเด่นของ LFM2.5 Q4_0

1. ประสิทธิภาพสูง เทียบเท่า Q4\_0 ดั้งเดิม

โมเดล LFM2.5 Q4\0 ที่พัฒนาด้วย QAD ยังคงรักษาคุณสมบัติเด่นของ GGUF Q4\0 ดั้งเดิมไว้ได้อย่างครบถ้วน นั่นคือ การใช้หน่วยความจำที่ต่ำ และ ความเร็วในการประมวลผลที่สูง (High throughput) ทำให้เหมาะอย่างยิ่งสำหรับการใช้งานบนอุปกรณ์ที่มีทรัพยากรจำกัด

2. กู้คืนความแม่นยำที่สูญเสียไป

จากการทดสอบพบว่า โมเดล LFM2.5 Q4\_0 สามารถ กู้คืนความแม่นยำเฉลี่ยได้ถึง 97% ของความแม่นยำที่สูญเสียไปในระหว่างกระบวนการ Quantization (การบีบอัดข้อมูล) ซึ่งเป็นตัวเลขที่น่าประทับใจอย่างยิ่ง

3. การเปรียบเทียบประสิทธิภาพที่ครอบคลุม

Liquid AI ได้ทำการทดสอบโมเดล LFM2.5 Q4\_0 กับโมเดล GGUF ที่ผ่าน Post-Training Quantization (PTQ) แบบดั้งเดิม โดยใช้ชุดการทดสอบที่หลากหลาย ครอบคลุมทั้งด้านการให้เหตุผล (Reasoning), การทำตามคำสั่ง (Instruction-following), การใช้งานเครื่องมือ (Tool use) และความสามารถในการทำงานแบบ Agentic (Agentic capabilities) การทดสอบเหล่านี้รวมถึง:

• GPQA Diamond
• MMLU-Pro
• IFEval
• IFBench
• Multi-IF
• BFCLv4

นอกจากนี้ยังมีการทดสอบด้านคณิตศาสตร์ที่เหมาะสมกับขนาดของโมเดล เช่น GSM8K สำหรับ LFM2.5-230M และ LFM2.5-350M และ AIME25 สำหรับ LFM2.5-1.2B-Instruct และ LFM2.5-2.6B

ผลการทดสอบแสดงให้เห็นว่า QAD ช่วยปรับปรุงประสิทธิภาพของ Q4\_0 checkpoint ได้อย่างมาก โดยโมเดล QAD สามารถรักษาประสิทธิภาพไว้ได้ถึง 97.1%, 96.5%, 97.4%, และ 96.6% ของ Baseline ประสิทธิภาพ BF16 ตามลำดับ

4. ความเร็วและขนาดบนฮาร์ดแวร์จริง

การวัดอัตราการประมวลผล (Decode throughput) ของโมเดลทั้งสี่ขนาด (LFM2.5-230M, LFM2.5-350M, LFM2.5-1.2B-Instruct, และ LFM2.5-2.6B) บนฮาร์ดแวร์ที่หลากหลาย เช่น MacBook Pro, NucBox EVO-X2, Samsung Galaxy S26 Ultra และ Raspberry Pi 5 แสดงให้เห็นถึงความสามารถในการทำงานจริง

• โมเดลขนาด 230M และ 350M ที่เป็น QAD Q4\0 มีคุณภาพเทียบเท่า Q5\K\_M แต่ให้ อัตราการประมวลผลสูงขึ้น 4-33%
• โมเดลขนาด 1.2B และ 2.6B ที่เป็น QAD Q4\0 มีคุณภาพเทียบเท่า Q4\K\_M แต่ให้ อัตราการประมวลผลสูงขึ้น 3-14%
• นอกจากนี้ QAD Q4\0 ยังมีประสิทธิภาพเทียบเท่ากับ Unsloth's UD-Q4K_XL ซึ่งเป็นโมเดล Quantization ภายนอกที่มีประสิทธิภาพสูงอีกด้วย

5. วิธีการใช้งาน QAD GGUFs

คุณสามารถใช้งานไฟล์ GGUF Q4\0 ที่พัฒนาด้วย QAD ได้อย่างง่ายดาย เพียงใช้กับ llama.cpp หรือ Runtime อื่น ๆ ที่รองรับไฟล์ GGUF Q4\0

6. ดาวน์โหลดโมเดลได้แล้ววันนี้

โมเดล LFM2.5 Q4\_0 GGUFs พร้อมให้ดาวน์โหลดแล้วบน Hugging Face สำหรับทุกขนาด: LFM2.5-230M, LFM2.5-350M, LFM2.5-1.2B-Instruct, และ LFM2.5-2.6B

Liquid AI ตั้งตารอที่จะได้เห็นนวัตกรรมที่คุณจะสร้างสรรค์ขึ้นด้วยโมเดลเหล่านี้!

ข้อมูลอ้างอิง (สำหรับการเขียนงานวิชาการ):

Aditya Tadimeti. (2026, August 19). LFM2.5 Q4\_0 Checkpoints from Quantization-Aware Distillation. Hugging Face Blog. [URL ของบทความต้นฉบับ]

#AI #MachineLearning #LLM #Quantization #HuggingFace

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

Community Evals: เปิดมิติใหม่แห่งการประเมินผล AI โปร่งใส ตรวจสอบได้ โดยชุมชน

ในยุคที่ AI พัฒนาไปอย่างรวดเร็ว การวัดผลและเปรียบเทียบประสิทธิภาพของโมเดล AI กลายเป็นเรื่องท้าทายที่สำคัญ ยิ่งไปกว่านั้น ความน่าเชื่อถือของ "กระดานผู้นำ" (Leaderboards) ที่มักเป็นแบบกล่องดำ (Black-box) ก็ถูกตั้งคำถามอย่างต่อเนื่อง Hugging Face จึงได้เปิดตัว Community Evals เพื่อปฏิวัติวงการประเมินผล AI สู่ความโปร่งใส ตรวจสอบได้ และขับเคลื่อนโดยชุมชนผู้ใช้งานอย่างแท้จริง

ทำไมการประเมินผล AI แบบเดิมจึงมีปัญหา? ⚠️

ปัจจุบัน แม้ว่าโมเดล AI จะทำคะแนนได้สูงในชุดข้อมูลทดสอบมาตรฐาน (Benchmark datasets) เช่น MMLU, GSM8K หรือ HumanEval แต่ในโลกแห่งความเป็นจริง โมเดลเหล่านั้นกลับยังคงมีปัญหาในการทำงานที่ซับซ้อน เช่น การท่องเว็บ การเขียนโค้ดสำหรับใช้งานจริง หรือการจัดการงานที่ต้องทำหลายขั้นตอนโดยไม่เกิดอาการหลอน (Hallucination)

นอกจากนี้ ยังมีความไม่สอดคล้องกันของคะแนนที่รายงานจากแหล่งต่าง ๆ ทั้งใน Model Cards, เอกสารงานวิจัย (Papers) หรือแพลตฟอร์มประเมินผลอื่น ๆ ทำให้ชุมชนขาด "แหล่งความจริงเดียว" (Single source of truth) ที่เชื่อถือได้

Community Evals: ก้าวสู่การประเมินผล AI ที่กระจายศูนย์และโปร่งใส 🤝

Hugging Face Hub กำลังมุ่งหน้าสู่ทิศทางใหม่ในการจัดการการประเมินผล โดยการกระจายอำนาจการรายงานผลและเปิดโอกาสให้ชุมชนผู้ใช้งานสามารถรายงานคะแนนสำหรับ Benchmark ต่าง ๆ ได้อย่างเปิดเผย

สำหรับ Benchmark: Dataset Repos ที่กลายเป็นศูนย์กลาง 📊

• Repository ของ Dataset สามารถลงทะเบียนเป็น Benchmark ได้แล้ว (เช่น MMLU-Pro, GPQA, HLE ที่พร้อมใช้งานแล้ว)
• ระบบจะรวบรวมผลการประเมินที่รายงานจากทั่วทั้ง Hub โดยอัตโนมัติ และแสดงผลบนหน้า Dataset Card
• Benchmark จะกำหนดสเปกการประเมินผ่านไฟล์ eval.yaml ตามรูปแบบ Inspect AI ทำให้ทุกคนสามารถทำการประเมินซ้ำได้ (Reproducible)
• ผลการประเมินที่รายงานจะต้องสอดคล้องกับนิยามของ Task นั้น ๆ

สำหรับ Models: ผลคะแนนที่ฝังอยู่ใน Repository 💻

• ผลคะแนนการประเมินจะถูกจัดเก็บในรูปแบบไฟล์ .eval_results/*.yaml ภายใน Model Repository
• คะแนนเหล่านี้จะปรากฏบน Model Card และถูกส่งต่อไปยัง Dataset Repository ที่เป็น Benchmark
• ทั้งผลคะแนนจากผู้พัฒนาโมเดลเอง และ Pull Requests (PR) สำหรับผลคะแนนจากชุมชน จะถูกรวบรวม
• ผู้พัฒนาโมเดลสามารถเลือกปิด PR หรือซ่อนผลคะแนนบางส่วนได้

สำหรับชุมชน: การมีส่วนร่วมอย่างสร้างสรรค์ 🚀

• ผู้ใช้งานทุกคนสามารถส่งผลการประเมินสำหรับโมเดลใดก็ได้ผ่าน Pull Request (PR)
• ผลการประเมินจะถูกแสดงในสถานะ "community" โดยไม่ต้องรอให้ผู้พัฒนาโมเดลอนุมัติ (Merge) หรือปิด PR
• ชุมชนสามารถอ้างอิงแหล่งที่มาของผลคะแนนได้ เช่น เอกสารงานวิจัย, Model Card, แพลตฟอร์มประเมินผลจากบุคคลที่สาม หรือ Log การประเมิน
• สามารถพูดคุยถกเถียงเกี่ยวกับคะแนนได้เหมือนกับการรีวิว PR ทั่วไป
• เนื่องจาก Hub ใช้ระบบ Git จึงมีประวัติการเพิ่มผลการประเมิน การเปลี่ยนแปลงต่าง ๆ ทำให้มีความโปร่งใส

ประโยชน์ที่คาดไม่ถึงจากการกระจายอำนาจการประเมินผล 💡

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

นอกจากนี้ คะแนนทั้งหมดจะสามารถเข้าถึงได้ผ่าน API ของ Hub ทำให้ง่ายต่อการสร้าง Leaderboards หรือ Dashboards ที่ปรับแต่งได้ตามต้องการ

Community Evals ไม่ได้แทนที่ แต่เสริมพลัง 🌟

Community Evals ไม่ได้มีเป้าหมายเพื่อทดแทน Benchmark เดิม หรือการประเมินผลแบบปิดที่มีผลลัพธ์เผยแพร่ (Closed evals with published results) แต่เป็นการเสริมพลังให้กับวงการด้วยผลการประเมินที่เปิดเผย (Open eval results) บนพื้นฐานของสเปกการประเมินที่สามารถทำซ้ำได้ (Reproducible eval specs)

ถึงแม้ว่าฟีเจอร์นี้อาจไม่สามารถแก้ปัญหา Benchmark Saturation หรือช่องว่างระหว่างคะแนน Benchmark กับประสิทธิภาพจริงได้โดยตรง และอาจไม่สามารถหยุดการเทรนโมเดลบนชุดข้อมูลทดสอบ (Training on test sets) ได้ แต่ก็ทำให้ "เกม" ที่เกิดขึ้นมีความชัดเจนมากขึ้น โดยการเปิดเผยว่าอะไรถูกประเมิน อย่างไร เมื่อไหร่ และโดยใคร

เป้าหมายหลักคือการทำให้ Hugging Face Hub เป็นพื้นที่ที่ทุกคนสามารถเข้ามาสร้างสรรค์และแบ่งปัน Benchmark ที่ทำซ้ำได้ โดยเฉพาะอย่างยิ่งสำหรับ Task และโดเมนใหม่ ๆ ที่ท้าทายโมเดล SOTA (State-of-the-art) มากยิ่งขึ้น

อยากเริ่มต้นใช้งาน?

• อ่านเอกสารเพิ่มเติม: เรียนรู้เกี่ยวกับผลการประเมินได้ที่ [Docs](ขอบคุณ แหล่งข้อมูล
  https://huggingface.co/docs/hub/evals)
• เพิ่มผลการประเมินของคุณ: เผยแพร่ผลการประเมินที่คุณได้ทำไว้ในรูปแบบไฟล์ YAML ในโฟลเดอร์ .eval_results/ บน Model Repository ใดก็ได้
• ตรวจสอบคะแนน: ดูคะแนนบน Dataset ที่เป็น Benchmark ได้ที่ [Hugging Face Hub](ขอบคุณ แหล่งข้อมูล
  https://huggingface.co/datasets)
• ลงทะเบียน Benchmark ใหม่: เพิ่มไฟล์ eval.yaml ใน Dataset Repository ของคุณ และติดต่อเราเพื่อเข้าร่วมในรายชื่อ Benchmark ที่รองรับ

ฟีเจอร์นี้ยังอยู่ในช่วง Beta เรากำลังพัฒนาอย่างเปิดเผย และยินดีรับฟังความคิดเห็นจากทุกท่าน!

#CommunityEvals #HuggingFace #AI #MachineLearning #OpenSource

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

ปริมาณหน่วยความจำที่เอเจนต์ต้องการจริง ๆ คือเท่าไร?

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

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

ALTK-Evolve ช่วยให้เอเจนต์เรียนรู้จากเส้นทางการทำงานที่ผ่านมาของตนเอง กลั่นกรองแนวทางที่นำกลับมาใช้ใหม่ได้ และนำกลับมาใช้ในขั้นตอนการอนุมาน โดยไม่ต้องอัปเดตน้ำหนักโมเดล (weight updates) หรือการใส่คำอธิบายประกอบโดยมนุษย์

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

การดึงข้อมูลที่คัดสรรมาอย่างดีสามารถให้ทั้งความแม่นยำสูงสุดและราคาถูกที่สุด ตัวอย่างเช่น gpt-oss-120b มีประสิทธิภาพการทำงานของงานเพิ่มขึ้น +16.1pp โดยใช้โทเค็นเพิ่มขึ้นเพียง +5% และการแคชพรอมต์ (prompt caching) ก็ช่วยให้ชุดแนวทางทั้งหมดมีราคาที่เข้าถึงได้ในการใช้งานจริง

การให้ "ปริมาณ" หน่วยความจำขึ้นอยู่กับความสามารถของโมเดล

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

1. โมเดลที่แข็งแกร่งและมีศักยภาพเหลืออยู่ (Strong models with headroom)

โมเดลเหล่านี้ต้องการชุดแนวทางทั้งหมด รวมถึงบทเรียนจากกรณีที่เกิดขึ้นไม่บ่อยนัก เนื่องจากมีความสามารถเพียงพอที่จะดูดซับและนำไปใช้ประโยชน์ได้ทั้งหมด ตัวอย่างเช่น DeepSeek-V3.2 (671B MoE) มีประสิทธิภาพการทำงานของงานเพิ่มขึ้น +9.5% เมื่อได้รับชุดแนวทางทั้งหมดที่กลั่นกรองจากตนเอง

2. โมเดลขนาดเล็กหรืออ่อนแอ (Smaller or weaker models)

โมเดลเหล่านี้อาจสับสนหรือจมอยู่กับชุดแนวทางจำนวนมาก สำหรับโมเดลเหล่านี้ วิธีที่ดีที่สุดคือการใช้แกนหลักที่กระชับและมีความเชื่อมั่นสูง ควบคู่ไปกับแนวทางที่เกี่ยวข้องกับงานเพียงไม่กี่อย่างที่ดึงมาใช้ในแต่ละงาน เช่น gpt-oss-120b (117B MoE) มีประสิทธิภาพเพิ่มขึ้น +16.1pp ด้วยแนวทางแบบเลือกนี้ ในขณะที่ชุดแนวทางทั้งหมดให้ผลกำไรน้อยกว่าและมีค่าใช้จ่ายโทเค็นสูงกว่าประมาณ 50%

3. โมเดลที่ถึงขีดจำกัดแล้ว (Already-saturated models)

โมเดลเหล่านี้ไม่แสดงผลกำไรที่วัดได้ เราเรียกรูปแบบนี้ว่า "รูปแบบอิ่มตัว" (saturated pattern) ซึ่งไม่ได้หมายถึงสาเหตุที่พิสูจน์ได้ โมเดลอาจใกล้ถึงขีดจำกัดสูงสุดสำหรับงานเหล่านี้แล้ว แนวทางอาจไม่ได้ครอบคลุมข้อผิดพลาดที่เหลืออยู่ หรือโมเดลอาจไม่สามารถนำแนวทางไปใช้อย่างมีประสิทธิภาพ ตัวอย่างเช่น GLM-5 (745B MoE) อยู่ในกลุ่มนี้จากการทดลองของเรา

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

การเรียนรู้เกิดขึ้นรอบ ๆ โมเดล ไม่ใช่ภายในโมเดล

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

1. เอเจนต์พยายามทำงานและสร้างเส้นทางการทำงาน (trajectories)
2. ALTK-Evolve ดึงเอาแนวทางพฤติกรรมจากทั้งการทำงานที่สำเร็จและไม่สำเร็จ
3. ระบบจะรวบรวมแนวทางเหล่านั้นเป็นชุดที่นำกลับมาใช้ใหม่ได้
4. ในขั้นตอนการอนุมาน เอเจนต์จะได้รับชุดแนวทางทั้งหมด หรือชุดที่เกี่ยวข้องกับงาน

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

ผลลัพธ์ที่ได้จากการทดลองกับโมเดลหลากหลาย

เราทำการประเมินบน AppWorld ซึ่งประกอบด้วย 585 งานที่ต้องทำหลายขั้นตอน (168 งานปกติ + 417 งานท้าทาย) ครอบคลุม 9 แอปพลิเคชันจำลอง (ปฏิทิน, ข้อความ, การชำระเงิน และอื่นๆ) งานต่างๆ จะถูกให้คะแนนสองวิธี:

• TGC (Task Goal Completion): วัดว่าเอเจนต์ทำงานแต่ละงานสำเร็จลุล่วงหรือไม่
• SGC (Scenario Goal Completion): เป็นเกณฑ์ที่เข้มงวดกว่า โดยวัดว่าทุกรูปแบบของสถานการณ์ (scenario) ผ่านเกณฑ์หรือไม่

การกำหนดค่า 3 รูปแบบที่ใช้ในการเปรียบเทียบ

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

• ชุดแนวทางทั้งหมด (Full guideline set): ฉีดแนวทางทั้งหมดเข้าไปในทุกขั้นตอน
• การดึงข้อมูลที่คัดสรร (Curated retrieval): นำเสนอชุดแนวทางที่เลือกสรรมาเฉพาะงาน

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

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

รูปแบบทั้งสามในมุมมองเดียว

โมเดลที่เป็นตัวแทนจากการทดลอง 8 โมเดล วัดผลด้วยการทำงานให้สำเร็จ (TGC) ในชุดทดสอบปกติ:

![รูปภาพแสดงโมเดลที่เป็นตัวแทนใน 3 รูปแบบที่สังเกตได้](ขอบคุณ แหล่งข้อมูล
https://huggingface.co/blog/ibm-research/altk-evolve-hmm/raw/main/appworld-patterns.png)
(หมายเหตุ: รูปภาพประกอบจากต้นฉบับ ไม่สามารถแสดงผลได้โดยตรงในรูปแบบข้อความ)

กราฟแสดง TGC เพื่อให้อ่านง่าย ตารางด้านล่างจะเพิ่มเมตริก SGC ที่เข้มงวดกว่า ซึ่งผลกำไรมักจะมากกว่า:

จากการอ่านคอลัมน์ SGC จะเห็นว่าเมตริกที่เข้มงวดกว่ามักจะมีการเปลี่ยนแปลงมากกว่า TGC เช่น SGC ของ DeepSeek เพิ่มขึ้น +16.1pp เทียบกับ TGC ที่เพิ่มขึ้น +9.5pp ซึ่งแสดงให้เห็นว่าแนวทางที่ดีมีส่วนช่วยอย่างมากในการให้เอเจนต์ทำงานในทุกรูปแบบของสถานการณ์ ไม่ใช่แค่กรณีทั่วไป และผลกระทบนี้ก็ไม่ได้หายไปที่ส่วนบนสุดของช่วง เช่น GPT-5.5 และ Opus ซึ่งใกล้เคียงกับขีดจำกัดของ TGC ยังคงได้รับ SGC เพิ่มขึ้น +7.2 และ +7.1pp ตามลำดับ แสดงว่าหน่วยความจำยังคงให้ผลตอบแทนตราบเท่าที่โมเดลยังมีโหมดความล้มเหลวที่สามารถแก้ไขได้

กลยุทธ์หน่วยความจำที่คุ้มค่าที่สุดก็อาจเป็นกลยุทธ์ที่ดีที่สุด

ข้อกังวลในทางปฏิบัติคือ การใส่ชุดแนวทางทั้งหมดจะเพิ่มอินพุตของขั้นตอน ReAct แต่ละขั้น เนื่องจากแนวทางจะถูกส่งซ้ำทุกครั้ง นี่คือสิ่งที่เราสังเกตได้:

| การกำหนดค่า (Configuration) | การใช้โทเค็นเฉลี่ยต่อการทำงาน (Average token use per task) | การเปลี่ยนแปลงของ TGC (TGC Change) |
| :-------------------------- | :------------------------------------------------------- | :------------------------------- |
| Baseline (No Memory) | 1.00x | - |
| Full Guideline Set | 1.51x | +9.5pp (DeepSeek) |
| Curated Retrieval | 1.05x | +16.1pp (gpt-oss-120b) |

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

การดึงข้อมูลที่คัดสรรช่วยให้ค่าใช้จ่ายใกล้เคียงกับ baseline สำหรับโมเดลที่อ่อนแอกว่า ซึ่งการคัดเลือกให้ผลดีในด้านความแม่นยำ ก็ให้ผลดีในด้านค่าใช้จ่ายเช่นกัน (+16.1pp TGC ด้วยโทเค็นที่เพิ่มขึ้นเพียง +5% สำหรับ gpt-oss-120b) ประสิทธิภาพที่ดีขึ้นที่นี่ไม่จำเป็นต้องใช้ค่าใช้จ่ายในการอนุมานที่สูงขึ้น

หน่วยความจำไม่ได้ทำให้ลูปการใช้เหตุผล (reasoning loop) บวมขึ้น DeepSeek ทำงานประมาณจำนวนขั้นตอน ReAct เท่าเดิมกับตอนที่ไม่มีหน่วยความจำ (เฉลี่ยประมาณ 18-19 ขั้นตอน) ดังนั้น ค่าใช้จ่ายที่เพิ่มขึ้นจึงมาจากการเพิ่มขึ้นของโทเค็นอินพุต ไม่ใช่การทำงานที่ยาวนานขึ้น

คันโยกประสิทธิภาพที่แท้จริงในการใช้งานจริงคือการแคชพรอมต์ (prompt caching): ส่วนที่คงที่ของชุดแนวทางจะเหมือนกันในทุกขั้นตอนและสามารถแคชได้ ซึ่งช่วยลดค่าใช้จ่ายที่แท้จริงลงอย่างมาก การออกแบบพรอมต์ที่คำนึงถึงแคช (Cache-aware prompt design) โดยการทำให้ส่วนแบ่งของชุดแนวทางคงที่ เพื่อให้สามารถแคชได้ เป็นสิ่งที่คุ้มค่ากับการลงทุนทางวิศวกรรม นอกจากนี้ เรายังตั้งสมมติฐานว่าขนาดหน้าต่างบริบทมีบทบาท: โมเดลที่มีหน้าต่างที่ใหญ่กว่าอาจดูดซับชุดแนวทางทั้งหมดได้อย่างมีประสิทธิภาพมากกว่า ในขณะที่โมเดลที่มีบริบทขนาดเล็กจะได้รับประโยชน์จากการดึงข้อมูลที่ช่วยให้เนื้อหาที่แทรกเข้าไปมีความกระชับ เรายังไม่ได้ทำการทดลองที่ควบคุมเพื่อแยกปัจจัยนี้

หน่วยความจำควรได้รับการปรับเทียบ ไม่ใช่แค่สะสม

บทเรียนที่ได้ไม่ใช่การให้เอเจนต์ทุกสิ่งที่มันได้เรียนรู้ แต่เป็นการให้ประสบการณ์ในปริมาณที่มันสามารถนำไปใช้ได้จริง

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

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

นี่เป็นเพียงจุดเริ่มต้น ไม่ใช่จุดสิ้นสุด:

• ตัวเลือกที่เรียนรู้ได้: ปัจจุบันการดึงข้อมูลของเราจะจัดอันดับแนวทางตามความคล้ายคลึงของโคไซน์ (cosine similarity) ซึ่งเราได้แสดงให้เห็นแล้วว่าไม่ได้บ่งชี้อย่างแม่นยำว่าแนวทางใดช่วยในงานที่กำหนด การฝึกตัวเลือกตามสัญญาณผลลัพธ์เป็นขั้นตอนต่อไปที่สมเหตุสมผล
• หน่วยความจำสำหรับโมเดลที่อ่อนแอมาก: ต่ำกว่าเกณฑ์ความสามารถขั้นต่ำ การกลั่นกรองตนเอง (self-distillation) จะขาดสัญญาณ หน่วยความจำที่ได้จากการกลั่นกรองโดยครู (teacher-distilled memory) สำหรับโมเดลที่อ่อนแอมากเป็นปัญหาที่แยกจากกันซึ่งเรากำลังสำรวจ
• นอกเหนือจาก AppWorld: ผลลัพธ์เหล่านี้ได้รับการตรวจสอบบน AppWorld ซึ่งเป็นเกณฑ์

ขอบคุณ แหล่งข้อมูล
https://huggingface.co/blog/ibm-research/altk-evolve-hmm

ทำความรู้จัก Multi-Vector Embedding Models: อนาคตของการค้นหาข้อมูลที่แม่นยำ

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

บทความนี้จะพาคุณไปสำรวจโลกของ Multi-Vector Models ทำความเข้าใจหลักการทำงาน ข้อดี ข้อเสีย และวิธีนำไปใช้งานจริง

Multi-Vector Models คืออะไร?

โมเดล Embedding แบบทั่วไปจะรับข้อความเข้ามา แล้วสร้างเวกเตอร์ (Vector) ที่เป็นตัวแทนของข้อความนั้นออกมาเพียงหนึ่งเดียว การเปรียบเทียบความคล้ายคลึงจึงทำได้โดยการคำนวณความสัมพันธ์ระหว่างเวกเตอร์สองตัวนี้ ซึ่งแม้จะทำงานได้ดีในหลายกรณี แต่ก็มีข้อจำกัดเมื่อข้อความยาว หรือมีเงื่อนไขการค้นหาหลายอย่าง

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

Multi-Vector Models แก้ปัญหานี้โดยการ ไม่บีบอัดข้อมูล แต่จะสร้างเวกเตอร์แยกสำหรับแต่ละ "โทเค็น" (Token) หรือส่วนย่อยของข้อความ ทำให้เอกสารที่มี 9 โทเค็น จะกลายเป็นเมทริกซ์ขนาด 9x128 แทนที่จะเป็นเวกเตอร์เดียวขนาด 1x128

หลักการทำงาน: MaxSim Operator

หัวใจสำคัญของ Multi-Vector Models คือ MaxSim Operator ซึ่งเป็นวิธีการคำนวณคะแนนความคล้ายคลึงที่แตกต่างออกไป โดยจะเปรียบเทียบโทเค็นของคำถาม (Query) กับโทเค็นทั้งหมดของเอกสาร (Document) แล้วเลือกค่าความคล้ายคลึงสูงสุดสำหรับแต่ละโทเค็นคำถาม จากนั้นจึงนำค่าสูงสุดเหล่านั้นมารวมกัน

สูตร MaxSim:
MaxSim(Q, D) = ∑Qi ∈ Q maxDj ∈ D Qi ⋅ Dj

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

ข้อดีคือ วิธีนี้ช่วยให้สามารถจับคู่คำที่มีความหมายเหมือนกัน (Synonyms) หรือการใช้คำที่แตกต่างแต่มีความหมายใกล้เคียงกันได้ดีขึ้น โดยไม่จำเป็นต้องเป็นคำเดียวกันเป๊ะๆ เช่น คำว่า "live" ในคำถาม อาจไปจับคู่กับคำว่า "inhabit" ในเอกสารได้ แม้จะไม่มีตัวอักษรเหมือนกันเลยก็ตาม

สิ่งที่ได้รับ และสิ่งที่ต้องแลก

สิ่งที่ได้รับ ✅

• ความแม่นยำในการค้นหาสูงขึ้น: โดยเฉพาะอย่างยิ่งเมื่อคำถามมีความเฉพาะเจาะจง หรือต้องการค้นหาข้อมูลบางส่วนที่สำคัญในเอกสารยาวๆ
• การจัดการกับคำถามที่มีหลายเงื่อนไข: แต่ละเงื่อนไขสามารถหาหลักฐานสนับสนุนของตัวเองได้ ทำให้ผลลัพธ์ตรงกับความต้องการมากขึ้น
• ความยืดหยุ่น: สามารถจัดการกับข้อมูลที่อยู่นอกเหนือจากการฝึกฝนของโมเดลแบบเวกเตอร์เดียวได้ดีกว่า
• การค้นหาเชิงภาพ (Visual Document Retrieval): เหมาะอย่างยิ่งสำหรับการจับคู่คำถามที่เป็นข้อความกับรูปภาพของเอกสารโดยตรง โดยไม่ต้องผ่านการแปลงข้อความเป็นตัวอักษร (OCR)

สิ่งที่ต้องแลก ⚠️

• ขนาด Index ที่ใหญ่ขึ้น: การเก็บเวกเตอร์จำนวนมากต่อเอกสาร ย่อมใช้พื้นที่จัดเก็บมากกว่าโมเดลเวกเตอร์เดียวอย่างหลีกเลี่ยงไม่ได้ แม้ว่ามิติของเวกเตอร์แต่ละตัวจะเล็กลงก็ตาม
• อย่างไรก็ตาม เทคนิคการบีบอัด Index เช่น PLAID สามารถช่วยลดขนาดพื้นที่จัดเก็บลงได้ ทำให้ขนาด Index ใกล้เคียงกับโมเดลแบบดั้งเดิม

การใช้งาน Multi-Vector Models กับ Sentence Transformers

การเริ่มต้นใช้งาน Multi-Vector Models กับ Sentence Transformers นั้นง่ายดาย เพียงติดตั้งไลบรารีที่จำเป็น

pip install -U sentence-transformers

หากต้องการใช้งานสำหรับการค้นหาเชิงภาพ (Visual Document Retrieval) อาจต้องติดตั้ง Dependencies เพิ่มเติมสำหรับจัดการรูปภาพ

การโหลดโมเดล 🛠️

การโหลดโมเดล Multi-Vector ทำได้เหมือนกับการโหลดโมเดล Sentence Transformers ทั่วไป เพียงระบุชื่อโมเดลที่รองรับ

from sentence_transformers import SentenceTransformer



# โหลดโมเดล Multi-Vector

model = SentenceTransformer('lightonai/LateOn')

คุณสามารถค้นหาโมเดลที่รองรับได้บน Hugging Face Hub โดยมองหา Tag ที่เกี่ยวข้อง เช่น multi-vector และ sentence-transformers

การเข้ารหัส (Encoding) Queries และ Documents 📝

Multi-Vector Models มีความแตกต่างระหว่างการเข้ารหัสคำถาม (Query) และเอกสาร (Document) โดยเฉพาะการใช้ Prefixes, การกำหนดความยาวสูงสุด (Length Caps) และการกำหนด Token ที่จะข้ามไปในการคำนวณคะแนน

# เข้ารหัสคำถาม

query_embeddings = model.encode_query("What is the weather like today?")



# เข้ารหัสเอกสาร

document_embeddings = model.encode_document("The weather today is sunny with a slight breeze.")

ผลลัพธ์ที่ได้จะเป็น List ของ 2D Tensors โดยแต่ละ Tensor แทนเวกเตอร์ของแต่ละ Token ซึ่งจะมีรูปร่างแตกต่างกันไปตามจำนวน Token ของแต่ละ Input

การคำนวณคะแนน (Scoring) 📊

หลังจากได้ Embeddings แล้ว คุณสามารถใช้เมธอด model.similarity() เพื่อคำนวณคะแนนความคล้ายคลึงระหว่าง Embeddings ทั้งหมดได้

# สมมติว่ามี query_embeddings และ document_embeddings จากตัวอย่างก่อนหน้า

# หากต้องการเปรียบเทียบหลายๆ เอกสารกับหลายๆ คำถาม

# scores = model.similarity(query_embeddings, document_embeddings)

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

การปรับแต่งโมเดล

โมเดล Multi-Vector มีการตั้งค่าบางอย่างที่สามารถปรับแต่งได้ เช่น queryprefix, documentprefix, maxlength สำหรับ Query และ Document รวมถึง skiptokens ที่จะถูกข้ามไปในการคำนวณคะแนน การตั้งค่าเหล่านี้จะอยู่ใน config ของโมเดล ซึ่งสามารถตรวจสอบได้ด้วยการ print(model)

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

ข้อควรพิจารณาเพิ่มเติม

• Document Length Cap: การกำหนด documentlength จะเป็นการตัดส่วนของเอกสารที่เกินกว่าค่าที่กำหนดออกไปก่อนที่จะถูก Index หาก Chunk ข้อมูลของคุณยาวกว่าค่า Cap ที่โมเดลถูกฝึกมา อาจพิจารณาเพิ่มค่านี้ในการเรียก encodedocument แต่ต้องคำนึงว่า Index จะมีขนาดใหญ่ขึ้น และโมเดลอาจทำงานนอกเหนือขอบเขตที่เคยฝึกมา
• Asymmetric Nature: โปรดจำไว้ว่าโมเดลเหล่านี้มีลักษณะไม่สมมาตร (Asymmetric) การใช้ encodequery() และ encodedocument() แยกกันจึงเป็นสิ่งจำเป็นเพื่อให้ได้ผลลัพธ์ที่ถูกต้อง

สรุป

Multi-Vector Embedding Models ที่ทำงานร่วมกับ Sentence Transformers เป็นก้าวสำคัญในการพัฒนาเทคโนโลยีการค้นหาข้อมูลให้มีความแม่นยำและละเอียดอ่อนมากยิ่งขึ้น แม้จะมีข้อแลกเปลี่ยนเรื่องขนาด Index แต่ด้วยเทคนิคการบีบอัดและประสิทธิภาพที่ได้รับ ทำให้โมเดลเหล่านี้เป็นทางเลือกที่น่าสนใจอย่างยิ่งสำหรับแอปพลิเคชันที่ต้องการการค้นหาข้อมูลที่เหนือกว่า

#MultiVectorEmbeddings #SentenceTransformers #AI #NLP #InformationRetrieval

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

SyGra Studio: เครื่องมือสร้างสรรค์ข้อมูลสังเคราะห์แบบ Visual Workflow ที่ทรงพลัง

การสร้างข้อมูลสังเคราะห์ (Synthetic Data Generation) สำหรับการฝึกฝนโมเดล AI หรือการทดสอบระบบ เป็นกระบวนการที่ซับซ้อนและต้องใช้ความเชี่ยวชาญ หากทำด้วยวิธีแบบเดิมๆ ที่ต้องเขียนโค้ดหรือแก้ไขไฟล์ YAML ด้วยตนเอง อาจทำให้เกิดความผิดพลาดและเสียเวลาได้ วันนี้เราจะมาทำความรู้จักกับ SyGra Studio เครื่องมือใหม่จาก ServiceNow-AI ที่จะเปลี่ยนการสร้างข้อมูลสังเคราะห์ให้เป็นเรื่องง่าย สนุก และมีประสิทธิภาพยิ่งขึ้น ด้วยการทำงานแบบ Visual Workflow ที่ใครๆ ก็ใช้งานได้

SyGra Studio ทำอะไรได้บ้าง? 💡

SyGra Studio ถูกออกแบบมาเพื่อช่วยให้ผู้ใช้สามารถสร้างและจัดการ Workflow การสร้างข้อมูลสังเคราะห์ได้อย่างครอบคลุม ตั้งแต่ต้นจนจบ โดยมีฟีเจอร์เด่นๆ ดังนี้:

• การตั้งค่าและตรวจสอบโมเดลที่หลากหลาย: รองรับโมเดลภาษาขนาดใหญ่ (LLM) จากผู้ให้บริการชั้นนำหลายราย เช่น OpenAI, Azure OpenAI, Ollama, Vertex AI, Bedrock, vLLM รวมถึง Custom Endpoints ทำให้ยืดหยุ่นในการเลือกใช้โมเดลที่เหมาะสม
• เชื่อมต่อแหล่งข้อมูลได้หลายรูปแบบ: สามารถเชื่อมต่อกับ Hugging Face, ระบบไฟล์ (File-system) หรือข้อมูลจาก ServiceNow โดยตรง พร้อมทั้งแสดงตัวอย่างข้อมูล (Preview Rows) ก่อนเริ่มการประมวลผลจริง
• ออกแบบ Workflow แบบ Visual: ลากวาง "บล็อก" (Nodes) ที่ต้องการใช้งาน แล้วกำหนดค่าต่างๆ เช่น เลือกโมเดล, เขียน Prompt พร้อมระบบช่วยแนะนำตัวแปร (Auto-suggested Variables), และกำหนดรูปแบบผลลัพธ์ (Output Schemas) ได้อย่างง่ายดาย
• จัดการข้อมูลและตัวแปร: สร้างผลลัพธ์ที่ซับซ้อนขึ้นโดยใช้ Shared State Variables และ Pydantic-powered Mappings เพื่อให้การส่งต่อข้อมูลระหว่าง Node เป็นไปอย่างราบรื่น
• รันและตรวจสอบผลลัพธ์ทันที: สามารถสั่งประมวลผล Workflow ทั้งหมด และดูผลลัพธ์ที่สร้างขึ้นได้ทันที พร้อมสถานะการทำงานของแต่ละ Node
• เครื่องมือช่วย Debug ที่ครบครัน: มีระบบการแสดง Log แบบ Inline, Breakpoints, Monaco-backed Code Editors และระบบบันทึกร่างอัตโนมัติ (Auto-saved Drafts) ช่วยให้การแก้ไขปัญหาทำได้รวดเร็ว
• ติดตามค่าใช้จ่ายและประสิทธิภาพ: ตรวจสอบค่าใช้จ่าย Token, Latency และผลลัพธ์ของ Guardrail ในแต่ละครั้งที่รัน พร้อมบันทึกประวัติการทำงานทั้งหมดไว้ในโฟลเดอร์ .executions/

เริ่มต้นใช้งาน SyGra Studio: Step-by-Step 🛠️

ขั้นตอนที่ 1: ตั้งค่าแหล่งข้อมูล (Configure the Data Source)

1. เปิด SyGra Studio และคลิก Create Flow จะปรากฏ Node เริ่มต้น (Start/End) โดยอัตโนมัติ
2. เลือก Connector ที่ต้องการใช้งาน (Hugging Face, Disk, หรือ ServiceNow)
3. กรอกพารามิเตอร์ที่จำเป็น เช่น repo_id, split, หรือ file path จากนั้นคลิก Preview เพื่อดูข้อมูลตัวอย่าง
4. ชื่อคอลัมน์ข้อมูลจะถูกแปลงเป็น State Variables ทันที (เช่น {prompt}, {genre}) ทำให้ทราบว่าสามารถอ้างอิงตัวแปรใดได้บ้างภายใน Prompt หรือ Processor
5. เมื่อข้อมูลถูกต้อง Studio จะทำการ Sync การตั้งค่าและส่งต่อตัวแปรเหล่านี้ไปยัง Node อื่นๆ ใน Workflow โดยอัตโนมัติ

ขั้นตอนที่ 2: สร้าง Workflow (Build the Flow Visually)

สำหรับตัวอย่างการสร้าง Workflow สร้างเรื่องราว (Story Generation Pipeline):

1. ลาก Node LLM ชื่อ “Story Generator” มาวาง
2. เลือกโมเดลที่ตั้งค่าไว้ (เช่น gpt-4o-mini)
3. เขียน Prompt เพื่อสร้างเนื้อเรื่อง และกำหนดให้ผลลัพธ์ถูกเก็บในตัวแปร story_body
4. ลาก Node LLM อีกตัว ชื่อ “Story Summarizer” มาวาง
5. อ้างอิงตัวแปร {storybody} ใน Prompt เพื่อสรุปเรื่องราว และกำหนดให้ผลลัพธ์ถูกเก็บใน storysummary
6. สามารถปรับแต่งเพิ่มเติม เช่น การตั้งค่า Structured Outputs, การ Attach Tools หรือการเพิ่ม Lambda/Subgraph Nodes สำหรับ Logic ที่ใช้ซ้ำหรือการแตกแขนง
7. Panel รายละเอียดของ Studio จะแสดงข้อมูลทั้งหมดให้เห็นอย่างชัดเจน ทั้งพารามิเตอร์โมเดล, Editor Prompt, การตั้งค่า Tool, โค้ด Pre/Post-process และการตั้งค่า Multi-LLM หากต้องการสร้างผลลัพธ์แบบขนาน การพิมพ์ { ใน Prompt จะแสดงรายการ State Variables ที่พร้อมใช้งานทั้งหมดทันที

ขั้นตอนที่ 3: ตรวจสอบและรัน Workflow (Review and Run)

1. เปิด Code Panel เพื่อตรวจสอบโค้ด YAML/JSON ที่ Studio สร้างขึ้น ซึ่งเป็นไฟล์เดียวกับที่จะถูกบันทึกใน tasks/examples/
2. เมื่อพร้อมแล้ว ให้กำหนดค่าต่างๆ ในหน้า Run Modal เช่น จำนวน Record, Batch Size, การ Retry
3. กด Run และสังเกต Execution Panel ที่จะแสดงสถานะของแต่ละ Node, การใช้งาน Token, Latency และ Cost แบบ Real-time พร้อม Log ที่ละเอียดช่วยให้ Debug ได้ง่าย
4. หลังจากรันเสร็จ สามารถดาวน์โหลดผลลัพธ์, เปรียบเทียบกับผลลัพธ์ก่อนหน้า, และดู Metadata เกี่ยวกับ Latency และการใช้งานต่างๆ ได้

การรัน Workflow ที่มีอยู่แล้ว 🚀

SyGra Studio ยังสามารถรัน Workflow ที่สร้างไว้แล้วได้ เช่น Workflow ของ Glaive Code Assistant ที่อยู่ใน tasks/examples/glaivecodeassistant/ ซึ่ง Workflow นี้จะทำการดึงข้อมูลจาก glaiveai/glaive-code-assistant-v2, ร่างคำตอบ, ตรวจสอบคำตอบ และวนลูปจนกว่าการตรวจสอบจะพอใจ

• Canvas Layout: จะเห็น Node LLM สองตัว (generateanswer และ critiqueanswer) เชื่อมต่อกันด้วย Conditional Edge ที่สามารถวนกลับมาแก้ไข หรือออกไปยัง END ได้
• Tunable Inputs: หน้า Run Modal ช่วยให้คุณสามารถสลับ Dataset Split, ปรับ Batch Size, จำกัดจำนวน Record หรือปรับ Temperature ได้โดยไม่ต้องแก้ไขไฟล์ YAML
• Observable Execution: คุณจะเห็น Node ทั้งสองทำงานตามลำดับ, ตรวจสอบผลการ Critique แบบ Intermediate, และติดตามสถานะแบบ Real-time
• Generated Outputs: ข้อมูลสังเคราะห์จะถูกสร้างขึ้น พร้อมใช้งานสำหรับ Model Training, Evaluation Pipelines หรือ Annotation Tools

สรุป

SyGra Studio เป็นแพลตฟอร์มที่ยอดเยี่ยมสำหรับการสร้าง Workflow การสร้างข้อมูลสังเคราะห์แบบ Visual ที่ใช้งานง่าย ช่วยลดความยุ่งยากในการเขียนโค้ดหรือแก้ไขไฟล์ YAML คุณสามารถตั้งค่า, สร้างสรรค์, รัน และตรวจสอบผลลัพธ์ได้อย่างมั่นใจ โดยไม่ต้องออกจากหน้าจอ Studio เลย

เอกสารเพิ่มเติม:

• [SyGra Docs](ขอบคุณ แหล่งข้อมูล
  https://servicenow.github.io/SyGra/)
• [Studio Docs](ขอบคุณ แหล่งข้อมูล
  https://servicenow.github.io/SyGra/gettingstarted/createtask_ui/)
• [Example Config](ขอบคุณ แหล่งข้อมูล
  https://github.com/ServiceNow/SyGra/blob/main/tasks/examples/glaivecodeassistant/graph_config.yaml)

#SyGraStudio #SyntheticData #AI #MachineLearning #LLM #WorkflowAutomation

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

จัดการ GPU ให้คุ้มค่า: เปลี่ยนลำดับการจัดสรร เพิ่มประสิทธิภาพได้ถึง 33% 🚀

เคยสงสัยไหมว่าทำไม GPU ของคุณถึงทำงานได้ไม่เต็มที่ ทั้งที่ก็มีงานค้างอยู่เต็มไปหมด? ปัญหาอาจไม่ได้อยู่ที่ฮาร์ดแวร์ แต่อยู่ที่ "ลำดับ" การจัดสรรงานต่างหาก! บทความนี้จะพาคุณไปดูเบื้องหลังการปรับปรุงระบบจัดสรร GPU ที่ช่วยเพิ่มประสิทธิภาพการใช้งานได้สูงถึง 33% โดยไม่ต้องเปลี่ยนเครื่องใหม่เลย

เมื่อการจัดลำดับงานส่งผลต่อประสิทธิภาพ 📊

ในโลกของการประมวลผล GPU ที่มีงานหลากหลายประเภท ทั้งการเทรนโมเดล, การอนุมานแบบเรียลไทม์ (Real-time Inference), การอนุมานแบบแบทช์ (Batch Inference) และการทำ Quantization แต่ละประเภทมีความต้องการทรัพยากรที่แตกต่างกัน บางงานต้องการ GPU จำนวนมากต่อเนื่องกันไปจนกว่าจะเสร็จ (Batch-like) ในขณะที่บางงานต้องการความยืดหยุ่นสูง ตอบสนองต่อความต้องการที่เปลี่ยนแปลงตลอดเวลา (Real-time)

ความท้าทายอยู่ที่การจัดสรร GPU ให้กับงานเหล่านี้ โดยเฉพาะเมื่อทรัพยากรมีจำกัดและงานแข่งขันกันเอง ระบบจัดสรรแบบ FIFO (First-In, First-Out) ที่จัดงานตามลำดับการเข้ามา อาจทำให้เกิดปัญหาเหล่านี้:

• การจอง GPU ล่วงหน้ามากเกินไป: งาน Real-time Inference ที่มีความต้องการสูงสุดในช่วงเวลาหนึ่ง อาจทำให้ต้องจอง GPU จำนวนมากตลอดทั้งวัน ทั้งที่ช่วงเวลาอื่นอาจใช้เพียงไม่กี่ตัว GPU ที่เหลือจึงไม่ได้ถูกใช้งานและไม่สามารถนำไปให้งานอื่นได้
• การจัดลำดับงานที่ไม่มีประสิทธิภาพ: งานที่มีความสำคัญสูงอาจต้องรอคิวนานกว่างานที่เข้ามาทีหลัง ทำให้เสียโอกาสในการประมวลผลที่มีมูลค่า

ระบบจัดสรรแบบใหม่: จัดลำดับอย่างไรให้ได้ผลลัพธ์ดีขึ้น? 🤔

ระบบจัดสรร GPU แบบใหม่นี้ถูกออกแบบมาเพื่อแก้ปัญหาดังกล่าว โดยพิจารณาทั้ง "การใช้งาน" (Utilization) และ "มูลค่าของงาน" (Priority-weighted Output) ไปพร้อมๆ กัน

สิ่งที่ระบบจัดสรรใหม่ทำได้:

1. จัดการงาน Real-time แบบยืดหยุ่น: แทนที่จะจอง GPU ตามความต้องการสูงสุด ระบบจะจัดสรรตามความต้องการจริงในแต่ละช่วงเวลา ทำให้ GPU ว่างเว้นจากการจองในช่วงที่ความต้องการต่ำ และสามารถนำไปให้งานประเภทอื่นใช้งานได้
2. จัดลำดับงานตามความสำคัญ: งานที่มีลำดับความสำคัญสูงจะได้รับการจัดสรรก่อน โดยพิจารณาจาก "มูลค่า" ที่จะได้รับ แทนที่จะเป็นเพียงลำดับการเข้ามา
3. มองภาพรวมทั้งหมด: ระบบสามารถมองเห็นงานที่ค้างอยู่ทั้งหมด และจัดสรร GPU ให้เหมาะสมกับ "รูปร่าง" (Shape) ที่งานต้องการได้อย่างมีประสิทธิภาพ

ผลลัพธ์ที่วัดได้:

จากการทดสอบใน 7 สถานการณ์ที่แตกต่างกัน โดยใช้ฮาร์ดแวร์และเวิร์กโหลดเดียวกัน พบว่า:

• การใช้งาน GPU เพิ่มขึ้น: จากเดิมที่อยู่ในช่วง 52–85% สามารถเพิ่มขึ้นเป็น 72–88% ในหลายสถานการณ์
• มูลค่าของงานเพิ่มขึ้นอย่างมีนัยสำคัญ: ตั้งแต่ 24.6% ไปจนถึง 105.1% โดยเฉลี่ยอยู่ที่ 52%

ตัวอย่างที่โดดเด่น: ในกรณีที่เน้นการเทรนโมเดลบน GPU 8 ตัว การใช้งานเพิ่มขึ้นจาก 53.6% เป็น 87.0% และมูลค่าของงานเพิ่มขึ้นกว่าเท่าตัว (105%)

ความสำคัญของการวัดผลที่ถูกต้อง ✅

การใช้งาน GPU ที่สูงขึ้นอย่างเดียวอาจไม่เพียงพอ หากไม่ได้งานที่มีมูลค่าสูงมาด้วย ระบบจัดสรรใหม่นี้จึงวัดผลทั้งสองด้าน:

• Utilization: วัดว่า GPU ถูกใช้งานไปเท่าใด
• Priority-weighted Output: วัดมูลค่าที่แท้จริงของงานที่ประมวลผลได้ โดยให้น้ำหนักกับงานที่มีลำดับความสำคัญสูง

ในบางกรณี ระบบ FIFO อาจให้ผลการใช้งาน (Utilization) ที่เท่ากัน แต่ระบบใหม่สามารถส่งมอบมูลค่า (Value) ที่สูงกว่าได้อย่างชัดเจน

เบื้องหลังการทำงาน: การจำกัดความของปัญหา 🛠️

การจัดสรร GPU ที่มีประสิทธิภาพสูงสุดต้องอาศัยการแก้ปัญหาที่ซับซ้อน โดยมีข้อจำกัดที่สำคัญ 5 ประการ:

1. GPU หนึ่งตัวรองรับได้เพียงหนึ่งงานต่อช่วงเวลา
2. งานต้องเป็นไปตามช่วงความต้องการและรักษาทรัพยากรที่กำลังใช้งานอยู่
3. งานแบบ Batch ต้องการ GPU จำนวนเต็มบล็อก (Power of two)
4. งาน Real-time มีข้อจำกัดในการเปลี่ยนแปลงจำนวน GPU ระหว่างช่วงเวลา
5. งานที่เริ่มแล้วจะไม่ถูกขัดจังหวะ

ส่วน "ฟังก์ชันวัตถุประสงค์" (Objective Function) จะคำนวณมูลค่าโดยการนำลำดับความสำคัญของงานคูณกับน้ำหนักเวลาที่ลดลง และมี "บทลงโทษ" หากไม่สามารถตอบสนองความต้องการของงาน Real-time ได้ ซึ่งบทลงโทษนี้จะสูงกว่ามูลค่าที่ได้จากงาน Batch อย่างมีนัยสำคัญ เพื่อให้มั่นใจว่างาน Real-time จะได้รับการตอบสนอง

ไม่ใช่แค่การเรียงลำดับ แต่คือการวางแผน 🧠

ระบบจัดสรรใหม่นี้ไม่ใช่แค่การเรียงลำดับงาน แต่เป็นการ "วางแผน" การใช้ทรัพยากร GPU ล่วงหน้า โดยพิจารณางานทั้งหมดที่ค้างอยู่ และสามารถจัดสรร GPU ให้ตรงกับ "รูปร่าง" ที่งานต้องการได้อย่างมีประสิทธิภาพ

• FIFO: จัดงานตามลำดับที่เข้ามา อาจทำให้งานที่ต้องการ GPU รูปแบบเฉพาะหาทรัพยากรที่เหลือไม่ได้
• ระบบใหม่: มองเห็นภาพรวม จัดสรร GPU ให้มี "ช่องว่าง" เหลือสำหรับงานที่ต้องการรูปทรงเฉพาะเหล่านั้น และใช้ลำดับความสำคัญในการตัดสินใจว่าใครจะได้ใช้ก่อน

ข้อควรจำ: ข้อมูลที่ใช้ในการคาดการณ์สำคัญไม่แพ้กัน 💡

ประสิทธิภาพของระบบจัดสรรนี้ขึ้นอยู่กับความแม่นยำของการคาดการณ์ความต้องการ GPU ของแต่ละงาน และปริมาณทราฟฟิกของงาน Real-time การคาดการณ์ที่แม่นยำจะช่วยให้ระบบสามารถจัดสรรทรัพยากรได้อย่างเหมาะสมที่สุด

การปรับปรุงระบบจัดสรร GPU ให้มีประสิทธิภาพไม่ใช่เรื่องซับซ้อนเกินไป การเปลี่ยนจากการจัดลำดับแบบ FIFO แบบเดิมๆ มาสู่ระบบที่ชาญฉลาดขึ้น สามารถเพิ่มประสิทธิภาพการใช้งาน GPU และสร้างมูลค่าให้กับธุรกิจได้อย่างมหาศาล

#GPU #การจัดการทรัพยากร #ประสิทธิภาพ #AI

ขอบคุณ แหล่งข้อมูล
https://huggingface.co/blog/Dharma-AI/gpu-management-pt2

Transformers.js v4 เปิดตัวแล้ว! ยกระดับ AI บนเว็บให้เร็ว แรง และยืดหยุ่นกว่าเดิม

Hugging Face ประกาศเปิดตัว Transformers.js v4 เวอร์ชันใหม่ล่าสุด ที่มาพร้อมการปรับปรุงครั้งใหญ่เพื่อยกระดับประสบการณ์การใช้งาน AI บนเว็บให้ดียิ่งขึ้น ทั้งในด้านประสิทธิภาพ ความยืดหยุ่น และการรองรับโมเดลที่หลากหลาย การอัปเดตครั้งนี้ไม่เพียงแต่ทำให้การพัฒนาแอปพลิเคชัน AI บนเบราว์เซอร์และสภาพแวดล้อม JavaScript อื่นๆ ง่ายขึ้น แต่ยังเปิดประตูสู่ความเป็นไปได้ใหม่ๆ ในการนำ AI ไปใช้จริง

ปรับปรุงประสิทธิภาพด้วย WebGPU Runtime ใหม่ 🚀

หัวใจสำคัญของการอัปเดต v4 คือการนำ WebGPU Runtime ที่เขียนขึ้นใหม่ทั้งหมดด้วยภาษา C++ มาใช้งาน ซึ่งพัฒนาขึ้นโดยความร่วมมือกับทีม ONNX Runtime การเปลี่ยนแปลงนี้ส่งผลให้:

• ความเร็วที่เหนือกว่า: WebGPU Runtime ใหม่รองรับ Operator ที่หลากหลายและมีประสิทธิภาพมากขึ้น ช่วยให้โมเดลทำงานได้เร็วขึ้นอย่างเห็นได้ชัด โดยเฉพาะอย่างยิ่งการนำ Operator เฉพาะทางอย่าง com.microsoft.GroupQueryAttention, com.microsoft.MatMulNBits, หรือ com.microsoft.QMoE มาใช้ ทำให้โมเดลประเภท BERT-based embedding เร็วขึ้นถึง 4 เท่าเมื่อเทียบกับเวอร์ชันก่อนหน้า
• ความแม่นยำและความครอบคลุม: รองรับ Operator ได้ดีขึ้น ส่งผลให้การคำนวณมีความแม่นยำและครอบคลุมโมเดลได้มากขึ้น
• ใช้งานได้หลากหลายสภาพแวดล้อม: โค้ด Transformers.js เดียวกันสามารถทำงานได้ทั้งบนเบราว์เซอร์, Server-side Runtimes (เช่น Node.js, Bun, Deno) และแอปพลิเคชันเดสก์ท็อป โดยยังคงได้รับประโยชน์จาก WebGPU Acceleration

โครงสร้าง Repository ที่เป็นระเบียบยิ่งขึ้น 🏗️

เพื่อรองรับการพัฒนาในระยะยาว Transformers.js v4 ได้ปรับโครงสร้าง Repository ให้เป็น Monorepo โดยใช้ pnpm workspaces ทำให้สามารถจัดการกับ Sub-packages ต่างๆ ได้อย่างมีประสิทธิภาพมากขึ้น การเปลี่ยนแปลงนี้ช่วยให้:

• แพ็กเกจที่เล็กลง: สามารถสร้างและเผยแพร่แพ็กเกจย่อยที่มีขนาดเล็กลง โดยยังคงพึ่งพา @huggingface/transformers core ได้โดยไม่ต้องดูแล Repository แยกหลายที่
• แยกส่วนการทำงาน: โค้ดโมเดลถูกแยกออกจากไฟล์ models.js เดิมที่ยาวกว่า 8,000 บรรทัด ออกเป็นโมดูลย่อยที่ชัดเจน ทำให้โค้ดอ่านง่ายขึ้น และเพิ่มโมเดลใหม่ๆ ได้สะดวก
• ตัวอย่างโครงการแยกต่างหาก: โครงการตัวอย่างถูกย้ายไปยัง Repository เฉพาะ เพื่อให้ Repository หลักมีโค้ดคอร์ไลบรารีที่สะอาดตา และผู้ใช้สามารถค้นหาหรือร่วมพัฒนาตัวอย่างได้ง่ายขึ้น

ฟีเจอร์ใหม่และ API ที่ทรงพลัง 🛠️

Transformers.js v4 มาพร้อมกับฟีเจอร์ใหม่ๆ ที่ช่วยให้การพัฒนาแอปพลิเคชัน AI ที่พร้อมใช้งานจริงเป็นไปได้ง่ายขึ้น:

• ModelRegistry API: ออกแบบมาเพื่อ Workflow การผลิต ช่วยให้ตรวจสอบ Assets ของ Pipeline ได้อย่างชัดเจนก่อนโหลด เช่น รายการไฟล์ที่จำเป็น (getpipelinefiles), ตรวจสอบสถานะ Cache (ispipelinecached), หรือล้าง Cache (clearpipelinecache) นอกจากนี้ progresscallback ยังรองรับ progresstotal ทำให้แสดงผลความคืบหน้าการโหลดได้สมบูรณ์ยิ่งขึ้น
• Environment Settings: เพิ่มการควบคุมการโหลดโมเดล เช่น env.useWasmCache สำหรับการใช้งานแบบ Offline และ env.fetch สำหรับการกำหนดค่า Fetch Implementation ที่กำหนดเอง
• การควบคุม Log ที่ดีขึ้น: ซ่อนคำเตือน WebGPU ONNX Runtime เป็นค่าเริ่มต้น และสามารถกำหนดระดับ Verbosity ได้อย่างชัดเจน ช่วยให้ Console Output มีเฉพาะข้อมูลที่สำคัญ
• Standalone Tokenizers.js Library: แยก Logic การ Tokenization ออกมาเป็นไลบรารี @huggingface/tokenizers โดยเฉพาะ มีขนาดเล็ก (8.8kB gzipped) และไม่มี Dependencies ทำให้ใช้งานได้ง่ายและมีประสิทธิภาพ

รองรับโมเดลใหม่ๆ และสถาปัตยกรรมที่ซับซ้อน 🚀

ด้วยกลยุทธ์การ Export โมเดลใหม่และการสนับสนุน Custom Operators จาก ONNX Runtime ทำให้ Transformers.js v4 สามารถเพิ่มโมเดลยอดนิยมจำนวนมากเข้ามา เช่น GPT-OSS, Chatterbox, GraniteMoeHybrid, LFM2-MoE, HunYuanDenseV1, Apertus, Olmo3, FalconH1, และ Youtu-LLM โมเดลเหล่านี้รองรับสถาปัตยกรรมขั้นสูง เช่น Mamba, Multi-head Latent Attention (MLA), และ Mixture of Experts (MoE) ซึ่งทั้งหมดนี้สามารถทำงานได้บน WebGPU ทำให้ผู้ใช้สามารถรันโมเดลเหล่านี้ได้โดยตรงบนเบราว์เซอร์หรือสภาพแวดล้อม JavaScript อื่นๆ ด้วย Hardware Acceleration

ปรับปรุง Build System และขนาด Bundle 💨

การเปลี่ยนจาก Webpack มาเป็น esbuild ส่งผลให้:

• Build Time เร็วขึ้น 10 เท่า: จาก 2 วินาที เหลือเพียง 200 มิลลิวินาที ทำให้การพัฒนาทำซ้ำได้เร็วขึ้นมาก
• ขนาด Bundle ลดลง 10%: โดยเฉลี่ย ทำให้ดาวน์โหลดเร็วขึ้น และแอปพลิเคชันเริ่มต้นทำงานได้ไวขึ้น โดยเฉพาะ transformers.web.js ที่มีขนาดเล็กลงถึง 53%

การปรับปรุงอื่นๆ ที่น่าสนใจ ✨

• รองรับโมเดลขนาดใหญ่: สามารถรันโมเดลที่มีพารามิเตอร์มากกว่า 8 พันล้านตัวได้สำเร็จ เช่น GPT-OSS 20B (q4f16) ที่ความเร็วประมาณ 60 tokens ต่อวินาที บน M4 Pro Max
• Type System ที่ดีขึ้น: รองรับ Dynamic Pipeline Types ที่ปรับเปลี่ยนตาม Input เพื่อประสบการณ์นักพัฒนาที่ดีขึ้น
• ปรับปรุง Prettier Configuration: ทำให้โค้ดมีรูปแบบที่สอดคล้องกันทั่วทั้ง Repository

Transformers.js v4 ถือเป็นการก้าวกระโดดครั้งสำคัญ ที่ทำให้การนำ AI ไปใช้บนเว็บง่ายขึ้น เร็วขึ้น และเข้าถึงได้มากขึ้น ใครที่กำลังพัฒนาแอปพลิเคชัน AI บนเว็บ ไม่ควรพลาดเวอร์ชันนี้!

คำถามที่พบบ่อย

Transformers.js v4 ใช้ WebGPU ได้บนทุกเบราว์เซอร์หรือไม่?

WebGPU รองรับบนเบราว์เซอร์รุ่นใหม่ๆ ส่วนใหญ่ แต่ประสิทธิภาพและความเข้ากันได้อาจแตกต่างกันไป ควรตรวจสอบเอกสารของเบราว์เซอร์ที่คุณใช้งาน

โมเดลที่เพิ่มเข้ามาใหม่ใน v4 มีอะไรบ้าง?

มีโมเดลยอดนิยมมากมาย เช่น GPT-OSS, Chatterbox, GraniteMoeHybrid, LFM2-MoE, HunYuanDenseV1, Apertus, Olmo3, FalconH1, และ Youtu-LLM

สามารถรันโมเดลบน Node.js ได้โดยตรงหรือไม่?

ได้ครับ ด้วย WebGPU Runtime ใหม่ ทำให้สามารถรันโมเดลที่เร่งความเร็วด้วย WebGPU ได้โดยตรงบน Node.js, Bun, และ Deno

Tokenizers.js Library มีประโยชน์อย่างไร?

เป็นไลบรารีแยกต่างหากสำหรับ Logic การ Tokenization โดยเฉพาะ มีขนาดเล็ก ไม่มี Dependencies และทำงานได้ดีทั้งบนเบราว์เซอร์และ Server-side

การปรับปรุงเรื่องขนาด Bundle มีผลอย่างไร?

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

#TransformersJS #WebGPU #AI #JavaScript #HuggingFace

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

OpenEnv: กรอบการทำงานใหม่เพื่อประเมิน Agent ที่ใช้เครื่องมือในโลกจริง

การพัฒนาปัญญาประดิษฐ์ (AI) โดยเฉพาะอย่างยิ่ง AI ที่สามารถทำงานร่วมกับเครื่องมือต่างๆ หรือที่เรียกว่า "Agent" กำลังก้าวไปอย่างรวดเร็ว แต่การทดสอบประสิทธิภาพของ Agent เหล่านี้ในสภาพแวดล้อมจริงที่ซับซ้อนยังคงเป็นความท้าทายสำคัญ Hugging Face และ Meta จึงได้ร่วมกันพัฒนา OpenEnv ซึ่งเป็นเฟรมเวิร์กโอเพนซอร์สที่ออกแบบมาเพื่อแก้ปัญหานี้ ด้วยการสร้างมาตรฐานวิธีการที่ Agent จะโต้ตอบกับสภาพแวดล้อมจริง

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

OpenEnv คืออะไร?

OpenEnv คือกรอบการทำงานที่ช่วยให้เราสามารถประเมิน AI Agent กับระบบจริง แทนที่จะเป็นเพียงการจำลองสถานการณ์ มันมอบวิธีการที่เป็นมาตรฐานในการเชื่อมต่อ Agent เข้ากับเครื่องมือและขั้นตอนการทำงานจริง พร้อมทั้งรักษาโครงสร้างที่จำเป็นสำหรับการประเมินที่สม่ำเสมอและเชื่อถือได้

OpenEnv ใช้ API แบบ Gym-oriented (reset, step, action, observations) คล้ายกับ Gymnasium ของ OpenAI นอกจากนี้ยังใช้ส่วนต่อประสานมาตรฐานสำหรับเรียกใช้เครื่องมือ (MCP tool call interface) เพื่อเชื่อมต่อกับสภาพแวดล้อมต่างๆ ซึ่งช่วยให้มีอินเทอร์เฟซที่สอดคล้องกันในทุกโดเมน ตั้งแต่การจำลองไปจนถึงสภาพแวดล้อมการใช้งานจริง

สภาพแวดล้อมเหล่านี้สามารถรักษา "สถานะ" (state) ไว้ได้หลายการดำเนินการ ทำให้ Agent สามารถทำการตัดสินใจที่ต้องอาศัยการคิดระยะยาว (long-horizon reasoning) และสามารถเชื่อมต่อโดยตรงกับ API และเครื่องมือจริง เช่น เว็บเบราว์เซอร์, ระบบจัดเก็บโค้ด (code repositories) หรือแม้กระทั่งระบบปฏิทิน สิ่งนี้ช่วยเปลี่ยนการประเมินจากการถามว่า "สิ่งนี้ทำงานได้หรือไม่ในการสาธิตที่ควบคุมได้?" ไปเป็นการถามว่า "สิ่งนี้สามารถทำงานได้อย่างน่าเชื่อถือในโลกจริงหรือไม่?"

Calendar Gym: มาตรฐานการวัดผลระดับโปรดักชัน

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

Turing ได้พัฒนาสภาพแวดล้อมการจัดการปฏิทินระดับโปรดักชันที่เรียกว่า Calendar Gym เพื่อให้ OpenEnv สามารถใช้งานได้จริงในกรณีที่ต้องเผชิญกับความต้องการที่สมจริงและท้าทาย แทนที่จะเป็นการจำลองการนัดหมายปฏิทินโดยทั่วไป Calendar Gym จะนำเสนอข้อจำกัดเดียวกันกับที่ Agent จะต้องเผชิญในระบบปฏิทินจริง ได้แก่:

• Access Control Lists (ACLs): การควบคุมสิทธิ์การเข้าถึงระหว่างผู้ใช้และปฏิทินต่างๆ
• การมองเห็นที่จำกัด: Agent อาจมองเห็นสถานะของผู้ใช้อื่นได้เพียงบางส่วน
• ขั้นตอนการทำงานแบบหลายขั้นตอน: การดำเนินการต้องถูกเชื่อมต่อกันตามลำดับที่ถูกต้อง

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

ตัวอย่างการใช้งาน Calendar Gym

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

from openenv import CalendarGym



env = CalendarGym()

observation, info = env.reset()



# สำรวจเครื่องมือที่มีอยู่

tools = env.call("ListToolsAction")

print(tools)



# สร้างกิจกรรม

event_details = {

    "summary": "Project meeting",

    "start": {"dateTime": "2026-03-15T10:00:00", "timeZone": "Asia/Bangkok"},

    "end": {"dateTime": "2026-03-15T11:00:00", "timeZone": "Asia/Bangkok"},

    "attendees": [{"email": "[email protected]"}]

}

create_event_action = env.call("CreateEventAction", calendarId="primary", event=event_details)

print(create_event_action)

เมื่อเรียกใช้ ListToolsAction ใน Calendar Gym คุณจะได้รับรายการเครื่องมือพร้อมกับ schema ของ input (ระบุว่าเครื่องมือนั้นรับ argument อะไรบ้าง)

สิ่งที่ค้นพบจากการประเมิน Agent ใน Calendar Gym

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

• การคิดวิเคราะห์หลายขั้นตอนเป็นคอขวดหลัก: Agent มักจะประสบปัญหาในการเชื่อมโยงการดำเนินการอย่างถูกต้องในขั้นตอนที่ยาวขึ้น ซึ่งชี้ให้เห็นว่าเกณฑ์การวัดผลจำเป็นต้องทดสอบการคิดวิเคราะห์ที่ต่อเนื่องผ่านขั้นตอนที่ขึ้นต่อกันหลายขั้นตอน ไม่ใช่แค่การเรียกใช้เครื่องมือครั้งเดียว
• ความคลุมเครือลดประสิทธิภาพลงอย่างมาก: Agent สามารถทำภารกิจสำเร็จได้เกือบ 90% เมื่อระบุปฏิทินอย่างชัดเจน แต่ความสำเร็จจะลดลงเหลือประมาณ 40% เมื่อใช้คำอธิบายเป็นภาษาธรรมชาติสำหรับภารกิจเดียวกัน การสร้างกลไกการค้นหาและตรวจสอบข้อมูลที่แข็งแกร่งขึ้นใน Agent loop (แทนที่จะพึ่งพา LLM ในการตีความการอ้างอิงเพียงอย่างเดียว) ดูเหมือนจะเป็นสิ่งจำเป็น
• การเลือกเครื่องมือที่ถูกต้องไม่เพียงพอ: ในการโต้ตอบที่ล้มเหลว มากกว่าครึ่งหนึ่งของข้อผิดพลาดเกิดจาก argument ของเครื่องมือที่ผิดรูปแบบ หรือลำดับการดำเนินการที่ไม่ถูกต้อง แม้ว่าจะเลือกเครื่องมือที่ถูกต้องแล้วก็ตาม พฤติกรรมของ Agent ที่น่าเชื่อถือขึ้นอยู่กับคุณภาพการดำเนินการและการให้ feedback ที่มีโครงสร้างพอๆ กับการเลือกเครื่องมือ ซึ่งการออกแบบสภาพแวดล้อมก็มีความสำคัญเช่นกัน

ความท้าทายเหล่านี้ไม่ได้จำกัดอยู่แค่การจัดตารางเวลาและปฏิทินเท่านั้น แต่สะท้อนถึงข้อจำกัดที่กว้างขึ้นซึ่งเกิดขึ้นเมื่อ Agent ทำงานในระบบที่เปลี่ยนแปลงไปในช่วงเวลานานๆ และชี้ให้เห็นถึงกรอบการประเมินที่ทดสอบสิทธิ์, การสังเกตการณ์บางส่วน (partial observability), และขั้นตอนการทำงานแบบหลายขั้นตอนไปพร้อมๆ กัน

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

หากต้องการเจาะลึกเกี่ยวกับการออกแบบ Calendar Gym, ระเบียบวิธีในการวัดผล และผลลัพธ์เชิงปริมาณ โปรดสำรวจบทความทางเทคนิคฉบับเต็มบนเว็บไซต์ของ Turing และหากต้องการสำรวจ Calendar Gym เวอร์ชันโคลน โปรดไปที่ Calendar Gym space

ข้อผิดพลาดที่พบบ่อยในการใช้เครื่องมือ (Appendix)

ในการใช้งานจริง การเชื่อมต่อเครื่องมือมักจะล้มเหลวในลักษณะที่ไม่ใช่เรื่องใหญ่ แต่เป็นข้อผิดพลาดเล็กๆ ที่คาดเดาได้ เมื่อเชื่อมต่อเครื่องมือ MCP เข้ากับ API จริง (เช่น การดำเนินการปฏิทิน) เราได้พบปัญหาที่เกิดขึ้นซ้ำๆ

กรณีข้อผิดพลาดเฉพาะที่พบ

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

1. Argument ของเครื่องมือไม่ตรงกับ Schema: Agent เรียกใช้เครื่องมือที่ถูกต้อง (เช่น events_insert) แต่ argument ที่ส่งไปไม่ตรงกับ JSON schema ที่ประกาศไว้

• ตัวอย่าง:
• ขาดฟิลด์ที่จำเป็น เช่น calendarId
• การซ้อน start / end ที่ไม่ถูกต้อง
• การส่งค่าเป็น string แทนที่จะเป็น object
• การบรรเทา: ให้ตัวอย่างที่ถูกต้องเพียงหนึ่งเดียวของการเรียกใช้ 'events_insert' ใน prompt ของคุณ และส่งคืนข้อผิดพลาดการตรวจสอบที่มีโครงสร้างเพื่อให้โมเดลสามารถซ่อมแซมและลองใหม่ได้ แทนที่จะล้มเหลวเงียบๆ

1. สิทธิ์ไม่เพียงพอ: การเรียกใช้เครื่องมือถูกต้องตาม syntax แต่ API ปฏิเสธเนื่องจากสิทธิ์ไม่เพียงพอ

• ตัวอย่าง:
• ขาด OAuth scopes ที่จำเป็น
• Access token หมดอายุ
• ผู้ใช้ไม่มีสิทธิ์เขียนไปยังปฏิทินเป้าหมาย
• การบรรเทา: ระบุ OAuth scopes ที่จำเป็นให้ชัดเจน และส่งคืนขั้นตอนการแก้ไขปัญหาที่สามารถดำเนินการได้ เพื่อให้ Agent สามารถแนะนำผู้ใช้ได้ แทนที่จะลองเรียกใช้การดำเนินการเดิมที่ล้มเหลวซ้ำๆ

1. รูปแบบวันที่/เวลาไม่ถูกต้อง: กิจกรรมถูกปฏิเสธโดย API หรือถูกสร้างขึ้นในเวลาที่ไม่คาดคิด

• ตัวอย่าง:
• ขาด timezone offset
• รูปแบบ datetime ไม่ใช่ RFC3339
• การซ้อน start.dateTime หรือ end.dateTime ที่ไม่ถูกต้อง
• การผสมผสานเวลากท้องถิ่นกับ UTC โดยไม่ระบุ offset
• การบรรเทา: กำหนดมาตรฐานเป็น RFC3339 พร้อมระบุ timezone offset อย่างชัดเจน (เช่น 2026-02-11T09:30:00-05:00) และรวมตัวอย่าง datetime ที่ถูกต้องอย่างน้อยหนึ่งตัวอย่างในเอกสารของคุณ เพื่อเป็นแนวทางให้โมเดลลดการลองผิดลองถูก

#AI #OpenSource #AgenticRL #HuggingFace #Meta

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

สร้าง CUDA Kernels ระดับโปรดักชันได้ง่ายขึ้น ด้วย Agent Skills จาก Hugging Face 🚀

การพัฒนา CUDA Kernels ที่มีประสิทธิภาพสูงนั้นซับซ้อนและต้องอาศัยความเชี่ยวชาญเฉพาะทางอย่างมาก โดยเฉพาะอย่างยิ่งเมื่อต้องผสานรวมเข้ากับไลบรารีใหญ่อย่าง Transformers และ Diffusers ซึ่งมีรายละเอียดปลีกย่อยมากมาย ไม่ว่าจะเป็นรูปแบบการเข้าถึงหน่วยความจำเฉพาะสถาปัตยกรรม GPU, กลยุทธ์การทำ Vectorization, หรือแม้แต่การจัดการกับปัญหาการผสานรวมที่อาจทำให้ผู้พัฒนาที่มีประสบการณ์ต้องปวดหัว

Hugging Face ได้เปิดตัว "Agent Skill" ใหม่ที่ออกแบบมาเพื่อแก้ปัญหานี้โดยเฉพาะ ด้วยการสอนให้ Coding Agents สามารถเขียน CUDA Kernels คุณภาพระดับโปรดักชันได้เอง ทำให้กระบวนการที่เคยยากลำบากนี้เข้าถึงได้ง่ายขึ้นมาก

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

Agent Skill คือการรวบรวมความรู้เฉพาะทาง (Domain Knowledge) ที่จำเป็นสำหรับงานใดงานหนึ่ง แล้วนำมาบรรจุในรูปแบบที่ Coding Agent สามารถเข้าใจและนำไปใช้งานได้ เมื่อเรานำ Agent Skill นี้ไปใช้กับ Coding Agent อย่าง Claude หรือ Codex มันจะสามารถเรียนรู้และนำความรู้เหล่านั้นไปประยุกต์ใช้ในการสร้าง CUDA Kernels ที่ทำงานได้จริง

เหตุผลที่ Agent Skill นี้มีความสำคัญ:

• แก้ปัญหาความซับซ้อนของ CUDA Kernels: การพัฒนา CUDA Kernels มีรายละเอียดที่ต้องใส่ใจมากมาย ตั้งแต่การปรับแต่งให้เข้ากับ GPU แต่ละรุ่น (H100, A100, T4) ไปจนถึงการผสานรวมกับโครงสร้างของ Diffusers และ Transformers ซึ่งมีรูปแบบที่แตกต่างกัน
• ลดช่องว่างของความรู้: ความรู้เหล่านี้มักกระจัดกระจายอยู่ในเอกสาร, Stack Overflow หรือคู่มือการปรับแต่งเฉพาะฮาร์ดแวร์ Agent Skill นี้จะรวบรวมทุกอย่างมาไว้ในที่เดียว
• เพิ่มประสิทธิภาพ: ช่วยให้นักพัฒนาสามารถสร้าง Kernels ที่ปรับแต่งมาอย่างดี เพื่อเพิ่มความเร็วในการประมวลผล ทั้งในระดับ Kernel เดี่ยวๆ และในระดับ End-to-End ของโมเดล

ติดตั้งและใช้งาน Agent Skill ง่ายๆ

การติดตั้ง Agent Skill นี้ทำได้ง่ายมาก โดยจะมาพร้อมกับไลบรารี kernels ของ Hugging Face

วิธีติดตั้ง:

pip install kernels

หลังจากติดตั้งแล้ว Agent Skill จะถูกวางไว้ในโฟลเดอร์ .claude/skills/cuda-kernels/ ซึ่ง Coding Agent ส่วนใหญ่จะสามารถตรวจจับและใช้งานได้โดยอัตโนมัติ

ตัวอย่างการเรียกใช้งาน:

คุณสามารถสั่งให้ Agent สร้าง Kernel ได้โดยตรง เช่น:

"Write me an RMSNorm kernel for an H100 GPU."

หรือสั่งงานแบบเปิดกว้างมากขึ้น:

"Build a kernel for the diffusers library."

Agent จะสามารถอ่าน Skill, เลือกพารามิเตอร์ GPU ที่เหมาะสม, สร้าง Source Code ของ CUDA Kernel, เขียน PyTorch Bindings, ตั้งค่า build.toml และสร้างสคริปต์สำหรับ Benchmark ได้ด้วยตัวเอง

สิ่งที่ Agent Skill นี้มีให้

Agent Skill นี้ประกอบด้วยข้อมูลกว่า 550 โทเค็น ซึ่งครอบคลุม:

• การปรับแต่งสำหรับ GPU NVIDIA: ให้คำแนะนำสำหรับการทำ Optimization บน GPU สถาปัตยกรรม H100, A100, และ T4 โดยคำนึงถึง Compute Capabilities, ขนาด Shared Memory, และ Bandwidth
• รูปแบบการผสานรวม: ครอบคลุมรูปแบบการทำงานกับทั้ง Diffusers และ Transformers รวมถึงปัญหาเฉพาะที่อาจพบเจอ
• เทมเพลต Kernel: มีเทมเพลตสำหรับ Kernel ที่ใช้ Vectorized Memory Access สำหรับ BF16, FP16, และ FP32
• เวิร์กโฟลว์ Benchmark: สคริปต์สำหรับวัดประสิทธิภาพทั้งแบบ Kernel เดี่ยว และการเปรียบเทียบ End-to-End
• การเชื่อมต่อกับ HuggingFace Kernel Hub: สามารถโหลด Community Kernels ผ่าน get_kernel ได้

ทดสอบประสิทธิภาพจริง: Diffusers และ Transformers

ทีมงานได้ทดสอบ Agent Skill นี้กับสองเป้าหมายจริง:

1. Diffusers Pipeline (LTX-Video บน H100)

Agent สามารถสร้าง Kernels สำหรับ RMSNorm, RoPE 3D, GEGLU, และ AdaLN สำหรับ LTX-Video ซึ่งเป็น Video Generation Pipeline โดย Kernel RMSNorm ถูกปรับแต่งพิเศษสำหรับ H100

• Isolated RMSNorm Benchmark: เปรียบเทียบประสิทธิภาพ Kernel RMSNorm เดี่ยวๆ กับ PyTorch Baseline พบว่า เร็วขึ้นเฉลี่ย 1.88 เท่า โดยมี Bandwidth Efficiency ที่ 34.7% ของ H100
• End-to-End Video Generation: เมื่อวัดประสิทธิภาพการสร้างวิดีโอแบบ End-to-End พบว่า เร็วขึ้น 6% ซึ่งสอดคล้องกับสัดส่วนการใช้ Compute ของ RMSNorm ใน Pipeline

2. Transformers Model (Qwen3-8B บน H100)

Agent สร้าง Kernel RMSNorm สำหรับ Qwen3-8B ซึ่งเป็น LLM ขนาดใหญ่

• Isolated RMSNorm Benchmark: เปรียบเทียบประสิทธิภาพ Kernel RMSNorm เดี่ยวๆ กับ PyTorch Baseline พบว่า เร็วขึ้นเฉลี่ย 1.94 เท่า โดยมี Bandwidth Efficiency ที่ 22.3% ของ H100
• Speedup with Sequence Length: ความเร็วที่เพิ่มขึ้นจะสูงขึ้นตาม Sequence Length โดย เร็วขึ้น 1.58 เท่า ที่ 128 tokens และ 2.47 เท่า ที่ 8192 tokens สำหรับการ Inference แบบ Long-Context Custom Kernel สามารถลด Latency ของ RMSNorm ลงได้เกือบครึ่ง

การเผยแพร่ Kernel ของคุณสู่ HuggingFace Kernel Hub

เมื่อสร้าง Kernel ที่มีประสิทธิภาพด้วย Agent Skill แล้ว คุณสามารถเผยแพร่สู่ HuggingFace Kernel Hub เพื่อให้ผู้อื่นสามารถนำไปใช้ได้ทันทีโดยไม่ต้องคอมไพล์

ขั้นตอน:

1. ตรวจสอบโครงสร้างโปรเจกต์: Agent จะสร้างโปรเจกต์ที่ได้มาตรฐาน kernel-builder อยู่แล้ว
2. Build ทุก Variant ด้วย Nix: ใช้ kernel-builder Nix flake เพื่อ Build Kernel ให้รองรับ PyTorch และ CUDA เวอร์ชันต่างๆ โดยอัตโนมัติ
3. สร้าง Repository บน Hub และ Push: อัปโหลด Kernel ที่ Build แล้วไปยัง Model Repository บน Hugging Face Hub
4. ให้ผู้อื่นโหลดในบรรทัดเดียว: เมื่อเผยแพร่แล้ว ทุกคนสามารถใช้ Kernel ของคุณได้ง่ายๆ ด้วยคำสั่ง get_kernel ซึ่งจะตรวจจับเวอร์ชัน Python, PyTorch, และ CUDA ของผู้ใช้ และดาวน์โหลด Binary ที่ตรงกันมาให้

สรุป

Agent Skill ใหม่นี้ถือเป็นก้าวสำคัญในการทำให้การพัฒนา CUDA Kernels ที่มีประสิทธิภาพสูงเป็นเรื่องที่เข้าถึงได้ง่ายขึ้นสำหรับทุกคน โดยผสานรวมความรู้เฉพาะทางเข้ากับ Coding Agent และสนับสนุนด้วย HuggingFace Kernel Hub สำหรับการเผยแพร่ ทำให้การสร้างสรรค์และแบ่งปันโซลูชันที่เร่งความเร็วในการประมวลผล AI เป็นไปได้อย่างมีประสิทธิภาพ

#CUDA #AgentSkills #HuggingFace #OpenSource

ขอบคุณ แหล่งข้อมูล
https://huggingface.co/blog/custom-cuda-kernels-agent-skills

สร้างแอปพลิเคชันเว็บแบบครบวงจรได้ในพริบตาด้วย Gradio gr.HTML

การพัฒนาแอปพลิเคชันเว็บสำหรับ AI อาจดูซับซ้อน โดยเฉพาะเมื่อต้องจัดการกับส่วนหน้า (frontend) ที่มีลูกเล่นหลากหลาย แต่ถ้ามีวิธีที่ช่วยให้คุณสร้างสรรค์แอปฯ ได้อย่างรวดเร็ว เพียงแค่ไฟล์ Python ไฟล์เดียวล่ะ? Gradio ได้นำเสนอ gr.HTML ซึ่งเป็นเครื่องมือที่ช่วยให้การสร้างสรรค์แอปฯ เว็บแบบครบวงจรเป็นเรื่องง่ายขึ้นอย่างไม่น่าเชื่อ

ทำความรู้จักกับ gr.HTML: หัวใจของการสร้างแอปฯ แบบ One-Shot

gr.HTML คือคอมโพเนนต์พิเศษของ Gradio ที่ให้คุณฝังโค้ด HTML, CSS และ JavaScript ลงไปในแอปพลิเคชัน Python ได้โดยตรง ทำให้สามารถสร้างส่วนติดต่อผู้ใช้ (UI) ที่ซับซ้อนและมีลูกเล่นได้โดยไม่ต้องพึ่งพาเฟรมเวิร์ก Frontend แยกต่างหาก

สิ่งที่ gr.HTML ทำได้: ตัวอย่างแอปพลิเคชันที่น่าทึ่ง

• Pomodoro Timer: สร้างตัวจับเวลา Pomodoro ที่มีแอนิเมชันต้นไม้ Pixel-art ที่เติบโตตามเวลาทำงาน พร้อมฟีเจอร์การติดตามเซสชัน การสลับธีม และโหมดพักเบรก ทั้งหมดนี้อยู่ในไฟล์ Python ไฟล์เดียว
• GitHub Contribution Heatmap: สร้างแผนภูมิแสดงผลการสร้างโค้ดบน GitHub ที่สามารถคลิกเพื่อสลับการแสดงผล, เปลี่ยนสี, สร้างรูปแบบต่างๆ และอัปเดตสถิติแบบเรียลไทม์
• Kanban Board: พัฒนาบอร์ด Kanban ที่รองรับการลากและวาง (Drag-and-Drop) ระหว่างคอลัมน์, แก้ไขข้อความในบัตรได้ทันที, ค้นหาแบบเรียลไทม์ และย่อ/ขยายคอลัมน์ได้
• Spin-to-Win Wheel: สร้างวงล้อสุ่มที่หมุนได้อย่างนุ่มนวล สามารถตั้งค่าล่วงหน้าสำหรับการตัดสินใจแบบต่างๆ หรือเพิ่มส่วนประกอบการหมุนใหม่ๆ ได้ตลอดเวลา
• Detection Viewer: สร้างมุมมองเฉพาะสำหรับผลลัพธ์ Object Detection, Instance Segmentation และ Pose Estimation โดยแสดงผล Bounding Boxes, Segmentation Masks, Keypoints และ Skeleton Connections ได้อย่างสวยงาม
• 3D Camera Control for Image Editing: ผสานรวมมุมมอง Three.js เข้ากับแอปพลิเคชัน Gradio เพื่อควบคุมกล้อง 3 มิติสำหรับการแก้ไขรูปภาพ โดยพารามิเตอร์กล้องจะถูกส่งไปยังโมเดล AI เพื่อประมวลผล
• Real-time Speech Transcription: สร้างระบบถอดเสียงพูดแบบเรียลไทม์ พร้อมแสดงสถานะแบบเคลื่อนไหว, ตัวนับคำต่อนาที (WPM) และผลลัพธ์ที่อัปเดตขณะพูด

กลไกการทำงานเบื้องหลัง: ง่ายกว่าที่คิด

หัวใจสำคัญของ gr.HTML คือการเชื่อมต่อระหว่าง Python และ JavaScript ผ่านเทมเพลต 3 ส่วนหลัก:

• ${value}: ใช้สำหรับแทรกค่าจาก Python เข้าสู่ JavaScript
• props.value: ใช้สำหรับอัปเดตค่าจาก JavaScript กลับไปยัง Python
• trigger('change'): ใช้สำหรับส่งสัญญาณการเปลี่ยนแปลงกลับไปยังฝั่ง Python

เมื่อต้องการสร้างคอมโพเนนต์ที่นำกลับมาใช้ใหม่ได้ คุณสามารถสร้างคลาสที่สืบทอดมาจาก gr.HTML ได้โดยตรง ทำให้คอมโพเนนต์นั้นทำงานเหมือนกับคอมโพเนนต์พื้นฐานอื่นๆ ของ Gradio เช่น gr.Image หรือ gr.Slider

ทำไม gr.HTML ถึงสำคัญสำหรับ "Vibe Coding"?

gr.HTML เปลี่ยนวิธีการพัฒนาแอปพลิเคชัน AI ให้รวดเร็วและมีประสิทธิภาพมากขึ้น โดยเฉพาะอย่างยิ่งเมื่อทำงานร่วมกับ Large Language Models (LLMs)

• การพัฒนาแบบ One-File: LLM สามารถสร้างโค้ดคอมโพเนนต์ที่กำหนดเองได้ในไฟล์ Python ไฟล์เดียว ไม่ต้องยุ่งยากกับการสร้างไฟล์สไตล์ชีต (CSS) หรือการตั้งค่า Build Config ที่ซับซ้อน
• วงจรการพัฒนาที่สั้น: คุณสามารถอธิบายสิ่งที่ต้องการ → รับโค้ด → รันแอปฯ Gradio → เห็นผลลัพธ์ → อธิบายสิ่งที่ต้องแก้ไข → ทำซ้ำ ได้อย่างรวดเร็วในเวลาเพียงไม่กี่วินาที ด้วยโหมด Reload ของ Gradio
• Deploy ได้ทันที: แอปพลิเคชันสามารถ Deploy ไปยัง Hugging Face Spaces ได้ง่ายๆ ด้วยคำสั่ง gradio deploy หรือแชร์ลิงก์ชั่วคราวด้วย demo.launch(share=True)

สรุป: ปลดปล่อยความคิดสร้างสรรค์ด้วย gr.HTML

Gradio มาพร้อมกับคอมโพเนนต์แบบโต้ตอบได้มากกว่า 30 แบบ แต่บางครั้งแอปพลิเคชัน AI ที่สมบูรณ์แบบของคุณอาจต้องการสิ่งที่พิเศษกว่านั้น gr.HTML คือคำตอบสำหรับความต้องการเหล่านั้น

หากคุณมีไอเดียเจ๋งๆ ลองนำ gr.HTML ไปใช้ สร้างสรรค์คอมโพเนนต์ที่กำหนดเองโดยการอธิบายความต้องการให้กับ LLM, สร้างโค้ด, และรันแอปพลิเคชัน คุณอาจจะทึ่งกับสิ่งที่คุณสามารถสร้างสรรค์ได้ภายในเวลาเพียงไม่กี่นาที!

#Gradio #grHTML #AI #WebDevelopment #Python

ขอบคุณ แหล่งข้อมูล
https://huggingface.co/blog/gradio-html-one-shot-apps

ไขปริศนา! ทำไม Agent อัจฉริยะในองค์กรถึงล้มเหลว? เจาะลึกด้วย IT-Bench และ MAST

ในโลกของการทำงานอัตโนมัติด้วย AI โดยเฉพาะกลุ่ม Agent อัจฉริยะที่ใช้โมเดลภาษาขนาดใหญ่ (LLM) การทำความเข้าใจว่าทำไมระบบเหล่านี้ถึงล้มเหลวในโลกแห่งความเป็นจริง โดยเฉพาะในงานที่ซับซ้อนอย่างการจัดการระบบ IT ถือเป็นเรื่องท้าทายอย่างยิ่ง การทดสอบประสิทธิภาพแบบเดิมๆ มักให้แค่ตัวเลขชี้วัดความสำเร็จ แต่ไม่สามารถบอกได้ว่า "ทำไม" ถึงล้มเหลว

IBM Research และ UC Berkeley ได้ร่วมมือกันศึกษาปัญหานี้อย่างจริงจัง โดยใช้เครื่องมือที่ชื่อว่า IT-Bench ซึ่งเป็น Benchmark มาตรฐานสำหรับงานด้าน SRE (Site Reliability Engineering), Security และ FinOps และ MAST (Multi-Agent System Failure Taxonomy) ซึ่งเป็นระเบียบวิธีที่ช่วยวินิจฉัยความล้มเหลวของระบบ Agent อัจฉริยะโดยเฉพาะ

ปัญหา "กล่องดำ" ของ Benchmark Agent

Benchmark อย่าง IT-Bench ถูกออกแบบมาเพื่อวัดประสิทธิภาพของ Agent ในงานสำคัญ เช่น การวินิจฉัยปัญหา Kubernetes, การแก้ไขช่องโหว่ความปลอดภัย หรือการจัดการต้นทุนบนคลาวด์ โดยปกติจะใช้ "อัตราความสำเร็จ" เป็นตัวชี้วัดหลัก แต่ตัวเลขนี้เพียงพอหรือไม่? การรู้ว่า Agent ทำงานสำเร็จ 14% ไม่ได้บอกเราว่าสาเหตุที่อีก 86% ล้มเหลวนั้นเกิดจากอะไรกันแน่ ลืมบริบท? สร้างคำสั่งผิด? หรือแค่หยุดทำงานไม่เป็น?

หากปราศจากวิธีการวิเคราะห์ความล้มเหลวที่ครอบคลุม นักพัฒนาจะยังคงต้องเดาทาง และมักจะแก้ไขปัญหาด้วยการปรับแต่ง Prompt แบบสุ่ม ซึ่งอาจแก้ปัญหาหนึ่งได้ แต่กลับสร้างปัญหาใหม่ขึ้นมาแทน

MAST: กุญแจไขกล่องดำแห่งความล้มเหลว

MAST ถูกพัฒนาขึ้นเพื่อเป็นมาตรฐานใหม่ในการวิเคราะห์รูปแบบความล้มเหลวของระบบ Agent ที่ซับซ้อน MAST จะแปลง Log การทำงานที่ดูเหมือนไม่มีโครงสร้าง ให้กลายเป็น "เวกเตอร์ความล้มเหลว" ที่มีโครงสร้าง ชี้ให้เห็นถึง 14 รูปแบบความล้มเหลวที่แตกต่างกัน โดยแบ่งออกเป็น 3 หมวดหมู่หลัก:

1. FC1: ปัญหาการออกแบบระบบ (โครงสร้างหลัก)

ความล้มเหลวที่เกิดจากสถาปัตยกรรมและนิยามบทบาทของ Agent เช่น:

• FM-1.3 Step Repetition: การทำงานซ้ำซ้อน (วนลูป)
• FM-1.4 Loss of Conversation History: การสูญเสียประวัติการสนทนา (Memory Leak)
• FM-1.5 Unaware of Termination Conditions: ไม่ทราบเงื่อนไขการสิ้นสุดการทำงาน (ไม่ยอมหยุด)

2. FC2: การสื่อสารผิดพลาดระหว่าง Agent (การสื่อสาร)

ความล้มเหลวที่เกิดขึ้นระหว่างการทำงาน จากวิธีการที่ Agent สื่อสารกันเอง หรือกับสภาพแวดล้อม เช่น:

• FM-2.2 Fail to Ask for Clarification: ล้มเหลวในการขอคำชี้แจง (ด่วนสรุปแทนที่จะถาม)
• FM-2.3 Task Derailment: งานหลุดจากเป้าหมาย (ออกนอกประเด็น)

3. FC3: การตรวจสอบงาน (การควบคุมคุณภาพ)

ความล้มเหลวในกระบวนการประกันคุณภาพของผลลัพธ์ที่ Agent สร้างขึ้น เช่น:

• FM-3.1 Premature Termination: การยุติงานก่อนเวลาอันควร (ยอมแพ้เร็วเกินไป)
• FM-3.3 Incorrect Verification: การตรวจสอบไม่ถูกต้อง (สร้างความสำเร็จปลอมขึ้นมา)

การทดลอง: วินิจฉัย Agent บน IT-Bench

เพื่อทดสอบแนวคิดการใช้ MAST ให้การประเมิน Agent มีประโยชน์และได้ข้อมูลเชิงลึกเกี่ยวกับรูปแบบความล้มเหลว นักวิจัยได้นำ MAST ไปประยุกต์ใช้กับ IT-Bench โดยได้ทำการวิเคราะห์ Log การทำงาน 310 รายการ จาก Agent SRE ที่สร้างขึ้นด้วย Codex ในสภาพแวดล้อมจริง ซึ่งครอบคลุมโมเดล 3 ประเภทที่แตกต่างกัน ได้แก่ Gemini-3-Flash, Kimi-K2 และ GPT-OSS-120B เพื่อให้มองข้ามเมตริกความสำเร็จแบบง่ายๆ และเจาะลึกถึง "ลายเซ็นความล้มเหลว" ที่ขับเคลื่อนผลลัพธ์เหล่านี้

ผลการทดสอบพบว่า:

• Gemini-3-Flash: 100 traces (เฉลี่ย 75.5% Recall)
• Kimi-K2: 105 traces (เฉลี่ย 28.6% Recall)
• GPT-OSS-120B: 105 traces (เฉลี่ย 12.4% Recall)

การค้นพบที่น่าสนใจจากการวิเคราะห์

1. โมเดลที่แข็งแกร่งอย่าง Gemini-3-Flash แสดงรูปแบบความล้มเหลวที่ "แม่นยำ" (แยกส่วน) ในขณะที่ Kimi-K2 และ GPT-OSS-120B แบบ Open Source กลับแสดงรูปแบบความล้มเหลวที่ "ทับซ้อนกัน"

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

• Gemini-3-Flash: เฉลี่ย 2.6 รูปแบบความล้มเหลวต่อ Traces ที่ล้มเหลว
• Kimi-K2: เฉลี่ย 4.7 รูปแบบความล้มเหลวต่อ Traces ที่ล้มเหลว
• GPT-OSS-120B: เฉลี่ย 5.3 รูปแบบความล้มเหลวต่อ Traces ที่ล้มเหลว

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

ในทางตรงกันข้าม GPT-OSS-120B กลับประสบกับ "การล่มสลายแบบทับซ้อน" ข้อผิดพลาดมีแนวโน้มที่จะสะสมเมื่อเวลาผ่านไป การจับคู่การให้เหตุผลที่ผิดพลาดเล็กน้อยในช่วงต้น อาจนำไปสู่การเบี่ยงเบนไปจากข้อกำหนดของงาน ซึ่งส่งผลให้ Agent ล้มเหลวโดยสิ้นเชิง Kimi-K2 อยู่ตรงกลาง ระหว่างสองโมเดลนี้ โดยมีความล้มเหลวที่บ่อยครั้งและซับซ้อนกว่าโมเดลระดับแนวหน้า แต่ไม่ถึงขั้นความไม่เสถียรของระบบแบบ GPT-OSS-120B

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

2. ความล้มเหลวแบบ "ไม่ร้ายแรง" (Benign) vs. "ร้ายแรง" (Fatal)

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

ข้อบกพร่องที่ "ไม่ร้ายแรง" (Benign Flaws)
ในโมเดลทั้งสาม รูปแบบความล้มเหลวบางอย่างปรากฏขึ้นบ่อยครั้ง แม้ในขณะที่การทำงานสำเร็จลุล่วง ซึ่งมักจะเป็นข้อขัดข้องเชิงโครงสร้างมากกว่าข้อผิดพลาดร้ายแรง:

• FM-1.3 Step Repetition: โหมดนี้ปรากฏใน Kimi-K2 ที่สำเร็จมากกว่า 90% ในโดเมน SRE การทำซ้ำมักเป็นสิ่งจำเป็น Agent อาจสอบถาม Metric เดียวกันหลายครั้งเพื่อยืนยันว่า Service กำลังดีขึ้น หรือการแก้ไขได้ผลหรือไม่ น่าสนใจว่า Gemini-3-Flash กลับแสดงการทำซ้ำน้อยลงใน Traces ที่ล้มเหลว ซึ่งบ่งชี้ว่าบางครั้งมันล้มเหลวเพราะ ไม่ทำซ้ำเพียงพอ
• FM-1.1 Disobey Task Specification: Agent มักจะเบี่ยงเบนไปจากรูปแบบเครื่องมือที่เข้มงวด หรือคำแนะนำตามลำดับ แต่ก็ยังสามารถระบุสาเหตุที่ถูกต้องได้

นี่คือจุดที่ MAST แสดงคุณค่าของมัน ช่วยให้เราเพิกเฉยต่อความล้มเหลวที่ไม่ร้ายแรง เช่น การทำซ้ำที่มักเกิดขึ้นในการแก้ไขปัญหา และมุ่งเน้นไปที่ความล้มเหลวร้ายแรงที่ทำให้การทำงานล้มเหลว

พฤติกรรมที่ "ร้ายแรง" (Fatal Failures)
พฤติกรรมบางอย่างแยกความสำเร็จออกจากความล้มเหลวได้อย่างชัดเจน เมื่อโหมดเหล่านี้ปรากฏ ความน่าจะเป็นของผลลัพธ์ที่สำเร็จจะลดลงอย่างมาก ตัวอย่างที่โดดเด่นที่สุดคือ FM-3.3 (Incorrect Verification) โหมดนี้แสดงการเพิ่มขึ้น 52% ใน Gemini-3-Flash ที่ล้มเหลวเมื่อเทียบกับ Traces ที่สำเร็จ โหมดที่โดดเด่นอื่นๆ ได้แก่ FM-1.5 (Unaware of Termination Conditions) และ FM-2.6 (Reasoning Action Mismatch) หากสิ่งเหล่านี้เกิดขึ้น การทำงานมีแนวโน้มที่จะล้มเหลว ซึ่งช่วยแนะนำผู้ปฏิบัติงานในการพัฒนากลยุทธ์การจัดการบริบทที่แข็งแกร่งทั่วทั้ง Agent ในระบบ และการโต้ตอบหลายรอบ

กรณีศึกษา: Gemini-3-Flash (ตัดสินใจเร็ว แต่อาจมั่นใจเกินไป)

Gemini-3-Flash มีประสิทธิภาพสูง แต่ปัญหาคอขวดหลักคือแนวโน้มที่จะ "สันนิษฐานว่าสำเร็จ" โดยไม่มีหลักฐานที่ชัดเจน รูปแบบความล้มเหลวของมันถูกครอบงำด้วยความแตกต่างอย่างมากในข้อผิดพลาดการตรวจสอบ Agent มักจะระบุสัญญาณที่ถูกต้อง แต่จะยุติการทำงานก่อนที่จะตรวจสอบกับ Ground Truth เพื่อแก้ไขปัญหานี้ นักพัฒนาควรใช้ "ประตูการตรวจสอบภายนอก" โดยการกำหนดให้มีหลักฐานจากเครื่องมือ เช่น การแจ้งเตือนที่เคลียร์แล้ว หรือ Threshold ของ Metric ที่ดี ก่อนที่จะอนุญาตให้ Agent สิ้นสุดการทำงาน ซึ่งจะช่วยลดความมั่นใจเกินไปโดยธรรมชาติของโมเดลนี้ได้

แนวทางการแก้ไข: การปรับปรุง Gemini-3-Flash บน ITBench ด้วย Prompt Engineering เพียงอย่างเดียวอาจไม่ช่วยมากนัก การทดลองที่แสดงในบทความ NeurIPS 2025 ชี้ให้เห็นว่า การปรับปรุงด้วย Prompt Engineering สำหรับความล้มเหลวที่เกี่ยวกับหน่วยความจำ สามารถเพิ่มประสิทธิภาพได้เพียงประมาณ 15.6% เท่านั้น ในขณะที่การเพิ่ม Agent ใหม่ เช่น Summarizer Agent เพื่อเตือน Agent อื่นๆ หรือกลไกการจัดการบริบท (เช่น State Machine ที่เข้มงวดขึ้นเพื่อบังคับการสิ้นสุด) สามารถเพิ่มประสิทธิภาพได้ถึง 53% เนื่องจากเป็นการจัดการกับปัญหาพื้นฐานของระบบมากกว่า

กรณีศึกษา: Kimi-K2 (วิกฤตการสิ้นสุดการทำงาน)

แม้ว่าความสับสนเกี่ยวกับการสิ้นสุดการทำงาน (FM-3.1 และ FM-1.5) จะเป็นรูปแบบความล้มเหลวที่แพร่หลายที่สุดสำหรับ Kimi-K2 แต่ Traces ที่ล้มเหลวของมันมักมีลักษณะเด่นคือ FM-2.6 (Action-Reasoning Mismatch) ซึ่งปรากฏใน Traces ที่ล้มเหลวสูงถึง 92%

ช่องว่างการดำเนินการ: แม้ว่าส่วนหนึ่งของการให้เหตุผลภายในมักจะถูกต้อง แต่ก็ประสบกับความล้มเหลว 92% ของ FM-2.6 (Action-Reasoning Mismatch) Agent มักจะระบุขั้นตอนต่อไปที่ถูกต้อง แต่กลับดำเนินการคำสั่งที่ซ้ำซ้อนหรือไม่เกี่ยวข้อง

กับดัก Meta-Loop: ประมาณ 25% ของ Traces ที่ล้มเหลวเกี่ยวข้องกับ FM-2.3 (Task Derailment) เมื่อการเรียกใช้เครื่องมือส่งคืนข้อผิดพลาดเล็กน้อย Agent มักจะละทิ้งเหตุการณ์หลัก และเข้าสู่วงจรการดีบักสคริปต์การตรวจสอบของตนเอง

Kimi-K2 เป็นตัวอย่างที่ดีของ Agent ที่ "คิดมากเกินไป" แต่ดำเนินการผิดพลาด

สิ่งที่ได้เรียนรู้ในการสร้าง Agent

จากการวิเคราะห์นี้ มีข้อคิดที่สำคัญสำหรับการสร้าง Agent ที่มีประสิทธิภาพในองค์กร:

• สำหรับ Frontier Models อย่าง Gemini: แยกการตรวจสอบออกไปภายนอก อย่าให้ LLM ตรวจการบ้านของตัวเอง กำหนดให้มีหลักฐานจากเครื่องมือที่ชัดเจนก่อนที่จะสรุปว่างานเสร็จสิ้น
• ควบคุมการสิ้นสุดและลูปการทำงานภายนอกโมเดล: ปัญหาการสิ้นสุดการทำงานเป็นสาเหตุการล้มเหลวที่พบบ่อย (FM-1.5) ควรเพิ่มเงื่อนไขการหยุดที่ชัดเจน และตัวตรวจจับลูปสำหรับการเรียกใช้เครื่องมือ/การดำเนินการซ้ำๆ

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

ฝึกฝนโมเดล AI ฟรี! ด้วย Unsloth และ Hugging Face Jobs

การพัฒนาปัญญาประดิษฐ์ (AI) กำลังก้าวหน้าอย่างรวดเร็ว และหนึ่งในเครื่องมือสำคัญที่ช่วยให้นักพัฒนาเข้าถึงการสร้างสรรค์ AI ได้ง่ายขึ้น คือการ Fine-tuning โมเดลภาษาขนาดเล็ก (Small Language Models - SLMs) ซึ่งมีความยืดหยุ่น ต้นทุนต่ำ และให้ผลลัพธ์ที่น่าประทับใจในงานเฉพาะทาง วันนี้เรามีข่าวดีสำหรับผู้ที่สนใจในการฝึกฝนโมเดล AI โดยเฉพาะการใช้ Unsloth ร่วมกับ Hugging Face Jobs ที่จะช่วยให้คุณทำสิ่งนี้ได้ ฟรี!

ทำไมต้องเลือกโมเดลขนาดเล็กสำหรับการ Fine-tuning?

โมเดลภาษาขนาดเล็ก เช่น LFM2.5-1.2B-Instruct เป็นตัวเลือกที่ยอดเยี่ยมสำหรับการ Fine-tuning ด้วยเหตุผลหลายประการ:

• ต้นทุนการฝึกต่ำ: ใช้ทรัพยากรน้อยกว่าโมเดลขนาดใหญ่ ทำให้ประหยัดค่าใช้จ่าย
• พัฒนาซ้ำได้รวดเร็ว: สามารถทดลองและปรับปรุงโมเดลได้อย่างว่องไว
• ประสิทธิภาพสูงในงานเฉพาะทาง: ถึงแม้จะมีขนาดเล็ก แต่ก็สามารถแข่งขันกับโมเดลขนาดใหญ่กว่าได้ในงานที่เจาะจง
• ใช้งานได้หลากหลาย: LFM2.5-1.2B-Instruct ใช้หน่วยความจำน้อยกว่า 1GB และถูกปรับให้เหมาะกับการใช้งานบนอุปกรณ์ต่างๆ เช่น คอมพิวเตอร์ตั้งโต๊ะ โทรศัพท์มือถือ หรือแม้แต่การทำงานบน CPU

ข้อเสนอสุดพิเศษ: เครดิตฟรีและสิทธิพิเศษสำหรับ Unsloth Jobs Explorers

เพื่อสนับสนุนชุมชนนักพัฒนา Hugging Face และ Unsloth กำลังมอบ เครดิตฟรี สำหรับการ Fine-tune โมเดลบน Hugging Face Jobs พร้อม รับสิทธิ์ใช้งาน Pro ฟรี 1 เดือน เพียงเข้าร่วมองค์กร Unsloth Jobs Explorers เพื่อรับสิทธิ์นี้

สิ่งที่ต้องเตรียมก่อนเริ่ม

การเริ่มต้นฝึกฝนโมเดล AI กับ Unsloth และ Hugging Face Jobs นั้นไม่ยุ่งยาก เพียงเตรียมสิ่งเหล่านี้:

• บัญชี Hugging Face: จำเป็นสำหรับการใช้งาน Hugging Face Jobs
• ตั้งค่าการชำระเงิน: เพื่อการยืนยันตัวตน (คุณสามารถตรวจสอบการใช้งานและจัดการการเรียกเก็บเงินได้ตลอดเวลา)
• Hugging Face Token: ที่มีสิทธิ์ในการเขียน (write permissions)
• (ทางเลือก) Coding Agent: เช่น Open Code, Claude Code หรือ Codex หากต้องการเครื่องมือช่วยในการเขียนโค้ด

เริ่มต้นฝึกฝนโมเดลด้วย hf jobs CLI

หากคุณต้องการฝึกฝนโมเดลโดยใช้ Hugging Face Jobs และ Unsloth คุณสามารถใช้ hf jobs CLI เพื่อส่ง Job ได้ง่ายๆ

ขั้นตอนที่ 1: ติดตั้ง hf CLI
รันคำสั่งต่อไปนี้:

pip install huggingface_hub[cli]

ขั้นตอนที่ 2: ส่ง Job เพื่อฝึกฝนโมเดล
หลังจากติดตั้ง hf CLI แล้ว คุณสามารถใช้คำสั่งเพื่อส่ง Job ได้ (โปรดดูรายละเอียดเพิ่มเติมในสคริปต์การฝึกฝนและเอกสารของ Hugging Face Jobs)

ติดตั้ง Skill ด้วย Coding Agent: วิธีที่ง่ายกว่า

Hugging Face Skills ช่วยลดความซับซ้อนในการฝึกฝนโมเดล AI เพียงแค่ใช้ Prompt คำสั่งกับ Coding Agent ที่คุณเลือก

สำหรับ Claude Code

Claude Code ค้นหา Skills ผ่านระบบ Plugin ของมัน ดังนั้นเราต้องติดตั้ง Hugging Face Skills ก่อน:

1. เพิ่ม Marketplace:

    /add-marketplace HuggingFace/skills

1. เรียกดู Skills ที่มี: ไปที่แท็บ "Discover" เพื่อดู Skills ที่มีให้เลือก
2. ติดตั้ง Model Trainer Skill:

    /install HuggingFace/model-trainer

ดูรายละเอียดเพิ่มเติมได้ในเอกสารการใช้งาน Hub ร่วมกับ Skills หรือเอกสาร Claude Code Skills

สำหรับ Codex

Codex ค้นหา Skills ผ่านไฟล์ AGENTS.md และไดเรกทอรี .agents/skills/

• ติดตั้ง Individual Skills:

    $skill-installer install HuggingFace/model-trainer

ดูรายละเอียดเพิ่มเติมได้ในเอกสาร Codex Skills และคู่มือ AGENTS.md

วิธีติดตั้งทั่วไป

อีกวิธีคือการ Clone repository ของ Skills และคัดลอก Skill ไปยังไดเรกทอรี Skills ของ Agent ของคุณ

เมื่อติดตั้ง Skill เรียบร้อยแล้ว ให้สั่ง Coding Agent ของคุณให้ฝึกฝนโมเดล:

/train model --model Qwen/Qwen2.5-0.5B --dataset trl-lib/Capybara --use-unsloth

Agent จะสร้างสคริปต์การฝึกฝน, ส่ง Job ไปยัง Hugging Face Jobs, และรายงาน Link สำหรับติดตามผลผ่าน Trackio

การทำงานเบื้องหลัง: Hugging Face Jobs

Training Jobs จะทำงานบน Hugging Face Jobs ซึ่งเป็น Cloud GPU ที่มีการจัดการเต็มรูปแบบ Agent จะทำหน้าที่:

• สร้างสคริปต์ UV พร้อม Dependencies
• ส่ง Job ผ่าน hf CLI
• รายงาน Job ID และ URL สำหรับติดตาม
• Push โมเดลที่ฝึกฝนเสร็จแล้วไปยัง Hugging Face Hub Repository ของคุณ

ตัวอย่างสคริปต์การฝึกฝน

Skill จะสร้างสคริปต์ที่คล้ายกับตัวอย่างนี้:

# Example Training Script (Conceptual)

from unsloth import FastLlamaModel

from datasets import load_dataset

from trl import SFTTrainer

from transformers import TrainingArguments



# Load model and tokenizer

model, tokenizer = FastLlamaModel.from_pretrained(

    "unsloth/Qwen2.5-0.5B-Instruct",

    max_seq_length=2048,

    torch_dtype="auto",

    load_in_4bit=True,

)



# Load dataset

dataset = load_dataset("trl-lib/Capybara", split="train")



# Training arguments

training_args = TrainingArguments(

    output_dir="output",

    per_device_train_batch_size=2,

    gradient_accumulation_steps=4,

    warmup_steps=10,

    max_steps=100,

    learning_rate=2e-4,

    fp16=True,

    logging_steps=1,

    optim="adamw_torch",

)



# Trainer

trainer = SFTTrainer(

    model=model,

    tokenizer=tokenizer,

    train_dataset=dataset,

    args=training_args,

    dataset_text_field="text",

)



# Train

trainer.train()



# Save model

trainer.save_model("your-hf-username/your-model-name")

(หมายเหตุ: นี่เป็นเพียงตัวอย่างสคริปต์เชิงแนวคิด รายละเอียดอาจแตกต่างกันไปตาม Skill และการตั้งค่า)

สำหรับภาพรวมราคา Hugging Face Spaces โปรดดูคู่มือที่นี่

เคล็ดลับในการทำงานกับ Coding Agents

• ระบุโมเดลและชุดข้อมูลให้ชัดเจน: รวมถึง Hub IDs (เช่น Qwen/Qwen2.5-0.5B และ trl-lib/Capybara) Agent จะค้นหาและยืนยันการผสมผสานเหล่านี้
• ระบุ Unsloth อย่างชัดเจน: หากคุณต้องการใช้ Unsloth มิฉะนั้น Agent จะเลือก Framework ตามโมเดลและงบประมาณ
• ขอประมาณการค่าใช้จ่าย: ก่อนเริ่ม Job ขนาดใหญ่
• ขอ Trackio Monitoring: เพื่อดู Loss Curves แบบเรียลไทม์
• ตรวจสอบสถานะ Job: โดยขอให้ Agent ตรวจสอบ Logs หลังจากการส่ง Job

แหล่งข้อมูลเพิ่มเติม

• Hugging Face Skills Repository: [ลิงก์ไปยัง Repository]
• Free Credits for Unsloth Jobs Explorers: [ลิงก์ไปยังหน้าข้อเสนอ]
• Unsloth Tutorial on Hugging Face Jobs: [ลิงก์ไปยัง Tutorial]
• Example Unsloth Jobs scripts: [ลิงก์ไปยังตัวอย่างสคริปต์]

การ Fine-tuning โมเดล AI ไม่เคยง่ายและเข้าถึงได้เท่านี้มาก่อน! ใช้โอกาสนี้ในการทดลองและสร้างสรรค์โมเดล AI ของคุณเองด้วย Unsloth และ Hugging Face Jobs

#AI #MachineLearning #FineTuning #HuggingFace #Unsloth

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