Thành thật mà nói, mỗi khi thấy ai đó ca ngợi dự án oracle là "tương lai nhất định sẽ như thế này thế kia", tôi đều có thói quen lùi lại — không phải là dự án đó có vấn đề gì, mà đơn giản là tôi không muốn bị chính sự chắc chắn của mình cắn trả.

Giờ đây thói quen của tôi đã đảo ngược: xem mọi hạ tầng cơ sở như "một hệ thống chắc chắn sẽ gặp sự cố vào một ngày nào đó" để đánh giá. Nghe có vẻ bi quan, nhưng tôi nghĩ đây chính xác là thái độ trung thực nhất. Không phải nhìn vào khi nó vận hành trơn tru thì rực rỡ ra sao, mà là xem khi nó sụp đổ thì có thể đứng vững hay không — thứ gọi là oracle, lỗi không bao giờ là sự kiện có xác suất nhỏ, chỉ là mức độ lớn nhỏ khác nhau. Vấn đề nhỏ có thể cách ly, còn một sự cố lớn có thể đe dọa tính mạng.

Tại sao tôi lại nói điều này? Bởi vì AI kết hợp với oracle, trực tiếp mở rộng phạm vi rủi ro. Oracle truyền thống chủ yếu bị mắc kẹt ở chỗ "nguồn giá bị thao túng", nhưng loại dự án xử lý dữ liệu phi cấu trúc này còn tiềm ẩn nhiều nguy cơ hơn: thông tin bị nhiễm độc, giả mạo đã tồn tại từ trước, văn bản bị dẫn dắt một cách tinh vi, thành kiến của mô hình bản thân. Nói trắng ra, nó không chỉ dễ dàng bị lợi dụng hơn, mà cách mắc lỗi cũng đa dạng hơn. Vì vậy, logic của tôi là ngược lại — đừng vội ca ngợi, hãy nghĩ trước rằng nó sẽ gặp sự cố, rồi xem nó có khả năng tự cứu hay không.

Phán đoán của tôi là, để oracle tồn tại lâu dài, rào cản mạnh nhất không phải là độ chính xác của suy luận, mà là khả năng phản ứng khẩn cấp. Nói cách khác, sau khi xuất sai, nó có thể nhanh chóng cắt lỗ, có thể đổ trách nhiệm, có thể rollback, có thể kiểm tra lại, cuối cùng vẫn khiến nhà phát triển tin tưởng và tiếp tục sử dụng.

Tôi đặc biệt quan tâm đến ba vấn đề thực tế:

Thứ nhất là khi chứng cứ ngoài chuỗi mâu thuẫn nhau, nó có dám đưa ra quyết định không? Tôi thà nó xuất ra độ tin cậy thấp, thậm chí từ chối thanh toán và giải thích lý do, còn hơn là vì muốn thể hiện "quyết đoán" mà cố gắng đưa ra kết quả.