ai-agents-for-beginners
ตัวแทน AI ในการผลิต: การสังเกตการณ์และการประเมินผล
ในขณะที่ตัวแทน AI ก้าวจากต้นแบบทดลองไปสู่แอปพลิเคชันในโลกจริง ความสามารถในการเข้าใจพฤติกรรมของพวกเขา ตรวจสอบประสิทธิภาพ และประเมินผลลัพธ์อย่างเป็นระบบจึงกลายเป็นเรื่องสำคัญ
เป้าหมายการเรียนรู้
หลังจากเรียนบทนี้จบ คุณจะรู้จัก/เข้าใจ:
- แนวคิดหลักของการสังเกตการณ์และการประเมินผลตัวแทน
- เทคนิคสำหรับปรับปรุงประสิทธิภาพ ต้นทุน และประสิทธิผลของตัวแทน
- สิ่งที่ควรประเมินและวิธีการประเมินตัวแทน AI อย่างเป็นระบบ
- วิธีควบคุมต้นทุนเมื่อนำตัวแทน AI ไปใช้งานจริง
- วิธีการติดตั้งเครื่องมือสำหรับตัวแทนที่สร้างด้วย Microsoft Agent Framework
เป้าหมายคือการให้ความรู้แก่คุณเพื่อแปลงตัวแทน “กล่องดำ” ให้กลายเป็นระบบที่โปร่งใส จัดการง่าย และน่าเชื่อถือ
หมายเหตุ: เป็นเรื่องสำคัญที่จะนำตัวแทน AI ที่ปลอดภัยและน่าเชื่อถือเข้าสู่ระบบ โปรดดูบทเรียน Building Trustworthy AI Agents ด้วย
Traces และ Spans
เครื่องมือสังเกตการณ์เช่น Langfuse หรือ Microsoft Foundry มักจะแสดงการทำงานของตัวแทนเป็น traces และ spans
- Trace แทนงานตัวแทนทั้งหมดตั้งแต่ต้นจนจบ (เช่น การจัดการคำถามของผู้ใช้)
- Spans คือขั้นตอนย่อยใน trace (เช่น การเรียกใช้โมเดลภาษา หรือนำข้อมูลมา)
หากไม่มีการสังเกตการณ์ ตัวแทน AI อาจรู้สึกเหมือน “กล่องดำ” - สถานะภายในและกระบวนการคิดไม่โปร่งใส ทำให้ยากต่อการวิเคราะห์ปัญหาหรือปรับปรุงประสิทธิภาพ แต่ด้วยการสังเกตการณ์ ตัวแทนจะกลายเป็น “กล่องแก้ว” ซึ่งเปิดเผยให้เห็นอย่างโปร่งใส ซึ่งสำคัญต่อการสร้างความน่าเชื่อถือและมั่นใจว่าทำงานตามที่ตั้งใจไว้
ทำไมการสังเกตการณ์จึงสำคัญในสภาพแวดล้อมการผลิต
การย้ายตัวแทน AI ไปยังสภาพแวดล้อมการผลิตนำมาซึ่งความท้าทายและข้อกำหนดใหม่ ๆ การสังเกตการณ์ไม่ใช่แค่สิ่งที่ “ดีที่จะมี” แต่เป็นความสามารถที่สำคัญ:
- การดีบักและวิเคราะห์สาเหตุหลัก: เมื่อเกิดข้อผิดพลาดหรือตัวแทนให้ผลลัพธ์ที่ไม่คาดคิด เครื่องมือสังเกตการณ์จะให้ traces ที่จำเป็นเพื่อระบุแหล่งที่มาของข้อผิดพลาด นี่สำคัญมากในตัวแทนที่ซับซ้อนซึ่งอาจมีการเรียกใช้ LLM หลายครั้ง การโต้ตอบกับเครื่องมือ และตรรกะตามเงื่อนไข
- การจัดการความหน่วงและต้นทุน: ตัวแทน AI มักพึ่งพา LLM และ API ภายนอกซึ่งถูกคิดค่าบริการตามจำนวน token หรือการเรียกใช้ การสังเกตการณ์ช่วยติดตามการเรียกใช้งานเหล่านี้อย่างแม่นยำ เพื่อหาการดำเนินการที่ช้าหรือแพงเกินไป ทำให้ทีมสามารถปรับปรุง prompt เลือกโมเดลที่มีประสิทธิภาพมากกว่า หรือตั้งค่ากระบวนการทำงานใหม่ โดยควบคุมต้นทุนและสร้างประสบการณ์ผู้ใช้ที่ดี
- ความน่าเชื่อถือ ความปลอดภัย และการปฏิบัติตามข้อกำหนด: ในแอปพลิเคชันหลายประเภท การรับรองว่าตัวแทนทำงานอย่างปลอดภัยและถูกต้องตามจริยธรรมเป็นสิ่งสำคัญ การสังเกตการณ์ช่วยให้มีร่องรอยการตรวจสอบการดำเนินการและการตัดสินใจของตัวแทน ซึ่งช่วยตรวจจับและลดปัญหาเช่น การแทรกแซง prompt การสร้างเนื้อหาที่เป็นอันตราย หรือการจัดการข้อมูลส่วนบุคคลอย่างผิดพลาด ตัวอย่างเช่น คุณสามารถตรวจสอบ traces เพื่อเข้าใจว่าทำไมตัวแทนจึงตอบสนองแบบนั้นหรือใช้เครื่องมือใดเครื่องมือหนึ่ง
- วงจรปรับปรุงอย่างต่อเนื่อง: ข้อมูลการสังเกตการณ์เป็นฐานของกระบวนการพัฒนาแบบวนซ้ำ โดยการติดตามการทำงานของตัวแทนในโลกจริง ทีมสามารถระบุพื้นที่ที่ต้องพัฒนา รวบรวมข้อมูลสำหรับการปรับแต่งโมเดล และตรวจสอบผลกระทบของการเปลี่ยนแปลง สร้างวงจรป้อนกลับที่ข้อมูลเชิงลึกจากการประเมินผลออนไลน์ช่วยพัฒนาการทดลองและปรับปรุงแบบออฟไลน์ ทำให้ประสิทธิภาพตัวแทนดีขึ้นเรื่อยๆ
ตัวชี้วัดสำคัญที่ควรติดตาม
เพื่อเฝ้าติดตามและเข้าใจพฤติกรรมของตัวแทน ควรติดตามตัวชี้วัดและสัญญาณหลายตัว แม้ว่าตัวชี้วัดเฉพาะอาจแตกต่างกันตามวัตถุประสงค์ของตัวแทน แต่บางตัวชี้วัดถือว่าสำคัญสากล
นี่คือตัวชี้วัดที่เครื่องมือสังเกตการณ์มักติดตาม:
ความหน่วง: ตัวแทนตอบสนองเร็วแค่ไหน? เวลารอนานส่งผลเสียต่อประสบการณ์ผู้ใช้ คุณควรวัดความหน่วงของงานและแต่ละขั้นตอนด้วยการติดตามการทำงานของตัวแทน เช่น ตัวแทนที่ใช้เวลารวม 20 วินาทีในการเรียกโมเดลทุกครั้ง อาจเร่งความเร็วโดยใช้โมเดลที่เร็วกว่า หรือตั้งให้เรียกโมเดลพร้อมกัน
ต้นทุน: ค่าใช้จ่ายต่อการทำงานของตัวแทนเท่าไร? ตัวแทน AI มักเรียก LLM ซึ่งคิดค่าบริการตาม token หรือ API ภายนอก การใช้เครื่องมือบ่อยหรือ prompt หลายครั้งอาจทำให้ต้นทุนเพิ่มขึ้นอย่างรวดเร็ว เช่น ถ้าตัวแทนเรียก LLM ห้าครั้งเพื่อปรับปรุงคุณภาพเล็กน้อย คุณต้องประเมินว่าคุ้มค่าหรือไม่ หรือลดจำนวนการเรียกใช้หรือตัวเลือกโมเดลที่ถูกกว่า การติดตามเรียลไทม์ช่วยระบุจุดที่ค่าใช้จ่ายพุ่งสูงผิดปกติ (เช่น bug ที่ทำให้เกิดลูป API ซ้ำซ้อน)
ข้อผิดพลาดของคำขอ: ตัวแทนล้มเหลวกี่คำขอ? ได้แก่ ข้อผิดพลาด API หรือการเรียกใช้เครื่องมือที่ล้มเหลว เพื่อทำให้ตัวแทนมีความแข็งแรงมากขึ้นในสภาพแวดล้อมการผลิต คุณสามารถตั้งค่าการ fallback หรือ retry เช่น ถ้า LLM provider A ล่ม ให้สลับไปใช้ LLM provider B แทน
ข้อเสนอแนะจากผู้ใช้: การประเมินโดยตรงจากผู้ใช้ช่วยให้ข้อมูลเชิงลึก เช่น คะแนนชอบ/ไม่ชอบ (👍/👎, ⭐1-5 ดาว) หรือความคิดเห็นเป็นข้อความ ข้อเสนอแนะเชิงลบอย่างต่อเนื่องควรเป็นสัญญาณเตือนว่าสิ่งที่ตัวแทนทำไม่เป็นไปตามที่คาดหวัง
ข้อเสนอแนะจากพฤติกรรมผู้ใช้: พฤติกรรมผู้ใช้เป็นฟีดแบ็กทางอ้อม แม้ไม่ต้องมีการให้คะแนน เช่น การเปลี่ยนคำถามทันที การถามซ้ำ หรือการคลิกปุ่ม retry เช่น ถ้าคุณเห็นผู้ใช้ถามคำถามเดิมซ้ำ ๆ นี่คือสัญญาณว่าตัวแทนทำงานผิดพลาด
ความถูกต้อง: ตัวแทนสร้างผลลัพธ์ที่ถูกหรือเหมาะสมบ่อยแค่ไหน? นิยามของความถูกต้องแตกต่างกัน (เช่น ความถูกต้องในการแก้ปัญหา การค้นคืนข้อมูล หรือความพึงพอใจของผู้ใช้) ขั้นแรกคือกำหนดความสำเร็จของตัวแทน คุณสามารถติดตามความถูกต้องผ่านการตรวจสอบอัตโนมัติ คะแนนประเมิน หรือป้ายกำกับการทำงานเสร็จ เช่น การทำเครื่องหมาย trace ว่า “สำเร็จ” หรือ “ล้มเหลว”
ตัวชี้วัดประเมินอัตโนมัติ: คุณสามารถตั้ง automated evals ได้ เช่น ใช้ LLM ให้คะแนนผลลัพธ์ของตัวแทนว่าช่วยได้ ถูกต้อง หรือไม่ มีไลบรารีโอเพนซอร์สหลายตัวช่วยให้คุณให้คะแนนแง่มุมต่าง ๆ ของตัวแทน เช่น RAGAS สำหรับตัวแทน RAG หรือ LLM Guard สำหรับตรวจจับภาษาที่เป็นอันตรายหรือการแทรกแซง prompt
ในทางปฏิบัติ การรวมตัวชี้วัดเหล่านี้ช่วยให้ครอบคลุมสถานะสุขภาพของตัวแทน AI ได้ดีที่สุด ใน notebook ตัวอย่าง ในบทนี้ เราจะแสดงให้เห็นว่าตัวชี้วัดเหล่านี้เป็นอย่างไรในตัวอย่างจริง แต่ก่อนอื่นเราจะเรียนรู้ว่ากระบวนการประเมินแบบทั่วไปเป็นอย่างไร
การติดตั้งเครื่องมือในตัวแทนของคุณ
เพื่อเก็บข้อมูลการติดตาม คุณจะต้องติดตั้งเครื่องมือในโค้ด เป้าหมายคือให้โค้ดตัวแทนสร้าง traces และ metrics ที่สามารถจับเก็บ ประมวลผล และแสดงผลโดยแพลตฟอร์มสังเกตการณ์
OpenTelemetry (OTel): OpenTelemetry ได้กลายเป็นมาตรฐานอุตสาหกรรมสำหรับการสังเกตการณ์ LLM โดยให้ชุด API, SDK และเครื่องมือสำหรับสร้าง เก็บ และส่งออกข้อมูล telemetry
มีไลบรารีการติดตั้งเครื่องมือหลายตัวที่พันรอบเฟรมเวิร์กตัวแทนที่มีอยู่และทำให้ง่ายต่อการส่งออก spans ของ OpenTelemetry ไปยังเครื่องมือสังเกตการณ์ Microsoft Agent Framework รองรับ OpenTelemetry โดยตรง ด้านล่างคือตัวอย่างการติดตั้งเครื่องมือในตัวแทน MAF:
from agent_framework.observability import get_tracer, get_meter
tracer = get_tracer()
meter = get_meter()
with tracer.start_as_current_span("agent_run"):
# การดำเนินการของเอเย่นต์จะถูกติดตามโดยอัตโนมัติ
pass
notebook ตัวอย่าง ในบทนี้จะแสดงวิธีการติดตั้งเครื่องมือในตัวแทน MAF ของคุณ
การสร้าง Span ด้วยตนเอง: แม้ไลบรารีการติดตั้งจะมีพื้นฐานที่ดี แต่บ่อยครั้งจำเป็นต้องมีข้อมูลเฉพาะหรือรายละเอียดเพิ่มเติม คุณสามารถสร้าง spans ด้วยตนเองเพื่อเพิ่มตรรกะแอปพลิเคชันแบบกำหนดเอง และสำคัญกว่านั้น สามารถเสริม spans ที่สร้างโดยอัตโนมัติหรือด้วยมือด้วยแอตทริบิวต์แบบกำหนดเอง (หรือที่เรียกว่าแท็กหรือข้อมูลเมตา) ซึ่งอาจรวมถึงข้อมูลเฉพาะธุรกิจ การคำนวณขั้นกลาง หรือบริบทที่เป็นประโยชน์สำหรับการดีบักหรือวิเคราะห์ เช่น user_id, session_id หรือ model_version
ตัวอย่างการสร้าง traces และ spans ด้วยตนเองโดยใช้ Langfuse Python SDK:
from langfuse import get_client
langfuse = get_client()
span = langfuse.start_span(name="my-span")
span.end()
การประเมินตัวแทน
การสังเกตการณ์ให้ตัวชี้วัด แต่การประเมินคือกระบวนการวิเคราะห์ข้อมูลนั้น (และทำการทดสอบ) เพื่อกำหนดว่าตัวแทน AI ทำงานได้ดีแค่ไหนและจะปรับปรุงอย่างไร กล่าวคือ เมื่อคุณมี traces และตัวชี้วัดแล้ว คุณจะใช้มันอย่างไรเพื่อตัดสินตัวแทนและตัดสินใจ
การประเมินอย่างสม่ำเสมอมีความสำคัญ เพราะตัวแทน AI มักไม่เป็นเชิงกำหนดและอาจเปลี่ยนแปลงได้ (ผ่านการอัปเดตหรือพฤติกรรมโมเดลที่เปลี่ยนไป) — ถ้าไม่มีการประเมิน คุณจะไม่รู้ว่า “ตัวแทนอัจฉริยะ” ของคุณทำงานดีจริงหรือถอยหลัง
มีสองประเภทของการประเมินสำหรับตัวแทน AI: การประเมินออนไลน์ และ การประเมินออฟไลน์ ทั้งสองมีคุณค่าและเสริมกัน โดยทั่วไปเราจะเริ่มจากการประเมินออฟไลน์เพราะเป็นขั้นตอนขั้นต่ำก่อนนำตัวแทนไปใช้จริง
การประเมินออฟไลน์
คือการประเมินตัวแทนในสภาพแวดล้อมที่ควบคุม โดยทั่วไปใช้ชุดข้อมูลทดสอบ ไม่ใช่คำถามผู้ใช้จริง คุณใช้ชุดข้อมูลคัดสรรที่รู้ว่าผลลัพธ์ที่คาดหวังคืออะไร หรือลักษณะการทำงานที่ถูกต้อง และนำตัวแทนไปทำงานกับข้อมูลเหล่านั้น
เช่น หากคุณสร้างตัวแทนแก้โจทย์เลข คุณอาจมี ชุดข้อมูลทดสอบ ที่มีโจทย์ 100 ข้อพร้อมคำตอบที่ทราบ การประเมินออฟไลน์มักทำในระหว่างการพัฒนา (และอาจเป็นส่วนของกระบวนการ CI/CD) เพื่อตรวจสอบการปรับปรุงหรือตรวจสอบไม่ให้เกิดการถอยหลัง ข้อดีคือมัน ทำซ้ำได้และให้ตัวชี้วัดความถูกต้องที่ชัดเจนเพราะมีความจริงพื้นฐาน คุณสามารถจำลองคำถามผู้ใช้และวัดคำตอบของตัวแทนกับคำตอบที่เหมาะสม หรือใช้ตัวชี้วัดอัตโนมัติที่กล่าวไว้ข้างต้น
ความท้าทายสำคัญของการประเมินออฟไลน์คือการมั่นใจว่าชุดทดสอบครอบคลุมและยังคงสอดคล้อง — ตัวแทนอาจทำงานดีในชุดทดสอบที่ตายตัวแต่เจอคำถามต่างกันมากในงานจริง ดังนั้นควรอัปเดตชุดข้อมูลทดสอบด้วยกรณีชายขอบและตัวอย่างใหม่ที่สะท้อนสถานการณ์จริง การผสมชุดเล็กสำหรับ “smoke test” อย่างรวดเร็วและชุดใหญ่สำหรับวัดประสิทธิภาพกว้าง ๆ จะเป็นประโยชน์
การประเมินออนไลน์
คือการประเมินตัวแทนในสถานการณ์ใช้งานจริงแบบสด เช่น ในการใช้งานจริงบนผลิตภัณฑ์ การประเมินออนไลน์เกี่ยวข้องกับการติดตามประสิทธิภาพของตัวแทนจากการโต้ตอบกับผู้ใช้จริงและวิเคราะห์ผลลัพธ์อย่างต่อเนื่อง
ตัวอย่างเช่น คุณอาจติดตามอัตราความสำเร็จ คะแนนความพึงพอใจของผู้ใช้ หรือตัวชี้วัดอื่น ๆ จากทราฟฟิกจริง ข้อดีของการประเมินออนไลน์คือมัน จับข้อมูลที่คุณอาจไม่คาดคิดในสภาพแล็บ — คุณสามารถสังเกตการเปลี่ยนแปลงของโมเดลเมื่อเวลาผ่านไป (ถ้าประสิทธิภาพของตัวแทนลดลงตามรูปแบบข้อมูลป้อนเข้าเปลี่ยน) และจับกรณีคำถามหรือสถานการณ์ที่ไม่อยู่ในชุดข้อมูลทดสอบ มันให้ภาพจริงว่าตัวแทนทำงานอย่างไรในโลกจริง
การประเมินออนไลน์มักเกี่ยวข้องกับการเก็บข้อเสนอแนะผู้ใช้ทั้งแบบปริยายและชัดเจนตามที่กล่าวไว้ และอาจรัน shadow tests หรือ A/B tests (ที่เวอร์ชันใหม่ของตัวแทนทำงานคู่ขนานเพื่อเปรียบเทียบกับเวอร์ชันเก่า) ท้าทายคือการหาป้ายกำกับหรือคะแนนที่เชื่อถือได้สำหรับโต้ตอบสดอาจยาก — คุณอาจต้องอาศัยฟีดแบ็กผู้ใช้หรือเมตริก downstream (เช่น ผู้ใช้คลิกรายการผลลัพธ์หรือไม่)
การผสมผสานระหว่างสองแบบ
การประเมินออนไลน์และออฟไลน์ไม่ได้เป็นทางเลือกเดียวกัน แต่เสริมกันอย่างสูง ข้อมูลเชิงลึกจากการเฝ้าดูออนไลน์ (เช่น ประเภทคำถามใหม่ที่ตัวแทนทำงานไม่ดี) สามารถนำไปปรับปรุงชุดข้อมูลทดสอบออฟไลน์ ในทางกลับกัน ตัวแทนที่ทำงานดีในชุดทดสอบออฟไลน์ก็สามารถนำไปใช้จริงและติดตามผลออนไลน์ได้อย่างมั่นใจ
แท้จริงแล้วหลายทีมใช้วงจร:
ประเมินออฟไลน์ -> นำไปใช้ -> เฝ้าติดตามออนไลน์ -> เก็บกรณีล้มเหลวใหม่ -> เพิ่มในชุดข้อมูลออฟไลน์ -> ปรับปรุงตัวแทน -> ทำซ้ำ
ปัญหาที่พบบ่อย
เมื่อคุณนำตัวแทน AI ไปใช้ในงานจริง อาจพบกับความท้าทายต่าง ๆ นี่คือปัญหาที่พบบ่อยและแนวทางแก้ไข
| ปัญหา | ทางแก้ไขที่เป็นไปได้ |
|---|---|
| ตัวแทน AI ทำงานไม่เสถียร | - ปรับปรุง prompt ที่มอบให้ตัวแทน ชัดเจนในเป้าหมาย - ระบุจุดที่แบ่งงานเป็นงานย่อย และใช้ตัวแทนหลายตัวช่วยกันจัดการ |
| ตัวแทน AI พบลูปต่อเนื่อง | - มีเงื่อนไขและข้อตกลงการหยุดที่ชัดเจนเพื่อให้ตัวแทนรู้ว่าเมื่อต้องหยุด - ในงานที่ซับซ้อนต้องใช้โมเดลขนาดใหญ่ที่เชี่ยวชาญด้านตรรกะและการวางแผน |
| การเรียกใช้เครื่องมือตัวแทน AI ไม่ทำงานดี | - ทดสอบและตรวจสอบผลลัพธ์ของเครื่องมืออยู่นอกระบบตัวแทน - ปรับปรุงพารามิเตอร์ prompt และชื่อของเครื่องมือ |
| ระบบหลายตัวแทนทำงานไม่เสถียร | - ปรับปรุง prompt ของตัวแทนแต่ละตัวให้เฉพาะเจาะจงและแตกต่างกัน - สร้างระบบลำดับชั้นโดยใช้ตัวแทน “routing” หรือ controller เพื่อตัดสินใจว่าตัวแทนใดเหมาะสม |
หลายปัญหานี้สามารถตรวจสอบได้มีประสิทธิภาพมากขึ้นด้วยการสังเกตการณ์ traces และ metrics ที่กล่าวไปข้างต้นจะช่วยระบุจุดเกิดปัญหาในเวิร์กโฟลว์ตัวแทน ช่วยให้การดีบักและปรับปรุงต้นแบบง่ายขึ้น
การจัดการต้นทุน
Here are some strategies to manage the costs of deploying AI agents to production:
Using Smaller Models: Small Language Models (SLMs) สามารถทำงานได้ดีในกรณีใช้งานแบบตัวแทนบางประเภท และจะช่วยลดค่าใช้จ่ายอย่างมาก ดังที่กล่าวไว้ก่อนหน้านี้ การสร้างระบบประเมินผลเพื่อกำหนดและเปรียบเทียบประสิทธิภาพกับโมเดลที่ใหญ่กว่าจะเป็นวิธีที่ดีที่สุดในการเข้าใจว่า SLM จะทำงานได้ดีเพียงใดในกรณีใช้งานของคุณ พิจารณาใช้ SLM สำหรับงานที่ง่ายกว่า เช่น การจำแนกเจตนา หรือการดึงพารามิเตอร์ ในขณะที่สงวนโมเดลที่ใหญ่กว่าสำหรับการให้เหตุผลที่ซับซ้อน
Using a Router Model: กลยุทธ์ที่คล้ายกันคือการใช้ความหลากหลายของโมเดลและขนาด คุณสามารถใช้ LLM/SLM หรือฟังก์ชันแบบไม่มีเซิร์ฟเวอร์เพื่อกำหนดเส้นทางคำขอตามความซับซ้อนไปยังโมเดลที่เหมาะสมที่สุด ซึ่งจะช่วยลดต้นทุนและยังรับประกันประสิทธิภาพในงานที่เหมาะสม ตัวอย่างเช่น กำหนดเส้นทางคำถามง่าย ๆ ไปยังโมเดลที่เล็กกว่าและเร็วกว่า และใช้โมเดลใหญ่ที่มีราคาแพงเฉพาะในงานให้เหตุผลที่ซับซ้อนเท่านั้น
Caching Responses: การระบุคำขอและงานที่พบบ่อยและให้คำตอบล่วงหน้าก่อนที่จะผ่านระบบเอเยนต์ของคุณเป็นวิธีที่ดีในการลดปริมาณคำขอที่ซ้ำกัน คุณยังสามารถสร้างโฟลว์เพื่อตรวจสอบว่าแต่ละคำขอนั้นเหมือนกับคำขอที่แคชไว้แค่ไหนโดยใช้โมเดล AI ขั้นพื้นฐาน กลยุทธ์นี้สามารถช่วยลดค่าใช้จ่ายอย่างมากสำหรับคำถามที่ถูกถามบ่อยหรือกระบวนการทำงานที่พบบ่อย
Lets see how this works in practice
In the example notebook of this section, we’ll see examples of how we can use observability tools to monitor and evaluate our agent.
Got More Questions about AI Agents in Production?
Join the Microsoft Foundry Discord to meet with other learners, attend office hours and get your AI Agents questions answered.
Previous Lesson
Next Lesson
ข้อจำกัดความรับผิดชอบ: เอกสารนี้ได้รับการแปลโดยใช้บริการแปลภาษาด้วย AI Co-op Translator แม้ว่าเราจะพยายามให้ความถูกต้องสูงสุด โปรดทราบว่าการแปลอัตโนมัติอาจมีข้อผิดพลาดหรือความไม่ถูกต้อง เอกสารต้นฉบับในภาษาดั้งเดิมควรถือเป็นแหล่งข้อมูลที่เชื่อถือได้ สำหรับข้อมูลที่สำคัญ ขอแนะนำให้ใช้การแปลโดยผู้เชี่ยวชาญที่เป็นมนุษย์ เราจะไม่รับผิดชอบต่อความเข้าใจผิดหรือการตีความผิดใดๆ ที่เกิดขึ้นจากการใช้การแปลนี้