Hiện tượng “nhân hóa” đầu ra AI đang lan rộng như thế nào?
Nếu bạn thường xuyên theo dõi các diễn đàn công nghệ như Hacker News hay các kho lưu trữ GitHub đang viral, chắc hẳn đã bắt gặp xu hướng mới: người dùng yêu cầu AI viết văn bản “như đang nói chuyện với người có ADHD” hoặc chỉ sử dụng ASD-STE100 (Simplified Technical English – tiếng Anh kỹ thuật đơn giản hóa). Đây không phải trào lưu ngẫu nhiên, mà là phản ứng tự nhiên trước những đầu ra dài dòng, rườm rà của các mô hình ngôn ngữ lớn.
Thực tế cho thấy ngày càng nhiều người cảm thấy khó chịu với giọng văn “như robot” của AI – những câu trả lời nghe có vẻ chính xác nhưng lại thiếu sự gần gũi, hoặc quá chi tiết đến mức gây choáng ngợp. Phản ứng tự nhiên là họ bắt đầu điều chỉnh prompt, yêu cầu mô hình “humanising LLM outputs” – tức là làm cho kết quả nghe giống người hơn, thân thiện hơn, súc tích hơn.
Nhưng liệu cách tiếp cận này có thực sự hiệu quả? Hay nó đang vô tình tạo ra những vấn đề nghiêm trọng hơn mà chúng ta chưa nhận ra?
Tại sao yêu cầu AI viết “thân thiện hơn” lại phản tác dụng?
Khi bạn yêu cầu một mô hình ngôn ngữ “viết ngắn gọn hơn”, “tránh thuật ngữ chuyên ngành”, hay “chỉ đưa ra thông tin quan trọng nhất”, bạn đang vô tình biến quá trình humanising LLM outputs thành một phần của công việc xử lý chính – thay vì để nó là bước cuối cùng trước khi hiển thị cho người dùng.
Điều này có nghĩa là ngay từ đầu, mô hình đã phải vừa giải quyết vấn đề kỹ thuật, vừa lo “trau chuốt” cách diễn đạt cho dễ nghe. Kết quả là gì? Thông tin bị nén lại, và quá trình nén đó không bao giờ là lossless – luôn có sự mất mát.
8 sai lầm phổ biến khi humanising LLM outputs
| Sai lầm | Hậu quả | Giải pháp đúng |
|---|---|---|
| Yêu cầu “viết ngắn gọn” ngay trong prompt chính | Thông tin quan trọng bị lược bỏ không kiểm soát được | Để AI trả về đầy đủ, sau đó dùng prompt riêng để tóm tắt |
| Bắt subagent viết báo cáo “dễ hiểu” | Parent agent nhận thông tin đã bị nén, quyết định sai | Subagent trả về structured data, chỉ format ở UI layer |
| Áp dụng ASD-STE100 cho toàn bộ pipeline | Agent communication mất độ chính xác kỹ thuật | Chỉ áp dụng simplified technical english ở presentation layer |
| Yêu cầu “tự tin và mượt mà” trong câu trả lời | Che giấu dấu hiệu hallucination và lỗi logic | Giữ nguyên độ chính xác, thêm confidence scores rõ ràng |
| Nén output qua nhiều lớp agent | Mất mát thông tin tích lũy, output cuối vô dụng | Truyền raw data giữa các agent, chỉ render một lần cuối |
| Không lưu bản gốc đầy đủ | Không thể kiểm tra lại hoặc debug khi cần | Luôn giữ high-fidelity output, tạo summary song song |
| Format dữ liệu sớm thành prose | Không thể parse lại hoặc xử lý tự động | Giữ format JSON/structured data đến tầng cuối |
| Trộn lẫn instruction logic với style instruction | Prompt trở nên phức tạp, khó maintain | Tách riêng system prompt và presentation preferences |
Nén thông tin = mất mát dữ liệu quan trọng
Output compression – hay việc nén đầu ra – nghe có vẻ hợp lý khi bạn muốn tiết kiệm thời gian đọc. Nhưng vấn đề nằm ở chỗ: bạn sẽ không bao giờ biết được điều gì đã bị bỏ sót, bởi vì văn bản vẫn “nghe có vẻ ổn”.
Hãy tưởng tượng một agent AI chạy 6 bài test để kiểm tra lỗi. Nếu nó được hướng dẫn viết theo kiểu “thân thiện”, bạn sẽ nhận được câu trả lời kiểu: “Hầu hết các bài test đều pass, có một vấn đề nhỏ cần xem xét thêm.” Nghe rất mượt mà, đúng không? Nhưng thực tế bạn cần là:
- 6 tests ran
- 5 passed
- 1 failed: test_user_auth (line 47, null pointer exception)
- Stack trace: […]
Đó mới là thông tin có giá trị thực sự. Khi bạn yêu cầu simplified technical english ngay từ đầu, bạn đang đánh đổi độ chính xác lấy sự dễ đọc – nhưng trong bối cảnh làm việc với AI, độ chính xác lại là thứ quan trọng nhất.
Khi agent nói chuyện với agent: vấn đề tầng tầng lớp lớp
Vấn đề trở nên nghiêm trọng hơn khi các hệ thống AI bắt đầu giao tiếp với nhau – tức là agent communication. Hình dung một subagent điều tra lỗi, viết báo cáo dưới dạng “tóm tắt dễ hiểu cho con người”, sau đó agent cha đọc báo cáo đó và lại viết thêm một bản tóm tắt khác “dễ hiểu hơn nữa” để gửi cho bạn.
Mỗi lần chuyển đổi như vậy, thông tin lại bị nén thêm một lần. Kết quả cuối cùng có thể là một câu trả lời nghe rất hay, nhưng đã mất đi hầu hết các chi tiết kỹ thuật cần thiết để bạn có thể đưa ra quyết định chính xác.
Những gì bị “đánh mất” khi thực hiện humanising LLM outputs quá sớm
Khi chúng ta ép buộc humanising LLM outputs ngay từ khâu xử lý, có hai điều quan trọng thường bị hy sinh: tính chi tiết và khả năng phát hiện lỗi.
Checklist: Những dấu hiệu cho thấy bạn đang “humanise” sai tầng
Dấu hiệu cảnh báo trong prompt design:
- ☐ Prompt chính có chứa từ “ngắn gọn”, “súc tích”, “dễ hiểu”
- ☐ Bạn yêu cầu AI “chỉ đưa ra thông tin quan trọng nhất” mà không định nghĩa cụ thể “quan trọng” là gì
- ☐ Subagent được hướng dẫn viết báo cáo theo phong cách “thân thiện với người dùng”
- ☐ Không có bản raw output được lưu lại để kiểm tra sau này
- ☐ Agent communication sử dụng natural language thay vì structured data
Dấu hiệu cảnh báo trong output nhận được:
- ☐ Câu trả lời nghe “mượt mà” bất thường, không có điểm chưa chắc chắn nào
- ☐ Thiếu số liệu cụ thể, stack traces, hoặc confidence scores
- ☐ Dùng cụm từ mơ hồ như “một số vấn đề”, “hầu hết trường hợp”
- ☐ Không thể trích xuất dữ liệu để xử lý tự động
- ☐ Khi debug lỗi, không biết thông tin nào đã bị bỏ qua
Dấu hiệu cảnh báo trong kiến trúc hệ thống:
- ☐ Style instructions trộn lẫn với core logic instructions
- ☐ Không có tầng presentation riêng biệt
- ☐ Output formatting xảy ra ở nhiều điểm khác nhau trong pipeline
- ☐ Không có cách để người dùng chuyển đổi giữa “detailed view” và “summary view”
- ☐ Agent không thể “nói chuyện với nhau” bằng dữ liệu chính xác
Khi nào nên hành động: Nếu bạn check được từ 3 mục trở lên trong bất kỳ phần nào, đã đến lúc refactor kiến trúc để tách riêng processing layer và presentation layer.
Kết quả chi tiết vs. câu trả lời “nghe hay”
AI agents thường thất bại theo những cách rất hữu ích: chúng để lộ ra các bằng chứng mâu thuẫn, các nhánh logic chưa được giải quyết, stack traces, hoặc các giả định chưa chắc chắn. Đây là những thông tin vô cùng giá trị nếu bạn muốn hiểu tại sao một vấn đề xảy ra.
Nhưng khi bạn yêu cầu mô hình viết theo lối “con người”, nó sẽ tự động làm mượt những “sự xấu xí hữu ích” đó thành những câu kiểu như: “Có một vài điểm cần cân nhắc thêm ở đây.” Nghe có vẻ chuyên nghiệp, nhưng hoàn toàn vô dụng khi bạn cần debug.
Lỗi bị che giấu sau lớp ngôn từ mượt mà
Một trong những rủi ro lớn nhất của việc humanising LLM outputs quá sớm là nó che giấu các dấu hiệu cảnh báo quan trọng. Khi một agent đang hallucinate (tưởng tượng ra thông tin không có thật) hoặc sắp cạn kiệt token window, bạn cần biết ngay lập tức.
Nhưng nếu prompt đã yêu cầu nó “viết mượt mà và tự tin”, những dấu hiệu đó sẽ bị che đậy bởi các cụm từ làm dịu như “dựa trên phân tích ban đầu” hay “theo hướng tiếp cận phổ biến”. Bạn sẽ cảm thấy yên tâm với câu trả lời, trong khi thực tế nó có thể đang hoàn toàn sai lệch.
Bài học từ các hệ thống kỹ thuật khác: Giữ nguyên dữ liệu thô đến phút cuối
Hầu hết các hệ thống phần mềm chúng ta xây dựng đều hoạt động theo nguyên tắc ngược lại hoàn toàn. Database không lưu trữ dữ liệu theo định dạng mà dashboard hiển thị. Compiler không làm cho intermediate representation (IR) của nó dễ đọc. API không trao đổi các “bản tóm tắt thân thiện” với nhau.
Thay vào đó, các hệ thống này giữ nguyên dạng dữ liệu có độ chính xác cao nhất (high-fidelity) càng lâu càng tốt, và chỉ chuyển đổi nó ở ranh giới – nơi con người tiêu thụ thông tin đó. Đây là nguyên tắc cơ bản trong thiết kế hệ thống, nhưng với các công cụ LLM, chúng ta đang làm ngược lại.
| Hệ thống truyền thống | Nguyên tắc xử lý | AI systems (sai) | AI systems (đúng) |
|---|---|---|---|
| Database → Application | Lưu raw data, format khi query | Prompt yêu cầu “trả về dễ đọc” | Trả structured data, render ở UI |
| API communication | JSON/Protocol Buffers chính xác | Agent gửi prose cho nhau | Agent gửi schemas/diffs cho nhau |
| Compiler pipeline | IR chính xác, chỉ optimize cuối | Nén thông tin qua mỗi bước | Giữ nguyên context, chỉ summarize một lần |
| Logging systems | Log đầy đủ, filter khi hiển thị | “Chỉ log những gì quan trọng” | Log tất cả, người dùng chọn level khi xem |
Tại sao lại như vậy? Bởi vì việc humanising LLM outputs cảm giác giống như một “cải thiện trải nghiệm người dùng” – nhưng thực chất, nó là một quyết định kiến trúc sai lầm khi được áp dụng quá sớm trong pipeline xử lý.
Giải pháp đúng đắn: Xử lý humanising LLM outputs ở tầng hiển thị, không phải tầng xử lý
Vậy chúng ta nên làm gì? Câu trả lời không phải là từ bỏ hoàn toàn ý tưởng humanising LLM outputs, mà là đặt nó đúng vị trí trong kiến trúc hệ thống.
Để agent giao tiếp bằng “ngôn ngữ máy”, chỉ biến đổi khi đến tay người dùng
Cách tiếp cận đúng là để các agent communication diễn ra bằng ngôn ngữ chính xác, hướng máy: schemas, diffs, thông báo lỗi đầy đủ, confidence scores, provenance data. Tất cả những thông tin này nên được giữ nguyên trong toàn bộ quá trình xử lý nội bộ.
Chỉ khi nào thông tin đó chuẩn bị được hiển thị cho người dùng cuối, lúc đó mới thực hiện output compression và chuyển đổi sang ngôn ngữ tự nhiên, dễ hiểu. Điều này có nghĩa là:
- Subagent trả về structured data đầy đủ, không phải prose
- Parent agent làm việc với data đó ở dạng gốc
- Chỉ ở presentation layer, một renderer mới chuyển đổi nó thành “câu trả lời ngắn gọn” hoặc simplified technical english nếu người dùng muốn
Với cách này, bạn không mất mát thông tin, nhưng vẫn có được trải nghiệm dễ chịu khi cần.
Cá nhân hóa và dễ tiếp cận vẫn quan trọng – nhưng đặt đúng chỗ
Cần nhấn mạnh rằng: không ai đang phản đối việc làm cho AI dễ tiếp cận hơn hay cá nhân hóa trải nghiệm. Nếu bạn muốn câu trả lời chỉ gồm 3 dòng, hoặc muốn đầu ra tuân theo simplified technical english, điều đó hoàn toàn hợp lý.
Vấn đề chỉ nằm ở timing. Thực hiện humanising LLM outputs ở tầng hiển thị (như một renderer setting) là khôn ngoan. Nhưng nhồi nhét nó vào prompt chính, khiến nó trở thành một phần của instruction set cốt lõi, thì lại là một sai lầm kiến trúc.
Tương lai của giao tiếp AI-người: Tách biệt logic và giao diện
Những prompt viral kiểu “nói chuyện với tôi như thể tôi có ADHD” thực ra đang chỉ ra đúng hướng đi của tương lai – chỉ là chúng đang được implement sai tầng.
Phiên bản bền vững của agent communication trong tương lai sẽ là: các agent có “ngôn ngữ bản địa” chính xác, hướng máy để trao đổi state với nhau, trong khi phiên bản ấm áp, súc tích, thân thiện dành cho con người chỉ được sinh ra ở ranh giới cuối cùng – nơi output được render ra màn hình.
Điều này không khác gì cách chúng ta xây dựng ứng dụng web: backend xử lý business logic và data ở dạng JSON/SQL, frontend mới lo việc biến nó thành UI đẹp mắt. Không ai lại để backend trả về HTML đã được styled sẵn cả.
Câu hỏi thường gặp về cách tối ưu đầu ra từ LLM
Có nên dùng prompt kiểu “nói chuyện như với người ADHD” không?
Nếu bạn đang làm việc trực tiếp với AI trong vai trò người dùng cuối và chỉ cần câu trả lời nhanh cho riêng mình, thì hoàn toàn có thể dùng prompt như vậy. Nhưng nếu bạn đang xây dựng một hệ thống agent phức tạp, hoặc cần output để làm đầu vào cho các bước xử lý tiếp theo, thì đây là một ý tưởng tồi. Lý do là nó sẽ khiến việc humanising LLM outputs xảy ra quá sớm, dẫn đến mất mát thông tin và che giấu lỗi. Tốt hơn hết là hãy để agent làm việc bằng “ngôn ngữ máy” chính xác, và chỉ format lại output ở bước cuối cùng khi hiển thị cho người dùng.
Làm thế nào để không mất thông tin khi yêu cầu AI rút gọn?
Cách an toàn nhất là tách biệt hai bước: để AI hoàn thành công việc và trả về kết quả đầy đủ, chi tiết nhất có thể (có thể là structured data, JSON, hoặc báo cáo đầy đủ). Sau đó, ở một bước riêng biệt – có thể là một prompt thứ hai hoặc một renderer riêng – bạn mới yêu cầu tóm tắt hoặc rút gọn. Với cách này, bạn luôn có bản gốc đầy đủ để kiểm tra lại nếu cần, đồng thời vẫn có được phiên bản ngắn gọn để đọc nhanh. Đây chính là ý nghĩa thực sự của việc thực hiện output compression đúng cách.
ASD-STE100 có phải lựa chọn tốt cho prompt AI?
ASD-STE100 (Simplified Technical English) là một tiêu chuẩn tuyệt vời được thiết kế để làm cho tài liệu kỹ thuật trở nên rõ ràng, dễ hiểu đối với con người – đặc biệt trong các ngành như hàng không, quốc phòng. Nhưng khi bạn áp dụng nó như một instruction cho agent ngay từ đầu, bạn đang yêu cầu AI tự động loại bỏ các từ phức tạp, hạn chế cấu trúc câu, và đơn giản hóa thông tin – ngay cả khi bản thân AI đang làm việc với dữ liệu phức tạp. Kết quả là agent communication giữa các subagent sẽ mất đi tính chính xác. Thay vào đó, hãy để các agent làm việc với ngôn ngữ kỹ thuật đầy đủ, và chỉ áp dụng simplified technical english khi render output cho người dùng không chuyên.
Kết luận: Prompt “nhân hóa” là tín hiệu sai chỗ đúng ý
Xu hướng yêu cầu humanising LLM outputs thông qua các prompt viral không phải là vô lý – nó phản ánh một nhu cầu thực sự từ người dùng: họ muốn AI nói chuyện dễ hiểu hơn, ít rườm rà hơn, phù hợp với cách họ xử lý thông tin. Đây là một phản hồi hoàn toàn hợp lệ.
Nhưng giải pháp mà người dùng đang tự tạo ra – nhồi nhét các yêu cầu này vào prompt chính – lại đang patch sai tầng. Đó giống như việc sửa bug ở UI bằng cách thay đổi database schema. Nó có vẻ hoạt động, nhưng tạo ra những vấn đề nghiêm trọng ở tầng sâu hơn.
Tương lai đúng đắn của công nghệ này không phải là loại bỏ khả năng cá nhân hóa và output compression, mà là đặt chúng đúng vị trí: ở presentation layer, không phải ở core processing layer. Khi đó, chúng ta sẽ có được cả hai – sự chính xác khi agent communication với nhau, và sự dễ chịu khi con người đọc kết quả. Thực hiện humanising LLM outputs đúng cách không chỉ giúp bảo toàn thông tin mà còn mở ra khả năng kiểm soát tốt hơn cách AI tương tác với người dùng.
Những prompt viral hôm nay thực chất là một bug report tập thể – người dùng đang nói với chúng ta rằng họ cần một cách tốt hơn để kiểm soát cách AI hiển thị thông tin. Và câu trả lời không nằm ở việc hack prompt, mà nằm ở việc thiết kế lại kiến trúc hệ thống theo nguyên tắc humanising LLM outputs tại đúng điểm tiếp xúc với người dùng.