Một sản phẩm AI nghiêm túc sẽ trông như thế nào?

Các sản phẩm "AI" hiện nay có một vấn đề lớn: chúng dường như không hề nghiêm túc với chính những tuyên bố của mình. Nhìn vào vô số chatbot nịnh bợ tự nhận là công cụ giải quyết vấn đề, ta thấy ngay rằng đây không phải là hình dáng của một công cụ giải quyết vấn đề thực thụ.

Ngay cả trước khi bàn đến những vấn đề đạo đức to lớn của các phòng thí nghiệm tiên phong (frontier lab), chính cách chúng được thiết kế như một sản phẩm đã khiến tôi luôn có cảm giác rằng chúng không phải là phần mềm, mà là một trò lừa đảo — được thiết kế để khiến ta tin rằng mình đang tương tác với một sản phẩm có năng lực mà nó thực sự không có.

Dưới đây là một số tính năng mà theo tôi, một sản phẩm dựa trên LLM — đặc biệt là sản phẩm phục vụ nghiên cứu hoặc phát triển phần mềm — cần có để chứng tỏ nó thực sự nghiêm túc trong việc giúp người dùng làm được những điều hữu ích.

Biến việc "kiểm tra sai sót" thành tính năng hạng nhất

Đây là vấn đề lớn nhất. Ai cũng biết rằng AI không thể cung cấp thông tin một cách đáng tin cậy. Mọi chatbot đều thừa nhận điều này ngay trong dòng chữ nhỏ ở giao diện: Gemini nói "AI có thể mắc lỗi, hãy kiểm tra lại", Claude nói "Claude là AI và có thể mắc lỗi", ChatGPT nói "ChatGPT có thể mắc lỗi, hãy kiểm tra thông tin quan trọng".

Nhưng tất cả những cảnh báo này chỉ là dòng chữ xám nhỏ, rõ ràng được đưa vào để đẩy trách nhiệm về phía người dùng chứ không giúp ích gì. Đây là hạn chế cốt lõi của mọi sản phẩm: việc kiểm tra đầu ra là phần không thể bỏ qua, nhưng lại rất dễ bỏ qua, và người dùng được khuyến khích bỏ qua ở mọi bước.

Một sản phẩm chatbot nghiêm túc sẽ đặt một ô đánh dấu bên cạnh mỗi khẳng định trong đầu ra. Nó sẽ là một bảng hai cột: cột đầu là nội dung do LLM tạo, cột sau là ghi chú của con người giải thích việc kiểm tra đã được thực hiện thế nào, kèm ô đánh dấu chỉ được tích sau khi người dùng tin rằng mình đã kiểm tra kỹ.

Các trợ lý lập trình cũng cần phiên bản tương tự. Hiện nay, việc kiểm tra bị đẩy sang bước review code — một mô hình xấu khuyến khích người "tạo" code đùn việc cho người review mà không hề nhìn qua.

Nếu sản phẩm nói với tôi rằng nó mắc lỗi và tôi phải là người kiểm tra, nhưng lại không cho tôi công cụ nào để kiểm tra, thì tôi không thể coi trọng nó.

Nhiều trích dẫn hơn để kiểm chứng, và nhiều chi tiết hơn

Hầu hết chatbot thích đưa ra câu trả lời hơn là trích dẫn. Khi buộc phải đưa danh sách trích dẫn, chúng thường "chán" giữa chừng và ngừng đưa trích dẫn. Khi có trích dẫn, chúng hiển thị dưới dạng chú thích nội tuyến chỉ ghi tên miền, với phông chữ nhỏ đến mức khó đọc.

Điều này hoàn toàn ngược lại. Nếu bạn yêu cầu AI thực hiện truy vấn nghiên cứu, mọi kết quả nên được trình bày dưới dạng danh sách trích dẫn. Mỗi trích dẫn phải là một đối tượng lớn với siêu dữ liệu rõ ràng: không chỉ nơi tìm thấy mà còn cả ngày xuất bản và tên tác giả nếu có. Trích dẫn nguyên văn (không qua RAG, không phải tóm tắt) phải được đặt ở vị trí trung tâm, lớn hơn mọi văn bản do AI tạo.

Nếu AI muốn tóm tắt, phần văn bản do AI tạo nên được trình bày nhỏ bên dưới trích dẫn, mờ nhạt đi — ít nhất cho đến khi người dùng xác nhận bản tóm tắt là chính xác.

Không dùng ngôi thứ nhất, không xin lỗi

Không có lý do gì để một công cụ phát triển phần mềm hay nghiên cứu dùng ngôn ngữ ngôi thứ nhất để mô tả chính nó. Chúng không nên làm vậy — thậm chí không nên được phép làm vậy.

Cũng không có lý do gì để chúng xin lỗi. Đó là sự lãng phí thời gian của tất cả mọi người: lãng phí cho chatbot khi tạo lời xin lỗi, lãng phí cho người dùng khi đọc nó, và lãng phí khi phải phản hồi lại. Vậy mà chúng luôn xin lỗi mỗi khi bị sửa.

Các nhà cung cấp biết rằng chúng thường xuyên gây ra khủng hoảng sức khỏe tinh thần. Để đối phó, họ thêm những "rào chắn" không hiệu quả, đến năm 2026 vẫn dễ dàng bị vượt qua. Một sản phẩm thực sự muốn giúp tăng năng suất sẽ khắc phục khiếm khuyết rõ ràng này và ngừng tạo ra những lời vô nghĩa.

Giao diện người dùng phi ngôn ngữ tự nhiên

Dù ngôn ngữ tự nhiên có thể là giao diện mạnh mẽ, thực tế cho thấy giao diện LLM bằng ngôn ngữ tự nhiên rất thiếu chính xác và lặp đi lặp lại, đầy những "mê tín" được ngụy trang thành "thực hành tốt nhất".

Cách tiếp cận phổ biến hiện nay là cho chatbot trực tiếp hành động thông qua các "công cụ" qua MCP server. Nhưng điều này cũng ngược lại: nếu ta không thể diễn đạt ý định rõ ràng ngay từ đầu, tại sao lại tin hệ thống này thực hiện những hành động có thể gây hại thay ta?

Thay vào đó, một sản phẩm nghiêm túc sẽ có giao diện riêng cho từng tác vụ cụ thể. Nếu nó được cho là có thể quét bảo mật tìm lỗ hổng OWASP top 10 trong codebase? Hãy có nút bấm cho việc đó. Xây dựng chức năng đó trực tiếp vào model, dùng những model nhỏ hơn có thể đáp ứng hiệu quả hơn.

Chỉ báo nguồn gốc dữ liệu mạnh mẽ

Chatbot tạo ra bảng dữ liệu lấy từ website, API, MCP tool hoặc từ việc tóm tắt và xáo trộn đầu vào của người dùng. Để tạo ảo giác về giao diện liền mạch, dữ liệu này được trình bày chung một định dạng bất kể nguồn gốc.

Nhưng có sự khác biệt khổng lồ giữa dữ liệu từ nguồn có thẩm quyền, dữ liệu do AI tạo ra, và dữ liệu ảo giác. Nếu sản phẩm muốn giúp ta ra quyết định chính xác dựa trên dữ liệu, nguồn gốc dữ liệu là yếu tố then chốt, cần được tích hợp vào quy trình "kiểm tra sai sót" và "xác minh trích dẫn".

Người dùng kiểm soát tốt hơn khả năng tái lập

Hầu hết người dùng không biết đến tham số "temperature" điều khiển mức độ ngẫu nhiên của LLM, vì nó không được hiển thị mặc định trên giao diện. Điều này tạo ra cảm giác chủ quan rằng ChatGPT đã đưa ra câu trả lời có thẩm quyền.

Nếu theo các khuyến nghị trước về giao diện có cấu trúc hơn thay vì trò chuyện dài dòng, có lẽ các phần tử đó cũng có thể phát lại quá trình để người dùng thấy mức độ đáng tin cậy của bot với một tác vụ cụ thể, và hiểu được bản chất ngẫu nhiên của quá trình ảnh hưởng thế nào.

Việc mọi cuộc trò chuyện đều được trình bày như một khung chat phẳng, không cho phép tương tác với các widget đã tạo ra trước đó ngoài việc chat thêm, khiến tôi cảm thấy sản phẩm chỉ đang tối ưu kiểu "tăng thời gian trên trang" như mạng xã hội, chỉ muốn dụ người dùng vào các cuộc trò chuyện lặp lại và không đáng tin cậy.

Khả năng hiển thị ngữ cảnh

Quản lý ngữ cảnh của LLM là thách thức thường trực với các tổ chức dùng quy trình "tác nhân". Nhồi quá nhiều thông tin vào ngữ cảnh gây ra những vấn đề đã biết. Người dùng nâng cao phải chia prompt dài thành "kỹ năng", truy cập thông tin qua "công cụ", và giao phó vấn đề con cho "tác nhân con".

Tuy nhiên, không sản phẩm nào hiển thị ngữ cảnh cho người dùng theo mặc định. Có addon bên thứ ba hiển thị thanh tiến độ đơn giản, nhưng so với thách thức kỹ thuật hàng đầu của công nghệ này thì đó là mức tối thiểu tối thiểu.

Việc thiếu khả năng hiển thị này khiến hầu hết công cụ mở rộng ngữ cảnh đều hoạt động mù quáng. Một sản phẩm nghiêm túc sẽ không chỉ hiển thị "ngữ cảnh khả dụng" mà còn giải thích tác động của việc nén ngữ cảnh, giúp dễ thấy các prompt do harness tạo ra, v.v.

Sandbox thực sự hoạt động

Các công cụ "vòng lặp tác nhân" dùng cho lập trình nguy hiểm không kém, thậm chí hơn thế. Các công cụ lập trình liên tục phá hủy dữ liệu của mọi người qua nhiều năm.

Các sự cố thảm khốc lên trang nhất tương đối hiếm so với lượng sử dụng coding-agent. Nhưng chúng cũng không phải loại vi phạm sandbox duy nhất. Model lập trình thường xuyên sửa code test thay vì hệ thống cần test đến mức có vô số bài "mẹo hay" khuyên chỉ cần yêu cầu tác nhân đừng gian lận. Lời khuyên như "dùng docker container" có thể ngăn nó xóa hệ điều hành, nhưng không ngăn nó phá hủy công việc cục bộ trong codebase.

Trong trường hợp tốt nhất, mọi biện pháp giảm thiểu và proxy và prompt chỉ biến người dùng thành cỗ máy tự động phê duyệt, bấm Y, Y, Y, Y liên tục cho đến khi phát điên và bật chế độ tự động hoàn toàn.

Việc tồn tại một số biện pháp giảm thiểu mà người dùng cực kỳ thận trọng có thể triển khai không thay đổi sự thật rằng "lập trình tác nhân" là công nghệ không an toàn mặc định, được triển khai không quan tâm và không hướng dẫn.

Một phòng thí nghiệm tiên phong thực sự quan tâm cung cấp công cụ hữu ích sẽ gửi đi sản phẩm có bảo mật tích hợp sẵn: sandbox mọi thao tác filesystem và giới hạn nghiêm ngặt mọi việc xóa; bắt buộc snapshot toàn bộ repo sau mỗi thao tác để dễ khôi phục; loại bỏ hoàn toàn chế độ "tự động"; và thiết kế cấu trúc trình bày kế hoạch cho người dùng theo nhóm hành động có thể duyệt theo lô.

Các quy trình con người

Các tổ chức triển khai AI cũng thường tỏ ra thiếu nghiêm túc. Nếu muốn dùng công cụ an toàn, họ cần ít nhất ba loại thay đổi lớn trong quy trình nội bộ:

1. Xoay ca để ngăn suy giảm sự cảnh giác

Đã có nhiều sự cố nổi bật khi việc nhà phát triển dần dần chấp nhận đầu ra LLM gây hậu quả kinh tế nghiêm trọng, điển hình là việc Amazon mất "hàng triệu đơn hàng".

Ngành hàng không có quy định rất nghiêm ngặt về yêu cầu nghỉ ngơi. Các ngành quan trọng về an toàn khác cũng có quy định tương tự. Vậy mà hầu hết đội phần mềm vẫn giao đầy đủ khối lượng tính năng cho mỗi kỹ sư, không dự trù nghỉ ngơi nào, và bảo mọi người review code khi rảnh.

Duy trì sự cảnh giác phải là ưu tiên hàng đầu. Các khoảng nghỉ định kỳ, không thể xâm phạm, khi mọi người làm việc không có AI hỗ trợ và không tiếp xúc với đầu ra AI, là yếu tố then chốt để giữ đầu óc minh mẫn.

2. Luyện tập kỹ năng để ngăn mất kỹ năng

Việc dùng AI dẫn đến phụ thuộc AI, và phụ thuộc AI dẫn đến mất kỹ năng.

Hãy tưởng tượng công nhân bốc xếp cảng biển chuyển sang tự động hóa. Khi còn bốc xếp thủ công, họ vận động liên tục và có thể nâng vật nặng bất cứ lúc nào. Khi chuyển sang ngồi trong buồng điều khiển cần cẩu tự động, họ sẽ yếu đi. Nhưng cần cẩu không hoàn toàn đáng tin cậy — chúng hỏng và làm rơi hàng, và hàng cần được di chuyển thủ công.

Nếu muốn người vận hành cần cẩu có thể nhảy ra bất cứ lúc nào và vẫn di chuyển hàng thủ công được, bạn cần cho họ thời gian đến phòng gym luyện tập. Tổ chức thực hiện chuyển đổi AI cũng cần tăng mạnh ngân sách học tập và phát triển, cả về nguồn lực lẫn thời gian.

3. Nguồn lực sức khỏe tinh thần để đối phó rủi ro

"Loạn thần do AI" thường bắt đầu từ việc giải quyết vấn đề thực tế, và có thể khởi phát cụ thể tại nơi làm việc, chưa kể tình trạng phổ biến hơn là "não bị chiên vì AI".

Nếu bạn buộc nhân viên dùng công cụ nguy hiểm có thể gây tổn hại trực tiếp và nghiêm trọng đến sức khỏe tinh thần, bạn cần đào tạo và nguồn lực. Bạn cần chuyên gia trị liệu nội bộ và phải chủ động kiểm tra để đảm bảo điều đó không xảy ra.

Kết luận

Nếu chỉ một trong những thiếu sót này bị bỏ qua, đó là chuyện bình thường. Nhưng gửi đi sản phẩm mà không có gì trong số đó không phải là quản lý sản phẩm tinh gọn, mà là thái độ bất cẩn với rủi ro và triết lý thiết kế hướng hoàn toàn đến demo ngắn hạn.

Quan trọng hơn, việc tồn tại nhiều năm mà không có bất kỳ tính năng nào như vậy, bất chấp hàng trăm sự cố chứng minh rủi ro, với hàng trăm tỷ đô la tài trợ, khiến tôi nghi ngờ rằng nếu thêm tất cả tính năng khiến sản phẩm thực sự an toàn và hữu ích, chúng sẽ tiết lộ rằng nó thực sự không cải thiện năng suất.

Trong một năm kể từ khi viết về đo lường tỷ lệ chi phí/lợi ích của AI, tôi đã nghe từ nhiều người cho thấy các sáng kiến AI của họ — như gần như mọi sáng kiến AI — hoặc đang thất bại hoặc đang vắt kiệt kỹ sư. Tôi vẫn chưa nghe từ một ai nói rằng "chúng tôi đo theo phương pháp của bạn và hóa ra công việc AI của chúng tôi rất tốt".

Hiện tượng thiếu bằng chứng không phải bằng chứng về sự vắng mặt, nhưng ở thời điểm này tôi cho rằng giả thuyết mặc định nên là: các công cụ AI, xét tổng thể, mang lại giá trị bằng không. Chúng mắc lỗi quá thường xuyên, và những tác động ngoại lai quá tệ và quá khó kiểm soát đến mức ngay cả trước khi nói đến việc chúng đầu độc con người theo nghĩa đen, những ảnh hưởng tiêu cực đến người dùng trực tiếp cũng triệt tiêu mọi lợi ích mà chúng mang lại.

Nếu tôi sai, thì việc đưa vào các công cụ đo lường hiệu quả của AI với tác vụ người dùng thực sự đang cố gắng hoàn thành — thay vì những benchmark vô nghĩa — sẽ cho thấy mức tăng năng suất lớn. Các phòng thí nghiệm tiên phong sẽ háo hức thêm những tính năng đó. Tôi cho rằng họ biết rằng nếu làm vậy, bức tranh hiện ra với người dùng sẽ rất ảm đạm.