- Đánh giá (evals) là yếu tố then chốt để tự tin triển khai các tác nhân (agents) sử dụng Mô hình Ngôn ngữ Lớn (LLM) vào môi trường sản phẩm, giúp giảm thiểu rủi ro về thương hiệu, tuân thủ và chi phí do sự biến thiên cao của LLM.
- Quá trình xây dựng nền tảng đánh giá hiệu quả phát triển từ các bảng tính đơn giản, đến giao diện người dùng tùy chỉnh và cuối cùng tích hợp khả năng quan sát trong môi trường sản xuất để xác định các chế độ lỗi thực tế và thúc đẩy cải tiến tác nhân liên tục.
- Một chiến lược đánh giá trưởng thành kết nối thử nghiệm ngoại tuyến với giám sát trực tuyến, coi khả năng quan sát và đánh giá là hai trụ cột của cùng một vấn đề, tạo thành một "bánh đà" cho việc tinh chỉnh và đảm bảo chất lượng tác nhân lặp lại.
Why building eval platforms is hard — Phil Hetzel, Braintrust
- Bắt đầu đánh giá sớm: Ngay cả các đánh giá dựa trên bảng tính đơn giản với vòng lặp và ví dụ đầu vào cũng là một bước quan trọng để nhận biết và giải quyết chất lượng tác nhân.
- Vượt ra khỏi bảng tính: Chuyển sang sử dụng giao diện người dùng tùy chỉnh và cơ sở dữ liệu mạnh mẽ để cải thiện tính bền vững của đánh giá, tạo điều kiện hợp tác giữa các bên liên quan kỹ thuật và phi kỹ thuật, cũng như quản lý dữ liệu đánh giá hiệu quả hơn.
- Khuyến khích thử nghiệm: Triển khai tính năng "sân chơi" (playground feature) cho phép người dùng kỹ thuật và phi kỹ thuật điều chỉnh các tham số tác nhân (ví dụ: lời nhắc hệ thống) trong môi trường biệt lập và so sánh điểm số đánh giá giữa các cấu hình khác nhau.
- Kết nối khả năng quan sát và đánh giá: Tích hợp dữ liệu theo dõi từ môi trường sản xuất với các đánh giá để xác định các chế độ lỗi thực tế của tác nhân, từ đó xây dựng các hàm tính điểm phù hợp và chính xác hơn.
- Thiết lập vòng lặp cải tiến tác nhân: Quan sát liên tục hành vi của tác nhân trong môi trường sản xuất, trích xuất các ví dụ lỗi thực tế, đưa chúng trở lại môi trường ngoại tuyến để cải tiến tác nhân bằng các đánh giá, sau đó triển khai lại, tạo thành một vòng lặp lặp lại hiệu quả.
- Mở rộng phạm vi nền tảng: Một nền tảng chất lượng tác nhân toàn diện cần bao gồm cả đánh giá ngoại tuyến, theo dõi (tracing) và ghi nhật ký (logging) trực tuyến để cung cấp tín hiệu đầy đủ về hiệu suất tác nhân và tương tác của người dùng.
- Giải quyết thách thức về dấu vết tác nhân: Dấu vết của tác nhân thường phức tạp, bán cấu trúc hoặc phi cấu trúc, với lượng lớn văn bản, khối lượng và tốc độ cao. Cần các giải pháp chuyên biệt cho việc thu nạp dữ liệu độ trễ thấp và phân tích tổng hợp dữ liệu, thay vì chỉ dựa vào cơ sở dữ liệu truyền thống có thể gặp vấn đề về hiệu suất.
evals— đánh giáagent quality platform— nền tảng chất lượng tác nhânobservability— khả năng quan sátGenerative AI POCs— bằng chứng khái niệm AI tạo sinhproduction environment— môi trường sản phẩmfailure modes— chế độ lỗiscoring functions— hàm tính điểmsystem prompt/system instructions— lời nhắc hệ thống / hướng dẫn hệ thốngtrace data— dữ liệu theo dõiflywheel— bánh đà (vòng lặp cải tiến liên tục)
Giới thiệu và Bối cảnh Cá nhân
Chào mọi người, 11:15 rồi, chúng ta sẽ bắt đầu ngay bây giờ. Trước khi bắt đầu, mọi người hãy cùng nói "Evals!" "Evals!" Tôi đã kể với đồng nghiệp Rose của mình, người đang ở ngoài cửa, rằng tôi từng là giáo sư trợ giảng trong nhiều năm. Năm đầu tiên giảng dạy, tôi cứ nghĩ mình sẽ có một lớp học đầy đủ 130 sinh viên háo hức học hỏi mỗi tuần. Nhưng rồi, theo thời gian, 130 trở thành 60, rồi 30, rồi 10. Vì vậy, tôi luôn tự nhủ rằng bất cứ khi nào tôi thuyết trình, chỉ khoảng bốn hoặc năm người sẽ đến, nhưng tôi sẽ rất hào hứng để giảng dạy cho bốn hoặc năm người đó. Hôm nay là một điều may mắn thực sự vì chúng ta có một căn phòng chật kín người. Mọi người đều hào hứng tìm hiểu về evals, và tôi cũng rất hào hứng để chia sẻ.
Đây là những gì chúng ta sẽ nói về ngày hôm nay: Tôi sẽ giới thiệu một chút về bản thân và công ty tôi đang làm việc, một cái nhìn tổng quan về vấn đề cần giải quyết. Chúng ta sẽ đi sâu vào các giai đoạn khác nhau khi mọi người xây dựng các nền tảng đánh giá (eval platforms). Và sau đó, chúng ta sẽ nói về, ít nhất là theo ý kiến của tôi, nơi mà tôi nghĩ các nền tảng đánh giá sẽ phát triển trong tương lai.
Vâng, đây là tôi. Tên tôi là Phil Hetzel. Tôi lãnh đạo bộ phận Kỹ thuật Giải pháp (Solutions Engineering) tại Brain Trust. Tôi sẽ nói về Brain Trust là gì trong giây lát. Về cơ bản, kỹ thuật giải pháp có nghĩa là tôi và đội của mình là những người đảm bảo rằng khách hàng đang nhận được giá trị tối đa từ nền tảng của chúng tôi và nhanh nhất có thể. Vì vậy, tôi may mắn là thông qua tất cả các khách hàng của mình, tôi thấy được đâu là xu hướng tiên tiến nhất trong cả evals và khả năng quan sát tác nhân (agent observability).
Trước khi đến Brain Trust, tôi đã dành 12 năm làm tư vấn và triển khai hệ thống. Tôi làm việc cho KPMG bốn năm. Tôi làm việc cho một công ty tên là Slalom Consulting trong tám năm, nơi tôi đã lãnh đạo Đơn vị Kinh doanh Databricks toàn cầu. Và tôi nhận thấy rằng khi tôi giúp khách hàng của mình với những triển khai đó, chúng rất tuyệt vời. Họ rất giỏi trong việc tạo ra các bằng chứng khái niệm (POCs) AI tạo sinh (Generative AI) này, nhưng không phải tất cả đều được đưa vào môi trường sản phẩm. Tôi muốn giúp ích trong việc đảm bảo những POCs đó có thể được đưa vào môi trường sản phẩm. Vì vậy, tôi thực sự bắt đầu sử dụng Brain Trust vì tôi biết nó giúp ích trong lĩnh vực này. Tôi bắt đầu sử dụng nó với tư cách là một người dùng. Và tôi thích nền tảng này đến mức tôi đã ứng tuyển vào một công việc và đã ở đây được khoảng một năm. Ngoài công việc, tôi thích chơi cờ vua, nhưng tôi chơi rất tệ. Và tôi thích dành thời gian cho vợ mình, và chú chó dachshund của tôi tên là Pistol Pete. Nó được chụp ảnh ở đây; nó là con vật màu nâu. Nó không phải là người màu đen. Người màu đen là tôi.
Giới thiệu về Brain Trust và Tầm quan trọng của Đánh giá
Có ai đã từng nghe về Brain Trust trước đây chưa? Ai đó? Vài cánh tay. Bao nhiêu người mới nghe về Brain Trust lần đầu tiên trong tuần này? Tuyệt vời. Brain Trust, để nhắc lại, tôi nghĩ chúng tôi là một nền tảng chất lượng tác nhân (agent quality platform). Có rất nhiều yếu tố tạo nên chất lượng. Cách chúng tôi đạt được chất lượng tác nhân là thông qua hai trụ cột chính: evals và khả năng quan sát (observability). Chúng tôi coi đây là những vấn đề thực sự tương tự cần giải quyết. Đó là những gì bạn đang làm với tác nhân của mình trước khi nó được đưa vào môi trường sản phẩm khi bạn đang thử nghiệm để có thể tự tin vào tác nhân của mình. Và khả năng quan sát cũng thực sự tương tự, nhưng bạn đã ở trong môi trường sản phẩm rồi. Tác nhân của bạn đang đối mặt với việc sử dụng thực tế từ những người dùng thực. Và bạn muốn tự tin – tôi nên nói là duy trì sự tự tin – rằng tác nhân của bạn đang hoạt động theo cách bạn đã nghĩ khi bạn xây dựng nó.
Vậy đó là Brain Trust. Tôi đã được yêu cầu cụ thể là không biến đây thành một bài giới thiệu bán hàng (sales pitch). Vì vậy, đó thực sự là slide cuối cùng về Brain Trust mà bạn sẽ thấy hôm nay. Mặc dù, tất nhiên, tôi rất vui khi trả lời các câu hỏi về công ty của chúng tôi trong tuần này. Nhưng chủ yếu, tôi muốn nói một cách khái quát hơn về cách mọi người bắt đầu phát triển và xây dựng các nền tảng này, dựa trên kinh nghiệm phong phú của chúng tôi trong lĩnh vực này.
Tại sao Đánh giá (Evals) lại Quan trọng?
Đó là lý do tại sao evals lại quan trọng. Evals quan trọng vì, nghe có vẻ hiển nhiên, nhưng các Mô hình Ngôn ngữ Lớn (LLM) có tính biến thiên cực kỳ cao. Chúng ta yêu thích các LLM vì chúng có tính biến thiên cao. Có rất nhiều loại vấn đề khác nhau mà các LLM có thể suy luận để giải quyết. Đó là lý do tại sao chúng ta lại bị thu hút bởi chúng như một công nghệ. Các LLM cũng là, tất nhiên, bộ não của tác nhân. Các tác nhân đang trở thành tiêu chuẩn trong cách khách hàng tương tác với các công ty. Mọi người hiện mong đợi một trải nghiệm tác nhân (agent experience). Vì vậy, nếu bạn kết hợp cả hai điều đó lại với nhau, bạn thực sự cần phải tự tin vào cách tác nhân của mình sẽ hoạt động một khi nó ở trong môi trường sản phẩm.
Nếu không làm như vậy, bạn sẽ phải chịu, hoặc có thể phải chịu, một rủi ro lớn từ cả góc độ thương hiệu, góc độ tuân thủ, và thậm chí hơn thế nữa là góc độ chi phí, bảo trì và hệ thống. Vì vậy, chúng ta muốn tránh tất cả những điều đó xảy ra và đảm bảo rằng khách hàng của chúng ta có trải nghiệm tuyệt vời và tác nhân của chúng ta đang hoạt động theo cách chúng ta đã nghĩ rằng chúng sẽ hoạt động.
Các Giai đoạn Xây dựng Nền tảng Đánh giá
Hiện tại, nhiều người đang thực hiện evals, nhưng nó chỉ nằm trên một Google Sheet hoặc một số bảng tính. Không có gì đáng xấu hổ về điều đó, bạn của tôi. Hãy giơ tay cao lên! Điều đó thật tuyệt. Tôi nghĩ điều đó rất tốt. Chỉ cần thực hiện bước đi đó đã là rất quan trọng rồi. Đó là một sự công nhận về không gian vấn đề. Rất nhiều người sẽ đến với chúng tôi và nói, "À, tôi không thực sự hiểu Brain Trust vì tất cả những gì tôi cần biết là cách lặp qua tác nhân của mình với một vài đầu vào khác nhau và có thể hiển thị một số ghi chú và điểm số viết tay về tác nhân đó."
Giai đoạn 1: Bảng tính và Vòng lặp for
Vậy những điều tôi đã đề cập ở đó là ba điều: một cách nào đó để thực thi tác nhân của bạn, một Giao diện người dùng (UI) (đôi khi đơn giản như một bảng tính) để hiển thị các đầu ra và điểm số đó, và sau đó là một cách để thu thập các ví dụ đầu vào (input examples). Ý tôi với ví dụ đầu vào là thứ có thể khởi tạo một lần chạy tác nhân (agent run), thứ có thể kích hoạt một tác nhân, bất kỳ thông tin nào cần thiết cho việc đó.
Đây sẽ là một bài thuyết trình rất ngắn nếu evals chỉ có vậy. Tôi sẽ cảm ơn thời gian của bạn và rời khỏi phòng, nhưng đó không phải là lý do bạn ở đây. Có một phần khác của tảng băng chìm. Nó phức tạp hơn nhiều. Có rất nhiều thứ bạn cuối cùng phải xây dựng khi bạn thực sự nghiêm túc về evals. Chúng ta sẽ không nói về mọi thứ trong số này hôm nay, nhưng chúng ta sẽ đề cập đến nhiều trong số đó. Và tất nhiên, nếu có bất cứ điều gì tôi không đề cập mà bạn quan tâm, tôi sẽ dành thời gian để hỏi đáp. Tôi cũng thấy rất nhiều điện thoại đang giơ lên, vì vậy tôi sẽ tạm dừng để chụp ảnh tảng băng chìm.
Một vài điều trong khi điều đó đang xảy ra: Tại sao đây là một vấn đề phức tạp? Chúng ta đã nói một chút về việc công nghệ nền tảng khá phức tạp như thế nào. Các LLM không phải là một công cụ hời hợt, nhưng việc xây dựng các tác nhân này cũng là một vấn đề đa vai trò (multi-persona problem). Đó không chỉ là điều mà các kỹ sư thực hiện một cách riêng lẻ. Đó là điều mà các kỹ sư – cho dù họ là kỹ sư sản phẩm (product engineers) hay kỹ sư AI (AI engineers), hoặc cả kỹ sư hệ thống (systems engineers) để làm cho mọi thứ chạy – các chuyên gia về lĩnh vực (SMEs) có kiến thức chuyên môn về lĩnh vực (domain knowledge), tất cả những người này đều cần phải tham gia. Và cuối cùng, evals tự chúng trở thành một vấn đề hệ thống (systems problem). Đó sẽ là điều cuối cùng chúng ta đề cập hôm nay.
Vậy đâu là các giai đoạn khác nhau của việc xây dựng một nền tảng đánh giá (eval platform)? Người bạn của tôi ở đó đã tự hào giơ tay về việc bắt đầu với một bảng tính. Đây là một nơi tuyệt vời để bắt đầu. Và điều quan trọng nhất là bạn chỉ cần bắt đầu. Vì vậy, bạn có một bảng tính và bạn có một vòng lặp for. Bạn có một loạt các ví dụ đầu vào mà bạn có thể lặp qua và bạn có một cách để thực thi tác nhân của mình. Vì vậy, bạn có thể thấy, mỗi khi bạn điều chỉnh tác nhân của mình, các đầu ra khác nhau như thế nào theo thời gian.
Mặc dù đây là một nơi tuyệt vời để bắt đầu, bởi vì ở đây không có rào cản gia nhập (barrier to entry) nào cả – mọi người đều có cách để truy cập một loại công nghệ bảng tính nào đó. Nhưng lợi nhuận có thể giảm dần vì một vài lý do. Điều này giống như, tôi sẽ gọi đây là ghi tài liệu, chứ không thực sự là thử nghiệm. Vì vậy, trong khi bạn có bảng tính này với một loạt các ví dụ đầu vào, có thể bạn theo dõi mỗi khi bạn điều chỉnh tác nhân của mình, các đầu ra khác nhau đã được phát ra. Tất nhiên, điều đó có thể trở nên cồng kềnh để quản lý theo thời gian. Rất khó để có thể so sánh trực tiếp các thử nghiệm qua thời gian. Bạn có thể sẽ không thực hiện nhiều phân tích (analytics) trên các thử nghiệm đó, và phân tích mà bạn đang thực hiện, chúng có thể đến từ một loại điểm số do con người chấm (human score) nào đó, điều này rất có giá trị, nhưng khó mở rộng trong thực tế.
Nếu chúng ta muốn đảm bảo rằng chúng ta đang đưa rất nhiều người vào cuộc, không chỉ những người có chuyên môn kỹ thuật mà cả những người không có chuyên môn kỹ thuật. Họ có thể thêm rất nhiều giá trị cho tác nhân của bạn vì kiến thức chuyên môn về lĩnh vực (domain expertise) độc đáo và sự gần gũi với người dùng. Ý tôi là, họ có thể sẽ không sử dụng bảng tính. Và nó chậm. Mỗi khi bạn đánh giá (eval), bạn có thể phải trải qua một quá trình hơi cồng kềnh để tạo lại hoặc thêm vào bảng tính.
Giai đoạn 2: Giao diện người dùng Tùy chỉnh và Cơ sở dữ liệu
Có lẽ một trong những cuộc trò chuyện thú vị nhất mà tôi có trong công việc của mình là khi một kỹ sư sản phẩm rất tự hào tham gia cuộc gọi với tôi, họ ưỡn ngực và nhếch mép với tôi và nói, "Tại sao tôi không thể tự mình làm tốt?" Tôi nghĩ nếu bạn mới bắt đầu hành trình của mình, đó là một bước đi rất tốt. Vì vậy, bây giờ thay vì ở trong "thế giới bảng tính", bạn đang tạo ra một cái gì đó tùy chỉnh riêng (bespoke) hơn một chút để đưa những người khác vào cuộc.
Vì vậy, bây giờ bạn có thể có một vòng lặp for. Bạn có một UI đẹp hơn bây giờ, vì vậy nó dễ tiếp cận hơn. Và hy vọng bạn đã chuyển sang một cơ sở dữ liệu không phải Excel hoặc Google Sheets. Bạn có thể sử dụng một cơ sở dữ liệu mới như Neon hoặc tương tự. Vì vậy, bây giờ bạn có một câu chuyện tốt hơn về khả năng lưu trữ lâu dài của các đánh giá (persistence of evals). Và vì điều này, bạn đưa nhiều người hơn vào cuộc. Bạn đang tạo ra các UI được tùy chỉnh riêng hơn một chút cho những người dùng cụ thể của bạn. Vấn đề ở đây là bạn vẫn chưa thực sự lặp lại (iterating). Bạn vẫn đang thực hiện công việc giống như báo cáo, chỉ là ghi tài liệu (documentation), hơn là khuyến khích nhiều lặp lại. Vì vậy, đây giống như một công cụ báo cáo (reporting tool) nhiều hơn.
Có bao nhiêu người đã tự xây dựng UI của riêng mình? Vâng, hợp lý.
Giai đoạn 3: Khuyến khích Thử nghiệm
Bước tiếp theo ở đây: bạn muốn khuyến khích nhiều thử nghiệm (experimentation), không chỉ với người dùng kỹ thuật mà cả người dùng không chuyên về kỹ thuật. Vì vậy, việc hiển thị hình ảnh này phù hợp hơn với việc cho phép thử nghiệm cho người dùng không chuyên về kỹ thuật. Nhưng tất nhiên, khi bạn đang xây dựng các nền tảng này, bạn cũng muốn cho phép trải nghiệm SDK-driven nhiều hơn. Điều đó đơn giản là không tạo ra một hình ảnh đẹp trong một bài thuyết trình.
Vì vậy, thử nghiệm đối với tôi có nghĩa là bạn có thể cấp cho người dùng quyền truy cập vào một tác nhân, một cấu hình của tác nhân trong một môi trường biệt lập (sandbox). Và bạn cho phép họ điều chỉnh các tham số (parameters) nhất định trong tác nhân đó. Trong ví dụ của tôi ở đây, tôi đang cho phép một người dùng trong UI thay đổi hướng dẫn hệ thống (system instructions) cho một tác nhân đang chạy bên ngoài nền tảng đánh giá của tôi và cho phép họ so sánh hai cấu hình khác nhau của lời nhắc hệ thống (system prompt) đó. Và tôi đang thực hiện evals trên hai lần chạy tác nhân khác nhau đó để tôi có thể hiển thị điểm số (bubble up scores). Bạn có thể thấy điều đó trong hình ảnh bây giờ. Tôi có thể hiển thị các điểm số khác nhau để hiểu cả về mặt kỹ thuật và chức năng tác nhân của tôi đang hoạt động như thế nào.
Vì vậy, bạn sẽ nghe về rất nhiều nền tảng có tính năng "sân chơi" (playground feature). Bạn sẽ muốn có một loại tính năng "sân chơi" nào đó cho cả người dùng kỹ thuật và không chuyên về kỹ thuật.
Giai đoạn 4: Kết nối Khả năng Quan sát và Đánh giá
Đây là nơi mà "miệng nói tay làm" (rubber meets the road) bởi vì cách tốt nhất để thực hiện evals là thực sự nghĩ về các chế độ lỗi (failure modes) mà tác nhân của bạn có thể mắc phải và xây dựng các hàm tính điểm (scoring functions) xung quanh những chế độ lỗi đó. Cách tốt nhất để tìm ra những chế độ lỗi đó ngay từ đầu là có quyền truy cập vào dữ liệu theo dõi trong môi trường sản phẩm (production trace data), tức là tác nhân của bạn đang đối mặt với người dùng thực và việc sử dụng thực.
Vì vậy, bước tiếp theo ở đây là một bước rất quan trọng. Chúng tôi muốn đảm bảo rằng chúng tôi có thể kết nối cái mà chúng tôi, ít nhất là nội bộ, gọi là bánh đà (flywheel). Khả năng quan sát và evals đối với chúng tôi thực sự là cùng một vấn đề từ góc độ hệ thống (system's perspective).
Chuyển đổi từ Nền tảng e-val sang Observability toàn diện
Một câu chuyện thú vị là ba năm trước, khi chúng tôi bắt đầu, chúng tôi chỉ là một nền tảng e-val. Sau đó, chúng tôi nhận thấy một trong những khách hàng của mình đang chạy e-val lớn này mỗi giờ, mỗi ngày. Chúng tôi liên hệ với người này, và họ nói, "À vâng, tôi chỉ đơn giản là đưa tất cả lưu lượng truy cập sản xuất của mình vào cơ sở dữ liệu này và chạy một e-val trên đó." Vì vậy, chúng tôi nghĩ, "Được thôi, có lẽ chúng ta nên tạo ra khả năng trace và quan sát lưu lượng truy cập thực tế và đáp ứng trường hợp sử dụng đó mà không cần phải nhồi nhét nó vào các e-val ngoại tuyến."
Vòng lặp cải tiến Tác nhân
Vì vậy, điều này thực sự quan trọng để đảm bảo rằng chúng ta có thể quan sát mọi thứ trong môi trường sản xuất và hiểu hành vi thực tế của các tác nhân của mình. Chúng ta cũng cần hiểu mức độ cải thiện thực sự mà những thay đổi chúng ta đang thực hiện đối với các tác nhân mang lại. Chúng tôi phân tích dữ liệu đó, đưa những ví dụ thực tế đó trở lại môi trường ngoại tuyến, và sau đó cải thiện chúng bằng cách sử dụng các e-val ngoại tuyến. Đây là một vòng lặp, không chỉ là một quy trình. Bạn sẽ thực hiện vòng lặp này xuyên suốt vòng đời của tác nhân mà bạn đưa vào sản xuất. Bạn nên lặp lại vòng lặp này càng nhiều lần càng tốt. Đó là cách bạn cải thiện.
Mở rộng Phạm vi: Từ e-val đến Tracing và Logging
Kết quả là, bạn đã thay đổi phạm vi của mình một chút; thực tế, bạn đã mở rộng phạm vi của mình rất nhiều. Bạn giờ đây là một nền tảng tracing và một nền tảng logging, ngoài việc là một nền tảng e-val ngoại tuyến. Lợi ích của điều này là bạn bắt đầu nhận được tín hiệu cao hơn nhiều từ cách người dùng tương tác với các tác nhân của bạn, và bạn có thể sử dụng những tương tác thực tế đó. Vì vậy, bạn gần như có thể coi e-val như việc chạy lại sản xuất trong một môi trường an toàn. Bạn đang đạt đến điểm đó với ví dụ này. Bạn cũng có thể thực hiện e-val trực tuyến bằng cách hướng các hàm chấm điểm đến lưu lượng khả năng quan sát của bạn và thực hiện các việc như cảnh báo – tất cả những điều bạn có thể xây dựng khi đạt đến giai đoạn trưởng thành này để chạy e-val.
Thách thức quản lý và phát triển Nền tảng
Mặt trái ở đây là: nếu bạn xây dựng nó, bạn phải quản lý nó. Vì vậy, chỉ vì bạn đã vibe-coded một nền tảng, thì sao? Bạn có thể được thăng chức vì nó, nhưng cũng sẽ là công việc của bạn là quản lý và tiếp tục phát triển nền tảng e-val của mình theo tốc độ của ngành, đây có thể là một thách thức thú vị mà công ty chúng tôi đang đặt cược và chúng tôi rất vui được giải quyết vấn đề đó.
Những thách thức đặc thù của Trace Tác nhân
Tuy nhiên, thách thức quan trọng hơn là các trace của tác nhân (nếu bạn nhìn trên màn hình, chúng thực sự rất phức tạp). Chúng không giống như các trace ứng dụng thông thường. Chúng thường bán cấu trúc, và nhiều khi là phi cấu trúc. Có một lượng lớn văn bản vốn có trong các vấn đề của LLM mà chúng ta đang giải quyết. Chúng rất lớn ngoài việc phức tạp. Nếu bạn cố gắng nhồi nhét một trace một gigabyte vào một hàng Postgres, điều đó có thể dẫn đến rất nhiều vấn đề về hiệu suất, và chúng rất nhiều. Nó có vận tốc cao vì có rất nhiều hoạt động sử dụng đang diễn ra trong sản xuất, hy vọng là với tác nhân mà bạn đã triển khai.
Giải pháp truy vấn và lưu trữ dữ liệu truyền thống
Đây là cách chúng tôi từng giải quyết vấn đề này. Ví dụ, nếu bạn đang ở giai đoạn trưởng thành này và có các trace đến, bạn sẽ cần tính đến hai mô hình truy vấn. Thứ nhất, nếu bạn đang thực hiện khả năng quan sát, bạn cần một cách để mọi người có thể xem ngay lập tức các trace của họ. Điều này rất quan trọng. Bạn sẽ cần một cách có độ trễ thấp để thu nạp dữ liệu. Thứ hai, bạn cũng cần một lớp bền vững cho mô hình truy vấn là muốn có thể phân tích và tổng hợp dữ liệu này. Chúng tôi từng sử dụng một kho dữ liệu mã nguồn mở cho việc này. Chúng tôi kết nối hai nguồn này lại với nhau thông qua một ngôn ngữ dành riêng cho miền mà chúng tôi tạo ra, gọi là BTQL, không ai thích (kể cả chúng tôi, chúng tôi ghét nó). Sau đó, chúng tôi thực hiện mức độ tổng hợp thứ ba bằng cách sử dụng DuckDB trong trình duyệt. Điều này đã hiệu quả với chúng tôi một thời gian. Sau đó, nó không còn hiệu quả khi tôi sử dụng một trong các ví dụ khách hàng của chúng tôi. Một khách hàng như Notion, chẳng hạn, gửi cho chúng tôi rất nhiều dữ liệu phi cấu trúc. Họ muốn có thể thực hiện những thứ như tìm kiếm toàn văn trên một trace. Không có công nghệ nào thực sự được trang bị để thực hiện phân tích kiểu văn bản, đây là một thách thức trong miền LLM vì có quá nhiều văn bản.
E-val và Khả năng quan sát là một Vấn đề hệ thống
Điều đó dẫn chúng tôi đến kết luận này: việc đo lường chất lượng tác nhân, thực hiện e-val, và thực hiện khả năng quan sát thực chất là một vấn đề hệ thống. Nó không chỉ là một vấn đề UI/UX. Chúng tôi nhận thấy rằng việc vibe-code UI của e-val khá dễ dàng, nhưng việc tạo ra lớp dữ liệu để chạy một nền tảng e-val và khả năng quan sát thành công thì khó khăn hơn rất nhiều. Không chỉ từ góc độ quy mô, mặc dù điều đó quan trọng, mà chủ yếu từ góc độ chức năng của việc cho phép mọi người làm những điều họ mong đợi, như thực hiện tìm kiếm toàn văn trên hàng triệu trace trong nền tảng mà họ lựa chọn.
Đặc điểm dữ liệu Trace Tác nhân và Mô hình đọc
Tôi đã nói về điều này một chút. Lý do tại sao đây là một vấn đề mới lạ cần giải quyết là vì nhiều khía cạnh (mà tôi sẽ không trình bày chi tiết trên slide này). Dữ liệu đến rất nhanh, và chúng rất lớn. Theo truyền thống, các span trong một trace chỉ là một phần của trace, thường chỉ vài kilobyte. Ở đây, chúng tôi đã thấy các span có kích thước 10-20 megabyte, chứa rất nhiều ngữ cảnh, và có tính phi cấu trúc cao. Ngoài ra, còn có rất nhiều mô hình đọc khác nhau. Bạn có thể đang thực hiện các mô hình đọc tổng hợp, nhưng bạn cũng muốn các mô hình đọc có độ trễ rất thấp. Vì vậy, mặc dù không có vấn đề nào trong số này là độc đáo riêng lẻ, nhưng khi kết hợp lại, chúng tạo thành một vấn đề rất độc đáo từ góc độ hệ thống.
Xây dựng Nền tảng dữ liệu phù hợp cho Trace
Vì vậy, điều chúng tôi đã làm, và điều mà tất cả các bạn sẽ phải nỗ lực thực hiện nếu tự xây dựng nó, là bạn thực sự phải suy nghĩ về việc tạo ra một nền tảng dữ liệu phù hợp cho các trace, để bạn có thể thực hiện một số yêu cầu chức năng cao hơn sẽ phát sinh sau này. Ví dụ tôi đưa ra ở đây là: giả sử bạn muốn cho một tác nhân mã hóa tự do hoạt động trên nền tảng e-val của mình để bạn có thể tự phục hồi tốt hơn bằng cách lấy dữ liệu từ nền tảng e-val, sử dụng một tác nhân mã hóa để đưa dữ liệu đó vào ngữ cảnh và thay đổi tác nhân của bạn trong một phiên tác nhân mã hóa. Đó là điều sẽ rất khó thực hiện nếu bạn chỉ có thể chạy rất nhiều SQL thuần túy trên phần phụ trợ dữ liệu của nền tảng e-val của bạn.
Trường hợp sử dụng Headless và Tác nhân mã hóa
Chúng tôi thực sự đã nhận thấy rất nhiều trường hợp sử dụng kiểu headless xuất hiện, nơi mọi người không quan tâm đến UI chút nào. Điều duy nhất họ quan tâm là, "Làm thế nào tôi có thể thực hiện e-val theo cách mà tôi có thể sử dụng một Codex hoặc một Claude Code để giúp tăng chất lượng của tác nhân của mình?"
Khám phá Unknown Unknowns và các Cân nhắc trong tương lai
Vấn đề cuối cùng tôi sẽ nói ở đây là vấn đề "vậy thì sao". Chúng ta sẽ bỏ qua điều này bây giờ để tiết kiệm thời gian. Đây là cách Brain Trust thực hiện điều đó. Chúng tôi có một bài blog về chủ đề này, vừa được phát hành, nếu bạn quan tâm. Điều tiếp theo bạn có thể mong đợi xây dựng vào nền tảng e-val của mình là khả năng cho người dùng biết những điều chưa biết nhưng không biết rằng mình chưa biết (unknown unknowns) về tác nhân của bạn. Tức là, "Đừng bắt tôi xem xét một đống trace; chỉ cần cho tôi biết mọi người đang sử dụng tác nhân của chúng ta như thế nào." Vì vậy, bạn muốn có thể khám phá những điều chưa biết nhưng không biết rằng mình chưa biết đó thông qua các kỹ thuật mô hình hóa chủ đề để bạn biết nên dành thời gian kỹ thuật của mình vào đâu. Bạn muốn đảm bảo rằng bạn đang xây dựng nền tảng của mình không chỉ cho con người mà còn cho các tác nhân, bởi vì đó là một trong những phương tiện chính mà con người đang tạo ra công nghệ hiện nay. Chúng ta thậm chí chưa nói về các yêu cầu phi chức năng đi kèm khi xây dựng các nền tảng này, như kiểm soát truy cập dựa trên vai trò và che giấu dữ liệu. Đó cũng là một điều cực kỳ quan trọng xuất hiện khi bạn muốn vận hành ở quy mô lớn. Và cuối cùng, một cân nhắc là thêm tracing tự động thông qua một loại proxy AI hoặc gateway nào đó để mọi người thậm chí không có lựa chọn nào khác ngoài việc trace các LLM của họ. Chúng ta có thể quản lý rất tập trung bằng cách thêm tracing tự động vào nền tảng e-val của bạn.
Xử lý Đầu vào/Đầu ra Đa phương thức
Tôi rất cảm kích thời gian của quý vị. Tôi còn khoảng một phút hai mươi giây cho phần hỏi đáp. Tôi có thể trả lời khoảng hai câu hỏi nếu có ai có thắc mắc. Vâng. Vậy Brain Trust xử lý các đầu ra và đầu vào đa phương thức (multimodal outputs and inputs) cũng như trace như thế nào? Vâng, về mặt kỹ thuật, chúng tôi chỉ đơn giản đặt chúng vào một lưu trữ đối tượng (object storage), tham chiếu chúng, và sau đó hiển thị trực tiếp chúng vào trace. Vì vậy, nếu bạn có một tệp âm thanh hoặc một tệp video, bạn có thể phát nó trong trace khi ai đó đang xem lại trace đó. Chúng tôi không muốn mọi người phải thoát khỏi nền tảng vì điều đó. Có một câu hỏi là, " Quản lý lời nhắc (prompt management) có nằm trong Brain Trust không?" Có thể có, hoặc không nhất thiết phải có. Vâng. Được rồi, hoàn hảo. Cảm ơn rất nhiều vì sự chú ý của quý vị hôm nay.
TL;DR
- Đánh giá (evals) là yếu tố then chốt để tự tin triển khai các tác nhân (agents) sử dụng Mô hình Ngôn ngữ Lớn (LLM) vào môi trường sản phẩm, giúp giảm thiểu rủi ro về thương hiệu, tuân thủ và chi phí do sự biến thiên cao của LLM.
- Quá trình xây dựng nền tảng đánh giá hiệu quả phát triển từ các bảng tính đơn giản, đến giao diện người dùng tùy chỉnh và cuối cùng tích hợp khả năng quan sát trong môi trường sản xuất để xác định các chế độ lỗi thực tế và thúc đẩy cải tiến tác nhân liên tục.
- Một chiến lược đánh giá trưởng thành kết nối thử nghiệm ngoại tuyến với giám sát trực tuyến, coi khả năng quan sát và đánh giá là hai trụ cột của cùng một vấn đề, tạo thành một "bánh đà" cho việc tinh chỉnh và đảm bảo chất lượng tác nhân lặp lại.
Điểm chính
- Bắt đầu đánh giá sớm: Ngay cả các đánh giá dựa trên bảng tính đơn giản với vòng lặp và ví dụ đầu vào cũng là một bước quan trọng để nhận biết và giải quyết chất lượng tác nhân.
- Vượt ra khỏi bảng tính: Chuyển sang sử dụng giao diện người dùng tùy chỉnh và cơ sở dữ liệu mạnh mẽ để cải thiện tính bền vững của đánh giá, tạo điều kiện hợp tác giữa các bên liên quan kỹ thuật và phi kỹ thuật, cũng như quản lý dữ liệu đánh giá hiệu quả hơn.
- Khuyến khích thử nghiệm: Triển khai tính năng "sân chơi" (playground feature) cho phép người dùng kỹ thuật và phi kỹ thuật điều chỉnh các tham số tác nhân (ví dụ: lời nhắc hệ thống) trong môi trường biệt lập và so sánh điểm số đánh giá giữa các cấu hình khác nhau.
- Kết nối khả năng quan sát và đánh giá: Tích hợp dữ liệu theo dõi từ môi trường sản xuất với các đánh giá để xác định các chế độ lỗi thực tế của tác nhân, từ đó xây dựng các hàm tính điểm phù hợp và chính xác hơn.
- Thiết lập vòng lặp cải tiến tác nhân: Quan sát liên tục hành vi của tác nhân trong môi trường sản xuất, trích xuất các ví dụ lỗi thực tế, đưa chúng trở lại môi trường ngoại tuyến để cải tiến tác nhân bằng các đánh giá, sau đó triển khai lại, tạo thành một vòng lặp lặp lại hiệu quả.
- Mở rộng phạm vi nền tảng: Một nền tảng chất lượng tác nhân toàn diện cần bao gồm cả đánh giá ngoại tuyến, theo dõi (tracing) và ghi nhật ký (logging) trực tuyến để cung cấp tín hiệu đầy đủ về hiệu suất tác nhân và tương tác của người dùng.
- Giải quyết thách thức về dấu vết tác nhân: Dấu vết của tác nhân thường phức tạp, bán cấu trúc hoặc phi cấu trúc, với lượng lớn văn bản, khối lượng và tốc độ cao. Cần các giải pháp chuyên biệt cho việc thu nạp dữ liệu độ trễ thấp và phân tích tổng hợp dữ liệu, thay vì chỉ dựa vào cơ sở dữ liệu truyền thống có thể gặp vấn đề về hiệu suất.
Từ vựng
evals— đánh giáagent quality platform— nền tảng chất lượng tác nhânobservability— khả năng quan sátGenerative AI POCs— bằng chứng khái niệm AI tạo sinhproduction environment— môi trường sản phẩmfailure modes— chế độ lỗiscoring functions— hàm tính điểmsystem prompt/system instructions— lời nhắc hệ thống / hướng dẫn hệ thốngtrace data— dữ liệu theo dõiflywheel— bánh đà (vòng lặp cải tiến liên tục)
Nội dung chi tiết
Giới thiệu và Bối cảnh Cá nhân
Chào mọi người, 11:15 rồi, chúng ta sẽ bắt đầu ngay bây giờ. Trước khi bắt đầu, mọi người hãy cùng nói "Evals!" "Evals!" Tôi đã kể với đồng nghiệp Rose của mình, người đang ở ngoài cửa, rằng tôi từng là giáo sư trợ giảng trong nhiều năm. Năm đầu tiên giảng dạy, tôi cứ nghĩ mình sẽ có một lớp học đầy đủ 130 sinh viên háo hức học hỏi mỗi tuần. Nhưng rồi, theo thời gian, 130 trở thành 60, rồi 30, rồi 10. Vì vậy, tôi luôn tự nhủ rằng bất cứ khi nào tôi thuyết trình, chỉ khoảng bốn hoặc năm người sẽ đến, nhưng tôi sẽ rất hào hứng để giảng dạy cho bốn hoặc năm người đó. Hôm nay là một điều may mắn thực sự vì chúng ta có một căn phòng chật kín người. Mọi người đều hào hứng tìm hiểu về evals, và tôi cũng rất hào hứng để chia sẻ.
Đây là những gì chúng ta sẽ nói về ngày hôm nay: Tôi sẽ giới thiệu một chút về bản thân và công ty tôi đang làm việc, một cái nhìn tổng quan về vấn đề cần giải quyết. Chúng ta sẽ đi sâu vào các giai đoạn khác nhau khi mọi người xây dựng các nền tảng đánh giá (eval platforms). Và sau đó, chúng ta sẽ nói về, ít nhất là theo ý kiến của tôi, nơi mà tôi nghĩ các nền tảng đánh giá sẽ phát triển trong tương lai.
Vâng, đây là tôi. Tên tôi là Phil Hetzel. Tôi lãnh đạo bộ phận Kỹ thuật Giải pháp (Solutions Engineering) tại Brain Trust. Tôi sẽ nói về Brain Trust là gì trong giây lát. Về cơ bản, kỹ thuật giải pháp có nghĩa là tôi và đội của mình là những người đảm bảo rằng khách hàng đang nhận được giá trị tối đa từ nền tảng của chúng tôi và nhanh nhất có thể. Vì vậy, tôi may mắn là thông qua tất cả các khách hàng của mình, tôi thấy được đâu là xu hướng tiên tiến nhất trong cả evals và khả năng quan sát tác nhân (agent observability).
Trước khi đến Brain Trust, tôi đã dành 12 năm làm tư vấn và triển khai hệ thống. Tôi làm việc cho KPMG bốn năm. Tôi làm việc cho một công ty tên là Slalom Consulting trong tám năm, nơi tôi đã lãnh đạo Đơn vị Kinh doanh Databricks toàn cầu. Và tôi nhận thấy rằng khi tôi giúp khách hàng của mình với những triển khai đó, chúng rất tuyệt vời. Họ rất giỏi trong việc tạo ra các bằng chứng khái niệm (POCs) AI tạo sinh (Generative AI) này, nhưng không phải tất cả đều được đưa vào môi trường sản phẩm. Tôi muốn giúp ích trong việc đảm bảo những POCs đó có thể được đưa vào môi trường sản phẩm. Vì vậy, tôi thực sự bắt đầu sử dụng Brain Trust vì tôi biết nó giúp ích trong lĩnh vực này. Tôi bắt đầu sử dụng nó với tư cách là một người dùng. Và tôi thích nền tảng này đến mức tôi đã ứng tuyển vào một công việc và đã ở đây được khoảng một năm. Ngoài công việc, tôi thích chơi cờ vua, nhưng tôi chơi rất tệ. Và tôi thích dành thời gian cho vợ mình, và chú chó dachshund của tôi tên là Pistol Pete. Nó được chụp ảnh ở đây; nó là con vật màu nâu. Nó không phải là người màu đen. Người màu đen là tôi.
Giới thiệu về Brain Trust và Tầm quan trọng của Đánh giá
Có ai đã từng nghe về Brain Trust trước đây chưa? Ai đó? Vài cánh tay. Bao nhiêu người mới nghe về Brain Trust lần đầu tiên trong tuần này? Tuyệt vời. Brain Trust, để nhắc lại, tôi nghĩ chúng tôi là một nền tảng chất lượng tác nhân (agent quality platform). Có rất nhiều yếu tố tạo nên chất lượng. Cách chúng tôi đạt được chất lượng tác nhân là thông qua hai trụ cột chính: evals và khả năng quan sát (observability). Chúng tôi coi đây là những vấn đề thực sự tương tự cần giải quyết. Đó là những gì bạn đang làm với tác nhân của mình trước khi nó được đưa vào môi trường sản phẩm khi bạn đang thử nghiệm để có thể tự tin vào tác nhân của mình. Và khả năng quan sát cũng thực sự tương tự, nhưng bạn đã ở trong môi trường sản phẩm rồi. Tác nhân của bạn đang đối mặt với việc sử dụng thực tế từ những người dùng thực. Và bạn muốn tự tin – tôi nên nói là duy trì sự tự tin – rằng tác nhân của bạn đang hoạt động theo cách bạn đã nghĩ khi bạn xây dựng nó.
Vậy đó là Brain Trust. Tôi đã được yêu cầu cụ thể là không biến đây thành một bài giới thiệu bán hàng (sales pitch). Vì vậy, đó thực sự là slide cuối cùng về Brain Trust mà bạn sẽ thấy hôm nay. Mặc dù, tất nhiên, tôi rất vui khi trả lời các câu hỏi về công ty của chúng tôi trong tuần này. Nhưng chủ yếu, tôi muốn nói một cách khái quát hơn về cách mọi người bắt đầu phát triển và xây dựng các nền tảng này, dựa trên kinh nghiệm phong phú của chúng tôi trong lĩnh vực này.
Tại sao Đánh giá (Evals) lại Quan trọng?
Đó là lý do tại sao evals lại quan trọng. Evals quan trọng vì, nghe có vẻ hiển nhiên, nhưng các Mô hình Ngôn ngữ Lớn (LLM) có tính biến thiên cực kỳ cao. Chúng ta yêu thích các LLM vì chúng có tính biến thiên cao. Có rất nhiều loại vấn đề khác nhau mà các LLM có thể suy luận để giải quyết. Đó là lý do tại sao chúng ta lại bị thu hút bởi chúng như một công nghệ. Các LLM cũng là, tất nhiên, bộ não của tác nhân. Các tác nhân đang trở thành tiêu chuẩn trong cách khách hàng tương tác với các công ty. Mọi người hiện mong đợi một trải nghiệm tác nhân (agent experience). Vì vậy, nếu bạn kết hợp cả hai điều đó lại với nhau, bạn thực sự cần phải tự tin vào cách tác nhân của mình sẽ hoạt động một khi nó ở trong môi trường sản phẩm.
Nếu không làm như vậy, bạn sẽ phải chịu, hoặc có thể phải chịu, một rủi ro lớn từ cả góc độ thương hiệu, góc độ tuân thủ, và thậm chí hơn thế nữa là góc độ chi phí, bảo trì và hệ thống. Vì vậy, chúng ta muốn tránh tất cả những điều đó xảy ra và đảm bảo rằng khách hàng của chúng ta có trải nghiệm tuyệt vời và tác nhân của chúng ta đang hoạt động theo cách chúng ta đã nghĩ rằng chúng sẽ hoạt động.
Các Giai đoạn Xây dựng Nền tảng Đánh giá
Hiện tại, nhiều người đang thực hiện evals, nhưng nó chỉ nằm trên một Google Sheet hoặc một số bảng tính. Không có gì đáng xấu hổ về điều đó, bạn của tôi. Hãy giơ tay cao lên! Điều đó thật tuyệt. Tôi nghĩ điều đó rất tốt. Chỉ cần thực hiện bước đi đó đã là rất quan trọng rồi. Đó là một sự công nhận về không gian vấn đề. Rất nhiều người sẽ đến với chúng tôi và nói, "À, tôi không thực sự hiểu Brain Trust vì tất cả những gì tôi cần biết là cách lặp qua tác nhân của mình với một vài đầu vào khác nhau và có thể hiển thị một số ghi chú và điểm số viết tay về tác nhân đó."
Giai đoạn 1: Bảng tính và Vòng lặp for
Vậy những điều tôi đã đề cập ở đó là ba điều: một cách nào đó để thực thi tác nhân của bạn, một Giao diện người dùng (UI) (đôi khi đơn giản như một bảng tính) để hiển thị các đầu ra và điểm số đó, và sau đó là một cách để thu thập các ví dụ đầu vào (input examples). Ý tôi với ví dụ đầu vào là thứ có thể khởi tạo một lần chạy tác nhân (agent run), thứ có thể kích hoạt một tác nhân, bất kỳ thông tin nào cần thiết cho việc đó.
Đây sẽ là một bài thuyết trình rất ngắn nếu evals chỉ có vậy. Tôi sẽ cảm ơn thời gian của bạn và rời khỏi phòng, nhưng đó không phải là lý do bạn ở đây. Có một phần khác của tảng băng chìm. Nó phức tạp hơn nhiều. Có rất nhiều thứ bạn cuối cùng phải xây dựng khi bạn thực sự nghiêm túc về evals. Chúng ta sẽ không nói về mọi thứ trong số này hôm nay, nhưng chúng ta sẽ đề cập đến nhiều trong số đó. Và tất nhiên, nếu có bất cứ điều gì tôi không đề cập mà bạn quan tâm, tôi sẽ dành thời gian để hỏi đáp. Tôi cũng thấy rất nhiều điện thoại đang giơ lên, vì vậy tôi sẽ tạm dừng để chụp ảnh tảng băng chìm.
Một vài điều trong khi điều đó đang xảy ra: Tại sao đây là một vấn đề phức tạp? Chúng ta đã nói một chút về việc công nghệ nền tảng khá phức tạp như thế nào. Các LLM không phải là một công cụ hời hợt, nhưng việc xây dựng các tác nhân này cũng là một vấn đề đa vai trò (multi-persona problem). Đó không chỉ là điều mà các kỹ sư thực hiện một cách riêng lẻ. Đó là điều mà các kỹ sư – cho dù họ là kỹ sư sản phẩm (product engineers) hay kỹ sư AI (AI engineers), hoặc cả kỹ sư hệ thống (systems engineers) để làm cho mọi thứ chạy – các chuyên gia về lĩnh vực (SMEs) có kiến thức chuyên môn về lĩnh vực (domain knowledge), tất cả những người này đều cần phải tham gia. Và cuối cùng, evals tự chúng trở thành một vấn đề hệ thống (systems problem). Đó sẽ là điều cuối cùng chúng ta đề cập hôm nay.
Vậy đâu là các giai đoạn khác nhau của việc xây dựng một nền tảng đánh giá (eval platform)? Người bạn của tôi ở đó đã tự hào giơ tay về việc bắt đầu với một bảng tính. Đây là một nơi tuyệt vời để bắt đầu. Và điều quan trọng nhất là bạn chỉ cần bắt đầu. Vì vậy, bạn có một bảng tính và bạn có một vòng lặp for. Bạn có một loạt các ví dụ đầu vào mà bạn có thể lặp qua và bạn có một cách để thực thi tác nhân của mình. Vì vậy, bạn có thể thấy, mỗi khi bạn điều chỉnh tác nhân của mình, các đầu ra khác nhau như thế nào theo thời gian.
Mặc dù đây là một nơi tuyệt vời để bắt đầu, bởi vì ở đây không có rào cản gia nhập (barrier to entry) nào cả – mọi người đều có cách để truy cập một loại công nghệ bảng tính nào đó. Nhưng lợi nhuận có thể giảm dần vì một vài lý do. Điều này giống như, tôi sẽ gọi đây là ghi tài liệu, chứ không thực sự là thử nghiệm. Vì vậy, trong khi bạn có bảng tính này với một loạt các ví dụ đầu vào, có thể bạn theo dõi mỗi khi bạn điều chỉnh tác nhân của mình, các đầu ra khác nhau đã được phát ra. Tất nhiên, điều đó có thể trở nên cồng kềnh để quản lý theo thời gian. Rất khó để có thể so sánh trực tiếp các thử nghiệm qua thời gian. Bạn có thể sẽ không thực hiện nhiều phân tích (analytics) trên các thử nghiệm đó, và phân tích mà bạn đang thực hiện, chúng có thể đến từ một loại điểm số do con người chấm (human score) nào đó, điều này rất có giá trị, nhưng khó mở rộng trong thực tế.
Nếu chúng ta muốn đảm bảo rằng chúng ta đang đưa rất nhiều người vào cuộc, không chỉ những người có chuyên môn kỹ thuật mà cả những người không có chuyên môn kỹ thuật. Họ có thể thêm rất nhiều giá trị cho tác nhân của bạn vì kiến thức chuyên môn về lĩnh vực (domain expertise) độc đáo và sự gần gũi với người dùng. Ý tôi là, họ có thể sẽ không sử dụng bảng tính. Và nó chậm. Mỗi khi bạn đánh giá (eval), bạn có thể phải trải qua một quá trình hơi cồng kềnh để tạo lại hoặc thêm vào bảng tính.
Giai đoạn 2: Giao diện người dùng Tùy chỉnh và Cơ sở dữ liệu
Có lẽ một trong những cuộc trò chuyện thú vị nhất mà tôi có trong công việc của mình là khi một kỹ sư sản phẩm rất tự hào tham gia cuộc gọi với tôi, họ ưỡn ngực và nhếch mép với tôi và nói, "Tại sao tôi không thể tự mình làm tốt?" Tôi nghĩ nếu bạn mới bắt đầu hành trình của mình, đó là một bước đi rất tốt. Vì vậy, bây giờ thay vì ở trong "thế giới bảng tính", bạn đang tạo ra một cái gì đó tùy chỉnh riêng (bespoke) hơn một chút để đưa những người khác vào cuộc.
Vì vậy, bây giờ bạn có thể có một vòng lặp for. Bạn có một UI đẹp hơn bây giờ, vì vậy nó dễ tiếp cận hơn. Và hy vọng bạn đã chuyển sang một cơ sở dữ liệu không phải Excel hoặc Google Sheets. Bạn có thể sử dụng một cơ sở dữ liệu mới như Neon hoặc tương tự. Vì vậy, bây giờ bạn có một câu chuyện tốt hơn về khả năng lưu trữ lâu dài của các đánh giá (persistence of evals). Và vì điều này, bạn đưa nhiều người hơn vào cuộc. Bạn đang tạo ra các UI được tùy chỉnh riêng hơn một chút cho những người dùng cụ thể của bạn. Vấn đề ở đây là bạn vẫn chưa thực sự lặp lại (iterating). Bạn vẫn đang thực hiện công việc giống như báo cáo, chỉ là ghi tài liệu (documentation), hơn là khuyến khích nhiều lặp lại. Vì vậy, đây giống như một công cụ báo cáo (reporting tool) nhiều hơn.
Có bao nhiêu người đã tự xây dựng UI của riêng mình? Vâng, hợp lý.
Giai đoạn 3: Khuyến khích Thử nghiệm
Bước tiếp theo ở đây: bạn muốn khuyến khích nhiều thử nghiệm (experimentation), không chỉ với người dùng kỹ thuật mà cả người dùng không chuyên về kỹ thuật. Vì vậy, việc hiển thị hình ảnh này phù hợp hơn với việc cho phép thử nghiệm cho người dùng không chuyên về kỹ thuật. Nhưng tất nhiên, khi bạn đang xây dựng các nền tảng này, bạn cũng muốn cho phép trải nghiệm SDK-driven nhiều hơn. Điều đó đơn giản là không tạo ra một hình ảnh đẹp trong một bài thuyết trình.
Vì vậy, thử nghiệm đối với tôi có nghĩa là bạn có thể cấp cho người dùng quyền truy cập vào một tác nhân, một cấu hình của tác nhân trong một môi trường biệt lập (sandbox). Và bạn cho phép họ điều chỉnh các tham số (parameters) nhất định trong tác nhân đó. Trong ví dụ của tôi ở đây, tôi đang cho phép một người dùng trong UI thay đổi hướng dẫn hệ thống (system instructions) cho một tác nhân đang chạy bên ngoài nền tảng đánh giá của tôi và cho phép họ so sánh hai cấu hình khác nhau của lời nhắc hệ thống (system prompt) đó. Và tôi đang thực hiện evals trên hai lần chạy tác nhân khác nhau đó để tôi có thể hiển thị điểm số (bubble up scores). Bạn có thể thấy điều đó trong hình ảnh bây giờ. Tôi có thể hiển thị các điểm số khác nhau để hiểu cả về mặt kỹ thuật và chức năng tác nhân của tôi đang hoạt động như thế nào.
Vì vậy, bạn sẽ nghe về rất nhiều nền tảng có tính năng "sân chơi" (playground feature). Bạn sẽ muốn có một loại tính năng "sân chơi" nào đó cho cả người dùng kỹ thuật và không chuyên về kỹ thuật.
Giai đoạn 4: Kết nối Khả năng Quan sát và Đánh giá
Đây là nơi mà "miệng nói tay làm" (rubber meets the road) bởi vì cách tốt nhất để thực hiện evals là thực sự nghĩ về các chế độ lỗi (failure modes) mà tác nhân của bạn có thể mắc phải và xây dựng các hàm tính điểm (scoring functions) xung quanh những chế độ lỗi đó. Cách tốt nhất để tìm ra những chế độ lỗi đó ngay từ đầu là có quyền truy cập vào dữ liệu theo dõi trong môi trường sản phẩm (production trace data), tức là tác nhân của bạn đang đối mặt với người dùng thực và việc sử dụng thực.
Vì vậy, bước tiếp theo ở đây là một bước rất quan trọng. Chúng tôi muốn đảm bảo rằng chúng tôi có thể kết nối cái mà chúng tôi, ít nhất là nội bộ, gọi là bánh đà (flywheel). Khả năng quan sát và evals đối với chúng tôi thực sự là cùng một vấn đề từ góc độ hệ thống (system's perspective).
Chuyển đổi từ Nền tảng e-val sang Observability toàn diện
Một câu chuyện thú vị là ba năm trước, khi chúng tôi bắt đầu, chúng tôi chỉ là một nền tảng e-val. Sau đó, chúng tôi nhận thấy một trong những khách hàng của mình đang chạy e-val lớn này mỗi giờ, mỗi ngày. Chúng tôi liên hệ với người này, và họ nói, "À vâng, tôi chỉ đơn giản là đưa tất cả lưu lượng truy cập sản xuất của mình vào cơ sở dữ liệu này và chạy một e-val trên đó." Vì vậy, chúng tôi nghĩ, "Được thôi, có lẽ chúng ta nên tạo ra khả năng trace và quan sát lưu lượng truy cập thực tế và đáp ứng trường hợp sử dụng đó mà không cần phải nhồi nhét nó vào các e-val ngoại tuyến."
Vòng lặp cải tiến Tác nhân
Vì vậy, điều này thực sự quan trọng để đảm bảo rằng chúng ta có thể quan sát mọi thứ trong môi trường sản xuất và hiểu hành vi thực tế của các tác nhân của mình. Chúng ta cũng cần hiểu mức độ cải thiện thực sự mà những thay đổi chúng ta đang thực hiện đối với các tác nhân mang lại. Chúng tôi phân tích dữ liệu đó, đưa những ví dụ thực tế đó trở lại môi trường ngoại tuyến, và sau đó cải thiện chúng bằng cách sử dụng các e-val ngoại tuyến. Đây là một vòng lặp, không chỉ là một quy trình. Bạn sẽ thực hiện vòng lặp này xuyên suốt vòng đời của tác nhân mà bạn đưa vào sản xuất. Bạn nên lặp lại vòng lặp này càng nhiều lần càng tốt. Đó là cách bạn cải thiện.
Mở rộng Phạm vi: Từ e-val đến Tracing và Logging
Kết quả là, bạn đã thay đổi phạm vi của mình một chút; thực tế, bạn đã mở rộng phạm vi của mình rất nhiều. Bạn giờ đây là một nền tảng tracing và một nền tảng logging, ngoài việc là một nền tảng e-val ngoại tuyến. Lợi ích của điều này là bạn bắt đầu nhận được tín hiệu cao hơn nhiều từ cách người dùng tương tác với các tác nhân của bạn, và bạn có thể sử dụng những tương tác thực tế đó. Vì vậy, bạn gần như có thể coi e-val như việc chạy lại sản xuất trong một môi trường an toàn. Bạn đang đạt đến điểm đó với ví dụ này. Bạn cũng có thể thực hiện e-val trực tuyến bằng cách hướng các hàm chấm điểm đến lưu lượng khả năng quan sát của bạn và thực hiện các việc như cảnh báo – tất cả những điều bạn có thể xây dựng khi đạt đến giai đoạn trưởng thành này để chạy e-val.
Thách thức quản lý và phát triển Nền tảng
Mặt trái ở đây là: nếu bạn xây dựng nó, bạn phải quản lý nó. Vì vậy, chỉ vì bạn đã vibe-coded một nền tảng, thì sao? Bạn có thể được thăng chức vì nó, nhưng cũng sẽ là công việc của bạn là quản lý và tiếp tục phát triển nền tảng e-val của mình theo tốc độ của ngành, đây có thể là một thách thức thú vị mà công ty chúng tôi đang đặt cược và chúng tôi rất vui được giải quyết vấn đề đó.
Những thách thức đặc thù của Trace Tác nhân
Tuy nhiên, thách thức quan trọng hơn là các trace của tác nhân (nếu bạn nhìn trên màn hình, chúng thực sự rất phức tạp). Chúng không giống như các trace ứng dụng thông thường. Chúng thường bán cấu trúc, và nhiều khi là phi cấu trúc. Có một lượng lớn văn bản vốn có trong các vấn đề của LLM mà chúng ta đang giải quyết. Chúng rất lớn ngoài việc phức tạp. Nếu bạn cố gắng nhồi nhét một trace một gigabyte vào một hàng Postgres, điều đó có thể dẫn đến rất nhiều vấn đề về hiệu suất, và chúng rất nhiều. Nó có vận tốc cao vì có rất nhiều hoạt động sử dụng đang diễn ra trong sản xuất, hy vọng là với tác nhân mà bạn đã triển khai.
Giải pháp truy vấn và lưu trữ dữ liệu truyền thống
Đây là cách chúng tôi từng giải quyết vấn đề này. Ví dụ, nếu bạn đang ở giai đoạn trưởng thành này và có các trace đến, bạn sẽ cần tính đến hai mô hình truy vấn. Thứ nhất, nếu bạn đang thực hiện khả năng quan sát, bạn cần một cách để mọi người có thể xem ngay lập tức các trace của họ. Điều này rất quan trọng. Bạn sẽ cần một cách có độ trễ thấp để thu nạp dữ liệu. Thứ hai, bạn cũng cần một lớp bền vững cho mô hình truy vấn là muốn có thể phân tích và tổng hợp dữ liệu này. Chúng tôi từng sử dụng một kho dữ liệu mã nguồn mở cho việc này. Chúng tôi kết nối hai nguồn này lại với nhau thông qua một ngôn ngữ dành riêng cho miền mà chúng tôi tạo ra, gọi là BTQL, không ai thích (kể cả chúng tôi, chúng tôi ghét nó). Sau đó, chúng tôi thực hiện mức độ tổng hợp thứ ba bằng cách sử dụng DuckDB trong trình duyệt. Điều này đã hiệu quả với chúng tôi một thời gian. Sau đó, nó không còn hiệu quả khi tôi sử dụng một trong các ví dụ khách hàng của chúng tôi. Một khách hàng như Notion, chẳng hạn, gửi cho chúng tôi rất nhiều dữ liệu phi cấu trúc. Họ muốn có thể thực hiện những thứ như tìm kiếm toàn văn trên một trace. Không có công nghệ nào thực sự được trang bị để thực hiện phân tích kiểu văn bản, đây là một thách thức trong miền LLM vì có quá nhiều văn bản.
E-val và Khả năng quan sát là một Vấn đề hệ thống
Điều đó dẫn chúng tôi đến kết luận này: việc đo lường chất lượng tác nhân, thực hiện e-val, và thực hiện khả năng quan sát thực chất là một vấn đề hệ thống. Nó không chỉ là một vấn đề UI/UX. Chúng tôi nhận thấy rằng việc vibe-code UI của e-val khá dễ dàng, nhưng việc tạo ra lớp dữ liệu để chạy một nền tảng e-val và khả năng quan sát thành công thì khó khăn hơn rất nhiều. Không chỉ từ góc độ quy mô, mặc dù điều đó quan trọng, mà chủ yếu từ góc độ chức năng của việc cho phép mọi người làm những điều họ mong đợi, như thực hiện tìm kiếm toàn văn trên hàng triệu trace trong nền tảng mà họ lựa chọn.
Đặc điểm dữ liệu Trace Tác nhân và Mô hình đọc
Tôi đã nói về điều này một chút. Lý do tại sao đây là một vấn đề mới lạ cần giải quyết là vì nhiều khía cạnh (mà tôi sẽ không trình bày chi tiết trên slide này). Dữ liệu đến rất nhanh, và chúng rất lớn. Theo truyền thống, các span trong một trace chỉ là một phần của trace, thường chỉ vài kilobyte. Ở đây, chúng tôi đã thấy các span có kích thước 10-20 megabyte, chứa rất nhiều ngữ cảnh, và có tính phi cấu trúc cao. Ngoài ra, còn có rất nhiều mô hình đọc khác nhau. Bạn có thể đang thực hiện các mô hình đọc tổng hợp, nhưng bạn cũng muốn các mô hình đọc có độ trễ rất thấp. Vì vậy, mặc dù không có vấn đề nào trong số này là độc đáo riêng lẻ, nhưng khi kết hợp lại, chúng tạo thành một vấn đề rất độc đáo từ góc độ hệ thống.
Xây dựng Nền tảng dữ liệu phù hợp cho Trace
Vì vậy, điều chúng tôi đã làm, và điều mà tất cả các bạn sẽ phải nỗ lực thực hiện nếu tự xây dựng nó, là bạn thực sự phải suy nghĩ về việc tạo ra một nền tảng dữ liệu phù hợp cho các trace, để bạn có thể thực hiện một số yêu cầu chức năng cao hơn sẽ phát sinh sau này. Ví dụ tôi đưa ra ở đây là: giả sử bạn muốn cho một tác nhân mã hóa tự do hoạt động trên nền tảng e-val của mình để bạn có thể tự phục hồi tốt hơn bằng cách lấy dữ liệu từ nền tảng e-val, sử dụng một tác nhân mã hóa để đưa dữ liệu đó vào ngữ cảnh và thay đổi tác nhân của bạn trong một phiên tác nhân mã hóa. Đó là điều sẽ rất khó thực hiện nếu bạn chỉ có thể chạy rất nhiều SQL thuần túy trên phần phụ trợ dữ liệu của nền tảng e-val của bạn.
Trường hợp sử dụng Headless và Tác nhân mã hóa
Chúng tôi thực sự đã nhận thấy rất nhiều trường hợp sử dụng kiểu headless xuất hiện, nơi mọi người không quan tâm đến UI chút nào. Điều duy nhất họ quan tâm là, "Làm thế nào tôi có thể thực hiện e-val theo cách mà tôi có thể sử dụng một Codex hoặc một Claude Code để giúp tăng chất lượng của tác nhân của mình?"
Khám phá Unknown Unknowns và các Cân nhắc trong tương lai
Vấn đề cuối cùng tôi sẽ nói ở đây là vấn đề "vậy thì sao". Chúng ta sẽ bỏ qua điều này bây giờ để tiết kiệm thời gian. Đây là cách Brain Trust thực hiện điều đó. Chúng tôi có một bài blog về chủ đề này, vừa được phát hành, nếu bạn quan tâm. Điều tiếp theo bạn có thể mong đợi xây dựng vào nền tảng e-val của mình là khả năng cho người dùng biết những điều chưa biết nhưng không biết rằng mình chưa biết (unknown unknowns) về tác nhân của bạn. Tức là, "Đừng bắt tôi xem xét một đống trace; chỉ cần cho tôi biết mọi người đang sử dụng tác nhân của chúng ta như thế nào." Vì vậy, bạn muốn có thể khám phá những điều chưa biết nhưng không biết rằng mình chưa biết đó thông qua các kỹ thuật mô hình hóa chủ đề để bạn biết nên dành thời gian kỹ thuật của mình vào đâu. Bạn muốn đảm bảo rằng bạn đang xây dựng nền tảng của mình không chỉ cho con người mà còn cho các tác nhân, bởi vì đó là một trong những phương tiện chính mà con người đang tạo ra công nghệ hiện nay. Chúng ta thậm chí chưa nói về các yêu cầu phi chức năng đi kèm khi xây dựng các nền tảng này, như kiểm soát truy cập dựa trên vai trò và che giấu dữ liệu. Đó cũng là một điều cực kỳ quan trọng xuất hiện khi bạn muốn vận hành ở quy mô lớn. Và cuối cùng, một cân nhắc là thêm tracing tự động thông qua một loại proxy AI hoặc gateway nào đó để mọi người thậm chí không có lựa chọn nào khác ngoài việc trace các LLM của họ. Chúng ta có thể quản lý rất tập trung bằng cách thêm tracing tự động vào nền tảng e-val của bạn.
Xử lý Đầu vào/Đầu ra Đa phương thức
Tôi rất cảm kích thời gian của quý vị. Tôi còn khoảng một phút hai mươi giây cho phần hỏi đáp. Tôi có thể trả lời khoảng hai câu hỏi nếu có ai có thắc mắc. Vâng. Vậy Brain Trust xử lý các đầu ra và đầu vào đa phương thức (multimodal outputs and inputs) cũng như trace như thế nào? Vâng, về mặt kỹ thuật, chúng tôi chỉ đơn giản đặt chúng vào một lưu trữ đối tượng (object storage), tham chiếu chúng, và sau đó hiển thị trực tiếp chúng vào trace. Vì vậy, nếu bạn có một tệp âm thanh hoặc một tệp video, bạn có thể phát nó trong trace khi ai đó đang xem lại trace đó. Chúng tôi không muốn mọi người phải thoát khỏi nền tảng vì điều đó. Có một câu hỏi là, " Quản lý lời nhắc (prompt management) có nằm trong Brain Trust không?" Có thể có, hoặc không nhất thiết phải có. Vâng. Được rồi, hoàn hảo. Cảm ơn rất nhiều vì sự chú ý của quý vị hôm nay.