LangSmith, Arize, Helicone hay PostHog: khách hàng đặt ràng buộc gì thì chọn công cụ đó

Muốn đưa Helicone vào một ứng dụng dùng SDK tương thích OpenAI, bạn chỉ cần sửa đúng một dòng: base URL trỏ sang ai-gateway.helicone.ai. Tích hợp nhanh như vậy rất hấp dẫn. Nhưng chính dòng đó cũng có nghĩa là mọi prompt và mọi câu trả lời của khách hàng sẽ đi qua một gateway không thuộc quyền quản lý của khách.

Vì thế, câu hỏi “nên dùng LangSmith, Arize, Helicone hay PostHog” thường được đặt sai chỗ. Bốn công cụ này đều ghi lại được các lần gọi LLM. Điểm khác nhau nằm ở chỗ mỗi công cụ ngầm giả định một kiểu khách hàng: khách cho phép dữ liệu đi đâu, chịu sửa code đến đâu, và đang lo về điều gì.

Đó cũng là việc của FDE. Bạn không ngồi viết bài review công cụ. Bạn ngồi trong phòng họp của khách và phải quyết định trong vài buổi. Nếu đọc ra đúng ràng buộc, bạn chọn đúng công cụ ngay lần đầu. Nếu đọc sai, ba tuần sau bạn sẽ phải gỡ ra lắp lại, đúng lúc khách bắt đầu tin bạn.

Vì sao không thể giám sát bằng tay?

IBM định nghĩa LLM observability là việc thu thập metrics, traces và logs từ ứng dụng LLM. Họ cũng lập luận rằng giám sát thủ công thì tốn nhiều công sức, dễ sai và không mở rộng được.

Thử hình dung một pilot mà cả đội mở file log ra đọc từng dòng: lúc còn ít request thì xoay xở được, nhưng lên production thì cách làm đó vỡ đúng như IBM cảnh báo.

JetBrains đưa ra một cách phân biệt rất hữu ích. Evaluation trả lời câu hỏi agent có thể làm được việc hay không. Observability trả lời câu hỏi agent có đang làm được việc hay không, và khách thường chỉ đang lo một trong hai.

JetBrains còn nhấn mạnh rằng với agent, trace phải theo được mạch suy luận qua từng bước, từng tool call và từng observation, chứ ghi mỗi output cuối là không đủ. Thử hình dung một agent tra cứu đơn hàng có sáu bước, trong đó bước thứ ba gọi nhầm tool.

Nếu chỉ log câu trả lời cuối cùng, bạn chỉ biết khách nhận một câu trả lời sai mà không biết vì sao.

Dữ liệu của khách được phép nằm ở đâu?

Đây là câu hỏi loại bỏ được nhiều phương án nhất, nên hãy hỏi nó trước tiên. Một ngân hàng hay một bệnh viện có thể không cho phép prompt chứa thông tin khách hàng rời khỏi hạ tầng của họ. Một startup thương mại điện tử thì có thể chẳng mấy bận tâm.

LangSmith cho phép chọn giữa cloud, hybrid và self-hosted. Với khách có yêu cầu về vị trí lưu dữ liệu, đây là lợi thế lớn.

Arize giải bài toán này theo cách khác. Arize AX là nền tảng thương mại, còn ngay trong tài liệu AX có đường dẫn sang Phoenix, sản phẩm mã nguồn mở của họ. Nếu khách không dùng được SaaS, Phoenix là phương án nên thử trước khi kết luận rằng phải tự viết công cụ.

Helicone thì ngược lại. Quy trình quick start đặt Helicone vào giữa luồng request dưới dạng gateway, đi kèm logging, observability và fallback giữa các provider. Với khách bị giới hạn, việc đầu tiên của bạn là hỏi bộ phận bảo mật xem họ có chấp nhận một gateway bên ngoài hay không, rồi mới nói đến chuyện tích hợp nhanh.

Gateway hay instrumentation: công cụ đứng ở đâu?

Gateway và instrumentation có điểm mạnh, điểm yếu gần như trái ngược nhau. Gateway gần như không cần sửa code, chỉ đổi base URL là xong, nhưng nó nằm ngay trên đường đi của mọi request. Instrumentation đòi bạn chạm vào code nhiều hơn và không đứng chắn giữa ứng dụng với provider.

Đừng vội coi instrumentation là an toàn hơn. Trace gửi lên LangSmith cloud hay Arize SaaS vẫn chứa prompt và output, giống như những gì PostHog mô tả khi ghi toàn bộ ngữ cảnh hội thoại cho mỗi generation. Đường đi của dữ liệu khác, chứ lượng dữ liệu rời khỏi hạ tầng của khách không hề nhỏ hơn.

Arize AX có auto-instrumentation cho hơn 30 provider và framework, nên phần việc sửa code được giảm đáng kể. Điều này đáng giá khi bạn gặp một codebase trộn nhiều framework, chuyện rất hay xảy ra ở khách hàng đã thử nghiệm vài vòng trước khi bạn tới.

Gateway của Helicone còn có một lợi ích mà instrumentation không có: fallback giữa các provider. Theo quick start, mô hình credit của Helicone giữ nguyên giá của provider với “0% markup”, và khách cũng có thể dùng key provider của chính họ. Với một startup đang muốn nhanh chóng có log và cơ chế dự phòng khi một provider bị lỗi, đây là lựa chọn thực dụng.

Khách đang muốn trả lời câu hỏi gì?

Đến đây ranh giới giữa evaluation và observability của JetBrains trở nên cụ thể. Arize tự mô tả AX là một nền tảng AI engineering để trace, evaluate và chạy experiment, tức là rộng hơn một công cụ ghi log. LangSmith nói đến việc nhìn thấy toàn bộ ứng dụng, từ một trace đơn lẻ cho tới metrics của cả production, có dashboard và alert.

PostHog đi theo một hướng khác. Mỗi lần gọi LLM được ghi thành một generation, gồm toàn bộ ngữ cảnh hội thoại, tool call, số token và độ trễ, và chi phí được tự động tính theo bảng giá model. Dữ liệu này nằm cạnh product analytics, nên bạn có thể nối hành vi người dùng với hành vi của model.

Thử hình dung một khách thương mại điện tử đã dùng PostHog để đo funnel. Họ không hỏi agent suy luận đúng hay sai ở bước bốn, mà muốn biết người dùng có chat với bot có mua hàng nhiều hơn không, và mỗi đơn hàng tốn bao nhiêu token. Với khách này, thêm một công cụ thứ hai có khi chỉ làm phân mảnh dữ liệu.

Ràng buộc của khách	Công cụ nên thử trước	Điều cần kiểm tra tại chỗ
Dữ liệu không được rời hạ tầng	LangSmith self-hosted hoặc Phoenix	Đội vận hành của khách có đủ người chạy và duy trì nó không
Muốn có log ngay trong một buổi, ít sửa code	Helicone gateway	Bộ phận bảo mật có chấp nhận traffic đi qua gateway không
Codebase trộn nhiều framework	Arize AX với auto-instrumentation	Framework của khách có nằm trong danh sách hơn 30 được hỗ trợ không
Cần evaluate và experiment, không chỉ ghi log	Arize AX	Khách thật sự cần biết agent có làm được không, hay chỉ cần biết nó có đang chạy không
Đã dùng PostHog, quan tâm hành vi người dùng và chi phí	PostHog LLM analytics	Trace có đủ chi tiết từng bước khi agent phức tạp dần lên không

Một buổi discovery nên hỏi gì?

Thứ tự câu hỏi quan trọng không kém nội dung. Hãy hỏi về dữ liệu trước, vì câu trả lời có thể loại ngay một nửa số phương án. Sau đó hỏi khách chịu sửa code đến mức nào, rồi mới hỏi họ muốn đo điều gì: agent có làm được không, có đang làm được không, hay người dùng có hưởng lợi không.

Một cái bẫy thường gặp là chọn công cụ mạnh nhất cho câu hỏi mà khách không hề đặt ra. Một nền tảng evaluate và experiment đầy đủ sẽ là gánh nặng nếu khách chỉ cần alert khi chi phí token tăng vọt.

Ngược lại, một gateway ghi log đơn giản sẽ không đủ khi khách đang vật lộn với một agent nhiều bước hỏng ở chỗ không ai nhìn thấy.

Ở Việt Nam, câu hỏi về dữ liệu thường đến trước

Nếu khách của bạn thuộc ngành tài chính, viễn thông hoặc khu vực nhà nước, câu hỏi “dữ liệu nằm ở đâu” rất có thể được đặt ra trước mọi câu hỏi khác. Khi đó, người đã tự tay chạy self-hosted một công cụ observability có lợi thế rõ rệt so với người chỉ biết dùng bản SaaS.

Trong CV, đừng viết “có kinh nghiệm với LangSmith”. Hãy viết theo hướng quyết định: bạn đã chọn công cụ nào, vì ràng buộc gì, và nhờ đó phát hiện ra lỗi gì.

Khi đọc JD của một vị trí FDE, hãy để ý những cụm như “on-prem”, “data residency” hay “agent reliability”, vì chúng cho bạn biết khách của công ty đó vướng ràng buộc nào trong ba ràng buộc trên.

Bốn công cụ này rồi sẽ thay đổi tính năng, đổi tên, thậm chí sáp nhập. Nhưng ba câu hỏi về dữ liệu, vị trí trong hệ thống và điều khách cần biết thì sẽ không đổi. Người biết hỏi đúng ba câu đó sẽ chọn đúng công cụ, kể cả với công cụ năm sau mới ra đời.