บทเรียนเชิงโต้ตอบด้าน Prompt Engineering ของ Anthropic [2024]

• บทเรียนด้าน Prompt Engineering จาก Anthropic ที่แนะนำวิธีเขียนพรอมป์ตที่เหมาะกับโมเดล Claude แบบอินเทอร์แอ็กทีฟทีละขั้นตอน
• ผู้ใช้สามารถฝึกและซึมซับได้ด้วยตนเองทั้ง โครงสร้างของพรอมป์ตที่ดี และ กรณีตัวอย่างความล้มเหลว รวมถึงเทคนิคการปรับปรุงอย่างมีประสิทธิภาพ
• ในแต่ละบทมีทั้ง ตัวอย่างฝึกปฏิบัติและคำอธิบาย ช่วยมอบประสบการณ์ที่ใกล้เคียงการใช้งานจริง
• ประกอบด้วย 9 บท ตั้งแต่ระดับเริ่มต้นถึงขั้นสูงและภาคผนวก เพื่อพัฒนาความสามารถในการเขียนพรอมป์ตและแก้ปัญหาด้วยตนเอง
• บทเรียนนี้ยังมีเวอร์ชัน Google Sheets ให้ใช้งานร่วมกัน ช่วยเพิ่ม การเข้าถึงและความสะดวกในการนำไปใช้

---

บทเรียนเชิงโต้ตอบด้าน Prompt Engineering ของ Anthropic

• สื่อการเรียนรู้โอเพนซอร์สที่มอบความรู้ด้านการออกแบบพรอมป์ตซึ่งเหมาะกับโมเดล AI อย่าง Claude
• แม้จะมีโฟลว์การเรียนรู้คล้ายกับแชตบอตที่อิง OpenAI แต่ด้วยการจัดเนื้อหาที่เน้นจุดเด่นและข้อจำกัดของโมเดล Claude รวมถึงการฝึกใช้งานจริง ทำให้มีความเป็นประโยชน์และนำไปใช้กับงานจริงได้มากกว่าบทเรียนอื่น
• โดยเฉพาะอย่างยิ่ง ผู้เรียนสามารถเขียนพรอมป์ตและทดลองผลลัพธ์ไปพร้อมกันได้จริง จึงเป็นประโยชน์อย่างมากสำหรับวิศวกรมือใหม่

แนะนำคอร์สและเป้าหมาย

• บทเรียนนี้จะแนะนำวิธีออกแบบและใช้งานพรอมป์ตที่เหมาะสมที่สุดภายใน Claude แบบเป็นขั้นตอน
• เมื่อเรียนจบคอร์ส ผู้ใช้จะสามารถเรียนรู้สิ่งต่อไปนี้ได้
  • ความเข้าใจเกี่ยวกับ โครงสร้างพรอมป์ตที่มีประสิทธิภาพ
  • การรับรู้ รูปแบบความล้มเหลวที่พบบ่อย และวิธีปรับปรุงที่สำคัญก่อน (กฎ 80/20)
  • การเข้าใจ จุดแข็งและจุดอ่อน ของโมเดล Claude
  • ความสามารถในการสร้างพรอมป์ต เพื่อประยุกต์ใช้กับงานทั่วไปหลากหลายประเภท

โครงสร้างคอร์สและเนื้อหา

• ประกอบด้วย 9 บท (ระดับเริ่มต้น ~ ขั้นสูง) และภาคผนวกเชิงลึก
• แต่ละบทมีทั้ง คำอธิบายเชิงทฤษฎี และ การฝึกปฏิบัติจริง
• ตอนท้ายของแต่ละส่วนมีพื้นที่ใน "Example Playground" ให้ผู้ใช้ป้อนพรอมป์ตเองและ ทดลองการเปลี่ยนแปลงของคำตอบ ได้
• มี เฉลยคำอธิบาย รวมไว้สำหรับทุกตัวอย่าง
• โมเดลพื้นฐานของบทเรียนคือ Claude 3 Haiku ซึ่งมีขนาดเล็กที่สุด รวดเร็วที่สุด และมีต้นทุนต่ำที่สุด โดยหากจำเป็นก็มีการกล่าวถึง Sonnet และ Opus ซึ่งมีความสามารถด้านสติปัญญาสูงกว่า
• ยังสามารถใช้งานในรูปแบบเวอร์ชันขยายของ Google Sheets ได้ ทำให้เข้าถึงการเรียนรู้ได้ง่าย

สารบัญหลักสูตร

• ระดับเริ่มต้น
  • Chapter 1: โครงสร้างพรอมป์ตพื้นฐาน
  • Chapter 2: วิธีเขียนคำสั่งให้ชัดเจนและตรงไปตรงมา
  • Chapter 3: การกำหนดบทบาท
• ระดับกลาง
  • Chapter 4: การแยกข้อมูลออกจากคำสั่ง
  • Chapter 5: การกำหนดรูปแบบเอาต์พุตและทำให้ Claude สนทนาได้ดีขึ้น
  • Chapter 6: การคิดล่วงหน้า (การดึงความคิดแบบเป็นขั้นตอน)
  • Chapter 7: วิธีใช้ตัวอย่าง
• ระดับสูง
  • Chapter 8: การป้องกัน Hallucination
  • Chapter 9: การสร้างพรอมป์ตที่ซับซ้อน (กรณีศึกษาตามอุตสาหกรรม)
    • ตัวอย่าง: ครอบคลุมปัญหาการประยุกต์ใช้จริงในงานหลากหลาย เช่น แชตบอต บริการด้านกฎหมาย บริการทางการเงิน การเขียนโค้ด ฯลฯ
• ภาคผนวก
  • วิธีการที่ก้าวไปไกลกว่าพรอมป์ตมาตรฐาน
    • เทคนิคขั้นสูง เช่น prompt chaining, การใช้เครื่องมือ, การค้นหา/การผสานผลการค้นหา เป็นต้น

แนวทางการใช้งาน

• แนะนำให้เรียนบทเรียนเรียงตามลำดับของแต่ละบท
• ด้วยการฝึกที่เน้นการใช้งานจริงและคำอธิบายแบบเป็นขั้นตอน แม้แต่ วิศวกรมือใหม่ ก็สามารถค่อย ๆ พัฒนาทักษะการออกแบบพรอมป์ตที่ นำไปใช้ได้จริง อย่างเป็นธรรมชาติ
• ชื่อผลิตภัณฑ์และชื่อโมเดลทั้งหมดเขียนตามต้นฉบับ จึงสามารถนำไปใช้ต่อได้ทันทีแม้อยู่ใน สภาพแวดล้อมการทำงานที่ใช้ภาษาอังกฤษเป็นหลัก

คุณลักษณะเพิ่มเติมและข้อมูลโอเพนซอร์ส

• บน Github มี Stars มากกว่า 19,400 รายการ และ 1,900 Fork
• ภาษาในการพัฒนาหลักคือ Jupyter Notebook และมีโค้ด Python บางส่วนรวมอยู่ด้วย
• ไม่มีแพ็กเกจสำหรับแจกจ่ายแยกต่างหาก และสื่อทั้งหมดสามารถอ้างอิงได้อย่างอิสระในฐานะโอเพนซอร์ส

[GN⁺]

ความคิดเห็นจาก Hacker News

• รู้สึกรำคาญมากที่คำว่า "engineering" ถูกใช้ในบริบทแบบนี้ คิดว่าไม่นับเป็น engineering จริง ๆ เพราะ engineering คือการออกแบบและสร้างสิ่งต่าง ๆ อย่างคาดการณ์ได้บนพื้นฐานของความรู้ที่สั่งสมมายาวนาน กฎฟิสิกส์ และกฎเกณฑ์ต่าง ๆ แต่สิ่งที่ทำกันอยู่ตอนนี้ก็แค่ลองมั่วไปเรื่อย ๆ จนกว่าจะได้ผลลัพธ์

  • ผมคิดว่าคำคำหนึ่งมีได้หลายความหมาย คำว่า "engineering" ใน "prompt engineering" มีนัยคล้ายกับใน "social engineering" คือคล้ายแต่ไม่เหมือนกัน ตัวอย่างเช่น นิยามของ engineering จาก Google ข้อ 2 คือ 'การใช้กลอุบายเพื่อให้บรรลุเป้าหมาย' และถ้าไปดูความหมายข้อ 3 ในพจนานุกรม Merriam-Webster หรือ collins dictionary, yourdictionary ก็จะเห็นชัดว่ามีความหมายที่ไม่เชิงเทคนิคอย่าง “การจัดการอย่างแยบยล, การวางแผน” อยู่จริง เป็นความหมายรองที่มีใช้กันมานานแล้ว

  • ผมกินซีเรียลไปพร้อมกับตรวจสเปกบนกล่องซีเรียล ทำแบบนั้นทุกเช้า แล้วก็ใช้สกิล engineering ในการขึ้นรถบัสด้วย เพราะผมหาเลี้ยงชีพด้วย prompt engineering ทุกวันนี้รู้สึกว่าคำจำนวนมากกำลังสูญเสียความหมายดั้งเดิมไป ดีหน่อยที่ไม่ได้มีผมหงุดหงิดอยู่คนเดียว

  • ผมยังชอบแนวทางของแคนาดาอยู่ดี คือระบบที่การจะใช้ตำแหน่ง engineer ได้ต้องได้รับใบอนุญาตจากหน่วยงานกำกับวิชาชีพของแต่ละรัฐ รู้สึกว่าสหรัฐฯ ใช้คำว่า engineer กับทุกคนมากเกินไป ตั้งแต่นักพัฒนาซอฟต์แวร์ ช่างซ่อม ช่างติดตั้ง HVAC ไปจนถึงช่างประปา

  • 1. software engineer แทบไม่มีความรู้เชิงกายภาพลึก ๆ เกี่ยวกับระบบคอมพิวเตอร์เลย และงานจริงก็เกี่ยวกับปรัชญามากกว่าวิทยาศาสตร์เชิงประจักษ์ รวมถึงเกี่ยวกับคณิตศาสตร์อยู่บ้าง 2) ดูเหมือนคุณจะไม่ค่อยรู้ทันแนวโน้มการพัฒนา AI เท่าไร เพราะตอนนี้มีทั้งคำศัพท์เฉพาะ แหล่งอ้างอิง และเอกสารสำหรับงาน prompt แล้ว คล้ายกับวิชา computer science เลย สาขานี้เป็นพื้นที่อิสระที่ไม่มีที่ไหนสอนในมหาวิทยาลัย และแนวโน้มตอนนี้คือไม่มีประสบการณ์ทำงานจริงก็ไม่รับเข้าทำงาน

  • ผมคิดว่าข้อถกเถียงแบบนี้จริง ๆ แล้วเอาไปใช้กับงานที่หลาย ๆ "engineering team" ทำอยู่ได้เหมือนกัน คือมีสมมติฐานแฝงว่าถ้า engineer เป็นคนทำ สิ่งนั้นก็ย่อมเป็น engineering และยิ่งไปกว่านั้นยังมีสมมติฐานลึก ๆ ด้วยว่าซอฟต์แวร์เองมีคุณค่าพอจะเรียกว่า software engineering หรือไม่

• ผมคิดว่าคำว่า "Engineering" เป็นอุปกรณ์เชิงวาทศิลป์ที่ทำให้คนรู้สึกว่านี่ไม่ใช่แค่การเขียนประโยคเฉย ๆ พูดตรง ๆ ถ้าเรียกมันว่า "prompt writing" มันอาจฟังดูเบาเกินไป และคงยิ่งทำให้คนที่ไม่ชอบคำว่า "soft" skill รู้สึกขัดหูมากขึ้น

• ให้ความรู้สึกเหมือนตอนของ "การเล่นแร่แปรธาตุสำหรับมือใหม่" ประจำวันนี้เลย ทำให้นึกถึงกรณีที่ความเร็วของอัลกอริทึมเพิ่มขึ้น 30% เมื่อใส่ค่า random seed เป็น 7 ใน benchmark set ไม่ใช่ 8 หรือ 6 แต่เป็น 7

  • คุณอาจไม่ชอบที่ทุกอย่างมันไม่ deterministic และซับซ้อนขึ้นแบบนี้ แต่ตอนนี้นี่คืองานของเรา ถ้าผมไม่ทำ สุดท้ายก็ต้องมีใครสักคนทำอยู่ดี ในโปรเจกต์ AI application ผมแยก prompt engineering ออกจาก engineering จริง ตั้งค่าเครื่องมือที่จำเป็นทั้งหมดให้พร้อม เช่น การทำ componentization, version control, evaluation tools เพื่อให้ทำ prompt engineering อย่างเป็นระบบที่สุด แล้วค่อยส่งต่อให้ผู้เชี่ยวชาญโดเมน ถ้าคุณคิดว่า prompt engineering เป็นแค่ระดับเลือก seed ก็ผมมองว่าไม่ควรเขียน prompt เลย

• สิ่งสำคัญที่ผมได้จากการอ่านบทความนี้คือทำให้คิดเรื่องลำดับของ output เช่น ให้โมเดลดึง evidence หรือ indicator ออกมาก่อนที่จะตอบ ผมรู้อยู่แล้วว่า LLM เป็น autocomplete แบบความน่าจะเป็น แต่ไม่เคยคิดเรื่องการ priming แบบนี้มาก่อน

  • วิธีนี้อาจใช้ไม่ได้กับ reasoning model เพราะ reasoning model จะคิดตามกระบวนการที่ต้องการก่อนจะให้คำตอบอยู่แล้ว ดังนั้นลำดับของ output จึงมีผลต่อความแม่นยำน้อยกว่า นี่อาจเป็นเหตุผลที่ OpenAI พยายามบังคับให้เกิด reasoning ก็ได้

  • ปกติผมมักขอให้ดึง quote สั้น ๆ จากแหล่งข้อมูลที่หาได้ออนไลน์ก่อน (ถ้าเกี่ยวข้อง) วิธีนี้ช่วยเสริมความน่าเชื่อถือของข้อมูลได้ระดับหนึ่ง ช่วงหลังมันจำเป็นมากตอนที่องค์กรของเรากำลังติดตั้ง Cloudflare Zero Trust

  • ในทางกลับกัน ถ้าขอให้ตอบก่อนแล้วค่อยยกเหตุผล โมเดลจะเข้าสู่ "โหมดพูดมั่ว" คือให้คำตอบตามใจแล้วค่อยหาเหตุผลมารองรับให้ดูน่าเชื่อถือ สู้ให้มันดึงข้อดีข้อเสียแบบเป็นกลางก่อน แล้วค่อยสรุปจะได้คำตอบที่รอบคอบกว่ามาก

• ผมคิดว่าควรใส่ "(2024)" ในชื่อโพสต์นี้

• สำหรับปัญหายาก ๆ เคล็ดลับ prompt engineering ที่ดีที่สุดในมุมมองผมคือ "ขยายแล้วค่อยบีบ" อธิบายให้ชัดคือ เริ่มจากระบุปัญหาและบริบทให้ชัดเจนก่อน จากนั้นให้ AI วิเคราะห์และค้นหาทุกตัวเลือกกับทุกแนวทางที่เป็นไปได้ เพื่อกางข้อมูลออกให้กว้างที่สุด แล้วค่อยให้มันลิสต์ข้อดีข้อเสียของแต่ละวิธีและเลือกทางแก้ที่เหมาะสมที่สุด ถ้าเป็นปัญหาง่าย ๆ ข้ามขั้นตอนทั้งหมดนี้แล้วถามตรง ๆ ก็ได้คำตอบ แต่ถ้าเป็นปัญหายากแล้วถามหาคำตอบทันที มันจะมั่วคำตอบที่ฟังดูน่าเชื่อถือออกมา ดังนั้นต้องเริ่มจากฐานที่ยึดกับความเป็นจริงเสมอ จึงต้องมีลำดับแบบ บริบทที่เฉพาะเจาะจง - วิเคราะห์ตัวเลือก - pros & cons - เลือกคำตอบสุดท้าย

  • วิธีนี้ดูเหมือนจะใช้ได้กับการแก้ปัญหาอื่น ๆ นอกเหนือจากปัญหา AI ด้วย

• ความเห็นว่าให้เพิ่ม 2024 ไว้ในชื่อเรื่อง

• ผมรู้สึกว่าเรากำลังเรียนรู้ที่จะสอน AI ในงานที่เราเคยทำเอง และจากนั้นก็เรียนรู้วิธีสั่งให้ AI ทำงานนั้นอย่างมีประสิทธิภาพ ถ้าเทคโนโลยีนี้ไม่ได้มีเศรษฐกิจสหรัฐฯ ทั้งระบบค้ำอยู่ มันก็อาจพองตัวขึ้นเหมือนบอลลูนลมร้อนแล้วทรุดฮวบลงมาได้

• คล้ายกับคอมเมนต์อื่น ๆ คือผมก็รู้สึกว่านี่ไม่ค่อยเหมือน engineering แบบดั้งเดิม แต่ผมคิดว่า Anthropic ทำงานวิจัยด้าน model interpretability ที่เจ๋งมากพอสมควร ถ้า เครื่องมือนั้น เปิดเป็น public API ก็อาจสร้าง feedback loop ที่ทำให้เราเปรียบเทียบความต่างของสถานะภายในโมเดลตาม prompt ต่าง ๆ และทำ tuning อย่างเป็นระบบมากขึ้นได้

• tutorial นี้เขียนขึ้นสำหรับโมเดลสามตัว (Sonnet, Haiku, Opus 3) ยังมีบทเรียนบางส่วนที่ใช้ได้จนถึงทุกวันนี้ แต่ก็มีบางส่วนที่ไม่ค่อยสำคัญแล้วสำหรับ RL model ที่ฉลาดกว่า (เช่น Sonnet 4.5) และเพื่ออ้างอิง Claude 3 Haiku คือโมเดลที่เล็กที่สุด เร็วที่สุด และถูกที่สุด ส่วน Sonnet กับ Opus ฉลาดกว่า โดย Opus เก่งที่สุด

  • ผมคิดว่าบทที่ 3 กับ 6 สำคัญน้อยลงเมื่อมองจากปัจจุบัน และก็สงสัยว่ายังมีส่วนอื่นอีกไหมที่สำคัญน้อยลง ถ้าสมมติว่าคนอ่านคือคนที่ทำงานกับ prompt แบบวนซ้ำหรือเน้นความแม่นยำ