Prompt chaining

Prompt chaining คือการตัดงานใหญ่หนึ่งชิ้นออกเป็นคำสั่งย่อยหลายขั้นที่ต่อกันเป็นทอด แทนที่จะยัดทุกอย่างลงใน prompt เดียวแล้วหวังให้โมเดลทำครบในครั้งเดียว บทความวิศวกรรมของ Anthropic ชื่อ Building effective agents อธิบายรูปแบบนี้ไว้ว่า prompt chaining ย่อยงานหนึ่งงานออกเป็นลำดับขั้น โดยการเรียก LLM แต่ละครั้งจะประมวลผลผลลัพธ์ที่ออกมาจากการเรียกครั้งก่อนหน้า เอกสาร prompting strategies ของ Google สำหรับ Gemini API เขียนหลักเดียวกันไว้ในหัวข้อการแตก prompt ออกเป็นส่วนประกอบว่า สำหรับงานซับซ้อนที่มีหลายขั้นตอนเรียงต่อกัน ให้ทำแต่ละขั้นเป็นหนึ่ง prompt แล้วร้อย prompt เหล่านั้นต่อกันเป็นลำดับ และในลำดับแบบนี้ ผลลัพธ์ของ prompt หนึ่งจะกลายเป็น input ของ prompt ถัดไป

จุดที่ทำให้ chaining ต่างจากการสั่งรวดเดียวคือช่องว่างระหว่างขั้น ซึ่งเป็นที่ที่เราแทรกการตรวจลงไปได้ บทความของ Anthropic ระบุว่าเราเลือกเพิ่มการตรวจด้วยโค้ด ซึ่งบทความเรียกว่า gate ในแผนภาพ ไว้ที่ขั้นกลางขั้นไหนก็ได้ เพื่อให้มั่นใจว่ากระบวนการยังเดินอยู่บนราง ด่านตรงนี้เป็นได้ตั้งแต่เงื่อนไขง่ายๆ อย่างเช็กว่าผลลัพธ์ออกมาเป็น structured-output ที่อ่านต่อได้จริงไหม ไปจนถึงการหยุดรอให้คนดูก่อนปล่อยผ่านแบบ human-in-the-loop เอกสาร prompting best practices ของ Claude เขียนถึงเหตุผลที่ยังต้องใช้ chaining แบบชัดแจ้งไว้ว่า ด้วย adaptive thinking กับการสั่งการ subagent โมเดล Claude รุ่นล่าสุดจัดการการให้เหตุผลหลายขั้นได้เองเป็นส่วนใหญ่อยู่แล้ว แต่การทำ prompt chaining แบบชัดแจ้ง ซึ่งก็คือการแตกงานออกเป็นการเรียก API ทีละขั้น ยังมีประโยชน์อยู่เมื่อเราต้องการตรวจดูผลลัพธ์ระหว่างทาง หรือต้องการบังคับโครงสร้าง pipeline แบบเจาะจง เอกสารหน้าเดียวกันเขียนว่ารูปแบบการต่อขั้นที่พบบ่อยที่สุดคือ self-correction ซึ่งไล่จากสร้างร่าง → ให้โมเดลตรวจร่างนั้นเทียบกับเกณฑ์ → ให้โมเดลขัดเกลาตามผลตรวจ และกำกับไว้ว่าแต่ละขั้นเป็นการเรียก API แยกกันคนละครั้ง เราจึงเก็บ log ประเมินผล หรือแตกทางเดินที่จุดไหนก็ได้ เอกสารของ Google ยังแยกอีกสองรูปแบบไว้ในหัวข้อเดียวกันนี้ อันแรกคือการแตกคำสั่ง ซึ่งเขียนว่าแทนที่จะมีคำสั่งหลายข้อใน prompt เดียว ให้สร้าง prompt หนึ่งอันต่อหนึ่งคำสั่ง แล้วเลือกได้ว่าจะประมวลผล prompt อันไหนโดยดูจาก input ของผู้ใช้ อันที่สองคือการรวมผลลัพธ์ ซึ่งเขียนว่า aggregation คือตอนที่เราอยากทำงานหลายอย่างแบบขนานบนข้อมูลคนละส่วน แล้วรวมผลเข้าด้วยกันเพื่อให้ได้ผลลัพธ์สุดท้าย

สำหรับคนที่ทำ workflow-automation ในงานเอกสาร ประโยชน์ของ chaining จะเห็นชัดตอนที่งานหนึ่งชิ้นมีหลายด่านที่ตรวจได้คนละแบบ เช่น อ่านไฟล์สัญญาแล้วดึงตัวเลขออกมา ตรวจว่าตัวเลขที่ดึงมาครบตามฟอร์ม แล้วค่อยเอาไปเขียนสรุปส่งต่อ ตัวอย่างที่บทความของ Anthropic ยกไว้ก็อยู่ในแนวเดียวกัน คือการสร้าง marketing copy แล้วแปลเป็นอีกภาษาหนึ่งแบบที่หน้า machine-translation พูดถึง กับการเขียน outline ของเอกสาร ตรวจว่า outline นั้นเข้าเกณฑ์ที่กำหนด แล้วจึงเขียนเอกสารจริงจาก outline นั้น รูปทรงแบบนี้จะคุ้นตาคนที่ต่อ flow ด้วยเครื่องมืออย่าง n8n อยู่แล้ว ส่วนข้อแลกเปลี่ยนนั้นบทความของ Anthropic เขียนไว้ตรงๆ ว่า workflow แบบนี้เหมาะอย่างยิ่งกับสถานการณ์ที่งานถูกแตกออกเป็น subtask ตายตัวได้ง่ายและสะอาด และเป้าหมายหลักคือการแลก latency เพื่อให้ได้ความแม่นยำที่สูงขึ้น ด้วยการทำให้การเรียก LLM แต่ละครั้งเป็นงานที่ง่ายลง อ่านกลับด้านก็คือ ถ้างานของเราแตกขั้นไม่ลงตัว การฝืนตัดเป็นทอดจะได้ความช้ามาโดยไม่ได้ความแม่นกลับไป ข้อควรระวังอีกข้อเป็นผลที่ตามมาจากตัวโครงสร้างเอง เอกสารของ Google ระบุไว้แค่ว่าผลลัพธ์ของ prompt หนึ่งจะกลายเป็น input ของ prompt ถัดไป ซึ่งแปลว่าความผิดพลาดที่รอดด่านแรกไปได้ก็ถูกส่งต่อเข้าไปในขั้นถัดไปด้วยเช่นกัน ขั้นปลายจึงเขียนสรุปออกมาสวยงามบนข้อมูลที่ผิดมาตั้งแต่ขั้นต้นได้หน้าตาเฉย นี่คือเหตุผลที่ด่านตรวจระหว่างขั้นสำคัญ และเป็นจุดที่คนตรวจงานควรระวัง automation-bias ไว้ด้วย เพราะผลลัพธ์ที่ผ่านหลายขั้นมาแล้วมักดูน่าเชื่อกว่าที่ควรจะเป็น

ตัวอย่างจากบทสนทนาจริง

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

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

หัวหน้าฝ่ายจัดซื้อ: แล้วแบบนั้นมันช้าลงไหมครับ ตอนนี้ก็รอผลอยู่พักหนึ่งแล้ว

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

ระวังสับสนกับ

• chain-of-thought : chain-of-thought คือการให้โมเดลไล่ความคิดเป็นขั้นอยู่ภายในคำตอบเดียว การเรียกยังเกิดครั้งเดียว เราจึงแทรกการตรวจด้วยโค้ดคั่นระหว่างขั้นไม่ได้ ส่วน prompt chaining คือคำสั่งหลายอันที่แยกกันจริงและส่งผลต่อกัน เอกสารของ Claude เขียนไว้ว่าแต่ละขั้นเป็นการเรียก API แยกกัน เราจึงเก็บ log ประเมินผล หรือแตกทางเดินที่จุดไหนก็ได้ ชื่อสองคำนี้คล้ายกันเพราะมีคำว่า chain เหมือนกัน แต่คนละระดับกัน
• agent : บทความของ Anthropic แยกสองอย่างนี้ไว้ว่า workflow คือระบบที่ LLM กับ tool ถูกจัดวางผ่านเส้นทางโค้ดที่กำหนดไว้ล่วงหน้า ส่วน agent คือระบบที่ LLM กำกับกระบวนการและการใช้ tool ของตัวเองแบบไดนามิก โดยคุมไว้เองว่าจะทำงานให้สำเร็จอย่างไร prompt chaining อยู่ฝั่งแรก คนวางเส้นทางไว้ล่วงหน้าว่าขั้นไหนมาก่อนหลัง ส่วน agent เลือกลำดับขั้นเอง
• agent-orchestration : เรื่องนี้ว่าด้วยการจัดคิวและประสาน agent หลายตัวให้ทำงานร่วมกัน หน่วยที่ถูกจัดคือ agent ทั้งตัว ส่วน chaining หน่วยที่ถูกร้อยเข้าด้วยกันคือ prompt แต่ละอันในเส้นทางที่คนกำหนดไว้แล้ว
• subagent : การมอบงานให้ subagent คือการโยนงานหนึ่งก้อนไปให้ผู้ช่วยอีกตัวที่มีบริบทของตัวเอง เอกสารของ Claude เขียนว่าโมเดลรุ่นล่าสุดสั่งการ subagent ได้เองโดยธรรมชาติ และมองออกได้ว่างานแบบไหนจะดีขึ้นถ้ามอบให้ subagent เฉพาะทาง แล้วลงมือทำเองโดยไม่ต้องสั่งชัดแจ้ง เอกสารหน้าเดียวกันเตือนไว้ด้วยว่าให้ระวังการใช้เกินจำเป็น เพราะบางรุ่นชอบแตก subagent ในงานที่ทำตรงๆ ทีเดียวก็จบเร็วกว่า จุดต่างจึงอยู่ที่ว่าใครเป็นคนตัดสินใจเรื่องลำดับ ใน chaining คือคนที่วาง flow ไว้