AI Assistant Platform คืออะไร?
ลองนึกภาพ ChatGPT แต่เราเป็นคนควบคุมทั้งหมด — เลือก AI model ได้, เก็บข้อมูลบน server ตัวเอง, แถมตั้งให้มันทำงานอัตโนมัติได้ด้วย
AI Assistant Platform คือระบบที่รับข้อความจาก user (ผ่าน Telegram, Discord หรือช่องทางอื่น) → ส่งไปให้ AI model ประมวลผล → ส่งคำตอบกลับ ฟังดูง่าย แต่พอจะทำให้ใช้งานได้จริงใน production มีรายละเอียดเยอะกว่าที่คิด
ทำไมต้อง Self-host?
- เลือก AI model ได้ — ไม่ติดกับ model ของแพลตฟอร์มใดแพลตฟอร์มหนึ่ง
- Privacy — ข้อมูลการสนทนาอยู่บน server เรา ไม่ถูกส่งไปบริษัทอื่น
- Customization — เพิ่ม cron jobs, เชื่อม search engine, ปรับ prompt ได้ตามใจ
- ไม่มี rate limit ของแพลตฟอร์ม — ถูกจำกัดแค่ rate limit ของ AI API ที่เลือกใช้
Multi-Model Architecture
AI Model คืออะไร? — คือ “สมอง” ของ AI แต่ละตัว ถูก train มาต่างกัน จุดแข็งจึงต่างกัน เหมือนถามคำถามเดียวกันกับคนละคน ได้คำตอบที่มุมมองต่างกัน
หลักการคือออกแบบระบบให้ เปลี่ยน model ได้โดยไม่ต้อง restart — ทำ abstraction layer ที่รับ input เหมือนกัน แต่ส่งไปหา model ต่างกันได้:
User message
│
▼
┌──────────────┐
│ Model Router │ ← เลือก model ตาม config (เปลี่ยนได้ runtime)
└──────┬───────┘
│
┌────┼────────────┬──────────────┐
▼ ▼ ▼ ▼
Gemini Grok Qwen Typhoon
(เร็ว) (คิดลึก) (code/จีน) (ไทย)
| Model | จุดเด่น | เหมาะกับ |
|---|---|---|
| Gemini Flash (Google) | เร็ว, ราคาถูก | สนทนาทั่วไป (model หลัก) |
| Grok (xAI) | reasoning เก่ง | งานวิเคราะห์, เปรียบเทียบ |
| Qwen (Alibaba) | เก่งภาษาจีน + coding | แปลภาษา, ช่วยเขียนโค้ด |
| Typhoon (SCB 10X) | เข้าใจภาษาไทยดี | งานที่ต้องเขียนไทยถูกต้อง |
ข้อดีของ multi-model คือเหมือนมีผู้เชี่ยวชาญหลายคน — เรื่องทั่วไปถาม Gemini (เร็วและถูก), เรื่องซับซ้อนถาม Grok (ละเอียดกว่า)
Cron Jobs — ระบบอัตโนมัติ
Cron Job คืออะไร? — คือการตั้งเวลาให้โปรแกรมทำงานซ้ำๆ อัตโนมัติ เหมือนตั้งนาฬิกาปลุก แต่แทนที่จะปลุกเรา มันจะ “ปลุก” โปรแกรมให้ทำงาน เช่น “ทุกเช้า 8 โมง ให้ดึงข่าวมาสรุป”
Cron jobs ทำให้ bot มีชีวิตมากขึ้น — ไม่ใช่แค่ตอบคำถามเวลาเราถาม แต่ส่งข้อมูลมาหาเราเองด้วย:
| Job | เวลา | ทำอะไร |
|---|---|---|
| Free Games Alert | ทุกเช้า | เช็คเกมฟรีจาก Epic Games, Steam |
| PM2.5 Air Quality | 07:00, 19:00 | ดึงข้อมูลฝุ่น → AI สรุปสถานการณ์พร้อมคำแนะนำ |
| AI News | 08:00 | ค้นหาข่าว AI ล่าสุด → AI สรุปเป็น 5 ข่าวสำคัญ |
แต่ละ job ใช้ AI สรุปข้อมูลให้อ่านง่าย เช่น PM2.5 job จะดึงตัวเลขจาก API → ส่งให้ AI แปลเป็นภาษาคน “วันนี้ฝุ่นเริ่มมีผลต่อสุขภาพ ควรใส่แมสก์ถ้าออกข้างนอก”
Design Pattern ของ Cron Job ที่ดี
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ Trigger │────▶│ Fetch │────▶│ AI │────▶│ Deliver │
│ (schedule)│ │ (API) │ │(summarize│ │ (chat) │
└──────────┘ └──────────┘ └──────────┘ └──────────┘
│ │
┌────▼────┐ ┌────▼────┐
│ Error │ │ Only │
│ Handler │ │ admin │
│(retry, │ │ gets │
│ alert) │ │ errors │
└─────────┘ └─────────┘
สิ่งที่ต้องคิดเผื่อ:
- Error handling — API ที่ดึงข้อมูลอาจล่มได้ ต้อง retry หรือ fallback
- แยก error channel — ถ้า API ล่ม ส่งแจ้งเตือนแค่ admin ไม่ใช่ส่ง error ใส่ group chat ตอนตี 3
Sidecar Pattern บน Kubernetes
Container คืออะไร? — กล่องที่บรรจุโปรแกรมพร้อมทุกอย่างที่มันต้องการ (code, libraries, config) ไว้ด้วยกัน ทำให้ย้ายไปรันที่ไหนก็ได้
Pod คืออะไร? — ใน Kubernetes, Pod คือกลุ่มของ containers ที่ทำงานด้วยกัน แชร์ network และ storage เหมือนคนหลายคนนั่งอยู่ในห้องเดียวกัน
AI assistant ใช้ sidecar pattern — ใส่ 2 containers ไว้ใน Pod เดียวกัน:
┌──────────────────────────────────────┐
│ Pod: AI Assistant │
│ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ Admin UI │ │ Gateway │ │
│ │ (จัดการ bot │ │ (ตัว bot │ │
│ │ ดู logs, │ │ ที่คุยกับ │ │
│ │ ตั้ง cron) │ │ Telegram) │ │
│ └──────┬───────┘ └──────┬───────┘ │
│ │ │ │
│ └──── shared ─────┘ │
│ storage │
│ (config, logs) │
└──────────────────────────────────────┘
- Admin UI — เว็บสำหรับจัดการ: ดู logs, เปลี่ยน AI model, ตั้งค่า cron jobs
- Gateway — ตัว bot จริงๆ ที่รับข้อความ → ส่งไป AI → ตอบกลับ
- Shared storage — ทั้งสอง containers แชร์พื้นที่เก็บ config เดียวกัน
ทำไมต้องแยกเป็น 2 containers แทนที่จะรวมเป็นอันเดียว?
- แยก concern — Admin UI กับ bot runtime มี dependencies ต่างกัน
- restart แยกกัน — ถ้า bot crash, Admin UI ยังเข้าได้เพื่อดู logs
- scale แยกกัน — ถ้าอนาคตต้องการหลาย bot instances แต่ Admin UI แค่ตัวเดียว
OAuth2 Proxy — กันคนอื่นเข้า Admin
Admin UI ต้องมี authentication ป้องกันไม่ให้คนอื่นเข้ามาแก้ config วิธีที่นิยมใน Kubernetes คือใช้ OAuth2 Proxy เป็นตัวกลาง:
User → OAuth2 Proxy → ตรวจสอบกับ Identity Provider → ถ้าผ่าน → Admin UI
ถ้าไม่ผ่าน → redirect ไปหน้า login
ข้อดีคือ app ไม่ต้องเขียน login logic เอง — OAuth2 Proxy จัดการให้หมด
Memory Management — ทำไม Bot กิน RAM เยอะ?
Gateway container ต้องเก็บ conversation history (ประวัติการสนทนา) ไว้ใน memory เพื่อให้ AI เข้าใจบริบท ถ้าคุยยาวๆ memory จะเพิ่มขึ้นเรื่อยๆ
OOMKilled คืออะไร? — ย่อมาจาก Out Of Memory Killed คือ Kubernetes จะ “ฆ่า” container ที่ใช้ memory เกินที่กำหนดไว้ เหมือนโปรแกรมถูกบังคับปิด
วิธีจัดการ:
- ตั้ง memory limit ให้สูงพอ — ให้ Kubernetes รู้ว่า container นี้ต้องการ memory เท่าไหร่
- บอก runtime ว่ามี memory เท่าไหร่ — เช่น Node.js ใช้
--max-old-space-sizeเพื่อจัดการ garbage collection - ตัด history เก่า — เก็บแค่ N ข้อความล่าสุด ไม่ให้สะสมจนล้น
เชื่อม Search Engine — ให้ AI รู้ข้อมูลล่าสุด
ปกติ AI ตอบได้แค่สิ่งที่มันเรียนรู้มาตอน train ถ้าถามเรื่องข่าวล่าสุด มันจะไม่รู้ แก้ได้ด้วยการเชื่อม self-hosted search engine:
1. User ถาม: "ข่าว AI วันนี้มีอะไรบ้าง?"
│
2. Bot ส่งไป Search Engine (self-hosted)
│
3. Search Engine ค้นหาจาก internet
│
4. ได้ผลลัพธ์ → AI สรุปให้อ่านง่าย
│
5. Bot ตอบกลับพร้อม sources (แหล่งที่มา)
เทคนิคนี้เรียกว่า RAG (Retrieval-Augmented Generation) — “เสริม” ความรู้ให้ AI ด้วยข้อมูลที่ค้นมาใหม่ ทำให้ AI ตอบเรื่อง real-time ได้โดยไม่ต้อง retrain model
ข้อดีของการ self-host search engine: ไม่มีค่า API ต่อ query, ไม่มี rate limit, privacy ดีกว่าเพราะ query อยู่ใน server เรา
บทเรียนที่สำคัญ
Token & Credential Expiry
Bot ที่เชื่อมกับ platform (Telegram, Discord) ต้องมี token (รหัสยืนยันตัวตน) ซึ่งมีวันหมดอายุ ถ้าลืม renew bot จะหยุดทำงานทันที
แนวทาง: ตั้ง alert แจ้งเตือนก่อน token หมดอายุ หรือทำระบบ auto-renew
Memory Leak ใน Long-running Process
Memory leak คือปัญหาที่โปรแกรมใช้ memory เพิ่มขึ้นเรื่อยๆ โดยไม่ปล่อยคืน เหมือนเปิดแท็บ Chrome เพิ่มเรื่อยๆ ไม่เคยปิด ใน chatbot สาเหตุหลักคือ conversation history ที่สะสมไว้ใน memory
แนวทาง: ตั้ง limit เช่น เก็บแค่ 50 ข้อความล่าสุด หรือเก็บแค่ 30 นาทีล่าสุด และ monitor memory usage ตลอด
Self-hosting = ต้อง Monitor
พอ host ทุกอย่างเอง ก็ดูแลเอง ต้องมีระบบ monitoring:
- Metrics (ตัวเลข) — CPU, memory, request count → ใช้ Prometheus หรือ Victoria Metrics
- Logs (ข้อความ) — error messages, audit trail → ใช้ Loki หรือ ELK stack
- Dashboard — ดูทุกอย่างในที่เดียว → ใช้ Grafana
ทำให้รู้เวลามีปัญหาก่อนที่ user จะมาบอก เช่น เห็นว่า memory ค่อยๆ เพิ่มขึ้น ก็แก้ได้ก่อนที่ bot จะ crash
ถ้าสนใจสร้าง AI assistant เอง ลองเริ่มจาก Telegram bot ง่ายๆ เชื่อมกับ AI API สัก 1 ตัว แล้วค่อยๆ เพิ่มความสามารถ — multi-model, cron jobs, search engine — ไปทีละขั้น