• Chia sẻ foreign Iceberg table qua OpenSharing chuyển từ preview sang GA
• Foreign schema và foreign table cũng lên GA cùng ngày
• Jobs API one-time run có thêm Standard performance mode
• DeepSeek V4.1 Flash xuất hiện trên Unity Gateway
• Zerobus Ingest ghi vào default storage vào Public Preview ngày 07/09

Điểm đáng chú ý ở đây không phải một tính năng đơn lẻ mà là hướng đi. Databricks đang biến Unity Catalog thành cửa duy nhất để dữ liệu đi ra, kể cả dữ liệu nó không sở hữu. Với đội data doanh nghiệp Việt, cái này gỡ được một nút thắt rất cụ thể: trước đây muốn chia sẻ bảng Iceberg đang nằm ở catalog khác thì hoặc phải copy vào Delta, hoặc phải dựng một job đồng bộ và tự chịu trách nhiệm khi lệch. Giờ chỉ cần khai báo và cấp quyền. Đổi lại, bạn nhận thêm một phụ thuộc: quyền và lineage sống trong Unity Catalog, và việc rời Databricks sau này sẽ đắt hơn. Standard performance mode cho Jobs API one-time run là món nhỏ nhưng tiết kiệm thật, vì phần lớn job chạy một lần là backfill hoặc job ad-hoc, không cần cấu hình hiệu năng cao. Còn Zerobus ghi thẳng vào default storage thì rút bớt một bước cấu hình external location, hợp với đội nhỏ chưa chuẩn hoá vùng lưu trữ.

• Tích hợp Iceberg Rust dời sang repo apache/datafusion-iceberg, DataFusion quản trị
• Parquet format 2.14.0 RC1: FILE logical type, INT96 theo thời gian, encoding ALFP
• Parquet chốt timestamp nanosecond 12 byte FIXED_LEN_BYTE_ARRAY cho trọn dải SQL
• Iceberg 1.12.0 RC0 chờ cắt, Iceberg Rust 0.11.0 RC1 đã qua phiếu
• Arrow ra ArrowMetal 0.1.0, compute kernel GPU cho Apple silicon, không upload dữ liệu
• Apache Ossie thêm đặc tả Relational Query Interface với hàm mở rộng MEASURE()

Tuần này lakehouse mở không chạy đua tính năng, nó chạy đua quản trị. Ba chuyện xảy ra cùng lúc và cùng một lô-gic. Một, DataFusion được giao repo Iceberg riêng vì code tích hợp cần người hiểu sâu DataFusion cầm, chứ không nên trôi vào repo của vendor. Hai, Parquet dành một luồng thảo luận hơn bốn mươi lăm tin nhắn chỉ để chốt luật phiên bản hoá, và luật cuối cùng rất thẳng: file chứa tính năng preview phải đọc được, còn reader thì tuyệt đối không được trả về dữ liệu sai khi gặp tính năng chưa hỗ trợ. Ba, Apache Ossie bắt đầu viết đặc tả cho tầng truy vấn quan hệ với hàm MEASURE(), tức là chuẩn semantic layer đang đi từ định nghĩa metric sang cả cách query nó. Với đội đang chọn nền lakehouse, đọc được tín hiệu này quan trọng hơn đọc bảng so sánh tính năng: một hệ sinh thái siết chuẩn kiểm định và làm rõ ai sở hữu cái gì là hệ sinh thái đáng cược dài hạn. ArrowMetal thì nhỏ nhưng thú vị, vì nó dùng shared-storage memory của chip Apple nên không phải upload xuống GPU rồi tải về, đúng kiểu tối ưu chỉ có khi phần cứng và format đi cùng nhau.

• Ảnh hưởng parquet-java từ 1.12 tới 1.18.0, mức độ moderate
• Cơ chế envelope encryption bọc data key qua KMS, URL KMS lưu trong file
• Reader không dùng application control thì URL do file quyết định
• KmsClient tự cài không kiểm host thì token KMS gửi tới máy của kẻ tấn công
• Parquet-java 1.18.1 tắt URL do file điều khiển theo mặc định, thêm cờ bật lại

Chỉ những ai thực sự dùng envelope encryption của Parquet mới bị, nên đây không phải báo động đỏ toàn ngành. Nhưng nhóm đó lại là nhóm quan tâm bảo mật nhất, nghĩa là lỗ hổng nằm đúng chỗ đau nhất. Điều cần nhớ là lô-gic tấn công: dữ liệu không tin cậy quyết định nơi gửi credential. Trong data lake, file đến từ đối tác, từ upload của người dùng, từ pipeline của đội khác, và gần như không ai coi metadata của file Parquet là input cần kiểm duyệt. Việc nên làm ngay khá gọn. Tra xem bạn có dùng keytools trong parquet-java không, kiểm phiên bản, nâng lên 1.18.1. Nếu chưa nâng được thì ép URL của KMS ở tầng ứng dụng, đừng để file quyết định, và bắt KmsClient tự viết phải kiểm tra host cùng xác thực. Việc không nên làm là bật lại cờ cho phép URL do file điều khiển chỉ vì pipeline cũ đang phụ thuộc nó, rồi hẹn dọn sau. Với engine chạy trên Spark hay Flink có shading, phiên bản parquet thật đang chạy hay khác với phiên bản bạn khai trong pom, nên hãy kiểm bằng dependency tree chứ đừng đoán.

• Mở rộng DBLog của Netflix, nền của Debezium và Flink CDC
• Giải bài toán copy-to-log handoff khi bootstrap hoặc thêm bảng mới
• Watermark xác định thay đổi chồng lấn mỗi lần đọc chunk, log luôn thắng
• Chứng minh kết quả đúng dù mỗi bảng và dải khoá đọc ở thời điểm khác
• Không đòi một snapshot database duy nhất cho toàn bộ quá trình copy

Nghe hàn lâm nhưng cực kỳ thực dụng. Bất kỳ ai từng bootstrap một bảng lớn vào pipeline CDC đang chạy đều biết khoảnh khắc lạnh người khi số liệu downstream lệch mà không biết lệch từ đâu. Bài này trả lời đúng câu hỏi đó ở mức hợp đồng: nếu nguồn và lớp capture thoả các điều kiện nêu ra, thì sau khi copy và reconcile xong, kết quả bảo đảm dựng lại đúng trạng thái nguồn kèm mọi insert, update, delete đã xử lý. Cái tôi thấy giá trị nhất là kết luận không cần snapshot duy nhất. Trong thực tế, giữ một snapshot nhất quán trên toàn database suốt nhiều giờ để copy hàng tỷ dòng là thứ vừa đắt vừa rủi ro, và nhiều đội đã lặng lẽ bỏ yêu cầu đó mà không biết mình có được phép bỏ hay không. Giờ thì biết. Với đội đang tự viết lớp CDC, hoặc đang chỉnh Debezium cho nguồn lạ, danh sách điều kiện trong bài chính là checklist kiểm định nên dán vào thiết kế. Còn đội chỉ dùng công cụ có sẵn thì giá trị là ở chỗ biết đâu là giới hạn hợp đồng, để khi lệch số thì nhìn đúng chỗ thay vì mò.

• Join nhiều-nhiều sinh trung gian lớn hơn input vài bậc độ lớn
• Factorized representation khai thác độc lập có điều kiện giữa các thuộc tính
• Vướng mắc cũ: factorized thì phân cấp, vectorized thì khối phẳng
• FFX dùng packed factorized vector, layout liền mạch thân thiện cache
• Engine pipelined đầu tiên hỗ trợ mọi sơ đồ factorization mà vẫn vectorized
• Đồng tối ưu cả semantic operator bằng cách serialize trung gian thành prompt

Đây là loại nghiên cứu mà người làm data thấy ngay chỗ đau của mình. Câu truy vấn chạy ba tiếng rồi tràn bộ nhớ vì một join nhiều-nhiều nổ ra hàng trăm tỷ dòng trung gian là chuyện xảy ra hàng tuần ở đội nào làm phân tích mạng hoặc chống gian lận. Factorization là hướng giải đã biết từ lâu trong giới nghiên cứu nhưng gần như không vào được engine thương mại, vì mọi engine phân tích hiện đại đều xây quanh vectorized execution và hai mô hình này chửi nhau về layout. Cái FFX làm là dựng lại toán tử để biểu diễn factorized nằm gọn trong vector liền mạch, nhờ đó cache không bị phá. Chi tiết đáng để ý thêm là phần semantic operator: khi câu truy vấn có bước gọi mô hình, giữ trung gian ở dạng factorized rồi serialize thành prompt gọn hơn nghĩa là bạn trả ít token hơn cho cùng một câu trả lời. Chưa có sản phẩm nào để dùng ngay, nhưng nếu bạn đang chọn engine cho workload join nặng, đây là tiêu chí nên hỏi vendor trong vòng hai năm tới.

• Excel Add-in chuyển từ public preview lên GA ngày 10/09/2026
• Pivot table có Live query, dữ liệu cập nhật chứ không phải bản xuất tĩnh
• Đọc được cả bảng Unity Catalog và metric view, không cần viết SQL
• Quyền và kiểm soát truy cập do Unity Catalog thi hành tập trung
• Chạy trên Excel bản web, Windows và macOS
• Pipeline liên tục có maintenance window một giờ cho cập nhật nền tảng

Trong năm món của tuần này, đây là món tôi nghĩ đội data Việt Nam cảm nhận được nhanh nhất. Làm tư vấn Data và BI nhiều năm, tôi thấy vòng lặp quen thuộc thế này: đội data dựng model chuẩn, dựng dashboard đẹp, rồi người dùng nghiệp vụ vẫn bấm Export to Excel vì họ cần cắt lát theo cách dashboard không lường trước. Từ giây đó, con số rời khỏi tầm quản trị và bắt đầu sống đời riêng. Excel Add-in lên GA không sửa văn hoá đó, nó chấp nhận văn hoá đó rồi kéo đường ống về đúng chỗ: người dùng vẫn ở Excel, vẫn pivot, nhưng số lấy từ metric view có định nghĩa duy nhất và quyền do Unity Catalog gác. Cái cần cảnh giác là đừng tưởng nó thay được semantic model. Nếu metric view của bạn định nghĩa lỏng, thì giờ bạn chỉ phát tán định nghĩa lỏng đó nhanh hơn thôi. Việc nên làm trước khi mở cho người dùng là dọn metric view cho gọn và đặt tên theo ngôn ngữ nghiệp vụ, vì cái tên cột trong pane của Excel chính là tài liệu duy nhất mà người dùng đọc. Với team nhỏ chưa có Unity Catalog nề nếp, thứ tự đúng là chuẩn hoá metric view trước, phát add-in sau.

• Iceberg Scan Plan API công khai trong Horizon Catalog ngày 10/09
• Chính sách masking cột và row access áp được cho engine ngoài
• dbt artifact cho continuous integration lên GA
• Openflow deployment thế hệ hai lên GA ngày 08/09, có mặt trên GCP ngày 11/09
• Ngừng cho tạo Openflow gen 1 từ 09/09, khách cũ phải chuyển
• Thêm hoặc bỏ ràng buộc hybrid table online lên GA

Cuộc đua thật giữa các nền lakehouse bây giờ không phải ai đọc Parquet nhanh hơn, mà ai giữ được chính sách quản trị khi dữ liệu bị engine khác đọc. Đó là lý do Scan Plan API quan trọng hơn vẻ ngoài khô khan của nó. Không có nó, bạn mở bảng Iceberg cho Trino đọc là mở luôn cả cột số căn cước mà bạn đã cẩn thận masking bên trong Snowflake. Có nó, catalog trả về kế hoạch quét đã cắt sẵn theo quyền, nên engine ngoài chỉ thấy phần được phép thấy. Việc dbt artifact lên GA cho CI cũng đáng chú ý với đội đang chuẩn hoá quy trình: nó biến kết quả biên dịch dbt thành đầu vào kiểm tra được trong pipeline, thay vì chạy lại toàn bộ rồi nhìn log. Phần khó nhằn là Openflow. Gen 2 lên GA thì vui, nhưng khai tử việc tạo mới gen 1 chỉ một ngày sau đó là thông điệp rõ ràng cho ai đang chạy production trên gen 1: hãy lên kế hoạch chuyển, đừng chờ Snowflake nhắc lần hai. Kinh nghiệm của tôi với các đợt retire kiểu này là phần tốn thời gian không nằm ở việc dựng deployment mới mà ở việc dò lại từng connector và từng credential đã cắm vào bản cũ.

• External secrets trong Unity Catalog vào Beta ngày 09/09
• Nối schema vào AWS Secrets Manager, quyền chỉ đọc
• Connector Celigo lấy audit log từ integrator.io
• Connector Anysphere Organization chụp snapshot thành viên và nhóm mỗi ngày
• Connector Anaplan nhập audit trail và bản ghi tài khoản người dùng

Hai chuyện trong một ngày, và cả hai nói cùng một câu: Databricks đang gom mọi thứ về Unity Catalog. External secrets là món thiết thực. Ai từng audit một workspace cũ đều biết cảm giác tìm ra token production nằm hardcode trong một notebook không ai nhận là của mình. Nối vào AWS Secrets Manager với quyền chỉ đọc giải đúng việc đó: secret vẫn sống ở nơi đội security quản, còn quyền đọc thì nằm cùng mô hình quyền của dữ liệu, nên review quyền chỉ cần xem một chỗ. Lưu ý nó mới Beta, và mới chỉ AWS Secrets Manager, nên đừng vội chuyển hết quy trình sang. Ba connector mới thì nói về một hướng ít ai để ý: cả ba đều kéo audit log và dữ liệu tổ chức, không phải dữ liệu nghiệp vụ. Đó là dấu hiệu khách hàng đang đưa log vận hành của SaaS vào lakehouse để phân tích, thường là cho bài toán tuân thủ, chi phí license và phát hiện hành vi bất thường. Nếu doanh nghiệp bạn đang phải giải trình việc ai truy cập cái gì trên chục SaaS khác nhau, đây là hướng đáng thử trước khi mua thêm một công cụ chuyên dụng.

• Ba kiểu cưỡng chế: thuyết phục, cấu trúc dồn đầu, cơ chế agent không sửa được
• Đối chiếu trực tiếp với GitHub Spec Kit, superpowers, BMAD và GSD
• Consort dùng orchestrator tất định dẫn các role agent riêng biệt
• Hai làn tách bạch: làn thiết kế spec-first và làn build test-driven
• Kết quả xanh phải đạt trên branch database sống, test là bất biến

Tôi để bài này ở mục công cụ chứ không ở mục nghiên cứu, vì nó là thứ đội data nên đọc trước khi thả agent vào repo pipeline của mình. Luận điểm trung tâm rất đáng suy nghĩ: mọi framework đều nói mình bắt agent giữ kỷ luật, nhưng khác nhau ở chỗ kỷ luật đó nằm trong prompt hay nằm trong code. Kỷ luật trong prompt thì mô hình có thể bỏ qua và bạn không biết lúc nào nó bỏ. Kỷ luật trong code thì agent muốn cũng không lách được. Theo tôi, riêng với công việc data, điểm hay nhất của Consort là cái cổng chạy test trên branch database sống. Code pipeline khác code web ở chỗ đúng cú pháp không có nghĩa là đúng dữ liệu: một câu join sai hạt vẫn compile, vẫn chạy, chỉ là nhân đôi doanh thu. Bắt agent phải chứng minh test xanh trên một branch dữ liệu thật là cách duy nhất tôi biết để bắt được loại lỗi đó trước khi nó vào báo cáo. Còn điều nên cân trọng: dựng orchestrator tất định cùng branch database cho mỗi lượt là chi phí hạ tầng thật, đội nhỏ nên bắt đầu bằng việc làm test bất biến và cổng người duyệt trước, chưa cần trọn bộ.

• Nút thắt của LLM công nghiệp là curation, không phải compute
• Corpus petabyte rải trên hàng trăm bảng vật lý, lineage gần như không có
• Wide-table hợp nhất hàng nghìn feature dẫn xuất dưới một schema logic
• Quản lý vòng đời feature khai báo, tự giải dependency và hợp toán tử
• Engine thích ứng định tuyến CPU và GPU, chịu lỗi ở mức UDF
• Khám phá dữ liệu lai: global ID index, đẩy OLAP, materialized view chạy nền

Bài này thú vị vì nó đảo lại một định kiến phổ biến. Người ta hay hình dung đội xây mô hình nền tảng là đội chơi với GPU, nhưng mô tả trong đây nghe y hệt một dự án data warehouse tệ: dữ liệu rải trăm bảng, feature dựng tay, không ai biết một cột được tính từ đâu. Và giải pháp họ chọn cũng là giải pháp của giới data: hợp nhất về logic, tách biệt về vật lý, khai báo thay vì orchestrate tay, có lineage. Nói cách khác, khi AI lên tới quy mô nào đó thì bài toán của nó quay về đúng bài toán data engineering cổ điển. Với người làm data ở Việt Nam, thông điệp rất cụ thể: những thứ bạn đã giỏi, như mô hình hoá, quản lý dependency và lineage, đang trở thành kỹ năng của tầng chuẩn bị dữ liệu cho AI, không bị AI xoá. Chi tiết tôi đánh giá cao nhất là chịu lỗi ở mức UDF. Ai từng backfill feature trên vài trăm terabyte đều biết nỗi đau một UDF hỏng ở phút thứ chín mươi làm mất cả lượt chạy. Đặt biên chịu lỗi ở mức toán tử thay vì mức job là lựa chọn thiết kế của người đã trả giá.

• Hệ quản trị dữ liệu ngữ nghĩa hiểu cấu trúc thư mục của tài liệu
• Bản gốc dùng 11,6 đến 51,9 phần trăm token so với phương pháp tốt nhất
• Vật chất hoá vết retrieval nhiều vòng thành experience edge để dùng lại
• Leo thang thích ứng: trả lời một vòng khi bằng chứng đã đủ
• Bật đủ hai cơ chế thì token còn 5,1 đến 32,5 phần trăm

Con số ở đây đáng nói vì nó đánh vào chỗ mà mọi dự án RAG doanh nghiệp đều mắc: hoá đơn token. Tôi đi triển khai RAG cho doanh nghiệp thì thấy pattern rất đều. Giai đoạn demo ai cũng vui, hỏi gì cũng ra. Giai đoạn đưa vào production thì kế toán gọi điện. Nguyên nhân lớn nhất thường không phải câu trả lời dài, mà là agent phải đi nhiều vòng để tìm bằng chứng và mỗi vòng lại nhồi thêm ngữ cảnh cấu trúc của tài liệu vào prompt. Hai ý tưởng trong bài này giải đúng chỗ đó và đều dễ hiểu. Một, câu hỏi giống nhau thì đừng đi lại đường cũ, hãy lưu vết đường đi rồi dùng lại. Hai, đừng mặc định đi nhiều vòng, chỉ leo thang khi bằng chứng một vòng chưa đủ. Điều nên nhớ là con số 5 phần trăm là biên tốt nhất trên tập dữ liệu của họ, đừng bê nguyên vào slide chào khách. Nhưng hướng thì đúng và có thể áp ngay kể cả không dùng hệ của họ: hãy đo xem bao nhiêu phần trăm câu hỏi của người dùng thực sự cần nhiều vòng, tôi cá là ít hơn bạn nghĩ.

• Join Query Expansion tăng độ phức tạp bằng cách thêm join hợp lệ
• Textual Query Augmentation tạo nhiễu ngôn ngữ có kiểm soát
• Độ chính xác giảm dần khi số join trong truy vấn tăng lên
• Viết tắt nhiều làm giảm độ chính xác tới 17 phần trăm
• Thêm họ chỉ số ở mức thực thi, thay cho Execution Accuracy nhị phân

Con số 17 phần trăm này nên được dán lên tường của mọi đội đang bán giải pháp hỏi đáp dữ liệu bằng tiếng tự nhiên. Vì sao? Vì người dùng thật không viết câu hỏi đầy đủ và trang trọng như tập test. Họ viết DT thay cho doanh thu, KH thay cho khách hàng, T9 thay cho tháng chín. Bài này đo chính xác cái giá của thói quen đó, và đó là một cái giá đủ lớn để một demo thành công biến thành một sản phẩm bị mất tin. Với bối cảnh Việt Nam thì còn nặng hơn, vì viết tắt trong tiếng Việt dày hơn nhiều và còn trộn cả tiếng Anh. Việc nên làm rất cụ thể. Một, đừng đánh giá text-to-SQL bằng benchmark quốc tế rồi đem con số đó đi chào khách, hãy dựng tập test từ chính câu hỏi người dùng của bạn, kèm cả viết tắt. Hai, xây một lớp từ điển đồng nghĩa và viết tắt ở tầng semantic, đừng kỳ vọng mô hình tự đoán. Ba, để ý phát hiện thứ hai của bài: độ chính xác tụt theo số join. Nếu model của bạn cần năm join để trả lời một câu hỏi thường gặp, vấn đề nằm ở mô hình dữ liệu, không nằm ở mô hình ngôn ngữ.

• Trajectory ghi lại tương tác của agent với mô hình, tool và môi trường
• Dùng cho trích xuất memory, fine-tune, tối ưu runtime, giám sát chi phí
• Hiện rải rác trong file, database và hệ observability, không hệ nào chuyên
• Ba đặc tính khó: cấu trúc phân cấp, văn bản lớn, dependency và lineage
• Đề xuất đồng thiết kế cả ingestion, storage và query processing

Nghe hơi giống chuyện tương lai, nhưng ai đã chạy agent trong production vài tháng thì thấy ngay đây là bài toán của hiện tại. Log của agent nhiều, lặp, phân cấp, và mỗi câu hỏi bạn muốn hỏi nó đều là câu hỏi lai. Ví dụ: cho tôi xem mọi lượt mà agent gọi tool tra tồn kho rồi sau đó vẫn trả lời sai, kèm chi phí token của từng lượt. Câu đó cần cấu trúc thực thi, cần hiểu ngữ nghĩa câu trả lời, và cần lineage giữa các bước. Đổ vào Elasticsearch thì mất cấu trúc, đổ vào Postgres thì phần văn bản vô dụng, đổ vào hệ observability thì mất lineage. Đó chính xác là lý do bài này ra đời. Tôi chưa khuyên ai đi tìm một TrajectoryDB để mua, vì đây là bài tầm nhìn chứ chưa phải sản phẩm. Nhưng có một việc nên làm ngay, rẻ và đỡ đau về sau: hãy thiết kế schema log agent của bạn ngay từ đầu với ba thứ là ID phân cấp của bước, con trỏ tới input và output, và chi phí token từng bước. Rất nhiều đội bỏ qua và sáu tháng sau không trả lời được câu hỏi đơn giản nhất là tiền đang đi đâu.

• Khung tổng thể OpenTI cho việc trích xuất hiểu biết từ kho bảng dữ liệu
• Ba nhánh rời rạc: table QA, text-to-SQL và data analysis agent
• Trích dẫn trong cùng nhãn nhiệm vụ cao gấp sáu lần so với trích chéo
• Hợp nhất thuật ngữ từ IR, NLP, machine learning, database và HCI
• Hệ hiện có chỉ mạnh phần phân tích, chưa phủ trọn vẹn từ đầu đến cuối
• Phần lớn benchmark hiện tại không phù hợp để đo mục tiêu này

Bài này nói ra một điều mà người mua giải pháp nên biết. Khi vendor cho bạn xem điểm benchmark của công cụ hỏi đáp dữ liệu, con số đó gần như luôn đo một mảnh của bài toán, thường là mảnh dịch câu hỏi thành SQL, và bỏ qua phần khó hơn nhiều: người dùng thực sự cần biết gì, làm sao biết câu trả lời có phục vụ đúng nhu cầu đó, làm sao xử lý khi câu hỏi mơ hồ hoặc dữ liệu không có. Con số trích dẫn chéo thấp gấp sáu lần là bằng chứng khá lạnh về việc ba cộng đồng đang giải ba phần của cùng một con voi mà ít đọc nhau. Theo tôi, giá trị thực dụng nhất của bài này là bảng phân rã bài toán: nhu cầu hiểu biết, quy trình dẫn ra nó từ kho bảng, và mức độ phục vụ được người hỏi. Dùng đúng ba trục đó làm câu hỏi thẩm định khi chọn công cụ thì bạn sẽ hỏi được những câu mà demo không chuẩn bị sẵn. Và với đội nội bộ đang tự xây, nó là lời nhắc rằng làm text-to-SQL chính xác hơn năm phần trăm không cứu được sản phẩm nếu người dùng vẫn không biết nên hỏi gì.

• Recall sau quantize không giải thích được bằng sai số trung bình
• Phân rã không phụ thuộc phân phối cho xác suất một phép so sánh bị đảo
• Xét cả phụ thuộc giữa các residual dùng chung query hoặc node đồ thị
• Định lý ghép đôi tất định cho việc chọn neighbour trong Vamana
• Chẩn đoán Gaussian ở mức biên không suy ra được đuôi residual cần thiết
• Có certificate trên block giữ lại khi thiếu giả thiết giải tích

Nếu bạn đang chạy vector search ở quy mô có hoá đơn, bài này thay đổi cách bạn nên nghĩ. Cách nghĩ cũ là quantize gây sai số, sai số gây mất recall, nên cứ đo sai số trung bình là biết. Bài này nói cách nghĩ đó sai về bản chất, vì thuật toán tìm kiếm không tiêu thụ khoảng cách, nó tiêu thụ các phép so sánh. Chỉ cần một phép so sánh bị đảo ở đúng bước cắt tỉa là cả một nhánh đồ thị biến mất khỏi kết quả, dù sai số trung bình vẫn rất nhỏ. Từ đó suy ra điều quan trọng: cái quyết định là khối xác suất của các biên gần bằng không, tức là những cặp vector vốn đã khó phân biệt, cộng với đuôi của phần dư sau hiệu chuẩn. Việc nên làm khi hạ bit không phải là xem recall trung bình trên tập test rồi thấy ổn mà chốt. Hãy tìm xem tập dữ liệu của bạn có bao nhiêu cặp nằm ở biên hẹp đó, vì chính chúng quyết định bạn có bị sập hay không. Và nhớ cảnh báo của bài: chẩn đoán theo phân phối biên nhìn có vẻ đẹp không bảo đảm gì về đuôi, nên đừng an tâm chỉ vì histogram trông giống Gaussian.

• Công cụ kiểm tương đương SQL có giới hạn: tìm không ra không chứng minh gì
• Đưa ra chặn tính được, biến tìm kiếm có giới hạn thành phép quyết định
• Làm việc trong khung combined-semantics, phủ cả DISTINCT và giữ trùng lặp
• Chặn cho truy vấn conjunctive là hai lũy thừa w nhân kích thước truy vấn
• Khai báo key làm chặn nhỏ lại, foreign key phi chu trình không đổi chặn
• Mở rộng sang vài lớp truy vấn có so sánh, trước đây chưa đặc tả được

Tôi đưa bài này vào mục thảo luận vì nó chạm đúng một điều mà đội data hay tự lừa mình. Khi refactor một câu SQL dài, hoặc khi chuyển logic từ stored procedure sang dbt model, câu hỏi duy nhất thật sự quan trọng là hai câu này có cho ra cùng kết quả không. Cách kiểm phổ biến hiện nay là chạy cả hai trên dữ liệu thật rồi so, hoặc dùng công cụ đi tìm phản ví dụ nhỏ. Cả hai cách đều chỉ cho bạn niềm tin, không cho bạn bằng chứng. Đóng góp của bài là biến việc tìm không ra phản ví dụ thành một chứng minh, với điều kiện bạn tìm đủ tới chặn mà họ tính. Chi tiết đáng khen là chặn chỉ phụ thuộc số cột mà câu truy vấn thực sự đọc, không phụ thuộc tổng số biến multiset, nên nó khả thi với truy vấn thật chứ không chỉ với ví dụ trong sách. Điểm cũng rất thực dụng: khai báo key làm chặn nhỏ lại. Nghĩa là database nào khai báo ràng buộc đầy đủ thì việc kiểm tương đương rẻ hơn. Đó là một lý lẽ mới, khá thuyết phục, cho việc đừng bỏ primary key chỉ vì warehouse không cưỡng chế nó.

• Restore counterfactual: đưa lại bằng chứng chuẩn rồi chạy lại cùng reader
• Phân loại lỗi thành cứu được, không thể cứu và còn lại
• So bốn chính sách xoá: FIFO, random, theo trùng lặp, theo mức quan trọng
• Ở 80 nghìn token, tỷ lệ không thể cứu 0,67 đến 0,73 với ba chính sách đầu
• Chính sách theo mức quan trọng do mô hình đánh giá tốt hơn, còn 0,60
• Ở 8 nghìn token, tỷ lệ không thể cứu đạt 1,00 với cả bốn chính sách

Đây là bài tôi nghĩ nên đọc trước khi cắt chi phí memory cho agent. Vì lý do rất người: khi hoá đơn token tăng, phản xạ đầu tiên của ai cũng là hạ ngân sách ngữ cảnh, rồi đo lại độ chính xác, thấy giảm chấp nhận được thì chốt. Bài này nói con số độ chính xác đó che mất một thứ quan trọng hơn: lỗi của bạn thuộc loại nào. Lỗi vì tìm chưa ra thì còn cứu được bằng cách cải tiến retrieval. Lỗi vì thông tin đã bị xoá khỏi bộ nhớ thì không có cách nào cứu, bạn chỉ có thể tăng ngân sách lại. Và con số 1,00 ở mức 8 nghìn token là một mốc cần nhớ: ở đó, tinh chỉnh chính sách xoá là công việc vô ích. Cái đáng suy nghĩ nữa là chính sách xoá theo mức quan trọng do mô hình tự đánh giá chỉ tốt hơn khoảng bảy điểm phần trăm so với FIFO. Tức là dùng mô hình để quyết định nên quên gì đắt hơn nhiều mà lợi không quá lớn. Với đội đang xây agent hỗ trợ khách hàng hoặc trợ lý nội bộ, việc nên làm là phân loại lỗi theo hai nhóm này trước khi tối ưu, vì hai nhóm cần hai giải pháp hoàn toàn khác nhau.

• Agent chạy dài đọc trạng thái rồi hành động rất lâu sau đó
• Version conflict là mọi thay đổi phát hiện được ở trạng thái đã đọc
• Decision conflict là thay đổi làm mất hiệu lực biện minh của hành động
• ATR ghi điều kiện biện minh dạng thực thi, chỉ kiểm lại phần bị ảnh hưởng
• Bốn kết cục: giữ nguyên, làm mới metadata, buộc lập kế hoạch lại, chặn

Bài này giải một vấn đề mà tôi tin rất nhiều đội sắp gặp mà chưa biết mình sắp gặp. Cơ chế optimistic concurrency control truyền thống của database chỉ trả lời được câu hỏi dữ liệu tôi đọc có đổi không. Câu đó đủ cho một transaction dài vài chục milli giây. Nó không đủ cho một agent đọc trạng thái lúc chín giờ sáng, chờ người duyệt tới ba giờ chiều, rồi mới gọi API chuyển tiền. Ở khoảng thời gian đó, dữ liệu chắc chắn đổi, và nếu bạn chặn mọi lượt có thay đổi thì agent gần như không bao giờ hoàn thành việc gì. Nếu bạn bỏ qua mọi thay đổi thì bạn có một quả bom. Cách ATR giải khá tinh: ghi lại điều kiện biện minh của hành động ở dạng có thể thực thi lại, rồi khi có thay đổi thì chỉ kiểm những điều kiện thực sự liên quan. Với đội làm automation nghiệp vụ, đây là lời nhắc thiết kế rất cụ thể: đừng chỉ lưu kết quả quyết định của agent, hãy lưu cả lý do dưới dạng biểu thức kiểm được. Đó là khác biệt giữa một hệ thống có thể audit và một hệ thống chỉ có thể xin lỗi.

• Doanh thu quý 19,3 tỷ đô, tăng 30 phần trăm so với cùng kỳ
• Cloud infrastructure tăng 121 phần trăm lên 7,4 tỷ đô
• Tổng doanh thu cloud tăng 62 phần trăm lên 11,6 tỷ đô
• Lãi ròng tăng 60 phần trăm lên 4,7 tỷ từ mức 2,93 tỷ
• Capex trong quý 28,5 tỷ đô, so với 8,5 tỷ cùng kỳ năm trước
• Nợ chạm 125 tỷ đô, hướng dẫn doanh thu năm tối thiểu 90 tỷ

Đọc báo cáo này nên đọc hai cột cùng lúc, vì mỗi cột kể một câu chuyện khác nhau. Cột doanh thu nói nhu cầu hạ tầng AI là thật và đang trả tiền: hạ tầng cloud tăng hơn gấp đôi, điều mà không một dòng sản phẩm database truyền thống nào làm được. Cột chi và nợ nói cái giá: 28,5 tỷ chi đầu tư trong một quý, gấp hơn ba lần cùng kỳ, và tổng nợ 125 tỷ. Nghĩa là Oracle đang đi vay để dựng công suất cho những hợp đồng nhiều năm, và mô hình này chỉ đứng vững nếu nhu cầu giữ nhịp đủ lâu để khấu hao xong đống phần cứng đó. Với người làm data ở Việt Nam, có hai hệ quả rất thực tế. Một, cuộc đua capex này đang định giá compute và lưu trữ mà bạn thuê, nên đừng lập ngân sách ba năm dựa trên giá hôm nay, cả hướng tăng lẫn giảm đều có thể mạnh. Hai, khi một nhà cung cấp gánh nợ lớn cho AI, sức ép bán kèm dịch vụ AI vào hợp đồng database sẽ tăng, nên hãy đọc kỹ điều khoản gia hạn. Theo tôi, câu hỏi đáng theo dõi trong bốn quý tới không phải doanh thu OCI tăng bao nhiêu, mà là tỷ lệ backlog thực sự chuyển thành doanh thu ghi nhận được.

• Thiết lập partner-powered AI features không còn tắt được trên giao diện
• Settings API vẫn cho thay đổi tới ngày 01/11/2026
• ABAC DENY policy vào Beta trong Unity Catalog
• DENY chặn tường minh MANAGE ACCESS CONTROL, ưu tiên hơn mọi grant
• ai_search thêm generate_citations, chỉ ra chunk chống lưng câu trả lời

Tôi xếp mục này vào phần doanh nghiệp vì nó là chuyện quản trị và hợp đồng, không phải chuyện kỹ thuật. Việc rút một công tắc khỏi giao diện và chỉ chừa đường API đến ngày mùng một tháng mười một là cách nói rất lịch sự rằng tính năng này sắp thành mặc định không thể tắt. Với doanh nghiệp trong ngành bị quản chặt, hoặc doanh nghiệp có cam kết với khách về việc dữ liệu không đi qua bên thứ ba, đây không phải chi tiết nhỏ. Việc nên làm ngay trong tháng này là xác định xem workspace của bạn có đang bật thiết lập đó, quyết định lập trường, và nếu cần tắt thì tắt qua Settings API trước hạn cùng với việc ghi lại quyết định vào tài liệu tuân thủ. Phía ngược lại, ABAC DENY là món tôi chờ đã lâu. Mô hình chỉ có grant luôn có một lỗ hổng thực tế: bạn cấp quyền theo nhóm cho tiện, rồi phát hiện một người trong nhóm đó không được phép, và cách duy nhất là bẻ nhóm ra. Có DENY thắng grant nghĩa là ngoại lệ diễn đạt được trực tiếp. Riêng generate_citations thì nhỏ mà quan trọng với ai đang làm RAG nội bộ, vì không có citation thì câu trả lời sai và câu trả lời đúng trông giống nhau y hệt.

• Wix chuyển 5 tỷ bản ghi và 10 terabyte trong bốn tuần, dùng CDC và Kafka
• Wix nhấn mạnh chạy thử để lộ dữ liệu hỏng cũ và kiểm đối chiếu đầu cuối
• StarTree ra Segment Group, gom metadata khoảng 100 segment thành một
• Pinot mở tới 10 triệu segment, tương thích bảng Iceberg nhiều triệu file
• Netflix mô tả vòng đời LLM-as-a-Judge bốn pha với quy trình RART
• Instacart để agent sinh và đánh giá giả thuyết mô hình trên nền Griffin

Điểm chung của mấy case study tuần này là sự tỉnh táo, và đó là lý do nên đọc. Wix không kể chuyện một công cụ thần kỳ, họ kể ba việc rất nhàm mà quyết định thành bại: chạy thử để phát hiện dữ liệu hỏng từ thời xa xưa, kiểm đối chiếu từ đầu đến cuối để bắt lệch sớm, và chia phân vùng Kafka cùng shard database cho đúng kích thước. Ai từng migrate dữ liệu lớn đều biết ba việc đó chiếm chín phần mười thời gian. StarTree thì nói về một bài toán ít ai nghĩ tới: khi mỗi ngày sinh ra khoảng ba trăm nghìn segment, thứ vỡ trước không phải lưu trữ mà là control plane phải quản metadata của chúng. Chi tiết đáng chú ý cho ai làm lakehouse là việc một bảng Iceberg năm triệu file sẽ mở đầu đời như một bảng Pinot năm triệu segment. Còn RART của Netflix là món tôi khuyên mọi đội đang làm đánh giá bằng mô hình nên xem: điểm hay là judge chỉ là một prompt template gắn rubric, nên tinh chỉnh nó không phải huấn luyện lại mô hình. Đó là cách làm mà đội nhỏ ở Việt Nam bắt chước được, chi phí gần bằng không.