Đây là một phần trong loạt bài chúng tôi đang xuất bản trong khuôn khổ Langfuse Academy, nơi chúng tôi hướng dẫn toàn bộ vòng đời kỹ thuật AI. Nếu bạn mới bắt đầu với loạt bài này, The AI Engineering Loop là nơi tốt nhất để bắt đầu.
Tóm tắt ngắn về AI Engineering Loop
AI Engineering Loop là cách các nhóm liên tục cải thiện hệ thống AI. Nó kết nối những gì đang diễn ra trong sản xuất (tracing, monitoring) với quy trình lặp có cấu trúc trong quá trình phát triển (datasets, experiments, evaluation). Mỗi cải tiến được triển khai đều tạo ra dữ liệu mới, và các nhóm lặp lại quy trình này một cách liên tục.
Bạn có thể đọc thêm về điều này tại đây.
Cách tracing phù hợp với vòng lặp
Phần mềm truyền thống phần lớn là xác định (deterministic), các lần thực thi tuân theo một định dạng được xác định trước. Đối với các ứng dụng LLM thì không phải vậy. Việc thực thi agent có thể lộn xộn, chúng ta đang đối mặt với hành vi nổi (emergent behaviour) với đầu vào, đầu ra phong phú và bất ngờ, cùng thứ tự thực thi. Bạn cần một thứ khác để theo dõi hành vi của agent: traces.
Tracing là trung tâm của toàn bộ vòng lặp cải tiến. Mọi bước khác (xem xét, xây dựng dataset, chạy thử nghiệm, đánh giá) đều hoạt động dựa trên traces.
Nếu bạn đã quen với các khái niệm observability truyền thống, một số nội dung sau đây có thể cảm thấy lặp lại. Bạn có thể lướt qua hoặc bỏ qua.
Giải phẫu của một trace
Một trace có thể phức tạp hoặc đơn giản tùy theo yêu cầu của ứng dụng, nhưng tất cả các trace đều có cùng cấu trúc cơ bản. Nó bao gồm một tập hợp các observations mô tả đường đi mà agent của bạn đã thực hiện.
Một observation là một bước duy nhất trong quy trình. Nó có đầu vào, đầu ra, thời gian bắt đầu/kết thúc, và metadata về những gì đã xảy ra trong bước đó.
Phân cấp
Một trace có cấu trúc cây phân cấp. Bên trong là các observation lồng nhau, có thể chứa các observation khác, tạo thành cấu trúc cha-con phản ánh quá trình thực thi thực tế của ứng dụng AI của bạn.
Bạn có thể thấy những gì đã xảy ra theo thứ tự nào, và bước nào là một phần của bước lớn hơn nào.
Dữ liệu observation
Đầu vào và đầu ra. Mỗi observation có thể có đầu vào và đầu ra. Hầu hết thời gian nó sẽ có cả hai; trong một số trường hợp cụ thể, nó có thể chỉ có một trong hai. Điều quan trọng cho khả năng diễn giải là bạn đặt đầu vào và/hoặc đầu ra phù hợp với loại hành động đang diễn ra trong observation đó.
Các loại observation. Để dễ dàng phân biệt giữa các thao tác, bạn sẽ thấy các loại observation khác nhau. Mỗi loại observation được sử dụng để ghi lại các loại tương tác khác nhau của một agent.
Các loại observation giúp đọc trace và lọc dễ dàng hơn. Trong một trace có 20 observation, việc nhanh chóng xác định các lệnh gọi LLM sẽ tiết kiệm thời gian.
Chi phí, độ trễ, lượng token
Ngoài đầu vào và đầu ra, có một vài thuộc tính trên observation là yếu tố cơ bản trong bất kỳ ứng dụng LLM nào: chi phí, độ trễ và lượng token. Các thuộc tính này được ghi lại cho từng observation và tổng hợp ở cấp độ trace.
Traces so với sessions
Hầu hết thời gian bạn sẽ không thấy toàn bộ vòng đời thực thi của một agent trong một trace. Các trace có thể được nhóm thành sessions. Nhưng ranh giới giữa trace và session ở đâu?
Một nguyên tắc chung là: một trace tương ứng với một lần gọi hệ thống của bạn, thường là một lệnh gọi API hoặc một lần thực thi agent. Một session sau đó nhóm nhiều trace lại với nhau, ví dụ như tất cả các lượt trong một cuộc hội thoại nhiều lượt.
Bắt đầu từ đâu
Nếu bạn mới bắt đầu, hãy tập trung vào việc thiết lập instrumentation cho một quy trình thực tế từ đầu đến cuối trước khi cố gắng bao phủ mọi đường đi có thể.
- Thiết lập tracing cho một đường dẫn yêu cầu quan trọng trong ứng dụng của bạn.
- Đảm bảo mỗi observation ghi lại đầu vào, đầu ra và metadata hữu ích cho bước mà nó đại diện.
- Xem xét thủ công một vài trace thực tế để xác nhận rằng cấu trúc dễ theo dõi và hữu ích cho việc gỡ lỗi.
Tiếp theo là gì
Khi bạn đã thấy traces, bạn có thể chuyển sang bước tiếp theo: monitoring. Monitoring là thứ kết nối traces với vòng lặp cải thiện và lặp lại trên agent của bạn.
