บริการวิศวกรรมทันที

ในโมดูล Generative AI คุณได้ทราบว่าอินพุต สเปซของโมเดล Generative AI นั้นแทบจะไม่มีขีดจำกัด หากต้องการสร้างเอาต์พุตที่ สอดคล้องกับความคาดหวังของผู้ใช้ คุณต้องสร้างพรอมต์ พรอมต์ คือสัญญาที่มีโครงสร้างระหว่างแอปพลิเคชันของคุณกับโมเดล

พรอมต์ที่เขียนอย่างดีควรมีลักษณะดังนี้

  • ระบุวิธีที่ LLM ควรสร้างคำตอบ
  • ประกอบด้วยคอมโพเนนต์หลายอย่างที่สามารถกำหนดเวอร์ชัน ทดสอบ และปรับปรุงได้ เมื่อเวลาผ่านไป
  • สามารถใช้เป็นอาร์ติแฟกต์ที่แชร์สำหรับการทำงานร่วมกันในทีมต่างๆ ได้

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

ตลอดทั้งโมดูลนี้ เราจะใช้ตัวอย่างร่วมกันคือ BlogBuddy ซึ่งเป็นผู้ช่วยด้านการเขียนที่ทำงานด้วยระบบ AI โดยได้รับแรงบันดาลใจจากการใช้ Prompt API ของ CyberAgent

กลับไปที่โมดูล Generative AI สำหรับพิมพ์เขียวของระบบ BlogBuddy

คอมโพเนนต์ของพรอมต์

คอมโพเนนต์พรอมต์แต่ละรายการมีบทบาทเฉพาะในการกำหนดลักษณะการทำงานของโมเดล

  • บริบท: กำหนดบทบาทและโดเมนของโมเดล เพื่อให้โมเดลเข้าใจวิธี การทำงาน
  • คำสั่ง: มอบหมายงานที่เฉพาะเจาะจงให้กับโมเดล
  • ตัวแปรอินพุต: บริบทเฉพาะสถานการณ์ที่แอปพลิเคชันของคุณระบุ แบบเรียลไทม์
  • รูปแบบเอาต์พุต: กำหนดโครงสร้างเอาต์พุตที่คาดไว้ เช่น คุณอาจต้องการเอาต์พุต JSON
  • ตัวอย่าง: แสดงวิธีดำเนินการงานสำหรับอินพุตอื่นๆ อย่างน้อย 1 รายการ
  • ข้อจำกัด: กำหนดขีดจำกัดที่ชัดเจนเพื่อให้เอาต์พุตสอดคล้องกัน ปลอดภัย และ เป็นไปตามแบรนด์

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

### Context

You are a writing assistant for blog authors.
Your job is to generate helpful, concise, and engaging content.

### Instruction

Generate 3 alternative titles for the user's blog post with a given style.

### Input variables

Here is the content of the blog post:
${blogPostContent}

Here is the desired style:
${titleStyle}

### Output format

Return valid JSON ONLY, in the following exact structure:
{
  "titles": ["Title option 1", "Title option 2", "Title option 3"]
}

### Examples

Example input:
{
  "blogPostContent": "I finally visited the small neighborhood café I've been eyeing for months...",
  "titleStyle": "friendly"
}

Example output:
{
  "titles": [
    "A First Visit to the Neighborhood Café",
    "Trying the Café I've Wanted to Visit for Months",
    "My Experience at a Long-Awaited Local Spot"
  ]
}
### Constraints

- Each title must be under 128 characters.
- Titles must be original, not copied verbatim from the draft.
- Keep the tone natural and human. Avoid emojis unless explicitly requested.
- Avoid sensationalism or clickbait.
- If the draft includes multiple topics, choose the most prominent topic.

สำหรับพรอมต์แรก ให้เริ่มจากสิ่งสำคัญ ได้แก่ คำสั่งและรูปแบบเอาต์พุต จากนั้นให้เพิ่มคอมโพเนนต์อื่นๆ ซ้ำๆ ขณะวิเคราะห์ผลลัพธ์และพิจารณาว่าต้องมีการควบคุมที่ละเอียดยิ่งขึ้นเพื่อความสําเร็จ

พรอมต์ของระบบเทียบกับพรอมต์ของผู้ใช้

คอมโพเนนต์ของพรอมต์บางส่วนมีการฮาร์ดโค้ดไว้ ในขณะที่คอมโพเนนต์อื่นๆ ผู้ใช้ปลายทางสามารถระบุได้

  • พรอมต์ของระบบมาจากนักพัฒนาแอปพลิเคชันและกำหนดลักษณะการทำงานโดยรวมของโมเดล โดยสามารถกำหนดบทบาทของโมเดล น้ำเสียงที่คาดหวัง รูปแบบเอาต์พุต (เช่น สคีมา JSON ที่เข้มงวด) และข้อจำกัดส่วนกลาง พรอมต์ของระบบยังเป็นที่ที่คุณเข้ารหัสข้อกำหนดด้านความปลอดภัยและความรับผิดชอบด้วย โดยจะยังคงสอดคล้องกันในคำขอต่างๆ และเป็นรากฐานที่มั่นคงสำหรับ ลักษณะการทำงานของโมเดล

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

API ของ Generative AI ส่วนใหญ่จะช่วยให้คุณจัดโครงสร้างพรอมต์เป็นอาร์เรย์ของข้อความ แต่ละข้อความจะมีบทบาท (ระบบหรือผู้ใช้) และเนื้อหา ซึ่งจะช่วยให้แยกคำสั่งที่เสถียรและเป็นสากลออกจากอินพุตแบบไดนามิกต่อคำขอได้ง่ายขึ้น

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

กรณีการใช้งานที่จำกัด

สำหรับกรณีการใช้งานที่เฉพาะเจาะจงมาก คุณสามารถกำหนดพรอมต์ส่วนใหญ่ไว้ล่วงหน้าในพรอมต์ของระบบได้ เช่น ใน BlogBuddy ผู้ใช้สามารถคลิกแสดงชื่อเพื่อ แสดงรายการคำแนะนำชื่อที่สร้างขึ้นสำหรับฉบับร่าง

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

หากต้องการสร้างฟีเจอร์นี้ด้วย Prompt API เราจะใช้ initialPrompts เพื่อกำหนดลักษณะการทำงานระดับระบบสำหรับทั้งเซสชัน

// Defines stable behavior for the entire session
const session = await LanguageModel.create({
  initialPrompts: [
    {
      role: "system",
      content: `You are a blog-writing assistant.
      Your task is to generate high-quality titles for blog posts.
      Always respond in concise, friendly language.
      Return exactly 3 alternative titles.
      Produce valid JSON with a "titles" array of strings.`
    }
  ]
});

เมื่อผู้ใช้คลิกแสดงคำบรรยายแทนเสียง ระบบจะเรียกใช้ข้อความแจ้งสำหรับเนื้อหาปัจจุบัน

// The only variable input is the blog content
const result = await session.prompt(blogContent);

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

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

งานที่ยืดหยุ่นต้องอาศัยพรอมต์ของผู้ใช้โดยละเอียด

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

เมื่อใช้ฟีเจอร์งานที่ยืดหยุ่น ผู้ใช้จะต้องระบุข้อมูลเพิ่มเติม เนื่องจากตัวเลือกที่เป็นไปได้มีหลากหลายมากขึ้น พรอมต์ของระบบยังคงควบคุมลักษณะการทำงานโดยรวม

แนวทางปฏิบัติแนะนำมีดังนี้

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

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

เทคนิคการป้อนพรอมต์ที่พบบ่อย

โดยปกติแล้ว นักพัฒนาซอฟต์แวร์จะลองใช้เทคนิคการเขียนพรอมต์หลายอย่างเพื่อค้นหาสิ่งที่เหมาะกับกรณีการใช้งานและโมเดลของตนมากที่สุด

การเขียนพรอมต์แบบ Zero-Shot Prompting

คุณอธิบายงานสำหรับโมเดลและหวังว่าทุกอย่างจะเรียบร้อย เช่น

"What is the capital of France?"

การแจ้งแบบศูนย์ช็อตเป็นพื้นฐานที่มีประสิทธิภาพสำหรับงาน AI หลายอย่าง สำหรับคำขอที่ไม่ซับซ้อน เช่น การค้นหาความรู้แบบสารานุกรม คุณอาจใช้เทคนิคนี้ต่อไปได้ อย่างไรก็ตาม ในการใช้งานจริงส่วนใหญ่ คุณจะต้องขยายพรอมต์ด้วยการปรับแต่งและตรรกะเพิ่มเติม

Few-Shot Prompting

การแจ้งแบบ Few-Shot คือการให้ตัวอย่างเพื่อแสดงลักษณะการทำงานที่ถูกต้อง รูปแบบ โครงสร้าง และตัวแปรสำคัญอื่นๆ ตัวอย่างพรอมต์สำหรับการจัดประเภทความรู้สึกมีดังนี้

You classify user messages into one of the following categories:
- "positive"
- "negative"
- "neutral"
Here are examples to guide your classifications:
Input: "I love this product! It works perfectly."
Output: { "label": "positive" }

Input: "This is terrible. I want a refund."
Output: { "label": "negative" }

Few-Shot Prompting มีประโยชน์สำหรับงานที่ต้องมีการคาดการณ์แบบเสมือนจริงประเภทนี้ นอกจากนี้ ยังใช้กับงานที่มีโครงสร้างที่จดจำได้ เช่น การสร้างชื่อในรูปที่ 1

เมื่อพื้นที่เอาต์พุตมีความกว้างมาก เช่น เนื้อหาแบบปลายเปิดหรือเนื้อหารูปแบบยาว การแจ้งแบบ Few-Shot อาจไม่ใช่เทคนิคที่ดีที่สุด การให้ตัวอย่างที่ครอบคลุมพื้นที่อย่างมีความหมายเป็นเรื่องยากหรือเป็นไปไม่ได้

การเขียนพรอมต์แบบ Chain-of-Thought

คุณกระตุ้นให้โมเดลให้เหตุผลทีละขั้นตอนก่อนที่จะสร้างคำตอบ คุณจะอธิบายขั้นตอนอย่างชัดเจนหรือปล่อยให้โมเดลกำหนดก็ได้ เช่น

"Think step-by-step to identify the main idea of this paragraph. Then produce a
short heading under 60 characters."

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

ซึ่งอาจมีค่าใช้จ่ายสูง การสร้างร่องรอยการให้เหตุผลแบบทีละขั้นตอนจะเพิ่มการคำนวณ ต้นทุน และเวลาในการตอบสนอง ใช้เฉพาะเมื่อกรณีการใช้งานของคุณต้องใช้การให้เหตุผลและการวางแผนที่ซับซ้อน

การแจ้งให้ไตร่ตรองตนเอง

หลังจากสร้างเนื้อหาครั้งแรก คุณขอให้โมเดลวิจารณ์และ แก้ไขเอาต์พุตของตัวเอง เช่น

"Review your previous output.
Identify unclear phrasing and rewrite it more concisely."

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

สิ่งที่ได้เรียนรู้

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

ในโมดูลถัดไป เราจะมาดูการพัฒนาพรอมต์ที่ขับเคลื่อนด้วยการประเมิน แนวทางปฏิบัตินี้จะช่วยให้คุณปรับปรุงพรอมต์อย่างเป็นระบบและมุ่งเน้นไปที่สิ่งที่เหมาะกับผลิตภัณฑ์และผู้ใช้มากที่สุด

แหล่งข้อมูล

เทคนิคแต่ละอย่างมีรูปแบบและแนวทางปฏิบัติแนะนำของตัวเอง มีแหล่งข้อมูลภายนอกโดยละเอียดมากมาย เช่น

โปรดดูเอกสารประกอบของโมเดลที่คุณเลือก เนื่องจากอาจมีคำแนะนำเฉพาะสำหรับคุณ เพื่อให้ได้ผลลัพธ์ที่ดีที่สุด

ทดสอบความเข้าใจ

คุณระบุกฎประเภทใดได้บ้างในพรอมต์ของระบบ

ตัวแปรอินพุตที่เฉพาะเจาะจง (เช่น ข้อมูลจากผู้ใช้) โครงสร้างเอาต์พุตที่คาดไว้ บทบาทของโมเดล และขีดจํากัดจํานวนอักขระ
เยี่ยมมาก ถูกต้องแล้ว
เฉพาะข้อมูลจากผู้ใช้เท่านั้นที่ป้อนได้ที่นี่
ยังไม่ใช่ ลองอีกครั้ง
เพื่อกำหนดบทบาทและโดเมนของโมเดล เพื่อให้โมเดลเข้าใจวิธีประพฤติตน
ยังไม่ใช่ ลองอีกครั้ง
ประเภทและขนาดโมเดลที่คุณใช้
ไม่ถูก ลองอีกครั้ง

คุณควรใช้เทคนิคใดเมื่อต้องการให้โมเดลให้เหตุผลทีละขั้นตอนก่อนที่จะสร้างคำตอบ

การเขียนพรอมต์แบบ Zero-Shot Prompting
ไม่ถูกต้อง
Few-Shot Prompting
ไม่ถูกต้อง
การเขียนพรอมต์แบบ Chain-of-Thought
เยี่ยมมาก ถูกต้องแล้ว
การแจ้งให้ไตร่ตรองตนเอง
ไม่ถูกต้อง

Few-Shot Prompting มีประโยชน์มากที่สุดเมื่อใด

เมื่อขอให้โมเดลทำงานโดยไม่มีบริบท
ไม่ถูกต้อง
เมื่องานมีโครงสร้างที่จดจำได้ เช่น การสร้างชื่อ หรือ ต้องมีการจัดรูปแบบที่เฉพาะเจาะจง
เยี่ยมมาก ถูกต้องแล้ว
เมื่อพื้นที่เอาต์พุตมีขนาดใหญ่มาก เช่น การเขียนอย่างสร้างสรรค์แบบปลายเปิด
ไม่ถูกต้อง
เมื่อต้องการให้โมเดลวิจารณ์งานของตัวเอง
ไม่ถูกต้อง

เทคนิคการเขียนพรอมต์เพื่อการไตร่ตรองตนเองคืออะไร

ขอให้โมเดลวิจารณ์และแก้ไขเอาต์พุตของตัวเองเพื่อปรับปรุงความชัดเจนหรือคุณภาพ
เยี่ยมมาก ถูกต้องแล้ว
เรียกใช้พรอมต์หลายครั้งและหาค่าเฉลี่ยของผลลัพธ์
ไม่ถูกต้อง
ขอให้ผู้ใช้เขียนพรอมต์ใหม่หากผลลัพธ์ไม่ดี
ไม่ถูกต้อง
อนุญาตให้โมเดลเปลี่ยนพรอมต์ของระบบแบบไดนามิก
ไม่ถูกต้อง