กำไร:
- สามารถออกแบบวิธีที่ระบบพร้อมท์แนะนำโมเดลตลอดการสนทนาทั้งหมดได้
- เข้าใจบทบาทและผลกระทบด้านต้นทุนของการคิดแบบปรับตัวและพารามิเตอร์ความพยายาม
- ใช้การควบคุมเอาต์พุต เช่น max_tokens ลำดับการหยุด และเอาต์พุตที่มีโครงสร้าง
ผลิตภัณฑ์สองรายการที่แตกต่างกันในรุ่นเดียวกันอาจมีพฤติกรรมแตกต่างไปจากเดิมอย่างสิ้นเชิง ความแตกต่างไม่ได้อยู่ในตัวโมเดล แต่อยู่ในพรอมต์ของระบบและพารามิเตอร์ที่กำหนด พรอมต์ของระบบคือ "สัญญางาน" ของโมเดล และพารามิเตอร์คือ "การตั้งค่างาน" ในหน่วยนี้ คุณจะได้เรียนรู้วิธีการออกแบบพรอมต์ของระบบที่มีประสิทธิภาพ การตั้งค่าการคิดและความพยายามในโมเดลสมัยใหม่ทำอย่างไร และวิธีการควบคุมเอาต์พุตสำหรับรูปแบบ/ความยาว การตั้งค่าเหล่านี้อย่างถูกต้องทำให้คุณสามารถจัดการทั้งคุณภาพและต้นทุนได้ในเวลาเดียวกัน
พร้อมท์ระบบ: คำสั่งถาวรของแบบจำลอง
พรอมต์ของระบบคือคำสั่งระดับสูงที่ใช้ตลอดการสนทนาทั้งหมด กฎเหล่านี้ยังคงใช้ได้ไม่ว่าผู้ใช้จะเป็นประเภทใดก็ตาม พรอมต์ของระบบที่ดีประกอบด้วยส่วนประกอบต่อไปนี้:
- บทบาท/ตัวตน: ใครคือนางแบบ? (“คุณเป็นผู้ช่วยสนับสนุนองค์กร”)
- ขอบเขตและขอบเขต: มันทำอะไรและไม่ทำอะไร? (“ยึดตามเอกสารกรมธรรม์ที่ให้ไว้เท่านั้น”)
- กฎการจัดรูปแบบ: ผลลัพธ์ควรมีลักษณะอย่างไร ("สูงสุด 3 บทความ ภาษาราชการ")
- พฤติกรรมในความไม่แน่นอน: เราทำอะไรเมื่อไม่แน่ใจ? ("หากไม่มีข้อมูลให้จัดทำส่งตรงไปยังหน่วยงานที่เกี่ยวข้อง")
- ความปลอดภัย/ความเป็นส่วนตัว: อะไรไม่ต้องการ/ไม่ต้องการ? ("ขอข้อมูลส่วนบุคคล")
เคล็ดลับ: รักษาพรอมต์ของระบบให้คงที่ อย่าฝังข้อมูลที่เปลี่ยนแปลงไปพร้อมกับคำขอแต่ละรายการ (วันที่ปัจจุบัน ชื่อผู้ใช้ รหัสเซสชัน) สิ่งนี้จะทำลายความสอดคล้องและทำให้แคชพร้อมท์บนหน่วย 6 เป็นโมฆะ ใส่ข้อมูลตัวแปรในข้อความผู้ใช้
กับดักคำสั่งที่ก้าวร้าวมากเกินไป
โมเดลสมัยใหม่ปฏิบัติตามคำแนะนำอย่างใกล้ชิด วลีที่ก้าวร้าวเช่น "ต้อง", "เสมอ", "ทำเช่นนี้อย่างแน่นอน" ฯลฯ ซึ่งใช้ได้กับรุ่นเก่า ในปัจจุบันนำไปสู่การกระตุ้นมากเกินไป: โมเดลจะเรียกตัวแทนเมื่อไม่จำเป็นหรือทำงานเป็นเวลานานโดยไม่จำเป็น ปรับกฎให้นุ่มนวลขึ้น: แทนที่จะ "ต้องใช้เครื่องมือค้นหา" กลับกลายเป็น "ถ้าคำตอบไม่อยู่ในการสนทนา ให้ใช้เครื่องมือค้นหา" จะแม่นยำกว่า
พารามิเตอร์โมเดล: ความคิดและความพยายาม
LLM แบบคลาสสิกมีพารามิเตอร์อุณหภูมิ: ค่าที่ต่ำกว่าจะให้ผลลัพธ์ที่เฉพาะเจาะจง/สม่ำเสมอมากขึ้น ค่าที่สูงกว่าจะให้ผลลัพธ์ที่หลากหลาย/สร้างสรรค์มากขึ้น โมเดลสมัยใหม่ (เช่น Opus 4.8, Sonnet 5) แทนที่แนวทางนี้ด้วยกลไกที่ทรงพลังกว่าสองกลไก และไม่ยอมรับพารามิเตอร์การสุ่มตัวอย่างเช่นอุณหภูมิอีกต่อไป
- การคิดแบบปรับเปลี่ยนได้: โมเดลจะให้เหตุผลทีละขั้นตอนใน "หัว" ของมันก่อนที่จะตอบสนอง แบบจำลองจะตัดสินใจว่าจะคิดมากน้อยเพียงใดโดยพิจารณาจากความยากของงาน ปรับปรุงความแม่นยำอย่างมากในปัญหาที่ซับซ้อนและหลายขั้นตอน เขาคิดให้น้อยลงเพื่อหลีกเลี่ยงความล่าช้าโดยไม่จำเป็นสำหรับคำถามง่ายๆ
- ความพยายาม: ปุ่มระดับสูงที่ปรับความลึกของโมเดลในการเจาะลึกงาน และจำนวนโทเค็นที่ใช้ทั้งหมด ระดับทั่วไป: ต่ำ ปานกลาง สูง และสูงกว่า ความพยายามสูงอาจปรับปรุงคุณภาพ แต่ยังเพิ่มความล่าช้าและต้นทุนด้วย ความพยายามต่ำนำมาซึ่งความรวดเร็วและความประหยัด
การตั้งค่า
ทำอะไร
เมื่อ
คิดนอก/ความพยายามต่ำ
รวดเร็ว ราคาถูก ผิวเผิน
การจำแนกประเภทอย่างง่าย การตอบสนองสั้น ๆ งานที่ไวต่อความล่าช้า
การคิดแบบปรับตัว + ความพยายามปานกลาง
คุณภาพ/ต้นทุนที่สมดุล
งานวัตถุประสงค์ทั่วไปส่วนใหญ่
การคิดแบบปรับตัว + ความพยายามสูง
ความแม่นยำสูงสุด
การใช้เหตุผลที่ซับซ้อน การเขียนโค้ด งานตัวแทนระยะไกล
ข้อควรระวัง: การสะท้อนกลับ "ความพยายามสูงสุดไม่ว่าจะอย่างไรก็ตาม" จะทำให้ต้นทุนสูงขึ้น ปรับความพยายามให้เข้ากับงาน ในงานง่ายๆ ความพยายามต่ำมักจะให้ผลลัพธ์ที่แม่นยำเหมือนเดิมในราคาที่ถูกกว่ามาก ไปให้สูงในที่ที่ต้องการความแม่นยำที่สำคัญ
การควบคุมเอาต์พุต: รูปแบบ ความยาว โครงสร้าง
นอกจากพารามิเตอร์แล้ว คุณยังสามารถควบคุมเอาต์พุตได้ด้วย:
- max_tokens: เพดานแข็งของเอาต์พุต (ยูนิตที่ 1 และ 3)
- ลำดับการหยุด: การหยุดโมเดลเมื่อเห็นสตริงบางตัว มีประโยชน์สำหรับการตั้งค่าเบรกพอยต์ในการผลิตที่มีโครงสร้าง
- เอาต์พุตที่มีโครงสร้าง: บังคับการตอบสนองของโมเดลให้สอดคล้องกับสคีมา JSON ที่คุณระบุ ช่วยให้มั่นใจได้ว่าเอาต์พุตสามารถแยกวิเคราะห์และถูกต้องโดยทางโปรแกรมได้ เชื่อถือได้มากกว่าการพูดว่า "just return JSON" พร้อมข้อความแจ้ง
{ "output_config": { "format": { "type": "json_schema", "schema": { "type": "object", "เพิ่มเติมProperties": false, "properties": { "category": { "type": "string", "enum": ["ใบแจ้งหนี้", "ทางเทคนิค", "return", "other"] }, "เร่งด่วน": { "type": "string", "enum": ["ต่ำ", "ปานกลาง", "สูง"] } }, "จำเป็น": ["หมวดหมู่", "เร่งด่วน"] } } }}
เทมเพลตพร้อมท์ระบบที่คัดลอกได้
# ผู้ช่วยสนับสนุนองค์กรคุณเป็นผู้ช่วยสนับสนุนองค์กร- อาศัยเอกสารนโยบายที่ให้ไว้เท่านั้น หากไม่มีอยู่ในเอกสาร ให้พูดว่า "ฉันไม่มีข้อมูลนี้" - ให้คำตอบอย่างเป็นทางการและชัดเจนไม่เกิน 3 ประโยค - ถามข้อมูลส่วนบุคคล (หมายเลข TC ID, หมายเลขบัตร) และอย่าทำซ้ำในคำตอบของคุณ - หากไม่แน่ใจอย่าเดา
# ตัวแยกประเภทการบังคับใช้เอาต์พุตที่มีโครงสร้างคุณคือตัวแยกประเภทความต้องการ ข้อมูลเข้าเป็นข้อความของลูกค้า ส่งคืนเฉพาะฟิลด์ที่ร้องขอ ห้ามเขียนความคิดเห็น หากคุณไม่แน่ใจ ให้ใช้ "อื่นๆ"
# นักวิเคราะห์ที่มีพฤติกรรมที่กำหนดไว้ในความไม่แน่นอนคุณคือนักวิเคราะห์ข้อมูล วาดเฉพาะการอนุมานที่ตรวจสอบได้จากตารางที่ให้ไว้ อย่าสร้างข้อสรุปที่ไม่มีอยู่ในข้อมูล หากการอนุมานไม่ชัดเจน ให้เขียนว่า "ข้อมูลไม่เพียงพอ"
# นักเขียนเนื้อหาพร้อมการควบคุมโทนและความยาวคุณเป็นนักเขียนเนื้อหา ใช้น้ำเสียงที่อบอุ่นแต่เป็นมืออาชีพ จำกัดแต่ละข้อความไว้ที่ 120 คำหรือน้อยกว่า หลีกเลี่ยงภาษาการตลาดที่ซ้ำซากจำเจ
พรอมต์อ่อน / พรอมต์แรง
# WEAK ให้ความช่วยเหลือและให้คำตอบที่ดี ทำดีที่สุดของคุณ
# บทบาทที่แข็งแกร่ง: ผู้เชี่ยวชาญด้านการสนับสนุนทางเทคนิค ขอบเขต: มีคู่มือผลิตภัณฑ์เท่านั้น รูปแบบ: รายการทีละขั้นตอน ลำดับเลข สูงสุด 5 ขั้นตอน ขีดจำกัด: แนะนำวิธีแก้ปัญหาที่ไม่อยู่ในคำแนะนำ พูดว่า "ฉันไม่พบมันในคู่มือ" ความเป็นส่วนตัว: อย่าใช้หมายเลขซีเรียลที่ผู้ใช้แชร์ซ้ำในการตอบกลับ
รุ่นทรงพลัง; โดยจะกำหนดบทบาท ขอบเขต รูปแบบ ขอบเขต และการรักษาความลับแยกกัน ความสม่ำเสมอของเอาต์พุตมาจากความชัดเจนนี้โดยตรง
มินิเคสสามอัน
กรณีที่ 1 — การลดต้นทุนด้วยการปรับความพยายาม ทีมหนึ่งกำลังเรียกร้องความพยายาม + คิดอย่างสูง แม้แต่การสรุปอีเมลง่ายๆ ก็มีราคาแพงและผลิตได้ช้า พวกเขามอบหมายงานง่ายๆ เช่น สรุปให้กับความพยายามต่ำ และการวิเคราะห์สัญญาให้กับความพยายามสูง รักษาความแม่นยำ เวลาแฝงโดยเฉลี่ยลดลงครึ่งหนึ่ง และค่าใช้จ่ายรายเดือนลดลงหนึ่งในสาม
กรณีที่ 2 — การรับประกัน JSON ทีมปฏิบัติการขอผลลัพธ์การจัดหมวดหมู่พร้อมข้อความแจ้งว่า "แค่ให้ JSON" แต่บางครั้งโมเดลจะเขียนว่า "นี่คือผลลัพธ์:" และโปรแกรมแยกวิเคราะห์ก็จะขัดข้อง เมื่อฉันเชื่อมต่อสคีมาเอาต์พุตที่กำหนดค่าไว้ เอาต์พุตจะส่งคืน JSON ที่ถูกต้องทุกครั้ง ข้อผิดพลาดในการแยกวิเคราะห์ถูกรีเซ็ตแล้ว
กรณีที่ 3 - การหดตัวทันทีแบบก้าวร้าว ผู้ช่วยแจ้งว่า "ต้องค้นหาทุกคำถาม"; แบบจำลองนี้ทำการค้นหาโดยไม่จำเป็นแม้แต่คำถามง่ายๆ ที่รู้คำตอบอยู่แล้ว ซึ่งช่วยชะลอความเร็วและเพิ่มต้นทุน พวกเขาผ่อนปรนกฎเป็น "หากคำตอบไม่อยู่ในบริบท ให้ค้นหา"; การโทรที่ไม่จำเป็นลดลง 70% และการตอบสนองก็เร็วขึ้น
ข้อผิดพลาดทั่วไป
- การฝังข้อมูลตัวแปรในพรอมต์ของระบบ: ทำลายความสอดคล้องและทำให้แคชใช้ไม่ได้
- คำสั่งที่ก้าวร้าวมากเกินไป: การกระตุ้นมากเกินไปและต้นทุนที่ไม่จำเป็นในโมเดลสมัยใหม่
- ความพยายามสูงในทุกงาน: เสียไปกับงานง่ายๆ ปรับความพยายามให้เข้ากับงาน
- การร้องขอ JSON ผ่านทางพรอมต์เท่านั้น: มันหยุดทำงานเป็นครั้งคราว; หากสำคัญ ให้ใช้เอาต์พุตที่มีโครงสร้าง
- ไม่ได้กำหนดขอบเขต/พฤติกรรมที่คลุมเครือ: โมเดลเติมเต็มช่องว่างด้วยการประดิษฐ์ (ภาพหลอน)
- นิสัยเก่าเกี่ยวกับ "อุณหภูมิ": โมเดลสมัยใหม่ไม่ยอมรับสิ่งนี้ ชี้แนะพฤติกรรมด้วยความรวดเร็วและความพยายาม
ลึกลงไป: การเขียนพร้อมท์เหมือนสัญญา
ทีมงานที่มีประสบการณ์ปฏิบัติต่อระบบพร้อมท์เหมือนสัญญา ไม่ใช่ข้อความในวรรณกรรม: มีประโยคที่ชัดเจน กฎที่วัดผลได้ มีขอบเขตที่ชัดเจน แนวทางนี้มีคุณประโยชน์ที่เป็นรูปธรรมสามประการ ประการแรกคือความสม่ำเสมอ: อินพุตเดียวกันจะให้เอาต์พุตที่คล้ายกันในเวลาที่ต่างกัน ประการที่สองคือความสามารถในการทดสอบ: คุณสามารถทดสอบแต่ละรายการแยกกันโดยใช้ตัวอย่างได้ ประการที่สามคือความง่ายในการบำรุงรักษา: หากพฤติกรรมผิดปกติ คุณจะรู้ว่าต้องเปลี่ยนรายการใด
แนวปฏิบัติที่ดีคือการเป็นผู้นำด้วยตัวอย่างเชิงบวก แทนที่จะระบุรายการ "อย่าทำเช่นนี้" จะมีประสิทธิภาพมากกว่าในโมเดลสมัยใหม่มากในการยกตัวอย่างที่ระบุว่า "นี่คือลักษณะของผลลัพธ์ที่ต้องการ" ตัวอย่างเช่น ในตัวแยกประเภท การเพิ่มหนึ่งหรือสองตัวอย่างของ JSON ที่คาดหวังไปยังพร้อมต์จะช่วยลดข้อผิดพลาดในการจัดรูปแบบได้อย่างมาก
เทคนิคที่ทรงพลังอีกประการหนึ่งคือการเขียนพฤติกรรมความไม่แน่นอนอย่างชัดเจน ส่วนคำสั่งเช่น "หากไม่แน่ใจ อย่าเดา พูดว่า 'ข้อมูลไม่เพียงพอ'" จะระงับแนวโน้มของแบบจำลองที่จะเติมช่องว่างด้วยการประดิษฐ์ (ภาพหลอน) ประโยคเดียวนี้จะช่วยลดชั้นการตรวจสอบ ซึ่งเราจะกล่าวถึงในหน่วยที่ 11: เมื่อแบบจำลองได้ทำเครื่องหมายความไม่แน่นอนแล้ว จะนำไปสู่การตรวจสอบโดยมนุษย์ได้ง่ายขึ้น
สุดท้ายนี้จงพิจารณาความพยายามและพร้อมท์ร่วมกัน เมื่อใช้ความพยายามสูง แบบจำลองจะสำรวจมากขึ้นและบางครั้งก็ทำ "งานพิเศษ" ที่ไม่พึงประสงค์ (คำอธิบายที่ไม่จำเป็น คำแนะนำเพิ่มเติม) การพูดว่า "ให้เฉพาะผลลัพธ์ที่ต้องการเท่านั้น อย่าเพิ่มความคิดเห็นเพิ่มเติม" ในพรอมต์จะชดเชยผลข้างเคียงของความพยายามสูงนี้
โดยสรุป
พรอมต์ของระบบเป็นคำสั่งถาวรของโมเดล: โดยจะกำหนดบทบาท ขอบเขต รูปแบบ พฤติกรรมที่ไม่ชัดเจน และการรักษาความลับ ในโมเดลสมัยใหม่ พฤติกรรมขับเคลื่อนโดยการคิดแบบปรับตัวและพารามิเตอร์ความพยายามมากกว่าอุณหภูมิ การปรับความพยายามให้สอดคล้องกับงานจะจัดการคุณภาพและต้นทุนไปพร้อมๆ กัน คุณรักษาความปลอดภัยเอาต์พุตด้วย max_tokens อาร์เรย์หยุด และเอาต์พุตที่มีโครงสร้าง
งานสมัคร
เลือกงาน (1) เขียนพร้อมท์ของระบบด้วยห้าองค์ประกอบ (บทบาท ขอบเขต รูปแบบ ความคลุมเครือ การรักษาความลับ) (2) ระบุระดับความพยายามที่คุณจะเลือกสำหรับงานนี้ และเพราะเหตุใด (3) หากควรมีโครงสร้างเอาต์พุต ให้ร่างสคีมา JSON ขนาดเล็ก (4) ตรวจสอบว่ามีรูปแบบที่ก้าวร้าวมากเกินไปในข้อความแจ้งของคุณและทำให้นุ่มนวลลง
รายการตรวจสอบ
- [ ] ฉันสามารถตั้งชื่อห้าองค์ประกอบของพรอมต์ระบบที่ดีได้
- [ ] ฉันสามารถอธิบายได้ว่าพารามิเตอร์การคิดแบบปรับตัวและความพยายามทำอะไรได้บ้าง
- [ ] ฉันสามารถสร้างสมดุลระหว่างคุณภาพ/ต้นทุนได้โดยการปรับความพยายามตามงาน
- [ ] ฉันรู้ว่าเหตุใดเอาต์พุตที่มีโครงสร้างจึงปลอดภัยกว่าการขอ JSON ผ่านทางพรอมต์
- [ ] ฉันสามารถรับรู้ถึงความเสี่ยงในโมเดลสมัยใหม่ของคำสั่งที่ก้าวร้าวจนเกินไป