ทำไมบิล AI พุ่ง เพราะสถาปัตยกรรม ไม่ใช่ prompt
การลดต้นทุน LLM คือแนวทางออกแบบและปรับแต่งสถาปัตยกรรมของระบบปัญญาประดิษฐ์ที่ใช้โมเดลภาษา เพื่อลดจำนวน token การเรียกใช้โมเดลที่ไม่จำเป็น และการคำนวณซ้ำ โดยเน้นการเลือกโมเดลให้เหมาะกับงาน การจัดการ context อย่างมีระบบ การใช้ prompt caching และการเก็บข้อมูลการใช้งานเพื่อวิเคราะห์ต้นทุน มากกว่าการปรับแก้ข้อความใน prompt ทีละคำ ทีมจำนวนมากเริ่มแก้ปัญหาบิล AI โดยลบคำใน system prompt แต่ไม่แตะสถาปัตยกรรมเลย ทั้งที่ระบบเดียวกันอาจส่งทุกคำขอไปยังโมเดลระดับแพง ใส่ประวัติสนทนาเกินจำเป็น ใช้เครื่องมือหลายตัว ซ้ำด้วยการ retry และเรียกตัวประเมินที่ก็ใช้ LLM อีกครั้ง การปรับคำจาก 1,200 token ให้เหลือ 1,050 token ดูเหมือนมีประโยชน์ แต่แทบไม่ช่วยอะไรถ้าโครงสร้างระบบยังสิ้นเปลืองอยู่ คำถามที่ควรถามจึงไม่ใช่ว่า “ทำให้ prompt ถูกลงอย่างไร” แต่ควรถามว่า “ทำไมคำขอนี้ต้องใช้โมเดลนี้ context ปริมาณนี้ จำนวนครั้งเรียกนี้ และผลลัพธ์ยาวขนาดนี้ตั้งแต่แรก” เมื่อตั้งคำถามใหม่ คุณจะเลิกมองต้นทุนแบบจุดเล็ก และหันไปมองเป็นปัญหาของทั้งระบบ LLM cost optimization จึงเป็นปัญหาด้านระบบมากขึ้นเรื่อยๆ ไม่ใช่เรื่องของ prompt แยกส่วน
| องค์ประกอบต้นทุนคำขอ LLM | ตัวอย่างการสิ้นเปลือง | แนวทางลดต้นทุน |
|---|---|---|
| uncached input tokens | ส่งประวัติสนทนาเดิมทุกครั้งแม้ไม่จำเป็น | ทำ context optimization และสรุปข้อมูลที่เลิกใช้งาน |
| cache writes และ cache reads | เปิด caching แต่ไม่ออกแบบ prompt ให้ใช้ซ้ำได้ | วางโครงสร้าง prompt ให้ส่วนที่ซ้ำสามารถอ่านจาก cache |
| output tokens | ให้โมเดลเขียนข้อความยาวเกินกว่าที่ระบบแสดง | กำหนดรูปแบบผลลัพธ์และความยาวให้ตรงกับการใช้งานจริง |
โมเดล routing เลือกสมองให้ตรงงาน ลดต้นทุน LLM แบบไม่เสียคุณภาพ
หัวใจการลดต้นทุน LLM คือยอมรับว่า ไม่ใช่ทุกงานสมควรใช้โมเดลที่เก่งที่สุดเสมอ งานจำแนกกลุ่ม ขีดเส้นข้อมูล และจัดรูปแบบ ส่วนใหญ่ใช้โมเดลเล็กและเร็วได้ ส่วนงานให้เหตุผลซับซ้อน งานหลายขั้นตอนแบบ agent และการตัดสินใจเสี่ยงสูง อาจต้องใช้โมเดลระดับ frontier ที่แพงกว่า แต่ก็มีไม่กี่เปอร์เซ็นต์ของคำขอรวม สถาปัตยกรรมที่ดีจึงเพิ่มชั้นโมเดล routing เข้ามาคั่นระหว่างคำขอและโมเดล ระบบจะตัดสินใจส่งคำขอไปยังโมเดลเล็ก โมเดลมาตรฐาน หรือโมเดล frontier ตามความยากของงานและความเสี่ยง หลักสำคัญคือ “ซื้อเฉพาะระดับความสามารถที่งานต้องการ” ไม่ใช่ส่งทุกอย่างไปให้โมเดลแพงสุด ตัวอย่างสถาปัตยกรรมพื้นฐานคือ ให้คำขอทุกคำผ่าน router ก่อน ถ้าเป็นงาน classification หรือ structured extraction ก็ไปโมเดลเล็ก ถ้าต้อง reasoning ลึกหรือความเสี่ยงสูงไปโมเดล frontier ส่วนที่เหลือใช้โมเดลมาตรฐานเป็นค่าเริ่มต้น และถ้ามีการตรวจสอบความถูกต้องแล้วพบว่าผลลัพธ์จากโมเดลเล็กไม่ผ่านก็ escalates ไปโมเดลมาตรฐานหรือ frontier ต่อ การออกแบบแบบนี้ลดค่า token ต่อคำขอได้มาก โดยไม่ต้องแตะ prompt เลย
context optimization และ token budget ทำให้ระบบฉลาดขึ้นภายใต้ข้อจำกัด
ปัญหาที่มองไม่เห็นในระบบหลายแห่งคือ โทเคนส่วนใหญ่ใช้ไปกับการส่งบริบทเดิมซ้ำๆ โดยไม่มีใครเช็ก ตัวอย่างหนึ่งคือ session ของ agent ที่ทำงานธรรมดา วางแผน query รัน ตรวจผล และแก้ไข เมื่อดูใกล้ๆ พบว่าในการเรียกโมเดลทั้งหมด 9 ครั้ง ภาพรวม context ส่วนใหญ่เป็นประวัติที่โมเดลไม่ต้องใช้แล้ว ทั้ง schema ที่ใช้ไปแล้ว output เครื่องมือที่สรุปแล้ว และคำสั่งที่ทำตามไปแล้ว การแก้ด้วยการบอกทีมให้จัดการ context เอง เช่น ตัด history สรุปผล tool หรือไม่แปะ schema ทั้งหมด มักไม่ยั่งยืน เพราะงานจัดการบริบทเป็นสิ่งที่มองไม่เห็นเมื่อมันทำงานดีและเจ็บปวดเมื่อมันพัง ทำให้แพ้ฟีเจอร์ใหม่ที่ทีมอยากส่งเสมอ นอกจากนี้แต่ละทีมก็คิดวิธีต่างกันไป จนแพลตฟอร์มมี “กลยุทธ์ context” หลายสิบแบบในที่เดียว เมื่อเปลี่ยนเวอร์ชันโมเดลหรือราคา คุณจะไม่อยากแก้ 40 ที่พร้อมกัน ทางออกคือย้าย context handling ลงไปชั้นล่าง ให้ agent ตัดสินใจว่าจะทำอะไร ส่วนเลเยอร์ด้านล่างตัดสินใจว่าจะให้มันเห็นโลกแค่ไหน และจัดการ token budget ต่อคลาสของงานล่วงหน้าก่อนรัน agent ไม่ใช่รอให้บิลออกมาค่อยรู้ต้นทุน ในระบบหลายขั้นตอนจริง เลเยอร์ context ที่แบ่งเป็นการเลือก การคัด การบีบอัด และการกำหนดเพดาน สามารถลดจำนวน input token ต่อการเรียกได้ราวสามในสี่ โดยไม่แตะ logic ของ agent และไม่เปลี่ยนคำตอบเลย
ข้อดีของ context engineering ชั้นใต้ agent
- อัปเดตกลยุทธ์ context ที่จุดเดียว ไม่ต้องให้ทุกทีม refactor
- สามารถคุม token budget ต่อคลาสงานให้คาดเดาได้มากขึ้น
- ลด input token ได้มากโดยไม่กระทบ logic หรือคุณภาพคำตอบ
ข้อเสียและข้อควรระวัง
- เลเยอร์นี้รู้ข้อมูลน้อยกว่า agent ใช้แค่ task class และสัญญาณพื้นฐาน จึงอาจตัดทอนสิ่งที่ implementation แบบผูกกับ agent จะเก็บไว้
- การ debug ยากขึ้น เพราะมีเลเยอร์กลางระหว่างสิ่งที่ agent คิดว่ามันส่ง กับสิ่งที่ถูกส่งจริง
- ถ้าเพดานงบ token แข็งเกินไป เมื่อภารกิจต้องใช้ context เกินกว่าที่คลาสกำหนด ผลลัพธ์จะแย่ลงแทนที่จะเป็นคำตอบแพงขึ้น
prompt caching และ semantic caching ตัดคำขอซ้ำออกจากระบบ
การลดต้นทุน LLM ที่ชัดเจนอีกด้านคือ prompt caching และ semantic caching ถ้าออกแบบดี มันทำให้คำขอที่ซ้ำหรือใกล้เคียงกันไม่ต้องจ่ายราคาเท่า context ใหม่ทุกครั้ง แต่ต้องเข้าใจว่า cache มีเศรษฐศาสตร์ของมันเอง ไม่ใช่ใส่ปุ่ม enable แล้วจบ ผู้ให้บริการบางรายตั้งราคาการอ่าน cache ต่ำกว่าการอ่าน input ปกติมาก แต่เขียน cache อาจมีราคาของตัวเองที่สูงกว่า input ปกติด้วยซ้ำ แนวคิดคือ context ที่ใช้ซ้ำควรไม่ต้องคำนวณและคิดราคาเท่ากับ context ใหม่เสมอ คุณจึงต้องออกแบบ prompt ให้มีส่วนหัวและคำอธิบายที่ใช้ร่วมกันได้หลายคำขอ แยกจากส่วนที่เปลี่ยนตามผู้ใช้ เมื่อส่วนที่ใช้ซ้ำถูกเขียนลง cache ครั้งแรก ค่าใช้จ่ายตรงนี้อาจสูงขึ้นเล็กน้อย แต่การอ่านซ้ำในคำขอต่อไปจะถูกลงมาก semantic caching ทรงพลังแต่ก็ง่ายต่อการใช้ผิด ถ้าความรู้และผลลัพธ์ค่อนข้างนิ่ง ระบบสามารถฝังเวกเตอร์คำถามใหม่ หา query ใน cache ที่ใกล้ความหมายกัน และใช้คำตอบเดิมได้ วิธีนี้ลดจำนวนการเรียก API ที่ไม่จำเป็น และลดเวลาตอบกลับสำหรับคำถามแบบเดิมที่มักเกิดขึ้นซ้ำ แต่ถ้าใช้กับข้อมูลที่เปลี่ยนบ่อยหรือมีบริบทเฉพาะผู้ใช้ อาจให้คำตอบผิดหรือไม่ตรงกับสถานการณ์ปัจจุบัน
สังเกตต้นทุนทั้งระบบ แล้วค่อยใช้ batch และสรุปบทเรียน
ก่อนลดต้นทุน LLM ต้องมองเห็นก่อนว่าเงินไหลออกตรงไหน ผู้เขียนระบบระดับแพลตฟอร์มเคยเจอว่าทุก agent ที่ onboard มีพฤติกรรมสิ้นเปลือง token แบบเดียวกัน และไม่มีทีมไหนสังเกตจนกว่าจะมีบิลออกมา เพื่อไม่ให้เกิดภาพแบบนั้น คุณต้องสร้างระบบบันทึกการใช้ LLM ให้ละเอียดตั้งแต่แรก ไม่ใช่ภายหลัง สำหรับแต่ละคำขอควรมีเหตุการณ์ใช้ LLM ที่บันทึกข้อมูลเช่น requestId ฟีเจอร์ tenantId โมเดล route ว่า small standard หรือ frontier เวอร์ชัน prompt จำนวน input token และ cached input token จำนวน output token จุดประสงค์ เช่น user-response classification retrieval summarization evaluation retry หรือ background-job เวลา latency จำนวนครั้ง retry และต้นทุนโดยประมาณต่อคำขอ เมื่อมีข้อมูลระดับนี้ คุณจะตอบคำถามได้ว่า ฟีเจอร์ไหนกินงบสุด tenant ไหนใช้หนัก โมเดลใดถูกใช้มากสุด ต้นทุนส่วนไหนมาจาก retry หรือ internal call และแต่ละเวอร์ชัน prompt ทำให้ context ใหญ่ขึ้นเท่าไหร่ ถ้าวาง tracing และ evaluation ไว้ใน repository ที่สร้าง agent ตั้งแต่ commit แรก ทุก agent จะส่ง telemetry เรื่อง token และคุณภาพโดยอัตโนมัติ เมื่อเห็นภาพรวมแล้วจึงค่อยใช้เทคนิคอย่าง batch processing ในงาน background และการจัดเส้นทางคำขอให้เหมาะกับโมเดลและเวลาการตอบ เพื่อให้ต้นทุนสอดคล้องกับผลลัพธ์ทางธุรกิจ ไม่ใช่แค่ถูกที่สุดต่อ token
