Chọn mô hình AI phù hợp: cân bằng chi phí và hiệu năng

Việc chọn mô hình mạnh nhất mang lại cảm giác yên tâm nhất định. Khi xây dựng một sản phẩm ứng dụng trí tuệ nhân tạo, lựa chọn mô hình mạnh nhất hiện có có vẻ là quyết định có trách nhiệm, gần như hiển nhiên. GPT-4o. Claude Opus. Gemini Ultra. Đó đều là những công nghệ ấn tượng, và chưa ai bị sa thải vì chọn công cụ thông minh nhất trong số các lựa chọn.

Nhưng có một điều cần cân nhắc. Dự án phình to. Chi phí tăng vọt. Độ trễ dần xuất hiện. Đến khoảng tháng thứ ba, nhóm bắt đầu đặt những câu hỏi khó trả lời: tại sao một tính năng tự động hoàn thành đơn giản lại đốt tín dụng API như một công ty khởi nghiệp dùng vốn đầu tư mạo hiểm mà không phải chịu trách nhiệm về hiệu quả chi tiêu?

Vấn đề là: “có năng lực cao nhất” và “phù hợp nhất” là hai tiêu chuẩn rất khác nhau. Các nhà cung cấp dịch vụ phát triển ứng dụng AI lựa chọn mô hình dựa trên đánh giá thực tế, chứ không dựa vào vị trí trên bảng xếp hạng.

Lớn hơn không mặc nhiên tốt hơn

Một mô hình hàng đầu hoạt động xuất sắc trong điều kiện lý tưởng, nhưng chi phí vận hành cao, xử lý đầu vào không hoàn hảo kém và thừa năng lực so với những nhiệm vụ đơn giản.

GPT-4o có thể làm thơ, suy luận về hợp đồng pháp lý, gỡ lỗi mã và giải thích hiện tượng rối lượng tử cho một đứa trẻ mười tuổi, đôi khi ngay trong cùng một câu trả lời. Điều đó thực sự ấn tượng. Nhưng nếu ứng dụng của bạn chỉ tóm tắt yêu cầu hỗ trợ khách hàng hoặc trích xuất dữ liệu có cấu trúc từ hóa đơn, bạn đang trả tiền cho những năng lực không dùng đến.

Các mô hình nhỏ hơn, chuyên biệt có thể xử lý nhiệm vụ có phạm vi cụ thể với độ chính xác ấn tượng:

• GPT-4o mini xử lý phần lớn nhiệm vụ ngôn ngữ với chi phí xấp xỉ một phần mười lăm GPT-4o
• Claude Haiku được thiết kế để xử lý nhanh và hiệu quả các khối lượng lớn công việc có cấu trúc
• Mistral 7B và Llama 3.1 8B là những lựa chọn mã nguồn mở chạy nhanh và phù hợp để tinh chỉnh

Khoảng cách giữa chúng và các mô hình hàng đầu thu hẹp đáng kể khi nhiệm vụ được giới hạn rõ ràng và câu lệnh được thiết kế tốt.

Bài toán chi phí ít ai nhắc đến trong các cuộc họp lập kế hoạch

Giá API tính trên mỗi token của mô hình hàng đầu có thể cao gấp 10–30 lần các mô hình nhẹ hơn. Chênh lệch này có vẻ trừu tượng cho đến khi bạn tính toán ở quy mô lớn.

Giả sử ứng dụng của bạn thực hiện 500.000 lệnh gọi API mỗi tháng:

Cùng một tính năng, nhưng biên lợi nhuận rất khác nhau.

Một số nhóm sử dụng kiến trúc kết hợp: định tuyến nhiệm vụ phân loại đơn giản sang mô hình nhẹ, dành mô hình nặng hơn cho các bước tạo nội dung hoặc suy luận phức tạp. Các công ty như Martian và RouteLLM đã xây dựng công cụ dành riêng cho việc định tuyến mô hình này. Đây không phải công việc kỹ thuật hào nhoáng, nhưng lại khiến các giám đốc tài chính yên tâm hơn hẳn.

Độ trễ là vấn đề về trải nghiệm người dùng

Thức ăn nhanh tồn tại là có lý do. Không phải lúc nào mọi người cũng muốn một bữa ăn năm món. Đôi khi họ chỉ muốn có câu trả lời ngay.

Các mô hình hàng đầu chậm hơn. Không phải lúc nào cũng chậm hơn nhiều, nhưng đủ để ảnh hưởng đến ứng dụng thời gian thực. Nếu người dùng chờ phản hồi AI trong giao diện hội thoại, giao diện chat hoặc trợ lý lập trình trực tiếp, độ trễ phản hồi sẽ ảnh hưởng trực tiếp đến cảm nhận của họ về sản phẩm. Một mô hình cần 4–6 giây để trả lời bắt đầu có vẻ thiếu tin cậy, ngay cả khi đầu ra tốt hơn về mặt kỹ thuật.

Quy tắc kinh nghiệm: khi người dùng nhìn thấy biểu tượng đang tải, mỗi giây chờ thêm đều làm giảm niềm tin.

Haiku, Mistral và Llama 3.1 8B chạy nhanh hơn đáng kể, đôi khi gấp 3–5 lần, trong điều kiện tải tương tự. Với các tính năng người dùng trực tiếp sử dụng, khi tốc độ cảm nhận là quan trọng, đây không phải yếu tố nhỏ. Đó là quyết định về sản phẩm.

Biến số thiết kế câu lệnh có thể thay đổi tất cả

Có một điều thường bị bỏ qua trong các cuộc thảo luận so sánh mô hình: một câu lệnh được thiết kế tốt cho mô hình nhỏ thường vượt qua câu lệnh sơ sài cho mô hình hàng đầu.

Chất lượng đầu ra là kết quả của cả năng lực mô hình VÀ chất lượng câu lệnh. Khi nhóm đầu tư vào thiết kế câu lệnh — hướng dẫn rõ ràng, định dạng đầu ra có cấu trúc, một vài ví dụ minh họa và các ràng buộc cụ thể — mô hình nhỏ có thể vượt xa giới hạn năng lực bề ngoài của nó.

Một số công cụ hữu ích cần biết:

• LangChain và DSPy để xây dựng và tối ưu hóa quy trình xử lý câu lệnh
• Guidance để tạo đầu ra theo các ràng buộc và tạo đầu ra có cấu trúc
• PromptFoo để đánh giá câu lệnh một cách có hệ thống trên nhiều mô hình

Một số tính năng AI ấn tượng nhất đang được triển khai thực tế hiện nay sử dụng những mô hình không lọt vào nhóm năm vị trí đầu của bất kỳ bảng xếp hạng năng lực nào. Chúng chỉ đơn giản là sử dụng những câu lệnh thực sự tốt.

Tinh chỉnh làm thay đổi bài toán

Sự so sánh giữa mô hình hàng đầu đa dụng và mô hình mã nguồn mở nhỏ hơn sẽ rất khác khi có tinh chỉnh. Một mô hình Llama 3.1 8B được tinh chỉnh bằng dữ liệu chuyên ngành của bạn — thuật ngữ, trường hợp biên và định dạng đầu ra bạn mong muốn — có thể vượt qua GPT-4o trong chính nhiệm vụ cụ thể đó.

Đây không phải giả thuyết. Các công ty trong lĩnh vực y tế, công nghệ pháp lý và thương mại điện tử đã chứng minh điều này nhiều lần.

Bạn có thể bắt đầu tinh chỉnh với:

• Hugging Face cung cấp dịch vụ lưu trữ mô hình mã nguồn mở, tập dữ liệu và hạ tầng huấn luyện
• Together AI hỗ trợ các lượt tinh chỉnh nhanh, chi phí hợp lý cho những mô hình mở phổ biến
• Replicate giúp triển khai mô hình tùy chỉnh mà không phải tự quản lý hạ tầng GPU

Tinh chỉnh đòi hỏi đầu tư ban đầu: tuyển chọn và chuẩn bị dữ liệu, thời gian tính toán và công sức đánh giá. Nhưng với nhiệm vụ chuyên ngành có khối lượng lớn, hiệu quả kinh tế thường trở nên thuận lợi hơn đáng kể.

Không thể để bảo mật và yêu cầu về nơi lưu trữ dữ liệu đến cuối mới tính

Một số ứng dụng hoàn toàn không thể gửi dữ liệu đến API bên thứ ba. Ví dụ:

• Nền tảng y tế hoạt động theo HIPAA
• Công cụ tài chính xử lý thông tin định danh cá nhân hoặc dữ liệu giao dịch chịu sự quản lý theo quy định
• Phần mềm doanh nghiệp có yêu cầu nghiêm ngặt về nơi lưu trữ dữ liệu

Các môi trường này có những ràng buộc mà API của bất kỳ mô hình hàng đầu nào cũng không thể khắc phục, bất kể mô hình có năng lực đến đâu. Mô hình tự triển khai, dù tại chỗ hay trên đám mây riêng, là con đường duy nhất. Điều đó có nghĩa là chạy các mô hình mã nguồn mở như Llama 3, Mistral hoặc Phi-3 trên hạ tầng của chính bạn. Một mô hình hàng đầu mà bạn không được phép sử dụng hợp pháp trong môi trường thực tế thì không phải lựa chọn đúng, đơn giản là vậy.

Bước đánh giá các nhóm thường bỏ qua

Phần lớn các nhóm chọn mô hình theo giả định rằng đắt nhất là tốt nhất mà không kiểm chứng. Điều họ nên làm là đánh giá có cấu trúc trên những mẫu đại diện cho tình huống sử dụng thực tế.

Quy trình sau có thể áp dụng:

1. Xây dựng tập đánh giá gồm 100–200 đầu vào đại diện cùng đầu ra mong đợi
2. Cho hai hoặc ba mô hình ứng viên xử lý các đầu vào đó trong điều kiện thực tế
3. Chấm theo tiêu chí thực tế: độ chính xác, tuân thủ định dạng, giọng điệu, độ trễ và chi phí mỗi lệnh gọi
4. Quyết định dựa trên dữ liệu, thay vì cảm tính hoặc vị trí trên bảng xếp hạng

Các công cụ như Braintrust, PromptFoo và Weights & Biases Prompts giúp bạn thực hiện đánh giá có hệ thống mà không cần nền tảng nghiên cứu. Việc thiết lập chỉ mất vài giờ. Đổi lại, bạn tránh được việc dùng sai mô hình suốt sáu tháng.

Khi nào mô hình hàng đầu thực sự là lựa chọn đúng

Công bằng mà nói, có những nhiệm vụ mà mô hình hàng đầu thực sự xứng đáng với mức giá.

Hãy dùng mô hình hàng đầu khi:

• Nhiệm vụ đòi hỏi suy luận phức tạp qua nhiều bước mà không có khuôn mẫu rõ ràng
• Sự biến động về chất lượng đầu ra gây tổn thất lớn và khối lượng xử lý tương đối thấp
• Bạn cần kiến thức rộng về thế giới hoặc khả năng phán đoán tinh tế mà không thể bù đắp bằng cách điều chỉnh câu lệnh
• Bạn đang làm nguyên mẫu và chưa xác định rõ ranh giới nhiệm vụ

Hãy tiếp tục dùng mô hình nhẹ hơn khi:

• Nhiệm vụ đã được xác định rõ và có tính lặp lại
• Tốc độ và chi phí quan trọng ở khối lượng bạn đang vận hành
• Bạn có thể đầu tư vào thiết kế câu lệnh hoặc tinh chỉnh
• Yêu cầu về nơi lưu trữ dữ liệu hoặc tuân thủ quy định loại trừ API bên thứ ba

Mục đích không phải là tránh các mô hình mạnh. Mục đích là lựa chọn có chủ đích, dựa trên bằng chứng, thay vì mặc định chọn cái tên nổi bật nhất trên bảng xếp hạng chỉ vì cảm thấy đó là lựa chọn an toàn.

Tổng kết

Chọn mô hình AI cho ứng dụng không nên là cuộc đua danh tiếng. Mô hình có năng lực cao nhất trên giấy không phải lúc nào, và thậm chí thường không phải, là mô hình đúng cho vấn đề của bạn.

Hãy chọn mô hình phù hợp với nhiệm vụ. Đánh giá bằng dữ liệu thực tế. Tính đến độ trễ, chi phí, yêu cầu bảo mật và khả năng đầu tư vào thiết kế câu lệnh hoặc tinh chỉnh của nhóm. Những quyết định tốt nhất về sản phẩm AI dựa trên các yếu tố cụ thể đó, chứ không phải công ty nào công bố những con số hào nhoáng nhất trong quý trước.

Các nhóm tạo ra sản phẩm AI xuất sắc không nhất thiết dùng mô hình mạnh nhất. Họ dùng mô hình phù hợp nhất.