Khi nào AI Agent được phép lên Production? Kiến trúc Evaluation, Replay và Release Gate cho CSKH đa kênh

Vấn đề không phải model có thông minh hay không, mà là agent có được phép tác động vào vận hành hay không

Một demo AI có thể trả lời trôi chảy câu hỏi về giá, đặt lịch hoặc trạng thái đơn hàng. Nhưng production đặt ra câu hỏi khác hẳn. Agent có nhận đúng khách khi họ đổi từ chat sang gọi điện không? Có lấy đúng bảng giá đang hiệu lực cho đúng chi nhánh không? Có biết nói “tôi chưa đủ dữ liệu” thay vì suy đoán không? Có tạo hai lịch hẹn khi webhook được gửi lại không? Có dừng khi khách đã rút đồng ý nhận tin không? Một câu trả lời nghe thuyết phục không bao trùm những failure mode này.

Vì vậy, release một AI Agent không nên giống bật một chat widget mới. Nó gần với release một hệ thống phân tán có khả năng ra quyết định và tạo side effect. Evaluation là lớp bằng chứng xác định agent được phép làm gì, trong điều kiện nào, với rủi ro nào và phải lùi về đâu khi bằng chứng không đủ. Đây là nền tảng để CEO nhìn thấy risk envelope, CTO có release gate rõ ràng và đội triển khai không phải dựa vào cảm giác sau vài cuộc hội thoại thành công.

Bài này trình bày một kiến trúc evaluation tham chiếu cho AI CSKH đa kênh. Nó phù hợp khi một hệ thống kết nối inbox, Voice AI, RAG, workflow và CRM như Bee CRM. Đây không phải tuyên bố rằng BEEDONI đang cung cấp một evaluation platform riêng. Mục tiêu là làm rõ cơ chế kỹ thuật cần có trước khi mở rộng automation trên dữ liệu và quy trình thật của doanh nghiệp.

Lớp 1. Evaluation contract: định nghĩa thành công trước khi đo model

Sai lầm phổ biến là chọn metric sau khi đã có câu trả lời. Evaluation contract phải được viết trước: customer journey nào nằm trong scope, actor nào, dữ liệu nguồn nào là authoritative, agent được phép đưa ra answer, recommendation hay action, và outcome nào được coi là thành công. Ví dụ “đặt lịch nha khoa” không chỉ là intent book_appointment. Nó có thể gồm nhận diện identity, thu thập dịch vụ và chi nhánh, chuẩn hóa thời gian, kiểm tra slot, xác nhận khách, tạo draft hoặc hold, ghi CRM và nhắc lịch theo consent.

{
  "journey": "appointment_booking",
  "version": "2026-01",
  "scope": { "channel": ["zalo", "web"], "tenant": "clinic_demo" },
  "allowed_actions": ["answer", "create_appointment_draft"],
  "human_required_for": ["confirm_appointment", "update_sensitive_profile"],
  "success": {
    "required_slots": ["service", "branch", "start", "customer"],
    "no_policy_violation": true,
    "outcome": "draft_created_or_handoff"
  },
  "failure_budget": { "critical_policy_violation": 0 }
}

Contract làm lộ trade-off sớm. Nếu mục tiêu là giảm thời gian chờ, đội ngũ có thể cho agent tạo draft nhanh hơn. Nếu action là hoàn tiền hoặc cập nhật dữ liệu nhạy cảm, tốc độ không thể là metric quyết định và approval phải thuộc contract. Với mỗi journey, cần xác định action không thể chấp nhận lỗi. Những action này không được che dưới một điểm trung bình như “accuracy 92%”. Một lỗi gửi nhầm dữ liệu khách khác nghiêm trọng hơn hàng trăm lỗi đổi văn phong câu trả lời.

Lớp 2. Golden conversations: biến hội thoại thật thành dữ liệu kiểm thử có provenance

Golden set là tập tình huống có expected outcome đã được người có thẩm quyền xác nhận. Nó không phải tập transcript càng lớn càng tốt. Một case tốt cần giữ input đã ẩn danh, context được phép cấp cho agent, expected answer hoặc abstain, expected route, evidence hợp lệ, tool call được phép, state transition và outcome. Với hội thoại nhiều lượt, cần lưu cả điểm người dùng đổi ý, thông tin bị thiếu và thời điểm data source thay đổi.

Tập test phải phân vùng. Training hoặc prompt-tuning set giúp cải tiến. Validation set giúp chọn config. Holdout set bị khóa để báo kết quả headline. Nếu cùng transcript được dùng liên tục để sửa prompt rồi lại công bố điểm, kết quả không còn dự báo generalization. Ngoài split theo case, cần xem split theo khách hàng, thời gian, chi nhánh hoặc campaign để tránh model học thuộc cách diễn đạt của một cohort mà vẫn được chấm cao.

Dữ liệu production cần minimization và de-identification trước khi thành eval asset. Không đưa raw phone, email, clinical note, payment detail hay token vào benchmark mặc định. Link tới evidence gốc chỉ nên mở cho reviewer đủ quyền. Dataset card nên ghi nguồn, mục đích sử dụng, cách ẩn danh, owner, retention, known gaps và version. Đây là cách biến “một file ví dụ” thành tài sản kỹ thuật có thể audit.

Lớp 3. Rubric phân tầng: chấm đúng ở từng boundary, không chỉ chấm câu cuối

Một evaluation pipeline đáng tin cần chấm từ dưới lên. Ingestion kiểm event có đủ tenant, correlation và thứ tự cần thiết. Context kiểm identity, ACL, source freshness và retrieval. Understanding kiểm intent, entity và ambiguity. Decision kiểm route, policy và trạng thái workflow. Action kiểm schema, idempotency, side effect và reconciliation. Experience kiểm câu trả lời, tone, handoff và outcome. Cách tách này biến lỗi thành tín hiệu sửa đúng nơi, thay vì yêu cầu đội model sửa mọi thứ bằng prompt.

Event / transcript
  │
  ├─▶ Context: identity + ACL + evidence đúng?
  ├─▶ Understanding: intent + slot + ambiguity đúng?
  ├─▶ Decision: policy + state transition đúng?
  ├─▶ Tool: tool selection + input schema + authority đúng?
  ├─▶ Action: idempotency + downstream state đúng?
  └─▶ Experience: grounded answer + handoff + outcome đúng?

Rubric cần có mức pass, fail và not-applicable. Ví dụ, một case chỉ hỏi policy không nên bị phạt vì không tạo tool call. Một case source không đủ cần pass khi agent abstain và handoff đúng, không phải fail vì không có câu trả lời. Với action rủi ro, score có thể là binary gate: bất cứ cross-tenant retrieval hoặc policy violation nào đều chặn release của scope đó, dù toàn bộ metric khác tốt.

Lớp 4. LLM Judge: dùng để mở rộng review, không dùng như oracle

LLM judge hữu ích khi rubric phức tạp, chẳng hạn kiểm câu trả lời có grounded vào evidence hay handoff có giữ đủ ngữ cảnh không. Nhưng judge là một model với bias, sensitivity theo prompt và khả năng bị ảnh hưởng bởi độ dài hoặc văn phong. Để judge có giá trị, rubric phải cụ thể, input phải chứa evidence phù hợp, output phải có reason và score theo tiêu chí, và kết quả cần được calibration định kỳ với reviewer người trên tập đại diện.

Calibration không dừng ở correlation tổng. Đội ngũ cần xem judge disagreement với người tập trung ở đâu: câu trả lời dài, tiếng Việt không dấu, ngành y tế, tên riêng, code-switching, policy edge case hay transcript ASR lỗi. Khi judge và reviewer bất đồng, case trở thành dữ liệu để sửa rubric hoặc đưa vào holdout. Không nên chỉnh judge cho khớp tuyệt đối với một reviewer; mục tiêu là một quy trình nhất quán, minh bạch và biết giới hạn của nó.

Lớp 5. Trace replay: đánh giá agent trên đường đi thật, không chỉ trên prompt rút gọn

Prompt unit test thường đưa một câu hỏi và vài document vào model. Nó bỏ qua phần lớn production path: context được assemble ra sao, cache có trả nhầm không, retrieval filter có chạy trước rerank không, tool nào được agent thấy, workflow bị timeout ở đâu và user đã đổi ý ở lượt nào. Trace replay tái hiện một journey đã được redaction bằng event sequence, context snapshot, tool fixtures và expected state, sau đó chạy phiên bản agent mới qua cùng conditions.

{
  "trace_id": "trace_eval_001",
  "fixture_version": "2026-01-15",
  "events": ["message.received", "customer.resolved"],
  "context_snapshot": { "crm_version": 42, "policy_version": "2026-01" },
  "tool_fixtures": { "check_availability": "slot_available" },
  "expected": {
    "route": "AWAITING_CUSTOMER_CONFIRMATION",
    "forbidden_tools": ["confirm_appointment"],
    "required_evidence": ["pricing_doc_v8"]
  }
}

Replay có hai chế độ. Deterministic replay dùng tool fixture để kiểm decision logic thay đổi do prompt, router hoặc policy. Live replay gọi sandbox hoặc read-only replica để kiểm integration contract, latency và schema drift. Không nên replay trace vào production write endpoint chỉ để chạy test. Action fixture cần mô phỏng timeout, duplicate delivery, stale data, policy deny và downstream success nhưng response mất, vì đó là các tình huống làm agent thất bại khác với happy path.

Lớp 6. Release gate: shadow trước, canary sau, autonomy tăng dần

Offline score là điều kiện cần, không phải điều kiện đủ. Sau khi pass golden set và integration test, agent nên chạy shadow mode: nhận cùng event production nhưng chỉ tạo prediction, tool plan hoặc draft trong vùng cô lập, không gửi tin, không ghi mutation. Reviewer so sánh đề xuất với outcome thực tế. Shadow phát hiện distribution shift, language style và dependency behavior mà fixture chưa bao phủ.

Khi shadow đạt gate đã định, rollout theo canary với tenant, channel, journey hoặc action scope hẹp. Một release plan cần có baseline, owner, dashboard, kill switch, rollback criterion và thời điểm review. Canary không có nghĩa “bật 5% traffic rồi chờ”. Với action high-impact, 5% vẫn có thể quá lớn. Đơn vị rollout có thể là read-only agent trước, rồi draft, rồi one reversible action, sau đó mới là confirm có khách hoặc người duyệt.

Release gate cần gắn rõ với policy. Ví dụ, một cross-tenant leak, gửi outbound sau consent withdrawn hoặc tạo duplicate appointment là critical failure có budget bằng 0 trong scope thử nghiệm. Ngược lại, một câu trả lời ngắn chưa tối ưu có thể được ghi nhận để cải thiện mà không nhất thiết rollback toàn bộ. Sự phân tầng này giúp đội không chặn mọi tiến bộ vì lỗi nhỏ, nhưng cũng không che risk nghiêm trọng bằng average score.

Lớp 7. Online monitoring: outcome mới là phép đo cuối, nhưng không được đo ngây thơ

Sau release, mỗi agent run cần để lại trace gồm input reference đã redaction, context source, retrieval IDs, policy verdict, tool attempt, workflow state, human intervention và downstream outcome. Các ID như trace_id, correlation_id, event_id, workflow_id và idempotency_key có vai trò khác nhau. Giữ chúng tách biệt giúp SRE biết hệ thống chậm ở đâu, đội business biết customer journey nào bị gián đoạn và audit biết action nào được ai phê duyệt.

Metric online phải được giải thích bằng cohort và attribution. Tỷ lệ booking tăng sau khi bật agent chưa chứng minh agent tạo ra tăng trưởng, vì campaign, seasonality, chất lượng lead hoặc team sales có thể đổi cùng lúc. Khi khả thi, dùng holdout, phased rollout hoặc A/B có guardrail. Khi không thể randomize, ghi rõ causal confidence thấp hơn và theo dõi đồng thời các safety metric: policy deny, handoff, override, complaint, cancellation, duplicate suppression, reconciliation lag và incident.

Lớp 8. Governance và vòng lặp cải tiến: mỗi lỗi phải trở thành một control tốt hơn

Một incident không nên chỉ được giải bằng “sửa prompt”. Case cần được phân loại: data quality, identity, retrieval, model understanding, tool schema, policy, workflow, permission, user experience hay human process. Sau triage, case được thêm vào regression suite với expected outcome, owner và version. Nếu root cause là knowledge source cũ, sửa source và version index. Nếu root cause là ambiguous policy, business owner phải quyết định rule. Nếu root cause là model uncertainty, agent cần hỏi lại hoặc handoff sớm hơn.

Đây là cách evaluation nối kỹ thuật với vận hành. Nhắn tin đa kênh, Voice AI, RAG và Bee CRM chỉ tạo thành hệ thống trưởng thành khi mỗi change có evidence trước release, mỗi action có boundary và mỗi incident làm policy hoặc test tốt hơn. Doanh nghiệp không cần chờ xây một nền tảng eval khổng lồ. Có thể bắt đầu bằng một journey, một rubric, vài dozen golden case và một review cadence nghiêm túc, rồi mở rộng theo risk và outcome đã đo.

“AI Agent không được phép lên production khi nó nói nghe đủ hay. Nó được phép mở rộng autonomy khi doanh nghiệp chứng minh được nó hiểu đúng phạm vi, hành động đúng boundary và lùi lại đúng lúc.”