Trong bài viết này
Từ được đánh dấu có giải thích. Di chuột hoặc chạm để xem, hay mở từ điển AI.
“Tóm tắt đoạn này” và “đối chiếu hai quy chế để tìm điều khoản mâu thuẫn” đều là yêu cầu xử lý văn bản. Nhưng chúng có thể cần ngữ cảnh, công cụ và mức kiểm tra khác nhau. Một bộ định tuyến quyết định đường xử lý trước khi công việc chính bắt đầu.
Routing đáng làm khi sự khác nhau giữa nhóm tác vụ đủ rõ và lợi ích lớn hơn chi phí lựa chọn sai hoặc điều phối thêm.
Bắt đầu từ nhóm công việc
Trong ví dụ giả định về trợ lý nội bộ, chia yêu cầu thành trích trường theo mẫu, hỏi đáp cần tài liệu và phân tích nhiều tài liệu. Mỗi nhóm có tiêu chí thành công và đường xử lý riêng.
Đừng đặt nhãn “dễ” và “khó” mà không có định nghĩa quan sát được. Một câu ngắn có thể hỏi về điều khoản hiếm; một văn bản dài có thể chỉ cần đếm số mục bằng mã. Độ dài là tín hiệu, không phải kết luận về độ khó.
Building effective agents của Anthropic mô tả routing như cách phân loại đầu vào rồi chuyển sang một nhiệm vụ chuyên biệt. Bài viết này dùng nguyên tắc kiến trúc đó, không lấy danh sách công cụ trong nguồn làm khuyến nghị hiện hành.
Chọn tín hiệu có thể kiểm tra
Có thể bắt đầu bằng quy tắc: người dùng chọn tác vụ từ giao diện, tài liệu có kiểu đã biết hoặc yêu cầu cần một công cụ nhất định. Khi quy tắc không đủ, mô hình phân loại có thể hỗ trợ.
Một quyết định định tuyến minh họa:
Loại yêu cầu: hỏi đáp có nguồn
Cần truy xuất: có
Phạm vi dữ liệu: quy chế được phép đọc
Đường xử lý: truy xuất → trả lời → kiểm tra trích dẫn
Lý do quan sát được: câu hỏi yêu cầu chính sách của tổ chứcTrường “lý do” giúp kiểm tra quyết định nhưng không thay thế dữ liệu đánh giá. Nếu mô hình tự chấm độ tin cậy, đừng mặc định con số đó là xác suất đã được hiệu chuẩn. Với trường hợp mơ hồ, chuyển sang đường tổng quát hoặc hỏi thêm khi thông tin thiếu thực sự thay đổi cách xử lý.
Agent dùng trạng thái hiện tại để chọn công cụ, đọc kết quả thực thi và kiểm tra tiến độ. Vòng lặp tiếp tục trong giới hạn được đặt trước hoặc kết thúc với kết quả đã xác minh.
↔ Vuốt ngang để xem toàn bộ sơ đồ.
01 / Quan sát
Agent nhận mục tiêu, trạng thái hiện tại và kết quả của các bước trước.
02 / Gọi công cụ
Mô hình đề xuất công cụ và đầu vào; ứng dụng kiểm tra quyền trước khi thực thi.
03 / Đọc kết quả
Agent nhận dữ liệu trả về, bao gồm thành công, dữ liệu rỗng hoặc lỗi.
04 / Kiểm tra và dừng
Kiểm tra mục tiêu đã đạt chưa. Dừng khi hoàn thành, thiếu quyền hoặc chạm giới hạn; nếu cần thì tiếp tục.
Minh họa một vòng lặp agent đơn giản. Công cụ chỉ được thực hiện thao tác trong quyền đã cấp; lời mô hình nói không thay thế kết quả thực thi.
Đo cả lỗi định tuyến và kết quả cuối
Một router có tỷ lệ phân loại cao vẫn có thể làm sản phẩm tệ hơn nếu lỗi tập trung ở tác vụ quan trọng. Chuyển câu hỏi đơn giản sang đường đắt thường gây lãng phí; chuyển câu hỏi cần nguồn sang đường không truy xuất có thể tạo câu trả lời thiếu căn cứ.
Lập bảng đối chiếu nhãn mong muốn với đường thực tế và đọc từng nhóm chuyển nhầm. Sau đó đo kết quả cuối: đúng nội dung, đủ bằng chứng, độ trễ và chi phí. Router không phải mục tiêu độc lập; nó phục vụ toàn hệ thống.
So sánh với cấu hình cơ sở không routing trên cùng tập đầu vào. Tính cả lượt phân loại, thời gian điều phối và lần chuyển tiếp sau thất bại. Nếu bỏ những khoản này, phép so sánh sẽ ưu ái kiến trúc phức tạp.
Fallback không được thay đổi lời hứa
Khi đường chính lỗi, fallback sang mô hình khác có thể giữ dịch vụ hoạt động. Nhưng nếu đường thay thế thiếu công cụ hoặc không hỗ trợ cùng định dạng, bạn cần kiểm tra hợp đồng trước khi dùng.
Ví dụ, một câu trả lời về chính sách cần trích nguồn không nên âm thầm trở thành câu trả lời từ kiến thức chung khi truy xuất hỏng. Có thể báo chưa tra cứu được và giữ yêu cầu chờ, thay vì trả một kết quả mang vẻ hoàn chỉnh.
Lỗi thường gặp là routing dựa trên đầu ra chưa kiểm tra, rồi cho các đường tiếp tục gọi lẫn nhau vô hạn. Đặt số lần chuyển tối đa, ghi đường đi và có trạng thái kết thúc rõ. Một hệ thống đơn giản đo được tốt hơn một mạng chuyển tiếp không biết vì sao đã chạy.
Bài tập: thiết kế một lỗi chuyển nhầm
Tạo các yêu cầu giả định gồm trích ngày từ email, hỏi quy chế nghỉ phép và so sánh hai bản quy chế. Thêm câu “tóm tắt quy chế mới khác gì bản cũ” để kiểm tra ranh giới giữa tóm tắt và đối chiếu.
Tiêu chí đạt: định nghĩa nhãn đủ rõ để người khác gán giống bạn, phát hiện được câu pha trộn, và đo được kết quả cuối cùng khi chuyển nhầm. Đọc tiếp đánh giá mô hình để xây tập kiểm tra trước khi tối ưu routing.