สิ่งสำคัญคือต้องพิจารณาอย่างรอบคอบว่าการตัดสินใจในระบบเอเจนต์ของคุณเกิดขึ้นอย่างไรและที่ส่วนใด
การมอบหมายการตัดสินใจให้ LLM มากขึ้นอาจช่วยให้ระบบรองรับงานได้หลากหลายขึ้น แต่ก็อาจต้องแลกกับความเร็ว ความน่าเชื่อถือ และความทนทานของระบบ
หากทำได้ ควรย้ายกระบวนการตัดสินใจออกจาก LLM มาไว้ในโค้ดซอฟต์แวร์ที่ระบุไว้อย่างชัดเจนให้มากที่สุด แนวทางนี้สำคัญอย่างยิ่งสำหรับเวิร์กโฟลว์ที่มีความเสี่ยงสูงและ/หรือใช้งานจริง
เมื่อออกแบบระบบเอเจนต์ที่ใช้ LLM หนึ่งในการตัดสินใจที่สำคัญที่สุดคือ การกำหนดขอบเขตว่ากระบวนการตัดสินใจส่วนใดควรอยู่ในโมเดล LLM และส่วนใดควรอยู่ในซอฟต์แวร์ที่ระบุไว้อย่างชัดเจน
เพื่อให้เข้าใจง่ายขึ้น เราอาจมองตัวเลือกนี้เป็นสเปกตรัมระหว่างแนวทางต่อไปนี้:
สถาปัตยกรรมแบบเราเตอร์กำหนดลำดับและตรรกะไว้ในโค้ดอย่างชัดเจน จึงทดสอบได้ คาดการณ์ได้ และมีความทนทานสำหรับงานเฉพาะทาง (เรียกอีกอย่างว่า “เอเจนต์เวิร์กโฟลว์”)
เอเจนต์ออร์เคสเตรเตอร์อาศัยโมเดลภาษาขนาดใหญ่ (LLM) เพื่อตัดสินใจลำดับงานแบบไดนามิกผ่านพรอมต์ภาษาธรรมชาติ เหมาะกับการโต้ตอบแบบปลายเปิดซึ่งตรรกะที่กำหนดไว้ล่วงหน้าไม่เพียงพอหรือไม่สามารถกำหนดได้
สำหรับเวิร์กโฟลว์ที่มีความเสี่ยงสูงและใช้งานจริง โดยทั่วไปเราแนะนำให้ใช้ความสามารถแบบเราเตอร์มากกว่า และใช้ออร์เคสเตรเตอร์เฉพาะกับแอปพลิเคชันที่ต้องการบทสนทนาอเนกประสงค์และยืดหยุ่น
สถาปัตยกรรมแบบเราเตอร์
ระบบเอเจนต์แบบเราเตอร์:
กำหนดลำดับการตัดสินใจผ่านโค้ดหรือซอฟต์แวร์อย่างชัดเจน และใช้ LLM เพื่อเลือกเส้นทางที่ซอฟต์แวร์จะดำเนินการ
ใกล้เคียงกับระบบซอฟต์แวร์แบบดั้งเดิม เพราะมีเส้นทางการทำงานที่ชัดเจนและคาดการณ์ได้ จึงให้ผลลัพธ์ที่สม่ำเสมอกว่า
เหมาะอย่างยิ่งกับงานที่กำหนดขอบเขตได้อย่างเคร่งครัด
ต่อไปนี้คือตัวอย่างอย่างง่ายของเอเจนต์แชตบอตสำหรับจองเที่ยวบินที่ใช้ “แนวทางแบบเราเตอร์” แม้ LLM จะช่วยจำแนกเจตนาของคำถามจากสามตัวเลือก แต่ท้ายที่สุดซอฟต์แวร์ของเราจะจับคู่เจตนานั้นกับคำตอบจากเทมเพลตข้อความ เนื่องจาก LLM ถูกจำกัดขอบเขตไว้อย่างมาก ผู้ใช้จึงได้รับประสบการณ์การทำงานที่สม่ำเสมอกว่า
สถาปัตยกรรมแบบออร์เคสเตรเตอร์
ระบบเอเจนต์แบบออร์เคสเตรเตอร์แตกต่างจากระบบเราเตอร์ตรงที่:
กำหนดลำดับตรรกะผ่านพรอมต์ภาษาธรรมชาติแทนซอฟต์แวร์ หมายเหตุ: เมื่อเทียบกับภาษาโปรแกรม ภาษาธรรมชาติมีความกำกวมและยืดหยุ่นโดยธรรมชาติ (ซึ่งเป็นทั้งข้อดีและข้อเสีย ดังที่จะกล่าวถึงภายหลัง) เราเรียกแนวคิดนี้ว่า “เจตนาแทนคำสั่ง”
รองรับตัวเลือกการประมวลผลหลายแบบ โดยให้ LLM กำหนดลำดับและวิธีดำเนินการ
สร้างเส้นทางตรรกะใหม่แบบไดนามิก ซึ่งยากต่อการกำหนดอย่างชัดเจนในซอฟต์แวร์
ความกำกวมนี้อาจทำให้ผลลัพธ์ไม่สม่ำเสมอ แต่เมื่อทำงานได้ดีก็อาจให้ความรู้สึก “ราวกับมีเวทมนตร์”
ตัวอย่างต่อไปนี้นำแนวทางแบบออร์เคสเตรเตอร์มาใช้กับโจทย์สายการบินอย่างง่ายเดียวกัน แทนที่จะให้ซอฟต์แวร์ตัดสินใจว่าควรตอบอย่างไร เรามอบหมายการตัดสินใจให้เลเยอร์ LLM ในที่นี้ เรามีระบบหลายเอเจนต์ โดยเอเจนต์ออร์เคสเตรเตอร์ “หลัก” จะคัดแยกคำถามของผู้ใช้ ส่งต่องานให้เอเจนต์ที่ออกแบบมาเฉพาะสำหรับการเปลี่ยนเที่ยวบิน และเอเจนต์นั้นจะตอบผู้ใช้ในท้ายที่สุด
ในตัวอย่างนี้ เลเยอร์ LLM ทำหน้าที่เป็นทั้งตัวจำแนก เราเตอร์ และผู้เขียนคำตอบ ส่วนในตัวอย่างเราเตอร์ LLM ทำหน้าที่เพียงตัวจำแนกเท่านั้น (โดยซอฟต์แวร์จัดการส่วนที่เหลือ)
หากทำได้ เราแนะนำให้ใช้แนวทางแบบเราเตอร์ เพราะมีข้อดีดังต่อไปนี้:
ความเร็วและประสิทธิภาพ: การประมวลผลภายในระบบทำได้เร็วกว่าการใช้ออร์เคสเตรเตอร์ที่ต้องพึ่งพา API ภายนอก นอกจากนี้ การประมวลผลตรรกะ “IF/ELSE” ด้วย Python ยังมีต้นทุนต่ำกว่าการจ่ายเงินให้ผู้ให้บริการ LLM ส่งตรรกะดังกล่าวไปประมวลผลผ่านโมเดลที่มีพารามิเตอร์ 4 แสนล้านตัวอย่างมาก
ความสามารถในการทดสอบและการคาดการณ์: แก้ไขข้อบกพร่อง ทดสอบ และบำรุงรักษาได้ง่ายกว่ามากด้วยแนวปฏิบัติด้านซอฟต์แวร์ที่เป็นมาตรฐาน
ความโปร่งใสและความน่าเชื่อถือ: พฤติกรรมที่แปรผันน้อยลงช่วยให้แก้ไขปัญหาได้ง่ายขึ้น ขั้นตอนการทำงานของแอปพลิเคชันยังถูกถ่ายทอดผ่านซอฟต์แวร์ที่โปร่งใสและควบคุมเวอร์ชันได้ในสัดส่วนที่มากขึ้น แทนที่จะอยู่ในค่าน้ำหนักของ LLM ซึ่งไม่โปร่งใสและตีความไม่ได้
ข้อเสียของแนวทางแบบเราเตอร์คืออาจตายตัว ไม่ยืดหยุ่น และรับมือกับปัญหาที่เป็นปลายเปิดมากขึ้นได้ยาก ผู้ใช้อาจมองว่าแชตบอตที่ตอบด้วยข้อความเดิมทุกครั้งนั้นน่าเบื่อและไม่มีพัฒนาการ
การออกแบบแบบออร์เคสเตรเตอร์มีความสามารถที่ทรงพลัง ได้แก่:
การวางแผน: วางแผนคำตอบแบบไดนามิกได้
การเลือกเครื่องมือ/ส่งต่องานให้เอเจนต์: เลือกเครื่องมือที่เหมาะสมหรือมอบหมายงานให้เอเจนต์
การผสานผลลัพธ์แบบวนซ้ำ: ปรับซ้ำและนำผลลัพธ์มาผสานใหม่อย่างสร้างสรรค์
การพิจารณาว่างานเสร็จสมบูรณ์หรือไม่: ตัดสินว่าเก็บข้อมูลได้เพียงพอสำหรับจัดทำคำตอบฉบับสมบูรณ์แล้วหรือยัง
เฟรมเวิร์กอย่าง Pydantic-AI หรือ Agents SDK ของ OpenAI ช่วยให้การจัดระบบทำได้ง่ายและนำไปใช้ได้อย่างรวดเร็ว จึงเหมาะอย่างยิ่งสำหรับการสาธิตหรือการพิสูจน์แนวคิด
ข้อเสียของแนวทางนี้ ได้แก่:
ไม่มีสิ่งใดรับประกันได้ว่าขั้นตอนการวางแผนและการดำเนินการต่อมาของ LLM จะถูกต้องหรือเหมาะสม ระบบเราเตอร์ก็มีปัญหาเดียวกัน แต่เนื่องจากมีขอบเขตจำกัดกว่า พฤติกรรมจึงคาดการณ์ได้มากกว่า
สำหรับงานที่เรียบง่ายและมีขอบเขตชัดเจน เราไม่น่าจะต้องใช้ความสามารถทั้งหมดของระบบหลายเอเจนต์ ตัวอย่างเช่น ในกรณีเอเจนต์สายการบิน ผู้ที่ติดต่อระบบสนับสนุนของสายการบินน่าจะมีคำถามหรือต้องการดำเนินการอยู่เพียงไม่กี่ประเภท
เนื่องจากตรรกะส่วนใหญ่อยู่ใน LLM ระบบจึงเสี่ยงถูกผู้ไม่หวังดีเจลเบรกหรือหาช่องทางแสวงหาประโยชน์ได้มากขึ้น
แนวทางนี้ซ่อนกระบวนการตัดสินใจไว้ใน LLM จึงทำให้เข้าใจระบบได้ยากขึ้น (แม้เครื่องมือตรวจสอบอย่าง Langfuse หรือ Braintrust อาจช่วยได้บางส่วน)
หมายเหตุถึงผู้อ่าน: แม้ความสามารถของโมเดลจะเปลี่ยนแปลงอย่างรวดเร็ว แต่แนวทางด้านล่างนี้ไม่น่าจะเปลี่ยนไปในอนาคตอันใกล้
กำหนดขอบเขตของปัญหา
คุณสามารถถ่ายทอดตรรกะการตัดสินใจที่ต้องการเป็นแผนภาพได้โดยง่ายหรือไม่
แอปพลิเคชันของคุณยอมรับความล้มเหลวหรือพฤติกรรมที่ไม่คาดคิดไม่ได้ใช่หรือไม่
หากตอบ “ใช่” สำหรับคำถามข้อใดข้อหนึ่งข้างต้น แสดงว่าความสามารถแบบเราเตอร์น่าจะเหมาะกว่า
หากทำได้ เราแนะนำให้ใช้แนวทางแบบเราเตอร์ตราบเท่าที่ยังรองรับความต้องการ โดยยึดหลักทั่วไปว่า หากส่วนใดของระบบเขียนเป็นโค้ดได้ ก็ควรเขียนเป็นโค้ด (กล่าวคือ อย่าใช้ LLM มากเกินความจำเป็น)
เมื่อแนวทางดังกล่าวถึงขีดจำกัด เราสามารถจำลองข้อดีบางประการของออร์เคสเตรเตอร์แบบปลายเปิดภายในขอบเขตที่ควบคุมได้ ตัวอย่างเช่น:
การเลือกเครื่องมือ/ส่งต่องานให้เอเจนต์: ทำได้ง่ายผ่านการแยกแขนงตามเงื่อนไขหรือตัวจำแนก LLM
การพิจารณาว่างานเสร็จสมบูรณ์หรือไม่: ตัวจำแนก LLM แบบพื้นฐานสามารถตรวจสอบว่าคำตอบครบถ้วนก่อนส่งกลับให้ผู้ใช้
อย่างไรก็ตาม “การวางแผน” และ “การผสานผลลัพธ์แบบวนซ้ำ” ทำได้ยากกว่ามากในระบบเราเตอร์ที่ตายตัวอย่างไม่ต้องสงสัย ดังนั้น เมื่องานต้องใช้ความสามารถเหล่านี้ (โดยพิจารณาจากตัวจำแนก LLM หรือตรรกะอื่น) เราแนะนำให้สร้างแขนงออร์เคสเตรเตอร์ที่มีข้อจำกัดน้อยลงในระบบ
การเลือกระหว่างสถาปัตยกรรมแบบเราเตอร์และออร์เคสเตรเตอร์ควรสอดคล้องกับความชัดเจน ความซับซ้อน และรูปแบบการโต้ตอบของแอปพลิเคชัน ปัจจุบัน แนวทางแบบเราเตอร์มอบความน่าเชื่อถือ ประสิทธิภาพ และความสะดวกในการทดสอบสำหรับงานที่มีขอบเขตชัดเจน ออร์เคสเตรเตอร์มีความยืดหยุ่นมากกว่าสำหรับการโต้ตอบเชิงสนทนาที่ครอบคลุมหลากหลายรูปแบบ
เมื่อ LLM พัฒนาอย่างต่อเนื่อง จุดสมดุลระหว่างสองแนวทางนี้ก็อาจเปลี่ยนแปลงไป เรามีแนวโน้มเลือกสถาปัตยกรรมแบบเราเตอร์หรือแบบผสมผสานสำหรับเวิร์กโหลดที่ใช้งานจริง และใช้ออร์เคสเตรเตอร์กับปัญหาแบบปลายเปิดที่ต้องการการโต้ตอบอย่างเป็นธรรมชาติ ยืดหยุ่น และคล้ายมนุษย์