ถ้าคุณเป็นคนที่ต้องจ่ายค่าบริการ AI เองทุกเดือน ก็น่าจะคุ้นเคยกับความรู้สึกที่ว่า ค่าใช้จ่ายปลายเดือนพุ่งเร็วกว่าประโยชน์ที่จับต้องได้ ปัญหานี้ Uber เองก็เจอมาเต็มๆ ทั้งองค์กร โดยในปี 2026 Uber ใช้งบ AI ของทั้งปีหมดเกลี้ยงตั้งแต่ 3 เดือนแรก จน COO ของบริษัทต้องออกมาให้สัมภาษณ์กับ Fortune ในเดือนพฤษภาคมว่า เริ่มตอบยากขึ้นเรื่อยๆ ว่าบริษัทจ่ายค่าเครื่องมือช่วยเขียนโค้ดด้วย AI ของ Anthropic อย่าง Claude Code ไปเพื่ออะไร ในเมื่อยังมองไม่เห็นประโยชน์ที่คุ้มค่าชัดเจนจากโมเดลตัวท็อปเหล่านี้

แต่ทางออกที่ Uber เลือก กลับไม่ใช่การสั่งให้ลดการใช้ AI ลง เพราะค่าใช้จ่ายที่บานปลายไม่ได้เกิดจากพนักงานใช้งานเยอะเกินไป แต่เกิดจากการเผลอส่งงานง่ายๆ ไปให้โมเดลที่แพงที่สุดทำโดยไม่จำเป็น และไม่ได้มีแค่ Uber ที่เจอปัญหานี้ ทั้ง Pinterest และ AT&T ต่างก็เพิ่งเปิดเผยตัวเลขของตัวเองไปในทิศทางเดียวกันว่า สามารถลดค่าใช้จ่ายลงได้ตั้งแต่ราวครึ่งหนึ่งไปจนถึงเก้าในสิบ ด้วยระบบ Model Routing ที่คอยคัดแยกงานตามความยากง่าย โดยทั้งสามบริษัทยังคงใช้โมเดลตัวท็อปกับงานยากๆ เหมือนเดิม

Uber: ผู้ใช้เพิ่ม 7 เท่า แต่ค่าใช้จ่ายนิ่งสนิท

ระหว่างเดือนกุมภาพันธ์ถึงสิงหาคม จำนวนผู้ใช้งาน AI Agent รายสัปดาห์ของ Uber เพิ่มขึ้นถึง 7 เท่า และจำนวนคำขอที่ Agent ส่งเข้ามาก็เพิ่มขึ้นถึง 9.4 เท่า แต่ค่าใช้จ่ายรวมของบริษัทกลับนิ่งสนิทมาตั้งแต่ช่วงเดือนมีนาคมถึงเมษายน โดยตัวเลขที่ Uber เปิดเผยในบล็อกวิศวกรรมระบุว่า ต้นทุนต่อคำขอ 1,000 ครั้งลดลง 34% และต้นทุนต่อหนึ่งเซสชันลดลงถึง 52% เมื่อเทียบจากจุดที่พุ่งสูงสุดในปีนี้

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

ยิ่งไปกว่านั้น ปัจจุบัน Pull Request มากกว่า 70% ของ Uber มาจาก AI Agent และ Uber ยังยืนยันด้วยว่าคุณภาพงานของ Agent ยังคงเท่าเดิมหรือดีขึ้น ขณะที่ต้นทุนต่อหน่วยลดลงในทุกตัวชี้วัด

Pinterest: จากที่เคยจ่ายร้อย ตอนนี้เหลือแค่แปด

Pinterest เปิดเผยเรื่องนี้ในการแถลงผลประกอบการรอบล่าสุด โดยซีอีโอ William Ready เล่าว่า Pinterest หันมาใช้โมเดลขนาดเล็กที่พัฒนาขึ้นเองสำหรับงานเฉพาะทาง ควบคู่ไปกับโมเดลแบบเปิดหรือ Open-source model ที่นำมาเทรนต่อด้วยข้อมูลภายในบนคลาวด์ส่วนตัวที่ปลอดภัยของบริษัท ผลลัพธ์คือ ต้นทุนต่อรายการของโมเดลเปิดเหล่านี้ เหลือไม่ถึง 8% เมื่อเทียบกับการใช้โมเดลแบบปิดหรือ Closed-source model ที่มีประสิทธิภาพใกล้เคียงกัน

เพื่อให้เห็นภาพชัดขึ้น จดหมายข่าวสายวิศวกรรมอย่าง The Pragmatic Engineer ซึ่งรวบรวมกรณีศึกษาของทั้งสามบริษัทนี้ ได้เปรียบเทียบตัวเลข 8% ให้เข้าใจง่ายๆ ว่า งานชิ้นไหนที่เคยต้องจ่าย 100 ดอลลาร์ ตอนนี้ Pinterest จ่ายจริงไม่ถึง 8 ดอลลาร์ (นี่เป็นการเปรียบเทียบของผู้เขียนจดหมายข่าว ไม่ใช่คำพูดโดยตรงของ Pinterest แต่คำนวณตามตัวเลขแล้วตรงกัน)

อย่างไรก็ตาม Pinterest ไม่ได้ระบุว่าใช้โมเดลเปิดตัวไหน และไม่ได้บอกว่ายังมีงานส่วนใดบ้างที่ยังต้องพึ่งพาโมเดลปิดอยู่ สิ่งที่ยืนยันมีเพียงต้นทุนต่อรายการของงานส่วนที่ย้ายมาใช้โมเดลเปิดแล้วเท่านั้น

AT&T: ลดต้นทุนได้ 56% แลกกับคุณภาพที่ลดลงเพียง 2%

สำหรับองค์กรยักษ์ใหญ่อย่าง AT&T ที่มีพนักงานหนึ่งแสนคน ผู้บริหารของบริษัทเปิดเผยกับสำนักข่าว The Information ว่า หลังจากย้ายงานบางส่วนไปรันบนโมเดลเปิด โดยใช้โปรแกรมคัดแยกและส่งต่องานอย่าง LiteLLM ที่คอยรับคำขอแล้วส่งต่อไปยังโมเดลที่กำหนดไว้ ต้นทุนของงานขั้นสูงบางอย่าง เช่น งานเขียนโค้ด ลดลงไปได้ถึง 56% โดยแลกกับคุณภาพงานที่วัดผลได้ลดลงไปเพียง 2% เท่านั้น

คุณภาพที่ลดลง 2% คือสิ่งที่ต้องแลกกับการย้ายครั้งนี้ แต่ AT&T ก็ไม่ได้ย้ายงานทั้งหมดไปใช้โมเดลเปิด ผู้บริหารคนเดิมระบุว่า นักพัฒนาของ AT&T ยังคงใช้โมเดลตัวท็อปกับงานยากๆ เช่น การเขียนโค้ดที่มีความซับซ้อนสูง ส่วนงานที่ย้ายไปใช้โมเดลเปิดคืองานที่เบากว่า เช่น การอ่านและสรุปโค้ดที่ส่งเข้ามา ซึ่งเขามองว่าสำหรับงานประเภทนี้ โมเดลเปิดทำผลงานได้ดีเทียบเท่า หรืออาจจะดีกว่าโมเดลรุ่นเก่าของ Anthropic และ OpenAI ด้วยซ้ำ

Routing: เหมือนมีคนคอยคัดแยกงานอยู่ตรงทางเข้า

จุดที่คนมักเข้าใจผิดมากที่สุด คือคิดว่าบริษัทเหล่านี้ตัดสินใจเลิกใช้โมเดลแพงๆ ไปเลย แต่ความจริงคือไม่มีใครเลิกใช้ โดย AT&T ยังคงใช้โมเดลตัวท็อปกับงานยาก และ Uber ก็ยังใช้โมเดลปิดกับงานสำคัญอย่างการตรวจโค้ด สิ่งเดียวที่เปลี่ยนไปคือ "งานไหนควรส่งให้ใครทำ" (ทั้งนี้ ตัวเลขทั้งสามชุดข้างต้น เป็นตัวเลขที่แต่ละบริษัทเก็บสถิติและรายงานขึ้นมาเอง)

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

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

สูตร 3 ขั้นของ Uber ที่ทีมเล็กก็ทำตามได้

ขั้นที่ 1: วัดผลจากเนื้องานจริงของตัวเอง

Uber ไม่ได้เลือกโมเดลจากการดูชาร์ตจัดอันดับบนอินเทอร์เน็ต แต่วัดจากเนื้องานจริง ตัวอย่างที่บล็อกยกมาคือระบบตรวจโค้ดสำหรับทุก Pull Request ในบริษัท ซึ่ง Uber ได้สร้าง Benchmark หรือชุดทดสอบมาตรฐานขึ้นมาจาก Pull Request จริงในระบบที่รู้อยู่แล้วว่ามีบั๊กซ่อนอยู่ตรงไหนบ้าง โดยแบ่งระดับความยากออกเป็น ง่าย ปานกลาง และยาก จากนั้นนำโมเดลทุกตัว ทั้งแบบเปิดและแบบปิด มารันผ่านระบบเดียวกัน แล้วให้คะแนนความแม่นยำในการตรวจจับบั๊ก ควบคู่ไปกับต้นทุนต่อการตรวจหนึ่งครั้ง ความเร็ว โอกาสที่การประมวลผลจะหมดเวลา และอัตราการแจ้งเตือนบั๊กมั่ว

ผลการทดสอบของ Uber ชี้ให้เห็นว่า โมเดลปิดระดับแนวหน้าส่วนใหญ่ที่นำมาทดสอบ มีต้นทุนอยู่ที่ 0.94 ถึง 2.42 ดอลลาร์ต่อการตรวจหนึ่งครั้ง ขณะที่โมเดลเปิดอยู่ที่ 0.06 ถึง 0.28 ดอลลาร์ แต่โมเดลที่ Uber เลือกใช้งานจริงในระบบ กลับเป็นโมเดลปิดตัวหนึ่งที่มีต้นทุน 0.47 ดอลลาร์ต่อครั้ง เพราะได้คะแนนความแม่นยำสูงที่สุดจากทั้งหมด 10 โมเดลที่นำมาทดสอบ บทเรียนตรงนี้คือ โมเดลที่ถูกที่สุดไม่ใช่คำตอบเสมอไป แต่ต้องเป็นโมเดลที่ "คุ้มค่าที่สุด" และโมเดลที่คุ้มค่าที่สุดก็ไม่ได้เป็นตัวเดิมตลอดไป โดย Uber ระบุเองว่าโมเดลที่คุ้มค่ามักจะเปลี่ยนไปทุกๆ ไม่กี่สัปดาห์ ทำให้ต้องนำชุดทดสอบนี้มารันประเมินซ้ำอยู่เรื่อยๆ

ถ้าคุณข้ามขั้นตอนนี้ แล้วรีบเปลี่ยนโมเดลตามกระแสที่เห็นคนแชร์กัน คุณจะไม่มีทางรู้เลยว่าคุณภาพงานลดลงไปแค่ไหน AT&T มั่นใจได้ว่าคุณภาพงานลดลงไปเพียง 2% ก็เพราะลงมือวัดผลจริง ส่วนทีมที่ไม่เคยวัด ก็จะไม่มีวันรู้ตัวเลขนี้เลย

ขั้นที่ 2: แบ่งงานตามระดับความยาก

ในระบบ AI Agent ยุคใหม่ งานหนึ่งชิ้นมักไม่ได้ใช้โมเดลเพียงตัวเดียวทำงานตั้งแต่ต้นจนจบ แต่โมเดลหลักจะทำหน้าที่แตกงานใหญ่ให้เป็นงานย่อยๆ แล้วส่งต่องานย่อยเหล่านั้นไปให้ Agent ตัวรองอย่าง Subagent ที่รับงานเฉพาะจุดไปทำแล้วส่งผลลัพธ์กลับมา ก่อนที่โมเดลหลักจะตรวจทานผลลัพธ์รวมอีกครั้ง Uber เผยว่า ในบรรดาการปรับแต่งทั้งหมด การปรับค่าเริ่มต้นของโมเดลที่ Subagent ใช้นั้นช่วยลดค่าใช้จ่ายได้มากที่สุด และยิ่งเห็นผลชัดเจนขึ้นเรื่อยๆ เพราะสัดส่วนของเซสชันที่เรียกใช้ Subagent เพิ่มขึ้นตลอดเวลา

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

ขั้นที่ 3: ตั้งค่าเริ่มต้นให้เหมาะสม

ขั้นตอนนี้เป็นส่วนที่คนทำงานคนเดียวหรือทีมขนาดเล็กนำไปปรับใช้ตามได้ทันทีโดยไม่ต้องพึ่งพาวิศวกร โดย Uber ปรับการตั้งค่าเริ่มต้นไว้ 3 จุดสำคัญ:

ข้อแรก ตั้งค่า Reasoning Effort หรือระดับการใช้ความคิดของโมเดล ไว้ที่ระดับปานกลางอย่าง Medium สำหรับทุกรอบการทำงาน เพราะ Output Token หรือโทเคนขาออกซึ่งเป็นหน่วยนับข้อความที่โมเดลสร้างขึ้น รวมถึงข้อความที่โมเดลคิดในใจ มีราคาแพงกว่าโทเคนขาเข้าหลายเท่าตัว และ Uber พบว่าสำหรับงานส่วนใหญ่ ระดับ Medium เป็นจุดสมดุลที่ดีที่สุดระหว่างต้นทุนและคุณภาพงาน

ข้อสอง ตัดทอนประวัติบทสนทนาด้วยวิธี Context Truncation โดยอัตโนมัติเมื่อแตะ 400,000 โทเคน แม้ว่าตัวโมเดลจะรองรับได้สูงสุดถึง 1,000,000 โทเคนก็ตาม เพราะทุกรอบที่เราส่งข้อความใหม่ โมเดลจะต้องอ่านประวัติทั้งหมดใหม่ตั้งแต่ต้น ยิ่งปล่อยให้ประวัติยาวเท่าไร เราก็ยิ่งต้องจ่ายค่าอ่านประวัติเดิมซ้ำๆ แพงขึ้นเรื่อยๆ

ข้อสาม ใช้ระบบแคชประวัติอย่าง Prompt Caching ให้เป็น ในแต่ละรอบที่คุยกัน แม้เราจะต้องส่งประวัติบทสนทนาเดิมซ้ำเข้าไป แต่ข้อความส่วนที่ระบบแคชไว้แล้ว จะคิดราคาเพียง 0.1 เท่า (ลดลง 90%) ของราคาโทเคนขาเข้าปกติ โดยแลกกับการจ่ายค่าเขียนแคชในครั้งแรกแพงขึ้นเป็น 1.25 ถึง 2 เท่าตามระยะเวลาที่จัดเก็บ ซึ่งเราเคยอธิบายเรื่องนี้ไว้อย่างละเอียดในบทความ ตอนที่ prompt cache หลุด แล้วว่า หากแคชหลุดเพียงครั้งเดียว คุณจะต้องจ่ายเงินค่าประวัติการคุยใหม่ทั้งหมดทันที

นอกจากนี้ Uber ยังพบอีกจุดรั่วไหลสำคัญที่คนใช้ Agent ควรรู้ นั่นคือ Tool Schema หรือโครงสร้างคำอธิบายเครื่องมือ เพียงแค่ส่งคำอธิบายของเครื่องมือกว่า 100 ตัว ว่าแต่ละตัวทำอะไรและรับค่าแบบไหนเข้าไปในทุกเซสชัน ก็กินพื้นที่ไปแล้ว 50,000 ถึง 70,000 โทเคนตั้งแต่ยังไม่ได้เริ่มทำงาน และต้องส่งซ้ำไปทุกๆ รอบการคุย ยิ่งเป็นเครื่องมือจากภายนอกยิ่งหนัก เช่น ชุดโปรแกรมสำนักงานเจ้าหนึ่งที่รวมเครื่องมือไว้ 49 ตัวในชุดเดียว ต้องเสียโทเคนไปราว 22,000 โทเคนเพียงแค่ค่าส่งคำอธิบายการทำงาน

ทางแก้ของ Uber คือ ปรับให้ Agent เรียกใช้เครื่องมือผ่านการรันสคริปต์ แทนที่จะให้โมเดลมานั่งคุยโต้ตอบกับเครื่องมือทีละรอบ แค่ดึงข้อมูลบรรทัดเดียวก็ช่วยลดโทเคนจาก 903 เหลือเพียง 402 โทเคนต่อครั้ง หรือลดลงไปเกินครึ่ง และสำหรับงานที่ต้องทำซ้ำหลายรอบ สามารถประหยัดโทเคนได้มากกว่า 90% เพราะจากที่โมเดลต้องคุยโต้ตอบหลายรอบ ก็รวบเหลือเพียงการรันสคริปต์ครั้งเดียว

แล้วโมเดลเปิดมีราคาถูกกว่าแค่ไหน?

จดหมายข่าวฉบับเดียวกันได้สรุปจากข้อมูลราคาที่มีว่า โมเดลเปิดมีราคาถูกกว่าโมเดลตัวท็อปอยู่ราว 2 ถึง 20 เท่า ซึ่งตัวเลขจากการใช้งานจริงของ Uber ก็อยู่ในเกณฑ์นี้เช่นกัน โดยโมเดลเปิดที่แพงที่สุดในชุดทดสอบตรวจโค้ด มีต้นทุนอยู่ที่ 0.28 ดอลลาร์ต่อการตรวจหนึ่งครั้ง เมื่อเทียบกับโมเดลปิดที่ Uber เลือกใช้จริงที่ 0.47 ดอลลาร์ และโมเดลปิดตัวท็อปที่แพงที่สุดซึ่งพุ่งไปถึง 2.42 ดอลลาร์

แต่ราคาต่อครั้งเป็นเพียงปัจจัยด้านเดียว เพราะอีกด้านที่ต้องดูควบคู่กันคือประสิทธิภาพ โดยชุดทดสอบข้างต้นระบุว่า โมเดลเปิดรุ่นประหยัดได้คะแนนความแม่นยำต่ำกว่าโมเดลปิดที่ Uber เลือกใช้อยู่ นี่จึงเป็นเหตุผลว่าทำไมเราต้องวัดผลก่อนเสมอ เพราะสำหรับงานตรวจโค้ด Uber มองว่าความแม่นยำที่ได้เพิ่มขึ้นมานั้นคุ้มค่ากับเงินส่วนต่างที่ต้องจ่าย แต่สำหรับงานประเภทอื่น คำตอบก็อาจจะออกมาตรงกันข้ามได้เช่นกัน

ข้อมูลนี้ยังสอดคล้องกับรายงานของทีมวิศวกรจาก Databricks บริษัทแพลตฟอร์มข้อมูลชั้นนำ ที่ได้ไปสัมภาษณ์วิศวกรจาก Stripe, Coinbase, Uber และ Ramp เพื่อค้นหาว่าวิธีไหนที่ช่วยลดบิล AI ได้จริง ผลสรุปเรียงตามประสิทธิภาพพบว่า การหันมาใช้โมเดลเปิดช่วยประหยัดเงินได้มากที่สุดเป็นอันดับหนึ่ง รองลงมาคือการทำ Model Routing ส่วนการตั้งเพดานงบประมาณและการตัดลดประวัติบทสนทนาช่วยได้บ้าง แต่ผลลัพธ์ยังห่างจากสองวิธีแรกมาก (ทั้งนี้ Databricks ให้ข้อสรุปเป็นภาพรวม ไม่ได้เปิดเผยตัวเลขแยกเป็นรายบริษัท)

นอกจากนี้ ยังมีสัญญาณในตลาดที่ชี้ไปในทิศทางเดียวกัน ข้อมูลจาก Ramp AI Index ดัชนีวัดการใช้จ่ายด้าน AI ของ Ramp ระบุว่า ในเดือนสิงหาคม ค่าใช้จ่ายด้าน AI ของกลุ่มธุรกิจ 1% แรกที่ใช้จ่ายด้าน AI สูงที่สุด ลดลงจากเดือนก่อนหน้าถึง 10% เหลืออยู่ที่ 7,200 ดอลลาร์ต่อพนักงานหนึ่งคนต่อเดือน โดยผู้เขียนจดหมายข่าวฉบับเดียวกันตั้งข้อสังเกตว่า ตัวเลขที่ลดลงไม่ได้เกิดจากการใช้โทเคนน้อยลง แต่เกิดจากการใช้จ่ายอย่างชาญฉลาดขึ้น (ซึ่งผู้เขียนระบุชัดเจนว่านี่เป็นการคาดเดาส่วนตัว ไม่ใช่ข้อมูลทางการที่ยืนยันแล้ว)

แนวทางนำไปปรับใช้จริง แยกตามขนาดทีม

สำหรับผู้ใช้งานทั่วไปหรือทีมขนาดเล็กที่จ่ายค่าบริการตามการใช้งานจริงผ่าน API: เริ่มนำ 3 สิ่งที่ Uber ทำไปปรับใช้ได้ทันทีโดยไม่ต้องมีทีมวิศวกร

• ปรับ Reasoning Effort ให้เป็นระดับกลางสำหรับงานทั่วไปในชีวิตประจำวัน แล้วค่อยปรับเพิ่มขึ้นเฉพาะงานที่รู้แน่ชัดว่ายากและซับซ้อน
• ตั้งค่าให้ตัดทอนประวัติการสนทนาให้เร็วขึ้น อย่ารอจนเต็มขีดจำกัด เพราะทุกรอบการตอบ คุณต้องเสียค่าใช้จ่ายกับประวัติทั้งหมดซ้ำ
• ส่งงานเบาๆ เช่น การสรุปเนื้อหา การจัดหมวดหมู่ หรือการร่างข้อความ ไปให้โมเดลราคาถูกหรือโมเดลเปิดทำ ส่วนโมเดลราคาแพงเก็บไว้ใช้กับงานที่ความผิดพลาดจะสร้างความเสียหายหนัก

สำหรับทีมพัฒนาที่มีปริมาณการใช้งานจริง: ก่อนตัดสินใจเปลี่ยนหรือย้ายไปใช้โมเดลใดๆ ให้สร้างชุดทดสอบจากเนื้องานจริงของทีมสัก 20 ถึง 50 ตัวอย่าง โดยเลือกงานที่รู้อยู่แล้วว่าผลลัพธ์แบบไหนดีและถูกต้อง จากนั้นนำโมเดลใหม่ที่เล็งไว้มารันเทียบผลกับโมเดลเดิม เพราะ Uber เริ่มจากชุดทดสอบของตัวเอง และ AT&T ก็รู้ว่าคุณภาพลดลงเท่าไรเพราะวัดผลจริง

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

---

ที่มา:

• บทความ The Pulse: tech companies move to open AI models จาก The Pragmatic Engineer
• บทความ Running a Software Factory Efficiently at Uber Scale จาก Uber