Cái bẫy một mô hình
Nhà cung cấp trí tuệ nhân tạo lớn nào cũng muốn bạn tin rằng mô hình đầu bảng của họ là câu trả lời đúng cho mọi câu hỏi. Niềm tin ấy tiện lợi cho họ về mặt buôn bán và sai cho bạn về mặt kỹ thuật.
Một mô hình tỏa sáng ở suy luận pháp lý với ngữ cảnh dài không phải mô hình hợp để viết một dòng chú thích mười chữ. Một mô hình có thị giác thuộc hàng tiên tiến là thừa thãi — và hẳn quá đắt — cho một tác vụ theo lô định dạng lại JSON có cấu trúc. Một mô hình có giá được chỉnh cho thông lượng có thể là lựa chọn tệ nhất có thể nghĩ ra khi bạn cần câu trả lời trong hai giây.
Khi bạn dựng trên một mô hình duy nhất, bạn không chọn công cụ tốt nhất. Bạn chọn công cụ tốt nhất bên trong một ràng buộc do người đặt ra. Theo thời gian, ràng buộc ấy dồn lại: trả quá cho việc đơn giản, hụt hơi ở việc phức tạp, và khi nhà cung cấp kia gặp sự cố hay tăng giá, cả sản phẩm của bạn đứng lại.
Năng lực, chứ không phải tên gọi
Trừu tượng hữu ích không phải «mô hình nào» mà là «yêu cầu này cần những năng lực gì». Câu hỏi ấy có một câu trả lời chính xác.
Một tin nhắn trò chuyện kèm ảnh chụp màn hình cần thị giác. Một bước luồng công việc gọi API bên ngoài cần công cụ. Một trợ lý mã nguồn phải tự kiểm đầu ra của chính nó thì cần chạy mã. Một đường tóm tắt ban đêm không cần nhanh thì dùng được giá theo lô; một trợ lý bên trong sản phẩm mà có người đang đợi thì không.
Khi bạn liệt kê các đòi hỏi về năng lực trước, việc chọn mô hình thành một bài toán lọc rồi sắp. Cho một tập đòi hỏi — chẳng hạn văn bản, thị giác và đầu ra có cấu trúc — bạn tìm mọi mô hình hỗ trợ cả ba, rồi sắp chúng theo chất lượng và giá cho ngữ cảnh yêu cầu hiện thời. Thứ tự ấy có thể đổi từ yêu cầu này sang yêu cầu khác, tùy người ta đang làm gì và tình hình tiền nong ra sao.
Đó đúng là điều đường phân luồng của ToRun làm. Chế độ (Trò chuyện, Mã nguồn, Ảnh, Nghiên cứu và các chế độ khác) ánh xạ sang một tập năng lực. Tập ấy lọc danh mục mô hình. Thứ tự theo giá và chất lượng chọn ra người thắng. Kết quả là bạn có thể dùng DeepSeek cho việc rút trích có cấu trúc số lượng lớn, Claude hay các mô hình hạng GPT-4 cho suy luận tinh tế, Google Gemini cho công việc tài liệu ngữ cảnh dài, và một mô hình ảnh chuyên biệt cho việc sinh tạo — tất cả từ cùng một mặt sản phẩm, mà không phải tự viết logic điều phối.
Dự phòng không phải thứ có thì hay
Sự cố của nhà cung cấp không phải những trường hợp hiếm hoi bên rìa. Chúng xảy ra khắp ngành vài lần mỗi tháng. Nếu sản phẩm của bạn phụ thuộc một nhà cung cấp duy nhất mà API của họ xuống cấp, sản phẩm của bạn xuống cấp theo.
Một chuỗi dự phòng là mức tối thiểu về vận hành: khi mô hình chính trả về lỗi nhất thời cho một yêu cầu, nền tảng thử lại trên mô hình đủ điều kiện tốt kế tiếp. Điều ấy giả định tầng phân luồng đã biết những mô hình nào đủ điều kiện — và đó chính là thứ phân luồng theo năng lực đem lại.
Dự phòng còn một lợi ích ít lộ hơn: nó giữ cho cách tính phí của bạn dễ đoán. Nếu mô hình lựa chọn đầu tiên tạm thời vượt một hạn mức dùng, việc rẽ sang mô hình đủ điều kiện kế tiếp giữ chi phí trong khoảng mà không phải trưng ra một thông báo lỗi.
Kết luận thực tế
Khi cân nhắc các nền tảng trí tuệ nhân tạo, hãy hỏi hai điều: nó chọn mô hình cho mỗi yêu cầu ra sao, và chuyện gì xảy ra khi mô hình ấy không dùng được hay hóa quá đắt?
Nếu câu trả lời cho một trong hai là «nó luôn lấy mô hình X», thì đó là mùi của kiến trúc. Những mô hình dùng được hôm nay sẽ không phải những mô hình tốt nhất nửa năm sau. Nhà cung cấp mới xuất hiện. Giá dịch chuyển. Ranh giới năng lực đổi chỗ. Một kiến trúc coi việc chọn mô hình là bài toán phân luồng — chứ không phải một quyết định cấu hình — thì già đi đẹp hơn, tốn ít hơn theo thời gian, và xuống cấp thanh thoát hơn dưới sức ép.
Một mô hình là điểm khởi đầu. Tầng phân luồng mới là nền móng thật sự.