Browser Agent ราคาประหยัดด้วย Haiku 5.5: เมื่อคิวตรวจสอบกลายเป็นต้นทุนใหม่

Anthropic เปิดตัว Claude Haiku 5.5 เมื่อวันที่ 7 ตุลาคมที่ผ่านมา โดยวางตำแหน่งให้เน้นการทำงานบนเว็บเบราว์เซอร์โดยเฉพาะ ในบทความเปิดตัวระบุว่าโมเดลนี้เหมาะสำหรับ “งานที่ต้องการความเร็ว เช่น การบริการลูกค้าแบบเรียลไทม์และการใช้งานเบราว์เซอร์ (browser use)” ขณะที่หน้าผลิตภัณฑ์ได้ยกตัวอย่างการกรอกแบบฟอร์ม การคีย์ข้อมูล และการโอนย้ายข้อมูลระหว่างแอปพลิเคชัน นอกจากนี้ในการเปิดตัวรอบเดียวกัน ยังได้เพิ่มฟีเจอร์ computer use และ browser use เข้าสู่ Python SDK และ TypeScript SDK ของ Anthropic ในสถานะเบต้าอีกด้วย สำหรับผลทดสอบบน OSWorld 2.1 ซึ่งเป็นชุดทดสอบวัดประสิทธิภาพด้าน computer use ที่ Anthropic ใช้อ้างอิง Haiku 5.5 ทำคะแนนได้ 72.4% โดยมีต้นทุนราว 0.61 ดอลลาร์ต่อครั้งเมื่อตั้งค่า effort ระดับสูงสุด (max) และทำได้ 53.3% ด้วยต้นทุนราว 0.13 ดอลลาร์เมื่อใช้ค่าเริ่มต้นระดับกลาง (medium)

อย่างไรก็ดี ตัวเลขที่เป็นพาดหัวข่าวดังกล่าวคือคะแนนที่ได้จากการทำงานสำเร็จบางส่วน (partial credit) หากลองอ่านรายงานระบบ (system card) อย่างละเอียด จะพบว่าการทดสอบรอบเดียวกันนั้นมีอัตราการทำงานผ่านเกณฑ์แบบสมบูรณ์ครบถ้วน (strict pass rate) อยู่ที่เพียง 37.1% เท่านั้น นั่นหมายความว่า ทีมงานที่นำ Haiku 5.5 ไปต่อเข้ากับระบบอัตโนมัติบนเบราว์เซอร์จะได้งานที่รันด้วยต้นทุนเพียงไม่กี่เซนต์ แต่ผลลัพธ์ส่วนใหญ่มักเสร็จเพียงบางส่วน ค่ารันระบบอาจถูกลงจริง แต่ต้นทุนในการตรวจทานไม่ได้ลดลงตามไปด้วย และสำหรับทีมที่เปิดให้ Agent หลายตัวทำงานพร้อมกัน ต้นทุนที่แท้จริงของระบบอัตโนมัติบนเบราว์เซอร์จึงตกไปอยู่กับคนที่ต้องคอยนั่งตรวจผลลัพธ์เหล่านั้น

TL;DR

จากการทดสอบบนชุดข้อมูลออฟไลน์ OSWorld 2.1 ของ Anthropic นั้น Haiku 5.5 ทำคะแนนสำเร็จบางส่วนเฉลี่ยได้ 72.4% แต่ทำงานผ่านเกณฑ์แบบสมบูรณ์จริงเพียง 37.1% ของจำนวนครั้งที่ทดสอบ ซึ่ง Sonnet 5.5 และ Opus 5.5 ก็พบช่องว่างระหว่างสองตัวเลขนี้ห่างกัน 34 ถึง 35 จุดเช่นเดียวกันในราคาที่สูงกว่า ดังนั้น ขอให้มองว่าการรันงานบนเบราว์เซอร์ทุกครั้งยัง “เสร็จไม่สมบูรณ์” เสมอจนกว่าจะได้รับการตรวจสอบ โดยควรกำหนดเงื่อนไขการตรวจรับงาน (acceptance check) ที่เข้มงวดไว้ใน Task ให้ Agent หยุดทำงานก่อนจะกดส่งข้อมูล (submit) ใดๆ พร้อมทั้งรายงานสิ่งที่ทำเสร็จ สิ่งที่ยังไม่เสร็จ และหลักฐานประกอบ จากนั้นจึงให้คนเป็นผู้อนุมัติขั้นตอนสุดท้ายด้วยการคอมเมนต์และ @ พูดถึง Agent ลงทุนกับการกำหนดขั้นตอนเพื่อประหยัดเวลาในการรีวิว เพราะค่ารันน่ะถูกที่สุดแล้ว ปล่อยให้ Agent ทำหน้าที่ค้นหา ดำเนินการ ทดสอบ และรายงานผล ส่วนคนมีหน้าที่กำหนดทิศทาง มอบสิทธิ์การตัดสินใจ และตรวจรับงาน

คะแนนบางส่วนไม่ใช่ “ทำเสร็จแล้ว”

Anthropic ได้ทดสอบ OSWorld 2.1 กับโจทย์ 82 ข้อจากทั้งหมด 108 ข้อ ที่ความละเอียดหน้าจอ 1080p กำหนดการทำงานสูงสุด 500 ขั้นตอนต่อหนึ่งครั้ง ที่ระดับ max effort และหาค่าเฉลี่ยจากการทดสอบ 5 รอบ โดยรายงานผลลัพธ์สองตัวเลขต่อหนึ่งโมเดล ซึ่งตัวเลขหลังนี่เองคือความเป็นจริงที่คนตรวจงานต้องเผชิญ

ประการแรก ช่องว่างของตัวเลขนี้ไม่ได้เป็นปัญหาเฉพาะของ Haiku เท่านั้น เพราะทุกโมเดลในตระกูลเดียวกันล้วนมีส่วนต่างราว 35 จุด ระหว่าง “ทำขั้นตอนส่วนใหญ่ไปแล้ว” กับ “งานเสร็จสมบูรณ์จริง” แม้กระทั่ง Opus 5.5 ก็ยังทำงานผ่านเกณฑ์แบบสมบูรณ์ได้เพียงประมาณครึ่งหนึ่งเท่านั้น การทดสอบ computer use ส่วนใหญ่ตามเกณฑ์วัดนี้จึงจบลงที่สถานะทำเสร็จเพียงบางส่วน ประการที่สอง Haiku 5.5 ทำให้การสร้างงานที่เสร็จเพียงบางส่วนมีราคาถูกลงมาก หากคำนวณต้นทุนต่อการทำงานผ่านแบบสมบูรณ์หนึ่งครั้ง จะถูกกว่า Sonnet 5.5 ประมาณ 7 เท่า และหากคิดต้นทุนต่อการรันหนึ่งครั้ง จะถูกกว่าถึง 9 เท่า

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

เมื่อค่ารันเหลือแค่หลักเซนต์ ต้นทุนจริงย้ายไปอยู่ที่ไหน

ระบบอัตโนมัติบนเบราว์เซอร์ที่มีราคาถูกทำให้เราต้องเปลี่ยนจุดโฟกัสของงบประมาณ ที่ต้นทุน 0.13 ดอลลาร์ต่อครั้ง การรันกรอกแบบฟอร์มสัก 100 รอบแทบจะเป็นแค่เศษเงินบนใบแจ้งหนี้ค่าโมเดล แต่การรัน 100 รอบที่ต้องใช้คนมาคอยตรวจเช็กว่าข้อมูลที่กรอกถูกต้องหรือไม่นั้น อาจกินเวลาทำงานของใครบางคนไปทั้งวัน Haiku 5.5 คิดราคาถูกกว่า Haiku 4.5 ถึง 90% สำหรับพรอมต์ไม่เกิน 100K โทเค็น แต่ค่าแรงของคนตรวจงานไม่ได้ลดลงตามไปด้วย

นอกจากนี้ยังมีประเด็นเรื่องโครงสร้างราคาที่ต้องระวัง Haiku 5.5 คิดราคา 0.10 ดอลลาร์ต่อ 1 ล้าน input token และ 0.50 ดอลลาร์ต่อ 1 ล้าน output token สำหรับพรอมต์ที่ไม่เกิน 100K โทเค็น แต่หากพรอมต์เกิน 100K ราคาจะปรับเป็น 0.50 ดอลลาร์ และ 2.50 ดอลลาร์ตามลำดับ เซสชันเบราว์เซอร์ที่ทำงานต่อเนื่องยาวนานสามารถสะสมขนาดพรอมต์จนเกินเกณฑ์ดังกล่าวได้ง่าย ซึ่งหลังจากนั้นทุกคำขอจะถูกคิดในอัตราที่แพงขึ้น นี่จึงเป็นอีกหนึ่งเหตุผลสำคัญที่ควรกำหนด Task บนเบราว์เซอร์ให้มีขอบเขตสั้น กระชับ: แบบฟอร์ม 1 ชุด, ข้อมูล 1 ชุด, ต่อ 1 Task เท่านั้น

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

การรีวิว Agent ที่ใช้ Computer Use: สิ่งที่ Task ต้องระบุไว้

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

ใน Sharkly ตัว Task ถูกออกแบบมาให้เป็นศูนย์กลางบันทึกข้อมูลร่วมกันอยู่แล้ว โดยเก็บทั้งคำอธิบาย (description), ความคิดเห็น, ไฟล์แนบ และประวัติกิจกรรม ข้อความที่ Agent สื่อสารกับทีมจะถูกบันทึกไว้ใน Task เป็นความคิดเห็นที่เชื่อมโยงกับรอบการรันงาน และบันทึกการทำงาน (execution log) ก็จะเก็บประวัติการเรียกใช้เครื่องมือตลอดจนเหตุการณ์ต่างๆ บน Runtime ดังนั้น การออกแบบระบบรีวิวจึงอยู่ที่สองจุดสำคัญ คือ คำอธิบาย Task ต้องระบุให้ชัดเจนว่างานที่ “เสร็จ” มีหน้าตาเป็นอย่างไร และคำสั่งของ Agent (instructions) ต้องระบุว่าในรายงานต้องมีเนื้อหาอะไรบ้าง นี่คือตัวอย่างโครงสร้างคำสั่งเริ่มต้นสำหรับ Agent ที่ใช้กรอกข้อมูลบนเบราว์เซอร์:

Restate the acceptance check from the Task description before you start.
Work up to, but not including, any submit, send, publish, pay, or delete action.
Then stop and report, in this order:
  Done: every record or field you completed, by its identifier.
  Not done: everything you skipped or could not complete, and why.
  Check: the acceptance check, and whether your own count meets it.
  Evidence: the paths of the screenshots you saved in the task directory.
Leave the Task waiting for human review. Do not take the final action
until a person @ mentions you in a comment on this Task to release it.

ควรกำหนดเงื่อนไขการตรวจรับงานให้สามารถนับจำนวนได้ชัดเจน เช่น “บันทึกข้อมูล 40 แถวลงใน CRM พร้อมอีเมลที่ตรงกันทุกรายการ” แทนที่จะเขียนกว้างๆ ว่า “นำเข้าข้อมูลจากสเปรดชีต” รายการในส่วน “Not done” (สิ่งที่ยังไม่เสร็จ) คือส่วนสำคัญที่การคิดคะแนนแบบ partial credit มักซ่อนเอาไว้ การระบุให้ชัดเจนว่ามีรายการใดบ้างที่ถูกข้ามไป จะช่วยเปลี่ยนงานที่เสร็จ 72% แบบไม่รู้อนาคต ให้กลายเป็นงาน 72% ที่ทราบรายการคงค้างอย่างแม่นยำ คุณสามารถอ่านเพิ่มเติมเกี่ยวกับรูปแบบรายงานได้ในคู่มือการตรวจทานงานของเอเจนต์ด้วยหลักฐานระดับ Task

ตามเอกสารคู่มือของ Agents บน Sharkly นั้น Agent จะทำงานตามโมเดลเริ่มต้นของ Runtime หากต้องการเปลี่ยน ให้ระบุในช่อง Custom arguments บน Agent หรือ Runtime (เช่น claude-haiku-5-5 สำหรับ Claude Code) เนื่องจากไม่มีเมนูดรอปดาวน์ให้เลือกโมเดลโดยตรง สามารถดูขั้นตอนการติดตั้งได้ที่วิธีใช้งาน Claude Haiku 5.5 ร่วมกับเอเจนต์ใน Sharkly

หยุดก่อนกด Submit

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

รูปแบบนี้ใช้ฟังก์ชันที่มีอยู่แล้วใน Sharkly กล่าวคือ Agent จะทำงานไปจนถึงขั้นตอนสุดท้ายก่อนกดยืนยัน แล้วเปลี่ยนสถานะ Task เป็นรอคนมาตรวจสอบ ซึ่งจะแจ้งเตือนไปยัง Inbox ของผู้ตรวจทาน เมื่อผู้ตรวจทานเปิดดูรายงานและภาพถ่ายหน้าจอ (screenshot) แล้วทำการแก้ไขหรือปฏิเสธ จากนั้นเพียงแค่คอมเมนต์บน Task พร้อม @ พูดถึง Agent เพื่อปล่อยให้ทำงานต่อ การคอมเมนต์ข้อความธรรมดาโดยไม่แท็กจะไม่ทำให้ Agent เริ่มทำงาน การแท็กจะช่วยเปิดหรือสนทนาต่อบน Task นั้น และคำตอบของ Agent จะถูกบันทึกเป็นความคิดเห็นอีกรายการที่เชื่อมโยงกับรอบการรันดังกล่าว การกด Submit จึงเกิดขึ้นภายใน Task เดิม ภายใต้บันทึกประวัติเดียวกัน หลังจากที่คนได้ตรวจสอบและอนุมัติแล้วเท่านั้น ดูรายละเอียดจุดพักงานอื่นๆ เพิ่มเติมได้ในคู่มือการตั้งจุดอนุมัติ (Approval Gates)

การคั่นด้วยจุดอนุมัตินี้ยังช่วยจำกัดความเสี่ยงอีกประการของการใช้เบราว์เซอร์ด้วย เพราะเบราว์เซอร์เอเจนต์ต้องอ่านหน้าเว็บที่ตนเองไม่ได้เป็นผู้สร้าง ในรายงานระบบของ Anthropic ระบุว่า Haiku 5.5 สามารถป้องกันการโจมตีแบบ prompt injection ได้ดีกว่า Haiku รุ่นก่อนหน้าทั้งหมด และเทียบเท่ากับโมเดลระดับแนวหน้าเมื่อต้องรับมือกับการโจมตีแบบปรับเปลี่ยนตามสภาพแวดล้อม (adaptive attackers) ในบริบทของ computer use แต่นั่นเป็นเพียงผลการทดสอบจากเกณฑ์มาตรฐาน ไม่ใช่คำรับประกันสำหรับพอร์ทัลคู่ค้าของบริษัทคุณ คำสั่งแปลกปลอมที่แฝงเข้ามาจะไม่สามารถทะลุไปถึงปุ่ม Submit ได้หากไม่มีคำสั่งอนุมัติจากคน จึงช่วยลดความรุนแรงของปัญหาลงได้มหาศาล ส่วนการวางขอบเขตความปลอดภัยฝั่งโฮสต์ (การแยก Computer เฉพาะ, การผูกรหัสผ่านเข้ากับแต่ละ Agent ผ่านตัวแปรสภาพแวดล้อมที่เป็นความลับ, การรันเบราว์เซอร์ทีละงาน) ก็เป็นแนวทางเดียวกับที่เราแนะนำไว้ในคู่มือแนวทางความปลอดภัยสำหรับ computer-use และสามารถอ่านส่วนที่เหลือเพิ่มเติมได้ในบทความเรื่อง prompt injection และเกราะป้องกันเอเจนต์

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

ยอมจ่ายค่า Effort เพื่อประหยัดเวลาตรวจสอบ

Haiku 5.5 เป็นโมเดล Haiku รุ่นแรกของ Anthropic ที่สามารถปรับระดับความพยายามในการประมวลผล (effort) ได้ โดยค่าเริ่มต้นจะอยู่ที่ระดับ medium สำหรับการทดสอบบน OSWorld นั้น การปรับระดับ effort ช่วยเพิ่มคะแนนการทำงานสำเร็จบางส่วนได้อย่างมีนัยสำคัญด้วยต้นทุนที่เพิ่มขึ้นเพียงเล็กน้อย:

การปรับระดับจาก medium ไปเป็น max จะเพิ่มต้นทุนขึ้นมาราว 0.49 ดอลลาร์ต่อการรันหนึ่งครั้ง และได้คะแนนความสำเร็จบางส่วนเพิ่มขึ้น 19 จุด ซึ่งหากคะแนนที่เพิ่มขึ้นนี้ช่วยย่นเวลาการตรวจงานของคนลงได้แม้เพียงเล็กน้อย การเลือกตั้งค่า max ก็ถือเป็นตัวเลือกที่คุ้มค่ากว่าอย่างแน่นอนสำหรับ Task บนเบราว์เซอร์ใดๆ ที่ต้องใช้คนตรวจทาน ในรายงานระบบมีการแสดงกราฟอัตราการผ่านแบบสมบูรณ์ตามระดับ effort แต่ระบุตัวเลขเฉพาะที่ระดับ max เท่านั้น ดังนั้นจึงควรวัดผลลัพธ์ที่สมบูรณ์จริงบน Task งานของคุณเองก่อนตัดสินใจเลือกระดับที่ต่ำกว่า ทั้งนี้ การตั้งค่า effort จะกำหนดผ่าน Claude Code บนเครื่อง Computer เนื่องจากตัว Agent ไม่ได้มีตัวเลือกโมเดลหรือการควบคุมความลึกในการคิด (thinking depth) มาให้ปรับโดยตรง เราควรเลือกใช้ระบบอัตโนมัติราคาประหยัดในจุดที่ไม่จำเป็นต้องมีใครมาคอยตรวจผลลัพธ์ ดังเช่นแนวทางในบทความ Luna สำหรับงานน่าเบื่อแปดสิบเปอร์เซ็นต์ แต่งานระบบเบราว์เซอร์ไม่ได้เป็นเช่นนั้น

งานบนเบราว์เซอร์ที่มีการบันทึกข้อมูลไปยังระบบภายนอก ควรแยกออกมาสร้างเป็น Task ของตนเองโดยเฉพาะ แทนที่จะรวมไว้ในเวิร์กโฟลว์ใหญ่ เพราะต้องมีคนคอยตรวจสอบและอนุมัติเสมอ สามารถศึกษากฎเกณฑ์ทั่วไปเรื่องนี้ได้ในบทความ การใช้ Haiku 5.5 เป็น Subagent หรือแยกเป็น Agent เดี่ยว

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