Microsoft เปิดตัว AI stack ที่เน้นเอเจนต์ (agent-centric) ในงาน Cloud and AI Innovation Day ที่เมืองเบงกาลูรู โดยเปิดตัวสิ่งที่เรียกว่า Microsoft IQ, Fabric IQ, เลเยอร์ Ontology และการกำกับดูแลแบบ Agent 365 การเคลื่อนไหวครั้งนี้เป็นการเปลี่ยนจุดเน้นจากแชทบอทแบบโดดเดี่ยวไปสู่ "เอเจนต์" (agents) ที่ทำงานได้ด้วยตนเองและสามารถท่องไปในบริการคลาวด์ของบริษัท ซึ่งบีบให้องค์กรต้องคิดใหม่ว่าจะสร้าง รัน และควบคุม AI อย่างไร
ทำไมการเปลี่ยนแปลงนี้ถึงสำคัญในตอนนี้
บริษัทส่วนใหญ่ติดขัดในช่วงระหว่างการทำ proof-of-concept ไปสู่การใช้งานจริงอย่างเต็มรูปแบบ คอขวดไม่ใช่ตัวโมเดล แต่คือ "ระบบท่อ" (plumbing)—ซึ่งก็คือการกำกับดูแล (governance), อัตลักษณ์ (identity) และการสังเกตการณ์ (observability) ที่จะทำให้เอเจนต์มีความน่าเชื่อถือและเป็นไปตามข้อกำหนด AI stack ใหม่ของ Microsoft จะเข้ามาเติมเต็มระบบท่อเหล่านี้ โดยนำเสนอเลเยอร์อัจฉริยะที่สามารถนำกลับมาใช้ใหม่ได้ ซึ่งสามารถทำงานบนแพลตฟอร์มข้อมูลและโมเดลภาษาขนาดใหญ่ (LLM) ใดก็ได้
องค์ประกอบหลักที่ Microsoft นำเสนอ
- Microsoft IQ – เลเยอร์อัจฉริยะที่อยู่ใน tenant ของลูกค้า ช่วยให้พวกเขาสามารถควบคุม prompt, หน่วยความจำ (memory) และนโยบาย (policy) ได้โดยตรง
- Fabric IQ – ความสามารถแบบเดียวกันที่ถูกรวมเข้ากับบริการ data-fabric ของ Microsoft เพื่อให้การวิเคราะห์และ AI ใช้บริบท (context) ร่วมกัน
- Ontology – โมเดลที่เครื่องสามารถอ่านได้ (machine-readable) ของกระบวนการทางธุรกิจ, เอนทิตี (entities) และความสัมพันธ์ต่างๆ ช่วยให้เอเจนต์เข้าใจว่า "ใครทำอะไร" โดยไม่ต้องเขียนกฎแบบ hard-coding
- Agent 365 – กรอบการกำกับดูแลที่เชื่อมโยงอัตลักษณ์ (identity), การเข้าถึงตามบทบาท (role-based access) และเส้นทางการตรวจสอบ (audit trails) เข้ากับเอเจนต์ AI ทุกตัว ทำให้สามารถปฏิบัติกับเอเจนต์ได้เหมือนกับพนักงานในระบบ HR หรือระบบรักษาความปลอดภัย
องค์ประกอบเหล่านี้จะเปลี่ยนจาก "แชทบอท" ให้กลายเป็น "เพื่อนร่วมงานดิจิทัล" (digital coworker) ที่สามารถดึงข้อมูล, กระตุ้นเวิร์กโฟลว์ และตัดสินใจภายใต้ขอบเขตขององค์กรได้
สิ่งที่ผู้ปฏิบัติงานสามารถนำไปใช้ได้ตั้งแต่วันนี้
- กำหนดคำบรรยายลักษณะงาน (job description) ของเอเจนต์ – ปฏิบัติต่อผู้ช่วย AI แต่ละตัวในฐานะบทบาทที่มีทักษะ คำแนะนำ และอัตลักษณ์เฉพาะตัว เมื่อเอเจนต์ทำงานผิดพลาด ให้ตรวจสอบความรับผิดชอบที่กำหนดไว้ก่อน ไม่ใช่แค่ตรวจสอบ prompt ที่กระตุ้นมันขึ้นมา
- ทำให้โมเดลสามารถสลับเปลี่ยนกันได้ – ด้วยการแยก LLM ออกจากโครงสร้างพื้นฐานโดยรอบ บริษัทจะสามารถสลับจาก GPT เป็น Claude, Llama หรือโมเดลอื่นๆ ในอนาคตได้โดยไม่ต้องสร้าง stack ใหม่ทั้งหมด การลงทุนจะอยู่ที่เลเยอร์การประสานงาน (orchestration layer) ไม่ใช่ที่ตัวโมเดลเอง
- ใช้การ "ห่อหุ้ม" แทนการ "รื้อถอน" (Wrap, don't rip) – ระบบเก่า (Legacy systems) สามารถเชื่อมต่อกับ AI ได้ผ่านตัวปรับต่อ (adapters) เช่น Kotak Mahindra ได้สาธิตเรื่องนี้โดยการวาง Azure Voice Live ทับบนระบบโทรศัพท์ที่มีอยู่เดิม ซึ่งพิสูจน์ให้เห็นว่าไม่จำเป็นต้องรื้อระบบใหม่ทั้งหมด
- มองว่าการปรับจูนเป็นกระบวนการที่ต่อเนื่อง – การทำ Fine-tuning ต้องมีวงจรที่เตรียมข้อมูล, ฝึกฝน, ประเมินผล และตรวจสอบประสิทธิภาพ หากไม่มีท่อส่งการประเมินผล (evaluation pipeline) ความพยายามในการปรับจูนใดๆ ก็จะเป็นไปอย่างไร้ทิศทาง
- เริ่มต้นด้วยข้อมูลที่สะอาด – ผู้เข้าร่วมงานรายหนึ่งเปิดเผยว่า หนึ่งในสี่ของรายงานที่พวกเขามีไม่เคยถูกนำมาใช้งานเลย การป้อนข้อมูลที่ยุ่งเหยิงเข้าสู่เอเจนต์มีแต่จะทำให้ความยุ่งเหยิงนั้นทำงานได้โดยอัตโนมัติมากขึ้น ดังนั้นโครงการด้านคุณภาพข้อมูลและการจัดระเบียบรายงานควรเกิดขึ้นก่อนการนำ AI มาใช้ในวงกว้าง
ไอเดียที่เป็นรูปธรรมสำหรับ Enterprise Stack
- สร้างแดชบอร์ดการสังเกตการณ์ (observability dashboard) แบบรวมศูนย์เพื่อติดตามค่าใช้จ่ายที่เกี่ยวข้องกับ AI, ความหน่วง (latency) และความสมบูรณ์ของท่อส่งข้อมูล (pipelines)
- ใช้โปรโตคอล MCP เพื่อเปิดให้เอเจนต์เข้าถึงคลังข้อมูลภายใน (internal data warehouses) โดยรักษาความปลอดภัยและการตรวจสอบการเคลื่อนย้ายข้อมูล
- สร้างโมเดลเชิงความหมาย (semantic models) ที่แปลงคำถามด้านการจัดการต้นทุนให้เป็นภาษาธรรมชาติ ช่วยให้ทีมการเงินสามารถถามว่า "ค่าใช้จ่ายคลาวด์ในไตรมาสที่แล้วเป็นอย่างไร?" และได้รับคำตอบในทันที
- ทดลองใช้ GitHub Copilot ในทีมพัฒนาเพื่อทำ code reviews แบบอัตโนมัติ โดยวัดทั้งความเร็วที่เพิ่มขึ้นและการลดลงของข้อผิดพลาด (defect reduction)
