Tại sao các kỹ sư AI đang chuyển dịch từ LangChain sang kiến trúc Agent tự phát triển

Gần đây, tôi đã dành nhiều thời gian để suy ngẫm về chủ đề này, và nó đã gợi nhớ lại những kinh nghiệm từ một số dự án tôi từng tham gia.

Hãy tưởng tượng một tình huống khá phổ biến: bạn triển khai một tính năng được hỗ trợ bởi LLM, bản demo diễn ra suôn sẻ và mọi bên liên quan đều hài lòng. Nhưng rồi, chỉ sau ba tuần đưa vào môi trường sản xuất (production), hệ thống gặp sự cố theo một cách mà không ai có thể giải thích được.

Bạn dành cả buổi chiều để dán mắt vào các bản ghi nhật ký (logs), chúng cho bạn biết điều gì đã xảy ra nhưng không nói rõ lý do tại sao. Cuối cùng, bạn phát hiện ra rằng khung làm việc (framework) đã "nuốt chửng" ngữ cảnh ở đâu đó giữa bước thứ ba và bước thứ tư, và giờ đây bạn đang phải đọc mã nguồn mà chính bạn không phải là người viết ra.

Đó không đơn thuần là một báo cáo lỗi, mà là một lời cảnh tỉnh về kiến trúc.

Các framework như LangChain cho phép các kỹ sư xây dựng hệ thống dựa trên LLM mà không cần trước đó hiểu rõ cách thức hoạt động của những hệ thống đó dưới áp lực thực tế. Lúc đầu, điều đó nghe có vẻ như một giải pháp cứu cánh tuyệt vời.

Nhưng tin tôi đi, cái giá phải trả sẽ không hiện ra cho đến khi bạn lún sâu vào một sự cố sản xuất nghiêm trọng, và lúc đó bạn bị mắc kẹt tự hỏi tại sao tác nhân (agent) của mình lại bỏ qua bước xác minh mà nó lẽ ra phải chạy.

Bài viết này nói về cái giá đó và lý do tại sao ngày càng nhiều kỹ sư, sau khi nhận ra vấn đề, đang tự xây dựng lớp điều phối (orchestration layer) của riêng họ.

Công nhận vai trò của LangChain

Tôi nhớ rằng vào đầu năm 2023, tôi đã chứng kiến một đồng nghiệp xây dựng một quy trình RAG hoàn chỉnh chỉ trong khoảng bốn mươi phút. Anh ấy đi từ kho vector (vector store), qua chuỗi truy xuất (retrieval chain), mẫu prompt (prompt templates), và cuộc gọi LLM, tất cả được kết nối trước giờ ăn trưa.

Sáu tháng trước đó, dự án đó sẽ mất ít nhất hai tuần để hoàn thành.

Nhìn lại, đó thực sự là cách và lý do LangChain lan truyền nhanh chóng đến vậy. Hầu hết các kỹ sư trước đó chưa từng xây dựng ứng dụng LLM. Không ai có ý kiến mạnh mẽ về cách đúng đắn để cấu trúc một chuỗi truy xuất hay quản lý bộ nhớ hội thoại và những thứ tương tự.

LangChain xuất hiện với các câu trả lời mang tính mô-đun, có thể kết hợp (composable) và được tài liệu hóa rõ ràng, và tất nhiên, các đội ngũ đã ngay lập tức áp dụng, bao gồm cả đội của tôi.

Vì vậy, khi tôi nói rằng nó tạo ra các vấn đề trong môi trường sản xuất, tôi không có ý phủ nhận giá trị của nó. Nó được tối ưu hóa cho giai đoạn mà hầu hết các đội ngũ đang trải qua khi họ áp dụng nó. Các vấn đề xuất hiện sau đó, khi giai đoạn thay đổi.

Khi sự trừu tượng hóa bị phá vỡ

Khi tôi đang học lập trình hướng đối tượng vào năm thứ hai đại học, một trong những khái niệm đầu tiên tôi hiểu rõ là sự trừu tượng hóa (abstraction): che giấu các chi tiết nội bộ về cách thức hoạt động của một thứ gì đó và chỉ hiển thị những gì người dùng cần.

LangChain áp dụng ý tưởng tương tự cho việc điều phối LLM. Nó che giấu rất nhiều điều đang diễn ra bên trong hệ thống của bạn để bạn có thể di chuyển nhanh hơn.

Tuy nhiên, các hệ thống AI trong môi trường sản xuất đòi hỏi điều gì đó đi ngược lại điều đó: sự rõ ràng (clarity). Bạn cần biết chính xác hệ thống của mình đã làm gì, theo thứ tự nào, với đầu vào nào, và tại sao. Không phải đại khái, mà là chính xác.

Sự trừu tượng hóa đánh đổi khả năng hiển thị đó để lấy tốc độ. Đó là một giao dịch công bằng lúc đầu, cho đến khi sự phức tạp bị ẩn giấu trở thành chính thứ bạn cần hiểu.

Và nó biểu hiện theo nhiều cách khác nhau.

Việc gỡ lỗi (Debugging) tồi tệ hơn bạn nghĩ: Khi một chuỗi đa bước đưa ra đầu ra sai, bạn không chỉ đang gỡ lỗi mã của chính mình. Bạn cũng đang cố gắng hiểu luồng thực thi của framework và lớp callback đang làm gì đằng sau hậu trường.

Tôi từng dành ba giờ để theo dõi một lỗi hóa ra là do mô-đun bộ nhớ âm thầm cắt bỏ ngữ cảnh. Bản sửa lỗi chỉ mất bốn phút. Nhưng việc tìm ra nguyên nhân mất nửa ngày vì sự trừu tượng hóa đã làm cho hành vi thực tế trở nên vô hình.

Khả năng quan sát (Observability) gặp trần kính: Bạn có thể tích hợp LangSmith và nhận được các dấu vết hữu ích, nhưng bạn vẫn đang nhìn mọi thứ qua "lăng kính" của framework, bị giới hạn trong các khoảng (spans) mà nó chọn để hiển thị. Khi bạn cần khả năng hiển thị vào một cái gì đó cụ thể liên quan đến logic kinh doanh của mình, bạn kết thúc bằng cách phải làm việc xung quanh mô hình dữ liệu của framework thay vì chỉ đo lường những gì thực sự quan trọng.

Trạng thái đa tác nhân (Multi-agent state) là nơi mọi thứ thực sự sụp đổ: Ngay khi bạn có các tác nhân phối hợp với nhau, người này lập kế hoạch, người khác thực thi, và một người nữa xác minh, trạng thái chia sẻ trở thành vấn đề thực sự.

Ai đã tạo ra thông tin này, khi nào, và nó còn hợp lệ không? Một tác nhân cập nhật bộ nhớ, một tác nhân khác đọc phiên bản cũ (stale), và người điều phối đưa ra quyết định dựa trên ngữ cảnh không còn phù hợp với thực tế.

Trạng thái được quản lý bởi framework thường hoạt động tốt cho các kịch bản "hạnh phúc" (happy path) và âm thầm sụp đổ ở các trường hợp ngoại lệ (edge cases). Các hệ thống sản xuất sống trong những trường hợp ngoại lệ đó.

Độ trễ (Latency) tích lũy: Mỗi lớp trừu tượng đều thêm chi phí thông qua tuần tự hóa (serialization), xác thực, kích hoạt callback và định tuyến nội bộ chạy cho dù bạn cần hay không.

Trong một nguyên mẫu, chi phí đó vô hình. Dưới lưu lượng truy cập thực tế, nó xuất hiện trong độ trễ phần trăm, cụ thể là ở các mức p95 và p99 nơi người dùng thực sự cảm nhận được.

Chi phí cho mỗi cuộc gọi có thể nhỏ, nhưng trong một hệ thống tác nhân thực hiện bốn, năm hoặc thậm chí sáu cuộc gọi mô hình cho mỗi yêu cầu của người dùng, những chi phí nhỏ đó tích tụ nhanh chóng.

Tại một điểm nào đó, bạn phải tự hỏi liệu chi phí đó có còn đáng giá với những gì nó mang lại hay không.

Không có điều nào trong số này là không thể giải quyết được bên trong một framework. Nhưng các bản sửa lỗi bắt đầu trông giống như việc cố gắng "lách luật" framework thay vì làm việc cùng nó. Và một khi bạn đến được điểm đó, sẽ khó khăn hơn để biết framework đang mang lại cho bạn điều gì.

Vậy việc "Tự xây dựng" trông như thế nào?

"Kiến trúc tác nhân gốc" (Native agent architecture) nghe có vẻ phức tạp hơn thực tế. Nó đơn giản có nghĩa là bạn tự viết logic điều phối dưới dạng mã của riêng bạn, thay vì dựa vào sự trừu tượng hóa của framework.

Trạng thái là thứ bạn định nghĩa và cập nhật một cách rõ ràng. Các công cụ (tools) là các hàm rõ ràng mà bạn có thể kiểm tra độc lập. Bộ nhớ là mã do bạn viết, vì vậy việc gỡ lỗi, kiểm soát và hiểu những gì được lưu trữ cũng như cách nó được truy xuất sẽ dễ dàng hơn.

Cuộc gọi mô hình là mã của bạn, điều này có nghĩa là bạn có thể đo lường nó trực tiếp và truy xuất những gì quan trọng.

Chắc chắn, sẽ có nhiều mã hơn ở giai đoạn đầu. Nhưng khi có sự cố, lỗi nằm trong mã của bạn chứ không phải ở đâu đó bên trong mô hình thực thi do người khác viết.

Đừng quên rằng, các luồng công việc phức tạp ánh xạ tự nhiên hơn ở đây. Những thứ như thực thi song song, rẽ nhánh có điều kiện và các tác vụ không đồng bộ chạy lâu dài (long-running async tasks) hoạt động tốt hơn nhiều trong các mô hình hướng sự kiện (event-driven patterns), theo những cách mà thực thi chuỗi đồng bộ không xử lý sạch sẽ.

Thiết kế nhiều hơn ở giai đoạn đầu có nghĩa là ít phải "chữa cháy" hơn sau này.

Tôi đã thấy các đội ngũ xây dựng lại một nguyên mẫu LangChain hoàn hảo thành một lớp điều phối tùy chỉnh chỉ vì kiến trúc gốc trông "nghiêm túc" hơn. Họ dành thêm ba tuần để làm điều đó và triển khai cùng một hệ thống với nhiều mã hơn để bảo trì.

Đối với tôi, đó không phải là tiến bộ.

Nếu bạn đang kiểm tra xem một tính năng có đáng để xây dựng hay không, thì một framework sẽ giúp bạn đến đó nhanh hơn. Nếu ba người sử dụng hệ thống nội bộ và không ai phải trực pager (nhận cảnh báo sự cố), chi phí trừu tượng hóa thì ổn.

Câu hỏi không phải là "framework hay gốc?" mà là bạn cần tối ưu hóa cho cái gì ngay bây giờ. Lặp lại nhanh chóng trên các yêu cầu chưa chắc chắn có nghĩa là framework hợp lý. Người dùng thực, SLA thực sự, điều phối tác nhân và giám sát vận hành có nghĩa là kiến trúc gốc đáng giá với chi phí đầu tư ban đầu của nó.

Hầu hết các đội ngũ đến điểm chuyển đổi sớm hơn họ mong đợi, thường là trong buổi gỡ lỗi nghiêm trọng đầu tiên hoặc lần đầu tiên ai đó yêu cầu các chỉ số chi tiết, và câu trả lời trung thực là "không thể mà không cần thêm nhiều công việc".

Đó là lúc cần suy nghĩ lại về kiến trúc, không phải sau sáu tháng tích lũy các giải pháp tạm thời.

Các framework là cách thức chuyển giao kiến thức trong một lĩnh vực mới. LangChain đã làm cho việc phát triển ứng dụng LLM trở nên dễ tiếp cận đối với một thế hệ kỹ sư. Đóng góp đó là có thật.

Nhưng sự trưởng thành trong một lĩnh vực trông giống như việc chuyển từ "tôi cấu hình framework để làm việc đó" sang "tôi hiểu framework đang làm gì, và tôi tự đưa ra các quyết định đó".

Không phải vì các framework xấu, mà vì việc sở hữu kiến trúc của bạn có nghĩa là bạn biết điều gì đang xảy ra dưới "mui xe".

Những kỹ sư xây dựng các hệ thống AI sản xuất đáng tin cậy nhất không phải là những người có công cụ tinh vi nhất. Họ là những người có thể giải thích chính xác hệ thống của họ làm gì tại bất kỳ điểm nào. Prompt nào được xây dựng, từ ngữ cảnh nào, trong điều kiện nào, và với phương án dự phòng nào.

Sự rõ ràng đó rất khó duy trì thông qua các lớp trừu tượng dày đặc.

Lời kết

Nợ trừu tượng (Abstraction debt) rất im lặng cho đến khi nó trở nên ồn ào. Bạn sẽ không nhận thấy nó trong quá trình xây dựng. Bạn sẽ nhận thấy nó khi một thứ gì đó thất bại theo cách mà thông báo lỗi của framework không thể giải thích.

Khoảnh khắc đó đến sớm hơn bạn mong đợi, thường được kích hoạt bởi một phiên gỡ lỗi hoặc một yêu cầu giám sát thay vì một cuộc họp lập kế hoạch.

Trạng thái và khả năng quan sát không phải là tùy chọn. Nếu bạn không thể truy xuất tác nhân của mình đã làm gì và tại sao, bạn thực sự không đang cải thiện hệ thống. Bạn chỉ đang hy vọng vào điều tốt nhất mỗi khi bạn triển khai lại.

Hãy coi việc điều phối là một quyết định kiến trúc thực sự. Hãy chọn nó một cách có chủ đích, với các sự đánh đổi được nhìn thấy rõ ràng.

Những kỹ sư xây dựng các hệ thống AI bền vững không phải là những người tránh xa các framework. Họ là những người biết khi nào nên ngừng để framework quyết định thay họ.