ByteByteGo: Hướng dẫn toàn diện về xử lý lỗi và thiết kế hệ thống LLM bền bỉ

Viết code thì nhanh, nhưng đưa vào vận hành (shipping) vẫn là một thử thách. Các giải pháp tính toán, lưu trữ và mạng lưới "chỉ với một nút bấm" của Railway được xây dựng để phục vụ cả phần mềm quy mô nhỏ lẫn quy mô siêu lớn (hyperscale).

Con người và các agent đều vận hành trên một hệ thống tích hợp theo chiều dọc (vertically integrated) trên phần cứng của chính chúng tôi. Hãy tận hưởng tốc độ vượt trội, hiệu quả kinh tế tốt hơn và sự an tâm hơn rất nhiều.

Đăng ký qua liên kết bên dưới để nhận tín dụng cloud miễn phí và để các agent của bạn thỏa sức làm việc.

Triển khai ngay

Ứng dụng được hỗ trợ bởi LLM là gì?

Nó cũng giống như bất kỳ ứng dụng phần mềm nào khác. Nhưng có một điểm khác biệt chính. Ngoài việc xử lý thông thường, ứng dụng còn gửi dữ liệu đến một mô hình ngôn ngữ lớn (LLM). Sau đó, nó sử dụng phản hồi của mô hình để thực hiện một tác vụ. Ví dụ, một chatbot hỗ trợ khách hàng có thể dựa vào LLM để trả lời các truy vấn của người dùng. Một hệ thống xử lý tài liệu có thể sử dụng LLM để trích xuất tên, ngày tháng và số tiền hóa đơn từ các tài liệu được tải lên. Một trợ lý lập trình có thể yêu cầu LLM viết một đoạn mã và tích hợp nó vào luồng logic.

Nhìn bề ngoài, chúng ta có thể cảm thấy việc xây dựng một ứng dụng như vậy khá đơn giản:

Người dùng gửi một yêu cầu.

Ứng dụng gửi một prompt đến LLM.

LLM trả về một câu trả lời.

Ứng dụng hiển thị câu trả lời đó hoặc sử dụng nó cho một số quá trình xử lý khác.

Tuy nhiên, có khả năng bất kỳ bước nào trong số này đều có thể thất bại. Mạng có thể không khả dụng. Nhà cung cấp LLM có thể từ chối yêu cầu của người dùng vì nhiều lý do. Yêu cầu có thể được gửi đi thành công, nhưng mô hình có thể trả về JSON không hợp lệ. LLM có thể hiểu sai hướng dẫn và bịa đặt thông tin sai lệch do hiện tượng ảo giác (hallucinations). Chúng cũng có thể mất nhiều thời gian để phản hồi.

Các kỹ thuật về khả năng phục hồi (resiliency) và xử lý lỗi giúp chuẩn bị cho ứng dụng xử lý các tình huống này theo cách tốt nhất có thể. Đây là những gì chúng ta sẽ đề cập trong bài viết:

Ý nghĩa của việc xử lý lỗi và khả năng phục hồi là gì?

Tại sao các ứng dụng LLM cần sự xử lý đặc biệt đối với việc xử lý lỗi?

Luồng yêu cầu trong một ứng dụng được hỗ trợ bởi LLM diễn ra như thế nào?

Các loại lỗi và sự cố chính

Làm thế nào để phân loại các sự cố nhằm đưa ra hành động phù hợp?

Làm thế nào để thử lại (retry) một yêu cầu một cách chính xác?

Làm thế nào để quản lý thời gian chờ (timeouts) và thời hạn (deadlines)?

Làm thế nào để xử lý các quy tắc nghiệp vụ trong một ứng dụng được hỗ trợ bởi LLM?

Làm thế nào để quản lý các phương án dự phòng (fallbacks) và suy giảm hiệu năng có kiểm soát (graceful degradation)?

Các bộ ngắt mạch (circuit breakers) hoạt động như thế nào trong thiết lập này?

Giới hạn tốc độ (rate limiting), hàng đợi và kiểm soát đồng thời

Làm thế nào để thực hiện các lệnh gọi công cụ (tool calls) của LLM một cách an toàn với tính lũy đẳng (idempotency)?

Làm thế nào để truyền phát (stream) các phản hồi từ LLM?

Trước khi đi vào chi tiết, hãy cùng hiểu chính xác xử lý lỗi và khả năng phục hồi nghĩa là gì.

Bạn có thể coi xử lý lỗi là một phần của chương trình chịu trách nhiệm quyết định hành động phù hợp khi có sự cố xảy ra. Ví dụ, hãy xem xét một ứng dụng gọi API của LLM. Nếu yêu cầu thành công, chương trình sẽ xử lý phản hồi theo cách thông thường. Nhưng nếu thất bại, chương trình có thể phải chọn từ nhiều tùy chọn khác nhau, chẳng hạn như thử lại yêu cầu, hiển thị thông báo giải thích, sử dụng mô hình dự phòng hoặc ghi lại lỗi để điều tra thêm.

Bất kỳ cách tiếp cận nào trong số này đều tốt hơn nhiều so với việc để toàn bộ ứng dụng bị treo. Nhưng chúng ta cũng không thể xử lý mọi vấn đề theo cùng một cách. Một ứng dụng thực tế trong môi trường sản xuất (production) cần có khả năng phân biệt giữa các loại lỗi khác nhau để chúng ta có thể thực hiện hành động đúng đắn. Do đó, việc xử lý lỗi tốt cần phải hiểu rõ cái gì đã thất bại và tại sao.

Ngược lại, khả năng phục hồi là khả năng của ứng dụng để tiếp tục thực hiện công việc ngay cả khi một số phần của hệ thống đang gặp sự cố. Chúng ta không cần một ứng dụng phải hoạt động hoàn hảo mới được coi là có khả năng phục hồi. Các lỗi là điều bình thường, nhưng chúng nên xảy ra trong tầm kiểm soát. Điều này còn được gọi là suy giảm hiệu năng có kiểm soát (graceful degradation).

Ví dụ, hãy xem xét một trợ lý du lịch sử dụng LLM để xây dựng lịch trình cá nhân hóa cho du khách. Nếu LLM chính mà nó phụ thuộc không khả dụng, ứng dụng có thể sử dụng một mô hình dự phòng nhỏ hơn để tạo lịch trình. Nếu mô hình đó cũng không khả dụng, ứng dụng có thể hiển thị các hướng dẫn điểm đến đã được tạo trước đó cho cùng các địa điểm đó. Tất nhiên, những câu trả lời này sẽ không được cá nhân hóa, nhưng người dùng sẽ không chỉ nhìn thấy một thông báo lỗi vô ích.

Trong khi xử lý lỗi giải quyết các sự cố riêng lẻ, khả năng phục hồi quan tâm nhiều hơn đến hành vi của toàn bộ hệ thống ngay cả khi mọi thứ đang gặp trục trặc.

Các ứng dụng phần mềm truyền thống hoạt động theo các quy tắc được xác định rõ ràng. Nếu chúng ta viết một hàm cộng 5 và 7, nó sẽ luôn trả về 12. Nếu hàm trả về thành công, kết quả được coi là hợp lệ.

Với LLM, chúng ta không có được sự xa xỉ đó. Điều này là do đầu ra từ LLM mang tính xác suất. Nói cách khác, cùng một prompt có thể tạo ra các câu trả lời khác nhau mỗi lần. Ngoài ra, một yêu cầu API thành công đến LLM không đảm bảo rằng phản hồi chúng ta nhận được là chính xác hoặc thậm chí là có thể sử dụng được. Theo những gì chúng ta biết, phản hồi có thể hoàn toàn là vô nghĩa. Điều này có nghĩa là một lệnh gọi API LLM có vẻ thành công dựa trên mã trạng thái, nhưng nó có thể là một thất bại về mặt logic. Có một số điều có thể sai với phản hồi:

Mô hình có thể đã bỏ qua một phần hướng dẫn.

Nó có thể đã trả về phản hồi văn bản thuần túy khi ứng dụng mong đợi JSON.

LLM có thể bị ảo giác và bịa đặt ra một sản phẩm, chính sách hoặc thông tin không có cơ sở trong dữ liệu thực tế.

Mô hình có thể trả về phản hồi không đầy đủ vì nó đã đạt đến giới hạn token.