Section 1: ทำไมองค์กรต้องมี GenAI Gateway
- ปัญหาที่พบเมื่อใช้ AI แบบต่างคนต่างใช้: Shadow AI, Key กระจัดกระจาย และค่าใช้จ่ายที่มองไม่เห็น
- บทบาทของ Gateway: จุดเดียวสำหรับสิทธิ์ ค่าใช้จ่าย นโยบาย และ Log
- สถาปัตยกรรมอ้างอิงของแพลตฟอร์ม AI ภายในองค์กรตั้งแต่ผู้ใช้จนถึงโมเดล
- ภาพรวมเครื่องมือโอเพนซอร์สและบริการ Gateway บน Cloud เพื่อใช้ประกอบการตัดสินใจ
- Workshop: สำรวจการใช้ AI ปัจจุบันขององค์กรตัวเองและจุดเสี่ยง
Section 2: Workshop: จัดชั้นข้อมูลและนโยบายเลือกโมเดล
- จัดชั้นข้อมูล เช่น สาธารณะ ภายใน ลับ และข้อมูลส่วนบุคคล
- จับคู่ชั้นข้อมูลกับโมเดลที่อนุญาต: Cloud API แบบ Enterprise หรือโมเดลภายใน
- อ่านเงื่อนไขการใช้ข้อมูลของผู้ให้บริการ AI เรื่องการเก็บและการนำข้อมูลไปฝึก
- ข้อพิจารณาตาม PDPA เมื่อส่งข้อมูลส่วนบุคคลไปประมวลผล
- Workshop: ร่างตารางนโยบายว่าข้อมูลแบบใดใช้กับโมเดลใดได้
Section 3: Lab: ติดตั้ง LiteLLM, Routing และ Fallback
- ติดตั้ง LiteLLM พร้อม PostgreSQL และ Redis ด้วย Docker Compose
- กำหนด Model List ใน config.yaml รวม Cloud API และโมเดลภายในผ่าน Ollama ภายใต้ชื่อกลางขององค์กร
- เรียกทุกโมเดลผ่าน OpenAI-compatible Endpoint เดียว และเก็บ API Key ของผู้ให้บริการเป็น Secret
- Load Balancing, Fallback, Retry และ Timeout เมื่อผู้ให้บริการล่มหรือเกินโควตา
- Routing ตามชั้นข้อมูล และ Caching ด้วย Redis เพื่อลดค่าใช้จ่าย
- Lab: ปิดผู้ให้บริการหนึ่งรายแล้วทดสอบว่าระบบสลับไปใช้ตัวสำรอง
Section 4: Lab: Virtual Key, ทีม และงบประมาณ
- ออก Virtual Key ให้ผู้ใช้ ทีม และแอป แทนการแจก Key จริงของผู้ให้บริการ
- จำกัดโมเดลที่แต่ละทีมเรียกได้ตามนโยบายข้อมูล
- ตั้งงบประมาณ Rate Limit และวันหมดอายุของ Key
- บทบาทผู้ดูแลใน LiteLLM และฟีเจอร์ที่ต้องใช้ License แบบ Enterprise
- Lab: จำลองทีมที่ใช้เกินงบแล้วดูว่าระบบตอบสนองอย่างไร
Section 5: Lab: หน้าแชตองค์กรด้วย Open WebUI
- ติดตั้ง Open WebUI และเชื่อมกับ LiteLLM แทนการต่อผู้ให้บริการโดยตรง
- เชื่อม SSO ผ่าน OIDC และภาพรวมการเชื่อม LDAP หรือ Active Directory
- จัดกลุ่มผู้ใช้และสิทธิ์การเข้าถึงโมเดล ฟีเจอร์ และ Knowledge ตามแผนก
- ตั้งโมเดลสำเร็จรูปพร้อม System Prompt สำหรับงานของแต่ละทีม
- เงื่อนไข License และ Branding ของ Open WebUI ที่ต้องรู้ก่อนใช้ในองค์กร