เลือกโมเดล AI ให้เหมาะสม: สมดุลระหว่างต้นทุนกับประสิทธิภาพ

การเลือกโมเดลที่ทรงพลังที่สุดให้ความรู้สึกสบายใจอยู่ไม่น้อย เมื่อคุณสร้างผลิตภัณฑ์ที่ใช้ AI การเลือกโมเดลที่ทรงพลังที่สุดที่มีอยู่ก็ดูเป็นการตัดสินใจที่มีความรับผิดชอบและแทบจะเป็นเรื่องสมเหตุสมผล GPT-4o, Claude Opus, Gemini Ultra ล้วนเป็นเทคโนโลยีที่น่าทึ่ง และไม่มีใครถูกไล่ออกเพียงเพราะเลือกเครื่องมือที่ฉลาดที่สุดในบรรดาตัวเลือก

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

ประเด็นคือ “มีความสามารถสูงสุด” กับ “เหมาะสมที่สุด” เป็นเกณฑ์คนละอย่างกันมาก ผู้ให้บริการ พัฒนาแอป AI เลือกโมเดลจากผลการประเมิน ไม่ใช่อันดับในตารางจัดอันดับ

ใหญ่กว่าไม่ได้แปลว่าดีกว่าโดยอัตโนมัติ

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

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

โมเดลขนาดเล็กที่เชี่ยวชาญเฉพาะทางจัดการงานที่มีขอบเขตชัดเจนได้อย่างแม่นยำน่าประทับใจ:

• GPT-4o mini รองรับงานภาษาส่วนใหญ่ด้วยต้นทุนประมาณหนึ่งในสิบห้าของ GPT-4o
• Claude Haiku ถูกออกแบบให้รวดเร็วและมีประสิทธิภาพสำหรับงานที่มีโครงสร้างและปริมาณมาก
• Mistral 7B และ Llama 3.1 8B เป็นตัวเลือกโอเพนซอร์สที่ทำงานรวดเร็วและเหมาะกับการปรับแต่งเพิ่มเติม

ช่องว่างระหว่างโมเดลเหล่านี้กับโมเดลแนวหน้าลดลงอย่างมากเมื่องานมีขอบเขตจำกัดและออกแบบพรอมป์ต์มาอย่างดี

การคำนวณต้นทุนที่ไม่มีใครพูดถึงในการประชุมวางแผน

ราคา API ต่อโทเค็นของโมเดลแนวหน้าอาจสูงเป็น 10–30 เท่าของโมเดลที่เบากว่า ความแตกต่างนี้อาจดูเป็นเรื่องนามธรรม จนกว่าจะลองคำนวณเมื่อใช้งานในปริมาณมาก

สมมติว่าแอปของคุณเรียก API เดือนละ 500,000 ครั้ง:

ฟีเจอร์เดียวกัน แต่อัตรากำไรต่างกันมาก

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

ความหน่วงเป็นปัญหาด้านประสบการณ์ผู้ใช้

อาหารจานด่วนมีอยู่ด้วยเหตุผลบางอย่าง คนเราไม่ได้ต้องการอาหารห้าคอร์สเสมอไป บางครั้งก็ต้องการคำตอบทันที

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

หลักปฏิบัติง่าย ๆ คือ หากผู้ใช้เห็นสัญลักษณ์กำลังโหลด ทุกวินาทีที่ต้องรอเพิ่มจะลดความเชื่อมั่น

Haiku, Mistral และ Llama 3.1 8B ทำงานเร็วกว่าอย่างเห็นได้ชัด บางครั้งเร็วกว่า 3–5 เท่าภายใต้ภาระงานที่ใกล้เคียงกัน สำหรับฟีเจอร์ที่ผู้ใช้ใช้งานโดยตรงและให้ความสำคัญกับความเร็วที่รับรู้ เรื่องนี้ไม่ใช่ข้อพิจารณาเล็กน้อย แต่เป็นการตัดสินใจเกี่ยวกับผลิตภัณฑ์

ตัวแปรด้านการออกแบบพรอมป์ต์ที่เปลี่ยนทุกอย่าง

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

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

เครื่องมือที่ควรรู้จักมีดังนี้:

• LangChain และ DSPy สำหรับประกอบและปรับปรุงกระบวนการทำงานของพรอมป์ต์
• Guidance สำหรับการสร้างผลลัพธ์ภายใต้ข้อจำกัดและผลลัพธ์ที่มีโครงสร้าง
• PromptFoo สำหรับประเมินพรอมป์ต์อย่างเป็นระบบในโมเดลหลายตัว

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

การปรับแต่งโมเดลเปลี่ยนสมการ

การเปรียบเทียบโมเดลแนวหน้าแบบทั่วไปกับโมเดลโอเพนซอร์สขนาดเล็กจะเปลี่ยนไปมากเมื่อมีการปรับแต่งโมเดลเข้ามา โมเดล Llama 3.1 8B ที่ปรับแต่งด้วยข้อมูลเฉพาะสาขาของคุณ ทั้งคำศัพท์ กรณีขอบ และรูปแบบผลลัพธ์ที่ต้องการ อาจทำผลงานได้ดีกว่า GPT-4o ในงานเฉพาะนั้น

นี่ไม่ใช่เพียงข้อสมมติ บริษัทด้านสาธารณสุข เทคโนโลยีกฎหมาย และอีคอมเมิร์ซได้แสดงให้เห็นเช่นนี้ครั้งแล้วครั้งเล่า

คุณอาจเริ่มต้นการปรับแต่งโมเดลได้จาก:

• Hugging Face สำหรับโฮสต์โมเดลโอเพนซอร์ส ชุดข้อมูล และโครงสร้างพื้นฐานสำหรับฝึกโมเดล
• Together AI สำหรับการปรับแต่งโมเดลเปิดยอดนิยมอย่างรวดเร็วและมีต้นทุนที่เข้าถึงได้
• Replicate สำหรับนำโมเดลที่ปรับเองไปใช้งานโดยไม่ต้องจัดการโครงสร้างพื้นฐาน GPU ของตนเอง

การปรับแต่งโมเดลต้องลงทุนล่วงหน้าทั้งการคัดสรรและเตรียมข้อมูล เวลาประมวลผล และงานประเมิน แต่สำหรับงานเฉพาะสาขาที่มีปริมาณมาก ความคุ้มค่าทางเศรษฐศาสตร์มักดีขึ้นอย่างมาก

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

แอปพลิเคชันบางประเภทไม่สามารถส่งข้อมูลไปยัง API ของบุคคลที่สามได้เลย เช่น:

• แพลตฟอร์มสาธารณสุขที่ดำเนินงานภายใต้ HIPAA
• เครื่องมือทางการเงินที่จัดการข้อมูลระบุตัวบุคคลหรือข้อมูลธุรกรรมที่อยู่ภายใต้กฎระเบียบ
• ซอฟต์แวร์องค์กรที่มีข้อกำหนดเรื่องสถานที่จัดเก็บข้อมูลอย่างเข้มงวด

สภาพแวดล้อมเหล่านี้มีข้อจำกัดที่ API ของโมเดลแนวหน้าใด ๆ ก็ไม่อาจแก้ได้ ไม่ว่าจะมีความสามารถมากเพียงใด โมเดลที่โฮสต์บนโครงสร้างพื้นฐานของตนเองไม่ว่าจะติดตั้งภายในองค์กรหรือบนคลาวด์ส่วนตัว จึงเป็นทางเดียวที่จะเดินต่อไปได้ นั่นหมายถึงการใช้โมเดลโอเพนซอร์สอย่าง Llama 3, Mistral หรือ Phi-3 บนโครงสร้างพื้นฐานของคุณเอง โมเดลแนวหน้าที่คุณไม่สามารถนำไปใช้จริงได้อย่างถูกกฎหมายย่อมไม่ใช่ตัวเลือกที่เหมาะสม เท่านั้นเอง

ขั้นตอนการประเมินที่ทีมมักข้ามไป

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

กระบวนการที่ใช้ได้ผลมีดังนี้:

1. สร้างชุดประเมินที่มีอินพุตตัวแทน 100–200 รายการ พร้อมผลลัพธ์ที่คาดหวัง
2. ให้อินพุตเหล่านั้นผ่านโมเดลตัวเลือกสองหรือสามตัวภายใต้สภาวะการใช้งานที่สมจริง
3. ให้คะแนนตามเกณฑ์จริงของคุณ ได้แก่ ความแม่นยำ การทำตามรูปแบบ น้ำเสียง ความหน่วง และต้นทุนต่อการเรียกใช้
4. ตัดสินใจจากข้อมูล ไม่ใช่ความรู้สึกหรืออันดับในตารางจัดอันดับ

เครื่องมืออย่าง Braintrust, PromptFoo และ Weights & Biases Prompts ช่วยให้ประเมินอย่างเป็นระบบได้โดยไม่ต้องมีพื้นฐานงานวิจัย ใช้เวลาเตรียมเพียงไม่กี่ชั่วโมง สิ่งที่ได้กลับมาคือไม่ต้องใช้โมเดลผิดตัวไปอีกหกเดือน

เมื่อใดโมเดลแนวหน้าจึงเป็นตัวเลือกที่เหมาะสมจริง ๆ

เพื่อความเป็นธรรม มีงานที่โมเดลแนวหน้าคุ้มค่ากับราคาของมันจริง ๆ

ใช้โมเดลแนวหน้าเมื่อ:

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

ใช้โมเดลที่เบากว่าต่อไปเมื่อ:

• งานมีขอบเขตชัดเจนและมีลักษณะซ้ำ ๆ
• ความเร็วและต้นทุนมีความสำคัญในปริมาณงานที่คุณกำลังดำเนินการ
• คุณสามารถลงทุนด้านการออกแบบพรอมป์ต์หรือปรับแต่งโมเดล
• ข้อกำหนดเรื่องสถานที่จัดเก็บข้อมูลหรือการปฏิบัติตามกฎระเบียบทำให้ใช้ API ของบุคคลที่สามไม่ได้

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

สรุป

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

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

ทีมที่ส่งมอบผลิตภัณฑ์ AI ที่ยอดเยี่ยมไม่ได้จำเป็นต้องใช้โมเดลที่ทรงพลังที่สุด แต่ใช้โมเดลที่เหมาะสมที่สุด