เวลาจะนำ AI มาใส่ใน workflow สิ่งที่เห็นง่ายมักเป็นช่วงที่โมเดลอ่านคำขอแล้วเขียนคำตอบกลับได้เหมือนคน แต่ในงานหนึ่งยังมีขั้นอื่นอยู่รอบๆ เช่น ตรวจว่าข้อมูลครบ หารหัสรายการ ตัดสินสิทธิ์ และบันทึกผลลงระบบ ส่วนเหล่านี้ไม่ได้ต้องการความยืดหยุ่นแบบเดียวกันทั้งหมด
ถ้านำทุกขั้นไปรวมเป็นคำสั่งเดียวให้โมเดลจัดการ เราอาจได้ต้นแบบเร็วขึ้น แต่เวลาเกิดผลต่างจากที่คาดก็จะตามยากว่าผิดจากการตีความภาษา ข้อมูลต้นทาง หรือกติกาที่ควรถูกบังคับแน่นอนตั้งแต่ต้น
ก่อนเลือกว่าจะทำเป็น agent หรือ pipeline แบบใด จึงควรแยกงานย่อยตามสิ่งที่มันต้องตัดสินก่อนครับ แล้วเลือกวิธีที่ช่วยรักษาขอบเขตและตรวจผลของแต่ละช่วงได้
สมมติว่ารับไฟล์ข้อมูลที่กำหนดชื่อคอลัมน์ ชนิดค่าและรายการที่ยอมรับไว้แล้ว การตรวจว่ามีคอลัมน์ครบหรือวันที่อยู่ในรูปแบบที่กำหนดสามารถทำด้วยกติกาในโปรแกรมได้ โดยไม่จำเป็นต้องให้โมเดลตัดสินใหม่ทุกไฟล์
ข้อดีคือเราระบุได้ว่าเงื่อนไขใดทำให้ผ่านหรือไม่ผ่าน และนำชุดข้อมูลเดิมมาตรวจซ้ำตามกติกาเดียวกันได้ แต่ก็ต้องเขียนกติกาให้ตรงความหมายจริง เช่น วันที่ที่อ่านเป็นตัวเลขได้ยังอาจผิดช่วงของงาน การใช้ rule ไม่ได้ทำให้ข้อกำหนดที่ขาดอยู่ครบเอง
จึงควรเริ่มจากสัญญาของ input และผลที่ต้องการก่อน ถ้าปัญหาคือคนยังตกลงนิยามไม่ตรงกัน การย้ายให้ AI ตัดสินอาจเพียงซ่อนความไม่ชัดนั้นไว้ในคำตอบที่อ่านลื่นขึ้น โดยยังไม่มีเกณฑ์ตรวจที่ทีมยอมรับร่วมกัน
อีกกลุ่มหนึ่งมีความหลากหลายของภาษา เช่น คนอธิบายอาการอุปกรณ์ด้วยถ้อยคำต่างกัน แล้วต้องการช่วยจัดหมวดหรือสกัดข้อมูลที่เขาระบุไว้ โมเดลอาจช่วยจัดรูปสิ่งที่ไม่อยู่ในแบบฟอร์มเดียวกันให้ไปใช้ต่อได้
แต่ควรบอกว่าต้องการให้สกัดสิ่งที่มีจริงหรือให้เสนอความเป็นไปได้ด้วย สองงานนี้ไม่เหมือนกัน หากช่องข้อมูลจำเป็นไม่ได้อยู่ในคำขอ ผลที่เหมาะสมอาจเป็นสถานะข้อมูลไม่พอและคำถามเพิ่ม ไม่ใช่เติมค่าที่ดูเข้ากันเพื่อให้โครงสร้างครบ
กรณีจัดหมวดก็ควรมีทางรองรับสิ่งที่อยู่นอกกลุ่มหรือยังตัดสินไม่ได้ ไม่บังคับให้เลือกหมวดที่ผิดเพียงเพราะ schema ยอมรับเฉพาะชื่อที่เตรียมไว้ ความเป็นระเบียบของ output จึงต้องมาพร้อมความหมายของกรณีไม่แน่ใจด้วย
ในแนวแบ่งของ Anthropic workflow ใช้เส้นทางที่กำหนดไว้ในโค้ดในการประสานโมเดลกับเครื่องมือ ส่วน agent ให้โมเดลมีบทบาทเลือกขั้นตอนและเครื่องมือระหว่างทำงานมากขึ้น เป็นนิยามที่ช่วยคุยเรื่องการควบคุมได้ โดยไม่ต้องถือว่าทุกสำนักใช้คำเหมือนกันทั้งหมด
งานที่รู้ลำดับอยู่แล้ว เช่น รับข้อความ สกัดข้อมูล ตรวจความครบ แล้วสร้างร่างให้ตรวจ อาจจัดเป็นเส้นทางที่มีจุดตัดสินชัดได้ ส่วนงานสำรวจที่ยังไม่รู้ว่าต้องอ่านแหล่งใดต่อ อาจต้องเปิดทางให้เลือกค้นเพิ่มตามหลักฐานที่พบ
การเปิดทางเลือกมากขึ้นก็เพิ่มสิ่งที่ต้องตาม ทั้งจำนวนขั้น เครื่องมือที่เลือกและเงื่อนไขหยุด จึงควรถามว่าความยืดหยุ่นนั้นช่วยแก้ความไม่แน่นอนส่วนใดของงาน ไม่เลือก agent เพียงเพราะชื่อดูเหมาะกับยุค AI มากกว่า
หลังโมเดลจัดข้อมูลมาแล้ว โปรแกรมควรตรวจชนิดค่า รายการที่ยอมรับและความสัมพันธ์ตามงานก่อนส่งต่อ เช่น รหัสอุปกรณ์ต้องมีอยู่จริงในขอบเขตที่ผู้ใช้มีสิทธิ์ ไม่เชื่อชื่อหรือรหัสที่โมเดลสร้างมาเพียงเพราะอยู่ใน JSON ที่ parse ผ่าน
สิทธิ์กับเงื่อนไขของการเปลี่ยนสถานะก็ควรบังคับที่บริการตามกติกาเดิม โมเดลอาจช่วยแปลความตั้งใจเป็นคำขอ แต่ไม่ควรมีสิทธิ์ข้ามเงื่อนไขเพราะอธิบายเหตุผลได้น่าเชื่อ หรือเพราะข้อความต้นทางอ้างว่าได้รับอนุมัติแล้ว
ถ้ามีขั้นให้คนตรวจ ควรแสดงข้อมูลที่ใช้ตัดสินและผลที่กำลังจะสร้างให้เพียงพอ ไม่ให้คนกดรับรองข้อความสั้นๆ โดยยังไม่เห็นว่ามันจะเปลี่ยนรายการใด ปริมาณเท่าไร หรือใช้ข้อมูลจากแหล่งไหน การยืนยันจึงควรมีวัตถุที่ตรวจได้ตามระดับผลกระทบของงาน
Workflow ควรแยกผลที่ถูกปฏิเสธเพราะข้อมูลไม่ครบ ออกจากปัญหาเครื่องมือหรือการเชื่อมต่อ เพราะวิธีทำต่อแตกต่างกัน การ retry ไม่ช่วยให้ข้อมูลที่คนยังไม่เคยให้ปรากฏขึ้น และการถามคนใหม่ทุกครั้งก็อาจไม่ช่วยตอนบริการปลายทางล่ม
สำหรับเส้นทางที่ให้โมเดลค้นหรือเรียกเครื่องมือต่อ ควรมีขอบเขตจำนวนขั้น เวลาและการใช้ทรัพยากร พร้อมสถานะเมื่อถึงขอบเขต ไม่วนเพิ่มคำสั่งจนได้ข้อความที่ดูสำเร็จโดยไม่ตรวจผลจริง และไม่ให้การหยุดเพราะงบหมดถูกแสดงเป็นงานสำเร็จ
คะแนนความมั่นใจที่โมเดลบอกเองก็ไม่ควรถูกใช้เป็นหลักประกันโดยไม่มีการตรวจรองรับ หากต้องใช้ตัดเส้นส่งคนตรวจ ควรมีข้อมูลทดสอบที่บอกได้ว่ากติกานั้นแยกงานเสี่ยงได้ตามที่ต้องการจริง ไม่รับตัวเลขในคำตอบมาเป็นความน่าจะเป็นที่ยืนยันแล้ว
กติกาในโปรแกรมเองก็ควรมีรุ่นหรือประวัติการเปลี่ยน เมื่อเจ้าของงานแก้เงื่อนไข เราจะรู้ว่าผลเก่าถูกตัดสินด้วยกติกาชุดไหน ไม่อ้างว่าโมเดลเปลี่ยนพฤติกรรมทั้งที่ส่วนตรวจข้อมูลหรือ config รอบข้างเปลี่ยนไปแล้ว
ชุดตรวจควรมีทั้งงานตรงกติกา ภาษาที่เขียนต่างกัน ข้อมูลขาดและกรณีที่ต้องส่งต่อ พร้อมระบุผลที่ยอมรับได้ตามงาน หากมีหลายวิธีไปถึงผลถูก ก็ไม่ควรบังคับว่าต้องเรียกเครื่องมือลำดับเดียวกันทุกครั้งโดยไม่มีเหตุจำเป็น
ควรดูคุณภาพผลปลายทางร่วมกับจำนวนครั้งเรียกเครื่องมือ เวลาและข้อผิดพลาด เพื่อรู้ว่าการเพิ่มความยืดหยุ่นช่วยงานจริงหรือสร้างทางอ้อมมากขึ้น บทนี้ไม่มีผลทดสอบโมเดลหรือตัวเลขต้นทุน จึงไม่ได้รับรองว่าการแยกแบบใดจะประหยัดหรือแม่นกว่ากับทุกข้อมูล
การเลือกใช้ AI ใน workflow ควรเริ่มจากขอบเขตการตัดสินของแต่ละขั้น งานที่มีกติกาชัดใช้โปรแกรมช่วยบังคับได้ ส่วนงานภาษาที่หลากหลายให้โมเดลช่วยตีความภายใต้ผลที่ตรวจต่อได้ เมื่อมีทางรองรับข้อมูลไม่พอ เงื่อนไขหยุดและหลักฐานผลจริง เราจะเพิ่มความยืดหยุ่นเฉพาะส่วนที่ต้องการโดยยังอธิบายกระบวนการทั้งหมดได้