Semantic Kernel คืออะไร: SDK จัดการ AI ของ Microsoft

หากคุณพัฒนาซอฟต์แวร์บน Microsoft stack และต้องการเพิ่ม AI โดยไม่ต้องผูกบริการ Python เข้าไปเสริม Semantic Kernel คือ SDK ที่ Microsoft สร้างขึ้นมาเพื่อคุณ เป็นชุดเครื่องมือโอเพนซอร์สที่เชื่อมต่อโค้ดและ API ที่มีอยู่ของคุณเข้ากับโมเดลภาษาขนาดใหญ่ และสามารถรันได้ใน C#, Python และ Java คู่มือนี้จะอธิบายว่า Semantic Kernel คืออะไร แกนหลักและปลั๊กอินทำงานร่วมกันอย่างไร และการรองรับ OpenAPI specification ของมันจะเปลี่ยน REST API ใดๆ ให้เป็นสิ่งที่โมเดลสามารถเรียกใช้งานได้อย่างไร

Semantic Kernel คืออะไร

Semantic Kernel (SK) เป็นชุดพัฒนาโอเพนซอร์สที่มีน้ำหนักเบาจาก Microsoft สำหรับสร้างเอเจนต์ AI และผสานรวมโมเดลเข้ากับโค้ดเบสของคุณ Microsoft อธิบายว่าเป็นมิดเดิลแวร์: มันอยู่ระหว่างแอปพลิเคชันของคุณกับโมเดล แปลงคำขอของโมเดลเป็นการเรียกฟังก์ชันจริง รันฟังก์ชันเหล่านั้น และส่งผลลัพธ์กลับไป คุณเขียนโค้ดปกติ และโมเดลจะตัดสินใจว่าจะเรียกใช้เมื่อใด

สามสิ่งที่ทำให้ SK โดดเด่นกว่าไลบรารีเอเจนต์อื่นๆ

ประการแรก มันรองรับหลายภาษาอย่างแท้จริง SK มี SDK อย่างเป็นทางการสำหรับ C#/.NET, Python และ Java พร้อมการรับประกันความเสถียรเวอร์ชัน 1.0+ สำหรับทั้งสามภาษา เฟรมเวิร์กเอเจนต์ส่วนใหญ่เน้น Python เป็นหลัก และมักจะมองข้ามภาษาอื่นๆ หากแบ็กเอนด์ของคุณเป็น .NET, SK เป็นหนึ่งในไม่กี่ตัวเลือกที่ครบวงจรและให้ความรู้สึกเหมือนเป็นส่วนหนึ่งของระบบ

ประการที่สอง มันไม่ยึดติดกับโมเดลใดๆ SK เชื่อมต่อกับ OpenAI, Azure OpenAI และผู้ให้บริการอื่นๆ ผ่านชุดตัวเชื่อมต่อ เมื่อคุณต้องการเปลี่ยนโมเดล คุณเพียงแค่เปลี่ยนการกำหนดค่า ไม่ใช่ทั้งแอปพลิเคชันของคุณ

ประการที่สาม มันถูกสร้างขึ้นโดยคำนึงถึงข้อกังวลขององค์กรเป็นหลัก Telemetry, hooks และ filters เป็นคุณสมบัติชั้นนำ ทำให้คุณสามารถบันทึก ตรวจสอบ และสกัดกั้นสิ่งที่ AI ทำได้ ด้วยเหตุนี้ Microsoft และทีมงาน Fortune 500 หลายแห่งจึงนำไปใช้

แกนหลัก (kernel), ปลั๊กอิน (plugins) และฟังก์ชัน (functions)

ออบเจกต์หลักคือ kernel ลองนึกภาพว่าเป็นคอนเทนเนอร์สำหรับ dependency injection สำหรับ AI คุณลงทะเบียนตัวเชื่อมต่อโมเดลและปลั๊กอินของคุณบน kernel จากนั้นสั่งให้มันทำงาน kernel จะจัดการการประสานงาน: การแจ้งเตือน (prompt), การเรียกโมเดล (model call), การเรียกฟังก์ชัน (function call), ผลลัพธ์ (result) และการทำซ้ำ

ปลั๊กอินคือกลุ่มฟังก์ชันที่มีชื่อที่คุณเปิดเผยให้โมเดลเข้าถึงได้ ฟังก์ชันคือความสามารถเดียวที่โมเดลสามารถเรียกใช้ได้ ฟังก์ชันมีสองประเภท:

• ฟังก์ชันเนทีฟ (Native functions) คือเมธอดปกติในโค้ดของคุณ (เมธอด C#, ฟังก์ชัน Python) ที่คุณใส่คำอธิบายประกอบเพื่อให้ kernel สามารถอธิบายให้กับโมเดลได้
• ฟังก์ชันพรอมต์ (Prompt functions) คือพรอมต์แบบเทมเพลตที่เรียกโมเดลเอง ซึ่งมีประโยชน์สำหรับการสรุป จัดหมวดหมู่ หรือเขียนข้อความใหม่

นี่คือรูปแบบของมันใน C# คุณสร้าง kernel ลงทะเบียนโมเดลแชท เพิ่มปลั๊กอิน และให้โมเดลเรียกใช้ฟังก์ชันเมื่อต้องการ

var builder = Kernel.CreateBuilder();
builder.AddOpenAIChatCompletion("gpt-4o", apiKey);
builder.Plugins.AddFromType<LightsPlugin>("Lights");
Kernel kernel = builder.Build();

// The model can now invoke LightsPlugin functions during a chat
var result = await kernel.InvokePromptAsync("Turn the kitchen light blue");

เมื่อโมเดลส่งคืนและ kernel เห็นว่าต้องการเรียก change_light_state, kernel จะรันโค้ดของคุณ บันทึกผลลัพธ์ และส่งกลับไปยังโมเดล ลูปนี้คือหัวใจของ SK

รูปแบบ OpenAPI-to-plugin

นี่คือคุณสมบัติที่ควรทราบมากที่สุด และเป็นสะพานเชื่อมที่สะอาดที่สุดไปยังบริการที่มีอยู่ของคุณ SK สามารถนำเข้า OpenAPI specification และเปลี่ยนทุกการดำเนินการให้เป็นฟังก์ชันที่เรียกใช้ได้โดยอัตโนมัติ คุณไม่จำเป็นต้องเขียนโค้ด wrapper เพียงแค่ชี้ SK ไปยังสเปก และแต่ละ path/operation ก็จะกลายเป็นฟังก์ชันที่โมเดลสามารถเรียกใช้ได้

ใน C# การเรียกใช้คือ ImportPluginFromOpenApiAsync ใน Python คือ add_plugin_from_openapi Java ก็มี importer ที่เทียบเท่ากัน นี่คือเวอร์ชัน C# ที่โหลดสเปกจาก URL:

await kernel.ImportPluginFromOpenApiAsync(
    pluginName: "lights",
    uri: new Uri("https://example.com/v1/swagger.json"),
    executionParameters: new OpenApiFunctionExecutionParameters()
    {
        EnablePayloadNamespacing = true
    }
);

เบื้องหลังการทำงาน SK จะแยกวิเคราะห์สเปก ดึงชื่อ คำอธิบาย ประเภท และโครงสร้างสำหรับแต่ละพารามิเตอร์ และส่งเมตาเดตานั้นไปยังโมเดล โมเดลจะให้เหตุผลว่าควรเรียกการดำเนินการใดและควรส่งอาร์กิวเมนต์ใด จากนั้น SK จะสร้างคำขอ HTTP ใช้การเรียกกลับการตรวจสอบสิทธิ์ของคุณ ส่งคำขอ และอ่านการตอบกลับกลับมา SK รองรับ OpenAPI 2.0 และ 3.0 และจะดาวน์เกรดสเปก 3.1 เป็น 3.0 หากทำได้

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

เอเจนต์และการวางแผน

SK เริ่มต้นด้วย planner ที่ชัดเจนซึ่งแยกเป้าหมายออกเป็นขั้นตอนต่างๆ เฟรมเวิร์กได้เปลี่ยนไปสู่การเรียกใช้ฟังก์ชัน โดยที่ตัวโมเดลเองจะตัดสินใจว่าจะเรียกฟังก์ชันใดและตามลำดับใด ซึ่งมีความน่าเชื่อถือมากกว่าเมื่อใช้กับโมเดลสมัยใหม่ นอกจากนั้น SK ยังเพิ่มเลเยอร์ Agent Framework สำหรับการสร้างเอเจนต์และรูปแบบหลายเอเจนต์ ด้วยสถานะตามเซสชัน, ลูปเอเจนต์ และการสนับสนุน Model Context Protocol (MCP) สำหรับการเชื่อมต่อเครื่องมือภายนอก

หากคุณกำลังเปรียบเทียบแนวทางต่างๆ นี่คือวิธีการที่ SK เปรียบเทียบกับ SDK เอเจนต์อื่นๆ ที่กล่าวถึงในบล็อกนี้

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

Semantic Kernel เหมาะกับ Microsoft Agent Framework อย่างไร

ส่วนนี้มีการเปลี่ยนแปลงอย่างรวดเร็ว ดังนั้นนี่คือสถานะที่เป็นจริง Microsoft ได้เปิดตัว Microsoft Agent Framework (MAF) และเอกสารประกอบอธิบายว่าเป็นผู้สืบทอดโดยตรงของทั้ง Semantic Kernel และ AutoGen ซึ่งสร้างโดยทีมงานเดียวกัน MAF ผสมผสานแนวคิดเอเจนต์ของ AutoGen เข้ากับคุณสมบัติระดับองค์กรของ SK และเพิ่มเวิร์กโฟลว์แบบกราฟสำหรับการจัดการหลายเอเจนต์

ในทางปฏิบัติหมายความว่า:

• Semantic Kernel มีความเสถียรและยังคงได้รับการสนับสนุน แอปพลิเคชัน SK ที่มีอยู่ยังคงทำงานได้ และการรับประกันการเปลี่ยนแปลงที่เข้ากันได้กับเวอร์ชัน 1.0+ ยังคงอยู่
• สำหรับโปรเจกต์เอเจนต์ใหม่ล่าสุด Microsoft แนะนำให้ใช้ Agent Framework และเผยแพร่คู่มือการย้ายโค้ด SK
• แนวคิด OpenAPI-to-plugin ยังคงดำเนินต่อไป การให้เอเจนต์เข้าถึง REST API ของคุณผ่านสเปกเป็นรูปแบบที่ทั้งสองเฟรมเวิร์กมีร่วมกัน

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

เมื่อใดควรใช้ Semantic Kernel

เลือกใช้ SK เมื่อ:

• Stack ของคุณคือ .NET หรือ Java และคุณต้องการการจัดการ AI ที่ให้ความรู้สึกเป็นธรรมชาติ แทนที่จะเป็น Python sidecar
• คุณมี REST API ที่มีอยู่มากมาย และต้องการให้โมเดลเรียกใช้ API เหล่านั้นผ่าน OpenAPI specs ของพวกมัน
• คุณต้องการระบบพื้นฐานระดับองค์กร: telemetry, filters, hooks และความสามารถในการตรวจสอบสิ่งที่ AI ทำ
• คุณต้องการเป็นอิสระจากโมเดล (model-agnostic) และเปลี่ยนผู้ให้บริการได้โดยไม่ต้องเขียนแอปพลิเคชันใหม่

มองหาทางเลือกอื่นเมื่อทีมของคุณใช้ Python เท่านั้น และคุณต้องการคุณสมบัติ multi-agent ที่ใหม่ที่สุด ซึ่งในกรณีนั้น MAF หรือไลบรารีที่เน้นกราฟเป็นหลักอาจเหมาะกับคุณมากกว่า

การทดสอบ API ที่อยู่เบื้องหลังเอเจนต์ Semantic Kernel ของคุณ

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

งานที่ใช้งานได้จริงบางอย่าง:

• ออกแบบและทดสอบ OpenAPI spec ก่อนที่คุณจะนำเข้า เนื่องจาก SK เปลี่ยนแต่ละการดำเนินการให้เป็นฟังก์ชันและป้อนคำอธิบายพารามิเตอร์ของคุณไปยังโมเดล สเปกที่ไม่ละเอียดจะทำให้เกิดการเรียกใช้เครื่องมือที่ไม่ดี ตรวจสอบความถูกต้องของสเปก ทดสอบทุกเอนด์พอยต์ และยืนยันว่าการตอบสนองตรงกับโครงสร้างที่กำหนด สัญญาที่ชัดเจนนำไปสู่เอเจนต์ที่ดีขึ้น
• จำลองการพึ่งพาอาศัยกันในระหว่างการพัฒนา คุณสามารถสร้าง mock API สำหรับเอนด์พอยต์ที่ยังไม่ได้สร้าง หรือจำลองเอนด์พอยต์ LLM เพื่อหลีกเลี่ยงการใช้โทเค็นและปัญหาการจำกัดอัตราการเรียกใช้ในขณะที่คุณแก้ไขข้อผิดพลาดในลูปการจัดการ ดู วิธีจำลองการเรียกใช้ API สำหรับรูปแบบ
• ยืนยันรูปร่างการตอบสนอง ใช้ API assertions เพื่อตรวจสอบว่าเอนด์พอยต์ของเครื่องมือที่เอเจนต์ของคุณเรียกใช้นั้นส่งคืนโครงสร้างที่โมเดลคาดหวังอย่างถูกต้อง เพื่อไม่ให้การเปลี่ยนแปลงแบ็กเอนด์ทำให้พฤติกรรมของเอเจนต์เสียหายโดยไม่รู้ตัว
• จัดการคีย์แยกตามสภาพแวดล้อม แยกข้อมูลรับรอง LLM และ API ของคุณในสภาพแวดล้อม dev, staging และ prod แทนที่จะฮาร์ดโค้ด

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

คำถามที่พบบ่อย

Semantic Kernel เป็นโอเพนซอร์สและฟรีหรือไม่?

ใช่ Semantic Kernel เป็นโอเพนซอร์สและเผยแพร่โดย Microsoft บน GitHub ภายใต้ใบอนุญาตแบบอนุญาต (permissive license) พร้อม SDK สำหรับ C#/.NET, Python และ Java คุณจ่ายค่าการใช้งานโมเดล (OpenAI, Azure OpenAI และอื่นๆ) ไม่ใช่ตัว SK เอง

Semantic Kernel รองรับภาษาใดบ้าง?

C#/.NET, Python และ Java โดยทั้งหมดมีการรับประกันความเสถียรเวอร์ชัน 1.0+ SDK สำหรับ C# มีความสมบูรณ์ที่สุด แต่ SDK สำหรับ Python และ Java ก็ครอบคลุมคุณสมบัติหลักของ kernel, plugins และการนำเข้า OpenAPI

Semantic Kernel ใช้ OpenAPI specs อย่างไร?

คุณนำเข้าสเปกด้วย ImportPluginFromOpenApiAsync (C#) หรือ add_plugin_from_openapi (Python) SK จะแยกวิเคราะห์สเปก เปลี่ยนแต่ละการดำเนินการให้เป็นฟังก์ชันที่เรียกใช้ได้พร้อมเมตาเดตาของพารามิเตอร์ และให้โมเดลเรียกใช้การดำเนินการเหล่านั้น เนื่องจากโมเดลอาศัยคำอธิบายของคุณ จึงควรตรวจสอบความถูกต้องของสเปกก่อน คุณสามารถทำเช่นนั้นและทดสอบเอนด์พอยต์จริงได้ด้วย Apidog

ฉันควรใช้ Semantic Kernel หรือ Microsoft Agent Framework ดี?

หากคุณมีแอปพลิเคชัน SK อยู่แล้ว ให้ใช้ต่อไป เพราะยังคงได้รับการสนับสนุนและมีความเสถียร สำหรับโปรเจกต์ใหม่ Microsoft กำหนดให้ Agent Framework เป็นผู้สืบทอด และมีคู่มือการย้ายข้อมูลให้ ตรวจสอบเอกสาร MAF ล่าสุดก่อนที่จะเริ่มต้นใหม่ เนื่องจากพื้นที่นี้มีการเปลี่ยนแปลงอย่างรวดเร็ว หากต้องการทดสอบ API ที่ทั้งสองเรียกใช้ ดู วิธีทดสอบ ChatGPT API ด้วย Apidog

สรุป

Semantic Kernel มอบวิธีการที่สะอาดตาให้กับทีมที่ใช้ Microsoft stack ในการจัดการ AI: kernel ที่เชื่อมต่อโมเดลเข้ากับโค้ดของคุณ, plugins และ functions ที่โมเดลสามารถเรียกใช้ได้ และเส้นทางการนำเข้า OpenAPI ที่เปิดเผย REST API ที่มีอยู่ของคุณในฐานะเครื่องมือของเอเจนต์ มีความเสถียรและได้รับการพิสูจน์แล้วในการใช้งานจริง โดย Agent Framework กำลังขับเคลื่อนทิศทางใหม่ล่าสุดไปข้างหน้า ไม่ว่าคุณจะเลือกอันไหน API ที่อยู่เบื้องหลังก็ยังคงต้องแข็งแกร่ง หากต้องการออกแบบ จำลอง และทดสอบสเปกและเอนด์พอยต์ที่เอเจนต์ของคุณพึ่งพา ดาวน์โหลด Apidog และสร้างสัญญา (contract) ก่อนที่เอเจนต์จะเรียกใช้มัน