Agent Browser คืออะไร ต่างจากเบราว์เซอร์ทั่วไปและสคริปต์อย่างไร

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

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

ความต่างข้อ 1: ใครเป็นคนตัดสินใจขั้นตอนถัดไป

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

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

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

ความต่างข้อ 2: มันรู้ได้อย่างไรว่ามีอะไรอยู่บนหน้าเว็บ

สคริปต์ใช้ selector เพื่อระบุ element โดย XPath และ CSS selector จะชี้ไปยังตำแหน่งของ node ในโครงสร้าง หากตำแหน่งเปลี่ยน selector ก็อาจใช้ไม่ได้

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

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

ความต่างข้อ 3: การกระทำถูกนำไปทำจริงอย่างไร

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

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

ตอนนี้ทำได้ถึงระดับไหน

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

จุดที่ยังไม่เสถียร

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

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

สิ่งที่ควรดูเมื่อต้องเลือกเครื่องมือ

ความสามารถในการดูและ replay ขั้นตอนการทำงานมักถูกมองข้าม แต่เมื่อมีปัญหา นี่คือวิธีสำคัญในการหาสาเหตุ ควรดูรูปแบบการแก้ error ด้วยว่าเครื่องมือหยุดทันทีหรือเปลี่ยนเส้นทางต่อ ตรวจสอบว่าสามารถควบคุมโมเดลและต้นทุนได้หรือไม่ เพราะงานยาวมักมีค่าใช้จ่ายสูงกว่าที่คาด ดูด้วยว่าสามารถเชื่อมต่อ custom tools และ workflow ได้หรือไม่ และสุดท้ายให้ยืนยันว่ารักษาสถานะล็อกอินอย่างไร การต้องเริ่มใหม่ทั้งหมดเพราะ session หายเป็นเรื่องน่ารำคาญมาก

เข้าใจกฎให้ชัดก่อนใช้

สิ่งที่ทำได้ทางเทคนิคไม่ได้แปลว่าได้รับอนุญาตให้ทำเสมอไป ต้องตรวจสอบก่อนว่าเงื่อนไขการใช้บริการของแพลตฟอร์มเป้าหมายอนุญาต automated access หรือไม่ และความถี่ของ request จะสร้างภาระให้บริการหรือเปล่า นอกจากนี้ การใช้เครื่องมือประเภทนี้เพื่อสมัครบัญชีจำนวนมาก หรือทำงานบนแพลตฟอร์มโดยอัตโนมัติเพื่อแลกรับผลประโยชน์ เป็นการใช้งานที่ฝ่าฝืนกฎของแพลตฟอร์ม แพลตฟอร์มต่าง ๆ พัฒนาความสามารถในการตรวจจับจังหวะการทำงาน เส้นทางพฤติกรรม และความสอดคล้องของสภาพแวดล้อมมากขึ้น และเมื่อมีการจัดการ มักกระทบหลายบัญชีพร้อมกัน

หากงานนั้นถูกต้องตามกฎ แต่ต้องให้หลายบัญชีมีสถานะล็อกอินที่แยกจากกัน การแยกสภาพแวดล้อมก็มีประโยชน์ เช่น PurpleMark มีสภาพแวดล้อมอิสระเพื่อให้ session และ storage ของแต่ละบัญชีมองไม่เห็นกัน

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