Ngừng cung cấp thông tin đăng nhập cơ sở dữ liệu cho các agent của bạn.
Một con số đã xuất hiện tại Hội nghị Data + AI Summit tuần này, xác nhận điều mà chúng tôi đã nói tại CrewAI từ lâu:
Tôi đã tham gia một phiên thảo luận dành cho nhà sáng lập tại Summit có tên "The Agentic Stack," và con số 99% chính là nội dung thực tế của cuộc trò chuyện. Không phải mô hình nào thông minh nhất, cũng không phải framework nào chiến thắng, mà là cơ sở hạ tầng thực tế giữa "bản demo này thú vị" và "cái này chạy trong sản xuất và doanh nghiệp tin tưởng nó."
Các công ty hiện nay đã xác định 20, 100, thậm chí 800 trường hợp sử dụng agent, nhưng đội ngũ AI của họ thực tế chỉ có thể triển khai khoảng 10 trường hợp trong năm nay. Nút thắt không phải là logic của agent, mà thường là sự kết hợp của nhiều thứ như quản trị, kiểm soát, khả năng phân quyền xây dựng, mô hình truy cập dữ liệu, và đôi khi là chính dữ liệu. Không chỉ là ai có thể truy cập cái gì, mà còn là liệu dữ liệu có được cấu trúc và gắn nhãn đủ tốt để agent sử dụng một cách có trách nhiệm hay không.
Bản prototype hoạt động vì ai đó đã cấp quyền truy cập rộng rãi vào một cơ sở dữ liệu dev với dữ liệu mẫu sạch, sau đó quá trình đánh giá bảo mật diễn ra, và ôi trời, rồi đội ngũ quản trị dữ liệu xuất hiện, và bây giờ dự án nằm im trong ba tháng trong khi mọi người tranh luận về kiểm soát truy cập, chất lượng dữ liệu, và các định nghĩa ngữ nghĩa lẽ ra phải được giải quyết từ đầu.
Trong bài viết này, tôi muốn tập trung vào các vấn đề liên quan đến dữ liệu, và vấn đề đầu tiên là sai lầm khi coi "cấp quyền truy cập dữ liệu cho agent" là một vấn đề duy nhất. Nó không phải vậy. Nó ít nhất là bốn vấn đề khác nhau, và mỗi vấn đề cần một kiểu tương tác khác nhau.
Hãy nghĩ về cách một nhà phân tích cấp cao thực sự làm việc trong một công ty: họ không chỉ làm một việc với dữ liệu, mà có thể làm nhiều việc, tùy thuộc vào nhu cầu.
Đôi khi họ đặt một câu hỏi kinh doanh bằng ngôn ngữ tự nhiên và muốn một câu trả lời sử dụng các định nghĩa thực tế của công ty, như thế nào là doanh thu hoặc khách hàng nào là đang hoạt động. Họ không viết SQL, họ dựa vào lớp ngữ nghĩa để làm đúng.
Đôi khi họ viết một truy vấn chính xác vì họ biết chính xác mình cần gì. Họ chỉ cần một bảng cụ thể, các cột đúng, các bộ lọc đúng, và cần kho dữ liệu thực thi và trả về các hàng.
Đôi khi họ gọi một hàm đã được phê duyệt, một phép tính hoặc quy tắc kinh doanh mà ai đó đã kiểm tra và đăng ký.
Và đôi khi họ tìm kiếm, họ có thể cần tìm các tài liệu hoặc bản ghi liên quan trong dữ liệu phi cấu trúc, ít giống một truy vấn cơ sở dữ liệu thông thường với schema đã biết, mà giống một bài toán truy xuất hơn.
Bốn chế độ tương tác khác nhau với dữ liệu, nhưng mỗi chế độ có bề mặt quản trị riêng, và mỗi chế độ hỏng theo cách khác nhau khi bạn sai quyền.
Khi bạn trao cho agent một kết nối cơ sở dữ liệu duy nhất, bạn đang gộp cả bốn chế độ thành một: SQL thô với bất cứ thứ gì thông tin đăng nhập có thể truy cập, agent tạo truy vấn chống lại các bảng mà nó có thể không hiểu, không có lớp ngữ nghĩa, không có quản trị hàm, không có tối ưu hóa truy xuất. Dấu vết kiểm toán của nền tảng dữ liệu của bạn thậm chí không nhận ra điều gì đang xảy ra.
Đó là trước khi bạn thậm chí đến với chất lượng dữ liệu. Agent không biết rằng cột "doanh thu" trong một bảng
"e" ở ngữ cảnh này có nghĩa khác so với ngữ cảnh khác, hoặc một nửa số bản ghi trong bảng kế thừa chưa được cập nhật từ năm 2023.
Điều này tương đương với việc giao cho nhân viên mới mật khẩu cơ sở dữ liệu sản xuất ngay ngày đầu tiên và nói "tự xoay sở đi."
Mỗi một trong bốn tương tác đó nên là một công cụ riêng biệt, có quản trị, không phải là một đường ống mở duy nhất.
Chúng tôi đã thêm Databricks như một tích hợp được quản lý trong CrewAI AMP. Bốn máy chủ MCP được quản lý, mỗi máy chủ dành cho một mẫu tương tác:
Mỗi máy chủ được cấu hình độc lập, vì vậy một nhóm hoặc luồng thực hiện phân tích tài chính có thể sử dụng Genie và SQL, trong khi một nhóm khác xử lý các vấn đề hỗ trợ có thể sử dụng Vector Search và UC Functions. Bạn chỉ kích hoạt những gì quy trình làm việc cần, không hơn.
Đối với các nhà phát triển muốn truy cập SQL trực tiếp trong mã, `DatabricksQueryTool` trong `crewai-tools` cung cấp điều đó với các thiết lập mặc định hợp lý: catalog, schema, warehouse có thể cấu hình, và giới hạn số dòng để một vòng lặp agent không vô tình kéo toàn bộ bảng khách hàng của bạn.
Agent nên đi qua cùng một lớp quản trị mà các nhà phân tích của bạn phải trải qua.
Nếu một nhà phân tích con người trong công ty bạn không thể truy vấn một bảng, thì agent thay mặt họ cũng không thể, và nếu có một hàm được phê duyệt để tính toán tỷ lệ rời bỏ, agent nên gọi hàm đó thay vì tự tạo phiên bản riêng từ một prompt.
Đây không phải là một hiểu biết chỉ dành riêng cho Databricks. Đây là cách tích hợp agent-dữ liệu nên hoạt động ở mọi nơi. Chúng tôi chỉ làm điều này cực kỳ dễ dàng hơn cho các công ty tình cờ cũng là khách hàng của Databricks.
Chúng tôi đã làm điều tương tự với Snowflake vào tuần trước. Chúng tôi sẽ tiếp tục làm điều đó với mọi nền tảng dữ liệu lớn, bởi vì đây là mẫu hình: các agent hoạt động trong ranh giới quản trị hiện có của doanh nghiệp, không xây dựng một ranh giới song song.
Hãy ngừng cấp thông tin đăng nhập cơ sở dữ liệu cho agent của bạn. Thay vào đó, hãy cung cấp cho chúng các công cụ được quản trị.
