การแก้ไขตนเองและการเขียนพรอมต์แบบไตร่ตรอง
นำขั้นตอนการไตร่ตรองมาใช้ โดยให้เอเจนต์ตรวจทานผลลัพธ์ของตนเทียบกับเป้าหมายเดิม ระบุส่วนที่ขาดหายหรือข้อผิดพลาด และสร้างแผนที่แก้ไขแล้วก่อนลองใหม่
การแก้ไขตนเองและการเขียนพรอมต์แบบไตร่ตรอง เป็นบทเรียน AI Engineering Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน AI Engineering Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส AI Engineering Academy มีบทเรียนทั้งหมด 4 บทเรียน
การป้อนคำสั่งแบบสะท้อนคิดคืออะไร
การป้อนคำสั่งแบบสะท้อนคิดเป็นเทคนิคที่ขอให้เอเจนต์ประเมินผลลัพธ์ของตนเองก่อนสรุปผล แทนที่จะสร้างคำตอบแล้วหยุด เอเจนต์จะทบทวนคำตอบเทียบกับเป้าหมายเดิม ระบุช่องว่างหรือข้อผิดพลาด และสร้างฉบับแก้ไข เทคนิคนี้เลียนแบบวิธีที่มนุษย์ตรวจทานงานของตนเอง และช่วยปรับปรุงคุณภาพผลลัพธ์ของงานที่ซับซ้อนได้อย่างมากโดยไม่ต้องใช้โมเดลผู้วิจารณ์แยกต่างหาก
วงจรสะท้อนคิดและแก้ไข
วงจรสะท้อนคิดพื้นฐานมีสามขั้นตอน ได้แก่ สร้างคำตอบเบื้องต้น วิจารณ์คำตอบนั้นตามเกณฑ์ที่ชัดเจน และ แก้ไขตามคำวิจารณ์ วงจรนี้ทำซ้ำได้หนึ่งครั้งหรือหลายครั้ง แต่ละรอบจะปรับปรุงคำตอบจนกว่าคำวิจารณ์จะระบุว่าคำตอบน่าพอใจ หรือถึงจำนวนครั้งการแก้ไขสูงสุด ขั้นตอนวิจารณ์เองก็เป็นการเรียกใช้ LLM ด้วยคำสั่งสะท้อนคิดเฉพาะทาง
async def reflect_and_revise(task: str, max_rounds: int = 2) -> str:
response = await generate_initial(task)
for round_num in range(max_rounds):
critique = await critique_response(task, response)
if critique.is_satisfactory:
break
response = await revise_response(task, response, critique.feedback)
return responseการเขียนคำสั่งวิจารณ์ที่มีประสิทธิภาพ
คำสั่งวิจารณ์ต้องระบุเกณฑ์การประเมินที่เป็นรูปธรรม แทนการขอให้โมเดล “ปรับปรุง” คำตอบเฉย ๆ ระบุสิ่งที่ต้องตรวจสอบอย่างเจาะจง เช่น ข้อกล่าวอ้างทุกข้อถูกต้องหรือไม่ คำตอบครอบคลุมทุกส่วนของคำถามหรือไม่ มีขั้นตอนใดขาดหายไปหรือไม่ มีข้อความส่วนเกินที่ไม่จำเป็นหรือไม่ คำสั่งวิจารณ์ที่มีรายการตรวจสอบชัดเจนจะสร้างข้อเสนอแนะที่นำไปใช้ได้จริง ซึ่งขั้นตอนการแก้ไขสามารถนำไปใช้ได้โดยตรง
CRITIQUE_PROMPT = '''
You are reviewing an AI-generated response to this task: {task}
Response to evaluate:
{response}
Check each criterion and provide specific feedback:
1. COMPLETENESS: Does it address all parts of the task?
2. ACCURACY: Are all factual claims correct?
3. CONCISENESS: Is there unnecessary padding or repetition?
4. FORMAT: Does it match the requested output format?
5. ACTIONABILITY: Can the user act on this response?
For each issue found, state exactly what to fix.
If the response is satisfactory on all criteria, say APPROVE.
'''การแยกวิเคราะห์คำตอบจากการวิจารณ์
จัดโครงสร้างผลลัพธ์ของการวิจารณ์ให้อยู่ในรูปแบบแบบจำลอง Pydantic เพื่อให้คุณตัดสินใจได้ด้วยโปรแกรมว่าควรแก้ไขหรือไม่ ช่อง is_satisfactory จะกำหนดว่าจะออกจากลูปหรือไม่ รายการ issues จะระบุให้ขั้นตอนการแก้ไขทราบอย่างชัดเจนว่าต้องแก้ไขอะไร ส่วนช่อง severity ช่วยให้คุณข้ามการแก้ไขปัญหาด้านรูปแบบเล็กน้อยได้ แต่ยังคงแก้ไขข้อผิดพลาดด้านข้อเท็จจริงเสมอ
from pydantic import BaseModel
from typing import List, Literal
class Issue(BaseModel):
criterion: str
description: str
severity: Literal['critical', 'moderate', 'minor']
class Critique(BaseModel):
is_satisfactory: bool
issues: List[Issue]
overall_verdict: str
# is_satisfactory=True means no revision needed
# is_satisfactory=False means issues must be addressedพรอมต์การแก้ไข
พรอมต์การแก้ไขจะได้รับงานเดิม คำตอบเริ่มต้น และข้อเสนอแนะจากการวิจารณ์ ขอให้แบบจำลองสร้างฉบับปรับปรุงที่จัดการกับแต่ละประเด็นที่การวิจารณ์ระบุไว้อย่างเจาะจง พร้อมทั้งคงส่วนที่ถูกต้องของคำตอบเดิมไว้ ให้ใส่คำว่า 'only' เสมอ เพื่อป้องกันไม่ให้แบบจำลองเปลี่ยนแปลงสิ่งที่การวิจารณ์อนุมัติแล้วโดยไม่จำเป็น
def build_revision_prompt(task: str, response: str, critique: Critique) -> str:
issues_text = '\n'.join(
f'- [{i.severity.upper()}] {i.criterion}: {i.description}'
for i in critique.issues
)
return f'''
Original task: {task}
Your previous response:
{response}
Issues to fix:
{issues_text}
Write an improved response that fixes ONLY the issues listed above.
Do not change parts that were not flagged as problems.
'''การแก้ไขตนเองสำหรับการสร้างโค้ด
การแก้ไขตนเองมีประสิทธิภาพเป็นพิเศษสำหรับการสร้างโค้ด หลังจากสร้างโค้ดแล้ว ให้เรียกใช้เครื่องมือตรวจสอบรูปแบบโค้ดหรือตัวตรวจสอบชนิดข้อมูลกับโค้ดนั้น ส่งผลลัพธ์ข้อผิดพลาดกลับไปให้แบบจำลอง แล้วขอให้แบบจำลองแก้ไขข้อผิดพลาดเหล่านั้น การ ไตร่ตรองโดยอิงผลการทำงานจริง นี้น่าเชื่อถือกว่าการวิจารณ์จากภาษาเพียงอย่างเดียว เพราะข้อเสนอแนะมาจากเครื่องมือที่เป็นกลาง ไม่ใช่การตัดสินของ LLM อีกตัวหนึ่ง
import subprocess
import sys
async def self_correct_code(task: str, max_rounds: int = 3) -> str:
code = await generate_code(task)
for _ in range(max_rounds):
# Write code to temp file and run mypy
with open('/tmp/agent_code.py', 'w') as f:
f.write(code)
result = subprocess.run(
[sys.executable, '-m', 'mypy', '/tmp/agent_code.py', '--ignore-missing-imports'],
capture_output=True, text=True
)
if result.returncode == 0:
break # No type errors
code = await fix_code(code, result.stdout + result.stderr)
return codeการหลีกเลี่ยงการแก้ไขเกินจำเป็น
ความล้มเหลวที่พบบ่อยในระบบไตร่ตรองคือ การแก้ไขเกินจำเป็น ซึ่งเกิดขึ้นเมื่อแบบจำลองทำให้ปัญหาเดิมแย่ลงขณะพยายามแก้ไขอีกเรื่องหนึ่ง ให้ลดปัญหานี้โดยจำกัดขอบเขตการแก้ไข พรอมต์การแก้ไขควรระบุอย่างชัดเจนว่า 'do not change anything that was not flagged.' นอกจากนี้ ให้เปรียบเทียบคำตอบที่แก้ไขแล้วกับคำตอบเดิมโดยใช้การตรวจสอบความแตกต่าง หากฉบับแก้ไขแตกต่างจากเดิมอย่างมาก แสดงว่าอาจเกิดข้อผิดพลาด และคุณควรเก็บคำตอบเดิมไว้
from difflib import SequenceMatcher
def safe_revision(original: str, revised: str, max_change_ratio: float = 0.7) -> str:
similarity = SequenceMatcher(None, original, revised).ratio()
if similarity < (1 - max_change_ratio):
print(f'Revision changed too much (similarity: {similarity:.2f}). Keeping original.')
return original
return revisedการไตร่ตรองในงานของเอเจนต์หลายขั้นตอน
ในเอเจนต์หลายขั้นตอน ให้เพิ่ม จุดตรวจสอบการไตร่ตรอง หลังจากทำชุดขั้นตอนหนึ่งเสร็จสิ้น เช่น หลังจากรวบรวมข้อมูลวิจัยทั้งหมดแล้วแต่ก่อนเขียนรายงานฉบับสุดท้าย เอเจนต์จะตรวจสอบสิ่งที่รวบรวมมา ระบุช่องว่างของข้อมูล และตัดสินใจว่าจะรวบรวมข้อมูลเพิ่มเติมหรือดำเนินการต่อ การไตร่ตรองระหว่างงานนี้ช่วยป้องกันไม่ให้เอเจนต์เข้าสู่ขั้นตอนการสังเคราะห์ด้วยหลักฐานที่ไม่ครบถ้วนหรือขัดแย้งกัน
async def research_with_reflection(question: str) -> str:
# Phase 1: gather evidence
evidence = await gather_evidence(question)
# Reflection checkpoint
assessment = await assess_evidence_completeness(question, evidence)
if not assessment.is_complete:
for gap in assessment.gaps:
more_evidence = await targeted_search(gap.search_query)
evidence.extend(more_evidence)
# Phase 2: synthesize
return await synthesize_answer(question, evidence)การบันทึกผลลัพธ์ของการไตร่ตรอง
บันทึกรอบการไตร่ตรองทุกครั้ง ได้แก่ คะแนนการวิจารณ์ ประเด็นที่ตรวจพบ และการแก้ไขจัดการกับประเด็นเหล่านั้นได้จริงหรือไม่ ข้อมูลนี้จะแสดงให้เห็นว่าพรอมต์การไตร่ตรองของคุณมีประสิทธิภาพเพียงใด หากคำตอบที่แก้ไขแล้วนำประเด็นเดิมที่การวิจารณ์ระบุไว้กลับมาอย่างสม่ำเสมอ แสดงว่าพรอมต์การแก้ไขของคุณยังไม่เฉพาะเจาะจงเพียงพอ หากการวิจารณ์ส่วนใหญ่ระบุว่า 'APPROVE' ตั้งแต่รอบแรก แสดงว่าคุณภาพการสร้างคำตอบเริ่มต้นสูงอยู่แล้ว และต้นทุนเพิ่มเติมจากการไตร่ตรองอาจไม่คุ้มค่า
import structlog
log = structlog.get_logger()
def log_reflection_round(task_id: str, round_num: int, critique: Critique, action: str):
log.info(
'reflection_round',
task_id=task_id,
round=round_num,
is_satisfactory=critique.is_satisfactory,
issue_count=len(critique.issues),
critical_issues=sum(1 for i in critique.issues if i.severity == 'critical'),
action=action # 'approved', 'revised', 'max_rounds_reached'
)เมื่อใดควรใช้การไตร่ตรอง
การไตร่ตรองเพิ่มเวลาแฝงและต้นทุน การไตร่ตรองและแก้ไขสองรอบจะทำให้จำนวนครั้งที่เรียกใช้ LLM สำหรับงานนั้นเพิ่มขึ้นอย่างน้อยสามเท่า ใช้การไตร่ตรองอย่างเลือกสรร ได้แก่ ใช้เสมอสำหรับผลลัพธ์ที่มีความสำคัญสูง เช่น โค้ดที่จะนำไปทำงานจริงหรือคำตอบของคำถามทางธุรกิจที่มีผลกระทบ ใช้ได้ตามความเหมาะสมสำหรับคำตอบที่ผู้ใช้เห็น และไม่ควรใช้กับขั้นตอนภายในชั่วคราวที่เครื่องมือจะตรวจสอบทันที ต้นทุนนี้คุ้มค่าเมื่อคุณภาพสำคัญกว่าความเร็ว
# Reflection decision matrix:
# Task type: Use reflection?
# SQL query generation YES (run+verify)
# Final report writing YES (review before delivery)
# Tool argument prep NO (tool result verifies it)
# Short factual answer MAYBE (if accuracy is critical)
# Internal agent thought NO (intermediate, not final)
# Code generation YES (run linter/tests)
USE_REFLECTION = {'report', 'code', 'email', 'analysis'}การวัดประสิทธิผลของการไตร่ตรอง
ตรวจสอบว่าการไตร่ตรองช่วยปรับปรุงผลลัพธ์ของคุณจริงหรือไม่ด้วยการทดสอบ A/B โดยประมวลผลงานครึ่งหนึ่งที่สุ่มเลือกด้วยการไตร่ตรอง และอีกครึ่งหนึ่งโดยไม่ใช้ จากนั้นให้ผู้ตัดสินที่เป็น LLM ประเมินทั้งสองกลุ่ม หากกลุ่มที่ใช้การไตร่ตรองได้คะแนนสูงกว่าอย่างมีนัยสำคัญ และการปรับปรุงนั้นมากกว่าค่าเวลาแฝงและต้นทุนที่เพิ่มขึ้น แสดงว่าการไตร่ตรองให้ผลคุ้มค่า หากคะแนนใกล้เคียงกัน แสดงว่าคุณภาพการสร้างคำตอบเริ่มต้นสูงเพียงพอแล้ว และการไตร่ตรองกำลังเพิ่มภาระโดยไม่ก่อประโยชน์
async def reflection_ab_test(tasks: list) -> dict:
import random
results = {'with_reflection': [], 'without_reflection': []}
for task in tasks:
if random.random() < 0.5:
response = await reflect_and_revise(task, max_rounds=2)
group = 'with_reflection'
else:
response = await generate_initial(task)
group = 'without_reflection'
score = await judge(task, response)
results[group].append(score.overall)
return {
'mean_with': sum(results['with_reflection']) / len(results['with_reflection']),
'mean_without': sum(results['without_reflection']) / len(results['without_reflection'])
}ตรวจสอบความเข้าใจ
ทดสอบความเข้าใจของคุณเกี่ยวกับการแก้ไขตนเองและพรอมต์แบบไตร่ตรองในเอเจนต์
สรุปบทเรียน
ในบทเรียนนี้ คุณได้เรียนรู้ว่า ลูปไตร่ตรองและแก้ไขช่วยปรับปรุงคุณภาพผลลัพธ์ โดยให้เอเจนต์วิจารณ์และแก้ไขคำตอบของตนเอง เกณฑ์การวิจารณ์ที่เป็นรูปธรรมช่วยสร้างข้อเสนอแนะที่นำไปดำเนินการได้ แทนคำแนะนำกว้าง ๆ ที่ไม่ชัดเจน และ การไตร่ตรองโดยอิงผลการทำงานจริงด้วยเครื่องมือที่เป็นกลาง เช่น เครื่องมือตรวจสอบรูปแบบโค้ด มีประสิทธิภาพเป็นพิเศษสำหรับการสร้างโค้ด บทถัดไป เราจะลงมือสร้างจุดตรวจสอบของเอเจนต์และการดำเนินงานต่อจากเดิม
เรียนรู้ Python ด้วย AI tutor — ฟรี
เขียนและเรียกใช้โค้ดจริงในเบราว์เซอร์ของคุณ รับความช่วยเหลือทันทีจาก AI tutor 24/7 และเรียนรู้ต่อจากที่คุณหยุดบนเว็บหรือในแอป
- คอร์ส
- 30
- บทเรียน
- 120
คำถามที่พบบ่อย
บทเรียน “การแก้ไขตนเองและการเขียนพรอมต์แบบไตร่ตรอง” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “การแก้ไขตนเองและการเขียนพรอมต์แบบไตร่ตรอง” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส AI Engineering Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส AI Engineering Academy มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “การแก้ไขตนเองและการเขียนพรอมต์แบบไตร่ตรอง”
นำขั้นตอนการไตร่ตรองมาใช้ โดยให้เอเจนต์ตรวจทานผลลัพธ์ของตนเทียบกับเป้าหมายเดิม ระบุส่วนที่ขาดหายหรือข้อผิดพลาด และสร้างแผนที่แก้ไขแล้วก่อนลองใหม่ คุณปฏิบัติ AI Engineering Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน AI Engineering Academy หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน AI Engineering Academy บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน
บทเรียน “การแก้ไขตนเองและการเขียนพรอมต์แบบไตร่ตรอง” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน AI Engineering Academy นี้ได้ไหม
ได้ บทเรียน AI Engineering Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- การจำแนกรูปแบบความล้มเหลวของเอเจนต์
- การแก้ไขตนเองและการเขียนพรอมต์แบบไตร่ตรอง
- การสร้างจุดตรวจสอบและดำเนินงานต่อ
- การส่งต่อให้มนุษย์มีส่วนร่วม