13Vận hành ứng dụng dùng mô hình ngôn ngữ lớn#

Khi một ứng dụng dùng mô hình ngôn ngữ lớn (LLM), phần lớn những gì đã trình bày vẫn đúng: vẫn cần hợp đồng dữ liệu, quản lý phiên bản, shadow và canary, giám sát và quay lui. Nhưng một số ràng buộc thay đổi, và việc vận hành loại hệ thống này thường được gọi riêng là LLMOps. Giáo trình Ứng dụng LLM trình bày cách xây dựng các ứng dụng đó; chương này xét chúng từ phía vận hành.

13.1Khác biệt so với hệ thống học máy thông thường#

Có năm ràng buộc thay đổi khi chuyển từ một mô hình tự huấn luyện sang một ứng dụng dùng LLM.

Ràng buộc đầu tiên là việc huấn luyện. Ứng dụng LLM thường dùng mô hình của bên thứ ba, nên thay cho huấn luyện lại là thay prompt, thay ngữ cảnh hoặc thay phiên bản mô hình. Ràng buộc thứ hai là đầu ra: thay vì một số hay một nhãn lớp, mô hình trả về văn bản tự do, và không có hàm đúng sai hiển nhiên để chấm nó. Ràng buộc thứ ba là tính tất định: ngoài yếu tố ngẫu nhiên khi lấy mẫu, mô hình của nhà cung cấp có thể thay đổi mà ứng dụng không hề biết. Ràng buộc thứ tư là chi phí: thay vì chủ yếu là chi phí huấn luyện, tương đối cố định, chi phí chính là suy luận tính theo token, thay đổi theo từng yêu cầu. Ràng buộc thứ năm là rủi ro: ngoài dự đoán sai còn có rò rỉ dữ liệu, nội dung có hại và prompt injection.

Ràng buộc thứ ba đáng chú ý nhất về mặt vận hành. Với mô hình tự huấn luyện, mô hình là một tạo tác bất biến nằm trong sổ đăng ký. Với mô hình gọi qua API, hành vi có thể thay đổi khi nhà cung cấp cập nhật mô hình mà vẫn giữ cùng tên gọi. Chen, Zaharia và Zou (2023) đo được những thay đổi đáng kể về hành vi của cùng một tên mô hình GPT-4 giữa hai phiên bản cách nhau ba tháng. Đây là dạng cực đoan của phụ thuộc dữ liệu không ổn định ở Mục 1.4, và cách xử lý cũng tương tự: dùng định danh phiên bản cố định của mô hình (các nhà cung cấp thường có tên kèm ngày phát hành), và coi mỗi lần đổi phiên bản là một lần phát hành đầy đủ, phải qua bộ đánh giá, shadow và canary.

13.2Đánh giá theo nhiều tầng#

Vì không có hàm đúng sai hiển nhiên, đánh giá là phần tốn kém nhất khi vận hành ứng dụng LLM. Cách tổ chức phổ biến là chia việc đánh giá thành ba tầng, đánh đổi giữa chi phí và độ tin cậy.

Tầng thứ nhất là kiểm tra theo quy tắc, áp dụng cho mọi lượt gọi với chi phí gần như bằng 0: đầu ra có đúng định dạng không, JSON có hợp lệ không, có trích dẫn không, độ dài có bất thường không, có từ khoá bị cấm không. Tầng thứ hai là dùng một mô hình ngôn ngữ làm giám khảo (LLM-as-a-judge) để chấm chất lượng nội dung, như câu trả lời có bám vào nguồn không, có hữu ích không, có đúng giọng văn không, có từ chối đúng lúc không. Tầng này tốn chi phí nên chỉ áp dụng cho một mẫu, thường từ vài phần trăm tới vài chục phần trăm số lượt gọi tuỳ lưu lượng; đây là mức thường gặp chứ không phải quy chuẩn. Tầng thứ ba là người chấm, trên một mẫu nhỏ và định kỳ. Tầng này đắt nhất, và dùng làm chuẩn để hiệu chỉnh giám khảo LLM.

Cấu trúc ba tầng này tương ứng với các lớp giám sát ở Mục 10.2: càng gần đánh giá thật thì càng đắt, nên phải lấy mẫu. Tầng thứ ba hay bị bỏ qua nhất, nhưng nó giữ cho cả hệ thống đánh giá đáng tin. Giám khảo LLM cũng là một mô hình, có sai số và có thể thay đổi theo phiên bản. Nếu không định kỳ đối chiếu với người chấm, hệ thống đánh giá có thể báo mọi thứ đều ổn trong khi chất lượng thực đã giảm. Chương 12 của Ứng dụng LLM trình bày chi tiết các loại đánh giá và cách tính số mẫu cần thiết.

13.3Thiên lệch của giám khảo LLM#

Zheng và cộng sự (2023), khi xây dựng bộ đánh giá MT-Bench, phân tích các thiên lệch của mô hình ngôn ngữ khi làm giám khảo. Có ba thiên lệch chính và một vấn đề về cách đặt câu hỏi.

Thiên lệch thứ nhất là thiên lệch vị trí: khi so sánh hai câu trả lời, giám khảo có xu hướng ưu tiên một vị trí, thường là câu trả lời đặt trước. Cách xử lý là hỏi hai lần với thứ tự đảo ngược, và chỉ tính là thắng khi thắng ở cả hai lần. Thiên lệch thứ hai là thiên lệch độ dài: câu trả lời dài hơn thường được chấm cao hơn dù không tốt hơn. Cách xử lý là đưa yêu cầu về độ dài vào tiêu chí chấm, hoặc so sánh các câu trả lời có độ dài tương đương. Thiên lệch thứ ba là khả năng giám khảo chấm cao hơn cho câu trả lời do chính nó sinh ra; các tác giả thấy dấu hiệu của hiện tượng này nhưng lưu ý rằng dữ liệu chưa đủ để kết luận chắc chắn. Cách xử lý thận trọng là dùng mô hình giám khảo khác họ với mô hình đang phục vụ. Cuối cùng, tiêu chí chấm mơ hồ như "câu trả lời này có tốt không" cho kết quả không ổn định; tiêu chí nên được chia thành nhiều chiều, mỗi chiều là một câu hỏi có hoặc không hoặc một thang điểm ngắn, kèm ví dụ mẫu.

Shankar và cộng sự (2024) ghi nhận thêm một hiện tượng khi xây dựng tiêu chí chấm: người dùng cần có tiêu chí để chấm đầu ra, nhưng chính việc đọc và chấm đầu ra lại làm họ thay đổi tiêu chí. Các tác giả gọi hiện tượng này là criteria drift. Hệ quả thực tế là không thể viết xong tiêu chí chấm một lần ngay từ đầu; cần đọc một lượng đầu ra thật trước, và xem lại tiêu chí định kỳ.

Nguyên tắc chung cho mọi giám khảo LLM là đo mức đồng thuận giữa nó và người chấm trên cùng một tập mẫu, ví dụ bằng hệ số kappa của Cohen, và coi đó là giới hạn trên cho độ tin cậy của mọi kết luận rút ra từ giám khảo. Lập luận này giống với lập luận về mức đồng thuận giữa những người gán nhãn ở Mục 3.5.

13.4Đánh giá ngoại tuyến và trực tuyến#

Việc đánh giá thường được tổ chức thành hai vòng. Vòng ngoại tuyến dùng một tập đánh giá chuẩn (golden set): một tập câu hỏi được chọn lọc, gồm cả những trường hợp khó, mà hệ thống phải đạt trước mỗi lần phát hành. Đây là bước kiểm định trong CI, tương đương với bước so sánh với mô hình đang chạy ở Mục 11.4; Mục 12.5 của Ứng dụng LLM trình bày cách kiểm thử hồi quy cho prompt. Vòng trực tuyến chấm bất đồng bộ một tỉ lệ nhỏ số lượt gọi thật, và gắn điểm vào bản ghi vết (trace) tương ứng (Chương 13 của Ứng dụng LLM).

Tập đánh giá chuẩn phải được cập nhật liên tục. Shankar và cộng sự (2022) ghi nhận thực hành này cho học máy nói chung: tập kiểm định nên thay đổi theo thời gian, và mỗi sự cố trong sản xuất nên trở thành một trường hợp mới trong tập kiểm định. Một tập đánh giá không được cập nhật dần dần chỉ còn đo những gì hệ thống đã làm đúng.

13.5Hệ thống RAG#

Với hệ thống RAG (retrieval-augmented generation), một câu trả lời sai có thể do hai nguyên nhân khác nhau, và mỗi nguyên nhân cần một cách sửa khác. Nếu tài liệu cần thiết không có trong ngữ cảnh, lỗi nằm ở bước truy xuất; nó được đo bằng recall@$k$ hay MRR trên một tập câu hỏi có nhãn tài liệu đúng, và được sửa bằng cách cải thiện việc chia đoạn, mô hình embedding, tìm kiếm kết hợp hay xếp hạng lại. Nếu tài liệu cần thiết có trong ngữ cảnh mà câu trả lời vẫn sai, lỗi nằm ở bước sinh; nó được đo bằng độ trung thành (faithfulness), tức các khẳng định trong câu trả lời có được ngữ cảnh hỗ trợ không, và được sửa bằng prompt, bằng mô hình khác, hoặc bằng cách yêu cầu trích dẫn.

Phân biệt hai nguyên nhân này là bước chẩn đoán đầu tiên cho mọi lỗi của hệ thống RAG; gộp chúng vào một chỉ số duy nhất thì không biết cần sửa ở đâu. Es và cộng sự (2023), với thư viện RAGAS, đề xuất theo dõi ba chỉ số: độ trung thành của câu trả lời với ngữ cảnh, mức liên quan của câu trả lời với câu hỏi, và mức liên quan của ngữ cảnh với câu hỏi. Thí nghiệm ở Mục 8.5 của Ứng dụng LLM cho một ví dụ vì sao bước truy xuất cần được theo dõi riêng: ở những câu hỏi mà truy xuất không đưa về đoạn nào thuộc đúng chương, độ chính xác giảm từ 0,586 khi không có ngữ cảnh xuống 0,276 khi có ngữ cảnh sai.

Hệ thống RAG còn có ba vấn đề vận hành riêng. Vấn đề thứ nhất là độ mới của chỉ mục: kho tài liệu thay đổi (thêm tài liệu, sửa, xoá), nên chỉ mục phải được cập nhật, và cần theo dõi khoảng thời gian từ lúc tài liệu thay đổi tới lúc chỉ mục phản ánh thay đổi đó. Vấn đề thứ hai là đổi mô hình embedding đòi hỏi lập chỉ mục lại toàn bộ, vì vector của hai mô hình embedding khác nhau không so sánh được với nhau. Việc đổi mô hình embedding nên được làm như một lần chuyển dữ liệu: lập chỉ mục mới song song, đánh giá, rồi mới chuyển. Vấn đề thứ ba là quyền truy cập: bước truy xuất phải lọc theo quyền của người hỏi; nếu không, hệ thống có thể trả lời bằng nội dung lấy từ tài liệu mà người hỏi không được phép xem.

13.6Chi phí và độ trễ#

Chi phí là phần khác nhiều nhất so với hệ thống học máy thông thường, vì nó thay đổi theo từng yêu cầu. Chi phí cần được ghi lại theo từng bản ghi vết và tách thành các thành phần:

chi phí một lượt = (số token vào × đơn giá token vào) + (số token ra × đơn giá token ra)
                 + chi phí các lượt gọi giám khảo LLM      ← ghi thành một dòng riêng
                 + chi phí truy xuất (embedding + tìm kiếm vector)

Ghi riêng chi phí của giám khảo giúp biết chi phí tăng vì lưu lượng tăng hay vì tỉ lệ lấy mẫu đánh giá tăng.

Để giảm chi phí, nên thử theo thứ tự sau. Trước hết là bộ nhớ đệm (cache): lưu kết quả cho các câu hỏi lặp lại chính xác, cho các câu hỏi gần giống (semantic cache), và lưu đệm phần đầu cố định của prompt (prompt caching; Mục 4.6 của Ứng dụng LLM). Tiếp theo là định tuyến (routing): gửi câu hỏi dễ tới mô hình nhỏ và rẻ, chỉ gửi câu hỏi khó tới mô hình lớn; cách này cần một bộ phân loại độ khó, và bộ phân loại đó cũng là một mô hình phải được giám sát. Cuối cùng là giảm ngữ cảnh, như bớt số đoạn truy xuất hay tóm tắt lịch sử hội thoại. Chi phí tỉ lệ với số token đầu vào, và ngữ cảnh thường chiếm phần lớn số token đó: trong thí nghiệm RAG ở Mục 8.5 của Ứng dụng LLM, hai đoạn ngữ cảnh làm số token đầu vào tăng từ 137 lên 813.

Về độ trễ, ứng dụng LLM có hai chỉ số riêng. Thời gian tới token đầu tiên (time to first token) quyết định cảm nhận về độ nhanh khi câu trả lời bắt đầu hiện ra, còn thời gian giữa các token quyết định tốc độ hiện ra của phần còn lại (Mục 2.5 của Ứng dụng LLM). Phân tích phần đuôi ở Mục 7.3 vẫn áp dụng. Một agent gọi mô hình và công cụ qua $k$ bước nối tiếp có thời gian trả lời bằng tổng thời gian các bước, và nếu mỗi bước chậm với xác suất 1% thì xác suất gặp ít nhất một bước chậm vẫn là $1 - 0{,}99^k$.

13.7Rào chắn#

Rào chắn (guardrails) là các phép kiểm tra chạy quanh lượt gọi mô hình. Ở đầu vào, chúng phát hiện prompt injection, phát hiện và che dữ liệu cá nhân, chặn những yêu cầu nằm ngoài phạm vi của ứng dụng, và giới hạn tần suất gọi của mỗi người dùng. Ở đầu ra, chúng kiểm tra định dạng (JSON hợp lệ, đúng lược đồ), phát hiện nội dung có hại, kiểm tra câu trả lời có bám vào nguồn với hệ thống RAG, và áp đặt giới hạn hành động (Mục 10.4).

Giới hạn hành động cần được nhấn mạnh. Với một agent có quyền gọi các công cụ có tác động thật, như gửi email, hoàn tiền hay sửa dữ liệu, cơ chế giới hạn hành động của Sculley và cộng sự áp dụng nguyên vẹn: đặt giới hạn cho số hành động mỗi loại trong mỗi khoảng thời gian, và khi chạm giới hạn thì dừng lại, chuyển cho người xử lý. Một mô hình ngôn ngữ trả lời sai mà có quyền hoàn tiền gây hậu quả lớn hơn nhiều so với một mô hình chấm điểm sai. Chương 11 của Ứng dụng LLM trình bày chi tiết về prompt injection, dữ liệu nhạy cảm và rào chắn nội dung.

13.8Quản lý phiên bản#

Yếu tố phiên bản ở Mục 2.2 áp dụng cho ứng dụng LLM với một danh sách dài hơn. Một phiên bản của ứng dụng gồm ít nhất: prompt, kể cả prompt hệ thống và các ví dụ few-shot (Mục 4.7 của Ứng dụng LLM); phiên bản mô hình và các tham số sinh như nhiệt độ, top-p, số token tối đa; cấu hình truy xuất gồm mô hình embedding, cách chia đoạn, số đoạn $k$, bộ xếp hạng lại; ảnh chụp của kho tài liệu, tức chỉ mục được lập vào thời điểm nào; định nghĩa các công cụ mà agent được phép gọi; và tiêu chí chấm cùng tập đánh giá chuẩn đã dùng để duyệt phiên bản.

Thay đổi bất kỳ thành phần nào trong số đó là tạo ra một phiên bản mới và cần đánh giá lại. Đây là nguyên lý CACE ở Mục 1.3 áp dụng cho ứng dụng LLM: prompt, mô hình, kho tài liệu và công cụ phụ thuộc lẫn nhau, nên thay đổi một thành phần có thể thay đổi hành vi của cả hệ thống.

13.9Tóm tắt#

Vận hành ứng dụng LLM giữ nguyên phần lớn nguyên tắc của các chương trước, nhưng có năm ràng buộc mới: không tự huấn luyện, đầu ra là văn bản tự do, mô hình của nhà cung cấp có thể thay đổi, chi phí tính theo token và có thêm rủi ro về nội dung. Đánh giá được chia thành ba tầng, kiểm tra theo quy tắc, giám khảo LLM và người chấm, trong đó giám khảo LLM có các thiên lệch đã biết và phải được đối chiếu định kỳ với người. Với hệ thống RAG, lỗi truy xuất và lỗi sinh cần được tách riêng. Chi phí cần được ghi theo từng thành phần, rào chắn cần có giới hạn hành động khi agent có quyền tác động thật, và mỗi thay đổi của prompt, mô hình, kho tài liệu hay công cụ là một phiên bản mới.

Đây là chương cuối của phần lý thuyết. Các chương sau gồm bài tập để luyện tập các phép tính và thiết kế đã gặp, câu hỏi phỏng vấn để ôn lại toàn bộ giáo trình, và danh sách tài liệu tham khảo.