เบราว์เซอร์ AI 4 รูปแบบและขอบเขตการใช้งานที่เหมาะสมของแต่ละแบบ

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

แม้ชื่อจะเหมือนกัน แต่ปัญหาที่แก้ต่างกันมาก แทนที่จะดูผลิตภัณฑ์ทีละตัว การแบ่งตามรูปแบบออกเป็น 4 ประเภทแล้วดูว่าแต่ละประเภททำอะไรได้และติดข้อจำกัดตรงไหนจะเห็นภาพชัดกว่า

ผู้ช่วยแบบ Sidebar: เข้าใจหน้าเว็บ แต่ไม่ลงมือควบคุมหน้าเว็บ

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

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

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

แบบ Agent-driven: ลงมือทำเองได้ แต่เหมาะกับทีละหนึ่งงาน

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

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

เหมาะกับบุคคลที่ต้องทำงานเว็บซับซ้อนแต่ไม่บ่อย

Cloud isolation: เบราว์เซอร์รันอยู่ระยะไกล แต่ใช้งานคล้ายอยู่ในเครื่อง

ในรูปแบบนี้ browser process ไม่ได้รันบนเครื่องของคุณ อุปกรณ์ local มีหน้าที่หลักในการโต้ตอบ จึงสามารถเปิด environment เดิมจากอุปกรณ์หลายเครื่องได้ โดย session และสถานะ login อยู่บน cloud ไม่ต้องตั้งค่าใหม่ทุกเครื่อง สถานะสามารถทำ snapshot และ rollback ได้ หาก environment มีปัญหาก็ย้อนกลับไปยังสถานะที่ใช้งานได้ก่อนหน้า และไม่จำเป็นต้องเก็บข้อมูลไว้ในเครื่อง เหมาะกับทีมที่เปลี่ยนอุปกรณ์บ่อยหรือไม่ต้องการกระจายข้อมูลธุรกิจไว้ตาม endpoint ต่าง ๆ

ข้อแลกเปลี่ยนก็มาจาก cloud เช่นกัน การรับส่งผ่านเครือข่ายทำให้เกิด latency จึงไม่ลื่นไหลเท่าเบราว์เซอร์ local เมื่อจำนวน environment เพิ่มขึ้น ค่าใช้ทรัพยากร cloud ก็เพิ่มตาม การเข้าถึงไฟล์ local ฮาร์ดแวร์ local และระบบในเครือข่ายภายในมีข้อจำกัดมากกว่า นอกจากนี้ cloud เพียงย้ายตำแหน่งของเครื่องเท่านั้น การจัดสรร network egress ระหว่างหลาย environment และการควบคุม concurrency ยังต้องวางแผนเอง

เบราว์เซอร์ที่จัดการ Environment: ชั้นสำหรับให้โปรแกรมทำ orchestration

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

สามารถสร้าง environment ที่แยกจากกันเป็นจำนวนมาก โดยแต่ละ environment มี fingerprint, Cookie และ local storage ของตนเอง มี interface สำหรับสร้าง ค้นหา เริ่ม หยุด และ recycle environment สามารถผูก network egress แยกให้แต่ละ environment และเชื่อมกับ automation framework หลักเพื่อให้โปรแกรมควบคุมได้ จุดประสงค์คือเปลี่ยน browser environment ให้เป็นโครงสร้างพื้นฐานที่จัดคิว แยก และบริหารได้

มันแก้ปัญหาอีกประเภทหนึ่งโดยสิ้นเชิง เมื่อจำนวนงานเพิ่มจาก 1 เป็น 100 วิธีข้างต้นอาจใช้ไม่ได้พร้อมกัน: ผู้ใช้หนึ่งคน หน้าต่างหนึ่งหน้าต่าง และทีละหนึ่งงานไม่รองรับงานแบบ batch; environment ปะปนกัน; งานรบกวนกัน; และ account อาจถูกมองว่าเป็นกลุ่มเดียวกัน ในชั้นนี้ PurpleMark ให้ความสามารถด้านการแยกและการจัดการ browser environment แบบรวมศูนย์ เพื่อให้แต่ละงานรันใน environment ของตัวเอง

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

เลือกอย่างไร

ลำดับการตัดสินใจค่อนข้างง่าย: เริ่มจากความต้องการจริงของคุณแล้วคิดย้อนกลับ

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

ข้อสุดท้ายควรเน้นเป็นพิเศษ AI เป็นผู้ตัดสินใจว่าจะทำอะไร แต่ browser environment เป็นตัวกำหนดว่าจะทำภายใต้ identity แบบใด เมื่อชั้น identity ไม่เสถียร ความล้มเหลวอาจดูสุ่มทั้งที่ต้นเหตุอยู่ที่ environment หลายทีมเริ่มจากถูกดึงดูดด้วยแนวคิด AI browser แล้วซื้อเครื่องมือที่เน้นการทำความเข้าใจ ก่อนจะพบภายหลังว่าความต้องการจริงคือการทำงานแบบ batch หากเลือกทิศทางผิด ต่อให้เครื่องมือดีเพียงใดก็ชดเชยช่องว่างนี้ไม่ได้

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