AI คำถามสัมภาษณ์ข้อที่ 2: จะมั่นใจได้อย่างไรว่าการเรียกใช้เครื่องมือของ Large Language Model (LLM) มีความน่าเชื่อถือ

จะมั่นใจได้อย่างไรว่า Large Language Model (LLM) ทำงานได้อย่างน่าเชื่อถือและควบคุมได้เมื่อเรียกใช้เครื่องมือ โดยไม่พึ่งพาแค่พรอมต์เพื่อ "โน้มน้าว" โมเดล จำเป็นต้องมีกรอบการจำกัดแบบหลายชั้นอย่างเป็นระบบ

เช่น ตัวอย่างการสอบถามสภาพอากาศ พฤติกรรม "การมั่ว" ทั่วไปสามประการของโมเดลในการเรียกใช้เครื่องมือ:
1. ไม่เรียกใช้เครื่องมือ แต่สร้างคำตอบเท็จขึ้นมาเอง
2. เรียกใช้เครื่องมือแต่ส่งพารามิเตอร์ที่มีรูปแบบผิด (เช่น เครื่องมือไม่รองรับ "มะรืนนี้" แต่ส่งพารามิเตอร์ date="มะรืนนี้")
3. แปลงรูปแบบพารามิเตอร์ตามอำเภอใจ (เช่น แปลง "มะรืนนี้" เป็นวันที่เฉพาะเจาะจงโดยพลการ) แม้ว่าเครื่องมือจะไม่ได้กำหนดให้ทำเช่นนั้น

รากฐานของปัญหาคือผลลัพธ์ของโมเดลนั้นเป็น ความน่าจะเป็น โดยธรรมชาติ พรอมต์เป็นเพียง "ข้อจำกัดแบบอ่อน" ที่ใช้กับความน่าจะเป็น ไม่ใช่กลไกบังคับที่รับประกันว่าโมเดลจะปฏิบัติตามอย่างเคร่งครัด ในสถานการณ์ที่ซับซ้อน "ข้อจำกัดแบบอ่อน" นี้มีแนวโน้มที่จะล้มเหลวได้ง่าย

เพื่อแก้ปัญหานี้ จำเป็นต้องมี โซลูชันทางวิศวกรรมแบบหลายชั้น:

1. ชั้นแรก: ปรับปรุงพรอมต์ (ข้อจำกัดแบบอ่อน)

   • ตำแหน่งคือจุดเริ่มต้นของระบบข้อจำกัด แต่ไม่ใช่จุดสิ้นสุด
   • ควรมองพรอมต์เป็น "สัญญาการดำเนินงาน" อธิบายวัตถุประสงค์ของเครื่องมือ ประเภทของพารามิเตอร์แต่ละตัว ขอบเขต และยกตัวอย่างค่าที่ไม่ถูกต้อง
   • ควรเพิ่ม ตัวอย่างแบบ Few-shot โดยแสดงตัวอย่าง "อินพุตที่ถูกต้อง → การเรียกใช้ที่ถูกต้อง" เพื่อใช้การเรียนรู้ในบริบทยึดรูปแบบพฤติกรรมของโมเดล

2. ชั้นที่สอง: นำ JSON Schema มาใช้ (ข้อจำกัดแบบแข็ง)

   • นี่คือขั้นตอนสำคัญจากการ "อธิบายเหตุผล" ไปสู่ "การตั้งรั้วกั้น"
   • ใช้คำจำกัดความที่มีโครงสร้างที่เครื่องอ่านได้และตรวจสอบได้ (JSON Schema) แทนคำอธิบายพารามิเตอร์ด้วยภาษาธรรมชาติ สามารถกำหนดประเภทฟิลด์อย่างเคร่งครัด ว่าต้องกรอกหรือไม่ ช่วงค่าที่เป็นไปได้ และสามารถตั้งค่า additionalProperties: false เพื่อห้ามโมเดลส่งออกฟิลด์ที่ไม่ได้กำหนดใดๆ
   • แพลตฟอร์ม API หลักรองรับการจำกัดผลลัพธ์ที่มีโครงสร้างนี้ในขั้นตอนการถอดรหัสของโมเดล ซึ่งช่วยหลีกเลี่ยงการละเมิดรูปแบบตั้งแต่ต้นทาง

3. ชั้นที่สาม: สร้างวงจรตรวจสอบ-ซ่อมแซม-ลองใหม่ (การรองรับการดำเนินการ)

   • แม้จะมี Schema ก็ยังต้องตรวจสอบไวยากรณ์และ Schema หลังจากได้รับผลลัพธ์จากโมเดล
   • เมื่อการตรวจสอบล้มเหลว ควรออกแบบกลไกการล้างข้อมูลอัตโนมัติและลองใหม่ (มีขีดจำกัด) โดยส่งข้อมูลข้อผิดพลาดกลับไปยังโมเดลเพื่อแก้ไขผลลัพธ์ เมื่อเกินจำนวนครั้งที่ลองใหม่ ต้องมีแผนลดระดับหรือดำเนินการด้วยมนุษย์

4. ระดับสถาปัตยกรรม: แยกหน้าที่รับผิดชอบ

   • ควรแยก การตัดสินใจ ออกจาก การดำเนินการ เป็นสถาปัตยกรรมสามชั้น:
     • ชั้นโมเดล: รับผิดชอบเฉพาะการตัดสินใจ (ตัดสินใจว่าจะเรียกใช้เครื่องมือใด สร้างพารามิเตอร์ใด)
     • ชั้นเฟรมเวิร์ก: รับผิดชอบการดำเนินการของเฟรมเวิร์ก รวมถึงการตรวจสอบ Schema การเรียกใช้เครื่องมือ การจัดการการลองใหม่ และการรวมผลลัพธ์ ซึ่งช่วยให้แน่ใจว่าข้อผิดพลาดของโมเดลไม่ส่งผลกระทบต่อความปลอดภัยของเครื่องมือโดยตรง และการเปลี่ยนแปลงเครื่องมือไม่จำเป็นต้องปรับเปลี่ยนพรอมต์บ่อยครั้ง
     • ชั้นเครื่องมือ: การดำเนินการความสามารถทางธุรกิจเฉพาะ
   • เฟรมเวิร์กเช่น LangChain, LlamaIndex กำลังทำงานในลักษณะนี้

ข้อจำกัดของโซลูชันปัจจุบัน: สามารถจัดการ รูปแบบพารามิเตอร์ ได้ดี แต่การตรวจสอบ ความหมายของพารามิเตอร์ (เช่น ความเท่าเทียมระหว่าง "เซี่ยงไฮ้" กับ "ฮู่") ยังไม่เพียงพอ นี่จะเป็นความท้าทายทางวิศวกรรมที่ต้องเผชิญในอนาคต

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