Hướng dẫn sử dụng OpenLLMetry và Traceloop để giám sát và truy vết ứng dụng LLM - ITFROMZERO - Share tobe shared! Ứng dụng LLM chạy chậm, ngốn token và dính lỗi ngầm khi lên production? Bài viết hướng dẫn chi tiết cách triển khai OpenLLMetry và Traceloop để tracing toàn bộ luồng xử lý AI theo chuẩn OpenTelemetry.

Table of Contents

Vấn đề thực tế khi đưa ứng dụng LLM lên Production

Lúc thử nghiệm local, app GenAI nào trông cũng mượt. Bạn gõ vài dòng gọi OpenAI API hay LangChain, nhận kết quả sau 2-3 giây và tự tin deploy. Nhưng môi trường production lại là một câu chuyện hoàn toàn khác.

Hàng loạt vấn đề thực tế lập tức phát sinh:

Phản hồi chậm chạp: Một request ngốn tới 12-15 giây. Bạn loay hoay không rõ điểm nghẽn nằm ở khâu embed văn bản, bước query Milvus/Pinecone hay do chính model phản hồi trễ.
Chi phí token tăng vọt: Hóa đơn API cuối tháng tăng gấp 3 lần. Đội ngũ không tài nào biết workflow nào đang ngốn token nhiều nhất, hay agent nào đang rơi vào vòng lặp vô tận.
Lỗi ngầm (Silent failure): Model trả về JSON sai schema, output rỗng hoặc bị hallucination. Backend không hề văng exception nào mà chỉ trả mã 200 kèm nội dung vô nghĩa, hoặc crash với log Internal Server Error cụt lủn.

Dùng print() hay đọc log text thủ công trong chuỗi RAG nhiều bước? Đó thực sự là cực hình.

Tại sao giám sát LLM khác hẳn hệ thống CRUD truyền thống?

Với web service thông thường, luồng chạy rất thẳng thắn: Route → Controller → Database → Response. Các công cụ APM quen thuộc chỉ việc đo thời gian query SQL và bắt HTTP status code.

Ứng dụng LLM lại có những đặc thù riêng:

Tính bất định (Non-deterministic): Cùng một câu hỏi đầu vào, mỗi lần chạy model lại sinh ra độ dài token và nội dung khác biệt.
Chuỗi gọi phức tạp (Chains & Agents): Một câu lệnh của user có thể kích hoạt 2 lần embedding, 3 lần truy vấn vector database và 4 lần gọi tool trung gian.
Mỗi SDK một kiểu: OpenAI, Anthropic, ChromaDB hay Cohere đều có định dạng payload riêng. Không có một schema chung nào để gom nhóm trace.

Nếu không bóc tách từng span thực thi, bạn sẽ hoàn toàn mù mờ khi hệ thống gặp sự cố lúc nửa đêm.

Ba hướng tiếp cận Observability cho LLM hiện nay

Tùy theo quy mô dự án, các team thường cân nhắc 3 hướng đi:

Cách 1: Tự viết decorator và log thủ công

Bạn tự bọc hàm bằng decorator, đo thời gian chạy bằng time.perf_counter() rồi ghi prompt và latency vào file JSON log.

Ưu điểm: Không phụ thuộc thư viện bên ngoài.
Nhược điểm: Tốn công bảo trì. Code nghiệp vụ bị rác bởi code logging, không có waterfall view để xem luồng gọi lồng nhau.

Cách 2: Dùng nền tảng đóng gói riêng (Vendor SDKs)

Các giải pháp chuyên biệt như LangSmith hay Arize Phoenix cung cấp giao diện dựng sẵn khá đẹp mắt.

Ưu điểm: Giao diện trực quan, cài đặt nhanh với các framework tương thích.
Nhược điểm: Rất dễ dính vendor lock-in. Nếu muốn chuyển trace sang Datadog, Dynatrace hoặc đổi framework từ LangChain sang llamaindex/custom code, bạn gần như phải làm lại từ đầu.

Cách 3: Chuẩn hóa OpenTelemetry với OpenLLMetry và Traceloop

OpenLLMetry là bộ công cụ mã nguồn mở do Traceloop phát triển. Dự án này mở rộng chuẩn công nghiệp OpenTelemetry (OTel) bằng semantic conventions dành riêng cho LLM. Công cụ tự động gắn instrumentation cho OpenAI, Anthropic, LangChain hay ChromaDB mà không bắt bạn sửa code gọi model.

Hướng dẫn triển khai OpenLLMetry với Traceloop

Cách tiếp cận linh hoạt nhất là dùng traceloop-sdk. Bạn vừa có auto-instrumentation sạch sẽ, vừa dễ dàng xuất trace về Traceloop Cloud hoặc cụm Jaeger/Grafana nội bộ.

Bước 1: Cài đặt thư viện

Cài đặt SDK qua pip trong môi trường ảo của dự án:

pip install traceloop-sdk openai

Bước 2: Cấu hình biến môi trường

Đăng ký tài khoản miễn phí tại app.traceloop.com để lấy API key, sau đó export biến môi trường:

export TRACELOOP_API_KEY="tlp_your_api_key_here"
export OPENAI_API_KEY="sk-proj-your_openai_key"

Bước 3: Khởi tạo Traceloop trong mã nguồn Python

Điểm mạnh của Traceloop nằm ở tính tinh gọn: gọi đúng một lệnh init ở entry point. Toàn bộ request OpenAI phía sau sẽ tự động được trace.

import os
from traceloop.sdk import Traceloop
from openai import OpenAI

# 1. Khởi tạo Traceloop trước khi gọi bất kỳ client AI nào
Traceloop.init(
    app_name="customer-support-bot",
    disable_batch=True  # Đẩy trace ngay lập tức, cực kỳ hữu ích khi debug local
)

# 2. Khởi tạo client OpenAI bình thường
client = OpenAI(api_key=os.environ.get("OPENAI_API_KEY"))

def generate_answer(question: str) -> str:
    response = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[
            {"role": "system", "content": "Bạn là trợ lý giải đáp kỹ thuật ngắn gọn."},
            {"role": "user", "content": question}
        ],
        temperature=0.2
    )
    return response.choices[0].message.content

if __name__ == "__main__":
    user_query = "OpenTelemetry là gì và tại sao cần dùng cho LLM?"
    answer = generate_answer(user_query)
    print("Phản hồi từ model:", answer)

Bước 4: Nhóm tác vụ nghiệp vụ bằng Decorator

Một pipeline thực tế thường gồm nhiều công đoạn: kiểm tra đầu vào, truy vấn database, gọi model và hậu xử lý kết quả. Hãy dùng decorator @workflow và @task để cấu trúc trace tree rõ ràng trên dashboard:

from traceloop.sdk.decorators import workflow, task
from openai import OpenAI

client = OpenAI()

@task(name="validate_input")
def check_prompt(prompt: str) -> bool:
    # Chặn các prompt quá ngắn hoặc rác
    return len(prompt.strip()) > 5

@task(name="call_llm_service")
def ask_llm(prompt: str) -> str:
    res = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": prompt}]
    )
    return res.choices[0].message.content

@workflow(name="full_qa_pipeline")
def handle_user_request(query: str):
    if not check_prompt(query):
        return "Câu hỏi quá ngắn, vui lòng nhập lại!"
    return ask_llm(query)

# Chạy thử workflow
handle_user_request("Cách cấu hình OpenLLMetry đẩy trace về Jaeger?")

Bước 5: Phân tích chỉ số trên Dashboard

Mở giao diện Traceloop hoặc Grafana Tempo, bạn sẽ thấy ngay các thông số trọng yếu:

Phân rã độ trễ (Latency Breakdown): Biểu đồ waterfall chỉ rõ từng span. Ví dụ: bước validate mất 12ms, gọi model ngốn 1.840ms.
Thống kê Token: Tách biệt rõ prompt tokens và completion tokens cho từng lượt gọi, giúp bạn tính chính xác chi phí USD của từng tính năng.
Dữ liệu Payload chi tiết: Xem trực tiếp prompt đầu vào và response sinh ra để bắt lỗi hallucination ngay khi user báo sự cố.

Nhờ đi theo chuẩn OpenTelemetry, bạn hoàn toàn chủ động về hạ tầng. Muốn chuyển sang Datadog hay collector nội bộ? Chỉ cần trỏ lại biến môi trường TRACELOOP_BASE_URL mà không phải sửa dù chỉ một dòng logic.