Langfuse hay Phoenix: 400 span không phân thắng bại, hạ tầng mới quyết định

|Tác giả: Ban biên tập QUASA|8 phút đọc
Langfuse hay Phoenix: 400 span không phân thắng bại, hạ tầng mới quyết định

Trong phép đo BenchClaw với 20 lượt mỗi nhánh, Langfuse và Arize Phoenix đều thu đủ 400/400 span; khoảng tin cậy của mức chênh lệch thời gian so với nhánh không gắn công cụ đều cắt qua 0. Phép đo chưa cho thấy bên nào có overhead thấp hơn. Với đội cần tự host trace và đánh giá ứng dụng LLM, hạ tầng phải vận hành, điều khoản giấy phép và cách làm việc với dữ liệu là những căn cứ chọn rõ hơn.

Langfuse hợp với đội chấp nhận duy trì nhiều dịch vụ lưu trữ và muốn dùng cùng codebase với bản cloud. Phoenix có đường khởi đầu gọn hơn với SQLite, rồi dùng PostgreSQL cho môi trường nhiều người; mô hình này cần được tính lại nếu các nhóm phải tách dữ liệu. Cả hai đều có trace, prompt và đánh giá, nên một bảng đánh dấu tính năng chưa nói được đội nào sẽ vận hành chúng thuận lợi hơn.

Phép đo thu trace nói được đến đâu?

Tác vụ thử nghiệm tạo các span cho lời gọi mô hình, công cụ và bước truy xuất. Ở những phiên bản được thử, hai nhánh đều ghi nhận đủ các span dự kiến, cùng quan hệ cha con và bản ghi lỗi mà tác vụ tạo ra. Đây là bằng chứng hữu ích về khả năng thu trace trong cấu hình ấy, nhưng không phải cam kết rằng mọi ứng dụng hay phiên bản mới đều đạt tỷ lệ thu tuyệt đối.

Khoảng tin cậy cắt qua 0 nghĩa là độ dao động của phép đo chưa cho phép tách phần thời gian do công cụ quan sát gây ra khỏi thời gian chạy tác vụ. Lời gọi API mô hình cũng góp phần làm thời gian mỗi lượt biến động. Vì vậy, không nên biến kết quả thành tuyên bố hai nền tảng có độ trễ bằng nhau, hoặc lấy chênh lệch thời gian quan sát được làm lợi thế chắc chắn cho một bên.

Bài đo dùng tác vụ dựng sẵn và số lượt chạy nhỏ. Nó chưa trả lời trace có đầy đủ những thuộc tính riêng của ứng dụng hay không, truy vấn dữ liệu lịch sử nhanh đến đâu, hoặc chi phí lưu giữ tăng thế nào khi payload lớn. Những câu hỏi đó thuộc về cấu hình triển khai và dữ liệu thực tế của đội, chứ không nằm trong kết quả thu span.

Langfuse đổi sự đồng nhất với bản cloud lấy những thành phần nào?

Mô tả của Langfuse cho biết bản tự host dùng cùng codebase với Langfuse Cloud, với phần lõi theo giấy phép MIT và các chức năng quản trị doanh nghiệp được cấp phép riêng. Hệ tự host cần ứng dụng web, worker, PostgreSQL, ClickHouse, Redis hoặc Valkey và kho blob. PostgreSQL phục vụ dữ liệu giao dịch; ClickHouse lưu trace, observation và điểm đánh giá, còn kho blob nhận sự kiện và payload lớn.

Kiến trúc ấy có ý nghĩa khi đội đã có người quản trị cơ sở dữ liệu phân tích, hàng đợi và lưu trữ đối tượng. Trace đi qua nhiều thành phần, nên kế hoạch vận hành phải bao gồm sao lưu, theo dõi dung lượng, nâng cấp và cách xử lý khi một khâu tiếp nhận hoặc xử lý sự kiện gặp sự cố. Một bản cài Docker Compose có thể giúp dựng môi trường thử, nhưng việc đặt toàn bộ stack trên một máy không tự tạo ra dự phòng cho production.

Giá phần mềm tự host không phản ánh toàn bộ chi phí. Chính sách giữ trace càng dài, payload và tệp đính kèm càng lớn thì nhu cầu lưu trữ và công việc quản trị càng đáng kể. Nếu tổ chức đã vận hành các dịch vụ cần thiết, Langfuse có thể tận dụng hạ tầng sẵn có; nếu chưa, số thành phần phải chăm sóc là một khoản chi phí kỹ thuật cần tính trước.

Phoenix gọn lúc khởi đầu, nhưng ranh giới nhóm thay đổi bài toán

Kiến trúc Phoenix mô tả một ứng dụng container gồm giao diện, bộ thu trace và cơ sở dữ liệu SQL. SQLite là lựa chọn mặc định cho phát triển cục bộ hoặc một người dùng; PostgreSQL được khuyến nghị cho production nhiều người, với công cụ sao lưu và khả năng truy cập đồng thời phù hợp hơn. Đội đã có PostgreSQL có thể triển khai Phoenix mà không phải thêm loại cơ sở dữ liệu phân tích và dịch vụ hàng đợi như stack Langfuse.

Sự gọn nhẹ đó phụ thuộc vào cách tổ chức dữ liệu. Một instance Phoenix tương ứng một tenant, trong đó quyền truy cập được quản lý theo vai trò. Khi nhiều nhóm cần ranh giới dữ liệu độc lập, có thể triển khai các instance cùng cơ sở dữ liệu riêng; tài liệu cũng nêu phương án dùng các schema PostgreSQL để cô lập dữ liệu trong một cơ sở dữ liệu chung. Mỗi cách đặt ra mức độ tách biệt và công việc quản trị khác nhau.

Vì thế, câu hỏi không chỉ là khởi chạy Phoenix cần bao nhiêu dịch vụ. Một nhóm dùng chung môi trường sẽ có nhu cầu khác tổ chức phải tách môi trường thử, production và dữ liệu của từng đơn vị. Cần tính số bản triển khai, cách cấp quyền và phạm vi sao lưu theo ranh giới dữ liệu thực sự cần duy trì.

Giấy phép tác động trực tiếp đến cách cung cấp sản phẩm

Phần lõi MIT của Langfuse và các chức năng quản trị cần giấy phép doanh nghiệp phải được xem riêng. Việc cần một tính năng quản trị có trả phí không làm thay đổi giấy phép của toàn bộ phần lõi. Đội mua hoặc tự host nên đối chiếu chính xác những quyền quản trị, kiểm toán và lưu giữ dữ liệu mà mình cần với phạm vi bản triển khai dự định dùng.

Phoenix dùng Elastic License 2.0. Điều khoản trong kho mã Phoenix cho phép sử dụng và sửa đổi phần mềm, nhưng hạn chế việc cung cấp nó cho bên thứ ba như một dịch vụ lưu trữ hoặc quản lý khi người dùng được tiếp cận phần đáng kể chức năng của Phoenix. Tự host phục vụ công việc nội bộ và bán quyền sử dụng một dịch vụ quan sát dựa trên Phoenix là hai mô hình cần phân biệt. Nếu sản phẩm dự kiến cho khách hàng truy cập trực tiếp vào năng lực của nền tảng, điều khoản này có thể quyết định lựa chọn trước cả chi phí máy chủ.

Ngôn ngữ, prompt và eval quyết định giá trị của trace

Tài liệu Phoenix mô tả việc nhận trace qua OpenTelemetry và OpenInference, với đường tích hợp cho Python, TypeScript và Java. Phoenix còn hỗ trợ chấm đầu ra, lưu phiên bản prompt, tạo tập dữ liệu từ trace và chạy thí nghiệm trên cùng đầu vào. Điều cần phân biệt là ngôn ngữ dùng để gửi trace và nơi đội viết, chạy bộ đánh giá: gửi được span từ ứng dụng chưa đồng nghĩa toàn bộ quy trình eval đã khớp với cách phát triển phần mềm của đội.

Langfuse cũng kết nối trace với prompt, tập dữ liệu và điểm đánh giá trong môi trường tự host. Giá trị của sự kết nối này xuất hiện khi một lỗi trong trace có thể trở thành mẫu thử, một phiên bản prompt mới được chạy trên cùng tập đầu vào và kết quả được so bằng tiêu chí do đội định nghĩa. Nếu bộ tiêu chí không phản ánh chất lượng đầu ra cần cải thiện, cả hai nền tảng vẫn có thể lưu rất nhiều trace mà không giúp phân biệt thay đổi tốt hay xấu.

Với ứng dụng có dữ liệu nhạy cảm, quyết định còn phụ thuộc vào nội dung được đưa vào span: prompt, đầu ra, thuộc tính người dùng và kết quả truy xuất có thể cần thời hạn giữ cùng quyền xem khác nhau. Langfuse đặt dữ liệu qua nhiều thành phần lưu trữ; Phoenix đòi hỏi chọn cơ sở dữ liệu và ranh giới instance phù hợp. Đội có hạ tầng phân tích sẵn và muốn giữ cùng sản phẩm giữa cloud với tự host có lý do chọn Langfuse. Đội muốn bắt đầu với ít dịch vụ hơn có lý do chọn Phoenix, miễn là mô hình tách nhóm và điều kiện giấy phép phù hợp với cách họ sẽ dùng sản phẩm.

Đọc thêm:

Chia sẻ:

Đăng ký bản tin

Nhận tin Web3, AI và tiền mã hóa mới nhất ngay trong hộp thư.

0