Microsoft và Databricks mở rộng hợp tác vì AI có quản trị

Ngày 23 tháng 7 năm 2026, Microsoft và Databricks công bố gia hạn quan hệ đối tác chiến lược đã có từ một thập kỷ nay, kéo dài đến hết những năm 2030. Quan hệ hợp tác Microsoft Databricks giờ đây kết hợp lớp quản trị Unity AI Gateway, lớp grounding Genie Ontology, việc tích hợp Genie sâu hơn vào các quy trình làm việc của Microsoft và hạ tầng Azure Databricks được mở rộng.

Với các đội kỹ thuật dữ liệu, nền tảng và MLOps, câu hỏi thực tế không phải là trợ lý có viết được câu trả lời trau chuốt hay không, mà là câu trả lời đó có dùng đúng định nghĩa đã phê duyệt, dữ liệu cập nhật, nguồn được cấp quyền và bằng chứng có thể truy vết hay không.

Tại Van Data Team, chúng tôi bắt đầu bằng việc lập bản đồ các câu hỏi, danh tính, hệ thống nguồn, định nghĩa nghiệp vụ, cổng review và các kịch bản lỗi trước khi chọn mô hình hay công cụ. Mô hình triển khai do chính người sáng lập dẫn dắt giúp khâu khảo sát và triển khai nằm trong cùng một vòng lặp. Bài hướng dẫn này tách thông tin đã được công bố khỏi phân tích rộng hơn của chúng tôi, sau đó đưa ra bảng so sánh các kỹ thuật grounding, checklist mức độ sẵn sàng, cổng quản trị và tiêu chí đánh giá.

Bài học chính

Microsoft và Databricks đang đưa AI doanh nghiệp đến gần hơn với dữ liệu có quản trị và các quy trình mà đội ngũ vốn đã vận hành.

• Thông tin đã công bố: Unity AI Gateway quản trị mô hình, agent và chi phí; Genie Ontology giúp grounding agent trên dữ liệu doanh nghiệp; còn Genie đưa trải nghiệm dữ liệu đó vào các ứng dụng làm việc của Microsoft.
• Thông tin đã công bố: Azure Databricks vẫn là một phần của nền tảng dữ liệu cốt lõi, trong khi hạ tầng Azure Cobalt đang được áp dụng cho các workload agentic và xử lý nhiều dữ liệu.
• Phân tích của Van Data Team: Mô hình tốt hơn không thể sửa được các định nghĩa chỉ số mâu thuẫn, quyền truy cập quá rộng, bảng dữ liệu cũ, thiếu lineage hay khâu đánh giá yếu.
• Khuyến nghị vận hành: Bắt đầu với một quy trình trợ lý có phạm vi giới hạn, áp dụng cổng quản trị từ lúc nhận yêu cầu đến lúc trả lời, và kiểm thử với bộ câu hỏi tin cậy trước khi triển khai rộng.

Microsoft và Databricks đã công bố những gì

Thông báo này gộp quản trị, grounding ngữ nghĩa, tích hợp quy trình làm việc và hạ tầng Azure vào cùng một định hướng AI doanh nghiệp.

Microsoft cho biết sẽ tiếp tục tích hợp nền tảng Data và AI của Databricks vào các sản phẩm của mình. Các điểm kết nối được nêu tên gồm Microsoft Entra, Azure Data Lake Storage, OneLake, Power BI, Microsoft Purview, Microsoft Foundry, Power Platform, Teams và Copilot. Không nên xem Genie, Genie Ontology và Unity AI Gateway là các sản phẩm có thể thay thế cho nhau.

Microsoft và Databricks cũng đang tăng cường Azure Databricks cho vận hành cốt lõi và lakehouse hợp nhất. Databricks đang áp dụng Azure Cobalt 200, bộ xử lý mà Microsoft cho biết mang lại hiệu năng tốt hơn tới 50% cho các workload agentic và xử lý nhiều dữ liệu, với tính năng mã hóa bộ nhớ được bật mặc định.

Con số hiệu năng đó là tuyên bố của Microsoft, không phải benchmark độc lập trên workload thực tế. Nó không chứng minh được một kết quả chung về độ trễ, chi phí hay thông lượng.

Trong bài công bố trên Microsoft Source, Judson Althoff, CEO mảng Microsoft Commercial Business, đã nêu mục tiêu vận hành như sau:

Thế hệ AI tiếp theo sẽ được định hình bởi mức độ hiệu quả mà tổ chức biến tri thức riêng thành năng lực thông minh.

Câu nói này dẫn tới câu hỏi kỹ thuật quan trọng: tổ chức có thể biến tri thức thành đầu vào có kiểm soát, kiểm thử được cho trợ lý AI hay không?

Phân tích của Van Data Team: ngữ cảnh nghiệp vụ mới là điểm nghẽn

Điểm nghẽn trong production thường không nằm ở việc mô hình có viết trôi chảy hay không; mà ở việc hệ thống xung quanh có cung cấp được bằng chứng nghiệp vụ đúng quyền truy cập, cập nhật và được định nghĩa chính xác hay không.

Ví dụ giả định: Priya, trưởng nhóm nền tảng tài chính, hỏi trợ lý nội bộ về số khách hàng đang hoạt động. Bảng hợp đồng định nghĩa khách hàng đang hoạt động theo trạng thái thương mại, còn model sản phẩm lại định nghĩa theo mức sử dụng gần đây. Cả hai nguồn đều hợp lệ về mặt kỹ thuật. Nếu trợ lý âm thầm chọn một nguồn, một mô hình mạnh hơn có thể đưa ra câu trả lời thuyết phục hơn, nhưng không vì thế mà dễ bảo vệ hơn. Hệ thống nên ánh xạ câu hỏi tới một định nghĩa đã được phê duyệt, hoặc yêu cầu Priya làm rõ.

Vì vậy, ngữ cảnh nghiệp vụ không chỉ là đoạn văn bản được truy xuất lúc trả lời. Nó bao gồm:

• các thuật ngữ, chỉ số, thực thể và mối quan hệ đã được phê duyệt;
• danh tính của người gửi yêu cầu và phạm vi dữ liệu mà danh tính đó được phép truy cập;
• nguồn dữ liệu chuẩn, người phụ trách và phân loại dữ liệu;
• lineage của các bước biến đổi, kiểm tra chất lượng và yêu cầu về độ mới;
• chính sách về bằng chứng, từ chối trả lời, chuyển cấp xử lý và audit;
• các ví dụ tin cậy dùng để đánh giá chất lượng câu trả lời.

Thông tin đã công bố: thông báo mô tả Genie Ontology là lớp giúp grounding agent trên dữ liệu doanh nghiệp. Phân tích của Van Data Team: một lớp ngữ nghĩa hoặc ontology có thể cung cấp cho trợ lý các khái niệm và mối quan hệ đã được phê duyệt, chẳng hạn định nghĩa doanh thu nào được áp dụng hoặc tài khoản liên hệ với khu vực ra sao. Đây là cách diễn giải ở góc độ kiến trúc, không phải tuyên bố về cấu trúc bên trong của Genie Ontology vốn chưa được công bố.

Thông tin đã công bố: Unity AI Gateway quản trị mô hình, agent và chi phí. Khuyến nghị của Van Data Team: đặt một ranh giới quản trị quanh mỗi yêu cầu, nơi có thể áp đặt danh tính, phân quyền, phạm vi nguồn được phép, ghi log, ngân sách, điều kiện đánh giá và quy tắc chuyển cấp xử lý. Không nên hiểu các cơ chế kiểm soát được đề xuất này là tính năng đã được xác nhận của Unity AI Gateway.

Không lớp nào bù đắp được cho một job ingest bị lỗi, một bước biến đổi chưa được kiểm thử, dữ liệu không có người phụ trách hay một bảng đã cũ. Ý nghĩa nghiệp vụ và quản trị chỉ phát huy tác dụng khi dữ liệu bên dưới vẫn đáng tin cậy.

So sánh các kỹ thuật grounding cho AI doanh nghiệp

Không có kỹ thuật grounding đơn lẻ nào tự mình đảm bảo được ý nghĩa nghiệp vụ, kiểm soát quyền truy cập, dữ liệu cập nhật và câu trả lời đáng tin cậy.

Giới hạn của bằng chứng: Thông báo của Microsoft và Databricks không giới thiệu hay mô tả RAG, retrieval-augmented generation, vector search, embedding hoặc cơ sở dữ liệu vector. Các khái niệm này chỉ xuất hiện bên dưới như một phần phân tích của Van Data Team về những kỹ thuật mà doanh nghiệp có thể dùng để grounding cho trợ lý AI.

Các lớp này bổ trợ cho nhau. Một trợ lý tài chính có thể dùng lớp ngữ nghĩa để xác định định nghĩa biên lợi nhuận đã được phê duyệt, dùng bảng có quản trị để tính toán, dùng retrieval để tìm phần diễn giải chính sách và dùng giao diện công cụ để chạy một truy vấn đã được cấp quyền. Vector index có thể giúp tìm tài liệu ứng viên, nhưng độ tương đồng không chứng minh được tài liệu đó còn hiệu lực, được phép truy cập hay chính xác.

Thứ tự thiết kế rất quan trọng. Thiết lập danh tính và nguồn dữ liệu chuẩn trước khi tối ưu retrieval. Định nghĩa ý nghĩa nghiệp vụ trước khi bắt mô hình tự suy luận. Sửa chất lượng pipeline trước khi tinh chỉnh prompt để chữa cháy cho dữ liệu xấu.

Kiến trúc triển khai và mức độ sẵn sàng của ngữ cảnh dữ liệu

Hình minh họa sau tóm tắt các cổng kiểm soát ngữ cảnh trước khi trả lời:

Một trợ lý đáng tin cậy phải đưa mọi yêu cầu qua các cổng danh tính, ngữ nghĩa, tình trạng dữ liệu, bằng chứng và phát hành.

Luồng xử lý yêu cầu cần xác thực người dùng, phân quyền phạm vi dữ liệu, xác định định nghĩa nghiệp vụ đã được phê duyệt, kiểm tra chất lượng và độ mới của nguồn, rồi mới truy vấn hoặc truy xuất ngữ cảnh. Sau khi sinh câu trả lời, hệ thống phải đính kèm bằng chứng nguồn, áp dụng kiểm tra chính sách và chất lượng, quyết định trả lời, từ chối trả lời hay chuyển cấp xử lý, và lưu lại bản ghi audit.

Hãy dùng checklist mức độ sẵn sàng này trước khi phát hành lên production:

Các công cụ kỹ thuật dữ liệu hiện có có thể gắn vào quanh các cổng này như những lựa chọn, không phải một bộ bắt buộc. Một lớp lakehouse hoặc lớp kiểu Delta có thể lưu dữ liệu phân tích có quản trị. Airflow hoặc công cụ điều phối tương đương có thể quản lý các phụ thuộc; dbt hoặc công cụ biến đổi dữ liệu tương đương có thể kiểm thử các model nghiệp vụ; Kafka hoặc hạ tầng streaming tương đương có thể đảm bảo độ mới của dữ liệu theo kiến trúc hướng sự kiện.

Các hệ thống catalog và quản trị có thể theo dõi người phụ trách, phân loại và lineage. Vector index có thể hỗ trợ truy xuất ứng viên theo ngữ nghĩa, trong khi MCP hoặc các giao diện công cụ khác có thể cung cấp các truy vấn và hành động có kiểm soát.

Không công cụ nào kể trên được giới thiệu trong thông báo này. Hãy chọn chúng dựa trên nguồn gốc dữ liệu của quy trình, tần suất thay đổi, bên sử dụng dữ liệu, mức rủi ro và nhu cầu khôi phục.

Các đội muốn có một điểm khởi đầu trong phạm vi rõ ràng có thể xác định phạm vi đánh giá mức độ sẵn sàng của ngữ cảnh dữ liệu cùng Van Data Team. Đầu ra phải cụ thể: bản đồ nguồn và danh tính, backlog về ngữ nghĩa, các khoảng trống về pipeline và mức dịch vụ, thiết kế cổng quản trị, bộ câu trả lời tin cậy, sổ đăng ký rủi ro và kế hoạch triển khai theo từng giai đoạn.

Các kiểu lỗi và đánh giá trong production

Cách nhanh nhất để đánh mất lòng tin là đưa ra một trợ lý nói năng trôi chảy nhưng không giải thích được quyền truy cập, nguồn dữ liệu hay định nghĩa mình dùng.

Các kiểu lỗi phổ biến gồm:

• cấp cho trợ lý quyền truy cập dữ liệu rộng hơn quyền của người dùng đang hỏi;
• truy vấn dữ liệu cũ, trùng lặp hoặc không có người phụ trách;
• chỉ định nghĩa các thuật ngữ nghiệp vụ quan trọng bên trong prompt;
• coi RAG là thứ thay thế cho phân quyền hoặc chất lượng dữ liệu;
• coi độ tương đồng vector là bằng chứng của sự thật;
• ghi log prompt mà không lưu bằng chứng về nguồn, phiên bản ngữ nghĩa và quyết định cấp quyền truy cập;
• chỉ kiểm thử các bản demo thành công thay vì các luồng từ chối trả lời và khôi phục;
• nhầm lẫn giữa Genie, Genie Ontology và Unity AI Gateway;
• khái quát tuyên bố về Azure Cobalt của Microsoft thành một benchmark độc lập.

Đánh giá trong production nên dùng một bộ câu hỏi tin cậy kèm câu trả lời kỳ vọng, bằng chứng được chấp nhận, vai trò người dùng được phép, điều kiện về độ mới và hành vi từ chối trả lời bắt buộc. Theo dõi độ chính xác ngữ nghĩa, tính đúng của bằng chứng, mức tuân thủ chính sách truy cập, số lần cố dùng nguồn cũ, số lần từ chối trả lời, kết quả chuyển cấp xử lý và mức đầy đủ của audit.

Observability trong production cần bao quát độ trễ, lượng token tiêu thụ so với ngân sách token của quy trình, chi phí trên mỗi quy trình, số lần thử lại, định tuyến mô hình, khối lượng review của con người và khả năng khôi phục khi lỗi. Hãy xem các giá trị hay biến động là số đo từ chính workload của tổ chức, không phải cam kết áp dụng cho mọi nơi. Một câu trả lời nhanh hơn không phải là cải tiến nếu nó dùng sai chỉ số hoặc vượt qua ranh giới phân quyền.

Ví dụ giả định: Một trợ lý vận hành nhận câu hỏi về tồn kho ngay sau khi bước kiểm tra độ mới của nguồn dữ liệu thất bại. Cách an toàn là gắn nhãn nguồn đã cũ, dùng phương án dự phòng đã được phê duyệt nếu có, hoặc từ chối trả lời và thông báo cho người phụ trách dữ liệu. Tự đưa ra một con số tồn kho nghe có vẻ hợp lý sẽ che giấu sự cố thực sự.

Ngân sách vận hành

Quan hệ hợp tác mở rộng giữa Microsoft và Databricks đặt quản trị chi phí bên cạnh quản trị mô hình và agent: hai bên cho biết Unity AI Gateway quản trị mô hình, agent và chi phí. Tính năng được công bố đó là một điểm kiểm soát, không phải bằng chứng cho thấy một quy trình sẽ hiệu quả về kinh tế khi chạy trên production.

Phân tích của Van Data Team: giá token của nhà cung cấp chỉ là đầu vào ban đầu. Trước khi triển khai, hãy chạy từng phương án ứng viên trên cùng một quy trình có phạm vi giới hạn, có kiểm soát danh tính, với cùng bộ đánh giá tin cậy, rồi chấm điểm:

• Chi phí cho mỗi đầu ra được chấp nhận: tổng chi phí mô hình, nền tảng, thử lại, người review và khôi phục cho mỗi kết quả được duyệt.
• Ngân sách độ trễ và token: thời gian phản hồi end-to-end và số token tiêu thụ trong mức trần đã được phê duyệt.
• Tỷ lệ thử lại và số phút review: tần suất hệ thống tự động phải làm lại và lượng thời gian con người cần bỏ ra để duyệt.
• Khôi phục khi lỗi: thời gian, công sức và khả năng audit cần có để chẩn đoán, khoanh vùng và chạy lại một trường hợp lỗi.
• Kết quả đánh giá: độ chính xác so với bộ câu trả lời tin cậy, việc dùng đúng nguồn, tuân thủ phân quyền và việc từ chối trả lời đúng lúc.

Tính chi phí trên mỗi kết quả quy trình được duyệt bằng tổng chi phí vận hành chia cho số đầu ra được duyệt. Một phương án rẻ trên mỗi lần gọi vẫn có thể đắt nếu nó tạo ra câu trả lời bị từ chối, chuyển cấp xử lý chậm hoặc phải dọn dẹp thủ công. Hãy chấm lại bảng điểm mỗi khi mô hình, prompt, công cụ, pipeline dữ liệu hoặc định nghĩa trong Genie Ontology thay đổi.

Kết luận: Xây dựng ngữ cảnh trước khi mở rộng trợ lý

Quan hệ hợp tác Microsoft Databricks quan trọng vì nó đặt ngữ cảnh nghiệp vụ, quản trị, tích hợp quy trình làm việc và hạ tầng dữ liệu vào cùng một định hướng AI doanh nghiệp. Thông báo này không phải là màn ra mắt RAG hay cơ sở dữ liệu vector. Các cơ chế được nêu tên gồm Unity AI Gateway, Genie Ontology, các tích hợp Genie, Azure Databricks và hạ tầng Azure Cobalt.

Với các đội dữ liệu, bước tiếp theo mang tính vận hành: chọn một quy trình có phạm vi giới hạn, định nghĩa ý nghĩa nghiệp vụ đã được phê duyệt, giới hạn nguồn theo danh tính, đảm bảo pipeline luôn khỏe, lưu lại bằng chứng và đánh giá câu trả lời dựa trên một bộ dữ liệu tin cậy. Việc chọn mô hình chỉ đến sau khi các nền tảng này đã rõ ràng.

Nếu bạn cần chuyển từ thảo luận kiến trúc sang một phạm vi triển khai có trách nhiệm rõ ràng, hãy làm việc với Van Data Team để xây dựng kế hoạch triển khai trong phạm vi giới hạn, bao gồm bản đồ nguồn, cổng quản trị, thiết kế đánh giá, runbook xử lý lỗi và lộ trình xây dựng theo từng giai đoạn. AI doanh nghiệp đáng tin cậy được xây dựng từ ngữ cảnh có kiểm soát, không phải từ những bản demo bóng bẩy.