Certain vs Optional: Zunavi quyết định điều gì đáng tin ra sao

Một registry feature flag đưa ra một lời cam kết

Hầu hết các hệ thống feature flag chỉ trả lời một câu hỏi: tính năng này bật hay tắt cho khách hàng này. Registry flag của Zunavi trả lời thêm một câu hỏi thứ hai, quan trọng hơn: bạn có thể tin những gì tính năng này nói với bạn không?

Mỗi năng lực trong registry được gắn một tier — certain (chắc chắn) hoặc optional (tùy chọn) — và tier này không chỉ mang tính hình thức. Nó quyết định trạng thái mặc định, và quyết định cách tính năng đó được phép tự mô tả trong giao diện.

Certain: Bật mặc định, vì bắt buộc phải vậy

Năm năng lực được đánh dấu certain và được bật mặc định: sổ đăng ký bản vẽ cốt lõi (drawing.core), tìm kiếm theo metadata (search.metadata), liên kết quy cách với bản vẽ (spec.link), quản lý phiên bản và phả hệ (revision.management), và quy trình phê duyệt (approval.flow). Đây là những năng lực mà một hệ thống quản lý bản vẽ không được phép sai. Nếu sổ đăng ký nói một bản vẽ đang ở phiên bản C, nó phải thực sự là phiên bản C. Nếu quy trình phê duyệt nói một thay đổi đã được duyệt, điều đó phải đúng và có thể truy vết được. Không tồn tại phiên bản “gần đúng” cho một hệ thống lưu trữ chính thức.

Optional: Tắt mặc định, vì độ chính xác chưa đạt tới đó

Bảy năng lực được đánh dấu optional và tắt mặc định: OCR khung tên (scan.titleblock), tìm kiếm tương đồng 2D (similar.2d), tìm kiếm tương đồng 3D (similar.3d), tìm kiếm tương đồng đa phương thức (similar.crossmodal), so sánh/diff bản vẽ (viewer.compare), trình xem 3D (viewer.3d), và AI agent (ai.agent). Đây không phải là những tính năng kém hơn — chúng thuộc số những phần thú vị nhất về mặt kỹ thuật của nền tảng. Nhưng chúng có chung một đặc điểm mà tier “certain” không có: chúng mang tính hỗ trợ, vẫn đang trong quá trình hoàn thiện, và kết quả đầu ra của chúng cần con người xác minh trước khi được coi là sự thật.

OCR khung tên đọc số hiệu linh kiện từ một bản vẽ đã quét thực sự hữu ích — cho đến khi nó đọc sai một ký tự và không ai phát hiện ra trước khi giá trị đó lan vào BOM. Tìm kiếm tương đồng dựa trên vector hiển thị một bản vẽ “trông giống” một bản vẽ hiện có là cách tuyệt vời để tránh trùng số hiệu linh kiện — trừ khi ai đó coi kết quả khớp đó là đồng nhất đã được xác nhận thay vì một manh mối đáng để kiểm tra. Chế độ lỗi của các tính năng optional không phải là “nó không hoạt động”. Đó là “nó đúng đủ thường xuyên để người ta ngừng kiểm tra lại, cho đến đúng lần nó quan trọng.”

Vì sao lại vạch ra ranh giới này

Sẽ đơn giản hơn, xét từ góc độ marketing, nếu gọi mọi thứ là “được hỗ trợ bởi AI” và bật hết lên. Chúng tôi cho rằng đó là lựa chọn sai, đặc biệt đối với phần mềm kỹ thuật. Dữ liệu sai trong một bảng tính chỉ gây khó chịu. Dữ liệu sai trong một sổ đăng ký bản vẽ mà xưởng gia công, phòng mua hàng, và đội chất lượng đều lấy dữ liệu từ đó có thể khiến vật liệu sai bị đặt hàng, phiên bản sai bị gia công, hoặc một số hiệu linh kiện trùng lặp âm thầm hợp nhất hai linh kiện khác nhau. Chi phí của sự sai lệch tăng theo số lượng quyết định ở tầng dưới phụ thuộc vào việc dữ liệu đó đúng — và trong sản xuất, đó là rất nhiều quyết định.

Vì vậy việc phân tier là một hình thức trung thực-qua-thiết-kế: certain nghĩa là “chúng tôi đảm bảo điều này là sự thật”, optional nghĩa là “đây là công cụ giúp một người làm nhanh hơn, và người đó vẫn là bước kiểm tra cuối cùng”. Ngay cả khi một tính năng optional được bật, giao diện vẫn phải gắn nhãn kết quả đầu ra của nó là mang tính hỗ trợ và cần xác minh — việc bật flag không nâng cấp vị thế nhận thức luận của tính năng đó.

Phần còn lại của ngành cũng đang vật lộn với vấn đề tương tự

Chúng tôi không phải người duy nhất kết luận rằng các tính năng hỗ trợ bởi AI trong phần mềm kỹ thuật cần một ranh giới tin cậy rõ ràng. Bình luận về việc áp dụng AI trong PLM cũng đưa ra cùng luận điểm từ phía nhà cung cấp: mục tiêu không phải là loại bỏ phán đoán của kỹ sư, mà là giảm công việc hành chính, làm nổi bật thông tin liên quan, và gắn cờ các vấn đề tiềm ẩn — và AI “không thể được kỳ vọng giải quyết vấn đề mà thiếu quản trị kỷ luật và xác thực của con người” (Supply & Demand Chain Executive, về cách tiếp cận của Aras với AI agent trong PLM). Nghiên cứu về gắn nhãn dữ liệu có hỗ trợ AI đạt tới một kết luận tương tự từ góc độ khác: độ tin cậy được cải thiện khi hệ thống hiển thị độ tin cậy (confidence) thay vì chỉ đưa ra câu trả lời trần trụi, và người dùng (một cách đúng đắn) e ngại tin tưởng đầu ra từ các mô hình hoạt động như hộp đen, không có khả năng quan sát dữ liệu huấn luyện hay kiểm thử (arXiv, về giao diện gắn nhãn dữ liệu có hỗ trợ AI). Sự phân chia certain/optional của Zunavi và ngôn ngữ giao diện “mang tính hỗ trợ, cần xác minh” là câu trả lời của chúng tôi cho chính vấn đề mà các nguồn trên mô tả: hiển thị độ tin cậy và nguồn gốc dữ liệu thay vì yêu cầu người dùng tin tưởng mù quáng vào một kết quả khớp, một lần đọc OCR, hay một điểm số tương đồng.

Cách các flag thực sự được resolve

Flag không chỉ là một boolean đơn giản cho mỗi tính năng. Việc resolve diễn ra theo các lớp: giá trị mặc định tích hợp sẵn của registry (defaultEnabled) là nền tảng, một override ở cấp cơ sở dữ liệu toàn cục có thể đảo ngược nó cho mọi tenant, và một override riêng cho từng tenant có thể đảo ngược nó lần nữa cho một khách hàng cụ thể. FeatureFlagsService.resolveAll(tenantKey) tổng hợp cả ba lớp thành một bản đồ đã resolve duy nhất cho mỗi tenant, được cache trong 30 giây để việc kiểm tra rẻ mà không bị lỗi thời quá lâu. Hình thức triển khai cũng ảnh hưởng đến điều này — Tenant.deployment có thể là ONPREM hoặc CLOUD, và các tenant on-premise mặc định tắt các flag phụ thuộc vào cloud, vì chúng thường đồng nghĩa với việc dữ liệu rời khỏi tổ chức. (Xem thêm trong bài viết về kiến trúc ưu tiên on-premise của chúng tôi.)

Được thực thi hai lần, không chỉ là gợi ý một lần

Điều khiến cơ chế này không chỉ là một quy ước giao diện là nó được kiểm tra hai lần, độc lập với nhau. Ở phía frontend, GET /api/v1/feature-flags trả về bản đồ đã resolve đầy đủ cho tenant hiện tại, và giao diện dùng nó để quyết định hiển thị gì và mở route nào. Nhưng một nút bị ẩn không phải là ranh giới bảo mật — đó chỉ là một gợi ý. Vì vậy cùng quy tắc đó được thực thi lại ở backend: mọi route phụ thuộc vào một năng lực bị khóa đều được gắn @RequireFeature(KEY), được kiểm tra bởi một FeatureFlagGuard toàn cục đăng ký như APP_GUARD. Nếu một request chạm trực tiếp vào endpoint của một tính năng đã bị tắt — flag tắt ở cấp tenant, tính năng chưa được cấp phép, bất kể lý do gì — API trả về 403, chấm hết, bất kể frontend đã hiển thị gì.

Sự thực thi kép đó là điểm khác biệt giữa một feature flag chỉ là tiện ích giao diện và một feature flag là một đảm bảo thực sự. Một tenant đã tắt tìm kiếm tương đồng sẽ không thấy kết quả cache cũ, cũng không chạm được vào một endpoint “vẫn hoạt động phần nào” — cánh cửa đóng ở đúng tầng thực sự quan trọng.

Vị trí của điều này trong bức tranh lớn hơn

Việc phân tier này không phải một chiêu ra mắt gắn với ngày phát hành — Zunavi chưa có ngày phát hành, và bài viết này cũng không đưa ra ngày nào. Đây là một quyết định mang tính cấu trúc được xây dựng ngay trong cách nền tảng được tạo ra, nhằm đứng vững bất kể một tính năng optional cụ thể có được nâng lên certain vào quý tới hay cần thêm một năm tinh chỉnh nữa. Mục tiêu không phải là ra mắt ít tính năng hơn; mà là không bao giờ để giao diện tuyên bố mức độ tin cậy vượt quá những gì năng lực bên dưới thực sự đã đạt được.

---

Đọc thêm: vì sao chúng tôi xây dựng lại sổ đăng ký bản vẽ của Zunavi từ đầu, vì sao Zunavi ưu tiên on-premise, và bài giới thiệu gốc về Zunavi. Bạn có ý kiến về ranh giới certain/optional nên đặt ở đâu cho quy trình làm việc của chính mình? Chúng tôi rất muốn nghe — [email protected].