Hướng dẫn

Hướng Dẫn Prompt GPT-4.1 Toàn Tập: Bí Kíp Khai Phá Tối Đa Sức Mạnh AI Từ Chuyên Gia (Cập Nhật 2025)

Phạm Xuân Hiếu
87 Min Read
Hướng Dẫn Prompt GPT-4.1 Toàn Tập: Bí Kíp Khai Phá Tối Đa Sức Mạnh AI Từ Chuyên Gia (Cập Nhật 2025)

Chào mừng các nhà phát triển, kỹ sư AI và những người đam mê công nghệ đến với hướng dẫn toàn diện nhất về cách làm chủ kỹ thuật prompt cho GPT-4.1 – mô hình ngôn ngữ lớn tiên tiến vừa được OpenAI ra mắt! Nếu GPT-4o đã khiến bạn kinh ngạc, thì GPT-4.1 hứa hẹn sẽ định nghĩa lại những gì chúng ta có thể đạt được với trí tuệ nhân tạo, đặc biệt trong các lĩnh vực phức tạp như lập trình, tuân thủ hướng dẫn chi tiết và xử lý ngữ cảnh siêu dài.

Trong bài viết này Xuân Hiếu sẽ “giải nén” những kiến thức cốt lõi từ chính những thử nghiệm nội bộ sâu rộng của OpenAI, đồng thời cung cấp cho bạn những chiến lược, mẹo và ví dụ thực tiễn để bạn có thể “ra lệnh” cho GPT-4.1 một cách hiệu quả nhất. Dù bạn đang muốn xây dựng các tác tử AI tự động hóa, phân tích tài liệu hàng triệu token hay đơn giản là muốn câu trả lời từ AI trở nên chính xác và dễ điều khiển hơn, đây chính là chìa khóa dành cho bạn.

Tại sao việc làm chủ prompt GPT-4.1 lại quan trọng đến vậy? Bởi vì mô hình này, dù thông minh vượt trội, vẫn cần những “chỉ thị” rõ ràng từ con người. Prompt chính là cầu nối giao tiếp, và một prompt được xây dựng tốt sẽ khai phóng toàn bộ tiềm năng của GPT-4.1, biến ý tưởng của bạn thành hiện thực với tốc độ và độ chính xác chưa từng có.

Hãy cùng nhau khám phá hành trình làm chủ GPT-4.1, bắt đầu từ những thay đổi nền tảng cho đến các kỹ thuật chuyên sâu nhất!

Cú Nhảy Vọt Từ GPT-4o: Hiểu Rõ Bản Chất và Sự Khác Biệt Của GPT-4.1 Trong Prompting

Trước khi đi sâu vào các kỹ thuật cụ thể, điều quan trọng là phải nhận thức được sự khác biệt cốt lõi trong cách GPT-4.1 tiếp nhận và xử lý prompt so với các “tiền bối” như GPT-4o. Đây không chỉ là một bản nâng cấp đơn thuần về kích thước hay tốc độ, mà là một sự thay đổi trong “triết lý” hoạt động.

  • Tuân Thủ Hướng Dẫn Theo Nghĩa Đen Hơn: Điểm khác biệt lớn nhất và có lẽ quan trọng nhất là GPT-4.1 được huấn luyện để tuân theo các chỉ dẫn một cách chặt chẽ và theo nghĩa đen hơn rất nhiều. Trong khi các mô hình trước đây có xu hướng “suy luận” ý định của người dùng một cách khá tự do, đôi khi dẫn đến kết quả không mong muốn hoặc đi chệch hướng, GPT-4.1 lại ưu tiên sự rõ ràng và chính xác trong từng từ ngữ của prompt.
    • Hệ quả: Điều này có nghĩa là bạn cần phải cẩn trọng và chi tiết hơn trong cách diễn đạt yêu cầu. Những prompt mơ hồ hoặc thiếu cụ thể có thể không mang lại kết quả tốt như trước.
  • Khả Năng Điều Khiển Vượt Trội (Highly Steerable): Chính nhờ việc tuân thủ chặt chẽ hướng dẫn, GPT-4.1 trở nên cực kỳ dễ điều khiển. Nếu hành vi của mô hình không như bạn mong đợi, thường chỉ cần một câu điều chỉnh (clarifying sentence) rõ ràng, kiên quyết và không mơ hồ là đủ để đưa mô hình trở lại đúng hướng. Đây là một lợi thế lớn cho các nhà phát triển muốn kiểm soát đầu ra một cách chính xác.
  • Sự Cần Thiết Của “Di Chuyển Prompt” (Prompt Migration): Do những thay đổi này, các prompt đã được tối ưu hóa cho GPT-4 hay GPT-4o có thể không hoạt động hiệu quả ngay lập tức với GPT-4.1. Bạn sẽ cần xem xét lại và điều chỉnh (migrate) các prompt hiện có của mình để tận dụng tối đa sức mạnh mới này. Đừng ngạc nhiên nếu một prompt cũ cho ra kết quả khác biệt đáng kể!

Nắm vững những khác biệt nền tảng này là bước đầu tiên để bạn không bị “bỡ ngỡ” khi làm việc với GPT-4.1 và có thể nhanh chóng thích nghi, khai thác hiệu quả những cải tiến vượt trội của nó.

Nguyên Tắc Vàng Trong Prompting GPT-4.1: Nền Tảng Cho Mọi Thành Công

Mặc dù GPT-4.1 mang đến những thay đổi đáng kể, nhiều nguyên tắc “bất hủ” trong nghệ thuật prompting vẫn giữ nguyên giá trị. Đây là những nền tảng vững chắc giúp bạn xây dựng những lời nhắc hiệu quả, bất kể độ phức tạp của tác vụ.

  1. Cung Cấp Ngữ Cảnh Rõ Ràng (Provide Context): Giống như con người, AI cần ngữ cảnh để hiểu đúng yêu cầu. Cung cấp thông tin nền, dữ liệu liên quan hoặc các ví dụ (few-shot examples) sẽ giúp GPT-4.1 nắm bắt ý định của bạn nhanh hơn và chính xác hơn.
  2. Hướng Dẫn Cụ Thể và Minh Bạch (Specific and Clear Instructions): “Hãy viết một bài thơ” sẽ cho kết quả khác xa với “Hãy viết một bài thơ lục bát 4 câu về mùa thu Hà Nội, sử dụng giọng văn nhẹ nhàng, lãng mạn.” Sự cụ thể loại bỏ sự mơ hồ và hướng mô hình đến kết quả mong muốn.
  3. Kích Thích Khả Năng Lập Kế Hoạch (Inducing Planning via Prompting): Đối với các tác vụ phức tạp, việc yêu cầu mô hình “suy nghĩ từng bước” hoặc “lập kế hoạch trước khi hành động” (ví dụ: “Hãy phân tích vấn đề, đề xuất 3 giải pháp, sau đó chọn giải pháp tốt nhất và giải thích lý do”) có thể cải thiện đáng kể chất lượng đầu ra và trí thông minh của mô hình.
  4. Thử Nghiệm và Lặp Lại Liên Tục (Iterate and Experiment): Kỹ thuật AI, và đặc biệt là prompt engineering, là một ngành khoa học thực nghiệm. Không có một công thức “one-size-fits-all”. Những gì hiệu quả với tác vụ này có thể không hiệu quả với tác vụ khác.
    • Xây dựng Đánh giá (Informative Evals): Thiết lập các phương pháp đánh giá (evals) kết quả của prompt để đo lường sự cải thiện một cách khách quan.
    • Lặp lại Thường xuyên (Iterate Often): Liên tục tinh chỉnh, thử nghiệm các biến thể khác nhau của prompt và theo dõi kết quả. Quá trình này sẽ giúp bạn “mài giũa” kỹ năng và tìm ra những gì hoạt động tốt nhất cho trường hợp sử dụng cụ thể của bạn.

Hãy nhớ rằng, GPT-4.1 được thiết kế để đáp ứng tốt với các prompt được xây dựng cẩn thận. Đầu tư thời gian vào việc học và thực hành những nguyên tắc này sẽ mang lại lợi ích to lớn trong việc khai thác tiềm năng của mô hình.

Làm Chủ Quy Trình Làm Việc Mang Tính Tác Tử (Agentic Workflows) với GPT-4.1: Xây Dựng AI Tự Chủ và Hiệu Quả

Một trong những ứng dụng thú vị và mạnh mẽ nhất của GPT-4.1 chính là khả năng xây dựng các quy trình làm việc mang tính tác tử (agentic workflows). Hãy tưởng tượng bạn có thể tạo ra các “trợ lý AI” không chỉ trả lời câu hỏi, mà còn có khả năng tự chủ thực hiện một chuỗi các hành động, sử dụng công cụ, và giải quyết các vấn đề phức tạp một cách độc lập. GPT-4.1 chính là nền tảng lý tưởng cho điều đó.

Thực tế, trong quá trình huấn luyện mô hình, OpenAI đã đặc biệt nhấn mạnh việc cung cấp một dải rộng các “quỹ đạo” giải quyết vấn đề mang tính tác tử đa dạng. Kết quả? Bộ khai thác tác tử (agentic harness) của họ cho GPT-4.1 đã đạt được hiệu suất tiên tiến nhất (state-of-the-art) đối với các mô hình phi lý luận trên SWE-bench Verified (một bộ tiêu chuẩn đánh giá khả năng giải quyết vấn đề kỹ thuật phần mềm), giải quyết thành công đến 55% các vấn đề được đặt ra. Đây là một minh chứng rõ ràng cho tiềm năng to lớn của GPT-4.1 trong lĩnh vực này.

Vậy, làm thế nào để chúng ta “ra lệnh” cho GPT-4.1 hoạt động như một tác tử hiệu quả? Bí mật nằm ở việc thiết kế Prompt Hệ Thống (System Prompt) một cách thông minh.

“Thần Chú” Trong Prompt Hệ Thống: 3 Lời Nhắc Không Thể Bỏ Qua Cho Tác Tử GPT-4.1

Để khai thác tối đa năng lực tác tử của GPT-4.1, OpenAI khuyến nghị bạn nên đưa ba loại “lời nhắc” (reminders) quan trọng sau vào tất cả các prompt dành cho tác tử. Các ví dụ dưới đây được tối ưu cho quy trình viết mã mang tính tác tử, nhưng bạn hoàn toàn có thể điều chỉnh cho các mục đích khác.

Tính Bền Bỉ (Persistence): Đảm Bảo Tác Tử Không “Bỏ Cuộc” Sớm

    • Mục đích: Lời nhắc này giúp mô hình hiểu rằng nó đang tham gia vào một cuộc hội thoại hoặc một quy trình gồm nhiều bước, nhiều lượt tương tác. Nó ngăn chặn việc mô hình kết thúc lượt của mình và trả lại quyền kiểm soát cho người dùng một cách quá sớm, trước khi vấn đề được giải quyết triệt để.
    • Ví dụ lời nhắc (đã Việt hóa và tối ưu):
Bạn là một tác tử AI chuyên nghiệp. Hãy kiên trì thực hiện nhiệm vụ cho đến khi truy vấn của người dùng được giải quyết HOÀN TOÀN. Chỉ kết thúc lượt làm việc của bạn và trả lại quyền kiểm soát khi bạn CHẮC CHẮN rằng vấn đề đã được xử lý xong.

Gọi Công Cụ (Tool-calling): Khuyến Khích Sử Dụng Công Cụ, Hạn Chế “Tự Bịa”

  • Mục đích: Lời nhắc này thúc đẩy mô hình tận dụng tối đa các công cụ (tools) được cung cấp cho nó, thay vì cố gắng “đoán mò” hoặc “tự bịa” thông tin, đặc biệt khi đối mặt với những yêu cầu cần truy xuất dữ liệu hoặc thực thi hành động cụ thể.
  • Ví dụ lời nhắc (đã Việt hóa và tối ưu):
Nếu bạn không chắc chắn về nội dung của một tệp, cấu trúc mã nguồn, hoặc bất kỳ thông tin nào liên quan đến yêu cầu của người dùng, HÃY SỬ DỤNG các công cụ được cung cấp để đọc tệp, tìm kiếm thông tin và thu thập dữ liệu liên quan. TUYỆT ĐỐI KHÔNG được đoán hoặc tự tạo ra câu trả lời.

Lập Kế Hoạch (Planning) [Tùy chọn]: Tư Duy Rõ Ràng Trước Khi Hành Động

  • Mục đích: Nếu bạn muốn tác tử của mình có một quy trình làm việc minh bạch và dễ kiểm soát hơn, lời nhắc này sẽ đảm bảo mô hình chủ động lập kế hoạch và suy ngẫm về mỗi lệnh gọi công cụ bằng văn bản. Thay vì chỉ âm thầm thực hiện một chuỗi các lệnh gọi công cụ, mô hình sẽ “tư duy thành tiếng”, giúp bạn hiểu rõ hơn về cách nó tiếp cận vấn đề.
  • Ví dụ lời nhắc (đã Việt hóa và tối ưu):
BẮT BUỘC phải lập kế hoạch chi tiết trước MỖI LẦN gọi hàm (tool call) và suy ngẫm kỹ lưỡng về kết quả của các lần gọi hàm TRƯỚC ĐÓ. KHÔNG được thực hiện toàn bộ quy trình này chỉ bằng cách liên tiếp gọi hàm mà không có bước lập kế hoạch và suy ngẫm, vì điều này có thể làm suy giảm khả năng giải quyết vấn đề và tư duy sâu sắc của bạn.

 

Sức mạnh tổng hợp của ba lời nhắc này là rất đáng kể. GPT-4.1 được huấn luyện để phản hồi cực kỳ sát sao với cả hướng dẫn từ người dùng và prompt hệ thống trong môi trường tác tử. Việc tuân thủ ba chỉ dẫn đơn giản này đã giúp OpenAI tăng điểm SWE-bench Verified nội bộ của họ lên gần 20%! Vì vậy, hãy coi đây là điểm khởi đầu vàng cho bất kỳ prompt tác tử nào bạn xây dựng. Chúng biến GPT-4.1 từ một chatbot đơn thuần thành một “tác tử” chủ động, hăng hái, có khả năng tự thúc đẩy tương tác và giải quyết vấn đề một cách độc lập.

Nâng Tầm Tương Tác: Kỹ Thuật Gọi Công Cụ (Tool Calling) Nâng Cao Với GPT-4.1

So với các phiên bản tiền nhiệm, GPT-4.1 đã trải qua quá trình huấn luyện chuyên sâu hơn về việc sử dụng hiệu quả các công cụ được truyền dưới dạng đối số (arguments) trong một yêu cầu API của OpenAI. Đây là một cải tiến quan trọng giúp các nhà phát triển tích hợp GPT-4.1 vào các hệ thống phức tạp một cách dễ dàng và mạnh mẽ hơn.

  • Ưu tiên sử dụng trường tools trong API: OpenAI đặc biệt khuyến khích các nhà phát triển chỉ sử dụng trường tools được cung cấp trong API để định nghĩa và truyền các công cụ cho mô hình. Tránh việc “chèn thủ công” mô tả công cụ vào prompt và tự viết một trình phân tích cú pháp (parser) riêng cho các lệnh gọi công cụ – một phương pháp có thể đã được sử dụng trước đây.
    • Lợi ích: Sử dụng trường tools là cách tốt nhất để giảm thiểu lỗi, đảm bảo mô hình luôn hoạt động trong “phạm vi phân phối” (in distribution) đã được huấn luyện khi thực hiện các chuỗi gọi công cụ. Trong các thử nghiệm nội bộ của OpenAI, họ đã ghi nhận tỷ lệ vượt qua SWE-bench Verified tăng 2% khi sử dụng mô tả công cụ được phân tích cú pháp qua API so với việc chèn schema thủ công vào prompt hệ thống.
  • Đặt Tên và Mô Tả Công Cụ Rõ Ràng – Chìa Khóa Để AI Hiểu Đúng:
    • Tên Công Cụ (Tool Name): Đặt tên một cách rõ ràng, súc tích, thể hiện chính xác mục đích của công cụ.
    • Mô Tả Công Cụ (Tool Description): Cung cấp một mô tả chi tiết, dễ hiểu trong trường “description”. Mô tả này nên giải thích công cụ làm gì, khi nào nên sử dụng và có thể cả những gì nó không làm.
    • Tham Số Công Cụ (Tool Parameters): Tương tự, đối với mỗi tham số (param) của công cụ, hãy đảm bảo tên gọi và mô tả phải rõ ràng, giúp mô hình hiểu và sử dụng chúng một cách chính xác.
  • Xử Lý Công Cụ Phức Tạp – Sức Mạnh Của Ví Dụ: Nếu công cụ của bạn có logic hoạt động phức tạp hoặc nhiều tham số, việc cung cấp ví dụ sử dụng (usage examples) là cực kỳ hữu ích.
    • Khuyến nghị: Tạo một mục riêng biệt, ví dụ # Examples hoặc <examples_section>, trong prompt hệ thống của bạn và đặt các ví dụ minh họa vào đó. Không nên nhồi nhét ví dụ vào trường “description” của công cụ, vì trường này nên giữ sự kỹ lưỡng nhưng tương đối ngắn gọn.
    • Giá trị của ví dụ: Ví dụ giúp mô hình hiểu rõ:
      • Khi nào nên kích hoạt một công cụ cụ thể.
      • Liệu có cần bao gồm văn bản từ người dùng (user text) bên cạnh lệnh gọi công cụ hay không.
      • Các giá trị tham số nào là phù hợp cho những loại đầu vào (inputs) khác nhau.
    • Mẹo: Đừng quên bạn có thể sử dụng tính năng “Generate Anything” trong Prompt Playground của OpenAI để có được những gợi ý ban đầu tốt cho việc định nghĩa công cụ mới của mình.

Kích Hoạt Tư Duy “Thành Tiếng”: Lập Kế Hoạch và Chuỗi Suy Nghĩ Trong Tác Tử GPT-4.1

Như đã đề cập ở phần Lời nhắc Hệ thống, bạn có thể chủ động yêu cầu các tác tử xây dựng bằng GPT-4.1 phải lập kế hoạch và suy ngẫm (plan and reflect) giữa các lần gọi công cụ, thay vì chỉ âm thầm thực hiện một chuỗi lệnh gọi không bị gián đoạn.

Điều quan trọng cần lưu ý: GPT-4.1 không phải là một “mô hình suy luận” (reasoning model) theo nghĩa là nó tự động tạo ra một “chuỗi suy nghĩ” (chain of thought) nội bộ ẩn giấu trước khi đưa ra câu trả lời. Tuy nhiên, thông qua prompt, nhà phát triển hoàn toàn có thể thúc đẩy (induce) mô hình tạo ra một kế hoạch từng bước, rõ ràng và minh bạch bằng văn bản. Bạn có thể hình dung đây là quá trình mô hình đang “suy nghĩ thành tiếng”.

Việc này mang lại nhiều lợi ích:

  • Tăng tính minh bạch: Giúp bạn hiểu rõ hơn về “quá trình tư duy” của tác tử.
  • Dễ gỡ lỗi: Khi có vấn đề xảy ra, việc xem lại kế hoạch của tác tử sẽ giúp xác định nguyên nhân dễ dàng hơn.
  • Cải thiện hiệu suất: Trong các thử nghiệm của OpenAI với tác vụ tác tử trên SWE-bench Verified, việc kích hoạt kế hoạch rõ ràng này đã giúp tăng tỷ lệ giải quyết thành công vấn đề lên 4%.

Để làm điều này, bạn có thể sử dụng các biến thể của lời nhắc “Lập kế hoạch” đã được giới thiệu ở phần Lời nhắc Hệ thống.

Lưu ý nhỏ: Trong tài liệu gốc, OpenAI có chia sẻ một ví dụ prompt tác tử chi tiết mà họ đã sử dụng để đạt điểm cao nhất trên SWE-bench Verified. Prompt này bao gồm các hướng dẫn cụ thể về quy trình làm việc và chiến lược giải quyết vấn đề, là một tài liệu tham khảo quý giá cho bất kỳ ai muốn xây dựng tác tử AI mạnh mẽ.

Khai Thác Sức Mạnh Ngữ Cảnh Dài Của GPT-4.1: Phân Tích Hàng Triệu Token Dữ Liệu Dễ Dàng

Một trong những giới hạn cố hữu của các mô hình ngôn ngữ lớn trước đây là khả năng xử lý một lượng lớn thông tin đầu vào cùng lúc. Với GPT-4.1, rào cản này đã được nới lỏng đáng kể. Mô hình này sở hữu một cửa sổ ngữ cảnh đầu vào (input context window) cực lớn, lên đến 1 triệu token, hoạt động với hiệu suất cao.

Điều này mở ra vô vàn khả năng ứng dụng mới và mạnh mẽ, bao gồm:

  • Phân tích cú pháp tài liệu có cấu trúc (Structured Document Parsing): Dễ dàng “đọc” và hiểu các tài liệu dài, phức tạp như hợp đồng, báo cáo tài chính, tài liệu nghiên cứu.
  • Xếp hạng lại thông tin (Re-ranking): Đưa vào một lượng lớn kết quả tìm kiếm hoặc tài liệu và yêu cầu mô hình xếp hạng lại chúng dựa trên các tiêu chí cụ thể.
  • Chọn lọc thông tin liên quan (Selecting Relevant Information): GPT-4.1 có khả năng vượt trội trong việc “lọc nhiễu”, tức là xác định và trích xuất những thông tin quan trọng từ một biển dữ liệu, đồng thời bỏ qua những phần không liên quan.
  • Suy luận đa bước sử dụng ngữ cảnh (Performing Multi-hop Reasoning using Context): Giải quyết các câu hỏi hoặc vấn đề đòi hỏi phải kết nối thông tin từ nhiều phần khác nhau trong một hoặc nhiều tài liệu dài.

Kích Thước Ngữ Cảnh Tối Ưu: Tìm Điểm Cân Bằng Cho Hiệu Suất

OpenAI đã quan sát thấy hiệu suất rất tốt của GPT-4.1 trên các bài đánh giá “tìm kim đáy bể” (needle-in-a-haystack – tức là tìm một thông tin nhỏ trong một khối lượng lớn dữ liệu) cho đến toàn bộ cửa sổ ngữ cảnh 1 triệu token. Mô hình cũng thể hiện năng lực mạnh mẽ khi xử lý các tác vụ phức tạp với sự pha trộn giữa mã lệnh, tài liệu liên quan và cả những thông tin không liên quan.

Tuy nhiên, có một vài lưu ý quan trọng:

  • Giới hạn tiềm ẩn: Hiệu suất xử lý ngữ cảnh dài có thể suy giảm khi số lượng mục cần được truy xuất (retrieved) trở nên quá lớn, hoặc khi tác vụ đòi hỏi phải thực hiện các suy luận phức tạp yêu cầu kiến thức về trạng thái của toàn bộ ngữ cảnh (ví dụ điển hình là thực hiện tìm kiếm trên đồ thị – graph search – trong một ngữ cảnh khổng lồ).
  • Cân nhắc chiến lược: Đối với các tác vụ cực lớn, việc chia nhỏ vấn đề hoặc sử dụng các kỹ thuật truy xuất thông tin (information retrieval) trước khi đưa vào mô hình vẫn có thể là một chiến lược hiệu quả.

Tinh Chỉnh Mức Độ Phụ Thuộc Vào Ngữ Cảnh: Khi Nào Nên Tin Vào AI, Khi Nào Cần Dữ Liệu Cung Cấp?

Khi đặt câu hỏi cho GPT-4.1, hãy cân nhắc xem bạn muốn mô hình dựa chủ yếu vào kiến thức nội bộ đã được huấn luyện của nó, hay chỉ nên dựa vào thông tin bạn cung cấp trong ngữ cảnh.

  • Sử dụng kiến thức nội bộ: Đôi khi, điều quan trọng là mô hình có thể tự mình kết nối các khái niệm, đưa ra những suy luận logic dựa trên kho kiến thức khổng lồ của nó. Điều này hữu ích cho các câu hỏi mở hoặc cần sự sáng tạo.
  • Chỉ sử dụng ngữ cảnh được cung cấp: Trong nhiều trường hợp khác, đặc biệt là khi làm việc với thông tin nhạy cảm, độc quyền hoặc cần độ chính xác tuyệt đối dựa trên nguồn cụ thể, bạn sẽ muốn mô hình chỉ sử dụng ngữ cảnh bạn đưa vào.

May mắn thay, bạn có thể “hướng dẫn” GPT-4.1 về mức độ phụ thuộc này thông qua prompt. Dưới đây là ví dụ về cách điều chỉnh (Việt hóa dựa trên hướng dẫn của OpenAI):

  • Chỉ thị chỉ sử dụng ngữ cảnh được cung cấp (cho các tác vụ yêu cầu độ chính xác cao từ nguồn):
// Hướng dẫn
- Chỉ sử dụng các tài liệu trong Ngữ Cảnh Bên Ngoài được cung cấp để trả lời Truy Vấn Của Người Dùng. Nếu bạn không biết câu trả lời dựa trên ngữ cảnh này, bạn PHẢI trả lời "Tôi không có đủ thông tin cần thiết để trả lời câu hỏi đó", ngay cả khi người dùng khăng khăng yêu cầu bạn trả lời.
  • Cho phép kết hợp kiến thức nội bộ và ngữ cảnh bên ngoài (mặc định, linh hoạt hơn):
// Hướng dẫn
- Theo mặc định, hãy sử dụng Ngữ Cảnh Bên Ngoài được cung cấp để trả lời Truy Vấn Của Người Dùng. Tuy nhiên, nếu cần thiết phải có thêm kiến thức cơ bản khác để trả lời, và bạn tự tin về câu trả lời đó, bạn có thể sử dụng một phần kiến thức của riêng mình để hỗ trợ việc trả lời câu hỏi.

Tổ Chức Prompt Cho Ngữ Cảnh Dài: Vị Trí Hướng Dẫn Ảnh Hưởng Đến Kết Quả

Đặc biệt khi làm việc với ngữ cảnh dài, cách bạn sắp xếp các hướng dẫn và phần ngữ cảnh trong prompt có thể ảnh hưởng đáng kể đến hiệu suất của mô hình.

OpenAI đã phát hiện ra quy tắc sau thông qua thử nghiệm:

  • Vị trí lý tưởng nhất: Nếu bạn có một khối lượng ngữ cảnh lớn trong prompt, hãy đặt các hướng dẫn (instructions) của bạn ở cả đầu và cuối phần ngữ cảnh được cung cấp. Cấu trúc này (hướng dẫn -> ngữ cảnh -> hướng dẫn lặp lại) cho thấy hiệu suất tốt hơn so với việc chỉ đặt hướng dẫn ở một vị trí (chỉ ở trên hoặc chỉ ở dưới).
  • Nếu chỉ đặt hướng dẫn một lần: Trong trường hợp bạn chỉ muốn đặt các hướng dẫn một lần duy nhất, thì việc đặt chúng ở phía trên phần ngữ cảnh (hướng dẫn -> ngữ cảnh) sẽ hoạt động tốt hơn là đặt chúng ở phía dưới (ngữ cảnh -> hướng dẫn).

Việc ghi nhớ những mẹo nhỏ về tổ chức này có thể giúp bạn tối ưu hóa cách GPT-4.1 “tiêu hóa” và phản hồi lại lượng lớn thông tin bạn cung cấp.

 

Khai Phá Tư Duy Sâu Sắc: Sức Mạnh Của Chuỗi Suy Nghĩ (Chain of Thought – CoT) Với GPT-4.1

Như chúng ta đã thảo luận ở phần về Quy trình Làm việc Tác tử, GPT-4.1 không phải là một “mô hình suy luận” (reasoning model) theo nghĩa truyền thống – tức là nó không tự động tạo ra một dòng suy nghĩ nội bộ, ẩn giấu trước khi đưa ra câu trả lời. Tuy nhiên, điều này không có nghĩa là chúng ta không thể hướng dẫn nó “suy nghĩ” một cách có hệ thống!

Việc nhắc mô hình suy nghĩ từng bước (prompting the model to think step by step), hay còn gọi là kỹ thuật Chuỗi Suy Nghĩ (Chain of Thought – CoT), là một phương pháp cực kỳ hiệu quả để:

  • Chia nhỏ vấn đề phức tạp: Giúp mô hình phân tách các bài toán lớn thành những phần nhỏ hơn, dễ quản lý hơn.
  • Giải quyết từng phần: Xử lý từng bước một cách logic.
  • Cải thiện chất lượng đầu ra tổng thể: Thường dẫn đến những câu trả lời chính xác, toàn diện và sâu sắc hơn.

Sự đánh đổi: Việc yêu cầu CoT thường làm tăng số lượng token đầu ra, điều này có thể dẫn đến chi phí cao hơn và độ trễ lớn hơn một chút. Tuy nhiên, lợi ích về chất lượng thường rất xứng đáng, đặc biệt đối với các tác vụ đòi hỏi sự phân tích kỹ lưỡng.

Một tin tốt là GPT-4.1 đã được huấn luyện để hoạt động tốt trong việc suy luận mang tính tác tử và giải quyết các vấn đề trong thế giới thực. Do đó, nó thường không đòi hỏi quá nhiều nỗ lực prompting phức tạp để có thể thực hiện CoT một cách hiệu quả.

Điểm Khởi Đầu Cho Prompt CoT: Một Chỉ Dẫn Đơn Giản Mà Hiệu Quả

OpenAI khuyến nghị bạn có thể bắt đầu bằng một chỉ dẫn CoT cơ bản, thường được đặt ở cuối prompt của bạn. Dưới đây là một ví dụ điển hình (đã Việt hóa và điều chỉnh):

... (phần còn lại của prompt của bạn) ...

Đầu tiên, hãy suy nghĩ cẩn thận từng bước một về những tài liệu nào là cần thiết để trả lời truy vấn này.
Tiếp theo, hãy liệt kê TIÊU ĐỀ và ID của mỗi tài liệu mà bạn xác định là quan trọng.
Cuối cùng, hãy định dạng các ID đó thành một danh sách rõ ràng.

Chỉ dẫn đơn giản này yêu cầu mô hình thực hiện một quy trình gồm ba bước: phân tích nhu cầu, xác định tài liệu, và định dạng kết quả. Đây là một cách tuyệt vời để “khởi động” tư duy tuần tự của mô hình.

Nâng Cấp Prompt CoT Của Bạn: Từ Thử Nghiệm Đến Tối Ưu Hóa

Sau khi bắt đầu với một prompt CoT cơ bản, bạn nên liên tục cải thiện nó dựa trên kết quả thực tế:

  1. Kiểm Tra Lỗi (Audit Failures): Xem xét kỹ lưỡng những trường hợp mà prompt CoT của bạn không mang lại kết quả như mong đợi. Lỗi nằm ở đâu trong “chuỗi suy nghĩ” của mô hình?
  2. Xử Lý Lỗi Hệ Thống: Nếu bạn nhận thấy các lỗi lặp đi lặp lại trong cách mô hình lập kế hoạch hoặc suy luận (ví dụ: luôn bỏ qua một bước quan trọng, hoặc hiểu sai một loại thông tin nhất định), hãy giải quyết chúng bằng cách thêm vào các hướng dẫn rõ ràng và cụ thể hơn trong prompt CoT của bạn.
  3. Đa Dạng Chiến Lược: Trong một prompt CoT không bị ràng buộc quá chặt chẽ, mô hình có thể thử nghiệm nhiều “chiến lược suy nghĩ” khác nhau. Nếu bạn quan sát thấy một phương pháp tiếp cận cụ thể nào đó hoạt động đặc biệt tốt cho loại vấn đề của mình, hãy hệ thống hóa (codify) chiến lược đó thành các bước rõ ràng trong prompt. Điều này giúp đảm bảo tính nhất quán và hiệu quả.
  4. Các Nguồn Lỗi Phổ Biến Cần Lưu Ý:
    • Hiểu sai ý định của người dùng (Misunderstanding user intent): Mô hình có thể bắt đầu “suy nghĩ” theo một hướng không chính xác nếu nó không nắm bắt đúng yêu cầu ban đầu.
    • Thu thập hoặc phân tích ngữ cảnh không đầy đủ (Insufficient context gathering or analysis): Nếu các bước “thu thập thông tin” trong CoT không hiệu quả, các bước suy luận sau đó sẽ thiếu nền tảng.
    • Tư duy từng bước không đầy đủ hoặc không chính xác (Insufficient or incorrect step-by-step thinking): Mô hình có thể bỏ qua các bước logic quan trọng hoặc mắc lỗi trong quá trình suy luận ở một bước cụ thể.

Hãy nhớ rằng, mục tiêu là hướng dẫn mô hình suy nghĩ một cách có phương pháp hơn, chứ không phải là viết kịch bản chi tiết cho mọi hành động của nó.

Ví Dụ Prompt CoT Nâng Cao: Hướng Dẫn Mô Hình Phân Tích Có Hệ Thống

Dưới đây là một ví dụ về prompt CoT được thiết kế để hướng dẫn mô hình tập trung một cách có phương pháp hơn vào việc phân tích ý định của người dùng và xem xét ngữ cảnh liên quan trước khi đưa ra câu trả lời cuối cùng. Cấu trúc này giúp đảm bảo một quy trình tư duy toàn diện hơn. (Ví dụ được Việt hóa và điều chỉnh dựa trên hướng dẫn của OpenAI):

# Chiến Lược Suy Luận (Reasoning Strategy)
Bạn PHẢI tuân theo các bước sau một cách cẩn thận:

1. **Phân Tích Truy Vấn (Query Analysis):**
* Phân tách và phân tích kỹ lưỡng truy vấn của người dùng cho đến khi bạn hoàn toàn tự tin về những gì họ có thể đang hỏi.
* Xem xét Ngữ Cảnh Bên Ngoài được cung cấp để giúp làm rõ bất kỳ thông tin nào không rõ ràng hoặc dễ gây nhầm lẫn trong truy vấn.

2. **Phân Tích Ngữ Cảnh (Context Analysis):**
* Cẩn thận lựa chọn và phân tích một tập hợp lớn các tài liệu có khả năng liên quan từ Ngữ Cảnh Bên Ngoài.
* Ưu tiên tối đa hóa khả năng "gọi nhớ" (recall) - tức là thà chọn thừa một vài tài liệu không liên quan còn hơn bỏ sót những tài liệu quan trọng. Nếu các tài liệu chính xác không nằm trong danh sách này, câu trả lời cuối cùng của bạn chắc chắn sẽ sai.
* Đối với mỗi tài liệu được chọn, hãy thực hiện các bước phân tích sau:
* **a. Phân tích (Analysis):** Đánh giá xem tài liệu đó có thể liên quan hoặc không liên quan như thế nào đến việc trả lời truy vấn.
* **b. Xếp hạng Mức độ Liên quan (Relevance rating):** [Cao, Trung bình, Thấp, Không có]

3. **Tổng Hợp (Synthesis):**
* Tóm tắt những tài liệu nào là liên quan nhất và giải thích lý do tại sao.
* Bao gồm TẤT CẢ các tài liệu có xếp hạng mức độ liên quan từ "Trung bình" trở lên.

# Câu Hỏi Của Người Dùng (User Question)
{user_question}

# Ngữ Cảnh Bên Ngoài (External Context)
{external_context}

Đầu tiên, hãy suy nghĩ cẩn thận từng bước về những tài liệu nào là cần thiết để trả lời truy vấn, tuân thủ chặt chẽ Chiến Lược Suy Luận đã được cung cấp.
Sau đó, hãy liệt kê TIÊU ĐỀ và ID của mỗi tài liệu.
Cuối cùng, định dạng các ID đó thành một danh sách.

 

Ví dụ này cho thấy cách bạn có thể cấu trúc một quy trình CoT chi tiết, yêu cầu mô hình thực hiện các bước phân tích cụ thể trước khi tổng hợp thông tin. Điều này đặc biệt hữu ích cho các tác vụ RAG (Retrieval Augmented Generation) hoặc các ứng dụng hỏi đáp phức tạp dựa trên tài liệu.

 

Đạt Đến Độ Chính Xác Tuyệt Đối: Làm Chủ Khả Năng Tuân Theo Hướng Dẫn Của GPT-4.1

GPT-4.1 không chỉ thông minh hơn trong việc hiểu và tạo ra ngôn ngữ, mà còn thể hiện một hiệu suất tuân theo hướng dẫn (instruction-following performance) vượt trội. Đây là một tin tuyệt vời cho các nhà phát triển, bởi nó cho phép bạn định hình và kiểm soát kết quả đầu ra một cách chính xác đến không ngờ cho các trường hợp sử dụng cụ thể của mình.

Bạn có thể “ra lệnh” cho GPT-4.1 về gần như mọi khía cạnh:

  • Các bước suy luận phức tạp trong quy trình tác tử.
  • Giọng điệu (tone) và phong cách (voice) của phản hồi.
  • Thông tin chi tiết về cách gọi công cụ.
  • Định dạng đầu ra mong muốn (JSON, Markdown, XML, v.v.).
  • Các chủ đề cần tránh hoặc cách xử lý thông tin nhạy cảm.

Tuy nhiên, có một điểm then chốt cần ghi nhớ: vì GPT-4.1 tuân theo hướng dẫn theo nghĩa đen hơn (more literally) so với các phiên bản trước, các nhà phát triển cần phải cung cấp các đặc tả rõ ràng và tường minh hơn về những gì mô hình NÊN làm và KHÔNG NÊN làm. Những quy tắc ngầm (implicit rules) mà các mô hình trước đây có thể “tự suy luận” giờ đây ít được GPT-4.1 giả định hơn.

Cảnh báo quan trọng: Các prompt đã được tối ưu hóa cho GPT-4, GPT-4o hoặc các mô hình khác có thể không hoạt động ngay lập tức hoặc cho kết quả như mong đợi với GPT-4.1. Bạn có thể cần phải điều chỉnh chúng, làm cho các hướng dẫn trở nên cụ thể hơn để phù hợp với “tính cách” mới này của mô hình.

Quy Trình Vàng: Phát Triển và Gỡ Lỗi Hướng Dẫn Cho Prompt GPT-4.1

Để giúp bạn xây dựng những prompt với các hướng dẫn hiệu quả, OpenAI đề xuất một quy trình làm việc gồm các bước sau:

  1. Bước 1: Bắt Đầu với “Khung Sườn” Tổng Thể
    • Tạo một mục tổng quan như "Quy Tắc Phản Hồi Chung" (Overall “Response Rules”) hoặc "Hướng Dẫn Chính" (Instructions) trong prompt của bạn.
    • Sử dụng các gạch đầu dòng (bullet points) để liệt kê những chỉ dẫn cấp cao, bao quát nhất về hành vi mong muốn của mô hình.
  2. Bước 2: Đi Sâu vào Chi Tiết cho Hành Vi Cụ Thể
    • Nếu bạn muốn thay đổi hoặc kiểm soát một hành vi cụ thể nào đó của mô hình (ví dụ: cách nó chào hỏi, cách nó từ chối một yêu cầu), hãy thêm một mục con để cung cấp thêm chi tiết cho danh mục đó.
    • Ví dụ: tạo mục # Cụm Từ Mẫu (Sample Phrases) để đưa ra các ví dụ về cách mô hình nên phản hồi trong các tình huống nhất định.
  3. Bước 3: Định Nghĩa Quy Trình Làm Việc Từng Bước
    • Nếu có những bước cụ thể mà bạn muốn mô hình tuân theo trong quy trình làm việc của nó (ví dụ: trong một tác vụ phân tích dữ liệu hoặc trả lời khách hàng), hãy tạo một danh sách được đánh số thứ tự (ordered list).
    • Sau đó, hãy chỉ thị rõ ràng cho mô hình phải tuân theo các bước này.
  4. Bước 4: Khi Hành Vi Vẫn “Chệch Hướng” – Gỡ Lỗi và Tinh Chỉnh
    • 4.1. Kiểm Tra Xung Đột và Thiếu Rõ Ràng:
      • Tìm kiếm các hướng dẫn có thể đang xung đột với nhau, hoặc các hướng dẫn chưa đủ chi tiết (underspecified), hoặc đơn giản là sai.
      • Lưu ý quan trọng từ OpenAI: Nếu có các hướng dẫn xung đột, GPT-4.1 có xu hướng tuân theo hướng dẫn nào xuất hiện gần cuối prompt hơn.
    • 4.2. Sức Mạnh Của Ví Dụ:
      • Thêm các ví dụ (examples) minh họa rõ ràng hành vi bạn mong muốn.
      • Đảm bảo rằng bất kỳ hành vi quan trọng nào được thể hiện trong ví dụ của bạn cũng phải được trích dẫn hoặc đề cập trong các quy tắc/hướng dẫn bằng lời của bạn. Sự nhất quán giữa quy tắc và ví dụ là rất quan trọng.
    • 4.3. Về Việc Sử Dụng Chữ IN HOA và “Khuyến Khích”:
      • Theo khuyến nghị, thường không cần thiết phải sử dụng tất cả chữ IN HOA (ALL-CAPS) hoặc các hình thức “khuyến khích” khác như “hối lộ” (ví dụ: “tôi sẽ boa cho bạn nếu bạn làm tốt”) hoặc “đe dọa” (ví dụ: “bạn sẽ bị phạt nếu làm sai”).
      • Hãy bắt đầu mà không có những kỹ thuật này. Chỉ sử dụng chúng nếu thực sự cần thiết cho trường hợp cụ thể của bạn sau khi các phương pháp khác không hiệu quả.
      • Cảnh báo: Nếu các prompt hiện tại của bạn đang sử dụng nhiều những kỹ thuật này, nó có thể khiến GPT-4.1 chú ý đến chúng một cách quá nghiêm ngặt, đôi khi dẫn đến hành vi cứng nhắc hoặc không mong muốn.
  • Mẹo Chuyên Gia: Việc sử dụng các Môi trường Phát triển Tích hợp (IDE) hỗ trợ AI có thể cực kỳ hữu ích trong quá trình lặp lại và tinh chỉnh prompt. Chúng có thể giúp bạn kiểm tra tính nhất quán, phát hiện xung đột, dễ dàng thêm ví dụ, hoặc thực hiện các cập nhật đồng bộ (ví dụ: thêm một quy tắc mới và cập nhật các ví dụ để minh họa quy tắc đó).

 

Những “Cạm Bẫy” Thường Gặp Khi Ra Lệnh Cho AI (Và Cách Né Tránh)

Những lỗi này không phải là duy nhất của GPT-4.1, nhưng việc nhận biết chúng sẽ giúp bạn gỡ lỗi hiệu quả hơn:

  1. Hướng Dẫn “Luôn Luôn” và Hệ Lụy Không Mong Muốn:
    • Vấn đề: Việc chỉ thị cho mô hình luôn luôn tuân theo một hành vi cụ thể đôi khi có thể gây ra tác dụng phụ không lường trước. Ví dụ, nếu bạn nói “bạn PHẢI gọi một công cụ trước khi trả lời người dùng,” mô hình có thể tự “bịa” ra đầu vào cho công cụ đó hoặc gọi công cụ với các giá trị rỗng (null) nếu nó không có đủ thông tin cần thiết.
    • Giải pháp: Thêm vào các điều kiện xử lý linh hoạt hơn. Ví dụ: “Nếu bạn không có đủ thông tin để gọi công cụ một cách chính xác, hãy yêu cầu người dùng cung cấp thêm thông tin bạn cần.”
  2. Sự Lặp Lại “Vẹt” Các Cụm Từ Mẫu:
    • Vấn đề: Khi được cung cấp các cụm từ mẫu (sample phrases), mô hình có thể sử dụng lại chúng một cách nguyên văn, khiến cho các phản hồi trở nên lặp đi lặp lại và thiếu tự nhiên đối với người dùng.
    • Giải pháp: Hãy chỉ thị rõ ràng cho mô hình rằng nó nên thay đổi (vary) các cụm từ mẫu đó khi cần thiết để phù hợp với ngữ cảnh và tránh sự nhàm chán.
  3. Nói Dài, Nói Dai, Nói Dở (Khi Không Được Yêu Cầu):
    • Vấn đề: Nếu không có hướng dẫn cụ thể, một số mô hình (bao gồm cả GPT-4.1 đôi khi) có thể tỏ ra “nhiệt tình” quá mức bằng cách cung cấp thêm nhiều giải thích dài dòng cho quyết định của chúng, hoặc sử dụng nhiều định dạng trong phản hồi hơn mức bạn mong muốn.
    • Giải pháp: Cung cấp các hướng dẫn rõ ràng về độ dài mong muốn, mức độ chi tiết, và định dạng đầu ra. Có thể cần cung cấp thêm ví dụ để minh họa sự ngắn gọn hoặc định dạng cụ thể mà bạn muốn.

Ví dụ: Chăm sóc khách hàng

Ví dụ prompt  về việc xây dựng một nhân viên dịch vụ khách hàng hư cấu, minh họa xuất sắc các phương pháp hay nhất: sự đa dạng của các quy tắc, tính cụ thể, việc sử dụng các mục bổ sung để làm rõ chi tiết, và tổng hợp thể hiện chính xác hành vi mong muốn dựa trên tất cả các quy tắc đã đặt ra.

SYS_PROMPT_CUSTOMER_SERVICE = """You are a helpful customer service agent working for NewTelco, helping a user efficiently fulfill their request while adhering closely to provided guidelines.

# Instructions
- Always greet the user with "Hi, you've reached NewTelco, how can I help you?"
- Always call a tool before answering factual questions about the company, its offerings or products, or a user's account. Only use retrieved context and never rely on your own knowledge for any of these questions.
- However, if you don't have enough information to properly call the tool, ask the user for the information you need.
- Escalate to a human if the user requests.
- Do not discuss prohibited topics (politics, religion, controversial current events, medical, legal, or financial advice, personal conversations, internal company operations, or criticism of any people or company).
- Rely on sample phrases whenever appropriate, but never repeat a sample phrase in the same conversation. Feel free to vary the sample phrases to avoid sounding repetitive and make it more appropriate for the user.
- Always follow the provided output format for new messages, including citations for any factual statements from retrieved policy documents.
- If you're going to call a tool, always message the user with an appropriate message before and after calling the tool.
- Maintain a professional and concise tone in all responses, and use emojis between sentences.
- If you've resolved the user's request, ask if there's anything else you can help with

# Precise Response Steps (for each response)
1. If necessary, call tools to fulfill the user's desired action. Always message the user before and after calling a tool to keep them in the loop.
2. In your response to the user
a. Use active listening and echo back what you heard the user ask for.
b. Respond appropriately given the above guidelines.

# Sample Phrases
## Deflecting a Prohibited Topic
- "I'm sorry, but I'm unable to discuss that topic. Is there something else I can help you with?"
- "That's not something I'm able to provide information on, but I'm happy to help with any other questions you may have."

## Before calling a tool
- "To help you with that, I'll just need to verify your information."
- "Let me check that for you—one moment, please."
- "I'll retrieve the latest details for you now."

## After calling a tool
- "Okay, here's what I found: [response]"
- "So here's what I found: [response]"

# Output Format
- Always include your final response to the user.
- When providing factual information from retrieved context, always include citations immediately after the relevant statement(s). Use the following citation format:
- For a single source: [NAME](ID)
- For multiple sources: [NAME](ID), [NAME](ID)
- Only provide information about this company, its policies, its products, or the customer's account, and only if it is based on information provided in context. Do not answer questions outside this scope.

# Example
## User
Can you tell me about your family plan options?

## Assistant Response 1
### Message
"Hi, you've reached NewTelco, how can I help you? 😊🎉\n\nYou'd like to know about our family plan options. 🤝 Let me check that for you—one moment, please. 🚀"

### Tool Calls
lookup_policy_document(topic="family plan options")

// After tool call, the assistant would follow up with:

## Assistant Response 2 (after tool call)
### Message
"Okay, here's what I found: 🎉 Our family plan allows up to 5 lines with shared data and a 10% discount for each additional line [Family Plan Policy](ID-010). 📱 Is there anything else I can help you with today? 😊"
"""

get_policy_doc = {
"type": "function",
"name": "lookup_policy_document",
"description": "Tool to look up internal documents and policies by topic or keyword.",
"parameters": {
"strict": True,
"type": "object",
"properties": {
"topic": {
"type": "string",
"description": "The topic or keyword to search for in company policies or documents.",
},
},
"required": ["topic"],
"additionalProperties": False,
},
}

get_user_acct = {
"type": "function",
"name": "get_user_account_info",
"description": "Tool to get user account information",
"parameters": {
"strict": True,
"type": "object",
"properties": {
"phone_number": {
"type": "string",
"description": "Formatted as '(xxx) xxx-xxxx'",
},
},
"required": ["phone_number"],
"additionalProperties": False,
},
}

response = client.responses.create(
instructions=SYS_PROMPT_CUSTOMER_SERVICE,
model="gpt-4.1-2025-04-14",
tools=[get_policy_doc, get_user_acct],
input="How much will it cost for international service? I'm traveling to France.",
# input="Why was my last bill so high?"
)

response.to_dict()["output"]

Lời Khuyên Vàng: Tối Ưu Hóa Prompt GPT-4.1 Toàn Diện

Sau khi đã nắm vững các kỹ thuật cụ thể, việc có một cấu trúc prompt tốt và biết cách sử dụng các yếu tố như dấu phân cách sẽ giúp bạn tối ưu hóa hơn nữa hiệu suất của GPT-4.1.

“Bộ Xương” Cho Một Prompt Hoàn Hảo: Cấu Trúc Đề Xuất

Dưới đây là một điểm khởi đầu tốt cho việc cấu trúc các prompt của bạn, được đề xuất bởi OpenAI. Hãy xem đây như một “khuôn mẫu” linh hoạt:

# Vai Trò và Mục Tiêu (Role and Objective)
# (Mô tả vai trò bạn muốn AI đảm nhận và mục tiêu tổng thể của prompt)

# Hướng Dẫn (Instructions)
# (Các quy tắc và chỉ dẫn chính)

## Các Tiểu Mục Cho Hướng Dẫn Chi Tiết Hơn (Sub-categories for more detailed instructions)
## (Ví dụ: # Giọng Điệu và Phong Cách, # Định Dạng Đầu Ra Cụ Thể)

# Các Bước Suy Luận (Reasoning Steps)
# (Nếu bạn muốn AI tuân theo một quy trình tư duy cụ thể - ví dụ: Chain of Thought)

# Định Dạng Đầu Ra (Output Format)
# (Mô tả rõ ràng định dạng bạn mong muốn cho kết quả trả về)

# Ví Dụ (Examples)
## Ví dụ 1 (Example 1)
### Đầu vào (Input):
### Đầu ra mong muốn (Desired Output):
## Ví dụ 2 (Example 2)
### ...

# Ngữ Cảnh (Context)
# (Dữ liệu, thông tin nền cần thiết cho AI)

# Hướng Dẫn Cuối Cùng và Yêu Cầu Suy Nghĩ Từng Bước (Final instructions and prompt to think step by step)
# (Có thể lặp lại một vài hướng dẫn quan trọng hoặc yêu cầu CoT ở đây)

 

Lời khuyên từ chuyên gia:

  • Linh hoạt là chìa khóa: Hãy thoải mái thêm hoặc bớt các mục cho phù hợp với nhu cầu cụ thể của bạn.
  • Thử nghiệm không ngừng: Thực nghiệm để xác định cấu trúc nào là tối ưu nhất cho trường hợp sử dụng (use case) của chính bạn.

Sức Mạnh Của Dấu Phân Cách (Delimiters): Giúp AI “Đọc Hiểu” Dễ Dàng Hơn

Dấu phân cách giúp mô hình phân biệt rõ ràng giữa các phần khác nhau của prompt (ví dụ: giữa hướng dẫn và ngữ cảnh, hoặc giữa các tài liệu khác nhau). Việc lựa chọn dấu phân cách hiệu quả là rất quan trọng. (Lưu ý: tham khảo lại phần “Ngữ Cảnh Dài” để biết các cân nhắc đặc biệt cho loại ngữ cảnh đó).

Markdown: Lựa Chọn Khởi Đầu An Toàn và Hiệu Quả

    • Khuyến nghị: OpenAI khuyên bạn nên bắt đầu với Markdown.
    • Cách dùng: Sử dụng các tiêu đề Markdown (#, ##, ###, ####+) cho các mục chính và mục con. Dùng dấu backtick nội tuyến (`code`) hoặc khối backtick () để bao bọc mã lệnh hoặc các đoạn văn bản cần nhấn mạnh một cách chính xác. Sử dụng danh sách được đánh số hoặc gạch đầu dòng tiêu chuẩn khi cần.

XML: Cấu Trúc Rõ Ràng, Linh Hoạt Cho Dữ Liệu Phức Tạp

    • Hiệu suất tốt: XML cũng cho thấy hiệu suất tốt, và GPT-4.1 đã được cải thiện khả năng tuân thủ thông tin trong các thẻ XML.
    • Ưu điểm: XML rất tiện lợi để bao bọc chính xác một mục (bao gồm cả thẻ mở và thẻ đóng), thêm siêu dữ liệu (metadata) vào các thẻ để cung cấp ngữ cảnh bổ sung, và cho phép cấu trúc lồng ghép (nesting).
    • Ví dụ sử dụng thẻ XML để lồng các ví dụ (Việt hóa):
<cac_vi_du>
<vi_du id="1" loai_tac_vu="VietTat">
<dau_vao>Thành phố Hồ Chí Minh</dau_vao>
<dau_ra_mong_muon>- TP.HCM</dau_ra_mong_muon>
</vi_du>
<vi_du id="2" loai_tac_vu="DichThuat">
<dau_vao>Hello world</dau_vao>
<dau_ra_mong_muon>Chào thế giới</dau_ra_mong_muon>
</vi_du>
</cac_vi_du>

JSON: Cấu Trúc Cao, Quen Thuộc Với Developer

    • Ưu điểm: JSON có cấu trúc rất cao và được mô hình hiểu rõ, đặc biệt trong các ngữ cảnh liên quan đến lập trình.
    • Nhược điểm: Nó có thể dài dòng hơn (verbose) và đòi hỏi việc thoát ký tự (character escaping) có thể gây thêm một chút phức tạp.

Hướng Dẫn Đặc Biệt Khi Thêm Số Lượng Lớn Tài Liệu/Tệp Vào Ngữ Cảnh Đầu Vào:

    • XML hoạt động tốt: Trong các thử nghiệm ngữ cảnh dài của OpenAI, XML cho thấy hiệu suất tốt.
      • Ví dụ: <tai_lieu id='doc1' tieu_de='Con Cáo Nâu Nhanh Nhẹn'>Nội dung về con cáo...</tai_lieu>
    • Định dạng của Lee và cộng sự cũng hiệu quả: Định dạng này (được đề xuất trong một nghiên cứu) cũng cho kết quả tốt.
      • Ví dụ: ID: doc1 | TIÊU ĐỀ: Con Cáo Nâu Nhanh Nhẹn | NỘI DUNG: Nội dung về con cáo...
    • JSON hoạt động đặc biệt kém: Đối với việc đưa vào một lượng lớn tài liệu, JSON không phải là lựa chọn tối ưu.
      • Ví dụ: [{'id': 'doc1', 'tieu_de': 'Con Cáo Nâu Nhanh Nhẹn', 'noi_dung': 'Nội dung về con cáo...'}]

Lời khuyên chung về dấu phân cách: Hãy sử dụng khả năng phán đoán của bạn và suy nghĩ xem điều gì sẽ cung cấp thông tin một cách rõ ràng nhất và “nổi bật” nhất đối với mô hình. Ví dụ, nếu bạn đang truy xuất các tài liệu mà bản thân chúng chứa rất nhiều thẻ XML, thì việc sử dụng một dấu phân cách cũng dựa trên XML có thể sẽ kém hiệu quả hơn (vì dễ gây nhầm lẫn).

Những Lưu Ý Quan Trọng (Caveats): Điểm Cần Cẩn Trọng Khi Làm Việc Với GPT-4.1

Mặc dù mạnh mẽ, GPT-4.1 cũng có một vài điểm bạn cần lưu ý:

  1. “Chống Cự” Với Đầu Ra Dài và Lặp Đi Lặp Lại:
    • Hiện tượng: Trong một số trường hợp cá biệt, OpenAI đã quan sát thấy mô hình có thể tỏ ra “chống cự” việc tạo ra các kết quả đầu ra rất dài và có tính lặp đi lặp lại cao (ví dụ: yêu cầu phân tích hàng trăm mục theo cùng một cách, từng mục một).
    • Giải pháp: Nếu điều này là bắt buộc cho trường hợp sử dụng của bạn, hãy hướng dẫn mô hình một cách mạnh mẽ để nó xuất đầy đủ thông tin đó. Đồng thời, cân nhắc việc chia nhỏ vấn đề thành các yêu cầu nhỏ hơn hoặc sử dụng một phương pháp tiếp cận ngắn gọn hơn.
  2. Hiếm Khi Gọi Công Cụ Song Song Không Chính Xác:
    • Hiện tượng: Đã có một vài trường hợp hiếm hoi các lệnh gọi công cụ song song (parallel tool calls) không được thực hiện một cách chính xác.
    • Lời khuyên: Hãy kiểm tra kỹ lưỡng tính năng này nếu bạn có ý định sử dụng. Nếu bạn gặp sự cố, hãy cân nhắc đặt tham số parallel_tool_calls thành false trong yêu cầu API của bạn.

BONUS: Chuyên Sâu Về Tạo và Áp Dụng File Diffs (Khác Biệt Tệp) với GPT-4.1

Đối với các nhà phát triển làm việc nhiều với mã nguồn, khả năng tạo ra các bản “khác biệt tệp” (diffs) một cách chính xác và có định dạng tốt là một năng lực cực kỳ quan trọng. Nó hỗ trợ các tác vụ như review code, tự động sửa lỗi, áp dụng bản vá, v.v.

Tin vui là dòng mô hình GPT-4.1 có khả năng tạo diff được cải thiện đáng kể so với các mô hình GPT trước đây.

APPLY_PATCH_TOOL_DESC = """This is a custom utility that makes it more convenient to add, remove, move, or edit code files. `apply_patch` effectively allows you to execute a diff/patch against a file, but the format of the diff specification is unique to this task, so pay careful attention to these instructions. To use the `apply_patch` command, you should pass a message of the following structure as "input":

%%bash
apply_patch <<"EOF"
*** Begin Patch
[YOUR_PATCH]
*** End Patch
EOF

Where [YOUR_PATCH] is the actual content of your patch, specified in the following V4A diff format.

*** [ACTION] File: [path/to/file] -> ACTION can be one of Add, Update, or Delete.
For each snippet of code that needs to be changed, repeat the following:
[context_before] -> See below for further instructions on context.
- [old_code] -> Precede the old code with a minus sign.
+ [new_code] -> Precede the new, replacement code with a plus sign.
[context_after] -> See below for further instructions on context.

For instructions on [context_before] and [context_after]:
- By default, show 3 lines of code immediately above and 3 lines immediately below each change. If a change is within 3 lines of a previous change, do NOT duplicate the first change’s [context_after] lines in the second change’s [context_before] lines.
- If 3 lines of context is insufficient to uniquely identify the snippet of code within the file, use the @@ operator to indicate the class or function to which the snippet belongs. For instance, we might have:
@@ class BaseClass
[3 lines of pre-context]
- [old_code]
+ [new_code]
[3 lines of post-context]

- If a code block is repeated so many times in a class or function such that even a single @@ statement and 3 lines of context cannot uniquely identify the snippet of code, you can use multiple `@@` statements to jump to the right context. For instance:

@@ class BaseClass
@@ def method():
[3 lines of pre-context]
- [old_code]
+ [new_code]
[3 lines of post-context]

Note, then, that we do not use line numbers in this diff format, as the context is enough to uniquely identify code. An example of a message that you might pass as "input" to this function, in order to apply a patch, is shown below.

%%bash
apply_patch <<"EOF"
*** Begin Patch
*** Update File: pygorithm/searching/binary_search.py
@@ class BaseClass
@@ def search():
- pass
+ raise NotImplementedError()

@@ class Subclass
@@ def search():
- pass
+ raise NotImplementedError()

*** End Patch
EOF
"""

APPLY_PATCH_TOOL = {
"name": "apply_patch",
"description": APPLY_PATCH_TOOL_DESC,
"parameters": {
"type": "object",
"properties": {
"input": {
"type": "string",
"description": " The apply_patch command that you wish to execute.",
}
},
"required": ["input"],
},
}

Định Dạng Diff Đề Xuất (Được OpenAI Huấn Luyện Sâu)

Mặc dù GPT-4.1 có thể tạo ra diff ở nhiều định dạng khác nhau nếu được cung cấp hướng dẫn và ví dụ rõ ràng, OpenAI đã công bố mã nguồn mở (open-source) một định dạng diff được khuyến nghị, mà trên đó mô hình đã được huấn luyện một cách sâu rộng. Điều này đặc biệt hữu ích cho các nhà phát triển mới bắt đầu, giúp giảm bớt phần lớn sự phỏng đoán khi tự mình tạo ra các yêu cầu diff.

#!/usr/bin/env python3

"""
A self-contained **pure-Python 3.9+** utility for applying human-readable
“pseudo-diff” patch files to a collection of text files.
"""

from __future__ import annotations

import pathlib
from dataclasses import dataclass, field
from enum import Enum
from typing import (
Callable,
Dict,
List,
Optional,
Tuple,
Union,
)


# --------------------------------------------------------------------------- #
# Domain objects
# --------------------------------------------------------------------------- #
class ActionType(str, Enum):
ADD = "add"
DELETE = "delete"
UPDATE = "update"


@dataclass
class FileChange:
type: ActionType
old_content: Optional[str] = None
new_content: Optional[str] = None
move_path: Optional[str] = None


@dataclass
class Commit:
changes: Dict[str, FileChange] = field(default_factory=dict)


# --------------------------------------------------------------------------- #
# Exceptions
# --------------------------------------------------------------------------- #
class DiffError(ValueError):
"""Any problem detected while parsing or applying a patch."""


# --------------------------------------------------------------------------- #
# Helper dataclasses used while parsing patches
# --------------------------------------------------------------------------- #
@dataclass
class Chunk:
orig_index: int = -1
del_lines: List[str] = field(default_factory=list)
ins_lines: List[str] = field(default_factory=list)


@dataclass
class PatchAction:
type: ActionType
new_file: Optional[str] = None
chunks: List[Chunk] = field(default_factory=list)
move_path: Optional[str] = None


@dataclass
class Patch:
actions: Dict[str, PatchAction] = field(default_factory=dict)


# --------------------------------------------------------------------------- #
# Patch text parser
# --------------------------------------------------------------------------- #
@dataclass
class Parser:
current_files: Dict[str, str]
lines: List[str]
index: int = 0
patch: Patch = field(default_factory=Patch)
fuzz: int = 0

# ------------- low-level helpers -------------------------------------- #
def _cur_line(self) -> str:
if self.index >= len(self.lines):
raise DiffError("Unexpected end of input while parsing patch")
return self.lines[self.index]

@staticmethod
def _norm(line: str) -> str:
"""Strip CR so comparisons work for both LF and CRLF input."""
return line.rstrip("\r")

# ------------- scanning convenience ----------------------------------- #
def is_done(self, prefixes: Optional[Tuple[str, ...]] = None) -> bool:
if self.index >= len(self.lines):
return True
if (
prefixes
and len(prefixes) > 0
and self._norm(self._cur_line()).startswith(prefixes)
):
return True
return False

def startswith(self, prefix: Union[str, Tuple[str, ...]]) -> bool:
return self._norm(self._cur_line()).startswith(prefix)

def read_str(self, prefix: str) -> str:
"""
Consume the current line if it starts with *prefix* and return the text
**after** the prefix. Raises if prefix is empty.
"""
if prefix == "":
raise ValueError("read_str() requires a non-empty prefix")
if self._norm(self._cur_line()).startswith(prefix):
text = self._cur_line()[len(prefix) :]
self.index += 1
return text
return ""

def read_line(self) -> str:
"""Return the current raw line and advance."""
line = self._cur_line()
self.index += 1
return line

# ------------- public entry point -------------------------------------- #
def parse(self) -> None:
while not self.is_done(("*** End Patch",)):
# ---------- UPDATE ---------- #
path = self.read_str("*** Update File: ")
if path:
if path in self.patch.actions:
raise DiffError(f"Duplicate update for file: {path}")
move_to = self.read_str("*** Move to: ")
if path not in self.current_files:
raise DiffError(f"Update File Error - missing file: {path}")
text = self.current_files[path]
action = self._parse_update_file(text)
action.move_path = move_to or None
self.patch.actions[path] = action
continue

# ---------- DELETE ---------- #
path = self.read_str("*** Delete File: ")
if path:
if path in self.patch.actions:
raise DiffError(f"Duplicate delete for file: {path}")
if path not in self.current_files:
raise DiffError(f"Delete File Error - missing file: {path}")
self.patch.actions[path] = PatchAction(type=ActionType.DELETE)
continue

# ---------- ADD ---------- #
path = self.read_str("*** Add File: ")
if path:
if path in self.patch.actions:
raise DiffError(f"Duplicate add for file: {path}")
if path in self.current_files:
raise DiffError(f"Add File Error - file already exists: {path}")
self.patch.actions[path] = self._parse_add_file()
continue

raise DiffError(f"Unknown line while parsing: {self._cur_line()}")

if not self.startswith("*** End Patch"):
raise DiffError("Missing *** End Patch sentinel")
self.index += 1 # consume sentinel

# ------------- section parsers ---------------------------------------- #
def _parse_update_file(self, text: str) -> PatchAction:
action = PatchAction(type=ActionType.UPDATE)
lines = text.split("\n")
index = 0
while not self.is_done(
(
"*** End Patch",
"*** Update File:",
"*** Delete File:",
"*** Add File:",
"*** End of File",
)
):
def_str = self.read_str("@@ ")
section_str = ""
if not def_str and self._norm(self._cur_line()) == "@@":
section_str = self.read_line()

if not (def_str or section_str or index == 0):
raise DiffError(f"Invalid line in update section:\n{self._cur_line()}")

if def_str.strip():
found = False
if def_str not in lines[:index]:
for i, s in enumerate(lines[index:], index):
if s == def_str:
index = i + 1
found = True
break
if not found and def_str.strip() not in [
s.strip() for s in lines[:index]
]:
for i, s in enumerate(lines[index:], index):
if s.strip() == def_str.strip():
index = i + 1
self.fuzz += 1
found = True
break

next_ctx, chunks, end_idx, eof = peek_next_section(self.lines, self.index)
new_index, fuzz = find_context(lines, next_ctx, index, eof)
if new_index == -1:
ctx_txt = "\n".join(next_ctx)
raise DiffError(
f"Invalid {'EOF ' if eof else ''}context at {index}:\n{ctx_txt}"
)
self.fuzz += fuzz
for ch in chunks:
ch.orig_index += new_index
action.chunks.append(ch)
index = new_index + len(next_ctx)
self.index = end_idx
return action

def _parse_add_file(self) -> PatchAction:
lines: List[str] = []
while not self.is_done(
("*** End Patch", "*** Update File:", "*** Delete File:", "*** Add File:")
):
s = self.read_line()
if not s.startswith("+"):
raise DiffError(f"Invalid Add File line (missing '+'): {s}")
lines.append(s[1:]) # strip leading '+'
return PatchAction(type=ActionType.ADD, new_file="\n".join(lines))


# --------------------------------------------------------------------------- #
# Helper functions
# --------------------------------------------------------------------------- #
def find_context_core(
lines: List[str], context: List[str], start: int
) -> Tuple[int, int]:
if not context:
return start, 0

for i in range(start, len(lines)):
if lines[i : i + len(context)] == context:
return i, 0
for i in range(start, len(lines)):
if [s.rstrip() for s in lines[i : i + len(context)]] == [
s.rstrip() for s in context
]:
return i, 1
for i in range(start, len(lines)):
if [s.strip() for s in lines[i : i + len(context)]] == [
s.strip() for s in context
]:
return i, 100
return -1, 0


def find_context(
lines: List[str], context: List[str], start: int, eof: bool
) -> Tuple[int, int]:
if eof:
new_index, fuzz = find_context_core(lines, context, len(lines) - len(context))
if new_index != -1:
return new_index, fuzz
new_index, fuzz = find_context_core(lines, context, start)
return new_index, fuzz + 10_000
return find_context_core(lines, context, start)


def peek_next_section(
lines: List[str], index: int
) -> Tuple[List[str], List[Chunk], int, bool]:
old: List[str] = []
del_lines: List[str] = []
ins_lines: List[str] = []
chunks: List[Chunk] = []
mode = "keep"
orig_index = index

while index < len(lines):
s = lines[index]
if s.startswith(
(
"@@",
"*** End Patch",
"*** Update File:",
"*** Delete File:",
"*** Add File:",
"*** End of File",
)
):
break
if s == "***":
break
if s.startswith("***"):
raise DiffError(f"Invalid Line: {s}")
index += 1

last_mode = mode
if s == "":
s = " "
if s[0] == "+":
mode = "add"
elif s[0] == "-":
mode = "delete"
elif s[0] == " ":
mode = "keep"
else:
raise DiffError(f"Invalid Line: {s}")
s = s[1:]

if mode == "keep" and last_mode != mode:
if ins_lines or del_lines:
chunks.append(
Chunk(
orig_index=len(old) - len(del_lines),
del_lines=del_lines,
ins_lines=ins_lines,
)
)
del_lines, ins_lines = [], []

if mode == "delete":
del_lines.append(s)
old.append(s)
elif mode == "add":
ins_lines.append(s)
elif mode == "keep":
old.append(s)

if ins_lines or del_lines:
chunks.append(
Chunk(
orig_index=len(old) - len(del_lines),
del_lines=del_lines,
ins_lines=ins_lines,
)
)

if index < len(lines) and lines[index] == "*** End of File":
index += 1
return old, chunks, index, True

if index == orig_index:
raise DiffError("Nothing in this section")
return old, chunks, index, False


# --------------------------------------------------------------------------- #
# Patch → Commit and Commit application
# --------------------------------------------------------------------------- #
def _get_updated_file(text: str, action: PatchAction, path: str) -> str:
if action.type is not ActionType.UPDATE:
raise DiffError("_get_updated_file called with non-update action")
orig_lines = text.split("\n")
dest_lines: List[str] = []
orig_index = 0

for chunk in action.chunks:
if chunk.orig_index > len(orig_lines):
raise DiffError(
f"{path}: chunk.orig_index {chunk.orig_index} exceeds file length"
)
if orig_index > chunk.orig_index:
raise DiffError(
f"{path}: overlapping chunks at {orig_index} > {chunk.orig_index}"
)

dest_lines.extend(orig_lines[orig_index : chunk.orig_index])
orig_index = chunk.orig_index

dest_lines.extend(chunk.ins_lines)
orig_index += len(chunk.del_lines)

dest_lines.extend(orig_lines[orig_index:])
return "\n".join(dest_lines)


def patch_to_commit(patch: Patch, orig: Dict[str, str]) -> Commit:
commit = Commit()
for path, action in patch.actions.items():
if action.type is ActionType.DELETE:
commit.changes[path] = FileChange(
type=ActionType.DELETE, old_content=orig[path]
)
elif action.type is ActionType.ADD:
if action.new_file is None:
raise DiffError("ADD action without file content")
commit.changes[path] = FileChange(
type=ActionType.ADD, new_content=action.new_file
)
elif action.type is ActionType.UPDATE:
new_content = _get_updated_file(orig[path], action, path)
commit.changes[path] = FileChange(
type=ActionType.UPDATE,
old_content=orig[path],
new_content=new_content,
move_path=action.move_path,
)
return commit


# --------------------------------------------------------------------------- #
# User-facing helpers
# --------------------------------------------------------------------------- #
def text_to_patch(text: str, orig: Dict[str, str]) -> Tuple[Patch, int]:
lines = text.splitlines() # preserves blank lines, no strip()
if (
len(lines) < 2
or not Parser._norm(lines[0]).startswith("*** Begin Patch")
or Parser._norm(lines[-1]) != "*** End Patch"
):
raise DiffError("Invalid patch text - missing sentinels")

parser = Parser(current_files=orig, lines=lines, index=1)
parser.parse()
return parser.patch, parser.fuzz


def identify_files_needed(text: str) -> List[str]:
lines = text.splitlines()
return [
line[len("*** Update File: ") :]
for line in lines
if line.startswith("*** Update File: ")
] + [
line[len("*** Delete File: ") :]
for line in lines
if line.startswith("*** Delete File: ")
]


def identify_files_added(text: str) -> List[str]:
lines = text.splitlines()
return [
line[len("*** Add File: ") :]
for line in lines
if line.startswith("*** Add File: ")
]


# --------------------------------------------------------------------------- #
# File-system helpers
# --------------------------------------------------------------------------- #
def load_files(paths: List[str], open_fn: Callable[[str], str]) -> Dict[str, str]:
return {path: open_fn(path) for path in paths}


def apply_commit(
commit: Commit,
write_fn: Callable[[str, str], None],
remove_fn: Callable[[str], None],
) -> None:
for path, change in commit.changes.items():
if change.type is ActionType.DELETE:
remove_fn(path)
elif change.type is ActionType.ADD:
if change.new_content is None:
raise DiffError(f"ADD change for {path} has no content")
write_fn(path, change.new_content)
elif change.type is ActionType.UPDATE:
if change.new_content is None:
raise DiffError(f"UPDATE change for {path} has no new content")
target = change.move_path or path
write_fn(target, change.new_content)
if change.move_path:
remove_fn(path)


def process_patch(
text: str,
open_fn: Callable[[str], str],
write_fn: Callable[[str, str], None],
remove_fn: Callable[[str], None],
) -> str:
if not text.startswith("*** Begin Patch"):
raise DiffError("Patch text must start with *** Begin Patch")
paths = identify_files_needed(text)
orig = load_files(paths, open_fn)
patch, _fuzz = text_to_patch(text, orig)
commit = patch_to_commit(patch, orig)
apply_commit(commit, write_fn, remove_fn)
return "Done!"


# --------------------------------------------------------------------------- #
# Default FS helpers
# --------------------------------------------------------------------------- #
def open_file(path: str) -> str:
with open(path, "rt", encoding="utf-8") as fh:
return fh.read()


def write_file(path: str, content: str) -> None:
target = pathlib.Path(path)
target.parent.mkdir(parents=True, exist_ok=True)
with target.open("wt", encoding="utf-8") as fh:
fh.write(content)


def remove_file(path: str) -> None:
pathlib.Path(path).unlink(missing_ok=True)


# --------------------------------------------------------------------------- #
# CLI entry-point
# --------------------------------------------------------------------------- #
def main() -> None:
import sys

patch_text = sys.stdin.read()
if not patch_text:
print("Please pass patch text through stdin", file=sys.stderr)
return
try:
result = process_patch(patch_text, open_file, write_file, remove_file)
except DiffError as exc:
print(exc, file=sys.stderr)
return
print(result)


if __name__ == "__main__":
main()

Các Định Dạng Diff Hiệu Quả Khác Cũng Hoạt Động Tốt

Nếu bạn muốn thử nghiệm các định dạng diff khác, OpenAI cho biết trong quá trình thử nghiệm của họ, định dạng diff TÌM KIẾM/THAY THẾ (SEARCH/REPLACE) (được sử dụng trong benchmark đa ngôn ngữ của Aider) cũng như một định dạng ** 유사 XML (pseudo-XML)** không có ký tự thoát nội bộ, đều cho tỷ lệ thành công cao.

Những định dạng diff hiệu quả này có chung hai khía cạnh quan trọng:

  1. Không sử dụng số dòng (line numbers).
  2. Cung cấp cả mã chính xác cần được thay thế VÀ mã chính xác để thay thế nó, với các dấu phân cách rõ ràng giữa hai phần này.

Dưới đây là ví dụ minh họa từ OpenAI:

  • Ví dụ định dạng TÌM KIẾM/THAY THẾ:
SEARCH_REPLACE_DIFF_EXAMPLE = """
path/to/file.py
```
>>>>>>> SEARCH
def search():
pass
=======
def search():
raise NotImplementedError()
<<<<<<< REPLACE
"""

PSEUDO_XML_DIFF_EXAMPLE = """
<edit>
<file>
path/to/file.py
</file>
<old_code>
def search():
pass
</old_code>
<new_code>
def search():
raise NotImplementedError()
</new_code>
</edit>
"""

 

Kết Luận: Khai Phóng Tiềm Năng Vô Hạn Của GPT-4.1 Qua Nghệ Thuật Prompting

Chúng ta đã cùng nhau đi qua một hành trình chi tiết, khám phá những bí mật và kỹ thuật để làm chủ GPT-4.1 – một trong những mô hình ngôn ngữ tiên tiến nhất hiện nay. Từ việc hiểu rõ bản chất “thích tuân lệnh theo nghĩa đen” của nó, xây dựng các tác tử AI tự chủ, xử lý những ngữ cảnh văn bản khổng lồ, kích hoạt chuỗi suy nghĩ sâu sắc, cho đến việc tinh chỉnh từng chi tiết trong hướng dẫn – rõ ràng, sức mạnh của GPT-4.1 là vô cùng to lớn.

Tuy nhiên, chìa khóa để khai phóng toàn bộ tiềm năng đó nằm ở chính đôi tay và khối óc của bạn – thông qua nghệ thuật prompt engineering. Một prompt được xây dựng tốt không chỉ là một câu lệnh, mà là một cuộc đối thoại thông minh, một sự hợp tác giữa con người và máy móc để đạt được những kết quả phi thường.

Hãy nhớ rằng, prompt engineering là một quá trình thực nghiệm và lặp lại không ngừng. Đừng ngại thử nghiệm, đừng sợ thất bại, và hãy luôn tìm cách cải thiện. Những hướng dẫn trong bài viết này là nền tảng vững chắc, nhưng chính sự sáng tạo và kiên trì của bạn mới là yếu tố quyết định.

Thế giới AI đang phát triển với tốc độ chóng mặt, và GPT-4.1 là một minh chứng cho điều đó. Hãy nắm bắt những kiến thức này, áp dụng chúng vào các dự án của bạn, và cùng nhau tạo nên những đột phá mới. Tương lai của AI đang chờ bạn kiến tạo!

Cảm ơn bạn đã theo dõi bài viết này. Chúc bạn thành công trên hành trình chinh phục GPT-4.1!

 

 

5/5 (100 bình chọn)

Xem thêm:

  1. Khuyến mãi 7/7/2022 Tiki
  2. Hướng dẫn người mới Tối ưu hóa cho công cụ tìm kiếm (SEO)
  3. Tổng hợp hơn 450 mẫu câu hỏi để bào ChatGPT OpenAI tối đa
  4. KuTools Excel công cụ thần thánh không thể thiếu với Office văn phòng
Chia sẻ bài này
ByPhạm Xuân Hiếu
Follow:
Chuyên gia tư vấn và thực hiện các chiến dịch digital marketing, SEO, truyền thông trực tuyến đa kênh với nhiều khách hàng nhiều lĩnh vực, bao gồm cả các Tổ chức, Hiệp hội, Công ty, Doanh nghiệp đến cá nhân kinh doanh.
Previous Article Làm chủ KLING AI 1.6 với tài liệu 4000 dòng và Master Video Prompt Creation GPT
Không có bình luận

Thời tiết hôm nay

Danh mục

Có thể bạn quan tâm