Mảnh ghép còn thiếu trong các cuộc thảo luận về AI
Mọi người đều đang nói về các tác nhân AI (AI agents). Lướt qua bất kỳ nguồn tin công nghệ nào, bạn cũng sẽ thấy hàng tá bản demo cho thấy một mô hình ngôn ngữ lớn có thể đặt vé máy bay, viết mã hoặc trả lời các yêu cầu hỗ trợ chỉ trong một cuộc hội thoại đầy ấn tượng. Thông điệp ngầm định có vẻ rõ ràng: nếu bạn kết nối người dùng với một LLM, phép màu sẽ xảy ra.
Ảo tưởng đó hoạt động rất tốt cho một bản demo kéo dài năm phút. Nhưng nó sẽ sụp đổ ngay khi người dùng thật, dữ liệu thật và tiền thật xuất hiện. Trong môi trường production, mối quan hệ không bao giờ chỉ là Người dùng ↔ LLM. Đó là Người dùng ↔ một hệ thống phức tạp có chứa một LLM. Phần của hệ thống đó mà không ai nhắc đến chính là hệ thống điều phối (harness)—khung nâng đỡ giúp lựa chọn, định tuyến, bảo vệ và điều phối mọi thứ xung quanh mô hình. Không có nó, bạn không có một sản phẩm. Bạn chỉ có một bản mẫu (prototype).
Tại sao vòng lặp đơn giản lại thất bại
Một bản demo là một môi trường được kiểm soát. Các truy vấn ngắn, ngữ cảnh hạn chế và rủi ro thấp. Nhà phát triển thực hiện một lệnh gọi API duy nhất, nhận lại phản hồi mượt mà, và khán giả vỗ tay. Nhưng môi trường production thì hỗn loạn. Người dùng đặt những câu hỏi tiếp nối mơ hồ. Các API bên thứ ba bị hết thời gian chờ (timeout). Một mô hình hôm qua vừa tạo ra JSON hoàn hảo thì hôm nay đột nhiên lại xuất ra markdown. Cửa sổ ngữ cảnh (context windows) bị đầy. Giới hạn tốc độ (rate limits) bị kích hoạt vào thời điểm tồi tệ nhất.
Một vòng lặp câu lệnh-phản hồi thô không có câu trả lời cho bất kỳ vấn đề nào trong số này. Nó không biết biến thể mô hình nào nên xử lý một tác vụ nhất định. Nó không nhớ những gì đã xảy ra ba lượt trước. Nó không thể thử lại một lệnh gọi bị lỗi, tiết chế các yêu cầu khi chi phí tăng vọt, hoặc làm sạch đầu ra trước khi nó đi vào cơ sở dữ liệu của bạn. Đây không phải là các trường hợp biên. Chúng là những đặc điểm định hình nên phần mềm trong thế giới thực. Xử lý chúng chính là nhiệm vụ của hệ thống điều phối.
Hệ thống điều phối thực sự làm gì
Hãy coi hệ thống điều phối như một lớp kỹ thuật giúp biến một mô hình ngôn ngữ từ một trình tạo văn bản thông minh thành một thành phần dịch vụ đáng tin cậy. Trách nhiệm của nó rất cụ thể và không hề hào nhoáng, đó chính là lý do tại sao chúng thường bị bỏ qua.
Lựa chọn mô hình cho tác vụ hiện tại. Không phải mọi tương tác đều cần mô hình nền tảng mạnh mẽ nhất hiện có. Một số công việc đòi hỏi khả năng suy luận thuần túy; số khác chỉ cần tốc độ và chi phí thấp. Một hệ thống điều phối được xây dựng tốt sẽ định tuyến các yêu cầu một cách thông minh. Ví dụ, một tác nhân hỗ trợ khách hàng có thể sử dụng một mô hình nhanh, rẻ để phân loại ý định của tin nhắn đến—yêu cầu hoàn tiền so với câu hỏi về vận chuyển. Nếu ý định cho thấy một tranh chấp chính sách phức tạp, hệ thống điều phối sẽ chuyển tác vụ đó lên một mô hình suy luận mạnh hơn. Nếu người dùng chỉ muốn một liên kết theo dõi, mô hình nhẹ sẽ trả lời ngay lập tức và tốc độ tiêu thụ chi phí của bạn vẫn ở mức kiểm soát được.
Xử lý luồng dữ liệu. Các ứng dụng thực tế không tồn tại trong chân không. Một tác nhân AI thường cần lấy tài liệu từ kho lưu trữ vector, truy vấn CRM, đọc hoạt động gần đây của người dùng, và sau đó tổng hợp tất cả thành một phản hồi mạch lạc. Hệ thống điều phối quản lý quá trình nạp dữ liệu đó. Nó lấy các đoạn ngữ cảnh phù hợp, kiểm tra xem chúng có nằm trong giới hạn token mà không làm mất đi tính liên quan hay không, cấu trúc chúng cho mô hình, và chuyển đầu ra thu được đến hệ thống tiếp theo trong chuỗi. Nếu không có sự điều phối này, mô hình sẽ bị thiếu hụt ngữ cảnh hoặc bị ngập trong nhiễu thông tin.
Quản lý lỗi. LLM gặp lỗi theo những cách mà các dịch vụ truyền thống không gặp phải. Chúng tạo ra các đầu ra có cấu trúc bị "ảo giác". Chúng trả về các phản hồi trống rỗng. Chúng vi phạm các hướng dẫn định dạng ngay khi phiên bản mô hình nền tảng thay đổi dù chỉ một chút. Hệ thống điều phối coi những lỗi này là hành vi có thể dự đoán được thay vì là những bất ngờ. Nó xác thực các schema, bắt các phản hồi sai định dạng, áp dụng logic thử lại với cơ chế chờ đợi lũy thừa (exponential backoff), và chuyển sang nhà cung cấp phụ hoặc kết quả đã lưu trong bộ nhớ đệm khi điểm cuối chính gặp sự cố. Khi mọi thứ khác đều thất bại, nó sẽ chuyển lên cho người vận hành thay vì âm thầm cung cấp những thông tin vô nghĩa cho khách hàng đang trả tiền.
Đảm bảo độ tin cậy của hệ thống. Môi trường production đồng nghĩa với việc có nhiều người dùng đồng thời, giới hạn chi phí và độ trễ không thể dự đoán. Hệ thống điều phối thực thi các giới hạn tốc độ, quản lý việc gom nhóm kết nối (connection pooling) và triển khai các bộ ngắt mạch (circuit breakers) để một nhà cung cấp mô hình chậm chạp không thể làm đóng băng toàn bộ ứng dụng của bạn. Nó ghi lại mọi tương tác để bạn có thể truy vết lý do tại sao một phiên làm việc cụ thể bị chệch hướng, và nó quản lý các phiên bản câu lệnh (prompt versioning) để việc triển khai không vô tình viết lại tính cách của tác nhân mà không có dấu vết kiểm tra (audit trails).
Cùng một mô hình, kết quả hoàn toàn khác biệt
Điều này giải thích một hiện tượng khiến nhiều đội ngũ sản phẩm bối rối. Hai công ty có thể bắt đầu với cùng một mô hình nền tảng—cùng trọng số, cùng cửa sổ ngữ cảnh, cùng thời điểm dừng huấn luyện—nhưng lại mang đến những trải nghiệm khác biệt hoàn toàn. Một bên mang lại cảm giác mong manh, chậm chạp và hay quên một cách kỳ lạ. Bên còn lại mang lại cảm giác nhanh nhạy, nhất quán và đáng tin cậy.
Sự khác biệt không bao giờ nằm ở bản thân mô hình. Nó nằm ở hệ thống bao quanh nó. Một đội ngũ coi mô hình là toàn bộ sản phẩm. Đội ngũ còn lại coi nó chỉ là một thành phần trong một kiến trúc có kỷ luật. Khung vận hành chính là nơi sự kỷ luật đó tồn tại.
Sự chuyển dịch từ Prompt sang Kiến trúc
Giai đoạn đầu của phát triển AI đặt kỹ thuật prompt (prompt engineering) vào vị trí trung tâm. Việc tinh chỉnh câu chữ, thêm ví dụ và lồng ghép các hướng dẫn nhập vai có thể cải thiện đáng kể chất lượng đầu ra. Kỹ năng đó vẫn quan trọng, nhưng nó đã chạm đến ngưỡng hiệu suất giảm dần khi xét về khía cạnh tạo ra lợi thế cạnh tranh bền vững. Bạn không thể dùng prompt để giải quyết vấn đề của một chính sách thử lại (retry policy) còn thiếu, hay một đường ống dữ liệu (data pipeline) lộn xộn đang làm rò rỉ ngữ cảnh riêng tư vào các phản hồi công khai.
Sự chuyển dịch thực sự đang diễn ra chính là hướng tới kiến trúc phần mềm. Các kỹ sư đang thiết kế các máy trạng thái (state machines), định nghĩa các giao diện nghiêm ngặt giữa lớp mô hình và logic ứng dụng, đồng thời coi tính không xác định (non-determinism) là một vấn đề kỹ thuật trọng yếu. Họ đang đặt ra các câu hỏi về hệ thống phân tán: Làm thế nào để duy trì trạng thái qua một cuộc hội thoại nhiều lượt? Điều gì xảy ra khi một công cụ hạ nguồn không khả dụng? Làm thế nào để kiểm thử một hệ thống mà thành phần cốt lõi của nó mang tính xác suất? Đây chính là những câu hỏi phân biệt giữa một món đồ chơi và một công cụ thực thụ.
Xây dựng cho Production: Khả năng quan sát và Điều phối
Nếu bạn thực sự nghiêm túc về việc đưa sản phẩm ra thị trường, khung vận hành đòi hỏi hai phẩm chất trên hết: khả năng quan sát (observability) và sự điều phối (orchestration).
Khả năng quan sát có nghĩa là bạn có thể thấy mô hình đã nhận được gì, nó đã trả về gì và mỗi bước mất bao lâu. Nó có nghĩa là truy vết vòng lặp quyết định của một agent qua mười bốn lần gọi công cụ và phát hiện chính xác nơi nó bắt đầu lặp vô tận hoặc đi chệch khỏi nhiệm vụ. Nếu không có khả năng hiển thị đó, việc gỡ lỗi một hệ thống AI giống như việc sửa động cơ ô tô trong bóng tối.
Sự điều phối có nghĩa là logic nghiệp vụ của bạn phải tách biệt với lớp tương tác mô hình. Nó có nghĩa là quản lý phiên bản (versioning) cho các prompt giống như cách bạn quản lý phiên bản mã nguồn, để một lần triển khai mới không làm thay đổi hành vi một cách âm thầm. Nó có nghĩa là chủ động kiểm thử các kịch bản lỗi—ngắt kết nối API giữa chừng, đưa vào các kết quả công cụ sai định dạng, mô phỏng việc tràn cửa sổ ngữ cảnh—để xem liệu khung vận hành có giữ cho hệ thống đứng vững hay không. Các framework có thể đến rồi đi, và dù bạn sử dụng một thư viện điều phối có sẵn hay tự xây dựng, tính kỷ luật quan trọng hơn tên thương hiệu.
Bài học cốt lõi
Các mô hình nền tảng sẽ tiếp tục cải tiến. Chúng sẽ nhanh hơn, rẻ hơn và mạnh mẽ hơn. Nhưng một động cơ mạnh mẽ hơn không thể sửa chữa một khung gầm bị hỏng. Những đội ngũ chiến thắng trong vài năm tới sẽ không phải là những đội ngũ có quyền truy cập vào mô hình xịn nhất. Họ sẽ là những người xây dựng được một khung vận hành đáng tin cậy, có khả năng quan sát và được điều phối tốt. Họ sẽ thay đổi mô hình mà không cần viết lại ứng dụng. Họ sẽ kiểm soát được chi phí vì khung vận hành quản lý mọi token. Họ sẽ ngủ ngon mỗi đêm vì hệ thống của họ có khả năng xử lý lỗi một cách êm đẹp.
Đừng quá ám ảnh về mô hình một cách tách biệt. Hãy bắt đầu ám ảnh về hệ thống vận hành nó. Tương lai thuộc về những kỹ sư xây dựng được các hệ thống thông minh hơn xung quanh các mô hình thông minh.
Bài viết này dựa trên những ý tưởng được thảo luận ban đầu bởi Abdulaziz Zos trong "Beyond The Model".
Để thảo luận thêm về kỹ thuật AI và thiết kế hệ thống, hãy tham gia cộng đồng học tập GyaanSetu.