Khi xây dựng ứng dụng dùng mô hình ngôn ngữ lớn, nhiều nhóm thường bắt đầu bằng cách chọn mô hình mạnh nhất có thể gọi được. Cách này tiện cho thử nghiệm nhanh, nhưng khi đưa vào sản phẩm thật, chi phí và độ trễ có thể tăng rất nhanh. Một chatbot nội bộ, hệ thống tóm tắt tài liệu hay công cụ phân loại email đều cần một câu hỏi thực tế: tác vụ này có thật sự cần mô hình lớn nhất không? Vấn đề không chỉ là giá mỗi lần gọi API. Độ trễ cao làm trải nghiệm người dùng kém đi, còn chi phí khó kiểm soát khiến sản phẩm khó mở rộng. Tối ưu ở đây không có nghĩa là dùng mô hình rẻ nhất, mà là dùng đúng mức năng lực cho từng bước trong pipeline. Một cách tiếp cận thực tế là chia tác vụ thành nhiều tầng: - Tầng đơn giản: dùng luật, regex, từ khóa hoặc mô hình nhỏ. Ví dụ: kiểm tra định dạng mã đơn hàng, phát hiện ngôn ngữ, lọc câu hỏi ngoài phạm vi. - Tầng trung bình: dùng mô hình nhỏ hơn để phân loại ý định, trích xuất trường thông tin, viết lại truy vấn tìm kiếm. - Tầng phức tạp: chỉ gọi mô hình lớn khi cần suy luận nhiều bước, tổng hợp nhiều nguồn hoặc trả lời có yêu cầu cao về diễn đạt. Ví dụ, với hệ thống hỗ trợ khách hàng, không nhất thiết mọi tin nhắn đều phải gửi thẳng tới LLM lớn. Nếu người dùng hỏi “đổi mật khẩu thế nào?”, hệ thống có thể tra cứu câu trả lời chuẩn trong tài liệu. Nếu người dùng mô tả một lỗi phức tạp gồm nhiều bước đã thử, khi đó gọi mô hình mạnh hơn để phân tích sẽ hợp lý hơn. Một số kỹ thuật nên áp dụng sớm: 1. Đặt ngân sách token cho từng loại tác vụ Prompt dài không phải lúc nào cũng tốt. Hãy đo số token đầu vào, đầu ra và đặt giới hạn phù hợp. Với tác vụ phân loại, yêu cầu mô hình trả về nhãn ngắn thay vì giải thích dài. Với tóm tắt, quy định rõ độ dài mong muốn. Cần tránh nhét toàn bộ lịch sử hội thoại hoặc toàn bộ tài liệu vào prompt nếu chỉ cần một phần nhỏ. 2. Dùng bộ định tuyến mô hình Model router là lớp quyết định nên dùng mô hình nào cho mỗi yêu cầu. Ban đầu có thể rất đơn giản: nếu câu hỏi thuộc nhóm FAQ thì dùng câu trả lời có sẵn; nếu cần trích xuất dữ liệu thì dùng mô hình nhỏ; nếu điểm tin cậy thấp thì chuyển sang mô hình lớn. Sau này có thể cải tiến bằng cách ghi log lỗi và điều chỉnh quy tắc định tuyến. 3. Cache những kết quả có khả năng lặp lại Nhiều ứng dụng có câu hỏi lặp đi lặp lại: chính sách hoàn tiền, hướng dẫn cài đặt, định nghĩa thuật ngữ. Cache theo truy vấn chuẩn hóa hoặc theo kết quả truy xuất tài liệu có thể giảm đáng kể số lần gọi mô hình. Tuy nhiên cần cẩn thận với dữ liệu cá nhân và những câu trả lời phụ thuộc ngữ cảnh người dùng. 4. Rút gọn ngữ cảnh trước khi gọi mô hình Trong RAG, đừng đưa quá nhiều đoạn tài liệu vào prompt chỉ vì “cho chắc”. Nên có bước xếp hạng lại, loại bỏ đoạn trùng lặp, cắt phần không liên quan và ưu tiên đoạn chứa thông tin trực tiếp. Ngữ cảnh ngắn hơn thường giúp giảm chi phí, giảm độ trễ và đôi khi còn tăng chất lượng vì mô hình ít bị nhiễu. 5. Theo dõi chi phí theo tính năng, không chỉ theo toàn hệ thống Nếu chỉ nhìn tổng chi phí mỗi ngày, rất khó biết phần nào đang lãng phí. Nên gắn metadata cho mỗi request: tính năng nào, loại người dùng nào, mô hình nào, số token đầu vào/đầu ra, thời gian phản hồi, kết quả có được người dùng chấp nhận không. Từ đó có thể phát hiện một tính năng ít giá trị nhưng tiêu tốn nhiều tài nguyên. Một nguyên tắc hữu ích: hãy coi mỗi lần gọi LLM là một quyết định kỹ thuật có chi phí, không phải một hàm tiện ích miễn phí. Trước khi thêm một lời gọi mô hình mới, nên hỏi: có cách đơn giản hơn không, có thể dùng mô hình nhỏ hơn không, có thể tái sử dụng kết quả trước đó không, và làm sao biết lời gọi này thật sự cải thiện trải nghiệm? Để bắt đầu, nhóm phát triển có thể làm một bảng nhỏ gồm các cột: tác vụ, mô hình đang dùng, độ dài prompt trung bình, độ trễ trung bình, chi phí tương đối, tỷ lệ lỗi, phương án thay thế. Chỉ cần nhìn bảng này, thường sẽ thấy ngay vài điểm tối ưu dễ làm: giảm prompt quá dài, cache câu hỏi phổ biến, hoặc chuyển một số tác vụ phân loại sang mô hình nhẹ hơn. LLM mạnh là công cụ rất hữu ích, nhưng sản phẩm tốt không phải lúc nào cũng là sản phẩm gọi mô hình lớn nhất ở mọi nơi. Sản phẩm tốt là sản phẩm biết dùng mô hình đúng lúc, đúng việc, đo được hiệu quả và kiểm soát được chi phí khi mở rộng.