1.1 Anthropic - Building effective agents

Tháng 10/2024, sau khi công bố sự ra đời của giao thức MCP, thì hai tháng sau, bài viết này được xuất bản trên trang blog chính thức của Anthropic. Tuy nhiên, tính đến thời điểm mình đọc bài viết, các nguyên tắc, ý tưởng thiết kế luồng tích hợp LLM vào các công việc thực tế vẫn còn rất hữu ích (đối với mình).

Trong bài viết này, Anthropic làm rõ khái niệm workflow và agent. Workflow là hệ thống tích hợp mô hình LLM và các công cụ thông qua các đoạn code được định nghĩa trước. Trong khi, khái niệm agent hướng đến việc đặt quyền tự chủ (autonomous) vào mô hình LLM, cho phép nó tự lên kế hoạch, tự điều hướng và sử dụng các công cụ cần thiết trong toàn bộ quá trình.

Khi nào nên và không nên sử dụng agent?

• Anthropic cho rằng nên tìm giải pháp đơn giản nhất cho mọi công việc, và CHỈ tăng độ phức tạp khi cần thiết. Chỉ nên tính đến việc sử dụng AI agent khi tính hiệu quả đã được cân bằng với chi phí phát sinh.
• Workflow phù hợp đối với các task có yêu cầu rõ ràng, độ chính xác và tính nhất quán (consistency) cao. Trong khi agent được sử dụng cho các task linh hoạt và hỗ trợ đưa ra quyết định.

Khi nào nên sử dụng framework?

Có nhiều framework hỗ trợ việc xây dựng hệ thống AI agent dễ dàng hơn (ví dụ: Claude AgentSDK), nhưng thường tạo ra một lớp bề mặt trừu tượng, và bỏ qua phần prompt và response cốt lõi phía bên dưới khiến cho việc debug trở nên khó khăn.
Anthropic khuyến nghị các nhà phát triển nên bắt đầu bằng việc sử dụng trực tiếp API của các nhà phát triển mô hình LLM với vài dòng code đơn giản hoặc sử dụng framework chỉ khi đã hiểu rõ phần chìm của chúng.

Workflow và khi nào nên sử dụng?

Phần này Anthropic phân loại workflow theo thiết kế và khi nào thì nên sử dụng loại nào.

Workflow: Prompt chaining

Task phù hợp: lý tưởng với các task đơn giản và có thể dễ dàng chia thành các subtask
Đặc điểm: output của task trước là input của task sau.
Ví dụ:

• Tạo cái bài viết Marketing -> dịch sang ngôn ngữ khác.
• Lên bản phác thảo tài liệu -> kiểm tra các tiêu chí đã thoả mãn hay chưa -> viết tài liệu hoàn chỉnh.

Workflow: Routing

Task phù hợp: lý tưởng với các task phức tạo có thể được giải quyết theo nhiều hướng khác nhau.
Đặc điểm: dùng một LLM Call Router có thể định tuyến luồng thực thi tiếp theo
Ví dụ:

• Xử lý ticket trong dịch vụ hỗ trợ khách hàng: phân loại yêu cầu đầu vào là yêu cầu hoàn tiền, yêu cầu hỗ trợ kỹ thuật hay yêu cầu tư vấn sản phẩm,... -> xử lý từng yêu cầu với quy trình khác nhau.
• Định tuyến các task đơn giản cho các model nhanh, nhẹ, kinh tế và các task phức tạp, khó hơn cho các model thông minh hơn.

Workflow: Parallelization

Task phù hợp: hiệu quả khi các subtask là độc lập, có thể chạy song song để tối ưu thời gian (sectioning) hoặc khi mong muốn có nhiều góc nhìn / lần thử để tổng hợp thành kết quả có độ tin cậy cao hơn (voting).
Ví dụ:

• Sectioning:
  • Guardrails: Sử dụng song song một model cho việc kiểm tra đầu vào của user, trong khi model còn lại xử lý yêu cầu -> hiệu quả hơn khi chỉ sử dụng một LLM call cho cả 2 công việc.
  • Tự động đánh giá hiệu suất của model LLM, trong đó mỗi LLM call đánh giá một khía cạnh riêng biệt của hiệu suất.
• Voting:
  • Kiểm tra một đoạn code để tìm các lỗ hổng tiềm năng bằng cách sử dụng song song nhiều LLM call.
  • Sử dụng nhiều LLM call để đánh giá nhiều khía cạnh khác nhau của một bài viết marketing hoặc sử dụng các phiếu bầu khác nhau để cân bằng kết quả dương tính và âm tính giả.

Workflow: Orchestrator-workers

Task phù hợp: task phức tạp và số lượng subtasks cần thực thi không cố định
Đặc điểm: một LLM call được giao nhiệm vụ phân chia nhiệm vụ (orchestrator), giao cho các LLM nhân viên và cuối cùng tổng hợp kết quả (synthesizer).

Vừa có đặc điểm tương đồng với routing và parallelization nhưng khác nhau về tính linh hoạt.

Ví dụ:

• Trong quá trình coding, số lượng file cần thay đổi ở mỗi lần debug rất khác nhau.
• Các task tìm kiếm bao gồm nhiều subtasks thu thập, phân tích từ nhiều nguồn -> tổng hợp thành báo cáo cuối cùng (khá tiềm năng cho Threat Intelligent Report).

Workflow: Evaluator-optimizer

Task phù hợp: task đã có một khung đánh giá với các tiêu chí rõ ràng và khi việc tinh chỉnh mang lại giá trị có thể đo lường được.
Đặc điểm: tương tự với quá trình viết và tinh chỉnh lặp đi lặp lại khi viết tài liệu.
Ví dụ:

• Với công việc phiên dịch, khi các phiên bản ban đầu không nắm bắt các sắc thái tinh tế, do đó cần người phê bình với các tiêu chí được xác định rõ ràng để cải thiện (evaluator).
• Các tìm kiếm phức tạp yêu cầu nhiều vòng tìm kiếm và phân tích để có kết quả toàn diện hơn, trong đó evaluator quyết định có nên thêm các vòng tìm kiếm khác hay không.

Agents và khi nào nên sử dụng?

Không còn giới hạn trong các prompt với các công cụ cố định được định nghĩa thông qua coding, các autonomous agent giờ đây tự lên kế hoạch, tương tác với môi trường và người dùng, nhận feedback từ đầu ra của công cụ, sau đó tiếp tục tự cải thiện và tinh chỉnh kế hoạch.

Task phù hợp: các task có mức độ phức tạp cao và không thể đưa ra một quy trình thực hiện cố định được.

Đặc điểm: vì agent được toàn quyền lên kế hoạch và thực thi các công cụ, do đó cần có các guardrails và được kiểm thử kỹ càng trong môi trường sandbox trước khi đưa vào sử dụng trong thực tế.

Bên cạnh đó, sức mạnh của agent phụ thuộc chủ yếu vào khả năng của LLM model (reasoning, planning) -> tiêu tốn nhiều tài nguyên và tiền bạc.

Ví dụ: High-level flow of a coding agent

Tóm lại, những gì hữu ích nhất của bài viết này đối với mình chính là việc Anthropic đã đưa ra góc nhìn của một nhà thiết kế quy trình ứng dụng LLM một cách hiệu quả, và các khía cạnh cần cân đo đong đếm để lựa chọn thiết kế phù hợp cho mục tiêu công việc cần giải quyết. Đồng thời, không nên bắt đầu với một workflow "hầm hố" (sở thích ngày xưa của mình khi làm n8n) nhưng lại vượt ngoài tầm kiểm soát, nên bắt đầu từ các thiết kế đơn giản, phân chia subtask cẩn thận và viết prompt rõ ràng, chi tiết.