Cách Similarweb dùng LangSmith để đánh giá báo cáo nghiên cứu từ AI Agent

Tác giả: Liora Korni, Kỹ sư AI cấp cao tại SimilarWeb

Đã bao nhiêu lần bạn triển khai một bản cập nhật prompt, mô hình hoặc công cụ cho agent, cảm thấy hài lòng với kết quả đầu ra đầu tiên mà bạn kiểm tra, nhưng vẫn cảm thấy bất an? Một kết quả có vẻ tốt hơn trong khi kết quả khác lại mất đi nguồn trích dẫn, bỏ sót một lưu ý quan trọng hoặc bắt đầu phụ thuộc quá nhiều vào một nguồn dữ liệu duy nhất.

Đây là vấn đề của người xây dựng agent. Trong phần mềm truyền thống, một thay đổi sẽ vượt qua các bài kiểm tra hoặc không, và hành vi đó có thể lặp lại. Một hệ thống agentic thì khác: cùng một đầu vào có thể đi theo một lộ trình khác, gọi các công cụ khác nhau và tạo ra một câu trả lời khác nhưng vẫn hợp lệ. Mỗi bản cập nhật là một canh bạc: liệu hệ thống đã tốt hơn hay bạn chỉ đơn thuần chuyển lỗi sang một nơi khác.

Đó là vấn đề chúng tôi gặp phải khi xây dựng Similarweb Data Studio. Similarweb đo lường thế giới kỹ thuật số, ước tính lưu lượng truy cập mà các trang web và ứng dụng nhận được, nguồn gốc của lưu lượng đó, hiệu suất của đối thủ cạnh tranh và sự thay đổi trong sự chú ý của người dùng. Data Studio là lớp agentic nằm trên dữ liệu đó. Thay vì phải điều hướng qua các bảng điều khiển và bộ lọc, người dùng đặt câu hỏi bằng ngôn ngữ tự nhiên, và agent sẽ lập kế hoạch công việc, gọi các công cụ dữ liệu phù hợp, truy xuất các con số và viết câu trả lời. Nó có thể xử lý một tra cứu nhanh (như "bao nhiêu phần trăm lưu lượng truy cập của spotify.com là trực tiếp?"), so sánh đối thủ cạnh tranh hoặc một báo cáo nghiên cứu đa bước đầy đủ. Với mỗi yêu cầu, nó tự quyết định cách thực hiện thay vì tuân theo một kịch bản cố định.

Một hệ thống agentic làm được nhiều việc hơn là chỉ tạo văn bản. Nó chọn công cụ, truy xuất dữ liệu và tổng hợp bằng chứng, vì vậy lỗi hồi quy (regression) có thể ẩn nấp trong bất kỳ bước nào trong số đó. Đó là lý do tại sao việc đánh giá phải trở thành một phần của kiến trúc sản phẩm. Chúng tôi cần một quy trình làm việc có thể hiển thị những trường hợp nào đã thay đổi, các khía cạnh chất lượng nào đã dịch chuyển, người đánh giá (evaluator) đã nói gì và điều gì đã xảy ra trong quá trình truy vết (trace).

LangSmith đã cung cấp cho chúng tôi quy trình đó tại một nơi duy nhất và giữ cho mọi kết quả đều có thể kiểm tra được, từ điểm số cho đến tận quá trình truy vết đằng sau nó.

Những gì bạn sẽ nhận được từ bài viết này: Nếu bạn xây dựng các agent, các pipeline RAG hoặc bất kỳ tính năng LLM nào có đầu ra mở, mang tính chủ quan hoặc dạng dài, và bạn từng do dự trước khi triển khai một thay đổi, thì bài viết này dành cho bạn. Đến cuối bài, bạn sẽ biết:

Hai cách để chấm điểm đầu ra: Kiểm tra xác định (Determinist Checks) và Chấm điểm bằng LLM-as-a-Judge.

Chúng tôi thực hiện hai loại kiểm tra trên đầu ra của agent.

Loại thứ nhất là kiểm tra xác định. Agent có gọi các công cụ bắt buộc không? Nó có tránh các công cụ không nên chạm vào không? Nó có trả về đầu ra có cấu trúc hợp lệ không? Đây là các so sánh đạt/không đạt mang tính cơ học, không liên quan đến mô hình.

Loại thứ hai là LLM-as-a-judge (LLM đóng vai trò giám khảo). Bất cứ khi nào chúng ta quan tâm đến ý nghĩa hoặc chất lượng, các quy tắc xác định sẽ không đủ, vì vậy chúng tôi giao quyết định cho một mô hình. Prompt của giám khảo cung cấp cho mô hình đó ba thứ: 1.) câu hỏi của người dùng, 2.) đầu ra của agent và 3.) tiêu chuẩn để chấm điểm. Sau đó, nó trả về một điểm số và một bình luận giải thích điểm số đó. Tiêu chuẩn có thể là một câu trả lời mẫu (golden answer) ("câu này có nói cùng một ý không?") hoặc một bảng tiêu chí với các mốc chấm điểm rõ ràng ("câu trả lời đáp ứng từng tiêu chuẩn chất lượng tốt đến mức nào?").

Chúng tôi coi giám khảo như một người đánh giá có khả năng mở rộng. Nó tạo ra các tín hiệu có thể kiểm tra được—điểm số, lý do đằng sau đó và liên kết đến quá trình truy vết—để chúng tôi có thể thấy agent thực sự đã làm gì.

Cả hai loại kiểm tra đều chạy trong cùng một vòng lặp đánh giá và xuất hiện cạnh nhau dưới dạng phản hồi trong LangSmith. Câu hỏi khó hơn đối với chúng tôi là: giám khảo nên chấm điểm dựa trên tiêu chuẩn nào?

Trường hợp dễ: Trò chuyện thông thường (Regular Chat)

Trường hợp đơn giản nhất để đánh giá trong một hệ thống agentic là trò chuyện thông thường.

Chú thích: Trò chuyện thông thường: một câu hỏi tập trung với hình thái câu trả lời dễ dự đoán hơn.

Mỗi ví dụ trong benchmark có một prompt cố định, một câu trả lời mẫu, các kiểm tra công cụ dự kiến và đầu ra của agent. Chúng tôi có thể so sánh đầu ra với câu trả lời mẫu, xác minh agent đã gọi các công cụ bắt buộc và theo dõi điểm số theo thời gian.

Cả hai loại kiểm tra đều xuất hiện ở đây. Các kiểm tra công cụ mang tính xác định. Tuy nhiên, việc so sánh đầu ra với câu trả lời mẫu là công việc của LLM-as-judge, vì một câu trả lời đúng có thể được diễn đạt theo nhiều cách và việc khớp văn bản chính xác là quá cứng nhắc. Giám khảo đó là trình đánh giá ngữ nghĩa, dựa trên câu trả lời mẫu. Câu hỏi duy nhất của nó là liệu đầu ra có mang cùng ý nghĩa hay không.

Mỗi trình đánh giá trả về một phản hồi, một khóa, một điểm số và một bình luận. Đối với câu hỏi về lưu lượng truy cập theo kênh ở trên, giám khảo ngữ nghĩa trả về kết quả như sau:

LangSmith biến phản hồi đó thành các cột trong thử nghiệm. Thay vì thu thập điểm số trong bảng tính, chúng tôi có thể so sánh các lần chạy, nhấp vào một điểm số và kiểm tra quá trình truy vết đằng sau nó.

Đối với trò chuyện thông thường, điều này là đủ. Có một câu trả lời dự kiến, vì vậy các kiểm tra xác định và một giám khảo ngữ nghĩa dựa trên đó bao quát hầu hết những gì quan trọng.

Trường hợp khó: Nghiên cứu chuyên sâu (Deep Research)

Đầu ra của Deep Research là các báo cáo dạng dài với nguồn, diễn giải, khuyến nghị, lưu ý và cấu trúc tường thuật. Có thể có nhiều báo cáo tốt cho cùng một câu hỏi.

Chú thích: Deep Research: một câu hỏi mở mà ở đó có thể có nhiều báo cáo tốt.

Một báo cáo mạnh có thể tập trung vào việc thu hút lưu lượng truy cập. Một báo cáo khác có thể tập trung vào vị thế cạnh tranh. Một báo cáo khác nữa có thể tập trung vào rủi ro kiếm tiền. Tất cả đều có thể hợp lệ nếu các tuyên bố có cơ sở và lập luận chặt chẽ.

Câu trả lời mẫu không hoạt động tốt trong trường hợp này. Không có tài liệu tham khảo duy nhất nào để so sánh và việc khớp với một báo cáo tham khảo chỉ thưởng cho sự tương đồng chứ không phải chất lượng. Vì vậy, thay vì một tài liệu tham khảo, chúng tôi cung cấp cho giám khảo một bảng tiêu chí: mỗi khía cạnh chất lượng có bảng tiêu chí riêng với các mốc chấm điểm rõ ràng, vì vậy giám khảo trả về điểm số cho từng khía cạnh thay vì một phán quyết tổng thể. Ví dụ, tiêu chí source_integration (tích hợp nguồn) hỏi liệu báo cáo có sử dụng các nguồn bên ngoài ngoài dữ liệu thô của nền tảng hay không:

Mỗi tiêu chí trả về một điểm số cộng với một giải thích ngắn gọn, vì vậy một con số thấp luôn đi kèm với lý do mà chúng tôi có thể kiểm tra. Một báo cáo có nguồn sơ sài sẽ nhận được đúng đánh giá đó:

Bên cạnh các bảng tiêu chí chất lượng, chúng tôi chạy các kiểm tra độ trung thực (faithfulness checks) để xác minh xem mỗi tuyên bố có thực sự tuân theo dữ liệu được truy xuất hay không, hay agent đã phóng đại những gì các nguồn hỗ trợ? Đây là nơi các tuyên bố tự tin nhưng không có cơ sở xuất hiện, điều này quan trọng nhất khi đầu ra dài và mang tính thuyết phục.

Các bảng tiêu chí và kiểm tra độ trung thực chấm điểm một báo cáo dựa trên các tiêu chuẩn riêng của nó. Để quyết định xem một phiên bản mới có thực sự tốt hơn không, chúng tôi cũng chạy so sánh A/B với một baseline: một lần chạy trước đó đã được lưu và chấp nhận mà chúng tôi coi là điểm tham chiếu, không phải là chân lý tuyệt đối. Giám khảo xem báo cáo mới bên cạnh baseline và cho biết cái nào mạnh hơn, thay vì chấm điểm một cách cô lập.

LangSmith kết nối điểm số của trình đánh giá với các quá trình truy vết và so sánh baseline

Viết một prompt cho trình đánh giá chỉ là một phần của quy trình làm việc. Phần khó hơn là chạy vòng lặp nhiều lần và quyết định xem một thay đổi có thực sự hiệu quả hay không.

LangSmith làm cho điều đó trở nên khả thi vì không có gì bị cô lập. aevaluate chạy vòng lặp trên một tập dữ liệu cố định, với các lần lặp lại và tính đồng thời; mọi điểm số của trình đánh giá đều nằm dưới dạng một cột, mọi điểm số đều mang theo bình luận của nó và mọi lần chạy đều liên kết trực tiếp đến quá trình truy vết và đến một baseline để so sánh. Điểm khác biệt nằm ở sự kết nối giữa con số, lập luận của trình đánh giá và hành vi của agent đằng sau nó.

Thay vì chỉ hỏi "Điểm trung bình có thay đổi không?", chúng tôi có thể hỏi:

Đó là sự khác biệt giữa đánh giá như một bảng điểm và đánh giá như một quy trình kỹ thuật để xây dựng các hệ thống agentic.

Các bảng tiêu chí được hiệu chỉnh sai có thể làm cho các bản cập nhật tốt trông giống như lỗi hồi quy

Phiên bản đầu tiên của đánh giá Deep Research đã làm chậm chúng tôi thay vì tăng tốc như dự định.

Chúng tôi đã thực hiện một thay đổi nhỏ về prompt, chạy lại benchmark và điểm tổng thể giảm xuống. Vì vậy, chúng tôi coi đó là một lỗi hồi quy: hoàn tác, tinh chỉnh, chạy lại. Rồi lại tiếp tục như vậy. Các báo cáo trông vẫn tốt đối với chúng tôi mỗi lần, nhưng con số cứ không đồng ý, và chúng tôi đã tin vào con số hơn là cách đọc của chính mình.