คำตอบสั้นๆ: ในการสร้างเอเจนต์ AI ที่ใช้งานได้จริง ให้คิดว่ามันเป็นวงจรควบคุม: รับอินพุต ตัดสินใจว่าจะทำอะไรต่อไป เรียกใช้เครื่องมือที่มีขอบเขตจำกัด สังเกตผลลัพธ์ และทำซ้ำจนกว่าจะผ่านการตรวจสอบ "เสร็จสมบูรณ์" อย่างชัดเจน มันจะมีประสิทธิภาพเมื่อภารกิจมีหลายขั้นตอนและต้องใช้เครื่องมือช่วย หากการเรียกใช้เพียงครั้งเดียวสามารถแก้ปัญหาได้ ให้ข้ามขั้นตอนการทำงานของเอเจนต์ไป เพิ่มรูปแบบเครื่องมือที่เข้มงวด ขีดจำกัดขั้นตอน การบันทึกข้อมูล และตัวตรวจสอบ/วิจารณ์ เพื่อให้เมื่อเครื่องมือล้มเหลวหรืออินพุตไม่ชัดเจน เอเจนต์จะเปลี่ยนไปใช้ระบบอื่นแทนที่จะวนซ้ำ
ประเด็นสำคัญ:
ลูปควบคุม : ดำเนินการวนซ้ำแบบรับข้อมูลเข้า→กระทำ→สังเกต โดยกำหนดเงื่อนไขการหยุดและจำนวนขั้นตอนสูงสุดอย่างชัดเจน
การออกแบบเครื่องมือ : ควรจำกัดขอบเขตการใช้งานของเครื่องมือ กำหนดประเภทข้อมูล กำหนดสิทธิ์การเข้าถึง และตรวจสอบความถูกต้อง เพื่อป้องกันความวุ่นวายจากเครื่องมือที่มีฟังก์ชัน "ทำอะไรก็ได้"
สุขอนามัยความจำ : ใช้การจัดเก็บข้อมูลระยะสั้นแบบกระชับควบคู่กับการเรียกใช้ข้อมูลระยะยาว หลีกเลี่ยงการบันทึกข้อมูลทั้งหมดลงหน่วย
การป้องกันการใช้งานในทางที่ผิด : เพิ่มรายการที่อนุญาต การจำกัดอัตรา การทำงานซ้ำได้ และการทดสอบเบื้องต้นสำหรับการกระทำที่มีความเสี่ยง
ความสามารถในการทดสอบ : จัดทำชุดสถานการณ์จำลอง (ความล้มเหลว ความคลุมเครือ การโจมตีแบบแทรก) และทำการทดสอบซ้ำทุกครั้งที่มีการเปลี่ยนแปลง
🔗 วิธีการวัดประสิทธิภาพ AI
เรียนรู้ตัวชี้วัดเชิงปฏิบัติเพื่อวัดความเร็ว ความแม่นยำ และความน่าเชื่อถือ.
🔗 วิธีการพูดคุยกับ AI
ใช้คำถามนำ บริบท และคำถามเพิ่มเติมเพื่อให้ได้คำตอบที่ดีขึ้น.
🔗 วิธีการประเมินโมเดล AI
เปรียบเทียบโมเดลโดยใช้การทดสอบ เกณฑ์การประเมิน และผลลัพธ์จากงานจริง.
🔗 วิธีการเพิ่มประสิทธิภาพโมเดล AI
ปรับปรุงคุณภาพและลดต้นทุนด้วยการปรับแต่ง การตัดแต่ง และการตรวจสอบอย่างต่อเนื่อง.
1) ตัวแทน AI คืออะไร ในภาษาที่คนทั่วไปเข้าใจได้ 🧠
เอเจนต์ AI คือลูป เอกสารประกอบเกี่ยวกับ "เอเจนต์" ของ LangChain
แค่นั้นเอง วงจรที่มีสมองอยู่ตรงกลาง.
รับข้อมูล → คิด → ลงมือทำ → สังเกต → ทำซ้ำ กระดาษ ReAct (เหตุผล + การกระทำ)
ที่ไหน:
-
อินพุต คือคำขอของผู้ใช้หรือเหตุการณ์ (อีเมลใหม่ ตั๋วขอความช่วยเหลือ การตรวจสอบสัญญาณจากเซ็นเซอร์)
-
การคิด เป็นแบบจำลองทางภาษาที่ใช้ในการให้เหตุผลเกี่ยวกับขั้นตอนต่อไป
-
การกระทำนี้ คือการเรียกใช้เครื่องมือ (ค้นหาเอกสารภายใน รันโค้ด สร้างตั๋ว ร่างคำตอบ) คู่มือการเรียกใช้ฟังก์ชันของ OpenAI
-
Observe กำลังอ่านผลลัพธ์จากเครื่องมือ
-
ส่วนที่ทำให้รู้สึกเหมือนเป็น "ตัวแทน" มากกว่า "คนช่างพูด" ก็คือ การใช้ฟังก์ชัน Repeat (เอกสารเกี่ยวกับ "ตัวแทน" ของ LangChain)
เอเจนต์บางตัวก็เหมือนมาโครอัจฉริยะ ในขณะที่บางตัวก็ทำหน้าที่เหมือนโอเปอเรเตอร์รุ่นน้องที่สามารถจัดการงานหลายอย่างพร้อมกันและแก้ไขข้อผิดพลาดได้ ทั้งสองแบบล้วนมีความสำคัญ.
นอกจากนี้ คุณไม่จำเป็นต้องมีอิสระเต็มที่หรอก ที่จริงแล้ว...คุณอาจจะไม่ต้องการมันด้วยซ้ำ 🙃
2) เมื่อใดที่คุณควรสร้างเอเจนต์ (และเมื่อใดที่คุณไม่ควรสร้าง) 🚦
สร้างเอเจนต์เมื่อ:
-
งานนี้เป็น กระบวนการหลายขั้นตอน และจะเปลี่ยนแปลงไปขึ้นอยู่กับสิ่งที่เกิดขึ้นระหว่างทาง
-
งานนี้จำเป็นต้อง ใช้เครื่องมือต่างๆ (ฐานข้อมูล, CRM, การเรียกใช้โค้ด, การสร้างไฟล์, เว็บเบราว์เซอร์, API ภายใน) ดูเอกสาร "เครื่องมือ" ของ LangChain
-
คุณต้องการ ผลลัพธ์ที่สม่ำเสมอและ มีขอบเขตชัดเจน ไม่ใช่แค่คำตอบแบบใช้ครั้งเดียวทิ้ง
-
คุณสามารถกำหนดความหมายของคำว่า "เสร็จสมบูรณ์" ในแบบที่คอมพิวเตอร์สามารถตรวจสอบได้ แม้ว่าจะกำหนดอย่างหลวมๆ ก็ตาม.
อย่าสร้างเอเจนต์เมื่อ:
-
แค่คำถามและคำตอบง่ายๆ ก็แก้ปัญหาได้แล้ว (อย่าทำให้มันซับซ้อนเกินไป เดี๋ยวจะเสียใจทีหลัง).
-
คุณต้องการความแน่นอนที่สมบูรณ์แบบ (ตัวแทนอาจมีความสอดคล้องกันบ้าง แต่ไม่ใช่แบบหุ่นยนต์).
-
ถ้าคุณไม่มีเครื่องมือหรือข้อมูลใดๆ ในการเชื่อมต่อ ส่วนใหญ่ก็จะเป็นแค่ความรู้สึกเท่านั้น.
พูดกันตรงๆ เลยนะ ครึ่งหนึ่งของ "โปรเจกต์เอเจนต์ AI" อาจเป็นเพียงเวิร์กโฟลว์ที่มีกฎการแยกสาขาไม่กี่ข้อก็ได้ แต่เอาเถอะ บางครั้งบรรยากาศก็สำคัญเหมือนกันนะ 🤷♂️
3) อะไรคือคุณสมบัติของเอเจนต์ AI ที่ดี ✅
นี่คือส่วน "อะไรทำให้เวอร์ชันที่ดีของ..." ที่คุณขอมา แต่ผมจะพูดตรงๆ เลยนะครับ:
ตัวแทน AI ที่ดีนั้น ไม่ใช่ ตัวที่คิดหนักที่สุด แต่เป็นตัวที่:
-
รู้ว่าตนเองได้รับอนุญาตให้ทำอะไรได้บ้าง (ขอบเขต)
-
ใช้เครื่องมืออย่างน่าเชื่อถือ (การเรียกแบบมีโครงสร้าง การลองใหม่ การหมดเวลา) คู่มือการเรียกฟังก์ชันของ OpenAI AWS “การหมดเวลา การลองใหม่ และการหน่วงเวลาพร้อมความผันผวน”
-
รักษาข้อมูลสถานะให้สะอาด (หน่วยความจำที่ไม่เสื่อมสภาพ) LangChain “ภาพรวมหน่วยความจำ”
-
อธิบายการกระทำของตน (บันทึกการตรวจสอบ ไม่ใช่การเปิดเผยเหตุผลลับ) ตามมาตรฐาน NIST AI RMF 1.0 (ความน่าเชื่อถือและความโปร่งใส)
-
หยุดการทำงานอย่างเหมาะสม (การตรวจสอบความสำเร็จ จำนวนขั้นตอนสูงสุด การแจ้งเตือน) เอกสาร "เอเจนต์" ของ LangChain
-
ล้มเหลวอย่างปลอดภัย (ขอความช่วยเหลือ ไม่หลงคิดว่าตนเองมีอำนาจ) NIST AI RMF 1.0
-
สามารถทดสอบได้ (คุณสามารถรันบนสถานการณ์จำลองสำเร็จรูปและให้คะแนนผลลัพธ์ได้)
ถ้าตัวแทนของคุณไม่สามารถผ่านการทดสอบได้ มันก็เหมือนเครื่องเล่นสล็อตแมชชีนที่มั่นใจมาก ๆ สนุกในงานปาร์ตี้ แต่ terrifying มากในขั้นตอนการผลิต 😬
4) ส่วนประกอบหลักของเอเจนต์ (โครงสร้างทางกายภาพ 🧩)
โดยทั่วไปแล้ว ตัวแทนขายที่เชื่อถือได้ส่วนใหญ่มักมีส่วนประกอบเหล่านี้:
ก) วงจรควบคุม 🔁
นี่คือผู้ประสานงาน:
-
ตั้งเป้าหมาย
-
ถามนางแบบถึงขั้นตอนต่อไป
-
เรียกใช้เครื่องมือ
-
เพิ่มการสังเกต
-
ทำซ้ำจนกว่าจะเสร็จสิ้น เอกสารประกอบ "เอเจนต์" ของ LangChain
ข) เครื่องมือ (หรือความสามารถ) 🧰
เครื่องมือคือสิ่งที่ทำให้เอเจนต์มีประสิทธิภาพ: เอกสาร "เครื่องมือ" ของ LangChain
-
การสืบค้นฐานข้อมูล
-
การส่งอีเมล
-
การดึงไฟล์
-
รันโค้ด
-
การเรียกใช้ API ภายใน
-
การเขียนข้อมูลลงในสเปรดชีตหรือ CRM
ค) ความจำ 🗃️
มีสองประเภทที่สำคัญ:
-
หน่วยความจำระยะสั้น : บริบทการทำงานปัจจุบัน ขั้นตอนล่าสุด แผนปัจจุบัน
-
หน่วยความจำระยะยาว : การตั้งค่าของผู้ใช้ บริบทของโครงการ ความรู้ที่ดึงมา (มักผ่านการฝังข้อมูล + ที่เก็บเวกเตอร์) เอกสาร RAG
ง) นโยบายการวางแผนและการตัดสินใจ 🧭
ถึงแม้คุณจะไม่เรียกมันว่า "การวางแผน" แต่คุณก็จำเป็นต้องมีวิธีการ:
-
รายการตรวจสอบ
-
กระดาษ ReAct แบบ “คิดแล้วค่อยทำ”
-
กราฟงาน
-
รูปแบบความสัมพันธ์ระหว่างหัวหน้างานกับลูกน้อง
-
รูปแบบความสัมพันธ์ระหว่างหัวหน้างานและลูกน้อง Microsoft AutoGen (เฟรมเวิร์กแบบหลายเอเจนต์)
E) มาตรการป้องกันและประเมินผล 🧯
-
สิทธิ์อนุญาต
-
โครงสร้างแบบแผนเครื่องมือที่ปลอดภัย OpenAI Structured Outputs
-
การตรวจสอบความถูกต้องของผลลัพธ์
-
ขีดจำกัดขั้นตอน
-
การบันทึกข้อมูล
ใช่แล้ว มันเป็นเรื่องของวิศวกรรมมากกว่าการกระตุ้นเตือน ซึ่งนั่นก็เป็น...ประเด็นสำคัญอย่างหนึ่ง.
5) ตารางเปรียบเทียบ: วิธีการสร้างเอเจนต์ที่ได้รับความนิยม 🧾
ด้านล่างนี้คือ "ตารางเปรียบเทียบ" ที่สมจริง - แต่ก็มีรายละเอียดปลีกย่อยอยู่บ้าง เพราะทีมจริงๆ ก็มีเอกลักษณ์เฉพาะตัว 😄
| เครื่องมือ / เฟรมเวิร์ก | ผู้ชม | ราคา | เหตุผลที่มันได้ผล | หมายเหตุ (ความวุ่นวายเล็กน้อย) | |
|---|---|---|---|---|---|
| ลังเชน | นักสร้างที่ชื่นชอบชิ้นส่วนสไตล์เลโก้ | ฟรีพอสมควร + โครงสร้างพื้นฐาน | ระบบนิเวศขนาดใหญ่สำหรับเครื่องมือ หน่วยความจำ และโซ่ | อาจกลายเป็นเรื่องยุ่งยากเหมือนกินสปาเก็ตตี้ได้ ถ้าคุณไม่ตั้งชื่อสิ่งต่างๆ ให้ชัดเจน | |
| LlamaIndex | ทีมที่มี RAG จำนวนมาก | ฟรีพอสมควร + โครงสร้างพื้นฐาน | รูปแบบการค้นหาที่แข็งแกร่ง การจัดทำดัชนี ตัวเชื่อมต่อ | เยี่ยมไปเลยถ้าเอเยนต์ของคุณทำหน้าที่แค่ “หาลูกค้า + ดำเนินการ”… ซึ่งเป็นเรื่องปกติ | |
| แนวทางสไตล์ผู้ช่วย OpenAI | ทีมที่ต้องการการตั้งค่าที่รวดเร็วยิ่งขึ้น | อิงตามการใช้งาน | รูปแบบการเรียกใช้เครื่องมือในตัวและสถานะการทำงาน | อาจมีความยืดหยุ่นน้อยกว่าในบางจุด แต่ใช้งานได้ดีกับแอปพลิเคชันหลายๆ ตัว | OpenAI เรียก ใช้ API ของ OpenAI Assistants |
| เคอร์เนลเชิงความหมาย | นักพัฒนาที่ต้องการการจัดการกระบวนการอย่างเป็นระบบ | ค่อนข้างฟรี | การสรุปเชิงนามธรรมที่ชัดเจนสำหรับทักษะ/หน้าที่ | ให้ความรู้สึก "เป็นระเบียบเรียบร้อยแบบองค์กร" - บางครั้งนั่นก็ถือเป็นคำชมนะ 😉 | |
| ออโต้เจน | ผู้ทดลองหลายตัวแทน | ค่อนข้างฟรี | รูปแบบความร่วมมือระหว่างเอเจนต์ | อาจพูดแทรกได้; กำหนดกฎการยุติการสนทนาอย่างเข้มงวด | |
| ครูว์ไอ | แฟนๆ “ทีมเอเยนต์” | ค่อนข้างฟรี | บทบาท + หน้าที่ + การส่งต่อ สามารถอธิบายได้ง่าย | จะได้ผลดีที่สุดเมื่อภารกิจมีความชัดเจน ไม่ใช่คลุมเครือ | |
| กองฟาง | การค้นหา + บุคลากรด้านไปป์ไลน์ | ค่อนข้างฟรี | ท่อแข็ง, การดึงข้อมูล, ส่วนประกอบ | ไม่ใช่ "โรงละครตัวแทน" แต่เป็น "โรงงานที่เน้นการปฏิบัติจริง" มากกว่า | |
| ม้วนเองได้ (ลูปแบบกำหนดเอง) | พวกชอบควบคุม (แบบแสดงความรัก) | เวลาของคุณ | เวทมนตร์น้อยที่สุด ความชัดเจนสูงสุด | โดยปกติแล้ววิธีที่ดีที่สุดในระยะยาวคือ...จนกว่าคุณจะคิดค้นสิ่งใหม่ทั้งหมด 😅 |
ไม่มีผู้ชนะเพียงคนเดียว ตัวเลือกที่ดีที่สุดขึ้นอยู่กับว่างานหลักของเอเจนต์ของคุณคือ การดึงข้อมูล การ ใช้งานเครื่องมือ เจน ต์หลายตัว หรือ อัตโนมัติ ของเวิร์กโฟลว์
6) วิธีสร้างเอเจนต์ AI ทีละขั้นตอน (สูตรสำเร็จ) 🍳🤖
นี่คือส่วนที่คนส่วนใหญ่มักมองข้ามไป แล้วก็สงสัยว่าทำไมเจ้าหน้าที่ถึงทำตัวเหมือนแรคคูนในห้องเก็บของ.
ขั้นตอนที่ 1: อธิบายลักษณะงานด้วยประโยคเดียว 🎯
ตัวอย่าง:
-
“ร่างคำตอบลูกค้าโดยใช้ข้อมูลนโยบายและบริบทของตั๋วแจ้งปัญหา จากนั้นขออนุมัติจากลูกค้า”
-
“ตรวจสอบรายงานข้อผิดพลาด จำลองข้อผิดพลาด และเสนอแนวทางแก้ไข”
-
“เปลี่ยนบันทึกการประชุมที่ไม่สมบูรณ์แบบให้เป็นงาน ผู้รับผิดชอบ และกำหนดเวลา”
ถ้าคุณไม่สามารถอธิบายมันอย่างง่ายๆ ได้ ตัวแทนของคุณก็ทำไม่ได้เช่นกัน หมายความว่ามันทำได้ แต่ก็จะปรับเปลี่ยนไปตามสถานการณ์ และการปรับเปลี่ยนตามสถานการณ์นี่แหละคือจุดที่งบประมาณจะหมดไป.
ขั้นตอนที่ 2: เลือกระดับความเป็นอิสระ (ต่ำ ปานกลาง เผ็ด) 🌶️
-
ระดับความเป็นอิสระต่ำ : ระบบจะแนะนำขั้นตอนต่างๆ และผู้ใช้จะต้องคลิก "อนุมัติ"
-
ระดับปานกลาง : ใช้งานเครื่องมือ ร่างผลลัพธ์ และแจ้งปัญหาเมื่อไม่แน่ใจ
-
ระดับสูง : ดำเนินการตั้งแต่ต้นจนจบ และแจ้งเตือนมนุษย์เฉพาะเมื่อเกิดข้อผิดพลาดเท่านั้น
เริ่มจากระดับที่ต่ำกว่าที่คุณต้องการก่อน คุณสามารถปรับเพิ่มขึ้นได้เสมอในภายหลัง.
ขั้นตอนที่ 3: เลือกกลยุทธ์โมเดลของคุณ 🧠
โดยทั่วไปคุณจะเลือก:
-
แบบจำลองที่แข็งแกร่งเพียงแบบเดียวสำหรับทุกสิ่ง (เรียบง่าย)
-
โมเดลหลักหนึ่งตัว + โมเดลขนาดเล็กกว่าสำหรับขั้นตอนราคาประหยัด (การจำแนกประเภท การกำหนดเส้นทาง)
-
โมเดลเฉพาะทาง (ด้านการมองเห็น การเข้ารหัส การพูด) หากจำเป็น
นอกจากนี้ ให้ตัดสินใจด้วยว่า:
-
โทเค็นสูงสุด
-
อุณหภูมิ
-
คุณอนุญาตให้แสดงลำดับความคิดที่ยาวนานภายในระบบหรือไม่ (ทำได้ แต่ห้ามเปิดเผยลำดับความคิดดิบๆ ให้ผู้ใช้ปลายทางเห็น)
ขั้นตอนที่ 4: กำหนดเครื่องมือด้วยรูปแบบข้อมูลที่เข้มงวด 🔩
เครื่องมือควรมีคุณสมบัติดังนี้:
-
แคบ
-
พิมพ์
-
ได้รับอนุญาต
-
เอาต์พุตโครงสร้างของ OpenAI ที่ผ่านการตรวจสอบแล้ว
แทนที่จะใช้เครื่องมือที่ชื่อว่า do_anything(input: string) ให้ใช้แบบนี้แทน:
-
search_kb(query: string) -> results[] -
create_ticket(title: string, body: string, priority: enum) -> ticket_id -
send_email(to: string, subject: string, body: string) -> statusคู่มือการเรียกใช้ฟังก์ชัน OpenAI
ถ้าคุณให้เลื่อยยนต์กับตัวแทน อย่าตกใจถ้ามันตัดแต่งพุ่มไม้โดยทำลายรั้วไปด้วย.
ขั้นตอนที่ 5: สร้างวงจรควบคุม 🔁
รอบขั้นต่ำ:
-
เริ่มต้นด้วยเป้าหมาย + บริบทเบื้องต้น
-
ถามแบบจำลอง: “ขั้นตอนต่อไปคืออะไร?”
-
ถ้ามีการเรียกใช้เครื่องมือ - ให้เรียกใช้เครื่องมือ
-
เพิ่มการสังเกต
-
ตรวจสอบเงื่อนไขการหยุด
-
ทำซ้ำ (โดยกำหนดจำนวนขั้นตอนสูงสุด) เอกสาร "เอเจนต์" ของ LangChain
เพิ่ม:
-
หมดเวลา
-
การลองใหม่ (ระวัง - การลองใหม่สามารถวนซ้ำได้) AWS “การหมดเวลา การลองใหม่ และการหน่วงเวลาพร้อมความผันผวน”
-
การจัดรูปแบบข้อผิดพลาดของเครื่องมือ (ชัดเจน เป็นระเบียบ)
ขั้นตอนที่ 6: เพิ่มหน่วยความจำอย่างระมัดระวัง 🗃️
ระยะสั้น: จัดทำ "สรุปสถานะ" ที่กระชับและอัปเดตทุกขั้นตอน LangChain แสดง "ภาพรวมหน่วยความจำ"
ระยะยาว: จัดเก็บข้อมูลสำคัญที่คงทน (การตั้งค่าของผู้ใช้ กฎขององค์กร เอกสารที่เสถียร)
หลักการโดยทั่วไป:
-
หากมีการเปลี่ยนแปลงบ่อย ให้เลือกแบบระยะสั้น
-
หากมีความเสถียร ก็สามารถเก็บรักษาไว้ได้ในระยะยาว
-
ถ้าเป็นของที่บอบบาง ควรเก็บในระยะเวลาน้อยที่สุด (หรืออย่าเก็บเลย)
ขั้นตอนที่ 7: เพิ่มการตรวจสอบความถูกต้องและการตรวจสอบวิจารณ์ 🧪
แบบแพทเทิร์นราคาประหยัดและใช้งานได้จริง:
-
ตัวแทนสร้างผลลัพธ์
-
ตัวตรวจสอบจะตรวจสอบโครงสร้างและข้อจำกัด
-
การตรวจสอบแบบจำลองวิจารณ์เพิ่มเติมสำหรับขั้นตอนที่ขาดหายไปหรือการละเมิดนโยบาย NIST AI RMF 1.0
มันอาจไม่สมบูรณ์แบบ แต่ก็สามารถจับเรื่องไร้สาระได้ในปริมาณที่น่าตกใจ.
ขั้นตอนที่ 8: บันทึกทุกสิ่งที่คุณจะเสียใจหากไม่ได้บันทึกไว้ 📜
บันทึก:
-
การเรียกใช้เครื่องมือ + ข้อมูลนำเข้า + ข้อมูลส่งออก
-
การตัดสินใจ
-
ข้อผิดพลาด
-
ผลลัพธ์สุดท้าย
-
โทเค็นและเวลาแฝง คู่มือเบื้องต้นเกี่ยวกับการตรวจสอบการทำงานของ OpenTelemetry
ตัวคุณในอนาคตจะขอบคุณคุณ ส่วนตัวคุณในปัจจุบันจะลืมไป นั่นแห่ล่ะชีวิต 😵💫
7) เครื่องมือเรียกหาที่ไม่ทำลายจิตวิญญาณของคุณ 🧰😵
การเรียกใช้เครื่องมือคือจุดที่ "วิธีการสร้างเอเจนต์ AI" กลายเป็นวิศวกรรมซอฟต์แวร์อย่างแท้จริง.
ทำให้เครื่องมือมีความน่าเชื่อถือ (ความน่าเชื่อถือเป็นสิ่งที่ดี)
เครื่องมือที่เชื่อถือได้ ได้แก่:
-
กำหนดได้แน่นอน
-
ขอบเขตแคบ
-
ทดสอบได้ง่าย
-
ปลอดภัยที่จะเรียกใช้ Stripe “Idempotent requests”
เพิ่มข้อจำกัดและขอบเขตที่ระดับเครื่องมือ ไม่ใช่แค่ข้อความแจ้งเตือน
ข้อความแจ้งเตือนเป็นเพียงคำแนะนำอย่างสุภาพ การตรวจสอบความถูกต้องของเครื่องมือเปรียบเสมือนประตูที่ปิดล็อกไว้ เอาต์พุตที่มีโครงสร้างของ OpenAI
ทำ:
-
รายการที่อนุญาต (เครื่องมือใดบ้างที่สามารถใช้งานได้)
-
การตรวจสอบความถูกต้องของข้อมูลป้อนเข้า
-
ข้อจำกัดอัตรา การใช้งาน คู่มือข้อจำกัดอัตราการใช้งานของ OpenAI
-
การตรวจสอบสิทธิ์ต่อผู้ใช้/องค์กร
-
โหมดทดลองก่อนดำเนินการสำหรับกิจกรรมเสี่ยง
ออกแบบเพื่อรองรับความล้มเหลวบางส่วน
เครื่องมือล้มเหลว เครือข่ายไม่เสถียร การตรวจสอบสิทธิ์หมดอายุ ตัวแทนต้อง:
-
ตีความข้อผิดพลาด
-
ลองใหม่โดยใช้กลไกหน่วงเวลาเมื่อเหมาะสม กลยุทธ์การลองใหม่ของ Google Cloud (หน่วงเวลา + ความผันผวน)
-
เลือกเครื่องมืออื่น
-
สถานการณ์จะบานปลายเมื่อติดอยู่กับที่
เทคนิคที่ได้ผลอย่างเงียบๆ: ส่งคืนข้อผิดพลาดที่มีโครงสร้าง เช่น:
-
ประเภท: ข้อผิดพลาดในการตรวจสอบสิทธิ์ -
ประเภท: ไม่พบ -
ประเภท: rate_limited
เพื่อให้โมเดลสามารถตอบสนองได้อย่างชาญฉลาดแทนที่จะตื่นตระหนก
8) ความทรงจำที่ช่วยคุณแทนที่จะคอยหลอกหลอนคุณ 👻🗂️
ความทรงจำนั้นทรงพลัง แต่ก็อาจกลายเป็นที่เก็บของรกได้เช่นกัน.
ความจำระยะสั้น: เก็บให้กระชับ
ใช้:
-
ขั้นตอนสุดท้าย N
-
สรุปผลแบบเรียลไทม์ (อัปเดตทุกรอบ)
-
แผนปัจจุบัน
-
ข้อจำกัดในปัจจุบัน (งบประมาณ เวลา นโยบาย)
ถ้าเอาทุกอย่างมาพิจารณาในบริบท คุณจะได้ผลลัพธ์ดังนี้:
-
ต้นทุนที่สูงขึ้น
-
ความหน่วงที่ช้าลง
-
ยิ่งสับสนมากขึ้น (ใช่ แม้แต่ในกรณีนั้นก็ตาม)
ความทรงจำระยะยาว: การดึงข้อมูลออกมาใช้มากกว่าการ "เก็บสะสม"
ความทรงจำระยะยาวส่วนใหญ่มีลักษณะดังนี้:
-
การฝังข้อมูล
-
ร้านเวกเตอร์
-
การสร้างข้อมูลเสริมการค้นหา (RAG) บทความ RAG
เอเจนต์ไม่จดจำข้อมูล แต่จะดึงข้อมูลส่วนที่เกี่ยวข้องมากที่สุดมาใช้ในขณะรันไทม์ LlamaIndex “บทนำเกี่ยวกับ RAG”
กฎการจำเชิงปฏิบัติ
-
บันทึก "การตั้งค่า" เป็นข้อเท็จจริงที่ชัดเจน: "ผู้ใช้ชอบสรุปแบบหัวข้อและไม่ชอบอิโมจิ" (ฮ่าๆ แต่ไม่ใช่ในกรณีนี้ 😄)
-
บันทึก "การตัดสินใจ" พร้อมประทับเวลาหรือเวอร์ชัน (มิเช่นนั้นจะเกิดความขัดแย้งขึ้นมากมาย)
-
อย่าเก็บความลับเว้นแต่คุณจำเป็นจริงๆ
และนี่คือคำอุปมาที่ไม่สมบูรณ์แบบของผม: ความทรงจำก็เหมือนตู้เย็น ถ้าคุณไม่เคยทำความสะอาดมันเลย ในที่สุดแซนด์วิชของคุณก็จะรสชาติเหมือนหัวหอมและความเสียใจ.
9) รูปแบบการวางแผน (จากแบบง่ายไปจนถึงแบบซับซ้อน) 🧭✨
การวางแผนก็คือการแบ่งส่วนอย่างเป็นระบบ อย่าทำให้มันเป็นเรื่องลึกลับเลย.
แบบ A: สมุดวางแผนแบบเช็คลิสต์ ✅
-
แบบจำลองจะแสดงรายการขั้นตอนออกมา
-
ดำเนินการทีละขั้นตอน
-
อัปเดตสถานะรายการตรวจสอบ
เหมาะสำหรับกระบวนการเริ่มต้นใช้งาน เรียบง่าย ทดสอบได้.
รูปแบบ B: วงจร ReAct (เหตุผล + การกระทำ) 🧠→🧰
-
โมเดลจะตัดสินใจเรียกใช้เครื่องมือถัดไป
-
สังเกตผลลัพธ์
-
ทำซ้ำ เอกสาร ReAct
นี่คือความรู้สึกแบบสายลับคลาสสิก.
รูปแบบ C: หัวหน้างาน-ลูกน้อง 👥
-
หัวหน้างานแบ่งเป้าหมายออกเป็นงานย่อย
-
พนักงานปฏิบัติงานเฉพาะด้าน
-
หัวหน้างานรวมผลลัพธ์ ของ Microsoft AutoGen (เฟรมเวิร์กแบบหลายเอเจนต์)
สิ่งนี้มีประโยชน์เมื่อสามารถทำงานแบบขนานได้ หรือเมื่อคุณต้องการ "บทบาท" ที่แตกต่างกัน เช่น:
-
นักวิจัย
-
โปรแกรมเมอร์
-
บรรณาธิการ
-
ผู้ตรวจสอบคุณภาพ
รูปแบบ D: วางแผนแล้วลงมือทำ พร้อมปรับแผนใหม่ 🔄
-
สร้างแผน
-
ดำเนินการ
-
หากผลลัพธ์จากเครื่องมือเปลี่ยนแปลงความเป็นจริง ให้วางแผนใหม่
วิธีนี้ช่วยป้องกันไม่ให้ตัวแทนดื้อรั้นทำตามแผนที่ผิดพลาด มนุษย์ก็ทำเช่นนี้เช่นกัน เว้นแต่ว่าพวกเขาจะเหนื่อยล้า ซึ่งในกรณีนั้นพวกเขาก็จะทำตามแผนที่ผิดพลาดเช่นกัน.
10) ความปลอดภัย ความน่าเชื่อถือ และการไม่ถูกไล่ออก 🔐😅
หากตัวแทนของคุณสามารถดำเนินการได้ คุณจำเป็นต้องมีการออกแบบด้านความปลอดภัย ไม่ใช่แค่สิ่งที่ "ควรมี" แต่เป็นสิ่งที่จำเป็น ตามมาตรฐาน NIST AI RMF 1.0
ข้อจำกัดที่เข้มงวด
-
จำนวนก้าวสูงสุดต่อการวิ่ง
-
จำนวนการเรียกใช้เครื่องมือสูงสุดต่อนาที
-
วงเงินใช้จ่ายสูงสุดต่อเซสชั่น (งบประมาณโทเค็น)
-
เครื่องมือที่ถูกจำกัดซึ่งต้องได้รับการอนุมัติ
การจัดการข้อมูล
-
ลบข้อมูลที่ละเอียดอ่อนออกก่อนบันทึก
-
สภาพแวดล้อมที่แยกจากกัน (สภาพแวดล้อมการพัฒนาเทียบกับสภาพแวดล้อมการใช้งานจริง)
-
สิทธิ์การใช้งานเครื่องมือแบบจำกัดสิทธิ์ขั้นต่ำ
ข้อจำกัดทางพฤติกรรม
-
บังคับให้ตัวแทนอ้างอิงเฉพาะส่วนของหลักฐานภายใน (ไม่ใช่ลิงก์ภายนอก แต่เป็นข้อมูลอ้างอิงภายในเท่านั้น)
-
จำเป็นต้องติดธงแสดงความไม่แน่นอนเมื่อความเชื่อมั่นต่ำ
-
หากข้อมูลที่ป้อนเข้ามาไม่ชัดเจน ให้ระบุว่า “ถามคำถามเพื่อความชัดเจน”
ตัวแทนที่น่าเชื่อถือไม่ใช่ตัวแทนที่มั่นใจที่สุด แต่เป็นตัวแทนที่รู้ว่าเมื่อใดที่กำลังเดา...และบอกออกมาตรงๆ.
11) การทดสอบและการประเมินผล (ส่วนที่ทุกคนหลีกเลี่ยง) 🧪📏
คุณไม่สามารถปรับปรุงสิ่งที่คุณวัดไม่ได้ ใช่แล้ว ประโยคนี้ฟังดูเชย แต่ก็เป็นความจริงที่น่ารำคาญ.
สร้างชุดสถานการณ์
สร้างกรณีทดสอบ 30-100 กรณี:
-
เส้นทางแห่งความสุข
-
กรณีพิเศษ
-
กรณี “เครื่องมือทำงานล้มเหลว”
-
คำขอที่ไม่ชัดเจน
-
ข้อความแจ้งเตือนที่เป็นอันตราย (ความพยายามในการแทรกข้อความแจ้งเตือน) OWASP Top 10 สำหรับแอปพลิเคชัน LLM OWASP LLM01 การแทรกข้อความแจ้งเตือน
ผลคะแนน
ใช้ตัวชี้วัดต่างๆ เช่น:
-
อัตราความสำเร็จของงาน
-
ระยะเวลาดำเนินการ
-
อัตราการแก้ไขข้อผิดพลาดของเครื่องมือ
-
อัตราการเกิดภาพหลอน (ข้อกล่าวอ้างที่ไม่มีหลักฐาน)
-
อัตราการอนุมัติของมนุษย์ (หากอยู่ในโหมดควบคุมดูแล)
การทดสอบการถดถอยสำหรับข้อความแจ้งเตือนและเครื่องมือ
ทุกครั้งที่คุณเปลี่ยน:
-
แผนผังเครื่องมือ
-
คำแนะนำระบบ
-
ตรรกะการเรียกค้น
-
รูปแบบหน่วยความจำ
เรียกใช้ชุดโปรแกรมอีกครั้ง
ตัวแทนเป็นสิ่งมีชีวิตที่อ่อนไหวมาก เหมือนต้นไม้ในบ้าน แต่แพงกว่า.
12) รูปแบบการใช้งานที่ไม่ทำให้งบประมาณของคุณบานปลาย 💸🔥
เริ่มต้นด้วยบริการเดียว
-
API ตัวควบคุมเอเจนต์
-
บริการเครื่องมือที่อยู่เบื้องหลัง
-
การบันทึกและติดตาม ผล คู่มือเบื้องต้นเกี่ยวกับความสามารถในการสังเกตการณ์ของ OpenTelemetry
ควรเพิ่มมาตรการควบคุมต้นทุนตั้งแต่เนิ่นๆ
-
ผลลัพธ์การดึงข้อมูลแคช
-
การบีบอัดสถานะการสนทนาด้วยบทสรุป
-
โดยใช้โมเดลขนาดเล็กกว่าสำหรับการกำหนดเส้นทางและการดึงข้อมูล
-
จำกัดการใช้ “โหมดคิดอย่างลึกซึ้ง” เฉพาะในขั้นตอนที่ยากที่สุดเท่านั้น
ทางเลือกทางสถาปัตยกรรมทั่วไป
-
ตัวควบคุมแบบไร้สถานะ + ที่เก็บสถานะภายนอก (ฐานข้อมูล/Redis)
-
การเรียกใช้เครื่องมือเป็นแบบ Idempotent เท่าที่เป็นไปได้ Stripe “คำขอแบบ Idempotent”
-
จัดคิวสำหรับงานที่ใช้เวลานาน (เพื่อไม่ให้คำขอเว็บค้างอยู่นานเกินไป)
นอกจากนี้: ควรติดตั้ง "สวิตช์ตัดไฟ" ด้วย คุณจะไม่จำเป็นต้องใช้มันจนกว่าคุณจะจำเป็นจริงๆ 😬
13) ข้อสรุป - ฉบับย่อเกี่ยวกับวิธีการสร้างเอเจนต์ AI 🎁🤖
หากคุณจำอะไรไม่ได้เลย ขอให้จำสิ่งนี้ไว้:
-
วิธีการสร้างเอเจนต์ AI นั้นส่วนใหญ่เกี่ยวกับการสร้างวงจรการทำงานที่ปลอดภัยรอบๆ โมเดล เอกสาร "เอเจนต์" ของ LangChain
-
เริ่มต้นด้วยเป้าหมายที่ชัดเจน ความเป็นอิสระต่ำ และเครื่องมือที่เข้มงวด OpenAI Structured Outputs
-
เพิ่มความจำผ่านการเรียกใช้ข้อมูล ไม่ใช่การยัดเยียดบริบทอย่างไม่รู้จบ ( เอกสาร RAG
-
การวางแผนนั้นทำได้ง่ายๆ เพียงแค่ใช้รายการตรวจสอบและวางแผนใหม่ก็เพียงพอแล้ว.
-
การบันทึกและการทดสอบจะเปลี่ยนความวุ่นวายของเอเจนต์ให้กลายเป็นสิ่งที่สามารถนำไปใช้งานได้ คู่มือเบื้องต้นเกี่ยวกับระบบตรวจสอบของ OpenTelemetry
-
กลไกควบคุมควรอยู่ในโค้ด ไม่ใช่แค่ในข้อความแจ้งเตือน OWASP Top 10 สำหรับแอปพลิเคชัน LLM
เอเจนต์ไม่ใช่เวทมนตร์ มันเป็นระบบที่ตัดสินใจได้ดีบ่อยครั้งจนมีคุณค่า...และยอมรับความพ่ายแพ้ก่อนที่จะก่อให้เกิดความเสียหาย ในแง่หนึ่งมันก็ให้ความรู้สึกสบายใจดีนะ 😌
ใช่แล้ว ถ้าคุณสร้างมันให้ดี มันจะให้ความรู้สึกเหมือนจ้างเด็กฝึกงานดิจิทัลตัวเล็กๆ ที่ไม่เคยนอนหลับ บางครั้งก็ตื่นตระหนก และชอบงานเอกสาร พูดง่ายๆ ก็คือเหมือนเด็กฝึกงานนั่นแหละ.
คำถามที่พบบ่อย
โดยสรุปแล้ว เอージェนต์ AI คืออะไร?
โดยพื้นฐานแล้ว เอเจนต์ AI คือวงจรที่ทำงานซ้ำๆ: รับข้อมูลเข้า ตัดสินใจขั้นตอนต่อไป ใช้เครื่องมือ อ่านผลลัพธ์ และทำซ้ำจนกว่าจะเสร็จสิ้น ส่วนคำว่า "เอเจนต์" มาจากการกระทำและการสังเกต ไม่ใช่แค่การพูดคุย เอเจนต์หลายตัวเป็นเพียงระบบอัตโนมัติอัจฉริยะที่สามารถเข้าถึงเครื่องมือได้ ในขณะที่บางตัวมีพฤติกรรมคล้ายกับผู้ปฏิบัติงานรุ่นเยาว์ที่สามารถแก้ไขข้อผิดพลาดได้.
ฉันควรสร้างเอเจนต์ AI แทนการใช้แค่คำสั่งสำเร็จรูปเมื่อใด?
สร้างเอเจนต์เมื่องานมีหลายขั้นตอน เปลี่ยนแปลงตามผลลัพธ์ระหว่างทาง และต้องการใช้เครื่องมือที่เชื่อถือได้ (API, ฐานข้อมูล, ระบบออกตั๋ว, การเรียกใช้โค้ด) เอเจนต์ยังมีประโยชน์เมื่อคุณต้องการผลลัพธ์ที่ทำซ้ำได้ พร้อมข้อจำกัด และวิธีการตรวจสอบว่า "เสร็จสมบูรณ์" แล้ว หากการตอบกลับแบบง่ายๆ ก็เพียงพอแล้ว เอเจนต์มักจะเป็นภาระที่ไม่จำเป็นและเป็นโหมดความล้มเหลวเพิ่มเติม.
ฉันจะสร้างเอเจนต์ AI ที่ไม่ติดอยู่ในวงวนได้อย่างไร?
ใช้เงื่อนไขการหยุดที่เข้มงวด: จำนวนขั้นตอนสูงสุด จำนวนการเรียกใช้เครื่องมือสูงสุด และตรวจสอบความสำเร็จที่ชัดเจน เพิ่มโครงสร้างแบบแผนของเครื่องมือ การหมดเวลา และการลองใหม่ที่จะไม่ลองใหม่ไปเรื่อยๆ บันทึกการตัดสินใจและผลลัพธ์ของเครื่องมือเพื่อให้คุณเห็นว่าเกิดข้อผิดพลาดที่จุดใด กลไกความปลอดภัยทั่วไปคือการยกระดับ: หากเจ้าหน้าที่ไม่แน่ใจหรือทำผิดซ้ำ ควรขอความช่วยเหลือแทนที่จะแก้ไขด้วยตนเอง.
สถาปัตยกรรมขั้นต่ำสำหรับการสร้างเอเจนต์ AI คืออะไร?
อย่างน้อยที่สุด คุณต้องมีลูปควบคุมที่ป้อนเป้าหมายและบริบทให้กับโมเดล ถามถึงการกระทำถัดไป เรียกใช้เครื่องมือหากมีการร้องขอ เพิ่มข้อมูลที่สังเกตได้ และทำซ้ำ คุณยังต้องการเครื่องมือที่มีรูปแบบอินพุต/เอาต์พุตที่เข้มงวดและมีการตรวจสอบ "เสร็จสิ้น" แม้แต่ลูปที่คุณสร้างขึ้นเองก็สามารถใช้งานได้ดีหากคุณรักษาความสะอาดของสถานะและบังคับใช้ขีดจำกัดของขั้นตอน.
ฉันควรออกแบบการเรียกใช้เครื่องมืออย่างไรเพื่อให้มีความน่าเชื่อถือในการใช้งานจริง?
ควรจำกัดขอบเขตของเครื่องมือให้แคบ กำหนดประเภท กำหนดสิทธิ์ และตรวจสอบความถูกต้อง หลีกเลี่ยงเครื่องมือแบบ "ทำได้ทุกอย่าง" ทั่วไป ควรใช้รูปแบบข้อมูลที่เข้มงวด (เช่น เอาต์พุตที่มีโครงสร้าง/การเรียกฟังก์ชัน) เพื่อป้องกันไม่ให้เอเจนต์สามารถกำหนดข้อมูลป้อนเข้าแบบง่ายๆ ได้ เพิ่มรายการอนุญาต การจำกัดอัตรา และการตรวจสอบสิทธิ์ของผู้ใช้/องค์กรในระดับเครื่องมือ ออกแบบเครื่องมือให้ปลอดภัยต่อการเรียกใช้งานซ้ำเมื่อเป็นไปได้ โดยใช้รูปแบบการทำงานซ้ำได้โดยไม่ส่งผลซ้ำซ้อน.
วิธีที่ดีที่สุดในการเพิ่มหน่วยความจำโดยไม่ทำให้ประสิทธิภาพของเอเจนต์ลดลงคืออะไร?
ควรแบ่งหน่วยความจำออกเป็นสองส่วน: สถานะการทำงานระยะสั้น (ขั้นตอนล่าสุด แผนปัจจุบัน ข้อจำกัด) และการเรียกใช้ข้อมูลระยะยาว (การตั้งค่า กฎที่คงที่ เอกสารที่เกี่ยวข้อง) สำหรับหน่วยความจำระยะสั้น ควรเก็บข้อมูลสรุปแบบย่อๆ ไว้ ไม่ใช่บันทึกการทำงานทั้งหมด ส่วนหน่วยความจำระยะยาว การเรียกใช้ข้อมูล (การฝังข้อมูล + ที่เก็บเวกเตอร์/รูปแบบ RAG) มักจะดีกว่าการ "ยัด" ทุกอย่างเข้าไปในบริบทและทำให้โมเดลสับสน.
ฉันควรใช้รูปแบบการวางแผนแบบใด: แบบเช็คลิสต์, แบบ ReAct หรือแบบหัวหน้างาน-ลูกน้อง?
เครื่องมือวางแผนแบบเช็คลิสต์นั้นยอดเยี่ยมเมื่อภารกิจสามารถคาดเดาได้และคุณต้องการสิ่งที่ทดสอบได้ง่าย ลูปแบบ ReAct นั้นโดดเด่นเมื่อผลลัพธ์จากเครื่องมือเปลี่ยนแปลงสิ่งที่คุณต้องทำต่อไป รูปแบบการแบ่งบทบาทระหว่างหัวหน้างานและผู้ปฏิบัติงาน (เช่น การแบ่งบทบาทแบบ AutoGen) ช่วยได้เมื่อภารกิจสามารถทำพร้อมกันได้หรือได้รับประโยชน์จากบทบาทที่แตกต่างกัน (นักวิจัย นักเขียนโค้ด ผู้ทดสอบคุณภาพ) การวางแผนแล้วดำเนินการโดยมีการวางแผนใหม่เป็นทางออกที่ใช้งานได้จริงเพื่อหลีกเลี่ยงแผนที่ไม่ดีซึ่งแก้ไขได้ยาก.
ฉันจะทำให้เอเจนต์ปลอดภัยได้อย่างไร หากมันสามารถกระทำการจริงได้?
ใช้สิทธิ์การเข้าถึงแบบจำกัดสิทธิ์ขั้นต่ำ และจำกัดการใช้งานเครื่องมือที่มีความเสี่ยงไว้หลังการอนุมัติหรือโหมด "ทดสอบก่อนใช้งานจริง" เพิ่มงบประมาณและขีดจำกัด: จำนวนขั้นตอนสูงสุด ค่าใช้จ่ายสูงสุด และขีดจำกัดการเรียกใช้เครื่องมือต่อนาที ลบข้อมูลที่ละเอียดอ่อนออกก่อนบันทึก และแยกสภาพแวดล้อมการพัฒนาออกจากสภาพแวดล้อมการใช้งานจริง กำหนดให้มีการระบุสถานะความไม่แน่นอนหรือถามคำถามเพิ่มเติมเมื่อข้อมูลป้อนเข้าไม่ชัดเจน แทนที่จะปล่อยให้ความมั่นใจเข้ามาแทนที่หลักฐาน.
ฉันจะทดสอบและประเมินผลเอージェนต์ AI อย่างไรเพื่อให้มันพัฒนาขึ้นเรื่อยๆ?
สร้างชุดสถานการณ์จำลองที่ประกอบด้วยกรณีที่ทุกอย่างราบรื่น กรณีพิเศษ ความล้มเหลวของเครื่องมือ คำขอที่ไม่ชัดเจน และความพยายามในการแทรกข้อความแจ้งเตือน (แบบ OWASP) ให้คะแนนผลลัพธ์ เช่น ความสำเร็จของงาน เวลาที่ใช้ในการทำงาน การแก้ไขข้อผิดพลาดของเครื่องมือ และการกล่าวอ้างที่ไม่มีหลักฐาน ทุกครั้งที่คุณเปลี่ยนแปลงรูปแบบเครื่องมือ ข้อความแจ้งเตือน การดึงข้อมูล หรือการจัดรูปแบบหน่วยความจำ ให้เรียกใช้ชุดสถานการณ์จำลองอีกครั้ง หากคุณไม่สามารถทดสอบได้ คุณก็ไม่สามารถส่งมอบผลิตภัณฑ์ได้อย่างน่าเชื่อถือ.
ฉันจะติดตั้งเอเจนต์โดยไม่ทำให้ความหน่วงและค่าใช้จ่ายเพิ่มสูงขึ้นได้อย่างไร?
รูปแบบทั่วไปคือคอนโทรลเลอร์แบบไร้สถานะที่มีที่เก็บสถานะภายนอก (ฐานข้อมูล/Redis) บริการเครื่องมืออยู่เบื้องหลัง และระบบบันทึก/ตรวจสอบที่มีประสิทธิภาพ (มักใช้ OpenTelemetry) ควบคุมต้นทุนด้วยการแคชการเรียกค้นข้อมูล สรุปสถานะที่กระชับ โมเดลขนาดเล็กสำหรับการกำหนดเส้นทาง/การดึงข้อมูล และจำกัด "การคิดเชิงลึก" ไว้เฉพาะขั้นตอนที่ยากที่สุด ใช้คิวสำหรับงานที่ใช้เวลานานเพื่อไม่ให้เว็บรีเควสต์ค้างอยู่ และควรมีสวิตช์ปิดการทำงานเสมอ.
เอกสารอ้างอิง
-
สถาบันมาตรฐานและเทคโนโลยีแห่งชาติ (NIST) - NIST AI RMF 1.0 (ความน่าเชื่อถือและความโปร่งใส) - nvlpubs.nist.gov
-
OpenAI - ผลลัพธ์ที่มีโครงสร้าง - platform.openai.com
-
OpenAI - คู่มือการเรียกใช้ฟังก์ชัน - platform.openai.com
-
OpenAI - คู่มือการจำกัดอัตราการใช้งาน - platform.openai.com
-
OpenAI - รัน API - platform.openai.com
-
OpenAI - การเรียกใช้งานฟังก์ชันผู้ช่วย - platform.openai.com
-
LangChain - เอกสารเกี่ยวกับเอเจนต์ (JavaScript) - docs.langchain.com
-
LangChain - เอกสารเครื่องมือ (Python) - docs.langchain.com
-
LangChain - ภาพรวมหน่วยความจำ - docs.langchain.com
-
arXiv - บทความ ReAct (เหตุผล + การกระทำ) - arxiv.org
-
arXiv - บทความ RAG - arxiv.org
-
คลังเครื่องมือสร้างระบบของ Amazon Web Services (AWS) - การหมดเวลา การลองใหม่ และการหน่วงเวลาพร้อมความผันผวน - aws.amazon.com
-
OpenTelemetry - คู่มือเบื้องต้นเกี่ยวกับระบบตรวจสอบการทำงาน - opentelemetry.io
-
Stripe - คำขอที่ไม่เปลี่ยนแปลงผลลัพธ์ (Idempotent requests) - docs.stripe.com
-
Google Cloud - กลยุทธ์การลองใหม่ (backoff + jitter) - docs.cloud.google.com
-
OWASP - 10 อันดับแรกสำหรับแอปพลิเคชันโมเดลภาษาขนาดใหญ่ - owasp.org
-
OWASP - LLM01 Prompt Injection - genai.owasp.org
-
LlamaIndex - บทนำเกี่ยวกับ RAG - developers.llamaindex.ai
-
ไมโครซอฟต์ - เคอร์เนลเชิงความหมาย - ที่ learn.microsoft.com
-
Microsoft AutoGen - เฟรมเวิร์กแบบหลายเอเจนต์ (เอกสารประกอบ) - microsoft.github.io
-
CrewAI - แนวคิดเกี่ยวกับเอเจนต์ - docs.crewai.com
-
Haystack (deepset) - เอกสารประกอบการใช้งาน Retrievers - docs.haystack.deepset.ai