Databricks: 'Thuế thử nghiệm' đang kìm hãm lộ trình AI của doanh nghiệp

Bạn biết cảm giác đó mà. Nhóm của bạn có một ý tưởng tuyệt vời cho một pipeline hỗ trợ bởi AI - có thể là một sản phẩm dữ liệu mới, hoặc một agent tự động hóa quy trình làm việc mà chẳng ai muốn thực hiện thủ công. Nhà tài trợ điều hành thì hào hứng. Trưởng nhóm kỹ thuật phác thảo kiến trúc trên bảng trắng. Và rồi… nhiều tuần trôi qua. Môi trường cần được thiết lập. Bối cảnh bị mất đi giữa các nhóm. Đến khi bản mẫu (prototype) sẵn sàng, nhà tài trợ điều hành đã chuyển hướng sang việc khác, nhóm đã mất đi động lực, và sáng kiến đó lặng lẽ chết đi sau một thứ gì đó mới mẻ hơn.

Khoảng cách đó, giữa "hãy thử cái này" và một bản mẫu hoạt động được, là thứ chúng tôi gọi là "thuế tạo mẫu" (prototyping tax). Và nó đang giết chết nhiều lộ trình AI hơn bất kỳ hạn chế nào của mô hình AI.

Tại sao loại thuế này ngày càng chồng chất

Nút thắt cổ chai không nằm ở tốc độ viết code của các kỹ sư - mà nằm ở hiệu quả R&D của toàn bộ tổ chức. R&D truyền thống được thiết kế để con người điều hướng: nó giúp việc phát triển phần mềm quy mô lớn trở nên khả thi, nhưng nó không được xây dựng cho các AI agent. Ba lực lượng đang làm tăng thêm loại thuế này:

Những ma sát này giải thích một điều mà các nhà phát triển thường xuyên báo cáo: AI agent mang lại cảm giác đột phá trên các dự án cá nhân nhưng lại gây thất vọng trên các codebase sản xuất. Agent không hề kém thông minh đi. Chỉ là codebase đó không được xây dựng để nó điều hướng.

Đó chính là thuế tạo mẫu. Hầu hết các lộ trình AI mà chúng tôi thấy đều phải trả một phiên bản nào đó của loại thuế này. Những nhóm đang bứt phá là những nhóm đã tìm ra cách để ngừng trả loại thuế đó.

Một vị thế khởi đầu khác biệt

Những nhóm đang bứt phá không sử dụng các agent tốt hơn. Họ đang mang đến cho agent của mình một vị thế khởi đầu tốt hơn: một vị thế dựa trên ngữ nghĩa kinh doanh (business semantics), chứ không chỉ là cú pháp (syntax). Khi agent đã nắm giữ được bối cảnh đó, hai điều về cách bạn xây dựng sẽ thay đổi.

Ý định trở thành đặc tả (spec). Một mô tả rõ ràng về những gì bạn muốn là đủ để bắt đầu, và lớp chuyển đổi cũ - nơi con người biến ý định thành các yêu cầu kỹ thuật trước khi bất kỳ ai có thể xây dựng - được rút gọn ngay trong phiên xây dựng. Quản trị (governance) được đưa vào vòng lặp: dòng dữ liệu (lineage), kiểm soát truy cập và các ràng buộc tuân thủ được thực hiện trực tiếp trong khi quá trình xây dựng diễn ra, thay vì được phát hiện sau đó khi có ai đó hỏi "khoan đã, chúng ta có thực sự được phép sử dụng dữ liệu này không?"

Không điều nào trong số này thay đổi người sở hữu kết quả đầu ra. Nó thay đổi cách nhìn nhận về việc sở hữu đó. Người xây dựng chuyển từ vai trò tác giả sang kiến trúc sư, người đánh giá và người hướng dẫn: dành ít thời gian gõ phím hơn, dành nhiều thời gian để ra quyết định hơn. Agent là một bộ nhân cho khả năng phán đoán, không phải là sự thay thế cho nó.

Điều gì thay đổi và điều gì không

Đây là sự đảo ngược quan trọng: trong phát triển truyền thống, bạn thống nhất trước khi xây dựng. Bạn viết đặc tả, lưu hành tài liệu thiết kế, tổ chức cuộc họp yêu cầu - và tất cả chỉ là mô phỏng của thực tế. Sau đó bạn triển khai, gặp phải những điều bất ngờ, thay đổi phạm vi, triển khai lại. Nhiều tuần trôi qua.

Trong phát triển theo hướng agent (agentic development), sự thống nhất diễn ra thông qua việc xây dựng. Bạn viết ra các giả định của mình, agent xây dựng một MVP hoạt động được trong vài giờ, và đặc tả xuất hiện từ code đang chạy, chứ không phải ngược lại. Tài liệu thiết kế trở nên chính xác nhờ quá trình xây dựng - vì nó được rút ra từ thực tế, không phải từ trí tưởng tượng.

Nén giai đoạn đầu, giữ vững giai đoạn sau. Lộ trình sản xuất không thay đổi - vẫn là CI/CD đó, vẫn quy trình review code đó, vẫn sự nghiêm ngặt đó. Không có làn đường ưu tiên cho code do AI tạo ra. Điều thay đổi là các bản mẫu đạt đến giai đoạn hoàn thiện và phát hành trước khi động lực phai nhạt.

Các chỉ số chứng minh vòng lặp đang hoạt động

Ba chỉ số cho bạn biết liệu thuế tạo mẫu có thực sự đang giảm bớt hay không - hay bạn chỉ vừa có một buổi hội thảo thành công.

Nội dung đo lường

Chỉ số

Tại sao nó quan trọng

Tốc độ nén

Thời gian tạo mẫu (Time-to-prototype) - từ ý tưởng đến MVP có thể demo

Chỉ số dẫn dắt. Nếu chỉ số này không giảm, vòng lặp không hoạt động.

Chất lượng nén

Tỷ lệ chấp nhận lần đầu (First-pass acceptance rate) - % các tiêu chí chấp nhận được đáp ứng mà không cần chu kỳ làm lại

Chứng minh agent đã xây dựng đúng thứ cần thiết, không chỉ là xây dựng nhanh.

Độ bền của kết quả đầu ra

Tỷ lệ PoC lên sản xuất (PoC-to-production rate) - % được phát hành qua CI/CD trong vòng 90 ngày

Chỉ số trễ. Chứng minh các bản mẫu không chỉ là những bản demo rồi bị bỏ xó.

Theo dõi cả ba chỉ số này cho mỗi nhóm, thiết lập mức cơ sở ngay bây giờ và quan sát xu hướng trong một quý. Nếu thời gian tạo mẫu giảm nhưng tỷ lệ PoC lên sản xuất không theo kịp, bạn đang tạo ra các bản demo, không phải phát hành sản phẩm.

Nơi các agent bản địa trên nền tảng (platform-native agents) thay đổi cuộc chơi

Các agent lập trình tổng quát thực sự giỏi về cú pháp, tệp tin và API. Điều chúng không biết là doanh nghiệp của bạn - các schema của bạn và ý nghĩa của chúng, mô hình quản trị của bạn, các mô hình triển khai của bạn. Vì vậy, chúng phải đi tìm kiếm, từng bước một, đốt cháy token và thời gian để xây dựng lại bối cảnh mà nền tảng đã nắm giữ sẵn.

Chúng tôi có số liệu về việc việc tìm kiếm đó tốn kém như thế nào. Trên một bộ benchmark gồm 401 tác vụ dữ liệu thực tế, một data agent bản địa trên nền tảng đạt độ chính xác 77% so với 56–72% của các agent lập trình tổng quát hàng đầu - với chi phí mỗi tác vụ chỉ bằng khoảng một nửa. Sự đánh đổi giữa chất lượng và chi phí mà bạn mong đợi đơn giản là không tồn tại. Chuyên môn tích lũy thành độ chính xác, tốc độ và chi phí cùng một lúc.

Trên Databricks, điều này thể hiện qua Genie Code - một autonomous data agent được xây dựng trực tiếp trên Unity Catalog - kết hợp với Genie Ontology, một lớp ngữ nghĩa được quản trị giúp agent hiểu được ý nghĩa kinh doanh, không chỉ là tên cột. Agent đọc hiểu ý nghĩa của một bảng thay vì suy luận, và kế thừa các kiểm soát truy cập cũng như quản trị của bạn theo mặc định.

Abacus Insights: kỹ thuật dữ liệu theo hướng agent trong y tế

Không nơi nào vị thế khởi đầu quan trọng hơn trong các ngành công nghiệp được quản lý chặt chẽ. Khi dữ liệu nhạy cảm và quản trị là điều không thể thương lượng, cách tiếp cận "khám phá và đoán" của một agent lập trình tổng quát không chỉ lãng phí thời gian - nó còn tạo ra rủi ro tuân thủ.

Abacus Insights xử lý dữ liệu y tế cho hơn 65 triệu thành viên dưới các kiểm soát đạt chuẩn HIPAA và air-gapped. Đây chính xác là môi trường mà cách tiếp cận "khám phá và đoán" không còn là sự lãng phí thời gian mà trở thành một rủi ro: nó không thể tùy tiện chạm vào PHI (thông tin sức khỏe cá nhân), nó không thể đoán mò về mô hình quản trị, và mỗi giả định sai lầm đều trở thành một vấn đề tuân thủ thay vì một bản sửa lỗi nhanh chóng.

Nhóm của họ đã đưa các agent lập bản đồ dữ liệu và pipeline vào sản xuất, với Genie Code là giao diện hàng ngày mà các kỹ sư của họ sử dụng - vì nó đã hiểu dữ liệu của họ và hoạt động trong khuôn khổ quản trị của họ, thay vì cần phải giải thích mọi thứ từ đầu. Và họ đã thấy những cải thiện hiệu quả đáng kể trong công việc trí tuệ dữ liệu của mình. Thành quả thể hiện qua các con số: việc onboarding khách hàng mới hiện đạt được giá trị đầu tiên trong khoảng thời gian chỉ bằng một nửa, và nỗ lực thủ công cho việc lập bản đồ dữ liệu và xây dựng pipeline giảm khoảng 40%.

Điểm mấu chốt

Thuế tạo mẫu là có thật, có thể đo lường được và là thứ có thể loại bỏ. Những nhóm đã tìm ra điều này không chờ đợi để thống nhất trước khi xây dựng — họ đang thống nhất bằng cách xây dựng, và phát hành trước khi động lực phai nhạt.