Arize Phoenix: trace và eval cho ứng dụng LLM, chạy ngay trong hạ tầng của khách

Chatbot nội bộ của khách vừa trả lời sai một câu về chính sách hoàn tiền. Việc đầu tiên bạn cần biết là nó sai ở bước nào: retrieval kéo về nhầm tài liệu, model tự bịa ra, hay một tool trả về dữ liệu cũ. Nếu không nhìn được bên trong một lần chạy, bạn chỉ còn cách đoán.

Arize Phoenix là công cụ cho bạn nhìn vào bên trong lần chạy đó. Nó do Arize AI và cộng đồng xây dựng, mã nguồn nằm trên GitHub tại Arize-ai/phoenix. Điều khiến FDE quan tâm là Phoenix chạy được trên laptop, trong container hoặc trên cloud của chính khách.

Lý do rất thực tế: ngân hàng hay bệnh viện hiếm khi chịu gửi prompt và tài liệu nội bộ sang một SaaS bên ngoài. Theo tài liệu self-hosting của Phoenix, khi tự host thì Arize không nhận được chút dữ liệu nào, mọi thứ ở lại trong hạ tầng của khách, kể cả khi hệ thống bị cắt hẳn khỏi internet.

Trace chỉ ra chỗ hỏng, eval cho biết hỏng nhiều đến đâu

Phoenix làm hai việc. Tracing mở một lần chạy ra thành từng bước nối tiếp nhau: lời gọi model, retrieval, tool, cả phần logic mà đội khách tự viết. Eval thì đo chất lượng đầu ra, với evaluator dựa trên LLM, dựa trên code hoặc dựa trên nhãn do người gán.

Hai việc này phải đi cùng nhau vì chúng trả lời hai câu hỏi khác nhau. Trace giải thích một ca lỗi cụ thể. Eval cho biết ca đó là chuyện cá biệt hay là lỗi của cả hệ thống, và đó mới là con số khách muốn nghe trong buổi review.

Vì sao dựa trên OpenTelemetry lại quan trọng ở site khách?

Phoenix xây trên OpenTelemetry và lấy dữ liệu nhờ instrumentation của OpenInference, nên định dạng trace không thuộc riêng một hãng nào. OpenInference là bộ quy ước và plugin bổ sung cho OpenTelemetry. Phoenix hỗ trợ sẵn, nhưng các backend khác cũng dùng được.

Với FDE, chi tiết này có giá trị khi thương lượng. Nhiều khách đã có sẵn hạ tầng OpenTelemetry và rất ngại bị khóa vào một nhà cung cấp. Bạn có thể nói thẳng với họ: phần instrumentation viết hôm nay vẫn dùng được nếu sau này khách muốn chuyển trace sang hệ thống khác.

Một buổi chiều với Docker

Để thử nhanh, bạn chỉ cần một container:

docker run --name phoenix -p 6006:6006 -p 4317:4317 arizephoenix/phoenix:latest

Cổng 6006 vừa phục vụ giao diện, vừa là collector OTLP qua HTTP. Cổng 4317 là collector OTLP qua gRPC. Việc còn lại là trỏ exporter của ứng dụng về một trong hai cổng.

Dưới đây là một phác thảo cho ứng dụng Python gọi OpenAI SDK. Ứng dụng dùng instrumentor của OpenInference và exporter OTLP HTTP chuẩn của OpenTelemetry:

from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter
from openinference.instrumentation.openai import OpenAIInstrumentor

provider = TracerProvider()
provider.add_span_processor(
    BatchSpanProcessor(OTLPSpanExporter(endpoint="http://localhost:6006/v1/traces"))
)
trace.set_tracer_provider(provider)
OpenAIInstrumentor().instrument(tracer_provider=provider)  # every LLM call now becomes a span

Nếu mạng của khách chỉ mở gRPC, bạn đổi sang exporter gRPC của OpenTelemetry và trỏ về cổng 4317. Phần instrumentation giữ nguyên.

Retrieval hỏng hay model hỏng?

Quay lại câu trả lời sai về hoàn tiền. Bạn mở trace và xem span retrieval trước. Nếu các đoạn được kéo về là chính sách của năm ngoái thì lỗi nằm ở index, không nằm ở model.

Còn nếu tài liệu đúng mà câu trả lời vẫn lệch, bạn đang gặp một ca hallucination, và chỗ cần sửa là prompt hoặc model. Một ca thì chưa đủ để kết luận, vì thế bước tiếp theo là đo.

Thử hình dung bạn gom 20 câu hỏi về hoàn tiền và viết evaluator đầu tiên bằng code, chỉ để kiểm tra câu trả lời có trích nguồn hay không:

import re

def has_citation(answer: str) -> bool:
    # Pass if the answer cites a source in the agreed [source: ...] format
    return bool(re.search(r"\[source:[^\]]+\]", answer))

Giả sử 14 trên 20 câu qua, 6 câu trượt. Evaluator thứ hai dùng LLM để chấm xem câu trả lời có bám tài liệu không, rồi bạn tự gán nhãn cả 20 câu. Nếu LLM chỉ khớp với bạn ở 12 câu thì chưa nên đưa con số của nó cho khách: hãy sửa prompt của evaluator trước.

Giấy phép là chỗ dễ vấp nhất

README gọi Phoenix là “open-source and self-hosted”, nhưng file LICENSE lại dùng Elastic License 2.0. Đây là giấy phép source-available, không phải giấy phép mã nguồn mở được OSI công nhận. ELv2 cấm cung cấp phần mềm cho bên thứ ba dưới dạng dịch vụ hosted hoặc managed.

Ranh giới dễ hình dung nhất là đặt hai kịch bản cạnh nhau. Bảng dưới là cách đọc điều khoản đó cho công việc FDE, không thay cho ý kiến pháp lý:

Kịch bản	Cách đọc theo điều khoản ELv2
Cài Phoenix vào hạ tầng của chính khách, đội của khách tự dùng để xem trace và eval	Không phải cung cấp phần mềm cho bên thứ ba dưới dạng dịch vụ, nên là kịch bản ít rủi ro hơn
Consultancy dựng một Phoenix dùng chung rồi bán quyền truy cập cho nhiều khách	Đụng thẳng vào điều khoản cấm cung cấp dưới dạng dịch vụ hosted hoặc managed

Khi soạn statement of work, hãy viết rõ Phoenix chạy trong hạ tầng của ai và ai là người dùng nó. Rồi để bộ phận pháp lý xác nhận ranh giới trước khi ký.

Từ laptop lên production

Arize nói bản tự host miễn phí và không bị giới hạn tính năng. Hãng cũng có một sản phẩm managed riêng tên là Arize AX. Khi khách hỏi vì sao không dùng bản managed, câu trả lời thường nằm ở yêu cầu dữ liệu không được rời khỏi mạng.

Tài liệu Docker có hai lời dặn đáng nhớ. Với Postgres, Phoenix chỉ hỗ trợ chính thức từ bản 14 trở lên, nên hãy hỏi phiên bản database của khách ngay buổi đầu. Khi lên production, hãy pin phiên bản image thay vì dùng latest, để lần nâng cấp sau không âm thầm làm hỏng dashboard đang chạy.

Những lỗi hay gặp khi đưa Phoenix vào dự án

Lỗi phổ biến nhất là tin ngay con số của LLM judge. Một evaluator dựa trên LLM chỉ có giá trị khi bạn đã so nó với nhãn do người gán; nếu nó khớp với bạn ở 12 trên 20 câu như ví dụ trên, tỷ lệ “bám tài liệu” mà nó báo ra chưa đáng đưa lên slide.

Lỗi thứ hai là mang nguyên lệnh docker run ... :latest từ laptop lên production. Lệnh đó hợp để thử, nhưng tài liệu khuyên pin đúng phiên bản bạn định dùng. Đi kèm là chuyện quên kiểm tra Postgres: một database dưới bản 14 nằm ngoài phạm vi hỗ trợ chính thức.

Lỗi thứ ba nằm ở hợp đồng chứ không ở code: coi chữ “open-source” trong README là đủ, rồi lên kế hoạch dựng một Phoenix dùng chung cho nhiều khách. Đọc file LICENSE trước khi viết SOW rẻ hơn nhiều so với sửa SOW sau khi ký.

Học gì trước?

Hãy học khái niệm của OpenTelemetry trước khi học giao diện Phoenix: trace, span, OTLP, khác biệt giữa HTTP và gRPC. Kiến thức này dùng được với mọi backend. Sau đó tập viết evaluator, vì phần khó nhất là định nghĩa thế nào là một câu trả lời “đúng” theo nghiệp vụ của khách.

Khi đọc JD các vị trí FDE, hãy để ý những từ như observability, evals, tracing. Trong CV, một dòng kiểu “dựng tracing cho ứng dụng LLM bằng OpenTelemetry/OpenInference trong VPC air-gapped của khách, theo dõi tỷ lệ câu trả lời bám nguồn” nặng ký hơn nhiều so với việc chỉ liệt kê tên công cụ.

Ứng dụng LLM nào cũng có lúc trả lời sai. Người được khách tin là người chỉ ra được bước gây lỗi và đưa ra con số đo được, ngay trong hạ tầng mà khách cho phép.