ทำไมโมเดล AI ที่มีความสามารถสูงสุดจึงไม่ใช่ตัวเลือกที่เหมาะสมสำหรับแอปของคุณ

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

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

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

ขนาดที่ใหญ่กว่าไม่ใช่เสมอไปว่าดีกว่า

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

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

โมเดลที่เล็กลงและเชี่ยวชาญจัดการงานที่มุ่งเน้นด้วยความแม่นยำที่น่าประทับใจ:

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

ช่องว่างระหว่างโมเดลเหล่านี้และโมเดลแนวหน้าจะลดลงอย่างมากเมื่องานมีความแคบและคำสั่งถูกออกแบบมาอย่างดี

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

ราคา API สำหรับโมเดลแนวหน้าสามารถสูงกว่าโมเดลที่เบากว่า 10 ถึง 30 เท่าต่อโทเค็น นี่คือช่องว่างที่ดูเหมือนจะไม่สำคัญจนกว่าคุณจะสร้างแบบจำลองที่มีขนาดใหญ่

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

คุณลักษณะเดียวกัน แต่มีเรื่องราวที่แตกต่างกันมาก

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

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

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

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

กฎที่ต้องจำ: หากผู้ใช้เห็นไอคอนการโหลด แต่ละวินาทีที่เพิ่มขึ้นจะลดความไว้วางใจ

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

ตัวแปรการออกแบบคำสั่งที่เปลี่ยนแปลงทุกอย่าง

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

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

เครื่องมือที่น่าสนใจที่นี่:

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

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

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

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

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

ที่ไหนที่จะเริ่มต้นด้วยการปรับแต่ง:

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

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

ความปลอดภัยและที่อยู่อาศัยของข้อมูลไม่ใช่เรื่องรอง

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

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

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

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

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

สิ่งนี้คือกระบวนการที่ทำงาน:

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

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

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

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

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

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

ยังคงใช้โมเดลที่เบากว่าเมื่อ:

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

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

สรุป

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

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

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