LangChain4j & Spring AI: Hai framework chủ yếu để xây dựng ứng dụng LLM với Java
Khi bắt đầu tích hợp Large Language Models vào dự án Java, bạn sẽ nhanh chóng nhận ra rằng gọi trực tiếp API của OpenAI hay Anthropic là chưa đủ. Bạn cần một framework giúp xây dựng workflow phức tạp, quản lý prompt, xử lý streaming, tích hợp RAG (Retrieval-Augmented Generation), và vận hành trong môi trường production. Đó chính là lý do tại sao LangChain4j và Spring AI trở thành hai lựa chọn chủ yếu trong hệ sinh thái Java hiện nay.
Bản chất: Tại sao bạn cần framework thay vì gọi API trực tiếp?
Hãy tưởng tượng bạn xây dựng một chatbot hỗ trợ khách hàng cho một công ty fintech ở Hà Nội. Bạn không chỉ cần gửi câu hỏi đến LLM và nhận lại câu trả lời. Bạn cần:
- Tạo prompt động dựa trên dữ liệu khách hàng từ database.
- Lưu lịch sử cuộc trò chuyện để model hiểu ngữ cảnh.
- Tìm kiếm tài liệu liên quan trong vector database trước khi hỏi LLM.
- Cho phép model gọi các API khác (kiểm tra số dư, lịch sử giao dịch) khi cần.
- Xử lý lỗi và retry nếu API timeout.
- Ghi log chi tiết để debug và giám sát hiệu năng.
Viết tất cả điều này từ đầu là tốn thời gian và dễ xảy ra lỗi. Framework là giải pháp: chúng cấp cho bạn các abstraction đã được kiểm chứng và tái sử dụng được cho những bài toán thường gặp.
LangChain4j: Nhẹ, linh hoạt, và được thiết kế riêng cho Java
LangChain4j là một framework mã nguồn mở được xây dựng từ đầu cho Java, không phải là port từ Python. Điều này rất quan trọng: nó tôn trọng các tuy tế của hệ sinh thái Java như strong typing, dependency injection, và performance characteristics.
Cách làm việc cơ bản của LangChain4j xoay quanh khái niệm "chains" – một dãy các bước xử lý được kết nối với nhau. Ví dụ, một chain đơn giản có thể là: (1) Nhận input từ người dùng, (2) Tìm kiếm tài liệu liên quan, (3) Tạo prompt, (4) Gọi LLM, (5) Phân tích response.
Điểm mạnh của LangChain4j là API định hướng dịch vụ (AiServices API). Bạn định nghĩa một interface Java đơn giản với annotation:
@AiServices public interface CustomerSupportAgent { @SystemMessage("You are a helpful customer support assistant") @UserMessage("Help with: ") String answer(String query); }Framework tự động tạo implementation, xử lý tất cả gọi API, prompting, và response parsing. Bạn chỉ cần inject service này và dùng như một Java object thông thường. Cách tiếp cận này giảm drastically lượng boilerplate code.
LangChain4j cũng hỗ trợ tốt RAG thông qua DocumentLoader (đọc PDF, TXT, DOCX), DocumentSplitter (chia document thành chunks 300 token), Embedding (chuyển text thành vector), và ContentRetriever (tìm kiếm trong vector database). Nếu bạn muốn build một knowledge base tìm kiếm thông minh, LangChain4j cung cấp các building block cần thiết.
Một điểm khác biệt: LangChain4j không ràng buộc bạn vào Spring. Bạn có thể dùng nó trong bất kỳ ứng dụng Java nào – standalone, Quarkus, Micronaut, hoặc thậm chí backend với framework khác.
Spring AI: Tích hợp sâu vào Spring ecosystem
Spring AI là cách tiếp cận khác: nó là phần mở rộng của Spring Framework, được xây dựng với mục đích tích hợp LLM vào ứng dụng Spring Boot một cách tự nhiên nhất.
Nếu bạn đã quen làm việc với Spring Boot, Spring AI sẽ cảm thấy rất quen thuộc. Auto-configuration, dependency injection, và externalization của cấu hình – tất cả hoạt động theo cách Spring developer mong đợi.
Spring AI cung cấp ChatClient – một abstraction thống nhất để giao tiếp với bất kỳ LLM nào (OpenAI, Anthropic, Google Gemini, v.v.). Bạn không cần viết code khác nhau cho từng provider:
@RestController public class ChatController { private final ChatClient chatClient; public ChatController(ChatClient.Builder builder) { this.chatClient = builder.build(); } @GetMapping("/chat") public String chat(@RequestParam String message) { return chatClient.prompt() .user(message) .call() .content(); } }Điểm mạnh của Spring AI là vector store integration. Nó cung cấp abstraction cho Milvus, Weaviate, Qdrant, Pinecone và các database vector khác. Bạn có thể làm RAG mà không phải lo lắng chi tiết từng provider.
Spring AI cũng có structured output support – nó giúp bạn lấy kết quả từ LLM theo format JSON schema bạn định nghĩa, với validation tự động. Điều này rất hữu ích khi bạn muốn model trích xuất thông tin có cấu trúc.
Nhược điểm: bạn bị ràng buộc vào Spring ecosystem. Nếu dự án không dùng Spring Boot, bạn sẽ phải cân nhắc lại.
Chọn framework nào?
Nói thẳng ra:
- Chọn LangChain4j nếu: bạn muốn linh hoạt, không bị ràng buộc Spring, hoặc dự án có kiến trúc microservices phức tạp với nhiều framework khác nhau.
- Chọn Spring AI nếu: bạn đã là người dùng Spring Boot, muốn development experience gọn gàng, và các team của bạn quen Spring patterns.
Trong thực tiễn, tại các dự án tôi triển khai ở Việt Nam, khi team quen Spring Boot, Spring AI thường là lựa chọn nhanh hơn vì giảm learning curve. Tuy nhiên, nếu dự án cần integration với nhiều LLM provider hoặc xây dựng agent phức tạp, LangChain4j cung cấp abstractions mạnh mẽ hơn.
Điều quan trọng: cả hai framework đều là open source, có cộng đồng tích cực, và được dùng trong production ở các công ty lớn. Sự khác biệt nằm ở phong cách thiết kế và tích hợp, không phải ở chất lượng cơ bản.
Kết nối đa nhà cung cấp: OpenAI, Claude, Gemini qua SDK Java
Khi xây dựng ứng dụng AI trong môi trường enterprise, bạn thường không muốn bị "buộc" chỉ dùng một nhà cung cấp LLM duy nhất. Lý do rất thực tế: giá cả biến động, tính khả dụng có sự cố, hay đôi khi một mô hình lại phù hợp hơn cho task cụ thể. Đây chính là lý do tại sao tính linh hoạt trong việc kết nối nhiều nhà cung cấp LLM thành yếu tố then chốt trong kiến trúc hệ thống AI hiện đại.
Trong thực tiễn triển khai tại các doanh nghiệp Việt Nam, tôi thường gặp tình huống: công ty bắt đầu với OpenAI vì dễ dùng, nhưng sau vài tháng họ muốn thử Claude để so sánh chất lượng output, hoặc chuyển sang Gemini để tiết kiệm chi phí. Nếu kiến trúc code bạn "ghép chặt" vào một nhà cung cấp, việc chuyển đổi này sẽ tốn rất nhiều thời gian và chi phí. Ngược lại, nếu từ đầu bạn thiết kế với tính đa nhà cung cấp, việc thay đổi chỉ là thay đổi cấu hình mà thôi.
Kiến trúc trừu tượng: Tại sao cần abstraction layer
Bản chất của đa nhà cung cấp LLM trong Java là xây dựng một lớp abstraction ở giữa code logic của bạn và các API cụ thể từng nhà cung cấp. Thay vì trực tiếp gọi OpenAI SDK ở khắp nơi trong code, bạn tạo một interface thống nhất, và các implementation khác nhau cho từng nhà cung cấp.
Ví dụ, thay vì code như này (cứng nhắc, khó bảo trì):
// ❌ Cách làm sai: cứng nhắc vào OpenAI OpenAiChatModel chatModel = new OpenAiChatModel("sk-..."); String response = chatModel.generate("Hôm nay thời tiết như thế nào?"); Bạn nên thiết kế như này:
// ✅ Cách làm đúng: interface thống nhất public interface LlmProvider { String chat(String message); String generateEmbedding(String text); } public class OpenAiProvider implements LlmProvider { // Implement bằng OpenAI SDK } public class ClaudeProvider implements LlmProvider { // Implement bằng Anthropic SDK } public class GeminiProvider implements LlmProvider { // Implement bằng Google SDK } Cách tiếp cận này cho phép bạn dễ dàng thay đổi nhà cung cấp mà không cần sửa đổi code logic chính. Chỉ cần thay đổi bean configuration hoặc environment variable, ứng dụng của bạn sẽ chuyển sang nhà cung cấp khác ngay lập tức.
Các SDK chính và đặc điểm của từng nhà cung cấp
OpenAI SDK là lựa chọn phổ biến nhất. Nó hỗ trợ đầy đủ GPT-4, GPT-3.5, vision, embeddings. API rất ổn định và tài liệu chi tiết. Tuy nhiên, chi phí có thể cao hơn so với các nhà cung cấp khác nếu volume request lớn.
// OpenAI SDK import com.openai.client.OpenAIClient; import com.openai.models.ChatCompletion; OpenAIClient client = new OpenAIClient("sk-..."); ChatCompletion response = client.chat().completions() .create(ChatCompletionCreateParams.builder() .model("gpt-4") .messages(List.of( ChatCompletionMessageParam.ofChatCompletionMessage( ChatCompletionMessage.builder() .role(ChatCompletionMessage.Role.USER) .content("Giải thích cách làm bánh mì Việt Nam") .build() ) )) .build()) .get(); System.out.println(response.choices().get(0).message().content()); Anthropic Claude SDK được đánh giá cao về chất lượng response, đặc biệt với các task reasoning phức tạp. API sử dụng kiến trúc message-based, dễ hiểu và linh hoạt. Claude cũng có context window dài (200K tokens), rất hữu ích cho xử lý tài liệu lớn hoặc lịch sử chat dài.
// Anthropic Claude SDK import com.anthropic.client.Anthropic; import com.anthropic.models.Message; AnthropicClient client = new AnthropicClient(); Message response = client.messages().create( MessageCreateParams.builder() .model("claude-3-5-sonnet-20241022") .maxTokens(1024) .messages(List.of( MessageParam.user("Viết một đoạn code Java tính Fibonacci") )) .build() ); System.out.println(response.content().get(0).text()); Google Gemini SDK (qua Vertex AI) mạnh ở multimodal capabilities và tích hợp tốt với Google Cloud Platform. Nếu công ty bạn đã sử dụng GCP, việc tích hợp Gemini sẽ rất thuận tiện. Chi phí cũng cạnh tranh, nhất là với mục đích non-commercial hoặc development.
// Google Gemini via Vertex AI import com.google.cloud.vertexai.VertexAI; import com.google.cloud.vertexai.generativeai.GenerativeModel; VertexAI vertexAI = new VertexAI("your-project-id", "us-central1"); GenerativeModel model = new GenerativeModel("gemini-pro", vertexAI); ContentStream stream = model.generateContentStream("Giải thích machine learning cho người mới bắt đầu"); stream.stream().forEach(response -> response.candidates().forEach(candidate -> System.out.println(candidate.content().parts().get(0).text()) ) ); Mỗi nhà cung cấp có cách xây dựng request khác nhau, nhưng chúng đều về cơ bản là: gửi model name, messages, và các parameters (temperature, max_tokens). Điểm khác biệt nằm ở tên parameter, default values, và feature support.
Triển khai đa nhà cung cấp trong thực tế
Để tránh viết code cặp với từng SDK, hãy dùng một framework abstraction. LangChain4j là lựa chọn tốt nhất vì nó hỗ trợ tất cả các nhà cung cấp chính thông qua một API thống nhất.
// LangChain4j: Một code, nhiều nhà cung cấp public class MultiProviderChatService { private final ChatLanguageModel model; public MultiProviderChatService(String provider) { this.model = switch (provider) { case "openai" -> OpenAiChatModel.builder() .apiKey(System.getenv("OPENAI_API_KEY")) .modelName("gpt-4") .build(); case "claude" -> AnthropicChatModel.builder() .apiKey(System.getenv("ANTHROPIC_API_KEY")) .modelName("claude-3-5-sonnet-20241022") .build(); case "gemini" -> GoogleAiChatModel.builder() .apiKey(System.getenv("GOOGLE_API_KEY")) .modelName("gemini-pro") .build(); default -> throw new IllegalArgumentException("Unknown provider"); }; } public String chat(String userMessage) { return model.generate(userMessage); } } // Sử dụng MultiProviderChatService service = new MultiProviderChatService("claude"); String response = service.chat("Hôm nay thời tiết Hà Nội thế nào?"); System.out.println(response); // Nếu muốn chuyển sang OpenAI, chỉ cần: service = new MultiProviderChatService("openai"); Cách này cho phép bạn dễ dàng A/B test giữa các nhà cung cấp, hoặc thay đổi nhà cung cấp mặc định mà không ảnh hưởng đến code logic. Bạn cũng có thể tạo một failover strategy: nếu OpenAI timeout, tự động fallback sang Claude, rồi Gemini nếu cần.
Khi kết nối với Spring Boot, tư cách dùng @Configuration bean để quản lý lifecycle của model, kết hợp với @Value hoặc environment properties để externalize configuration. Điều này giúp bạn dễ dàng switching provider giữa development, staging, và production mà không cần build lại application.
RAG, Agent, Memory: Nâng cao khả năng LLM Java ứng dụng thực tế
Khi xây dựng ứng dụng AI bằng Java, bạn sẽ nhanh chóng nhận ra rằng chỉ gọi API đến LLM là chưa đủ. Mô hình ngôn ngữ lớn có bộ nhớ ngắn hạn, không hiểu được dữ liệu riêng của doanh nghiệp, và thường cần sự hỗ trợ từ các công cụ bên ngoài để giải quyết vấn đề phức tạp. Đó là lý do tại sao RAG (Retrieval-Augmented Generation), AI Agent, và Memory Management trở thành những thành phần then chốt trong các hệ thống AI sản phẩm.
Hãy tưởng tượng bạn đang xây dựng một chatbot hỗ trợ khách hàng cho công ty bảo hiểm Việt Nam. LLM cơ bản không biết về chính sách độc quyền của công ty bạn, quy trình klaim hay các quy định riêng. Nó sẽ đưa ra câu trả lời chung chung hoặc thậm chí sai lạc. Đó là lúc RAG xuất hiện: bạn lưu trữ tất cả tài liệu chính sách của công ty vào một vector database, khi người dùng hỏi, hệ thống sẽ tìm kiếm các tài liệu liên quan và cung cấp chúng cho LLM như một bối cảnh. Kết quả? Câu trả lời chính xác, dựa trên dữ liệu thực tế của công ty.
Trong LangChain4j, việc triển khai RAG không phức tạp như bạn tưởng. Bạn định nghĩa một ContentRetriever, nó sẽ tìm kiếm các tài liệu phù hợp từ vector database của bạn. Sau đó, những tài liệu này được đưa vào prompt cùng câu hỏi của người dùng. Framework sẽ xử lý toàn bộ quá trình tìm kiếm, xếp hạng, và chuẩn bị dữ liệu cho LLM. Điều quan trọng là bạn cần chọn mô hình embedding phù hợp—đó là công cụ chuyển đổi văn bản thành vector số học để có thể tìm kiếm ngữ nghĩa. Với dữ liệu tiếng Việt, hãy chọn mô hình embedding hỗ trợ tốt tiếng Việt, không phải chỉ tiếng Anh.
AI Agent là bước tiến xa hơn. Thay vì LLM chỉ trả lời câu hỏi dựa trên dữ liệu sẵn có, Agent có thể tự quyết định sử dụng những công cụ nào để giải quyết vấn đề. Ví dụ: agent có thể được trang bị công cụ gọi API kiểm tra số dư tài khoản, công cụ tính lãi suất, công cụ tra cứu lịch sử giao dịch. Khi bạn hỏi "Nếu tôi gửi 100 triệu đồng với lãi suất 5% năm, 3 năm sau tôi nhận được bao nhiêu?", agent sẽ nhận ra cần phải sử dụng công cụ tính lãi, gọi nó, nhận kết quả, và trả lời bạn. Quá trình này diễn ra trong vài bước reasoning tự động, mà bạn không cần phải lập trình từng bước.
Để triển khai agent trong Java, LangChain4j cung cấp annotation @Tool. Bạn định nghĩa các method có annotation này, mô tả chức năng của chúng, và LLM sẽ tự động biết khi nào nên gọi chúng. Framework xử lý logic gọi công cụ, xử lý lỗi, và quay trở lại LLM với kết quả. Điều này giảm đáng kể lượng code boilerplate mà bạn phải viết.
Memory Management giải quyết một vấn đề cơ bản: LLM không nhớ những gì bạn nói trước đó nếu bạn không nói lại. Trong một cuộc hội thoại dài, nếu bạn giữ toàn bộ lịch sử tin nhắn, số lượng token tăng exponentially, khiến chi phí API tăng và độ trễ lớn hơn. Giải pháp là message windowing—chỉ giữ lại những tin nhắn gần đây nhất, hoặc sử dụng summarization—tóm tắt những tin nhắn cũ thành một bản tóm tắt để LLM hiểu bối cảnh. LangChain4j cung cấp các chiến lược memory khác nhau mà bạn có thể lựa chọn tùy theo nhu cầu ứng dụng.
Trong thực tế, khi triển khai tại doanh nghiệp, bạn cần kết hợp cả ba thành phần này. Ví dụ, một hệ thống customer support: sử dụng RAG để truy vấn tài liệu chính sách, sử dụng Agent để gọi API kiểm tra thông tin khách hàng, và sử dụng Memory để theo dõi cuộc hội thoại. Kết quả là một chatbot thông minh, chính xác, và thực sự hữu ích cho người dùng cuối.
Chìa khóa là hiểu rõ khi nào sử dụng từng thành phần. Không phải tất cả ứng dụng đều cần Agent—nếu LLM chỉ cần trả lời câu hỏi từ dữ liệu tĩnh, RAG đã đủ. Tương tự, nếu bạn xây dựng hệ thống dành riêng cho câu hỏi một lần, Memory không cần thiết. Hãy bắt đầu đơn giản, sau đó thêm tính năng khi thực tế yêu cầu, thay vì cố gắng triển khai mọi thứ từ đầu.
Sản Phẩm Chất Lượng: Xử Lý Lỗi, Khả Năng Phục Hồi, Ghi Nhật Ký và Thực Tiễn Tốt Nhất
Khi triển khai ứng dụng sử dụng LLM vào môi trường sản xuất, việc chỉ tập trung vào "tính năng hoạt động" là chưa đủ. Điều quyết định sự khác biệt giữa một dự án AI thành công và một đó là cách bạn xử lý khi mọi thứ không diễn ra theo kế hoạch. Từ kinh nghiệm xây dựng các hệ thống AI cho doanh nghiệp Việt Nam, tôi đã nhìn thấy rằng hầu hết các vấn đề không xuất phát từ mô hình LLM, mà từ cách chúng ta quản lý lỗi, khôi phục sự cố, và theo dõi hành vi của hệ thống trong thực tế.
Tại sao xử lý lỗi lại quan trọng đến vậy? API của các nhà cung cấp LLM (OpenAI, Anthropic, Google) có độ khả dụng cao, nhưng không phải là 100%. Mạng internet có thể không ổn định. Kích thước token có thể vượt giới hạn. Rate limit có thể được kích hoạt. Nếu ứng dụng của bạn không chuẩn bị sẵn cho các tình huống này, người dùng sẽ gặp trải nghiệm tệ: lỗi không rõ ràng, ứng dụng đóng băng, hoặc dữ liệu bị mất.
Trong Java, cách tiêu chuẩn là bao bọc tất cả các lệnh gọi API LLM bằng try-catch và xử lý các exception cụ thể:
try { String response = chatClient.prompt() .system("Bạn là một trợ lý hữu ích") .user(userInput) .call() .content(); return response; } catch (ApiException e) { logger.error("Lỗi gọi API LLM: {}", e.getMessage()); return "Tôi gặp sự cố tạm thời. Vui lòng thử lại."; } catch (TokenLimitExceededException e) { logger.warn("Yêu cầu vượt giới hạn token"); return "Đầu vào quá dài. Vui lòng rút gọn."; }Tuy nhiên, try-catch đơn thuần là chỉ bước đầu. Bạn cần retry logic với exponential backoff—kỹ thuật mà các công ty công nghệ lớn sử dụng hàng ngày. Ý tưởng đơn giản: nếu một yêu cầu thất bại do lỗi tạm thời (network timeout, rate limit), hãy thử lại, nhưng đợi lâu hơn mỗi lần:
@Service public class ResilientLLMService { @Retryable( retryFor = TemporaryException.class, maxAttempts = 3, backoff = @Backoff(delay = 1000, multiplier = 2.0) ) public String callLLMWithRetry(String prompt) { return chatClient.prompt() .user(prompt) .call() .content(); } @Recover public String recover(TemporaryException e) { logger.error("Tất cả lần thử lại đều thất bại"); return "Không thể xử lý yêu cầu ngay bây giờ."; } }Chiến lược này giúp bạn tự động khôi phục từ các lỗi tạm thời mà không cần can thiệp thủ công. Thực tế, khi xây dựng hệ thống chatbot cho một công ty fintech Việt Nam, việc thêm retry logic giảm tỷ lệ lỗi từ 8% xuống 1% chỉ trong vài dòng code.
Ghi nhật ký (logging) là mắt và tai của bạn trong sản xuất. Khi một người dùng nói "Ứng dụng của tôi bị hỏng", bạn không thể chỉ nói "vui lòng thử lại". Bạn cần biết chính xác điều gì đã xảy ra. Thiết lập logging ở các mức độ khác nhau:
- DEBUG: Chi tiết về từng bước gọi API, nội dung prompt, token count. Chỉ bật ở development hoặc khi debug sự cố cụ thể.
- INFO: Các sự kiện quan trọng—"người dùng gửi prompt", "nhận phản hồi từ LLM", "lưu kết quả vào cơ sở dữ liệu".
- WARN: Những thứ không phải lỗi nhưng đáng chú ý—"token gần giới hạn", "retry lần thứ 2".
- ERROR: Các lỗi thực sự—"API không phản hồi", "exception không được dự đoán".
Ví dụ cơ bản:
logger.debug("Prompt gửi đi: {}", userInput); logger.info("Gọi LLM API cho người dùng {}", userId); try { String result = callLLM(userInput); logger.info("Phản hồi nhận được, độ dài: {} ký tự", result.length()); } catch (Exception e) { logger.error("Lỗi gọi LLM: ", e); }Nhưng logging chỉ hữu ích nếu bạn có cách quan sát và phân tích nó. Trong một dự án thực tế, hãy tập trung vào:
- Số lần gọi API thành công vs thất bại mỗi ngày
- Thời gian phản hồi trung bình từ LLM
- Các lỗi lặp đi lặp lại (ví dụ: "rate limit bị kích hoạt vào giờ 10 sáng mỗi ngày")
- Chi phí token thực tế so với dự算
Best practice cuối cùng: thiết kế với "graceful degradation" (suy giảm thanh lịch). Không phải lúc nào người dùng cũng cần phản hồi LLM hoàn hảo. Đôi khi một phản hồi "cũ" từ cache hoặc một gợi ý đơn giản sẽ tốt hơn là không có gì cả. Ví dụ:
public String getResponse(String userInput) { // Bước 1: Thử lấy từ cache String cached = cache.get(userInput); if (cached != null) return cached; // Bước 2: Thử gọi LLM try { String llmResponse = callLLM(userInput); cache.put(userInput, llmResponse); return llmResponse; } catch (Exception e) { // Bước 3: Nếu thất bại, trả về câu trả lời mặc định logger.warn("LLM không khả dụng, sử dụng fallback"); return "Xin lỗi, tôi đang bận. Hãy thử lại trong vài giây."; } }Chiến lược này đảm bảo ứng dụng của bạn luôn có thể cung cấp một cái gì đó hữu ích, ngay cả khi LLM gặp sự cố. Đó là sự khác biệt giữa một sản phẩm chất lượng cao và một sản phẩm dễ bị người dùng phàn nàn.
Xử lý lỗi, khả năng phục hồi, và ghi nhật ký không phải là "thứ có thể làm sau". Chúng là nền tảng của bất kỳ hệ thống AI sản xuất nào. Bỏ thời gian vào đúng chỗ từ đầu sẽ tiết kiệm hàng trăm giờ debug và khôi phục sự cố sau này.
