Prompt Engineering Basics: A Practical Glossary Entry

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

Prompt จริงๆ คืออะไร

Prompt คือทุกอย่างที่คุณส่งไปยังโมเดลก่อนที่มันจะสร้างคำตอบ — คำสั่ง บริบท ตัวอย่าง และคำถามหรืองานจริงๆ โมเดลแชทสมัยใหม่ส่วนใหญ่แบ่งสิ่งนี้ออกเป็นบทบาท: system message (ตั้งค่าพฤติกรรมและข้อจำกัด) user messages (คำขอจริง) และบางครั้ง assistant messages (เทิร์นก่อนหน้าหรือตัวอย่าง) หากคุณใช้ API เช่นของ OpenAI หรือ Anthropic คุณจะตั้งค่าเหล่านี้อย่างชัดแจ้งในโค้ด หากคุณใช้อินเตอร์เฟซแชท system prompt มักจะถูกซ่อนหรือตั้งค่าครั้งเดียวที่จุดเริ่มต้นของการสนทนา

ทำไมคำถามเดียวกันถึงได้คำตอบต่างกัน

โมเดลภาษาทำนายโทเคนถัดไปจากทุกสิ่งที่มาก่อนหน้า รวมถึงการเขียนของคุณ ลำดับคำ และแม้กระทั่งการใช้เครื่องหมายวรรคตอน ถาม "Explain recursion" แล้วคุณจะได้คำตอบตามตำราเรียนทั่วไป ถาม "Explain recursion to a junior developer who understands loops but not recursion, using a single Python example with a base case and recursive case" แล้วคุณจะได้สิ่งที่มีประโยชน์มากขึ้น ความเจาะจำของอินพุตของคุณกำหนดความเจาะจำของผลลัพธ์โดยตรง นี่คือสัญญาณสำคัญที่ผู้เริ่มต้นต้องใจ: โมเดลไม่ได้อ่านใจคุณ มันกำลังจับคู่รูปแบบกับคำของคุณ

เทคนิคหลักที่ควรเรียนรู้ก่อน

Zero-shot prompting หมายถึงการถามโดยตรงโดยไม่มีตัวอย่าง: "Write a regex that matches US phone numbers." วิธีนี้ใช้ได้ดีกับงานทั่วไปที่กำหนดไว้อย่างชัดเจน

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

Chain-of-thought prompting ขอให้โมเดลคิดทีละขั้นตอนก่อนให้คำตอบสุดท้าย มักจะโดยการเพิ่ม "think step by step" อย่างแท้จริงหรือโดยการขอให้แสดงการทำงาน วิธีนี้ช่วยกับคณิตศาสตร์ ตรรกะ และงานหลายขั้นตอน แม้ว่ามันจะเพิ่มการใช้โทเคนและความยาวของการตอบด้วย

Role prompting กำหนดบุคลิกให้โมเดล — "You are a senior security engineer reviewing this code for vulnerabilities" — ซึ่งสามารถเปลี่ยนน้ำเสียง คำศัพท์ และรายละเอียดประเภทที่มันให้ความสำคัญ มันไม่ได้ให้ความสามารถใหม่แก่โมเดล แต่มันทำให้รูปแบบเอาต์พุตมั่นคง

โครงสร้างสำคัญกว่าความเฉลียวฉลาด

ผู้เริ่มต้นมักคิดว่า prompt engineering คือการหาวลีแม่นม้ายาก ในทางปฏิบัติ โครงสร้างเอาชนะความเฉลียวฉลาดเกือบทุกครั้ง แบ่ง prompt ของคุณออกเป็นส่วนชัดเจน: บริบท งาน ข้อจำกัด และรูปแบบ ตัวอย่างเช่น:

Context: You're reviewing a Python Flask app for a security audit.
Task: Identify SQL injection risks in the code below.
Constraints: Only flag issues in the /login and /search routes.
Format: Return a numbered list with the line number and a one-sentence explanation.

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

ความผิดพลาดทั่วไปตั้งแต่เริ่มต้น

ข้อผิดพลาดทั่วไปคือความกำกวมปลอมตัวเป็นความสั้น — ถาม "make this better" โดยไม่กำหนดว่า "better" หมายถึงอะไร (เร็วกว่า? อ่านง่ายกว่า? ปลอดภัยกว่า?) อีกอย่างคือการบรรจุ prompt เดียวด้วยห้างานที่ไม่เกี่ยวข้อง ซึ่งมักจะให้ผลลัพธ์ตื้นต่อทั้งห้างานแทนที่จะเป็นคำตอบที่เข้มแข็งต่องานเดียว ผู้เริ่มต้นก็ลืมว่าโมเดลไม่มีความจำระหว่างการเรียก API แยกต่างหากเว้นแต่คุณจะส่งประวัติการสนทนาก่อนหน้ากลับมาอย่างชัดแจ้ง ซึ่งทำให้คนสับสนเมื่อสร้างสิ่งใดๆ ที่มีสถานะ

การทดสอบและการวนซ้ำเหมือนวิศวกร

ปฏิบัติต่อ prompt เหมือนโค้ดที่คุณเวอร์ชันและทดสอบ ไม่ใช่ข้อความแบบครั้งเดียวที่คุณทิ้งไป เก็บบันทึกของรูปแบบ prompt และเอาต์พุต โดยเฉพาะกับสิ่งใดๆ ที่คุณจะใช้ซ้ำในการผลิต เช่นบ็อทสนับสนุนลูกค้าหรือผู้ช่วยตรวจสอบโค้ด การเปลี่ยนแปลงการเขียนเล็กน้อย — "summarize" เทียบกับ "summarize in exactly three bullet points" — สามารถให้ผลลัพธ์ที่แตกต่างกันอย่างมีความหมาย และวิธีเดียวที่จะรู้ว่าสิ่งใดใช้ได้กับกรณีการใช้งานของคุณคือการเรียกใช้การเปรียบเทียบด้วยตัวเองแทนที่จะสมมติ

สิ่งนี้พอดีกับการสร้างสิ่งของจริงอย่างไร

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

หากคุณต้องการไปต่อ ตรวจสอบส่วนของ Korra Studio เกี่ยวกับการทำงานกับ LLM APIs ใน Python และเกี่ยวกับการสร้างเครื่องมือขนาดเล็กที่ขับเคลื่อนด้วย AI ตั้งแต่เริ่มต้น