RAG-CRM với Bee CRM: Truy xuất theo quyền, dữ liệu động và câu trả lời có bằng chứng thay vì đổ toàn bộ CRM vào prompt

RAG-CRM không phải một prompt dài hơn

Khi một tư vấn viên hỏi “khách này đã đặt lịch ở chi nhánh nào, báo giá nào còn hiệu lực và ai đang phụ trách”, câu trả lời đòi hỏi dữ liệu động, quyền truy cập và ngữ cảnh thời gian. Đưa toàn bộ CRM vào prompt vừa không thể mở rộng, vừa tạo dữ liệu cũ, vừa phá vỡ nguyên tắc least privilege. RAG-CRM đúng nghĩa phải truy xuất đúng phần dữ liệu mà requester được phép xem, có nguồn để kiểm tra và biết abstain khi bằng chứng chưa đủ.

Bài viết kiến trúc Enterprise RAG trước đó đã trình bày hybrid retrieval, reranking và guardrail cho kho tài liệu. Tài liệu này đi sâu vào phần nối RAG với dữ liệu CRM: lifecycle, ACL, citation và kiểm thử authorization. Điểm cốt lõi: một index hữu ích không được trở thành bản sao không kiểm soát của dữ liệu khách hàng.

Lớp 1. Tách CRM system of record khỏi derived index

Bee CRM hoặc CRM hiện hữu giữ dữ liệu giao dịch gốc: contact, deal, ticket, appointment, owner, trạng thái và quyền. Chỉ mục keyword hoặc vector được tạo từ bản sao đã chuẩn hóa để tìm nhanh theo ngôn ngữ tự nhiên. Vì là derived data, mỗi chunk cần mang tenant ID, object ID, version, updated_at, ACL, loại nguồn và deletion state. Khi record đổi owner, bị merge, xóa hoặc quyền thay đổi, index và cache phải nhận event tương ứng.

{
  "chunk_id": "crm:ticket:TK-2048:v7:note-2",
  "tenant_id": "tenant_123",
  "object_type": "ticket",
  "object_id": "TK-2048",
  "source_version": 7,
  "updated_at": "2025-04-18T08:30:00+07:00",
  "acl": { "roles": ["sales-manager"], "owner_id": "usr_9" },
  "deletion_state": "active",
  "text": "... dữ liệu đã chuẩn hóa ..."
}

Đồng bộ ban đầu cần backfill có checkpoint. Sau đó CDC hoặc webhook phát incremental update. Nhưng webhook không miễn trừ reconciliation: cần định kỳ so sánh version và deletion state giữa CRM với index để tìm missed event, stale chunk hoặc citation mồ côi. Đây là khác biệt giữa demo tìm kiếm và hệ thống phục vụ quyết định vận hành.

Lớp 2. Retrieval theo tenant và quyền trước khi đưa dữ liệu tới LLM

Tenant ID và quyền requester phải trở thành filter ở tầng truy vấn server-side. Chỉ những candidate qua filter mới được vector search, keyword search, rerank và đưa vào context. Câu lệnh trong prompt như “chỉ trả lời dữ liệu của tenant hiện tại” có giá trị hướng dẫn hành vi, nhưng không phải security boundary. Một lỗi filter sau retrieval có thể để ranking, cache hoặc telemetry đã thấy dữ liệu không được phép.

Hybrid retrieval không phải mặc định thần kỳ, nhưng thường hợp lý khi CRM có cả identifier chính xác lẫn ghi chú tự do. BM25 hoặc exact filter xử lý mã hiếm tốt hơn; vector search giúp hiểu cách diễn đạt khác nhau; cross-encoder rerank quyết định lại trên tập candidate nhỏ hơn. Không evidence đủ mạnh, trợ lý cần nói rõ không tìm thấy dữ liệu trong phạm vi quyền hiện có và đề nghị đường xử lý tiếp theo.

Lớp 3. Citation là contract, dữ liệu động đi qua tool có schema

Một citation đúng cần đạt ba điều kiện: nguồn tồn tại, nguồn thực sự chứng minh claim, và requester có quyền xem nguồn đó. Citation relevance khác citation correctness: câu trả lời có thể có vẻ hữu ích nhưng trỏ sai ticket, hoặc trỏ đúng ticket nhưng diễn giải sai. UI nên đưa người dùng tới object CRM với quyền kiểm tra, thay vì tạo ảo giác rằng text sinh ra đã là bằng chứng.

Giá khuyến mãi, lịch trống, trạng thái đơn hàng và owner hiện tại không nên dựa vào chunk đã lập chỉ mục. Chúng đi qua tool hoặc API theo schema chặt, xác thực quyền và return data đủ nhỏ. Các thao tác ghi như đặt lịch hoặc sửa hồ sơ phải tách khỏi luồng trả lời, có policy gate, xác nhận khi cần và idempotency key. Cách này giữ Bee CRM là điểm quyết định trạng thái, thay vì biến LLM thành một nguồn dữ liệu thứ hai.

Lớp 4. Đánh giá sáu lớp trước khi tin câu trả lời

• Ingestion: record vừa cập nhật, xóa hoặc đổi quyền có phản ánh vào index và cache đúng SLA đã định nghĩa không?
• Retrieval: evidence chuẩn có nằm trong top-k sau tenant và ACL filter không?
• Generation: câu trả lời có grounded vào evidence thay vì suy diễn không?
• Citation: citation có tồn tại, hỗ trợ đúng claim và hợp lệ với requester không?
• Authorization: test role matrix, tenant khác, record đã xóa và cache boundary có rò dữ liệu không?
• Operations: index lag, queue lag, latency, error rate và cost/query có nằm trong SLO của use case không?

Một eval set hữu ích cần câu hỏi thật đã ẩn danh, golden object và citation, record đã xóa, requester thiếu quyền, dữ liệu tenant khác và mẫu prompt injection. Không nên quảng cáo Recall@10, citation correctness hoặc p95 latency nếu chưa nêu rõ cohort, ground truth, phiên bản index, role scope, tải hệ thống và khoảng thời gian đo. Đó là target kiểm thử hoặc SLO đề xuất, không tự động là năng lực mặc định của mọi triển khai.

Lớp 5. Ingestion lifecycle: thay đổi, xóa, merge và quyền mới đều là event hạng nhất

Đội kỹ thuật thường kiểm thử happy path là record mới xuất hiện trong search. Những lỗi khó hơn lại nằm ở lifecycle ngược: deal đổi owner, contact bị merge, ticket bị xóa, scope OAuth bị thu hẹp hoặc retention policy yêu cầu purge. Một upsert mới không xóa chunk cũ đã bị thay thế. Một ACL thay đổi sau khi embedding đã tạo không tự cập nhật cache. Nếu không có tombstone, source version và reconciliation, citation có thể trỏ đến dữ liệu không còn hợp lệ.

CRM change event
  │
  ├─▶ Normalize object + ACL + tenant metadata
  ├─▶ Upsert version mới hoặc tombstone version cũ
  ├─▶ Invalidate cache theo object và permission scope
  ├─▶ Update keyword/vector index bất đồng bộ
  └─▶ Reconcile định kỳ: source version = index version?

Reconciliation không nhất thiết chạy cùng nhịp cho mọi object. Record giá hoặc lịch trống có thể không cần index vì phải gọi API thời gian thực. Knowledge note ít thay đổi có thể reconcile theo batch. Điều quan trọng là phân loại data freshness theo use case, đo lag từ source update tới searchable state và có owner khi lag vượt SLO. Nếu một dữ liệu không thể chấp nhận stale, đừng đưa nó vào retrieval chỉ vì vector search thuận tiện.

Lớp 6. Cache cũng là security boundary

Nhiều hệ thống filter retrieval đúng nhưng cache sai. Cache key cho query hoặc answer phải chứa tenant ID, role hoặc ACL scope, phiên bản dữ liệu liên quan và khi cần cả identity requester. Cache một answer theo text câu hỏi rồi trả cho role khác là một cách bypass authorization không cần khai thác vector database. Tương tự, telemetry và eval trace phải tránh lưu raw retrieved content nếu không có retention và access boundary tương đương CRM.

Một thiết kế production nên có security test âm tính: requester không có quyền, record đã xóa, tenant khác nhưng query giống nhau, cache warm từ role cao, prompt injection nằm trong attachment và object được merge giữa hai contact. Mục tiêu không phải tuyên bố cô lập tuyệt đối, mà chứng minh boundaries đã được kiểm thử trên matrix quyền và dữ liệu đại diện cho triển khai thực tế.

Lớp 7. Mẫu hỏi đáp có thể kiểm tra trong vận hành

Một response RAG-CRM hữu ích nên tách rõ fact lấy từ evidence, dữ liệu động vừa tra qua tool và phần hệ thống chưa biết. Với câu hỏi về lịch hẹn, UI có thể hiển thị nguồn lịch sử từ CRM, slot đang trống theo API và button tạo workflow draft. Với câu hỏi về chính sách, response hiển thị version tài liệu và ngày hiệu lực. Khi evidence mâu thuẫn, assistant nêu mâu thuẫn và route về owner dữ liệu, không tự chọn câu trả lời thuận tiện nhất.

Đây là cách RAG-CRM bổ sung cho Bee CRM, không thay thế trách nhiệm vận hành dữ liệu. Doanh nghiệp cần xác định object nào là nguồn chuẩn, ai chịu ownership, field nào được đưa vào retrieval, role nào được xem và cách cập nhật hoặc xóa lan tới index. Quyết định đó tạo ra chất lượng lâu dài hơn mọi lựa chọn embedding đơn lẻ.

“RAG-CRM đáng tin không làm mô hình biết mọi thứ. Nó khiến hệ thống biết dữ liệu nào được phép dùng, nguồn nào chứng minh câu trả lời và lúc nào cần im lặng.”