Định tuyến email AI: dựng như hệ thống thật

Đừng triển khai AI phân loại email như một prompt đẹp. Hãy thiết kế nó như hệ thống vận hành: taxonomy, governance, monitoring và đường lui.

Bụi Wire

2026-07-09

“Có cách nào cho AI đọc hộ inbox rồi tự chuyển đúng phòng ban không?”

Câu hỏi này nghe vô hại, cho tới khi bạn nhận ra inbox của một tổ chức không phải cái thùng thư gia đình. Một email về nhà ở có thể là khiếu nại khẩn. Một email gửi nhầm phòng IT có thể chứa dữ liệu cá nhân. Một email tưởng bình thường có thể cần phản hồi trong vài giờ, không phải vài ngày.

Nguồn cảm hứng lần này là một use case khá đời: dùng Amazon Bedrock để phân loại, bổ sung ngữ cảnh và ưu tiên email trong khu vực công. Nhưng mình không muốn bạn nhìn nó như “AI đọc email hay quá”. Góc đáng bàn hơn là: triển khai AI routing là bài toán hệ thống, không phải bài toán chọn model.

Nếu sau bài này bạn đổi một cách nghĩ, thì là câu này: đừng hỏi model nào phân loại email tốt nhất; hãy hỏi hệ thống của bạn chịu lỗi sai kiểu nào được.

Sơ đồ minh họa cho bài Định tuyến email AI: dựng như hệ thống thật

Sơ đồ tóm tắt ý chính của bài viết.

Mục tiêu thật: không phải tự động hóa, mà là giảm nhầm tuyến

Nhiều team bắt đầu bằng prompt:

Classify this email into IT, Housing, Benefits, Children Services.
Return urgency: low, medium, high.

Prompt này chạy demo ổn. Vấn đề bắt đầu khi ra production.

Ví dụ cụ thể: một email của người dân viết dài, lẫn cả chuyện mất trợ cấp, tình trạng nhà ở xuống cấp và trẻ em trong gia đình bị ảnh hưởng. Nếu model chọn đúng một nhãn duy nhất, bạn có thể “đúng về mặt kỹ thuật” nhưng sai về mặt vận hành.

Vì vậy, mục tiêu không nên là “AI thay nhân viên sort mail”. Mục tiêu nên là:

giảm thời gian email nằm sai hàng đợi;
làm rõ email nào cần người xử lý ngay;
giữ được dấu vết vì sao hệ thống route như vậy;
cho phép con người sửa và feedback lại.

Nói thẳng ra thì, AI routing giống một hải trình có nhiều phao tiêu: model chỉ là một đoạn trên tuyến, không phải cả con tàu.

Checklist trước khi viết dòng code đầu tiên

Trước khi đụng Bedrock, Lambda, queue hay dashboard, team nên khóa 6 quyết định này:

| Quyết định | Câu hỏi cần chốt | Nếu bỏ qua sẽ bị gì |
|---|---|---|
| Taxonomy | Có những nhóm email nào, nhóm nào được multi-label? | Model ép email vào nhãn sai |
| Severity | “Khẩn” nghĩa là gì trong SLA nội bộ? | Mỗi phòng hiểu urgency một kiểu |
| Confidence | Ngưỡng tin cậy nào thì auto-route? | Tự động hóa quá tay |
| Human review | Trường hợp nào bắt buộc người duyệt? | Sai một lần nhưng hậu quả lớn |
| Audit trail | Lưu input, output, lý do, version prompt ở đâu? | Không debug được khi bị hỏi lại |
| Governance | Ai được sửa prompt, taxonomy, model config? | Một thay đổi nhỏ làm lệch cả luồng |

Ở đây có vài thuật ngữ cần neo nhanh:

taxonomy: bộ phân loại nghiệp vụ, ví dụ Housing, IT, Benefits, nhưng có định nghĩa rõ ràng.
confidence threshold: ngưỡng tin cậy để quyết định auto-route hay đưa người duyệt.
human-in-the-loop: con người nằm trong vòng xử lý, thường để duyệt các case rủi ro.
audit trail: dấu vết quyết định, giúp truy lại hệ thống đã làm gì và vì sao.

Đừng để taxonomy là file Google Sheet ai cũng sửa. Với hệ thống email công vụ, taxonomy nên được version như code.

version: 2026-01-08
categories:
  - id: housing
    description: Issues about housing conditions, rent, repairs, homelessness
    allow_multi_label: true
    escalation_rules:
      - condition: mentions_safety_risk
        severity: high
  - id: it
    description: Internal or public digital service access issues
    allow_multi_label: false
severity:
  high: response_same_day
  medium: response_within_standard_sla
  low: batch_review

Đây không phải phần “phụ trợ”. Đây là mỏ neo của hệ thống. Không có nó, model trôi theo cách viết email của từng người.

Bóc lớp hệ thống: 5 tầng nên dựng

Một bản triển khai gọn có thể đi theo 5 tầng sau.

1. Ingestion: nhận email nhưng chưa vội tin

Email đi vào từ mailbox, form web hoặc hệ thống CRM. Ở tầng này, hãy chuẩn hóa:

subject;
body;
sender metadata;
attachment metadata;
timestamp;
routing history nếu có.

Đừng ném raw email thẳng vào model. HTML, chữ ký, thread cũ và footer có thể làm nhiễu. Với email dài, nên tách phần mới nhất khỏi lịch sử trao đổi.

2. Pre-processing: che dữ liệu nhạy cảm nếu cần

Nếu email chứa thông tin cá nhân, team cần quyết định phần nào được gửi vào model. Có thể dùng redaction, nghĩa là che hoặc thay thế dữ liệu nhạy cảm trước khi inference.

Ví dụ:

{
  "sender": "redacted",
  "body": "My child has been affected by unsafe housing conditions...",
  "attachments": ["photo_metadata_only"]
}

Không phải hệ thống nào cũng cần che mọi thứ. Nhưng phải có quyết định rõ, nhất là khi dùng model inference qua tài khoản cloud.

3. Classification: cho model chọn, nhưng bắt trả cấu trúc

Đừng nhận câu trả lời văn xuôi kiểu “email này có vẻ thuộc Housing”. Hãy ép output có schema.

{
  "categories": ["housing", "children_services"],
  "severity": "high",
  "confidence": 0.82,
  "rationale": "Mentions unsafe housing conditions affecting a child.",
  "requires_human_review": true
}

rationale là lý do ngắn để người vận hành hiểu. Nhưng nhớ: rationale không phải bằng chứng tuyệt đối. Nó là lời giải thích của model, cần được log cùng input và version prompt.

4. Routing: quyết định như hệ thống workflow

Đây là nơi nhiều demo chết đuối. Classification chỉ nói “có vẻ thuộc nhóm nào”. Routing mới là hành động:

gửi vào queue phòng ban;
gắn SLA;
tạo ticket;
báo người trực;
yêu cầu review nếu confidence thấp hoặc severity cao.

Hình dung thế này: model nói “gió đang đổi hướng”, còn routing quyết định có đổi buồm hay quay về cảng. Đừng nhập nhằng hai việc đó.

5. Monitoring: xem model lệch trước khi inbox cháy

Nguồn về SageMaker AI với MLflow nhắc lại một điểm rất quan trọng: model có thể xuống chất lượng sau khi deploy vì dữ liệu đầu vào đổi. Với routing email, hai loại lệch đáng theo dõi là:

data drift: dữ liệu vào đổi tính chất, ví dụ mùa mưa làm email về nhà ở tăng, hoặc form mới thêm trường khiến nội dung khác trước.
model drift: chất lượng dự đoán giảm vì pattern cũ không còn khớp, ví dụ cách người dân mô tả vấn đề thay đổi.

Metric thực dụng hơn benchmark:

tỷ lệ email bị người dùng sửa route;
tỷ lệ case high severity bị downgrade nhầm;
thời gian từ nhận email đến đúng queue;
số email cần human review;
nhóm category có confusion cao.

Nếu có ground truth, tức nhãn đúng do người xác nhận, hãy lưu lại để đánh giá định kỳ. Nếu chưa có, bắt đầu bằng sampling: mỗi ngày lấy một phần email đã route để người phụ trách kiểm tra.

Governance: đừng để prompt nằm trên máy ai đó

Nguồn về Jamf AI Governance và Bedrock gợi ý một lớp thường bị bỏ quên: quản trị cấu hình AI trên thiết bị và ứng dụng. Với developer, bài học không nằm ở chuyện Mac hay Jamf cụ thể, mà ở nguyên tắc: AI config phải được quản lý tập trung.

Các file cần version và kiểm soát quyền:

prompt template;
taxonomy;
model ID;
region chạy inference;
logging config;
MCP server config nếu agent có gọi tool;
policy về dữ liệu được gửi ra model.

MCP server ở đây hiểu ngắn là điểm nối để ứng dụng AI gọi tool hoặc dữ liệu ngoài. Nếu email agent được phép gọi CRM, ticketing system hoặc knowledge base, MCP config sai có thể route đúng email nhưng ghi nhầm hệ thống.

Với team Việt Nam quy mô nhỏ, không cần dựng governance quá nặng ngay ngày đầu. Nhưng ít nhất hãy có:

/config
  taxonomy.yaml
  prompt_v3.md
  routing_rules.yaml
  model_config.yaml
/evals
  golden_set_2026_01.jsonl
/logs
  decision_schema.md

Và một rule đơn giản: thay đổi prompt hoặc taxonomy phải qua pull request. Không chỉnh nóng trong production rồi “nhớ nhớ là có sửa”.

Bẫy dễ dính: GraphRAG, test sớm, và triage quá đà

Có vài thứ hấp dẫn nhưng cần dùng đúng liều.

GraphRAG là RAG có thêm quan hệ dạng graph, hữu ích khi tri thức nằm rải rác và cần nối quan hệ giữa tài liệu. Trong nghiên cứu dược, kiểu BYOKG và GraphRAG giúp kết nối tri thức phân mảnh. Nhưng với email routing, đừng vội dựng graph nếu bài toán chỉ là phân loại theo phòng ban. GraphRAG đáng cân nhắc khi bạn cần tra policy phức tạp: ví dụ quyền lợi, địa bàn, lịch sử vụ việc và quan hệ giữa nhiều hồ sơ.

Sequential testing như mSPRT cho phép kiểm tra thử nghiệm nhiều lần mà vẫn kiểm soát lỗi thống kê tốt hơn kiểu cứ nhìn p-value mỗi ngày rồi dừng khi thấy đẹp. Với AI routing, ý tưởng áp dụng là: nếu bạn A/B prompt mới, đừng ship chỉ vì vài ngày đầu có vẻ tốt. Hãy định nghĩa tiêu chí dừng trước.

Triage quá đà cũng nguy hiểm. Nếu mọi email đều bị gắn high, nhân viên sẽ bỏ qua tín hiệu khẩn. Severity phải khan hiếm thì mới có giá trị.

Làm trong một buổi: bản triển khai tối thiểu

Nếu là mình, mình sẽ không bắt đầu bằng hệ thống hoành tráng. Một buổi chiều đủ để dựng bản “đi biển gần bờ”:

Lấy 100-200 email đã xử lý

Giả sử team bạn có dữ liệu lịch sử. Loại bỏ thông tin nhạy cảm nếu cần. Gắn nhãn đúng theo phòng ban và severity.

Viết taxonomy v1

Mỗi category có mô tả, ví dụ đúng, ví dụ sai, rule escalation.

Tạo prompt trả JSON

Ép schema cố định. Nếu output sai schema thì reject, không cố parse bằng niềm tin.

Chạy batch eval

So output model với nhãn người đã gắn. Đừng chỉ nhìn accuracy tổng; soi các case severity cao và multi-label.

Đặt ngưỡng auto-route

Ví dụ minh họa: confidence trên 0.85 và severity không phải high thì auto-route; còn lại đưa human review. Con số này không phải chuẩn chung, phải chỉnh theo rủi ro của bạn.

Log decision

Lưu input đã xử lý, output JSON, model version, prompt version, timestamp và người sửa nếu có.

Sau vòng này, bạn chưa có hệ thống hoàn hảo. Nhưng bạn có thứ quan trọng hơn: một khung ra quyết định có thể debug.

Chốt lại: chọn đường lui trước khi chọn model

Triển khai AI phân loại email không khó ở đoạn gọi model. Khó ở chỗ hệ thống phải biết khi nào không nên tự tin.

Điều đáng giữ từ các case Bedrock, governance, monitoring, GraphRAG và sequential testing là một nguyên tắc chung: production AI cần ranh giới vận hành rõ hơn là demo đẹp.

Model mới có thể làm bạn thấy gió thuận. Nhưng con tàu có về đúng cảng hay không phụ thuộc vào taxonomy, routing rule, log, monitoring và người được quyền kéo phanh. Đi biển mà chỉ ngắm sóng thì dễ say; nhìn bản đồ trước vẫn đỡ ướt giày hơn.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng