เทคนิคและแนวทางในการตรวจสอบโมเดลภาษาขนาดใหญ่บน AWS | อเมซอนเว็บเซอร์วิส

โมเดลภาษาขนาดใหญ่ (LLM) ได้ปฏิวัติขอบเขตการประมวลผลภาษาธรรมชาติ (NLP) โดยปรับปรุงงานต่างๆ เช่น การแปลภาษา การสรุปข้อความ และการวิเคราะห์ความรู้สึก อย่างไรก็ตาม เนื่องจากโมเดลเหล่านี้มีขนาดและความซับซ้อนเพิ่มขึ้นอย่างต่อเนื่อง การติดตามประสิทธิภาพและพฤติกรรมจึงมีความท้าทายมากขึ้น

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

ในโพสต์นี้ เราจะสาธิตตัววัดบางส่วนสำหรับการตรวจสอบ LLM ออนไลน์และสถาปัตยกรรมที่เกี่ยวข้องสำหรับการปรับขนาดโดยใช้บริการของ AWS เช่น อเมซอน คลาวด์วอตช์ และ AWS แลมบ์ดา. นี่เป็นการนำเสนอโซลูชันที่ปรับแต่งได้เกินกว่าจะเป็นไปได้ การประเมินแบบจำลอง งานด้วย อเมซอน เบดร็อค.

ภาพรวมของโซลูชัน

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

เราขอแนะนำให้แต่ละโมดูลส่งคำขอการอนุมานขาเข้าไปยัง LLM โดยส่งคู่พร้อมต์และการดำเนินการ (ตอบกลับ) ไปยังโมดูลคำนวณเมตริก แต่ละโมดูลมีหน้าที่ในการคำนวณหน่วยเมตริกของตนเองโดยคำนึงถึงการแจ้งอินพุตและความสมบูรณ์ (การตอบสนอง) ตัววัดเหล่านี้จะถูกส่งผ่านไปยัง CloudWatch ซึ่งสามารถรวบรวมและทำงานร่วมกับการแจ้งเตือนของ CloudWatch เพื่อส่งการแจ้งเตือนเกี่ยวกับเงื่อนไขเฉพาะ แผนภาพต่อไปนี้แสดงให้เห็นถึงสถาปัตยกรรมนี้

เวิร์กโฟลว์ประกอบด้วยขั้นตอนต่อไปนี้:

1. ผู้ใช้ส่งคำขอไปยัง Amazon Bedrock โดยเป็นส่วนหนึ่งของแอปพลิเคชันหรืออินเทอร์เฟซผู้ใช้
2. Amazon Bedrock บันทึกคำขอและการดำเนินการ (ตอบกลับ) ลงใน บริการจัดเก็บข้อมูลอย่างง่ายของ Amazon (Amazon S3) ตามการกำหนดค่าของ การบันทึกการร้องขอ.
3. ไฟล์ที่บันทึกไว้ใน Amazon S3 จะสร้างเหตุการณ์ที่ ทริกเกอร์ ฟังก์ชันแลมบ์ดา ฟังก์ชั่นเรียกใช้โมดูล
4. โมดูลจะโพสต์การวัดตามลำดับไปที่ ตัววัด CloudWatch.
5. สัญญาณเตือน สามารถแจ้งทีมพัฒนาเกี่ยวกับค่าเมตริกที่ไม่คาดคิดได้

สิ่งที่สองที่ต้องพิจารณาเมื่อใช้การตรวจสอบ LLM คือการเลือกตัวชี้วัดที่เหมาะสมในการติดตาม แม้ว่าจะมีตัวชี้วัดที่เป็นไปได้มากมายที่คุณสามารถใช้เพื่อติดตามประสิทธิภาพ LLM แต่เราอธิบายตัวชี้วัดที่กว้างที่สุดบางส่วนในโพสต์นี้

ในส่วนต่อไปนี้ เราจะเน้นเมตริกโมดูลที่เกี่ยวข้องบางส่วนและสถาปัตยกรรมโมดูลประมวลผลเมตริกที่เกี่ยวข้อง

ความคล้ายคลึงกันเชิงความหมายระหว่างพร้อมท์และเสร็จสิ้น (ตอบกลับ)

เมื่อเรียกใช้ LLM คุณสามารถดักฟังพร้อมต์และดำเนินการให้เสร็จสิ้น (ตอบกลับ) สำหรับแต่ละคำขอ และแปลงเป็นการฝังโดยใช้โมเดลการฝัง การฝังเป็นเวกเตอร์มิติสูงที่แสดงถึงความหมายเชิงความหมายของข้อความ อเมซอนไททัน จัดหาโมเดลดังกล่าวผ่าน Titan Embeddings ด้วยการใช้ระยะห่างเช่นโคไซน์ระหว่างเวกเตอร์ทั้งสองนี้ คุณสามารถระบุได้ว่าพรอมต์และความสมบูรณ์ (การตอบสนอง) มีความคล้ายคลึงกันในเชิงความหมายเพียงใด คุณสามารถใช้ได้ วิทย์ or scikit เรียนรู้ เพื่อคำนวณระยะห่างโคไซน์ระหว่างเวกเตอร์ แผนภาพต่อไปนี้แสดงสถาปัตยกรรมของโมดูลคำนวณเมตริกนี้

เวิร์กโฟลว์นี้ประกอบด้วยขั้นตอนสำคัญต่อไปนี้:

1. ฟังก์ชัน Lambda ได้รับข้อความที่สตรีมผ่าน อเมซอน Kinesis ประกอบด้วยคู่พร้อมท์และการตอบสนอง (ตอบกลับ)
2. ฟังก์ชันได้รับการฝังสำหรับทั้งพรอมต์และการเสร็จสิ้น (การตอบสนอง) และคำนวณระยะห่างโคไซน์ระหว่างเวกเตอร์ทั้งสอง
3. ฟังก์ชันจะส่งข้อมูลนั้นไปยังตัววัด CloudWatch

ความรู้สึกและความเป็นพิษ

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

เวิร์กโฟลว์ประกอบด้วยขั้นตอนต่อไปนี้:

1. ฟังก์ชัน Lambda ได้รับการจับคู่พร้อมท์และการเสร็จสิ้น (ตอบสนอง) ผ่าน Amazon Kinesis
2. ผ่านการประสาน AWS Step Functions การเรียกใช้ฟังก์ชัน เข้าใจ Amazon เพื่อตรวจจับไฟล์ ความรู้สึก และ ความเป็นพิษ.
3. ฟังก์ชันจะบันทึกข้อมูลลงในตัววัด CloudWatch

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการตรวจจับความรู้สึกและความเป็นพิษด้วย Amazon Comprehend โปรดดูที่ สร้างตัวทำนายความเป็นพิษแบบข้อความที่มีประสิทธิภาพ และ แจ้งเนื้อหาที่เป็นอันตรายโดยใช้การตรวจจับความเป็นพิษของ Amazon Comprehend.

อัตราส่วนของการปฏิเสธ

การปฏิเสธที่เพิ่มขึ้น เช่น เมื่อ LLM ปฏิเสธการดำเนินการให้เสร็จสิ้นเนื่องจากขาดข้อมูล อาจหมายความว่าผู้ใช้ที่เป็นอันตรายกำลังพยายามใช้ LLM ในลักษณะที่มีจุดประสงค์เพื่อเจลเบรค หรือความคาดหวังของผู้ใช้ไม่เป็นไปตามที่กำหนด และพวกเขาก็ ได้รับการตอบกลับที่มีคุณค่าต่ำ วิธีหนึ่งในการวัดว่าเหตุการณ์นี้เกิดขึ้นบ่อยแค่ไหนคือการเปรียบเทียบการปฏิเสธมาตรฐานจากแบบจำลอง LLM ที่ใช้กับการตอบสนองจริงจาก LLM ตัวอย่างเช่น ต่อไปนี้คือวลีปฏิเสธทั่วไปของ Claude v2 LLM ของ Anthropic:

“Unfortunately, I do not have enough context to provide a substantive response. However, I am an AI assistant created by Anthropic to be helpful, harmless, and honest.”

“I apologize, but I cannot recommend ways to…”

“I'm an AI assistant created by Anthropic to be helpful, harmless, and honest.”

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

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

เวิร์กโฟลว์ประกอบด้วยขั้นตอนต่อไปนี้:

1. ฟังก์ชัน Lambda ได้รับข้อความแจ้งและการเสร็จสิ้น (ตอบกลับ) และได้รับการฝังจากการตอบกลับโดยใช้ Amazon Titan
2. ฟังก์ชันคำนวณระยะห่างโคไซน์หรือยุคลิเดียนระหว่างการตอบสนองและพร้อมท์การปฏิเสธที่มีอยู่ซึ่งแคชไว้ในหน่วยความจำ
3. ฟังก์ชันจะส่งค่าเฉลี่ยนั้นไปยังตัววัด CloudWatch

อีกทางเลือกหนึ่งคือการใช้ การจับคู่ที่คลุมเครือ สำหรับแนวทางที่ตรงไปตรงมาแต่มีประสิทธิภาพน้อยกว่าในการเปรียบเทียบการปฏิเสธที่ทราบกับเอาต์พุต LLM อ้างถึง เอกสาร Python สำหรับตัวอย่าง

สรุป

ความสามารถในการสังเกต LLM เป็นแนวทางปฏิบัติที่สำคัญในการรับรองการใช้งาน LLM ที่เชื่อถือได้และน่าเชื่อถือ การตรวจสอบ การทำความเข้าใจ และการรับรองความถูกต้องและความน่าเชื่อถือของ LLM สามารถช่วยคุณลดความเสี่ยงที่เกี่ยวข้องกับโมเดล AI เหล่านี้ได้ ด้วยการตรวจสอบภาพหลอน การดำเนินการที่ไม่ดี (การตอบสนอง) และการแจ้งเตือน คุณสามารถมั่นใจได้ว่า LLM ของคุณดำเนินไปในแนวทางเดิมและมอบคุณค่าที่คุณและผู้ใช้ของคุณต้องการ ในโพสต์นี้ เราได้พูดคุยถึงเมตริกบางอย่างเพื่อแสดงตัวอย่าง

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการประเมินแบบจำลองฐานราก โปรดดูที่ ใช้ SageMaker Clarify เพื่อประเมินโมเดลพื้นฐานและเรียกดูเพิ่มเติม ตัวอย่างโน๊ตบุ๊ค มีอยู่ในพื้นที่เก็บข้อมูล GitHub ของเรา คุณยังสามารถสำรวจวิธีดำเนินการประเมิน LLM ในวงกว้างได้ ดำเนินการประเมิน LLM ตามขนาดโดยใช้บริการ Amazon SageMaker Clarify และ MLOps. สุดท้ายนี้เราแนะนำให้อ้างอิงถึง ประเมินแบบจำลองภาษาขนาดใหญ่ในด้านคุณภาพและความรับผิดชอบ เพื่อเรียนรู้เพิ่มเติมเกี่ยวกับการประเมิน LLM

---

เกี่ยวกับผู้เขียน

บรูโน่ ไคลน์ เป็นวิศวกร Machine Learning อาวุโสที่มี AWS Professional Services Analytics Practice เขาช่วยลูกค้าปรับใช้โซลูชันข้อมูลขนาดใหญ่และการวิเคราะห์ นอกเหนือจากงาน เขาชอบใช้เวลากับครอบครัว ท่องเที่ยว และลองอาหารใหม่ๆ

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

• เนื้อหาที่ขับเคลื่อนด้วย SEO และการเผยแพร่ประชาสัมพันธ์ รับการขยายวันนี้
• PlatoData.Network Vertical Generative Ai เพิ่มพลังให้กับตัวเอง เข้าถึงได้ที่นี่.
• เพลโตไอสตรีม. Web3 อัจฉริยะ ขยายความรู้ เข้าถึงได้ที่นี่.
• เพลโตESG. คาร์บอน, คลีนเทค, พลังงาน, สิ่งแวดล้อม แสงอาทิตย์, การจัดการของเสีย. เข้าถึงได้ที่นี่.
• เพลโตสุขภาพ เทคโนโลยีชีวภาพและข่าวกรองการทดลองทางคลินิก เข้าถึงได้ที่นี่.
• ที่มา: https://aws.amazon.com/blogs/machine-learning/techniques-and-approaches-for-monitoring-large-language-models-on-aws/