โมเดลภาษาขนาดใหญ่ (LLMs) มักจะสะดุดเมื่อคุณสั่งให้พวกมันทำหลายอย่างพร้อมกันในคราวเดียว ลองโยนไฟล์ PDF หนา 50 หน้าเข้าไปในช่องแชท แล้วสั่งให้ทำทั้งการวิเคราะห์เชิงโครงสร้าง การประเมินความเสี่ยง และการสรุปสำหรับผู้บริหารในคำสั่งเดียว ผลลัพธ์ที่ได้มักจะเบาบาง สับสน หรือผิดพลาดอย่างสิ้นเชิง วิธีการที่ดีกว่าคือการทำแบบเป็นระบบ (mechanical) โดยแบ่งงานออกเป็นขั้นตอนย่อยๆ ส่งผลลัพธ์จากขั้นตอนแรกไปยังขั้นตอนที่สองโดยตรง และทำเช่นนี้ต่อไปเรื่อยๆ Anthropic เรียกรูปแบบนี้ว่า prompt chaining ส่วน Google เรียกว่า sequential pipeline ทั้งสองชื่อนี้อธิบายสิ่งเดียวกัน นั่นคือสายการผลิต (assembly line) ที่แต่ละสถานีจะจัดการการแปลงข้อมูลเฉพาะอย่างหนึ่ง
สิ่งนี้มีลักษณะอย่างไรในทางปฏิบัติ
แทนที่จะใช้ prompt ขนาดใหญ่เพียงอันเดียว คุณจะสร้างชุดขั้นตอนเล็กๆ ที่มุ่งเน้นเฉพาะจุด ลองนึกภาพทีมตรวจสอบการปฏิบัติตามกฎระเบียบ (compliance team) ที่ต้องประมวลผลการประเมินความปลอดภัยของผู้ขาย ขั้นตอนแรกคือการดึงข้อความดิบจาก PDF ที่สแกนมา ขั้นตอนที่สองคือการระบุทุกการกล่าวถึงมาตรฐานการเข้ารหัสและการควบคุมการเข้าถึง ขั้นตอนที่สามคือการนำสิ่งที่พบเหล่านั้นไปเทียบกับรายการตรวจสอบภายใน และขั้นตอนที่สี่คือการร่างบันทึกข้อความสั้นๆ สำหรับหัวหน้าฝ่ายความปลอดภัย เอเจนต์ (agent) ตัวหนึ่งเปลี่ยน PDF เป็นข้อความ เอเจนต์ตัวถัดไปดึงข้อมูลเฉพาะจากข้อความนั้น และเอเจนต์ตัวสุดท้ายเขียนสรุปจากข้อมูลดังกล่าว ไม่มีขั้นตอนใดที่ดูหรูหรา และไม่มีขั้นตอนใดที่ทำงานหลายอย่างพร้อมกัน แต่ละส่วนทำหน้าที่เพียงอย่างเดียวให้ดีที่สุด
นี่คือเหตุผลที่การเปรียบเทียบกับสายการผลิตนั้นใช้ได้ผล ในโรงงาน พนักงานคนเดียวไม่ได้ประกอบรถยนต์ทั้งคัน การแบ่งงานเฉพาะทางช่วยรักษาคุณภาพให้สูงและจำกัดรูปแบบความผิดพลาดให้แคบลง ตรรกะเดียวกันนี้ใช้กับโมเดลภาษาเช่นกัน Prompt ที่ขอเพียงแค่การดึงข้อมูลแบบ JSON มีโอกาสที่จะเกิดอาการหลอน (hallucinate) น้อยกว่า Prompt ที่ขอทั้งความเห็นและการจัดรูปแบบในคำสั่งเดียวกัน
สร้าง Gate ไม่ใช่การเดา
จุดที่อ่อนแอที่สุดในสายโซ่ใดๆ คือการส่งต่อข้อมูล (handoff) โมเดลอาจตอบกลับมาเป็นการปฏิเสธอย่างสุภาพ ส่งข้อมูลมาเป็น markdown แทนที่จะเป็น JSON หรือส่งคำตอบมาไม่ครบ หากข้อมูลขยะเหล่านั้นไหลเข้าสู่ขั้นตอนที่สอง สายโซ่ทั้งหมดจะพังทลาย วิธีแก้ไขคือการสร้าง "gate" (ด่านตรวจ)
Gate ไม่ใช่การเรียกใช้โมเดล แต่มันคือโค้ดธรรมดา คุณเขียนสคริปต์สั้นๆ ที่ทำงานระหว่างขั้นตอน มันอาจจะตรวจสอบความยาวของผลลัพธ์เพื่อให้แน่ใจว่าไม่ว่างเปล่า หรืออาจจะรันการตรวจสอบ JSON schema validation เพื่อยืนยันว่า key ต่างๆ ตรงกับสิ่งที่ขั้นตอนที่สามคาดหวัง การตรวจสอบด้วย regex สามารถยืนยันได้ว่ามีที่อยู่อีเมลหรือฟิลด์วันที่อยู่จริงก่อนที่จะมีการสร้าง prompt ถัดไปเสียด้วยซ้ำ สิ่งนี้จะช่วยหยุดข้อผิดพลาดก่อนที่คุณจะเสียเงินไปกับผลลัพธ์ที่ใช้งานไม่ได้ Gate ใช้เวลาประมวลผลเพียงไม่กี่ไมโครวินาที แต่การเรียกใช้ LLM ที่ล้มเหลวในขั้นตอนถัดไปนั้นต้องเสียทั้งโทเคน (tokens) ความหน่วง (latency) และสุขภาพจิตของคุณ
ให้คิดซะว่ามันคือจุดตรวจสอบคุณภาพในโรงงาน คุณไม่จำเป็นต้องใช้ AI มานับจำนวนสินค้า คุณแค่ต้องการไม้บรรทัด
เมื่อไหร่ควรทำ Chaining และเมื่อไหร่ควรหยุด
Prompt chaining ไม่ใช่คำตอบสำหรับทุกปัญหา จงใช้มันเมื่อเนื้องานมีขั้นตอนที่แน่นอนและทำซ้ำได้ เช่น รายงานทางการเงินรายเดือน การตรวจสอบสัญญาที่เป็นมาตรฐาน และกระบวนการวิเคราะห์ log เป็นตัวอย่างที่ดี หากคุณสามารถเขียนขั้นตอนการทำงานเป็นรายการตรวจสอบ (checklist) ได้ คุณก็น่าจะทำ chaining ได้ นอกจากนี้ คุณควรใช้การ chaining เมื่อต้องการความแม่นยำสูงสำหรับงานที่ซับซ้อน การแบ่งปัญหาออกเป็นขั้นตอนจะบังคับให้โมเดลจัดการกับชั้นตรรกะทีละชั้น สุดท้ายแล้ว การทำ chain ยังช่วยให้ debug ได้ง่ายกว่า prompt แบบก้อนเดียว (monolithic prompts) เมื่อบทสรุปผิด คุณก็ไปตรวจสอบการดึงข้อมูล (extraction) เมื่อการดึงข้อมูลผิด คุณก็ไปตรวจสอบข้อความต้นฉบับ คุณมีชิ้นงานระหว่างทาง (intermediate artifacts) ให้ตรวจสอบได้
หลีกเลี่ยง prompt chaining เมื่อคุณไม่ทราบขั้นตอนล่วงหน้า งานวิจัยเชิงสำรวจ การระดมสมองแบบปลายเปิด หรือภารกิจเชิงสืบสวนสอบสวนไม่ได้ดำเนินไปเป็นเส้นตรง และควรข้ามมันไปหากความเร็วคือสิ่งสำคัญที่สุดของคุณ การทำ chain เป็นแบบลำดับ (serial) ขั้นตอนที่สองไม่สามารถเริ่มได้จนกว่าขั้นตอนแรกจะเสร็จสิ้น หากขั้นตอนของคุณไม่ได้ขึ้นต่อกัน ให้รันแบบขนาน (parallel) แทน ไม่มีเหตุผลที่จะต้องทำ chain การแปลเอกสารฉบับเดียวกันสามครั้งที่แยกจากกันโดยสิ้นเชิง
กับดักความตายตัว (The Rigidity Trap)
สิ่งที่ต้องแลกมากับโครงสร้างทั้งหมดนี้คือความตายตัว (rigidity) สายโซ่ที่ถูกกำหนดไว้ตายตัวไม่สามารถปรับตัวเข้ากับสถานการณ์ใหม่ได้ หากผู้ขายส่งแบบฟอร์มที่มีหกฟิลด์มา แต่ gate สำหรับตรวจสอบ schema ของคุณคาดหวังไว้เพียงห้า สายการผลิตก็จะหยุดชะงัก หากผู้ใช้โหลดไฟล์ Word แทนที่จะเป็น PDF ขั้นตอนแรกจะพัง และส่วนที่เหลือของสายโซ่ก็จะไม่มีข้อมูลให้ประมวลผลต่อ
ที่แย่กว่านั้นคือ ข้อผิดพลาดจะแพร่กระจายออกไป ความผิดพลาดที่เกิดขึ้นในช่วงแรกจะไหลผ่านสายโซ่ทั้งหมด หากตัวดึงข้อมูล PDF ตัดเครื่องหมายลบออกจากตัวเลขทางการเงิน ทุกขั้นตอนที่ตามมาจะปฏิบัติกับตัวเลขที่ผิดนั้นเสมือน