- Hội thảo tập trung vào việc cung cấp các ứng dụng Trí tuệ nhân tạo (AI) chất lượng cao bằng cách tận dụng nền tảng Brain Trust, hợp tác với Trainline để chia sẻ kinh nghiệm thực tế.
- Thách thức chính trong việc triển khai AI là chuyển đổi từ các bản thử nghiệm (POC) sang môi trường sản phẩm thực tế, do sự khác biệt giữa tính xác định của phần mềm truyền thống và tính xác suất của AI.
- Brain Trust cung cấp một nền tảng quan sát AI (AI observability) và quy trình làm việc có hệ thống (flywheel) để giải quyết các vấn đề này, giúp các tổ chức xác định chế độ lỗi, đánh giá hiệu suất và liên tục cải thiện hệ thống AI ở quy mô lớn.
Shipping complex AI applications — Braintrust & Trainline
- Việc chuyển đổi các bản thử nghiệm AI/ML (đặc biệt là AI tạo sinh) sang môi trường sản phẩm gặp khó khăn lớn do thiếu "sự chặt chẽ trong vận hành" (operational rigor) và tính phi xác định của AI.
- "Khả năng quan sát" (observability) là yếu tố then chốt để hiểu hành vi của hệ thống AI trong sản xuất, vượt ra ngoài việc chỉ xem xét các nhật ký (logs) thông thường.
- Phát triển AI chất lượng đòi hỏi cách tiếp cận có cấu trúc, tương tự như kiến trúc dịch vụ vi mô (microservices) trong kỹ thuật phần mềm, để chia nhỏ các lời nhắc (prompts) phức tạp và luồng tác nhân (agentic flow).
- Hội thảo thực hành sẽ hướng dẫn xây dựng hệ thống AI với "gọi công cụ đa giai đoạn" (multi-stage tool calling), sử dụng Brain Trust để "công cụ đo lường" (instrument) và đánh giá hiệu suất.
- Xác định các "chế độ lỗi" (failure modes) bằng "kiểm thử vàng" (golden test) và xử lý "trường hợp biên" (edge cases) bằng dữ liệu thực tế là rất quan trọng để công nghiệp hóa và duy trì hệ thống AI.
- Brain Trust là một nền tảng "khả năng quan sát AI" (AI observability platform) giúp xử lý dữ liệu bán cấu trúc (semi-structured traces) từ các hệ thống AI để theo dõi và cải thiện liên tục thông qua một "vòng quay liên tục" (flywheel) lặp đi lặp lại.
- Trainline sử dụng AI để dự đoán gián đoạn tàu (ML truyền thống) và vận hành "trợ lý du lịch AI" (AI travel assistant) là một "hệ thống đa tác nhân" (multi-agent system) chủ động xử lý các yêu cầu như hoàn tiền và đổi tàu.
hands-on workshop— hội thảo thực hànhAI— Trí tuệ nhân tạoBrain Trust— (Tên nền tảng)LLMs— Mô hình Ngôn ngữ Lớnkỹ sư AI— AI engineermôi trường sản phẩm— production environmentoperational rigor— sự chặt chẽ trong vận hànhobservability— khả năng quan sátprompt— lời nhắcfailure modes— chế độ lỗigolden test— kiểm thử vàngedge cases— trường hợp biênflywheel— vòng quay liên tụcAI travel assistant— trợ lý du lịch AImulti-agent system— hệ thống đa tác nhân
Giới thiệu và chào mừng
Chào buổi chiều tất cả mọi người. Chào mừng đến với Sonny London. Đây có phải là lần đầu tiên của mọi người ở đây không? Tôi nghĩ là có, vì đây là một hội nghị khai mạc. Thật tuyệt vời, thật tuyệt vời. Cảm ơn rất nhiều vì đã tham gia buổi hôm nay. Hy vọng các bạn đã chọn đúng buổi. Nhưng đối với những ai cần kiểm tra kỹ lại, đây là một hands-on workshop về việc cung cấp các ứng dụng AI chất lượng cao với Brain Trust. Chúng tôi cũng sẽ hợp tác với các đồng nghiệp tại Trainline, những người sẽ được giới thiệu ngay sau đây.
Về phần giới thiệu của tôi: các bạn có thể gọi tôi là Durand, giống như ban nhạc Duran Duran, nhưng có thêm chữ G. Hy vọng mọi người là fan của Simon Le Bon. Tôi đã có cơ hội giúp các tổ chức và doanh nghiệp mở rộng quy mô áp dụng các hệ thống quan trọng, và giờ đây tôi đang chuyển sang kỷ nguyên AI. Nền tảng của tôi là toán học thuần túy. Tôi biết rằng học máy đến khoa học dữ liệu và hiện tại là kỹ thuật AI đang là xu hướng nóng, và đây là thời điểm rất thích hợp. Các bạn cứ thoải mái kết nối với tôi trên LinkedIn nếu muốn theo dõi hoặc chỉ đơn giản là trò chuyện về lĩnh vực này.
Tôi cũng có hai người bạn từ Trainline ở đây, nếu các bạn muốn đến và tự giới thiệu. (Kiểm tra micro) Ồ, tốt. Vâng. Xin chào mọi người. Cảm ơn đã đến với workshop này, đặc biệt là sau giờ ăn trưa và thời tiết nắng đẹp bên ngoài. Cảm ơn rất nhiều vì đã đến đây. Tên tôi là Osama. Tôi là một kỹ sư AI cấp cao tại Trainline. Ai biết tôi không? Vâng, một người. Trước đây tôi là một kỹ sư nền tảng cấp chuyên viên và có nền tảng về thị giác máy tính. Tôi cũng đã phát triển các ứng dụng di động bên cạnh. Có lúc tôi không liên quan gì đến AI, nhưng vâng, bây giờ chúng tôi đang làm AI cùng với các đồng nghiệp tại Trainline.
Chào mọi người. Tên tôi là Mike. Tôi là một kỹ sư AI cấp cao tại Trainline. Tôi có nền tảng nghiên cứu về các Mô hình Ngôn ngữ Lớn (LLMs), nhưng nghiên cứu của tôi tập trung vào các LLM tiền-LLM lớn, như BERT hoặc các LLM cũ hơn. Vì vậy, chúng tôi đang tiếp tục xây dựng các sản phẩm tác nhân (agentic products) tiên tiến nhất tại Trainline. Nếu các bạn đến từ nước ngoài, tôi chắc rằng các bạn đã sử dụng Trainline rồi; nếu chưa, xin hãy dùng thử, vì đây là dịch vụ hiện đại nhất để mua vé và các thứ khác. Vâng, chào mừng, và chúng tôi rất vui khi được tổ chức workshop này. Chúng tôi sẽ hướng dẫn các bạn qua trải nghiệm thực hành.
Tuyệt vời. Tôi cũng có một số đồng nghiệp từ Brain Trust đến từ nước ngoài. Phil, Eric và Rose, nếu các bạn có thể giơ tay. Đừng lo lắng, mọi người sẽ an toàn nếu các bạn gặp khó khăn. Chỉ cần gọi và họ sẽ giúp đỡ. Tuyệt vời.
Hướng dẫn chung và thiết lập hội thảo
Chỉ muốn một chút về hướng dẫn chung. Nếu mọi người có thể tham gia kênh Slack của AI Engineer. À, có một tổ chức AI Engineer, nhưng cũng có một kênh Slack cụ thể mà chúng ta sẽ sử dụng hôm nay để giúp tiến hành workshop. Vì vậy, nếu các bạn gặp khó khăn, chúng ta có thể sử dụng kênh Slack để giúp đỡ lẫn nhau. Một lần nữa, chúng tôi đã ở đó rồi, nhưng khi chúng ta tiến hành và đến phần thực hành, nếu các bạn gặp khó khăn, điều này sẽ thực sự hữu ích. Chúng tôi cũng cung cấp các tờ hướng dẫn (cheat sheets). Vì vậy, nếu các bạn gặp phải một trở ngại cụ thể, có các hướng dẫn từng bước giúp các bạn đến được nơi chúng ta cần trong workshop mà không cần phải cảm thấy bị tụt lại phía sau. Một lần nữa, tất cả các tài nguyên chúng tôi chia sẻ hôm nay đều có sẵn công khai. Chúng tôi có thể có bất kỳ buổi theo dõi cụ thể nào nếu cần. Nhưng chúng tôi sẽ cho các bạn vài phút để đảm bảo các bạn tham gia vào kênh đó, và sau đó tham gia kênh AI Engineer Europe 226 Brain Trust Dash Workshop. Đây là một kênh công khai. Được rồi, mọi người. Tôi đoán chúng ta có thể bắt đầu. Vâng, đối với những người ngồi ở phía sau, chúng ta sẽ cần tham gia kênh Slack. Vì vậy, nếu các bạn đã thấy Pierce, tôi hy vọng sẽ làm được điều đó. Cảm ơn mọi người. Hãy tiếp tục.
Cấu trúc buổi hội thảo
Ok, đây là để giúp định hướng workshop hôm nay. Chúng ta sẽ chia thành ba phần chính. Chúng ta sẽ dành một chút thời gian để thiết lập bối cảnh tại sao chúng ta ở đây và tại sao workshop này lại phù hợp. Hy vọng chúng ta sẽ thiết lập ngữ cảnh cho khi chúng ta đi vào workshop, xây dựng hệ thống, nói về việc làm thế nào để chúng ta triển khai AI chất lượng, và sau đó chúng ta sẽ tổng kết các điểm chính và chúng tôi sẽ ở lại để trả lời bất kỳ câu hỏi mở nào mà chúng ta có từ thực tế.
Đối tượng tham gia
Ok, hy vọng hôm nay sẽ có rất nhiều người đến từ nhiều nền tảng khác nhau. Chúng tôi dự định workshop này sẽ phục vụ cho, một lần nữa, có lẽ mọi người ở đây đều biết Mô hình Ngôn ngữ Lớn (LLM) là gì. Tôi không muốn xúc phạm ai cả, nhưng hy vọng các bạn đang bắt đầu hành trình khám phá và trưởng thành trong việc vận hành để xây dựng các hệ thống AI. Vì vậy, cho dù bạn là một kỹ sư sản phẩm AI, có lẽ từ một đội ứng dụng, hoặc đến từ những người học máy truyền thống, có lẽ bạn có thể là một người vận hành nền tảng hoặc cơ sở hạ tầng. Workshop này thực sự phù hợp với bạn.
Chỉ cần giơ tay lên đây, ai ở đây đến từ nền tảng khoa học dữ liệu truyền thống, chẳng hạn? Thú vị, thú vị. Ai ở đây có lẽ đến từ kỹ thuật phần mềm và sau đó chuyển sang AI? Được rồi, vậy đây chắc chắn là căn phòng phù hợp cho bạn. Hy vọng chúng ta sẽ có thể đẩy nhanh mọi thứ khi chúng ta tiến triển.
Thách thức khi đưa AI vào sản xuất
Được rồi, chỉ để đặt ngữ cảnh ở đây. Tôi nghĩ đây không phải là một biểu hiện bất thường mà chúng ta đang thấy rộng rãi hơn trong ngành. Một lần nữa, nhưng nếu giơ tay, ai ở đây đã làm một bản thử nghiệm (POC) học máy hoặc AI, cụ thể hơn là một bản thử nghiệm (POC) AI tạo sinh, nhưng sau đó đã không thể đưa nó vào môi trường sản phẩm (production)? Được rồi, có một vài cánh tay, vâng. Tôi sẽ lo lắng nếu không ai giơ tay, nhưng đây là một vấn đề then chốt mà tôi và khách hàng của tôi đang nói đến, các giám đốc điều hành, những người cấp cao, tất cả đều đang rất quan tâm. Họ đang nghĩ về công nghệ mới này. Công nghệ này rất mới, nhưng nó mới đối với rất nhiều người, đặc biệt là trong các doanh nghiệp lớn hơn và các ngành được quản lý. Và sau đó họ đang cố gắng đưa công nghệ này để mang lại giá trị cho khách hàng của họ.
Nhưng thật không may, có một rào cản lớn giữa việc phát triển một cái gì đó trên máy cục bộ của bạn và sau đó công nghiệp hóa nó, đảm bảo nó hoạt động trong thực tế. Nhưng điểm mấu chốt mà chúng tôi đã thấy từ tất cả các nghiên cứu hiện có là không phải các mô hình đặc biệt thông minh. Chúng tôi có các mô hình rất tinh vi, cho dù bạn xây dựng một cái gì đó nội bộ hay bạn đang sử dụng một nhà cung cấp thương mại trực tuyến hàng đầu. Điều chúng tôi thấy rộng rãi hơn là loại sự chặt chẽ trong vận hành (operational rigor) khi đưa các hệ thống này ra quy mô đã không theo kịp, bởi vì kỹ thuật phần mềm truyền thống rất xác định (deterministic), 1 cộng 1 bằng 2, tuyệt vời. Và các hệ thống trực tuyến, như tôi đã từng nói, hoặc một đứa trẻ năm tuổi sẽ nói, 2 cộng 3 bằng 10, bố ơi. Vì vậy, chúng ta phải điều chỉnh và đảm bảo rằng chúng ta đang cung cấp điều đó ở quy mô.
Và một lần nữa, đây là một điểm quan trọng mà chúng tôi thấy khi triển khai những thứ này là thực tế là mọi người nghĩ rằng demo là đủ. Nhưng rõ ràng, thực hiện 2 đến 3, 5 demo thì tuyệt vời, nhưng khi đưa vào sản xuất, mọi thứ đều gặp trục trặc. Coi một số nhật ký (logs) của bạn là khả năng quan sát (observability) – và điều này thực sự quan trọng đối với cách chúng tôi nhìn nhận Brain Trust – đó là nhật ký sẽ cho bạn biết điều gì đã xảy ra. Nhưng đôi khi bạn cần đi sâu vào hệ thống và hiểu hành vi của nó. Và đây thực sự là nơi khả năng quan sát phát huy tác dụng.
Một điều nữa là, nó hoạt động trên máy của tôi, nhưng thất bại trong môi trường sản phẩm. Tôi cố gắng vá lời nhắc (prompt) và sau đó, lại vận hành cho đến khi vấn đề tiếp theo xảy ra và chế độ lỗi tiếp theo. Nhưng một lần nữa, làm thế nào để chúng ta theo dõi điều đó? Đặc biệt nếu bạn không có một hệ thống tại chỗ, bất kể bạn sử dụng công cụ nào, điều này có thể gây ra ảnh hưởng lớn. Vì vậy, rất nhiều điều chúng tôi thấy, một lần nữa, không phải là công cụ hay công nghệ, mà là các quy trình làm việc vận hành (operational workflows) nhiều hơn. Và đây thực sự là điều chúng tôi muốn giúp bạn trong workshop hôm nay.
Cách tiếp cận để phát triển AI chất lượng
Vì vậy, một lần nữa, như tôi đã đề cập, nó không phải là nguyên mẫu, mà là đạt đến trạng thái mà chúng ta biết chính xác điều gì đã thay đổi trong hệ thống, làm thế nào để chúng ta tương tác với điều đó và sau đó làm thế nào để chúng ta đưa ra một sự chặt chẽ (rigor) có hệ thống để chúng ta có thể ngày càng tốt hơn. Hãy nhớ rằng, mục tiêu của chúng ta không phải là độ bao phủ 100%, mà là đạt được càng gần càng tốt trong khi duy trì việc khắc phục những khoảng trống có thể tồn tại.
Và một lần nữa, một điều mà chúng tôi thấy lặp đi lặp lại là, một lời nhắc có thể hoạt động, nhưng khi bạn di chuyển và công nghiệp hóa nó, bạn có thể muốn làm những điều như chia nhỏ nó thành từng phần trách nhiệm riêng lẻ. Vì vậy, nếu bạn đến từ nền tảng kỹ thuật phần mềm, bạn biết về những điều này, bạn sẽ chia monolith thành dịch vụ vi mô (microservices). Chúng tôi sẽ phác thảo một cách tiếp cận rất tương tự ở đây khi chúng tôi nói về việc xây dựng các hệ thống này. Một lần nữa, đảm bảo rằng chúng ta đang hiểu những thay đổi này, đưa ra một tập hợp các hệ thống, đây thực sự là điều chúng tôi muốn làm trong workshop hôm nay.
Nội dung thực hành hội thảo
Về phần hôm nay, hy vọng, như tôi đã đề cập, đây là một workshop thực hành, vì vậy chúng ta sẽ vào terminal, chúng ta sẽ vào UI, và chúng ta sẽ đi qua từng bước và hướng dẫn trong suốt quá trình. Vì vậy, chúng ta sẽ xây dựng một hệ thống AI theo giai đoạn với gọi công cụ (multi-stage tool calling), điều này thực sự cho phép chúng ta thấy một luồng tác nhân (agentic flow) hơn. Chúng ta sẽ sử dụng Brain Trust để công cụ đo lường (instrument) và xem hiệu suất của ứng dụng đang hoạt động như thế nào.
Sau đó, chúng ta cũng muốn xem xét việc tạo ra cái mà chúng tôi gọi là xác định các chế độ lỗi (failure modes) bằng cách sử dụng một kiểm thử vàng (golden test). Vì vậy, chúng ta sẽ đẩy nó qua. Sau đó, chúng ta cũng muốn nói về cách chúng ta công nghiệp hóa nó. Vì vậy, việc chuyển từ "nó chỉ hoạt động trên máy của tôi" sang một cái gì đó mà bạn có thể sử dụng trong môi trường sản phẩm và có một hệ thống quản lý nó. Và điều quan trọng là xác định các trường hợp biên (edge cases), bởi vì một lần nữa, bạn có thể tạo một tập dữ liệu kiểm thử (test data set), nhưng cuối cùng không có gì thay thế được dữ liệu thực tế (real world data). Vì vậy, chúng tôi sẽ cho bạn thấy cách chúng ta sẽ lấy những tín hiệu thực tế đó và đánh giá để hoàn thành vòng lặp.
Giới thiệu về Brain Trust
Chỉ là một phần giới thiệu ngắn gọn nữa ở đây, ai đã từng nghe nói về Brain Trust, đã thử nghiệm với Brain Trust, tôi có thể xin một cái giơ tay không? Được rồi, tuyệt vời, tuyệt vời. Vì vậy, được rồi, tôi thích những cánh tay của bạn.
Vì vậy, một chút giới thiệu về Brain Trust. Chúng tôi là một công ty hiện đã, tôi nghĩ là gần ba năm tuổi. Chúng tôi là một công ty khoảng Series B. Vì vậy, chúng tôi vừa thông báo rằng ở mức thị trường thực phẩm, chúng tôi đã huy động được 80 triệu đô la, với định giá 800 triệu đô la. Chúng tôi có các nhà đầu tư như Iconic, a16z, cũng như Gwelok để thực sự nói về việc giúp các tổ chức triển khai AI chất lượng ở quy mô lớn.
Chúng tôi là nền tảng cho khả năng quan sát AI (AI observability). Chúng tôi có một lượng lớn người dùng trên toàn cầu, nhưng chúng tôi cũng đang mở rộng sự hiện diện của mình mạnh mẽ ở Châu Âu. Vì vậy, một lần nữa, tôi là một trong những kỹ sư đầu tiên gia nhập để giúp xây dựng chức năng đưa sản phẩm ra thị trường của chúng tôi ở đây. Chúng tôi rất vui mừng, một lần nữa, với khách hàng của chúng tôi và bạn bè của chúng tôi qua Trainline để làm điều đó. Một số khách hàng địa phương của chúng tôi bao gồm như Lovable, Dr. Lub cũng đang thực sự thúc đẩy các hệ thống AI này.
Một lần nữa, khi sử dụng Brain Trust, tôi muốn tự mình trải nghiệm, nhưng điều mà chúng tôi thực sự nổi bật là khả năng thực hiện điều này ở quy mô lớn. Vì vậy, người sáng lập, Ankur Gwel, đây thực sự là lần thứ ba ông xây dựng Brain Trust. Ông ấy là một chuyên gia khi nói đến các hệ thống cơ sở dữ liệu. Và ông ấy đã xây dựng một công ty tên là Imperial Provisity được Figma mua lại, công ty này nói về trích xuất tài liệu. Ông ấy cần để đội ngũ học máy (ML team) ra ngoài đó. Và bởi vì ông ấy nhận ra, việc xây dựng các đánh giá này rất khó, việc hiểu các dấu vết sản xuất (production traces) rất khó. Vì vậy, chúng tôi đang gặp vấn đề này, tôi chắc rằng có những tổ chức khác cũng đang làm như vậy. Và vì vậy ông ấy đã thành lập Brain Trust, để thực sự giúp thực hiện điều này ở quy mô lớn.
Giới thiệu Brain Trust và Vòng Lặp Flywheel
Khi chúng tôi xử lý và phân tích các traces đi vào, và một lần nữa, vì đây là dữ liệu semi-structured (bán cấu trúc) thay đổi rất nhiều, chúng tôi nhận ra rằng các hệ thống phân tích truyền thống không còn phù hợp. Vì vậy, chúng tôi đã tạo ra một danh mục cơ sở dữ liệu mới mang tên Brain Trust, thực sự giúp xác định và tăng tốc quá trình này ở quy mô lớn. Một lần nữa, chúng tôi làm việc với các nền tảng agnostic (không phụ thuộc vào nền tảng). Vì vậy, bất kể framework tác nhân hay các nhà cung cấp LLM nào bạn đang sử dụng, chúng tôi đều mong muốn giúp bạn mang lại giá trị.
Một điều tôi sẽ nói khi chúng ta tiến hành workshop này là khái niệm flywheel (vòng quay liên tục). Nếu bạn đã từng làm việc với phát triển Agile, bạn biết rằng sự hoàn hảo là kẻ thù của cái tốt. Chúng ta muốn bắt đầu từ một điểm nào đó. Ngay cả khi đó là một ứng dụng mới và bạn không biết nó sẽ hoạt động ra sao trong sản xuất, chúng ta có thể bắt đầu với một bộ đánh giá. Nếu bạn có một ứng dụng hiện có để tích hợp công cụ/đo lường, điều đó thật tuyệt. Chúng ta có thể thu thập thông tin đó và xác định các chế độ lỗi tại đây. Vì vậy, điều quan trọng là đưa thông tin vào hệ thống, xác định các chế độ đó, khắc phục, triển khai, sau đó giám sát và hoàn thành flywheel lặp đi lặp lại để bạn đạt được một kết quả thống nhất.
Train Line: Nền Tảng Đặt Vé Tàu và Trợ Lý Du Lịch AI
Bây giờ, tôi sẽ nhường lời cho các đồng nghiệp của tôi tại Train Line để họ chia sẻ kinh nghiệm của mình, cụ thể là trước khi sử dụng Brain Trust và cách họ đang được giúp đỡ. Osama, bạn có thể bắt đầu. Cảm ơn rất nhiều. Và xin chào một lần nữa những người mới tham gia cùng chúng tôi. Như đã giới thiệu, Train Line là một công ty thực sự giúp mọi người di chuyển bằng tàu hỏa. Tàu hỏa khác với máy bay nếu bạn chưa biết. Có một hệ thống trung tâm trên toàn thế giới dành cho tất cả các chuyến bay, nhưng điều này không đúng với tàu hỏa. Ở Châu Âu và Vương quốc Anh, tôi phải nói là rất khó, nếu bạn muốn cài đặt một ứng dụng cho mỗi hãng vận chuyển, chắc chắn nó sẽ chiếm toàn bộ không gian trên điện thoại di động của bạn.
Vì vậy, Train Line thực sự là một nền tảng cơ bản giúp bạn đặt vé, là một ứng dụng di động agnostic (không phụ thuộc vào nền tảng), agnostic với nhà cung cấp dịch vụ vận chuyển. Bạn làm điều đó trên một ứng dụng và bạn có thể đặt vé tàu từ Paris đến London, từ Lyon đến Milan, bất cứ khi nào bạn muốn, với mọi nhà cung cấp dịch vụ ở EU. Chúng tôi bán gần 6,3 tỷ vé tàu, 27 triệu hoạt động và vẫn đang tiếp tục tăng. Và có lẽ một điều thú vị khác cho hội nghị này là số lượng cuộc hội thoại AI mà chúng tôi có với trợ lý du lịch của mình. Chúng tôi có một trợ lý du lịch được công khai cho mọi người. Và nó không chỉ là một chatbot. Nó thực sự là một hệ thống đa tác nhân có thể xử lý hoàn tiền cho bạn, có thể xử lý việc đổi tàu cho bạn. Vì vậy, nó là một hệ thống tác nhân rất chủ động, tôi phải nói vậy, chứ không chỉ là một chatbot. Có lẽ các đồng nghiệp của tôi muốn bổ sung thêm về điều đó. Vậy lợi ích của việc có 27 triệu khách hàng đang hoạt động là gì? Bạn có một không gian rộng lớn về cách bạn có thể phục vụ các ứng dụng tác nhân trực tiếp cho khách hàng. Osama đã nói về các ví dụ về điều đó, đó là trợ lý du lịch mà bạn có thể truy cập từ cửa sổ vé trong ứng dụng. Đó là một hệ thống tác nhân, điều mà chúng ta sẽ nói thêm một chút ở phần sau của slide. Tuyệt vời. Chúng ta nên chuyển sang điểm tiếp theo.
Học Máy và AI Tạo Sinh tại Train Line
Tôi sẽ nói ngắn gọn. Là một công ty bán vé tàu, tại sao chúng tôi lại làm học máy? Tất nhiên là chúng tôi có thể. Có rất nhiều điều phải làm và để giúp mọi người trong hành trình của họ, mua vé, đi tàu, về nhà. Chúng tôi làm hai việc. Phần ML truyền thống, đó là xây dựng các mô hình, chúng tôi làm điều đó. Chúng tôi xây dựng các mô hình ML bên trong Train Line từ đầu, từ dữ liệu đến mô hình. Đây là điều chúng tôi làm. Và chúng tôi cũng xây dựng các hệ thống AI tạo sinh dựa trên đa tác nhân mà chúng ta đã quen thuộc, trên các LLM mà chúng ta yêu thích và trân trọng, cùng với các công cụ và kỹ thuật ngữ cảnh và tất cả những thứ đó. Chúng tôi làm cả hai khía cạnh này tại Train Line.
Đây là hai ví dụ về những gì người dùng đang sử dụng trên các hệ thống đó ở phía bên trái. Vì vậy, bạn có thể coi đây là ứng dụng thời tiết của bạn nhưng dành cho các sự cố gián đoạn tàu. Về cơ bản, bạn có vé tàu. Bạn đến đó. Chúng tôi biết liệu chuyến tàu này có bị gián đoạn hay không, liệu nó có khả năng bị trễ hay không. Chúng tôi biết điều đó dựa trên lượng dữ liệu khổng lồ mà chúng tôi có, dựa trên mô hình học máy đã được huấn luyện và thực sự có thể dự đoán các sự cố gián đoạn tàu, việc trễ tàu và tất cả những điều đó. Vì vậy, đây là phần ML truyền thống.
Ví dụ còn lại là trợ lý du lịch mà tôi đã nói với bạn. Nó rất, như tôi đã nói, tôi phải nói là một hệ thống đa tác nhân rất tiên tiến. Nó có thể hiển thị cho bạn các chuyến tàu thay thế nếu tàu của bạn bị hủy hoặc có vấn đề gì đó. Chúc bạn may mắn khi tự mình làm điều đó ngay cả với Chat GPT. Và ví dụ khác là xử lý hoàn tiền. Vì vậy, bạn thực sự có thể yêu cầu hoàn tiền cho vé của mình nếu tàu của bạn bị trễ hoặc tất cả những điều đó và nó thực sự có thể cung cấp cho bạn tất cả những điều đó mà không cần chuyển giao. Và cũng có thể chuyển giao cho bộ phận hỗ trợ khách hàng là người thật trong nhóm hỗ trợ khách hàng đáng yêu của chúng tôi. Điều đó có nghĩa là nếu bạn đang làm điều này ở cấp độ sản xuất và ở quy mô Train Line, điều đó có nghĩa là hoặc bạn có thể đặt câu hỏi liệu chúng tôi có đang gây ra sự cố tại Train Line không? Tất nhiên, chúng tôi không muốn làm điều đó. Và chúng tôi đang di chuyển nhanh chóng vì công nghệ chắc chắn đang di chuyển nhanh chóng. Và đây là lý do tại sao chúng tôi ở đây. Chúng tôi ở đây để cho bạn thấy chúng tôi đang làm gì để di chuyển nhanh chóng mà không gây ra sự cố về AI. Và chúng tôi có thể làm điều đó trên cơ sở xử lý các hệ thống phần mềm phức tạp mà chúng tôi yêu thích và trân trọng, từ API đến quy mô lớn và phục vụ hàng triệu người dùng.
Quản Lý Hệ Thống Phần Mềm Xác Định và Không Xác Định
Cách chúng tôi muốn suy nghĩ về điều này là theo quy mô. Vì vậy, chúng tôi chắc chắn rằng bất cứ hệ thống phần mềm nào chúng tôi có đều là khía cạnh xác định (deterministic) của vấn đề. Và mặt khác, việc xây dựng các mô hình ML, đây là khía cạnh không xác định (non-deterministic) của vấn đề. Và chúng tôi chắc chắn rằng sự tồn tại của tác nhân nằm ở giữa. Có những phần của chúng là xác định. Có những phần của chúng chắc chắn không xác định. Và đây là khung làm việc tư duy mà chúng tôi có.
Về chất lượng, chúng tôi xử lý nó như thế nào? Đó là câu hỏi. Đối với các mô hình ML, chúng tôi quan tâm đến chất lượng dữ liệu mà chúng tôi sử dụng để huấn luyện các mô hình. Nhưng chúng tôi cũng có trên đó, tất nhiên, các đánh giá học máy, dù là ngoại tuyến hay trực tuyến. Ngoại tuyến có nghĩa là trước khi đưa vào sản xuất, bạn cần thực hiện các đánh giá của mình. Và trực tuyến là dữ liệu bạn nhận được từ môi trường sản xuất. Và đánh giá mô hình của bạn xem nó có hoạt động tốt hay không. Trong trường hợp của chúng tôi, ví dụ, đối với dự báo đó, liệu nó có dự đoán đúng trạng thái của chuyến tàu nếu nó bị gián đoạn hay không? Liệu mô hình có chính xác trong dự đoán của nó hay không? Đó là một ví dụ.
Mặt khác, đối với những người quen thuộc với kỹ thuật phần mềm, chúng tôi thực hiện tất cả các kiểm tra chất lượng, sơ đồ và công cụ mà chúng tôi có để xử lý chất lượng ở quy mô lớn, quy mô rất lớn tại Train Line. Và đối với các hệ thống đó, tôi nghĩ bạn đã đoán được, nó về cơ bản là sự kết hợp của cả hai. Chắc chắn không có cái này mà không có cái kia. Chúng tôi làm mọi thứ mà chúng tôi thực hiện về chất lượng trong các hệ thống xác định, nhưng chúng tôi cũng sử dụng khía cạnh đánh giá từ các hệ thống không xác định. Vì vậy, vâng, đó là khung làm việc tư duy mà chúng tôi có tại Train Line khi suy nghĩ về các hệ thống này. Và chắc chắn, Brain Trust đang giúp đỡ điều đó. Và nhân tiện, tuyên bố miễn trừ trách nhiệm: chúng tôi không, tôi phải nói là, chúng tôi ở đây chỉ vì chúng tôi tin rằng Brain Trust hoạt động hiệu quả với chúng tôi. Chúng tôi không được trả tiền. Vì vậy, đó là 100%. Chúng tôi là những khách hàng hài lòng. Chúng tôi đã sử dụng Brain Trust trong một thời gian dài. Và chúng tôi sử dụng nó trong các tính năng khác nhau của Brain Trust. Chúng tôi thực sự sử dụng chúng ở đây. Ví dụ, đối với các đánh giá ML AI, chúng tôi làm điều đó. Và chúng tôi theo dõi điểm số của trợ lý du lịch ở nhiều cấp độ, từ ngữ điệu cho đến khả năng giúp đỡ thực tế khi liên quan đến vé. Và vé thực sự, tôi phải nói là rất phức tạp về mặt lý luận (reasoning) và những gì bạn nên nhận được, những gì bạn không nhận được, tùy thuộc vào việc tàu có bị trễ hay không, loại vé là vé khứ hồi hay vé đặt trước. Có rất nhiều trường hợp phức tạp. Nhưng vâng, chúng tôi theo dõi khía cạnh đánh giá đó.
Tối Ưu Hóa Chi Phí LLM và Triển Khai Nhanh Chóng với Brain Trust
Có ai trong số các bạn đã từng gặp khó khăn với chi phí LLM, số lượng mã thông báo, việc chuyển đổi mô hình, những vấn đề như vậy không? Vâng, thật vui khi thấy. Đó cũng là một vấn đề với Train Line vì chúng tôi làm điều này ở quy mô lớn và số lượng OpenAI cũng như lượng traffic mà chúng tôi phải trả cứ như thế này. Vì vậy, chúng tôi phải liên tục chuyển đổi mô hình, chọn mô hình tốt nhất cho một trường hợp sử dụng, các mô hình rẻ hơn, các mô hình với mã thông báo hiệu quả. Bây giờ, bất cứ khi nào bạn muốn chuyển đổi mô hình, bạn muốn đảm bảo rằng nó hoạt động ít nhất ở cùng mức độ với mô hình hiện tại của bạn, đúng không? Trước Brain Trust, chúng tôi không có cách cụ thể nào để làm điều đó vì chúng tôi không có điểm số được thiết lập, chúng tôi không có, bạn biết đấy, kiểu đánh giá nào cả.
Với việc sử dụng Brain Trust, nó đã giúp chúng tôi có thể mô phỏng hiệu suất của mô hình thấp hơn sẽ trông như thế nào và chúng tôi đã sử dụng Brain Trust rộng rãi để chạy đánh giá ngoại tuyến và xem hiệu quả sẽ ra sao, và cả đánh giá trực tuyến để thấy rằng hiệu quả dự định mà chúng tôi quan sát được ngoại tuyến là đúng như mong đợi. Vì vậy, tôi nghĩ đó là một trong những trường hợp sử dụng. Một trường hợp khác mang tính tổng quát hơn, đó là chúng tôi sẽ mất rất nhiều thời gian để đánh giá một tính năng mới được triển khai vào trợ lý du lịch, nhưng với Brain Trust, chúng tôi đã có thể đảm bảo rằng chúng tôi tin tưởng trải nghiệm mới với người dùng sẽ tốt. Vì vậy, Brain Trust đã giúp chúng tôi rất nhiều trong việc triển khai nhanh chóng.
Khả Năng Quan Sát và Hợp Tác Liên Chức Năng
Và phần khác chắc chắn là khả năng quan sát. Chúng tôi sử dụng Brain Trust cho khả năng quan sát nếu cái này đang hoạt động. Vâng, đây là ví dụ thực tế từ Brain Trust. Chúng tôi về cơ bản đang giới thiệu những gì bạn sẽ thấy trong workshop. Nhưng vâng, chúng tôi có thể theo dõi mọi thứ chúng tôi đang làm, gọi công cụ (tool calling), tác nhân khác, về số lượng, về chất lượng, những loại hiểu biết sâu sắc đó, bạn sẽ cần chúng để chuyển từ chứng minh khái niệm sang hệ thống thực tế trong sản xuất hoặc trong công ty của bạn hoặc cho một sản phẩm thực sự đang được sử dụng và người dùng thấy nó là một sản phẩm hoạt động thực sự chứ không phải chỉ là một hệ thống được tạo ra bởi AI. Không, chúng tôi chắc chắn cần điều đó cho những trường hợp đó.
Có muốn bổ sung gì ở đây không? Tôi chỉ muốn nói rằng Brain Trust cho phép bạn nhìn vào bên trong các quy trình làm việc tác nhân phức tạp, đến cấp độ gọi công cụ, cấp độ mã thông báo, điều này rất sâu sắc và giúp bạn gỡ lỗi rất nhiều thứ trong sản xuất và trước khi bạn triển khai nó.
Và một điều cuối cùng có lẽ là điểm thân thiện với các nhóm chức năng chéo. Đó là điều mà chúng tôi đã khám phá ra trong quá trình làm việc bởi vì chúng tôi đang xây dựng các hệ thống đó từ trợ lý du lịch đến các mô hình. Đến một thời điểm nào đó, chúng tôi cần có, chúng tôi là một công ty lớn và chúng tôi có những người từ bộ phận sản phẩm với nền tảng phi kỹ thuật và chúng tôi cần giao tiếp và chúng tôi cần chia sẻ nhiều thứ và họ cũng cần tự phục vụ một số thứ đó. Chúng tôi không thể nói, "hãy chăm sóc" bất kỳ ai và nói, "này, bạn nên làm cái này. Để tôi lấy nhật ký, tải xuống và gửi cho bạn." Điều đó không hiệu quả. Ở quy mô lớn, chúng tôi cần một cách mà chúng tôi có thể giúp, tôi phải nói là, chúng tôi có thể làm việc theo cách liên chức năng và để mọi người được, tôi phải nói là, tự do làm bất cứ điều gì họ muốn và tự phục vụ với dữ liệu và hiểu biết sâu sắc. Vì vậy, đây là những gì chúng tôi cũng đã khám phá ra trong quá trình làm việc và Brain Trust cũng giúp ích rất nhiều với nhiều yêu cầu mà chúng tôi không thể có, nhưng chúng tôi thực sự đánh giá cao. Và tất nhiên còn nhiều hơn nữa, chúng tôi chỉ đang sử dụng một phần của hệ thống đó. Chúng tôi có những thứ riêng của mình, Brain Trust, tôi nghĩ bạn đang xây dựng thêm nhiều công cụ nữa. Vì vậy, chắc chắn còn nhiều điều nữa sẽ đến, tôi nghĩ workshop chắc chắn sẽ giúp bạn khám phá tất cả những điều đó.
Chuẩn bị Hội thảo
Và tất nhiên, thật vui khi được xây dựng trong buổi hội thảo này. Mọi người có thể mở máy tính xách tay ra. Nếu bạn quan tâm, Train Line đang tuyển dụng trong lĩnh vực A&G và nội bộ. Vâng, tôi xin chuyển lời cho bạn, được chứ? Tuyệt vời. Cảm ơn rất nhiều về điều đó, đội ngũ. Và một lần nữa, tôi muốn gửi lời cảm ơn cá nhân, cũng như từ phía vợ tôi. Chúng tôi rất cảm ơn vì chức năng lưu phân tách (split-save functionality). Hãy cho tôi biết màu sắc của nó. Được rồi, đội ngũ. Bây giờ, chúng ta hãy tiến hành cài đặt.
Thiết lập Môi trường Hội thảo
Một lần nữa, đây sẽ là một buổi hội thảo thực hành. Tốt hơn hết là hãy chuẩn bị sẵn sàng các skill bash của bạn. Đùa thôi, tôi đã có một lệnh wrapper tiện lợi để giúp mọi người. Hy vọng mọi người, hoặc ít nhất là hầu hết các bạn, đã tham gia tổ chức Slack dành cho AI Engineer và cũng đã tham gia kênh còn lại. Tôi đã đặt một liên kết tới đây, nhưng cũng có một mã QR đến kho lưu trữ (repository) mà chúng ta sẽ sử dụng. Tôi sẽ dành vài phút cho việc này. Những điều thực sự quan trọng là đăng ký một tài khoản Brain Trust miễn phí. Nếu bạn sử dụng Gmail, bạn có thể dùng mẹo thêm dấu cộng để tạo tài khoản của mình. Nếu bạn là người dùng Brain Trust hiện có, thì hy vọng điều này sẽ không làm ảnh hưởng đến tài khoản hiện tại của bạn, bạn cũng sẽ cần quyền truy cập vào một Khóa API OpenAI mà bạn có thể dễ dàng tạo. Nếu vì lý do nào đó bạn không thể tạo khóa, vui lòng cho đồng nghiệp của tôi biết. Chúng tôi sẽ có thể gửi và DM cho bạn trên Slack để sử dụng cho buổi học cụ thể này. Và tôi nghĩ, rõ ràng là với tư cách một hội nghị kỹ thuật, đặc biệt là về AI, nếu bạn đang sử dụng hỗ trợ lập trình AI (AI coding assistance), hãy thoải mái sử dụng nó với IDE hoặc trong terminal để được hướng dẫn, đặt câu hỏi về cơ sở mã và những thứ tương tự. Tôi đã cố gắng đơn giản hóa rất nhiều phần khung (scaffolding) hiện có. Vì vậy, tôi đang sử dụng mise để quản lý Node và PNPM trên máy, nhưng bạn cũng có thể tải xuống Node v2-2 ở phiên bản cụ thể đó. Nó sẽ ổn, nhưng một lần nữa, tôi chỉ muốn lưu ý, đặc biệt cho buổi hội thảo này, tôi đã sửa chữa cụ thể đó, có thể nói là một lần. Tôi đang sử dụng make để một lần nữa, một số cú pháp bên ngoài (syntax exterior) để đóng gói các lệnh. Nếu vì lý do nào đó bạn không cài đặt make, nếu bạn đang dùng máy Windows, bạn có thể chỉ cần chạy các lệnh PNPM, đó chỉ là các wrapper cho tệp package.json. Tôi nghe vậy hôm nay. Vì vậy, vâng, chúng tôi sẽ dành vài phút để mọi người quét và clone. Tôi cũng muốn chỉ ra rằng hôm nay tôi có một bản hướng dẫn. Tôi thấy nhiều người đã xem qua, nhưng vâng, chúng tôi cung cấp một hướng dẫn từng bước. Như đã đề cập, khi chúng ta tiến hành buổi hội thảo hôm nay, nếu bạn gặp khó khăn, vui lòng đặt câu hỏi trên kênh Slack, nhưng cũng có thể tham khảo điều này. Như đã đề cập, đây sẽ là một tài nguyên công khai, vì vậy ngay cả khi bạn không tham gia hội thảo này, nếu bạn gặp khó khăn, bạn có thể tự mình xem lại bất cứ lúc nào. Giờ thì, xin cho tôi hỏi: Ai ở đây không thể nhận được Khóa API OpenAI? Hy vọng mọi người có thể cung cấp được nó. Điều này thực sự quan trọng. Vâng. Một số người mới tham gia. Không có mã QR cho Slack. Tôi có thể làm điều đó. Được rồi mọi người, tôi nghĩ chúng ta có một vài người đến muộn, vì vậy tôi sẽ không dành quá nhiều thời gian cho phần này, nhưng nếu bạn tham gia muộn, vui lòng quét mã QR đó để có quyền truy cập vào tổ chức Slack kỹ thuật AI, và sau đó tham gia kênh AI Engineer Europe 2026 Brain Trust Workshop. Đây là một kênh công khai. Thông qua kênh đó, bạn sẽ có thể truy cập vào nội dung được ghim: kho lưu trữ (repository) cũng như một cheat sheet (tài liệu hướng dẫn nhanh), mà chúng ta cũng sẽ theo dõi. Mọi người kiểm tra lại chút nhé. Hy vọng hầu hết các bạn đều có thể tham gia kênh Slack và có thể clone kho lưu trữ và truy cập vào đó. Được rồi.
Xây dựng Tác nhân Phân loại Hỗ trợ Mẫu
Như tôi đã đề cập ngay từ đầu trong chương trình nghị sự, những gì chúng ta sẽ làm là tạo một ví dụ về một tác nhân phân loại hỗ trợ (support triage agent). Hy vọng điều này sẽ minh họa cho nhiều hệ thống mà mọi người có thể đã xây dựng hoặc đang cố gắng xây dựng. Đây là một ứng dụng hư cấu được thiết kế đặc biệt cho buổi hội thảo. Vui lòng không sử dụng nó trong môi trường sản xuất. Mục đích chỉ là để dạy chúng ta cách xây dựng các mô hình AI này và mở rộng quy mô. Vì vậy, ý tưởng là khi một yêu cầu (ticket) được tạo trong hệ thống cụ thể, chúng ta có một tập hợp các tác nhân đi qua một quy trình theo từng giai đoạn (stage process) gọi công cụ (tool calling) để tạo ra một tập hợp thông tin có thể được phát ra cho các hệ thống hạ nguồn (downstream systems) từ góc độ đó. Để giúp hình dung cách hệ thống hoạt động: Một lần nữa, chúng ta nhận đầu vào là một yêu cầu. Chúng ta có bước đầu tiên là thu thập ngữ cảnh (context). Đây là một cách trích xuất thông tin khá xác định. Sau đó, chúng ta tiến hành phần phân loại (triage portion) nơi chúng ta đã chia thành ba giai đoạn. Vì vậy, chúng ta có một Mô hình Ngôn ngữ Lớn (LLM) và các lời gọi công cụ (tool calls) để phân loại vấn đề cụ thể đó. Sau đó, chúng ta muốn có một người đánh giá chính sách (policy reviewer) để đảm bảo đầu ra là chính xác. Sau đó, chúng ta muốn tạo và soạn thảo một câu trả lời cho khách hàng bằng một công cụ viết trả lời (reply writer). Và sau đó chúng ta muốn đóng gói (package) tất cả lại. Và tùy thuộc vào mức độ nghiêm trọng của yêu cầu cụ thể này, chúng ta có thể gọi một công cụ khác để xác định xem chúng ta có cần leo thang vấn đề này cho một người tham gia (human in the loop) hay không, và sau đó soạn thảo kết quả cuối cùng. Vì vậy, một lần nữa, không quá phức tạp, nhưng chỉ để cung cấp cho bạn ý tưởng về hệ thống mà chúng ta sẽ cố gắng xây dựng và vận hành trong buổi học.
Vai trò của Brain Trust trong Triển khai Tác nhân
Một điều cần lưu ý là khi chúng ta bắt đầu sử dụng Brain Trust, vấn đề thực sự là nó phù hợp ở đâu để giúp bạn triển khai và quản lý các tác nhân ở quy mô lớn. Tôi đã cô lập điều này ở đây, nơi mọi thứ chúng ta sẽ làm về cuối, đặc biệt là khi chúng ta tiến hành hoặc theo dõi nó từ đầu đến cuối (end-to-end) như các đồng nghiệp của tôi đã nói. Chúng ta sẽ sử dụng chế độ được quản lý (managed mode) cho lời nhắc, tức là chuyển những gì bạn làm cục bộ vào một môi trường an toàn. Các lời gọi công cụ (tool calls) cũng sẽ được quản lý. Vậy thì, làm thế nào để bạn nói về việc truy cập vào các hệ thống bên ngoài và sau đó hỏi về các đánh giá và điểm số, những thứ sẽ được chạy qua cơ sở hạ tầng Brain Trust của chúng tôi. Cũng cần chỉ ra rằng, nếu bạn truy cập vào kho lưu trữ GitHub, cũng có một phiên bản GitHub Pages của tài liệu này. Vì vậy, các slide sẽ luôn sẵn sàng để bạn sử dụng và xem.
Điều hướng và Điểm kiểm tra Hội thảo
Được rồi, một điều quan trọng nữa là tôi đã cố gắng giúp bạn qua từng giai đoạn và điểm kiểm tra (checkpoint) này. Vì vậy, nếu bạn gặp khó khăn, ý tưởng chỉ là bạn git checkout tới một tag hoặc nhánh cụ thể. Trong trường hợp này, mỗi tag hoặc nhánh riêng lẻ đều có thể chạy được hoàn chỉnh ở giai đoạn đó. Vì vậy, nếu bạn gặp khó khăn lần nữa, hãy git checkout tới nhánh đó, đảm bảo bạn chạy make setup, thực thi các lệnh, và sau đó bạn sẽ nhận được đầu ra gần như giống hệt nhau mỗi lần. Một lần nữa, tất cả điều này đều được ghi lại trong tệp README, nhưng cũng được bao gồm trong cheat sheet (tài liệu hướng dẫn nhanh) để bạn tiến hành.
Lộ trình Hội thảo
Được rồi, vâng, chỉ để cung cấp cho bạn trình tự các sự kiện, chúng ta sẽ thực hiện việc dựng khung (scaffolding) và thiết lập. Tôi sẽ nói về việc xây dựng một tác nhân cơ bản. Một lần nữa, buổi hội thảo này thực sự không được thiết kế để nói về việc xây dựng các tác nhân. Vấn đề là, một khi bạn có một tác nhân, làm thế nào để bạn vận hành (operationalize) nó? Vì vậy, để ngắn gọn, chúng ta sẽ thực hiện từng bước, và sau đó chúng ta sẽ đi vào phần cốt lõi nơi chúng ta sẽ thêm tính năng truy vết (tracing), nói về các đánh giá, bạn biết đấy, nói về tập dữ liệu vàng (golden set) và xác định nơi chúng ta có thể cải thiện. Và sau đó toàn bộ quá trình cùng với nhau, sử dụng cơ sở hạ tầng được quản lý (managed infrastructure) trong Brain Trust để giúp vận hành điều này. Và một lần nữa, nói về sự hợp tác mà các đồng nghiệp của tôi tại Train Line đã nói đến. Một điều quan trọng nữa là, một khi bạn xác định được một lỗi sản xuất (production failure), làm thế nào để chúng ta áp dụng các sửa lỗi và hoàn thành vòng lặp (flywheel) đó để mang lại cho bạn một tài sản hoàn chỉnh (finalized asset).
Bước 1: Xây dựng Tác nhân Cơ bản
Được rồi, vậy thì bước một, chúng ta sẽ nói về việc xây dựng tác nhân. Vì vậy, ở điểm kiểm tra này, một lần nữa, chúng ta cần bắt đầu từ một nơi nào đó, phải không? Vậy chúng ta làm gì? Chúng ta sẽ thực hiện một cuộc gọi ban đầu đến một Mô hình Ngôn ngữ Lớn (LLM), chúng ta sẽ thiết lập một lời nhắc (một lượt hỏi-đáp, một đầu vào, một đầu ra) và nhận được một đầu ra. Vì vậy, một lần nữa, nếu bạn đang thực hiện một bằng chứng khái niệm (proof of concept), điều này có thể rất tuyệt như một phần của sự khởi đầu ban đầu, nhưng một lần nữa, chúng ta biết rằng còn rất nhiều việc phải làm. Nhưng vâng, đối với ngữ cảnh, chúng ta sẽ chỉ đi qua điều này. Nhưng như tôi đã đề cập, chỉ vì nó hoạt động trong bản demo không có nghĩa là nó đã có thể hoạt động trong môi trường sản xuất. Tôi đã đặt một số mã giả (pseudocode) ở đây để trình bày rõ hơn, nhưng bạn có thể thấy ở đây, với tất cả các mô hình ngôn ngữ này, chúng ta cung cấp một tập hợp lời nhắc trợ lý, chúng ta cung cấp người dùng, và đặc biệt là văn bản, và chúng ta chuyển đầu ra của nó trở lại ứng dụng của mình. Vì vậy, một hàm, một lời gọi mô hình, chúng ta có đầu ra có cấu trúc (structured output) mà chúng ta muốn nhận làm một phần của đầu ra. Vì vậy, những gì chúng ta sẽ làm là, khi chúng ta thực hiện việc dựng khung (scaffolding) và checkout sang nhánh đầu tiên, chúng ta sẽ nhận được một tập hợp các yêu cầu mẫu, vì vậy đây là một trường hợp đã được thực hiện trong mã, hoặc bạn có thể sử dụng giao diện dòng lệnh (command line), vì vậy tôi sẽ trình bày ngắn gọn về cách nó sẽ trông như thế nào với các đầu ra, và bạn sẽ nhận được một cái gì đó tương tự ở định dạng JSON. Hy vọng mọi người có thể thấy điều này vào lúc này. Tôi có ứng dụng ở đây. Vì vậy, tôi sẽ chỉ đi đến basic checkout. Tôi sẽ kiểm tra nó. Và đây là gì? Vậy thì, nếu tôi xem xét ở đây, tôi hiện đã checkout sang nhánh đầu tiên đó, đó là việc xây dựng tác nhân cơ bản. Tôi có ứng dụng ở đây, một lần nữa rất giống với mã lời nhắc. Chúng ta đang tạo một máy khách, gọi OpenAI SDK. Một lần nữa, để ngắn gọn, tôi không sử dụng bất kỳ SDK tác nhân nào, nhưng chúng tôi hoàn toàn hỗ trợ điều đó khi chúng ta tiến hành buổi hội thảo. Vì vậy, điều này thực sự có sẵn, và bạn sẽ thấy một lần nữa từ Makefile, nếu bạn không cài đặt make, thì bạn chỉ có thể thực thi các script PNPM, hoặc tôi không biết nếu bạn sử dụng NPM hoặc Yarn. Điều đó cũng có thể. Tôi chưa kiểm tra nó, nhưng việc tìm hiểu sẽ hoạt động vì nó chỉ sử dụng tệp package.json. Vì vậy, trong trường hợp này, giả sử bạn muốn làm điều gì đó như make tickets. Vì vậy, tôi muốn đưa ra một thứ, nói rằng, 'mật khẩu của tôi cần được đặt lại.' Trong trường hợp này, tôi đã cung cấp một số giá trị mặc định, một số enter, enter, enter. Và bây giờ nó chỉ đang thực hiện một cuộc gọi đến OpenAI. Tôi chỉ đang sử dụng, bạn có thể sẽ thấy từ tệp biến môi trường, tôi đang sử dụng GPT-5 Mini. Bạn có thể thay đổi nó nếu muốn, nhưng với mục đích này, chúng ta sẽ giữ nó đơn giản. Vì vậy, bạn có thể thấy ở đây, tôi có yêu cầu, và nó cũng đã cung cấp một số đầu ra ở đây. Nhưng một lần nữa, đó là một lượt hỏi-đáp duy nhất. Tôi nghĩ chúng ta đã, tôi đang gặp một số vấn đề. Vì vậy, bạn biết đấy, dựa trên đầu ra này, nó trông khá hợp lý, nhưng một lần nữa, nó sẽ không giải quyết được nhiều trường hợp biên (edge cases) mà chúng ta muốn, đặc biệt nếu bạn có nhiều sắc thái mới cho tổ chức mà chúng ta đang cố gắng xây dựng thành logic ở đây. Tôi đang đi vào những thứ như make demo. Vì vậy, make demo, nếu bạn muốn viết script, nó cũng vậy. Tôi chỉ đang gọi cùng một hàm, nhưng tôi đã mã hóa nó dưới dạng JSON ở đây. Vì vậy, các trường JSON có sẵn để xem. Khá đơn giản. Tôi không muốn đi sâu vào đó quá nhiều.
Thêm các Công cụ để Nâng cao Khả năng Xác định
Vậy thì, điều tiếp theo tôi muốn làm là nói về việc thêm các công cụ ghi nhật ký tài khoản (account log tools). Vì vậy, chúng ta có thể muốn nói rằng, 'hãy cố gắng làm cho điều này trở nên xác định hơn một chút.' Ngay cả khi một lời nhắc có thể được cấu trúc rất tốt, tôi có thể muốn đưa vào các cách hoạt động khác nhau. Vì vậy, trong trường hợp này, tôi đang gọi ba công cụ khác nhau để xem các bài viết help desk liên quan. Sẽ có cả bài viết nội bộ và bên ngoài. Tôi có thể muốn xem xét một số điều đã xảy ra với các tài khoản. Vì vậy, theo cách tương tự, tôi đang tùy chỉnh; tôi đã thực hiện một cuộc di chuyển nhất định, và điều đó có thể có tác động đến các hệ thống backend. Và có lẽ có một lý do mà tôi muốn tạo một sự leo thang ở đây. Trong trường hợp này, những gì tôi đã làm là tôi đã làm cho nó trở nên xác định hơn một chút. Với mục đích của buổi hội thảo này, một lần nữa, điều này được coi là mã, nhưng trên thực tế, bạn có thể sẽ giao tiếp với các hệ thống bên ngoài như một tìm kiếm vector (vector search), MCPC, CLI, và tất cả các loại giao diện để xây dựng khả năng này. Và một lần nữa, điều quan trọng ở đây là bạn càng thêm nhiều công cụ, số lượng cách bạn có thể thất bại cũng sẽ tăng lên.
Giới thiệu về Tracing và Local Tools
Vì vậy, một lần nữa, đây là lý do tại sao tracing (theo dõi), khi chúng ta bắt đầu, sẽ trở nên quan trọng hơn. Vậy là có một cái ở đây. Một lần nữa, hãy tham khảo readme ở đây. Điều tiếp theo chúng ta sẽ làm là đi tới các công cụ cục bộ. Trong trường hợp này, các công cụ mà tôi đã tạo sau đó sẽ có sẵn ở đây. Nhưng một lần nữa, chúng chỉ được đưa vào như code để đơn giản hóa. Và một lần nữa, tôi có thể làm điều tương tự, bạn tạo một ticket (yêu cầu), nói rằng "cần đặt lại mật khẩu, tài khoản bị khóa". Được rồi. Giờ thì, nó đã cung cấp thêm một chút thông tin. Bạn có thể thấy nó chi tiết hơn một chút vì chúng ta đã đưa các lệnh gọi công cụ vào đây và cung cấp thêm ngữ cảnh cho Mô hình Ngôn ngữ Lớn (LLM).
Cũng cần lưu ý ở đây: nếu bạn cảm thấy bế tắc, nhiều phần trong số này hoạt động. Các tag của các nhánh workshop được xây dựng tuần tự. Vì vậy, nếu bạn truy cập vào, giả sử, git tag số sáu, nó sẽ bao gồm mọi thứ trong đó. Đừng cảm thấy bạn phải đi qua từng cái một. Nếu bạn cảm thấy bế tắc và muốn bỏ qua, bạn cũng có thể làm vậy. Được rồi, công cụ. Một lần nữa, tôi đã thực sự trình bày code rồi. Đây là một ý tưởng về mã giả sẽ trông như thế nào.
Quy trình làm việc theo giai đoạn (Stages) với Mô hình Ngôn ngữ Lớn (LLM)
Các giai đoạn. Tôi nghĩ đây là điều tiếp theo, một lần nữa, chúng ta đang chia nhỏ lệnh gọi nguyên khối từ Mô hình Ngôn ngữ Lớn (LLM). Chúng ta hiện đang giới thiệu các công cụ, và điều tiếp theo là đi sâu hơn nữa vào các giai đoạn đặc biệt về cách Mô hình Ngôn ngữ Lớn (LLM) nên hành xử. Bạn có thể đã thấy từ sơ đồ trình tự đó, nơi tôi đã thực hiện hiệu quả năm giai đoạn cho việc này: thiết lập các thứ để thu thập ngữ cảnh, phân loại, xác định xem nó có đáp ứng các chính sách thương hiệu hay không, cung cấp một câu trả lời thân thiện với khách hàng, và cũng có một phần nội bộ cho các hệ thống của chúng tôi, sau đó hoàn thiện kết quả cho các hệ thống hạ nguồn.
Một lần nữa, điều này chỉ xuất phát từ kỹ thuật phần mềm truyền thống. Bạn chia nhỏ vấn đề của mình, bạn có thể thấy chính xác nơi nào đang gặp sự cố trên stack (ngăn xếp), và bạn sẽ có thể khắc phục. Vì vậy, một lần nữa, nếu có thể, hãy cố gắng tường minh hơn và chia nhỏ nó thành các thách thức mà bạn có thể giải quyết. Vâng, chỉ là một chút mã giả. Đây là hình dung về nó sẽ trông như thế nào. Bạn có lẽ sẽ đặt một trình gỡ lỗi với một ID mới và xem xét điều đó. Được rồi, tôi đã thực hiện một phần của điều này, nhưng chúng ta đã bắt đầu với điểm khởi đầu, và sau đó tôi sẽ nói về việc thực hiện giai đoạn đặc biệt ở đây. Hãy cùng xem phần tiếp theo của readme về các giai đoạn đặc biệt.
Ví dụ về xử lý ticket và Tác nhân đa giai đoạn
Nếu tôi xem xét bây giờ, thư mục nguồn có các hàm riêng lẻ đã được tách ra. Các lời nhắc liên quan đến đó đang được sử dụng. Vì vậy, giả sử đây là một phân loại từ những gì chúng ta đang sử dụng. Nếu tôi đi xuống ứng dụng, bạn có thể thấy nó bắt đầu ở đây. Tôi đang sử dụng các hàm đồng bộ để thực thi. Tương tự như vậy, nếu tôi làm điều gì đó như, bạn biết đấy, hãy lấy nó, có lẽ tôi sẽ làm điều gì đó khác biệt. Một vấn đề cổ điển khác là gì? Ví dụ, "tôi cần nâng cấp gói của mình từ Pro lên Enterprise, nhưng trang web không hoạt động, gặp lỗi $800".
Trong trường hợp này, tôi đang ở cấp khách hàng thứ hai. Chúng ta đang nói về việc thanh toán ở đây và bộ đếm của tôi thực sự đang ở cột ba. Chỉ để cho bạn thấy, điều này là trực tiếp; nó không phải là thứ được mã hóa cứng trong hệ thống. Điều đáng chú ý nữa là giai đoạn này hơi chậm vì chúng ta đã chia nhỏ từng Mô hình Ngôn ngữ Lớn (LLM) một lần thành các lời gọi tuần tự. Vì vậy, dự kiến sẽ mất nhiều thời gian hơn một chút, nhưng một lần nữa, đó là một phần của việc xây dựng luồng ngữ nghĩa. Và bây giờ bạn có thể thấy, nó lại chi tiết hơn một chút, nhưng có nhiều suy nghĩ hơn được đưa vào tác nhân này.
Vì vậy, tôi đoán bạn có thể thấy một lần nữa, chúng ta đã nói về một vấn đề thanh toán. Bạn có thể thấy rằng nó tin rằng mức độ khẩn cấp khá cao vì khách hàng muốn nâng cấp từ một cấp khác, nhưng rõ ràng có tác động đến doanh thu. Vì vậy, trong trường hợp này, chúng ta nên leo thang (chuyển giao) cho những người thích hợp ở phía chúng tôi. Bạn có thể thấy ở đây quy trình leo thang thường nên như thế nào, và cả phản hồi nội bộ và phản hồi cho khách hàng cũng được cung cấp. Chúng tôi đã đưa vào một điểm tin cậy để nói rằng, bạn biết đấy, nếu đây là vấn đề thực sự, nhưng một lần nữa, như đã đề cập, các lệnh gọi công cụ sẽ có thể lấy thông tin từ các hệ thống khác nhau để cung cấp mức độ tin cậy cao hơn. Hoàn hảo.
Tracing và Khả năng Quan sát của Tác nhân
Được rồi, với điều đó trong tâm trí. Vì vậy, một lần nữa, chúng tôi hy vọng đã cho thấy cách chúng ta có thể xây dựng và lấy một tác nhân, chia nhỏ nó, xây dựng một cái gì đó đa giai đoạn, giới thiệu việc gọi công cụ để cung cấp cho chúng ta những gì chúng ta cần. Điều tiếp theo là cung cấp thông tin đó và bắt đầu tracing (theo dõi) nó, để chúng ta thực sự có thể thấy điều gì đang xảy ra đến từng chi tiết riêng lẻ. Và đây là lúc phần khả năng quan sát (observability) phát huy tác dụng.
Vì vậy, những gì chúng ta sẽ làm trong phần này là phân tích toàn bộ đường dẫn thực thi. Chúng ta biết rằng cấu trúc này rất lồng ghép. Vì vậy, có các lệnh gọi công cụ và có thêm các lệnh gọi hàm đằng sau chúng. Chúng ta muốn theo dõi một số điều quan trọng. Và tôi nghĩ đồng nghiệp của tôi đã chỉ ra những khó khăn ban đầu mà họ gặp phải khi nói về độ trễ, chi phí, số lượng mã thông báo, đặc biệt là thời gian cho mã thông báo đầu tiên, đó là một số liệu/thước đo rất quan trọng mà chúng ta thấy nhiều khách hàng của mình đang cố gắng xác định.
Ngoài ra, đầu vào là gì, đầu ra là gì và siêu dữ liệu liên quan đến điều này? Và sau đó, bao gồm các loại trường bổ sung để, một lần nữa, khi chúng ta nói về giám sát và khả năng quan sát (observability), chúng ta có thể truy vấn nó trong giao diện người dùng (UI) ngay lập tức và thiết lập cảnh báo khi cần. Vì vậy, một lần nữa, có một đầu ra là không đủ. Chúng ta cần hiểu toàn bộ đường dẫn thực thi, và đó là những gì tracing (theo dõi) cho phép chúng ta làm.
Cài đặt Tracing và Bộ công cụ phát triển phần mềm (SDK) đa ngôn ngữ
Vâng, chỉ để cung cấp cho bạn một ý tưởng về ngữ cảnh. Tôi biết đây là một chủ đề khá gây tranh cãi đối với một số người vì, một lần nữa, tôi đến từ nền tảng phát triển full-stack. Vì vậy, nó bao gồm cả Python, Go cũng như TypeScript. Bộ công cụ phát triển phần mềm (SDK) của chúng tôi là đa ngôn ngữ: Ruby, Go, tôi nghĩ thậm chí cả .NET, chúng tôi có một số người đang sử dụng nó. Và điều đó đều tốt. Nhưng vâng, tôi chỉ giữ TypeScript để đơn giản hóa ở đây hôm nay. Nhưng, vâng, các Bộ công cụ phát triển phần mềm (SDK) thực sự hỗ trợ một loạt các ngôn ngữ khác nhau mà bạn có thể bắt đầu tracing (theo dõi) ứng dụng của mình.
Tracing các Tác nhân đa lượt và cấu trúc lồng ghép
Vì vậy, vâng, một điều thực sự quan trọng ở đây và là một trong những thách thức mà tôi thấy ở khách hàng của chúng tôi, nói chung, là họ sẽ thực hiện một tương tác riêng lẻ đối với một parent span (khoảng thời gian gốc) duy nhất. Và điều này thậm chí áp dụng cho công việc của tôi với, giả sử, các tác nhân đa lượt, đa hội thoại. Điều chúng tôi muốn có thể làm là trace (theo dõi) điều đó thành một cấu trúc lồng ghép để bạn có thể thấy mọi thứ trong một tương tác, giả sử một cuộc hội thoại, trong một parent span. Vì vậy, điều thực sự quan trọng khi chúng ta bắt đầu instrumenting (đo lường) ứng dụng của mình là đảm bảo rằng chúng ta đang có các cấu trúc phù hợp. Nếu không, bạn sẽ không thể thấy toàn bộ tác động của việc mọi thứ có thể sai ở đâu trong ứng dụng của mình.
Một lần nữa, điều này chỉ là đọc trace (dấu vết). Hy vọng rằng, mọi người, đặc biệt là các kỹ sư phần mềm trong phòng đang sử dụng các công cụ khả năng quan sát (observability) truyền thống ngoài kia, sẽ thấy điều này không quá khác biệt. Nhưng đối với những người có thể mới làm quen với màn hình này, một trace chỉ cho phép chúng ta tìm ra không chỉ những gì đã xảy ra mà còn cả những gì đang xảy ra với ứng dụng của bạn trong thời gian thực. Vì vậy, một lần nữa, theo dõi mọi lệnh gọi, mang theo siêu dữ liệu đó, và tùy thuộc vào nơi chế độ lỗi xảy ra, chúng ta có thể xác định lộ trình khắc phục mà chúng ta cần thực hiện. Được chứ?
Thực hiện Tracing với Brain Trust
Vì vậy, ở giai đoạn tiếp theo, chúng ta sẽ thêm tracing (theo dõi) vào đây. Và sau đó chúng ta thực sự sẽ chạy nó và đi vào Brain Trust và hy vọng chúng ta sẽ thấy nó xảy ra. Nhưng có một điều tôi muốn ghi nhớ trước khi làm điều đó. Hãy xem readme của chúng ta. Nó bảo chúng ta trace (theo dõi) nó. Được rồi, bây giờ chúng ta đã sẵn sàng. Vậy là tôi đã giới thiệu một tập lệnh hỗ trợ ở đây gọi là tracing.
Vì vậy, điều chúng tôi làm khá tốt trong Bộ công cụ phát triển phần mềm (SDK) của mình là, một lần nữa, chúng tôi không muốn giới thiệu thêm độ phức tạp ở những nơi không cần thiết. Vì vậy, nếu bạn đang sử dụng Bộ công cụ phát triển phần mềm (SDK) của nhà cung cấp Mô hình Ngôn ngữ Lớn (LLM) tiêu chuẩn, bạn có thể đơn giản wrap (bọc) hàm đó. Chúng tôi cung cấp điều đó out of the box (ngay lập tức). Nhưng sau đó, khi nói đến các lệnh gọi riêng lẻ, một lần nữa, chúng tôi có thể thiết lập một số tập lệnh hỗ trợ ở đây để giúp wrap up (tổng hợp) khi cần. Nếu bạn đang sử dụng một cái gì đó như Python, thì bạn cũng có thể có một hàm decorator (hàm trang trí) cũng hữu ích. Trong trường hợp này, tôi có một hàm nhỏ hay ho giúp với parent (cha) và child (con).
Và sau đó, khi nói đến việc tracing (theo dõi) ứng dụng thực tế, bạn có thể thấy ở đây, tôi có một child span (khoảng thời gian con) đã được thực thi trong suốt quá trình này. Một lần nữa, tôi không muốn thực sự code (viết mã) điều này vào thời điểm này vì code đang mở rộng khá nhiều. Nhưng vâng, tôi chỉ muốn đi qua các khái niệm chính cho điều này. Được rồi, trước khi tôi chạy ứng dụng, tôi muốn vào giao diện người dùng (UI) của Brain Trust. Đôi khi nó có thể tạo ra một dự án thử nghiệm nếu bạn đã đăng ký tài khoản dùng thử miễn phí, vì vậy hy vọng bạn đã làm điều đó sớm hơn hôm nay. Nó sẽ tạo ra một dự án mới khi chúng ta thực thi điều này.
Một điều thực sự quan trọng nữa: nếu bạn chưa làm, hãy đi tới hồ sơ của bạn ở góc trên bên trái. Được rồi, để tôi tạo một cái. Vậy thì, bây giờ, hãy vào hồ sơ của bạn. Sau đó, nơi có chữ 'Khóa API', nhập tên của bạn cho khóa, tạo nó, và sau đó sử dụng nó trong môi trường của bạn, tệp .ENV của bạn, hoặc bảo mật nó trong một kho khóa nếu bạn đã có. Ngoài ra còn có khóa OpenAI mà chúng tôi hy vọng bạn đã tạo. Điều đó cũng nên được sử dụng trong các nhà cung cấp AI. Tôi đã đặt cái này ở cấp tổ chức. Bạn cũng có thể làm điều này cho mỗi dự án, tùy thuộc vào việc bạn muốn phân chia nó theo một nhóm hoặc môi trường cụ thể; điều đó cũng được hỗ trợ đầy đủ. Nhưng trong trường hợp này, chúng ta sẽ cần khóa này sau này khi nói đến chấm điểm được quản lý và trực tuyến.
Chỉ một chút thông tin bên lề: khóa mà bạn đã tạo, hãy đảm bảo bạn đặt nó vào tổ chức Brain Trust của bạn ở đây để sử dụng sau này.
Giám sát thực thi Tác nhân trong Brain Trust UI
Được rồi, với điều đó trong tâm trí, tôi sẽ chạy demo. Và chỉ để tham khảo, nếu bạn bị kẹt, bạn chỉ cần sử dụng make setup để đảm bảo mọi thứ đã sẵn sàng. Và trong trường hợp này, chúng ta muốn thực hiện make demo. Tôi sẽ chỉ chạy các ticket tiếp theo. Tôi giữ các ticket đó. Tôi thậm chí có thể làm điều đó bằng cách sử dụng lệnh make ticket.
Vì vậy, trong khi nó đang chạy ngầm, nếu bạn quay lại vị trí của mình, bạn sẽ thấy có một dự án gọi là helper workshop. Đó là dự án sẽ được tạo ra như một phần của workshop này hôm nay. Nếu bạn điều hướng đến tab nhật ký, bạn sẽ bắt đầu thấy điều này xuất hiện trong thời gian thực. Điều đáng chú ý, một lần nữa, nhờ vào các khả năng của chúng tôi trong Brain Trust, chúng tôi có khả năng ghi gần như tức thì vào hệ thống và đọc có sẵn ngay sau đó. Đặc biệt, nó là một hàm chặn dài.
Vì vậy, rất nhiều khách hàng của chúng tôi, đặc biệt là những người phức tạp hơn, thực sự đang sử dụng Brain Trust ở quy mô lớn và thực sự thúc đẩy giới hạn. Vì vậy, không phải trường hợp 'tôi có hàng nghìn trace (dấu vết)'. Họ đang đẩy hàng chục triệu trace cùng một lúc, trong một khoảng thời gian rất ngắn, và họ muốn có thể tổng hợp điều này. Và một lần nữa, khi bạn xây dựng sự phức tạp hơn trong ứng dụng của mình, bạn đang gửi điều này đến nhiều người dùng hơn, điều đó sẽ phát triển khá nhanh chóng, và bạn cần có một hệ thống có thể xử lý quy mô đó.
Vì vậy, khi bạn bắt đầu thấy các nhật ký xuất hiện (chúng xuất hiện theo thứ tự ngược lại), tôi sẽ xem xét cái đầu tiên ở đây và chúng ta sẽ bắt đầu thấy quá trình đo lường được trace (theo dõi). Có một nút đặc biệt ở đây cho phép bạn xem điều này ở chế độ toàn màn hình, điều mà tôi nghĩ là khá hữu ích. Như tôi đã đề cập, vì chúng ta có cấu trúc lồng ghép tại chỗ, nơi chúng ta đi qua từng nút theo kiểu cây, tương tác này ở trên cùng là demo ticket. Ở cấp độ cao nhất, chúng ta thấy rằng một lời gọi Mô hình Ngôn ngữ Lớn (LLM) đã diễn ra, cùng với các tài liệu lời nhắc, chi phí đầu vào/đầu ra, và độ trễ liên quan đến nó.
Khả năng Quan sát và Dòng thời gian
Tôi cũng đã bao gồm một số metadata vì tôi muốn có thể trích xuất và lọc chúng khi cần, và tôi sẽ chỉ cho bạn cách hoạt động. Mọi thứ đều có sẵn ở đây để xem. Metadata có ở đó. Nếu tôi muốn xem xét vấn đề này theo một cách khác, chúng ta thậm chí có thể xem xét từng bước riêng lẻ. Ví dụ, tôi muốn xem điều gì đã xảy ra với các chuyên gia nghệ thuật cây xuống đến việc gọi thực tế tới Hollumn. Vì vậy, một lần nữa, SDK cung cấp rất nhiều sự linh hoạt xung quanh việc này để bạn có thể thấy những gì đã được đưa vào, lý do đằng sau nó, và thông tin mà chúng ta đã thiết lập cho nó. Và rồi, đến phần cuối cùng, liệu nó có nên được leo thang (escalate) hay không. Một trong những chế độ xem mà chúng ta sẽ thấy là một phần của điều này là việc xem xét dòng thời gian (timeline). Điều này mang lại cho bạn ý tưởng về một phương pháp thác nước (waterfall methodology) để xem liệu một bước cụ thể nào đó có đang mất nhiều thời gian hơn không. Chúng ta có cần khắc phục không? Điều đó là không thể thực hiện được. Được rồi. Vậy, nếu tôi xem trang logs, tôi có thể thu thập, làm mới, một cái gì đó như bốn ticket đã được đẩy. Vâng, điều này sẽ xuất hiện ngay bây giờ. Vâng, đó là hai ticket tại thời điểm này. Vì vậy, một lần nữa, thông tin tương tự mà chúng ta đã hiển thị cũng có sẵn trong console. Vâng, chúng ta đã đề cập đến tracing.
Đánh giá Hiệu suất Hệ thống AI
Hãy nói về phần đánh giá (evaluation) cho vấn đề này. Điều này khá thú vị, một lần nữa, tùy thuộc vào vị trí của bạn trong hành trình hoặc việc xây dựng ứng dụng này. Nhiều khách hàng đã xây dựng một ứng dụng, đã có sẵn, kiểu như các Mô hình Ngôn ngữ Lớn (LLM) đã được tích hợp. Nhưng điều gì sẽ xảy ra khi bạn gặp phải vấn đề khởi động lạnh (cold start) mà bạn không biết mình đang xây dựng cái gì? Vậy, "tốt" trông như thế nào? Và, trên thực tế, "tốt" có nghĩa gì đối với tôi? Trong trường hợp ứng dụng hỗ trợ mà chúng ta đang phát triển hôm nay, kiểu như trong các điểm có thể thương lượng hơn, cách chúng ta phân loại trường hợp hỗ trợ, cách chúng ta đảm bảo không có kết quả nghiêm trọng hoặc ít nghiêm trọng cho những vấn đề đang gây tắc nghẽn này. Liệu việc leo thang (escalation) có tuân thủ chính sách với các SLA (Thỏa thuận mức dịch vụ) không? Cấu trúc có vẻ ổn không? Và nếu chúng ta thực hiện bất kỳ thay đổi cụ thể nào, liệu nó có thực sự cải thiện cách chúng ta nhìn nhận mà không làm hỏng hoặc gây hồi quy (regression) cho ứng dụng không? Chúng ta có thể làm điều này bằng cách sử dụng đánh giá. Vì vậy, một đánh giá (evaluation), đối với những người (hy vọng nhiều người đã biết chúng là gì), nhưng đối với những người trong phòng, hãy nghĩ về nó như một cách mà bạn có tập dữ liệu (data set) của mình, đầu vào của bạn, bạn có một nhiệm vụ, và sau đó bạn có một kết quả mà bạn muốn đánh giá hoặc một hàm chấm điểm (scoring function). Và điều này hơi khác một chút so với phát triển phần mềm truyền thống khi làm việc với các hệ thống AI vì tính chất phi xác định (non-deterministic) của chúng. Vì vậy, trong phần cụ thể này, điều tôi sẽ nói ở đây là tạo ra cái mà chúng ta gọi là tập dữ liệu vàng (golden data set). Vì vậy, trong ứng dụng hỗ trợ này, tôi sẽ thử nghiệm một cách giai thoại (anecdotally), nhưng tôi muốn tạo ra một tập hợp các trường hợp biên (edge cases) mà tôi nghĩ rằng điều này thực sự sẽ giúp mang lại cho chúng ta ít nhất một mức độ tự tin ban đầu cho doanh nghiệp rằng những gì chúng ta đang phát hành vào sản phẩm (production) là có mục đích. Luôn có chỗ để cải thiện, nhưng không phải là tôi chỉ phát hành ứng dụng này dựa trên cảm tính. Tôi có một cách cụ thể để nói, được rồi, đây là cách nó hoạt động theo thời gian. Để làm điều này, một lần nữa, chúng ta sử dụng hai loại hàm chấm điểm chính. Loại đầu tiên là xác định (deterministic). Vì vậy, tôi nghĩ nhiều người đã bắt đầu sử dụng loại này, một lần nữa, đến từ kỹ thuật phần mềm truyền thống, bạn biết đấy, kiểm thử đơn vị (unit tests). Bạn sẽ không nói là tương tự, nhưng chúng khá giống nhau về bản chất, nơi chúng rất dễ chạy, hiệu quả về chi phí, bạn thực sự không sử dụng một mô hình (model) tại thời điểm này. Loại thứ hai, tinh vi hơn một chút, là sử dụng một Mô hình Ngôn ngữ Lớn (LLM) làm trọng tài (judge), tức là một hệ thống AI khác. Và điều này thực sự hữu ích khi nói đến các hệ thống có sắc thái (nuance), điều mà không thể thực sự được xác định chỉ bằng các hệ thống xác định. Vì vậy, một lần nữa, việc tạo ra phong cách thương hiệu chỉ là đáp ứng sự hài lòng của khách hàng v.v. Vì vậy, điều quan trọng nhất là nếu bạn không thể viết nó theo cách xác định, bạn muốn sử dụng LLM làm trọng tài bất cứ khi nào có thể. Và tại sao điều này lại quan trọng hơn, một lần nữa, nó chỉ là để đảm bảo rằng bất kỳ thay đổi nào chúng ta thực hiện đều là một thay đổi an toàn khi chúng ta tiến hành điều này.
Tải lên và Chạy Đánh giá
Được rồi. Vậy, tôi sẽ chuyển sang ý tưởng đó một lần nữa. Hãy xem tệp readme. Và sau đó chúng ta sẽ làm, tên từ điển là gì? Bạn có thể vào C, được rồi. Và sau đó liệt kê ở đây. Sau đó make demo, à, make setup, chúng ta sẽ ổn thôi. Được rồi. Vậy, một điều tôi muốn bạn làm nữa là chạy lệnh C dataset, vì vậy chúng ta thực hiện make C dataset. Được rồi. Vậy, điều này sẽ tải lên các trường hợp kiểm thử đánh giá của chúng ta vào Giao diện người dùng (UI) của BrainTrust. Vì vậy, nếu tôi chuyển sang các tập dữ liệu của mình bây giờ, bạn sẽ thấy nó được gọi là helper.seed_dataset. Một lần nữa, chỉ để đơn giản hóa việc tạo 10 đầu vào, tôi cũng đã phân loại chúng. Vì vậy, đầu vào sẽ mong đợi một số metadata liên quan đến nó. Đó là cấu trúc cốt lõi để tạo một đánh giá. Vì vậy, là một phần của điều này, và cả xác định và phi xác định, tôi đã tạo một số hàm chấm điểm sẽ được sử dụng như một phần của điều này. Vì vậy, nó có sẵn ở đây, và sau đó là các hàm chấm điểm. Vì vậy, một lần nữa, kiểm tra danh mục như một schema tại chỗ là một lý do leo thang khi cần, một lần nữa, rất dễ chạy và mã hóa. Vâng, chúng ta có sự tinh vi hơn với tiêu chí khách hàng (customer rubric), vì vậy đây là trường hợp sử dụng LLM làm trọng tài nhiều hơn ở đây. Được rồi. Và sau đó chúng ta có thể quay lại readme. Vì vậy, chúng ta không cần phải làm demo, chúng ta đã đẩy nó qua rồi. Hãy tiếp tục và sau đó thực hiện make eval. Vì vậy, điều này sau đó sẽ chạy một đánh giá, và như tôi nghe, dữ liệu ban đầu (seed data) cũng vậy, một lần nữa, không cần thiết, tôi phải đưa nó vào mã nguồn, nhưng cho dù nó đến từ một cơ sở dữ liệu, trong trường hợp này, tôi chỉ sử dụng một tệp JSON phẳng cho điều này, chỉ để cung cấp cho bạn một số ngữ cảnh. Vì vậy, khi chạy đánh giá này, chúng ta sẽ có, nếu chúng ta vào UI, một nơi cho các thử nghiệm (experiments), vì vậy tôi sẽ bắt đầu kiểm tra ở đây. Vâng, thử nghiệm đó đã chạy, một lần nữa, lưu trữ các JSON liên quan đến nó. Vì vậy, bạn sẽ nhận được một đầu ra như terminal Silesian, nhưng nếu chúng ta quay lại UI, một lần nữa, chúng ta bắt đầu theo dõi ứng dụng của mình dựa trên đầu vào và đầu ra cho tập dữ liệu cụ thể này. Khá giống với tracing mà chúng ta đã thấy từ các trace trực tuyến, bạn sẽ thấy rất tương tự ở đây, và xem cách nó hoạt động trong suốt quá trình thử nghiệm của bạn. Và tôi nghĩ rằng, khi chúng ta tiến bộ với workshop, chúng ta sẽ bắt đầu thấy cách chúng ta cải thiện nó bằng cách sử dụng các hàm khác nhau và theo dõi điều đó trên UI. Nếu bạn cần thêm không gian hiển thị (real estate) nữa, bạn cũng có thể thu gọn menu, điều này cũng hữu ích.
Chuyển từ Môi trường Cục bộ sang Quản lý
Được rồi. Hãy tiếp tục với điểm kiểm tra (checkpoint) tiếp theo, xoay quanh việc triển khai và quản lý vấn đề này. Như tôi đã đề cập, tôi nghĩ rằng nhiều người, ít nhất là (và hy vọng khi tôi thấy điều này với các khách hàng phổ biến), lại nói rằng "mọi thứ sẽ hoạt động tốt trên máy của tôi." Được rồi, bây giờ đưa điều đó vào mã nguồn. Tôi muốn đưa điều này vào một nơi mà tôi có thể bắt đầu cộng tác (collaborate) tốt hơn một chút. Nó nằm ở một điểm tham chiếu. Tôi có một phiên bản trong lịch sử. Bạn có thể bắt đầu xác định, một lần nữa, ai đã thực hiện thay đổi gì? Và bạn cần một cách để tập hợp những người dùng này lại với nhau. Vì vậy, tôi nghĩ rằng khách hàng đã nói về cộng tác. Điều thú vị nữa là, một lần nữa, việc thay đổi lời nhắc trên máy của bạn và sau đó cố gắng chuyển mã nguồn đó đến một kho lưu trữ, và sau đó có thể ai đó, ví dụ như một quản lý sản phẩm SME không chuyên về kỹ thuật, có lẽ, họ muốn cập nhật các lời nhắc. Họ không thể làm được. Họ phải nhờ bạn giúp đỡ. Có lẽ điều đó đã xảy ra với một số người trong phòng hôm nay. Tôi biết điều đó đã xảy ra với tôi vài lần trước đây. Và điều đó có thể bắt đầu trở nên thực sự khó chịu. Vì vậy, chúng tôi thực sự chỉ muốn một cách để có thể tập hợp điều đó lại với nhau. Một điều thực sự quan trọng, đặc biệt đối với những người làm việc trong các ngành công nghiệp được quản lý chặt chẽ. Ví dụ, khả năng tái sản xuất (reproducibility) là một điều rất quan trọng. Và tôi đã làm việc trong, bạn biết đấy, hơn một thập kỷ trong cả ngân hàng và thị trường vốn. Tôi biết rõ ràng với quy định hiện hành, đặc biệt là những thứ như quyền được lãng quên, việc hiểu ai đã thực hiện một thay đổi, đặc biệt trong một kịch bản thoát hiểm căng thẳng. Làm thế nào chúng ta có thể đưa điều này vào một hệ thống mới? Điều này thực sự quan trọng để giúp mở khóa điều đó. Và điều thú vị khi nói đến việc xác định các thay đổi trước khi bạn làm điều đó. Vì vậy, một lần nữa, chúng ta không muốn chỉ thực hiện các thay đổi, đẩy ra sản phẩm và hỏi chúng ta điều gì đã xảy ra. Chúng ta cần phải có khả năng thiết lập điều đó. Và đối với chúng tôi, một lần nữa, chúng tôi đang giới thiệu một số khả năng mới. Vì vậy, những gì bạn đang chạy hiện tại, bạn đã chạy các công cụ, bạn đã chạy các lời nhắc, mọi thứ trên máy cục bộ của bạn. Điều chúng tôi muốn làm là chuyển giao (offload) khả năng đó vào BrainTrust. Vì vậy, khi ứng dụng của bạn đang chạy trong môi trường bảo mật, nó có thể tham chiếu đến BrainTrust để lấy thông tin đó và sau đó hỗ trợ đường dẫn thực thi, điều này, một lần nữa, tuân theo các cơ chế tracing mà chúng ta đã thực hiện. Vì vậy, theo mặc định, khi bạn chạy các lệnh make, chế độ thời gian chạy (runtime mode) được đặt thành kiểu cục bộ (local). Nếu bạn muốn sử dụng chế độ quản lý (managed mode), chỉ cần sử dụng tiền tố (prefix), managed, và bất kỳ lệnh make còn lại nào cũng sẽ diễn ra ở đó. Vậy, điều tôi muốn làm là chuyển sang IDE. Vậy, quay lại readme của tôi.
Quản lý Lời nhắc và Tham số trong BrainTrust
Vì vậy, tôi sẽ xem xét ở đây. Chúng ta sẽ thực hiện make setup. Tôi cứ nghĩ, tôi thực sự muốn nhấn mạnh ở thời điểm này, vì chúng ta đang quản lý điều này trong BrainTrust, hãy sử dụng lệnh setup BrainTrust ở đây. Vậy, điều đó sẽ đóng gói các hàm chấm điểm, công cụ và lời nhắc và đẩy chúng lên cơ sở hạ tầng bảo mật. Vì vậy, bạn sẽ nhận được một đầu ra như thế này và điều đó sẽ trông như thế nào trong Giao diện người dùng (UI). Vậy, hãy quay lại tổng quan (overview) để xem. Vì vậy, ở phía bên trái, nếu chúng ta xem xét các lời nhắc, bạn sẽ bắt đầu thấy ba lời nhắc mà chúng ta đã tạo như một phần của quy trình làm việc đó. Để bạn hình dung ở đây, nếu chúng ta đi đến true or specialist. Vậy, bạn có thể định nghĩa một slug. Tức là một ID có thể thay đổi, nhưng bạn có thể tham chiếu đến nó trong mã nguồn. Điều này cũng có thể được tạo ra khi cần. Lời nhắc, một lần nữa, được coi là mã nguồn. Chúng ta cũng sử dụng một số nội suy (interpolation) ở đó nếu bạn muốn tham số hóa, và tôi sẽ sớm cho bạn thấy điều đó trông như thế nào. Nếu tôi đi đến hàm chấm điểm, vậy hãy tiếp tục để chấm điểm. Được rồi, để tôi xem một chút. Tôi xem xét các tham số. Tôi sẽ xem xét ở đây, và tôi đã tạo các tham số cụ thể chỉ để đơn giản hóa việc thay đổi mô hình cơ sở (baseline model). Vậy, có lẽ chỉ cần giơ tay lên: Các mô hình này được phát hành quá nhanh. Đã có ai từng bị một quản lý sản phẩm (PM) hoặc một quản lý sản phẩm SME không chuyên về kỹ thuật nói rằng, "Này, nhân tiện, tôi có thể thay đổi lời nhắc không? Tôi có thể thay đổi mô hình hoặc lời nhắc và xem nó sẽ trông như thế nào không?" Điều đó đã xảy ra với các bạn chưa? Tôi nghĩ có ba người giơ tay ở đây. Tuyệt vời. Được rồi, vậy, điều tốt đẹp với việc này bây giờ, sử dụng các tham số được quản lý, những SME không chuyên về kỹ thuật đó có thể vào BrainTrust và thay đổi lời nhắc ở đây. Viết một bình luận để nói, "Xem, hãy sử dụng một mô hình khác." Tôi sẽ sử dụng một cái gì đó như cho Mini. Chỉ cần nói, "Đang kiểm thử một mô hình mới." Tôi sẽ lưu phiên bản này ở đây. Viết bình luận. Và điều tôi sẽ làm nữa, chỉ để đưa ra một lời khẳng định cuối cùng. Tôi sẽ tạo một tập hợp BrainTrust. Vì vậy, mỗi khi bạn thay đổi điều gì đó, bạn có thể chạy lệnh này. Nhưng tôi chỉ làm điều đó để ngắn gọn ở đây. Điều đó chủ yếu là để giữ cho mô hình này đồng bộ. Vì vậy, đối với nhiều lời nhắc, đó là kiểu đồng bộ. Nhưng nếu tôi xem xét, xin lỗi, các tham số hiện có, nó sẽ ở đó. Và vì vậy, điều tôi muốn làm là nếu tôi làm điều gì đó như mở khóa. Vì vậy, trong trường hợp này, bằng cách chạy quản lý, tôi chỉ thay đổi quá trình thực thi. Không phải để chạy mô hình cục bộ, mà là để làm theo đường dẫn mà BrainTrust đã thiết lập cho mô hình. Và nếu mọi thứ diễn ra tốt đẹp, bạn sẽ thấy đó là một hệ thống mới. Bạn có thể thấy rằng họ đã thay đổi mô hình ở đây. Vì vậy, một lần nữa, tôi không phải thực hiện bất kỳ thay đổi mã nguồn nào. Tất cả những gì tôi phải làm là vào UI, thay đổi mô hình tôi muốn.
Thiết Lập Đường Cơ Sở và Tự Động Hóa
Khi bạn có một tham số, hãy chạy nó và cách nó sử dụng một đường cơ sở để thiết lập các hoạt ảnh. Một lần nữa, nếu muốn, bạn cũng có thể chạy script demo để đưa các ticket demo vào. Tôi sẽ bỏ qua phần này cho buổi workshop hôm nay. Tôi nghĩ tôi thấy điều này với nhiều khách hàng khác nhau của mình, họ nói: "Ồ, bạn biết đấy, có thể có một loạt các vấn đề khác." Nó nói: "Này, nhân tiện, Brain Trust hiện đang có quyền kiểm soát truy cập đối với các tham số nút này." Điều tôi muốn nói là Brain Trust không thực sự nhằm mục đích thay thế sự chặt chẽ đó. Bạn có lẽ vẫn muốn sử dụng những thứ như hệ thống kiểm soát phiên bản để theo dõi điều đó. Điều chúng tôi đang nói là, khi đưa vào vận hành nó và đảm bảo rằng những người dùng khác có thể làm việc trên hệ thống chia sẻ, đây là một cách tiếp cận được khuyến nghị mà chúng tôi sẽ thực hiện để giúp ích. Vì vậy, một lần nữa, bạn có lẽ vẫn phải có các lời nhắc, bộ công cụ và tham số của mình theo một cách tập trung, nhưng sau đó cung cấp tự động hóa để bạn đồng bộ hóa và làm việc. Đó là cách tốt nhất chúng tôi thấy khách hàng tận dụng điều này.
Giới Thiệu Tính Năng Online Scoring
Tiếp theo, chúng ta sẽ nói về online scoring. Vậy bây giờ chúng ta đã có các đánh giá đó, điều chúng ta sẽ làm là áp dụng các điểm số đó vào các production logs thực tế đang đến thông qua ứng dụng. Thật tuyệt khi chúng ta đã thực hiện các trường hợp thử nghiệm của mình. Chúng ta có một mức độ tin cậy rằng nó đang hoạt động, nhưng một lần nữa, không có gì thay thế được dữ liệu sản xuất. Tất cả chúng ta đều biết điều này. Vì vậy, điều chúng ta sẽ làm là tạo, một lần nữa, di chuyển logic vào Brain Trust và thiết lập tự động hóa theo mục tiêu (on-the-goal automations) mà sau đó sẽ theo dõi và đánh giá điều này khi nó đến trong thời gian thực. Điều cần lưu ý khi bạn bắt đầu hành trình của mình là, đặc biệt nếu bạn đang sử dụng LLM làm người đánh giá, bạn nên bắt đầu với một tỷ lệ lấy mẫu cao hơn. Vì vậy, khi logs đang đến, nếu có thể, bạn muốn đảm bảo xác định một đường cơ sở. Nhưng lại có một sự đánh đổi khi những cuộc gọi này có thể khá tốn kém, đặc biệt nếu bạn đang sử dụng các mô hình tinh vi hơn và cần tỷ lệ suy luận cao. Tại thời điểm đó, khi bạn hài lòng với đầu ra, bạn có thể muốn giảm tỷ lệ lấy mẫu xuống còn 5 đến 10 phần trăm, để bạn quản lý chi phí một cách hiệu quả. Xác định điểm số. Chúng rẻ, khuyến nghị chạy chúng liên tục.
Trình Diễn và Thiết Lập Công Cụ
Xin lỗi, câu hỏi đó là gì? Vâng, tôi sẽ hiển thị điều đó trong Giao diện người dùng. Tôi sẽ chỉ cho bạn. Nếu tôi quay lại Môi trường phát triển tích hợp (IDE), tôi sẽ vào readme ở đây. Ồ, đó là lý do tại sao tôi bỏ lỡ các công cụ được quản lý. Vậy thì hãy git checkout. Được rồi, đó. Như tôi đã đề cập, tất cả chúng đều xây dựng dựa trên nhau, vì vậy việc bỏ qua bước này hoàn toàn ổn. Vậy thì git checkout. Được rồi, bây giờ, nếu tôi chạy make setup, mọi thứ sẽ ổn. Chạy setup Brain Trust. Trong trường hợp này, tôi thực sự đang lấy các công cụ cho sản xuất. Một lần nữa, điều này chỉ thực sự giúp tăng tốc mọi thứ khi có thể. Khi tôi cuộn xuống, nếu tôi làm mới, đúng vậy, tôi cuộn. Các hàm tính điểm mà bạn đã thấy trước đó trong mã nguồn, giờ đây chúng đang được quản lý bởi Brain Trust. Vì vậy, bạn có thể thấy nó có sẵn ở đây. Điều tôi muốn nhấn mạnh là tree. Vì vậy, tôi có rất nhiều LLM làm người đánh giá, đã được áp dụng. Vì vậy, tôi đã đưa nó ra, nhưng khi lấy S. Và có một quy tắc tự động hóa đang được áp dụng. Vì vậy, chất lượng gốc nội tuyến.
Tự Động Hóa và Khung Sườn
Những gì tôi đã làm ở đây, một lần nữa, tôi đã tự động hóa việc thiết lập dưới dạng mã, để khởi tạo dự án. Nhưng một lần nữa, những gì chúng ta có thể làm ở đây là, tùy thuộc vào việc đó là một span riêng lẻ, chúng ta có thể chạy thực thi hoặc toàn bộ trace. Và đây là lý do tại sao siêu dữ liệu rất quan trọng, vì chúng ta chỉ muốn theo dõi các lỗi cụ thể có thể xảy ra trong mã nguồn. Một lần nữa, tùy thuộc vào trường hợp sử dụng, tỷ lệ lấy mẫu của tôi, như tôi đã đề cập, được đặt là 100, nhưng đối với các cuộc gọi tốn kém hơn, chúng ta cũng muốn cân nhắc điều đó. Vì vậy, đây là cách tự động hóa hoặc cách chúng ta thực hiện điều đó trong Brain Trust ngày nay. Không, tự động hóa giống như việc thực thi đối với logs đến. Nhưng tôi quan tâm hơn, tôi đã áp dụng tự động hóa để thiết lập môi trường và khung sườn này. Vì vậy, tôi chỉ muốn phân biệt điều đó ở đây. Xin lỗi, có câu hỏi. Bạn có thể giải thích rõ hơn về điều đó được không? Vâng. Đúng vậy. Vâng, đúng vậy. Ổn thôi. Vâng, chúng ta có thể muốn coi đó là một trường hợp biên, đưa nó vào một tập dữ liệu, xác định nó và sau đó đưa nó trở lại. Vì vậy, đó sẽ là cách tiếp cận mà tôi sẽ thực hiện cho việc này. Nếu bạn chưa có bất kỳ sự thật cơ bản nào hoặc chúng đã có rồi, đúng không? Vì vậy, đây là lý do tại sao tôi nói, tùy thuộc vào nơi bạn bắt đầu, tốt hơn là nên có một số loại dữ liệu và sau đó bắt đầu chu trình phản hồi của bạn từ đó. Ồ, trường hợp đó. Chúng ta có thể đưa điều đó vào một tập dữ liệu và sau đó phát lại qua sân chơi. Đó sẽ là cách chúng ta làm điều đó. Vâng. Vâng.
Giới Thiệu Khắc Phục Lỗi
Được rồi. Vậy là chúng ta đã kiểm tra online scoring, đến lúc rồi. Được rồi, bây giờ đến phần khắc phục. Vì vậy, hy vọng sẽ thấy được sự khác biệt (delta), hoặc một lần nữa, lý do chúng ta ở đây hôm nay. Vì vậy, hy vọng điều này có thể giúp bạn với câu hỏi cụ thể đó. Vì vậy, một lần nữa, đây là điều có thể xảy ra như một đầu vào hợp lý cho hệ thống tác nhân của chúng ta: người dùng có thể nói: "Này, điều này không khẩn cấp, nhưng tôi sẽ xem liệu chúng ta có thể xuất hóa đơn trước cuộc họp hội đồng quản trị không." Mô hình nói: "Chờ đã, điều này có vẻ ổn đối với tôi." Ai đó nói: "Không, khẩn cấp. Đến xem, đến xem." Nhưng nghiệp vụ thì rất khác, đúng không? Điều này có lẽ cần được chú ý ngay lập tức. Giám đốc tài chính của bạn được hiển thị báo cáo quý cần phải hoàn thành. Và đây là sự khác biệt giữa những gì chúng ta đang làm ở đây hôm nay là cố gắng xác định chế độ lỗi thích hợp và sau đó khắc phục điều đó có thể.
Quy Trình Khắc Phục và Kiểm Tra
Vì vậy, trong trường hợp này, một lần nữa, tôi có thể chạy chế độ cụ thể này ở đây. Tôi có điều này trong tập dữ liệu này. Vì vậy, chỉ cần chạy một kịch bản mà chúng ta sẽ phát lại lỗi. Chúng ta muốn ngăn chặn đánh giá đối với điều này. Chúng ta sẽ siết chặt lời nhắc, chạy lại và xem nó trông như thế nào. Chúng ta có lẽ sẽ sử dụng nó lại. Đó không chỉ là một trường hợp thử nghiệm cụ thể, mà nó có thể bao quát toàn bộ trường hợp thử nghiệm của chúng ta để xem liệu nó có hoạt động như mong đợi và chúng ta chưa thoái lui trên một thứ khác từ góc độ đó không. Được rồi, vậy thì hãy tiến hành và có hai nhánh riêng biệt cho việc này. Vì vậy, hãy chia nhánh của chúng ta thành A, một nhánh sẽ có tỷ lệ lỗi trong tâm trí. Chúng ta sẽ truy cập Giao diện người dùng và xem điều đó, sau đó chúng ta sẽ nói về đường dẫn khắc phục ở đó nữa.
Rất nhiều sản phẩm thực sự. Vì vậy, chúng ta thậm chí có thể thực hiện chế độ một lần (one-time mode) mà sẽ tạo ra một lỗi phát lại (replay failure). Được rồi, vậy tôi có tập hợp năm trường hợp là hồi quy của các chế độ lỗi. Vì vậy, đó là cái đầu tiên bạn thấy trong ticket ví dụ. Vâng, đó là một tệp JSON ở đây. Hãy xem ở đây. Được rồi, vậy hãy xem chế độ lỗi ở đây. Bạn có thể đi sâu vào điều này. Bạn cũng sẽ nhận thấy rằng chúng ta đã thiết lập online, các công cụ được quản lý cũng như online scoring. Trace trở nên tinh vi hơn nữa bởi vì chúng ta đang thực thi điều này đối với môi trường Brain Trust an toàn. Vì vậy, một lần nữa, chuyển từ local sang được quản lý. Tôi sẽ đi đến makefile. Xin lỗi, cảm ơn về JSON. Hãy đến tài liệu hướng dẫn. Vì vậy, tôi chỉ đang thực hiện đánh giá đối với một kịch bản cụ thể.
Theo Dõi Khắc Phục trong Giao Diện Người Dùng
Được rồi, như chúng ta có thể thấy khi chúng ta đang phát triển với ứng dụng, thử nghiệm, một lần nữa, trình xem chỉ cho phép chúng ta thấy tiến độ của các thay đổi của chúng ta. Vì vậy, bạn có thể thấy chúng ta đã chạy tập dữ liệu mới nhất. Chúng ta nhận thấy một số suy giảm ở đây, điều này cho phép chúng ta theo dõi nó. Vì vậy, tập dữ liệu được quản lý mà tôi đã nghĩ đến, tỷ lệ lỗi thực tế đang được ghi lại. Và bạn có thể thấy, tôi đã có thể xem nó để so sánh với các thử nghiệm hiện có, để theo dõi tiến độ và khắc phục khi có thể.
Vì vậy, tôi bỏ qua điều tiếp theo là tôi sẽ đi đến readme. Và sau đó tiến hành khắc phục. Vì vậy, trong khắc phục này, tôi đã thay đổi lời nhắc mà tôi đã sử dụng. Vì vậy, một cách để xem điều đó là nếu tôi xem lời nhắc và thay đổi. Vì vậy, chúng ta sẽ thấy, chúng ta sẽ thấy bất kỳ sự khác biệt nào ở đó. Ngay tại chỗ. Cuộn xuống tệp readme ở đây. Giả sử tôi làm một điều ở đây, hãy cho chúng ta một cờ cụ thể, tôi nghĩ vậy. Tôi không biết bạn có muốn kiểm tra lại và đặt điều đó không. Vâng, thế thôi. Vì vậy, nếu bạn muốn đặt điều đó, nếu nó tồn tại, thay thế, trong VM build chat. Vâng. Vâng, ổn thôi. Vì vậy, vâng, mọi người, nếu bạn muốn, trong phần script khắc phục, nếu bạn đặt biến môi trường BRAIN_TRUST_ON_THE_SCORE, nếu on_the_score tồn tại, bạn đặt nó là thay thế. Nó sẽ đẩy các thay đổi đã cập nhật vào môi trường. Vậy thì, nếu tôi lấy, ôi, nó không phải cho điều đó. Và sau đó bạn cũng sẽ thấy, bây giờ chúng ta đã cập nhật lời nhắc và đẩy nó lên, nó cũng có sẵn ở đây. Vì vậy, cũng như trong Giao diện người dùng, một lần nữa, một phần của vận hành, đưa vào vận hành, chúng ta có thể thấy ai đã thay đổi gì, nhưng thực sự điều gì đã được thay đổi đối với lời nhắc cụ thể trong trường hợp này, đặc biệt là ở đây. Vì vậy, bao gồm hai sự thật, và làm rõ điều đó.
Được rồi. Vậy thì, quay lại đây, giả sử chúng ta chạy lại đánh giá này. Vì vậy, chúng ta đã thực hiện thay đổi đối với lời nhắc, và bây giờ chúng ta đang chạy phiên bản đã được khắc phục để xem nó hoạt động như thế nào. Được rồi, vậy thì đó là chạy thử nghiệm ở đây với các thay đổi mới, hy vọng vậy. Và tôi đang chuyển sang Giao diện người dùng, tôi sẽ đến phần thử nghiệm ở đây. Và nó hầu như không có ở đó, nhưng bạn có thể thấy, kiểu như, khôi phục nó, bạn biết đấy, bất kỳ cải thiện nào đi lên là cải thiện đó. Nhưng vâng, chỉ để bạn có ý tưởng ở đây, rằng, bây giờ chúng ta đã thực hiện đánh giá, thực ra điều tôi có thể làm là, ừm, thực hiện một so sánh (diff), và chúng ta có thể làm, vì vậy hãy thực hiện một so sánh trong sự khác biệt (delta). Vâng. Vì vậy, vâng, hãy phát triển, ừm, cải thiện theo thời gian, ừm, theo cách nào, theo cách nào, ừm, kết quả mong muốn. Vâng.
Tổng Kết và Các Bài Học Quan Trọng
Tôi nghĩ chúng ta đang đến gần cuối nội dung. Ừm, vì vậy tôi biết nó đã có nhiều bước. Vì vậy, tôi thực sự, thực sự muốn cảm ơn thời gian và sự chú ý của bạn đã đi qua đó. Như đã đề cập, các tạo phẩm là công khai. Chúng ta có cheat sheet ở đó. Chúng ta có kênh Slack để giúp đỡ nếu bạn có bất kỳ câu hỏi nào. Hy vọng, chỉ để cung cấp cho bạn một tóm tắt về những gì bạn đã hoàn thành hôm nay, theo thứ tự này: bạn đã đi từ việc lấy một lời nhắc một lần chạy (single-shot prompt) thành xây dựng một quy trình làm việc tác nhân năm giai đoạn (five-stage agent workflow) sử dụng cuộc gọi công cụ (tool calls). Điều chúng ta sau đó có thể làm là kiểm tra cách điều này hoạt động khá nhiều, và sau đó đi sâu vào điều này bằng cách thêm theo dõi Brain Trust, đảm bảo mọi thứ được ghi lại.
Ừm, chúng ta cũng sau đó muốn nói về, bạn biết đấy, làm thế nào chúng ta đánh giá hệ thống từ, ừm, bạn biết đấy, không có trực tuyến, khi có điều gì đó mới, ừm, tạo ra những tập vàng (golden set) hiệu quả với những trường hợp thử nghiệm đó, mà chúng ta sẽ thực thi đối với chúng. Chúng ta sau đó đã triển khai những lời nhắc được quản lý, những công cụ và tham số đó vào kiến trúc Brain Trust an toàn để sử dụng. Và chúng ta cũng đã thêm online scoring để sau đó đánh giá hệ thống khi nó diễn ra. Và sau đó chúng ta đã chọn một lỗi sản xuất cụ thể, chúng ta đã xem trace, chúng ta đã sửa đổi lời nhắc trong trường hợp của chúng ta và chúng ta đã thấy sự khác biệt ở đó. Sau khi chạy lại đánh giá, chúng ta đã thấy nó khôi phục đến nơi cần thiết. Và trong trường hợp này, hoàn thành đánh giá đầy đủ về việc xây dựng, quan sát nó, triển khai nó và đưa nó tiến về phía trước.
Ừm, vì vậy, vâng, chỉ để tổng kết và hoàn thành nó. Một lần nữa, hy vọng điều này không phổ biến, nhưng một lần nữa, những gì có thể hoạt động trong sản xuất sẽ không thực sự hoạt động trong nguyên mẫu (prototype). Ừm, chúng ta thực sự cần phải phân tích điều này, xác định các chế độ lỗi và tiến về phía trước. Và đó là nơi, một lần nữa, các giai đoạn rõ ràng trở nên thực sự, thực sự quan trọng, đúng không? Và, ừm, một lần nữa, điều này giới thiệu thêm các khu vực mà mọi thứ có thể gặp trục trặc, nhưng dễ gỡ lỗi hơn nếu đó là trường hợp. Ừm, bạn biết đấy, không có gì thay thế được việc đi sâu vào mã nguồn và theo dõi mọi thứ. Vì vậy, tôi sẽ nói nó có khả năng quan sát. Đây là những yêu cầu cơ bản (table stakes) tại thời điểm này.
Liên tục cải tiến và truy vết ứng dụng
Nếu bạn có một ứng dụng ở lớp sản xuất (production layer application) mà bạn không thực hiện việc tracing, bạn cần phải xem xét lại từ đầu và triển khai nó một cách hiệu quả. Và hy vọng, chúng tôi có thể chỉ cho bạn cách thực hiện điều đó bằng cách sử dụng Brain Trust. Một lần nữa, không có gì có thể thay thế hoàn hảo cho nhật ký sản xuất (production logs), nhưng tốt hơn hết là hãy bắt đầu từ đâu đó. Nếu bạn có ý tưởng về một vấn đề có thể xảy ra, đây là những cách hoàn hảo để bổ sung cho việc đánh giá, sử dụng các chế độ lỗi đó làm trường hợp kiểm thử của bạn.
Như tôi đã đề cập, đây là một quá trình liên tục, đúng không? Không có gì là hoàn tất mãi mãi. Nếu bạn đã làm việc trong phát triển linh hoạt (agile development), phản hồi liên tục là rất quan trọng. Và một lần nữa, chúng tôi đang mang mô hình vận hành này đến, nhưng với một bề mặt vận hành tập trung vào người dùng (user-centric surface). Hy vọng, chúng tôi sẽ mang điều này về cho các nhóm của bạn ngay hôm nay.
Vì vậy, lời khuyến khích của tôi dành cho bạn là, nếu đây là điều bạn quan tâm, hãy chọn một thứ gì đó đã đi vào hoạt động. Không nhất thiết phải là toàn bộ bộ ứng dụng. Có thể bắt đầu với thứ gì đó quan trọng hơn một chút mà bạn thực sự muốn cải thiện các chế độ vận hành của nó. Thêm tracing, thu thập số liệu của bạn từ chế độ đó, xây dựng các khám phá lặp đi lặp lại (iteratively explore) và sau đó lặp lại mọi thứ nếu có thể. Vì vậy, một lần nữa, vòng lặp phản hồi càng nhanh, bạn càng có nhiều cái nhìn sâu sắc và bạn càng có thể cải thiện tổng thể các hoạt động vận hành và phân phối của hệ thống.
Lời kêu gọi hành động & Tài nguyên
Đây là lời kêu gọi hành động. Tôi biết chúng tôi đã cung cấp rất nhiều nội dung cho bạn. Rõ ràng là chúng tôi đang cố gắng thu thập phản hồi. Chúng tôi cố gắng đặt ra một số Hàng rào bảo vệ, vì vậy tôi đánh giá cao sự nỗ lực của mọi người khi phải xử lý nhiều thông tin để thực hiện điều này. Nhưng như tôi đã đề cập, bạn phải bắt đầu từ đâu đó. Hãy để chúng tôi giúp bạn tăng tốc. Chúng tôi có rất nhiều tài liệu được cung cấp. Bạn cũng có thể sử dụng tác nhân AI của chúng tôi trên agent để tìm kiếm nếu bạn có bất kỳ câu hỏi nào, nhưng chúng tôi cũng có một cookbook (sách hướng dẫn) có sẵn. Tôi thường trực tiếp đưa cookbook vào Cursor, Codex, và những công cụ khác rồi nói: "Về cơ bản, hãy lấy SDK và bắt đầu tracing ứng dụng của tôi." Nó khá hiệu quả. Chúng tôi thậm chí còn có một phiên bản chỉ là một CLI cho ứng dụng Brain Trust của chúng tôi. Điều đó cho phép bạn thực hiện những việc như tự động đo lường (auto-instrumentation). Tôi chỉ muốn giới thiệu đồng nghiệp Eric của tôi, người đang làm việc rất nhanh chóng và tuyệt vời, hãy ghé thăm gian hàng của anh ấy vì nó thực sự tuyệt vời.
Và một lần nữa, nếu đây là điều bạn quan tâm và muốn tìm hiểu thêm, vui lòng liên hệ với đại diện tài khoản của bạn tại Brain Trust. Một lần nữa, chúng tôi rất sẵn lòng hỗ trợ nếu có thể. Nếu bạn đang ở trong Discord, hãy thoải mái tham gia; chúng tôi rất vui được trả lời các câu hỏi ở đó. Và một lần nữa, tôi thực sự muốn cảm ơn bạn vì thời gian và sự chú ý của bạn. Hôm nay là một ngày nắng đẹp, và tôi không muốn giữ mọi người ở đây; tôi muốn bạn ra ngoài hít thở không khí trong lành. Nhưng vâng, thay mặt cho Brain Trust, người đào tạo và bản thân tôi, xin chân thành cảm ơn thời gian và sự chú ý của bạn. Đó là một vinh dự, và tôi mong muốn được gặp bạn ngoài kia khi bạn thực hiện tracing và nhận được giá trị từ việc cung cấp AI. Tôi hoan nghênh bạn. Xin cảm ơn.
TL;DR
- Hội thảo tập trung vào việc cung cấp các ứng dụng Trí tuệ nhân tạo (AI) chất lượng cao bằng cách tận dụng nền tảng Brain Trust, hợp tác với Trainline để chia sẻ kinh nghiệm thực tế.
- Thách thức chính trong việc triển khai AI là chuyển đổi từ các bản thử nghiệm (POC) sang môi trường sản phẩm thực tế, do sự khác biệt giữa tính xác định của phần mềm truyền thống và tính xác suất của AI.
- Brain Trust cung cấp một nền tảng quan sát AI (AI observability) và quy trình làm việc có hệ thống (flywheel) để giải quyết các vấn đề này, giúp các tổ chức xác định chế độ lỗi, đánh giá hiệu suất và liên tục cải thiện hệ thống AI ở quy mô lớn.
Điểm chính
- Việc chuyển đổi các bản thử nghiệm AI/ML (đặc biệt là AI tạo sinh) sang môi trường sản phẩm gặp khó khăn lớn do thiếu "sự chặt chẽ trong vận hành" (operational rigor) và tính phi xác định của AI.
- "Khả năng quan sát" (observability) là yếu tố then chốt để hiểu hành vi của hệ thống AI trong sản xuất, vượt ra ngoài việc chỉ xem xét các nhật ký (logs) thông thường.
- Phát triển AI chất lượng đòi hỏi cách tiếp cận có cấu trúc, tương tự như kiến trúc dịch vụ vi mô (microservices) trong kỹ thuật phần mềm, để chia nhỏ các lời nhắc (prompts) phức tạp và luồng tác nhân (agentic flow).
- Hội thảo thực hành sẽ hướng dẫn xây dựng hệ thống AI với "gọi công cụ đa giai đoạn" (multi-stage tool calling), sử dụng Brain Trust để "công cụ đo lường" (instrument) và đánh giá hiệu suất.
- Xác định các "chế độ lỗi" (failure modes) bằng "kiểm thử vàng" (golden test) và xử lý "trường hợp biên" (edge cases) bằng dữ liệu thực tế là rất quan trọng để công nghiệp hóa và duy trì hệ thống AI.
- Brain Trust là một nền tảng "khả năng quan sát AI" (AI observability platform) giúp xử lý dữ liệu bán cấu trúc (semi-structured traces) từ các hệ thống AI để theo dõi và cải thiện liên tục thông qua một "vòng quay liên tục" (flywheel) lặp đi lặp lại.
- Trainline sử dụng AI để dự đoán gián đoạn tàu (ML truyền thống) và vận hành "trợ lý du lịch AI" (AI travel assistant) là một "hệ thống đa tác nhân" (multi-agent system) chủ động xử lý các yêu cầu như hoàn tiền và đổi tàu.
Từ vựng
hands-on workshop— hội thảo thực hànhAI— Trí tuệ nhân tạoBrain Trust— (Tên nền tảng)LLMs— Mô hình Ngôn ngữ Lớnkỹ sư AI— AI engineermôi trường sản phẩm— production environmentoperational rigor— sự chặt chẽ trong vận hànhobservability— khả năng quan sátprompt— lời nhắcfailure modes— chế độ lỗigolden test— kiểm thử vàngedge cases— trường hợp biênflywheel— vòng quay liên tụcAI travel assistant— trợ lý du lịch AImulti-agent system— hệ thống đa tác nhân
Nội dung chi tiết
Giới thiệu và chào mừng
Chào buổi chiều tất cả mọi người. Chào mừng đến với Sonny London. Đây có phải là lần đầu tiên của mọi người ở đây không? Tôi nghĩ là có, vì đây là một hội nghị khai mạc. Thật tuyệt vời, thật tuyệt vời. Cảm ơn rất nhiều vì đã tham gia buổi hôm nay. Hy vọng các bạn đã chọn đúng buổi. Nhưng đối với những ai cần kiểm tra kỹ lại, đây là một hands-on workshop về việc cung cấp các ứng dụng AI chất lượng cao với Brain Trust. Chúng tôi cũng sẽ hợp tác với các đồng nghiệp tại Trainline, những người sẽ được giới thiệu ngay sau đây.
Về phần giới thiệu của tôi: các bạn có thể gọi tôi là Durand, giống như ban nhạc Duran Duran, nhưng có thêm chữ G. Hy vọng mọi người là fan của Simon Le Bon. Tôi đã có cơ hội giúp các tổ chức và doanh nghiệp mở rộng quy mô áp dụng các hệ thống quan trọng, và giờ đây tôi đang chuyển sang kỷ nguyên AI. Nền tảng của tôi là toán học thuần túy. Tôi biết rằng học máy đến khoa học dữ liệu và hiện tại là kỹ thuật AI đang là xu hướng nóng, và đây là thời điểm rất thích hợp. Các bạn cứ thoải mái kết nối với tôi trên LinkedIn nếu muốn theo dõi hoặc chỉ đơn giản là trò chuyện về lĩnh vực này.
Tôi cũng có hai người bạn từ Trainline ở đây, nếu các bạn muốn đến và tự giới thiệu. (Kiểm tra micro) Ồ, tốt. Vâng. Xin chào mọi người. Cảm ơn đã đến với workshop này, đặc biệt là sau giờ ăn trưa và thời tiết nắng đẹp bên ngoài. Cảm ơn rất nhiều vì đã đến đây. Tên tôi là Osama. Tôi là một kỹ sư AI cấp cao tại Trainline. Ai biết tôi không? Vâng, một người. Trước đây tôi là một kỹ sư nền tảng cấp chuyên viên và có nền tảng về thị giác máy tính. Tôi cũng đã phát triển các ứng dụng di động bên cạnh. Có lúc tôi không liên quan gì đến AI, nhưng vâng, bây giờ chúng tôi đang làm AI cùng với các đồng nghiệp tại Trainline.
Chào mọi người. Tên tôi là Mike. Tôi là một kỹ sư AI cấp cao tại Trainline. Tôi có nền tảng nghiên cứu về các Mô hình Ngôn ngữ Lớn (LLMs), nhưng nghiên cứu của tôi tập trung vào các LLM tiền-LLM lớn, như BERT hoặc các LLM cũ hơn. Vì vậy, chúng tôi đang tiếp tục xây dựng các sản phẩm tác nhân (agentic products) tiên tiến nhất tại Trainline. Nếu các bạn đến từ nước ngoài, tôi chắc rằng các bạn đã sử dụng Trainline rồi; nếu chưa, xin hãy dùng thử, vì đây là dịch vụ hiện đại nhất để mua vé và các thứ khác. Vâng, chào mừng, và chúng tôi rất vui khi được tổ chức workshop này. Chúng tôi sẽ hướng dẫn các bạn qua trải nghiệm thực hành.
Tuyệt vời. Tôi cũng có một số đồng nghiệp từ Brain Trust đến từ nước ngoài. Phil, Eric và Rose, nếu các bạn có thể giơ tay. Đừng lo lắng, mọi người sẽ an toàn nếu các bạn gặp khó khăn. Chỉ cần gọi và họ sẽ giúp đỡ. Tuyệt vời.
Hướng dẫn chung và thiết lập hội thảo
Chỉ muốn một chút về hướng dẫn chung. Nếu mọi người có thể tham gia kênh Slack của AI Engineer. À, có một tổ chức AI Engineer, nhưng cũng có một kênh Slack cụ thể mà chúng ta sẽ sử dụng hôm nay để giúp tiến hành workshop. Vì vậy, nếu các bạn gặp khó khăn, chúng ta có thể sử dụng kênh Slack để giúp đỡ lẫn nhau. Một lần nữa, chúng tôi đã ở đó rồi, nhưng khi chúng ta tiến hành và đến phần thực hành, nếu các bạn gặp khó khăn, điều này sẽ thực sự hữu ích. Chúng tôi cũng cung cấp các tờ hướng dẫn (cheat sheets). Vì vậy, nếu các bạn gặp phải một trở ngại cụ thể, có các hướng dẫn từng bước giúp các bạn đến được nơi chúng ta cần trong workshop mà không cần phải cảm thấy bị tụt lại phía sau. Một lần nữa, tất cả các tài nguyên chúng tôi chia sẻ hôm nay đều có sẵn công khai. Chúng tôi có thể có bất kỳ buổi theo dõi cụ thể nào nếu cần. Nhưng chúng tôi sẽ cho các bạn vài phút để đảm bảo các bạn tham gia vào kênh đó, và sau đó tham gia kênh AI Engineer Europe 226 Brain Trust Dash Workshop. Đây là một kênh công khai. Được rồi, mọi người. Tôi đoán chúng ta có thể bắt đầu. Vâng, đối với những người ngồi ở phía sau, chúng ta sẽ cần tham gia kênh Slack. Vì vậy, nếu các bạn đã thấy Pierce, tôi hy vọng sẽ làm được điều đó. Cảm ơn mọi người. Hãy tiếp tục.
Cấu trúc buổi hội thảo
Ok, đây là để giúp định hướng workshop hôm nay. Chúng ta sẽ chia thành ba phần chính. Chúng ta sẽ dành một chút thời gian để thiết lập bối cảnh tại sao chúng ta ở đây và tại sao workshop này lại phù hợp. Hy vọng chúng ta sẽ thiết lập ngữ cảnh cho khi chúng ta đi vào workshop, xây dựng hệ thống, nói về việc làm thế nào để chúng ta triển khai AI chất lượng, và sau đó chúng ta sẽ tổng kết các điểm chính và chúng tôi sẽ ở lại để trả lời bất kỳ câu hỏi mở nào mà chúng ta có từ thực tế.
Đối tượng tham gia
Ok, hy vọng hôm nay sẽ có rất nhiều người đến từ nhiều nền tảng khác nhau. Chúng tôi dự định workshop này sẽ phục vụ cho, một lần nữa, có lẽ mọi người ở đây đều biết Mô hình Ngôn ngữ Lớn (LLM) là gì. Tôi không muốn xúc phạm ai cả, nhưng hy vọng các bạn đang bắt đầu hành trình khám phá và trưởng thành trong việc vận hành để xây dựng các hệ thống AI. Vì vậy, cho dù bạn là một kỹ sư sản phẩm AI, có lẽ từ một đội ứng dụng, hoặc đến từ những người học máy truyền thống, có lẽ bạn có thể là một người vận hành nền tảng hoặc cơ sở hạ tầng. Workshop này thực sự phù hợp với bạn.
Chỉ cần giơ tay lên đây, ai ở đây đến từ nền tảng khoa học dữ liệu truyền thống, chẳng hạn? Thú vị, thú vị. Ai ở đây có lẽ đến từ kỹ thuật phần mềm và sau đó chuyển sang AI? Được rồi, vậy đây chắc chắn là căn phòng phù hợp cho bạn. Hy vọng chúng ta sẽ có thể đẩy nhanh mọi thứ khi chúng ta tiến triển.
Thách thức khi đưa AI vào sản xuất
Được rồi, chỉ để đặt ngữ cảnh ở đây. Tôi nghĩ đây không phải là một biểu hiện bất thường mà chúng ta đang thấy rộng rãi hơn trong ngành. Một lần nữa, nhưng nếu giơ tay, ai ở đây đã làm một bản thử nghiệm (POC) học máy hoặc AI, cụ thể hơn là một bản thử nghiệm (POC) AI tạo sinh, nhưng sau đó đã không thể đưa nó vào môi trường sản phẩm (production)? Được rồi, có một vài cánh tay, vâng. Tôi sẽ lo lắng nếu không ai giơ tay, nhưng đây là một vấn đề then chốt mà tôi và khách hàng của tôi đang nói đến, các giám đốc điều hành, những người cấp cao, tất cả đều đang rất quan tâm. Họ đang nghĩ về công nghệ mới này. Công nghệ này rất mới, nhưng nó mới đối với rất nhiều người, đặc biệt là trong các doanh nghiệp lớn hơn và các ngành được quản lý. Và sau đó họ đang cố gắng đưa công nghệ này để mang lại giá trị cho khách hàng của họ.
Nhưng thật không may, có một rào cản lớn giữa việc phát triển một cái gì đó trên máy cục bộ của bạn và sau đó công nghiệp hóa nó, đảm bảo nó hoạt động trong thực tế. Nhưng điểm mấu chốt mà chúng tôi đã thấy từ tất cả các nghiên cứu hiện có là không phải các mô hình đặc biệt thông minh. Chúng tôi có các mô hình rất tinh vi, cho dù bạn xây dựng một cái gì đó nội bộ hay bạn đang sử dụng một nhà cung cấp thương mại trực tuyến hàng đầu. Điều chúng tôi thấy rộng rãi hơn là loại sự chặt chẽ trong vận hành (operational rigor) khi đưa các hệ thống này ra quy mô đã không theo kịp, bởi vì kỹ thuật phần mềm truyền thống rất xác định (deterministic), 1 cộng 1 bằng 2, tuyệt vời. Và các hệ thống trực tuyến, như tôi đã từng nói, hoặc một đứa trẻ năm tuổi sẽ nói, 2 cộng 3 bằng 10, bố ơi. Vì vậy, chúng ta phải điều chỉnh và đảm bảo rằng chúng ta đang cung cấp điều đó ở quy mô.
Và một lần nữa, đây là một điểm quan trọng mà chúng tôi thấy khi triển khai những thứ này là thực tế là mọi người nghĩ rằng demo là đủ. Nhưng rõ ràng, thực hiện 2 đến 3, 5 demo thì tuyệt vời, nhưng khi đưa vào sản xuất, mọi thứ đều gặp trục trặc. Coi một số nhật ký (logs) của bạn là khả năng quan sát (observability) – và điều này thực sự quan trọng đối với cách chúng tôi nhìn nhận Brain Trust – đó là nhật ký sẽ cho bạn biết điều gì đã xảy ra. Nhưng đôi khi bạn cần đi sâu vào hệ thống và hiểu hành vi của nó. Và đây thực sự là nơi khả năng quan sát phát huy tác dụng.
Một điều nữa là, nó hoạt động trên máy của tôi, nhưng thất bại trong môi trường sản phẩm. Tôi cố gắng vá lời nhắc (prompt) và sau đó, lại vận hành cho đến khi vấn đề tiếp theo xảy ra và chế độ lỗi tiếp theo. Nhưng một lần nữa, làm thế nào để chúng ta theo dõi điều đó? Đặc biệt nếu bạn không có một hệ thống tại chỗ, bất kể bạn sử dụng công cụ nào, điều này có thể gây ra ảnh hưởng lớn. Vì vậy, rất nhiều điều chúng tôi thấy, một lần nữa, không phải là công cụ hay công nghệ, mà là các quy trình làm việc vận hành (operational workflows) nhiều hơn. Và đây thực sự là điều chúng tôi muốn giúp bạn trong workshop hôm nay.
Cách tiếp cận để phát triển AI chất lượng
Vì vậy, một lần nữa, như tôi đã đề cập, nó không phải là nguyên mẫu, mà là đạt đến trạng thái mà chúng ta biết chính xác điều gì đã thay đổi trong hệ thống, làm thế nào để chúng ta tương tác với điều đó và sau đó làm thế nào để chúng ta đưa ra một sự chặt chẽ (rigor) có hệ thống để chúng ta có thể ngày càng tốt hơn. Hãy nhớ rằng, mục tiêu của chúng ta không phải là độ bao phủ 100%, mà là đạt được càng gần càng tốt trong khi duy trì việc khắc phục những khoảng trống có thể tồn tại.
Và một lần nữa, một điều mà chúng tôi thấy lặp đi lặp lại là, một lời nhắc có thể hoạt động, nhưng khi bạn di chuyển và công nghiệp hóa nó, bạn có thể muốn làm những điều như chia nhỏ nó thành từng phần trách nhiệm riêng lẻ. Vì vậy, nếu bạn đến từ nền tảng kỹ thuật phần mềm, bạn biết về những điều này, bạn sẽ chia monolith thành dịch vụ vi mô (microservices). Chúng tôi sẽ phác thảo một cách tiếp cận rất tương tự ở đây khi chúng tôi nói về việc xây dựng các hệ thống này. Một lần nữa, đảm bảo rằng chúng ta đang hiểu những thay đổi này, đưa ra một tập hợp các hệ thống, đây thực sự là điều chúng tôi muốn làm trong workshop hôm nay.
Nội dung thực hành hội thảo
Về phần hôm nay, hy vọng, như tôi đã đề cập, đây là một workshop thực hành, vì vậy chúng ta sẽ vào terminal, chúng ta sẽ vào UI, và chúng ta sẽ đi qua từng bước và hướng dẫn trong suốt quá trình. Vì vậy, chúng ta sẽ xây dựng một hệ thống AI theo giai đoạn với gọi công cụ (multi-stage tool calling), điều này thực sự cho phép chúng ta thấy một luồng tác nhân (agentic flow) hơn. Chúng ta sẽ sử dụng Brain Trust để công cụ đo lường (instrument) và xem hiệu suất của ứng dụng đang hoạt động như thế nào.
Sau đó, chúng ta cũng muốn xem xét việc tạo ra cái mà chúng tôi gọi là xác định các chế độ lỗi (failure modes) bằng cách sử dụng một kiểm thử vàng (golden test). Vì vậy, chúng ta sẽ đẩy nó qua. Sau đó, chúng ta cũng muốn nói về cách chúng ta công nghiệp hóa nó. Vì vậy, việc chuyển từ "nó chỉ hoạt động trên máy của tôi" sang một cái gì đó mà bạn có thể sử dụng trong môi trường sản phẩm và có một hệ thống quản lý nó. Và điều quan trọng là xác định các trường hợp biên (edge cases), bởi vì một lần nữa, bạn có thể tạo một tập dữ liệu kiểm thử (test data set), nhưng cuối cùng không có gì thay thế được dữ liệu thực tế (real world data). Vì vậy, chúng tôi sẽ cho bạn thấy cách chúng ta sẽ lấy những tín hiệu thực tế đó và đánh giá để hoàn thành vòng lặp.
Giới thiệu về Brain Trust
Chỉ là một phần giới thiệu ngắn gọn nữa ở đây, ai đã từng nghe nói về Brain Trust, đã thử nghiệm với Brain Trust, tôi có thể xin một cái giơ tay không? Được rồi, tuyệt vời, tuyệt vời. Vì vậy, được rồi, tôi thích những cánh tay của bạn.
Vì vậy, một chút giới thiệu về Brain Trust. Chúng tôi là một công ty hiện đã, tôi nghĩ là gần ba năm tuổi. Chúng tôi là một công ty khoảng Series B. Vì vậy, chúng tôi vừa thông báo rằng ở mức thị trường thực phẩm, chúng tôi đã huy động được 80 triệu đô la, với định giá 800 triệu đô la. Chúng tôi có các nhà đầu tư như Iconic, a16z, cũng như Gwelok để thực sự nói về việc giúp các tổ chức triển khai AI chất lượng ở quy mô lớn.
Chúng tôi là nền tảng cho khả năng quan sát AI (AI observability). Chúng tôi có một lượng lớn người dùng trên toàn cầu, nhưng chúng tôi cũng đang mở rộng sự hiện diện của mình mạnh mẽ ở Châu Âu. Vì vậy, một lần nữa, tôi là một trong những kỹ sư đầu tiên gia nhập để giúp xây dựng chức năng đưa sản phẩm ra thị trường của chúng tôi ở đây. Chúng tôi rất vui mừng, một lần nữa, với khách hàng của chúng tôi và bạn bè của chúng tôi qua Trainline để làm điều đó. Một số khách hàng địa phương của chúng tôi bao gồm như Lovable, Dr. Lub cũng đang thực sự thúc đẩy các hệ thống AI này.
Một lần nữa, khi sử dụng Brain Trust, tôi muốn tự mình trải nghiệm, nhưng điều mà chúng tôi thực sự nổi bật là khả năng thực hiện điều này ở quy mô lớn. Vì vậy, người sáng lập, Ankur Gwel, đây thực sự là lần thứ ba ông xây dựng Brain Trust. Ông ấy là một chuyên gia khi nói đến các hệ thống cơ sở dữ liệu. Và ông ấy đã xây dựng một công ty tên là Imperial Provisity được Figma mua lại, công ty này nói về trích xuất tài liệu. Ông ấy cần để đội ngũ học máy (ML team) ra ngoài đó. Và bởi vì ông ấy nhận ra, việc xây dựng các đánh giá này rất khó, việc hiểu các dấu vết sản xuất (production traces) rất khó. Vì vậy, chúng tôi đang gặp vấn đề này, tôi chắc rằng có những tổ chức khác cũng đang làm như vậy. Và vì vậy ông ấy đã thành lập Brain Trust, để thực sự giúp thực hiện điều này ở quy mô lớn.
Giới thiệu Brain Trust và Vòng Lặp Flywheel
Khi chúng tôi xử lý và phân tích các traces đi vào, và một lần nữa, vì đây là dữ liệu semi-structured (bán cấu trúc) thay đổi rất nhiều, chúng tôi nhận ra rằng các hệ thống phân tích truyền thống không còn phù hợp. Vì vậy, chúng tôi đã tạo ra một danh mục cơ sở dữ liệu mới mang tên Brain Trust, thực sự giúp xác định và tăng tốc quá trình này ở quy mô lớn. Một lần nữa, chúng tôi làm việc với các nền tảng agnostic (không phụ thuộc vào nền tảng). Vì vậy, bất kể framework tác nhân hay các nhà cung cấp LLM nào bạn đang sử dụng, chúng tôi đều mong muốn giúp bạn mang lại giá trị.
Một điều tôi sẽ nói khi chúng ta tiến hành workshop này là khái niệm flywheel (vòng quay liên tục). Nếu bạn đã từng làm việc với phát triển Agile, bạn biết rằng sự hoàn hảo là kẻ thù của cái tốt. Chúng ta muốn bắt đầu từ một điểm nào đó. Ngay cả khi đó là một ứng dụng mới và bạn không biết nó sẽ hoạt động ra sao trong sản xuất, chúng ta có thể bắt đầu với một bộ đánh giá. Nếu bạn có một ứng dụng hiện có để tích hợp công cụ/đo lường, điều đó thật tuyệt. Chúng ta có thể thu thập thông tin đó và xác định các chế độ lỗi tại đây. Vì vậy, điều quan trọng là đưa thông tin vào hệ thống, xác định các chế độ đó, khắc phục, triển khai, sau đó giám sát và hoàn thành flywheel lặp đi lặp lại để bạn đạt được một kết quả thống nhất.
Train Line: Nền Tảng Đặt Vé Tàu và Trợ Lý Du Lịch AI
Bây giờ, tôi sẽ nhường lời cho các đồng nghiệp của tôi tại Train Line để họ chia sẻ kinh nghiệm của mình, cụ thể là trước khi sử dụng Brain Trust và cách họ đang được giúp đỡ. Osama, bạn có thể bắt đầu. Cảm ơn rất nhiều. Và xin chào một lần nữa những người mới tham gia cùng chúng tôi. Như đã giới thiệu, Train Line là một công ty thực sự giúp mọi người di chuyển bằng tàu hỏa. Tàu hỏa khác với máy bay nếu bạn chưa biết. Có một hệ thống trung tâm trên toàn thế giới dành cho tất cả các chuyến bay, nhưng điều này không đúng với tàu hỏa. Ở Châu Âu và Vương quốc Anh, tôi phải nói là rất khó, nếu bạn muốn cài đặt một ứng dụng cho mỗi hãng vận chuyển, chắc chắn nó sẽ chiếm toàn bộ không gian trên điện thoại di động của bạn.
Vì vậy, Train Line thực sự là một nền tảng cơ bản giúp bạn đặt vé, là một ứng dụng di động agnostic (không phụ thuộc vào nền tảng), agnostic với nhà cung cấp dịch vụ vận chuyển. Bạn làm điều đó trên một ứng dụng và bạn có thể đặt vé tàu từ Paris đến London, từ Lyon đến Milan, bất cứ khi nào bạn muốn, với mọi nhà cung cấp dịch vụ ở EU. Chúng tôi bán gần 6,3 tỷ vé tàu, 27 triệu hoạt động và vẫn đang tiếp tục tăng. Và có lẽ một điều thú vị khác cho hội nghị này là số lượng cuộc hội thoại AI mà chúng tôi có với trợ lý du lịch của mình. Chúng tôi có một trợ lý du lịch được công khai cho mọi người. Và nó không chỉ là một chatbot. Nó thực sự là một hệ thống đa tác nhân có thể xử lý hoàn tiền cho bạn, có thể xử lý việc đổi tàu cho bạn. Vì vậy, nó là một hệ thống tác nhân rất chủ động, tôi phải nói vậy, chứ không chỉ là một chatbot. Có lẽ các đồng nghiệp của tôi muốn bổ sung thêm về điều đó. Vậy lợi ích của việc có 27 triệu khách hàng đang hoạt động là gì? Bạn có một không gian rộng lớn về cách bạn có thể phục vụ các ứng dụng tác nhân trực tiếp cho khách hàng. Osama đã nói về các ví dụ về điều đó, đó là trợ lý du lịch mà bạn có thể truy cập từ cửa sổ vé trong ứng dụng. Đó là một hệ thống tác nhân, điều mà chúng ta sẽ nói thêm một chút ở phần sau của slide. Tuyệt vời. Chúng ta nên chuyển sang điểm tiếp theo.
Học Máy và AI Tạo Sinh tại Train Line
Tôi sẽ nói ngắn gọn. Là một công ty bán vé tàu, tại sao chúng tôi lại làm học máy? Tất nhiên là chúng tôi có thể. Có rất nhiều điều phải làm và để giúp mọi người trong hành trình của họ, mua vé, đi tàu, về nhà. Chúng tôi làm hai việc. Phần ML truyền thống, đó là xây dựng các mô hình, chúng tôi làm điều đó. Chúng tôi xây dựng các mô hình ML bên trong Train Line từ đầu, từ dữ liệu đến mô hình. Đây là điều chúng tôi làm. Và chúng tôi cũng xây dựng các hệ thống AI tạo sinh dựa trên đa tác nhân mà chúng ta đã quen thuộc, trên các LLM mà chúng ta yêu thích và trân trọng, cùng với các công cụ và kỹ thuật ngữ cảnh và tất cả những thứ đó. Chúng tôi làm cả hai khía cạnh này tại Train Line.
Đây là hai ví dụ về những gì người dùng đang sử dụng trên các hệ thống đó ở phía bên trái. Vì vậy, bạn có thể coi đây là ứng dụng thời tiết của bạn nhưng dành cho các sự cố gián đoạn tàu. Về cơ bản, bạn có vé tàu. Bạn đến đó. Chúng tôi biết liệu chuyến tàu này có bị gián đoạn hay không, liệu nó có khả năng bị trễ hay không. Chúng tôi biết điều đó dựa trên lượng dữ liệu khổng lồ mà chúng tôi có, dựa trên mô hình học máy đã được huấn luyện và thực sự có thể dự đoán các sự cố gián đoạn tàu, việc trễ tàu và tất cả những điều đó. Vì vậy, đây là phần ML truyền thống.
Ví dụ còn lại là trợ lý du lịch mà tôi đã nói với bạn. Nó rất, như tôi đã nói, tôi phải nói là một hệ thống đa tác nhân rất tiên tiến. Nó có thể hiển thị cho bạn các chuyến tàu thay thế nếu tàu của bạn bị hủy hoặc có vấn đề gì đó. Chúc bạn may mắn khi tự mình làm điều đó ngay cả với Chat GPT. Và ví dụ khác là xử lý hoàn tiền. Vì vậy, bạn thực sự có thể yêu cầu hoàn tiền cho vé của mình nếu tàu của bạn bị trễ hoặc tất cả những điều đó và nó thực sự có thể cung cấp cho bạn tất cả những điều đó mà không cần chuyển giao. Và cũng có thể chuyển giao cho bộ phận hỗ trợ khách hàng là người thật trong nhóm hỗ trợ khách hàng đáng yêu của chúng tôi. Điều đó có nghĩa là nếu bạn đang làm điều này ở cấp độ sản xuất và ở quy mô Train Line, điều đó có nghĩa là hoặc bạn có thể đặt câu hỏi liệu chúng tôi có đang gây ra sự cố tại Train Line không? Tất nhiên, chúng tôi không muốn làm điều đó. Và chúng tôi đang di chuyển nhanh chóng vì công nghệ chắc chắn đang di chuyển nhanh chóng. Và đây là lý do tại sao chúng tôi ở đây. Chúng tôi ở đây để cho bạn thấy chúng tôi đang làm gì để di chuyển nhanh chóng mà không gây ra sự cố về AI. Và chúng tôi có thể làm điều đó trên cơ sở xử lý các hệ thống phần mềm phức tạp mà chúng tôi yêu thích và trân trọng, từ API đến quy mô lớn và phục vụ hàng triệu người dùng.
Quản Lý Hệ Thống Phần Mềm Xác Định và Không Xác Định
Cách chúng tôi muốn suy nghĩ về điều này là theo quy mô. Vì vậy, chúng tôi chắc chắn rằng bất cứ hệ thống phần mềm nào chúng tôi có đều là khía cạnh xác định (deterministic) của vấn đề. Và mặt khác, việc xây dựng các mô hình ML, đây là khía cạnh không xác định (non-deterministic) của vấn đề. Và chúng tôi chắc chắn rằng sự tồn tại của tác nhân nằm ở giữa. Có những phần của chúng là xác định. Có những phần của chúng chắc chắn không xác định. Và đây là khung làm việc tư duy mà chúng tôi có.
Về chất lượng, chúng tôi xử lý nó như thế nào? Đó là câu hỏi. Đối với các mô hình ML, chúng tôi quan tâm đến chất lượng dữ liệu mà chúng tôi sử dụng để huấn luyện các mô hình. Nhưng chúng tôi cũng có trên đó, tất nhiên, các đánh giá học máy, dù là ngoại tuyến hay trực tuyến. Ngoại tuyến có nghĩa là trước khi đưa vào sản xuất, bạn cần thực hiện các đánh giá của mình. Và trực tuyến là dữ liệu bạn nhận được từ môi trường sản xuất. Và đánh giá mô hình của bạn xem nó có hoạt động tốt hay không. Trong trường hợp của chúng tôi, ví dụ, đối với dự báo đó, liệu nó có dự đoán đúng trạng thái của chuyến tàu nếu nó bị gián đoạn hay không? Liệu mô hình có chính xác trong dự đoán của nó hay không? Đó là một ví dụ.
Mặt khác, đối với những người quen thuộc với kỹ thuật phần mềm, chúng tôi thực hiện tất cả các kiểm tra chất lượng, sơ đồ và công cụ mà chúng tôi có để xử lý chất lượng ở quy mô lớn, quy mô rất lớn tại Train Line. Và đối với các hệ thống đó, tôi nghĩ bạn đã đoán được, nó về cơ bản là sự kết hợp của cả hai. Chắc chắn không có cái này mà không có cái kia. Chúng tôi làm mọi thứ mà chúng tôi thực hiện về chất lượng trong các hệ thống xác định, nhưng chúng tôi cũng sử dụng khía cạnh đánh giá từ các hệ thống không xác định. Vì vậy, vâng, đó là khung làm việc tư duy mà chúng tôi có tại Train Line khi suy nghĩ về các hệ thống này. Và chắc chắn, Brain Trust đang giúp đỡ điều đó. Và nhân tiện, tuyên bố miễn trừ trách nhiệm: chúng tôi không, tôi phải nói là, chúng tôi ở đây chỉ vì chúng tôi tin rằng Brain Trust hoạt động hiệu quả với chúng tôi. Chúng tôi không được trả tiền. Vì vậy, đó là 100%. Chúng tôi là những khách hàng hài lòng. Chúng tôi đã sử dụng Brain Trust trong một thời gian dài. Và chúng tôi sử dụng nó trong các tính năng khác nhau của Brain Trust. Chúng tôi thực sự sử dụng chúng ở đây. Ví dụ, đối với các đánh giá ML AI, chúng tôi làm điều đó. Và chúng tôi theo dõi điểm số của trợ lý du lịch ở nhiều cấp độ, từ ngữ điệu cho đến khả năng giúp đỡ thực tế khi liên quan đến vé. Và vé thực sự, tôi phải nói là rất phức tạp về mặt lý luận (reasoning) và những gì bạn nên nhận được, những gì bạn không nhận được, tùy thuộc vào việc tàu có bị trễ hay không, loại vé là vé khứ hồi hay vé đặt trước. Có rất nhiều trường hợp phức tạp. Nhưng vâng, chúng tôi theo dõi khía cạnh đánh giá đó.
Tối Ưu Hóa Chi Phí LLM và Triển Khai Nhanh Chóng với Brain Trust
Có ai trong số các bạn đã từng gặp khó khăn với chi phí LLM, số lượng mã thông báo, việc chuyển đổi mô hình, những vấn đề như vậy không? Vâng, thật vui khi thấy. Đó cũng là một vấn đề với Train Line vì chúng tôi làm điều này ở quy mô lớn và số lượng OpenAI cũng như lượng traffic mà chúng tôi phải trả cứ như thế này. Vì vậy, chúng tôi phải liên tục chuyển đổi mô hình, chọn mô hình tốt nhất cho một trường hợp sử dụng, các mô hình rẻ hơn, các mô hình với mã thông báo hiệu quả. Bây giờ, bất cứ khi nào bạn muốn chuyển đổi mô hình, bạn muốn đảm bảo rằng nó hoạt động ít nhất ở cùng mức độ với mô hình hiện tại của bạn, đúng không? Trước Brain Trust, chúng tôi không có cách cụ thể nào để làm điều đó vì chúng tôi không có điểm số được thiết lập, chúng tôi không có, bạn biết đấy, kiểu đánh giá nào cả.
Với việc sử dụng Brain Trust, nó đã giúp chúng tôi có thể mô phỏng hiệu suất của mô hình thấp hơn sẽ trông như thế nào và chúng tôi đã sử dụng Brain Trust rộng rãi để chạy đánh giá ngoại tuyến và xem hiệu quả sẽ ra sao, và cả đánh giá trực tuyến để thấy rằng hiệu quả dự định mà chúng tôi quan sát được ngoại tuyến là đúng như mong đợi. Vì vậy, tôi nghĩ đó là một trong những trường hợp sử dụng. Một trường hợp khác mang tính tổng quát hơn, đó là chúng tôi sẽ mất rất nhiều thời gian để đánh giá một tính năng mới được triển khai vào trợ lý du lịch, nhưng với Brain Trust, chúng tôi đã có thể đảm bảo rằng chúng tôi tin tưởng trải nghiệm mới với người dùng sẽ tốt. Vì vậy, Brain Trust đã giúp chúng tôi rất nhiều trong việc triển khai nhanh chóng.
Khả Năng Quan Sát và Hợp Tác Liên Chức Năng
Và phần khác chắc chắn là khả năng quan sát. Chúng tôi sử dụng Brain Trust cho khả năng quan sát nếu cái này đang hoạt động. Vâng, đây là ví dụ thực tế từ Brain Trust. Chúng tôi về cơ bản đang giới thiệu những gì bạn sẽ thấy trong workshop. Nhưng vâng, chúng tôi có thể theo dõi mọi thứ chúng tôi đang làm, gọi công cụ (tool calling), tác nhân khác, về số lượng, về chất lượng, những loại hiểu biết sâu sắc đó, bạn sẽ cần chúng để chuyển từ chứng minh khái niệm sang hệ thống thực tế trong sản xuất hoặc trong công ty của bạn hoặc cho một sản phẩm thực sự đang được sử dụng và người dùng thấy nó là một sản phẩm hoạt động thực sự chứ không phải chỉ là một hệ thống được tạo ra bởi AI. Không, chúng tôi chắc chắn cần điều đó cho những trường hợp đó.
Có muốn bổ sung gì ở đây không? Tôi chỉ muốn nói rằng Brain Trust cho phép bạn nhìn vào bên trong các quy trình làm việc tác nhân phức tạp, đến cấp độ gọi công cụ, cấp độ mã thông báo, điều này rất sâu sắc và giúp bạn gỡ lỗi rất nhiều thứ trong sản xuất và trước khi bạn triển khai nó.
Và một điều cuối cùng có lẽ là điểm thân thiện với các nhóm chức năng chéo. Đó là điều mà chúng tôi đã khám phá ra trong quá trình làm việc bởi vì chúng tôi đang xây dựng các hệ thống đó từ trợ lý du lịch đến các mô hình. Đến một thời điểm nào đó, chúng tôi cần có, chúng tôi là một công ty lớn và chúng tôi có những người từ bộ phận sản phẩm với nền tảng phi kỹ thuật và chúng tôi cần giao tiếp và chúng tôi cần chia sẻ nhiều thứ và họ cũng cần tự phục vụ một số thứ đó. Chúng tôi không thể nói, "hãy chăm sóc" bất kỳ ai và nói, "này, bạn nên làm cái này. Để tôi lấy nhật ký, tải xuống và gửi cho bạn." Điều đó không hiệu quả. Ở quy mô lớn, chúng tôi cần một cách mà chúng tôi có thể giúp, tôi phải nói là, chúng tôi có thể làm việc theo cách liên chức năng và để mọi người được, tôi phải nói là, tự do làm bất cứ điều gì họ muốn và tự phục vụ với dữ liệu và hiểu biết sâu sắc. Vì vậy, đây là những gì chúng tôi cũng đã khám phá ra trong quá trình làm việc và Brain Trust cũng giúp ích rất nhiều với nhiều yêu cầu mà chúng tôi không thể có, nhưng chúng tôi thực sự đánh giá cao. Và tất nhiên còn nhiều hơn nữa, chúng tôi chỉ đang sử dụng một phần của hệ thống đó. Chúng tôi có những thứ riêng của mình, Brain Trust, tôi nghĩ bạn đang xây dựng thêm nhiều công cụ nữa. Vì vậy, chắc chắn còn nhiều điều nữa sẽ đến, tôi nghĩ workshop chắc chắn sẽ giúp bạn khám phá tất cả những điều đó.
Chuẩn bị Hội thảo
Và tất nhiên, thật vui khi được xây dựng trong buổi hội thảo này. Mọi người có thể mở máy tính xách tay ra. Nếu bạn quan tâm, Train Line đang tuyển dụng trong lĩnh vực A&G và nội bộ. Vâng, tôi xin chuyển lời cho bạn, được chứ? Tuyệt vời. Cảm ơn rất nhiều về điều đó, đội ngũ. Và một lần nữa, tôi muốn gửi lời cảm ơn cá nhân, cũng như từ phía vợ tôi. Chúng tôi rất cảm ơn vì chức năng lưu phân tách (split-save functionality). Hãy cho tôi biết màu sắc của nó. Được rồi, đội ngũ. Bây giờ, chúng ta hãy tiến hành cài đặt.
Thiết lập Môi trường Hội thảo
Một lần nữa, đây sẽ là một buổi hội thảo thực hành. Tốt hơn hết là hãy chuẩn bị sẵn sàng các skill bash của bạn. Đùa thôi, tôi đã có một lệnh wrapper tiện lợi để giúp mọi người. Hy vọng mọi người, hoặc ít nhất là hầu hết các bạn, đã tham gia tổ chức Slack dành cho AI Engineer và cũng đã tham gia kênh còn lại. Tôi đã đặt một liên kết tới đây, nhưng cũng có một mã QR đến kho lưu trữ (repository) mà chúng ta sẽ sử dụng. Tôi sẽ dành vài phút cho việc này. Những điều thực sự quan trọng là đăng ký một tài khoản Brain Trust miễn phí. Nếu bạn sử dụng Gmail, bạn có thể dùng mẹo thêm dấu cộng để tạo tài khoản của mình. Nếu bạn là người dùng Brain Trust hiện có, thì hy vọng điều này sẽ không làm ảnh hưởng đến tài khoản hiện tại của bạn, bạn cũng sẽ cần quyền truy cập vào một Khóa API OpenAI mà bạn có thể dễ dàng tạo. Nếu vì lý do nào đó bạn không thể tạo khóa, vui lòng cho đồng nghiệp của tôi biết. Chúng tôi sẽ có thể gửi và DM cho bạn trên Slack để sử dụng cho buổi học cụ thể này. Và tôi nghĩ, rõ ràng là với tư cách một hội nghị kỹ thuật, đặc biệt là về AI, nếu bạn đang sử dụng hỗ trợ lập trình AI (AI coding assistance), hãy thoải mái sử dụng nó với IDE hoặc trong terminal để được hướng dẫn, đặt câu hỏi về cơ sở mã và những thứ tương tự. Tôi đã cố gắng đơn giản hóa rất nhiều phần khung (scaffolding) hiện có. Vì vậy, tôi đang sử dụng mise để quản lý Node và PNPM trên máy, nhưng bạn cũng có thể tải xuống Node v2-2 ở phiên bản cụ thể đó. Nó sẽ ổn, nhưng một lần nữa, tôi chỉ muốn lưu ý, đặc biệt cho buổi hội thảo này, tôi đã sửa chữa cụ thể đó, có thể nói là một lần. Tôi đang sử dụng make để một lần nữa, một số cú pháp bên ngoài (syntax exterior) để đóng gói các lệnh. Nếu vì lý do nào đó bạn không cài đặt make, nếu bạn đang dùng máy Windows, bạn có thể chỉ cần chạy các lệnh PNPM, đó chỉ là các wrapper cho tệp package.json. Tôi nghe vậy hôm nay. Vì vậy, vâng, chúng tôi sẽ dành vài phút để mọi người quét và clone. Tôi cũng muốn chỉ ra rằng hôm nay tôi có một bản hướng dẫn. Tôi thấy nhiều người đã xem qua, nhưng vâng, chúng tôi cung cấp một hướng dẫn từng bước. Như đã đề cập, khi chúng ta tiến hành buổi hội thảo hôm nay, nếu bạn gặp khó khăn, vui lòng đặt câu hỏi trên kênh Slack, nhưng cũng có thể tham khảo điều này. Như đã đề cập, đây sẽ là một tài nguyên công khai, vì vậy ngay cả khi bạn không tham gia hội thảo này, nếu bạn gặp khó khăn, bạn có thể tự mình xem lại bất cứ lúc nào. Giờ thì, xin cho tôi hỏi: Ai ở đây không thể nhận được Khóa API OpenAI? Hy vọng mọi người có thể cung cấp được nó. Điều này thực sự quan trọng. Vâng. Một số người mới tham gia. Không có mã QR cho Slack. Tôi có thể làm điều đó. Được rồi mọi người, tôi nghĩ chúng ta có một vài người đến muộn, vì vậy tôi sẽ không dành quá nhiều thời gian cho phần này, nhưng nếu bạn tham gia muộn, vui lòng quét mã QR đó để có quyền truy cập vào tổ chức Slack kỹ thuật AI, và sau đó tham gia kênh AI Engineer Europe 2026 Brain Trust Workshop. Đây là một kênh công khai. Thông qua kênh đó, bạn sẽ có thể truy cập vào nội dung được ghim: kho lưu trữ (repository) cũng như một cheat sheet (tài liệu hướng dẫn nhanh), mà chúng ta cũng sẽ theo dõi. Mọi người kiểm tra lại chút nhé. Hy vọng hầu hết các bạn đều có thể tham gia kênh Slack và có thể clone kho lưu trữ và truy cập vào đó. Được rồi.
Xây dựng Tác nhân Phân loại Hỗ trợ Mẫu
Như tôi đã đề cập ngay từ đầu trong chương trình nghị sự, những gì chúng ta sẽ làm là tạo một ví dụ về một tác nhân phân loại hỗ trợ (support triage agent). Hy vọng điều này sẽ minh họa cho nhiều hệ thống mà mọi người có thể đã xây dựng hoặc đang cố gắng xây dựng. Đây là một ứng dụng hư cấu được thiết kế đặc biệt cho buổi hội thảo. Vui lòng không sử dụng nó trong môi trường sản xuất. Mục đích chỉ là để dạy chúng ta cách xây dựng các mô hình AI này và mở rộng quy mô. Vì vậy, ý tưởng là khi một yêu cầu (ticket) được tạo trong hệ thống cụ thể, chúng ta có một tập hợp các tác nhân đi qua một quy trình theo từng giai đoạn (stage process) gọi công cụ (tool calling) để tạo ra một tập hợp thông tin có thể được phát ra cho các hệ thống hạ nguồn (downstream systems) từ góc độ đó. Để giúp hình dung cách hệ thống hoạt động: Một lần nữa, chúng ta nhận đầu vào là một yêu cầu. Chúng ta có bước đầu tiên là thu thập ngữ cảnh (context). Đây là một cách trích xuất thông tin khá xác định. Sau đó, chúng ta tiến hành phần phân loại (triage portion) nơi chúng ta đã chia thành ba giai đoạn. Vì vậy, chúng ta có một Mô hình Ngôn ngữ Lớn (LLM) và các lời gọi công cụ (tool calls) để phân loại vấn đề cụ thể đó. Sau đó, chúng ta muốn có một người đánh giá chính sách (policy reviewer) để đảm bảo đầu ra là chính xác. Sau đó, chúng ta muốn tạo và soạn thảo một câu trả lời cho khách hàng bằng một công cụ viết trả lời (reply writer). Và sau đó chúng ta muốn đóng gói (package) tất cả lại. Và tùy thuộc vào mức độ nghiêm trọng của yêu cầu cụ thể này, chúng ta có thể gọi một công cụ khác để xác định xem chúng ta có cần leo thang vấn đề này cho một người tham gia (human in the loop) hay không, và sau đó soạn thảo kết quả cuối cùng. Vì vậy, một lần nữa, không quá phức tạp, nhưng chỉ để cung cấp cho bạn ý tưởng về hệ thống mà chúng ta sẽ cố gắng xây dựng và vận hành trong buổi học.
Vai trò của Brain Trust trong Triển khai Tác nhân
Một điều cần lưu ý là khi chúng ta bắt đầu sử dụng Brain Trust, vấn đề thực sự là nó phù hợp ở đâu để giúp bạn triển khai và quản lý các tác nhân ở quy mô lớn. Tôi đã cô lập điều này ở đây, nơi mọi thứ chúng ta sẽ làm về cuối, đặc biệt là khi chúng ta tiến hành hoặc theo dõi nó từ đầu đến cuối (end-to-end) như các đồng nghiệp của tôi đã nói. Chúng ta sẽ sử dụng chế độ được quản lý (managed mode) cho lời nhắc, tức là chuyển những gì bạn làm cục bộ vào một môi trường an toàn. Các lời gọi công cụ (tool calls) cũng sẽ được quản lý. Vậy thì, làm thế nào để bạn nói về việc truy cập vào các hệ thống bên ngoài và sau đó hỏi về các đánh giá và điểm số, những thứ sẽ được chạy qua cơ sở hạ tầng Brain Trust của chúng tôi. Cũng cần chỉ ra rằng, nếu bạn truy cập vào kho lưu trữ GitHub, cũng có một phiên bản GitHub Pages của tài liệu này. Vì vậy, các slide sẽ luôn sẵn sàng để bạn sử dụng và xem.
Điều hướng và Điểm kiểm tra Hội thảo
Được rồi, một điều quan trọng nữa là tôi đã cố gắng giúp bạn qua từng giai đoạn và điểm kiểm tra (checkpoint) này. Vì vậy, nếu bạn gặp khó khăn, ý tưởng chỉ là bạn git checkout tới một tag hoặc nhánh cụ thể. Trong trường hợp này, mỗi tag hoặc nhánh riêng lẻ đều có thể chạy được hoàn chỉnh ở giai đoạn đó. Vì vậy, nếu bạn gặp khó khăn lần nữa, hãy git checkout tới nhánh đó, đảm bảo bạn chạy make setup, thực thi các lệnh, và sau đó bạn sẽ nhận được đầu ra gần như giống hệt nhau mỗi lần. Một lần nữa, tất cả điều này đều được ghi lại trong tệp README, nhưng cũng được bao gồm trong cheat sheet (tài liệu hướng dẫn nhanh) để bạn tiến hành.
Lộ trình Hội thảo
Được rồi, vâng, chỉ để cung cấp cho bạn trình tự các sự kiện, chúng ta sẽ thực hiện việc dựng khung (scaffolding) và thiết lập. Tôi sẽ nói về việc xây dựng một tác nhân cơ bản. Một lần nữa, buổi hội thảo này thực sự không được thiết kế để nói về việc xây dựng các tác nhân. Vấn đề là, một khi bạn có một tác nhân, làm thế nào để bạn vận hành (operationalize) nó? Vì vậy, để ngắn gọn, chúng ta sẽ thực hiện từng bước, và sau đó chúng ta sẽ đi vào phần cốt lõi nơi chúng ta sẽ thêm tính năng truy vết (tracing), nói về các đánh giá, bạn biết đấy, nói về tập dữ liệu vàng (golden set) và xác định nơi chúng ta có thể cải thiện. Và sau đó toàn bộ quá trình cùng với nhau, sử dụng cơ sở hạ tầng được quản lý (managed infrastructure) trong Brain Trust để giúp vận hành điều này. Và một lần nữa, nói về sự hợp tác mà các đồng nghiệp của tôi tại Train Line đã nói đến. Một điều quan trọng nữa là, một khi bạn xác định được một lỗi sản xuất (production failure), làm thế nào để chúng ta áp dụng các sửa lỗi và hoàn thành vòng lặp (flywheel) đó để mang lại cho bạn một tài sản hoàn chỉnh (finalized asset).
Bước 1: Xây dựng Tác nhân Cơ bản
Được rồi, vậy thì bước một, chúng ta sẽ nói về việc xây dựng tác nhân. Vì vậy, ở điểm kiểm tra này, một lần nữa, chúng ta cần bắt đầu từ một nơi nào đó, phải không? Vậy chúng ta làm gì? Chúng ta sẽ thực hiện một cuộc gọi ban đầu đến một Mô hình Ngôn ngữ Lớn (LLM), chúng ta sẽ thiết lập một lời nhắc (một lượt hỏi-đáp, một đầu vào, một đầu ra) và nhận được một đầu ra. Vì vậy, một lần nữa, nếu bạn đang thực hiện một bằng chứng khái niệm (proof of concept), điều này có thể rất tuyệt như một phần của sự khởi đầu ban đầu, nhưng một lần nữa, chúng ta biết rằng còn rất nhiều việc phải làm. Nhưng vâng, đối với ngữ cảnh, chúng ta sẽ chỉ đi qua điều này. Nhưng như tôi đã đề cập, chỉ vì nó hoạt động trong bản demo không có nghĩa là nó đã có thể hoạt động trong môi trường sản xuất. Tôi đã đặt một số mã giả (pseudocode) ở đây để trình bày rõ hơn, nhưng bạn có thể thấy ở đây, với tất cả các mô hình ngôn ngữ này, chúng ta cung cấp một tập hợp lời nhắc trợ lý, chúng ta cung cấp người dùng, và đặc biệt là văn bản, và chúng ta chuyển đầu ra của nó trở lại ứng dụng của mình. Vì vậy, một hàm, một lời gọi mô hình, chúng ta có đầu ra có cấu trúc (structured output) mà chúng ta muốn nhận làm một phần của đầu ra. Vì vậy, những gì chúng ta sẽ làm là, khi chúng ta thực hiện việc dựng khung (scaffolding) và checkout sang nhánh đầu tiên, chúng ta sẽ nhận được một tập hợp các yêu cầu mẫu, vì vậy đây là một trường hợp đã được thực hiện trong mã, hoặc bạn có thể sử dụng giao diện dòng lệnh (command line), vì vậy tôi sẽ trình bày ngắn gọn về cách nó sẽ trông như thế nào với các đầu ra, và bạn sẽ nhận được một cái gì đó tương tự ở định dạng JSON. Hy vọng mọi người có thể thấy điều này vào lúc này. Tôi có ứng dụng ở đây. Vì vậy, tôi sẽ chỉ đi đến basic checkout. Tôi sẽ kiểm tra nó. Và đây là gì? Vậy thì, nếu tôi xem xét ở đây, tôi hiện đã checkout sang nhánh đầu tiên đó, đó là việc xây dựng tác nhân cơ bản. Tôi có ứng dụng ở đây, một lần nữa rất giống với mã lời nhắc. Chúng ta đang tạo một máy khách, gọi OpenAI SDK. Một lần nữa, để ngắn gọn, tôi không sử dụng bất kỳ SDK tác nhân nào, nhưng chúng tôi hoàn toàn hỗ trợ điều đó khi chúng ta tiến hành buổi hội thảo. Vì vậy, điều này thực sự có sẵn, và bạn sẽ thấy một lần nữa từ Makefile, nếu bạn không cài đặt make, thì bạn chỉ có thể thực thi các script PNPM, hoặc tôi không biết nếu bạn sử dụng NPM hoặc Yarn. Điều đó cũng có thể. Tôi chưa kiểm tra nó, nhưng việc tìm hiểu sẽ hoạt động vì nó chỉ sử dụng tệp package.json. Vì vậy, trong trường hợp này, giả sử bạn muốn làm điều gì đó như make tickets. Vì vậy, tôi muốn đưa ra một thứ, nói rằng, 'mật khẩu của tôi cần được đặt lại.' Trong trường hợp này, tôi đã cung cấp một số giá trị mặc định, một số enter, enter, enter. Và bây giờ nó chỉ đang thực hiện một cuộc gọi đến OpenAI. Tôi chỉ đang sử dụng, bạn có thể sẽ thấy từ tệp biến môi trường, tôi đang sử dụng GPT-5 Mini. Bạn có thể thay đổi nó nếu muốn, nhưng với mục đích này, chúng ta sẽ giữ nó đơn giản. Vì vậy, bạn có thể thấy ở đây, tôi có yêu cầu, và nó cũng đã cung cấp một số đầu ra ở đây. Nhưng một lần nữa, đó là một lượt hỏi-đáp duy nhất. Tôi nghĩ chúng ta đã, tôi đang gặp một số vấn đề. Vì vậy, bạn biết đấy, dựa trên đầu ra này, nó trông khá hợp lý, nhưng một lần nữa, nó sẽ không giải quyết được nhiều trường hợp biên (edge cases) mà chúng ta muốn, đặc biệt nếu bạn có nhiều sắc thái mới cho tổ chức mà chúng ta đang cố gắng xây dựng thành logic ở đây. Tôi đang đi vào những thứ như make demo. Vì vậy, make demo, nếu bạn muốn viết script, nó cũng vậy. Tôi chỉ đang gọi cùng một hàm, nhưng tôi đã mã hóa nó dưới dạng JSON ở đây. Vì vậy, các trường JSON có sẵn để xem. Khá đơn giản. Tôi không muốn đi sâu vào đó quá nhiều.
Thêm các Công cụ để Nâng cao Khả năng Xác định
Vậy thì, điều tiếp theo tôi muốn làm là nói về việc thêm các công cụ ghi nhật ký tài khoản (account log tools). Vì vậy, chúng ta có thể muốn nói rằng, 'hãy cố gắng làm cho điều này trở nên xác định hơn một chút.' Ngay cả khi một lời nhắc có thể được cấu trúc rất tốt, tôi có thể muốn đưa vào các cách hoạt động khác nhau. Vì vậy, trong trường hợp này, tôi đang gọi ba công cụ khác nhau để xem các bài viết help desk liên quan. Sẽ có cả bài viết nội bộ và bên ngoài. Tôi có thể muốn xem xét một số điều đã xảy ra với các tài khoản. Vì vậy, theo cách tương tự, tôi đang tùy chỉnh; tôi đã thực hiện một cuộc di chuyển nhất định, và điều đó có thể có tác động đến các hệ thống backend. Và có lẽ có một lý do mà tôi muốn tạo một sự leo thang ở đây. Trong trường hợp này, những gì tôi đã làm là tôi đã làm cho nó trở nên xác định hơn một chút. Với mục đích của buổi hội thảo này, một lần nữa, điều này được coi là mã, nhưng trên thực tế, bạn có thể sẽ giao tiếp với các hệ thống bên ngoài như một tìm kiếm vector (vector search), MCPC, CLI, và tất cả các loại giao diện để xây dựng khả năng này. Và một lần nữa, điều quan trọng ở đây là bạn càng thêm nhiều công cụ, số lượng cách bạn có thể thất bại cũng sẽ tăng lên.
Giới thiệu về Tracing và Local Tools
Vì vậy, một lần nữa, đây là lý do tại sao tracing (theo dõi), khi chúng ta bắt đầu, sẽ trở nên quan trọng hơn. Vậy là có một cái ở đây. Một lần nữa, hãy tham khảo readme ở đây. Điều tiếp theo chúng ta sẽ làm là đi tới các công cụ cục bộ. Trong trường hợp này, các công cụ mà tôi đã tạo sau đó sẽ có sẵn ở đây. Nhưng một lần nữa, chúng chỉ được đưa vào như code để đơn giản hóa. Và một lần nữa, tôi có thể làm điều tương tự, bạn tạo một ticket (yêu cầu), nói rằng "cần đặt lại mật khẩu, tài khoản bị khóa". Được rồi. Giờ thì, nó đã cung cấp thêm một chút thông tin. Bạn có thể thấy nó chi tiết hơn một chút vì chúng ta đã đưa các lệnh gọi công cụ vào đây và cung cấp thêm ngữ cảnh cho Mô hình Ngôn ngữ Lớn (LLM).
Cũng cần lưu ý ở đây: nếu bạn cảm thấy bế tắc, nhiều phần trong số này hoạt động. Các tag của các nhánh workshop được xây dựng tuần tự. Vì vậy, nếu bạn truy cập vào, giả sử, git tag số sáu, nó sẽ bao gồm mọi thứ trong đó. Đừng cảm thấy bạn phải đi qua từng cái một. Nếu bạn cảm thấy bế tắc và muốn bỏ qua, bạn cũng có thể làm vậy. Được rồi, công cụ. Một lần nữa, tôi đã thực sự trình bày code rồi. Đây là một ý tưởng về mã giả sẽ trông như thế nào.
Quy trình làm việc theo giai đoạn (Stages) với Mô hình Ngôn ngữ Lớn (LLM)
Các giai đoạn. Tôi nghĩ đây là điều tiếp theo, một lần nữa, chúng ta đang chia nhỏ lệnh gọi nguyên khối từ Mô hình Ngôn ngữ Lớn (LLM). Chúng ta hiện đang giới thiệu các công cụ, và điều tiếp theo là đi sâu hơn nữa vào các giai đoạn đặc biệt về cách Mô hình Ngôn ngữ Lớn (LLM) nên hành xử. Bạn có thể đã thấy từ sơ đồ trình tự đó, nơi tôi đã thực hiện hiệu quả năm giai đoạn cho việc này: thiết lập các thứ để thu thập ngữ cảnh, phân loại, xác định xem nó có đáp ứng các chính sách thương hiệu hay không, cung cấp một câu trả lời thân thiện với khách hàng, và cũng có một phần nội bộ cho các hệ thống của chúng tôi, sau đó hoàn thiện kết quả cho các hệ thống hạ nguồn.
Một lần nữa, điều này chỉ xuất phát từ kỹ thuật phần mềm truyền thống. Bạn chia nhỏ vấn đề của mình, bạn có thể thấy chính xác nơi nào đang gặp sự cố trên stack (ngăn xếp), và bạn sẽ có thể khắc phục. Vì vậy, một lần nữa, nếu có thể, hãy cố gắng tường minh hơn và chia nhỏ nó thành các thách thức mà bạn có thể giải quyết. Vâng, chỉ là một chút mã giả. Đây là hình dung về nó sẽ trông như thế nào. Bạn có lẽ sẽ đặt một trình gỡ lỗi với một ID mới và xem xét điều đó. Được rồi, tôi đã thực hiện một phần của điều này, nhưng chúng ta đã bắt đầu với điểm khởi đầu, và sau đó tôi sẽ nói về việc thực hiện giai đoạn đặc biệt ở đây. Hãy cùng xem phần tiếp theo của readme về các giai đoạn đặc biệt.
Ví dụ về xử lý ticket và Tác nhân đa giai đoạn
Nếu tôi xem xét bây giờ, thư mục nguồn có các hàm riêng lẻ đã được tách ra. Các lời nhắc liên quan đến đó đang được sử dụng. Vì vậy, giả sử đây là một phân loại từ những gì chúng ta đang sử dụng. Nếu tôi đi xuống ứng dụng, bạn có thể thấy nó bắt đầu ở đây. Tôi đang sử dụng các hàm đồng bộ để thực thi. Tương tự như vậy, nếu tôi làm điều gì đó như, bạn biết đấy, hãy lấy nó, có lẽ tôi sẽ làm điều gì đó khác biệt. Một vấn đề cổ điển khác là gì? Ví dụ, "tôi cần nâng cấp gói của mình từ Pro lên Enterprise, nhưng trang web không hoạt động, gặp lỗi $800".
Trong trường hợp này, tôi đang ở cấp khách hàng thứ hai. Chúng ta đang nói về việc thanh toán ở đây và bộ đếm của tôi thực sự đang ở cột ba. Chỉ để cho bạn thấy, điều này là trực tiếp; nó không phải là thứ được mã hóa cứng trong hệ thống. Điều đáng chú ý nữa là giai đoạn này hơi chậm vì chúng ta đã chia nhỏ từng Mô hình Ngôn ngữ Lớn (LLM) một lần thành các lời gọi tuần tự. Vì vậy, dự kiến sẽ mất nhiều thời gian hơn một chút, nhưng một lần nữa, đó là một phần của việc xây dựng luồng ngữ nghĩa. Và bây giờ bạn có thể thấy, nó lại chi tiết hơn một chút, nhưng có nhiều suy nghĩ hơn được đưa vào tác nhân này.
Vì vậy, tôi đoán bạn có thể thấy một lần nữa, chúng ta đã nói về một vấn đề thanh toán. Bạn có thể thấy rằng nó tin rằng mức độ khẩn cấp khá cao vì khách hàng muốn nâng cấp từ một cấp khác, nhưng rõ ràng có tác động đến doanh thu. Vì vậy, trong trường hợp này, chúng ta nên leo thang (chuyển giao) cho những người thích hợp ở phía chúng tôi. Bạn có thể thấy ở đây quy trình leo thang thường nên như thế nào, và cả phản hồi nội bộ và phản hồi cho khách hàng cũng được cung cấp. Chúng tôi đã đưa vào một điểm tin cậy để nói rằng, bạn biết đấy, nếu đây là vấn đề thực sự, nhưng một lần nữa, như đã đề cập, các lệnh gọi công cụ sẽ có thể lấy thông tin từ các hệ thống khác nhau để cung cấp mức độ tin cậy cao hơn. Hoàn hảo.
Tracing và Khả năng Quan sát của Tác nhân
Được rồi, với điều đó trong tâm trí. Vì vậy, một lần nữa, chúng tôi hy vọng đã cho thấy cách chúng ta có thể xây dựng và lấy một tác nhân, chia nhỏ nó, xây dựng một cái gì đó đa giai đoạn, giới thiệu việc gọi công cụ để cung cấp cho chúng ta những gì chúng ta cần. Điều tiếp theo là cung cấp thông tin đó và bắt đầu tracing (theo dõi) nó, để chúng ta thực sự có thể thấy điều gì đang xảy ra đến từng chi tiết riêng lẻ. Và đây là lúc phần khả năng quan sát (observability) phát huy tác dụng.
Vì vậy, những gì chúng ta sẽ làm trong phần này là phân tích toàn bộ đường dẫn thực thi. Chúng ta biết rằng cấu trúc này rất lồng ghép. Vì vậy, có các lệnh gọi công cụ và có thêm các lệnh gọi hàm đằng sau chúng. Chúng ta muốn theo dõi một số điều quan trọng. Và tôi nghĩ đồng nghiệp của tôi đã chỉ ra những khó khăn ban đầu mà họ gặp phải khi nói về độ trễ, chi phí, số lượng mã thông báo, đặc biệt là thời gian cho mã thông báo đầu tiên, đó là một số liệu/thước đo rất quan trọng mà chúng ta thấy nhiều khách hàng của mình đang cố gắng xác định.
Ngoài ra, đầu vào là gì, đầu ra là gì và siêu dữ liệu liên quan đến điều này? Và sau đó, bao gồm các loại trường bổ sung để, một lần nữa, khi chúng ta nói về giám sát và khả năng quan sát (observability), chúng ta có thể truy vấn nó trong giao diện người dùng (UI) ngay lập tức và thiết lập cảnh báo khi cần. Vì vậy, một lần nữa, có một đầu ra là không đủ. Chúng ta cần hiểu toàn bộ đường dẫn thực thi, và đó là những gì tracing (theo dõi) cho phép chúng ta làm.
Cài đặt Tracing và Bộ công cụ phát triển phần mềm (SDK) đa ngôn ngữ
Vâng, chỉ để cung cấp cho bạn một ý tưởng về ngữ cảnh. Tôi biết đây là một chủ đề khá gây tranh cãi đối với một số người vì, một lần nữa, tôi đến từ nền tảng phát triển full-stack. Vì vậy, nó bao gồm cả Python, Go cũng như TypeScript. Bộ công cụ phát triển phần mềm (SDK) của chúng tôi là đa ngôn ngữ: Ruby, Go, tôi nghĩ thậm chí cả .NET, chúng tôi có một số người đang sử dụng nó. Và điều đó đều tốt. Nhưng vâng, tôi chỉ giữ TypeScript để đơn giản hóa ở đây hôm nay. Nhưng, vâng, các Bộ công cụ phát triển phần mềm (SDK) thực sự hỗ trợ một loạt các ngôn ngữ khác nhau mà bạn có thể bắt đầu tracing (theo dõi) ứng dụng của mình.
Tracing các Tác nhân đa lượt và cấu trúc lồng ghép
Vì vậy, vâng, một điều thực sự quan trọng ở đây và là một trong những thách thức mà tôi thấy ở khách hàng của chúng tôi, nói chung, là họ sẽ thực hiện một tương tác riêng lẻ đối với một parent span (khoảng thời gian gốc) duy nhất. Và điều này thậm chí áp dụng cho công việc của tôi với, giả sử, các tác nhân đa lượt, đa hội thoại. Điều chúng tôi muốn có thể làm là trace (theo dõi) điều đó thành một cấu trúc lồng ghép để bạn có thể thấy mọi thứ trong một tương tác, giả sử một cuộc hội thoại, trong một parent span. Vì vậy, điều thực sự quan trọng khi chúng ta bắt đầu instrumenting (đo lường) ứng dụng của mình là đảm bảo rằng chúng ta đang có các cấu trúc phù hợp. Nếu không, bạn sẽ không thể thấy toàn bộ tác động của việc mọi thứ có thể sai ở đâu trong ứng dụng của mình.
Một lần nữa, điều này chỉ là đọc trace (dấu vết). Hy vọng rằng, mọi người, đặc biệt là các kỹ sư phần mềm trong phòng đang sử dụng các công cụ khả năng quan sát (observability) truyền thống ngoài kia, sẽ thấy điều này không quá khác biệt. Nhưng đối với những người có thể mới làm quen với màn hình này, một trace chỉ cho phép chúng ta tìm ra không chỉ những gì đã xảy ra mà còn cả những gì đang xảy ra với ứng dụng của bạn trong thời gian thực. Vì vậy, một lần nữa, theo dõi mọi lệnh gọi, mang theo siêu dữ liệu đó, và tùy thuộc vào nơi chế độ lỗi xảy ra, chúng ta có thể xác định lộ trình khắc phục mà chúng ta cần thực hiện. Được chứ?
Thực hiện Tracing với Brain Trust
Vì vậy, ở giai đoạn tiếp theo, chúng ta sẽ thêm tracing (theo dõi) vào đây. Và sau đó chúng ta thực sự sẽ chạy nó và đi vào Brain Trust và hy vọng chúng ta sẽ thấy nó xảy ra. Nhưng có một điều tôi muốn ghi nhớ trước khi làm điều đó. Hãy xem readme của chúng ta. Nó bảo chúng ta trace (theo dõi) nó. Được rồi, bây giờ chúng ta đã sẵn sàng. Vậy là tôi đã giới thiệu một tập lệnh hỗ trợ ở đây gọi là tracing.
Vì vậy, điều chúng tôi làm khá tốt trong Bộ công cụ phát triển phần mềm (SDK) của mình là, một lần nữa, chúng tôi không muốn giới thiệu thêm độ phức tạp ở những nơi không cần thiết. Vì vậy, nếu bạn đang sử dụng Bộ công cụ phát triển phần mềm (SDK) của nhà cung cấp Mô hình Ngôn ngữ Lớn (LLM) tiêu chuẩn, bạn có thể đơn giản wrap (bọc) hàm đó. Chúng tôi cung cấp điều đó out of the box (ngay lập tức). Nhưng sau đó, khi nói đến các lệnh gọi riêng lẻ, một lần nữa, chúng tôi có thể thiết lập một số tập lệnh hỗ trợ ở đây để giúp wrap up (tổng hợp) khi cần. Nếu bạn đang sử dụng một cái gì đó như Python, thì bạn cũng có thể có một hàm decorator (hàm trang trí) cũng hữu ích. Trong trường hợp này, tôi có một hàm nhỏ hay ho giúp với parent (cha) và child (con).
Và sau đó, khi nói đến việc tracing (theo dõi) ứng dụng thực tế, bạn có thể thấy ở đây, tôi có một child span (khoảng thời gian con) đã được thực thi trong suốt quá trình này. Một lần nữa, tôi không muốn thực sự code (viết mã) điều này vào thời điểm này vì code đang mở rộng khá nhiều. Nhưng vâng, tôi chỉ muốn đi qua các khái niệm chính cho điều này. Được rồi, trước khi tôi chạy ứng dụng, tôi muốn vào giao diện người dùng (UI) của Brain Trust. Đôi khi nó có thể tạo ra một dự án thử nghiệm nếu bạn đã đăng ký tài khoản dùng thử miễn phí, vì vậy hy vọng bạn đã làm điều đó sớm hơn hôm nay. Nó sẽ tạo ra một dự án mới khi chúng ta thực thi điều này.
Một điều thực sự quan trọng nữa: nếu bạn chưa làm, hãy đi tới hồ sơ của bạn ở góc trên bên trái. Được rồi, để tôi tạo một cái. Vậy thì, bây giờ, hãy vào hồ sơ của bạn. Sau đó, nơi có chữ 'Khóa API', nhập tên của bạn cho khóa, tạo nó, và sau đó sử dụng nó trong môi trường của bạn, tệp .ENV của bạn, hoặc bảo mật nó trong một kho khóa nếu bạn đã có. Ngoài ra còn có khóa OpenAI mà chúng tôi hy vọng bạn đã tạo. Điều đó cũng nên được sử dụng trong các nhà cung cấp AI. Tôi đã đặt cái này ở cấp tổ chức. Bạn cũng có thể làm điều này cho mỗi dự án, tùy thuộc vào việc bạn muốn phân chia nó theo một nhóm hoặc môi trường cụ thể; điều đó cũng được hỗ trợ đầy đủ. Nhưng trong trường hợp này, chúng ta sẽ cần khóa này sau này khi nói đến chấm điểm được quản lý và trực tuyến.
Chỉ một chút thông tin bên lề: khóa mà bạn đã tạo, hãy đảm bảo bạn đặt nó vào tổ chức Brain Trust của bạn ở đây để sử dụng sau này.
Giám sát thực thi Tác nhân trong Brain Trust UI
Được rồi, với điều đó trong tâm trí, tôi sẽ chạy demo. Và chỉ để tham khảo, nếu bạn bị kẹt, bạn chỉ cần sử dụng make setup để đảm bảo mọi thứ đã sẵn sàng. Và trong trường hợp này, chúng ta muốn thực hiện make demo. Tôi sẽ chỉ chạy các ticket tiếp theo. Tôi giữ các ticket đó. Tôi thậm chí có thể làm điều đó bằng cách sử dụng lệnh make ticket.
Vì vậy, trong khi nó đang chạy ngầm, nếu bạn quay lại vị trí của mình, bạn sẽ thấy có một dự án gọi là helper workshop. Đó là dự án sẽ được tạo ra như một phần của workshop này hôm nay. Nếu bạn điều hướng đến tab nhật ký, bạn sẽ bắt đầu thấy điều này xuất hiện trong thời gian thực. Điều đáng chú ý, một lần nữa, nhờ vào các khả năng của chúng tôi trong Brain Trust, chúng tôi có khả năng ghi gần như tức thì vào hệ thống và đọc có sẵn ngay sau đó. Đặc biệt, nó là một hàm chặn dài.
Vì vậy, rất nhiều khách hàng của chúng tôi, đặc biệt là những người phức tạp hơn, thực sự đang sử dụng Brain Trust ở quy mô lớn và thực sự thúc đẩy giới hạn. Vì vậy, không phải trường hợp 'tôi có hàng nghìn trace (dấu vết)'. Họ đang đẩy hàng chục triệu trace cùng một lúc, trong một khoảng thời gian rất ngắn, và họ muốn có thể tổng hợp điều này. Và một lần nữa, khi bạn xây dựng sự phức tạp hơn trong ứng dụng của mình, bạn đang gửi điều này đến nhiều người dùng hơn, điều đó sẽ phát triển khá nhanh chóng, và bạn cần có một hệ thống có thể xử lý quy mô đó.
Vì vậy, khi bạn bắt đầu thấy các nhật ký xuất hiện (chúng xuất hiện theo thứ tự ngược lại), tôi sẽ xem xét cái đầu tiên ở đây và chúng ta sẽ bắt đầu thấy quá trình đo lường được trace (theo dõi). Có một nút đặc biệt ở đây cho phép bạn xem điều này ở chế độ toàn màn hình, điều mà tôi nghĩ là khá hữu ích. Như tôi đã đề cập, vì chúng ta có cấu trúc lồng ghép tại chỗ, nơi chúng ta đi qua từng nút theo kiểu cây, tương tác này ở trên cùng là demo ticket. Ở cấp độ cao nhất, chúng ta thấy rằng một lời gọi Mô hình Ngôn ngữ Lớn (LLM) đã diễn ra, cùng với các tài liệu lời nhắc, chi phí đầu vào/đầu ra, và độ trễ liên quan đến nó.
Khả năng Quan sát và Dòng thời gian
Tôi cũng đã bao gồm một số metadata vì tôi muốn có thể trích xuất và lọc chúng khi cần, và tôi sẽ chỉ cho bạn cách hoạt động. Mọi thứ đều có sẵn ở đây để xem. Metadata có ở đó. Nếu tôi muốn xem xét vấn đề này theo một cách khác, chúng ta thậm chí có thể xem xét từng bước riêng lẻ. Ví dụ, tôi muốn xem điều gì đã xảy ra với các chuyên gia nghệ thuật cây xuống đến việc gọi thực tế tới Hollumn. Vì vậy, một lần nữa, SDK cung cấp rất nhiều sự linh hoạt xung quanh việc này để bạn có thể thấy những gì đã được đưa vào, lý do đằng sau nó, và thông tin mà chúng ta đã thiết lập cho nó. Và rồi, đến phần cuối cùng, liệu nó có nên được leo thang (escalate) hay không. Một trong những chế độ xem mà chúng ta sẽ thấy là một phần của điều này là việc xem xét dòng thời gian (timeline). Điều này mang lại cho bạn ý tưởng về một phương pháp thác nước (waterfall methodology) để xem liệu một bước cụ thể nào đó có đang mất nhiều thời gian hơn không. Chúng ta có cần khắc phục không? Điều đó là không thể thực hiện được. Được rồi. Vậy, nếu tôi xem trang logs, tôi có thể thu thập, làm mới, một cái gì đó như bốn ticket đã được đẩy. Vâng, điều này sẽ xuất hiện ngay bây giờ. Vâng, đó là hai ticket tại thời điểm này. Vì vậy, một lần nữa, thông tin tương tự mà chúng ta đã hiển thị cũng có sẵn trong console. Vâng, chúng ta đã đề cập đến tracing.
Đánh giá Hiệu suất Hệ thống AI
Hãy nói về phần đánh giá (evaluation) cho vấn đề này. Điều này khá thú vị, một lần nữa, tùy thuộc vào vị trí của bạn trong hành trình hoặc việc xây dựng ứng dụng này. Nhiều khách hàng đã xây dựng một ứng dụng, đã có sẵn, kiểu như các Mô hình Ngôn ngữ Lớn (LLM) đã được tích hợp. Nhưng điều gì sẽ xảy ra khi bạn gặp phải vấn đề khởi động lạnh (cold start) mà bạn không biết mình đang xây dựng cái gì? Vậy, "tốt" trông như thế nào? Và, trên thực tế, "tốt" có nghĩa gì đối với tôi? Trong trường hợp ứng dụng hỗ trợ mà chúng ta đang phát triển hôm nay, kiểu như trong các điểm có thể thương lượng hơn, cách chúng ta phân loại trường hợp hỗ trợ, cách chúng ta đảm bảo không có kết quả nghiêm trọng hoặc ít nghiêm trọng cho những vấn đề đang gây tắc nghẽn này. Liệu việc leo thang (escalation) có tuân thủ chính sách với các SLA (Thỏa thuận mức dịch vụ) không? Cấu trúc có vẻ ổn không? Và nếu chúng ta thực hiện bất kỳ thay đổi cụ thể nào, liệu nó có thực sự cải thiện cách chúng ta nhìn nhận mà không làm hỏng hoặc gây hồi quy (regression) cho ứng dụng không? Chúng ta có thể làm điều này bằng cách sử dụng đánh giá. Vì vậy, một đánh giá (evaluation), đối với những người (hy vọng nhiều người đã biết chúng là gì), nhưng đối với những người trong phòng, hãy nghĩ về nó như một cách mà bạn có tập dữ liệu (data set) của mình, đầu vào của bạn, bạn có một nhiệm vụ, và sau đó bạn có một kết quả mà bạn muốn đánh giá hoặc một hàm chấm điểm (scoring function). Và điều này hơi khác một chút so với phát triển phần mềm truyền thống khi làm việc với các hệ thống AI vì tính chất phi xác định (non-deterministic) của chúng. Vì vậy, trong phần cụ thể này, điều tôi sẽ nói ở đây là tạo ra cái mà chúng ta gọi là tập dữ liệu vàng (golden data set). Vì vậy, trong ứng dụng hỗ trợ này, tôi sẽ thử nghiệm một cách giai thoại (anecdotally), nhưng tôi muốn tạo ra một tập hợp các trường hợp biên (edge cases) mà tôi nghĩ rằng điều này thực sự sẽ giúp mang lại cho chúng ta ít nhất một mức độ tự tin ban đầu cho doanh nghiệp rằng những gì chúng ta đang phát hành vào sản phẩm (production) là có mục đích. Luôn có chỗ để cải thiện, nhưng không phải là tôi chỉ phát hành ứng dụng này dựa trên cảm tính. Tôi có một cách cụ thể để nói, được rồi, đây là cách nó hoạt động theo thời gian. Để làm điều này, một lần nữa, chúng ta sử dụng hai loại hàm chấm điểm chính. Loại đầu tiên là xác định (deterministic). Vì vậy, tôi nghĩ nhiều người đã bắt đầu sử dụng loại này, một lần nữa, đến từ kỹ thuật phần mềm truyền thống, bạn biết đấy, kiểm thử đơn vị (unit tests). Bạn sẽ không nói là tương tự, nhưng chúng khá giống nhau về bản chất, nơi chúng rất dễ chạy, hiệu quả về chi phí, bạn thực sự không sử dụng một mô hình (model) tại thời điểm này. Loại thứ hai, tinh vi hơn một chút, là sử dụng một Mô hình Ngôn ngữ Lớn (LLM) làm trọng tài (judge), tức là một hệ thống AI khác. Và điều này thực sự hữu ích khi nói đến các hệ thống có sắc thái (nuance), điều mà không thể thực sự được xác định chỉ bằng các hệ thống xác định. Vì vậy, một lần nữa, việc tạo ra phong cách thương hiệu chỉ là đáp ứng sự hài lòng của khách hàng v.v. Vì vậy, điều quan trọng nhất là nếu bạn không thể viết nó theo cách xác định, bạn muốn sử dụng LLM làm trọng tài bất cứ khi nào có thể. Và tại sao điều này lại quan trọng hơn, một lần nữa, nó chỉ là để đảm bảo rằng bất kỳ thay đổi nào chúng ta thực hiện đều là một thay đổi an toàn khi chúng ta tiến hành điều này.
Tải lên và Chạy Đánh giá
Được rồi. Vậy, tôi sẽ chuyển sang ý tưởng đó một lần nữa. Hãy xem tệp readme. Và sau đó chúng ta sẽ làm, tên từ điển là gì? Bạn có thể vào C, được rồi. Và sau đó liệt kê ở đây. Sau đó make demo, à, make setup, chúng ta sẽ ổn thôi. Được rồi. Vậy, một điều tôi muốn bạn làm nữa là chạy lệnh C dataset, vì vậy chúng ta thực hiện make C dataset. Được rồi. Vậy, điều này sẽ tải lên các trường hợp kiểm thử đánh giá của chúng ta vào Giao diện người dùng (UI) của BrainTrust. Vì vậy, nếu tôi chuyển sang các tập dữ liệu của mình bây giờ, bạn sẽ thấy nó được gọi là helper.seed_dataset. Một lần nữa, chỉ để đơn giản hóa việc tạo 10 đầu vào, tôi cũng đã phân loại chúng. Vì vậy, đầu vào sẽ mong đợi một số metadata liên quan đến nó. Đó là cấu trúc cốt lõi để tạo một đánh giá. Vì vậy, là một phần của điều này, và cả xác định và phi xác định, tôi đã tạo một số hàm chấm điểm sẽ được sử dụng như một phần của điều này. Vì vậy, nó có sẵn ở đây, và sau đó là các hàm chấm điểm. Vì vậy, một lần nữa, kiểm tra danh mục như một schema tại chỗ là một lý do leo thang khi cần, một lần nữa, rất dễ chạy và mã hóa. Vâng, chúng ta có sự tinh vi hơn với tiêu chí khách hàng (customer rubric), vì vậy đây là trường hợp sử dụng LLM làm trọng tài nhiều hơn ở đây. Được rồi. Và sau đó chúng ta có thể quay lại readme. Vì vậy, chúng ta không cần phải làm demo, chúng ta đã đẩy nó qua rồi. Hãy tiếp tục và sau đó thực hiện make eval. Vì vậy, điều này sau đó sẽ chạy một đánh giá, và như tôi nghe, dữ liệu ban đầu (seed data) cũng vậy, một lần nữa, không cần thiết, tôi phải đưa nó vào mã nguồn, nhưng cho dù nó đến từ một cơ sở dữ liệu, trong trường hợp này, tôi chỉ sử dụng một tệp JSON phẳng cho điều này, chỉ để cung cấp cho bạn một số ngữ cảnh. Vì vậy, khi chạy đánh giá này, chúng ta sẽ có, nếu chúng ta vào UI, một nơi cho các thử nghiệm (experiments), vì vậy tôi sẽ bắt đầu kiểm tra ở đây. Vâng, thử nghiệm đó đã chạy, một lần nữa, lưu trữ các JSON liên quan đến nó. Vì vậy, bạn sẽ nhận được một đầu ra như terminal Silesian, nhưng nếu chúng ta quay lại UI, một lần nữa, chúng ta bắt đầu theo dõi ứng dụng của mình dựa trên đầu vào và đầu ra cho tập dữ liệu cụ thể này. Khá giống với tracing mà chúng ta đã thấy từ các trace trực tuyến, bạn sẽ thấy rất tương tự ở đây, và xem cách nó hoạt động trong suốt quá trình thử nghiệm của bạn. Và tôi nghĩ rằng, khi chúng ta tiến bộ với workshop, chúng ta sẽ bắt đầu thấy cách chúng ta cải thiện nó bằng cách sử dụng các hàm khác nhau và theo dõi điều đó trên UI. Nếu bạn cần thêm không gian hiển thị (real estate) nữa, bạn cũng có thể thu gọn menu, điều này cũng hữu ích.
Chuyển từ Môi trường Cục bộ sang Quản lý
Được rồi. Hãy tiếp tục với điểm kiểm tra (checkpoint) tiếp theo, xoay quanh việc triển khai và quản lý vấn đề này. Như tôi đã đề cập, tôi nghĩ rằng nhiều người, ít nhất là (và hy vọng khi tôi thấy điều này với các khách hàng phổ biến), lại nói rằng "mọi thứ sẽ hoạt động tốt trên máy của tôi." Được rồi, bây giờ đưa điều đó vào mã nguồn. Tôi muốn đưa điều này vào một nơi mà tôi có thể bắt đầu cộng tác (collaborate) tốt hơn một chút. Nó nằm ở một điểm tham chiếu. Tôi có một phiên bản trong lịch sử. Bạn có thể bắt đầu xác định, một lần nữa, ai đã thực hiện thay đổi gì? Và bạn cần một cách để tập hợp những người dùng này lại với nhau. Vì vậy, tôi nghĩ rằng khách hàng đã nói về cộng tác. Điều thú vị nữa là, một lần nữa, việc thay đổi lời nhắc trên máy của bạn và sau đó cố gắng chuyển mã nguồn đó đến một kho lưu trữ, và sau đó có thể ai đó, ví dụ như một quản lý sản phẩm SME không chuyên về kỹ thuật, có lẽ, họ muốn cập nhật các lời nhắc. Họ không thể làm được. Họ phải nhờ bạn giúp đỡ. Có lẽ điều đó đã xảy ra với một số người trong phòng hôm nay. Tôi biết điều đó đã xảy ra với tôi vài lần trước đây. Và điều đó có thể bắt đầu trở nên thực sự khó chịu. Vì vậy, chúng tôi thực sự chỉ muốn một cách để có thể tập hợp điều đó lại với nhau. Một điều thực sự quan trọng, đặc biệt đối với những người làm việc trong các ngành công nghiệp được quản lý chặt chẽ. Ví dụ, khả năng tái sản xuất (reproducibility) là một điều rất quan trọng. Và tôi đã làm việc trong, bạn biết đấy, hơn một thập kỷ trong cả ngân hàng và thị trường vốn. Tôi biết rõ ràng với quy định hiện hành, đặc biệt là những thứ như quyền được lãng quên, việc hiểu ai đã thực hiện một thay đổi, đặc biệt trong một kịch bản thoát hiểm căng thẳng. Làm thế nào chúng ta có thể đưa điều này vào một hệ thống mới? Điều này thực sự quan trọng để giúp mở khóa điều đó. Và điều thú vị khi nói đến việc xác định các thay đổi trước khi bạn làm điều đó. Vì vậy, một lần nữa, chúng ta không muốn chỉ thực hiện các thay đổi, đẩy ra sản phẩm và hỏi chúng ta điều gì đã xảy ra. Chúng ta cần phải có khả năng thiết lập điều đó. Và đối với chúng tôi, một lần nữa, chúng tôi đang giới thiệu một số khả năng mới. Vì vậy, những gì bạn đang chạy hiện tại, bạn đã chạy các công cụ, bạn đã chạy các lời nhắc, mọi thứ trên máy cục bộ của bạn. Điều chúng tôi muốn làm là chuyển giao (offload) khả năng đó vào BrainTrust. Vì vậy, khi ứng dụng của bạn đang chạy trong môi trường bảo mật, nó có thể tham chiếu đến BrainTrust để lấy thông tin đó và sau đó hỗ trợ đường dẫn thực thi, điều này, một lần nữa, tuân theo các cơ chế tracing mà chúng ta đã thực hiện. Vì vậy, theo mặc định, khi bạn chạy các lệnh make, chế độ thời gian chạy (runtime mode) được đặt thành kiểu cục bộ (local). Nếu bạn muốn sử dụng chế độ quản lý (managed mode), chỉ cần sử dụng tiền tố (prefix), managed, và bất kỳ lệnh make còn lại nào cũng sẽ diễn ra ở đó. Vậy, điều tôi muốn làm là chuyển sang IDE. Vậy, quay lại readme của tôi.
Quản lý Lời nhắc và Tham số trong BrainTrust
Vì vậy, tôi sẽ xem xét ở đây. Chúng ta sẽ thực hiện make setup. Tôi cứ nghĩ, tôi thực sự muốn nhấn mạnh ở thời điểm này, vì chúng ta đang quản lý điều này trong BrainTrust, hãy sử dụng lệnh setup BrainTrust ở đây. Vậy, điều đó sẽ đóng gói các hàm chấm điểm, công cụ và lời nhắc và đẩy chúng lên cơ sở hạ tầng bảo mật. Vì vậy, bạn sẽ nhận được một đầu ra như thế này và điều đó sẽ trông như thế nào trong Giao diện người dùng (UI). Vậy, hãy quay lại tổng quan (overview) để xem. Vì vậy, ở phía bên trái, nếu chúng ta xem xét các lời nhắc, bạn sẽ bắt đầu thấy ba lời nhắc mà chúng ta đã tạo như một phần của quy trình làm việc đó. Để bạn hình dung ở đây, nếu chúng ta đi đến true or specialist. Vậy, bạn có thể định nghĩa một slug. Tức là một ID có thể thay đổi, nhưng bạn có thể tham chiếu đến nó trong mã nguồn. Điều này cũng có thể được tạo ra khi cần. Lời nhắc, một lần nữa, được coi là mã nguồn. Chúng ta cũng sử dụng một số nội suy (interpolation) ở đó nếu bạn muốn tham số hóa, và tôi sẽ sớm cho bạn thấy điều đó trông như thế nào. Nếu tôi đi đến hàm chấm điểm, vậy hãy tiếp tục để chấm điểm. Được rồi, để tôi xem một chút. Tôi xem xét các tham số. Tôi sẽ xem xét ở đây, và tôi đã tạo các tham số cụ thể chỉ để đơn giản hóa việc thay đổi mô hình cơ sở (baseline model). Vậy, có lẽ chỉ cần giơ tay lên: Các mô hình này được phát hành quá nhanh. Đã có ai từng bị một quản lý sản phẩm (PM) hoặc một quản lý sản phẩm SME không chuyên về kỹ thuật nói rằng, "Này, nhân tiện, tôi có thể thay đổi lời nhắc không? Tôi có thể thay đổi mô hình hoặc lời nhắc và xem nó sẽ trông như thế nào không?" Điều đó đã xảy ra với các bạn chưa? Tôi nghĩ có ba người giơ tay ở đây. Tuyệt vời. Được rồi, vậy, điều tốt đẹp với việc này bây giờ, sử dụng các tham số được quản lý, những SME không chuyên về kỹ thuật đó có thể vào BrainTrust và thay đổi lời nhắc ở đây. Viết một bình luận để nói, "Xem, hãy sử dụng một mô hình khác." Tôi sẽ sử dụng một cái gì đó như cho Mini. Chỉ cần nói, "Đang kiểm thử một mô hình mới." Tôi sẽ lưu phiên bản này ở đây. Viết bình luận. Và điều tôi sẽ làm nữa, chỉ để đưa ra một lời khẳng định cuối cùng. Tôi sẽ tạo một tập hợp BrainTrust. Vì vậy, mỗi khi bạn thay đổi điều gì đó, bạn có thể chạy lệnh này. Nhưng tôi chỉ làm điều đó để ngắn gọn ở đây. Điều đó chủ yếu là để giữ cho mô hình này đồng bộ. Vì vậy, đối với nhiều lời nhắc, đó là kiểu đồng bộ. Nhưng nếu tôi xem xét, xin lỗi, các tham số hiện có, nó sẽ ở đó. Và vì vậy, điều tôi muốn làm là nếu tôi làm điều gì đó như mở khóa. Vì vậy, trong trường hợp này, bằng cách chạy quản lý, tôi chỉ thay đổi quá trình thực thi. Không phải để chạy mô hình cục bộ, mà là để làm theo đường dẫn mà BrainTrust đã thiết lập cho mô hình. Và nếu mọi thứ diễn ra tốt đẹp, bạn sẽ thấy đó là một hệ thống mới. Bạn có thể thấy rằng họ đã thay đổi mô hình ở đây. Vì vậy, một lần nữa, tôi không phải thực hiện bất kỳ thay đổi mã nguồn nào. Tất cả những gì tôi phải làm là vào UI, thay đổi mô hình tôi muốn.
Thiết Lập Đường Cơ Sở và Tự Động Hóa
Khi bạn có một tham số, hãy chạy nó và cách nó sử dụng một đường cơ sở để thiết lập các hoạt ảnh. Một lần nữa, nếu muốn, bạn cũng có thể chạy script demo để đưa các ticket demo vào. Tôi sẽ bỏ qua phần này cho buổi workshop hôm nay. Tôi nghĩ tôi thấy điều này với nhiều khách hàng khác nhau của mình, họ nói: "Ồ, bạn biết đấy, có thể có một loạt các vấn đề khác." Nó nói: "Này, nhân tiện, Brain Trust hiện đang có quyền kiểm soát truy cập đối với các tham số nút này." Điều tôi muốn nói là Brain Trust không thực sự nhằm mục đích thay thế sự chặt chẽ đó. Bạn có lẽ vẫn muốn sử dụng những thứ như hệ thống kiểm soát phiên bản để theo dõi điều đó. Điều chúng tôi đang nói là, khi đưa vào vận hành nó và đảm bảo rằng những người dùng khác có thể làm việc trên hệ thống chia sẻ, đây là một cách tiếp cận được khuyến nghị mà chúng tôi sẽ thực hiện để giúp ích. Vì vậy, một lần nữa, bạn có lẽ vẫn phải có các lời nhắc, bộ công cụ và tham số của mình theo một cách tập trung, nhưng sau đó cung cấp tự động hóa để bạn đồng bộ hóa và làm việc. Đó là cách tốt nhất chúng tôi thấy khách hàng tận dụng điều này.
Giới Thiệu Tính Năng Online Scoring
Tiếp theo, chúng ta sẽ nói về online scoring. Vậy bây giờ chúng ta đã có các đánh giá đó, điều chúng ta sẽ làm là áp dụng các điểm số đó vào các production logs thực tế đang đến thông qua ứng dụng. Thật tuyệt khi chúng ta đã thực hiện các trường hợp thử nghiệm của mình. Chúng ta có một mức độ tin cậy rằng nó đang hoạt động, nhưng một lần nữa, không có gì thay thế được dữ liệu sản xuất. Tất cả chúng ta đều biết điều này. Vì vậy, điều chúng ta sẽ làm là tạo, một lần nữa, di chuyển logic vào Brain Trust và thiết lập tự động hóa theo mục tiêu (on-the-goal automations) mà sau đó sẽ theo dõi và đánh giá điều này khi nó đến trong thời gian thực. Điều cần lưu ý khi bạn bắt đầu hành trình của mình là, đặc biệt nếu bạn đang sử dụng LLM làm người đánh giá, bạn nên bắt đầu với một tỷ lệ lấy mẫu cao hơn. Vì vậy, khi logs đang đến, nếu có thể, bạn muốn đảm bảo xác định một đường cơ sở. Nhưng lại có một sự đánh đổi khi những cuộc gọi này có thể khá tốn kém, đặc biệt nếu bạn đang sử dụng các mô hình tinh vi hơn và cần tỷ lệ suy luận cao. Tại thời điểm đó, khi bạn hài lòng với đầu ra, bạn có thể muốn giảm tỷ lệ lấy mẫu xuống còn 5 đến 10 phần trăm, để bạn quản lý chi phí một cách hiệu quả. Xác định điểm số. Chúng rẻ, khuyến nghị chạy chúng liên tục.
Trình Diễn và Thiết Lập Công Cụ
Xin lỗi, câu hỏi đó là gì? Vâng, tôi sẽ hiển thị điều đó trong Giao diện người dùng. Tôi sẽ chỉ cho bạn. Nếu tôi quay lại Môi trường phát triển tích hợp (IDE), tôi sẽ vào readme ở đây. Ồ, đó là lý do tại sao tôi bỏ lỡ các công cụ được quản lý. Vậy thì hãy git checkout. Được rồi, đó. Như tôi đã đề cập, tất cả chúng đều xây dựng dựa trên nhau, vì vậy việc bỏ qua bước này hoàn toàn ổn. Vậy thì git checkout. Được rồi, bây giờ, nếu tôi chạy make setup, mọi thứ sẽ ổn. Chạy setup Brain Trust. Trong trường hợp này, tôi thực sự đang lấy các công cụ cho sản xuất. Một lần nữa, điều này chỉ thực sự giúp tăng tốc mọi thứ khi có thể. Khi tôi cuộn xuống, nếu tôi làm mới, đúng vậy, tôi cuộn. Các hàm tính điểm mà bạn đã thấy trước đó trong mã nguồn, giờ đây chúng đang được quản lý bởi Brain Trust. Vì vậy, bạn có thể thấy nó có sẵn ở đây. Điều tôi muốn nhấn mạnh là tree. Vì vậy, tôi có rất nhiều LLM làm người đánh giá, đã được áp dụng. Vì vậy, tôi đã đưa nó ra, nhưng khi lấy S. Và có một quy tắc tự động hóa đang được áp dụng. Vì vậy, chất lượng gốc nội tuyến.
Tự Động Hóa và Khung Sườn
Những gì tôi đã làm ở đây, một lần nữa, tôi đã tự động hóa việc thiết lập dưới dạng mã, để khởi tạo dự án. Nhưng một lần nữa, những gì chúng ta có thể làm ở đây là, tùy thuộc vào việc đó là một span riêng lẻ, chúng ta có thể chạy thực thi hoặc toàn bộ trace. Và đây là lý do tại sao siêu dữ liệu rất quan trọng, vì chúng ta chỉ muốn theo dõi các lỗi cụ thể có thể xảy ra trong mã nguồn. Một lần nữa, tùy thuộc vào trường hợp sử dụng, tỷ lệ lấy mẫu của tôi, như tôi đã đề cập, được đặt là 100, nhưng đối với các cuộc gọi tốn kém hơn, chúng ta cũng muốn cân nhắc điều đó. Vì vậy, đây là cách tự động hóa hoặc cách chúng ta thực hiện điều đó trong Brain Trust ngày nay. Không, tự động hóa giống như việc thực thi đối với logs đến. Nhưng tôi quan tâm hơn, tôi đã áp dụng tự động hóa để thiết lập môi trường và khung sườn này. Vì vậy, tôi chỉ muốn phân biệt điều đó ở đây. Xin lỗi, có câu hỏi. Bạn có thể giải thích rõ hơn về điều đó được không? Vâng. Đúng vậy. Vâng, đúng vậy. Ổn thôi. Vâng, chúng ta có thể muốn coi đó là một trường hợp biên, đưa nó vào một tập dữ liệu, xác định nó và sau đó đưa nó trở lại. Vì vậy, đó sẽ là cách tiếp cận mà tôi sẽ thực hiện cho việc này. Nếu bạn chưa có bất kỳ sự thật cơ bản nào hoặc chúng đã có rồi, đúng không? Vì vậy, đây là lý do tại sao tôi nói, tùy thuộc vào nơi bạn bắt đầu, tốt hơn là nên có một số loại dữ liệu và sau đó bắt đầu chu trình phản hồi của bạn từ đó. Ồ, trường hợp đó. Chúng ta có thể đưa điều đó vào một tập dữ liệu và sau đó phát lại qua sân chơi. Đó sẽ là cách chúng ta làm điều đó. Vâng. Vâng.
Giới Thiệu Khắc Phục Lỗi
Được rồi. Vậy là chúng ta đã kiểm tra online scoring, đến lúc rồi. Được rồi, bây giờ đến phần khắc phục. Vì vậy, hy vọng sẽ thấy được sự khác biệt (delta), hoặc một lần nữa, lý do chúng ta ở đây hôm nay. Vì vậy, hy vọng điều này có thể giúp bạn với câu hỏi cụ thể đó. Vì vậy, một lần nữa, đây là điều có thể xảy ra như một đầu vào hợp lý cho hệ thống tác nhân của chúng ta: người dùng có thể nói: "Này, điều này không khẩn cấp, nhưng tôi sẽ xem liệu chúng ta có thể xuất hóa đơn trước cuộc họp hội đồng quản trị không." Mô hình nói: "Chờ đã, điều này có vẻ ổn đối với tôi." Ai đó nói: "Không, khẩn cấp. Đến xem, đến xem." Nhưng nghiệp vụ thì rất khác, đúng không? Điều này có lẽ cần được chú ý ngay lập tức. Giám đốc tài chính của bạn được hiển thị báo cáo quý cần phải hoàn thành. Và đây là sự khác biệt giữa những gì chúng ta đang làm ở đây hôm nay là cố gắng xác định chế độ lỗi thích hợp và sau đó khắc phục điều đó có thể.
Quy Trình Khắc Phục và Kiểm Tra
Vì vậy, trong trường hợp này, một lần nữa, tôi có thể chạy chế độ cụ thể này ở đây. Tôi có điều này trong tập dữ liệu này. Vì vậy, chỉ cần chạy một kịch bản mà chúng ta sẽ phát lại lỗi. Chúng ta muốn ngăn chặn đánh giá đối với điều này. Chúng ta sẽ siết chặt lời nhắc, chạy lại và xem nó trông như thế nào. Chúng ta có lẽ sẽ sử dụng nó lại. Đó không chỉ là một trường hợp thử nghiệm cụ thể, mà nó có thể bao quát toàn bộ trường hợp thử nghiệm của chúng ta để xem liệu nó có hoạt động như mong đợi và chúng ta chưa thoái lui trên một thứ khác từ góc độ đó không. Được rồi, vậy thì hãy tiến hành và có hai nhánh riêng biệt cho việc này. Vì vậy, hãy chia nhánh của chúng ta thành A, một nhánh sẽ có tỷ lệ lỗi trong tâm trí. Chúng ta sẽ truy cập Giao diện người dùng và xem điều đó, sau đó chúng ta sẽ nói về đường dẫn khắc phục ở đó nữa.
Rất nhiều sản phẩm thực sự. Vì vậy, chúng ta thậm chí có thể thực hiện chế độ một lần (one-time mode) mà sẽ tạo ra một lỗi phát lại (replay failure). Được rồi, vậy tôi có tập hợp năm trường hợp là hồi quy của các chế độ lỗi. Vì vậy, đó là cái đầu tiên bạn thấy trong ticket ví dụ. Vâng, đó là một tệp JSON ở đây. Hãy xem ở đây. Được rồi, vậy hãy xem chế độ lỗi ở đây. Bạn có thể đi sâu vào điều này. Bạn cũng sẽ nhận thấy rằng chúng ta đã thiết lập online, các công cụ được quản lý cũng như online scoring. Trace trở nên tinh vi hơn nữa bởi vì chúng ta đang thực thi điều này đối với môi trường Brain Trust an toàn. Vì vậy, một lần nữa, chuyển từ local sang được quản lý. Tôi sẽ đi đến makefile. Xin lỗi, cảm ơn về JSON. Hãy đến tài liệu hướng dẫn. Vì vậy, tôi chỉ đang thực hiện đánh giá đối với một kịch bản cụ thể.
Theo Dõi Khắc Phục trong Giao Diện Người Dùng
Được rồi, như chúng ta có thể thấy khi chúng ta đang phát triển với ứng dụng, thử nghiệm, một lần nữa, trình xem chỉ cho phép chúng ta thấy tiến độ của các thay đổi của chúng ta. Vì vậy, bạn có thể thấy chúng ta đã chạy tập dữ liệu mới nhất. Chúng ta nhận thấy một số suy giảm ở đây, điều này cho phép chúng ta theo dõi nó. Vì vậy, tập dữ liệu được quản lý mà tôi đã nghĩ đến, tỷ lệ lỗi thực tế đang được ghi lại. Và bạn có thể thấy, tôi đã có thể xem nó để so sánh với các thử nghiệm hiện có, để theo dõi tiến độ và khắc phục khi có thể.
Vì vậy, tôi bỏ qua điều tiếp theo là tôi sẽ đi đến readme. Và sau đó tiến hành khắc phục. Vì vậy, trong khắc phục này, tôi đã thay đổi lời nhắc mà tôi đã sử dụng. Vì vậy, một cách để xem điều đó là nếu tôi xem lời nhắc và thay đổi. Vì vậy, chúng ta sẽ thấy, chúng ta sẽ thấy bất kỳ sự khác biệt nào ở đó. Ngay tại chỗ. Cuộn xuống tệp readme ở đây. Giả sử tôi làm một điều ở đây, hãy cho chúng ta một cờ cụ thể, tôi nghĩ vậy. Tôi không biết bạn có muốn kiểm tra lại và đặt điều đó không. Vâng, thế thôi. Vì vậy, nếu bạn muốn đặt điều đó, nếu nó tồn tại, thay thế, trong VM build chat. Vâng. Vâng, ổn thôi. Vì vậy, vâng, mọi người, nếu bạn muốn, trong phần script khắc phục, nếu bạn đặt biến môi trường BRAIN_TRUST_ON_THE_SCORE, nếu on_the_score tồn tại, bạn đặt nó là thay thế. Nó sẽ đẩy các thay đổi đã cập nhật vào môi trường. Vậy thì, nếu tôi lấy, ôi, nó không phải cho điều đó. Và sau đó bạn cũng sẽ thấy, bây giờ chúng ta đã cập nhật lời nhắc và đẩy nó lên, nó cũng có sẵn ở đây. Vì vậy, cũng như trong Giao diện người dùng, một lần nữa, một phần của vận hành, đưa vào vận hành, chúng ta có thể thấy ai đã thay đổi gì, nhưng thực sự điều gì đã được thay đổi đối với lời nhắc cụ thể trong trường hợp này, đặc biệt là ở đây. Vì vậy, bao gồm hai sự thật, và làm rõ điều đó.
Được rồi. Vậy thì, quay lại đây, giả sử chúng ta chạy lại đánh giá này. Vì vậy, chúng ta đã thực hiện thay đổi đối với lời nhắc, và bây giờ chúng ta đang chạy phiên bản đã được khắc phục để xem nó hoạt động như thế nào. Được rồi, vậy thì đó là chạy thử nghiệm ở đây với các thay đổi mới, hy vọng vậy. Và tôi đang chuyển sang Giao diện người dùng, tôi sẽ đến phần thử nghiệm ở đây. Và nó hầu như không có ở đó, nhưng bạn có thể thấy, kiểu như, khôi phục nó, bạn biết đấy, bất kỳ cải thiện nào đi lên là cải thiện đó. Nhưng vâng, chỉ để bạn có ý tưởng ở đây, rằng, bây giờ chúng ta đã thực hiện đánh giá, thực ra điều tôi có thể làm là, ừm, thực hiện một so sánh (diff), và chúng ta có thể làm, vì vậy hãy thực hiện một so sánh trong sự khác biệt (delta). Vâng. Vì vậy, vâng, hãy phát triển, ừm, cải thiện theo thời gian, ừm, theo cách nào, theo cách nào, ừm, kết quả mong muốn. Vâng.
Tổng Kết và Các Bài Học Quan Trọng
Tôi nghĩ chúng ta đang đến gần cuối nội dung. Ừm, vì vậy tôi biết nó đã có nhiều bước. Vì vậy, tôi thực sự, thực sự muốn cảm ơn thời gian và sự chú ý của bạn đã đi qua đó. Như đã đề cập, các tạo phẩm là công khai. Chúng ta có cheat sheet ở đó. Chúng ta có kênh Slack để giúp đỡ nếu bạn có bất kỳ câu hỏi nào. Hy vọng, chỉ để cung cấp cho bạn một tóm tắt về những gì bạn đã hoàn thành hôm nay, theo thứ tự này: bạn đã đi từ việc lấy một lời nhắc một lần chạy (single-shot prompt) thành xây dựng một quy trình làm việc tác nhân năm giai đoạn (five-stage agent workflow) sử dụng cuộc gọi công cụ (tool calls). Điều chúng ta sau đó có thể làm là kiểm tra cách điều này hoạt động khá nhiều, và sau đó đi sâu vào điều này bằng cách thêm theo dõi Brain Trust, đảm bảo mọi thứ được ghi lại.
Ừm, chúng ta cũng sau đó muốn nói về, bạn biết đấy, làm thế nào chúng ta đánh giá hệ thống từ, ừm, bạn biết đấy, không có trực tuyến, khi có điều gì đó mới, ừm, tạo ra những tập vàng (golden set) hiệu quả với những trường hợp thử nghiệm đó, mà chúng ta sẽ thực thi đối với chúng. Chúng ta sau đó đã triển khai những lời nhắc được quản lý, những công cụ và tham số đó vào kiến trúc Brain Trust an toàn để sử dụng. Và chúng ta cũng đã thêm online scoring để sau đó đánh giá hệ thống khi nó diễn ra. Và sau đó chúng ta đã chọn một lỗi sản xuất cụ thể, chúng ta đã xem trace, chúng ta đã sửa đổi lời nhắc trong trường hợp của chúng ta và chúng ta đã thấy sự khác biệt ở đó. Sau khi chạy lại đánh giá, chúng ta đã thấy nó khôi phục đến nơi cần thiết. Và trong trường hợp này, hoàn thành đánh giá đầy đủ về việc xây dựng, quan sát nó, triển khai nó và đưa nó tiến về phía trước.
Ừm, vì vậy, vâng, chỉ để tổng kết và hoàn thành nó. Một lần nữa, hy vọng điều này không phổ biến, nhưng một lần nữa, những gì có thể hoạt động trong sản xuất sẽ không thực sự hoạt động trong nguyên mẫu (prototype). Ừm, chúng ta thực sự cần phải phân tích điều này, xác định các chế độ lỗi và tiến về phía trước. Và đó là nơi, một lần nữa, các giai đoạn rõ ràng trở nên thực sự, thực sự quan trọng, đúng không? Và, ừm, một lần nữa, điều này giới thiệu thêm các khu vực mà mọi thứ có thể gặp trục trặc, nhưng dễ gỡ lỗi hơn nếu đó là trường hợp. Ừm, bạn biết đấy, không có gì thay thế được việc đi sâu vào mã nguồn và theo dõi mọi thứ. Vì vậy, tôi sẽ nói nó có khả năng quan sát. Đây là những yêu cầu cơ bản (table stakes) tại thời điểm này.
Liên tục cải tiến và truy vết ứng dụng
Nếu bạn có một ứng dụng ở lớp sản xuất (production layer application) mà bạn không thực hiện việc tracing, bạn cần phải xem xét lại từ đầu và triển khai nó một cách hiệu quả. Và hy vọng, chúng tôi có thể chỉ cho bạn cách thực hiện điều đó bằng cách sử dụng Brain Trust. Một lần nữa, không có gì có thể thay thế hoàn hảo cho nhật ký sản xuất (production logs), nhưng tốt hơn hết là hãy bắt đầu từ đâu đó. Nếu bạn có ý tưởng về một vấn đề có thể xảy ra, đây là những cách hoàn hảo để bổ sung cho việc đánh giá, sử dụng các chế độ lỗi đó làm trường hợp kiểm thử của bạn.
Như tôi đã đề cập, đây là một quá trình liên tục, đúng không? Không có gì là hoàn tất mãi mãi. Nếu bạn đã làm việc trong phát triển linh hoạt (agile development), phản hồi liên tục là rất quan trọng. Và một lần nữa, chúng tôi đang mang mô hình vận hành này đến, nhưng với một bề mặt vận hành tập trung vào người dùng (user-centric surface). Hy vọng, chúng tôi sẽ mang điều này về cho các nhóm của bạn ngay hôm nay.
Vì vậy, lời khuyến khích của tôi dành cho bạn là, nếu đây là điều bạn quan tâm, hãy chọn một thứ gì đó đã đi vào hoạt động. Không nhất thiết phải là toàn bộ bộ ứng dụng. Có thể bắt đầu với thứ gì đó quan trọng hơn một chút mà bạn thực sự muốn cải thiện các chế độ vận hành của nó. Thêm tracing, thu thập số liệu của bạn từ chế độ đó, xây dựng các khám phá lặp đi lặp lại (iteratively explore) và sau đó lặp lại mọi thứ nếu có thể. Vì vậy, một lần nữa, vòng lặp phản hồi càng nhanh, bạn càng có nhiều cái nhìn sâu sắc và bạn càng có thể cải thiện tổng thể các hoạt động vận hành và phân phối của hệ thống.
Lời kêu gọi hành động & Tài nguyên
Đây là lời kêu gọi hành động. Tôi biết chúng tôi đã cung cấp rất nhiều nội dung cho bạn. Rõ ràng là chúng tôi đang cố gắng thu thập phản hồi. Chúng tôi cố gắng đặt ra một số Hàng rào bảo vệ, vì vậy tôi đánh giá cao sự nỗ lực của mọi người khi phải xử lý nhiều thông tin để thực hiện điều này. Nhưng như tôi đã đề cập, bạn phải bắt đầu từ đâu đó. Hãy để chúng tôi giúp bạn tăng tốc. Chúng tôi có rất nhiều tài liệu được cung cấp. Bạn cũng có thể sử dụng tác nhân AI của chúng tôi trên agent để tìm kiếm nếu bạn có bất kỳ câu hỏi nào, nhưng chúng tôi cũng có một cookbook (sách hướng dẫn) có sẵn. Tôi thường trực tiếp đưa cookbook vào Cursor, Codex, và những công cụ khác rồi nói: "Về cơ bản, hãy lấy SDK và bắt đầu tracing ứng dụng của tôi." Nó khá hiệu quả. Chúng tôi thậm chí còn có một phiên bản chỉ là một CLI cho ứng dụng Brain Trust của chúng tôi. Điều đó cho phép bạn thực hiện những việc như tự động đo lường (auto-instrumentation). Tôi chỉ muốn giới thiệu đồng nghiệp Eric của tôi, người đang làm việc rất nhanh chóng và tuyệt vời, hãy ghé thăm gian hàng của anh ấy vì nó thực sự tuyệt vời.
Và một lần nữa, nếu đây là điều bạn quan tâm và muốn tìm hiểu thêm, vui lòng liên hệ với đại diện tài khoản của bạn tại Brain Trust. Một lần nữa, chúng tôi rất sẵn lòng hỗ trợ nếu có thể. Nếu bạn đang ở trong Discord, hãy thoải mái tham gia; chúng tôi rất vui được trả lời các câu hỏi ở đó. Và một lần nữa, tôi thực sự muốn cảm ơn bạn vì thời gian và sự chú ý của bạn. Hôm nay là một ngày nắng đẹp, và tôi không muốn giữ mọi người ở đây; tôi muốn bạn ra ngoài hít thở không khí trong lành. Nhưng vâng, thay mặt cho Brain Trust, người đào tạo và bản thân tôi, xin chân thành cảm ơn thời gian và sự chú ý của bạn. Đó là một vinh dự, và tôi mong muốn được gặp bạn ngoài kia khi bạn thực hiện tracing và nhận được giá trị từ việc cung cấp AI. Tôi hoan nghênh bạn. Xin cảm ơn.