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

หากค่าใช้จ่าย LLM ของคุณกำลังพุ่งสูงขึ้น คุณอาจจะอยากเปลี่ยนไปใช้โมเดลที่ราคาถูกกว่า เช่น เปลี่ยนจาก GPT-4 เป็น GPT-4-mini ซึ่งวิธีนี้ช่วยได้เพียงเล็กน้อย และแทบจะไม่สามารถแก้ปัญหาที่แท้จริงได้เลย

ปัญหาที่แท้จริงคือเวิร์กโฟลว์ (Workflow) ของคุณ คนส่วนใหญ่มักจะส่งทุกขั้นตอนผ่าน LLM โดยใช้การใช้เหตุผลทางภาษา (Language reasoning) กับงานที่ไม่จำเป็นต้องใช้มัน

ทุกเวิร์กโฟลว์ของ AI ประกอบด้วย 4 ส่วน:

• Trigger: เริ่มต้นการทำงาน ค่าใช้จ่ายเกือบเป็นศูนย์ • Deterministic ML: จัดหมวดหมู่หรือให้คะแนนข้อมูล ซึ่งมีราคาถูก • LLM: อ่าน เขียน และใช้เหตุผล ซึ่งมีราคาแพง • Tool/API: ดึงข้อมูลหรือเขียนข้อมูล ซึ่งมีราคาถูก

ช่องว่างระหว่าง Deterministic ML และ LLM นั้นกว้างมาก LLM อาจมีราคาแพงกว่าโมเดลจัดหมวดหมู่ (Classifier) แบบง่ายๆ ถึง 100 ถึง 1,000 เท่า หากคุณไม่เลือกเครื่องมือที่เหมาะสมสำหรับแต่ละขั้นตอน คุณก็จะลงเอยด้วยการใช้เครื่องมือที่แพงที่สุดโดยอัตโนมัติ

ลองดูตัวอย่างระบบ Support Ticket

การออกแบบที่ไม่ดีจะส่ง Ticket ทั้งหมดไปยัง LLM โดยสั่งให้ LLM วิเคราะห์เจตนา (Intent), จัดเส้นทาง Ticket, ร่างคำตอบ และอัปเดต CRM ซึ่งเป็นการใช้จ่ายที่เกินความจำเป็น เพราะการจัดหมวดหมู่ไม่จำเป็นต้องใช้ LLM แต่ต้องการเพียงโมเดลแบบง่ายๆ เพื่อจับคู่ข้อความเข้ากับหมวดหมู่เท่านั้น

การออกแบบที่ดีกว่าควรเป็นดังนี้:

  1. Trigger: มี Ticket เข้ามา
  2. Deterministic ML: โมเดลที่รวดเร็วและราคาถูกจะตัดสินว่า Ticket นั้นเป็นเรื่องการเรียกเก็บเงิน, เรื่องทางเทคนิค หรือสแปม
  3. LLM: ใช้เฉพาะเพื่อร่างคำตอบสำหรับ Ticket ที่ถูกต้องเท่านั้น
  4. Tool/API: ระบบทำการอัปเดต CRM

ในเวอร์ชันนี้ Ticket ที่เป็นสแปมจะไม่ถูกส่งไปถึง LLM เลย ทำให้คุณไม่ต้องจ่าย "ภาษี LLM" (LLM tax) ให้กับงานที่ไร้ประโยชน์

หากคุณวางโครงสร้างสถาปัตยกรรมอย่างถูกต้อง คุณจะสามารถตัดการเรียกใช้งาน (Calls) ที่แพงที่สุดออกไปได้ โดยที่ยังไม่ต้องเปลี่ยนโมเดลด้วยซ้ำ

ทำตามขั้นตอนเหล่านี้เพื่อลดค่าใช้จ่ายของคุณ:

  • วางแผนเวิร์กโฟลว์ของคุณ ระบุว่าขั้นตอนใดที่ต้องใช้การใช้เหตุผลจริงๆ และขั้นตอนใดที่เป็นเพียงการจัดหมวดหมู่หรือการดึงข้อมูล (Extraction)
  • ย้ายขั้นตอนที่เป็น Deterministic ออกจาก Prompt ใช้เครื่องมือที่รวดเร็วและราคาถูกกว่าสำหรับการจัดเส้นทาง (Routing) และการให้คะแนน (Scoring)
  • จำกัดการเข้าถึง LLM (Gate the LLM) อย่าสร้างคำตอบสำหรับงานที่ไม่จำเป็นต้องใช้มัน
  • ประเมินขนาดของโมเดลเป็นขั้นตอนสุดท้าย เลือกใช้โมเดลขนาดเล็กสำหรับขั้นตอนการสร้างคำตอบ (Generation) ก็ต่อเมื่อสถาปัตยกรรมของคุณมีความกระชับ (Lean) แล้วเท่านั้น

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

Source: https://dev.to/bakshiyogesh/your-ai-bill-isnt-a-model-problem-its-an-architecture-problem-1ole

Optional learning community: https://t.me/GyaanSetuAi