Observability

Khả năng quan sát là khả năng hiểu những gì đang diễn ra bên trong một hệ thống phần mềm dựa trên telemetry mà hệ thống phát ra—chủ yếu là log, metric và trace—đủ để trả lời các câu hỏi mới về hành vi mà không cần triển khai mã mới. Thuật ngữ này bắt nguồn từ lý thuyết điều khiển; năm 1960, Rudolf Kálmán định nghĩa một hệ thống là có thể quan sát nếu có thể xác định trạng thái bên trong từ đầu ra. Các nhóm phần mềm tiếp nhận thuật ngữ này trong thập niên 2010, khi hệ thống được chia thành nhiều dịch vụ và lỗi không còn khớp với các dashboard được dựng sẵn. Với các hệ thống học máy, khả năng quan sát còn bao gồm dữ liệu và dự đoán: model nhận đầu vào nào, tạo đầu ra gì, độ tin cậy ra sao và cả hai thay đổi thế nào theo thời gian.

Log, metric và trace#

Ba loại telemetry, thường được gọi là các trụ cột của khả năng quan sát, giúp trả lời những câu hỏi khác nhau:

• Metric: Chuỗi thời gian dạng số như tốc độ yêu cầu, tỷ lệ lỗi, phân vị độ trễ, mức sử dụng bộ nhớ và GPU; dữ liệu này có chi phí lưu trữ thấp, phù hợp với dashboard và cảnh báo. Sách về kỹ thuật độ tin cậy trang web của Google nêu bốn tín hiệu vàng cần đo cho mọi dịch vụ: độ trễ, lưu lượng, lỗi và mức bão hòa.
• Log: Bản ghi sự kiện có dấu thời gian; hữu ích nhất khi được cấu trúc dưới dạng JSON với các trường như ID yêu cầu, phiên bản model và kích thước đầu vào để có thể lọc và đếm.
• Trace: Đường đi của một yêu cầu qua mọi dịch vụ mà yêu cầu đó đi qua, được ghi lại thành cây span; mỗi span có tên, thời điểm bắt đầu, thời lượng và thuộc tính, cho biết yêu cầu đã tiêu tốn thời gian ở đâu.

OpenTelemetry, được hình thành năm 2019 bằng cách hợp nhất các dự án OpenTracing và OpenCensus, cung cấp API, SDK và giao thức truyền tải trung lập với nhà cung cấp (OTLP) cho cả ba tín hiệu; các backend như Prometheus, Grafana và Jaeger lưu trữ cũng như hiển thị chúng. Ví dụ này trace một yêu cầu phân loại ảnh bằng OpenTelemetry Python SDK, ghi một span cha cho yêu cầu và một span con cho từng giai đoạn:

import torch
import torchvision
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import SimpleSpanProcessor
from opentelemetry.sdk.trace.export.in_memory_span_exporter import InMemorySpanExporter

# Keep finished spans in memory; a production service exports them over OTLP instead
exporter = InMemorySpanExporter()
provider = TracerProvider()
provider.add_span_processor(SimpleSpanProcessor(exporter))
tracer = provider.get_tracer("classifier")
model = torchvision.models.resnet18().eval()
frame = torch.rand(3, 1080, 1920)

# Trace one request as a parent span with a child span for each stage
with tracer.start_as_current_span("predict", attributes={"model.name": "resnet18", "image.height": 1080}):
    with tracer.start_as_current_span("preprocess"):
        batch = torchvision.transforms.functional.resize(frame, [224, 224]).unsqueeze(0)
    with tracer.start_as_current_span("inference"), torch.inference_mode():
        logits = model(batch)

spans = exporter.get_finished_spans()
names = {span.context.span_id: span.name for span in spans}
for span in spans:
    parent = names[span.parent.span_id] if span.parent else "-"
    print(f"{span.name:<11} {(span.end_time - span.start_time) / 1e6:5.1f} ms  parent: {parent}")

Trên CPU Apple M5 Pro, chương trình in ra một span preprocess dài 1.0 đến 1.4 ms và một span inference dài 7 đến 9 ms; cả hai đều có predict làm span cha, cùng một span predict dài 8 đến 10 ms, cho thấy trace quy phần lớn thời gian của yêu cầu cho model. Khi các span được xuất qua OTLP, mọi dịch vụ xử lý yêu cầu đều thêm span dưới cùng một trace ID; backend như Jaeger sẽ hiển thị chúng trên cùng một dòng thời gian.

Observability và giám sát#

Giám sát model theo dõi các kiểu lỗi đã biết bằng metric, dashboard và ngưỡng cảnh báo được xác định trước, chẳng hạn tỷ lệ lỗi vượt 1% hoặc độ trễ suy luận vượt mục tiêu. Khả năng quan sát là thuộc tính rộng hơn, cho phép điều tra những lỗi chưa ai dự đoán bằng cách phân tích telemetry chi tiết sau sự việc theo khách hàng, phiên bản model, camera hoặc bất kỳ thuộc tính nào khác. Sách Google SRE yêu cầu hoạt động giám sát trả lời hai câu hỏi: điều gì đang hỏng và vì sao; quá trình điều tra đi từ câu trả lời thứ nhất đến câu trả lời thứ hai dựa trên cả ba loại tín hiệu:

AI có thể giải thích là một lĩnh vực riêng, giải thích vì sao model tạo ra đầu ra cụ thể dựa trên các đặc trưng đầu vào hoặc activation nội bộ; các giá trị quy kết của lĩnh vực này có thể được ghi log như một tín hiệu bổ sung.

Khả năng quan sát trong học máy#

Các hệ thống học máy thường gặp lỗi âm thầm: model thị giác máy tính có thể trả lời mọi yêu cầu bằng HTTP 200 trong khi dự đoán suy giảm do camera bị dịch chuyển, ánh sáng thay đổi hoặc xuất hiện sản phẩm mới. Vì vậy, khả năng quan sát ML bổ sung telemetry về dữ liệu và dự đoán bên cạnh các tín hiệu dịch vụ thông thường. Các nhóm ghi lại thống kê đầu vào như kích thước và độ sáng ảnh để phát hiện trôi dạt dữ liệu, theo dõi phân phối dự đoán như số lượng từng lớp, kết quả rỗng và độ tin cậy trung bình, đồng thời tính độ chính xác theo phân đoạn khi nhãn sự thật nền đến, thường là sau vài ngày. Trong quá trình huấn luyện, callback gửi đường cong loss, metric và mức sử dụng hệ thống của từng lần chạy đến công cụ theo dõi thí nghiệm như TensorBoard và MLflow. Với ứng dụng tác tử AI và mô hình ngôn ngữ lớn, trace ghi lại từng prompt, bước truy xuất, lần gọi công cụ và phản hồi; các quy ước ngữ nghĩa GenAI của OpenTelemetry chuẩn hóa những thuộc tính như gen_ai.usage.input_tokens để số lượng và chi phí token nhất quán giữa các công cụ.

Mọi endpoint chuyên dụng trên Ultralytics Platform đều tích hợp sẵn giám sát triển khai: thẻ số lượng yêu cầu, tỷ lệ lỗi và độ trễ p95; tab Logs có các mức độ nghiêm trọng và bộ lọc Errors cho mục lỗi và cảnh báo; cùng thống kê dự đoán biểu đồ hóa các lớp hàng đầu, độ tin cậy trung bình theo thời gian, số dự đoán trên mỗi ảnh và thời gian suy luận của model, tách biệt với độ trễ yêu cầu. Đường cong độ tin cậy giảm hoặc sự thay đổi ở các lớp hàng đầu sẽ hiển thị trên biểu đồ ngay cả khi mọi yêu cầu đều thành công.