• NetApp công bố ý định mua PEAK:AIO ngày 25/09/2026, chưa công bố giá
• Kiến trúc đích: metadata tách khỏi data, scale độc lập với nhau
• Nhắm hỗ trợ hàng nghìn tỷ file, môi trường exabyte, workload song song cao
• Công nghệ PEAK:AIO xuất phát từ hợp tác với Los Alamos và Carnegie Mellon
• Sẽ gắn vào ONTAP, giữ đường nâng cấp cho khách ONTAP hiện tại

Câu chuyện thực ở đây không phải một thương vụ M&A nữa, mà là một thừa nhận về kiến trúc. Hầu hết hệ file doanh nghiệp được thiết kế cho hàng triệu file, không phải hàng nghìn tỷ. Khi bạn đổ một corpus huấn luyện vào đó, throughput đọc có thể vẫn đẹp nhưng thao tác liệt kê, stat, mở file bắt đầu làm GPU ngồi chơi. Đó là lúc metadata thành cổ chai. Theo mình, điều này nghĩa là gì với doanh nghiệp Việt: nếu bạn đang báo giá storage cho một dự án AI, con số IOPS và GB mỗi giây chưa đủ để kết luận gì. Hãy hỏi thêm hệ này chịu được bao nhiêu file trong một namespace, và khi vượt số đó thì độ trễ metadata tăng theo đường nào. Điều thực dụng hơn: với đa số team ở Việt Nam, quy mô dữ liệu chưa tới ngưỡng đó, nên đừng mua kiến trúc exabyte cho bài toán terabyte.

• Snowpipe Streaming ghi vào bảng Iceberg đã partition lên GA ngày 24/09/2026
• CHECK constraint trên hybrid table lên GA, kiểm ràng buộc ngay tại cột
• Dynamic table incremental refresh nay nhận mệnh đề VALUES
• Code Bundles vào preview, đóng gói code để triển khai và chia sẻ
• Ba ngày trước đó Snowflake mở Container Runtime cho Streamlit app ở preview

Đây là loại tin dễ bị bỏ qua nhưng lại ăn thực vào chi phí vận hành. Mô hình phổ biến lâu nay: stream đổ vào một bảng staging không partition, rồi một job định kỳ đọc lên, phân vùng lại, ghi xuống bảng chính. Job đó vừa tốn compute, vừa tạo độ trễ, và là nơi sinh ra bài toán small file kinh điển. Ghi trực tiếp vào bảng đã partition cắt bỏ cả ba thứ đó cùng lúc. Nhưng cẩn thận một điểm: ghi trực tiếp vào partition không tự động giải quyết small file, nó chỉ chuyển vấn đề sang tầng compaction. Theo mình, điểm cần nhớ cho team Việt Nam đang chạy CDC hoặc event vào lakehouse: hãy đo lại số file sinh ra trên mỗi partition mỗi giờ sau khi đổi, rồi đặt lịch compaction theo số đó, đừng đặt theo cảm giác.

• DataEnclave nằm trong VAST DataEngine, dùng NVIDIA Confidential Computing
• Tạo vùng cô lập trải qua CPU và GPU để giải mã và xử lý tại chỗ
• Cryptographic attestation kiểm môi trường trước khi nhả khóa
• Doanh nghiệp giữ khóa dữ liệu, bên cung cấp AI giữ khóa model, tách biệt
• Triển khai được trong data center riêng, cloud tin cậy, môi trường sovereign hoặc air-gapped
• Preview từ 24/09, dự kiến GA quý một 2027

Điểm kỹ thuật đáng chú ý là khoảng trống mà confidential computing nhắm vào. Doanh nghiệp nào cũng đã mã hoá dữ liệu lúc nằm yên và lúc truyền, nhưng đến lúc tính toán thì dữ liệu phải ở dạng rõ trong bộ nhớ. Đó chính là chỗ mọi cam kết bảo mật dừng lại, và cũng là lý do phòng pháp chế của ngân hàng hay bệnh viện nói không với mọi đề xuất AI dùng dữ liệu thật. Theo mình, cái đáng học từ tin này không phải tên sản phẩm mà là cách đặt vấn đề: thay vì hỏi làm sao đưa dữ liệu lên AI an toàn, hãy hỏi làm sao đưa AI xuống chỗ dữ liệu. Trong tư vấn, đa số bế tắc mình gặp ở doanh nghiệp Việt là bài toán này, không phải bài toán độ chính xác model. Nhưng cũng đừng vội: preview với GA cách nhau hơn một quý, và confidential computing đòi phần cứng GPU đời mới.

• Iceberg 1.12.0 RC0 trượt vì stylesheet Bootstrap và file Lottie thiếu ghi chú MIT
• RC1 mở ngày 22/09, vẫn có một phiếu chống không ràng buộc vì Caffeine thiếu mục LICENSE trong bundle GCP
• Polaris 1.8.0 RC0 mở 17/09 trượt vì thiếu NOTICE cho Kite và Orekit, RC1 trượt vì file test mang header license của Dremio
• Parquet mở review Modular Footer nhằm tăng hiệu năng trên bảng rất nhiều cột
• Kiểu logic VECTOR được đề xuất dựa trên LIST, đang tranh luận có nên nhét ràng buộc độ dài vào đặc tả hay không
• Đặc tả materialized view của Iceberg đã có POC trên Spark và Trino, chốt thảo luận 01/10
• Kiểu FILE nối ba dự án: Parquet 2.14 ship FILE, Arrow định nghĩa arrow.parquet.file, Iceberg thiết kế uỷ quyền qua REST catalog
• Iceberg C++ 0.4.0 RC0 pass với 174 commit kể từ 0.3.0, có hỗ trợ kiểu V3

Hai chuyện rất khác nhau đang diễn ra cùng tuần. Chuyện thứ nhất là thủ tục: bốn vòng bỏ phiếu trượt liên tiếp đều không phải vì bug, mà vì thiếu một dòng trong LICENSE hoặc NOTICE. Nghe như chuyện giấy tờ, nhưng đó chính là thứ khiến một bản Apache dám đem vào doanh nghiệp có phòng pháp chế. Chuyện thứ hai quan trọng hơn nhiều: Parquet đang bàn kiểu VECTOR và kiểu FILE ngay trong đặc tả. Nghĩa là gì? Nghĩa là embedding và file phi cấu trúc đang được chuẩn bị để sống ngay cạnh cột số và cột chuỗi trong cùng một bảng, với catalog giữ quyền đọc. Đọc theo góc nhìn người làm RAG: nếu điều đó thành hình, kiến trúc hai kho song song mà chúng ta đang dùng, một lakehouse cho bảng và một vector database riêng, sẽ bị đặt câu hỏi.

• Nhận câu hỏi tiếng tự nhiên, trả về kế hoạch thực thi có operator được sinh tại chỗ
• Quy trình ba bước: trích hành động nguyên tử, lập hợp đồng đầu vào đầu ra, rồi gom nhóm và sinh hàm
• Cắt 58,8% chi phí thực thi trung bình trên SemBench so với hệ tốt thứ hai
• Chạy trong hệ quản trị dữ liệu đa phương thức KathDB
• Chất lượng kết quả tương đương hoặc tốt hơn các hệ so sánh

Ý tưởng ở đây đáng suy nghĩ hơn con số. Hầu hết hệ text-to-SQL coi SQL là đích đến, nên mọi tính toán phải diễn đạt được bằng SQL. Với câu hỏi đa phương thức, kiểu như tìm hợp đồng có điều khoản giống nhau rồi đối chiếu với số liệu bán hàng, SQL thuần bắt đầu khổ. KathDB-FAO chọn hướng ngược: vẫn giữ bộ khung kế hoạch truy vấn, nhưng cho phép thân mỗi operator là code sinh ra theo đúng câu hỏi. Nhờ có hợp đồng đầu vào đầu ra, code sinh ra vẫn kiểm tra được, không phải một khối hộp đen. Điều này nghĩa là gì với người làm nghề: nếu bạn đang dựng một agent phân tích dữ liệu và thấy nó cứ viết SQL dài dằng dặc rồi sai, vấn đề có thể không ở prompt mà ở chỗ bạn bắt nó diễn đạt mọi thứ bằng một ngôn ngữ duy nhất. Tách thành các bước nhỏ có kiểm tra thường rẻ và đáng tin hơn.

• Chuyển join không gian 3D thành phép ray tracing để dùng RT core của GPU
• Bắn tia theo cạnh một mắt lưới vào cây phân cấp dựng trên mắt lưới kia
• Tầng trên kiểm tia với node để loại sớm, tầng lá kiểm tia với tam giác
• Nhắm thay cách làm filter-and-refine với các phép so cặp tam giác
• Ứng dụng: digital twin, quy hoạch đô thị, sinh học tính toán

Bài này khó đụng tới công việc hàng ngày của phần lớn người làm BI, nhưng đáng đọc vì cách tư duy. Câu hỏi gốc rất đơn giản: hai khối hình ba chiều này có cắt nhau không. Cách làm truyền thống là so từng cặp mặt tam giác, mà một mắt lưới có hàng nghìn mặt thì số phép so tăng theo bình phương. GPU game lại có sẵn một khối phần cứng được thiết kế đúng cho câu hỏi tia này có chạm tam giác nào không, và nó nhanh hơn nhiều lần code tự viết. Việc cần làm chỉ là dịch bài toán sang đúng ngôn ngữ của khối phần cứng đó. Theo mình, bài học chuyển được: khi một truy vấn của bạn chậm, trước khi mua thêm node hãy hỏi nó có thể viết lại thành một bài toán khác mà phần cứng hay engine đã làm sẵn rất tốt hay không. Đó là cách tăng hiệu năng không tính tiền theo giờ.

• system.query.history lên GA ngày 21/09/2026
• Ghi trạng thái thực thi, thời gian và nguồn gốc truy vấn ở phạm vi toàn account
• Bao phủ cả SQL warehouse và serverless compute
• Cùng ngày: credential dịch vụ model provider dùng được secret của Unity Catalog, xoay khóa không phải sửa dịch vụ

Đây là loại tính năng không ai làm demo nhưng ai vận hành thật đều cần. Chi phí lakehouse tăng không phải vì một truy vấn khổng lồ, mà vì vài trăm truy vấn nhỏ chạy mỗi năm phút từ một dashboard ai đó quên tắt. Nếu không có bảng lịch sử truy vấn ở phạm vi toàn account, bạn sẽ đi đoán theo từng workspace và luôn thiếu mảnh ghép. Khuyến nghị cụ thể của mình cho team đang chạy Databricks: dựng một báo cáo đổ theo ba trục là nguồn gốc truy vấn, thời lượng, và số lần chạy trong ngày, rồi xếp theo tổng thời lượng. Gần như lần nào mình làm việc này với khách hàng, ba dòng đầu tiên đều là thứ không ai đoán ra trước. Còn việc credential dùng secret của Unity Catalog là chi tiết nhỏ nhưng đúng nguyên tắc: khóa nên nằm ở một chỗ có phân quyền và xoay được, không nằm rải trong cấu hình từng dịch vụ.

• Genie One MCP server lên GA ngày 25/09/2026, Genie thành tool hội thoại qua MCP
• Bất kỳ MCP client hay agent nào cũng neo được câu hỏi dữ liệu vào nền có quản trị
• Tag có quản trị và tag thường lên GA cho dashboard, notebook, Databricks app và Genie Agent
• Genie Code dựng pipeline xử lý tài liệu: parse, phân loại, trích xuất, kiểm tra trên PDF, hợp đồng, hoá đơn
• Pipeline có bước đánh giá chất lượng kèm theo
• Một ngày trước đó, chia sẻ metric view qua OpenSharing lên GA, truy vấn bằng MEASURE trên serverless

Nếu chỉ chọn một tin Databricks trong tuần để hiểu họ đang đi đâu, mình chọn tin này. Bản chất của Genie là một semantic layer có hội thoại: bạn định nghĩa bảng nào, chỉ số nào, ai được xem, rồi Genie trả lời câu hỏi trong khuôn đó. Đưa nó ra thành MCP server nghĩa là cái khuôn đó giờ có một địa chỉ mà mọi agent bên ngoài gọi được. Đây là khác biệt lớn so với cách làm phổ biến hiện nay, tức là cho agent một connection string rồi để nó tự viết SQL. Cách sau nhanh trong demo và vỡ trong production, vì không ai kiểm được agent hiểu doanh thu theo nghĩa nào. Mình đang học và làm thực hành RAG trên nền Databricks nên nói thẳng chỗ mạnh của họ: gộp data và AI về một nền, quản trị một chỗ, đó là điểm khác biệt thật, không phải khẩu hiệu. Nhưng cũng nói thẳng chỗ khó: Genie chỉ tốt bằng semantic model bạn khai.

• Ba sản phẩm công bố ngày 24/09/2026: Maestro, Live Map, Guardian Agents với Agent Contracts
• Maestro dựng trên Knowledge Graph của Collibra, có Maestro Studio để cấu hình agent và Maestro Assistant làm giao diện chat
• Người dùng đặt được persona, quyền, và danh sách tool cho agent, neo vào nguồn tri thức đã chứng thực
• Live Map đến từ Deasy Labs by Collibra, dựng context graph cho tài liệu phi cấu trúc
• Guardian Agents và Agent Contracts quản cả agent xây ngoài Collibra
• Báo cáo Harris Poll công bố 16/09: 76% người ra quyết định gặp rào cản khi đưa agent vào production
• 87% nói team phải thường xuyên kiểm lại xem context agent đang dùng còn đúng hay không

Con số 87% đáng dừng lại lâu hơn cái tên sản phẩm. Nó nói rằng gần chín trên mười team phải liên tục đi kiểm xem context mà agent đang dùng còn đúng hay không. Đây chính là chi phí ẩn của việc dựng agent trên nền dữ liệu không ổn định: bạn không trả tiền một lần lúc build, bạn trả hàng tháng bằng thời gian người thật đi xác minh. Theo mình, cách đọc đúng của tin này với doanh nghiệp Việt: trước khi mua bất kỳ công cụ governance cho AI, hãy trả lời được một câu đơn giản là doanh thu trong công ty bạn có mấy định nghĩa. Nếu câu trả lời là hơn một, thì vấn đề chưa phải công cụ. Nhưng phần Agent Contracts thì đáng học kể cả khi bạn không mua gì: ý tưởng là mỗi agent phải khai trước nó dùng dữ liệu nào, được làm gì, và ai chịu trách nhiệm.

• Cobuild ra mắt tháng 6/2026, bản mở rộng công bố 24/09 tại hội nghị Succeed
• Cobuild Insights: hỏi bằng lời thường, nhận câu trả lời chất lượng analyst trên dữ liệu đã quản trị
• Dataiku Headless: điều khiển nền tảng từ trong coding agent, dựng pipeline, model, dashboard, agent
• Migrate được workbook Excel hoặc workflow Alteryx cũ thành project có thể kiểm tra và có quản trị
• Agent Management nhận Cobuild, gợi ý chỉ số giá trị kinh doanh và xử lý cảnh báo rủi ro
• AI Catalog phổ quát gồm dataset, model, agent và semantic model đã kiểm duyệt

Phần Dataiku Headless là chi tiết mình thấy thú vị nhất, vì nó đảo chiều quan hệ giữa nền tảng và công cụ. Lâu nay nền tảng data là nơi bạn phải vào để làm việc. Headless biến nó thành một dịch vụ mà coding agent gọi từ bên ngoài. Hệ quả thực tế: công việc trước đây sống trong terminal của một người giờ thành thứ cả công ty xem lại và chạy lại được. Câu đáng chú ý của chính CTO Dataiku là team kỹ thuật và team nghiệp vụ đang chạy trên hai nền tảng khác nhau, không chung dữ liệu và không chung rào chắn, và khoảng cách đó chịu được khi mới vài pilot nhưng thành gánh nặng khi lên quy mô. Theo mình, đây là mô tả chính xác tình trạng ở khá nhiều doanh nghiệp Việt. Nhưng cần nói rõ: migrate một workbook Excel thành project có quản trị không tự động làm logic trong đó đúng. Nó chỉ làm logic đó nhìn thấy được.

• Python UDF scalar và batch của Unity Catalog lên GA ngày 23/09/2026
• Bỏ giới hạn năm lần gọi, hỗ trợ named handler, khớp timestamp với PySpark
• Cho cài dependency riêng và đọc credential cùng secret của Unity Catalog
• Scala UDF cũng đọc được secret, cả loại session-scoped và loại của Unity Catalog
• Truy vấn time travel áp row filter và column mask theo ABAC ở beta, cần Databricks Runtime 19 trở lên
• Genie App Builder vào beta: dựng app từ prompt trong App Spaces, có quản trị và zero-idle scaling
• DeepSeek V4 Pro bản 0813 sẽ ngừng hoạt động ngày 30/10/2026

Trong ba món này, món ít gây chú ý nhất lại là món đáng nhắc nhất trong cuộc họp bảo mật. Time travel là tính năng ai dùng Delta hay Iceberg cũng thích, vì nó cho đọc lại trạng thái bảng ở một thời điểm cũ. Nhưng nếu row filter và column mask chỉ áp cho truy vấn hiện tại, thì một câu truy vấn với mệnh đề VERSION AS OF trở thành đường vòng để xem dữ liệu mà bạn vừa cấm người ta xem. Khá nhiều đội mình gặp chưa từng nghĩ tới chuyện này khi thiết kế phân quyền. Điều nên làm ngay, kể cả trên nền tảng khác: đi kiểm xem chính sách masking của bạn có áp cho truy vấn lịch sử hay không, và nếu không thì ai đang có quyền chạy truy vấn lịch sử.

• CLI tên ug ra ngày 22/09/2026, gom xác thực, cấu hình, MCP server, skill và theo dõi chi tiêu
• Tổ chức cấu hình tập trung model, MCP server, skill, harness mặc định và Smart Routing
• Unified tracing ghi cả hoạt động coding agent, hiển thị tool và skill cạnh các lượt gọi model
• Cùng ngày: connector Shopify vào beta, lấy sản phẩm, đơn, khách, tồn kho, fulfillment, khuyến mãi
• Lakebase backup schedule API vào beta, đặt nhịp snapshot ngày, tuần, tháng và thời hạn giữ
• Mời người nhận OpenSharing qua email vào beta, hết phải trao đổi file credential
• Ba model mới lên Unity Gateway: GPT-6 Sol, GPT-6 Luna của OpenAI và Opus 5.5 của Anthropic

Đọc dưới góc nhìn kỹ thuật của một người làm nghề, đây là tin có tính bước ngoặt hơn cả mấy cái GA to đùng khác trong tuần. Hiện trạng ở gần như mọi công ty: mỗi lập trình viên tự cắm coding agent của mình, tự cắm MCP server, tự chọn model, và không ai biết tổng cộng đang tiêu bao nhiêu hay agent đang chạm vào dữ liệu nào. Đó là một vùng mù rất lớn, và nó nằm ngay cạnh source code cùng database production. Việc kéo coding agent vào chung một gateway có xác thực, có tracing, có hạn mức chi là việc sớm muộn phải làm. Điểm mình thấy đúng nhất là ghi tool và skill cạnh các lượt gọi model trong tracing: nếu chỉ log lượt gọi model thì bạn biết tốn tiền, nhưng phải log tool mới biết agent đã làm gì. Khuyến nghị thực tế: nếu công ty bạn chưa dùng Databricks, bài học vẫn dùng được.

• Cortex AI Function Evaluation vào public preview ngày 21/09/2026, dùng để đo chất lượng
• Cortex AI Function Optimization vào public preview, nhằm triển khai AI hiệu quả hơn
• Cortex Agents Compact API vào preview, tinh giản lượt tương tác với agent
• Ngày 23/09: Container Runtime cho Streamlit app trong Native App vào preview
• Ngày 23/09: báo cáo tình trạng bảo mật tài khoản trong Trust Center vào preview

Tính năng đánh giá thường bị coi là phần phụ, nhưng thực tế nó quyết định dự án AI sống hay chết. Vòng đời điển hình mình thấy ở doanh nghiệp: dựng một hàm tóm tắt hay phân loại bằng model, demo rất hay, đưa vào chạy, rồi ba tháng sau không ai biết nó còn đúng bao nhiêu phần trăm vì chưa từng có bộ đo. Khi chất lượng tụt, không ai chứng minh được là tụt, nên cũng không ai dám sửa. Có khung đánh giá ngay trong nền tảng giải quyết chuyện hậu cần: bộ dữ liệu đánh giá nằm cùng chỗ với dữ liệu sản xuất, chạy lại được theo lịch, và kết quả có thể đưa vào dashboard như mọi chỉ số khác. Theo mình, điều nên làm không đợi tính năng nào lên GA: chọn ba mươi tới năm mươi trường hợp có đáp án đúng do người xác nhận, chạy lại mỗi lần đổi prompt hoặc đổi model, và ghi kết quả vào một bảng.

• DataBuddy ra mắt 25/09/2026, là sản phẩm trợ lý thứ ba của Tencent Cloud sau CodeBuddy và WorkBuddy
• Bốn nhóm agent: Data Engineering có tự chữa lỗi, Data Governance soát metadata, lineage, chất lượng, bảo mật
• Data Analytics trả lời hội thoại kèm phân tích nguyên nhân gốc, Data Science giảm triển khai model từ 30 ngày còn 7 ngày
• Unity Semantics đạt 95,9% độ chính xác phân tích so với 83,5% của NL2SQL thuần
• Agent Runtime lo quản trị, khả năng kiểm toán và kiểm soát dữ liệu cho agent
• OneOps gộp DataOps, MLOps và AIOps vào một nền, hãng nói đạt hiệu quả gấp 5 tới 10 lần
• Đã có ở Trung Quốc, Thái Lan, Hàn Quốc, Indonesia, đang mở sang châu Âu và châu Mỹ
• Nối được OLAP engine sẵn có mà không phải di chuyển dữ liệu

Cặp số 95,9% và 83,5% là thứ mình sẽ mang đi dùng lại trong tư vấn. Nó lượng hoá đúng cái điều mà mọi người làm BI đều linh cảm nhưng khó chứng minh: khoảng cách giữa hỏi thẳng model và hỏi qua một lớp nghĩa đã định là khoảng mười hai điểm phần trăm. Mười hai điểm nghe nhỏ, nhưng dịch sang thực tế là cứ sáu câu trả lời thì thêm gần một câu đúng, và trong báo cáo tài chính thì một câu sai đủ để mất niềm tin cả hệ thống. Theo mình, bài học rút ra không phụ thuộc bạn dùng nền tảng nào: đầu tư vào semantic model, định nghĩa chỉ số, quan hệ bảng và quy tắc nghiệp vụ là đầu tư có lãi cao nhất khi làm AI trên dữ liệu. Nó rẻ hơn đổi model và bền hơn sửa prompt. Một điểm cần cân nhắc: các con số này do hãng tự công bố, chưa có bên thứ ba đo lại, nên đừng đem nguyên vào slide như sự thật đã kiểm chứng.

• Paper2Agent đọc bài báo, tìm ra công cụ, code và tài liệu mà nhóm nghiên cứu đã công bố
• Một agent khác viết và kiểm thử code cần thiết để agent bài báo dùng được các công cụ đó
• Agent sau đó chạy lại phân tích gốc và áp phương pháp cho câu hỏi mới
• So sánh với agent đa dụng có cùng quyền truy cập công cụ: agent chuyên biệt làm tốt hơn
• Nhóm nghiên cứu còn thử cho các agent sinh từ những nghiên cứu khác nhau làm việc cùng nhau

Kết luận phụ của nghiên cứu này mới là phần đáng mang về áp dụng: cho một model quyền truy cập tới công cụ không bằng dựng một agent chuyên biệt quanh công cụ đó. Nghe hiển nhiên nhưng nó phản bác đúng cách làm phổ biến hiện nay, tức là cắm một đống MCP server vào một agent chung rồi hy vọng nó tự biết dùng cái nào cho việc gì. Thực tế agent chung phải đoán, và đoán nhiều thì sai nhiều. Trong khi agent chuyên biệt có ngữ cảnh hẹp, biết trước tool này dùng cho bài toán nào và tham số nào là hợp lý. Điều này nghĩa là gì với người đang dựng hệ thống nội bộ: đừng cố làm một siêu agent biết tất cả. Chia theo nghiệp vụ, mỗi agent một phạm vi hẹp có tài liệu và có ví dụ, rồi cho chúng gọi nhau khi cần. Cách này khó hơn lúc thiết kế nhưng dễ hơn nhiều lúc gỡ lỗi, vì khi sai bạn biết sai ở agent nào.

• Vấn đề: thông tin từ nguồn có hạn chế truy cập bị lưu vào bộ nhớ agent rồi tái dùng dưới người dùng khác
• Hệ quả là hạn chế của nguồn gốc bị vượt qua, dẫn tới rò rỉ thông tin
• Đề xuất khái niệm Governed Enterprise Memory, gộp tích hợp nguồn, quản trị bộ nhớ và liên tục phân quyền
• AkasicMEM hiện thực hoá bằng lineage bắc cầu, ghép chính sách lúc tạo bộ nhớ
• Đánh giá lại chính sách ngay lúc truy hồi, không chỉ lúc ghi

Hãy hình dung một tình huống rất thật. Một agent hỗ trợ phòng nhân sự đọc bảng lương, tóm tắt vài nhận định, lưu vào bộ nhớ dài hạn để lần sau khỏi đọc lại. Ba tuần sau, một người ở phòng khác dùng cùng agent đó, hỏi một câu liên quan, và agent lôi cái nhận định cũ ra trả lời. Không ai truy cập trái phép bảng lương, nhưng thông tin từ bảng lương đã đi ra ngoài phạm vi cho phép. Đó chính xác là điều bài báo gọi là mất tính liên tục của phân quyền, và nó không phải chuyện lý thuyết. Theo mình, điều cần làm ngay cho bất kỳ ai đang dựng agent có bộ nhớ ở doanh nghiệp: mỗi mảnh bộ nhớ phải ghi kèm nó sinh ra từ nguồn nào, và lúc truy hồi phải kiểm lại quyền của người đang hỏi với nguồn đó, không chỉ kiểm quyền lúc ghi.

• Bài toán: các bảng liên quan về nghĩa nhưng thiếu cột tường minh để join
• Văn bản phi cấu trúc là bằng chứng nối hai bảng rời rạc lại với nhau
• Đặt tên bài toán là Text-Mediated Join Path Discovery
• LOKI dùng kiến trúc cross-attention hai chiều học biểu diễn dòng bảng và câu văn
• Học được liên kết dòng với câu ở mức chi tiết mà không cần gán nhãn cục bộ
• Xuất ra đường join tường minh, gom theo nhóm nhất quán, sinh bảng đã tích hợp có provenance tới từng câu

Đây là bài mình thấy gần nghề nhất trong cả tuần. Ai từng nhận một data lake kế thừa đều biết cảnh này: có ba trăm bảng, không có tài liệu, tên cột viết tắt, và người biết rõ nhất đã nghỉ. Thứ duy nhất còn lại thường là tài liệu dạng văn bản, biên bản họp, mô tả quy trình. Con người dùng đúng những tài liệu đó để suy ra quan hệ giữa các bảng. Việc mô hình hoá đúng quá trình đó thành một bài toán học máy là cách tiếp cận hợp lý hơn nhiều so với đi đoán quan hệ chỉ bằng độ giống tên cột, cách mà đa số công cụ discovery hiện nay đang làm và hay sai. Điểm mình đánh giá cao nhất là đầu ra có provenance tới cấp câu, tức là hệ nói được nó suy ra quan hệ này từ câu nào trong tài liệu nào. Không có phần đó thì không ai dám dùng, vì một đề xuất join sai đủ để làm sai cả báo cáo.

• Vấn đề: provenance của việc chia sẻ dữ liệu hiếm khi được lưu giữ
• Kể cả khi có lưu, một bên đơn phương đổi database là dấu vết thành lạc hậu
• Khung yêu cầu mỗi bên giữ một tập con thông tin gắn với từng lần trao đổi
• Có cơ chế để auditor xác minh rằng các bên thực sự đã giữ thông tin đó
• Gộp query witness của database với giao thức proof-of-possession trong mật mã
• Kiểm toán hiệu quả mà không cần nhân bản toàn bộ dữ liệu hay giám sát xâm nhập

Vấn đề bài báo đặt ra rất thực dụng và ít người nói tới. Khi doanh nghiệp bán hoặc mua một tập dữ liệu, hợp đồng thường ghi rất rõ phạm vi sử dụng, nhưng hệ thống thì không ghi gì. Sáu tháng sau, khi thanh tra hỏi tập dữ liệu này đã được chia sẻ với ai và trong điều kiện nào, câu trả lời thường là một email và ký ức của một người. Đó không phải bằng chứng. Điểm thông minh của đề xuất này là không đòi mỗi bên giữ toàn bộ bản sao dữ liệu, vì làm thế vừa tốn vừa tạo thêm rủi ro rò rỉ. Nó chỉ đòi giữ đủ thông tin để chứng minh, rồi dùng mật mã để auditor kiểm mà không phải soi vào dữ liệu. Theo mình, điều nên làm ngay cả khi không dùng khung nào: mỗi lần dữ liệu đi ra khỏi tổ chức, hãy ghi vào một sổ bất biến gồm ai yêu cầu, lấy đúng tập nào, theo điều kiện nào, và vào thời điểm nào. Một bảng append-only là đủ để bắt đầu.

• Chỉ ra ba giới hạn của hệ dữ liệu truyền thống: pipeline do người viết, thiếu hiểu nghĩa, xử lý cứng và thụ động
• Đề xuất chuyển từ thiết kế thủ công sang điều phối tự chủ
• Chuyển từ thao tác theo mặt chữ sang diễn giải theo nghĩa, từ phản ứng sang chủ động
• Sáu thành phần: tổ chức dữ liệu theo nghĩa, toán tử mang nghĩa, điều phối và tối ưu pipeline bằng agent
• Ba thành phần còn lại: tinh chỉnh theo phản hồi, quản lý bộ nhớ, tự thích ứng chủ động
• Dựng hai agent chuyên biệt cho phân tích dữ liệu và cho data science
• Báo cáo cải thiện hiệu năng so với các phương pháp tốt nhất hiện tại trên benchmark thật

Mình đọc bài này như một bản đồ hơn là một sản phẩm. Sáu thành phần nó nêu ra đúng là sáu chỗ mà một hệ dữ liệu có agent thật sự phải có, và đa số hệ đang được bán trên thị trường chỉ có hai hoặc ba. Cụ thể: gần như ai cũng có phần điều phối pipeline bằng agent, nhiều nơi có toán tử mang nghĩa dạng gọi model trong SQL, nhưng phần tổ chức dữ liệu theo nghĩa thì thường chỉ là một catalog chưa ai cập nhật, phần tinh chỉnh theo phản hồi thì gần như không có, và phần tự thích ứng chủ động thì chưa thấy đâu. Theo mình, cách dùng bài này hiệu quả nhất là biến sáu thành phần thành sáu câu hỏi trong buổi demo với nhà cung cấp. Câu hỏi khó nhất và cũng hữu ích nhất là câu về tinh chỉnh theo phản hồi: khi agent làm sai và người dùng sửa, hệ của anh học được gì từ lần sửa đó, hay lần sau vẫn sai y như vậy.

• Chủ đề lên Hacker News ngày 26/09/2026 với 209 điểm và 102 bình luận
• Một dữ kiện từ hệ thống camera đọc biển số dẫn tới bắt giữ sai
• Người bị bắt giam mười ba ngày, hiện đang khởi kiện
• Thảo luận tập trung vào việc một điểm dữ liệu đơn lẻ được dùng như bằng chứng
• Vụ việc xảy ra tại Palm Beach, Florida

Mình đưa tin này vào bản tin dữ liệu, không phải bản tin pháp lý, vì cái lỗi ở đây là lỗi thiết kế hệ thống dữ liệu chứ không phải lỗi của một con người xấu. Hệ thống đọc biển số cho ra một chuỗi ký tự kèm một thời điểm và một vị trí. Nhìn vào thì rất giống một sự thật. Nhưng nó là kết quả của một model nhận dạng có tỷ lệ lỗi, chạy trên ảnh có chất lượng thay đổi, và đầu ra không mang theo độ tin cậy. Khi một đầu ra không mang theo độ tin cậy, mọi người dùng ở phía sau sẽ coi nó là chắc chắn. Đó là quy luật, không phải ngoại lệ.

• Nghiên cứu The Impact of Agentic AI on Network Operations công bố 23/09/2026
• Omdia thực hiện độc lập, khảo sát 1.000 lãnh đạo IT và vận hành mạng
• Tổ chức khảo sát có từ 500 nhân viên trở lên
• Hơn bốn trên năm kỳ vọng đạt mô hình vận hành do AI dẫn trong 12 tháng
• Hơn ba phần tư sẵn sàng trao quyền tự chủ đáng kể cho agentic AI
• Gần một phần tư thoải mái với vận hành hoàn toàn tự trị, không người giám sát
• Mô hình mô tả: người vận hành đặt hướng và rào chắn, agent cảm nhận, suy luận, hành động

Khảo sát này nói về vận hành mạng nhưng bài học chuyển thẳng sang vận hành dữ liệu, vì hai nghề có cùng cấu trúc: hệ thống phức tạp, thay đổi liên tục, và hậu quả của một lệnh sai thì rất đắt. Điều làm mình lo là con số gần một phần tư sẵn sàng bỏ hẳn người giám sát. Đọc cùng với khảo sát tuần trước về việc phần lớn tổ chức bị tắc khi đưa agent lên production, bức tranh rõ dần: nhiều người muốn tự trị nhưng chưa có hạ tầng để biết agent đã làm gì. Theo mình, thứ tự đúng phải ngược lại: có tracing và có sổ ghi trước, rồi mới nới quyền. Đức chỉ chia sẻ dưới góc nhìn kỹ thuật của một người làm Data và AI: trong các hệ thống tự động mình từng dựng, thứ cứu mình không phải model tốt hơn, mà là log đủ chi tiết để ba tuần sau còn dựng lại được chuyện gì đã xảy ra.

• Knowledge graph ngày càng được dùng làm bộ nhớ cho model để hỗ trợ tác vụ hạ nguồn
• Dựng đồ thị bằng tay rất tốn công nên nhiều phương pháp tự động đã ra đời
• Phương pháp cho dữ liệu bán cấu trúc ít được quan tâm hơn phương pháp cho văn bản
• Chưa có benchmark và bộ đánh giá toàn diện cho việc dựng đồ thị từ dữ liệu bán cấu trúc
• Sáu chiều chất lượng: hợp lệ cú pháp, đúng nghĩa, nhất quán, súc tích, đầy đủ, hữu dụng
• Chiều hữu dụng đo bằng khả năng đồ thị trả lời được các câu hỏi năng lực

Chiều đo thứ sáu là chiều mình thích nhất và cũng là chiều hay bị bỏ qua nhất: đồ thị có trả lời được câu hỏi năng lực hay không. Nói dễ hiểu, một knowledge graph có thể rất đẹp về mặt cú pháp, đúng chuẩn RDF, không có mâu thuẫn, nhưng vẫn vô dụng nếu không ai hỏi được nó điều mình cần biết. Mình gặp chuyện này nhiều lần khi làm RAG cho doanh nghiệp: đội dựng xong một đồ thị tri thức rất công phu, rồi phát hiện những câu hỏi thực tế mà người dùng quan tâm lại không đi qua đồ thị đó được. Theo mình, cách tránh rất đơn giản và nên làm trước khi viết dòng code đầu tiên: viết ra hai mươi câu hỏi mà người dùng thật sẽ hỏi, rồi thiết kế đồ thị hoặc schema ngược từ những câu đó. Nghe ngược đời nhưng nó tiết kiệm hàng tháng.

• Số 288 phát hành ngày 21/09/2026
• Bolt chuyển 10 triệu truy vấn Looker mỗi tháng từ Presto sang Databricks
• Tự viết bộ chuyển đổi hiểu cả SQL và template Liquid của Looker, đối chiếu kết quả trên hai hệ, mọi thay đổi đều đảo được
• Một bài lập luận phần lớn doanh nghiệp không cần tính toán phân tán nếu làm đúng xử lý tăng dần
• Một bài đề xuất version control cho chỉ số, quan hệ và quy tắc nghiệp vụ, kèm cổng kiểm trước khi agent chạy truy vấn
• Airbnb dùng nền tảng Chronon làm mới hồ sơ khách theo hành vi đang duyệt mà không làm chậm truy vấn
• Số này còn có kinh nghiệm về backpressure, kiểm tải Kafka, gỡ lỗi DuckDB và tối ưu chi phí cloud

Chi tiết mình đánh giá cao nhất trong cách Bolt làm migration không phải công nghệ mà là kỷ luật: họ đối chiếu kết quả dashboard trên cả hai hệ và giữ mọi thay đổi ở trạng thái đảo được. Đây chính là chỗ hầu hết dự án chuyển engine thất bại. Chuyển SQL sang engine mới thì công cụ làm được, nhưng bảo đảm con số trên dashboard vẫn y như cũ thì phải đo, và phải đo tự động trên hàng nghìn truy vấn chứ không phải xem mắt vài cái. Nếu team bạn đang chuẩn bị đổi warehouse, hạng mục đầu tiên trong kế hoạch nên là bộ đối chiếu kết quả, không phải bộ chuyển đổi cú pháp. Còn bài về câu hỏi bạn có thật sự có big data thì mình thấy đúng tới mức hơi đau. Trong tư vấn, phần lớn bài toán mình gặp ở doanh nghiệp Việt chạy trọn trên một máy nếu thiết kế phần xử lý tăng dần cho đúng.

• Helix Research Workspaces công bố 25/09/2026, dựng trực tiếp trên nền Databricks
• Hơn 550.000 bản ghi GenoSphere cho đối tác nghiên cứu được duyệt
• Mỗi bản ghi gộp dữ liệu Exome+ với trung bình hơn 13 năm hồ sơ y tế điện tử, kèm dữ liệu bảo hiểm y tế và dược
• Có bộ công cụ phân tích gen cho nghiên cứu quy mô lớn
• Có trợ lý viết code hỗ trợ nhà nghiên cứu phát triển và tinh chỉnh mã phân tích
• Workspace theo dự án, có kiểm soát truy cập và theo dõi, thấy được tiến độ và chi phí compute theo thời gian thực

Mô hình Trusted Research Environment là thứ mình nghĩ ngành y tế và ngân hàng Việt Nam nên nghiên cứu kỹ, vì nó giải đúng cái bế tắc quen thuộc. Tình trạng hiện nay: bệnh viện hoặc ngân hàng có dữ liệu quý, nhà nghiên cứu hoặc đối tác muốn dùng, nhưng không ai dám xuất dữ liệu ra ngoài. Kết quả là dữ liệu nằm chết. TRE đảo ngược dòng chảy: dữ liệu không đi đâu, người phân tích vào một môi trường có kiểm soát, làm việc trong đó, và chỉ mang kết quả tổng hợp ra. Phần mình thấy thực tế nhất trong thiết kế của Helix là cho nhà nghiên cứu thấy chi phí compute theo thời gian thực. Nghe như chi tiết kế toán nhưng nó là chi tiết quyết định mô hình có sống được không, vì môi trường dùng chung mà không ai thấy mình đang tiêu bao nhiêu thì hoá đơn sẽ giết dự án trước khi kết quả nghiên cứu ra.

• Accenture công bố đầu tư qua Accenture Ventures ngày 25/09/2026
• Đối tượng nhận vốn là Within, một công ty nền tảng AI
• Mục tiêu công bố là hỗ trợ triển khai AI agent trong doanh nghiệp
• Giá trị khoản đầu tư không được công bố

Tin ngắn nhưng chỉ dấu rõ. Trong hai năm qua, tiền đổ vào lớp model và lớp hạ tầng huấn luyện. Năm nay dòng tiền dịch dần sang lớp triển khai, tức là phần biến một model có sẵn thành một quy trình nghiệp vụ chạy được trong công ty có quy tắc, có người duyệt, có sổ ghi. Theo mình, đó là dịch chuyển hợp lý, vì đúng là chỗ đang tắc thật. Hầu hết doanh nghiệp không thiếu model tốt, họ thiếu cách đưa model vào quy trình mà không phá vỡ kiểm soát. Điểm đáng chú ý với người làm nghề ở Việt Nam: nếu lớp triển khai là chỗ khách hàng trả tiền, thì kỹ năng đáng đầu tư không phải tinh chỉnh model, mà là thiết kế workflow, quản trị dữ liệu, và làm cho người dùng thật chịu đổi cách làm việc. Công nghệ chỉ có giá trị khi chạm được tới lớp nghiệp vụ và lớp con người, phần còn lại là demo.

• Công bố ngày 24/09/2026, PhoenixAI thành đối tác dữ liệu nền tảng của Cloudera
• Engine chạy được trong môi trường private và public cloud của Cloudera
• Hứa truy vấn SQL dưới một giây trên dữ liệu streaming và dữ liệu lịch sử định dạng lakehouse
• Giữ được mức đồng thời cao mà hiệu năng không tụt
• Truy vấn tại chỗ, bỏ được phi chuẩn hoá bắt buộc, tiền tổng hợp phức tạp và pipeline ETL không cần thiết
• Dựng cluster quản lý được bằng vài cú bấm qua Cloudera Anywhere Cloud Marketplace
• Có RBAC chi tiết, ghi kiểm toán theo từng truy vấn, bảo đảm chủ quyền dữ liệu

Cái đáng nhìn ở tin này không phải PhoenixAI mà là chỗ Cloudera đang tự đặt mình: nền tảng dữ liệu hybrid cho doanh nghiệp cần giữ dữ liệu trong biên giới của mình. Đó là thị trường thật và đang lớn, đặc biệt ở khu vực có quy định về chủ quyền dữ liệu, mà Việt Nam nằm trong số đó. Về mặt kỹ thuật, lời hứa truy vấn dưới một giây trên cả streaming và lịch sử là lời hứa hay được nghe, nên đọc nó kèm dấu hỏi: dưới một giây với truy vấn nào, trên bao nhiêu dữ liệu, với bao nhiêu người dùng đồng thời. Đức chỉ chia sẻ dưới góc nhìn kỹ thuật của một người làm BI: điểm đáng quan tâm hơn con số độ trễ là lời hứa bỏ được tiền tổng hợp. Mỗi lớp pre-aggregation bạn thêm vào là thêm một chỗ số liệu có thể lệch so với nguồn, và thêm một việc phải bảo trì.

• Thương vụ hoàn tất ngày 23/09/2026, Progress lấy gần như toàn bộ tài sản và nhân sự
• Theo báo chí, giá mua khoảng 400 triệu đô, kèm hơn 2.400 khách hàng
• Nền tảng AI và dữ liệu của Domo trở thành một phần của Progress
• Pháp nhân còn lại đổi tên thành Huckleberry.ai, Inc.
• Cổ phiếu giao dịch trên Nasdaq Global Market với mã HUCK từ ngày 24/09/2026
• Bảng cân đối không nợ, còn khoảng 221 triệu đô tiền mặt, tương đương khoảng 4,46 đô mỗi cổ phiếu
• Giữ lại hơn 900 triệu đô lỗ chuyển tiếp thuế, phần này không bán cho Progress
• Josh James tiếp tục lãnh đạo công ty cùng hội đồng quản trị hiện tại

Đây là tin quan trọng nhất tuần theo mình, và không phải vì con số. Domo từng là một trong những cái tên được nhắc nhiều nhất khi người ta bàn về BI hiện đại, gọi vốn rất lớn, lên sàn, và bây giờ nền tảng đi vào tay một công ty phần mềm hạ tầng còn pháp nhân cũ thành một cái vỏ có tiền và có lỗ chuyển tiếp thuế. Cách cấu trúc thương vụ nói rất nhiều: bên mua muốn sản phẩm và khách hàng, bên bán giữ lại hơn 900 triệu đô lỗ chuyển tiếp thuế vì đó là thứ có giá trị riêng. Theo mình, bài học cho người làm BI ở Việt Nam có hai phần. Phần thứ nhất, về nghề: lớp công cụ dashboard độc lập đang bị kẹp giữa hai bên, một bên là nền tảng dữ liệu tự làm luôn phần trình bày, một bên là agent hỏi đáp trực tiếp trên semantic layer.

• Công bố ngày 23/09/2026: 350 triệu đô, định giá 3,5 tỷ đô
• Insight Partners và S32 đồng dẫn dắt, nhà đầu tư cũ Addition tham gia đáng kể
• Nhiều nhà đầu tư mới và cũ khác gồm March Capital, Greylock, Lightspeed, GV, Wells Fargo
• Lập luận: thời kỳ dữ liệu 1.0 là gán nhãn đơn giản, giải bằng số lượng người
• Thời kỳ dữ liệu 2.0 đòi tác vụ agentic của chuyên gia, môi trường thử nghiệm và bộ tiêu chí, mất hàng giờ tới hàng ngày để dựng một cái
• Công ty ra từ Stanford AI Lab, nền tảng nghiên cứu gồm hơn 250 bài báo được trích dẫn hơn 25.000 lần
• Ra mắt dịch vụ dữ liệu chuyên gia từ tháng 9/2025, tăng trưởng nhanh kể từ đó
• Tiền dùng để mở rộng năng lực nhà máy dữ liệu, đầu tư vào AI theo ngành dọc, mở sang lĩnh vực và phương thức mới

Phần đáng đọc nhất không phải con số mà là cách họ mô tả sự dịch chuyển. Dữ liệu 1.0 là gán nhãn: cho người xem ảnh và bấm chọn nhãn, bài toán số lượng, giải bằng tuyển thêm người. Dữ liệu 2.0 là dựng môi trường và tiêu chí chấm cho tác vụ phức tạp, và một tác vụ như vậy có khi mất chuyên gia giỏi cả ngày để thiết kế. Đó là công việc nghiên cứu, không phải công việc gia công. Nếu mô tả này đúng, và mình nghĩ nó đúng, thì nó có hệ quả trực tiếp cho thị trường nhân lực khu vực. Việc gán nhãn đơn giản, phần lâu nay nhiều công ty ở Đông Nam Á nhận làm, đang mất giá vì model tự làm được. Phần có giá là thiết kế bài kiểm tra: biết nghiệp vụ đủ sâu để viết ra một tình huống khó, và biết chấm thế nào là đúng.