Bóc tách thực thể và hành động nghiệp vụ vào Bee CRM: Structured Extraction, Validation, HITL và đối soát lịch hẹn, tái khám, đơn hàng

Từ hội thoại đến hành động nghiệp vụ phải đi qua các cổng kiểm soát

Khách nhắn “chị đặt lịch implant sáng thứ Ba tuần sau, bác sĩ Minh Thư còn không em” có vẻ là một yêu cầu đơn. Về kỹ thuật, câu đó chứa action, subject, dịch vụ, thời điểm tương đối, người phục vụ, phạm vi chi nhánh và có thể là một câu hỏi lịch trống. Nếu hệ thống hiểu sai ngày, nhầm người hay bỏ qua policy, một record CRM đẹp vẫn có thể dẫn tới lịch hẹn sai ngoài đời.

Nguyên tắc thiết kế là tách hiểu ngôn ngữ khỏi quyết định và thực thi. Extractor tạo ứng viên có cấu trúc. Normalizer chuẩn hóa. Validator đối chiếu dữ liệu có thẩm quyền. Policy gate và nhân sự quyết định rủi ro. Workflow engine mới gửi action idempotent. Cuối cùng reconciliation xác nhận trạng thái downstream đúng như mong đợi. Điều này mở rộng cho lịch hẹn, tái khám, đơn hàng và task follow-up, nhưng không đồng nhất chúng với quyết định lâm sàng hoặc phê duyệt tài chính.

{
  "action": "create_appointment",
  "subject_ref": "Contact/123",
  "fields": {
    "start": {
      "raw_value": "9 giờ sáng thứ Ba tuần sau",
      "normalized_value": "2025-10-21T09:00:00+07:00",
      "confidence": 0.91,
      "evidence": { "message_id": "msg_456", "start": 18, "end": 45 },
      "normalization_status": "resolved"
    }
  },
  "overall_confidence": 0.86
}

Lớp 1. Structured extraction: output là ứng viên, không phải executable command

Mỗi field trích xuất cần giữ raw value để con người đọc lại nguyên văn, normalized value để máy xử lý, confidence, source evidence, normalization status và validation status. Với cuộc gọi, evidence nên trỏ về đoạn transcript và timestamp; với chat, trỏ về message ID và offset. Version của model, prompt, schema và policy cần nằm trong audit event để một quyết định có thể tái hiện sau này.

Nếu thiếu subject đã xác minh, dịch vụ, timezone hoặc thời gian rõ ràng, output đúng không phải cố đoán cho đủ JSON. Output đúng là trạng thái needs_clarification hoặc needs_review. Với healthcare, workflow hành chính có thể đặt hoặc nhắc lịch theo policy doanh nghiệp. Nó không được tự đánh giá chỉ định điều trị, mức độ khẩn cấp y khoa hay thay bác sĩ quyết định chăm sóc.

Lớp 2. Normalization có audit, validation phải xác định được

“Sáng thứ Ba tuần sau” không phải timestamp. Bộ suy luận thời gian cần lưu raw value, anchor time là thời điểm tin nhắn, timezone như Asia/Ho_Chi_Minh, thời điểm resolve và resolution rule. Khi một cách nói có nhiều diễn giải, chatbot hỏi lại bằng ngày cụ thể thay vì dùng confidence để chọn một trong hai. Số điện thoại, dịch vụ, SKU, tên chi nhánh và trạng thái đơn cũng cần mapping có version, để rule thay đổi không âm thầm sửa lịch sử cũ.

• Kiểm tra subject tồn tại, thuộc đúng tenant và requester có quyền thao tác.
• Kiểm tra consent, purpose, channel, rate limit và policy trước outbound hoặc chăm sóc lại.
• Kiểm tra dịch vụ, nhân viên, sản phẩm, giá, tồn kho hoặc appointment slot từ hệ thống nguồn, không từ model memory.
• Kiểm tra action không trùng, record đang ở trạng thái cho phép và các field bắt buộc đã có bằng chứng.

Lớp 3. Human-in-the-loop, idempotency và reconciliation

Thay vì để model gọi trực tiếp API tạo appointment hoặc order, hệ thống tạo WorkflowTask nội bộ chứa ứng viên, evidence, validation result, risk level và action được đề xuất. Reviewer có thể approve, reject hoặc sửa field. Tất cả lựa chọn trở thành audit event. Với action cần xác nhận của khách, workflow giữ chỗ hoặc draft trước, rồi chỉ confirm sau khi khách và policy đều hợp lệ.

Idempotency key cần ổn định theo tenant, nguồn, action đã chuẩn hóa và revision. Ví dụ tenant_123:msg_456:create_appointment:v1. Khi khách sửa yêu cầu, tạo revision mới thay vì ghi đè bằng chứng cũ. Nếu request timeout sau khi hệ thống ngoài đã tạo record, retry mù có thể tạo lịch trùng. Reconciliation so sánh expected state workflow với actual state từ CRM, calendar, ERP hoặc hệ thống lịch để phát hiện success chưa ghi nhận, duplicate, webhook mất hay sửa tay ngoài luồng.

Lớp 4. Đo precision theo action, bảo vệ dữ liệu theo boundary

Không nên gộp một con số “accuracy” cho toàn bộ pipeline. Đo riêng action precision trên action đã auto-executed, subject exact match, date-time exact match gồm timezone và anchor, service hoặc order exact match, reviewer override, duplicate prevention, reconciliation lag và policy block. Mọi báo cáo cần nêu cohort, kênh, khoảng thời gian, ground truth, cách human adjudication và khoảng tin cậy nếu dùng để quyết định mở rộng automation.

PII, nội dung hội thoại, số điện thoại, email, clinical note và token không nên xuất hiện trong log vận hành thô. Log cần ưu tiên event ID, hash, actor, action, policy, result và timestamp; dữ liệu chi tiết chỉ mở cho role cần thiết. Bee CRM có thể giữ hành trình khách và luồng follow-up trên một bề mặt vận hành, còn kết nối API với CRM, calendar hay ERP hiện hữu phải được khảo sát mapping dữ liệu, quyền và boundary action theo từng doanh nghiệp.

Lớp 5. Thiết kế schema để action có thể kiểm tra trước khi chạy

Schema action nên biểu đạt rõ điều gì extractor biết, điều gì validator đã xác nhận và điều gì vẫn cần con người. Không trộn confidence model với authorization hoặc execution_result. Một cấu trúc hữu ích gồm candidate, evidence, normalization result, validation failures, policy decision, review decision, execution attempt và reconciliation result. Khi mỗi transition được biểu diễn tường minh, UI có thể giải thích cho reviewer và test tự động có thể bao phủ các nhánh quan trọng.

{
  "task_id": "wf_01J...",
  "candidate": { "action": "create_appointment", "revision": 1 },
  "validation": {
    "subject": "passed",
    "slot": "passed",
    "consent": "passed",
    "timezone": "needs_confirmation"
  },
  "policy": { "decision": "review_required", "version": "2025-10" },
  "execution": { "state": "blocked" },
  "audit": { "source_event_id": "evt_01J..." }
}

Schema strict giảm lỗi parse, nhưng không thay thế validation nghiệp vụ. JSON hợp lệ vẫn có thể đặt bác sĩ sai chi nhánh hoặc tạo đơn với SKU đã hết hàng. Validator nên trả reason code có thể hiển thị hoặc route, ví dụ slot_unavailable, consent_missing, identity_unverified, price_version_expired. Reason code giúp đo loại failure theo thời gian thay vì chỉ có một bucket “automation failed”.

Lớp 6. Reviewer experience quyết định human-in-the-loop có thực sự an toàn

Human review chỉ là control thật khi người duyệt nhận đủ thông tin trong thời gian hợp lý. Màn hình review cần raw câu khách nói, normalized field, evidence highlight, dữ liệu nguồn được quyền xem, validation result, rule nào tạo yêu cầu review và action hậu quả nếu approve. Reviewer cần có lựa chọn approve, reject, sửa và request clarification, không bị ép chọn một nút “đồng ý” mơ hồ.

Escalation cần expiry và ownership. Một task review treo quá lâu có thể gây mất lịch hoặc gửi phản hồi sai thời điểm. Khi hết SLA, workflow nhắc owner, chuyển người dự phòng hoặc thông báo khách rằng yêu cầu đang được xác minh, tùy theo policy. Không nên auto-approve chỉ vì hàng review quá tải; đó là chuyển rủi ro vận hành thành rủi ro cho khách hàng.

Lớp 7. Privacy, retention và evaluation là phần của kiến trúc, không phải việc thêm sau

Pipeline xử lý PII cần minimization ngay từ input. Nếu chỉ cần extraction date và service, không nhất thiết đưa toàn bộ lịch sử CRM vào context. Dữ liệu dùng để đánh giá nên synthetic hoặc de-identified khi có thể; quyền truy cập transcript, audio và evidence cần theo role, retention policy và audit. Secret, OAuth token, số điện thoại và clinical note không được đi vào log debug mặc định. Các bản ghi phục vụ đối soát phải giữ đúng thông tin cần thiết, có thời hạn và đáp ứng chính sách doanh nghiệp.

Eval nên bao gồm tiếng Việt không dấu, cách nói miền vùng, code-switching, relative date, khách đổi ý, nhiều ý định trong một câu, duplicate message, thiếu quyền, record đã xóa và note có prompt injection. Kết quả cần tách theo từng action và trường dữ liệu. Một pipeline có date-time exact match cao nhưng subject match thấp không đủ an toàn để tự tạo lịch. Chỉ khi dữ liệu đo chứng minh scope hẹp đạt yêu cầu, đội ngũ mới mở rộng mức tự động hóa.

“AI hữu ích nhất khi biến hội thoại thành một đề xuất có bằng chứng. Quyết định tạo thay đổi ngoài đời vẫn phải thuộc về policy, dữ liệu có thẩm quyền và con người chịu trách nhiệm.”