Theo dõi LLM tại Cổng AI: Xem mọi lần gọi mô hình

Việc theo dõi LLM trở nên dễ dàng hơn nhiều khi lưu lượng mô hình chạy qua một lớp cổng duy nhất. Thay vì yêu cầu mỗi nhóm sản phẩm thêm ghi nhật ký tùy chỉnh xung quanh mỗi lời nhắc, cuộc gọi công cụ, thử lại và phản hồi từ nhà cung cấp, cổng có thể trở thành nơi nhất quán để đo lường hoạt động AI.

Điều này trở nên quan trọng khi một ứng dụng vượt qua giai đoạn nguyên mẫu đơn giản. Một tính năng AI trong sản xuất có thể gọi nhiều mô hình, sử dụng các tuyến dự phòng, kích hoạt công cụ, chạy các công việc nền và phục vụ nhiều khách hàng với các mẫu sử dụng khác nhau. Nếu không có các dấu vết có cấu trúc, các nhóm sẽ phải đoán lý do tại sao phản hồi lại chậm, tốn kém, chất lượng thấp hoặc khó tái tạo.

Đối với các nhóm đã sử dụng API AI hoặc đang đánh giá kiến trúc cổng, việc theo dõi LLM là thói quen vận hành tiếp theo cần thiết kế sớm.

Những gì LLM Tracing Nên Ghi Lại

Một dấu vết hữu ích không chỉ là lời nhắc và phản hồi thô. Nó nên giải thích những gì đã xảy ra trong một yêu cầu AI từ lúc ứng dụng gửi đi đến lúc người dùng nhận được câu trả lời.

• Mô hình và nhà cung cấp nào đã xử lý yêu cầu
• Yêu cầu mất bao lâu từ đầu đến cuối
• Số lượng token đầu vào và đầu ra đã sử dụng
• Liệu có liên quan đến định tuyến, dự phòng, thử lại hoặc giới hạn tốc độ hay không
• Ứng dụng, người dùng, không gian làm việc hoặc tính năng nào đã tạo ra cuộc gọi
• Các cuộc gọi công cụ, bước đại lý hoặc hệ thống hạ nguồn nào là một phần của phiên
• Liệu đầu ra có vượt qua đánh giá, kiểm duyệt hoặc kiểm tra chất lượng hay không

Mục tiêu không phải là lưu trữ mọi thứ mãi mãi. Mục tiêu là làm cho hành vi AI trong sản xuất đủ dễ hiểu để các nhóm kỹ thuật, sản phẩm và hỗ trợ có thể gỡ lỗi các sự cố thực tế mà không cần phải tái tạo lại dòng thời gian bằng tay.

Tại sao Cổng là Nơi Tốt Nhất để Bắt Đầu

Theo dõi ở cấp độ ứng dụng có thể hoạt động cho một ứng dụng. Nó trở nên phức tạp khi có nhiều ứng dụng, đội nhóm, mô hình và nhà cung cấp tham gia. Mỗi đội nhóm có thể ghi lại các trường khác nhau, sử dụng các quy ước đặt tên khác nhau hoặc bỏ qua việc theo dõi hoàn toàn khi thời hạn trở nên gấp rút.

Một cổng cung cấp cho các đội nhóm một cửa trước duy nhất cho lưu lượng mô hình. Lớp trung tâm đó có thể chuẩn hóa siêu dữ liệu yêu cầu, dữ liệu sử dụng, phản hồi của nhà cung cấp và quyết định định tuyến trước khi dữ liệu chảy vào hệ thống quan sát hoặc đánh giá.

Đây cũng là lý do tại sao việc theo dõi LLM phù hợp một cách tự nhiên bên cạnh các quyết định cổng rộng hơn. Một đội nhóm hỏi tại sao họ nên sử dụng một cổng LLM thường đang hỏi về quyền truy cập mô hình, định tuyến, chuyển đổi dự phòng, kiểm soát chi phí và quản trị. Việc theo dõi biến những quyết định cổng đó thành bằng chứng mà đội nhóm có thể kiểm tra sau này.

Theo dõi LLM Tại Cổng AI Hỗ Trợ Đánh Giá

Theo dõi và đánh giá nên được kết nối. Một dấu vết cho bạn biết điều gì đã xảy ra. Một vòng lặp đánh giá giúp bạn quyết định liệu kết quả có đủ tốt hay không.

Khi các dấu vết được ghi lại một cách nhất quán, các đội nhóm có thể biến các ví dụ sản xuất thực tế thành các bộ đánh giá. Họ có thể so sánh các thay đổi lời nhắc, kiểm tra hoán đổi mô hình, phân tích lỗi và xác định bước chính xác nơi một tác nhân đã đi sai hướng.

Điều này đặc biệt hữu ích cho các tác nhân và quy trình làm việc nhiều bước. Một câu trả lời cuối cùng có thể trông sai, nhưng nguyên nhân gốc có thể nằm ở giai đoạn trước trong chuỗi: trình truy xuất trả về ngữ cảnh yếu, một cuộc gọi công cụ thất bại một cách âm thầm, mô hình vượt quá ngân sách hoặc một mô hình dự phòng xử lý yêu cầu khác với mong đợi.

Với việc theo dõi ở cấp độ cổng, các sự kiện này có thể được kết nối trên toàn bộ đường dẫn yêu cầu thay vì bị phân tán trong nhật ký ứng dụng, bảng điều khiển nhà cung cấp và ảnh chụp màn hình riêng lẻ.

Sử dụng Tiêu Chuẩn Nơi Chúng Có Ích

Các đội nhóm không cần phải phát minh ra một định dạng theo dõi riêng nếu một tín hiệu tiêu chuẩn đã hoạt động. Các dấu vết OpenTelemetry được thiết kế để đại diện cho công việc dưới dạng các khoảng liên kết, điều này làm cho chúng phù hợp hữu ích cho các yêu cầu AI phức tạp di chuyển qua nhiều dịch vụ.

Đối với các hệ thống AI, lựa chọn quan trọng là mô hình khoảng. Một dấu vết thực tế có thể bao gồm một khoảng cha cho yêu cầu của người dùng, các khoảng con cho định tuyến, cuộc gọi mô hình, cuộc gọi công cụ, truy xuất, đánh giá và xử lý hậu kỳ, cộng với siêu dữ liệu cho tên mô hình, sử dụng token, độ trễ và loại lỗi.

Cấu trúc đó làm cho các dấu vết trở nên hữu ích giữa các nhóm. Các kỹ sư nền tảng có thể kiểm tra độ trễ và lỗi của nhà cung cấp. Các nhóm sản phẩm có thể nghiên cứu các tính năng nào thúc đẩy việc sử dụng. Các nhóm tài chính có thể hiểu các mẫu chi phí token. Các nhóm hỗ trợ có thể điều tra các lỗi do người dùng báo cáo với một dòng thời gian thực.

Cẩn Thận Với Dữ Liệu Lời Nhắc Và Phản Hồi

Các dấu vết LLM có thể chứa dữ liệu nhạy cảm. Lời nhắc và phản hồi có thể bao gồm hồ sơ khách hàng, tài liệu nội bộ, thông tin đăng nhập vô tình được người dùng dán vào, hoặc ngữ cảnh kinh doanh bí mật.

Trước khi xuất dữ liệu yêu cầu đầy đủ, các nhóm nên quyết định những gì cần được thu thập, che giấu, lấy mẫu, hoặc loại trừ. Trong nhiều trường hợp, siêu dữ liệu là đủ cho phân tích chi phí, độ trễ, định tuyến và độ tin cậy. Việc thu thập đầy đủ lời nhắc và phản hồi có thể hữu ích cho việc đánh giá chất lượng, nhưng nó cần được kiểm soát một cách cẩn thận.

Một kế hoạch theo dõi tốt trả lời bốn câu hỏi: ai có thể xem các dấu vết, các trường nào được lưu trữ, dữ liệu được giữ lại bao lâu, và những gì không bao giờ được rời khỏi môi trường kiểm soát.

Danh Sách Kiểm Tra Theo Dõi LLM Thực Tế

• Định tuyến các cuộc gọi mô hình sản xuất qua một lớp API duy nhất nếu có thể.
• Đính kèm siêu dữ liệu ổn định như ứng dụng, môi trường, không gian làm việc, tính năng, và định danh người dùng hoặc nhóm.
• Theo dõi mô hình, nhà cung cấp, độ trễ, sử dụng token, mã trạng thái, thử lại, dự phòng, và dữ liệu lỗi.
• Kết nối các cuộc gọi công cụ và các bước tác nhân với cùng một dấu vết cha.
• Xuất các dấu vết sau khi yêu cầu hướng tới người dùng hoàn tất nếu có thể, để khả năng quan sát không làm chậm đường dẫn phản hồi.
• Gửi các dấu vết vào một công cụ quan sát hoặc đánh giá mà nhóm thực sự sẽ sử dụng.
• Loại trừ, che giấu, hoặc lấy mẫu dữ liệu lời nhắc và phản hồi nhạy cảm dựa trên chính sách.
• Xem xét các dấu vết thường xuyên để cải thiện định tuyến, lời nhắc, lựa chọn mô hình, và kiểm soát chi phí.

Vị Trí Của ShareAI

ShareAI cung cấp cho các nhà phát triển một API cho hơn 150+ mô hình, với khả năng hiển thị trên thị trường, định tuyến, chuyển đổi dự phòng, theo dõi sử dụng và truy cập trả phí theo token. Lớp truy cập mô hình trung tâm đó là nền tảng mà các nhóm cần trước khi họ có thể suy nghĩ rõ ràng về lưu lượng AI trên các ứng dụng và nhà cung cấp.

Khi các cuộc gọi mô hình được tập trung hóa, các nhóm có thể đưa ra quyết định tốt hơn về những gì cần theo dõi, những gì cần đánh giá và nơi cần tối ưu hóa. Họ có thể so sánh hành vi của mô hình, hiểu các mẫu sử dụng và xây dựng thói quen vận hành dựa trên bằng chứng sản xuất thực tế thay vì các bảng điều khiển nhà cung cấp rải rác.

Bắt đầu bằng cách định tuyến các cuộc gọi mô hình thông qua một tích hợp, sau đó thiết kế quy trình theo dõi và đánh giá của bạn xung quanh các tín hiệu quan trọng nhất: độ trễ, chi phí, chất lượng, độ tin cậy và tác động đến người dùng.