Microsoft Fara 1.5: ทดลอง Computer Use โดยมีจุดอนุมัติและร่องรอยตรวจสอบ

ถ่ายทอดจากคลิป Julian Goldie SEO และบทความต้นทางวันที่ 3 สิงหาคม 2026 ตัวเลข benchmark เป็นผลที่ Microsoft และคลิปนำเสนอ ไม่ใช่ผลทดสอบของเว็บไซต์ ตัวอย่าง portal เป็นเดโม ไม่ใช่การรับรองว่าระบบทำงานจริงได้ทุกภาษา ทุกเว็บไซต์ หรือหยุดขออนุมัติได้ถูกต้องทุกครั้ง ข้อเสนอธุรกิจไทยคงจากบทความต้นทาง · วิดีโอต้นทาง

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

คลิปจาก Julian Goldie SEO ชี้ให้เห็นว่า Microsoft กำลังเดิมพันกับ AI อีกประเภทหนึ่งชื่อ Fara 1.5 ซึ่งไม่ได้มีหน้าที่คุยกับเราเป็นหลัก แต่ทำหน้าที่มองหน้าจอ browser แล้วคลิก พิมพ์ เลื่อน และตัดสินใจทีละขั้นเพื่อไปถึงเป้าหมายงาน

ประเด็นที่น่าสนใจสำหรับเจ้าของธุรกิจไทยไม่ใช่แค่คะแนน benchmark ของ model แต่คือคำถามว่า งานหลังบ้านซ้ำๆ งานประสานหลายระบบ หรือการตรวจข้อมูลบนเว็บ จะส่งต่อให้ AI agent ทำแทนได้มากแค่ไหนโดยที่ยังควบคุมความเสี่ยงได้อยู่

สารบัญ

• Step 1: เข้าใจก่อนว่า Fara 1.5 ต่างจาก Chatbot ตรงไหน
• Step 2: เลือกขนาด model จากงานและทรัพยากรที่มี
• Step 3: ตั้งค่า demo ให้ agent ไม่หลุดงาน
• Step 4: วางรั้วความปลอดภัยก่อนให้ AI แตะระบบงาน
• Step 5: แปลงตัวอย่าง portal ให้เป็น workflow ของธุรกิจไทย
• Step 6: Actionable Insights สำหรับเริ่มใช้ Browser Automation
• Step 7: Troubleshooting เมื่อ Agent คลิกพลาดหรือหยุดกลางทาง
• Step 8: การต่อยอดหลังจาก workflow แรกนิ่งแล้ว
• Step 9: สรุป Checklist ทั้งหมดก่อนนำ Fara 1.5 ไปใช้

Step 1: เข้าใจก่อนว่า Fara 1.5 ต่างจาก Chatbot ตรงไหน

Fara 1.5 เป็นกลุ่ม computer-use model จาก Microsoft Research มี 3 ขนาด ได้แก่ 4B, 9B และ 27B โดยพัฒนาบน Qwen 3.5 น้ำหนัก model เปิดให้ใช้งานบน Hugging Face ภายใต้สัญญาอนุญาต MIT และยังสามารถนำไปใช้งานผ่าน Microsoft Foundry ได้สำหรับทีมที่ไม่ต้องการจัดการ hardware เอง

ความต่างหลักคือ chatbot รับข้อความแล้วสร้างข้อความตอบกลับ แต่ Fara มองภาพหน้าจอเหมือนที่มนุษย์เห็น จากนั้นเลือก action เดียว เช่น คลิกปุ่ม พิมพ์ข้อความ เลื่อนหน้า เปิด URL หรือค้นหา แล้วจึงจับภาพหน้าจอใหม่เพื่อคิดต่อ

วงจรนี้เรียกว่า observe, think, act, log คือสังเกต คิด ลงมือทำ และบันทึกร่องรอยการทำงาน การแยก action ให้เล็กลงมีข้อดีตรงที่เราตรวจสอบได้ว่า AI ทำอะไรในแต่ละจุด แทนที่จะปล่อยให้ระบบวิ่งยาวแล้วค่อยพบว่าผลลัพธ์ผิดตอนจบ

จุดเด่นอีกเรื่องคือ Fara ใช้การมองเห็นเป็นหลัก แทนการอ่าน HTML หรือ accessibility tree ที่อยู่เบื้องหลังหน้าเว็บ Model จึงประเมินพิกัด pixel ที่ควรคลิกโดยตรง วิธีนี้เหมาะกับเว็บที่ใช้ widget เฉพาะทาง หน้า dashboard ภายในบริษัท หรือระบบเก่าที่โครงสร้างหน้าเว็บไม่เป็นมาตรฐาน

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

Step 2: เลือกขนาด model จากงานและทรัพยากรที่มี

Fara 1.5 มีขนาดไม่เท่ากัน และไม่จำเป็นต้องเริ่มที่ model ใหญ่ที่สุด 4B เป็นจุดเริ่มต้นที่เหมาะกับการทดลองบนเครื่อง local เพราะเบา เร็ว และยังทำคะแนน Online-Mind2Web ได้ 57.3% ซึ่งต่ำกว่า OpenAI Operator ที่คลิปอ้างไว้ 58.3% อยู่ 1 จุดเปอร์เซ็นต์

รุ่น 9B เป็นทางเลือกกลางสำหรับงานที่ต้องการความสามารถเพิ่มขึ้น ส่วน 27B รองรับ context window 262,000 token จึงตามงานที่มีขั้นตอนยาวได้มากกว่า แม้จะเก็บภาพหน้าจอล่าสุดไว้เพียง 3 ภาพ และแปลงร่องรอยก่อนหน้าเป็นข้อความเพื่อลดภาระ context รุ่นนี้ต้องใช้ GPU จริงจัง โดย Microsoft แนะนำให้กระจายการประมวลผลอย่างน้อย 2 GPU

ตัวเลข benchmark ที่นำเสนอมีภาพรวมดังนี้

• Online-Mind2Web 300 งานบน 136 เว็บไซต์: Fara 1.5 27B ทำได้ 72.3%
• OpenAI Operator ทำได้ 58.3% และ Gemini 2.5 Computer Use ทำได้ 57.3% ใน benchmark เดียวกัน
• WebVoyager: 27B ทำได้ 89.3%, 9B ทำได้ 86.6%, 4B ทำได้ 80.8%
• WebTailBench ซึ่งเน้นงาน long-tail: 27B ทำ outcome success ได้ 40.2%, 9B ได้ 32.3%, 4B ได้ 27.4%

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

สำหรับธุรกิจไทย แนวคิดที่ปลอดภัยกว่าคือเริ่มจาก งานสั้น งานซ้ำ และมีนิยามผลลัพธ์ชัด เช่น ตรวจว่าคำสั่งซื้อรายการใดค้างอยู่ใน dashboard, รวบรวมสถานะเคสจาก portal, หรือเปิดรายงานยอดขายแล้วดึงเฉพาะตัวเลขที่กำหนด ไม่ควรเริ่มจาก “จัดการงาน admin ทั้งหมดให้หน่อย” เพราะคำสั่งกว้างทำให้ agent เดาทิศทางเองมากเกินไป

Step 3: ตั้งค่า demo ให้ agent ไม่หลุดงาน

Fara มีพื้นที่ทดลองบน Hugging Face ที่ให้กรอก start URL, ระบุเป้าหมาย, กำหนดจำนวน agent steps และเลือกว่าจะอนุญาต action ที่ย้อนกลับไม่ได้หรือไม่ การตั้งค่าที่สำคัญที่สุดคือ toggle ของ irreversible actions ซึ่งปิดเป็นค่าเริ่มต้น

แผงด้านขวาจะแสดงหน้าจอใหม่ของแต่ละขั้น พร้อม action ที่เลือกและ log การตัดสินใจ เมื่องานจบ ลำดับการทำงานจะถูกแสดงย้อนหลังเป็น slideshow ทำให้เราตรวจได้ว่า agent เริ่มหลงทางที่จุดใด

สำหรับการเริ่มทดสอบ ควรตั้งค่าตามหลักง่ายๆ ดังนี้

1. ระบุ start URL เสมอ เพื่อตัดขั้นตอนค้นหาเว็บจากศูนย์
2. จำกัด step ไว้ราว 10 ถึง 20 ขั้นในรอบแรก
3. เขียนเป้าหมายเป็นผลลัพธ์ ไม่ใช่สั่งลำดับการคลิกละเอียดเกินไป
4. ระบุเงื่อนไขที่สำคัญ เช่น workspace, ช่วงเวลา, สถานะ และรูปแบบสรุป
5. ปิดสิทธิ์ action ที่ย้อนกลับไม่ได้จนกว่าจะตรวจพฤติกรรมได้สม่ำเสมอ

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

ข้อสังเกตสำคัญคือ Fara ทำงานกับภาษาอังกฤษเป็นหลัก หากระบบหลังบ้านของเราเป็นภาษาไทย หรือใช้ปุ่มและข้อมูลภาษาไทยจำนวนมาก ควรทดสอบกับข้อมูลจำลองก่อนเสมอ อย่าอนุมานว่า model ที่ทำ benchmark ภาษาอังกฤษได้ดีจะเข้าใจ workflow ภาษาไทยในระดับเดียวกัน

Step 4: วางรั้วความปลอดภัยก่อนให้ AI แตะระบบงาน

ความสามารถในการคลิกคือพลัง และพลังนี้มีความเสี่ยงมากกว่า chatbot อย่างชัดเจน Fara ถูกฝึกให้หยุดถามที่ “critical points” 3 กลุ่ม ได้แก่ ข้อมูลจำเป็นไม่ครบ คำสั่งคลุมเครือ และ action ที่ย้อนกลับไม่ได้

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

Microsoft แนะนำให้รันผ่าน harness ของตนเองหรือ MagenticLite ซึ่งมี sandbox browser, container ที่ไม่เข้าถึงไฟล์ในเครื่อง, allow list สำหรับกำหนด domain ที่เข้าได้, watch mode สำหรับเก็บ log และปุ่มหยุดฉุกเฉิน แนวทางความปลอดภัยของ Microsoft Security ช่วยย้ำหลักเดียวกันว่า AI ต้องมีขอบเขตสิทธิ์และร่องรอยตรวจสอบ

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

จุดตั้งต้นที่เหมาะสมคือใช้บัญชีทดสอบ แยก browser profile สำหรับ agent จำกัด domain และกำหนดว่าการเปลี่ยนแปลงทุกประเภทต้องให้คนอนุมัติ ผลลัพธ์จากแต่ละรอบควรเก็บ log ไว้เปรียบเทียบ ไม่ใช่ดูแค่ว่างานสำเร็จหรือไม่

Step 5: แปลงตัวอย่าง portal ให้เป็น workflow ของธุรกิจไทย

ตัวอย่างที่ชัดที่สุดคือ portal สำหรับจัดการงานทดลอง: เข้า workspace ที่ระบุ ค้นหา job ที่ล้มเหลว กด resubmit แล้วอ่าน final log ของงานที่สำเร็จเพื่อสรุปผล Fara จะมอง selector เลือก workspace รอให้ตารางโหลด ใช้คอลัมน์สถานะหรือ filter หา failed jobs เข้าแต่ละรายการ แล้วมองหาปุ่ม resubmit

ก่อนกด resubmit ระบบจะถึงจุด critical point เพราะเป็นการเปลี่ยนสถานะ หากได้รับอนุญาตแล้ว agent จะทำต่อและใช้ action สำหรับจดจำชื่อ job เพื่อไม่ให้ลืมเมื่อเดินไปอีกหลายขั้น จากนั้นทำซ้ำกับรายการอื่น และส่งสรุปเมื่อจบงาน

ถ้าแปลงมาเป็นธุรกิจไทย workflow อาจหน้าตาแบบนี้

• ร้านค้าออนไลน์: ตรวจคำสั่งซื้อที่ชำระแล้วแต่คลังยังไม่ยืนยัน และสรุปส่งทีม fulfillment โดยไม่กดเปลี่ยนสถานะเอง
• เอเจนซี: เปิด portal โฆษณาของลูกค้า อ่านแคมเปญที่งบใกล้หมด แล้วสรุปเป็นรายงานประจำวัน
• ทีมบริการลูกค้า: ค้นหา ticket ที่สถานะรอทีมภายในเกิน SLA แล้วรวบรวมลิงก์เคสเพื่อส่งต่อหัวหน้าทีม
• ฝ่ายปฏิบัติการ: ตรวจรายการ failed jobs ในระบบภายใน แล้วให้คนกดยืนยันเฉพาะรายการที่ต้อง rerun

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

Step 6: Actionable Insights สำหรับเริ่มใช้ Browser Automation

• เลือกงานที่เสียเวลาวันละ 15 ถึง 30 นาที: งานที่ต้องเปิดหลายหน้าเพื่ออ่านข้อมูลคือผู้สมัครที่ดี ไม่จำเป็นต้องเริ่มจากงานใหญ่ที่สุด
• กำหนด Definition of Done: ระบุว่าต้องได้รายงานอะไร มีคอลัมน์ใด และห้ามทำ action ใด ไม่ใช่แค่บอกให้ “ไปเช็กให้หน่อย”
• เริ่มจากโหมดอ่านอย่างเดียว: ให้ agent ค้นหา กรอง และสรุปก่อน แล้วค่อยเพิ่มสิทธิ์แก้ไขเมื่อผ่านการทดสอบหลายรอบ
• ล็อกความละเอียดหน้าจอ: คลิปแนะนำให้เริ่มทดสอบที่ความละเอียด 1440 x 900 ควรตรวจค่าที่ harness รองรับและทดสอบความแม่นยำของพิกัดจริง ไม่ถือว่าความละเอียดเพียงอย่างเดียวรับประกันผล
• วัดผลจาก error rate ไม่ใช่เดโม: เก็บจำนวนรอบที่สำเร็จ จุดที่ต้องให้คนช่วย และเวลาที่ประหยัดได้จริงก่อนขยายงาน

Step 7: Troubleshooting เมื่อ Agent คลิกพลาดหรือหยุดกลางทาง

• ปัญหา: Agent คลิกผิดปุ่มตั้งแต่ต้นงาน
  สาเหตุ: ขนาดหน้าจอไม่สอดคล้องกับการฝึก หรือหน้าเว็บโหลดไม่ทัน
  วิธีแก้: ตั้งหน้าจอใกล้ 1440 x 900, ลด animation ที่ไม่จำเป็น, เพิ่มเวลารอหลังเปลี่ยนหน้า และทดสอบเฉพาะ workflow สั้นก่อน
• ปัญหา: Agent เดินวนหรือใช้ step หมดก่อนงานจบ
  สาเหตุ: คำสั่งกว้างเกินไป หรือเริ่มจาก URL ที่ไกลจากจุดทำงาน
  วิธีแก้: ใส่ start URL ที่ถูกต้อง, แยกงานเป็นช่วงย่อย, ระบุ filter และผลลัพธ์ที่ต้องการให้ชัด
• ปัญหา: Agent หยุดถามก่อน submit หรือเปลี่ยนสถานะ
  สาเหตุ: ระบบตรวจพบ action ที่ย้อนกลับไม่ได้ ซึ่งเป็นพฤติกรรมที่ควรเกิด
  วิธีแก้: ตรวจรายการในหน้าจอยืนยันก่อนอนุมัติ และอย่าเปิดสิทธิ์ถาวรเพียงเพื่อให้รอบเดียวเดินต่อ
• ปัญหา: Agent เข้าเว็บหรืออ่านข้อความที่ไม่เกี่ยวข้องกับงาน
  สาเหตุ: หน้าเว็บมีข้อความชักนำหรือ prompt injection ที่พยายามเปลี่ยนเป้าหมาย
  วิธีแก้: ใช้ allow list เฉพาะ domain ที่จำเป็น, เขียนคำสั่งห้ามทำตามคำสั่งบนหน้าเว็บที่ขัดกับเป้าหมาย และเปิด watch mode
• ปัญหา: ผลสรุปไม่ตรงกับข้อมูลในระบบภาษาไทย
  สาเหตุ: ข้อจำกัดด้านภาษาและการอ่านองค์ประกอบบนหน้าเว็บ
  วิธีแก้: ให้ agent ส่งหลักฐานเป็น screenshot หรือ URL ของรายการที่พบ และให้คนตรวจผลก่อนใช้ตัดสินใจสำคัญ

Step 8: การต่อยอดหลังจาก workflow แรกนิ่งแล้ว

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

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

แนวคิดสุดท้ายคือออกแบบ workflow แบบ human-in-the-loop สำหรับงานที่เปลี่ยนสถานะ เช่น คืนเงิน ปรับงบโฆษณา หรือส่งข้อความถึงลูกค้า ให้ AI เตรียมข้อมูลและข้อเสนอแนะ ส่วนคนตัดสินใจในจุดที่กระทบรายได้ ความสัมพันธ์ และความน่าเชื่อถือของธุรกิจ

Step 9: สรุป Checklist ทั้งหมดก่อนนำ Fara 1.5 ไปใช้

• ☐ เลือกงานบน browser ที่ซ้ำ มีเป้าหมายชัด และมีความเสี่ยงต่ำ
• ☐ เริ่มทดลองด้วย Fara 1.5 4B หรือ environment ที่ควบคุมได้
• ☐ ตั้ง start URL ให้ใกล้จุดทำงานที่สุด
• ☐ ตั้ง step limit 10 ถึง 20 สำหรับรอบทดสอบ
• ☐ เขียน prompt ที่บอกผลลัพธ์ ขอบเขต และสิ่งต้องห้าม
• ☐ ปิด irreversible actions ในช่วงแรก
• ☐ ใช้ sandbox browser, allow list และ log ทุก action
• ☐ ตั้งหน้าจอใกล้ 1440 x 900 เพื่อช่วยเรื่องความแม่นยำในการคลิก
• ☐ ให้คนอนุมัติก่อนทุก action ที่ส่งผลต่อข้อมูล ลูกค้า หรือการเงิน
• ☐ วัดเวลาที่ลดลงและ error rate ก่อนขยายไป workflow ถัดไป

Microsoft Fara 1.5 ทำให้ภาพของ AI agent ที่ “ทำงานบนเว็บแทนคน” ใกล้ใช้งานจริงขึ้น โดยเฉพาะเมื่อ model ขนาดเล็กยังมีศักยภาพสูงพอสำหรับงานเฉพาะทาง แต่โอกาสที่แท้จริงไม่ได้อยู่ที่การปล่อย AI ทำทุกอย่างเอง อยู่ที่การออกแบบ workflow ให้ AI รับงานที่น่าเบื่อ ตรวจสอบได้ และหยุดในจุดที่มนุษย์ควรเป็นคนตัดสินใจ

ข้อมูลรุ่นและข้อจำกัดเพิ่มเติม: Microsoft Research Fara1.5 และ model card Fara1.5-27B