ai-agents-for-beginners
ตัวแทน AI ในการผลิต: การสังเกตการณ์ & การประเมินผล
เมื่อระบบตัวแทน AI ก้าวจากต้นแบบทดลองสู่การใช้งานจริง ความสามารถในการเข้าใจพฤติกรรมของพวกเขา ติดตามประสิทธิภาพ และประเมินผลลัพธ์อย่างเป็นระบบจึงกลายเป็นสิ่งสำคัญ
เป้าหมายการเรียนรู้
หลังจากเรียนบทนี้แล้ว คุณจะทราบวิธี/เข้าใจ:
- แนวคิดหลักของการสังเกตการณ์และการประเมินตัวแทน
- เทคนิคในการปรับปรุงประสิทธิภาพ ค่าใช้จ่าย และประสิทธิผลของตัวแทน
- สิ่งที่ต้องประเมินและวิธีการประเมินตัวแทน AI อย่างเป็นระบบ
- วิธีควบคุมค่าใช้จ่ายเมื่อปรับใช้ตัวแทน AI ในการผลิต
- วิธีติดตั้งเครื่องมือให้ตัวแทนที่สร้างด้วย Microsoft Agent Framework
เป้าหมายคือการมอบความรู้ให้คุณเพื่อเปลี่ยนตัวแทน “กล่องดำ” เป็นระบบที่โปร่งใส จัดการได้ และน่าเชื่อถือ
หมายเหตุ: สำคัญมากที่จะต้องปรับใช้ตัวแทน AI ที่ปลอดภัยและเชื่อถือได้ กรุณาดูบทเรียน การสร้างตัวแทน AI ที่น่าเชื่อถือ ด้วย
ร่องรอย (Traces) และช่วง (Spans)
เครื่องมือสังเกตการณ์เช่น Langfuse หรือ Microsoft Foundry โดยทั่วไปจะแสดงการทำงานของตัวแทนในรูปแบบของร่องรอยและช่วง
- ร่องรอย (Trace) เป็นการแสดงงานของตัวแทนครบถ้วนตั้งแต่เริ่มจนเสร็จ (เหมือนการจัดการคำถามของผู้ใช้)
- ช่วง (Spans) คือขั้นตอนย่อยในร่องรอย (เช่น การเรียกโมเดลภาษา หรือการดึงข้อมูล)
หากไม่มีการสังเกตการณ์ ตัวแทน AI จะเหมือน “กล่องดำ” — สภาพภายในและการตัดสินใจถูกปกคลุมด้วยความไม่โปร่งใส ทำให้การวินิจฉัยปัญหาหรือเพิ่มประสิทธิภาพเป็นเรื่องยาก ด้วยการสังเกตการณ์ ตัวแทนจะกลายเป็น “กล่องแก้ว” ให้ความโปร่งใสที่สำคัญสำหรับการสร้างความเชื่อถือและการทำงานอย่างที่ตั้งใจไว้
ทำไมการสังเกตการณ์ถึงสำคัญในสภาพแวดล้อมการผลิต
การย้ายตัวแทน AI ไปสู่สภาพแวดล้อมการผลิตใหม่นำมาซึ่งความท้าทายและข้อกำหนดใหม่ ๆ การสังเกตการณ์ไม่ใช่แค่สิ่งที่ดีที่จะมีอีกต่อไป แต่เป็นความสามารถที่จำเป็น:
- การดีบักและวิเคราะห์สาเหตุหลัก: เมื่อเกิดความล้มเหลวหรือผลลัพธ์ที่ไม่คาดหวัง เครื่องมือสังเกตการณ์จะให้ร่องรอยเพื่อตรวจสอบหาต้นตอข้อผิดพลาด ซึ่งสำคัญอย่างยิ่งในตัวแทนที่ซับซ้อนที่อาจมีการเรียก LLM หลายครั้ง การโต้ตอบกับเครื่องมือ และตรรกะมีเงื่อนไข
- การจัดการความล่าช้าและค่าใช้จ่าย: ตัวแทน AI มักพึ่งพา LLM และ API ภายนอกที่คิดค่าบริการเป็นจำนวนโทเค็นหรือต่อการเรียกใช้ การสังเกตการณ์ช่วยให้ติดตามการเรียกเหล่านี้อย่างแม่นยำ ช่วยระบุการทำงานที่ช้าหรือแพงเกินไป ทำให้ทีมสามารถปรับแต่งคำสั่ง เลือกโมเดลที่มีประสิทธิภาพกว่า หรือออกแบบเวิร์กโฟลว์ใหม่เพื่อจัดการต้นทุนและเพิ่มประสบการณ์ผู้ใช้
- ความเชื่อถือ ความปลอดภัย และการปฏิบัติตามข้อกำหนด: ในหลายแอปพลิเคชัน การทำให้ตัวแทนปฏิบัติตัวอย่างปลอดภัยและมีจริยธรรมเป็นสิ่งสำคัญ การสังเกตการณ์ให้เส้นทางตรวจสอบการกระทำและการตัดสินใจของตัวแทน สามารถใช้ตรวจจับและแก้ไขปัญหา เช่น การฉีดคำสั่ง (prompt injection) การสร้างเนื้อหาที่เป็นอันตราย หรือการจัดการข้อมูลส่วนบุคคลที่ไม่เหมาะสม เช่น คุณสามารถตรวจสอบร่องรอยเพื่อเข้าใจว่าทำไมตัวแทนจึงให้คำตอบหรือใช้เครื่องมือเฉพาะ
- วงจรปรับปรุงต่อเนื่อง: ข้อมูลสังเกตการณ์เป็นฐานในการพัฒนาซ้ำ โดยการติดตามประสิทธิภาพในโลกจริง ทีมจะระบุจุดที่ต้องปรับปรุง รวบรวมข้อมูลสำหรับการปรับแต่งโมเดล และยืนยันผลกระทบของการเปลี่ยนแปลง ซึ่งสร้างวงจรป้อนกลับที่ข้อมูลในสภาพการผลิตช่วยปรับปรุงการทดลองและการปรับแต่งแบบออฟไลน์ นำไปสู่ประสิทธิภาพตัวแทนที่ดีขึ้นอย่างต่อเนื่อง
ตัวชี้วัดสำคัญที่ต้องติดตาม
เพื่อเฝ้าติดตามและเข้าใจพฤติกรรมตัวแทน จำเป็นต้องติดตามชุดของตัวชี้วัดและสัญญาณ แม้ว่าตัวชี้วัดเฉพาะจะเปลี่ยนไปตามจุดประสงค์ของตัวแทน แต่บางตัวชี้วัดก็สำคัญทั่วไป
นี่คือตัวชี้วัดที่เครื่องมือสังเกตการณ์ส่วนใหญ่มักติดตาม:
ความล่าช้า: ตัวแทนตอบสนองเร็วแค่ไหน? เวลารอนานจะส่งผลลบต่อประสบการณ์ผู้ใช้ คุณควรวัดความล่าช้าสำหรับงานและขั้นตอนแต่ละขั้นโดยการติดตามการทำงานของตัวแทน ตัวอย่างเช่น ตัวแทนที่ใช้เวลา 20 วินาทีสำหรับการเรียกโมเดลทั้งหมดอาจเร่งความเร็วได้โดยใช้โมเดลที่เร็วกว่า หรือเรียกโมเดลหลายตัวพร้อมกัน
ค่าใช้จ่าย: ค่าใช้จ่ายต่อการทำงานของตัวแทนเท่าไร? ตัวแทน AI พึ่งพาการเรียก LLM ที่คิดค่าบริการตามโทเค็นหรือ API ภายนอก การใช้เครื่องมือบ่อยครั้งหรือการส่งคำสั่งหลายชุดสามารถเพิ่มค่าใช้จ่ายอย่างรวดเร็ว เช่น หากตัวแทนเรียก LLM ห้าครั้งเพื่อปรับปรุงคุณภาพเพียงเล็กน้อย คุณต้องประเมินว่าค่าใช้จ่ายนี้คุ้มหรือไม่ หรือคุณควรลดจำนวนการเรียกใช้หรือใช้โมเดลราคาถูกกว่า การตรวจสอบแบบเรียลไทม์ยังช่วยให้ระบุการกระโดดของค่าใช้จ่ายที่ไม่คาดคิดได้ (เช่น บั๊กที่ทำให้เกิดลูป API เกินความจำเป็น)
ข้อผิดพลาดการร้องขอ: ตัวแทนล้มเหลวกี่ครั้งในการส่งคำขอ? ซึ่งรวมถึงข้อผิดพลาด API หรือการเรียกเครื่องมือที่ล้มเหลว เพื่อทำให้ตัวแทนของคุณมีความทนทานมากขึ้นต่อปัญหาเหล่านี้ในสภาพการผลิต คุณสามารถตั้งค่าการสำรองหรือการลองอีกครั้ง เช่น หากผู้ให้บริการ LLM A หยุดทำงาน คุณสามารถสลับไปผู้ให้บริการ LLM B เป็นสำรอง
ความคิดเห็นจากผู้ใช้: การประเมินโดยตรงจากผู้ใช้ให้ข้อมูลเชิงลึกที่มีคุณค่า ซึ่งรวมถึงคะแนนชัดเจน (👍นิ้วโป้งขึ้น/👎ลง, ⭐1-5 ดาว) หรือความคิดเห็นเป็นข้อความ หากได้รับคำติชมเชิงลบอย่างต่อเนื่อง คุณควรแจ้งเตือนเพราะนี่เป็นสัญญาณว่าตัวแทนทำงานไม่เป็นไปตามคาด
ความคิดเห็นแฝงจากผู้ใช้: พฤติกรรมของผู้ใช้ให้ข้อมูลย้อนกลับโดยอ้อมแม้ไม่มีการให้คะแนนอย่างชัดเจน เช่น การเปลี่ยนคำถามทันที การถามซ้ำ หรือการคลิกปุ่มลองใหม่ เช่น หากคุณเห็นว่าผู้ใช้ถามคำถามเดิมซ้ำ ๆ นั่นเป็นสัญญาณว่าตัวแทนไม่ได้ทำงานตามที่คาดหวัง
ความถูกต้อง: ตัวแทนให้ผลลัพธ์ที่ถูกต้องหรือเป็นที่ต้องการบ่อยแค่ไหน? คำนิยามด้านความถูกต้องแตกต่างกัน (เช่น ความถูกต้องในการแก้ปัญหา ความแม่นยำในการดึงข้อมูล ความพึงพอใจของผู้ใช้) ขั้นตอนแรกคือการกำหนดว่าความสำเร็จสำหรับตัวแทนของคุณเป็นอย่างไร คุณสามารถติดตามความถูกต้องผ่านการตรวจสอบอัตโนมัติ คะแนนประเมิน หรือป้ายแสดงงานเสร็จ เช่น การทำเครื่องหมายร่องรอยว่า “สำเร็จ” หรือ “ล้มเหลว”
ตัวชี้วัดการประเมินอัตโนมัติ: คุณยังสามารถตั้งค่าการประเมินอัตโนมัติ เช่น ใช้ LLM ให้คะแนนผลลัพธ์ของตัวแทนว่ามีประโยชน์ ถูกต้อง หรือไม่ นอกจากนี้ยังมีไลบรารีโอเพนซอร์สหลายตัวที่ช่วยให้คุณประเมินด้านต่าง ๆ ของตัวแทนได้ เช่น RAGAS สำหรับตัวแทน RAG หรือ LLM Guard เพื่อป้องกันภาษาที่เป็นอันตรายหรือการฉีดคำสั่ง
ในทางปฏิบัติ การผสมผสานของตัวชี้วัดเหล่านี้จะครอบคลุมสถานะสุขภาพของตัวแทน AI ได้ดีที่สุด ในสมุดตัวอย่างบทนี้ example notebook เราจะแสดงตัวชี้วัดเหล่านี้ในตัวอย่างจริง แต่ก่อนอื่นเราจะเรียนรู้เวิร์กโฟลว์การประเมินแบบทั่วไปก่อน
ติดตั้งเครื่องมือให้ตัวแทนของคุณ
ในการรวบรวมข้อมูลร่องรอย คุณต้องติดตั้งเครื่องมือในโค้ด เป้าหมายคือการติดตั้งโค้ดตัวแทนเพื่อส่งร่องรอยและตัวชี้วัดที่สามารถถูกจับ ประมวลผล และแสดงภาพได้โดยแพลตฟอร์มการสังเกตการณ์
OpenTelemetry (OTel): OpenTelemetry ได้กลายเป็นมาตรฐานอุตสาหกรรมสำหรับการสังเกตการณ์ LLM โดยจัดเตรียมชุด API, SDK และเครื่องมือสำหรับการสร้าง เก็บ และส่งออกข้อมูลโทรเมทรี
มีไลบรารีติดตั้งเครื่องมือจำนวนมากที่ช่วยห่อหุ้มกรอบงานตัวแทนที่มีอยู่และทำให้ง่ายต่อการส่งออกช่วง 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
สมุดตัวอย่าง example notebook ในบทนี้จะแสดงวิธีติดตั้งเครื่องมือให้ตัวแทน MAF ของคุณ
การสร้างช่วงแบบแมนนวล: แม้ไลบรารีติดตั้งเครื่องมือจะให้พื้นฐานที่ดี แต่บางครั้งจำเป็นต้องมีข้อมูลที่ละเอียดหรือกำหนดเองมากขึ้น คุณสามารถสร้างช่วงเองเพื่อเพิ่มตรรกะแอปพลิเคชันที่กำหนดเอง ที่สำคัญคือสามารถเสริมช่วงที่สร้างโดยอัตโนมัติหรือแมนนวลได้ด้วยคุณลักษณะกำหนดเอง (เรียกว่าป้ายหรือข้อมูลเมตา) ซึ่งอาจรวมถึงข้อมูลเฉพาะธุรกิจ การคำนวณขั้นกลาง หรือบริบทใด ๆ ที่มีประโยชน์สำหรับการดีบักหรือวิเคราะห์ เช่น user_id, session_id, หรือ model_version
ตัวอย่างการสร้างร่องรอยและช่วงแบบแมนนวลด้วย Langfuse Python SDK:
from langfuse import get_client
langfuse = get_client()
span = langfuse.start_span(name="my-span")
span.end()
การประเมินตัวแทน
การสังเกตการณ์ให้ตัวชี้วัดกับเรา แต่การประเมินเป็นกระบวนการวิเคราะห์ข้อมูลนั้น (และการทดสอบ) เพื่อกำหนดว่าตัวแทน AI ทำงานดีแค่ไหนและจะปรับปรุงอย่างไร กล่าวคือ เมื่อคุณมีร่องรอยและตัวชี้วัดแล้ว คุณใช้มันอย่างไรเพื่อตัดสินตัวแทนและตัดสินใจ?
การประเมินปกติมีความสำคัญเพราะตัวแทน AI มักไม่ตายตัวและสามารถพัฒนาได้ (ผ่านการอัปเดตหรือพฤติกรรมโมเดลเปลี่ยน) — หากไม่มีการประเมิน คุณจะไม่ทราบว่าตัวแทน “อัจฉริยะ” ของคุณทำงานดีจริงหรือถดถอยลง
มีสองประเภทของการประเมินตัวแทน AI: การประเมินออนไลน์ และ การประเมินออฟไลน์ ทั้งสองมีคุณค่าและเสริมกัน มักเริ่มจากการประเมินออฟไลน์ เพราะเป็นขั้นตอนขั้นต่ำก่อนปรับใช้ตัวแทนใด ๆ
การประเมินออฟไลน์
นี่คือการประเมินตัวแทนในสภาพแวดล้อมควบคุม โดยใช้ชุดข้อมูลทดสอบ โดยไม่ใช่คำถามผู้ใช้สดจริง คุณใช้ชุดข้อมูลที่คัดสรรแล้วซึ่งรู้ว่าผลลัพธ์หรือพฤติกรรมที่ถูกต้องเป็นอย่างไร แล้วรันตัวแทนด้วยชุดข้อมูลเหล่านั้น
ตัวอย่างเช่น หากคุณสร้างตัวแทนแก้ปัญหาคำถามคณิตศาสตร์ คุณอาจมี ชุดข้อมูลทดสอบ 100 ปัญหาพร้อมคำตอบที่รู้จัก การประเมินออฟไลน์มักทำในช่วงพัฒนา (และอาจเป็นส่วนหนึ่งของกระบวนการ CI/CD) เพื่อเช็คการปรับปรุงหรือป้องกันความถดถอย ข้อดีคือมัน ทวนซ้ำได้และให้ตัวชี้วัดความถูกต้องที่ชัดเจนเพราะมีความจริงพื้นฐาน คุณอาจจำลองคำถามผู้ใช้และวัดการตอบของตัวแทนกับคำตอบที่เหมาะสม หรือใช้ตัวชี้วัดอัตโนมัติเหมือนที่กล่าวข้างต้น
ความท้าทายหลักของการประเมินออฟไลน์คือการทำให้ชุดข้อมูลทดสอบครบถ้วนและยังคงเกี่ยวข้อง — ตัวแทนอาจทำได้ดีในชุดทดสอบคงที่ แต่เจอคำถามที่แตกต่างในสภาพการผลิต ดังนั้นคุณควรอัปเดตชุดทดสอบด้วยกรณีขอบใหม่และตัวอย่างที่สะท้อนสถานการณ์จริง การผสมผสานชุดเล็ก “ทดสอบเบื้องต้น” กับชุดใหญ่สำหรับตัวชี้วัดประสิทธิภาพกว้าง ๆ จะเป็นประโยชน์ ชุดเล็กสำหรับตรวจสอบเร็ว ชุดใหญ่สำหรับตัวชี้วัดครอบคลุม
การประเมินออนไลน์
หมายถึงการประเมินตัวแทนในสภาพแวดล้อมสดจริง คือระหว่างใช้งานจริงในสภาพการผลิต การประเมินออนไลน์คือการติดตามประสิทธิภาพตัวแทนจากการโต้ตอบกับผู้ใช้จริงและวิเคราะห์ผลลัพธ์อย่างต่อเนื่อง
ตัวอย่างเช่น คุณอาจติดตามอัตราความสำเร็จ คะแนนความพึงพอใจของผู้ใช้ หรือเมตริกอื่น ๆ ในการรับส่งข้อมูลสด ข้อดีของการประเมินออนไลน์คือมัน จับสิ่งที่คุณอาจไม่คาดคิดในการตั้งค่าห้องปฏิบัติการ — คุณสามารถสังเกตการเปลี่ยนแปลงโมเดลตามเวลา (ถ้าประสิทธิภาพตัวแทนลดลงตามรูปแบบอินพุตเปลี่ยน) และจับคำถามหรือสถานการณ์ที่ไม่อยู่ในชุดทดสอบของคุณ นี่แสดงภาพแท้จริงของพฤติกรรมตัวแทนในโลกจริง
การประเมินออนไลน์มักรวมถึงการเก็บข้อมูลย้อนกลับทั้งแบบชัดเจนและแฝงจากผู้ใช้ ดังที่กล่าวไว้ และอาจทดสอบแบบเงาหรือ A/B ทดสอบ (ที่เวอร์ชันใหม่ของตัวแทนรันคู่ขนานกับเวอร์ชันเดิมเพื่อตรวจสอบเปรียบเทียบ) ความท้าทายคือการได้ป้ายหรือตัวชี้วัดที่น่าเชื่อถือจากการโต้ตอบสด — คุณอาจต้องพึ่งพาความคิดเห็นผู้ใช้หรือเมตริกจากระบบปลายทาง (เช่น ผู้ใช้คลิกผลลัพธ์หรือไม่)
การผสมผสานทั้งสอง
การประเมินออนไลน์และออฟไลน์ไม่ใช่สิ่งแยกจากกัน แต่เติมเต็มซึ่งกันและกัน ข้อมูลเชิงลึกจากการเฝ้าติดตามออนไลน์ (เช่น ประเภทคำถามผู้ใช้ใหม่ที่ตัวแทนทำงานไม่ดี) สามารถนำไปใช้เพิ่มชุดข้อมูลทดสอบออฟไลน์ ในทางกลับกัน ตัวแทนที่ทำงานดีในการทดสอบออฟไลน์ก็สามารถปรับใช้และติดตามบนออนไลน์ได้อย่างมั่นใจ
ในความเป็นจริง หลายทีมใช้กระบวนการวนลูป:
ประเมินออฟไลน์ -> ปรับใช้ -> ติดตามออนไลน์ -> รวบรวมกรณีล้มเหลวใหม่ -> เพิ่มในชุดข้อมูลออฟไลน์ -> ปรับแต่งตัวแทน -> ทำซ้ำ
ปัญหาทั่วไป
เมื่อคุณปรับใช้ตัวแทน AI ในการผลิต คุณอาจพบกับความท้าทายต่าง ๆ นี่คือปัญหาทั่วไปและวิธีแก้ปัญหาที่เป็นไปได้:
| ปัญหา | วิธีแก้ไขที่เป็นไปได้ |
|---|---|
| ตัวแทน AI ทำงานไม่สม่ำเสมอ | - ปรับคำสั่ง (prompt) ที่ให้กับตัวแทน AI ให้ชัดเจนและตรงประเด็น - แยกงานออกเป็นงานย่อยและมีตัวแทนหลายตัวจัดการช่วยได้ |
| ตัวแทน AI ติดลูปอย่างต่อเนื่อง | - ให้เงื่อนไขการหยุดที่ชัดเจน เพื่อให้ตัวแทนทราบว่าเมื่อไรต้องหยุดกระบวนการ - สำหรับงานซับซ้อนที่ต้องการเหตุผลและวางแผน ใช้โมเดลใหญ่ที่มีความเชี่ยวชาญเฉพาะด้าน |
| เครื่องมือที่ตัวแทนเรียกใช้ทำงานไม่ดี | - ทดสอบและตรวจสอบผลลัพธ์ของเครื่องมือนอกระบบตัวแทน - ปรับค่าพารามิเตอร์ คำสั่ง และการตั้งชื่อเครื่องมือให้เหมาะสม |
| ระบบตัวแทนหลายตัวทำงานไม่สม่ำเสมอ | - ปรับคำสั่งที่ให้แต่ละตัวแทนให้มีความเฉพาะเจาะจงและแตกต่างกัน - สร้างระบบลำดับชั้นโดยใช้ตัวแทน “routing” หรือตัวควบคุมเพื่อตัดสินใจว่าตัวแทนใดถูกต้อง |
ปัญหาเหล่านี้หลายอย่างสามารถระบุได้ดีขึ้นเมื่อมีการสังเกตการณ์ ร่องรอยและตัวชี้วัดที่กล่าวมาก่อนหน้านี้ช่วยระบุตำแหน่งปัญหาในเวิร์กโฟลว์ตัวแทนได้อย่างแม่นยำ ทำให้การดีบักและเพิ่มประสิทธิภาพมีประสิทธิผลมากขึ้น
การจัดการค่าใช้จ่าย
นี่คือกลยุทธ์บางประการในการจัดการต้นทุนของการนำตัวแทน AI ไปใช้งานจริง:
การใช้โมเดลขนาดเล็ก: โมเดลภาษาเล็ก (SLMs) สามารถทำงานได้ดีในกรณีการใช้งานตัวแทนบางประเภทและจะช่วยลดต้นทุนได้อย่างมาก ตามที่ได้กล่าวไว้ก่อนหน้านี้ การสร้างระบบประเมินผลเพื่อกำหนดและเปรียบเทียบประสิทธิภาพกับโมเดลขนาดใหญ่เป็นวิธีที่ดีที่สุดในการเข้าใจว่า SLM จะทำงานได้ดีเพียงใดในกรณีการใช้งานของคุณ พิจารณาใช้ SLM สำหรับงานที่ง่ายกว่า เช่น การจำแนกเจตนาหรือการดึงค่าพารามิเตอร์ ขณะที่จองโมเดลที่ใหญ่กว่าไว้สำหรับการวิเคราะห์ที่ซับซ้อน
การใช้โมเดลเส้นทาง (Router Model): กลยุทธ์ที่คล้ายกันคือการใช้ความหลากหลายของโมเดลและขนาด คุณสามารถใช้ LLM/SLM หรือฟังก์ชัน serverless เพื่อเส้นทางคำขอตามความซับซ้อนไปยังโมเดลที่เหมาะสมที่สุด วิธีนี้จะช่วยลดต้นทุนในขณะเดียวกันก็รับประกันประสิทธิภาพในงานที่เหมาะสม ตัวอย่างเช่น เส้นทางคำถามง่าย ๆ ไปยังโมเดลขนาดเล็กและรวดเร็ว และใช้โมเดลขนาดใหญ่และมีราคาสูงเฉพาะกับงานวิเคราะห์ที่ซับซ้อนเท่านั้น
การแคชผลลัพธ์: การระบุคำขอและงานที่พบบ่อย และให้คำตอบก่อนที่มันจะผ่านระบบตัวแทนของคุณเป็นวิธีที่ดีในการลดปริมาณคำขอที่เหมือนกัน คุณยังสามารถดำเนินการสร้างกระบวนการเพื่อตรวจสอบว่าคำขอใกล้เคียงกับคำที่แคชไว้มากน้อยเพียงใดโดยใช้โมเดลง่าย ๆ ของ AI วิธีนี้สามารถลดต้นทุนสำหรับคำถามที่ถามบ่อยหรือเวิร์กโฟลว์ที่พบบ่อยได้อย่างมาก
มาดูตัวอย่างการทำงานในทางปฏิบัติกัน
ใน ตัวอย่างโน้ตบุ๊กของส่วนนี้ เราจะเห็นตัวอย่างว่าเราสามารถใช้เครื่องมือสังเกตการณ์เพื่อติดตามและประเมินตัวแทนของเราได้อย่างไร
มีคำถามเพิ่มเติมเกี่ยวกับตัวแทน AI ในการผลิตไหม?
เข้าร่วม Microsoft Foundry Discord เพื่อพบกับผู้เรียนคนอื่น ๆ เข้าร่วมชั่วโมงทำงาน และรับคำตอบสำหรับคำถามเกี่ยวกับตัวแทน AI ของคุณ
บทเรียนก่อนหน้า
บทเรียนถัดไป
ปฏิเสธความรับผิดชอบ: เอกสารนี้ได้รับการแปลโดยใช้บริการแปลภาษา AI Co-op Translator ขณะที่เราพยายามให้ความถูกต้อง โปรดทราบว่าการแปลโดยอัตโนมัติอาจมีข้อผิดพลาดหรือความไม่ถูกต้อง เอกสารต้นฉบับในภาษาต้นทางควรถูกพิจารณาเป็นแหล่งข้อมูลที่เชื่อถือได้ สำหรับข้อมูลที่สำคัญ แนะนำให้ใช้การแปลโดยมนุษย์มืออาชีพ เราไม่รับผิดชอบต่อความเข้าใจผิดหรือการตีความที่ผิดพลาดที่เกิดขึ้นจากการใช้การแปลนี้