งานคัดลอก ตรวจเอกสาร ตอบคำถามเดิม และติดตามคำตอบอาจกินเวลาที่ทีมต้องใช้กับงานอื่น กรณีของ Niels Rogge ที่ Hugging Face เริ่มจากการแยกขั้นตอนที่เขาทำซ้ำ แล้วเลือกว่าจะล็อกเส้นทางเป็น workflow หรือให้ agent ตัดสินใจตามข้อมูลที่พบ
ในวิดีโอบนช่อง AI Engineer Niels เล่าว่าเขาใช้ระบบช่วยงาน outreach ไปยังนักวิจัย ตั้งแต่คัดกรอง paper อ่านข้อมูล ตรวจเอกสาร สร้าง GitHub issue ไปจนถึงติดตามคำตอบ ผลและสถิติที่เขายกมาเป็นคำรายงานของผู้สร้างระบบ ไม่มี issue receipt หรือผลทดสอบแยกต่างหากในหลักฐานบทความนี้
หา “งานคอขวด” ที่ทำให้ข้อมูลดีแต่ถูกค้นหาไม่เจอ
Niels เล่าว่าทีม Community Science พบงานวิจัยที่เผยแพร่ model weights หรือ dataset กระจัดกระจายบน Google Drive, GitHub Releases, Dropbox หรือ Zenodo ทำให้คนที่ต้องการใช้ผลงานค้นหาหรือเชื่อมข้อมูลได้ยาก
ในบทบรรยายเขาอธิบายว่า Hugging Face เชื่อม paper กับโมเดลและชุดข้อมูล มี metadata ให้ค้นหาตามภาษา ประเภทโมเดล หรือ library และใช้ model card หรือ dataset card ช่วยจัดเอกสารของ artifact งาน outreach ของเขาชวนผู้วิจัยนำไฟล์และข้อมูลเหล่านี้มารวมไว้บน Hub
ตัวอย่างประยุกต์สำหรับธุรกิจไทยคือข้อมูลลูกค้าหรือคำตอบบริการที่กระจายอยู่หลายไฟล์ หลายช่องทาง หรือคู่มือภายในที่ค้นไม่พบเมื่อต้องใช้ ตัวอย่างเหล่านี้เป็นโจทย์ที่บทความเสนอ ไม่ใช่กรณีศึกษาของทีม Hugging Face
เกณฑ์คัดโจทย์ที่บทความเสนอมี 3 ข้อ:
- มีข้อมูลหรือคำขอไหลเข้ามาต่อเนื่อง
- ทีมต้องตรวจและตัดสินใจด้วยรูปแบบเดิมซ้ำๆ
- หากตอบช้าหรือตกหล่น จะกระทบรายได้ ความพึงพอใจ หรือความน่าเชื่อถือ
ตัวอย่างประยุกต์คือคัดแยก lead สรุปใบเสนอราคา ตามเอกสารลูกค้า ตรวจข้อมูลสินค้า หรือจัดหมวดคำถามจากหลายช่องทาง โดยเลือกงานที่ทีมอธิบายขั้นตอนและตรวจผลได้
เขียนงานเดิมของเราให้เป็นแผนผัง ก่อนให้ AI ทำแทน
Niels ไม่ได้เริ่มจาก agent ที่ซับซ้อน เขาเริ่มจากการแยกสิ่งที่ทำด้วยตนเองอยู่แล้วออกมาเป็นลำดับงานชัดเจน ได้แก่ ค้นหา GitHub ของ paper อ่าน README ตรวจว่ามีโมเดลหรือ dataset บน Hugging Face อยู่แล้วหรือไม่ เช็กว่าข้อมูลกำกับและเอกสารครบหรือเปล่า จากนั้นจึงเลือกว่าจะสร้าง pull request เพื่อเติมเอกสาร หรือเปิด GitHub issue เพื่อชวนเจ้าของงานย้ายไฟล์เข้ามา
กรณีนี้ชี้ให้เห็นประโยชน์ของการอธิบายกระบวนการเดิมก่อนเลือกเครื่องมือ: ข้อมูลเข้าเป็นอะไร ต้องอ่านอะไร และเงื่อนไขใดนำไปสู่ผลลัพธ์แบบไหน การมีลำดับงานชัดช่วยให้ทีมออกแบบและตรวจ workflow ได้
ตัวอย่างโครงงานธุรกิจที่บทความเสนอให้เขียนก่อนทดลอง:
- ข้อมูลเข้า: เช่น อีเมลลูกค้า แบบฟอร์ม lead หรือใบแจ้งปัญหา
- ขั้นตอนตรวจ: ต้องอ่านช่องไหน ตรวจเงื่อนไขอะไร และหาแหล่งข้อมูลใด
- การตัดสินใจ: กรณีไหนตอบอัตโนมัติ กรณีไหนส่งต่อคน
- ผลลัพธ์: ต้องสร้างข้อความ บันทึก CRM แจ้ง Slack หรือเปิด ticket หรือไม่
- ข้อห้าม: สิ่งที่ AI ไม่มีสิทธิ์อนุมัติ ส่ง หรือแก้ไขเอง
ตัวอย่างประยุกต์: บริษัทรับเหมาอาจให้ระบบอ่านแบบฟอร์มขอราคา แยกประเภทงาน ตรวจข้อมูลหน้างาน และสร้างร่างอีเมลขอข้อมูลเพิ่ม โดยกำหนดให้คนตรวจราคาสุดท้ายและข้อความก่อนส่งออก
เลือก workflow ก่อน agent เมื่อเส้นทางงานชัด
Niels แยก workflow ที่กำหนดเส้นทางไว้ก่อนและเรียก LLM API ตามขั้นตอน ออกจาก agent ที่ใช้ model วนเรียกเครื่องมือ เขามองแบบแรกว่าคาดเดาเส้นทางได้มากกว่าและควบคุมขั้นตอนได้ แต่ยืดหยุ่นน้อยกว่า
ส่วน autonomous agent เลือกขั้นตอนและเรียกเครื่องมือใน loop จนถึงเงื่อนไขจบงาน เขามองว่าแบบนี้ยืดหยุ่นกว่าแต่คาดเดาได้ยากกว่า และย้ำว่าสองแนวทางสามารถผสมกันตามงานได้
เขาเล่าว่างาน outreach ช่วงที่เริ่มสร้างในปี 2024 ใช้ Python script เรียก LLM API ตามจุดที่กำหนด โดยไม่ใช้ agent framework และอ้างถึงแนวทางเริ่มจากระบบง่ายในบทความ Building Effective Agents ของ Anthropic บทความนี้รายงานสิ่งที่เขาอ้างในคลิป ไม่ได้ใช้เป็นหลักฐานว่าคำแนะนำภายนอกหรือผลิตภัณฑ์ปัจจุบันเหมือนเดิมทุกข้อ
ตัวอย่าง workflow สำหรับทดลองในองค์กรที่บทความเสนอ:
- อ่านอีเมลเข้า แล้วติดป้ายหมวดฝ่ายขาย บัญชี หรือบริการลูกค้าให้ทีมตรวจ
- ดึงข้อมูลจากใบสั่งซื้อ แล้วเตรียมชีตสำหรับตรวจข้อมูล
- สร้างร่างสรุปรายงานยอดขายให้ทีมตรวจ
- ตรวจเอกสารที่ขาดข้อมูล แล้วร่างข้อความขอรายละเอียดเพิ่ม
ข้อเสนอประยุกต์คือเลือกเครื่องมือตามเส้นทางงานและผลที่ตรวจได้ งานที่มีเงื่อนไขชัดอาจเริ่มด้วย workflow ส่วนงานที่ต้องค้นข้อมูลหรือเลือกขั้นตอนหลากหลายจึงค่อยทดลอง agent พร้อมเปรียบเทียบคุณภาพ ต้นทุน และภาระที่คนต้องตรวจ
ตั้งเวลาทำงานและติดตามต้นทุนเหมือนบริหารพนักงานหนึ่งคน
Niels อธิบายว่างาน outreach ของเขารันทุกคืนด้วย cron job ผ่าน GitHub Actions เพื่ออ่าน paper และเลือกเปิด issue หรือสร้าง pull request ตามเงื่อนไข เป็นตัวอย่างระบบตามรอบที่เขาใช้อยู่ในช่วงที่บรรยาย ไม่ได้ยืนยันราคา โควตา หรือเงื่อนไขบริการในปัจจุบัน
เขาใช้ Langfuse สำหรับ tracing เพื่อตรวจ input, output, prompt, ค่าใช้จ่าย และ latency สิ่งที่หลักฐานรองรับคือเครื่องมือและข้อมูลที่เขาบอกว่าติดตาม ไม่ใช่ผลวัดต้นทุนหรือประสิทธิภาพจริงของระบบ
ข้อเสนอสำหรับงานธุรกิจคือเก็บข้อมูลเข้า ผลลัพธ์ แหล่งอ้างอิง และสถานะงานให้ตรวจย้อนกลับได้ เพื่อช่วยแยกว่าข้อผิดพลาดมาจากข้อมูล prompt หรือการเชื่อมต่อ แทนการดูเฉพาะข้อความสุดท้าย
ตัวอย่างตัวชี้วัดบน dashboard ที่บทความเสนอให้เลือกตามงาน:
- จำนวนงานที่รับเข้า ทำสำเร็จ และล้มเหลว
- จำนวนงานที่ต้องส่งต่อให้คน
- ค่าใช้จ่ายต่อรายการ และค่าใช้จ่ายรวมต่อเดือน
- เวลาตั้งแต่รับงานจนได้ผลลัพธ์
- อัตราคำตอบผิด หรืออัตราที่ทีมแก้ไขงาน AI
รายการตัวชี้วัดข้างต้นเป็นข้อเสนอเพิ่มเติมจากกรณี tracing ไม่ใช่ dashboard ที่พิสูจน์แล้วในคลิป ทีมควรกำหนดเป้าหมายและเทียบกับงานเดิมก่อนสรุปว่าระบบคืนเวลาหรือคุ้มต้นทุน
ใช้ autonomous agent กับงานติดตามที่คำตอบหลากหลาย
เมื่อ workflow เปิด GitHub issue มากขึ้น Niels พบงานคอขวดที่การอ่านแจ้งเตือนและติดตามคำตอบ เขาจึงทดลอง agent สำหรับขั้นตอนนี้ ส่วน follow-up เขายังเริ่มงานเองผ่าน skill แล้วรับรายงานผลใน Slack ของทีม
ตามคำอธิบายของเขา ระบบ follow-up ใช้ Claude Agent SDK พร้อม Bash, Hugging Face CLI และ skill วิธีใช้ CLI โดยมี sandbox เป็นขอบเขตงาน รายละเอียดนี้เป็นภาพสถาปัตยกรรมที่เขารายงาน ไม่ใช่คู่มือ API หรือการรับรอง compatibility ของรุ่นปัจจุบัน
ข้อเสนอประยุกต์เรื่องขอบเขตงานคือเริ่มด้วยเครื่องมือและข้อมูลที่จำเป็นต่อโจทย์เดียว แล้ววัดผลก่อนเพิ่มสิทธิ์หรือเชื่อมระบบอื่น ไม่ต้องให้ agent เข้าถึงทุกระบบตั้งแต่การทดลองครั้งแรก
งานแบบใดที่ธุรกิจอาจพิจารณา autonomous agent ได้บ้าง
- ติดตามสถานะ lead ที่มีคำถามและเงื่อนไขต่างกัน
- ช่วยไล่แก้ ticket ภายในที่ต้องค้นคู่มือหลายแหล่ง
- ตรวจและเติมเอกสารสินค้าโดยอ้างอิงข้อมูลหลายไฟล์
- สรุปประเด็นจากการคุยกับลูกค้า แล้วเสนอขั้นตอนถัดไปให้ทีมอนุมัติ
สำหรับการทดลองกับงานธุรกิจ บทความเสนอให้เริ่มจากอ่านข้อมูลและสร้างร่าง พร้อมกำหนดจุดที่คนตรวจหรืออนุมัติการส่งข้อความและแก้ข้อมูล ข้อนี้เป็นข้อเสนอของบทความ ไม่ใช่ขั้นตอนอนุมัติที่ Niels ยืนยันว่าใช้ในระบบ outreach ของเขา
แยกงานขนาน แต่ไม่ปล่อยให้ AI ส่งข้อความแบบไร้การควบคุม
Niels อธิบายการกระจาย follow-up เป็น container แยกกัน โดยหนึ่ง agent loop ประมวลผลหนึ่ง GitHub issue เพื่อทำหลายงานขนานกัน หลักฐานที่มีเป็นคำบรรยายสถาปัตยกรรม ไม่ใช่ผลทดสอบว่าความผิดพลาดของแต่ละงานจะไม่กระทบระบบอื่น
เขายกตัวอย่างผลที่รายงานเอง เช่น การย้ายโมเดล PaddleOCR มายัง Hugging Face และการเติม model card จาก paper กับ README ส่วน dataset 400 GB เป็นตัวอย่างผู้ที่ติดต่อว่าต้องการเผยแพร่ ไม่ใช่หลักฐานว่าเผยแพร่สำเร็จแล้ว เขายังรายงานว่า issue หลายพันรายการมีคำตอบเชิงลบสองครั้ง ซึ่งไม่มีบันทึกแยกในหลักฐานนี้ให้ตรวจจำนวนหรืออัตราตอบรับ
Niels บอกว่าเขาไม่ได้แจ้งผู้รับว่าข้อความเขียนโดย agent เพราะมองว่าส่งเนื้อหาแบบที่ตนเคยส่ง และกังวลว่าเมื่อรู้ว่าเป็น bot ผู้รับอาจปิด issue รายละเอียดนี้เป็นข้อจำกัดของกรณีที่ควรรับรู้ ไม่ใช่คำแนะนำให้ธุรกิจทำตาม
ข้อเสนอของบทความสำหรับการติดต่อภายนอกคือกำหนดนโยบายข้อความและเจ้าของความรับผิดชอบให้ชัด รวมถึงให้ผู้รับขอคุยกับคนได้ ประเมินทั้งความถูกต้อง ประโยชน์ต่อผู้รับ และความคาดหวังในการสื่อสาร ไม่ใช้จำนวนข้อความหรือคำตอบเชิงบวกเป็นเกณฑ์เดียว
ทำ evaluation ก่อนขยายปริมาณงาน
Niels ตั้งคำถามว่าระบบจะหลีกเลี่ยงข้อความคุณภาพต่ำหรือ spam ได้อย่างไร และย้ำเรื่อง evaluation โดยอ้างถึงแหล่งความรู้ของ Hamel Hussein บทความนี้ไม่ได้มีผลประเมินหรืออัตราข้อผิดพลาดของระบบดังกล่าว
ข้อเสนอประยุกต์คือเลือกตัวอย่างงานหลายลักษณะให้ผู้รู้ในทีมตรวจตามเกณฑ์เดียวกัน เช่น ข้อมูลถูกต้องหรือไม่ แหล่งอ้างอิงครบหรือไม่ น้ำเสียงเหมาะหรือไม่ และควรส่งจริงหรือส่งต่อคน เก็บผลตรวจและเหตุผลก่อนเพิ่มปริมาณงาน โดยไม่ถือจำนวนตัวอย่างใดเป็นขั้นต่ำที่รับประกันคุณภาพ
ในการตรวจตัวอย่าง ไม่ควรดูเพียงความลื่นไหลของภาษา ควรตรวจข้อมูล สิทธิ์การตัดสินใจ และผลที่ข้อความอาจทำให้ผู้รับเข้าใจด้วย เช่น ระบบอาจเขียนข้อความดูดีแต่กล่าวถึงส่วนลดที่ยังไม่ได้อนุมัติ
อ้างอิง How I automate my own job at Hugging Face using agents — Niels Rogge, Hugging Face โดย Niels Rogge บนช่อง AI Engineer วิดีโอเผยแพร่วันที่ 20 สิงหาคม 2026 ข้อมูลวันที่นี้เป็นวันอัปโหลด ไม่ใช่วันจัดงาน คำบรรยายที่บันทึกไว้มีตำแหน่งเวลาแรก 00:17 และท้าย 20:12 จากวิดีโอความยาว 20:37 โดยไม่ใช้ตำแหน่งเวลาท้ายยืนยันว่ามีคำบรรยายครบทุกวินาที
