เอเจนต์ AI ควรช่วยประหยัดเวลาของวิศวกร
แต่ในทางปฏิบัติ เอเจนต์จำนวนมากทำงานนานเกินไป ใช้ token มากเกินไป และยังให้ผลลัพธ์ที่ไม่ดีพอ
วิธีแก้ที่พบบ่อยคือปรับปรุง prompt เพิ่มคำสั่ง เอกสารสถาปัตยกรรม ตัวอย่าง และข้อยกเว้น จนสุดท้าย system prompt กลายเป็นวิกิภายในขนาดย่อม
แต่นั่นไม่ได้แก้ปัญหาหลัก
เอเจนต์มักใช้เวลาส่วนใหญ่ค้นหาบริบทที่ควรมีอยู่แล้วซ้ำอีก และพยายามทำงานผ่านอินเทอร์เฟซที่ไม่ได้ออกแบบมาสำหรับเอเจนต์
ต้นทุนที่แท้จริงคือการค้นหาซ้ำ ลิงก์ไปยังหัวข้อ
ลองพิจารณาคำถามง่าย ๆ:
ทำไมค่าใช้จ่าย AWS ของเราจึงเพิ่มขึ้นในสัปดาห์นี้?
หากไม่มีเครื่องมือและบริบทขององค์กร เอเจนต์อาจต้อง:
- ค้นหาว่ามีบัญชี AWS ใดบ้าง
- หาข้อมูลการเรียกเก็บเงิน
- ตรวจสอบหลายบริการ
- ค้นหาในคลังโค้ด Terraform
- คาดเดาว่าทรัพยากรเป็นของใคร
- เปรียบเทียบเมตริกด้วยตนเอง
- ลองรันคำสั่งซ้ำด้วยพารามิเตอร์ที่ต่างกัน
ทุกขั้นตอนเพิ่มผลลัพธ์เข้าไปในบทสนทนา และโมเดลต้องประมวลผลผลลัพธ์นั้นอีกครั้งในขั้นตอนถัดไป
ผลลัพธ์คือวงจรที่ยิ่งทวีคูณ:
บริบทไม่เพียงพอ → ต้องค้นหาเพิ่ม → context window ใหญ่ขึ้น → วิเคราะห์ช้าลง → ใช้ token มากขึ้น
สุดท้ายเอเจนต์อาจหาคำตอบได้ แต่เส้นทางนั้นสิ้นเปลือง ช้า และทำซ้ำได้ยาก
prompt ที่ใหญ่ขึ้นไม่ใช่บริบทการปฏิบัติงาน ลิงก์ไปยังหัวข้อ
prompt มีประโยชน์สำหรับกำหนดเป้าหมายและข้อจำกัด:
- ทำงานแบบอ่านอย่างเดียว
- ห้ามเปิดเผยข้อมูลลูกค้า
- อธิบายหลักฐาน
- ขออนุมัติก่อนทำการเปลี่ยนแปลง
คำสั่งเหล่านี้เหมาะสม
แต่ prompt ไม่สามารถบรรจุสถานะปัจจุบันของ AWS ได้ ไม่รู้ว่า RDS instance ถูกเปลี่ยนเมื่อวาน ทีมใดเป็นเจ้าของ เหตุใดจึงตั้งขนาดใหญ่เกินความต้องการโดยตั้งใจ หรือ Reserved Instance มีผลต่อการตัดสินใจปรับขนาดหรือไม่
การเพิ่มข้อความแบบคงที่ไม่ได้แก้ปัญหาข้อมูลที่เปลี่ยนแปลงตลอดเวลา
prompt ขนาดใหญ่ยังทำให้ปัญหาแย่ลงได้ ข้อมูลเก่ายังคงอยู่หลังระบบเปลี่ยน บริบทที่ไม่เกี่ยวข้องแย่งความสนใจ และทุกคำขอต้องเสียค่าใช้จ่ายเพื่อประมวลผลข้อความเดิมซ้ำ
prompt ควรอธิบายว่าเอเจนต์ทำงานอย่างไร ไม่ควรบรรจุทุกสิ่งที่เอเจนต์อาจต้องใช้ในอนาคต
บริบทช่วยลดการค้นหาซ้ำ ลิงก์ไปยังหัวข้อ
บริบททำให้ข้อมูลดิบจาก AWS มีความหมายในเชิงปฏิบัติการ
บริบทที่มีประโยชน์ประกอบด้วย:
- เจ้าของบัญชี AWS และสภาพแวดล้อม
- ความสัมพันธ์ระหว่างแอปพลิเคชันกับทรัพยากร
- การตัดสินใจด้านสถาปัตยกรรม
- เหตุการณ์ขัดข้องก่อนหน้า
- ข้อยกเว้นที่ทราบแล้ว
- ข้อกำหนดด้านความปลอดภัย
- การเปลี่ยนแปลงที่วางแผนไว้
ไม่จำเป็นต้องโหลดข้อมูลเหล่านี้ลงในทุก prompt แต่ควรค้นหาและดึงมาใช้เมื่อเกี่ยวข้อง
เอเจนต์ที่กำลังตรวจสอบค่าใช้จ่าย RDS ที่เพิ่มขึ้นอาจต้องรู้เจ้าของฐานข้อมูล แผนปรับขนาดล่าสุด และข้อผูกพันของ Reserved Instance แต่ไม่น่าต้องใช้เอกสาร Kubernetes หรือข้อมูลเหตุการณ์ขัดข้องของ CloudFront จากปีที่แล้ว
บริบทที่ดีต้องถูกคัดเลือก ไม่ใช่เทลงไปทั้งหมด
เครื่องมือทำให้เอเจนต์ยึดโยงกับความเป็นจริง ลิงก์ไปยังหัวข้อ
บริบทอธิบายสภาพแวดล้อม เครื่องมือให้หลักฐานปัจจุบันและการดำเนินการที่ควบคุมได้
สำหรับงานปฏิบัติการบน AWS เครื่องมือที่มีประโยชน์สามารถเปิดให้ใช้:
- การคิวรี Cost and Usage Report
- การค้นหาด้วย AWS Resource Explorer
- การค้นหาเหตุการณ์ใน CloudTrail
- ประวัติจาก AWS Config
- เมตริกจาก CloudWatch
- เหตุการณ์จาก AWS Health
- ข้อมูลเจ้าของทรัพยากร
เครื่องมือที่เจาะจงสามารถทดแทนงานสำรวจที่อาจใช้ token หลายพัน token ได้
แทนที่จะให้เอเจนต์ค้นหาว่าข้อมูลการเรียกเก็บเงินอยู่ที่ใดและสร้างคิวรีเอง ให้เครื่องมือหนึ่งตัวรับบัญชี บริการ ช่วงวันที่ และรูปแบบการจัดกลุ่ม เครื่องมือนั้นสามารถตรวจสอบคำขอ รันคิวรีที่ได้รับอนุมัติ กรองข้อมูลที่ไม่เกี่ยวข้อง และส่งคืนผลลัพธ์แบบมีโครงสร้างขนาดเล็ก
จากนั้นเอเจนต์สามารถใช้ token เพื่อวิเคราะห์คำตอบ แทนที่จะใช้ไปกับการค้นหาวิธีนำข้อมูลมา
MCP สามารถสร้างอินเทอร์เฟซมาตรฐานให้เครื่องมือเหล่านี้ได้ แต่ MCP ไม่ได้ทำให้เครื่องมือที่ออกแบบมาไม่ดีกลายเป็นเครื่องมือที่ดี
เครื่องมือต้องมีขอบเขตจำกัด ลิงก์ไปยังหัวข้อ
การให้เอเจนต์ใช้ shell แบบทั่วไปไม่ได้ทำให้มีประสิทธิภาพขึ้นโดยอัตโนมัติ
เครื่องมือที่ออกแบบมาไม่ดีอาจส่งคืนทรัพยากรหลายพันรายการ ไฟล์ log ทั้งหมด หรือผลตอบกลับ API ที่ไม่ผ่านการกรอง ซึ่งเป็นเพียงการย้ายปัญหาเรื่อง token ไปอีกจุด
เครื่องมือที่ดีสำหรับเอเจนต์ควร:
- รับพารามิเตอร์ที่ชัดเจน
- กรองข้อมูลก่อนส่งคืน
- ส่งคืนผลลัพธ์แบบมีโครงสร้าง
- บังคับใช้ขีดจำกัดผลลัพธ์
- แสดงข้อผิดพลาดที่ชัดเจน
- แยกการอ่านออกจากการเขียน
- หลีกเลี่ยงการส่งคืน secrets
- บันทึกข้อมูลกำกับของการเรียกใช้
เครื่องมือที่ดีที่สุดทำงานปฏิบัติการหนึ่งอย่างได้ดี
ขอบเขตด้านความปลอดภัยยังคงมีผล ลิงก์ไปยังหัวข้อ
AI ไม่ได้เปลี่ยนโมเดลความปลอดภัยของ AWS
เอเจนต์ควรใช้มาตรการควบคุมแบบเดียวกับ workload ใน production:
- role IAM ตามหลักสิทธิ์เท่าที่จำเป็น
- ข้อมูลประจำตัวชั่วคราวจาก STS
- แยกสิทธิ์สำหรับการอ่านและการเปลี่ยนแปลง
- กำหนดขอบเขตบัญชีและสภาพแวดล้อมอย่างชัดเจน
- ให้มนุษย์อนุมัติการดำเนินการที่มีความอ่อนไหว
- มีบันทึกการตรวจสอบสำหรับทุกการเรียกเครื่องมือ
ค่าเริ่มต้นควรเป็นสิทธิ์แบบอ่านอย่างเดียว
เอเจนต์ที่ตรวจสอบค่าใช้จ่ายไม่จำเป็นต้องมีสิทธิ์ปรับขนาด RDS หากเอเจนต์แนะนำการเปลี่ยนแปลง การดำเนินการนั้นควรผ่านขั้นตอนอนุมัติและดำเนินงานที่แยกต่างหาก
คำสั่งใน prompt เช่น “ห้ามเปลี่ยนแปลง production” มีประโยชน์ แต่ไม่ใช่มาตรการควบคุมด้านความปลอดภัย
IAM และขอบเขตของเครื่องมือต่างหากที่เป็นมาตรการควบคุม
วัดจากงานที่เสร็จ ลิงก์ไปยังหัวข้อ
ลำดับการทำงานของเอเจนต์ที่ยาวอาจดูมีประสิทธิผล ทั้งที่ซ่อนความสูญเปล่าไว้มาก
ผมจะวัด:
- จำนวน token ต่องานที่เสร็จ
- เวลาจนได้ผลลัพธ์แรกที่มีประโยชน์
- จำนวนครั้งที่เรียกเครื่องมือ
- การอ่านและคิวรีซ้ำ
- การเรียกใช้เครื่องมือที่ล้มเหลว
- จำนวนครั้งที่ต้องให้มนุษย์แก้ไข
เป้าหมายไม่ใช่ลดการใช้ token ให้ต่ำที่สุดในทุกกรณี งานซับซ้อนยังต้องสำรวจ
เป้าหมายคือไม่ต้องเสียค่าใช้จ่ายซ้ำ ๆ กับงานค้นหาที่รู้อยู่แล้วว่าต้องทำ
ข้อสรุป ลิงก์ไปยังหัวข้อ
prompt ที่ดีขึ้นมีความสำคัญ โมเดลที่ดีขึ้นก็เช่นกัน
แต่ทั้งสองอย่างทดแทนข้อมูลปัจจุบัน บริบทขององค์กร หรืออินเทอร์เฟซการปฏิบัติงานที่ปลอดภัยไม่ได้
สำหรับเอเจนต์ AI บน AWS ที่ใช้ใน production:
- prompt กำหนดเป้าหมายและข้อจำกัด
- บริบทอธิบายสภาพแวดล้อม
- เครื่องมือดึงหลักฐานและดำเนินการภายใต้การควบคุม
- IAM กำหนดสิ่งที่ได้รับอนุญาตจริง
- มนุษย์อนุมัติการตัดสินใจที่มีผลกระทบสูง
เอเจนต์ที่เร็วที่สุดไม่ใช่เอเจนต์ที่มี prompt ใหญ่ที่สุด
แต่คือเอเจนต์ที่รู้ว่าต้องค้นหาที่ไหน มีเครื่องมือที่เหมาะสม และหยุดเมื่อทำงานเสร็จ