Cẩm nang Kỹ thuật Nền tảng cho các Mô hình Ngôn ngữ Lớn (LLM) trong Sản xuất

Trang chủ InfoQ Bài viết Cẩm nang Kỹ thuật Nền tảng cho các LLM trong Sản xuất AI, ML & Kỹ thuật Dữ liệu Cẩm nang Kỹ thuật Nền tảng cho các LLM trong Sản xuất Ngày 05/10/2026 32 phút đọc Bởi Aditya Mulik Được đánh giá bởi Srini Penchikala Theo dõi chúng tôi trên Youtube 232K người theo dõi Linkedin 26K người theo dõi Instagram Mới RSS 19K độc giả X 57.1k người theo dõi Facebook 21K lượt thích Bluesky Mới Nghe bài viết này - 0:00 Âm thanh sẵn sàng phát Trình duyệt của bạn không hỗ trợ phần tử âm thanh. 0:00 0:00 Bình thường 1.25x 1.5x Thích Danh sách đọc Những điểm chính * Tỷ lệ "ảo giác" (hallucination rate) là một chỉ số có thể kiểm soát ở cấp độ nền tảng. Bằng cách bao bọc mô hình trong một vòng lặp thử lại tự động, có khả năng phát hiện lỗi định dạng, lỗi căn cứ và lỗi cơ sở hạ tầng ngay lập tức, chúng tôi đã giảm tỷ lệ "ảo giác" trong sản xuất từ 15% xuống 1,5% mà không cần thay đổi mô hình nền tảng. * Một cổng xác thực ý định (intent-validation gate) trả về "chưa phân loại" thay vì mặc định chọn tác nhân có điểm số cao nhất, giúp loại bỏ các "ảo giác" ngoài ý định và cải thiện định tuyến đa tác nhân. * Bằng cách lưu trữ các lời nhắc (prompt) trong một kho lưu trữ có khả năng bảo toàn lịch sử thay vì mã hóa cứng chúng vào các tệp ứng dụng, chúng tôi có thể cập nhật hoặc khôi phục các hướng dẫn ngay lập tức trong thời gian chạy. Việc điều chỉnh lời nhắc mà không có nhật ký kiểm tra rõ ràng là cách dễ nhất để âm thầm phá vỡ hành vi của AI. * Thực thi ủy quyền công cụ trực tiếp tại máy chủ tài nguyên với chính sách từ chối mặc định nghiêm ngặt; chỉ dựa vào kiểm tra cổng API có nghĩa là bất kỳ lỗi nào trong bộ điều phối của bạn cũng có thể ngay lập tức làm lộ mọi công cụ được kết nối. * Các công cụ APM (Application Performance Monitoring) tiêu chuẩn không thể phát hiện sự suy giảm ngữ nghĩa. Bạn phải đo lường tỷ lệ "ảo giác" và chi phí token cho mỗi nhóm tại điểm nhập yêu cầu. Cố gắng điều chỉnh sự phân bổ này vào một đường dẫn sản xuất trực tiếp sau này sẽ tiêu tốn hàng tuần thời gian kỹ thuật. Vào cuối tháng đầu tiên triển khai hệ thống khuyến nghị tồn kho dựa trên LLM trong sản xuất, khoảng 15% phản hồi của tác nhân là "ảo giác" – những kết quả nghe có vẻ tự tin nhưng không dựa trên bất kỳ thông tin thực tế nào. Sáu tháng sau, tỷ lệ này là 1,5% và đòn bẩy làm thay đổi con số này không phải là một mô hình nền tảng tốt hơn. Đó là quyết định ngừng coi ngăn xếp LLM như một mối quan tâm của ứng dụng và bắt đầu coi nó như một cơ sở hạ tầng nền tảng. Dự án đằng sau bài viết này là một nền tảng độ chính xác tồn kho tại một tổ chức bán lẻ lớn. Trong chuỗi cung ứng bán lẻ, hồ sơ tồn kho hệ thống thường sai lệch so với hàng hóa thực tế trên kệ do thất lạc, hư hỏng, trộm cắp và sai sót trong kiểm đếm; sự sai lệch đó làm giảm hiệu quả đặt hàng, bổ sung và khả năng sẵn có của sản phẩm. Các nhà tài trợ liên quan Hệ thống LLM đa tác nhân của chúng tôi phân tích các tín hiệu sai lệch trên hàng triệu mã sản phẩm (SKU) và hàng tỷ hồ sơ tồn kho lịch sử, sau đó tạo ra các khuyến nghị điều chỉnh cho người dùng nhằm duy trì độ chính xác tồn kho mọi lúc. Lớp nền tảng được mô tả trong bài viết này đã được xây dựng với sự hợp tác của một đội ngũ gồm các chuyên gia kinh doanh, sản phẩm, kỹ sư phần mềm, nhà khoa học dữ liệu và kỹ sư dữ liệu. Hiện tại, lớp nền tảng này đang phục vụ hàng chục nhóm ứng dụng trong các trường hợp sử dụng như kiểm toán tồn kho, xem xét bổ sung, phân loại sai lệch và nhiều hơn nữa. Bài viết này ghi lại sự thay đổi đó, định tuyến thông qua các mô hình nền tảng như Gemini và GPT dưới lưu lượng truy cập cấp doanh nghiệp. Các mô hình dưới đây là những gì tôi ước đã được áp dụng ngay từ ngày đầu tiên. Mọi nguyên mẫu được mô tả ở đây đều được triển khai trong một kho lưu trữ GitHub đi kèm, được xây dựng một cách có chủ đích mà không có các lớp trừu tượng ẩn. Trong khi một khuôn khổ có thể che giấu cơ chế đằng sau một decorator hoặc một loại tác nhân tích hợp, kho lưu trữ này giữ cho các bộ phận chuyển động hiển thị để các mô hình vẫn dễ hiểu. Các đoạn mã trong bài viết này được lấy trực tiếp từ kho lưu trữ đó. Có một điểm khác biệt có chủ đích so với phiên bản sản xuất. Kho lưu trữ chạy một mô hình cục bộ (llama3.1 thông qua Ollama), được kết nối qua LiteLLM thay vì một mô hình nền tảng được lưu trữ, do đó toàn bộ hệ thống có thể chạy từ đầu đến cuối mà không tốn chi phí API. **Tại sao các ứng dụng LLM riêng lẻ thất bại ở quy mô lớn** Mô hình thất bại đủ nhất quán giữa các nhóm để có thể dự đoán được. Nguyên mẫu hoạt động. Lần triển khai sản xuất đầu tiên có vẻ ổn trong một tuần. Sau đó, các vấn đề không xuất hiện trong quá trình đánh giá bắt đầu xuất hiện trên các bảng điều khiển. Trong trường hợp của chúng tôi, ba lỗi đã xuất hiện trong quá trình thử nghiệm beta, mỗi lỗi đều bắt nguồn từ điều mà nguyên mẫu chưa bao giờ thực hiện. Đầu tiên là việc điều tiết API LLM. Với khối lượng yêu cầu thực tế, chúng tôi bắt đầu bị nhà cung cấp mô hình giới hạn tốc độ. Thứ hai là ngữ cảnh. Khi hệ thống đề xuất một mục không phù hợp, nguyên nhân gốc rễ hầu như luôn là dữ liệu chúng tôi cung cấp cho mô hình, chứ không phải bản thân mô hình, điều này khiến các đường ống kỹ thuật dữ liệu mạnh mẽ trở thành trung tâm của giải pháp. Thứ ba là vấn đề lớn, ảo giác, vốn hiếm khi xảy ra riêng lẻ nhưng trở thành một tỷ lệ ổn định khi chúng tôi phục vụ lưu lượng truy cập sản xuất. Chúng tôi đã thiết kế nền tảng để có thể theo dõi những lỗi này. Khả năng hiển thị đó đã biến mỗi lỗi từ một bí ẩn thành thứ chúng tôi có thể khắc phục. Việc theo dõi chúng cũng làm rõ lý do tại sao chúng thuộc về một lớp nền tảng chứ không phải bất kỳ ứng dụng nào. Ba đặc tính nổi bật: **Ảo giác như đầu ra, không phải lỗi.** Một phản hồi ảo giác không phải là một dấu vết ngăn xếp (stack trace). Nó vượt qua mọi kiểm tra sức khỏe truyền thống. Dịch vụ hạ nguồn tiêu thụ nó, thực hiện hành động dựa trên nó, và chỉ sau đó rất lâu, ai đó mới nhận thấy đầu ra được đề xuất không tồn tại. **Chi tiêu token không kiểm soát.** Nếu không có thuộc tính trên mỗi yêu cầu