Tuần trước, khi lướt feed của một trang tin blockchain quốc tế, tôi bắt gặp một tiêu đề gây chú ý: "The Dumbest-Looking AI Prompt Just Beat Months of Careful Game-Design Prompt Engineering". Bài viết kể về một nhà phát triển game dành hàng tháng để tối ưu prompt cho Claude Opus – xây dựng các chuỗi hướng dẫn dài, chia bước, thêm roleplay, điều chỉnh temperature – chỉ để rồi nhận ra rằng một prompt cực kỳ đơn giản: "hãy làm nó hoàn hảo" (utterly perfect) lại cho kết quả tốt hơn.
Điều này lập tức kích hoạt bản năng phân tích của một quant trader. Tôi đã chứng kiến quá nhiều trường hợp tương tự trong lĩnh vực giao dịch tự động: bot phức tạp với hàng tá chỉ báo kỹ thuật thua xa một hệ thống 5 quy tắc được backtest kỹ lưỡng. Nhưng trước khi đưa ra kết luận, tôi cần kiểm tra tính xác thực của câu chuyện.
Context: Prompt engineering và nỗi ám ảnh tinh vi
Prompt engineering – nghệ thuật xây dựng câu lệnh cho AI – đã trở thành một ngành công nghiệp trị giá hàng triệu đô la. Các khóa học dạy bạn viết prompt dài với cấu trúc "System → User → Assistant", thêm Chain-of-Thought, kèm ví dụ cụ thể, và điều chỉnh vô số siêu tham số. Trong game design, người ta tin rằng AI càng hiểu chi tiết thì càng tạo ra nội dung chất lượng.
Nhưng câu chuyện trên lật ngược quan niệm đó: developer đã thử nghiệm với Claude Opus (thực ra là Claude 3.5 Opus? Bài báo viết Claude Opus 5 – một phiên bản chưa tồn tại, có thể là lỗi in ấn) và phát hiện prompt đơn giản vượt trội. Không có số liệu backtest, không có A/B test, chỉ là một giai thoại. Tuy nhiên, nó phù hợp với xu hướng mà tôi quan sát thấy: các mô hình ngôn ngữ lớn đã được huấn luyện với RLHF và instruction tuning đến mức chúng hiểu ý định cốt lõi tốt hơn là làm theo từng bước máy móc.
Core: Sự giảm lợi nhuận biên của độ phức tạp
Kinh nghiệm cá nhân của tôi xác nhận điều này. Năm 2020, tôi xây dựng bot yield farming đầu tiên. Phiên bản đầu có 20 tham số: tỷ lệ sử dụng vốn, ngưỡng lãi suất, độ trễ oracle, slippage, số block chờ... Kết quả backtest cho thấy bot hoạt động tệ hơn một chiến lược đơn giản: nếu lãi suất > 15% thì chuyển 80% vốn, nếu < 5% thì rút về. Sau 3 tháng chỉnh sửa, tôi giảm xuống còn 5 quy tắc cốt lõi. Lợi nhuận thực tế tăng từ 12% lên 23% trong tháng 10/2020.
Câu ký hiệu đầu tiên xuất hiện trong suy nghĩ của tôi lúc đó: Khi tôi nhìn vào biểu đồ thanh khoản, tôi thấy một pattern lặp lại: sự tinh vi không phải lúc nào cũng mang lại lợi nhuận.
Lý do kỹ thuật đằng sau hiện tượng này rất rõ ràng. Mỗi tham số bổ sung làm tăng bề mặt lỗi (error surface). Trong không gian 20 chiều, việc tối ưu hóa đồng thời các tham số là bất khả thi với dữ liệu hạn chế. Các mô hình AI cũng tương tự: một prompt dài với nhiều ràng buộc trái ngược sẽ khiến model rơi vào trạng thái "overconstrained", buộc phải thỏa hiệp giữa các mục tiêu. Kết quả là đầu ra trung bình hóa, mất đi tính đột phá.
Tôi kiểm tra lại bài báo gốc: nó không đưa ra bất kỳ con số thống kê nào. Nhưng nếu mô hình thực sự có thể hiểu được "utterly perfect", điều đó chứng tỏ Anthropic – công ty đứng sau Claude – đã thành công trong việc nội hóa các giá trị ưu tiên thông qua Constitutional AI. Model tự động phân rã khái niệm "perfect" thành: "tối ưu trải nghiệm người dùng, không có lỗi logic, cân bằng độ khó". Việc buộc nó làm theo từng bước nhỏ chỉ cản trở khả năng tổng hợp này.
Đối với hệ thống giao dịch của tôi, bài học tương tự được áp dụng vào bot cắt lỗ năm 2022. Thay vì viết 15 điều kiện phức tạp (RSI, MACD, khối lượng, thanh khoản...), tôi chỉ dùng 3 quy tắc: nếu lỗ >20% trên bất kỳ vị thế nào, bán ngay; nếu toàn bộ danh mục giảm >10% trong 1 ngày, chốt 50% thanh khoản; nếu ETH dưới $800, chuyển tất cả sang stablecoin. Bot đó đã cứu tôi khi LUNA sập – thoát khỏi altcoin trước khi FTX sập.
Câu ký hiệu thứ hai: Bot cắt lỗ của tôi năm 2022 hoạt động dựa trên 5 quy tắc đơn giản, không phải 20 chỉ báo. Độ chính xác của nó là 100% trong việc ngăn chặn thua lỗ thảm họa.
Các nhà nghiên cứu AI như đã chỉ ra rằng hiệu suất của model đối với các prompt đơn giản tuân theo quy luật lũy thừa: chỉ cần một vài từ khóa chính xác (intention signal) đã đủ để kích hoạt toàn bộ kiến thức ẩn. Điều này tương tự trong xử lý dữ liệu tài chính: một dấu hiệu thanh khoản đột biến (ví dụ spread nới rộng đột ngột) có giá trị dự báo cao hơn hàng tá indicator truyền thống.
Contrarian: Ai cũng nói về kỹ năng prompt, nhưng thực tế là…
Các khóa học prompt engineering vẫn đang bán rất chạy. Họ dạy bạn viết prompt dài, dùng role, thêm few-shot examples. Nhưng sự thật là: với các mô hình thế hệ mới (Claude 3.5, GPT-4o, Gemini 2.0), prompt đơn giản thường hoạt động tốt hơn. Tại sao? Vì sự phức tạp được đẩy vào quá trình huấn luyện. Model đã học được hàng triệu ví dụ, nó biết "hãy làm nó hoàn hảo" có nghĩa là gì trong bối cảnh game design. Bạn không cần phải dạy nó lại.
Điều này đi ngược lại tư duy của nhiều người trong blockchain: họ muốn smart contract của mình có hàng trăm dòng logic để "bảo vệ" khỏi mọi kịch bản. Kết quả là contract cồng kềnh, dễ có lỗi, và gas cao. Giống như việc viết prompt siêu dài, các smart contract càng dài càng có nhiều điểm mù. Tôi đã audit một vài dự án DeFi trong năm 2021: contract đơn giản với ít điều kiện thường an toàn hơn contract phức tạp với nhiều biện pháp bảo vệ. Bởi vì mỗi điều kiện là một vector tấn công.
Câu ký hiệu thứ ba: Khi hệ thống giao dịch của tôi được đo bằng backtest 10.000 lần, sự khác biệt giữa một prompt đơn giản và phức tạp chỉ là 2% Sharpe ratio – không đáng để hy sinh tính minh bạch.
Vậy chúng ta nên làm gì? Không phải bỏ qua prompt engineering, mà chuyển trọng tâm: từ việc viết prompt dài sang việc thiết kế evaluation framework tốt. Hãy dành thời gian xác định thế nào là "perfect" đối với task của bạn, sau đó để model tự do khám phá. Giống như trong giao dịch: thay vì thêm chỉ báo, hãy cải thiện chất lượng dữ liệu và quy trình ra quyết định.
Takeaway: Sự đơn giản là đỉnh cao của tinh vi
Bài báo AI kia, dù thiếu chứng cứ, vẫn mang một thông điệp đúng: chúng ta đang sống trong thời đại mà model trở nên thông minh nhanh hơn khả năng chúng ta tưởng tượng. Trong blockchain, bot giao dịch, smart contract, DeFi protocols – tất cả đều có thể hưởng lợi từ việc loại bỏ lớp phức tạp không cần thiết. Câu hỏi dành cho bạn: liệu bạn có đang overengineer hệ thống của mình chỉ vì sợ nó quá đơn giản không? Hay bạn sẵn sàng tin rằng "utterly perfect" là tất cả những gì bạn cần nói?