ผู้นำทางความคิด
ศึกครั้งต่อไปของ SaaS เริ่มต้นเหนือชั้น MCP

Model Context Protocol กำลังมอบวิธีมาตรฐานให้ AI เชื่อมต่อกับซอฟต์แวร์ระดับองค์กร Vrushali Paunikar ประธานเจ้าหน้าที่ฝ่ายผลิตภัณฑ์ของ Carta มองว่า ความท้าทายที่ใหญ่กว่าคือการตัดสินใจว่าจะเกิดอะไรขึ้นหลังเชื่อมต่อแล้ว และควรมอบหมายงานให้โมเดลภาษาทำมากน้อยเพียงใด
ในช่วงปีที่ผ่านมา Model Context Protocol เปลี่ยนจากมาตรฐานทางเทคนิคที่ค่อนข้างเป็นที่รู้จักในวงแคบ มาเป็นหนึ่งในแนวคิดสำคัญที่สุดของ AI ระดับองค์กร
MCP มอบวิธีมาตรฐานให้แอปพลิเคชัน AI เชื่อมต่อกับซอฟต์แวร์ภายนอก เข้าถึงข้อมูล และดำเนินการต่าง ๆ แทนที่บริษัทซอฟต์แวร์แต่ละแห่งจะต้องสร้างส่วนเชื่อมต่อเฉพาะสำหรับโมเดล AI แต่ละตัว MCP กลับทำหน้าที่เป็นภาษากลาง
ลองนึกภาพว่า MCP เป็นเต้ารับไฟฟ้าบนผนังบ้าน มันคือมาตรฐานกลางที่ทำให้อุปกรณ์ใด ๆ เสียบปลั๊กและรับพลังงานได้ ข้อดีคือเป็นมาตรฐานเปิดและใช้งานได้ทุกที่ แต่เต้ารับเพียงอย่างเดียวไม่ได้ทำอะไรให้คุณ คุณยังต้องมีเครื่องใช้ไฟฟ้า
ผมคิดว่าเมื่อมองย้อนกลับมา เราอาจมองกระแสความสนใจ MCP ในปัจจุบันคล้ายกับที่มองการเติบโตของ API ซึ่งเป็นรากฐานสำคัญและเปลี่ยนวิธีสร้างซอฟต์แวร์ แต่เมื่อเวลาผ่านไป การเชื่อมต่อก็กลายเป็นโครงสร้างพื้นฐานที่ทุกคนคาดหวัง แทนที่จะเป็นตัวผลิตภัณฑ์เอง
ขณะนี้ อุตสาหกรรม SaaS ส่วนใหญ่กำลังมองว่าการเชื่อมต่อกับ AI เป็นผลิตภัณฑ์ที่เสร็จสมบูรณ์แล้ว เพียงสร้างเซิร์ฟเวอร์ MCP เปิดให้เข้าถึงเครื่องมือและข้อมูลที่เหมาะสม แล้วปล่อยให้โมเดลจัดการต่อเอง
สำหรับกรณีใช้งานบางอย่าง แค่นั้นก็เพียงพอ แต่สำหรับขั้นตอนการทำงานขององค์กรจำนวนมาก โดยเฉพาะงานด้านการเงิน วิธีนี้ยังไม่เพียงพอ
MCP กำลังครองชั้นการเชื่อมต่อ
การกำหนดมาตรฐานกำลังเปลี่ยนวิธีที่แอปพลิเคชัน AI ทำงานร่วมกับซอฟต์แวร์ MCP ได้รับการรองรับจากแพลตฟอร์ม AI รายใหญ่จำนวนมากขึ้นเรื่อย ๆ ทำให้ผู้ใช้สามารถทำงานกับระบบพื้นฐานเดียวกันผ่านอินเทอร์เฟซ AI ที่ตนเองเลือกได้จริงมากขึ้น
อย่างไรก็ตาม แม้การทำงานร่วมกันได้จะแก้ปัญหาเรื่องการเข้าถึง แต่ก็ไม่ได้บอกโมเดลว่าควรทำงานนั้นอย่างไร
ผมใช้เวลาส่วนใหญ่คิดเกี่ยวกับซอฟต์แวร์ที่นักลงทุนในตลาดเอกชนและทีมการเงินใช้ ซึ่งเป็นบริบทที่ทำให้เห็นความแตกต่างนี้ได้ชัดเจนเป็นพิเศษ
ตัวอย่างเช่น หากให้ระบบ AI เข้าถึงข้อมูลผลการดำเนินงานและพอร์ตการลงทุนของกองทุนส่วนบุคคล ก็อาจมีวิธีตอบคำถามที่ฟังดูตรงไปตรงมาได้หลายแบบ
วิธีหนึ่งอาจใช้การคำนวณที่เหมาะสม อีกวิธีอาจเลือกใช้ทางลัด ส่วนอีกวิธีอาจเข้าใจผิดว่าผู้ใช้ต้องการอะไร
ผู้ใช้จึงต้องสวมบทบาททั้งนักวิเคราะห์ วิศวกรพรอมป์ต์ และผู้ควบคุมคุณภาพ ประสบการณ์เช่นนี้ไม่ใช่สิ่งที่เคยให้คำมั่นไว้ว่าจะใช้งานได้อย่างราบรื่น
ผลิตภัณฑ์ยังต้องมีจุดยืน
ชั้นถัดไปของระบบคือจุดที่น่าสนใจ หาก MCP เป็นชั้นการเชื่อมต่อ ปลั๊กอินและทักษะก็อยู่เหนือชั้นนั้น โดยบอกเอเจนต์ว่าจะใช้การเชื่อมต่อดังกล่าวเพื่อทำงานเฉพาะอย่างให้สำเร็จได้อย่างไร
แทนที่จะเพียงเปิดให้โมเดลเข้าถึงข้อมูลและฟังก์ชันต่าง ๆ สิ่งเหล่านี้ยังสามารถรวบรวมคำสั่ง ขั้นตอนการทำงาน การคำนวณแบบกำหนดผลลัพธ์แน่นอน และอินเทอร์เฟซเข้าไว้ด้วยกัน
บางครั้งอาจหมายถึงการทำตามลำดับขั้นตอนที่กำหนดไว้ บางครั้งอาจหมายถึงการเรียกใช้การคำนวณหรือสคริปต์ที่ให้ผลลัพธ์แน่นอน แทนที่จะให้ LLM คิดหาคำตอบเอง ในกรณีอื่น ผลลัพธ์สุดท้ายอาจเป็นสเปรดชีต รายงาน หรือแอปพลิเคชันขนาดเล็กที่ออกแบบมาโดยเฉพาะสำหรับขั้นตอนการทำงานนั้น
ความเชี่ยวชาญจึงอยู่ในตัวผลิตภัณฑ์ แทนที่จะปล่อยให้โมเดลรับผิดชอบทั้งหมด
หลักฐานแสดงให้เห็นว่าวิธีผสานทั้งสองอย่างเข้าด้วยกันได้ผล Google เพิ่งทดสอบเอเจนต์เขียนโค้ด AI ที่เข้าถึงเอกสารทางเทคนิคของ Google ผ่าน MCP ได้ จากนั้นจึงให้คำสั่งเพิ่มเติมที่เจาะจงกับงาน โดยอธิบายวิธีใช้ข้อมูลดังกล่าวให้เกิดประโยชน์สูงสุด เมื่อนำการเชื่อมต่อมาใช้ร่วมกับคำสั่งเหล่านั้น ผลการประเมินของ Google มีอัตราผ่าน 96.3% และใช้โทเค็นต่อคำตอบที่ถูกต้องน้อยกว่าการพรอมป์ต์แบบมาตรฐาน 63%
สำหรับบริษัท SaaS สิ่งนี้เปลี่ยนจุดที่สร้างความแตกต่างในการแข่งขัน หากทุกแอปพลิเคชันเปิดให้เข้าถึงข้อมูลผ่านมาตรฐานเปิดเดียวกัน การเข้าถึงเพียงอย่างเดียวก็จะมีความโดดเด่นน้อยลง แต่ความสามารถในการเปลี่ยนการเข้าถึงนั้นให้เป็นผลลัพธ์ที่เชื่อถือได้กลับมีคุณค่ามากขึ้น
ไม่ใช่ทุกงานที่ควรปล่อยให้โมเดลจัดการเอง
โมเดลภาษาขนาดใหญ่เป็นระบบเชิงความน่าจะเป็น ความยืดหยุ่นที่ทำให้โมเดลเหล่านี้มีประโยชน์ต่อการเขียน การสำรวจ และการใช้เหตุผล กลับไม่เหมาะนักกับขั้นตอนการทำงานที่ต้องอาศัยความแม่นยำและการทำซ้ำได้เหมือนเดิมทุกครั้ง การเงินเป็นตัวอย่างที่ชัดเจน หากใครคาดหวังว่าการคำนวณเดียวกันจะให้คำตอบเดิมทุกครั้ง ความแปรปรวนก็จะกลายเป็นปัญหาอย่างรวดเร็ว
ซอฟต์แวร์การเงินพัฒนามาหลายทศวรรษในทิศทางตรงกันข้าม ทั้งเส้นทางการตรวจสอบ สิทธิ์การใช้งาน การคำนวณที่เป็นมาตรฐาน และกระบวนการที่ทำซ้ำได้ ล้วนมีขึ้นเพราะความสม่ำเสมอเป็นสิ่งสำคัญ
AI ไม่ควรละทิ้งบทเรียนเหล่านั้น ผลิตภัณฑ์ AI ระดับองค์กรที่ดีที่สุดจะรู้ว่าเมื่อใดควรปล่อยให้โมเดลใช้เหตุผล และเมื่อใดควรกำหนดกรอบให้ระบบ ระบบเชิงความน่าจะเป็นเหมาะเมื่อการใช้วิจารณญาณและการตีความเป็นประโยชน์ ส่วนเครื่องมือที่ให้ผลลัพธ์แน่นอนเหมาะกว่าเมื่อจำเป็นต้องมีความแม่นยำและทำซ้ำได้
หลักการเดียวกันนี้ใช้ได้กับทุกกรณีที่การได้คำตอบผิดมีต้นทุนสูง
จุดที่ความแตกต่างของ SaaS จะขยับไปอยู่ในอนาคต
ชั้นที่กำลังก่อรูปเหนือ MCP ยังมีความชัดเจนน้อยกว่าตัว MCP เองมาก
มีแนวทางเกี่ยวกับปลั๊กอินและสกิลที่แตกต่างกันเกิดขึ้น แต่ก็เริ่มมีความพยายามทำให้สิ่งเหล่านี้พกพาไปใช้ข้ามแพลตฟอร์ม AI ได้มากขึ้น แทนที่จะผูกไว้กับระบบนิเวศใดระบบนิเวศหนึ่ง
บริษัท SaaS ยังคงต้องตัดสินใจ แม้ว่ามาตรฐานทั้งหมดจะยังไม่ลงตัว และที่ผ่านมา ก็เป็นเช่นนี้มาโดยตลอด
อีกทางเลือกหนึ่งคือเปิดอินเทอร์เฟซให้ใช้งาน แล้วปล่อยให้ลูกค้าประกอบประสบการณ์ใช้งานขึ้นเอง
AI อาจเดินไปในเส้นทางเดียวกัน การเชื่อมต่อเอเจนต์เข้ากับซอฟต์แวร์ระดับองค์กรทำได้ง่ายขึ้นในทุก ๆ เดือน ข้อได้เปรียบจะยิ่งอยู่ที่สิ่งที่เกิดขึ้นหลังจากนั้น นั่นคือเวิร์กโฟลว์ กลไกควบคุม และความเชี่ยวชาญเฉพาะด้าน ซึ่งช่วยบอกเอเจนต์ว่าจะเปลี่ยนการเข้าถึงให้เป็นผลลัพธ์ที่เชื่อถือได้ได้อย่างไร












