AI Prompt Engineering · บทเรียน

เมื่อพรอมต์การให้เหตุผลช่วยได้

งานที่ได้รับประโยชน์และต้นทุนที่เกี่ยวข้อง

เมื่อพรอมต์การให้เหตุผลช่วยได้ เป็นบทเรียน AI Prompt Engineering ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน AI Prompt Engineering และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส AI Prompt Engineering มีบทเรียนทั้งหมด 4 บทเรียน

การให้เหตุผลไม่ใช่สิ่งที่ไม่มีต้นทุน

พรอมป์ต์ที่ขอให้เหตุผล (CoT ความสอดคล้องในตนเอง และ ToT) แลก โทเค็น เวลาแฝง และเงินกับความแม่นยำ คำถามสำคัญทางวิศวกรรมไม่ใช่การให้เหตุผล สามารถช่วยได้หรือไม่ แต่คือมันช่วย งานนี้มากพอที่จะคุ้มกับต้นทุนหรือไม่

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

def value_of_reasoning(acc_reason, acc_direct, token_mult, dollar_per_acc):
    gain = acc_reason - acc_direct           # accuracy delta
    cost = token_mult                         # token/latency multiplier
    return gain, gain / cost, gain * dollar_per_acc

งานที่ได้รับประโยชน์มากที่สุด

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

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

BENEFIT_HIGH = [
    'multi_step_arithmetic',
    'logical_deduction',
    'multi_hop_qa',
    'planning_and_scheduling',
    'algorithmic_code',
]

งานที่แทบไม่ได้รับประโยชน์

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

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

BENEFIT_LOW = [
    'sentiment_classification',
    'named_entity_extraction',
    'format_conversion',
    'pure_fact_recall',
]
# Prefer concise zero-shot with a strict output schema here

การคิดมากเกินไปอาจส่งผลเสีย

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

ควรทดสอบแบบ A/B ระหว่างการให้เหตุผลกับการตอบโดยตรงเสมอ แทนที่จะสมมติว่าการให้เหตุผลเป็นการยกระดับที่ดีกว่าอย่างแน่นอน

# Always run the control
results = {
    'direct': eval_direct(task_val),
    'cot':    eval_cot(task_val),
}
use_cot = results['cot'].acc > results['direct'].acc + MIN_GAIN

ตัวคูณต้นทุน

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

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

cost = {
    'direct': 1,
    'cot': 5,                  # ~5x output tokens
    'self_consistency': 5 * N, # times number of samples
    'tot': BRANCH * DEPTH * BEAM * 2,  # gen + eval per node
}

กลไกคัดเลือกการให้เหตุผลแบบปรับตามสถานการณ์

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

วิธีนี้จะรวมการประมวลผลที่มีต้นทุนสูงไว้เฉพาะจุดที่คุ้มค่า และรักษาต้นทุนกับเวลาแฝงเฉลี่ยให้อยู่ในระดับต่ำ

def gated_answer(q):
    draft = llm(direct_prompt(q), temperature=0)
    if confidence(draft) >= 0.85:
        return draft                       # cheap path
    return self_consistency(cot_prompt(q), n=10)  # expensive path

โมเดลที่มีการให้เหตุผลในตัวเปลี่ยนแนวทางตัดสินใจ

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

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

def pick_model(task):
    if task.hardness == 'low':
        return ('fast_model', {'reasoning_effort': 'none'})
    if task.hardness == 'high':
        return ('reasoning_model', {'reasoning_effort': 'high'})
    return ('reasoning_model', {'reasoning_effort': 'low'})

ต้นทุนด้านความสอดคล้องกับเหตุผลและความปลอดภัย

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

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

def expose_reasoning(chain, user_facing):
    if user_facing:
        return summarize_safe(chain)  # never raw; may contain injections
    return chain                       # internal logging only

การวัดความคุ้มค่าอย่างถูกต้อง

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

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

def pareto(configs, val):
    pts = [(c, eval_acc(c, val), eval_cost(c, val)) for c in configs]
    frontier = [
        p for p in pts
        if not any(o[1] >= p[1] and o[2] < p[2] for o in pts if o is not p)
    ]
    return frontier

กรอบการตัดสินใจ

ให้ตัดสินใจตามลำดับนี้: (1) งานเป็นแบบหลายขั้นตอนหรือเชิงประกอบหรือไม่ หากไม่ใช่ ให้ข้ามการให้เหตุผล (2) การทดสอบแบบ A/B แบบออฟไลน์แสดงให้เห็นว่าความแม่นยำเพิ่มขึ้นจริงหรือไม่ (3) ความแม่นยำที่เพิ่มขึ้นยังคุ้มค่าเมื่อคำนึงถึงงบประมาณด้านต้นทุนและเวลาแฝงหรือไม่ (4) การเรียกใช้โมเดลที่แข็งแกร่งกว่าเพียงครั้งเดียว หรือโมเดลที่มีการให้เหตุผลในตัว จะให้ผลลัพธ์เดียวกันด้วยต้นทุนที่ต่ำกว่าหรือไม่

ควรนำการให้เหตุผลมาใช้ก็ต่อเมื่อผ่านเกณฑ์คัดเลือกทั้งสี่ข้อ

def should_reason(task):
    if not task.multi_step: return False
    if eval_gain(task) < MIN_GAIN: return False
    if not within_budget(task): return False
    if cheaper_alternative_matches(task): return False
    return True

นำทุกอย่างมาประกอบกัน

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

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

def policy(q, task):
    if not should_reason(task):
        return llm(direct_prompt(q), temperature=0)
    if task.needs_search:
        return tot_solve(q)
    if task.high_stakes:
        return self_consistency(cot_prompt(q), n=adaptive_n(q))
    return llm(cot_prompt(q), temperature=0)

ตรวจสอบอย่างรวดเร็ว

ตัดสินใจใช้การให้เหตุผลโดยคำนึงถึงต้นทุน

สรุปทบทวน

ประเด็นสำคัญ:

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

คำถามที่พบบ่อย

บทเรียน “เมื่อพรอมต์การให้เหตุผลช่วยได้” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “เมื่อพรอมต์การให้เหตุผลช่วยได้” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส AI Prompt Engineering ให้อัปเกรดเป็น CoddyKit PRO คอร์ส AI Prompt Engineering มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “เมื่อพรอมต์การให้เหตุผลช่วยได้”

งานที่ได้รับประโยชน์และต้นทุนที่เกี่ยวข้อง คุณปฏิบัติ AI Prompt Engineering ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน AI Prompt Engineering หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน AI Prompt Engineering บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน

บทเรียน “เมื่อพรอมต์การให้เหตุผลช่วยได้” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน AI Prompt Engineering นี้ได้ไหม

ได้ บทเรียน AI Prompt Engineering ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

← กลับไปที่ AI Prompt Engineering