Mọi lộ trình sản phẩm đều có một đầu mục ghi là "AI Agent." Từ này nghe có vẻ như là sự tiến bộ. Nó báo hiệu cho ban lãnh đạo rằng đội ngũ của bạn đang xây dựng tương lai, chứ không chỉ là duy trì hiện tại. Nhưng đây là sự thật khó chịu mà hầu hết các video demo sẽ không cho bạn thấy: một agent là cách tốn kém nhất và ít có khả năng dự đoán nhất để hoàn thành một công việc. Đối với đa số các tác vụ kinh doanh, nó hoàn toàn là sai công cụ. Những kỹ sư giỏi nhất không phải là những người vội vã xây dựng nó. Họ là những người biết khi nào nên dừng lại.
Cạm bẫy Phân loại
Hãy quan sát một đội ngũ khi họ lên kế hoạch cho agent đầu tiên, bạn sẽ thường thấy điều này. Một email hỗ trợ gửi đến. Một mô hình ngôn ngữ lớn đọc tiêu đề và nội dung, quyết định xem đó là câu hỏi về thanh toán hay lỗi kỹ thuật, rồi đưa nó vào hàng đợi phù hợp. Đội ngũ gọi đây là một agent. Không phải vậy.
Thứ họ đã xây dựng là một luồng (flow) xác định với một lần gọi mô hình duy nhất bên trong. Các bước là cố định: tiếp nhận email, gọi mô hình, chuyển vào hàng đợi. Không có vòng lặp, không có việc sử dụng công cụ (tool use), không có khoảnh khắc nào hệ thống dừng lại để xem xét lại kế hoạch vì lần thử đầu tiên thất bại. Nó không duyệt cơ sở kiến thức, không viết mã, hay kiểm tra trạng thái đơn hàng giữa chừng. Nó đưa ra một phán đoán rồi thôi. Việc bọc lần gọi duy nhất đó trong một microservice không biến nó thành một agent.
Cái giá thực sự của việc nhầm lẫn một luồng với một agent không chỉ là hạ tầng bổ sung. Đó là tính không xác định (non-determinism) mà bạn đã mời gọi mà không thu lại được lợi ích gì. Cùng một email có thể được điều hướng khác nhau vào sáng thứ Ba so với chiều thứ Tư vì nhiệt độ (temperature) khác không hoặc prompt bị trôi (drift). Bạn phải trả giá cho một agent về độ trễ, chi phí token và chi phí đánh giá, trong khi một luồng với một bước phân loại có thể giải quyết vấn đề nhanh hơn và rẻ hơn.
Giải quyết theo thứ tự từ thấp lên cao
Hầu hết các vấn đề đều có những "người họ hàng" đơn giản hơn có thể giải quyết chúng tốt không kém. Hãy coi nó như một chiếc thang, và bắt đầu từ dưới cùng.
Sửa đổi quy trình. Đôi khi công việc tồn tại chỉ vì hai hệ thống không đồng nhất. Một bản ghi khách hàng trong CRM không đồng bộ với nền tảng hỗ trợ (ticketing platform), vì vậy con người phải lấp đầy khoảng trống đó một cách thủ công mỗi sáng. Đừng tự động hóa khoảng trống đó bằng một agent. Hãy loại bỏ nó. Nếu đường ống dữ liệu (data pipeline) hoạt động tốt, công việc đó sẽ biến mất.
Sử dụng truy vấn. Nếu câu trả lời chỉ là một việc tra cứu hoặc tổng hợp đơn giản, hãy xử lý nó như vậy. "Có bao nhiêu khoản hoàn tiền chúng ta đã xử lý vào thứ Ba tuần trước?" không cần đến khả năng suy luận. Nó cần SQL. Một agent chuyển đổi ngôn ngữ tự nhiên thành SQL nghe có vẻ thanh lịch cho đến khi bạn nhận ra gánh nặng bảo trì còn lớn hơn cả việc viết ba truy vấn có tài liệu hướng dẫn mà đội ngũ của bạn có thể chạy từ một dashboard.
Xây dựng một luồng xác định. Khi các quy tắc là cố định và kết quả có thể lặp lại, hãy sử dụng logic tường minh. Nếu giá trị đơn hàng vượt quá một ngưỡng nhất định, hãy chuyển lên bộ phận tài chính. Nếu người dùng không hoạt động trong ba mươi ngày, hãy gửi email tái tương tác. Mã nguồn xử lý việc này với biến số bằng không và khả năng quan sát đầy đủ. Bạn có thể unit-test nó. Bạn không thể unit-test một "cảm giác" (vibe).
Sử dụng một luồng với một lần gọi mô hình. Đây là nơi dành cho phân loại, gắn thẻ cảm xúc (sentiment tagging) hoặc trích xuất dữ liệu. Mô hình đưa ra một phán đoán duy nhất bên trong một kịch bản cứng nhắc. Bạn tiếp nhận một tài liệu, trích xuất số hóa đơn và ghi nó vào cơ sở dữ liệu. Các bước xung quanh được lập trình cứng (hardcoded). Mô hình không chọn việc tiếp theo cần làm; nó chỉ dán nhãn những gì nó thấy. Đây là một mô hình mạnh mẽ, nhưng nó vẫn là một luồng.
Xây dựng agent sau cùng. Hãy dành bước này cho các tác vụ mà hành động tiếp theo thực sự phụ thuộc vào những gì mô hình khám phá ra trong quá trình chạy. Nếu hệ thống phải đọc một email, nhận ra nó cần tra cứu một lô hàng trong API logistics, thấy rằng lô hàng bị chậm trễ, và sau đó soạn một phản hồi tùy chỉnh dựa trên dữ liệu mới đó, thì bạn đang ở vùng lãnh thổ của agent. Lộ trình không thể được vẽ trước vì mô hình sẽ quyết định phải làm gì sau mỗi sự thật mới.
Bài kiểm tra bảng trắng
Có một cách nhanh chóng để giải quyết tranh luận trong một cuộc họp. Hãy yêu cầu đội ngũ của bạn vẽ các nhánh quyết định lên bảng trắng.
Nếu bạn có thể lập bản đồ mọi lộ trình trước khi mô hình chạy, hãy xây dựng một luồng. Vẽ các hình thoi, viết các câu lệnh if-else, và xong. Tính dự đoán được là một tính năng, không phải là một hạn chế.
Nếu bản thân mô hình phải quyết định bước tiếp theo là gì, nếu nó chọn công cụ, thiết lập các tham số và lặp lại để suy nghĩ lại, thì bạn cần một agent. Sự điều hướng động (dynamic routing) đó chính là ranh giới phân chia. Đừng vô tình bước qua ranh giới đó chỉ vì bạn muốn sử dụng một API mới.
Thuế ẩn
Các bản demo khiến agent trông có vẻ không gặp trở ngại nào. Thực tế vận hành (production) sẽ tiết lộ bốn loại "thuế" tích tụ rất nhanh.
Tính không xác định. Cùng một