โมเดล AI ต้องการเครื่องเสมือน

 (blog.sigplan.org)
3 คะแนน โดย GN⁺ 2025-09-01 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ซอฟต์แวร์ AI ไม่ได้ต้องการเพียงแค่การเรียกใช้โมเดลเท่านั้น แต่ยังต้องมีคุณลักษณะแบบระบบปฏิบัติการที่ให้ ความปลอดภัย·การแยกส่วน·ความสามารถในการขยาย·การพกพา และด้วยเหตุนี้จึงมีการเสนอแนวคิด เครื่องเสมือนสำหรับโมเดล AI โดยเฉพาะ (MVM)
  • เช่นเดียวกับที่ Java Virtual Machine(JVM) ทำให้เกิดความปลอดภัยของหน่วยความจำและ “เขียนครั้งเดียว รันได้ทุกที่” เครื่องเสมือนสำหรับ AI ก็จะแยก โมเดลออกจากตรรกะการผสานรวม เพื่อรับประกันความสามารถในการสับเปลี่ยนและการทำงานร่วมกันได้
  • เครื่องเสมือนจะกำหนด ชุดคำสั่งมาตรฐาน สำหรับสิ่งต่าง ๆ เช่น การเรียกใช้โมเดล การเรียกใช้เครื่องมือ การบันทึกผลลัพธ์ อินพุตจากผู้ใช้ และการแตกแขนงตามเงื่อนไข เพื่อให้สามารถจำกัดและติดตามพฤติกรรมของโมเดลได้อย่างปลอดภัย
  • งานวิจัยที่มีอยู่แล้ว เช่น Structured tool calling ของ OpenAI, MCP ของ Anthropic, FIDES/AC4A ของ Microsoft และรันไทม์โอเพนซอร์ส ต่างแสดงให้เห็นถึง ทิศทางของการทำให้เป็นมาตรฐาน แล้ว
  • เครื่องเสมือน AI ที่นิยามไว้อย่างชัดเจนจะทำให้ การเสริมความปลอดภัย·ความเป็นส่วนตัว การมอนิเตอร์ประสิทธิภาพ การตรวจสอบผลลัพธ์ และการสร้างอีโคซิสเต็มข้ามแพลตฟอร์ม เป็นไปได้ และอาจกลายเป็นโครงสร้างพื้นฐานสำคัญที่ทำให้ระบบ AI น่าเชื่อถือและปลอดภัยยิ่งขึ้น

บทนำ

  • โมเดล AI กำลังถูกนำไปใช้ในซอฟต์แวร์เพื่อวัตถุประสงค์หลากหลาย เช่น application copilots, การผสานรวมกับ IDE, และการใช้เครื่องมือผ่านโปรโตคอล MCP
    • ความก้าวหน้าเหล่านี้เพิ่มความจำเป็นในการรับประกัน ความเป็นส่วนตัว, ความปลอดภัย และการทำงานที่ถูกต้องแม่นยำ
  • ความปลอดภัยและความเป็นส่วนตัว ต้องถูกทำให้มั่นคงตั้งแต่ขั้นตอนการออกแบบระบบ และไม่เพียงพอหากค่อยมาเพิ่มภายหลัง
  • โดยได้รับแรงบันดาลใจจาก Java Virtual Machine(JVM) จึงมีการเสนอความสำคัญของ เครื่องเสมือนมาตรฐาน สำหรับโมเดล AI
    • JVM มอบสภาพแวดล้อมการรันที่เชื่อถือได้ผ่านความปลอดภัยของหน่วยความจำ, การควบคุมการเข้าถึง, และการตรวจสอบไบต์โค้ด
    • สิ่งนี้ทำให้ “เขียนครั้งเดียว รันได้ทุกที่” เป็นไปได้

บทบาทของเครื่องเสมือนสำหรับโมเดล AI (MVM)

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

งานวิจัยที่มีอยู่และความจำเป็น

  • โปรโตคอลการเรียกใช้เครื่องมือแบบมีโครงสร้างของ OpenAI: มอบการผสานรวมเครื่องมือที่ชัดเจนผ่าน Function Calling API แบบ JSON และข้อกำหนด OpenAPI
  • MCP(2024) ของ Anthropic: โปรโตคอลแบบเปิด สำหรับเชื่อมผู้ช่วย AI กับข้อมูลภายนอก
    • ถูกเปรียบว่าเป็น “พอร์ต USB-C สำหรับแอปพลิเคชัน AI” และมอบอินเทอร์เฟซที่ใช้งานได้ทั่วไป
    • มีตัวอย่างการยอมรับใช้งานอย่างรวดเร็ว รวมถึงในองค์กรขนาดใหญ่
  • Security orchestrator – FIDES & AC4A(2025):
    • FIDES (Microsoft Research): บังคับใช้นโยบาย การไหลของข้อมูล พร้อมติดตามป้ายกำกับความลับของข้อมูล และเพิ่มแอ็กชัน “inspect”
    • AC4A: จัดการเครื่องมือและข้อมูลเป็นลำดับชั้นแบบสไตล์ OS และบังคับโหมดการทำงานแบบ สิทธิ์เท่าที่จำเป็น
    • โครงการเหล่านี้แสดงให้เห็นถึงความเป็นไปได้ที่ MVM จะฝัง ความปลอดภัย และ การควบคุมการเข้าถึง ไว้ในตัว
  • รันไทม์เอเจนต์โอเพนซอร์ส: langchain, Semantic Kernel, llguidance มอบ บริการรันไทม์ เพื่อสนับสนุนการพัฒนาแอปพลิเคชัน AI ที่เสถียร
  • ข้อกำหนดของ MVM ต้องอาศัยให้ ข้อมูลฝึกของโมเดล สะท้อนข้อกำหนดของอินเทอร์เฟซ และจำเป็นต้องมี วิวัฒนาการร่วมกัน ระหว่างโมเดลกับ MVM

ข้อดีของ MVM

  • การแยกความรับผิดชอบ: แยก ตรรกะของโมเดล ออกจาก ตรรกะการผสานรวม เพื่อเปลี่ยนโมเดลให้เป็น คอมโพเนนต์ที่สับเปลี่ยนได้
    • รักษาความสามารถในการทำงานร่วมกันได้เมื่อเปลี่ยนไปใช้โมเดลใหม่หรือย้ายแพลตฟอร์ม
  • ความปลอดภัยและการกำกับดูแลที่มีมาในตัว: MVM รับประกันความปลอดภัยผ่าน การตรวจสอบสิทธิ์, audit log และกลไกป้องกัน
    • เช่นเดียวกับ AC4A ที่ MVM ทำหน้าที่เป็น gatekeeper เพื่อยับยั้ง พฤติกรรมที่ไม่คาดคิด
  • การติดตามประสิทธิภาพอย่างโปร่งใส: การวินิจฉัยในรันไทม์ช่วยให้เห็น ประสิทธิภาพของโมเดล, การใช้ทรัพยากร และระดับการเข้าถึงข้อมูล
    • สามารถเปรียบเทียบความแม่นยำ ความมีประโยชน์ และการตอบสนองได้ผ่าน benchmark
  • การตรวจสอบผลลัพธ์ของโมเดล: ใช้เทคโนโลยีอย่าง zero-knowledge proof เพื่อตรวจสอบความสมบูรณ์ของผลลัพธ์ เสริมทั้งความน่าเชื่อถือและความรับผิดชอบ

บทสรุป

  • เครื่องเสมือนสำหรับโมเดล AI เป็นสิ่งจำเป็นเพื่อลดความซับซ้อนของระบบ AI และเพิ่มความสามารถในการทำงานร่วมกัน
  • ช่วยเสริม ความปลอดภัย, ความเป็นส่วนตัว, การพกพา และความน่าเชื่อถือ พร้อมเพิ่มความเร็วในการพัฒนาและความสามารถในการขยายของอีโคซิสเต็ม
  • จากงานวิจัยของบริษัทเทคโนโลยี สตาร์ตอัป และแวดวงวิชาการ ข้อกำหนดของ MVM สามารถมอบมาตรฐานที่ทำให้โมเดล AI โต้ตอบกันได้อย่างปลอดภัยและราบรื่น
  • เป้าหมายคือการสร้าง ฉันทามติ ร่วมกับชุมชนเกี่ยวกับความจำเป็นของข้อกำหนด MVM และองค์ประกอบที่ควรรวมไว้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-09-01
ความเห็นจาก Hacker News

  • ฉันคิดว่าบทความนี้ขาดคำอธิบายที่เป็นรูปธรรม เลยไม่แน่ใจว่ากำลังเสนออะไรกันแน่ VM (Virtual Machine) ไม่ว่าอย่างไรก็เกี่ยวข้องกับชุดคำสั่ง การควบคุมลำดับการทำงาน รีจิสเตอร์ ฯลฯ แต่บทความนี้กลับโฟกัสอยู่แค่เรื่อง authorization เท่านั้น สรุปแล้วดูเหมือนกำลังพูดถึง 'อะไรบางอย่างที่คล้าย sandbox, jail, container ที่ทำให้โมเดลโต้ตอบกับโลกภายนอกได้'

    • ก็เลยสงสัยว่าเขากำลังพูดถึง VM execution engine จริง ๆ หรือ Docker สำหรับ LLM กันแน่ โดยรวมดูเหมือนเป็นการเล่าแบบห่อแพ็กเกจมากกว่า ฉันคิดว่าถ้าออกแบบระบบแพ็กเกจไม่ดีอาจกลายเป็นหายนะได้ ดูได้จากประสบการณ์เรื่อง packaging ของ Python ที่มีมาหลายแบบ

    • พอเห็นคำว่า VM ฉันก็รู้สึกทันทีว่ามันใกล้เคียงกับ sandbox มาก ในบทความเองก็พูดถึง "การแยก" อยู่แล้ว เลยไม่ได้รู้สึกว่าคลุมเครือหรือข้อมูลไม่พอ เพียงแต่ข้ออ้างของผู้เขียนมันสามัญเกินไป และโซลูชันก็ยังไม่สมบูรณ์ ต่อให้เอาไปไว้ใน sandbox ระดับ OS หรือฮาร์ดแวร์ ถ้าเอเจนต์ไปเจอ AWS CLI ที่ตั้งค่า IAM ผิดก็ยังแย่อยู่ดี ขอบเขตระยะไกลก็ซับซ้อนเหมือนกัน ฉันไม่เห็น insight ใหม่อะไร คิดว่าปัญหาไม่ได้อยู่ที่การเลือกคำศัพท์

    • ถ้าตามคำนิยามในบทความ ก็อาจมองได้ว่า AI agent ปัจจุบันก็รันอยู่ใน VM แล้วเหมือนกัน เช่น ใน MCP host สามารถถามผู้ใช้เพื่อขอความยินยอมก่อนรัน หรือมี rule แบบ Claude code ที่อนุมัติคำสั่งบางแพตเทิร์นอัตโนมัติได้

  • ฉันคิดว่าประเด็นสำคัญไม่ใช่ว่าจะให้เครื่องมืออะไรกับ LLM แต่คือจะยอมให้มันทำพฤติกรรมแบบไหนได้บ้าง เช่น ในกรณีจองตั๋วเครื่องบิน เราอยากให้ LLM ช่วยเทียบราคาจากหลายเว็บไซต์และจ่ายเงินให้เสร็จได้ แต่ก็ไม่อยากให้มันดันเลือกตั๋วถูกกว่า 3 ดอลลาร์แต่ใช้เวลาเดินทาง 37 ชั่วโมงแบบไร้สาระ เรื่องดูข้อมูลสวัสดิการก็ควรดูได้เฉพาะของตัวเอง ไม่ควรเห็นของเพื่อนร่วมงาน เครื่องมือเดียวกันแต่ขอบเขตสิทธิ์ต่างกัน ฝ่าย HR ย่อมดูข้อมูลพนักงานที่ตัวเองดูแลได้ แต่กรณีนั้นก็มีประเด็นเพิ่มอย่าง audit log ด้วย นั่นคือ intent สำคัญกว่าพฤติกรรมเสียอีก ควรวาง LLM ไว้ในฐานะตัวแทนของผู้ใช้ และให้อยู่ในกล่องสิทธิ์เดียวกัน

    • ที่พูดมาทั้งหมดก็คือ capability security model นั่นเอง ต้องส่งต่อ capability ที่ software agent เข้าถึงได้ให้มันอย่างชัดเจน และการกระทำที่อยู่นอกลิสต์นี้ต้องทำไม่ได้ในเชิงกายภาพ แต่ในความเป็นจริงไม่มี mainstream OS ตัวไหนที่ทำโมเดลนี้ได้จริง มีงานวิจัยและความพยายามอยู่บ้าง (ตัวอย่าง OS: EROS, Fuchsia, Sandstorm) แต่ไม่ค่อยประสบความสำเร็จในตลาด เพราะงั้นวิธีที่ใกล้เคียงที่สุดในทางปฏิบัติคือใช้ VM แล้วใส่เฉพาะเครื่องมือที่ต้องการลงไปใน VM วิธีนี้ไม่สมบูรณ์ เพราะตัวเครื่องมือเองก็ทั่วไปเกินไปเมื่อเทียบกับ capability ที่แท้จริง ซอฟต์แวร์ที่สร้างบนหลัก least privilege มักล้มเหลวในตลาดอยู่บ่อย ๆ

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

    • มอง LLM agent เป็น user อีกคนหนึ่งที่มีสิทธิ์เท่าผู้ใช้ก็ได้ แต่มีสิทธิ์ต่างกันไปตาม context เช่น บางโฟลเดอร์ซอร์สโค้ดมีสิทธิ์อ่าน/เขียน บางโฟลเดอร์อ่านได้อย่างเดียว สิทธิ์ที่ LLM agent มีในแต่ละโปรเจกต์จึงต่างกัน และเป็นผลตัดกันหรือสับเซตของสิทธิ์ผู้ใช้ โดยพื้นฐานมีสิทธิ์ 3 แบบคือ Allow, Deny และ Ask (ขออนุญาต) และถ้าจำเป็นก็ถามผู้ใช้ก่อน ปัญหาคือสิทธิ์ใน OS ปัจจุบัน รวมถึงสิทธิ์ของแอปและข้อมูล ยังละเอียดไม่พอ แม้แต่ git ก็ควรถูกออกแบบให้อนุญาตเฉพาะบางคำสั่ง ไม่ใช่เข้าถึงทุกอย่างได้ ตอนนี้แต่ละแอปเลยต้องจำลองสิ่งนี้กันเองใน userspace แบบฝืน ๆ เวิร์กโฟลว์คล้าย sudo ถ้าฉันเปิดแอปด้วย LLM Agent user ของตัวเอง สิทธิ์จะถูกให้หรือจำกัดตาม context นั้น และจะทำอะไรได้ภายในขอบเขตที่ฉันอนุญาตเมื่อฉันร้องขอเท่านั้น แต่ตอนนี้แต่ละแอปแบบ agentic ต้องไปทำกระบวนการนี้กันเอง จึงควรทำให้เป็นบริการระดับ OS อย่างเป็นระบบ ชั่วคราวอาจเลี่ยงด้วยการสร้าง/ลบบัญชีผู้ใช้ชั่วคราวตาม agent context แล้วสื่อสารกันผ่าน IPC หรือเครือข่ายเท่านั้น

    • ฉันสงสัยว่าโมเดลแบบนี้จะทำงานได้จริงไหม ต่อให้ LLM ทำอะไรได้ เว็บไซต์ต่าง ๆ ก็อาจตรวจจับแล้วปรับราคาหรือทำให้ decision tree พังได้ แบบนั้นสู้ให้ทุกเว็บไซต์มี API สำหรับ LLM หรือใช้ 'rss + json' ไปเลยน่าจะดีกว่า มาก เหมือน BBS หรือระบบเมนูผ่าน SMS ที่ให้แค่ข้อมูลเรียบง่ายกับตัวเลือก แบบนั้นเหมาะกับ LLM ที่สุด โฆษณาก็เหมือนกัน ไม่จำเป็นต้องโชว์โฆษณาให้ LLM ดู แถมโฆษณาที่พยายามหลอก LLM จะยิ่งมีประสิทธิภาพกว่า เช่น ตอนค้นหาเที่ยวบิน โฆษณาอาจล่อให้ LLM เชื่อว่าสินค้าของตัวเองดีที่สุดก็ได้ เพราะตอนนี้ AI ยังเรียบง่ายอยู่ ถ้ามีโฆษณาสำหรับ AI โดยเฉพาะก็น่าจะน่าสนุกดี

    • ถ้ากำหนดและบังคับใช้ความหมายของ “คำตอบที่ดี” ได้จริง ก็อาจไม่จำเป็นต้องใช้ LLM เองด้วยซ้ำ ในกรณี HR เราอาจถาม intent ตรง ๆ ได้ แต่กับ LLM นั้นยากเพราะมันไม่มี intent

  • ก่อนหน้านี้ฉันเคยเห็นโพสต์ HN ที่ John Carmack บอกว่าการทำ XROS ที่ Meta เป็นการเสียทั้งเวลาและเงิน แต่บทความที่เห็นวันนี้กลับย้ำแรงมากถึง 'ความจำเป็นของ OS แบบใหม่' VM อาจไม่ใช่ OS เต็มรูปแบบ แต่ต่างกันตรงที่มันนำ OS/โค้ดเบสเดิมมาใช้แล้วทำให้เบาได้

    • สองบทความนั้นพูดกันคนละเรื่องเลย จริง ๆ แล้วฉันก็ไม่เห็นว่าบทความนี้กำลังย้ำแรงถึงความจำเป็นของ VM หรือ OS ใหม่ด้วย สุดท้ายทั้งหมดก็เป็นแค่เรื่อง access control

    • ฝั่ง XR เน้นเรื่อง performance กับ dev experience เป็นหลัก แต่ฝั่ง LLM แก่นของปัญหาคือจะ sandbox และทำให้การเข้าถึง tool/data เรียบง่ายได้อย่างไร ต้องทำอีกเยอะเพื่อไม่ให้ LLM ทำลายสภาพแวดล้อมรันไทม์หรือทำข้อมูลเสียหาย และถ้ามีมาตรฐานก็จะลดภาระการฝึกซ้ำและทำให้ใช้โมเดลของคนอื่นได้สะดวกขึ้น XR ถ้ามีแค่ SDK ก็มักแก้ได้ด้วยการเทรน แต่ AI มีต้นทุนวิจัยพัฒนาและ compute สูงกว่ามาก

    • WebAssembly มี sandbox มาให้โดยพื้นฐาน ดังนั้นผมว่ามาได้ครึ่งทางแล้ว ที่เหลือคืออินเทอร์เฟซที่ชัดเจนสำหรับการย้ายข้อมูล/สิทธิ์ระหว่าง instance และวิธีที่ instance ต่าง ๆ จะสร้างกันและกันได้

    • ฉันไม่คิดว่าบทความนี้เป็นเหตุผลเพียงพอให้เขียน OS ใหม่ การสร้าง execution environment สำหรับ AI กับการออกแบบ OS ที่เหมาะกับ AI จากศูนย์เป็นคนละเรื่องกันโดยสิ้นเชิง

  • หลังจากอ่านบทความละเอียดและตามดูลิงก์อ้างอิงแล้ว ฉันรู้สึกว่าบทความนี้กำลังชี้ปัญหาที่ลึกกว่าคำว่า "VM สำหรับ AI" เฉย ๆ VM อย่างเดียวไม่พอจะรับผิดชอบความปลอดภัยของ LLM workflow ได้ workflow ระดับบนสุดต้องเข้าถึงงานและข้อมูลอ่อนไหว เช่น เครือข่าย PII credentials ฯลฯ และ LLM ก็เปราะบางต่อ prompt injection กับปัญหาความสอดคล้อง แค่เอา LLM ไปใส่ VM ไม่ได้แก้ปัญหา ต้องมี 'การจัดการการไหลของข้อมูล' โดย partition workflow ข้อมูล และการประมวลผลตามหน่วยงาน เพื่อให้งานย่อยขั้นต่ำเท่านั้นที่เข้าถึงข้อมูลแบบจำกัดได้ และมีเพียง subset ที่ดูแลงานอ่อนไหวเท่านั้นที่ต้องถูกเชื่อถือและตรวจสอบ สิ่งสำคัญในบทความคือ “Secure Orchestrators” ที่กล่าวถึง และ งานวิจัย FIDES “VM” ในที่นี้สุดท้ายก็คือการรัน task ในคอนเทนเนอร์ที่ให้เฉพาะสิทธิ์/ข้อมูลแบบจำกัด orchestrator ต้องเป็นคนสร้างคอนเทนเนอร์นี้ กำหนดสิทธิ์ที่เหมาะสม และติดป้ายระดับความอ่อนไหวให้ข้อมูลผลลัพธ์ด้วย (taint-tracking) โดยรวมฉันคิดว่าคำอย่าง “partitioning” หรือ “isolation” และการเน้นประเด็นเรื่องข้อมูล น่าจะเหมาะกว่า “VM for AI”

    • ฟังดูคล้าย Microsoft Wassette

    • เป้าหมายควรเป็นการลบแนวคิดเรื่อง workflow ออกไปเลย ในโลกของ LLM+VM แค่การให้ tool กับ LLM ก็ถือเป็น workflow แล้ว วิธีนี้ทุกวันนี้ก็ใช้ได้ผลดีเป็นบางครั้ง แต่มีข้อจำกัดกับงานที่ต้องใช้ tool หรือสถานการณ์ยกเว้นที่ไม่ได้นิยามไว้ล่วงหน้า ยิ่งไปกว่านั้น แนวทางแบบ workflow ก็มักหนีไม่พ้นข้อจำกัดแบบเชิงเส้นเสมอ (หรือ DAG รวมถึง loop) ขั้นต่อไปคือไม่ให้ tool เลย แล้วให้ LLM สร้าง tool ขึ้นมาเองสด ๆ ตอนต้องใช้ บางปัญหาจำเป็นต้องใช้แนว brute-force

  • ระหว่างอ่าน ฉันถึงกับรู้สึกว่าบทความสมัยนี้เหมือน AI เขียนเองไปแล้ว จากมุมโฮสติ้ง การทำให้ AI agent ลุกขึ้นมารันได้อย่างเสถียรในทุกสภาพแวดล้อมก็เป็นความท้าทายใหญ่มากแล้ว ในฐานะนักพัฒนา ฉันใช้ rootless docker devcontainer บน wsl อยู่ แม้มัลแวร์บางชนิดอาจเจาะได้ แต่ก็ยังรู้สึกว่าวิธีนี้ปลอดภัยกว่าแนวทาง VM แถมยังมีข้อดีเรื่อง reproducibility และการแยกสภาพแวดล้อมด้วย และถ้า AI ทำสภาพแวดล้อมฉันพังก็แค่ยกคอนเทนเนอร์ขึ้นใหม่ ภาระทางใจก็น้อยกว่า

  • ถ้ามองวิธี deploy โมเดลที่พัฒนาไปไกลที่สุดในเชิงพาณิชย์ จะเห็นว่าแทบทุกคุณสมบัติที่บทความนี้พูดถึง เช่น การแยกสภาพแวดล้อม นั้นมีใช้อยู่แล้ว แม้ไม่ถึงระดับ OS แท้ ๆ แต่ฟังก์ชันก็คล้ายกัน ถึงอย่างนั้นก็ยังไม่พอ ถ้าอยากให้เอเจนต์ทำงานได้จริง มันต้องเข้าถึงทรัพยากรสำคัญ และการให้สิทธิ์เท่าที่จำเป็นพอดีนั้นยากกว่าการแยก LLM เองเสียอีก โมเดลที่แม่นยำสำหรับความปลอดภัยของ LLM คือ 'untrusted userspace' ไม่จำเป็นต้องออกแบบ OS ทั้งชุด

    • ฉันเห็นด้วยว่าแนวคิด 'untrusted userspace' นั้นตรงประเด็น วิธีแบบนี้อาจช่วยด้านความปลอดภัยได้อยู่บ้างในระดับละเอียด แต่ฉันไม่เห็นด้วยกับส่วนที่ผู้เขียนพูดเกินจริงราวกับว่ามัน “รับประกัน” อะไรได้ เขาเทียบการเข้าถึง tool กับสิทธิ์ไฟล์ แต่จริง ๆ แล้วประวัติของ file permission ใน OS ก็ไม่ได้ดีอะไร ถ้าจะตรวจว่าควรอนุญาตให้ใช้เครื่องมือจองหรือไม่ สุดท้ายมันก็คือเว็บเบราว์เซอร์อยู่ดี และเบราว์เซอร์ก็เป็นเครื่องมือสารพัดประโยชน์ที่อาจถูกโจมตีแบบ jailbreak ได้เช่นกัน ประเด็นสำคัญคือแม้อยู่ภายใต้ข้อจำกัดของ virtual machine แบบนี้ เราก็ยังต้องมีมาตรการความปลอดภัยแบบใหม่เพื่อไม่ให้โมเดล AI แสดงพฤติกรรมเป็นกบฏ สุดท้ายก็ได้บทเรียนเรียบง่ายว่าเรายังจำเป็นต้องแก้ปัญหา 'alignment'

  • ฉันเห็นด้วยว่าการแยก LLM ควรถูกทำอย่างเคร่งครัดถึงระดับการออกแบบ VM ด้วยเหตุผลเดียวกับที่ระบบปฏิบัติการแบบดั้งเดิมบังคับใช้สิ่งเหล่านี้อย่างเข้มงวด ไม่นานมานี้ฉันเคยสรุปไอเดียไว้ในบล็อกนี้ โดยเทียบวิธีทำงานของ LLM กับ process/task ใน OS แบบดั้งเดิม abstraction หลัก ๆ ไม่ได้ยากเกินจะทำ — ฉันรวม chat/tool interface ของ LLM backend 8 ตัวเพื่อให้จัดการ tool approval จากศูนย์กลางได้ ยังไม่ได้ทำ capabilities model แต่จากประสบการณ์กับ OS เก่าอย่าง VSTa มันเป็นวิธีที่ธรรมชาติมาก LLM ตัวหนึ่งควรสามารถมอบหมายสับเซตของสิทธิ์ที่ตนมีให้ LLM อีกตัวได้ และตอนนี้ก็ทำเครื่องมือ delegation ไว้แล้ว

  • ฉันคิดว่าการสร้าง abstract machine ใหม่แบบ VM มีแต่จะเพิ่มความซับซ้อน ทั้งที่เรามีบัญชีผู้ใช้ สิทธิ์อ่าน/เขียน/รันไฟล์ และการเข้าถึงชั่วคราวหรือระยะไกลผ่าน access token ซึ่งครอบคลุมได้เพียงพอแล้ว capability model ทุกแบบน่าจะสร้างได้บนแนวคิดพวกนี้ ฉันเลยมองว่าการทำให้เครื่องมือที่มีอยู่เรียบง่ายลงเป็นแนวทางที่ดีกว่า ตอนนี้ทุกคนกำลังทดลองของใหม่กันมาก โดยหวังการเปลี่ยนแปลงครั้งใหญ่ของซอฟต์แวร์ทั้งระบบ แต่ฉันคิดว่าเราควรใช้ช่วงนี้เพื่อลดความซับซ้อนที่ไม่จำเป็นและทำทุกอย่างให้เรียบง่ายขึ้น เช่น เปลี่ยน MCP server เป็น CLI tool ง่าย ๆ ด้วย Claude ใช้เวลาแค่ 10 นาที เท่านี้ก็ใช้งานได้ดีพอแล้ว

    • โมเดลความปลอดภัยของ desktop OS สมัยใหม่ทุกวันนี้อ่อนแออย่างน่าเหลือเชื่อ การมอบสิทธิ์ทุกอย่างให้โปรแกรมโดยแทบไม่มีคำเตือนหรือการยืนยันใด ๆ เป็นเรื่องแทบจะบ้าคลั่ง ถ้าผู้ใช้ต้องการสภาพแวดล้อมที่ไม่จำกัดจริง ๆ ก็ควรมีตัวเลือกให้ แต่ค่าเริ่มต้นต้องเป็น least privilege ควรให้สิทธิ์เป็นรายโปรแกรมและรายโดเมน เช่น ถ้าเป็นเครื่องมือ visualise การใช้ดิสก์ มันอาจต้องเข้าถึงระบบไฟล์ทั้งหมด แต่ไม่จำเป็นต้องเข้าถึงเครือข่ายท้องถิ่นหรืออินเทอร์เน็ตเลย

    • จุดแข็งที่สุดของ VM คือการจำกัดขอบเขตความเสียหาย agent ที่เก่งพออาจใช้ zero day เพื่อเจาะระบบได้ง่าย ๆ แค่สิทธิ์ระดับผู้ใช้ก็น่ากลัวมากแล้ว และการจำกัดความรู้ของเอเจนต์ด้วยไฟร์วอลล์เป็นเรื่องยากมาก เพราะมีวิธีอ้อมได้จากอินเทอร์เน็ตเต็มไปหมด มันจะเก่งมากในการแคร็กระบบแบบนี้ จึงต้องมีมาตรการความปลอดภัยที่แข็งมาก

    • ในสภาพแวดล้อมของ LLM แนวคิดเรื่องอ่านครั้งเดียว ('temporary read') ใช้ไม่ได้ ทันทีที่ข้อมูลเข้าไปอยู่ใน context ก็ต้องถือว่ามันอาจรั่วไปยังทุกที่ที่เชื่อมต่ออยู่ได้จนกว่าเอเจนต์จะตายและ context จะถูกลบ เรื่องนี้ไม่ว่าจะมี VM หรือไม่ก็เหมือนกัน และ VM อย่างเดียวก็ไม่ใช่คำตอบด้านความปลอดภัย

    • เห็นด้วยเป็นส่วนใหญ่ ความเสี่ยงด้านความปลอดภัยหลายอย่างเกิดขึ้นได้ไม่ว่าจะมี VM หรือไม่ ต่อไป defense in depth จะยิ่งสำคัญขึ้น แต่ตอนนี้ยังมีช่องทางง่ายเกินไปที่ผู้โจมตีจะใช้ AI agent มาทำร้ายผู้ใช้ได้

    • ทันทีที่อนุญาตให้ใช้เครื่องมือแก้ไขไฟล์ ความปลอดภัยแทบทั้งหมดก็หายไปแล้ว

  • ฉันคิดว่า Fuchsia อาจเป็น OS ที่ใช้งานได้จริงสำหรับควบคุมพฤติกรรมของโมเดล AI เพราะมันเป็น object capability OS ทำให้แต่ละคอมโพเนนต์ (process) เข้าถึงได้เฉพาะ capability ที่ถูกมอบให้อย่างชัดเจน

    • ฉันชอบและเห็นด้วยกับดีไซน์ของ Fuchsia แต่ไม่คิดว่ามันจะเกิดขึ้นจริง ในทางปฏิบัติน่าจะมีโอกาสมากกว่าที่เราจะเห็นโมเดลคล้าย Fuchsia บน WASM/WASI component ซึ่งโฮสต์ได้ตั้งแต่คลาวด์ถึงมือถือ แทนที่จะสร้าง OS ใหม่ขึ้นมา

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

    • Devin และ OpenHands ก็คล้ายกัน ในโปรเจกต์ AI pilot ที่ฉันทำเมื่อไม่กี่เดือนก่อนเอง 'รัน agent ใน VM (เป็นค่าเริ่มต้น)' ก็เป็นองค์ประกอบหลัก

    • มันอยู่บน Kubernetes ที่ใช้ AKS (Azure Kubernetes) พร้อม gvisor และ Jupyter ครอบอยู่

    • ไม่จำเป็นเสมอไป เช่น ถ้าสมมติว่ามี AI สองตัว (อย่าง ChatGPT เป็นต้น) รันอยู่บนเครื่องเดียวกัน ตอนนี้ยังไม่มีทั้งมาตรฐานเรื่องการทำงานร่วมกันหรือ interoperability ระหว่างกันเลย