Hầu hết các dự án BI cho startup thường bắt đầu quá sớm và quá lớn.
Một nhà sáng lập đặt ra một câu hỏi đơn giản: "Người dùng từ kênh này có quay lại sau lần chạy đầu tiên không?" Câu trả lời nên là một truy vấn. Nhưng thay vào đó, nó thường trở thành một dự án nền tảng: kết nối mọi nguồn, xây dựng warehouse, định nghĩa sự kiện, làm sạch danh tính, thiết lập dashboard và chờ đợi.
Công việc đó cuối cùng sẽ quan trọng. Nhưng với một nhóm nhỏ, đó có thể là bước đi sai lầm đầu tiên. Cơ sở dữ liệu sản phẩm đã biết hầu hết những gì nhà sáng lập cần biết. Nó biết ai đã đăng ký, ai đã chạy gì, họ dùng gì, chi phí bao nhiêu, cái gì thất bại và họ có quay lại không.
Vấn đề thực sự không phải là sự thật nằm ở đâu. Mà là làm sao để cho phép một AI agent phân tích sự thật đó mà không để lộ dữ liệu gốc của môi trường sản xuất.
Đó là mô hình chúng tôi sử dụng tại VM0: một nhánh Neon chỉ đọc, đã được che giấu, cung cấp đủ sự thật cho các AI agent chạy BI mà không tiết lộ dữ liệu mà họ không nên thấy.
Vấn đề của nhà sáng lập: câu hỏi đến trước đội dữ liệu
Các công ty giai đoạn đầu không thiếu câu hỏi. Họ thiếu thời gian.
Mỗi ngày, nhóm sáng lập muốn biết những điều như:
- Lưu lượng truy cập hôm qua có chuyển thành người dùng thực không?
- Kênh đăng ký nào tạo ra người thực sự chạy gì đó?
- Người dùng lần đầu có quay lại sau 7 hoặc 30 ngày không?
- Tài khoản trả phí nào đang im lặng?
- Tuyến mô hình nào đang tạo ra chi phí?
- Người dùng thử nghiệm lạm dụng có đốt compute trước khi chuyển đổi không?
- Sức khỏe sản phẩm tốt lên hay xấu đi so với hôm qua?
Không câu hỏi nào trong số này là lạ lẫm. Chúng là nhịp vận hành của một startup.
Nhưng trả lời chúng theo cách BI truyền thống tạo ra rất nhiều công việc phụ. Thường bạn bắt đầu bằng cách chuyển dữ liệu ra khỏi cơ sở dữ liệu sản phẩm sang một hệ thống khác. Sau đó bạn chuẩn hóa, định nghĩa chỉ số, xây dựng lại mối quan hệ và thiết lập dashboard. Nhóm sẽ có một hệ phân tích sạch hơn, nhưng nhà sáng lập thường phải chờ nhiều ngày hoặc tuần cho một câu trả lời lẽ ra chỉ cần một truy vấn SQL.
Với một startup nhỏ, sự đánh đổi đó có thể là ngược lại. Bạn không cần một nền tảng dữ liệu hoàn chỉnh để hỏi những câu hỏi vận hành đầu tiên 20. Bạn cần một cách an toàn để truy vấn nguồn sự thật mà bạn đã có.
Cơ sở dữ liệu đã là nguồn sự thật
Tại VM0, cơ sở dữ liệu sản phẩm chứa các thông tin quan trọng cho nhiều quyết định cấp nhà sáng lập:
- Tổ chức và người dùng
- Trạng thái đăng ký
- Lượt chạy agent và lịch trình
- Tiêu thụ credits và sự kiện sử dụng
- Mô hình được chọn và tuyến nhà cung cấp
- Trạng thái connector
- Trạng thái lỗi và dấu thời gian
Những mối quan hệ này đã có sẵn. Chúng mới hơn bất kỳ dashboard nào phía sau, và phản ánh cách sản phẩm thực sự hoạt động.
Điều này quan trọng vì nhiều câu hỏi BI giai đoạn đầu là dạng quan hệ. Nhà sáng lập không chỉ muốn xem lượt xem trang hay số lượt chạy. Họ muốn kết nối hành vi trên toàn hệ thống:
Trong số người dùng đăng ký từ kênh này, có bao nhiêu người đã chạy gì đó vào ngày đầu, và bao nhiêu người quay lại sau lần chạy đầu tiên?
Hoặc:
Những tổ chức trả phí nào không chạy gì trong 7 ngày qua, và trước đó họ có hoạt động không?
Hoặc:
Tài khoản thử nghiệm mới đã đốt bao nhiêu compute trong 6 giờ đầu, trước và sau khi chúng tôi thay đổi kiểm soát lạm dụng?
Những câu hỏi này nằm tự nhiên trong cơ sở dữ liệu sản phẩm. Chúng trở nên khó hơn nhiều khi mỗi câu trả lời bắt đầu bằng việc chuyển dữ liệu sang một nền tảng riêng biệt.
Lối tắt không an toàn là truy cập sản xuất gốc
Lối tắt hấp dẫn là rõ ràng: chỉ cần để AI agent truy vấn môi trường sản xuất.
Điều đó là không chấp nhận được.
Cơ sở dữ liệu sản xuất có thể chứa những thông tin nhạy cảm nhất của công ty: địa chỉ email, prompt, nội dung chat, thông tin đăng nhập, trạng thái nhà cung cấp đã mã hóa, log, thông báo lỗi, API key và hồ sơ vận hành nội bộ. Dù AI agent có cẩn thận, truy cập gốc vẫn tạo ra vấn đề ranh giới. AI agent có thể thấy quá nhiều. Một sai sót trong truy vấn, báo cáo hoặc ảnh chụp màn hình có thể rò rỉ thông tin mà nhóm không bao giờ muốn lộ ra.
Quyền ghi còn tệ hơn nữa. BI không nên có khả năng thay đổi dữ liệu sản xuất. Một nhà phân tích, dù là người hay AI agent, không nên chỉ cách một lệnh sai là có thể thay đổi dữ liệu người dùng.
Vậy nên câu hỏi không phải là AI agent có thể viết SQL không. Họ có thể. Câu hỏi là bạn có thể cung cấp đủ sự thật để hữu ích mà vẫn giữ quyền riêng tư và an toàn là ràng buộc cứng không.
Với chúng tôi, những ràng buộc đó là cốt lõi:
- AI agent không được thấy prompt gốc.
- AI agent không được thấy email gốc.
- AI agent không được thấy thông tin đăng nhập hoặc bí mật.
- AI agent không được thấy log văn bản tự do nhạy cảm.
- AI agent không được có quyền ghi vào nguồn BI.
- Nhóm sáng lập vẫn phải có khả năng hỏi các câu hỏi vận hành thực tế một cách nhanh chóng.
Đó là hình mẫu hệ thống chúng tôi cần.
Giải pháp an toàn: cơ sở dữ liệu chỉ đọc, đã che giấu
Neon cho phép một mô hình hữu ích vì các nhánh là bản sao rẻ, tách biệt của cơ sở dữ liệu Postgres. Bạn có thể tạo một nhánh giống sản xuất, biến đổi nó và chỉ công khai nhánh đó thay vì môi trường sản xuất.
Tại VM0, chúng tôi dùng cách này để tạo cái gọi là MaskDB.
Luồng thực hiện đơn giản:
- Bắt đầu từ nhánh Neon sản xuất gốc.
- Tạo nhánh mới theo lịch trình.
- Cài đặt PostgreSQL Anonymizer và các công cụ che giấu riêng cho VM0.
- Gắn nhãn bảo mật cho các cột nhạy cảm.
- Chạy ẩn danh hóa tĩnh trên nhánh.
- Áp dụng che giấu tùy chỉnh cuối cùng cho các trường cần xử lý đặc biệt.
- Tạo role
masked_readonlyvới quyền truy cậpSELECT. - Để AI agent truy vấn role đó, không phải sản xuất.
Chi tiết quan trọng là việc che giấu là tĩnh. Giá trị nhạy cảm được viết lại trên nhánh đã che giấu trước khi AI agent kết nối. Điều này khác với việc yêu cầu mọi truy vấn phía sau phải nhớ không chọn gì. Chính nhánh là ranh giới.
Trong MaskDB của chúng tôi, thông tin đăng nhập và bí mật bị loại bỏ. Email và số điện thoại được che một phần. Nội dung người dùng như prompt, tin nhắn chat, prompt lịch trình và kết quả agent bị loại bỏ. Văn bản lỗi được rút gọn thành loại thay vì toàn bộ stack hoặc thông điệp. Các bảng không nên xuất hiện trong phân tích có thể bị loại bỏ hoàn toàn.
Đồng thời, các định danh mờ như org_id, user_id và clerk_user_id vẫn có thể join. Đó là điều làm cho BI khả thi. Chúng tôi không cần AI agent biết địa chỉ email hay nội dung prompt của ai đó. Chúng tôi cần nó biết cùng một tổ chức đã đăng ký, chạy tác vụ, tiêu thụ credits, đăng ký gói, ngừng hoạt động hoặc quay lại sau đó.
Đó là sự cân bằng: che giấu thông tin nhạy cảm, dễ đọc của con người, giữ lại xương sống quan hệ.
AI agent có thể làm gì khi đã có ranh giới
Khi cơ sở dữ liệu chỉ đọc, đã che giấu tồn tại, AI agent có thể trở nên hữu ích rất nhanh.
Nó có thể đặt câu hỏi trực tiếp lên dữ liệu sản phẩm:
- Giữ chân người dùng 7 ngày và 30 ngày
- Kích hoạt từ đăng ký đến lần chạy đầu
- Giữ chân dựa trên lần chạy đầu
- Tổ chức trả phí không hoạt động
- Trạng thái đăng ký và theo dõi churn
- Sử dụng mô hình theo mô hình được chọn
- Tuyến nhà cung cấp tích hợp so với do người dùng chọn
- Tiêu thụ compute thử nghiệm
- Chi phí mỗi lần chạy theo mô hình
- Tỷ lệ lỗi và hoàn thành theo nhóm
Nó cũng có thể kết hợp sự thật từ cơ sở dữ liệu với các hệ thống xung quanh.
Báo cáo Morning Brief của chúng tôi lấy dữ liệu từ Plausible, Axiom, Sentry, Google Ads, GitHub và các nguồn vận hành khác. Cơ sở dữ liệu cho biết người dùng và tổ chức đã làm gì. Plausible cho biết điều gì xảy ra trên trang web. PostHog giúp cung cấp ngữ cảnh sự kiện sản phẩm. Axiom cho biết điều gì xảy ra trong log và đường dẫn yêu cầu. Sentry bắt lỗi. Stripe và Clerk giúp giải thích thanh toán và danh tính. GitHub cho thấy năng suất kỹ thuật.
Điểm mấu chốt không phải là thay thế mọi công cụ bằng SQL. Mà là để AI agent kết nối các sự thật mà nhà sáng lập thực sự quan tâm.
Ví dụ:
Google trả phí gửi nhiều lưu lượng hơn tự nhiên hôm qua. Những người dùng đó có thực sự đến lần chạy đầu, hay dừng ở đầu phễu?
Hoặc:
Chúng tôi đã thay đổi kiểm soát lạm dụng thử nghiệm. Tài khoản thử mới có đốt ít compute hơn trong vài giờ đầu không?
Hoặc:
Tuyến mô hình này rẻ hơn mỗi lần chạy. Điều đó có xuất hiện trong lịch sử chat thực tế, hay chỉ trên lý thuyết giá?
Đây không phải là câu hỏi dashboard. Chúng là câu hỏi vận hành. Chúng thay đổi theo tuần, đôi khi theo ngày. Một AI agent có quyền truy cập cơ sở dữ liệu an toàn có thể trả lời mà không cần kỹ thuật xây dựng view mới mỗi lần.
Ví dụ thực tế: giữ chân và sức khỏe người dùng bên ngoài
Một trong các phân tích nội bộ hàng ngày của chúng tôi xem xét sức khỏe người dùng bên ngoài trong 24 giờ gần nhất.
Báo cáo bắt đầu từ MaskDB, sau đó áp dụng bộ loại trừ nghiêm ngặt. Các tổ chức nội bộ VM0 bị loại bỏ. Các tổ chức spam bị Clerk cấm hoặc khóa cũng bị loại bỏ. Bộ loại trừ này được áp dụng ở mọi nơi, bao gồm cả số đăng ký và nhóm giữ chân, để mẫu số luôn kiểm toán được.
Từ đó, AI agent có thể tạo báo cáo vận hành ngắn gọn:
- Lượt chạy và tổ chức bên ngoài hoạt động
- Tỷ lệ hoàn thành
- Tỷ lệ kích hoạt qua web, CLI, lịch trình và tuyến không phải Zero
- Tỷ lệ mô hình
- Chế độ nhà cung cấp
- Hoạt động tổ chức trả phí
- Tổ chức trả phí không hoạt động
- Đăng ký trả phí mới và tổ chức thử nghiệm
- Theo dõi churn
- Phân khúc người dùng 30 ngày
- Giữ chân từ đăng ký đến chạy
- Giữ chân lần chạy đầu
Đây chính xác là loại báo cáo mà nhóm sáng lập cần. Nó không yêu cầu prompt gốc. Không yêu cầu email gốc. Không cần quyền ghi sản xuất.
Nhưng cần khả năng join đúng các sự kiện sản phẩm.
Trong một lần chạy, AI agent phát hiện một số ít tổ chức bên ngoài hoạt động đang tạo ra phần lớn lưu lượng, một số tổ chức trả phí đã im lặng, và các nhóm đăng ký gần đây có tỷ lệ kích hoạt thấp đột ngột do đăng ký spam làm tăng mẫu số. Đó là những điều nhà sáng lập nên thấy ngay, không phải phát hiện sau nhiều tuần qua dashboard.
Ví dụ thứ hai: kinh tế học lạm dụng thử nghiệm
Dữ liệu sản phẩm đã che giấu cũng hữu ích cho các câu hỏi không phải biểu đồ BI cổ điển.
Khi chúng tôi xem xét lạm dụng thử nghiệm, chỉ số hữu ích không phải là tổng compute tiêu thụ. Tổng chi tiêu sẽ thiên về tài khoản cũ, vì họ có nhiều thời gian tiêu credits hơn. Câu hỏi tốt hơn là:
Một tài khoản mới đốt bao nhiêu compute thử nghiệm trong vài giờ đầu sau đăng ký?
Dùng MaskDB, AI agent đo lượng compute tiêu thụ trong các khoảng thời gian sau đăng ký. Nó dùng tiêu thụ credits từ sự kiện sử dụng, dấu thời gian đăng ký từ metadata tổ chức, và trạng thái đăng ký để tách biệt kinh tế thử nghiệm với sử dụng trả phí.
Sau khi kiểm soát lạm dụng được triển khai, compute thử nghiệm trung bình bị đốt trong những giờ đầu sau đăng ký giảm hơn 80%. Đuôi tiêu thụ lớn gần như biến mất. Ở phân vị 90, compute thử nghiệm trong giờ đầu giảm từ khoảng $4.05 xuống còn khoảng $0.26, giảm 94%.
Con số đó không chỉ là điểm phân tích. Nó thay đổi góc nhìn vận hành doanh nghiệp. Nó cho nhóm sáng lập biết lạm dụng không chỉ được phát hiện, mà kinh tế học của thử nghiệm cũng đang đi đúng hướng.
Và điều đó khả thi vì cơ sở dữ liệu có sự thật, còn nhánh đã che giấu giúp AI agent phân tích an toàn.
Ví dụ thứ ba: chi phí mô hình trong sản phẩm thực tế
Trang giá và bảng benchmark hữu ích, nhưng không trả lời câu hỏi mà nhà sáng lập thực sự quan tâm:
Mô hình này tốn bao nhiêu trong sản phẩm thực, qua các lần chạy thực?
Dùng MaskDB, AI agent so sánh các lần chạy chat lịch sử bằng cách join bản ghi chạy với mô hình được chọn tại thời điểm chạy và tổng hợp credits bị tính từ sự kiện sử dụng.
Sự khác biệt này quan trọng. Bạn không nên quy các lần chạy lịch sử theo nhà cung cấp mặc định hiện tại của người dùng, vì mặc định có thể thay đổi. Mô hình được chọn tại thời điểm chạy mới là nguồn sự thật.
Trong phân tích của chúng tôi, DS v4 Pro có chi phí credits mô hình trung vị cho mỗi lần chạy chat khoảng 49% so với Sonnet. Nói cách khác, lần chạy chat trung vị thực tế rẻ hơn khoảng 51% trên tuyến đó.
Một lần nữa, đây là BI cấp nhà sáng lập. Nó kết nối hành vi sản phẩm, chi phí hạ tầng và chiến lược mô hình. Không cần warehouse mới. Chỉ cần truy cập an toàn vào dữ liệu quan hệ phù hợp.
Đây không phải là giải pháp thay thế warehouse mãi mãi
Sẽ đến lúc công ty cần một hệ dữ liệu chính quy hơn.
Khi chỉ số cần quản trị ngữ nghĩa chặt chẽ, khi nhiều nhóm phụ thuộc cùng định nghĩa, khi việc bổ sung dữ liệu lịch sử trở nên phức tạp, khi dashboard trở thành một phần của hệ vận hành, warehouse hoặc lakehouse có thể là câu trả lời đúng.
Nhưng nhiều startup chọn giải pháp đó quá sớm.
Nếu bạn là nhóm sáng lập nhỏ, hệ BI đầu tiên nên giúp bạn trả lời câu hỏi, không tạo ra một sản phẩm thứ hai để duy trì. Một cơ sở dữ liệu đã che giấu có thể là cầu nối. Nó không phủ nhận việc mô hình hóa dữ liệu là quan trọng. Nó nhận ra rằng cơ sở dữ liệu sản phẩm đã chứa các mối quan hệ bạn cần cho quyết định tiếp theo.
AI agent không thay thế nhu cầu phán đoán. Nó làm cho phiên bản đầu tiên của phân tích rẻ hơn để thực hiện.
Mô hình cho nhóm sáng lập
Mô hình rất đơn giản:
- Xem cơ sở dữ liệu sản phẩm là nguồn sự thật đầu tiên.
- Không bao giờ để lộ dữ liệu sản xuất gốc cho AI agent.
- Dùng nhánh giống sản xuất, không phải bộ dữ liệu mẫu tự tạo.
- Che giấu tĩnh các cột nhạy cảm trước khi truy cập.
- Giữ lại định danh join mờ để phân tích vẫn hoạt động.
- Công khai nhánh qua role chỉ đọc.
- Để AI agent chạy vòng phân tích trên DB đã che giấu và các công cụ liên quan.
Điều này giúp nhóm sáng lập có một hệ vận hành hữu ích mà không cần xây dựng nền tảng dữ liệu đầy đủ ngay từ đầu.
Nó cũng tạo ra tư thế bảo mật sạch hơn. AI agent có ranh giới cứng. Cơ sở dữ liệu mà nó thấy đã được biến đổi. Role mà nó dùng không thể ghi. Báo cáo nó tạo ra có thể bị giới hạn ở định danh băm hoặc tổng hợp.
Đó là sự cân bằng chúng tôi muốn ở VM0: quyền riêng tư và bảo mật là nền tảng, không phải đánh đổi, đồng thời vẫn giúp nhóm sáng lập hiểu doanh nghiệp nhanh hơn nhiều.
Trước khi xây dựng data lake, hãy hỏi liệu một nhánh chỉ đọc, đã che giấu của cơ sở dữ liệu sản phẩm có thể trả lời 20 câu hỏi tiếp theo mà nhóm bạn thực sự có không.
Với chúng tôi, đó là con đường nhanh hơn đến BI.
Nguồn
- Neon, "Create Environments with Masked Production Data Using Neon Branches": https://neon.com/blog/environments-masked-production-data
- Neon fork of PostgreSQL Anonymizer: https://github.com/neondatabase/postgresql_anonymizer
