Prompt ที่ดีช่วยให้ model เข้าใจงานได้ชัดขึ้น แต่ prompt ไม่ได้เป็น workflow ทั้งหมด เปรียบเทียบง่าย ๆ คือ prompt คล้ายคำสั่งให้ผู้ปฏิบัติงาน ส่วน workflow คือการออกแบบว่าใครมีข้อมูลอะไร ใช้เครื่องมือไหน ตรวจผลตรงไหน และต้องทำอย่างไรเมื่อขั้นตอนหนึ่งล้มเหลว

การพูดว่า “เพิ่มรายละเอียดใน prompt” จึงแก้ได้เฉพาะปัญหาบางชนิด ถ้าระบบส่ง context ผิด หรือ tool คืนข้อมูลเก่า prompt ที่เขียนสวยขึ้นก็ไม่ได้ทำให้หลักฐานถูกต้องขึ้น

Prompt เป็นเพียงชั้นหนึ่งของ workflow

Prompt อยู่ในเส้นทางที่ต้องจัดการ context, state, tools, validation, retry และ evaluation ร่วมกัน

สิ่งที่อยู่รอบ prompt

workflow ที่ใช้งานจริงมักมีส่วนประกอบอย่างน้อยดังนี้:

  • context: ข้อมูลที่ให้ model และเหตุผลว่าทำไมจึงเลือกข้อมูลนั้น
  • tools: API หรือฟังก์ชันที่มี input/output และ permission ชัดเจน
  • state: สิ่งที่เกิดขึ้นแล้วและสิ่งที่ยังต้องทำ
  • validation: ข้อกำหนดที่ตรวจด้วย code ได้
  • retries: เงื่อนไขที่ควรลองใหม่และเงื่อนไขที่ควรหยุด
  • evaluation: วิธีวัดผลจากตัวอย่างจริง ไม่ใช่ดูคำตอบตัวอย่างเดียว
  • orchestration: ลำดับและเงื่อนไขที่เชื่อมทุกส่วนเข้าด้วยกัน

การคิดแบบนี้ช่วยแยก probabilistic step ออกจาก deterministic step ได้ชัดขึ้น เช่น model อาจช่วยแปลงคำถามเป็น search query แต่การตรวจว่า user มีสิทธิ์อ่าน document หรือไม่ควรเป็น code ที่คาดเดาได้

Prompt ไม่ควรเป็นที่เก็บกฎทั้งหมด

ถ้า prompt ยาวขึ้นทุกครั้งที่พบ bug เราอาจกำลังย้าย business rule ไปอยู่ในที่ที่ตรวจสอบยากขึ้น กฎที่มีผลต่อความปลอดภัยหรือความถูกต้องควรอยู่ใน boundary ที่ระบบทดสอบได้ เช่น:

const query = await model.createSearchQuery(question);
const results = await search(query);
const allowed = results.filter((item) => canRead(user, item));

if (allowed.length === 0) {
  return { status: 'needs-more-evidence' };
}

const answer = await model.answer({ question, context: allowed });
return validateAnswer(answer, allowed);

ในตัวอย่างนี้ model ยังมีบทบาท แต่ไม่สามารถข้าม permission gate หรือเปลี่ยนผลลัพธ์ว่างให้กลายเป็นหลักฐานได้

Retry ไม่ใช่การลองซ้ำแบบไม่จำกัด

บาง error ควร retry เช่น network timeout ชั่วคราว แต่บาง error ไม่ควร retry เช่น schema ไม่ผ่าน, permission denied หรือ context ว่าง การ retry ทุกอย่างเพิ่ม latency และอาจสร้าง side effect ซ้ำถ้า tool ทำงานแบบเขียนข้อมูล

ก่อน retry ควรระบุว่า operation นี้ idempotent หรือไม่ มี retry budget เท่าไร และเมื่อไรต้องส่งต่อให้คน การบันทึก attempt แต่ละครั้งยังช่วยให้เรารู้ว่า latency สูงเพราะ model หรือเพราะระบบกำลังลองซ้ำ

Evaluation ต้องวัด workflow

ถ้าวัดแค่คำตอบสุดท้าย เราอาจไม่เห็นว่า retrieval หยิบ source ผิด หรือ validation ไม่ได้ทำงาน ชุดประเมินที่ดีควรมี expected evidence, expected action และ expected refusal ด้วย

ตัวอย่างคำถามหนึ่งอาจต้องตรวจว่า:

  1. ระบบค้นเอกสารที่มี effective_at ล่าสุด
  2. ระบบไม่ส่งเอกสารข้าม permission boundary
  3. คำตอบอ้าง source ที่ค้นพบจริง
  4. เมื่อ source ขัดแย้ง ระบบระบุความไม่แน่นอน

นี่ทำให้ evaluation เป็นการทดสอบ workflow ไม่ใช่การให้คะแนนสำนวนเพียงอย่างเดียว

สรุป

prompt engineering กับ AI engineering ไม่ใช่คู่แข่ง Prompt ที่ดีเป็นเครื่องมือสำคัญ แต่ AI Engineer ต้องออกแบบระบบที่ทำให้ prompt ได้ context ที่ถูก มีเครื่องมือที่จำกัดสิทธิ์ และมีทางออกเมื่อความมั่นใจหรือหลักฐานไม่พอ

สิ่งที่ควรจำมีสามข้อ:

  1. prompt เป็น component หนึ่งของ workflow ไม่ใช่ workflow ทั้งหมด
  2. กฎที่ deterministic และมีผลต่อความปลอดภัยควรตรวจด้วย code
  3. evaluation ควรตรวจเส้นทาง ข้อมูล หลักฐาน และการปฏิเสธเมื่อไม่ควรตอบ

References

  • OpenAI — Prompt engineering: แนวทางทำให้ instructions ชัดและตรวจผลลัพธ์ได้ง่ายขึ้น
  • Anthropic — Building effective agents (2024): แยก workflow ที่กำหนดเส้นทางไว้จาก agent ที่เลือกวิธีทำงานระหว่างทาง
  • OpenAI — A practical guide to building agents: อธิบาย tools, orchestration และ guardrails ในระบบที่ให้ model ควบคุม workflow
  • LangChain — Evaluation concepts: ตัวอย่างกรอบคิดเรื่อง evaluation ของ application และ workflow ไม่ใช่แค่ข้อความสุดท้าย