Prompting for Agents | Code w/ Claude

• Thiết kế câu lệnh cho Tác nhân AI vượt ra ngoài những kiến thức cơ bản, tập trung vào việc cho phép mô hình AI tự chủ thực hiện các tác vụ phức tạp, giá trị cao bằng cách sử dụng công cụ trong một vòng lặp liên tục.
• Để tạo câu lệnh hiệu quả, người thiết kế cần tư duy như Tác nhân AI, cung cấp các nguyên tắc heuristic rõ ràng, và hướng dẫn chi tiết về việc lựa chọn công cụ cũng như quy trình tư duy của mô hình.
• Do tính chất tự động hóa của Tác nhân AI, việc thiết kế câu lệnh phải tính đến các tác dụng phụ không mong muốn và bao gồm các chiến lược quản lý cửa sổ ngữ cảnh để duy trì hiệu suất trong các tác vụ dài.

• Xác định kịch bản sử dụng phù hợp: Chỉ triển khai Tác nhân AI cho các tác vụ phức tạp, giá trị cao mà lộ trình thực hiện không rõ ràng, các công cụ cần thiết có thể định nghĩa và chi phí sai sót có thể phục hồi.
• Mô phỏng trải nghiệm của Tác nhân AI: Thiết kế câu lệnh và công cụ bằng cách đặt mình vào vị trí của Tác nhân AI, đảm bảo rằng một con người có thể hiểu rõ ràng hành động mong muốn trong môi trường được cung cấp.
• Cung cấp các nguyên tắc heuristic rõ ràng: Diễn đạt tường minh các quy tắc và hành vi mong muốn cho Tác nhân AI (ví dụ: khi nào dừng lại, giới hạn số lần gọi công cụ, tránh hành động không thể đảo ngược) để tránh hiểu lầm hoặc hành động quá mức.
• Hướng dẫn lựa chọn và sử dụng công cụ hiệu quả: Chỉ dẫn rõ ràng Tác nhân AI khi nào và công cụ nào nên sử dụng trong các ngữ cảnh cụ thể, thay vì chỉ cung cấp danh sách công cụ với mô tả ngắn gọn.
• Tối ưu hóa quá trình tư duy của Tác nhân AI: Yêu cầu Tác nhân AI lập kế hoạch trước khi hành động (ví dụ: lập kế hoạch tìm kiếm) và sử dụng tư duy xen kẽ để đánh giá chất lượng kết quả, đặc biệt là từ các nguồn bên ngoài như tìm kiếm web.
• Dự đoán và quản lý tác dụng phụ không mong muốn: Nhận thức rằng các thay đổi trong câu lệnh có thể dẫn đến hành vi không lường trước do tính tự động của Tác nhân AI; thiết kế các giới hạn hoặc điều kiện dừng để kiểm soát các vòng lặp vô hạn hoặc hành động không mong muốn.
• Áp dụng chiến lược quản lý cửa sổ ngữ cảnh: Sử dụng các phương pháp như "Compaction" (nén) để tóm tắt các cuộc trò chuyện dài và quản lý hiệu quả cửa sổ ngữ cảnh, cho phép Tác nhân AI xử lý các tác vụ kéo dài mà không bị mất ngữ cảnh.

• Thiết kế câu lệnh — Prompt Design
• Tác nhân AI — AI Agent
• mô hình AI — AI model
• công cụ — tool
• tác vụ — task
• câu lệnh hệ thống — system prompt
• vòng lặp — loop
• ngữ cảnh — context
• cửa sổ ngữ cảnh — context window
• nguyên tắc heuristic hợp lý — reasonable heuristics

Giới thiệu về Thiết kế Câu lệnh cho Tác nhân AI

Chào mừng tất cả quý vị. Chúng ta sẽ tiếp tục với chủ đề Thiết kế câu lệnh cho Tác nhân AI. Hy vọng quý vị đã tham gia buổi Thiết kế câu lệnh cơ bản hoặc mới tham gia cùng chúng tôi. Tôi là Hannah, thuộc đội Trí tuệ nhân tạo ứng dụng của Anthropic. Chào mọi người, tôi là Jeremy, cũng thuộc đội Trí tuệ nhân tạo ứng dụng và là kỹ sư sản phẩm.

Hôm nay, chúng ta sẽ chuyển trọng tâm, không còn nói về những điều cơ bản của Thiết kế câu lệnh nữa, mà sẽ đi sâu vào cách chúng ta thực hiện điều này cho các Tác nhân AI, chẳng hạn như chơi Pokemon. Hy vọng quý vị đã tham gia buổi Thiết kế câu lệnh cơ bản hoặc đã quen thuộc với những kiến thức cơ bản về câu lệnh. Chúng ta sẽ không đi sâu vào các câu lệnh console rất cơ bản hay tương tác với Claude trên máy tính để bàn hôm nay.

Tuy nhiên, để nhắc lại, chúng ta coi Thiết kế câu lệnh là lập trình bằng ngôn ngữ tự nhiên. Bạn cần suy nghĩ về những gì Tác nhân AI hoặc mô hình AI của bạn sẽ làm, những tác vụ nó sẽ hoàn thành. Bạn cần giao tiếp rõ ràng với Tác nhân AI, cung cấp ví dụ khi cần thiết và đưa ra hướng dẫn. Chúng tôi thường sử dụng một cấu trúc rất cụ thể cho câu lệnh console, nhưng tôi muốn bạn loại bỏ hình dung này khỏi tâm trí, vì cấu trúc cho Tác nhân AI có thể rất khác biệt. Đối với một Tác nhân AI, bạn có thể không cần phải đưa ra một câu lệnh có cấu trúc rõ ràng như vậy. Nó sẽ thực sự rất khác, chúng ta sẽ cho phép nhiều yếu tố khác nhau được đưa vào.

Tác nhân AI: Định nghĩa và Hoạt động

Tôi sẽ nói về Tác nhân AI là gì, sau đó Jeremy sẽ trình bày cách chúng ta thực hiện điều này cho chúng. Hy vọng bạn đã có một hình dung về Tác nhân AI trong tâm trí. Tại Anthropic, chúng tôi định nghĩa Tác nhân AI là các mô hình AI sử dụng công cụ trong một vòng lặp.

Chúng ta giao cho Tác nhân AI một tác vụ và cho phép nó làm việc liên tục, sử dụng công cụ khi thấy phù hợp, cập nhật các quyết định dựa trên thông tin nhận được từ các lời gọi công cụ của nó và tiếp tục làm việc độc lập cho đến khi hoàn thành tác vụ.

Chúng ta giữ nó đơn giản như vậy: môi trường (nơi Tác nhân AI làm việc), các công cụ mà Tác nhân AI sở hữu, và câu lệnh hệ thống (nơi chúng ta yêu cầu Tác nhân AI làm hoặc hoàn thành điều gì đó). Chúng tôi thường nhận thấy rằng càng giữ đơn giản, hiệu quả càng cao. Hãy để Tác nhân AI làm việc của nó, để mô hình AI là chính nó và hoàn thành tác vụ này.

Khi nào nên sử dụng Tác nhân AI?

Bạn không phải lúc nào cũng cần sử dụng Tác nhân AI. Thực tế, có nhiều kịch bản mà bạn sẽ không muốn sử dụng Tác nhân AI. Có những phương pháp tiếp cận khác sẽ phù hợp hơn. Tác nhân AI thực sự phù hợp nhất cho các tác vụ phức tạp và có giá trị cao. Đây không phải là thứ bạn nên triển khai trong mọi tình huống có thể. Bạn sẽ không nhận được kết quả mong muốn và sẽ tốn nhiều tài nguyên hơn mức cần thiết.

Chúng ta sẽ nói một chút về danh sách kiểm tra hoặc cách suy nghĩ về việc khi nào bạn nên sử dụng Tác nhân AI hoặc khi nào bạn không nên sử dụng.

1. Tác vụ có phức tạp không? Đây có phải là một tác vụ mà bạn, một con người, có thể nghĩ ra một quy trình từng bước để hoàn thành không? Nếu có, bạn có thể không cần Tác nhân AI. Bạn nên sử dụng Tác nhân AI khi không rõ ràng cách bạn sẽ hoàn thành tác vụ. Bạn có thể biết mình muốn đi đâu, nhưng không biết chính xác cách để đến đó, cần những công cụ và thông tin gì để đạt được trạng thái cuối cùng.

2. Tác vụ có giá trị không? Bạn có nhận được nhiều giá trị từ việc Tác nhân AI hoàn thành tác vụ này không? Hay đây là một loại tác vụ hoặc quy trình làm việc có giá trị thấp? Trong trường hợp đó, một quy trình làm việc thông thường có thể tốt hơn. Bạn thực sự không muốn sử dụng tài nguyên của một Tác nhân AI, trừ khi đây là thứ mang lại đòn bẩy cao, có thể tạo ra doanh thu, hoặc thực sự có giá trị đối với người dùng. Nhấn mạnh, đây phải là một tác vụ phức tạp.

3. Các phần của tác vụ có khả thi không? Khi bạn nghĩ về tác vụ cần thực hiện, bạn có thể cung cấp cho các Tác nhân AI những công cụ cần thiết để hoàn thành tác vụ này không? Nếu bạn không thể định nghĩa công cụ, nếu bạn không thể cung cấp cho Tác nhân AI quyền truy cập vào thông tin hoặc công cụ cần thiết, bạn có thể muốn thu hẹp tác vụ. Nếu bạn có thể định nghĩa và cung cấp cho Tác nhân AI những công cụ nó cần, đó là một trường hợp sử dụng tốt hơn cho Tác nhân AI.

4. Chi phí sai sót và khả năng phát hiện lỗi? Điều cuối cùng bạn có thể muốn nghĩ đến là chi phí của các lỗi hoặc mức độ dễ dàng phát hiện lỗi. Nếu việc sửa lỗi, phát hiện lỗi thực sự khó khăn, đó có thể không phải là nơi bạn muốn Tác nhân AI làm việc độc lập. Trong trường hợp đó, bạn có thể muốn có một con người trong vòng lặp. Nếu lỗi là thứ bạn có thể phục hồi hoặc không quá tốn kém khi xảy ra, thì bạn có thể tiếp tục cho phép Tác nhân AI làm việc độc lập.

Các trường hợp sử dụng Tác nhân AI thực tế

Để làm cho điều này trở nên thực tế hơn, chúng ta sẽ nói về một vài ví dụ. Tôi sẽ không đi qua từng ví dụ, nhưng hãy chọn một vài ví dụ rõ ràng hoặc trực quan cho hầu hết chúng ta.

• Lập trình (Coding): Rõ ràng, tất cả các bạn đều rất quen thuộc với việc sử dụng Tác nhân AI trong lập trình. Lập trình là một trường hợp sử dụng tuyệt vời. Chúng ta có thể nghĩ về một tài liệu thiết kế. Mặc dù bạn biết mình muốn đạt được điều gì (tạo một Pull Request (PR)), nhưng bạn không biết chính xác cách để đến đó. Không rõ ràng bạn sẽ làm gì trước tiên, cách bạn sẽ lặp lại điều đó, những thay đổi bạn có thể thực hiện trên đường đi, tùy thuộc vào những gì bạn tìm thấy. Đây là một tác vụ có giá trị cao. Claude rất giỏi trong lập trình. Và đây là một trường hợp sử dụng có giá trị cao. Nếu Tác nhân AI của bạn thực sự có thể đi từ một tài liệu thiết kế đến một Pull Request, đó là rất nhiều thời gian mà bạn, một kỹ sư có kỹ năng cao, được tiết kiệm. Và bạn có thể dành thời gian của mình cho những việc khác mang lại hiệu quả cao hơn. Vì vậy, đây là một trường hợp sử dụng tuyệt vời cho Tác nhân AI.

• Tìm kiếm (Search): Nếu chúng ta mắc lỗi trong quá trình tìm kiếm, có nhiều cách để chúng ta có thể sửa chữa điều đó. Chúng ta có thể sử dụng các trích dẫn, chúng ta có thể sử dụng các phương pháp khác để kiểm tra lại kết quả. Vì vậy, nếu Tác nhân AI mắc lỗi trong quá trình tìm kiếm, đây là điều chúng ta có thể phục hồi và có lẽ không quá tốn kém.

• Sử dụng máy tính (Computer Use): Đây cũng là một nơi chúng ta có thể phục hồi từ các lỗi. Chúng ta có thể quay lại, chúng ta có thể thử nhấp lại. Không quá khó để cho phép Claude nhấp vài lần cho đến khi nó có thể sử dụng công cụ một cách chính xác.

• Phân tích dữ liệu (Data Analysis): Tôi nghĩ đây là một ví dụ thú vị khác, tương tự như lập trình. Chúng ta có thể biết kết quả cuối cùng mà chúng ta muốn đạt được. Chúng ta biết một tập hợp Thông tin chi tiết mà chúng ta muốn thu thập từ dữ liệu hoặc một biểu đồ trực quan hóa mà chúng ta muốn tạo từ dữ liệu. Chúng ta không biết chính xác dữ liệu có thể trông như thế nào. Dữ liệu có thể có các định dạng khác nhau, có thể có lỗi, có thể có các vấn đề về chi tiết mà chúng ta không chắc chắn cách phân tách. Chúng ta không biết chính xác quy trình mà chúng ta sẽ thực hiện và phân tích dữ liệu đó, nhưng chúng ta biết mình muốn đạt được điều gì cuối cùng. Vì vậy, đây là một ví dụ khác về trường hợp sử dụng tuyệt vời cho Tác nhân AI.

Hy vọng những điều này có ý nghĩa với bạn. Bây giờ tôi sẽ nhường lời cho Jeremy. Anh ấy có kinh nghiệm phong phú trong việc xây dựng các Tác nhân AI tại Anthropic và sẽ chia sẻ một số phương pháp hay nhất để thiết kế câu lệnh hiệu quả và cách cấu trúc một câu lệnh tuyệt vời cho Tác nhân AI.

Các thực hành tốt nhất trong Thiết kế Câu lệnh cho Tác nhân AI

Cảm ơn, Hannah. Chào mọi người. Vâng, về thiết kế câu lệnh cho Tác nhân AI. Tôi sẽ trình bày một vài điểm mà chúng tôi đã học được chủ yếu từ việc tự xây dựng các Tác nhân AI. Một số Tác nhân AI bạn có thể dùng thử từ Anthropic là Claude Code, hoạt động trong thiết bị đầu cuối của bạn và duyệt các tệp của bạn một cách có tính tác nhân, sử dụng công cụ bash để thực sự hoàn thành các tác vụ trong lập trình. Tương tự, chúng tôi có tính năng nghiên cứu nâng cao mới trên claude.ai. Tính năng này cho phép bạn thực hiện hàng giờ nghiên cứu. Ví dụ, bạn có thể tìm hàng trăm công ty khởi nghiệp xây dựng Tác nhân AI hoặc bạn có thể tìm hàng trăm khách hàng tiềm năng cho công ty của mình. Điều này cho phép mô hình AI thực hiện nghiên cứu trên các công cụ của bạn, Google Drive, tìm kiếm web và những thứ tương tự.

Trong quá trình xây dựng các sản phẩm này, một điều chúng tôi đã học được là bạn cần phải suy nghĩ như Tác nhân AI của mình. Đây có lẽ là nguyên tắc quan trọng nhất. Ý tưởng là về cơ bản bạn cần hiểu và phát triển một mô hình tư duy về những gì Tác nhân AI của bạn đang làm và cảm giác như thế nào khi ở trong môi trường đó. Vì vậy, môi trường cho Tác nhân AI là một tập hợp các công cụ và các phản hồi mà nó nhận được từ những công cụ đó.

Trong ngữ cảnh của Claude Code, cách bạn có thể làm điều này là bằng cách thực sự mô phỏng quy trình và chỉ cần tưởng tượng nếu bạn ở vị trí của Claude Code, với các mô tả công cụ chính xác và lược đồ công cụ mà nó có, liệu bạn có bối rối hay bạn có thể thực hiện tác vụ mà nó đang làm không? Nếu một con người không thể hiểu Tác nhân AI của bạn nên làm gì, thì Trí tuệ nhân tạo cũng sẽ không thể. Và vì vậy, điều này thực sự quan trọng để suy nghĩ về thiết kế công cụ, suy nghĩ về thiết kế câu lệnh là mô phỏng và trải nghiệm môi trường của chúng.

Một điểm khác là bạn cần cung cấp cho Tác nhân AI của mình những nguyên tắc heuristic hợp lý. Hannah đã đề cập rằng Thiết kế câu lệnh là kỹ thuật khái niệm. Điều đó thực sự có nghĩa là gì? Đó là một trong những lý do tại sao Thiết kế câu lệnh sẽ không biến mất và tại sao cá nhân tôi mong đợi thiết kế câu lệnh sẽ trở nên quan trọng hơn chứ không phải kém quan trọng hơn khi các mô hình AI trở nên thông minh hơn. Điều này là do thiết kế câu lệnh không chỉ là về văn bản, không chỉ là về những từ bạn cung cấp cho mô hình AI. Đó là về việc quyết định những khái niệm nào mô hình AI nên có và những hành vi nào nó nên tuân theo để hoạt động tốt trong một môi trường cụ thể.

Ví dụ, Claude Code có khái niệm về tính không thể đảo ngược. Nó không nên thực hiện các hành động không thể đảo ngược có thể gây hại cho người dùng hoặc môi trường của họ. Vì vậy, nó sẽ tránh những loại hành động gây hại này hoặc bất cứ điều gì có thể gây ra thiệt hại không thể đảo ngược cho môi trường hoặc mã của bạn hoặc bất cứ điều gì tương tự. Vì vậy, khái niệm về tính không thể đảo ngược là điều bạn cần truyền đạt vào mô hình AI và phải rất rõ ràng về nó và suy nghĩ về các trường hợp biên. Mô hình AI có thể hiểu sai khái niệm này như thế nào? Nó có thể không biết ý nghĩa của nó như thế nào? Ví dụ, nếu bạn muốn mô hình AI rất nhiệt tình và bạn muốn nó có tính chủ động cao, thì nó có thể làm quá một chút. Nó có thể hiểu sai những gì bạn đang nói và làm nhiều hơn những gì bạn mong đợi. Và vì vậy, bạn phải rất rõ ràng và sắc sảo về các khái niệm bạn đang cung cấp cho các mô hình AI.

Một số ví dụ về những nguyên tắc heuristic hợp lý mà chúng tôi đã học được:

• Khi xây dựng tính năng nghiên cứu, chúng tôi nhận thấy rằng mô hình AI thường thực hiện rất nhiều tìm kiếm web khi không cần thiết. Ví dụ, nó sẽ tìm thấy câu trả lời thực tế cần, như có thể tìm thấy danh sách các công ty mở rộng quy mô ở Hoa Kỳ. Và sau đó nó sẽ tiếp tục tìm kiếm, mặc dù nó đã có câu trả lời. Điều đó là do chúng tôi chưa nói rõ ràng với mô hình AI: "Khi bạn tìm thấy câu trả lời, bạn có thể dừng lại. Bạn không cần phải tiếp tục tìm kiếm nữa."
• Tương tự, chúng tôi phải cung cấp cho mô hình AI một loại ngân sách để suy nghĩ. Ví dụ, chúng tôi nói rằng đối với các truy vấn đơn giản, nó nên sử dụng dưới năm lời gọi công cụ, nhưng đối với các truy vấn phức tạp hơn, nó có thể sử dụng tới 10 hoặc 15.

Vì vậy, những loại nguyên tắc heuristic mà bạn có thể cho rằng mô hình AI đã hiểu, bạn thực sự phải diễn đạt rõ ràng. Một cách tốt để suy nghĩ về điều này là nếu bạn đang quản lý một thực tập sinh mới ra trường và chưa có kinh nghiệm làm việc, bạn sẽ diễn đạt cho họ như thế nào để vượt qua tất cả các vấn đề mà họ có thể gặp phải trong công việc đầu tiên của họ? Và bạn sẽ làm thế nào để rất sắc sảo và rõ ràng với họ về cách hoàn thành điều đó? Đó thường là cách bạn nên nghĩ về việc đưa ra các nguyên tắc heuristic cho Tác nhân AI của mình, đó chỉ là những nguyên tắc chung mà nó nên tuân theo. Chúng có thể không phải là các quy tắc nghiêm ngặt, nhưng chúng là một loại thực hành.

Một điểm khác là lựa chọn công cụ là chìa khóa.

Hướng dẫn sử dụng công cụ hiệu quả

Khi các mô hình AI trở nên mạnh mẽ hơn, có khả năng xử lý ngày càng nhiều công cụ, Sonnet 4 và Opus 4 có thể xử lý tới 100 công cụ, thậm chí hơn thế nữa nếu bạn có thiết kế câu lệnh tốt. Tuy nhiên, để sử dụng những công cụ này, bạn phải làm rõ mô hình AI nên sử dụng công cụ nào cho các tác vụ khác nhau. Ví dụ, đối với nghiên cứu, chúng ta có thể cấp quyền truy cập vào Google Drive cho mô hình AI. Chúng ta có thể cấp quyền truy cập vào các MCP tools như Sentry, DataDog hoặc GitHub. Nó có thể tìm kiếm trên tất cả các công cụ này. Nhưng mô hình AI không tự biết công cụ nào quan trọng cho tác vụ nào, đặc biệt trong ngữ cảnh cụ thể của công ty bạn. Chẳng hạn, nếu công ty bạn sử dụng Slack nhiều, có thể mô hình AI nên ưu tiên tìm kiếm thông tin liên quan đến công ty trên Slack. Tất cả những câu hỏi về cách mô hình AI nên sử dụng công cụ, bạn phải cung cấp cho nó các nguyên tắc rõ ràng về thời điểm và ngữ cảnh sử dụng công cụ nào. Điều này thực sự quan trọng, và tôi thường thấy mọi người không câu lệnh Tác nhân AI về công cụ nào nên sử dụng, họ chỉ cung cấp mô hình AI và công cụ với vài mô tả rất ngắn gọn. Và rồi họ tự hỏi tại sao mô hình AI không sử dụng đúng công cụ? Rất có thể là vì mô hình AI không biết nó nên làm gì trong ngữ cảnh đó.

Hướng dẫn và tối ưu hóa quá trình tư duy

Một điểm khác ở đây là bạn có thể hướng dẫn quá trình tư duy. Mọi người thường bật chế độ extended thinking (tư duy mở rộng), rồi để Tác nhân AI tự chạy và cho rằng nó sẽ đạt được hiệu suất tốt hơn ngay lập tức. Thực tế, giả định đó là đúng. Hầu hết thời gian, bạn sẽ có được hiệu suất tốt hơn ngay lập tức, nhưng bạn có thể tối ưu hiệu suất hơn nữa nếu chỉ cần câu lệnh Tác nhân AI để sử dụng tư duy của nó một cách hiệu quả. Chẳng hạn, đối với việc tìm kiếm, chúng tôi yêu cầu mô hình AI lập kế hoạch cho quy trình tìm kiếm của nó. Vì vậy, trước tiên, nó phải quyết định mức độ phức tạp của query này, nên sử dụng bao nhiêu tool calls ở đây, nên tìm kiếm từ những nguồn nào, làm thế nào để biết khi nào thành công; chúng tôi yêu cầu nó lập kế hoạch chính xác tất cả những điều này trong thinking block đầu tiên của nó.

Và một khả năng mới mà các mô hình AI của Claude 4 có là khả năng sử dụng interleaved thinking (tư duy xen kẽ) giữa các tool calls. Sau khi nhận được kết quả từ web, chúng tôi thường nhận thấy rằng các mô hình AI cho rằng tất cả kết quả tìm kiếm trên web đều đúng. Chúng tôi chưa nói rõ ràng với chúng rằng điều này không phải lúc nào cũng đúng. Và vì vậy, chúng có thể lấy những kết quả web này và sử dụng chúng ngay lập tức. Vì vậy, một điều chúng tôi câu lệnh mô hình AI của mình làm là sử dụng interleaved thinking này để thực sự suy ngẫm về chất lượng của kết quả tìm kiếm và quyết định xem chúng có cần xác minh chúng không, có cần thêm thông tin không, hay chúng có nên thêm một tuyên bố miễn trừ trách nhiệm về việc kết quả có thể không chính xác hay không.

Quản lý tác dụng phụ không mong muốn

Một điểm khác khi thiết kế câu lệnh Tác nhân AI là Tác nhân AI khó đoán hơn so với quy trình làm việc hoặc các câu lệnh kiểu phân loại. Hầu hết các thay đổi sẽ có unintended side effects (tác dụng phụ không mong muốn). Điều này là do Tác nhân AI sẽ hoạt động tự động trong một loop. Chẳng hạn, nếu bạn nói với Tác nhân AI, "hãy tiếp tục tìm kiếm cho đến khi bạn tìm thấy câu trả lời đúng. Hãy tìm nguồn chất lượng cao nhất có thể và luôn tìm kiếm cho đến khi bạn tìm thấy nguồn đó." Điều bạn có thể gặp phải là unintended side effect của việc Tác nhân AI không tìm thấy bất kỳ nguồn nào. Có thể nguồn hoàn hảo này không tồn tại cho query đó. Và vì vậy, nó sẽ tiếp tục tìm kiếm cho đến khi chạm đến cửa sổ ngữ cảnh của nó. Đó thực sự là điều chúng tôi cũng đã gặp phải. Vì vậy, bạn phải nói với Tác nhân AI rằng, "nếu bạn không tìm thấy nguồn hoàn hảo, không sao cả. Bạn có thể dừng lại sau một vài tool calls." Do đó, hãy lưu ý rằng các câu lệnh của bạn có thể có unintended side effects và bạn có thể phải roll those back (hoàn tác chúng).

Mở rộng và quản lý cửa sổ ngữ cảnh

Một điểm khác là giúp Tác nhân AI quản lý cửa sổ ngữ cảnh của nó. Các mô hình AI Claude 4 có cửa sổ ngữ cảnh 200K token. Đây là đủ dài cho rất nhiều tác vụ chạy dài. Nhưng khi bạn sử dụng một Tác nhân AI để thực hiện công việc một cách tự động, bạn có thể chạm đến giới hạn cửa sổ ngữ cảnh này. Có một số chiến lược bạn có thể sử dụng để mở rộng cửa sổ ngữ cảnh hiệu quả. Một trong số đó mà chúng tôi sử dụng cho Claude Code được gọi là Compaction (nén). Đây là một công cụ mà mô hình AI có, sẽ tự động được gọi khi nó đạt khoảng 190.000 token, tức là gần cửa sổ ngữ cảnh. Và điều này sẽ tóm tắt hoặc nén mọi thứ trong cửa sổ ngữ cảnh thành một bản tóm tắt rất súc tích nhưng chính xác, sau đó được chuyển đến một phiên bản Claude mới cùng với bản tóm tắt đó và tiếp tục quá trình. Chúng tôi nhận thấy rằng điều này về cơ bản cho phép bạn chạy vô thời hạn với Claude Code. Bạn hầu như không bao giờ hết ngữ cảnh. Thỉnh thoảng, nó có thể bỏ sót các chi tiết từ phiên làm việc trước. Nhưng phần lớn thời gian, điều này sẽ giữ lại tất cả các chi tiết quan trọng và mô hình AI sẽ "nhớ" những gì đã xảy ra trong phiên trước.

Tương tự, bạn có thể ghi vào một external file (tệp bên ngoài). Vì vậy, mô hình AI có thể truy cập vào một tệp bổ sung. Và các mô hình AI Claude 4 này đặc biệt giỏi trong việc ghi bộ nhớ vào một tệp. Và chúng có thể sử dụng tệp này để về cơ bản mở rộng cửa sổ ngữ cảnh của chúng.

Một điểm khác là bạn có thể sử dụng Tác nhân phụ. Chúng ta sẽ không nói nhiều về điều này ở đây, nhưng về cơ bản, nếu bạn có các Tác nhân AI luôn chạm đến cửa sổ ngữ cảnh của chúng, bạn có thể ủy quyền một số công việc mà Tác nhân AI đang làm cho một Tác nhân AI khác. Chẳng hạn, bạn có thể có một Tác nhân AI đóng vai trò lead agent (tác nhân chính), sau đó các Tác nhân phụ thực hiện quá trình tìm kiếm thực tế. Sau đó, các Tác nhân phụ có thể nén kết quả lại cho lead agent dưới dạng rất súc tích mà không sử dụng nhiều token. Và lead agent có thể cung cấp báo cáo cuối cùng cho người dùng. Chúng tôi thực sự sử dụng quy trình này trong hệ thống nghiên cứu của mình. Và điều này cho phép bạn nén những gì đang diễn ra trong quá trình tìm kiếm và sau đó chỉ sử dụng cửa sổ ngữ cảnh cho lead agent để thực sự viết báo cáo. Vì vậy, loại multi-agent system (hệ thống đa tác nhân) này có thể hiệu quả trong việc giới hạn cửa sổ ngữ cảnh.

Tin tưởng vào khả năng của Claude

Cuối cùng, bạn có thể để Claude là Claude. Về cơ bản, điều này có nghĩa là Claude đã rất giỏi trong vai trò một Tác nhân AI. Bạn không cần phải làm quá nhiều việc ngay từ đầu. Vì vậy, tôi khuyên bạn nên thử nghiệm hệ thống AI của mình với một câu lệnh và công cụ bare bones (tối thiểu), xem nó gặp lỗi ở đâu, rồi từ đó tiếp tục phát triển. Đừng vội cho rằng Claude không thể làm được, vì Claude thường sẽ khiến bạn ngạc nhiên về khả năng của nó.

Thiết kế công cụ chất lượng cao

Tôi đã nói về thiết kế công cụ rồi, nhưng điểm mấu chốt ở đây là bạn muốn đảm bảo rằng công cụ của bạn tốt. Một công cụ tốt là gì? Nó sẽ có một tool name (tên công cụ) đơn giản, chính xác, phản ánh chức năng của nó. Bạn sẽ đã kiểm tra và đảm bảo rằng nó hoạt động tốt. Nó sẽ có một well-formed description (mô tả rõ ràng) để một người đọc công cụ này có thể hiểu, giống như bạn đưa một hàm cho một Developer khác trong nhóm của bạn. Liệu họ có hiểu và sử dụng được hàm đó không? Bạn nên đặt câu hỏi tương tự về agent computer interfaces (giao diện máy tính của tác nhân) hoặc các công cụ mà bạn đang cung cấp cho Tác nhân AI của mình. Hãy đảm bảo rằng chúng có thể sử dụng được và rõ ràng. Chúng tôi cũng thường thấy mọi người cung cấp cho một Tác nhân AI một loạt công cụ có tên hoặc mô tả rất giống nhau. Ví dụ, bạn cung cấp cho nó sáu search tools (công cụ tìm kiếm). Và mỗi search tool tìm kiếm trong một database (cơ sở dữ liệu) hơi khác nhau. Điều này sẽ làm mô hình AI bối rối. Vì vậy, hãy cố gắng giữ cho các công cụ của bạn khá riêng biệt và kết hợp các công cụ tương tự thành một.

Ví dụ về quy trình làm việc của Tác nhân AI và demo console

Một ví dụ nhanh ở đây là bạn có thể có một Tác nhân AI, chẳng hạn, sử dụng các công cụ khác nhau để đầu tiên tìm kiếm inventory (hàng tồn kho) trong một database, chạy một query (truy vấn). Dựa trên thông tin tìm được, nó có thể suy ngẫm về inventory, suy nghĩ một chút, sau đó quyết định generate an invoice (tạo hóa đơn), tạo hóa đơn này, nghĩ xem nên làm gì tiếp theo, và sau đó quyết định send an email (gửi email). Và như vậy, loop (vòng lặp) này bao gồm việc Tác nhân AI lấy thông tin từ database (môi trường bên ngoài của nó), sử dụng các công cụ của nó, và sau đó cập nhật dựa trên thông tin đó cho đến khi hoàn thành tác vụ. Và đó là cách các Tác nhân AI hoạt động nói chung.

Vì vậy, hãy cùng xem một demo nhanh. Tôi sẽ chuyển sang máy tính của mình. Bạn có thể thấy ở đây đây là console (bảng điều khiển) của chúng tôi. Console là một công cụ tuyệt vời để mô phỏng các câu lệnh của bạn và xem chúng sẽ trông như thế nào trong UI (giao diện người dùng). Và tôi đã sử dụng điều này trong khi chúng tôi lặp lại nghiên cứu để hiểu điều gì đang thực sự diễn ra và Tác nhân AI đang làm gì. Đây là một cách tuyệt vời để think like your agents (suy nghĩ như các tác nhân của bạn) và put yourself in their shoes (đặt mình vào vị trí của chúng).

Bạn có thể thấy chúng tôi có một câu lệnh lớn ở đây. Nó không quá dài, khoảng 1.000 token. Nó liên quan đến việc nhà nghiên cứu thực hiện một quy trình nghiên cứu. Chúng tôi nói cho nó biết chính xác những gì nó nên lập kế hoạch trước. Chúng tôi nói cho nó biết nó thường nên sử dụng bao nhiêu tool calls. Chúng tôi đưa ra một số guidelines (hướng dẫn) về những sự thật nó nên suy nghĩ, điều gì tạo nên một high quality source (nguồn chất lượng cao), và những thứ tương tự. Và sau đó chúng tôi bảo nó sử dụng parallel tool calls (gọi công cụ song song). Tức là, chạy nhiều web searches (tìm kiếm web) in parallel (song song) cùng một lúc, thay vì chạy tuần tự tất cả. Sau đó, chúng tôi đưa ra câu hỏi này: "Bao nhiêu quả chuối có thể vừa trong một chiếc Rivian R1S?" Đây không phải là câu hỏi mà mô hình AI có thể trả lời, vì Rivian R1S mới ra mắt gần đây. Đó là một chiếc xe hơi. Nó không biết trước tất cả các thông số kỹ thuật và mọi thứ. Vì vậy, nó sẽ phải tìm kiếm trên web. Hãy chạy thử và xem điều gì xảy ra.

Demo tìm kiếm với Claude

Bạn sẽ thấy rằng ngay từ đầu, nó sẽ suy nghĩ và phân tích yêu cầu này. Và nó nhận ra, "OK, web search sẽ hữu ích ở đây. Tôi nên lấy cargo capacity (dung tích khoang chứa hàng). Tôi nên tìm kiếm." Wow. Và bạn thấy ở đây, nó đã chạy hai web searches in parallel cùng một lúc, cho phép nó nhận lại các kết quả này rất nhanh chóng. Và sau đó, nó đang suy ngẫm về các kết quả. Vì vậy, nó nhận ra, "OK, tôi đã tìm thấy banana dimensions (kích thước quả chuối). Tôi biết rằng USDA (Bộ Nông nghiệp Hoa Kỳ) xác định chuối dài từ 7 đến 8 inch. Tôi cần chạy một web search khác. Hãy để tôi chuyển đổi những thứ này sang standard measurements (các đơn vị đo lường tiêu chuẩn) hơn." Bạn có thể thấy nó đang sử dụng tool calls interleaved with thinking (xen kẽ với tư duy), đây là một điều mới mà các mô hình AI Claude 4 có thể làm. Cuối cùng, nó đang thực hiện một số calculations (tính toán). Nó đang suy nghĩ về việc có bao nhiêu quả chuối có thể được đóng gói vào cargo space (khoang chứa hàng) của chiếc xe tải. Và nó đang chạy thêm một vài web searches. Bạn có thể thấy rằng đây là một tác vụ khá phức tạp, nhưng giờ đây nó có thể cung cấp một câu trả lời. Nó đã thực hiện rất nhiều web searches, và nó sẽ cho bạn biết nó có thể chứa bao nhiêu quả chuối, ước tính khoảng 48.000 quả chuối. Tôi đã thấy mô hình AI ước tính bất cứ thứ gì từ 30.000 đến 50.000. Tôi nghĩ câu trả lời đúng là khoảng 30.000. Vì vậy, đây là con số gần đúng.

Trở lại các bài thuyết trình, tôi nghĩ rằng cách tiếp cận này – thử nghiệm câu lệnh của bạn, xem mô hình AI gọi những công cụ nào, đọc các thinking blocks của nó và thực sự xem cách mô hình AI suy nghĩ – thường sẽ làm rõ ràng các vấn đề và điều gì đang sai. Vì vậy, bạn sẽ thử nghiệm nó, và bạn sẽ thấy, "OK, có thể mô hình AI đang sử dụng quá nhiều công cụ ở đây. Có thể nó đang sử dụng sai nguồn, hoặc có thể nó chỉ đang làm theo guidelines sai." Vì vậy, đây là một cách thực sự hữu ích để think like your agents và làm cho chúng cụ thể hơn.

Đánh giá Tác nhân AI

Trở lại các bài thuyết trình. OK, về evals (đánh giá). Evaluations (đánh giá) thực sự quan trọng đối với bất kỳ hệ thống AI nào. Chúng rất quan trọng để đo lường một cách có hệ thống liệu bạn có đang tiến bộ trong câu lệnh của mình hay không. Bạn sẽ nhanh chóng nhận thấy rằng rất khó để thực sự tiến bộ trên một câu lệnh nếu bạn không có một eval có ý nghĩa cho bạn biết liệu câu lệnh của bạn có tốt hơn không, và liệu hệ thống AI của bạn có tốt hơn không. Nhưng evals khó hơn nhiều đối với Tác nhân AI. Tác nhân AI là long running (chạy dài). Chúng thực hiện rất nhiều thứ. Chúng có thể không phải lúc nào cũng có một predictable process (quy trình có thể dự đoán được). Classification (phân loại) dễ eval hơn vì bạn chỉ cần kiểm tra: "Nó có phân loại đầu ra này một cách chính xác không?" Nhưng Tác nhân AI thì khó hơn. Vậy, một vài lời khuyên để làm điều này dễ dàng hơn.

Một là, effect size (kích thước hiệu ứng) càng lớn thì sample size (kích thước mẫu) bạn cần càng nhỏ. Và đây chỉ là một principle from science (nguyên tắc từ khoa học) nói chung, trong đó nếu một effect size rất lớn, ví dụ, nếu một loại medication (thuốc) sẽ chữa khỏi bệnh ngay lập tức, bạn thực sự không cần một sample size lớn với rất nhiều người để biết rằng treatment (phương pháp điều trị) này đang có effect (hiệu quả).

Tối ưu hóa Quy trình Đánh giá Tác nhân AI

Tương tự, khi bạn thay đổi một câu lệnh và rõ ràng là hệ thống đang hoạt động tốt hơn, bạn không cần một quy trình đánh giá lớn. Tôi thường thấy các nhóm nghĩ rằng họ cần thiết lập một quy trình đánh giá khổng lồ với hàng trăm trường hợp thử nghiệm và tự động hóa hoàn toàn khi họ mới bắt đầu xây dựng một Tác nhân AI. Đây là một chế độ lỗi và là một chống mẫu. Bạn nên bắt đầu với một quy trình đánh giá rất nhỏ và chỉ chạy nó để xem điều gì xảy ra. Bạn thậm chí có thể bắt đầu thủ công. Nhưng điều quan trọng là phải bắt đầu. Tôi thường thấy các nhóm trì hoãn các quy trình đánh giá vì họ nghĩ rằng chúng quá đáng sợ hoặc cần một quy trình đánh giá quá chuyên sâu để thực sự nhận được tín hiệu hữu ích. Nhưng bạn có thể nhận được tín hiệu tuyệt vời từ một số lượng nhỏ các trường hợp thử nghiệm. Bạn chỉ cần giữ các trường hợp thử nghiệm đó nhất quán và sau đó tiếp tục kiểm tra chúng để biết liệu mô hình và câu lệnh có đang tốt hơn hay không.

Bạn cũng muốn sử dụng các tác vụ thực tế. Vì vậy, đừng chỉ đưa ra các câu lệnh hoặc mô tả hoặc tác vụ tùy tiện mà không có bất kỳ mối tương quan thực sự nào với những gì hệ thống của bạn sẽ làm. Ví dụ, nếu bạn đang làm việc với các tác vụ lập mã, bạn không muốn chỉ cung cấp cho mô hình các bài toán competitive programming problems. Bởi vì đây không phải là lập mã trong thế giới thực. Bạn sẽ muốn cung cấp cho nó các tác vụ thực tế thực sự phản ánh những gì Tác nhân AI của bạn sẽ làm. Tương tự, trong lĩnh vực tài chính, bạn muốn thực hiện các tác vụ mà những người thực đang cố gắng giải quyết và chỉ sử dụng chúng để đánh giá liệu mô hình có thể thực hiện những tác vụ đó hay không. Điều này cho phép bạn thực sự đo lường liệu mô hình có đang tốt hơn ở các tác vụ mà bạn quan tâm hay không.

Sử dụng Mô hình ngôn ngữ lớn làm Trọng tài Đánh giá

Một điểm khác là Mô hình ngôn ngữ lớn (LLM) làm trọng tài thực sự mạnh mẽ, đặc biệt khi bạn cung cấp cho nó một rubric (tiêu chí đánh giá). Vì vậy, các Tác nhân AI sẽ có nhiều loại đầu ra khác nhau. Ví dụ, nếu bạn đang sử dụng chúng để tìm kiếm, chúng có thể có hàng tấn loại báo cáo tìm kiếm khác nhau với các cấu trúc khác nhau. Nhưng Mô hình ngôn ngữ lớn (LLM) rất giỏi trong việc xử lý nhiều loại cấu trúc và văn bản khác nhau với các đặc điểm khác nhau. Và một điều mà chúng tôi đã làm, ví dụ, là cung cấp cho mô hình một rubric rõ ràng và sau đó yêu cầu nó đánh giá đầu ra của Tác nhân AI. Ví dụ, đối với các tác vụ tìm kiếm, chúng tôi có thể cung cấp cho nó một rubric nói rằng hãy kiểm tra xem mô hình đã xem các nguồn phù hợp chưa, kiểm tra xem nó đã nhận được câu trả lời chính xác chưa. Trong trường hợp này, chúng ta có thể nói hãy kiểm tra xem mô hình đã ước tính số lượng chuối có thể chứa trong một rubric nằm trong khoảng từ 10.000 đến 50.000 quả. Bất cứ điều gì nằm ngoài phạm vi đó đều không thực tế. Vì vậy, bạn có thể sử dụng những thứ như vậy để đánh giá xem mô hình có đưa ra câu trả lời đúng không, liệu nó có tuân thủ đúng quy trình không.

Tầm quan trọng của Đánh giá Thủ công của Con người

Tuy nhiên, cuối cùng, không có gì có thể thay thế hoàn hảo cho các đánh giá thủ công của con người (human evals). Bạn cần kiểm tra hệ thống theo cách thủ công. Bạn cần xem nó đang làm gì. Bạn cần xem các bản ghi, xem những gì mô hình đang làm và hiểu hệ thống của bạn nếu bạn muốn đạt được tiến bộ trên đó.

Các Ví dụ về Quy trình Đánh giá cho Tác nhân AI

Dưới đây là một số ví dụ về quy trình đánh giá cho các Tác nhân AI.

Độ chính xác của Câu trả lời (Answer Accuracy)

Một ví dụ mà tôi đã trình bày là độ chính xác của câu trả lời. Đây là nơi bạn chỉ cần sử dụng Mô hình ngôn ngữ lớn (LLM) làm trọng tài để đánh giá xem câu trả lời có chính xác không. Ví dụ, trong trường hợp này, bạn có thể nói rằng Tác nhân AI cần sử dụng một công cụ để truy vấn số lượng nhân viên và sau đó báo cáo câu trả lời. Và sau đó bạn biết số lượng nhân viên trong công ty của bạn. Vì vậy, bạn chỉ có thể kiểm tra điều đó với Mô hình ngôn ngữ lớn (LLM) làm trọng tài. Lý do bạn sử dụng Mô hình ngôn ngữ lớn (LLM) làm trọng tài ở đây là vì nó mạnh mẽ hơn đối với các biến thể. Ví dụ, nếu bạn chỉ kiểm tra số nguyên 47 trong trường hợp này trong đầu ra, điều đó không mạnh mẽ lắm. Và nếu mô hình nói 47 dưới dạng văn bản, bạn sẽ chấm điểm sai. Vì vậy, bạn muốn sử dụng Mô hình ngôn ngữ lớn (LLM) làm trọng tài để mạnh mẽ hơn đối với những biến thể nhỏ đó.

Độ chính xác của Việc sử dụng Công cụ (Tool Use Accuracy)

Một cách khác để bạn có thể đánh giá các Tác nhân AI là độ chính xác của việc sử dụng công cụ. Các Tác nhân AI liên quan đến việc sử dụng công cụ trong một vòng lặp. Và vì vậy, nếu bạn biết trước công cụ nào mô hình nên sử dụng hoặc cách nó nên sử dụng chúng, bạn chỉ có thể đánh giá xem nó có sử dụng đúng công cụ trong quy trình hay không. Ví dụ, trong trường hợp này, tôi có thể đánh giá Tác nhân AI nên sử dụng tìm kiếm web ít nhất năm lần để trả lời câu hỏi này. Và vì vậy tôi chỉ có thể kiểm tra trong bản ghi theo chương trình, liệu lệnh gọi công cụ cho tìm kiếm web có xuất hiện năm lần hay không. Tương tự, bạn có thể kiểm tra trong trường hợp này, để trả lời câu hỏi "đặt chuyến bay", Tác nhân AI nên sử dụng công cụ "tìm chuyến bay". Và bạn có thể kiểm tra điều đó theo chương trình. Và điều này cho phép bạn đảm bảo rằng các công cụ phù hợp đang được sử dụng vào đúng thời điểm.

Đánh giá Trạng thái Cuối cùng với Tau Bench

Cuối cùng, một quy trình đánh giá thực sự tốt cho các Tác nhân AI là tau bench. Bạn có thể tìm kiếm điều này. tau bench là một bộ tiêu chuẩn mã nguồn mở cho thấy bạn có thể đánh giá liệu các Tác nhân AI có đạt được trạng thái cuối cùng chính xác hay không. Vì vậy, rất nhiều Tác nhân AI đang sửa đổi một cơ sở dữ liệu hoặc tương tác với người dùng theo cách mà bạn có thể nói rằng mô hình luôn phải đạt được trạng thái này ở cuối quy trình. Ví dụ, nếu Tác nhân AI của bạn là một Tác nhân AI dịch vụ khách hàng cho hãng hàng không và người dùng yêu cầu thay đổi chuyến bay của họ. Ở cuối quy trình của Tác nhân AI để phản hồi câu lệnh đó, nó phải đã thay đổi chuyến bay trong cơ sở dữ liệu. Và vì vậy bạn chỉ có thể kiểm tra ở cuối quy trình của Tác nhân AI, chuyến bay đã được thay đổi chưa, hàng này trong cơ sở dữ liệu đã được thay đổi sang một ngày khác chưa. Và điều đó có thể xác minh rằng Tác nhân AI đang hoạt động chính xác. Điều này thực sự mạnh mẽ và bạn có thể sử dụng nó trong nhiều trường hợp sử dụng khác nhau. Ví dụ, bạn có thể kiểm tra xem cơ sở dữ liệu của bạn đã được cập nhật chính xác chưa. Bạn có thể kiểm tra xem các tệp nhất định đã được sửa đổi chưa, những thứ tương tự. Và đó là một cách để đánh giá trạng thái cuối cùng mà Tác nhân AI đạt được.

Hỏi & Đáp: Xây dựng Câu lệnh cho Tác nhân AI

Đó là tất cả từ chúng tôi. Chúng tôi rất vui được trả lời câu hỏi của bạn.

Câu hỏi: Bạn có thể nói về việc xây dựng câu lệnh cho các Tác nhân AI không? Bạn có cung cấp các câu lệnh dài hơn trước, sau đó lặp lại, hay bạn bắt đầu từng đoạn một? Quá trình đó trông như thế nào và những suy nghĩ đằng sau nó là gì?

Trả lời: Đó là một câu hỏi tuyệt vời. Tôi có thể quay lại màn hình của mình không? Tôi chỉ muốn trình diễn. Cảm ơn bạn.

Vâng, bạn có thể thấy đây là một câu lệnh cuối cùng mà chúng tôi đã đạt được, nhưng đây không phải là nơi chúng tôi bắt đầu. Tôi nghĩ câu trả lời cho câu hỏi của bạn là bạn bắt đầu với một câu lệnh ngắn, đơn giản. Vì vậy, trong trường hợp này, tôi có thể bắt đầu với một cái gì đó rất ngắn. Tôi sẽ để nguyên cái này một lát, và tôi sẽ nói, "Tìm kiếm trên web để trả lời câu hỏi." Và tôi có thể chỉ nói, "Tìm kiếm trên web một cách agentic." Tôi sẽ thay đổi cái này thành một câu hỏi khác: "Các mô hình Claude 4 tốt đến mức nào?" Và sau đó chúng ta sẽ chạy nó.

Vì vậy, bạn sẽ muốn bắt đầu với một cái gì đó rất đơn giản và chỉ xem nó hoạt động như thế nào. Bạn sẽ thường thấy rằng Claude có thể thực hiện tác vụ tốt ngay lập tức. Nhưng nếu bạn có nhiều nhu cầu hơn và bạn cần nó hoạt động thực sự nhất quán trong môi trường sản xuất, bạn sẽ nhận thấy các edge cases (trường hợp biên) hoặc những lỗi nhỏ khi bạn thử nghiệm với nhiều trường hợp sử dụng hơn. Và vì vậy bạn sẽ thêm những điều đó vào câu lệnh.

Vì vậy, tôi sẽ nói rằng việc xây dựng một câu lệnh cho Tác nhân AI, về mặt cụ thể, trông giống như sau: bắt đầu đơn giản, thử nghiệm, xem điều gì xảy ra, lặp lại từ đó, bắt đầu thu thập các trường hợp thử nghiệm mà mô hình thất bại hoặc thành công. Và sau đó, theo thời gian, cố gắng tăng số lượng trường hợp thử nghiệm thành công. Và cách để làm điều này là thêm hướng dẫn, thêm ví dụ vào câu lệnh. Nhưng bạn thực sự chỉ làm điều đó khi bạn tìm ra các edge cases là gì. Và bạn có thể thấy rằng nó nghĩ rằng các mô hình thực sự tốt. Vậy thì tuyệt vời.

Hỏi & Đáp: Few-shot Examples và Chain of Thought

Câu hỏi: Khi tôi thực hiện prompting thông thường và nó không phải agentic, tôi thường đưa ra một vài few-shot examples như "đây là đầu vào, đây là đầu ra." Điều này hoạt động rất tốt cho các tác vụ phân loại. Có một sự tương đồng nào ở đây trong thế giới agentic mà bạn thấy hữu ích không, hay tôi không nên nghĩ theo cách đó?

Trả lời: Đó là một câu hỏi tuyệt vời. Vâng, bạn có nên bao gồm các few-shot examples trong câu lệnh của mình không? Và các kỹ thuật prompting truyền thống liên quan đến việc cung cấp cho mô hình, nói rằng mô hình nên sử dụng một chain of thought và sau đó đưa ra một vài few-shot examples, như một loạt các ví dụ để bắt chước. Chúng tôi thấy rằng những kỹ thuật này không hiệu quả lắm đối với các mô hình tiên tiến hiện đại và đối với các Tác nhân AI. Lý do chính cho điều này là nếu bạn cung cấp cho mô hình một loạt các ví dụ về chính xác quy trình mà nó nên tuân theo, điều đó chỉ giới hạn mô hình quá nhiều. Những mô hình này thông minh hơn bạn có thể dự đoán. Và vì vậy bạn không muốn nói cho chúng biết chính xác những gì chúng cần làm. Tương tự, chain of thought đã được tinh chỉnh vào các mô hình tại thời điểm này. Các mô hình biết cách suy nghĩ trước. Chúng không cần phải được bảo như "hãy sử dụng chain of thought".

Nhưng những gì chúng ta có thể làm ở đây là, một, bạn có thể nói cho mô hình cách sử dụng tư duy của nó. Vì vậy, bạn biết tôi đã nói trước đó, thay vì nói với mô hình rằng bạn cần sử dụng một chain of thought, nó đã biết điều đó. Bạn chỉ có thể nói "sử dụng quy trình tư duy của bạn để lập kế hoạch tìm kiếm của bạn" hoặc "để lập kế hoạch những gì bạn sẽ làm về mặt lập mã", hoặc bạn có thể yêu cầu nó ghi nhớ những điều cụ thể trong quy trình tư duy của nó. Và điều đó giúp các Tác nhân AI đi đúng hướng.

Về các ví dụ, bạn sẽ muốn cung cấp cho mô hình các ví dụ nhưng không quá chi tiết/cứng nhắc. Tôi nghĩ chúng ta đã hết thời gian, nhưng bạn có thể đến gặp tôi trực tiếp và tôi sẽ nói chuyện với tất cả các bạn sau. Cảm ơn. Cảm ơn vì đã đến.