- Đây là hướng dẫn về prompt engineering do Anthropic cung cấp, tương tác theo từng bước để chỉ cách viết prompt tối ưu cho mô hình Claude
- Người dùng có thể trực tiếp luyện tập và nắm vững cấu trúc của một prompt tốt, các trường hợp thất bại, cùng những kỹ thuật cải thiện hiệu quả
- Mỗi chương đều bao gồm ví dụ thực hành và phần giải thích, mang lại trải nghiệm gần với thực tế
- Gồm 9 chương từ cơ bản đến nâng cao cùng phụ lục, giúp rèn luyện khả năng tự viết prompt và giải quyết vấn đề
- Hướng dẫn này cũng cung cấp thêm phiên bản Google Sheets để tăng khả năng tiếp cận và mức độ hữu dụng
Hướng dẫn tương tác về prompt engineering của Anthropic
- Tài liệu học tập mã nguồn mở cung cấp kiến thức thiết kế prompt tối ưu cho mô hình AI Claude
- Dù có luồng học tương tự các chatbot dựa trên OpenAI, tài liệu này nổi bật về khả năng ứng dụng thực tế và tính thực dụng hơn các hướng dẫn khác nhờ tập trung vào việc nhận biết điểm mạnh, điểm hạn chế của mô hình Claude và thực hành thực chiến
- Đặc biệt, người học có thể vừa viết prompt vừa thử nghiệm kết quả thực tế, mang lại lợi thế lớn cho các kỹ sư mới bắt đầu
Giới thiệu khóa học và mục tiêu
- Hướng dẫn này chỉ dẫn theo từng bước cách thiết kế và sử dụng prompt tối ưu trong Claude
- Sau khi hoàn thành khóa học, người dùng có thể nắm được các nội dung sau
- Hiểu cấu trúc prompt hiệu quả
- Nhận diện các mẫu thất bại điển hình và cách cải thiện ưu tiên trước (quy tắc 80/20)
- Nắm được điểm mạnh và điểm yếu của mô hình Claude
- Xây dựng năng lực tạo prompt để áp dụng vào nhiều công việc phổ biến
Cấu trúc khóa học và nội dung
- Gồm 9 chương (từ cơ bản đến nâng cao) và phụ lục chuyên sâu
- Mỗi chương đều cung cấp cả phần lý thuyết và thực hành trực tiếp
- Cuối mỗi phần có không gian trong "Example Playground" để trực tiếp nhập prompt và thử nghiệm sự thay đổi trong phản hồi
- Mọi ví dụ đều kèm theo đáp án giải thích
- Mô hình mặc định của hướng dẫn là Claude 3 Haiku, dòng nhẹ nhất, nhanh nhất và rẻ nhất. Khi cần cũng có đề cập đến Sonnet và Opus với mức độ thông minh cao hơn
- Có thể sử dụng cả dưới dạng phiên bản mở rộng trên Google Sheets nên khả năng tiếp cận rất cao
Mục lục chương trình học
- Cơ bản
- Chương 1: Cấu trúc prompt cơ bản
- Chương 2: Cách viết chỉ dẫn rõ ràng và trực tiếp
- Chương 3: Gán vai trò
- Trung cấp
- Chương 4: Tách dữ liệu và chỉ dẫn
- Chương 5: Chỉ định định dạng đầu ra và hội thoại hóa cho Claude
- Chương 6: Tư duy trước (gợi ra suy nghĩ theo từng bước)
- Chương 7: Cách sử dụng ví dụ
- Nâng cao
- Chương 8: Ngăn hallucination
- Chương 9: Xây dựng prompt phức tạp (các trường hợp theo ngành)
- Ví dụ: chatbot, dịch vụ pháp lý, dịch vụ tài chính, lập trình và nhiều bài toán ứng dụng thực tế theo từng nghiệp vụ khác nhau
- Phụ lục
- Các phương pháp vượt ra ngoài prompt tiêu chuẩn
- Các kỹ thuật nâng cao như prompt chaining, sử dụng công cụ, tìm kiếm/tích hợp kết quả tìm kiếm
Hướng dẫn sử dụng
- Khuyến nghị nên học theo thứ tự từng chương một
- Nhờ phần luyện tập bám sát thực tế và phần giải thích theo từng bước, ngay cả kỹ sư mới bắt đầu cũng có thể tự nhiên rèn được năng lực thiết kế prompt có thể dùng trong công việc thật
- Tất cả tên sản phẩm và tên mô hình đều được giữ nguyên như bản gốc, nên có thể dùng ngay cả trong môi trường làm việc dùng tiếng Anh
Đặc điểm bổ sung và thông tin mã nguồn mở
- Trên Github hiện đã ghi nhận hơn 19.400 Stars và 1.900 Fork
- Ngôn ngữ phát triển chính là Jupyter Notebook, đồng thời cũng bao gồm một phần mã Python
- Không có gói phân phối riêng; toàn bộ tài liệu đều là mã nguồn mở và có thể tự do tham khảo
1 bình luận
Ý kiến trên Hacker News
Tôi rất khó chịu khi từ "engineering" được dùng trong ngữ cảnh này, tôi không nghĩ có thể xem đó là engineering thực sự; engineering là công việc thiết kế và tạo ra thứ gì đó một cách có thể dự đoán được dựa trên tri thức tích lũy qua thời gian dài, các định luật vật lý và quy tắc, còn thứ đang làm bây giờ chẳng qua chỉ là thử bừa cho đến khi ra kết quả
Tôi nghĩ từ nào cũng có nhiều nghĩa, "engineering" trong "prompt engineering" có sắc thái tương tự nhưng khác với trong "social engineering"; ví dụ định nghĩa số 2 của Google về engineering là "hành động dùng mưu mẹo để đạt mục đích", và nếu xem định nghĩa thứ 3 của Merriam-Webster hay collins dictionary, yourdictionary thì cũng thấy rõ tồn tại nghĩa phi kỹ thuật như “thao túng khéo léo, lập kế hoạch”, đây là một nghĩa thứ cấp đã được xác lập của từ này
Tôi ăn ngũ cốc và xem xét thông số trên hộp ngũ cốc, sáng nào cũng vậy, rồi còn áp dụng kỹ năng engineering để lên xe buýt nữa, bởi vì tôi là người kiếm sống bằng prompt engineering; thật may vì hóa ra không chỉ mình tôi thấy khó chịu khi quá nhiều từ ngữ ngày nay đang mất đi nghĩa gốc của chúng
Tôi vẫn thích cách tiếp cận của Canada, tức là muốn dùng danh xưng engineer thì phải được cấp phép bởi cơ quan quản lý kỹ sư của từng bang; tôi thấy ở Mỹ việc gọi mọi software developer, thợ máy, kỹ thuật viên lắp đặt HVAC, thợ ống nước... là engineer là hơi quá
Tôi nghĩ tranh cãi này thực ra cũng có thể áp dụng y hệt cho công việc của rất nhiều "engineering team"; có một tiền đề ngầm là nếu engineer làm việc đó thì bản thân việc đó sẽ thành engineering, và xa hơn nữa còn có giả định sâu hơn về việc bản thân software có thực sự xứng đáng được gọi là software engineering hay không
Tôi nghĩ từ "Engineering" là một dụng cụ tu từ để khiến mọi người thấy đây không chỉ đơn giản là viết câu; nói thật thì nếu gọi là "prompt writing" nghe có vẻ nhẹ cân hơn, nên với những người vốn đã không thích khái niệm "soft" skill thì sẽ càng khó chịu hơn
Cảm giác như tập "giả kim thuật cho người mới bắt đầu" ngày hôm nay vậy, làm tôi nhớ tới trường hợp tốc độ thuật toán tăng 30% khi đặt random seed là 7 trong benchmark set; không phải 8 hay 6 mà là 7
Khi đọc bài này, điều khiến tôi ngộ ra là nên nghĩ về cách sắp xếp thứ tự đầu ra, ví dụ yêu cầu mô hình trích xuất bằng chứng hoặc chỉ dấu trước khi trả lời; tôi biết LLM là kiểu tự động hoàn thành mang tính xác suất, nhưng trước giờ chưa từng nghĩ đến chuyện priming theo cách này
Cách này có thể không áp dụng cho reasoning model; reasoning model vốn sẽ đi qua tiến trình suy nghĩ theo cách mong muốn trước khi đưa ra đáp án, nên thứ tự đầu ra ít ảnh hưởng đến độ chính xác hơn, có lẽ đó là một phần lý do OpenAI muốn ép mô hình reasoning
Tôi thường yêu cầu trích ra trước những đoạn trích ngắn từ các nguồn tìm thấy online (nếu có liên quan); làm vậy giúp bù đắp phần nào độ tin cậy của thông tin, đây là cách rất cần thiết gần đây khi tổ chức của chúng tôi triển khai Cloudflare Zero Trust
Ngược lại, nếu bắt nó trả lời trước rồi mới đưa căn cứ, mô hình sẽ rơi vào "chế độ nói bừa" khi đưa ra một đáp án tùy tiện rồi hợp lý hóa nó nghe cho xuôi; tốt hơn là bắt nó liệt kê khách quan ưu và nhược điểm trước rồi mới kết luận, như vậy nó sẽ trả lời cẩn trọng hơn nhiều
Tôi nghĩ nên thêm "(2024)" vào tiêu đề của bài gửi này
Theo tôi, mẹo prompt engineering tốt nhất cho các bài toán khó là "mở rộng rồi thu hẹp"; nói cụ thể hơn, trước tiên hãy trình bày rõ vấn đề và bối cảnh, để AI phân tích và tìm mọi lựa chọn cũng như cách tiếp cận có thể nhằm mở rộng tối đa thông tin, sau đó liệt kê ưu và nhược điểm của từng cách, rồi chọn giải pháp phù hợp nhất; với bài toán dễ thì có thể bỏ qua hết và hỏi thẳng cũng ra đáp án, nhưng với bài toán khó mà hỏi đáp án ngay thì nó chỉ bịa ra cho hợp lý, nên nhất định phải bắt đầu từ căn cứ thực tế; vì vậy cần luồng đi từ bối cảnh cụ thể - phân tích lựa chọn - pros & cons - lựa chọn cuối cùng
Ý kiến là nên thêm 2024 vào tiêu đề
Tôi có cảm giác là chúng ta đang dạy AI những gì chính mình từng làm, rồi lại học cách ra lệnh hiệu quả để AI làm chính việc đó; nếu công nghệ này không được toàn bộ nền kinh tế Mỹ chống lưng thì có thể nó sẽ bay lên như khinh khí cầu nóng rồi rơi xuống rất nhanh
Giống như nhiều bình luận khác, tôi không thấy thứ này mang cảm giác engineering chính thống, nhưng tôi nghĩ Anthropic đã làm một số nghiên cứu khá hay về khả năng diễn giải mô hình; nếu công cụ đó được công bố dưới dạng public API thì có thể sẽ tạo ra một vòng phản hồi cho phép so sánh khác biệt trạng thái nội bộ của mô hình theo từng prompt và tinh chỉnh có hệ thống hơn
Tutorial này được viết cho ba mô hình (Sonnet, Haiku, Opus 3); vẫn có một số bài học còn áp dụng được đến hôm nay, nhưng cũng có những phần không còn quá quan trọng với các mô hình RL thông minh hơn như Sonnet 4.5; nói thêm thì Claude 3 Haiku là mô hình nhỏ nhất, nhanh nhất và rẻ nhất, còn Sonnet và Opus thông minh hơn, trong đó Opus là tốt nhất