Nhiều sản phẩm SaaS không còn cạnh tranh với các sản phẩm SaaS khác nữa. Chúng đang cạnh tranh với các stack AI mã nguồn mở có thể kết hợp linh hoạt.
AI mã nguồn mở đã đạt đến mức nhiều công ty không còn cần một gói đăng ký riêng cho mỗi quy trình làm việc hẹp nữa. Thay vào đó, họ có thể lắp ráp một stack linh hoạt gồm các mô hình mở, lớp điều phối, cơ sở dữ liệu, công cụ tự động hóa và giao diện nhẹ để xử lý phần công việc ngày càng lớn mà các công cụ SaaS từng đảm nhận.
Điều này không có nghĩa là SaaS đã chết.
Nó có nghĩa là câu hỏi mặc định đang chuyển từ:
"Chúng ta nên mua công cụ nào?"
sang:
"Chúng ta nên mua cái này, hay tự kết hợp nó với AI mã nguồn mở?"
Đó là một thay đổi lớn.
Và nó đang xảy ra bởi vì hệ sinh thái mã nguồn mở không còn chỉ dành cho các phòng thí nghiệm nghiên cứu, người đam mê, hay các đội ngũ kỹ thuật nặng về hạ tầng. Nó đang trở nên thiết thực cho các startup, đại lý, nhà vận hành và các đội ngũ kỹ thuật muốn kiểm soát nhiều hơn, chi phí biên thấp hơn và ít phụ thuộc vào nhà cung cấp hơn.
Bài viết này khám phá stack AI mã nguồn mở thực sự là gì, tại sao nó bắt đầu thay thế các phần của SaaS, danh mục nào dễ bị tổn thương nhất, một stack hiện đại trông như thế nào, nó thắng ở đâu, vẫn còn thiếu sót chỗ nào, và cách suy nghĩ về việc áp dụng nó mà không biến công ty bạn thành một dự án bảo trì.
Mọi người thực sự muốn nói gì khi họ nói AI mã nguồn mở đang thay thế SaaS
Cụm từ này rất dễ bị phóng đại.
AI mã nguồn mở không thay thế mọi công ty SaaS trong một lần. Nó đang thay thế một tầng lớp ngày càng tăng các sản phẩm dành riêng cho quy trình làm việc, nặng về middleware, nhẹ về giao diện mà giá trị cốt lõi của chúng ngày càng có thể tái tạo được.
Nói một cách thực tế, điều đó bao gồm phần mềm được xây dựng xung quanh các công việc như:
- trả lời câu hỏi dựa trên tài liệu nội bộ
- tóm tắt cuộc họp hoặc bản ghi
- phân loại và định tuyến ticket
- tạo báo cáo hoặc đề xuất
- tự động hóa các tác vụ văn phòng lặp đi lặp lại
- làm giàu lead và dữ liệu CRM
- xây dựng copilot nội bộ
- trích xuất dữ liệu có cấu trúc từ các tài liệu lộn xộn
- tạo trợ lý hỗ trợ khách hàng nhẹ
- kết nối các công cụ thông qua quy tắc và trình kích hoạt
Một số lượng đáng ngạc nhiên các sản phẩm SaaS trong các danh mục này không được bảo vệ bởi các hào sâu trong thiết kế quy trình làm việc. Lợi thế của chúng thường đến từ việc đóng gói, phân phối, UX và lòng tin—chứ không phải từ một cốt lõi kỹ thuật không thể thay thế.
Điều đó quan trọng bởi vì cốt lõi kỹ thuật chính xác là thứ mà AI mã nguồn mở đang làm cho rẻ hơn để sao chép.
Tại sao sự thay đổi này lại xảy ra ngay bây giờ
Đây không chỉ đơn thuần là về các mô hình tốt hơn.
Đó là kết quả của năm thay đổi xảy ra cùng một lúc.
- Các mô hình mở giờ đã đủ tốt cho nhiều tác vụ kinh doanh
Sự bứt phá lớn nhất không phải là các mô hình mở đánh bại các mô hình tiên tiến nhất trên mọi điểm chuẩn.
Mà là chúng không còn cần phải làm vậy nữa.
Đối với nhiều quy trình làm việc kinh doanh, "tốt nhất thế giới" là không cần thiết. Những gì các đội ngũ thực sự cần là:
- đầu ra có cấu trúc nhất quán
- khả năng suy luận chấp nhận được
- khả năng tóm tắt mạnh mẽ
- khả năng truy xuất ngữ nghĩa (retrieval grounding) tốt
- độ trễ chấp nhận được
- quyền riêng tư và kiểm soát triển khai
Ngưỡng đó thấp hơn nhiều so với những gì sự cường điệu về mô hình tiên tiến gợi ý.
Trong nhiều trường hợp sử dụng, các mô hình mở đã vượt quá ngưỡng đó.
- Cơ sở hạ tầng xung quanh các mô hình đã trưởng thành
Một mô hình đơn lẻ không thay thế một công cụ SaaS.
Một mô hình cộng với:
- lớp suy luận (inference)
- giao diện
- hệ thống truy xuất
- logic tự động hóa
- ghi nhật ký
- phân quyền
- lưu trữ
- đánh giá
bắt đầu trông giống như một sản phẩm.
Hệ sinh thái xung quanh là thứ làm cho stack mã nguồn mở trở nên khả thi.
- Sự gia tăng SaaS (SaaS sprawl) đã trở nên đắt đỏ và lộn xộn về mặt vận hành
Các đội ngũ đang kiệt sức với việc xếp chồng các gói đăng ký.
Mỗi công cụ mới đều giới thiệu:
- một hóa đơn khác
- một hệ thống đăng nhập khác
- một quy trình đánh giá nhà cung cấp khác
- một kho dữ liệu riêng biệt khác
- một bề mặt tích hợp khác
- một quyết định gia hạn khác
Khi một stack mã nguồn mở có thể thay thế ba đến sáu công cụ có phạm vi hẹp, thì kinh tế học bắt đầu thu hút sự chú ý nhanh chóng.
- Các quy trình làm việc gốc AI (AI-native) có thể kết hợp được theo thiết kế
SaaS truyền thống thường giả định các quy trình làm việc cố định.
Các stack AI mã nguồn mở khuyến khích sự kết hợp.
Điều đó có nghĩa là các công ty ngày càng có thể xây dựng các hệ thống phù hợp với hoạt động thực tế của họ thay vì buộc các hoạt động phải phù hợp với các giả định phần mềm được xây dựng sẵn.
- Kiểm soát đang trở nên chiến lược
Nhiều đội ngũ hơn hiện nay quan tâm sâu sắc đến:
- dữ liệu của họ sống ở đâu
- họ phụ thuộc vào nhà cung cấp mô hình nào
- chi phí sử dụng ở quy mô lớn là bao nhiêu
- liệu họ có thể chuyển đổi nhà cung cấp hay không
- liệu hành vi sản phẩm AI của họ có thể kiểm tra được hay không
Các stack mã nguồn mở cung cấp khả năng kiểm soát theo cách mà nhiều sản phẩm SaaS không thể.
Các danh mục SaaS dễ bị tổn thương nhất trước AI mã nguồn mở
Không phải tất cả SaaS đều dễ bị tổn thương như nhau.
Các danh mục dễ bị tổn thương nhất thường có bốn đặc điểm chung:
- quy trình làm việc mang tính lặp đi lặp lại
- giao diện tương đối mỏng
- "trí thông minh" chủ yếu là chuyển đổi văn bản hoặc định tuyến
- sản phẩm có thể được tái tạo bằng cách kết hợp các mô hình, prompt, truy xuất và tự động hóa
Các danh mục dễ bị tổn thương nhất
- Trợ lý tri thức nội bộ
Nhiều đội ngũ hiện nay xây dựng hệ thống chat-qua-tài-liệu nội bộ nhanh hơn so với việc họ có thể đánh giá các công cụ tri thức AI doanh nghiệp.
- Công cụ viết và tóm tắt AI
Nếu sản phẩm cốt lõi là "nhận văn bản đầu vào, tạo ra văn bản tốt hơn đầu ra", thì rào cản để sao chép đã giảm mạnh.
- Copilot hỗ trợ cơ bản và bot FAQ
Một khi việc truy xuất, rào chắn (guardrails) và chuyển tiếp (escalation) được xử lý tốt, nhiều trường hợp sử dụng hỗ trợ không còn đủ phức tạp về mặt kỹ thuật để yêu cầu một nhà cung cấp chuyên biệt.
- Công cụ tự động hóa quy trình làm việc có lớp AI
Một phần đáng kể các sản phẩm "tự động hóa AI" đang bị thách thức bởi sự kết hợp của các hệ thống điều phối mã nguồn mở, API và các mô hình cục bộ hoặc được lưu trữ.
- Trợ lý làm giàu lead và nghiên cứu
Các công cụ này vẫn cần sự tuân thủ và tìm nguồn cung ứng cẩn thận, nhưng một phần lớn quy trình làm việc hiện có thể được tái tạo với dữ liệu mở, các pipeline scraping phù hợp, API làm giàu và tóm tắt AI.
- Phần mềm trích xuất và phân loại tài liệu
Đây là một danh mục lớn.
Đối với nhiều quy trình làm việc tài liệu có cấu trúc, các đội ngũ hiện có thể kết hợp OCR, pipeline trích xuất, logic xác thực và LLM để thay thế các giải pháp điểm đắt tiền.
Các danh mục ít bị tổn thương hơn
Một số SaaS vẫn có khả năng phòng thủ cao hơn vì nó phụ thuộc vào:
- phân phối độc quyền
- tuân thủ chuyên biệt
- hiệu ứng mạng lưới
- quy trình làm việc được quản lý
- tích hợp sâu, nhúng
- lòng tin và khả năng kiểm toán ở quy mô doanh nghiệp
- tập dữ liệu độc đáo hoặc hệ thống hồ sơ vận hành
Nói cách khác, AI mã nguồn mở mạnh nhất khi vấn đề là trí thông minh quy trình làm việc (workflow intelligence), chứ không phải khi hào phòng thủ là lòng tin thể chế, phân phối, hoặc sức nặng hạ tầng.
Stack AI mã nguồn mở hiện đại thực sự trông như thế nào
Khi mọi người nói "stack AI mã nguồn mở", họ thường mô tả nó một cách quá chung chung.
Trong thực tế, nó thường bao gồm các lớp.
- Lớp mô hình (Model layer)
Đây là nơi trí thông minh ngôn ngữ hoặc đa phương thức tồn tại.
Các lựa chọn điển hình bao gồm:
- LLM trọng số mở để suy luận và tạo sinh
- mô hình cục bộ nhỏ hơn để phân loại và trích xuất chi phí thấp
- mô hình chuyên biệt để nhúng (embedding), phiên âm, OCR, hoặc xếp hạng lại (reranking)
Sự thay đổi chính là mô hình không còn là toàn bộ sản phẩm. Nó chỉ là một lớp trong một hệ thống lớn hơn.
- Lớp suy luận (Inference layer)
Đây là runtime thực sự phục vụ mô hình.
Các mẫu hình phổ biến bao gồm:
- runtime cục bộ để thử nghiệm và quy trình làm việc riêng tư
- máy chủ suy luận tự lưu trữ cho các đội ngũ
- nhà cung cấp mô hình mở được lưu trữ khi không cần quản lý GPU
Lớp này quyết định chi phí, tốc độ, độ phức tạp vận hành và tình trạng bảo mật.
- Lớp truy xuất và dữ liệu (Retrieval and data layer)
Đây là thứ biến một mô hình chung chung thành một công cụ kinh doanh.
Các thành phần điển hình:
- Postgres hoặc bộ lưu trữ có cấu trúc khác
- tìm kiếm vector để truy xuất ngữ nghĩa
- kho tài liệu và bộ lưu trữ đối tượng
- hệ thống siêu dữ liệu và lọc
- bộ kết nối dữ liệu và pipeline tiếp nhận
Một phần lớn sự hữu ích của sản phẩm AI đến từ lớp này, chứ không phải mô hình cơ sở.
- Lớp điều phối (Orchestration layer)
Lớp này kiểm soát cách hệ thống hoạt động.
Nó quyết định:
- khi nào gọi một mô hình
- sử dụng mô hình nào
- cách truy xuất ngữ cảnh
- khi nào gọi công cụ
- cách xâu chuỗi các bước với nhau
- cách xử lý lỗi và thử lại
Đây là nơi các nền tảng tự động hóa, công cụ quy trình làm việc và giàn giáo tác nhân (agent scaffolds) trở nên có giá trị.
- Lớp giao diện (Interface layer)
Đây là thứ người dùng thực sự chạm vào.
Nó có thể là:
- giao diện chat
- bảng điều khiển (dashboard)
- tiện ích mở rộng trình duyệt
- công cụ quản trị nội bộ
- bot Slack
- endpoint API
- màn hình quy trình làm việc dựa trên biểu mẫu
Một lý do chính khiến các stack mã nguồn mở có thể cạnh tranh là nhiều công cụ kinh doanh không yêu cầu giao diện người dùng đặc biệt phức tạp để mang lại giá trị.
- Lớp quan sát và đánh giá (Observability and evaluation layer)
Đây là sự khác biệt giữa một món đồ chơi và một hệ thống đáng tin cậy.
Bạn cần biết:
- những prompt nào đã chạy
- ngữ cảnh nào đã được truy xuất
- các yêu cầu mất bao lâu
- chi phí suy luận là bao nhiêu
- cái gì đã thất bại
- liệu chất lượng đầu ra đã được cải thiện hay suy giảm
Khi các sản phẩm AI trưởng thành, lớp này đang trở thành một trong những phần quan trọng nhất về mặt chiến lược của stack.
Một ví dụ thực tế về stack thay thế nhiều công cụ cùng một lúc
Hãy xem xét một nhóm bán hàng hoặc vận hành nhỏ.
Trước đây, họ có thể phải trả tiền riêng cho:
- phiên âm cuộc họp
- tóm tắt AI
- làm giàu CRM
- tìm kiếm nội bộ
- soạn thảo đề xuất
- tự động hóa quy trình làm việc
- tìm kiếm tài liệu hỗ trợ
Một stack mã nguồn mở hiện đại có thể kết hợp phần lớn những thứ đó vào một hệ thống nội bộ duy nhất.
Ví dụ:
- mô hình phiên âm hoặc API cho các cuộc gọi
- kho tài liệu cho sách hướng dẫn (playbooks), bản ghi và đề xuất
- truy xuất vector để tìm kiếm kiến thức
- công cụ quy trình làm việc để định tuyến các bản tóm tắt vào CRM
- mẫu prompt để tạo bản nháp theo dõi
- bảng điều khiển hoặc giao diện chat để nhóm truy cập
- lớp đánh giá để đo lường chất lượng câu trả lời và độ tin cậy của quy trình làm việc
Một stack duy nhất đó có thể thay thế nhiều công cụ hẹp trong khi cung cấp cho nhóm nhiều quyền kiểm soát hơn đối với định dạng đầu ra, lựa chọn mô hình và hành vi chi phí.
Đây chính xác là lý do tại sao nhiều danh mục SaaS dễ bị tổn thương.
Không phải vì AI mã nguồn mở mạnh về mặt lý thuyết.
Mà là vì nó ngày càng có thể thu gọn nhiều giao dịch mua phần mềm thành một hệ thống có thể kết hợp duy nhất.
Các mẫu hình stack AI mã nguồn mở phổ biến nhất hiện nay
Các đội ngũ khác nhau áp dụng các phiên bản stack khác nhau tùy thuộc vào mức độ trưởng thành và mục tiêu.
Mẫu hình 1: Stack của nhà xây dựng đơn lẻ (The solo builder stack)
Điều này phổ biến trong số các hacker độc lập, nhà sáng tạo kỹ thuật và nhà tư vấn.
Các thành phần điển hình:
- runtime mô hình cục bộ hoặc chi phí thấp
- cơ sở dữ liệu đơn giản
- công cụ tự động hóa quy trình làm việc
- frontend nhẹ
- một lớp truy xuất
- một mục tiêu triển khai
Stack này được tối ưu hóa cho tốc độ và kỷ luật chi phí.
Mẫu hình 2: Stack công cụ nội bộ khởi nghiệp (The startup internal tools stack)
Điều này phổ biến cho các công ty xây dựng copilot nội bộ hoặc tự động hóa quy trình.
Các thành phần điển hình:
- lớp mô hình được lưu trữ hoặc tự lưu trữ
- Postgres + hỗ trợ vector
- tiếp nhận tài liệu
- xác thực và kiểm soát truy cập theo vai trò
- công cụ quy trình làm việc
- ghi nhật ký và theo dõi
- bảng điều khiển quản trị
Stack này được tối ưu hóa để tạo đòn bẩy nội bộ nhanh chóng.
Mẫu hình 3: Stack đại lý hoặc nhà vận hành (The agency or operator stack)
Mẫu hình này thường được sử dụng bởi các đại lý thay thế nhiều công cụ SaaS định kỳ cho chính họ hoặc khách hàng.
Các trường hợp sử dụng điển hình:
- nghiên cứu lead
- tạo đề xuất
- tự động hóa báo cáo
- trợ lý hỗ trợ khách hàng
- quy trình làm việc nội dung
- hệ thống tiếp nhận và định tuyến
Stack này được tối ưu hóa để tái sử dụng qua các dự án.
Mẫu hình 4: Stack thay thế SaaS AI dạng sản phẩm (The productized AI SaaS replacement stack)
Đây là khi một nhóm không chỉ sử dụng stack nội bộ mà còn biến nó thành một sản phẩm.
Tại thời điểm đó, stack thường bổ sung thêm:
- thanh toán
- đa đối tượng thuê (multi-tenancy)
- phân quyền chi tiết
- giám sát mạnh mẽ hơn
- quy trình làm việc phản hồi và QA
- quản trị dữ liệu chặt chẽ hơn
Đây là nơi sự kết hợp mã nguồn mở trở thành mối đe dọa trực tiếp đối với các công ty SaaS AI-first.
Các công cụ liên tục xuất hiện trong các stack này
Stack cụ thể thay đổi liên tục, nhưng một số danh mục xuất hiện nhiều lần.
Các khối xây dựng phổ biến theo lớp
Lớp
Các lựa chọn mã nguồn mở điển hình
Tại sao chúng quan trọng
Mô hình
LLM trọng số mở, mô hình nhúng, bộ xếp hạng lại
Chất lượng suy luận và truy xuất cốt lõi
Suy luận
Ollama, vLLM, runtime tự lưu trữ, API mô hình mở
Chi phí, quyền riêng tư, tính linh hoạt khi phục vụ
Cơ sở dữ liệu
Postgres, pgvector, lưu trữ tài liệu/đối tượng
Bộ nhớ có cấu trúc và ngữ nghĩa
Tự động hóa
n8n và các công cụ quy trình làm việc tương tự
Kết nối các hệ thống và giảm thao tác thủ công
Lớp ứng dụng
Next.js, React, bảng điều khiển nội bộ, API
Bề mặt sản phẩm nhẹ
Giao diện chat/tìm kiếm
Open WebUI, giao diện tùy chỉnh
Truy cập nhanh vào quy trình làm việc AI nội bộ
Khả năng quan sát
Langfuse, công cụ theo dõi, nhật ký tùy chỉnh
Độ tin cậy, chất lượng và tốc độ lặp lại
Xác thực/Backend
Supabase, xác thực tùy chỉnh, lớp DB được quản lý
Lắp ráp sản phẩm nhanh chóng
Đánh giá
Kiểm tra prompt, bộ hồi quy, chấm điểm theo tiêu chí
Ngăn chặn suy giảm chất lượng âm thầm
Điểm quan trọng không phải là tên thương hiệu chính xác của từng công cụ.
Điểm quan trọng là mọi lớp chính hiện đều có các lựa chọn mã nguồn mở hoặc tiêu chuẩn mở đáng tin cậy.
Đó là điều thay đổi phương trình xây-dựng-vs-mua.
Tại sao các nhóm chọn con đường mã nguồn mở ngay cả khi SaaS dễ dàng hơn
Thoạt nhìn, SaaS trông vẫn đơn giản hơn.
Nó thường là vậy.
Vậy tại sao ngày càng nhiều nhóm chọn con đường khó khăn hơn?
Bởi vì trong những tình huống thích hợp, con đường khó khăn hơn lại tốt hơn về mặt chiến lược.
- Chi phí dài hạn thấp hơn
Một gói đăng ký trông có vẻ rẻ.
Bảy gói đăng ký chồng chéo thì không.
Stack mã nguồn mở thường có chi phí thiết lập cao hơn và chi phí biên thấp hơn, đặc biệt đối với các nhóm đã có sẵn nhân tài kỹ thuật.
- Tùy chỉnh tốt hơn
Hầu hết các quy trình làm việc AI không giống hệt nhau giữa các nhóm.
Các công cụ SaaS thường buộc các nhóm vào một quy trình làm việc trung bình.
Các hệ thống được kết hợp cho phép các nhóm mã hóa logic, prompt, phê duyệt và hành vi truy xuất của riêng họ.
- Quyền riêng tư và kiểm soát dữ liệu
Nhiều doanh nghiệp ngày càng cảm thấy không thoải mái khi gửi dữ liệu nội bộ nhạy cảm qua một chuỗi các công cụ của bên thứ ba khi họ có thể tự lưu trữ hoặc quản lý phần lớn stack.
- Ít bị khóa vào nhà cung cấp hơn
Các stack mã nguồn mở giúp việc chuyển đổi các thành phần dễ dàng hơn.
Bạn có thể thay đổi:
- nhà cung cấp mô hình
- chiến lược suy luận
- lớp UI
- công cụ tự động hóa
- quy trình đánh giá
mà không cần xây dựng lại toàn bộ hệ thống từ đầu.
- Vòng lặp học tập nhanh hơn
Khi bạn sở hữu stack, bạn sẽ học được nơi quy trình làm việc thực sự bị hỏng.
Điều đó thường có giá trị hơn là mua một lớp trừu tượng được đánh bóng quá sớm.
Nơi SaaS vẫn chiến thắng rõ ràng
Một phân tích chín chắn cũng phải nói điều này một cách thẳng thắn:
Có nhiều trường hợp SaaS vẫn là quyết định thông minh hơn.
SaaS vẫn chiến thắng khi bạn cần:
- triển khai ngay lập tức với nỗ lực kỹ thuật tối thiểu
- tuân thủ, SLA và sự sẵn sàng của bộ phận mua hàng
- hỗ trợ doanh nghiệp và trách nhiệm giải trình rõ ràng
- trải nghiệm người dùng được đánh bóng cao cho các nhóm phi kỹ thuật
- tích hợp độc quyền sâu
- quy trình làm việc không đủ chiến lược để biện minh cho việc sở hữu tùy chỉnh
- một hệ thống hồ sơ (system of record) thay vì một lớp quy trình làm việc
Đây là lý do tại sao các nhà vận hành giỏi nhất không giáo điều.
Họ không thay thế SaaS vì mã nguồn mở là mốt.
Họ thay thế SaaS khi các yếu tố kinh tế, khả năng kiểm soát và tính linh hoạt của sản phẩm cho phép.
Sai lầm lớn nhất mà các nhóm mắc phải khi áp dụng AI mã nguồn mở
Họ cố gắng thay thế quá nhiều, quá sớm.
Điều đó thường tạo ra một trong hai kết quả tồi tệ.
Kết quả 1: stack trở thành một dự án khoa học nội bộ
Nhóm dành hàng tháng trời để lắp ráp cơ sở hạ tầng trước khi mang lại giá trị kinh doanh.
Kết quả 2: họ tung ra một nguyên mẫu mong manh và nhầm nó với một sản phẩm
Quy trình làm việc hoạt động trong các bản demo, nhưng bị hỏng khi sử dụng thực tế vì khả năng quan sát, phân quyền, đánh giá và logic phục hồi đã bị bỏ qua.
Cách đúng đắn để áp dụng stack này không phải là xây dựng lại toàn bộ stack phần mềm của bạn từ đầu.
Đó là bắt đầu với một quy trình làm việc duy nhất nơi:
- chi phí SaaS là rõ ràng
- quy trình làm việc mang tính lặp đi lặp lại
- logic có thể giải thích được
- ROI của việc kiểm soát là cao
Đó là nơi AI mã nguồn mở hoạt động tốt nhất.
Một cách thông minh hơn để áp dụng stack
Các nhóm mạnh nhất thường tuân theo một trình tự.
Bước 1: Xác định một quy trình làm việc có ma sát cao
Các ví dụ tốt:
- tìm kiếm nội bộ qua tài liệu và bản ghi
- tạo báo cáo lặp đi lặp lại
- đánh giá và làm giàu lead
- soạn thảo hỗ trợ
- trích xuất tài liệu
Bước 2: Chỉ xây dựng lại lớp trí thông minh trước
Đừng thay thế mọi thứ.
Bắt đầu bằng cách thay thế phần có chi phí cao nhất hoặc kém linh hoạt nhất.
Bước 3: Thêm khả năng quan sát sớm hơn bạn nghĩ là cần thiết
Ghi lại:
- đầu vào
- đầu ra
- ngữ cảnh truy xuất
- lỗi
- chi phí
- độ trễ
Nếu không có điều này, bạn sẽ không biết liệu hệ thống có đang tốt hơn hay không.
Bước 4: Giữ giao diện đơn giản
Một giao diện cơ bản hoạt động tốt còn hơn một giao diện phức tạp làm trì hoãn việc ra mắt.
Bước 5: Chứng minh giá trị kinh doanh trước khi mở rộng stack
Một khi một quy trình làm việc hoạt động, hãy mở rộng một cách cẩn thận.
Đây là cách một stack AI mã nguồn mở trở thành đòn bẩy vận hành thay vì là kịch kỹ thuật (technical theater).
Mối đe dọa cạnh tranh thực sự đối với SaaS không phải là mô hình
Đó là sự kết hợp (composition).
Đó là ý tưởng chiến lược mà nhiều người vẫn bỏ lỡ.
Các công ty SaaS không bị đe dọa chủ yếu bởi một mô hình tốt hơn.
Họ đang bị đe dọa bởi một thế giới nơi các công ty ngày càng có thể tự kết hợp các hệ thống của họ từ:
- mô hình mở
- cơ sở hạ tầng mở
- tự động hóa linh hoạt
- cơ sở dữ liệu hàng hóa (commodity databases)
- giao diện nhẹ
- các lớp prompt và đánh giá có thể tái sử dụng
Một khi điều đó trở nên bình thường, trọng tâm sẽ dịch chuyển.
Sản phẩm chiến thắng không còn tự động là sản phẩm có bảng điều khiển đẹp nhất.
Nó có thể là sản phẩm dễ thích nghi nhất, rẻ nhất để chạy và ít gây đau đớn nhất để tích hợp vào các quy trình làm việc hiện có.
Điều đó thay đổi đáng kể lĩnh vực cạnh tranh.
Điều này có nghĩa là gì đối với các nhà sáng lập và nhà vận hành
Nếu bạn đang xây dựng hoặc mua phần mềm ngay bây giờ, bài học thực tế rất đơn giản.
Bạn nên ngừng coi mọi vấn đề quy trình làm việc AI là một vấn đề mua sắm phần mềm.
Đôi khi nó vẫn là vậy.
Nhưng ngày càng nhiều, đó là một vấn đề thiết kế stack (stack design problem).
Điều đó có nghĩa là những câu hỏi đáng để đặt ra là:
- Quy trình làm việc này có đủ chiến lược để sở hữu không?
- Chúng ta có đang trả giá SaaS cho thứ gì đó hiện có thể tái tạo được không?
- Một stack nội bộ có thể kết hợp có thay thế được vài công cụ điểm không?
- Hào phòng thủ thực sự nằm ở nhà cung cấp, hay chỉ ở tốc độ thực thi và cách đóng gói?
- Chúng ta cần một sản phẩm bên ngoài được đánh bóng, hay chỉ một hệ thống nội bộ đáng tin cậy?
Các nhóm đặt ra những câu hỏi đó một cách tốt sẽ đưa ra các quyết định công nghệ tốt hơn nhiều trong vài năm tới.
Suy nghĩ cuối cùng
Stack AI mã nguồn mở không thay thế tất cả SaaS.
Nhưng nó đang thay thế đủ để buộc thị trường phần mềm phải bước vào một thực tế mới.
Ngày càng nhiều công cụ không còn an toàn chỉ vì chúng tiện lợi.
Nếu giá trị cốt lõi của chúng có thể được xây dựng lại từ các mô hình mở, truy xuất, điều phối, lưu trữ và một giao diện mỏng, thì danh mục của chúng đang chịu áp lực—dù họ có thừa nhận hay không.
Điều đó không có nghĩa là mọi công ty nên vội vàng tự lưu trữ mọi thứ.
Nó có nghĩa là giả định cũ—mua trước, chỉ xây dựng nếu thực sự cần thiết—đang yếu đi.
Trong các quy trình làm việc nặng về AI, một giả định mới đang xuất hiện:
kết hợp trước khi logic có thể tái tạo, mua khi lòng tin, quy mô hoặc độ phức tạp thực sự biện minh cho điều đó.
Đó là sự thay đổi.
Và đối với một phần lớn phần mềm hiện đại, nó chỉ mới bắt đầu.
