Tối ưu hóa giúp chúng ta làm mọi thứ nhanh hơn, ít tốn kém hơn và hiệu quả hơn, chính vì vậy, tối ưu hóa gần như đã trở thành một phản xạ của thế giới hiện đại. Nếu có thể tạo ra cùng một kết quả với ít thời gian, chi phí hoặc nguồn lực hơn, hệ thống trở nên hiệu quả hơn, tối ưu hóa rõ ràng là điều nên làm. Vấn đề bắt đầu khi chúng ta đi từ một nhận định hợp lý — tối ưu hóa thường tạo ra kết quả tốt — đến một giả định rộng hơn: nếu tối ưu một thứ là tốt, thì tiếp tục tối ưu nó chắc hẳn sẽ còn tốt hơn. Đây là lúc câu hỏi trở nên thú vị: Có nên tối ưu hóa mọi thứ? Nếu tập trung tối ưu một khía cạnh không thực sự cần thiết, hoặc đẩy việc tối ưu đi quá xa, kết quả đôi khi lại phản tác dụng.

Tối ưu hoá mọi thứ là việc cần thiết hay chỉ là “bệnh thành tích”?

Một khía cạnh có thể cải thiện không có nghĩa là nó cần được ưu tiên tối ưu. Nếu đã đáp ứng tốt nhu cầu hoặc không ảnh hưởng đáng kể đến kết quả chung, việc tiếp tục cải thiện có thể tốn nhiều công sức mà mang lại ít giá trị. Và đôi khi, việc cố gắng tối ưu thứ không cần tối ưu, lại trở thành gánh nặng cho hệ thống, hoặc doanh nghiệp.

Ví dụ, một chatbot chăm sóc khách hàng phục vụ hàng trăm dịch vụ có thể cần vài chục công cụ để lấy thông tin từ các hệ thống khác nhau. Nhìn vào số lượng này, chúng ta dễ nghĩ rằng nên gộp lại thành một hoặc hai công cụ cho đơn giản. Tuy nhiên, một công cụ MCP có thể gọi nhiều API phía sau, nên giảm số công cụ chưa chắc đã giảm khối lượng xử lý. Chẳng hạn, khách hàng chỉ hỏi trạng thái hoàn tiền, nhưng công cụ tổng hợp lại yêu cầu backend lấy cả thông tin đơn hàng, thanh toán, ưu đãi và lịch sử hỗ trợ trước khi trả kết quả. Nếu những dữ liệu đó không cần thiết, chúng ta đang tăng số lượt gọi và có thể kéo dài thời gian phản hồi chỉ để chatbot nhìn thấy ít công cụ hơn.

Việc gộp vẫn có giá trị nếu các bước thường xuyên đi cùng nhau và backend có thể xử lý hiệu quả hơn, chẳng hạn gọi song song các API độc lập rồi chỉ trả về thông tin liên quan. Vì vậy, điều cần đánh giá là chatbot có chọn đúng công cụ không, toàn bộ yêu cầu mất bao lâu, tốn bao nhiêu tài nguyên và có trả lời đúng nhu cầu không. Nếu hệ thống hiện tại đáp ứng tốt những yêu cầu này, ép giảm xuống một hoặc hai công cụ có thể chỉ chuyển sự phức tạp sang backend và làm tăng công sức bảo trì. Số lượng công cụ nên là kết quả của thiết kế phù hợp, thay vì trở thành mục tiêu tối ưu riêng.¹

Vậy để tránh được cái bẫy “tối ưu hoá”, chúng ta cần phải làm gì?

Bản thân tối ưu hóa không phải là vấn đề. Nhưng để tối ưu một hệ thống, trước hết chúng ta phải xác định điều gì được xem là “tốt hơn”. Đó có thể là tốc độ nhanh hơn, chi phí thấp hơn, tỷ lệ chuyển đổi cao hơn hoặc số lượng đầu ra nhiều hơn. Ngay khi chọn một mục tiêu, chúng ta cũng đang quyết định hệ thống sẽ tập trung vào điều gì, có thể bỏ qua điều gì và sẵn sàng đánh đổi điều gì để đạt được mục tiêu ấy. Vì vậy, tối ưu hóa không chỉ là tìm ra cách làm tốt hơn, nó còn là lựa chọn thứ gì đáng được cải thiện — và thứ gì nên bỏ lại phía sau trong quá trình đó.

Tối ưu chỉ số nhưng không cải thiện kết quả thực sự

Để tối ưu một hệ thống, chúng ta cần biết kết quả hiện tại đang như thế nào và dựa vào đâu để đánh giá sự cải thiện. Tuy nhiên, những điều chúng ta quan tâm thường khó được phản ánh đầy đủ bằng một con số. Chẳng hạn, một nhóm chăm sóc khách hàng muốn hỗ trợ khách hàng tốt hơn, nhưng chất lượng hỗ trợ còn phụ thuộc vào việc vấn đề có được giải quyết hay không, thông tin có chính xác không và khách hàng có phải liên hệ nhiều lần không. Thời gian xử lý trung bình dễ đo hơn, nhưng chỉ phản ánh một phần của chất lượng đó.

Vì vậy, chúng ta thường sử dụng các chỉ số đại diện để theo dõi và đánh giá. Thời gian xử lý giảm có thể cho thấy quy trình hỗ trợ đang hiệu quả hơn, nếu chất lượng giải quyết vấn đề vẫn được duy trì. Nhưng khi chỉ số này trở thành mục tiêu đánh giá chính, nhân viên có thể tìm cách kết thúc cuộc trò chuyện sớm, dù khách hàng chưa được hỗ trợ đầy đủ. Khi đó, chỉ số được cải thiện nhưng kết quả thực sự lại kém đi.

Đây là vấn đề được nhắc đến trong Goodhart’s Law: khi một thước đo trở thành mục tiêu, nó có thể không còn phản ánh tốt điều chúng ta muốn đo. Cách diễn đạt phổ biến của nguyên lý này gắn với Marilyn Strathern, dựa trên quan sát trước đó của Charles Goodhart.² Khi phân tích các dạng của hiệu ứng Goodhart, David Manheim và Scott Garrabrant cũng chỉ ra rằng hiện tượng này không nhất thiết xuất phát từ hành vi gian lận. Áp lực tối ưu có thể khiến mối quan hệ giữa chỉ số đại diện và mục tiêu thực sự không còn đúng như trong điều kiện ban đầu.³

Trong AI, vấn đề tương tự xuất hiện dưới dạng specification gaming: tác nhân khai thác cách thiết kế nhiệm vụ hoặc phần thưởng để đạt điểm cao mà không thực hiện đúng ý định của người thiết kế. Ví dụ, trong trò chơi đua thuyền được DeepMind dẫn lại, tác nhân phát hiện rằng chạy vòng quanh một khu vực để liên tục thu thập điểm thưởng có lợi hơn việc hoàn thành cuộc đua. Nó tăng được điểm số, nhưng không đạt kết quả mà người thiết kế mong muốn.⁴

Những ví dụ này cho thấy tối ưu một chỉ số chỉ có ý nghĩa khi chỉ số đó vẫn phản ánh kết quả cần đạt. Với chăm sóc khách hàng, thời gian xử lý cần được xem cùng khả năng giải quyết vấn đề và tỷ lệ khách hàng phải liên hệ lại. Với AI, điểm đánh giá cao cần đi kèm việc kiểm tra tác nhân có thực hiện đúng nhiệm vụ hay không. Trước khi tìm cách cải thiện một con số, chúng ta cần xác định con số đó đang phản ánh điều gì và còn bỏ sót điều gì.

Tối ưu quá mức – con dao hai lưỡi

Ngay cả khi chọn đúng mục tiêu, chúng ta vẫn cần xác định nên tối ưu đến mức nào. Nếu chỉ tập trung giảm chi phí hoặc tăng mức sử dụng nguồn lực, phần công suất chưa sử dụng có thể bị xem là lãng phí và bị cắt bỏ. Tuy nhiên, phần dư đó đôi khi chính là khả năng dự phòng để hệ thống xử lý những việc ngoài kế hoạch.

Giả sử hai nhóm có cùng năng lực, một nhóm được phân công công việc chiếm khoảng 60% thời gian, nhóm còn lại là 95%. Nếu chỉ nhìn vào mức sử dụng nguồn lực, nhóm thứ hai có vẻ hiệu quả hơn. Nhưng khi phát sinh sự cố hoặc yêu cầu khẩn cấp, nhóm này gần như không còn thời gian để xử lý nếu không trì hoãn công việc khác hoặc làm thêm giờ. Nhóm thứ nhất có nhiều khoảng trống hơn để thích ứng. Các con số ở đây chỉ nhằm minh họa: điều cần xem xét là phần nguồn lực chưa sử dụng đang thực sự dư thừa hay đang phục vụ nhu cầu dự phòng. Đây cũng là một vấn đề trong resilience engineering, lĩnh vực nghiên cứu khả năng duy trì và điều chỉnh hoạt động của hệ thống trước những thay đổi hoặc gián đoạn. Năng lực dự phòng có thể giúp hệ thống thích nghi khi điều kiện thực tế khác với dự kiến. Vì vậy, loại bỏ phần dư để tăng hiệu quả trong điều kiện bình thường cũng có thể làm giảm khả năng ứng phó khi xảy ra sự kiện bất ngờ.⁶

Việc xác định giới hạn tối ưu còn xuất hiện khi hai mục tiêu cùng có giá trị nhưng cần đánh đổi với nhau. Trong kỹ thuật phần mềm, chúng ta vừa muốn dịch vụ đáng tin cậy, vừa muốn thường xuyên cải tiến sản phẩm. Thay đổi hệ thống có thể gây ra sự cố, nhưng hạn chế mọi thay đổi để tránh sự cố cũng cản trở việc phát triển. Cách Google SRE sử dụng error budget là một ví dụ về việc đặt giới hạn để quản lý sự đánh đổi này. Nhóm vận hành xác định Service Level Objective (SLO), tức mục tiêu về mức độ dịch vụ. Error budget là mức lỗi được phép trong một khoảng thời gian mà dịch vụ vẫn đáp ứng SLO. Khi còn ngân sách lỗi, nhóm có thể tiếp tục triển khai thay đổi với mức rủi ro phù hợp; khi ngân sách đã hết, chính sách có thể yêu cầu tạm dừng những thay đổi không thiết yếu để ưu tiên khôi phục độ tin cậy.⁷

Như vậy, mục tiêu cần được tối ưu trong những giới hạn phù hợp với toàn bộ hệ thống. Giảm chi phí cần tính đến năng lực dự phòng; tăng tốc độ phát triển cần tính đến độ tin cậy. Thay vì mặc định càng giảm hoặc càng tăng một chỉ số càng tốt, chúng ta cần xác định mức nào là đủ và những điều kiện nào phải được duy trì.

Tạm kết

Tối ưu hóa vẫn là điều cần thiết khi giúp giải quyết một vấn đề cụ thể và mang lại lợi ích xứng đáng với công sức bỏ ra. Một quy trình có những bước không còn giá trị thì nên được rút gọn; một hệ thống có thể dùng ít tài nguyên hơn mà vẫn giữ được chất lượng thì nên được cải thiện. Tuy nhiên, việc tối ưu cần đi cùng với đánh giá tác động lên toàn bộ hệ thống, bởi một chỉ số tốt hơn chưa chắc đã đồng nghĩa với kết quả tốt hơn.

Trước khi bắt đầu tối ưu hoá, chúng ta cần làm rõ cần tối ưu điều gì, và đến mức nào. Chúng ta nên tối ưu có chọn lọc, với mục tiêu rõ ràng và giới hạn phù hợp. Có những việc đáng để tiếp tục cải thiện, có những việc chỉ cần đạt mức đủ tốt, và có những việc nên thay đổi cách tiếp cận thay vì cố làm nhanh hơn hay rẻ hơn. Tối ưu hoá là một nghệ thuật, và tối ưu đúng thứ, đúng chừng mực sẽ giúp bạn tối ưu cả cuộc sống của bạn.

Cheers & Peace!

---

Nguồn tham khảo

1. Anthropic, “Writing effective tools for agents — with agents” ↩︎
2. Marilyn Strathern, “Improving Ratings: Audit in the British University System”. ↩︎
3. David Manheim & Scott Garrabrant, “Categorizing Variants of Goodhart’s Law”. ↩︎
4. Google DeepMind, “Specification gaming: the flip side of AI ingenuity”. ↩︎
5. Google DeepMind, “Specification gaming: the flip side of AI ingenuity”. ↩︎
6. Jean Pariès, John Wreathall & Erik Hollnagel, “Resilience Engineering in Practice: A Guidebook“. ↩︎
7. Google, “Site Reliability Engineering Workbook — Error Budget Policy” ↩︎