IMMACULATE: เผยกรอบการตรวจสอบบริการ LLM แบบกล่องดำใหม่ ตรวจจับการแทนที่โมเดลและการรายงานโทเค็นผิดพลาดด้วยต้นทุนเพียง 1%

ผู้เขียน

ผู้เขียนบทความนี้มาจากมหาวิทยาลัยแห่งชาติสิงคโปร์และมหาวิทยาลัยแคลิฟอร์เนีย เบิร์กลีย์ ตามลำดับ ผู้เขียนคนแรก Guo Yanpei มาจากมหาวิทยาลัยแห่งชาติสิงคโปร์ ให้ความสนใจในระยะยาวกับปัญหาความน่าเชื่อถือและความปลอดภัยในโครงสร้างพื้นฐานของโมเดลภาษาขนาดใหญ่ โดยเฉพาะอย่างยิ่งความสามารถในการตรวจสอบและความเสี่ยงด้านแรงจูงใจทางเศรษฐกิจของบริการ LLM บนคลาวด์ อาจารย์ที่ปรึกษาคือศาสตราจารย์หนุ่มสาวอธิการบดีของมหาวิทยาลัยแห่งชาติสิงคโปร์ Zhang Jiaheng และศาสตราจารย์ Dawn Song จากมหาวิทยาลัยแคลิฟอร์เนีย เบิร์กลีย์

บทนำ: วิกฤตความไว้วางใจในบริการ LLM แบบกล่องดำ

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

ในความเป็นจริง การอภิปรายเกี่ยวกับการ “ลดความฉลาด” ของบริการ LLM ได้ปรากฏขึ้นซ้ำแล้วซ้ำเล่าในชุมชนนักพัฒนาหลายแห่งทั้งในและต่างประเทศ ผู้ใช้จำนวนมากรายงานว่าประสิทธิภาพของโมเดลดูลงอย่างเห็นได้ชัดหลังจากใช้งานไประยะหนึ่ง [1,2] ในเวลาเดียวกัน หากผู้ให้บริการด้วยเหตุผลทางการแข่งขันหรือเชิงกลยุทธ์ ให้บริการที่แตกต่างหรือมีคุณภาพต่ำแก่กลุ่มผู้ใช้เฉพาะกลุ่ม [3] ก็จะยิ่งทำให้วิกฤตความไว้วางใจในบริการ AI แบบกล่องดำรุนแรงขึ้น

วิธีแก้ปัญหา: กรอบการตรวจสอบ IMMACULATE

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

IMMACULATE: เผยกรอบการตรวจสอบบริการ LLM แบบกล่องดำใหม่ ตรวจจับการแทนที่โมเดลและการรายงานโทเค็นผิดพลาดด้วยต้นทุนเพียง 1%

  • ชื่อบทความ: IMMACULATE: A Practical LLM Auditing Framework via Verifiable Computation
  • ลิงก์บทความ: https://arxiv.org/pdf/2602.22700
  • ลิงก์โค้ด: https://github.com/guo-yanpei/Immaculate

ภาพรวมของกรอบงาน

IMMACULATE เป็นกรอบการตรวจสอบสำหรับ LLM API แบบกล่องดำ ไม่จำเป็นต้องเข้าถึงโครงสร้างภายในโมเดล และไม่ต้องพึ่งพาฮาร์ดแวร์น่าเชื่อถือเฉพาะทาง ก็สามารถตรวจจับได้ว่าผู้ให้บริการคลาวด์ได้ดำเนินกระบวนการอนุมานของโมเดลตามที่อ้างจริงหรือไม่ และได้รายงานปริมาณการใช้โทเค็นอย่างถูกต้องหรือไม่ ด้วยการนำหน่วยวัดทางสถิติใหม่ที่เรียกว่า Logit Distance Distribution มาใช้ ร่วมกับเทคโนโลยีการตรวจสอบแบบสุ่มและการคำนวณที่สามารถตรวจสอบได้ IMMACULATE บรรลุค่าใช้จ่ายของระบบต่ำกว่า 1% บนโมเดลจริง ในขณะเดียวกันก็สามารถตรวจจับพฤติกรรมที่ไม่เป็นไปตามข้อกำหนดที่เกิดจากแรงจูงใจทางเศรษฐกิจ เช่น การเปลี่ยนโมเดล การควอนไทซ์เกินขนาด และการคิดค่าบริการโทเค็นเกินจริงได้อย่างน่าเชื่อถือ

00 พื้นหลัง: เมื่อ LLM กลายเป็นบริการ API

ในปีที่ผ่านมา โมเดลภาษาขนาดใหญ่ค่อยๆ กลายเป็นโครงสร้างพื้นฐานที่สำคัญสำหรับแอปพลิเคชัน AI ผู้ใช้ส่วนใหญ่เรียกใช้ความสามารถของโมเดลผ่านบริการ API บนคลาวด์ เช่น บริการที่ให้โดย OpenAI, Anthropic และ Google

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

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

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

ดังนั้น คำถามสำคัญจึงเกิดขึ้น: จะตรวจสอบว่า LLM API ถูกดำเนินการอย่างซื่อสัตย์หรือไม่ โดยไม่ต้องเข้าถึงภายในโมเดล?

01 ภาพรวมวิธีการ: กรอบการตรวจสอบ IMMACULATE

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

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

IMMACULATE: เผยกรอบการตรวจสอบบริการ LLM แบบกล่องดำใหม่ ตรวจจับการแทนที่โมเดลและการรายงานโทเค็นผิดพลาดด้วยต้นทุนเพียง 1%
รูปที่ 1 กระบวนการทำงานของ IMMACULATE: หน่วยตรวจสอบปลอมตัวเป็นผู้ใช้ทั่วไปส่งคำขอแบบสุ่ม และหลังจากได้รับคำตอบแล้วจะขอข้อพิสูจน์

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

02 เทคโนโลยีหลัก: Logit Distance Distribution (LDD)

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

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

เพื่อจุดประสงค์นี้ IMMACULATE ใช้คุณลักษณะโครงสร้างนี้: กำหนดเส้นทางการตัดสินใจแบบไม่ต่อเนื่องให้คงที่ และเปรียบเทียบเฉพาะความเบี่ยงเบนของการคำนวณต่อเนื่อง กล่าวโดยเฉพาะ ภายใต้ลำดับการตัดสินใจแบบไม่ต่อเนื่องที่กำหนดให้เหมือนกัน เปรียบเทียบการกระจายระยะทางของเวกเตอร์ logits ที่สร้างขึ้นในแต่ละขั้นตอนระหว่างโมเดลที่ติดตั้งและโมเดลอ้างอิง นั่นคือ Logit Distance Distribution

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

แนวคิดหลักคือ: ไม่ตรวจสอบโดยตรงว่าทุกขั้นตอนของการอนุมานเหมือนกันทุกประการหรือไม่ แต่เป็นการวัด การกระจายของความเบี่ยงเบน logit ระหว่างโมเดลที่ดำเนินการจริงและโมเดลอ้างอิง
* หากระบบทำงานปกติ ความเบี่ยงเบนของ logit มาจากความคลาดเคลื่อนเชิงตัวเลขเท่านั้น การกระจายความเบี่ยงเบนจะคงที่และรวมตัว
* หากระบบมีพฤติกรรมที่ไม่เป็นไปตามข้อกำหนด (เช่น การเปลี่ยนโมเดล การควอนไทซ์เกินขนาด) การกระจายความเบี่ยงเบนจะขยายหรือเคลื่อนออกไปอย่างเห็นได้ชัด

ด้วยการใช้สถิติความน่าจะเป็นส่วนหางของ LDD ระบบสามารถระบุพฤติกรรมการดำเนินการที่ผิดปกติได้

03 ผลการทดลอง: ตรวจจับพฤติกรรมที่ไม่เป็นไปตามข้อกำหนดด้วยต้นทุนต่ำ

ทีมวิจัยได้ประเมินประสิทธิผลของ IMMACULATE บนหลายโมเดลและชุดข้อมูล ผลการทดลองแสดงให้เห็นว่าสำหรับคำขอเดียว:

IMMACULATE: เผยกรอบการตรวจสอบบริการ LLM แบบกล่องดำใหม่ ตรวจจับการแทนที่โมเดลและการรายงานโทเค็นผิดพลาดด้วยต้นทุนเพียง 1%
รูปที่ 3 การกระจายระยะทาง TV ของโมเดล LLaMA3-70B จะเห็นได้ว่าวิธีการอนุมานที่ต่างกันมีความแตกต่างของความน่าจะเป็นที่ชัดเจนมากในส่วนหาง

  • อัตราการตรวจจับการโจมตีโดยการเปลี่ยนโมเดลสูงกว่า 90%
  • อัตราการตรวจจับการโจมตีโดยการควอนไทซ์สามารถถึง 1%–10%

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

ในเวลาเดียวกัน ค่าใช้จ่ายของระบบ IMMACULATE ต่ำมาก:
* ภายใต้เอนจินอนุมาน vLLM ผลกระทบต่อปริมาณงาน < 1%
* การพิสูจน์การคำนวณจะถูกทริกเกอร์บนคำขอที่น้อยมากเท่านั้น

这表明该框架具备现实部署可行性。

04 สรุป

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

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

IMMACULATE: เผยกรอบการตรวจสอบบริการ LLM แบบกล่องดำใหม่ ตรวจจับการแทนที่โมเดลและการรายงานโทเค็นผิดพลาดด้วยต้นทุนเพียง 1%


⚠️ หมายเหตุ: เนื้อหาได้รับการแปลโดย AI และตรวจสอบโดยมนุษย์ หากมีข้อผิดพลาดโปรดแจ้ง

☕ สนับสนุนค่ากาแฟทีมงาน

หากคุณชอบบทความนี้ สามารถสนับสนุนเราได้ผ่าน PromptPay

PromptPay QR
SCAN TO PAY WITH ANY BANK

本文来自网络搜集,不代表คลื่นสร้างอนาคต立场,如有侵权,联系删除。转载请注明出处:https://www.itsolotime.com/th/archives/27069

Like (0)
Previous 6 hours ago
Next 6 hours ago

相关推荐