LangChain, LlamaIndex, Haystack hay gọi API thẳng: chọn framework theo vấn đề của khách, không theo độ nổi tiếng

Trong bài hướng dẫn xây agent công bố ngày 19/12/2024, Anthropic đưa ra một lời khuyên ngược với điều nhiều dev vẫn làm theo phản xạ: hãy bắt đầu bằng cách gọi thẳng API của LLM. Lý do rất thực dụng. Nhiều pattern chỉ cần vài dòng code.

Trong khi đó, mỗi framework đều có lời hứa của riêng mình. Haystack tự nhận là framework mã nguồn mở để xây agent sẵn sàng cho production. LangChain hứa giúp khởi động agent nhanh với bất kỳ nhà cung cấp model nào. LlamaIndex mời bạn xây agent trên chính dữ liệu của tổ chức.

Với một FDE, chọn framework không chỉ là chuyện sở thích. Code bạn viết sẽ nằm lại trong codebase của khách sau khi bạn rời đi, và đội của khách là người phải debug nó lúc hai giờ sáng.

Vì thế, câu hỏi đúng không phải “framework nào tốt nhất” mà là “khách đang tắc ở phần nào, và mình có nên giao phần đó cho thư viện của người khác không”.

Mỗi công cụ đang giải quyết một phần việc khác nhau

Đọc kỹ cách từng bên tự mô tả, bạn sẽ thấy họ không cạnh tranh trên cùng một sân. LangChain đặt trọng tâm ở tốc độ khởi động và việc dùng được với mọi nhà cung cấp model. Khi cần agent production có mức xác định (determinism) nhất định, họ đưa bạn sang một sản phẩm riêng là LangGraph, với khả năng kiểm soát ở mức thấp.

LangChain còn có LangSmith, nền tảng để quan sát, đánh giá và triển khai agent. Chi tiết này quan trọng với FDE: một phần trong hệ sinh thái này là sản phẩm khách có thể phải mua thêm, không chỉ là thư viện mã nguồn. Khi đề xuất LangChain, bạn cần nói rõ khách đang dùng phần nào và phần nào có thể kéo theo chi phí sau này.

LlamaIndex bắt đầu từ dữ liệu: một bộ công cụ Python để xây agent dựa trên LLM, chạy trên dữ liệu của chính khách. Workflow của họ là quy trình nhiều bước hướng sự kiện, kết hợp agent, data connector và tool. RAG ở đây chỉ là một tool trong số đó chứ không phải toàn bộ hệ thống.

Haystack không giấu logic sau các lớp tự động. Theo tài liệu của deepset, pipeline là một đồ thị do chính bạn nối, nên lần nào nó cũng chạy giống nhau. Họ nhấn mạnh việc kiểm soát tường minh retrieval, routing, memory và generation, và hứa có thể đổi model hoặc hạ tầng mà không phải viết lại hệ thống.

RAGFlow thì khác hẳn: đây không phải thư viện để ghép code mà là một engine RAG dựng sẵn. Điểm mạnh của nó là hiểu sâu tài liệu phi cấu trúc có định dạng phức tạp. Nó còn cho người dùng xem trực quan cách tài liệu được cắt chunk để con người can thiệp.

Bảng dưới đây đặt từng công cụ vào những tình huống thường gặp ở site khách:

Công cụ	Mạnh ở phần nào	Hợp khi khách cần	Câu cần hỏi trước khi đưa vào
LangChain + LangGraph	Khởi động nhanh, dùng được nhiều nhà cung cấp; LangGraph cho production cần determinism	Demo nhanh để thuyết phục người ra quyết định, rồi chuyển sang luồng có kiểm soát	Khách sẽ dùng LangSmith không, và ai trả tiền?
LlamaIndex	Agent chạy trên dữ liệu riêng, workflow hướng sự kiện, nhiều data connector	Dữ liệu nằm rải rác ở nhiều nguồn	Connector nào cần thật, connector nào chưa cần đến?
Haystack	Pipeline do dev tự nối, chạy nhất quán, đổi được model và hạ tầng	Khách cần kiểm toán, cần tái lập được kết quả, sợ bị lock-in	Đội của khách có đủ người để giữ đồ thị đó không?
RAGFlow	Engine dựng sẵn, hiểu tài liệu phức tạp, xem và sửa được cách cắt chunk	Kho PDF lộn xộn, cần người nghiệp vụ kiểm tra chất lượng truy xuất	Có chấp nhận chạy thêm một hệ thống riêng thay vì một thư viện không?
Gọi API thẳng	Ít lớp trung gian nhất, nhìn thấy toàn bộ prompt	Luồng đơn giản, cần debug nhanh	Phần nào đang tự viết lại thứ mà framework đã giải quyết tốt?

Khách đang tắc ở phần nào?

Thử hình dung một tình huống giả định: một công ty logistics muốn có agent nội bộ trả lời câu hỏi về hợp đồng vận chuyển. Dữ liệu là vài nghìn file PDF scan có bảng biểu, soạn theo nhiều mẫu khác nhau qua từng năm. Bạn có hai tuần.

Tuần đầu, bạn gọi thẳng API, cắt tài liệu theo độ dài cố định và in nguyên văn prompt trước mỗi lần gửi. Người dùng hỏi phí lưu kho tuyến Hải Phòng – Hà Nội, model trả lời sai. Prompt in ra (số liệu minh họa) trông như sau:

Ngữ cảnh:
[Đoạn 15] Hải Phòng – Hà Nội | 4.200.000 | 350.000
[Đoạn 31] Phí lưu kho được tính theo tháng, thanh toán cuối kỳ...
Câu hỏi: Phí lưu kho tuyến Hải Phòng – Hà Nội là bao nhiêu?

Nhìn vào đây, lỗi hiện ra ngay. Dòng tiêu đề “Tuyến | Phí vận chuyển | Phí lưu kho” đã rơi sang đoạn 14, không được truy xuất, nên model chỉ thấy hai con số không có tên cột và chọn nhầm số đầu tiên. Vấn đề nằm ở khâu đọc và cắt tài liệu, không nằm ở khâu điều phối agent.

Đó là lúc đáng đưa vào một công cụ mạnh về hiểu tài liệu như RAGFlow. Màn hình xem cách cắt chunk của nó cho phép người bên vận hành thấy bảng phí bị tách khỏi tiêu đề và chỉnh lại để cả bảng nằm trong một chunk. In lại prompt, đoạn ngữ cảnh giờ mang đủ tên cột và model chọn đúng số 350.000.

Bài học cho ngày đầu ở site khách: trước khi bàn đến framework, hãy in prompt ra và tự hỏi chunk được truy xuất có chứa đủ thông tin để một người đọc trả lời đúng hay không.

Các tình huống khác sẽ dẫn tới công cụ khác. Nếu tài liệu sạch nhưng nằm rải rác ở SharePoint, database và email, lớp dữ liệu của LlamaIndex mới là phần giúp bạn tiết kiệm công sức.

Giả sử thêm rằng khách là doanh nghiệp bị kiểm toán và cần mỗi câu trả lời tái lập được. Khi đó, đồ thị tự nối của Haystack, chạy cùng một cách mỗi lần, sẽ dễ bảo vệ trước bộ phận tuân thủ hơn.

Nếu sếp bên khách chỉ cần một demo trong ba ngày để duyệt ngân sách, khởi động nhanh bằng LangChain là hợp lý, miễn là bạn nói trước rằng bản production sẽ cần LangGraph hoặc một cách làm khác.

Bạn rời đi rồi, khách vẫn phải gánh lớp trừu tượng

Anthropic chỉ ra rủi ro lớn nhất: framework thường thêm những lớp trừu tượng che mất prompt thật bên dưới, khiến việc debug khó hơn. Với một dev làm sản phẩm nội bộ, đó chỉ là một chút phiền toái. Với FDE, đó là món nợ bạn để lại cho đội của khách.

Lời khuyên thứ hai của Anthropic còn thẳng hơn: nếu dùng framework, hãy hiểu code bên dưới. Họ ghi nhận rằng giả định sai về những gì diễn ra bên trong là nguồn lỗi phổ biến của khách hàng. Nói cách khác, lỗi thường không đến từ model mà từ việc người dùng tưởng framework đang làm một việc nhưng thực ra nó làm việc khác.

Từ đó, mỗi framework cần qua một bài kiểm tra trước khi bàn giao. Bạn có in ra được nguyên văn prompt cuối cùng gửi tới model, như trong ví dụ hợp đồng vận chuyển ở trên không? Đội của khách có lần được từ một câu trả lời sai về đúng chunk, đúng bước routing đã gây ra nó không?

Nếu câu trả lời là không, framework đó đang tiết kiệm thời gian cho bạn bằng cách bắt khách trả giá sau này.

Tự viết không có nghĩa là viết lại mọi thứ

Đọc lời khuyên của Anthropic thành “không bao giờ dùng framework” là hiểu sai. Họ nói nhiều pattern chỉ cần vài dòng code, chứ không nói mọi pattern. Một vòng lặp gọi tool, một bước tóm tắt, một router đơn giản đều nằm gọn trong vài chục dòng mà ai trong đội khách cũng đọc được.

Nhưng tự viết bộ phân tích PDF có bảng biểu, hay tự viết connector cho mười nguồn dữ liệu, là tự làm lại phần việc mà RAGFlow hay LlamaIndex đã đầu tư rất nhiều. Lời hứa “đổi model mà không phải viết lại” của Haystack cũng chỉ có giá trị khi khách thật sự có khả năng đổi model.

Nếu không, một lớp adapter mỏng do bạn tự viết cũng đủ để giảm rủi ro lock-in.

Cách làm hợp lý ở site khách vì thế thường là kết hợp. Phần điều phối nên tự viết và giữ thật mỏng, đủ để in ra mọi prompt. Framework chỉ nên đưa vào ở đúng một lớp nặng, nơi nó gánh việc thật. Khi bàn giao, hãy kèm một trang giải thích vì sao lớp đó dùng thư viện còn các lớp khác thì không.

Developer Việt nên luyện gì

Kỹ năng đáng giá ở đây không phải là thuộc API của cả bốn công cụ. Đó là khả năng giải thích, trước mặt kỹ sư bên khách, vì sao chọn công cụ này cho phần việc này. Hãy luyện bằng cách làm cùng một bài toán theo hai cách: gọi API thẳng và dùng một framework, rồi ghi lại chỗ nào framework giúp, chỗ nào nó che mất prompt.

Tên framework trong job description cũng là manh mối: một vị trí nhắc LangGraph và observability nhiều khả năng đang cần người đưa agent lên production có kiểm soát. Khi kể kinh nghiệm, hãy cho nhà tuyển dụng thấy bạn biết cân nhắc vì sao dùng hay bỏ một công cụ, thay vì đưa ra một danh sách tên thư viện.

Framework rồi sẽ đổi tên, gộp sản phẩm, thay cách tự giới thiệu. Thói quen gọi API thẳng trước, tìm đúng chỗ khách đang tắc rồi mới chọn công cụ thì sẽ còn dùng được lâu hơn bất kỳ framework nào trong số này.