Agent Browser để mô hình tự quyết định cách thao tác trên trang web thay vì đi theo các bước được viết cứng. Khác biệt chính nằm ở người ra quyết định, cách hiểu nội dung trang, cách thực thi hành động và những giới hạn thực tế hiện nay.
Tự động hóa trình duyệt bằng script là cách làm quen thuộc: xác định phần tử, viết sẵn đường đi, thêm xử lý ngoại lệ và chạy khá ổn định — cho đến khi trang web đổi giao diện. Nếu thay đổi rơi đúng vào một nút quan trọng, cả script có thể phải viết lại, vì mã nhận diện một cấu trúc cụ thể, trong khi cấu trúc lại là thứ dễ thay đổi nhất.
Agent Browser đi theo cách khác. Nó để mô hình nhìn vào nội dung của trang và quyết định bước tiếp theo nên làm gì. Đây cũng là lý do nó ít nhạy cảm hơn với việc trang thay đổi thiết kế.
Khác biệt 1: Ai quyết định bước tiếp theo
Trong script truyền thống, con người viết sẵn đường đi. Bước đầu bấm ở đâu, bước sau điền gì và chờ bao lâu đều được cố định từ trước. Khi chạy, script chỉ làm theo những chỉ dẫn đó.
Agent Browser giao quyền quyết định cho mô hình. Bạn mô tả mục tiêu, chẳng hạn sắp xếp nội dung từ một nguồn thành bảng theo các điều kiện nhất định. Mở trang nào, lọc trước hay chuyển trang trước, xử lý cửa sổ bật lên ra sao đều được tính trong lúc thực thi.
Khác biệt này rất dễ bị đánh giá thấp. Chi phí bảo trì chuyển từ việc viết mã sang việc mô tả yêu cầu cho rõ ràng. Độ khó kỹ thuật giảm xuống, nhưng yêu cầu về cách diễn đạt mục tiêu lại cao hơn.
Khác biệt 2: Làm sao biết trên trang có gì
Script nhận diện phần tử bằng selector. XPath và CSS selector trỏ đến vị trí của node trong cấu trúc. Khi vị trí thay đổi, selector sẽ mất hiệu lực.
Agent Browser thay vào đó gửi thông tin cấu trúc của trang hoặc ảnh chụp màn hình cho mô hình. Mô hình xác định đây là nút đăng nhập, kia là ô tìm kiếm và khu vực khác là giá sản phẩm. Nó thiên về đọc ý nghĩa hơn là đọc tọa độ.
Đổi lại là chi phí thực tế. Để mô hình hiểu một trang, cần gửi cấu trúc DOM hoặc ảnh chụp; trang càng phức tạp thì lượng dữ liệu gửi càng lớn. Với tác vụ dài, phần chi phí này không nhỏ. Mỗi bước còn phải chờ suy luận của mô hình trả về, vì vậy toàn bộ quá trình chậm hơn rõ rệt so với script được viết cứng.
Khác biệt 3: Hành động được thực thi như thế nào
Sau khi quyết định vẫn phải thực sự thao tác. Loại công cụ này thường đóng gói khả năng của trình duyệt thành một nhóm hành động có thể gọi: mở trang, nhấp, điền biểu mẫu, đăng nhập, tải tệp lên, cuộn hoặc chuyển trang và trích xuất dữ liệu. Mô hình đưa ra hành động cần gọi cùng tham số; trình duyệt thực thi rồi trả kết quả về cho mô hình làm đầu vào cho vòng tiếp theo.
Việc chia nhỏ nhiệm vụ và sửa lỗi cũng diễn ra ở lớp này. Một mục tiêu được tách thành nhiều bước và thực hiện theo thứ tự. Nếu phát hiện đã đi sai hướng, mô hình có thể đổi sang điểm vào khác thay vì báo lỗi rồi dừng ngay. Điều này đặc biệt quan trọng với các trang có cấu trúc không đều, nơi tỷ lệ hoàn thành phụ thuộc rất nhiều vào khả năng phục hồi sau lỗi.
Hiện nay có thể làm đến mức nào
Các tác vụ có tính xác định cao và bước thực hiện rõ ràng đã có thể chạy được: thu thập thông tin công khai theo điều kiện và chuyển thành dữ liệu có cấu trúc; thực hiện nhập liệu lặp lại và gửi theo định dạng trong hệ thống của chính mình; hoặc theo dõi một trang cụ thể và thông báo khi giá, tồn kho hay thông báo thay đổi. Điểm chung là đường đi có thể dự đoán, lỗi có thể thử lại và có người kiểm tra được kết quả.
Những chỗ vẫn chưa ổn định
Các vấn đề dễ xuất hiện nhất ở phần hiểu ngữ nghĩa. Để quyết định có nên bấm một nút hay không, mô hình phải hiểu trước ý nghĩa nghiệp vụ của nó. Khi cấu trúc trang phức tạp hoặc cách diễn đạt trái với trực giác, mô hình có thể phán đoán sai: chọn nhầm điểm vào hoặc lấy nhầm trường dữ liệu. Chuỗi thao tác càng sâu thì sai lệch càng dễ tích lũy. Lệch một chút ở đầu có thể khiến phía sau không thể khôi phục.
Các tình huống có cơ chế đối kháng mạnh còn khó hơn. CAPTCHA, chặn bởi hệ thống kiểm soát rủi ro và trạng thái đăng nhập hết hạn phụ thuộc chủ yếu vào môi trường nền chứ không phải bản thân mô hình. Dù mô hình thông minh đến đâu cũng không thể biến một yêu cầu bị từ chối thành thành công. Thực thi trên cloud và proxy do nhà cung cấp quản lý có thể giải quyết một phần, nhưng cũng kéo theo chi phí theo mức sử dụng và sự phụ thuộc vào hạ tầng bên thứ ba.
Những điểm đáng xem khi lựa chọn
Khả năng quan sát và phát lại quá trình thực thi thường bị bỏ qua, nhưng khi có sự cố đây là cách chính để tìm nguyên nhân. Cũng cần xem cơ chế sửa lỗi: công cụ dừng khi lỗi hay đổi đường tiếp tục? Hãy kiểm tra việc chọn mô hình và chi phí có kiểm soát được không, vì tác vụ dài thường tốn hơn dự kiến. Xem thêm khả năng tích hợp công cụ và quy trình tùy chỉnh, rồi cuối cùng xác nhận trạng thái đăng nhập được giữ ra sao. Phải chạy lại toàn bộ chỉ vì mất phiên là việc rất phiền.
Làm rõ quy tắc trước khi sử dụng
Điều có thể làm về mặt kỹ thuật không đồng nghĩa với điều được phép làm. Trước tiên cần kiểm tra điều khoản dịch vụ của nền tảng mục tiêu có cho phép truy cập tự động hay không và tần suất yêu cầu có gây áp lực cho dịch vụ hay không. Dùng công cụ kiểu này để đăng ký tài khoản hàng loạt hoặc tự động thực hiện nhiệm vụ trên nền tảng để đổi lấy lợi ích là hành vi vi phạm quy tắc nền tảng. Khả năng nhận diện nhịp thao tác, đường hành vi và tính nhất quán của môi trường ngày càng tốt hơn, và khi xử lý thường nhiều tài khoản bị ảnh hưởng cùng lúc.
Nếu bản thân tác vụ là hợp lệ nhưng nhiều tài khoản cần trạng thái đăng nhập tách biệt, lớp cô lập môi trường sẽ phát huy tác dụng. Ví dụ, PurpleMark cung cấp các môi trường độc lập để phiên và bộ nhớ của mỗi tài khoản không thể nhìn thấy lẫn nhau.
Cách kiểm chứng thực tế là chọn một tác vụ nhỏ, quen thuộc và có bước rõ ràng, để công cụ chạy hoàn chỉnh, so sánh kết quả với cách làm thủ công, ghi lại cách nó phản ứng khi lỗi và tính thời gian thực tế. Nếu một tác vụ nhỏ chạy ổn, sau đó mới mở rộng. Nếu ngay từ đầu đã muốn tự động hóa toàn bộ quy trình, khả năng cao sẽ mắc ở một bước trung gian nào đó.
