Cách Anthropic triển khai AI tự phục vụ phân tích dữ liệu ngay trên Slack

Các phương pháp tối ưu để triển khai một tác nhân phân tích dữ liệu trên Slack

Việc làm cho một tác nhân (agent) hoạt động chính xác và việc triển khai nó ở nơi mà những người không chuyên về phân tích có thể sử dụng là hai quá trình hoàn toàn khác biệt. Chúng tôi sẽ không nhắc lại các khuyến nghị về độ chính xác từ bài viết trước vì chúng vẫn còn phù hợp trong trường hợp này.

Thay vào đó, chúng tôi sẽ chia sẻ năm bài học quan trọng nhất của mình trong năm qua về cách triển khai một tác nhân phân tích dữ liệu trên Slack, cũng như cách bạn nên tư duy về phân phối, quyền truy cập, tính cập nhật và khả năng quan sát.

Cập nhật các kỹ năng thường xuyên như cách bạn cập nhật các mô hình dữ liệu

Bạn có thể dạy Claude cách thực hiện một tác vụ phù hợp với phong cách và yêu cầu của mình thông qua một "kỹ năng" (skill) — đây là một tệp markdown chứa các hướng dẫn bằng ngôn ngữ tự nhiên và các tệp tin mà Claude có thể tham chiếu khi cần.

Quyết định kiến trúc quan trọng nhất mà chúng tôi thực hiện là coi các tệp kỹ năng như nội dung được phục vụ và làm mới liên tục, thay vì là thứ được gửi đi một lần rồi bỏ quên.

Các mô hình dữ liệu có thể thay đổi vài lần trong ngày. Ví dụ: một cột bị đổi tên, định nghĩa về một chỉ số được sửa lại, hoặc một bảng bị ngừng sử dụng. Mỗi thay đổi đó cần phải được cập nhật vào tệp kỹ năng trong thời gian ngắn. Nếu Claude đọc bản sao kỹ năng của thứ Ba tuần trước, nó sẽ đưa ra câu trả lời sai của thứ Ba tuần trước với sự tự tin tuyệt đối.

Xu hướng này đặc biệt nguy hiểm vì người tiêu dùng dữ liệu hiện đã hoàn toàn tách biệt khỏi bối cảnh cần thiết để đánh giá độ chính xác của phản hồi. Họ không nhìn vào bảng điều khiển (dashboard) với các đường xu hướng hay các chỉ số liên quan để thực hiện "bài kiểm tra nhanh". Họ có thể chỉ nhận được một hoặc hai điểm dữ liệu trên Slack, và nếu đó không phải là dữ liệu họ thường xuyên theo dõi, họ có khả năng sẽ chấp nhận câu trả lời sai một cách đầy tự tin.

Để kiểm soát môi trường luôn thay đổi này, runtime của Claude Tag sẽ mount thư mục skills/ trong kho dữ liệu của chúng tôi và đọc lại nó trong mỗi cuộc hội thoại. Các tệp kỹ năng chỉ là các tệp markdown trên ổ đĩa; tác nhân đọc chúng theo cùng cách nó đọc bất kỳ tệp dự án nào khác.

Cung cấp cho tác nhân các kỹ năng vượt xa việc chỉ biết truy vấn

Bản năng ban đầu của chúng tôi khi triển khai tác nhân phân tích dữ liệu bằng Claude Tag là tạo ra một "kỹ năng kiến thức" (knowledge skill) — thứ dạy cho Claude biết nên sử dụng bảng nào và lớp ngữ nghĩa (semantic layer) của chúng tôi được tổ chức ra sao — rồi coi như xong. Chúng tôi nhanh chóng nhận ra cách tiếp cận đó sẽ cung cấp các con số chính xác, nhưng lại thiếu đi những thông tin chi tiết hữu ích.

Hầu hết người tiêu dùng dữ liệu thường đặt những câu hỏi mở và mơ hồ như "điều gì gây ra sự sụt giảm này?", "bạn có thể dự báo kết quả cuối tháng không?", hoặc "hãy hiển thị dữ liệu này dưới dạng phễu". Để trả lời những câu hỏi đó, tác nhân cần biết không chỉ dữ liệu nằm ở đâu mà còn cả cách một chuyên gia phân tích sẽ làm việc với nó.

Vì vậy, bên cạnh kỹ năng kiến thức này, chúng tôi đã trang bị cho Claude Tag các kỹ năng phân tích hoặc runbook bổ sung, bao gồm:

Mọi đội ngũ dữ liệu có lẽ đều đã có những quy ước này; chúng thường chỉ nằm trong đầu ai đó và thỉnh thoảng mới được ghi chép lại. Việc viết chúng ra thành các kỹ năng đảm bảo Claude áp dụng chúng nhất quán như cách một nhà khoa học dữ liệu của bạn thực hiện.

Kết nối với bối cảnh kinh doanh, không chỉ là kho dữ liệu (warehouse)

Ngay cả sự kết hợp giữa kỹ năng kiến thức và kỹ năng runbook cũng không phải lúc nào cũng đủ để trả lời một câu hỏi. Khi ai đó hỏi "tại sao lượt đăng ký giảm vào thứ Ba?", câu trả lời thường không nằm trong mô hình dữ liệu, mà thường nằm rải rác trong các luồng Slack, trình theo dõi sự cố, ghi chú phát hành và tài liệu.

Để giải quyết những khoảng trống này, chúng tôi kết nối Claude Tag vào chỉ mục kiến thức nội bộ, nơi lưu trữ các tài liệu, thảo luận và sự kiện trên toàn công ty. Khi tác nhân thấy một chỉ số biến động, nó có thể tìm kiếm trong chỉ mục đó để tìm bối cảnh đương thời: một sự cố được mở vào sáng hôm đó, một cờ tính năng (feature flag) bị thay đổi, hoặc thông báo của đối thủ cạnh tranh mà ai đó đã chia sẻ trong một kênh.

Câu trả lời bây giờ sẽ trông như thế này: "lượt đăng ký giảm 12% vào thứ Ba: có một sự cố dịch vụ thanh toán xảy ra từ 9-11 giờ sáng hôm đó, và sự sụt giảm tập trung ở khu vực bị ảnh hưởng."

Nếu tổ chức của bạn có biểu đồ tri thức (knowledge graph), công cụ tìm kiếm nội bộ, hoặc thậm chí chỉ là các nguồn cấp dữ liệu về sự cố và nhật ký thay đổi được tổ chức tốt, việc kết nối Claude Tag với chúng là thông tin có đòn bẩy cao nhất mà bạn có thể thêm vào sau chính kho dữ liệu. Bạn cũng có thể kết nối Claude Tag để nó có thể đọc và lấy bối cảnh từ các kênh quan trọng trên Slack.

Cấp quyền cho tài khoản dịch vụ một cách có chủ đích

Claude Tag truy vấn kho dữ liệu của bạn dưới danh nghĩa một tài khoản dịch vụ (service account), chứ không phải dưới danh nghĩa người đã đặt câu hỏi. Mặc dù đây là thiết kế đúng đắn (vì bạn không muốn mọi người dùng Slack đều cần thông tin xác thực kho dữ liệu trực tiếp), nhưng bất kỳ ai có thể nhắc đến bot đều có quyền truy cập dữ liệu của bot đó. Không có cơ chế bảo mật theo hàng (row-level security) cho từng người dùng: những gì tài khoản dịch vụ có thể đọc, bất kỳ ai trong kênh cũng có thể hỏi.

Chúng tôi tiếp cận vấn đề này theo năm cách (và chúng tôi khuyên bạn nên thực hiện nghiêm túc vì rất dễ làm sai và khó sửa chữa):

1. Giới hạn tài khoản dịch vụ chỉ trong dữ liệu được quản trị. Tại Anthropic, tài khoản dịch vụ của Claude Tag chỉ có thể đọc các bảng đầu ra của lớp ngữ nghĩa và các mart dữ liệu đã được tuyển chọn cung cấp cho chúng. Nó không thể đọc các luồng sự kiện thô, các lược đồ staging, hoặc bất cứ thứ gì trong sandbox cá nhân. Nếu một câu hỏi yêu cầu dữ liệu nằm ngoài phạm vi đó, tác nhân sẽ thông báo thay vì đoán mò. Đó cũng là trải nghiệm người dùng đúng đắn vì dữ liệu nằm ngoài lớp được quản trị chưa được xác thực.

2. Phân loại PII (thông tin nhận dạng cá nhân) ở cấp độ cột và từ chối quyền truy cập của tài khoản dịch vụ. Dữ liệu được quản trị không tự động là dữ liệu an toàn PII (ví dụ: một bảng đã được tuyển chọn vẫn có thể chứa địa chỉ email). Chúng tôi duy trì một danh mục dữ liệu với dòng dõi dữ liệu (lineage) ở cấp độ cột, vì vậy nguồn gốc và luồng hạ nguồn của mọi cột đều được biết rõ. Khi các cột mới xuất hiện, Claude sẽ quét chúng và gắn cờ các ứng viên có khả năng là PII để con người xem xét. Sau đó, con người sẽ áp dụng phân loại trong siêu dữ liệu của cột, và dòng dõi sẽ truyền nhãn đó sang các bảng dẫn xuất. Vì tài khoản dịch vụ của Claude Tag không có quyền truy cập PII, các kiểm soát truy cập cấp cột của kho dữ liệu sẽ làm cho bất kỳ cột PII nào trở nên vô hình đối với tác nhân. Nó có thể truy vấn bảng, nhưng các cột nhạy cảm đơn giản là không thể đọc được.

3. Ghi lại đường dẫn kết nối trong chính kỹ năng. Kỹ năng kho dữ liệu của chúng tôi có một phần dành riêng về cách tác nhân kết nối (cho dù qua CLI, API trực tiếp, hay máy chủ MCP) và chính xác cách xác thực hoạt động cho từng đường dẫn. Tính năng đơn giản này cho phép chúng tôi phân biệt giữa việc tác nhân thất bại một cách rõ ràng ("Tôi không thể tiếp cận kho dữ liệu từ giao diện này; đây là lý do") so với thất bại gây bối rối (một truy vấn chạy âm thầm vào sai dự án, hoặc một lời nhắc xác thực bị chuyển tiếp đến nơi không nên). Khi cơ chế kết nối nằm trong kỹ năng, tác nhân có thể giải thích các hạn chế của chính nó.

4. Coi việc tham gia kênh của Claude như một quyền truy cập. Việc thêm Claude Tag vào một kênh Slack thực chất là cấp cho các thành viên của kênh đó quyền truy cập đọc vào bất cứ thứ gì tác nhân có thể truy vấn. Chúng tôi đã làm điều này một cách rõ ràng: Claude được thêm vào một kênh bởi một thành viên trong nhóm dữ liệu, và nhóm dữ liệu sở hữu danh sách các kênh đó.

5. Gán nhãn mọi truy vấn. Đối với mỗi truy vấn kho dữ liệu, Claude Tag mang theo các nhãn xác định giao diện, cuộc hội thoại và người dùng yêu cầu (nơi Slack cung cấp). Điều này không thực thi bất cứ điều gì tại thời điểm truy vấn, nhưng nó cung cấp khả năng phân bổ chi phí và dấu vết kiểm toán (bạn có thể xác định ai là người đã đặt câu hỏi quét 4 TB sau khi sự việc đã xảy ra).

Quan điểm chung của chúng tôi là một tác nhân phân tích dữ liệu trên Slack là một bản sao đọc (read replica) được chia sẻ của kho dữ liệu được quản trị của bạn, và chúng tôi cố gắng giới hạn nó như vậy.

Đo lường mọi câu trả lời

Việc xác định xem tác nhân có đưa ra câu trả lời đầy đủ hay không không phải là điều bạn có thể nhìn bằng mắt thường.

Chúng tôi ghi lại một sự kiện có cấu trúc cho mọi câu hỏi mà Claude Tag xử lý. Điều này bao gồm:

Dữ liệu đo lường này cung cấp cho hai chế độ xem. Một chế độ theo dõi mức độ áp dụng hoặc tỷ lệ các truy vấn của tác nhân đi qua lớp được quản trị thay vì SQL ad hoc theo giao diện và miền. Chế độ còn lại theo dõi tính chính xác được đo bằng tỷ lệ phản ứng 👎 và các chỉnh sửa theo miền. Đây là đại diện trực tuyến cho độ chính xác giữa các lần chạy đánh giá (eval runs).

Chỉ số áp dụng hóa ra lại là con số có thể hành động duy nhất mà chúng tôi theo dõi. Khi nó giảm đối với một miền, điều đó gần như luôn có nghĩa là một tệp kỹ năng đã bị lệch hoặc một loại câu hỏi mới đã xuất hiện mà lớp ngữ nghĩa chưa bao phủ được.

Cách điều này thúc đẩy việc áp dụng phân tích tự phục vụ

Các luồng Claude Tag trở thành cuộc họp mới

Các luồng Claude Tag yêu thích và hiệu quả nhất của chúng tôi thường có nhiều người tham gia. Trong những trường hợp này, chúng tôi thấy mọi người đóng góp ý tưởng và bối cảnh trong khi Claude xử lý các công việc nặng nhọc.

Ví dụ, một thành viên trong nhóm dữ liệu đã hỏi Claude tại sao một bảng điều khiển doanh thu lại mất nhiều thời gian hơn bình thường để tải. Claude phát hiện ra kết quả truy vấn không được lưu vào bộ nhớ đệm và một lỗi đang làm chậm quá trình kết quả đến trang web.