คุมค่า AI API ไม่ให้บิลบาน: 5 ชั้นป้องกันที่ใช้จริงในระบบแชทบอท

ค่า AI API คิดตามการใช้งาน (จำนวน token) ข้อดีคือใช้น้อยก็จ่ายน้อย ข้อเสียคือไม่มีเพดานให้เอง ถ้ามีคนยิงเครื่องมือสาธารณะของเรารัวๆ หรือโค้ดวนลูปผิด บิลจะวิ่งไปเรื่อยๆ จนกว่าจะมีคนเห็น

บทความนี้รวมวิธีที่ผมใช้คุมค่าใช้จ่ายในระบบแชทบอทและเครื่องมือฟรีบนเว็บ เรียงจากชั้นที่ป้องกันความเสียหายหนักที่สุดก่อน

ชั้นที่ 1: ตั้งเพดานใช้จ่ายรายเดือนที่บัญชี

ผู้ให้บริการหลักอย่าง Anthropic (Claude) และ OpenAI ให้ตั้งเพดานการใช้จ่ายของบัญชีได้ ตั้งไว้ก่อนเปิดระบบให้คนนอกใช้เสมอ เลือกตัวเลขที่ "ถ้าหมดทั้งก้อนเดือนนี้ก็ยังรับได้"

ชั้นนี้คือตาข่ายสุดท้าย ถ้าทุกชั้นข้างล่างพลาด ความเสียหายจะหยุดที่ตัวเลขนี้

ชั้นที่ 2: Rate limit ต่อผู้ใช้ / ต่อ IP

endpoint สาธารณะที่เรียก AI (เช่น ปุ่ม "วิเคราะห์ด้วย AI" ที่ไม่ต้องล็อกอิน) คือรูรั่วที่ใหญ่ที่สุด เพราะทุกครั้งที่มีคนกด เราเป็นคนจ่าย ให้จำกัดจำนวนครั้งต่อ IP ต่อวัน เช่น 5 ครั้ง

from collections import defaultdict
from datetime import date
_hits = defaultdict(int)   # (ip, วันที่) -> จำนวนครั้ง

def allow(ip: str, limit: int = 5) -> bool:
    key = (ip, date.today().isoformat())
    if _hits[key] >= limit:
        return False
    _hits[key] += 1
    return True

ตัวนับในแรมแบบนี้รีเซ็ตเมื่อเซิร์ฟเวอร์รีสตาร์ต ซึ่งยอมรับได้สำหรับ rate limit คร่าวๆ (ถ้าต้องแม่นยำ ให้เก็บใน Redis หรือฐานข้อมูล) สำหรับแชทบอท ให้จำกัดต่อผู้ใช้แทน IP เช่น ไม่เกิน 40 ข้อความต่อชั่วโมงต่อคน กันคนเล่นสแปม

หลังบ้าน (เช่น Render) มักส่ง IP จริงมาใน header X-Forwarded-For ถ้าอ่านจาก remote_addr ตรงๆ อาจได้ IP ของ load balancer และทุกคนจะใช้โควตาร่วมกัน

ชั้นที่ 3: ไม่ต้องใช้ AI ก็อย่าใช้

คำถามจำนวนมากในแชทของร้านค้าตอบด้วยข้อมูลตายตัวได้ เช่น "ร้านอยู่ไหน", "เปิดกี่โมง", "มีโปรไหม" ให้ดักคำถามพวกนี้ด้วยการจับคำสำคัญ แล้วตอบจาก template ที่ดึงข้อมูลจาก config ของร้าน

• ค่าใช้จ่าย AI เป็นศูนย์สำหรับคำถามกลุ่มนี้
• คำตอบถูกต้องเสมอ (AI ไม่มีโอกาสแต่งราคาขึ้นมาเอง)
• ใช้เป็นคำตอบสำรองได้ตอนผู้ให้บริการ AI ล่ม

เดโมบนเว็บที่ให้คนทั่วไปลองเล่น ถ้าเป็นบทสนทนาแบบกำหนดทางไว้ ทำแบบไม่เรียก AI เลยก็ได้ ผู้ใช้ส่วนใหญ่แยกไม่ออก และต้นทุนเป็นศูนย์ไม่ว่าจะมีคนเข้ามากแค่ไหน

ชั้นที่ 4: ใช้โมเดลเล็กคัดก่อน แล้วค่อยส่งให้โมเดลใหญ่

งานแบบ "อ่านข้อมูล 50 รายการ แล้วเลือกตัวที่น่าสนใจมาวิเคราะห์ละเอียด" ไม่จำเป็นต้องใช้โมเดลแพงกับทุกรายการ ให้โมเดลเล็กราคาถูก (เช่นตระกูล Haiku ของ Claude หรือรุ่น mini ของ OpenAI) ตอบแค่ ผ่าน/ไม่ผ่าน แล้วส่งเฉพาะรายการที่ผ่านให้โมเดลใหญ่

ข้อควรระวัง: ถ้าโมเดลเล็กพังหรือตอบรูปแบบผิด ให้ fail-open คือปล่อยรายการนั้นไปให้โมเดลใหญ่ตัดสินแทน ไม่ใช่ทิ้งไปเงียบๆ เพราะการทิ้งรายการดีไปเพราะตัวคัดพัง แย่กว่าจ่ายแพงขึ้นเล็กน้อย

ชั้นที่ 5: จำกัดขนาด input และ output

• ตัดข้อความที่ผู้ใช้ส่งมาให้ยาวไม่เกินที่จำเป็น (เช่น 2,000 ตัวอักษร)
• ตั้ง max_tokens ของคำตอบให้พอดีกับงาน แชทตอบลูกค้าไม่ต้องยาวเป็นหน้า
• ประวัติแชทที่ส่งให้ AI ทุกรอบ เก็บแค่ไม่กี่ข้อความล่าสุด ไม่ต้องส่งทั้งบทสนทนา
• system prompt ยาวๆ ที่ส่งซ้ำทุกครั้ง ใช้ฟีเจอร์ prompt caching ของผู้ให้บริการช่วยลดค่าใช้จ่ายได้

อย่าลืม: เฝ้าดูให้เห็น

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

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

อ่านต่อ: เมื่อ AI ใช้ไม่ได้แล้วไม่มีใครรู้