Khi thử nghiệm một ứng dụng dùng mô hình ngôn ngữ lớn, nhiều nhóm thường tập trung vào việc “trả lời hay chưa”. Nhưng khi đưa vào sử dụng thật, hai câu hỏi khác xuất hiện rất nhanh: hệ thống có trả lời đủ nhanh không, và chi phí có tăng ngoài kiểm soát không? Đây không chỉ là vấn đề hạ tầng. Cách thiết kế prompt, luồng xử lý, bộ nhớ đệm và lựa chọn mô hình đều ảnh hưởng trực tiếp đến trải nghiệm người dùng cũng như ngân sách vận hành. 1. Đừng dùng mô hình lớn cho mọi việc Một lỗi phổ biến là đưa tất cả yêu cầu vào mô hình mạnh nhất. Trong thực tế, không phải tác vụ nào cũng cần khả năng suy luận phức tạp. Ví dụ: - Phân loại câu hỏi người dùng thuộc nhóm “bảo hành”, “thanh toán”, “kỹ thuật” có thể dùng mô hình nhỏ hơn hoặc thậm chí luật đơn giản. - Tóm tắt nội dung dài, phân tích nhiều điều kiện hoặc sinh câu trả lời có ngữ cảnh mới cần mô hình mạnh hơn. - Kiểm tra định dạng email, mã đơn hàng, số điện thoại không nên gọi LLM nếu có thể xử lý bằng regex hoặc code thông thường. Một kiến trúc thực tế là chia hệ thống thành nhiều tầng: tầng rẻ và nhanh xử lý trước, chỉ chuyển sang mô hình lớn khi cần thiết. 2. Giảm số token trước khi nghĩ đến tối ưu hạ tầng Với ứng dụng LLM, token là một đơn vị chi phí quan trọng. Prompt càng dài, ngữ cảnh càng dư thừa, chi phí và độ trễ càng tăng. Một số cách giảm token dễ áp dụng: - Viết system prompt ngắn gọn, chỉ giữ quy tắc thật sự cần. - Không nhét toàn bộ lịch sử hội thoại nếu chỉ vài lượt gần nhất là đủ. - Với RAG, chỉ đưa các đoạn tài liệu liên quan nhất thay vì nhiều đoạn “cho chắc”. - Yêu cầu đầu ra có cấu trúc rõ ràng, tránh để mô hình viết dài không cần thiết. Ví dụ, thay vì gửi 10 trang chính sách cho mỗi câu hỏi, hệ thống nên truy xuất 3–5 đoạn liên quan nhất, sau đó yêu cầu mô hình trả lời dựa trên các đoạn đó. Nếu câu hỏi chỉ cần tra cứu đơn giản, thậm chí có thể trả lời bằng mẫu dựng sẵn. 3. Dùng cache cho câu hỏi và bước xử lý lặp lại Trong nhiều ứng dụng, người dùng hỏi những câu rất giống nhau: “phí vận chuyển bao nhiêu?”, “làm sao đổi mật khẩu?”, “đơn hàng bao lâu thì tới?”. Nếu mỗi lần đều gọi mô hình, chi phí sẽ bị lãng phí. Có thể cache ở nhiều mức: - Cache câu trả lời cho câu hỏi phổ biến. - Cache kết quả truy xuất tài liệu trong hệ thống RAG. - Cache phần tóm tắt hồ sơ người dùng hoặc lịch sử hội thoại. - Cache kết quả phân loại ý định. Điểm cần lưu ý là cache phải có cơ chế hết hạn hoặc cập nhật khi dữ liệu nguồn thay đổi. Ví dụ, câu trả lời về chính sách hoàn tiền không nên được lưu mãi nếu chính sách có thể thay đổi theo tháng. 4. Thiết kế prompt để mô hình trả lời đúng trọng tâm Prompt dài chưa chắc tốt. Một prompt tốt nên giúp mô hình hiểu việc cần làm, dữ liệu được phép dùng và định dạng đầu ra mong muốn. Ví dụ chưa tối ưu: “Bạn là trợ lý thông minh. Hãy trả lời câu hỏi sau thật hay và đầy đủ.” Ví dụ tốt hơn: “Trả lời ngắn gọn bằng tiếng Việt, tối đa 5 câu. Chỉ sử dụng thông tin trong phần Ngữ cảnh. Nếu không đủ thông tin, nói rõ là chưa có dữ liệu để kết luận.” Cách viết thứ hai giúp giảm lan man, hạn chế bịa thông tin và kiểm soát độ dài đầu ra. 5. Đo đạc trước khi tối ưu Không nên tối ưu dựa trên cảm giác. Một ứng dụng LLM nên ghi nhận các chỉ số cơ bản: - Thời gian phản hồi trung bình và các trường hợp chậm bất thường. - Số token đầu vào, đầu ra theo từng loại tác vụ. - Tỷ lệ gọi từng loại mô hình. - Tỷ lệ cache hit. - Tỷ lệ lỗi hoặc câu trả lời bị người dùng đánh giá không hữu ích. Khi có số liệu nội bộ, nhóm phát triển sẽ biết nên tối ưu ở đâu. Có khi vấn đề không nằm ở mô hình mà ở bước truy xuất dữ liệu quá chậm, prompt quá dài, hoặc hệ thống gọi LLM nhiều lần cho một yêu cầu đơn giản. 6. Chấp nhận đánh đổi có chủ đích Không có cấu hình nào vừa rẻ nhất, nhanh nhất, lại chính xác nhất trong mọi tình huống. Một chatbot tư vấn nội bộ có thể ưu tiên chi phí thấp. Một trợ lý phân tích hợp đồng có thể cần ưu tiên độ chính xác và khả năng giải thích. Một ứng dụng hỗ trợ khách hàng thời gian thực lại cần phản hồi nhanh. Lời khuyên thực tế là hãy chia tác vụ theo mức rủi ro. Tác vụ rủi ro thấp có thể dùng mô hình nhỏ, cache mạnh và câu trả lời ngắn. Tác vụ rủi ro cao nên dùng mô hình tốt hơn, kiểm tra bổ sung và có thể yêu cầu con người duyệt lại. Kết luận Tối ưu ứng dụng LLM không chỉ là chọn mô hình mới nhất. Những việc đơn giản như giảm token, phân tầng mô hình, dùng cache, đo đạc chi phí và viết prompt rõ ràng thường đem lại hiệu quả lớn. Nếu bắt đầu một dự án AI, hãy thiết kế cơ chế theo dõi chi phí và độ trễ ngay từ đầu. Khi sản phẩm có người dùng thật, những chi tiết này sẽ quyết định hệ thống có vận hành bền vững hay không.