Xây dựng ứng dụng LLM: Tại sao bạn có thể không cần một Agent Framework phức tạp

Bạn muốn xây dựng một ứng dụng LLM. Ý tưởng đầu tiên xuất hiện trong đầu thường là: hãy xây dựng một tác nhân (agent) mạnh mẽ!

Nhưng ngay lập tức, bạn tự hỏi: mình nên sử dụng framework nào? CrewAI? LangGraph? Microsoft Agent Framework? Hay cái gì khác? Bạn mở vài trang tài liệu, so sánh các ví dụ và cố gắng quyết định. Vài giờ trôi qua, bạn cảm thấy quá tải và thậm chí chưa viết được một dòng code nào.

Nhưng hãy đợi một chút: Bạn có thực sự cần một agent framework ở đây không? Thực tế là, bạn có thậm chí cần xây dựng một LLM agent không?

Trong hai năm qua, tôi đã xây dựng khá nhiều ứng dụng LLM trong các lĩnh vực khác nhau. Một bài học tôi rút ra là rằng đối với nhiều ứng dụng LLM hữu ích, thứ hoạt động đáng tin cậy cuối cùng không phải là một tác nhân tự trị. Đó là workflow (quy trình làm việc). Và để xây dựng các workflow đó, bạn thậm chí có thể không cần bất kỳ framework nào.

Trong bài viết này, tôi sẽ chỉ cho bạn cách tạo mẫu một workflow LLM sử dụng Python thuần, các hàm cục bộ, đầu ra có cấu trúc và OpenAI Responses API (mô hình này cũng áp dụng cho các nhà cung cấp LLM khác). Chúng ta sẽ cùng thực hành giải quyết một vấn đề giải thích bất thường.

Mục tiêu của tôi không phải là lập luận rằng các framework là xấu. Chúng rõ ràng hữu ích trong nhiều tình huống. Mục tiêu là chỉ ra rằng đối với nhiều ứng dụng, một workflow rõ ràng có thể là sự trừu tượng hóa đầu tiên bạn thực sự cần.

1. Ưu tiên Workflow trước khi nhảy vào Agent

Một LLM agent thường đề cập đến một hệ thống tự trị có thể tự quyết định việc cần làm tiếp theo. Bạn đưa cho nó một mục tiêu và một bộ công cụ. Nó sẽ lập kế hoạch, hành động, quan sát kết quả và tiếp tục lặp lại. Thay vì theo một đường dẫn cố định, agent tự động chọn bước tiếp theo dựa trên tình huống hiện tại. Đối với các vấn đề mở, điều này rất mạnh mẽ.

Tuy nhiên, nhiều vấn đề trong thế giới thực không quá mở. Trong nhiều trường hợp, chúng ta biết đại khích cách vấn đề nên được giải quyết. Nhưng nếu chúng ta đã biết điều đó, tại sao lại yêu cầu mô hình phải "phát minh lại chiếc xe"?

Đây là lúc workflow phát huy tác dụng.

Trong một workflow LLM, chúng ta - các nhà phát triển - định nghĩa các bước chính, và LLM được sử dụng bên trong các bước đã chọn như một động cơ suy luận. Về bản chất, đây vẫn là một ứng dụng được hỗ trợ bởi LLM. Sự khác biệt là LLM không được coi là toàn bộ hệ thống, mà chỉ là một nút quyết định bên trong một quy trình lớn hơn.

Vậy lợi ích của việc áp dụng workflow LLM là gì?

• Workflow trong suốt: Bạn có thể dễ dàng kiểm tra từng bước vì mỗi bước có vai trò được xác định rõ ràng và hợp đồng đầu vào/đầu ra rõ ràng.
• Workflow mô-đun: Bạn có thể thay đổi một bước mà không cần viết lại toàn bộ ứng dụng.
• Quan trọng nhất: Workflow có luồng điều khiển xác định (deterministic). Suy luận và quyết định của LLM có thể thay đổi bên trong một bước, nhưng đường dẫn tổng thể do mã code kiểm soát. Điều này loại bỏ rất nhiều sự không chắc chắn khi cố gắng xây dựng một thứ gì đó đáng tin cậy.

Tôi biết, điều này nghe có vẻ kém thú vị hơn việc xây dựng một agent hoàn toàn tự trị. Nhưng mục tiêu của bạn là cung cấp một giải pháp hiệu quả. Nếu những điều nhàm chán hoạt động tốt, chúng ta nên vui vẻ sử dụng chúng.

2. Những yếu tố thực sự cần thiết để thiết kế

Theo kinh nghiệm của tôi, có bốn thành phần chính:

1. Luồng điều khiển (Control flow)
2. Hướng dẫn vai trò (Role instructions / system prompts)
3. Trình tạo prompt (Prompt builders)
4. Đầu ra có cấu trúc (Structured output)

2.1 Luồng điều khiển

Luồng điều khiển định nghĩa cách ứng dụng di chuyển từ đầu vào đến đầu ra. Một cách hữu ích để nghĩ về luồng điều khiển là xem nó như một đồ thị. Trong đồ thị này, chúng ta có các nút (nodes) và các cạnh (edges):

• Nodes: Mỗi nút đại diện cho một bước trong ứng dụng. Nó có thể là một bước xử lý xác định bởi code (ví dụ: tải dữ liệu, gọi hàm cục bộ) hoặc một bước LLM, nơi LLM được sử dụng để đưa ra quyết định, trích xuất thông tin hoặc viết giải thích.
• Edges: Mỗi cạnh đại diện cho cách thông tin di chuyển từ bước này sang bước tiếp theo. Cạnh có thể là tĩnh (luôn gọi bước tiếp theo được xác định trước) hoặc có điều kiện (ví dụ: nếu LLM nói cần thêm bằng chứng, cạnh liên kết đến nút công cụ cục bộ).

Điểm chính: trong một workflow, code sở hữu đồ thị này. LLM bị ràng buộc với các nút cụ thể thay vì chạy tự do.

2.2 Hướng dẫn vai trò

Một workflow thường sử dụng LLM trong một số vai trò, và mỗi vai trò cần hướng dẫn riêng (system prompts). Hướng dẫn vai trò định nghĩa cách LLM nên hành xử bên trong một nút cụ thể, bao gồm nhân cách, nhiệm vụ, những gì cần chú ý và những gì cần tránh.

2.3 Trình tạo prompt

Trong khi hướng dẫn vai trò định nghĩa hành vi, trình tạo prompt quyết định LLM có thể nhìn thấy gì. Về bản chất, đây là một hàm: nhận các giá trị động từ workflow hiện tại, xử lý chúng và đưa vào mẫu prompt. Đây là nơi chúng ta kiểm soát cửa sổ ngữ cảnh (context window).

2.4 Đầu ra có cấu trúc

Trong workflow, đầu ra của LLM thường là kết quả trung gian được bước tiếp theo tiêu thụ. Việc để LLM xuất ra văn bản tự do không phải là ý tưởng tốt vì nó làm cho việc phân tích cú pháp downstream trở nên mong manh.

Cách tiếp cận tốt hơn là yêu cầu LLM trả về đầu ra có cấu trúc tuân theo lược đồ dữ liệu được xác định trước, thường là đối tượng JSON hoặc mô hình Pydantic. Lược đồ này là hợp đồng giữa các bước LLM.

3. Xây dựng một Workflow thực tế

Ở đây, chúng ta sẽ xây dựng một workflow điều tra chất lượng dữ liệu nhỏ sử dụng tập dữ liệu Iris. Trong thực tế, chúng ta thường cần sàng lọc các tập dữ liệu và đánh dấu các bản ghi đáng ngờ trước khi đưa vào huấn luyện mô hình. Nhưng chỉ đánh dấu là chưa đủ; chúng ta muốn hiểu lý do "tại sao": đó có thực sự là vấn đề chất lượng dữ liệu không và bằng chứng nào hỗ trợ đánh giá đó?

Workflow của chúng ta có hai vai trò LLM:

1. LLM Investigator (Điều tra viên): Xác định bằng chứng chẩn đoán nào cần thu thập tiếp theo.
2. LLM Explainer (Người giải thích): Nhận bằng chứng đã thu thập và đưa ra đánh giá cuối cùng.

Chúng ta sẽ xây dựng workflow này mà không sử dụng bất kỳ framework agent nào.

Sơ đồ luồng làm việc LLM

Bước 1: Sàng lọc mẫu đáng ngờ

Bước này sử dụng logic phát hiện đơn giản để gắn cờ các mẫu dữ liệu bất thường. Chúng ta tính toán z-scores cho từng mẫu so với các mẫu có cùng nhãn loài. Mẫu hàng 55 được xác định đúng là mẫu chúng ta đã sửa đổi.

Bước 2: Thu thập bằng chứng lặp lại

Ở bước này, chúng ta muốn LLM thu thập đủ bằng chứng trước khi cố gắng giải thích mẫu bất thường. Chúng ta cấu hình vai trò LLM Investigator để thực hiện nhiệm vụ này.

Chúng ta cung cấp cho điều tra viên hai công cụ cục bộ:

1. compare_row_to_species_profile: So sánh mẫu với hồ sơ loài bằng z-scores.
2. find_nearest_neighbors: Tìm các mẫu gần nhất bằng mô hình KNN.

Vòng lặp điều tra được triển khai trực tiếp trong Python. Sau mỗi lần gọi LLM, Python sẽ thực thi hàm cục bộ được chọn và thêm kết quả vào danh sách bằng chứng.

Bước thu thập bằng chứng

Bước 3: Giải thích mẫu đã gắn cờ

Với bằng chứng đã thu thập, bước cuối cùng là yêu cầu một LLM khác giải thích bằng chứng và tạo đánh giá.

Bước giải thích của LLM

Chúng ta định nghĩa một lược đồ đầu ra có cấu trúc cho LLM Explainer, bao gồm các trường như assessment (đánh giá), confidence (mức độ tin cậy), và explanation (giải thích).

4. Khi nào thực sự cần Agent hoặc Framework?

Cho đến nay, chúng ta đã cố tình tránh cả agent và framework. Nhưng điều đó không có nghĩa là chúng vô dụng. Chỉ là vấn đề nằm ở loại bài toán chúng ta đang giải quyết.

4.1 Khi bạn thực sự cần một Agent

Câu trả lời ngắn gọn: Khi bạn không biết đường dẫn giải pháp tốt nhất trước. Điều này xảy ra trong hai trường hợp:

1. Bạn đơn giản không biết cách giải quyết vấn đề (không có quy trình thiết lập).
2. Không gian các đường dẫn khả thi quá rộng để liệt kê bằng tay.

Tuy nhiên, hãy nhớ rằng khi sử dụng LLM agents, bạn có được sự linh hoạt nhưng đánh đổi bằng độ tin cậy và khả năng gỡ lỗi.

4.2 Khi bạn thực sự cần một Framework

Ngay cả khi bạn quyết định workflow là hình thức đúng, bạn vẫn có thể cần một framework để xây dựng nó. Phiên bản Python thuần rất tuyệt để tạo mẫu nhanh (prototyping). Tuy nhiên, khi chuyển sang môi trường sản xuất (production), các framework cung cấp khả năng xử lý lỗi tốt hơn, khả năng quan sát, kiểm soát của con người và tính bền vững.

Tóm lại, framework rất tốt để giải quyết các vấn đề bạn gặp phải sau khi ý tưởng của bạn đã hoạt động.

5. Kết luận

Đối với nhiều ứng dụng LLM hữu ích, thứ bạn cần đầu tiên có thể không phải là một agent tự trị hay một framework nặng ký. Những gì bạn cần là một workflow rõ ràng, với luồng điều khiển, hướng dẫn vai trò, trình tạo prompt, đầu ra có cấu trúc và mã code Python để kết nối chúng lại.

Hãy bắt đầu đơn giản, xác thực ý tưởng chính nhanh chóng, sau đó thêm độ phức tạp chỉ khi vấn đề đòi hỏi.