Choosing a primary large language model can take an afternoon. Handling what happens when it fails is the real engineeri

Việc lựa chọn một mô hình ngôn ngữ lớn (LLM) chính có thể chỉ mất một buổi chiều. Xử lý những gì xảy ra khi nó thất bại mới là công việc kỹ thuật thực sự.

Hầu hết các đội ngũ đều tối ưu hóa cho kịch bản lý tưởng (happy path). Họ đánh giá độ chính xác trên các tập dữ liệu sạch, tinh chỉnh prompt với các đầu vào lý tưởng và triển khai một cách đầy tự tin. Sau đó, lưu lượng truy cập thực tế (production traffic) ập đến. Mô hình bắt đầu bị timeout trong giờ cao điểm, trả về JSON sai định dạng vào tối thứ Sáu, hoặc đột nhiên tốn kém gấp ba lần sau một đợt cập nhật giá. Tính năng AI được thiết kế kỹ lưỡng của bạn trở thành một gánh nặng vì không ai lên kế hoạch cho việc mô hình bị lỗi.

Trong bất kỳ ứng dụng đa mô hình (multi-model) nghiêm túc nào, các quy tắc dự phòng (fallback rules) không phải là một ý tưởng nảy ra sau cùng. Chúng là hạ tầng cốt lõi. Cách hệ thống của bạn phản ứng khi mô hình chính gặp trục trặc sẽ quyết định việc người dùng ở lại hay rời đi.

Bắt đầu với các tín hiệu lỗi rõ ràng

Bạn không thể xây dựng một chiến lược dự phòng nếu không biết chính xác mình đang phản ứng với điều gì. Hãy bắt đầu bằng việc thiết lập giám sát (instrumenting) mọi lời gọi mô hình gửi đi và phân loại các lỗi thành các tín hiệu cụ thể, có thể hành động được.

Hãy chú ý đến các lỗi API timeout khi endpoint của nhà cung cấp bị treo. Chú ý các lỗi giới hạn tốc độ (rate limit) — thường là lỗi HTTP 429 — xảy ra khi bạn tăng đột biến lưu lượng hoặc chạm ngưỡng hạn mức hàng tháng. Chú ý các đầu ra JSON không hợp lệ làm hỏng pipeline phân tích (parser pipeline) của bạn. Chú ý các phản hồi trống hoặc không đầy đủ, trông có vẻ thành công ở lớp HTTP nhưng không chứa nội dung hữu ích nào. Chú ý độ trễ (latency) cao làm giảm trải nghiệm chat trước khi bất kỳ lỗi timeout cứng nào xảy ra. Chú ý lỗi tràn độ dài ngữ cảnh (context length overflow) khi đầu vào của người dùng vượt quá cửa sổ ngữ cảnh của mô hình. Và chú ý đến sự suy giảm chất lượng (quality regression), lỗi tinh vi nhất trong tất cả: mô hình vẫn phản hồi, nhưng câu trả lời bị lệch hướng, trở nên mơ hồ hoặc phớt lờ các hướng dẫn định dạng sau một bản cập nhật từ phía nhà cung cấp.

Mỗi tín hiệu này nên kích hoạt một phản ứng khác nhau. Một lỗi timeout xứng đáng được thử lại (retry). JSON lỗi xứng đáng được chuyển sang mô hình khác. Một lỗi giới hạn tốc độ có thể có nghĩa là bạn cần chuyển hẳn sang một nhà cung cấp khác.

Khớp cơ chế dự phòng với quy trình làm việc

Sử dụng cùng một quy tắc dự phòng cho mọi tác vụ là một công thức dẫn đến thảm họa. Một chatbot và một tác vụ trích xuất dữ liệu chạy ngầm có nhu cầu hoàn toàn trái ngược nhau. Hãy thiết kế cơ chế dự phòng xoay quanh quy trình làm việc cụ thể.

Chatbots cần tốc độ và sự mạch lạc trong hội thoại. Người dùng có thể bỏ qua một câu trả lời hơi chung chung, nhưng họ sẽ không chấp nhận việc phải chờ đợi năm giây. Nếu mô hình chính chậm lại, hãy chuyển sang một phương án dự phòng nhanh — thường là một biến thể nhỏ hơn từ cùng một dòng mô hình, hoặc một gói dịch vụ tốc độ cao từ nhà cung cấp khác. Hãy giữ cho cuộc đối thoại được tiếp diễn.

Hệ thống RAG cần độ chính xác. Bạn đã trả chi phí cho việc truy xuất — tìm kiếm vector, reranking, có thể là cả web crawling. Nếu bộ tạo (generator) không tuân thủ ngữ cảnh được cung cấp, tất cả công sức đó sẽ đổ sông đổ biển. Hãy chuyển sang một mô hình nổi tiếng về khả năng tuân thủ hướng dẫn chính xác và hiểu ngữ cảnh dài, ngay cả khi nó chậm hơn.

Các công cụ lập trình cần tính logic. Các nhà phát triển muốn cú pháp chính xác và các lời gọi API hợp lệ hơn là những lời giải thích hoa mỹ. Nếu mô hình chính bắt đầu "ảo giác" (hallucinating) về các hàm hoặc bỏ qua các trường hợp biên (edge cases), hãy chuyển sang một mô hình được tinh chỉnh (fine-tuned) cho mã nguồn. Hãy chấp nhận độ trễ cao hơn để đổi lấy đầu ra có thể biên dịch được.

Trích xuất JSON cần cấu trúc. Việc tạo dữ liệu có cấu trúc rất dễ bị lỗi. Chỉ cần thiếu một dấu ngoặc hoặc một dấu ngoặc kép không được escape đúng cách cũng sẽ làm hỏng việc ghi vào cơ sở dữ liệu ở các bước sau. Nếu mô hình chính bắt đầu không tuân thủ schema, hãy thử lại một lần, sau đó chuyển sang một mô hình có độ tin cậy về định dạng cao. Thật kỳ lạ, các mô hình nhỏ hơn được tinh chỉnh để tuân thủ thường hoạt động tốt hơn các "gã khổng lồ" sáng tạo trong tác vụ cụ thể này.

Tự động hóa và các tác vụ hàng loạt (batch jobs) cần kiểm soát chi phí. Các bộ phân loại chạy ngầm, bộ tóm tắt nhật ký (log) và bộ tạo thông báo chạy liên tục. Một đợt tăng giá đột ngột ở mô hình chính có thể biến một hóa đơn hàng ngày ở mức kiểm soát được thành một cuộc khủng hoảng ngân sách. Hãy để một mô hình rẻ hơn, ổn định hơn ở chế độ chờ cho các luồng công việc không quan trọng này. Nếu chất lượng đầu ra giảm nhẹ, tác động đến doanh nghiệp thường là tối thiểu.

Hiểu rõ các ràng buộc trước khi chuyển đổi

Việc thay đổi mô hình một cách mù quáng sẽ tạo ra những vấn đề mới. Nếu bạn hạ cấp từ một mô hình mạnh xuống một mô hình yếu, bản dự phòng có thể hiểu sai các prompt tinh tế và tạo ra "rác", dẫn đến các lỗi dây chuyền ở các bước sau. Nếu bạn nâng cấp lên một mô hình lớn hơn, bạn có thể giải quyết được vấn đề chất lượng nhưng sẽ làm vỡ ngân sách chỉ trong vài giờ.

Trước khi đưa bất kỳ mô hình nào lên trạng thái dự phòng, hãy kiểm tra (audit) nó dựa trên sáu yếu tố.

• Khả năng của mô hình: Liệu nó có thực sự xử lý được loại prompt đó không, hay nó sẽ thất bại theo một cách khác?
• Hỗ trợ ngôn ngữ: Phương án dự phòng của bạn có thể làm rất tốt tiếng Anh nhưng lại gặp hiện tượng ảo giác (hallucinate) khi dùng tiếng Hindi, tiếng Tây Ban Nha hoặc tiếng Nhật.
• Kích thước cửa sổ ngữ cảnh: Nếu đầu vào của bạn là 50.000 token, một phương án dự phòng với giới hạn 16.000 token sẽ bị cắt bớt và làm mất ý nghĩa một cách âm thầm.
• Độ trễ: Một số nhà cung cấp luôn nhanh hơn những bên khác tại khu vực của bạn.
• Chi phí mỗi yêu cầu: Hãy thiết lập một mức trần cố định. Biết rõ chi phí dự phòng khi lưu lượng đạt đỉnh là bao nhiêu.
• Độ tin cậy của đầu ra: Liệu nó có tuân thủ định dạng đầu ra mọi lúc, hay chỉ vào mỗi thứ Ba?

Bốn mô hình dự phòng hiệu quả

Không phải mọi lỗi đều cần cùng một cách khắc phục. Hãy xây dựng một bộ công cụ gồm các loại dự phòng và áp dụng chúng một cách có chủ đích.

Dự phòng thử lại (Retry fallback). Đối với các lỗi mạng tạm thời và sự cố gián đoạn ngắn từ nhà cung cấp, hãy thử lại cùng một mô hình với cơ chế lùi dần thời gian chờ (exponential backoff). Đừng thử lại khi đầu ra bị sai định dạng hoặc vượt quá ngữ cảnh — việc gửi cùng một prompt lỗi hai lần hiếm khi mang lại kết quả.

Dự phòng tương đương (Equivalent fallback). Khi nhà cung cấp chính của bạn bị sập hoặc bị giới hạn tốc độ (throttled), hãy chuyển sang một mô hình tương tự từ một nhà cung cấp khác. Việc chuyển từ một mô hình tiên phong (frontier model) này sang một mô hình khác có cùng phân khúc thường đòi hỏi rất ít việc viết lại prompt và vẫn giữ được chất lượng đầu ra.

Dự phòng rẻ hơn (Cheaper fallback). Hãy dành riêng một mô hình chi phí thấp cho các tác vụ không quan trọng. Nếu phương án giá rẻ gặp khó khăn, hãy giảm cấp tính năng một cách mượt mà thay vì lãng phí các token cao cấp cho những công việc có giá trị thấp.

Dự phòng mạnh hơn (Stronger fallback). Nghe có vẻ ngược đời, nhưng điều này rất thiết yếu. Khi một mô hình tầm trung liên tục gặp khó khăn với các lập luận phức tạp, toán học nhiều bước hoặc phân tích pháp lý tinh vi, hãy nâng cấp lên một mô hình có năng lực cao hơn. Hãy sử dụng cách này một cách tiết kiệm cho các luồng người dùng có giá trị cao, nơi mà độ chính xác giúp bảo vệ doanh thu hoặc sự an toàn.

Tích hợp logic vào kiến trúc của bạn

Đừng rải rác logic dự phòng khắp hàng tá khối try-catch trong mã nguồn ứng dụng. Hãy coi việc định tuyến (routing) là một phần của hạ tầng. Hãy xây dựng một lớp trung gian (middleware layer) để ánh xạ các loại tác vụ tới danh sách các mô hình theo thứ tự, mỗi mô hình có ngưỡng thời gian chờ (timeout), chính sách thử lại và bộ ngắt mạch (circuit breaker) riêng.

Hãy theo dõi các sự kiện dự phòng như những chỉ số quan trọng (first-class metrics). Tỷ lệ lỗi cho bạn biết khi nào một mô hình bị sập; tỷ lệ dự phòng cho bạn biết khi nào một mô hình không phù hợp với công việc. Nếu hệ thống của bạn phải chuyển sang dự phòng 30 hoặc 40 phần trăm thời gian, mô hình chính của bạn đang không được tối ưu cho khối lượng công việc đó. Đó là tín hiệu để đánh giá lại việc lựa chọn mô hình, chứ không chỉ là xử lý lỗi.

Thiết lập ngân sách rõ ràng. Việc dự phòng không bao giờ được là một tấm séc khống. Nếu bạn nâng cấp lên mô hình cao cấp khi tải cao, hãy giới hạn số lượng yêu cầu được nâng cấp mỗi phút. Hãy bảo vệ túi tiền của bạn với sự nghiêm ngặt tương tự như cách bạn bảo vệ thời gian hoạt động (uptime) của hệ thống.

Bài kiểm tra thực tế

Bạn không xây dựng sản phẩm để trình diễn (demo). Bạn đang xây dựng cho lúc 3 giờ chiều thứ Ba, khi API chạy chậm chạp, người dùng đang chờ đợi và đội ngũ tài chính vừa hỏi tại sao hóa đơn AI lại tăng gấp đôi. Một chiến lược dự phòng trưởng thành sẽ giữ cho sản phẩm hoạt động ổn định, giữ cho trải nghiệm người dùng nhất quán và giữ cho chi phí của bạn có thể dự đoán được.

Hãy chọn mô hình chính một cách cẩn thận. Nhưng hãy dành thời gian gấp đôi để thiết kế những gì sẽ xảy ra khi nó làm bạn thất vọng.

Source: How to Design AI Model Fallback Rules for Multi-Model Apps

Community: GyaanSetu AI on Telegram