Langfuse: công cụ giúp FDE trả lời ba câu hỏi khó nhất sau khi deploy LLM

Sau khi một ứng dụng LLM lên production, khách hàng thường sẽ hỏi ba câu: vì sao nó trả lời như vậy, mỗi tháng tốn bao nhiêu, và bản tuần này có tốt hơn bản tuần trước không.

Trả lời ba câu đó bằng cảm giác là cách nhanh nhất để mất uy tín trước khách. Langfuse được thiết kế để trả lời bằng dữ liệu: trace cho câu “vì sao”, theo dõi chi phí cho câu “bao nhiêu”, và eval cho câu “có tốt lên không” — tất cả trong cùng một nền tảng.

Với một FDE, còn một điều kiện tiên quyết trước khi bàn đến tính năng: công cụ observability bạn cài vào hạ tầng của khách phải chạy được trong mạng nội bộ của họ. Langfuse tự mô tả mình là mở, self-host được và mở rộng được — đúng ba tính chất mà team bảo mật phía khách sẽ hỏi trước tiên.

Trace không chỉ ghi lại cuộc gọi LLM

Theo tài liệu Langfuse, application tracing ghi lại toàn bộ vòng đời của một request khi nó đi qua hệ thống: prompt, response, token đã dùng và latency. Đáng chú ý hơn, trace bao gồm cả những bước không phải LLM — retrieval, embedding, các API call. Với ứng dụng RAG, đó chính là nơi lỗi hay trốn.

Thử hình dung bạn đang triển khai một trợ lý tra cứu chính sách nội bộ cho một ngân hàng. Người dùng than phiền rằng câu trả lời về hạn mức tín dụng bị sai. Nếu chỉ nhìn prompt và response, bạn sẽ đoán là model “bịa” và bắt đầu sửa prompt.

Mở trace trong Langfuse, câu chuyện có thể hoàn toàn khác: bước embedding chạy bình thường, bước retrieval trả về năm đoạn văn bản, nhưng không đoạn nào chứa bảng hạn mức mới. Vấn đề là index chưa cập nhật, không phải prompt. Bạn trả lời khách hàng trong mười phút thay vì mất một ngày thử nghiệm prompt vô ích.

Điều kiện để làm được việc đó là SDK phải được gắn vào production, và đây là lúc team platform của khách sẽ lo về hiệu năng. Tài liệu Langfuse ghi rõ: các sự kiện trace được xếp hàng cục bộ và đẩy đi theo lô, nên thời gian phản hồi của ứng dụng không bị ảnh hưởng. Đó là câu bạn cần nói được trong buổi họp kiến trúc.

Con số bạn gửi lên thắng con số Langfuse đoán

Câu hỏi “tốn bao nhiêu” nghe đơn giản nhưng có hai cách trả lời, và Langfuse hỗ trợ cả hai. Ứng dụng có thể gửi thẳng usage và cost lên; hoặc nếu không gửi, Langfuse tự suy ra từ các model definition có giá theo từng loại usage.

Quy tắc quyết định: khi cả hai cùng tồn tại, giá trị được gửi lên có ưu tiên hơn giá trị suy ra.

Lời khuyên: nếu khách hàng dùng model qua hợp đồng riêng, hãy gửi cost từ app ngay từ đầu, vì con số suy ra sẽ sai và bạn sẽ mất uy tín khi bộ phận tài chính đối chiếu hóa đơn. Nếu dùng model phổ biến, kiểm tra model definition trước khi trình dashboard cho bất kỳ ai.

Chấm điểm production, rồi khóa regression trong CI

Câu hỏi thứ ba khó nhất: hệ thống có đang tốt lên không. Langfuse cho phép tự động chấm điểm các trace production đang chạy bằng LLM-as-a-judge, nên bạn có một thước đo liên tục thay vì chờ người dùng than phiền. Nhưng điểm số chỉ có ý nghĩa khi nó dẫn đến hành động.

Vòng lặp hợp lý tại khách hàng trông như sau. Trace nào bị chấm thấp, bạn kéo vào một dataset gồm các test case. Mỗi lần đổi prompt hay đổi chiến lược retrieval, bạn chạy experiment trên dataset đó — và theo tài liệu, experiment có thể chạy ngay trong CI để bắt regression trước khi code lên production.

Để thay đổi đó an toàn, Langfuse còn có prompt management: prompt có version và deploy theo label.

Việc “sửa prompt” khi ấy không còn là một thao tác đầy rủi ro, mà là một thay đổi có số version, có điểm số trước và sau; và vì production trỏ vào label chứ không vào một bản prompt cố định, muốn quay về bản cũ thì chỉ cần gắn lại label cho version trước.

Giới hạn bạn phải nói trước với khách

Langfuse không thay bạn đánh giá. Judge là một LLM, nên điểm số của nó cần được một người đọc mẫu định kỳ để kiểm chứng — hãy coi đó là đèn báo, không phải phán quyết. Chi phí suy ra cũng phụ thuộc hoàn toàn vào bảng giá bạn khai.

Về giấy phép, có một mốc bạn cần biết. Ngày 16 tháng 1 năm 2026, Langfuse thông báo trên blog của mình rằng ClickHouse đã mua lại công ty. Langfuse nói họ vẫn gắn bó với mã nguồn mở và self-hosting, không có thay đổi giấy phép nào được lên kế hoạch; phía ClickHouse khẳng định các tính năng lõi tiếp tục dưới giấy phép MIT.

Cam kết đó áp dụng cho “tính năng lõi”, nên hãy đọc kỹ phần nào thuộc lõi trước khi hứa với khách. Công cụ bạn cài vào hạ tầng của họ phải sống lâu hơn hợp đồng của bạn.

Về vận hành, ClickHouse cho biết Langfuse vốn đã được xây trên ClickHouse. Nếu self-host, bạn cần sẵn sàng vận hành thêm một hệ thống lưu trữ nữa trong hạ tầng khách hàng, và nên hỏi rõ team của họ ai sẽ nhận phần đó.

Học gì trước

Bắt đầu từ khái niệm trace: hiểu rằng một request là một chuỗi bước, mỗi bước có input, output, thời gian và chi phí riêng. Gắn SDK vào một app RAG nhỏ của bạn, chạy vài chục câu hỏi và tập đọc trace cho tới khi bạn nhìn ra lỗi retrieval nhanh hơn lỗi prompt. Sau đó mới đến dataset, experiment và CI.

Trong CV, đừng viết “biết dùng Langfuse”. Hãy viết bạn đã triển khai observability cho một ứng dụng LLM, với trace đầy đủ các bước, chi phí đối chiếu được với hóa đơn, và một bộ test case chạy trong CI. Nhà tuyển dụng FDE đọc dòng đó và thấy người có thể đứng trước khách hàng.

Khi mọi thứ chạy ổn, không ai nhắc đến Langfuse. Nhưng ngày hệ thống trả lời sai một con số quan trọng, người có trace trong tay là người giữ được hợp đồng.