Chuyển đổi số ngành xây dựng trong kỷ nguyên AI

Trong hơn hai thập niên qua, ngành xây dựng đã trải qua một quá trình số hóa mạnh mẽ. Bản vẽ giấy được thay bằng CAD, hồ sơ được chuyển thành PDF, bảng tính được quản lý bằng Excel, mô hình thông tin công trình (Building Information Modeling – BIM) ngày càng phổ biến và môi trường dữ liệu chung (Common Data Environment – CDE) bắt đầu được sử dụng để quản lý, chia sẻ thông tin dự án. Nhìn từ bên ngoài, ngành xây dựng dường như đã tạo ra một khối lượng dữ liệu số khổng lồ. Nhưng có một câu hỏi căn bản cần được đặt ra: Chúng ta thực sự đã chuyển đổi số, hay mới chỉ số hóa vật chứa thông tin?

Phần lớn hoạt động của ngành xây dựng hiện nay vẫn được tổ chức quanh hồ sơ và sản phẩm bàn giao. Hợp đồng quy định phải nộp bản vẽ, báo cáo, bảng tính, mô hình và các loại tệp. Mỗi tổ chức tạo ra một bộ hồ sơ tại một thời điểm nhất định, chuyển nó cho tổ chức tiếp theo và xem việc bàn giao là hoàn thành. Vì vậy, mặc dù vật chứa đã chuyển từ giấy sang số, logic quản trị thông tin về cơ bản vẫn mang dấu ấn của thời đại hồ sơ.

Một kỹ sư có thể xuất dữ liệu từ phần mềm BIM sang Excel. Một người khác sửa bảng Excel rồi gửi cho bộ phận tiếp theo.  Đơn vị vận hành sau đó lại nhập dữ liệu vào hệ thống quản lý tài sản. Khi thiết kế thay đổi, chuỗi thao tác này phải được thực hiện lại. Mỗi lần dữ liệu cần đi từ điểm A đến điểm B lại trở thành một chuyến vận chuyển thủ công riêng biệt, phụ thuộc vào một con người, một thao tác và đôi khi là một quy trình mà chỉ người thực hiện hiểu đầy đủ. Hệ quả là chi phí xử lý tăng theo số lần mô hình thay đổi; cùng một dữ liệu được sao chép thành nhiều phiên bản; định danh đối tượng có thể bị mất; nguồn gốc dữ liệu khó truy nguyên; sai sót xảy ra nhưng không để lại dấu vết; và dữ liệu ở các công đoạn phía sau dần tách khỏi nguồn tạo ra nó. Một dự án vì vậy có thể sở hữu hàng nghìn tệp số, nhiều mô hình BIM và một CDE nhưng vẫn chưa thực sự vận hành theo cách tiếp cận lấy dữ liệu làm trung tâm (Data-Centric).

Đây là giới hạn căn bản của mô hình lấy tệp làm trung tâm (File-Centric). Chuyển đổi số ngành xây dựng vì vậy không thể tiếp tục được đánh giá đơn giản bằng số lượng phần mềm được triển khai, số mô hình BIM được tạo ra hay số hồ sơ đã được điện tử hóa. Câu hỏi quan trọng hơn phải là: Dữ liệu có thể chảy liên tục và đáng tin cậy giữa con người, phần mềm, tổ chức và các giai đoạn của vòng đời công trình hay không? Có thể nhìn quá trình trưởng thành này qua ba trạng thái: lấy giấy làm trung tâm (Paper-Centric), lấy tệp làm trung tâm (File-Centric) và lấy dữ liệu làm trung tâm (Data-Centric). 

Trong trạng thái lấy dữ liệu làm trung tâm, đơn vị quản trị cơ bản không còn chỉ là một bản vẽ, bảng tính hay mô hình, mà là các thực thể thông tin có thể được nhận diện, liên kết, truy vấn, kiểm chứng và tái sử dụng.

Hãy lấy một cửa chống cháy làm ví dụ. Trong cách tiếp cận lấy tệp làm trung tâm (FileCentric), thông tin của chiếc cửa có thể đồng thời nằm trong mô hình kiến trúc, bảng thống kê cửa, hồ sơ phòng cháy chữa cháy, bảng Excel mua sắm và phần mềm quản lý tài sản. Mỗi hệ thống có thể đặt tên chiếc cửa theo một cách khác nhau. Khi dữ liệu được chuyển từ hệ thống này sang hệ thống khác, rất khó bảo đảm rằng tất cả vẫn đang nói về cùng một đối tượng. 

Trong cách tiếp cận lấy dữ liệu làm trung tâm (DataCentric), trước hết phải tồn tại một thực thể có định danh ổn định, chẳng hạn Door- 03-125. Thực thể đó có loại đối tượng, thuộc tính chống cháy, vị trí, không gian chứa nó, nhà sản xuất, ngày lắp đặt, trạng thái kiểm định, lịch sử bảo trì và các quan hệ cần thiết khác. Tệp vẫn tồn tại và vẫn rất quan trọng, nhưng lúc này tệp trở thành một phương tiện đóng gói, lưu trữ hoặc biểu diễn dữ liệu, thay vì là nơi duy nhất quyết định sự tồn tại của dữ liệu. Từ đây có thể hình thành khái niệm nguyên tử thông tin (Information Atom), để chỉ một đơn vị thông tin đủ nhỏ nhưng vẫn có ý nghĩa đối với một quyết định hoặc nghiệp vụ xác định. 

Tuy nhiên, một nguyên tử thông tin không thể lưu thông đáng tin cậy nếu nó không mang theo ngữ cảnh cần thiết. Vì vậy, mỗi nguyên tử thông tin cần có một hộ chiếu thông tin (Information Passport). Hộ chiếu đó trước hết phải cho biết định danh (Identity), tức đối tượng này là ai; ngữ nghĩa (Semantics), tức đối tượng này là gì và được hiểu như thế nào; thuộc tính (Properties), tức những đặc điểm cần biết; quan hệ (Relationships), tức nó liên hệ với những thực thể nào; vị trí (Location), tức nó nằm ở đâu; thời gian và trạng thái (Time/State), tức nó tồn tại ở thời điểm nào và đang trong trạng thái nào; nguồn gốc dữ liệu (Provenance), tức dữ liệu do đâu mà có, ai tạo ra, ai thay đổi và thay đổi khi nào; cùng trạng thái kiểm chứng (Validation), tức dữ liệu đã đáp ứng các yêu cầu và quy tắc xác định hay chưa. Khi những yếu tố này được duy trì cùng dữ liệu, một con số không còn chỉ là một con số và một đối tượng BIM không còn chỉ là một khối hình học. Chúng trở thành những đơn vị thông tin có thể được hiểu trong đúng ngữ cảnh, có thể truy nguyên và có thể kiểm chứng.

Nếu nguyên tử thông tin (Information Atom) là “hàng hóa” của nền kinh tế dữ liệu xây dựng thì ngành xây dựng cần một hệ thống logistics để hàng hóa đó có thể lưu thông. Đây là nơi cần phân biệt dòng dữ liệu (Data Flow) với đường ống hoặc dây chuyền dữ liệu (Data Pipeline). Dòng dữ liệu cho biết dữ liệu đi từ đâu đến đâu, còn Data Pipeline xác định dữ liệu được tiếp nhận, phân tích cấu trúc, chuyển đổi, phân loại, kiểm tra, lưu trữ và cung cấp cho các hệ thống tiếp theo như thế nào.

Dữ liệu có thể bắt đầu từ phần mềm thiết kế, sau đó được tiếp nhận dữ liệu (Data Ingestion), phân tích cấu trúc dữ liệu (Data Parsing), chuyển đổi dữ liệu (Data Transformation), gắn với hệ thống phân loại (Classification) và từ điển dữ liệu (Data Dictionary), rồi được kiểm chứng (Validation), lưu trữ, truy vấn, phân tích và cung cấp cho các hệ thống khác. Điều quan trọng không nằm ở tên của từng công nghệ mà ở khả năng duy trì định danh, ngữ nghĩa, quan hệ, nguồn gốc và độ tin cậy của dữ liệu trong toàn bộ hành trình đó.

Từ cách nhìn này có thể hình thành khái niệm logistics dữ liệu xây dựng (Construction Data Logistics). Nếu nguyên tử thông tin (Information Atom) là hàng hóa thì hộ chiếu thông tin (Information Passport) là hộ chiếu của hàng hóa; tuần tự hóa dữ liệu (Serialization) là cách đóng dữ liệu thành dạng có thể lưu trữ hoặc truyền đi; IFC, JSON hay XML là những hình thức biểu diễn và trao đổi dữ liệu; giao diện lập trình ứng dụng (Application Programming Interface – API), môi trường dữ liệu chung (Common Data Environment – CDE) và các nền tảng trao đổi dữ liệu là một phần của hạ tầng vận chuyển. 

Đặc tả cung cấp thông tin (Information Delivery Specification – IDS) quy định dữ liệu phải đáp ứng những yêu cầu gì; bộ máy quy tắc (Rule Engine) thực hiện việc kiểm tra; nguồn gốc dữ liệu (Provenance) đóng vai trò gần giống vận đơn ghi lại nguồn gốc và hành trình; đồ thị tri thức (Knowledge Graph) tổ chức các thực thể và quan hệ thành mạng tri thức; còn tác nhân trí tuệ nhân tạo (AI Agent) sử dụng những dữ liệu đã được tổ chức và kiểm chứng để phân tích, giải thích hoặc thực hiện hành động.

Nhìn theo cách đó, lớp nền tảng dữ liệu dùng chung của buildingSMART (buildingSMART Data Dictionary – bSDD), môi trường dữ liệu chung (CDE), giao diện lập trình ứng dụng (API), đồ thị tri thức (Knowledge Graph), IFC, IDS hay các nền tảng như Speckle không còn là những công nghệ BIM rời rạc. Chúng là những cấu phần khác nhau của một hạ tầng lưu thông dữ liệu xây dựng. Vấn đề cốt lõi không phải lựa chọn một phần mềm để thay thế tất cả phần mềm khác, mà là làm thế nào để dữ liệu có thể đi qua nhiều hệ thống mà không đánh mất định danh, ngữ nghĩa, quan hệ, nguồn gốc và độ tin cậy. 

Đây cũng là mắt xích thường bị bỏ qua khi nói về BIM và trí tuệ nhân tạo (Artificial Intelligence – AI). Chúng ta thường hình dung một con đường rất ngắn từ BIM đến AI, như thể chỉ cần đưa đủ mô hình vào một hệ thống trí tuệ nhân tạo thì máy sẽ tự hình thành tri thức. Nhưng AI không thể tự biến dữ liệu hỗn loạn thành sự thật đáng tin cậy. Giữa BIM và AI phải tồn tại một lớp quan trọng hơn: dữ liệu đáng tin cậy (Trusted Data).

Dữ liệu thô (Raw Data) trước hết phải trở thành dữ liệu sạch (Clean Data), sau đó là dữ liệu có cấu trúc (Structured Data), dữ liệu có ngữ nghĩa (Semantic Data), dữ liệu được liên kết (Connected Data), dữ liệu đã được kiểm chứng (Validated Data) và cuối cùng là dữ liệu đáng tin cậy (Trusted Data). Khi dữ liệu có định danh, ngữ nghĩa, quan hệ, nguồn gốc và cơ chế kiểm chứng, nó mới có khả năng hình thành tri thức đáng tin cậy (Trusted Knowledge). Vì vậy, tương lai của BIM-AI không được quyết định chủ yếu bởi chúng ta có bao nhiêu gigabyte dữ liệu hay bao nhiêu triệu đối tượng BIM, mà bởi bao nhiêu dữ liệu có thể được nhận diện, hiểu đúng, liên kết, truy nguyên và kiểm chứng để máy có thể sử dụng một cách đáng tin cậy. Nhiều dữ liệu hơn không tự động tạo ra nhiều trí tuệ hơn. Trí tuệ chỉ xuất hiện khi dữ liệu được biến thành tri thức có ngữ cảnh và có thể kiểm chứng.

Tuy nhiên, một Data Pipeline tốt vẫn chưa đủ. Công trình tồn tại hàng chục, thậm chí hàng trăm năm, trong khi phần mềm, tổ chức và con người liên tục thay đổi. Điều cần duy trì không chỉ là khả năng vận chuyển dữ liệu tại một thời điểm mà còn là sự liên tục của thông tin qua thời gian. Đây chính là sợi chỉ số xuyên vòng đời (Digital Thread). 

Một cửa chống cháy có thể lần lượt trải qua trạng thái được thiết kế (Designed), được phê duyệt (Approved), được mua sắm (Procured), được lắp đặt (Installed), được kiểm tra hoặc nghiệm thu (Inspected), được bảo trì (Maintained) và được thay thế (Replaced). Trong toàn bộ quá trình đó, nếu định danh của đối tượng được duy trì, lịch sử thay đổi được ghi lại, nguồn gốc dữ liệu có thể truy nguyên và các quan hệ không bị mất, chúng ta không còn có nhiều phiên bản rời rạc của một chiếc cửa. Chúng ta có một thực thể duy nhất với lịch sử số xuyên suốt vòng đời.

Đó cũng là nền móng thực sự của bản sao số (Digital Twin). Một bản sao số không thể đáng tin cậy nếu không biết dữ liệu hiện tại được hình thành từ đâu, đã thay đổi như thế nào, ai xác nhận và trạng thái trong thế giới số có còn tương ứng với tài sản thực hay không. Bản sao số vì vậy không nên bắt đầu từ việc dựng một mô hình 3D thật đẹp, mà từ khả năng duy trì một sợi chỉ số xuyên vòng đời đáng tin cậy (Trusted Digital Thread). 

Cách tiếp cận này đồng thời đặt lại điểm xuất phát của BIM. Điểm xuất phát không nên là câu hỏi “cần mô hình 3D đến mức nào?”, mà phải bắt đầu từ mục đích (Purpose); từ mục đích xác định quyết định (Decision) cần đưa ra; từ quyết định xác định yêu cầu thông tin (Information Requirement); và từ yêu cầu thông tin mới xác định dữ liệu nào cần được tạo ra, cấu trúc, kiểm chứng và biểu diễn ở mức nào. Đây là sự chuyển dịch từ ưu tiên mô hình 3D trước (3D-First) sang lấy dữ liệu làm điểm xuất phát (Data-First); đồng thời là lấy yêu cầu làm điểm xuất phát (Requirement-First) và thiết kế khả năng kiểm chứng ngay từ đầu (Validation-First). Ở cấp độ cao hơn, đây không còn chỉ là vấn đề của một dự án BIM.

 Một quốc gia làm chủ được Data Pipeline của ngành xây dựng sẽ từng bước có khả năng biết mình đã xây những gì, ở đâu, bằng vật liệu gì, khi nào, với chi phí nào và các tài sản đó hiện đang ở trạng thái nào. Trên nền tảng đó mới có thể phát triển quản lý tài sản công dựa trên dữ liệu, định mức dựa trên dữ liệu thực, quản lý carbon, bản sao số đô thị (Urban Digital Twin), quy định thông minh hoặc quy định có thể được máy xử lý (SmartCodes), kiểm tra tuân thủ tự động, bảo trì dự đoán và các tác nhân trí tuệ nhân tạo (AI Agents) cho ngành xây dựng.

Đối với Việt Nam, vấn đề dài hạn vì vậy không nên chỉ là phát triển thêm các phần mềm BIM mà cần từng bước hình thành hạ tầng dữ liệu xây dựng Việt Nam (Vietnam Construction Data Infrastructure – CDI-VN). Hạ tầng đó có thể kết nối hệ thống phân loại xây dựng Việt Nam (VNClass), từ điển dữ liệu mở Việt Nam (ODD-VN), các yêu cầu thông tin số, cơ chế định danh và siêu dữ liệu (Metadata), IFC, IDS, thư viện quy tắc máy đọc, CDE, API, sợi chỉ số xuyên vòng đời (Digital Thread), đồ thị tri thức (Knowledge Graph) và các tác nhân trí tuệ nhân tạo có kiểm soát (Controlled AI Agents). 

Mục tiêu không phải tạo ra một “siêu phần mềm BIM quốc gia”, mà là xây dựng ngôn ngữ chung, quy tắc chung và hạ tầng chung để dữ liệu có thể lưu thông xuyên phần mềm, tổ chức, dự án và vòng đời tài sản. Đây chính là bước chuyển từ tư duy xây dựng các ứng dụng số riêng lẻ sang tư duy xây dựng một hạ tầng dữ liệu dùng chung cho toàn ngành. Vì vậy, cần tái định nghĩa chuyển đổi số ngành xây dựng. Xây dựng số không đồng nghĩa với việc có nhiều tệp số hơn (Digital Construction ≠ More Digital Files). 

Sự trưởng thành thực sự phải là quá trình chuyển từ lấy giấy làm trung tâm (PaperCentric) sang lấy tệp làm trung tâm (File-Centric), và cuối cùng là lấy dữ liệu làm trung tâm (Data-Centric); từ trao đổi dữ liệu theo từng lần bàn giao (Data Exchange) sang dòng dữ liệu liên tục (Continuous Data Flow); và từ các tệp số rời rạc (Digital Files) sang sợi chỉ số xuyên vòng đời đáng tin cậy (Trusted Digital Thread). 

Tương lai của chuyển đổi số ngành xây dựng vì thế không phải là có nhiều tệp số hơn, mà là xây được một dòng dữ liệu liên tục, có định danh, có ngữ nghĩa, có quan hệ, có nguồn gốc, được kiểm chứng và có thể được cả con người lẫn máy sử dụng xuyên suốt vòng đời công trình.