Khi các công cụ Generative AI trở nên phổ biến, “prompt engineering” cũng nhanh chóng trở thành một kỹ năng được nhắc đến ở khắp nơi. Chỉ cần tìm kiếm một chút, chúng ta có thể bắt gặp hàng loạt công thức: yêu cầu AI “đóng vai chuyên gia”, hướng dẫn nó suy nghĩ theo từng bước, hay sử dụng những mẫu prompt dài hàng chục dòng với kỳ vọng tạo ra kết quả tốt hơn. Những kỹ thuật này có giá trị nhất định. Nhưng nếu đã sử dụng AI đủ lâu, chúng ta cũng dễ nhận ra một điều: prompt càng dài chưa chắc câu trả lời càng tốt. Có lúc một yêu cầu rất chi tiết vẫn cho ra kết quả chung chung; ngược lại, một câu ngắn nhưng được đặt trong đúng ngữ cảnh lại có thể cho kết quả rất sát nhu cầu.

Nguyên nhân là chất lượng đầu ra không chỉ phụ thuộc vào cách chúng ta viết câu lệnh. AI còn cần biết đang giải quyết vấn đề gì, có những thông tin nào để làm việc, kết quả được dùng vào đâu và thế nào được xem là một kết quả tốt.¹² Hiểu đơn giản, làm việc hiệu quả với AI không phải là tìm ra một câu prompt hoàn hảo, mà là quá trình xác định bài toán, cung cấp thông tin, giao nhiệm vụ, xem kết quả, kiểm tra và tiếp tục điều chỉnh. Vì vậy, thay vì chỉ hỏi “Làm thế nào để viết prompt tốt hơn?”, một câu hỏi hữu ích hơn là: Làm thế nào để tổ chức việc tương tác với AI để nó hiểu đúng bài toán, có đủ thông tin để xử lý và chúng ta có thể phát hiện khi kết quả chưa đáng tin?

Nếu ở những bài trước, Lemon’s Tribe đã đi vào prompt engineering – cách diễn đạt yêu cầu – và context engineering – cách lựa chọn, tổ chức thông tin để AI có đủ dữ liệu làm việc, thì bài này đứng ở một lớp rộng hơn. Trọng tâm không còn là tối ưu từng prompt hay từng context riêng lẻ, mà là cách thiết kế toàn bộ quá trình tương tác với AI, từ lúc xác định bài toán cho đến khi kiểm chứng và sử dụng kết quả. Hãy cùng Lemon’s Tribe tìm hiểu trong bài viết này nhé. Leggo!

Bạn cần làm gì trước khi prompt?

Giả sử chúng ta mở ChatGPT, Claude hay Gemini và nhập:

Phân tích funnel này giúp tôi.

AI vẫn có thể trả lời. Nhưng trước khi phân tích, nó phải tự suy đoán hàng loạt thứ: mục tiêu của funnel là gì, vấn đề nào đang cần tìm, chỉ số nào quan trọng, đâu là mức biến động đáng chú ý và kết quả phân tích sẽ được sử dụng để làm gì. Càng có nhiều khoảng trống như vậy, AI càng phải tự bổ sung bằng những giả định có vẻ hợp lý. Vì thế, cùng một yêu cầu có thể được viết lại thành:

Phân tích funnel dưới đây để xác định ba bước có tỷ lệ rơi lớn nhất. Với mỗi bước, hãy tính tỷ lệ rơi, tách riêng những gì có thể quan sát trực tiếp từ dữ liệu và những giả thuyết cần kiểm chứng. Sau đó đề xuất thêm dữ liệu cần thu thập để kiểm tra từng giả thuyết. Không tự giả định những số liệu chưa được cung cấp.

Điểm quan trọng ở đây không phải prompt thứ hai dài hơn. Khác biệt nằm ở chỗ bài toán đã được xác định rõ hơn: cần tìm gì, phạm vi phân tích đến đâu và đâu là ranh giới giữa dữ liệu thực tế với suy luận.

Điều này đặc biệt quan trọng trong Product. Nếu yêu cầu AI “đề xuất cách tăng conversion”, nhưng chưa xác định conversion đang giảm ở đâu, nhóm người dùng nào bị ảnh hưởng hay nguyên nhân đã biết là gì, AI rất dễ nhảy thẳng từ hiện tượng sang giải pháp. Kết quả có thể nghe hợp lý nhưng chưa chắc giải quyết đúng vấn đề. Vì vậy, trước khi chỉnh prompt, nên kiểm tra một bước cơ bản hơn: chúng ta đã xác định đủ rõ bài toán cần AI giải quyết chưa?

Khi câu trả lời không tốt, hãy kiểm tra context trước

Ngay cả khi bài toán đã rõ, AI vẫn chỉ có thể làm việc dựa trên những thông tin mà nó có. Giả sử chúng ta yêu cầu AI đánh giá một PRD. Nếu chỉ đưa cho nó phần mô tả tính năng mà không có mục tiêu kinh doanh, nhóm người dùng, hạn chế kỹ thuật hay các quyết định trước đó của đội ngũ, AI có thể đưa ra những đề xuất hoàn toàn hợp lý về lý thuyết nhưng không phù hợp với sản phẩm thực tế. Trong trường hợp này, thêm câu “hãy phân tích thật kỹ” không giải quyết được vấn đề. AI không thiếu sự cẩn thận; nó thiếu thông tin. Đây là lý do khái niệm context engineering ngày càng được nhắc đến nhiều hơn bên cạnh prompt engineering. Nếu prompt engineering tập trung vào việc chúng ta yêu cầu AI làm gì, context engineering tập trung vào việc AI cần biết gì trước khi thực hiện yêu cầu đó.

Tuy nhiên, đưa càng nhiều thông tin vào cũng không đồng nghĩa với kết quả càng tốt. Nghiên cứu Lost in the Middle cho thấy khi context trở nên dài, khả năng sử dụng thông tin của mô hình không đồng đều; thông tin nằm giữa một context dài có thể được khai thác kém hơn thông tin ở đầu hoặc cuối.³

Hiểu đơn giản, vấn đề không phải là cung cấp nhiều context nhất có thể, mà là cung cấp đúng context cần thiết cho nhiệm vụ. Với một người làm Product, điều này có thể đơn giản là chọn đúng tài liệu trước khi yêu cầu AI làm việc. Phân tích phản hồi người dùng thì cần nội dung phản hồi và cách phân loại hiện tại; đánh giá roadmap thì cần mục tiêu, ràng buộc và dữ liệu về sản phẩm; viết tài liệu kỹ thuật thì cần kiến trúc và quy ước của hệ thống. Đổ toàn bộ kho tài liệu vào một cuộc hội thoại không đảm bảo AI sẽ hiểu vấn đề tốt hơn.

Bài toán càng phức tạp, càng nên chia thành nhiều bước

Một lỗi khác khá phổ biến là cố đưa toàn bộ công việc vào một prompt: “Đọc research này, tìm insight, xây strategy, đánh giá rủi ro, tạo roadmap và viết presentation cho management.”. AI có thể làm tất cả những việc trên trong một lượt và tạo ra một kết quả trông rất hoàn chỉnh. Vấn đề chỉ xuất hiện khi chúng ta muốn kiểm tra xem kết quả đó có đúng không. Nếu phần tổng hợp research sai, strategy được xây trên đó cũng có thể sai. Nếu strategy sai, roadmap tiếp tục kế thừa sai lệch đó. Một lỗi ở đầu quá trình vì thế có thể lan xuống toàn bộ phần còn lại mà người dùng rất khó nhận ra. Đây là lúc việc chia nhỏ bài toán trở nên quan trọng. Nghiên cứu về Least-to-Most Prompting cho thấy mô hình có thể xử lý một số bài toán phức tạp tốt hơn khi bài toán được tách thành các vấn đề nhỏ và giải quyết lần lượt.⁴

Trong Product, thay vì yêu cầu AI đi thẳng từ dữ liệu đến giải pháp, chúng ta có thể chia thành bốn bước:

• Trước hết, yêu cầu AI chỉ xác định những gì có thể quan sát trực tiếp từ dữ liệu.
• Từ những quan sát đó mới xây dựng các giả thuyết có khả năng giải thích hiện tượng.
• Sau đó xác định dữ liệu hoặc thử nghiệm cần thiết để kiểm tra từng giả thuyết.
• Cuối cùng, khi đã có đủ bằng chứng, mới bắt đầu bàn đến giải pháp.

Mạch xử lý khi đó trở thành:

Dữ liệu → Quan sát → Giả thuyết → Kiểm chứng → Giải pháp.

Mỗi bước mà AI thực hiện sẽ tạo thành một node để con người có thể kiểm tra. Chúng ta có thể hỏi: quan sát này có thực sự xuất phát từ dữ liệu thực không? Giả thuyết này dựa trên quan sát nào? Đề xuất này phụ thuộc vào giả định nào? Thay vì nhận một câu trả lời hoàn chỉnh từ một chiếc hộp đen, chúng ta có thể nhìn thấy cách kết quả được hình thành và can thiệp trước khi một sai lệch nhỏ trở thành một quyết định lớn.

Khi mô tả bằng lời chưa đủ, hãy đưa ví dụ

Có những yêu cầu rất khó diễn đạt chính xác chỉ bằng hướng dẫn, đặc biệt khi kết quả mong muốn phụ thuộc vào cách hiểu hoặc quy ước riêng của từng nhóm. Ví dụ, một đội ngũ có thể muốn AI phân loại phản hồi người dùng theo hệ thống nội bộ; viết nội dung theo một cấu trúc cố định; hoặc đánh giá tài liệu dựa trên những tiêu chí riêng. Trong những trường hợp như vậy, chỉ mô tả bằng lời thường chưa đủ, vì cùng một khái niệm có thể được hiểu theo nhiều cách khác nhau. Trong trường hợp này, đưa ra ví dụ cụ thể cho AI thường hiệu quả hơn. Đây chính là nguyên lý của few-shot prompting: đưa cho mô hình một số ví dụ đầu vào và đầu ra để nó suy ra quy luật hoặc cách trình bày mong muốn. Các hướng dẫn về prompting của OpenAI và Google đều khuyến nghị sử dụng ví dụ khi cần giúp mô hình hiểu rõ hơn về cấu trúc hoặc cách thực hiện nhiệm vụ.^{5 6}

Ví dụ, nếu muốn AI phân loại phản hồi thành BUG, UX và FEATURE, thay vì viết một đoạn dài giải thích từng nhóm, chúng ta có thể đưa một vài trường hợp:

“Ứng dụng bị crash khi quét QR” → BUG
“Tôi không hiểu cách dùng tính năng này” → UX
“Nên cho phép lưu địa điểm yêu thích” → FEATURE

Khi đó AI không chỉ nhận được định nghĩa, mà còn nhìn thấy cách chúng ta áp dụng định nghĩa vào trường hợp thực tế.

Tuy nhiên, ví dụ cũng có thể tạo thành khuôn mẫu quá cứng. Nếu toàn bộ ví dụ đều là những trường hợp rất rõ ràng, AI có thể xử lý kém khi gặp dữ liệu nằm giữa hai nhóm. Vì vậy, với những bài toán phân loại hoặc đánh giá, nên có cả ví dụ điển hình lẫn một số trường hợp khó phân biệt.

Làm kỹ các bước trên, giờ có thể thoải mái tin những gì AI tạo ra? Bạn chắc chưa?

Sau khi AI tạo ra một kết quả tương đối tốt, chúng ta thường có xu hướng dừng lại ở đó. Nhưng đây cũng là lúc AI có thể được sử dụng cho một vai trò khác: phản biện chính kết quả vừa tạo ra. Giả sử bạn đang cân nhắc một chiến lược sản phẩm, thay vì hỏi: “Phương án nào tốt nhất?”, bạn có thể yêu cầu AI tạo ra ba phương án dựa trên các cơ chế khác nhau, chỉ ra ưu nhược điểm của từng phương án, sau đó tìm lập luận mạnh nhất để phản đối chính những phương án đó. Tương tự, sau khi có một kế hoạch, có thể đặt một giả định: “Giả sử sáu tháng sau kế hoạch này thất bại. Những nguyên nhân hợp lý nhất có thể là gì?”. Mục đích không phải để AI tự chứng minh rằng nó sai. Mục đích là tạo thêm những hướng suy nghĩ để người dùng kiểm tra một kết luận từ nhiều phía trước khi hành động. Một số hướng nghiên cứu về reasoning, chẳng hạn self-consistency hay Tree of Thoughts, cũng khai thác ý tưởng tạo và đánh giá nhiều hướng suy luận thay vì phụ thuộc hoàn toàn vào một chuỗi suy luận duy nhất.^{7 8}

Trong công việc hằng ngày, chúng ta không nhất thiết phải áp dụng nguyên xi các phương pháp nghiên cứu này. Bài học thực tế đơn giản hơn: kết quả đầu tiên chỉ nên được xem là một phương án, không phải mặc định là đáp án cuối cùng.

Với Product, đây là cách AI có thể tạo giá trị vượt ra ngoài việc viết nội dung. Nó có thể giúp mở rộng không gian lựa chọn, tìm các trường hợp biên, đặt câu hỏi ngược và làm lộ ra những giả định mà chúng ta chưa nhận thấy.

Khi AI thiếu thông tin, đừng bắt nó đoán

Trong quá trình tương tác với AI, sẽ có lúc bạn hướng dẫn, đưa ngữ cảnh đầy đủ nhưng AI vẫn không tạo ra được câu trả lời đáp ứng được nhu cầu. Lỗi không hẳn đến từ AI, mà đến một mức độ nào đó, chất lượng tương tác không thể chỉ cải thiện bằng prompt hoặc context. Vậy lý do đằng sau là gì?

Lý do khá đơn giản: language model tạo ra ngôn ngữ, trong khi nhiều nhiệm vụ thực tế cần tương tác với thế giới bên ngoài. Muốn biết thông tin mới nhất, cần tìm kiếm. Muốn kiểm tra số liệu, cần truy vấn dữ liệu hoặc tính toán. Muốn kiểm tra một chính sách, cần đọc nguồn gốc. Muốn thực hiện hành động trong hệ thống, cần API hoặc công cụ tương ứng. Chính vì vậy, nghiên cứu ReAct là một trong những công trình quan trọng, đặt việc suy luận và hành động trong cùng một quá trình: mô hình không chỉ tạo ra suy luận từ kiến thức sẵn có mà còn có thể tương tác với nguồn thông tin bên ngoài để tiếp tục giải quyết nhiệm vụ.⁹

Hiểu đơn giản, nếu hỏi AI một thông tin mới nhưng không cho nó tìm kiếm, chúng ta đang yêu cầu nó nhớ. Nếu cho phép AI tìm kiếm và kiểm tra nguồn, chúng ta đang cho nó tra cứu. Tương tự, nếu chỉ yêu cầu AI tính toán bằng ngôn ngữ, chúng ta đang dựa vào khả năng suy luận của mô hình; nếu cho nó sử dụng công cụ tính toán, chúng ta đang trao cho AI một năng lực phù hợp hơn với nhiệm vụ.

Đây cũng là nền tảng của RAG, tool use và các hệ thống agent: thay vì giới hạn AI trong những gì mô hình đã biết, chúng ta mở rộng khả năng của nó bằng dữ liệu và công cụ bên ngoài. Khi đó, AI không chỉ trả lời câu hỏi mà còn có thể thu thập thông tin, xử lý dữ liệu và thực hiện hành động.

Nhưng việc trao thêm năng lực cũng thay đổi bản chất của rủi ro. Một chatbot trả lời sai có thể khiến người dùng hiểu nhầm. Một agent có quyền gọi API, gửi email hay thay đổi dữ liệu mà đưa ra quyết định sai có thể tạo ra hậu quả thật. Vì vậy, câu hỏi tiếp theo không còn chỉ là “AI có thể làm được gì?”, mà còn là “chúng ta kiểm soát việc nó làm những điều đó như thế nào?”

Trao quyền càng nhiều, dây cương “harness” càng phải đủ chặt

Đây là vai trò của harness: tập hợp các cơ chế bao quanh mô hình để giới hạn cách AI hoạt động, cung cấp công cụ phù hợp, kiểm tra kết quả và quyết định khi nào AI được phép tiếp tục hành động.

Một trong những yếu tố khiến harness phải xuất hiện trong vòng làm việc của AI là do một đặc điểm của language model: AI có thể bịa ra câu trả lời, mặc dù nghe có vẻ rất hợp lý. NIST gọi hiện tượng mô hình tạo ra nội dung sai hoặc không có cơ sở nhưng trình bày như thông tin đúng là confabulation, và xem đây là một nhóm rủi ro cần được quản lý trong Generative AI.¹⁰

Bên cạnh đó, một yếu tố khác đến từ việc model AI có thể làm rất tốt một số nhiệm vụ nhưng thất bại ở những nhiệm vụ khác tưởng như khá tương đồng. Hiện tượng này được gọi là “jagged technological frontier”. Trong thí nghiệm này, người sử dụng AI đạt kết quả tốt hơn khi nhiệm vụ nằm trong vùng năng lực của AI, nhưng có thể cho kết quả kém hơn khi sử dụng nó cho những nhiệm vụ nằm ngoài vùng đó.¹¹

Vấn đề vì thế không thể được giải quyết bằng cách đơn giản hỏi lại AI: “Bạn có chắc không?”. Nếu cùng một mô hình vừa tạo ra kết luận vừa tự xác nhận kết luận đó, chúng ta vẫn đang phụ thuộc vào cùng một nguồn sai lệch. Một harness tốt cần tạo ra những cơ chế kiểm tra độc lập hơn. Ví dụ như, code có thể được chạy test, phép tính có thể được kiểm tra bằng công cụ tính toán, số liệu có thể được đối chiếu với nguồn dữ liệu, thông tin thực tế có thể yêu cầu dẫn nguồn. Chặt chẽ hơn nữa, những hành động có rủi ro cao có thể cần xác nhận của con người trước khi thực thi, hoặc quyền truy cập công cụ cũng có thể được giới hạn theo đúng phạm vi mà agent cần để hoàn thành nhiệm vụ.

Hiểu nôm na là tool giúp mở rộng những gì AI có thể làm; harness quyết định AI được làm đến đâu và làm thế nào để chúng ta biết kết quả có đáng tin hay không. Hai yếu tố vì vậy phải phát triển cùng nhau. Nếu chỉ trao thêm công cụ mà không tăng khả năng kiểm soát, chúng ta đang khuếch đại cả năng lực lẫn sai sót của AI. Ngược lại, một hệ thống kiểm soát quá chặt nhưng không cung cấp đủ dữ liệu và công cụ sẽ khiến AI không thể hoàn thành nhiệm vụ có ý nghĩa. Mục tiêu không phải là hạn chế AI càng nhiều càng tốt, mà là trao đúng năng lực kèm kiểm soát đúng mức. AI càng tiến gần từ “đưa ra câu trả lời” sang “thực hiện hành động”, vai trò của harness càng trở thành một phần bắt buộc của thiết kế hệ thống.

Từ viết prompt đến thiết kế cách làm việc với AI

Nếu nối các nguyên tắc trên lại, tương tác với AI có thể được nhìn như một quy trình:

Xác định bài toán → cung cấp context → chia nhỏ nhiệm vụ → tạo phương án → phản biện → kiểm chứng → điều chỉnh → hành động.

Prompt vẫn nằm trong quy trình đó, nhưng không còn là toàn bộ vấn đề. Cách nhìn này cũng giải thích vì sao việc sưu tầm hàng trăm “prompt mẫu” thường không đem lại nhiều giá trị như kỳ vọng. Một prompt tốt có thể giúp chúng ta diễn đạt yêu cầu rõ hơn, nhưng nó không tự tạo ra context còn thiếu, không tự sửa một bài toán đặt sai và cũng không bảo đảm kết quả được kiểm chứng. Hơn nữa, cách prompting hiệu quả còn phụ thuộc vào loại mô hình và nhiệm vụ. OpenAI cũng lưu ý rằng các nhóm model khác nhau có thể phản ứng khác nhau với cùng một cách hướng dẫn. Trong các hệ thống thực tế, prompt nên được đánh giá bằng test và eval thay vì chỉ điều chỉnh dựa trên cảm giác.¹²

Vì vậy, có thể nói, kỹ năng bền vững khi dùng AI không phải là nhớ càng nhiều công thức prompt càng tốt, mà là hiểu AI đang đóng vai trò gì trong từng bước của công việc. Nó có đủ dữ liệu để làm nhiệm vụ này không? Phần nào có thể giao cho AI? Phần nào cần công cụ bên ngoài? Kết quả nào cần kiểm chứng? Và quan trọng nhất, quyết định nào vẫn phải do con người chịu trách nhiệm?

Tạm kết

Càng sử dụng AI cho những công việc phức tạp, chúng ta càng dễ nhận ra một điều: vấn đề hiếm khi nằm ở việc “chưa biết prompt đủ hay”. Một prompt tốt có thể giúp AI hiểu yêu cầu rõ hơn. Context tốt giúp nó có đủ thông tin để làm việc. Công cụ giúp mở rộng khả năng của nó. Harness giúp giữ những khả năng đó trong phạm vi có thể kiểm soát. Nhưng tất cả những thứ này chỉ thực sự có ý nghĩa khi chúng được đặt trong một quy trình mà con người vẫn hiểu mình đang giải quyết vấn đề gì, đang dựa vào giả định nào và sẽ kiểm chứng kết quả ra sao.

Vì vậy, kỹ năng quan trọng nhất khi làm việc với AI có lẽ không phải là học cách khiến nó luôn đưa ra câu trả lời đúng. Điều đó vừa khó, vừa không thực tế. Quan trọng hơn là thiết kế cách làm việc sao cho AI có thể sai mà chúng ta vẫn nhận ra được cái sai trước khi nó biến thành quyết định hoặc hành động.

Khi nhìn theo cách đó, prompt engineering hay context engineering không còn là những kỹ thuật tách rời. Chúng là những mảnh ghép trong một câu hỏi lớn hơn: chúng ta muốn AI tham gia vào quá trình suy nghĩ và làm việc của mình đến mức nào, và cần thiết kế hệ thống ra sao để khai thác được năng lực đó mà không đánh mất khả năng phán đoán của chính mình?

Có lẽ đây mới là điểm phân biệt giữa việc dùng AI và biết cách làm việc cùng AI.

Cheers & Peace!

---

Nguồn tham khảo

1. OpenAI, Prompt Engineering Guide. OpenAI Developer Documentation. ↩︎
2. Google AI for Developers, Prompt design strategies. ↩︎
3. Liu, N. F., et al. (2023), Lost in the Middle: How Language Models Use Long Contexts. ↩︎
4. Zhou, D., et al. (2022), Least-to-Most Prompting Enables Complex Reasoning in Large Language Models. ↩︎
5. OpenAI, Prompt Engineering Guide. OpenAI Developer Documentation. ↩︎
6. Google AI for Developers, Prompt design strategies. ↩︎
7. Wang, X., et al. (2022), Self-Consistency Improves Chain of Thought Reasoning in Language Models. ↩︎
8. Yao, S., et al. (2023), Tree of Thoughts: Deliberate Problem Solving with Large Language Models. ↩︎
9. Yao, S., et al. (2022), ReAct: Synergizing Reasoning and Acting in Language Models. ↩︎
10. NIST. (2024), Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. ↩︎
11. Dell’Acqua, F., et al, Navigating the Jagged Technological Frontier: Field Experimental Evidence of the Effects of AI on Knowledge Worker Productivity and Quality. ↩︎
12. OpenAI, Prompt Engineering Guide. OpenAI Developer Documentation. ↩︎