Sự quen thuộc là kẻ thù: Tại sao hệ thống doanh nghiệp thất bại trong 60 năm qua?

Sự quen thuộc là kẻ thù: Tại sao hệ thống doanh nghiệp thất bại trong 60 năm qua?

Hai tuần trước, tôi đã demo một phần sản phẩm mình đang xây dựng cho một giám đốc cấp cao của một tập đoàn toàn cầu — người được giao nhiệm vụ dẫn dắt việc áp dụng AI tại mảng kinh doanh trị giá hàng tỷ USD này. Cuộc trò chuyện của chúng tôi diễn ra ngoài hồ sơ, nhưng những gì họ chia sẻ — và lý do họ không thể mua sản phẩm của tôi — chính là cơ sở cho bài viết này.

Đầu tiên, họ thừa nhận rằng những gì tôi trình bày là lần đầu tiên họ thấy một hệ thống AI cho công việc doanh nghiệp phức tạp trông sẵn sàng để triển khai. Họ có những lo ngại quen thuộc: dữ liệu phải nằm dưới sự kiểm soát của họ (không vấn đề gì, kiến trúc của tôi được thiết kế chính xác xung quanh điều đó).

Tiếp theo, họ kể về những gì các công ty tư vấn lớn đang chào mời: các báo giá lên tới hàng trăm nghìn USD. Các công ty khổng lồ — đối thủ của tôi — đang yêu cầu được trả tiền để xây dựng một sản phẩm hoạt động, trong khi tôi đã demo một sản phẩm hoạt động ngay lập tức.

Sau đó, tôi được biết họ không thể mua từ tôi. Tại sao? Vì rủi ro.

Họ nói rất ngắn gọn: mua từ một công ty nhỏ đổi mới là hành động dũng cảm, còn mua từ một cái tên lớn, được công nhận rộng rãi là một "chính sách bảo hiểm". Người mua e ngại rủi ro phải có bảo hiểm. Sự bảo hiểm đó — quan trọng hơn giá cả và sản phẩm — chính là thứ mà phần mềm doanh nghiệp luôn dựa vào để kinh doanh.

Cuộc trò chuyện này không phải là một trường hợp cá biệt. Nó là hình hài của một thất bại kéo dài sáu mươi năm mà ngành công nghiệp này vẫn gọi một cách êm đềm là "thận trọng".

Kẻ thù được đặt tên

Vào năm 2011, Rich Hickey — người tạo ra ngôn ngữ lập trình Clojure — đã có một bài nói chuyện nổi tiếng mang tên Simple Made Easy (Đơn giản là Dễ dàng). Ông vạch ra sự khác biệt mà phần lớn ngành này vẫn phớt lờ. Đơn giản (Simple) là khách quan: hai thứ đơn giản khi chúng không rối rắm, không móc nối vào nhau. Dễ dàng (Easy) là tương đối: dễ dàng với ai? Dễ dàng là thứ ở ngay bên cạnh, là thứ quen thuộc.

Phần mềm doanh nghiệp đã dành hàng thập kỷ nhầm lẫn hai khái niệm này. Toàn bộ bộ máy lựa chọn công nghệ doanh nghiệp — từ các báo cáo của phân tích viên, các tiêu chí RFP, đến bữa tối của CTO — là một cỗ máy thưởng cho sự quen thuộc. Nó không phải là cỗ máy thưởng cho sự đúng đắn.

Mỗi thất bại được liệt kê dưới đây, và nghĩa trang kéo dài bốn mươi năm chứa đựng chúng, đều có một nguyên nhân cấu trúc giống nhau: người mua mua những gì họ quen thuộc, không phải những gì đúng đắn. Nhà cung cấp trông an toàn đánh bại nhà cung cấp đổi mới. Ngôn ngữ mà ủy ban tuyển dụng nhận biết đánh bại ngôn ngữ sẽ giúp hệ thống dễ bảo trì hơn.

Sự quen thuộc là tiêu chí lựa chọn quan trọng nhất, và đã như vậy từ trước khi tôi sinh ra. Nó đã tốn kém — theo ước tính sơ bộ của tôi — hàng trăm tỷ USD.

Năm cách sự quen thuộc giết chết trí tuệ doanh nghiệp

1. Nhà cung cấp quen thuộc

Microsoft tự hào công bố vào năm 2020 rằng SharePoint có hơn 200 triệu người dùng hoạt động hàng tháng. Nó được triển khai trong hầu hết mọi công ty Fortune 1000. Tuy nhiên, theo lời chính người dùng, nó là một trong những sản phẩm tồi tệ nhất, được mệnh danh là "nơi tài liệu đến để chết".

Sản phẩm thực tế không quyết định doanh số — sự quen thuộc của nhà cung cấp mới là yếu tố quyết định.

2. Ngôn ngữ và kiến trúc quen thuộc

Nhìn vào bất kỳ trang tuyển dụng công nghệ của nhà cung cấp phần mềm lớn nào. Đếm số lần nhắc đến Java, .NET, Azure, Oracle... Sự phân bố này không phải ngẫu nhiên, mà là một chính sách.

Các ngôn ngữ này được chọn không phải vì chúng là công cụ đúng đắn, mà vì "Java" là một từ mà ủy ban thăng chức, kiểm toán viên và cán bộ mua sắm đều có thể giả vờ hiểu. Trong khi đó, "Clojure" hay "Datomic"? Lập tức bị loại vì quá xa lạ.

Tuy nhiên, khi phần mềm được viết bởi các tác nhân AI (AI agents) nhiều như bởi con người, lập luận về ngôn ngữ quen thuộc trở nên yếu hơn bao giờ hết. Một LLM không quan tâm mã của bạn là Java hay Clojure; nó quan tâm đến hiệu quả của mã và tính ổn định về mặt ngữ nghĩa. Trên các trục này, những ngôn ngữ mà ngành công nghiệp chọn vì sự tiện lợi cho con người lại là lựa chọn tồi tệ hơn cho máy móc so với những ngôn ngữ bị loại bỏ vì xa lạ.

3. Quy trình mua sắm quen thuộc

Phần mềm doanh nghiệp không được bán dựa trên kết quả thực tế. Nếu các nhà cung cấp bán sản phẩm dựa trên kết quả (ví dụ: nhận 10% tiền tiết kiệm mà phần mềm tạo ra), họ sẽ chuyển rủi ro triển khai sang bảng cân đối kế toán của chính mình. Thay vào đó, họ bán giấy phép sử dụng công cụ. Họ nhận được biên lợi nhuận gộp 90% ngay từ đầu, và rửa tay khỏi việc công cụ có thực hiện được kết quả kinh doanh hay không.

Người mua sắm hành động một cách hợp lý để bảo vệ bản thân. Họ tìm kiếm các "tín hiệu thị trường hàng kém chất lượng" — sự quen thuộc, vị trí trên Gartner Magic Quadrant, và thương hiệu lớn. Họ mua phiên bản doanh nghiệp của IBM. Nếu nó thất bại (điều thường xuyên xảy ra), người mua sắm vẫn an toàn. Họ có thể nói với ủy ban: "Chúng tôi đã mua tiêu chuẩn ngành".

4. Sự thất bại quen thuộc

Từ năm 1965 đến 1995, các hệ thống chuyên gia (Expert Systems) như Cyc đã tiêu tốn khoảng 200 triệu USD và hoàn toàn thất bại. Đến năm 1997, Booz Allen Hamilton phát hiện rằng 84% các chương trình quản lý tri thức không tạo ra tác động đáng kể nào cho tổ chức.

Những thất bại này là giống hệt nhau. Chúng là thất bại về thời gian và entropy. Các hệ thống này yêu cầu con người cập nhật liên tục, nhưng những người giỏi nhất lại bận rộn làm việc thực tế.

Ngày nay, chúng ta có "chỉ cần thêm AI vào wiki của bạn". Đây là lặp lại sai lầm tương tự. Một wiki không thông minh vì nó không biết thực thể là gì hay các mối quan hệ. Bạn không thể làm cho một đống tài liệu phi cấu trúc trở nên thông minh chỉ bằng cách gắn một mô hình ngôn ngữ vào nó.

5. Stack AI quen thuộc

Vào đầu năm 2023, kiến trúc Retrieval Augmented Generation (RAG) xuất hiện ở khắp nơi. Tuy nhiên, vào tháng 6 năm 2024, các bài kiểm tra độc lập cho thấy tỷ lệ ảo giác (hallucination) lên tới 17-34% ngay cả trên các hệ thống pháp lý đắt tiền nhất.

Microsoft cũng phải thừa nhận rằng GraphRAG — sản phẩm họ bán như câu trả lời AI cho doanh nghiệp — lại tốn kém 1.000 lần khi lập chỉ mục, đến mức phải xây dựng lại từ đầu.

Lỗi sai ở đây là giả định rằng bạn có thể lấy một thư viện tài liệu và làm cho nó thông minh bằng cách đính kèm một mô hình ngôn ngữ. Bạn không thể làm được điều đó. Wiki không phải là thứ bạn thêm AI vào, mà là thứ AI thay thế.

Bẫy hai lựa chọn

Trong bốn mươi năm, ngành này chỉ có hai lựa chọn.

• Lựa chọn 1: Mã hóa cấu trúc bằng tay (Expert systems, ontologies). Bạn có được trí tuệ nếu bạn đủ tiền trả cho một đội ngũ PhD để duy trì nó. Kinh tế học cho thấy bạn không thể.
• Lựa chọn 2: Bỏ qua cấu trúc (Wikis, SharePoint). Bạn có sự chấp nhận vì không ai phải làm việc khó, nhưng bạn không có trí tuệ vì không ai làm việc khó.

Lần đầu tiên, tôi tin rằng có một lựa chọn thứ ba. Một mô hình ngôn ngữ, với sự điều khiển đúng cách, có thể đọc một PDF phi cấu trúc và đề xuất các thực thể, mối quan hệ và sự thật bên trong nó. Con người chỉ cần thả tệp hoặc chuyển tiếp email — sản phẩm phụ của công việc thực tế của họ. Cấu trúc, lần đầu tiên, có thể được tạo ra từ nội dung thay vì được yêu cầu từ con người.

Cái không quen thuộc trông như thế nào?

Vào năm 2013, các nhà sáng lập của Nubank — một ngân hàng kỹ thuật số tại Brazil — đã ngồi xuống với một tờ giấy trắng. Họ quyết định xây dựng ngân hàng bằng Datomic (một cơ sở dữ liệu bất biến) và Clojure. Những lựa chọn này bị coi là điên rồ vì quá xa lạ và không quen thuộc với các tiêu chuẩn doanh nghiệp.

Kết quả? Nubank hiện là ngân hàng kỹ thuật số độc lập lớn nhất thế giới với hơn 100 triệu khách hàng. Họ sở hữu hơn 3.000 cơ sở dữ liệu Datomic và hàng nghìn dịch vụ vi mô. Ngôn ngữ và cơ sở dữ liệu mà không ai có lý trí nào chọn vào năm 2013 giờ đây đang vận hành ngân hàng bán lẻ lớn nhất bán cầu Nam.

Thành công của họ đến từ việc từ chối chọn những gì quen thuộc. Họ xây dựng những gì vấn đề yêu cầu, không phải những gì báo cáo phân tích chỉ ra.

Kiến trúc mà danh mục này yêu cầu

Đây là lúc bài viết này trở thành một lời đề xuất. Tôi đã xây dựng một nền tảng trí tuệ tự lưu trữ (self-hosted) tại Úc, nơi mọi lựa chọn kiến trúc quan trọng đều là một lựa chọn "chống sự quen thuộc".

• Nó được xây dựng trên Clojure, vì tôi tin rằng sự phức tạp ngẫu nhiên trong hệ thống doanh nghiệp là một khoản nợ lũy kế theo thập kỷ.
• Nó được xây dựng trên Datomic, vì việc kiểm toán không phải là tính năng thêm vào, mà là kiến trúc.
• Nó là Graph-native (đồ thị gốc), vì các câu hỏi đa bước (multi-hop) không thể được trả lời bởi sự tương đồng cosine trên các đoạn văn bản.
• Nó có một bộ điều khiển xác định xung quanh các thành phần ngẫu nhiên. Mô hình ngôn ngữ đề xuất, nhưng giàn giáo kiểm chứng.
• Nó được thiết kế để chủ quyền (sovereign) — khách hàng kiểm soát việc triển khai.

Bốn bài kiểm tra cho stack hiện tại của bạn

Trước khi kết thúc, tôi xin đưa ra một chẩn đoán — bốn bài kiểm tra. Nếu nhiều hơn một bài kiểm tra thất bại, cơ sở hạ tầng tri thức của bạn là sản phẩm của sự quen thuộc, không phải sự đúng đắn.

1. Bài kiểm tra phân tích khoảng trống: Hãy hỏi hệ thống: "Rủi ro chiến lược nào của chúng tôi không có biện pháp giảm thiểu liên kết trong bất kỳ danh mục đầu tư nào?" Một cơ sở dữ liệu vectơ không thể trả lời điều này vì nó không thể lý luận về sự vắng mặt. Nó chỉ có thể cho bạn biết cái gì giống rủi ro, không phải cái gì thiếu.
2. Bài kiểm tra giải quyết thực thể: Hệ thống có giải quyết được "JPMorgan Chase & Co.", "JPMC", và "Chase Manhattan" thành một nút duy nhất với bằng chứng có thể kiểm tra được không? Nếu hệ thống chỉ cung cấp điểm tương đồng, đó là thanh tìm kiếm có tham vọng, không phải lý luận.
3. Bài kiểm tra du hành thời gian: Bạn có thể truy vấn hệ thống như nó tồn tại một năm trước không? Nếu không, bạn không có sổ cái kiểm toán, bạn chỉ có một nhật ký chạy quên dần quá khứ.
4. Bài kiểm tra chủ quyền: Nếu một quyền hạn nước ngoài thay đổi lập trường của họ vào ngày mai (kiểm soát xuất khẩu, lưu trữ dữ liệu), quyền truy cập vào cơ sở hạ tầng trí tuệ của chính bạn có thay đổi theo không?

Kết luận

Quản lý tri thức doanh nghiệp đã có bốn mươi năm, một phần tư nghìn tỷ USD và năm thế hệ công nghệ khác nhau để giải quyết vấn đề, nhưng nó đã không làm được. Câu trả lời của năm 2026 — "thêm AI vào wiki" — lặp lại cùng một sai lầm phân loại đã định hình mọi làn sóng trước đó.

Những người xây dựng hiểu điều này sẽ xây dựng những thứ thay thế wiki. Familiarity (sự quen thuộc) là kẻ thù. Chúng ta đã quen gọi sự quen thuộc là sự an toàn. Chúng ta đã sai.