ต้นทุน AI ต่อสาขา คำนวณและควบคุมยังไง ให้ไม่ต้องเดารวมทั้งบริษัท

เจ้าของธุรกิจหลายสาขาที่เริ่มใช้ AI Automation หรือแชทบอทมักเจอปัญหาเดียวกัน — บิลรวมจากผู้ให้บริการ AI มาเป็นก้อนเดียวทั้งบริษัท

แต่ไม่มีใครบอกได้ว่าสาขาไหนใช้เยอะ สาขาไหนคุ้ม สาขาไหนกำลังเผาเงินเปล่า

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

บทความนี้อธิบายวิธีคิด โครงสร้างข้อมูลที่ต้องมี วิธีสร้าง cost dashboard ที่ใช้ตัดสินใจได้จริง พร้อมเช็กลิสต์ปฏิบัติจริงและตัวอย่างการคำนวณแบบสมมติ — ไม่ใช่แค่กราฟสวยๆ

สารบัญ

ต้นทุน AI ต่อสาขา คืออะไร
ทำไมธุรกิจหลายสาขาถึงต้องมองต้นทุนแยกรายสาขา ไม่ใช่ดูรวม
โครงสร้างของ Cost Dashboard ที่ใช้งานได้จริง
เครื่องมือและแนวทางที่ใช้ติดตามต้นทุนระดับนี้ในทางเทคนิค
ข้อควรระวังในการอ่านตัวเลขต้นทุนต่อสาขา
เช็กลิสต์ปฏิบัติจริง: สิ่งที่ต้องเก็บข้อมูลให้เห็นต้นทุนต่อสาขาแม่นยำ
ตัวอย่างการคำนวณแบบสมมติ: ธุรกิจ 5 สาขา
บทความนี้อธิบายอะไร และไม่ได้อธิบายอะไร
คำถามที่พบบ่อย

ต้นทุน AI ต่อสาขา คืออะไร

ต้นทุน AI ต่อสาขา คือค่าใช้จ่ายด้าน AI ที่แจกแจงตามหน่วยธุรกิจ (สาขา/สาขาย่อย/ทรัพย์สิน) แทนที่จะรวมเป็นก้อนเดียวระดับบริษัท โดยทั่วไปประกอบด้วย 3 ส่วน:

ต้นทุน token ของโมเดลภาษา (LLM) ตามจำนวนที่ใช้จริงต่อบทสนทนา — token ขาเข้า (input, สิ่งที่ลูกค้าพิมพ์ + ประวัติแชท + context ที่แนบ) และ token ขาออก (output, คำตอบที่โมเดลสร้าง) ราคาไม่เท่ากันเสมอ โมเดลส่วนใหญ่คิด output แพงกว่า input 3-5 เท่า ดังนั้นบอทที่ตอบยาวๆ จะกินต้นทุนมากกว่าบอทที่ตอบสั้นกระชับ แม้จำนวนบทสนทนาเท่ากัน
ต้นทุน compute/infrastructure ที่รันระบบ เช่น เซิร์ฟเวอร์รัน workflow, vector database ที่เก็บฐานความรู้ (knowledge base) สำหรับค้นหาคำตอบ, หรือ GPU ถ้ามีการรันโมเดลเอง (self-hosted) แทนการเรียกผ่าน API — ส่วนนี้มักเป็นต้นทุนคงที่หรือกึ่งคงที่ ไม่ผันตรงตามปริมาณการใช้งานเหมือนต้นทุน token
ค่าบริการเสริม เช่น API เชื่อมต่อระบบภายนอก (เช็คสต็อก, จองคิว, ระบบ POS, ระบบ CRM) ที่ AI เรียกใช้งานแทนพนักงาน บางบริการคิดตามจำนวนครั้งที่เรียก (per-call) บางบริการคิดแบบ subscription รายเดือน — ต้องแยกให้ออกว่าแบบไหนผันตามปริมาณใช้งานจริงของแต่ละสาขา แบบไหนเป็นต้นทุนคงที่ที่ต้องจัดสรร (allocate) เอาเอง

จุดที่มักเข้าใจผิดคือคิดว่า "ต้นทุนต่อสาขา" แปลว่าต้องมีบิลแยกจากผู้ให้บริการ AI รายสาขา — ในทางปฏิบัติแทบไม่มีผู้ให้บริการรายไหนออกบิลแบบนั้น

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

ทำไมธุรกิจหลายสาขาถึงต้องมองต้นทุนแยกรายสาขา ไม่ใช่ดูรวม

เมื่อธุรกิจมีมากกว่า 1 สาขา ต้นทุน AI ไม่ได้กระจายเท่ากันตามธรรมชาติ สาขาที่ลูกค้าเยอะ ถามซับซ้อน หรือมีพนักงานพิมพ์คำถามยาวๆ ใส่บอท จะกิน token มากกว่าสาขาเล็กที่ใช้แค่ตอบคำถามพื้นฐาน

ปัจจัยที่ทำให้ต้นทุนต่างกันระหว่างสาขา มักมาจาก 4 อย่างนี้ ไม่ใช่แค่ "จำนวนลูกค้า" อย่างเดียว:

ความยาวของบทสนทนา — สาขาที่ลูกค้าถามวนหลายรอบกว่าจะได้คำตอบ (เช่น เพราะฐานความรู้ไม่ครอบคลุม หรือบอทตอบไม่ตรงคำถามรอบแรก) จะสะสม token ต่อ session สูงกว่าสาขาที่คำถามตรงไปตรงมา
ความซับซ้อนของ prompt/context — สาขาที่ต้องแนบข้อมูลบริบทเยอะ (เช่น ประวัติลูกค้า, สต็อกสินค้าเฉพาะสาขา) ในทุกคำขอ จะมี input token สูงกว่าสาขาที่ทำงานแบบง่าย ไม่ต้องแนบ context มาก
โมเดลที่เลือกใช้ต่างกัน — ถ้าบางสาขาถูกตั้งค่าให้ใช้โมเดลตัวใหญ่ (แม่นกว่าแต่แพงกว่า) สำหรับงานที่จริงๆ ใช้โมเดลเล็กก็พอ ต้นทุนจะพุ่งโดยไม่มีเหตุผลด้านคุณภาพรองรับ
อัตราการเกิดคำถามซ้ำ (repeat rate) — สาขาที่ลูกค้าถามคำถามเดิมๆ บ่อย (เวลาเปิด-ปิด, ที่จอดรถ, โปรโมชัน) แต่ระบบไม่มีกลไก cache คำตอบสำเร็จรูป จะยิงเข้าโมเดลทุกครั้งโดยไม่จำเป็น

ถ้าดูแต่ตัวเลขรวม เจ้าของธุรกิจจะพลาด 3 อย่าง:

มองไม่เห็นสาขาที่ใช้เกินคุ้ม — เช่น สาขาหนึ่งมีบอทตอบคำถามซ้ำๆ ที่ควรทำเป็นคำตอบสำเร็จรูป (cached) แต่กลับยิงเข้าโมเดลทุกครั้ง ทำให้ต้นทุนสูงเกินจำเป็นโดยไม่มีใครรู้ จนกว่าจะมีคนแยกดูเป็นรายสาขาแล้วเจอว่าสาขานั้นมีสัดส่วนต้นทุนต่อบทสนทนาสูงผิดปกติเมื่อเทียบสาขาอื่นที่ทำธุรกิจแบบเดียวกัน
ต่อรองงบประมาณผิดจุด — ถ้าไม่รู้ว่าต้นทุนจริงอยู่ที่สาขาไหน การตัดงบหรือเพิ่มงบ AI จะเป็นการเดา ไม่ใช่การตัดสินใจจากข้อมูล เช่น อาจตัดงบสาขาที่จริงๆ ใช้งานคุ้มค่าที่สุด เพียงเพราะมันมีตัวเลขต้นทุนรวมสูง (เพราะสาขาใหญ่) โดยไม่ได้ดูต้นทุนต่อหน่วย
ประเมิน ROI ต่อสาขาไม่ได้ — สาขาที่ AI ช่วยลดชั่วโมงงานพนักงานได้มาก อาจคุ้มค่าแม้ต้นทุนสูงกว่า ในขณะที่สาขาที่ต้นทุนต่ำแต่ไม่มีใครใช้บอทเลยก็ไม่ได้แปลว่าดี — ต้องเทียบทั้งต้นทุนและผลลัพธ์คู่กันเป็นรายสาขา ไม่ใช่ใช้ตัวเลขต้นทุนตัวเดียวตัดสิน

โครงสร้างของ Cost Dashboard ที่ใช้งานได้จริง

Cost dashboard ที่มีประโยชน์ไม่ใช่แค่กราฟค่าใช้จ่ายรวมรายเดือน แต่ต้องแตกละเอียดพอที่จะใช้ตัดสินใจได้ ต่อไปนี้คือส่วนประกอบหลักที่ควรมี

1. ต้นทุน token แยกตามโมเดลและสาขา

โมเดลภาษาแต่ละตัวราคาไม่เท่ากัน (เช่น โมเดลขนาดใหญ่ที่ตอบคำถามซับซ้อนจะแพงกว่าโมเดลขนาดเล็กที่ใช้จัดหมวดหมู่ข้อความ)

ระบบที่ดีควรบันทึกว่าแต่ละคำขอ (request) ใช้โมเดลไหน กี่ token ขาเข้า-ขาออก แล้ว map กลับไปที่สาขาต้นทาง เพื่อให้เห็นว่าสาขาไหนใช้โมเดลราคาแพงเกินความจำเป็นสำหรับงานง่ายๆ

ในทางปฏิบัติ ระบบ AI ที่ออกแบบดีมักไม่ได้ใช้โมเดลเดียวตลอดทั้ง flow — ขั้นตอนจัดหมวดหมู่คำถามเบื้องต้น (intent classification) ควรใช้โมเดลเล็กราคาถูก

ส่วนขั้นตอนตอบคำถามที่ต้องเหตุผลซับซ้อนค่อยส่งต่อให้โมเดลใหญ่

ถ้า dashboard แยกได้ถึงระดับ "ขั้นตอนไหนในระบบ" ไม่ใช่แค่ "สาขาไหน" จะเห็นจุดที่ปรับโมเดลให้ถูกลงได้โดยไม่กระทบคุณภาพ

2. ปริมาณการใช้งาน (volume) เทียบต้นทุนต่อหน่วย

ตัวเลขที่มีความหมายกว่า "ต้นทุนรวมต่อเดือน" คือ "ต้นทุนต่อบทสนทนา" หรือ "ต้นทุนต่อ transaction" ของแต่ละสาขา เพราะสาขาใหญ่ที่มีลูกค้าเยอะย่อมมีต้นทุนรวมสูงกว่าสาขาเล็กเป็นธรรมชาติอยู่แล้ว

ตัวเลขที่บอกว่าระบบมีประสิทธิภาพหรือไม่คือต้นทุนเฉลี่ยต่อการใช้งานหนึ่งครั้ง ไม่ใช่ยอดรวม

ควรดู 2 ระดับคู่กัน: ต้นทุนต่อ "session" (หนึ่งรอบการคุยของลูกค้าคนหนึ่ง อาจมีหลายข้อความ) และต้นทุนต่อ "resolution" (หนึ่งครั้งที่บอทแก้ปัญหาให้ลูกค้าสำเร็จโดยไม่ต้องโอนให้พนักงาน) เพราะ

สาขาที่ต้นทุนต่อ session สูงแต่ resolution rate ก็สูงตาม อาจคุ้มกว่าสาขาที่ต้นทุนต่อ session ต่ำแต่ต้องโอนให้พนักงานทุกครั้งอยู่ดี

3. Infrastructure/compute cost ที่แชร์ระหว่างสาขา

ถ้าระบบมีส่วนที่รันกลาง (เช่น vector database ที่เก็บฐานความรู้ร่วมของทุกสาขา หรือเซิร์ฟเวอร์ที่รันโมเดลเอง) ต้นทุนส่วนนี้ต้องมีสูตรจัดสรร (allocation) ที่ชัดเจน

เช่น หารตามสัดส่วนปริมาณ request ของแต่ละสาขา ไม่ใช่หารเท่ากันทุกสาขาแบบเหมารวม เพราะสาขาที่ใช้งานน้อยจะถูกจัดสรรต้นทุนเกินจริง

วิธีจัดสรรที่ใช้กันในทางปฏิบัติมีอย่างน้อย 3 แบบ และให้ผลต่างกัน:

ตามสัดส่วนจำนวน request — เข้าใจง่ายที่สุด แต่ไม่ยุติธรรมถ้าบาง request ใช้ compute หนักกว่ากันมาก (เช่น query ที่ต้องค้นฐานความรู้ขนาดใหญ่)
ตามสัดส่วน token ที่ประมวลผล — ละเอียดกว่า สะท้อนภาระงานจริงมากกว่าการนับจำนวนครั้ง
ตามสัดส่วนรายได้หรือจำนวนธุรกรรมของสาขา — เหมาะกับกรณีที่ต้องการจัดสรรต้นทุนแบบ "ตามความสามารถในการจ่าย" มากกว่า "ตามการใช้งานจริง" ซึ่งบางองค์กรเลือกใช้เพื่อความง่ายในการรายงานบัญชี แม้จะไม่สะท้อนต้นทุนจริงเป๊ะๆ ก็ตาม

ไม่มีสูตรไหนถูกผิดสัมบูรณ์ — สิ่งสำคัญคือเลือกสูตรเดียวแล้วใช้สม่ำเสมอ เพื่อให้เทียบข้ามเดือนและข้ามสาขาได้อย่างสอดคล้องกัน

4. เพดานงบประมาณ (budget) และการแจ้งเตือนล่วงหน้า

Dashboard ที่ดีไม่ใช่แค่รายงานย้อนหลัง แต่ควรตั้งเพดานต้นทุนต่อสาขาต่อเดือน แล้วแจ้งเตือนเมื่อสาขาไหนใกล้ชนเพดาน ก่อนที่ใบแจ้งหนี้จะมาเซอร์ไพรส์ปลายเดือน

ในทางปฏิบัติควรตั้งระดับแจ้งเตือนอย่างน้อย 2 ขั้น เช่น เตือนเมื่อถึง 70% ของเพดาน (ให้เวลาตรวจสอบก่อนเกิดปัญหาจริง) และเตือนซ้ำเมื่อถึง 90% หรือเกินเพดาน (ต้องตัดสินใจทันที)

พร้อมทั้งกำหนดว่าใครเป็นคนรับการแจ้งเตือนนั้น — ถ้าไม่มีเจ้าของตัวเลขชัดเจน การแจ้งเตือนจะถูกมองข้ามเหมือนอีเมลระบบทั่วไป

แนวทางนี้ตรงกับสิ่งที่วงการเรียกว่า FinOps (แนวปฏิบัติบริหารต้นทุนคลาวด์แบบมีวินัย) ที่ตอนนี้ขยายมาครอบคลุมต้นทุน AI/LLM โดยเฉพาะ ผ่านกลุ่มทำงาน FinOps for AI ของ FinOps Foundation (finops.org)

5. เชื่อมต้นทุนกับผลลัพธ์ทางธุรกิจ

ตัวเลขต้นทุนอย่างเดียวยังไม่บอกว่าคุ้มหรือไม่คุ้ม ต้องวางคู่กับตัวชี้วัดผลลัพธ์

เช่น จำนวนคำถามที่ AI ตอบได้เองโดยไม่ต้องส่งต่อพนักงาน (%Bot Handled), เวลาตอบกลับเฉลี่ย (First Response Time), จำนวนครั้งที่ต้องโอนพนักงาน (escalation) ต่อวัน หรือชั่วโมงงานที่ประหยัดได้ — เพื่อคำนวณ ROI ต่อสาขาแทนที่จะดูต้นทุนลอยๆ

ตัวชี้วัดเหล่านี้ควรอยู่บน dashboard เดียวกับต้นทุน ไม่ใช่คนละรายงาน เพราะการต้องเปิดสองไฟล์แล้วเทียบเองด้วยมือ ทำให้ในทางปฏิบัติแทบไม่มีใครทำเป็นประจำ

เครื่องมือและแนวทางที่ใช้ติดตามต้นทุนระดับนี้ในทางเทคนิค

ในทางวิศวกรรม การแตกต้นทุนระดับนี้ทำได้จริงด้วยเครื่องมือ observability และ gateway สำหรับ LLM ที่มีอยู่แล้วในตลาด เช่น LiteLLM ซึ่งเป็น proxy ที่บันทึกต้นทุนแยกตาม API key/ทีม/โปรเจกต์ได้ในตัว (LiteLLM cost tracking docs)

และ Langfuse ซึ่งเป็นเครื่องมือ observability ที่คำนวณต้นทุนต่อ trace (หนึ่งบทสนทนาหรือหนึ่งการเรียกใช้โมเดล) โดยอัตโนมัติจาก token usage (Langfuse model usage & cost docs)

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

จุดที่ต้องออกแบบเองเสมอ ไม่ว่าจะใช้เครื่องมือไหน คือ metadata schema — ตกลงให้ชัดตั้งแต่ต้นว่าทุกคำขอที่ยิงเข้าโมเดลต้องแนบ field อะไรบ้าง เช่น branch_id, channel (LINE/Facebook/เว็บ), flow_step (ขั้นตอนไหนของ workflow), และ session_id

ถ้า field พวกนี้ไม่ได้ถูกแนบมาตั้งแต่ต้น ต่อให้เครื่องมือ observability ดีแค่ไหนก็จะแตกข้อมูลย้อนหลังไม่ได้ เพราะไม่มีอะไรให้ group ตาม

นี่คือเหตุผลที่การวางระบบ tagging ต้องทำตั้งแต่ตอนออกแบบ workflow ไม่ใช่ค่อยแปะทีหลังตอนอยากดูรายงาน

ข้อควรระวังในการอ่านตัวเลขต้นทุนต่อสาขา

อย่าเทียบสาขาที่มีขนาดต่างกันด้วยตัวเลขรวม — ใช้ต้นทุนต่อ transaction เทียบกันแทน
แยกต้นทุน "ใช้งานปกติ" กับ "ใช้งานผิดปกติ" — เช่น มีการทดสอบระบบหรือมี bug ที่ยิง request ซ้ำๆ จะทำให้ตัวเลขเดือนนั้นเพี้ยน ต้องมีการตรวจสอบก่อนสรุปเป็นแนวโน้ม
ต้นทุนต่ำไม่ได้แปลว่าดีเสมอไป — ถ้าสาขาไหนต้นทุนต่ำเพราะพนักงานไม่ใช้บอทเลย นั่นคือปัญหาการนำไปใช้งาน (adoption) ไม่ใช่ความสำเร็จด้านต้นทุน
ระวัง seasonality ปลอมที่ดูเหมือนแนวโน้มจริง — สาขาที่อยู่ใกล้แหล่งท่องเที่ยวหรือขายสินค้าตามเทศกาลจะมีปริมาณคำถามพุ่งเป็นช่วงๆ ตามธรรมชาติ ถ้าเทียบเดือนต่อเดือนตรงๆ โดยไม่ปรับฐานตามฤดูกาล อาจตีความผิดว่าต้นทุนกำลังหลุดควบคุมทั้งที่จริงคือปริมาณลูกค้าสูงขึ้นตามช่วงเวลาปกติ
ตัวเลขเดือนแรกที่เปิดใช้งานสาขาใหม่มักไม่สะท้อนต้นทุนคงที่ระยะยาว — ช่วงแรกมักมีการทดสอบระบบ ปรับ prompt บ่อย และพนักงานยังลองผิดลองถูก ทำให้ต้นทุนต่อ transaction สูงกว่าปกติ ควรรอให้ผ่านช่วง ramp-up อย่างน้อย 1-2 เดือนก่อนใช้ตัวเลขเป็นฐานเทียบสาขาอื่น

เช็กลิสต์ปฏิบัติจริง: สิ่งที่ต้องเก็บข้อมูลให้เห็นต้นทุนต่อสาขาแม่นยำ

ก่อนจะสร้าง dashboard ได้เลย ธุรกิจต้องมีข้อมูลดิบที่ถูกเก็บถูกวิธีตั้งแต่ต้นทาง ต่อไปนี้คือสิ่งที่ควรตรวจสอบว่ามีอยู่จริงในระบบหรือยัง:

ทุกคำขอมี branch_id ติดมาตั้งแต่ต้นทาง ไม่ใช่เดาย้อนหลัง — ถ้าระบบระบุสาขาจากเบอร์โทรหรือ LINE OA ที่ลูกค้าทักเข้ามา ต้องแน่ใจว่า mapping ระหว่างช่องทางกับสาขานั้นถูกต้อง 100% โดยเฉพาะสาขาที่ใช้ LINE OA ร่วมกันหลายสาขาหรือมีการโอนแชทข้ามสาขา
แยก token input/output ต่อคำขอ ไม่ใช่ดูรวมเป็นก้อนต่อวัน — เพราะสัดส่วน input/output ต่างกันในแต่ละประเภทคำถาม การดูแค่ยอดรวมจะซ่อนว่าอะไรเป็นตัวดันต้นทุนจริง (คำถามที่ต้องแนบ context เยอะ vs คำตอบที่ยาวเกินจำเป็น)
บันทึกว่าคำขอแต่ละครั้งใช้โมเดลตัวไหน — ถ้าระบบมีการสลับโมเดลอัตโนมัติ (เช่น ใช้โมเดลเล็กสำหรับ intent ง่าย ใช้โมเดลใหญ่เมื่อจำเป็น) ต้องเก็บ log ว่าคำขอไหนไปโมเดลไหน ไม่งั้นจะไม่มีทางรู้ว่าการสลับโมเดลได้ผลจริงหรือไม่
แยก log คำขอที่มาจากการทดสอบ/dev ออกจากคำขอลูกค้าจริง — คำขอจากทีมพัฒนาที่ทดสอบ flow ก่อนปล่อยใช้งาน ถ้าไม่ติด tag แยก จะปนเข้าไปในตัวเลขต้นทุนของสาขาที่ใช้ทดสอบ ทำให้ตัวเลขเดือนนั้นสูงผิดปกติโดยไม่มีเหตุผลทางธุรกิจ
มีสูตรจัดสรรต้นทุน infrastructure ที่แชร์กัน เขียนเป็นเอกสารและใช้ตายตัว — ไม่ใช่แค่ตกลงปากเปล่า เพราะถ้าเปลี่ยนสูตรกลางเดือนหรือเปลี่ยนตามอารมณ์ จะเทียบตัวเลขข้ามเดือนไม่ได้เลย
เก็บจำนวน resolution (บอทแก้ปัญหาสำเร็จโดยไม่โอนพนักงาน) คู่กับต้นทุน ไม่ใช่แค่จำนวนข้อความ — จำนวนข้อความสูงไม่ได้แปลว่าทำงานได้ดี บางครั้งข้อความเยอะเพราะบอทตอบไม่ตรงจนต้องถามซ้ำ ต้องมีตัวเลขที่บอกว่า "จบงานสำเร็จกี่ครั้ง" คู่กับต้นทุนเสมอ
ตั้งรอบตรวจสอบข้อมูลย้อนหลังอย่างน้อยเดือนละครั้งก่อนปิดยอด — เพื่อจับความผิดปกติ (request ซ้ำจาก bug, การทดสอบที่ลืม tag แยก) ก่อนที่ตัวเลขจะถูกใช้ไปตัดสินใจเรื่องงบประมาณจริง
กำหนดเจ้าของข้อมูล (data owner) ต่อสาขาให้ชัดว่าใครมีหน้าที่ตรวจสอบตัวเลขนี้ทุกเดือน — dashboard ที่ไม่มีใครเปิดดูเป็นประจำ ต่อให้ออกแบบดีแค่ไหนก็ไม่ต่างจากไม่มี

ตัวอย่างการคำนวณแบบสมมติ: ธุรกิจ 5 สาขา

หมายเหตุ: ตัวเลขทั้งหมดในหัวข้อนี้เป็นตัวอย่างสมมติเพื่ออธิบายวิธีคิดเท่านั้น ไม่ใช่ข้อมูลลูกค้าจริง สมมติธุรกิจร้านอาหาร 5 สาขา ใช้บอท AI ตอบคำถามลูกค้าผ่าน LINE ทุกสาขา และมีฐานความรู้ (vector database) กลางที่ทุกสาขาใช้ร่วมกัน

ขั้นที่ 1 — ต้นทุน token รายสาขา (สมมติ):

สาขา	จำนวนบทสนทนา/เดือน	ต้นทุน token รวม	ต้นทุนต่อบทสนทนา
A (สาขาใหญ่ ในห้าง)	4,000	4,000 บาท	1.00 บาท
B (สาขากลาง)	2,500	2,750 บาท	1.10 บาท
C (สาขากลาง)	2,200	2,860 บาท	1.30 บาท
D (สาขาเล็ก)	900	990 บาท	1.10 บาท
E (สาขาเล็ก เปิดใหม่)	600	1,080 บาท	1.80 บาท

ขั้นที่ 2 — จัดสรรต้นทุน infrastructure กลาง (สมมติ vector database + เซิร์ฟเวอร์ workflow รวม 3,000 บาท/เดือน) ตามสัดส่วนจำนวนบทสนทนา (รวม 10,200 บทสนทนา):

สาขา A: 4,000/10,200 × 3,000 = 1,176 บาท
สาขา B: 2,500/10,200 × 3,000 = 735 บาท
สาขา C: 2,200/10,200 × 3,000 = 647 บาท
สาขา D: 900/10,200 × 3,000 = 265 บาท
สาขา E: 600/10,200 × 3,000 = 176 บาท

ขั้นที่ 3 — ต้นทุนรวมต่อสาขา (token + ส่วนแบ่ง infrastructure):

สาขา A: 4,000 + 1,176 = 5,176 บาท → 1.29 บาท/บทสนทนา
สาขา B: 2,750 + 735 = 3,485 บาท → 1.39 บาท/บทสนทนา
สาขา C: 2,860 + 647 = 3,507 บาท → 1.59 บาท/บทสนทนา
สาขา D: 990 + 265 = 1,255 บาท → 1.39 บาท/บทสนทนา
สาขา E: 1,080 + 176 = 1,256 บาท → 2.09 บาท/บทสนทนา

การอ่านผล (ตัวอย่างสมมติ): ถ้าดูแค่ต้นทุนรวม สาขา A จะดูเหมือน "แพงที่สุด" เพราะยอดรวมสูงสุด แต่พอคิดต้นทุนต่อบทสนทนากลับถูกที่สุด

เพราะฐานปริมาณใหญ่ช่วยเฉลี่ยต้นทุน infrastructure กลางให้ต่ำลง

ส่วนสาขา E ที่ยอดรวมต่ำสุดกลับมีต้นทุนต่อบทสนทนาแพงที่สุด — สมเหตุสมผลถ้าสาขาเพิ่งเปิดใหม่และยังอยู่ช่วง ramp-up (ตามที่กล่าวถึงในหัวข้อ "ข้อควรระวัง" ด้านบน)

แต่ถ้าผ่านไป 3-4 เดือนแล้วตัวเลขสาขา E ยังไม่ลดลง นั่นคือสัญญาณที่ต้องเข้าไปตรวจว่าเกิดจากคำถามซ้ำที่ไม่ได้ cache หรือใช้โมเดลแพงเกินความจำเป็นหรือไม่ ไม่ใช่แค่ปัญหาปริมาณน้อย

ขั้นตอนถัดไปที่ควรทำคือเอาตัวเลขต้นทุนต่อบทสนทนานี้ไปวางคู่กับ resolution rate ของแต่ละสาขา (ตามหัวข้อที่ 5 ของโครงสร้าง dashboard ด้านบน) ก่อนสรุปว่าสาขาไหน "คุ้ม" หรือ "ไม่คุ้ม" จริง

บทความนี้อธิบายอะไร และไม่ได้อธิบายอะไร

บทความนี้อธิบาย แนวคิดและวิธีคิดโครงสร้างของ cost dashboard ต่อสาขา สำหรับธุรกิจหลายสาขาที่ใช้ AI พร้อมตัวอย่างการคำนวณแบบสมมติเพื่อให้เห็นภาพวิธีคิด

ไม่ใช่การเผยแพร่ตัวเลขต้นทุนจริงของลูกค้ารายใดรายหนึ่ง

ตัวเลขในหัวข้อ "ตัวอย่างการคำนวณแบบสมมติ" ด้านบนเป็นตัวเลขสมมติล้วนๆ ที่สร้างขึ้นเพื่ออธิบายสูตรจัดสรรต้นทุนเท่านั้น

ปัจจุบันยังไม่มีเวอร์ชันข้อมูลจริงแบบไม่ระบุตัวตน (anonymized) ที่พร้อมเผยแพร่ต่อสาธารณะ

เมื่อมีข้อมูลจริงจากลูกค้าที่ยินยอมให้ใช้แบบไม่ระบุตัวตน จะมีการเผยแพร่เป็นบทความ proof-of-concept แยกต่างหากในอนาคต

Cost dashboard แบบที่อธิบายในบทความนี้เป็นหนึ่งใน deliverable ของแพ็กเกจ AI Engineering at Scale ของเรา ซึ่งเป็นบริการวางระบบ AI สำหรับธุรกิจหลายสาขา — อ่านรายละเอียดเพิ่มเติมได้ที่หน้า AI Engineering at Scale

และถ้าสนใจแนวคิดเรื่องระบบ AI ที่วางไว้สาขาเดียวแล้ว clone ไปใช้ได้ทุกสาขา อ่านต่อได้ในบทความ "ระบบ AI ที่ Clone ได้ทุกสาขา"

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

Q: ต้นทุน AI ต่อสาขาต่อเดือน ควรอยู่ที่เท่าไหร่? A: ไม่มีตัวเลขตายตัว เพราะขึ้นอยู่กับปริมาณการใช้งาน โมเดลที่เลือกใช้ และความซับซ้อนของงานที่ AI ทำ

สิ่งที่สำคัญกว่าตัวเลขเดี่ยวๆ คือการมีระบบติดตามที่แตกรายสาขาได้ เพื่อเทียบสาขาต่อสาขาและเทียบกับผลลัพธ์ที่ได้

Q: ทำไมบิล AI รวมทั้งบริษัทถึงไม่พอใช้ตัดสินใจ? A: เพราะบิลรวมบอกแค่ยอดรวม แต่ไม่บอกว่าสาขาไหนเป็นตัวดันต้นทุนขึ้น หรือสาขาไหนใช้งานคุ้มค่าจริง การตัดงบหรือขยายระบบโดยดูแค่ยอดรวมจึงเป็นการเดา ไม่ใช่การตัดสินใจจากข้อมูล

Q: ต้องมีทีม data/IT เองก่อนไหมถึงจะทำ cost dashboard แบบนี้ได้? A: ไม่จำเป็นต้องมีทีมภายในก่อน ระบบสามารถวางโครงสร้าง tagging และ dashboard ให้ตั้งแต่ตอนสร้างระบบ AI ได้เลย

โดยเจ้าของธุรกิจไม่ต้องเข้าใจรายละเอียดทางเทคนิคทั้งหมด แค่ต้องรู้ว่าต้องดูตัวเลขไหนเพื่อตัดสินใจ

Q: ถ้าใช้ AI Automation แบบ subscription รายเดือน (เช่นแพ็กเกจแฟรนไชส์บอท) ยังต้องมี cost dashboard แบบนี้ไหม? A: แบบ subscription ราคาคงที่มักไม่มีความจำเป็นต้องแตกต้นทุนละเอียดขนาดนี้ เพราะจ่ายเท่ากันทุกเดือนอยู่แล้ว แต่จะไม่เห็นว่าสาขาไหนใช้งานคุ้มหรือไม่คุ้ม

cost dashboard แบบนี้เหมาะกับระบบที่วางเอง (bespoke) ซึ่งต้นทุนผันตามการใช้งานจริง และต้องการความโปร่งใสระดับสาขา

Q: มีเครื่องมือสำเร็จรูปให้ใช้ทำ cost dashboard แบบนี้ไหม หรือต้องสร้างเอง? A: มีเครื่องมือ observability/gateway สำหรับ LLM ในตลาดที่รองรับการแตกต้นทุนตาม tag ได้อยู่แล้ว (เช่น LiteLLM, Langfuse)

งานหลักคือการออกแบบว่าจะ tag "สาขา" เข้าไปตรงไหนของระบบ และจะจัดสรรต้นทุน infrastructure ที่ใช้ร่วมกันอย่างไรให้ยุติธรรม ซึ่งเป็นงานออกแบบสถาปัตยกรรม ไม่ใช่แค่ติดตั้งเครื่องมือ

สนใจให้เราวางระบบ cost dashboard แบบนี้ให้ธุรกิจหลายสาขาของคุณ? Cost dashboard ต่อสาขาต่อเดือนเป็นหนึ่งใน deliverable ที่รวมอยู่ในแพ็กเกจ AI Engineering at Scale ของเรา — ทักมาคุยรายละเอียดและขอใบเสนอราคา

เขียนโดย Jade (Sarunjade) — ที่ปรึกษาและวิศวกรระบบ AI สำหรับธุรกิจหลายสาขา บทความนี้เป็นบทความอธิบายแนวคิดและวิธีการ (methodology explainer) ไม่ใช่ case study ที่เผยแพร่ผลลัพธ์จริงของลูกค้ารายใดรายหนึ่ง — ปัจจุบันยังไม่มีข้อมูลลูกค้าจริงแบบไม่ระบุตัวตนที่พร้อมเผยแพร่ ตัวเลขและแนวทางในบทความนี้อ้างอิงจากหลักปฏิบัติ FinOps for AI และเอกสารเครื่องมือ observability ที่ใช้งานจริงในอุตสาหกรรม (อ้างอิงด้านล่าง) ตัวอย่างการคำนวณในหัวข้อ "ตัวอย่างการคำนวณแบบสมมติ" เป็นตัวเลขสมมติที่สร้างขึ้นเพื่ออธิบายวิธีคิดเท่านั้น

แหล่งอ้างอิง: