Full Workshop: Build Your Own Deep Research Agents - Louis-François Bouchard, Paul Iusztin, Samridhi

• Nội dung được tạo bởi AI thường có vấn đề về chất lượng như chung chung, nông cạn, hoặc thiếu chính xác ("AI Slop", "ảo giác"), đòi hỏi các phương pháp tạo nội dung kỹ lưỡng hơn thay vì chỉ dựa vào các mô hình ngôn ngữ.
• Việc tự động hóa quy trình tạo nội dung kỹ thuật thông qua các tác nhân nghiên cứu chuyên sâu và viết bài chuyên biệt có thể giảm đáng kể chi phí và thời gian, nhưng cần tập trung vào việc tạo ra các quy trình có kiểm soát thay vì tự chủ quá mức.
• Quyết định sử dụng "workflow" hay "agent" phụ thuộc vào nhu cầu của hệ thống: workflow phù hợp với các bước cố định, tuần tự, trong khi agent cần thiết khi có yêu cầu về hành động tự chủ, phản ứng với môi trường và khả năng lập kế hoạch linh hoạt.

• Quản lý ngữ cảnh chủ động: Luôn giữ "ngân sách ngữ cảnh" tinh gọn và phù hợp nhất có thể bằng cách tóm tắt, huấn luyện nội dung và truy xuất dựa trên tiêu chí để giảm chi phí token và cải thiện hiệu suất mô hình, đặc biệt là khắc phục vấn đề "mất ở giữa".
• Phân biệt rõ ràng giữa Workflow và Agent: Áp dụng workflow cho các tác vụ có các bước xác định trước, tuần tự và không cần phản ứng động, bởi đây là giải pháp đơn giản, đáng tin cậy và hiệu quả chi phí hơn so với việc triển khai agent không cần thiết.
• Sử dụng Agent cho các hành động động: Triển khai hệ thống tác nhân khi ứng dụng cần thực hiện các hành động tự chủ, phản ứng với thay đổi trong môi trường (ví dụ: gọi API, ghi vào cơ sở dữ liệu) hoặc lập kế hoạch phức tạp.
• Tận dụng Công cụ trong Tác nhân đơn lẻ: Thay vì hệ thống đa tác nhân phức tạp, xây dựng một tác nhân duy nhất làm người ra quyết định và lập kế hoạch, sau đó sử dụng các "công cụ" chuyên biệt như các khả năng AI riêng để xử lý các tác vụ cụ thể như xác thực hoặc định dạng.
• Chống lại "AI Slop" và "ảo giác": Thiết kế hệ thống với các bước nghiên cứu kỹ lưỡng và xác thực nghiêm ngặt để tránh tạo ra nội dung chung chung, lỗi thời hoặc không chính xác do mô hình ngôn ngữ sinh ra.
• Chọn mức độ tự chủ phù hợp: Đánh giá cẩn thận "thang trượt tự chủ"; mức độ tự chủ càng cao (hệ thống tác nhân) càng tăng độ phức tạp, giảm kiểm soát và tăng chi phí. Thường thì các quy trình làm việc tăng cường mô hình ngôn ngữ đơn giản là đủ.
• Tự động hóa nghiên cứu và viết kỹ thuật: Xây dựng hệ thống tự động hóa quá trình nghiên cứu chuyên sâu và soạn thảo ban đầu, cho phép các chuyên gia con người tập trung vào việc cải thiện cốt truyện, độ chính xác và giá trị thực tế của nội dung.

• AI Slop — Nội dung AI vô nghĩa/hời hợt
• ảo giác — hallucination (trong ngữ cảnh AI)
• mô hình ngôn ngữ — language model (LM)
• ngữ cảnh — context
• kỹ thuật AI — AI engineering
• quy trình làm việc — workflow
• hệ thống tác nhân — agent system
• kỹ thuật lời nhắc — prompt engineering
• cửa sổ ngữ cảnh — context window
• vấn đề "mất ở giữa" — "lost in the middle problem"

Giới thiệu Hội thảo và Vấn đề Nội dung AI

Chào mọi người, tôi hy vọng âm thanh ổn. Hoàn hảo. Vậy thì, chúng ta sẽ bắt đầu hội thảo và giới thiệu về bản thân mình trong thời gian ngắn. Nhưng trước tiên, chúng tôi muốn trình bày slide này vì đây về cơ bản là LinkedIn trong năm nay. Đây là loại nội dung mà khi bạn hỏi ChatGPT, về cơ bản đó là những gì bạn nhận được. Chúng là những phản hồi rất chung chung và có một vài điều sai với phản hồi thực tế này mà chúng tôi không thực sự muốn thấy. Những điều rõ ràng là các từ ngữ "lỗi thời", AI Slop, tức là tất cả những chi tiết phức tạp mà chúng ta đều biết. Nhưng còn nhiều hơn thế nữa, và may mắn thay, thậm chí không có dấu gạch ngang giữa M nào ở đó. Nhưng có một số vấn đề khác, như các dòng hơi cao.

Tuy nhiên, điều tổng quát hơn, giống như hầu hết các công ty, những quan niệm sai lầm phổ biến hoặc những quan niệm sai lầm của hầu hết mọi người, nó thường xuyên mắc phải. Đây là một số ví dụ từ các bài đăng trên LinkedIn mà tất cả đều nói về "hầu hết các chủ đề", "hầu hết mọi người ở đây", "hầu hết các dự án AI". Và tôi thực sự cũng mắc phải điều đó. Vì vậy, chúng ta học hỏi trong quá trình làm việc. Và có một số vấn đề khác với ảo giác hoặc thông tin lỗi thời. Rõ ràng, nội dung này được tạo ra vào tuần trước và GPT-4 không phải là state of the art. Tương tự, có một số cụm từ AI Slop mà chúng ta thấy rất nhiều, những cụm từ rõ ràng như "phát triển nhanh chóng" nhưng cũng có câu cổ điển "nó không phải về cái gì đó mà là về cái gì khác" mà nó tạo ra rất nhiều. Và điều tồi tệ nhất là, thông thường, điều này thực sự vô nghĩa và hời hợt. Nó không cung cấp bất kỳ giá trị hay điều gì hữu ích nào. Vì vậy, điều chúng ta cần ở đây là một nghiên cứu kỹ lưỡng và cách viết phù hợp xoay quanh các mô hình ngôn ngữ này.

Tự động hóa Quy trình Tạo Nội dung Kỹ thuật

Để cung cấp thêm ngữ cảnh cho hội thảo này, chúng tôi về cơ bản, tôi tạo các khóa học và hàng tấn video đào tạo cùng nội dung kỹ thuật. Và để làm điều đó, chúng tôi cần tạo nội dung kỹ thuật xoay quanh kỹ thuật AI. Vì vậy, chúng tôi cần các technical writer, nghĩa là chúng tôi cần các kỹ sư AI, writer, editor cùng nhau lặp lại và rất nhiều thời gian để tạo ra một câu chuyện hay, một bài viết hay, một bài học hay hoặc một video hay nói chung, điều mà cuối cùng tốn rất nhiều tiền. Vì vậy, điều chúng tôi cố gắng làm là tự động hóa quá trình này, điều mà chúng tôi đã làm hoặc ít nhất là một phần của nó, bởi vì phần còn lại thực sự là một điều thuộc về con người để tạo ra một câu chuyện hay, liên quan đến những người khác. Và đó là điều chúng tôi đã làm. Chúng tôi đã xây dựng một hệ thống để thay thế toàn bộ quá trình nghiên cứu rất kỹ lưỡng và sau đó là viết kỹ thuật.

Vì vậy, những gì nó làm là chúng tôi đưa ra một chủ đề như "kỹ thuật harness là gì". Và chúng tôi có tác nhân nghiên cứu chuyên sâu của riêng mình sẽ tìm kiếm nhiều trang web và công cụ, sử dụng công cụ để làm rất nhiều thứ. Và sau đó là một hệ thống khác để viết một bài báo kỹ thuật thực tế với mã, hình ảnh và lý tưởng là một bài viết không có slop ở đó. Và thực ra, hệ thống này, vì chúng tôi xây dựng khóa học, chúng tôi đã sử dụng nó để xây dựng một khóa học dạy cách xây dựng hệ thống đó. Vì vậy, đó thực sự là một dự án thú vị để thực hiện nói chung và nó cho phép chúng tôi lặp lại và kiểm tra rất nhiều và có phản hồi trực tiếp từ người dùng với các sinh viên của chúng tôi. Vì vậy, nó thực sự rất tuyệt.

Mục tiêu Hội thảo và Tài liệu Chia sẻ

Và đó là điều chúng tôi cố gắng chia sẻ ở đây trong hội thảo kéo dài hai giờ của chúng tôi hoặc ít nhất là một phiên bản nhỏ gọn hơn nhiều với một hệ thống nghiên cứu chuyên sâu nhỏ hơn, đơn giản hơn và một tác nhân viết chỉ dành cho nội dung ngắn hơn cho một bài đăng kiểu LinkedIn. Và chúng tôi cũng cố gắng chia sẻ những gì chúng tôi đã học được khi xây dựng nó. Bạn có thể mở hoặc lấy kho lưu trữ GitHub, nó là công khai. Trong 30 phút đầu tiên, tôi sẽ chỉ nói chuyện bằng slide nên bạn sẽ không cần đến nó. Nhưng sau đó, các đồng nghiệp của tôi sẽ tham gia với mã, vì vậy có thể đáng để có nó. Và chúng tôi sẽ hiển thị lại mã này sau. Vì vậy, bạn có thể lấy nó đúng lúc.

Nhưng về cơ bản, tôi sẽ trình bày những gì chúng tôi đã học được trong một số thuật ngữ vì chúng tôi là một công ty cá nhân và đó là điều chúng tôi muốn làm. Vì vậy, tôi sẽ trình bày một số kiến thức cơ bản để đưa mọi người đến cùng một cấp độ hoặc ít nhất là đến các định nghĩa của chúng tôi về mọi thứ và chia sẻ những gì chúng tôi đã học được khi xây dựng nó. Và sau đó Sam sẽ tiếp quản để nói về tác nhân nghiên cứu chuyên sâu thực tế và tiếp tục với phần còn lại.

Giới thiệu Đội ngũ TORDI

Chúng tôi là ai? Tôi là Louis François, CTO và đồng sáng lập của TORDI. Tôi đã là một nghiên cứu sinh Tiến sĩ về AI cho đến khi ChatGPT ra đời, khi đó tôi về cơ bản đã chuyển sang làm một nhà giáo dục toàn thời gian và tạo ra Towards AI để tập trung vào điều đó. Tôi đã làm video giải thích các bài báo nghiên cứu trong bảy năm nay. Và rõ ràng ngay bây giờ, tôi tập trung hơn vào kỹ thuật AI. Và tôi đã phát triển trong lĩnh vực này từ năm 2020. Tại startup đầu tiên, tôi được tuyển dụng cho vị trí đó. Vì vậy, tôi sẽ để Sam tự giới thiệu.

Chào mọi người, tôi là Sam Ruby. Tôi là một kỹ sư máy học. Tôi cũng là một technical writer và tư vấn viên giúp Towards AI. Tuyệt vời. Rất vui được gặp tất cả các bạn.

Chào mọi người, tôi là Paulis Dyn và tôi đã xây dựng phần mềm trong tám năm. Và tôi đã tham gia vào lĩnh vực giảng dạy AI hơn bốn năm. Và tôi cũng là tác giả của cuốn sách bán chạy "Sổ tay kỹ thuật". Và tôi rất vui được trình bày hội thảo này cho các bạn hôm nay.

Không gian Vấn đề Kỹ thuật AI

Vì vậy, tôi sẽ bắt đầu bằng cách giới thiệu, chúng tôi luôn bắt đầu với một vấn đề. Và ở đây nó khá tổng quát. Tôi bắt đầu giới thiệu không gian vấn đề kỹ thuật AI. Nơi về cơ bản, tất cả các quyết định của chúng ta với tư cách là kỹ sư AI đều bị chi phối bởi các ràng buộc mà thông thường ít áp dụng cho kỹ sư phần mềm, đó là chi phí hoặc nhiệm vụ có thể thay đổi rất nhiều tùy thuộc vào mô hình bạn sử dụng, kiến trúc bạn sử dụng. Chúng ta có các yêu cầu về độ trễ với các mô hình suy luận và những thứ khác mà chúng ta có thể kiểm soát. Chúng ta rõ ràng có một số chất lượng cần tôn trọng và quyền riêng tư dữ liệu trong trường hợp này mà chúng ta cần cẩn thận.

May mắn thay, chúng ta có một stack để giúp đỡ, cho dù đó là từ kỹ thuật lời nhắc, kỹ thuật ngữ cảnh, đến sử dụng công cụ điều phối hoặc xây dựng hệ thống đánh giá của riêng chúng ta.

Thang Tự chủ trong Hệ thống AI

Sau đó, chúng tôi muốn xem đó như một loại thanh trượt tự chủ đi từ rất đơn giản, chỉ cần nhắc lệnh một mô hình đến xây dựng hệ thống tác nhân. Nơi mà bạn càng thêm sự phức tạp từ nhắc lệnh đến các quy trình làm việc tiên tiến hơn đến hệ thống tác nhân, bạn càng thêm tự chủ, nhưng bạn cũng càng ít kiểm soát hơn toàn bộ hệ thống của mình. Và rõ ràng, chi phí càng cao. Và đối với chúng tôi, điều đó rất quan trọng để chọn khi chúng tôi xây dựng cho khách hàng. Vì vậy, đó là lý do tại sao chúng tôi cố gắng dạy những gì chúng tôi xây dựng trong Agent Loop này. Nhưng đối với chúng tôi, điều thực sự quan trọng là xây dựng một hệ thống phù hợp mà chúng tôi không cần quá nhiều tự chủ nơi nó có thể gây thêm vấn đề và sự không chắc chắn.

Và rõ ràng hầu hết mọi người đều quan tâm đến việc xây dựng các tác nhân, nhưng hầu hết các tác nhân mà khách hàng của chúng tôi muốn thực sự là các quy trình làm việc siêu đơn giản hoặc ít nhất là các quy trình làm việc mà chúng ta có thể dễ dàng nghĩ ra. Và vì vậy, tôi muốn cố gắng bắt đầu bằng cách định nghĩa quy trình làm việc lên đến hệ thống đa tác nhân kết thúc bằng ví dụ nghiên cứu chuyên sâu mà chúng tôi đã thực hiện.

Khái niệm Workflow

Workflow là gì? Một workflow rất đơn giản. Nó chỉ là một mô hình ngôn ngữ, nhưng được tăng cường. Bởi vì các mô hình ngôn ngữ chỉ nhận vào mã thông báo và văn bản và tạo ra mã thông báo và văn bản. Vì vậy, bạn không thể làm nhiều với văn bản ngoài việc đọc và viết email, điều mà một số người trong chúng ta làm nhiều hơn thế. Vì vậy, lý tưởng nhất là bạn muốn thêm các thứ vào nó, như thêm dữ liệu mà nó có thể không có quyền truy cập, cho dù đó là tại công ty của bạn hay một số dữ liệu khác cần thiết để trả lời tốt nhất người dùng. Bạn có thể thêm, bạn có thể cấp cho nó quyền truy cập vào công cụ để làm những việc khác ngoài việc chỉ tạo mã thông báo. Và bạn có thể thêm bộ nhớ để nó có thể ghi nhớ tương tác và hữu ích hơn nhiều. Nhưng đây vẫn không phải là một tác nhân. Nó chỉ là một thứ chúng ta có thể xây dựng dễ dàng và đáng tin cậy.

Các Kỹ thuật Workflow Nâng cao

Và một workflow có thể phức tạp hơn thế nữa. Bạn có thể xâu chuỗi các lời nhắc lại với nhau để giảm độ trễ và độ phức tạp để làm nhiều việc hơn dựa trên các điều kiện nghiêm ngặt. Bạn thậm chí có thể làm điều đó với một bộ định tuyến để quyết định tự động dựa trên các điều kiện về những gì bạn muốn làm, cho dù đó là sử dụng một mô hình nhỏ hơn hay chỉ thực hiện một nhiệm vụ khác rồi quay lại. Bạn có thể làm điều đó song song để hiệu quả hơn hoặc để cải thiện kết quả bằng cách bỏ phiếu đa số và các kỹ thuật khác. Và bạn thậm chí có thể thêm các vòng lặp để tự động cải thiện kết quả dựa trên phản hồi của người đánh giá. Nhưng tất cả những điều này vẫn không phải là tác nhân. Nó chỉ là một workflow mà chúng ta có thể xây dựng và thêm tất cả những thứ này. Chúng ta thậm chí có thể kết hợp chúng. Chúng ta có thể xây dựng các workflow thực sự tiên tiến.

Agent là gì?

Vậy khi nào điều đó trở thành một tác nhân? Và ở đây một lần nữa, tôi đang sử dụng một minh họa từ Anthropic. Đó là một định nghĩa mà chúng tôi thực sự thích. Đó là khi nó cần thực hiện hành động và quan trọng hơn, khi nó có thể phản ứng với những gì xảy ra trong môi trường. Vì vậy, rất đơn giản, nó phải có khả năng thực hiện hành động tự chủ và phản ứng với những gì xảy ra, như tôi đã nói. Và lý tưởng nhất là có khả năng lập kế hoạch để quyết định công cụ nào sẽ sử dụng và quan trọng hơn là công cụ nào không nên sử dụng, cách phản hồi và mọi thứ.

Khi nào nên sử dụng Agent thay vì Workflow?

Vậy khi nào chúng ta nên sử dụng thứ này, một hệ thống tác nhân, so với một workflow? Chà, thông thường, chúng ta luôn muốn sử dụng giải pháp đơn giản nhất. Chỉ cần một lời nhắc hoạt động. Điều đó là lý tưởng. Và khi chúng ta xây dựng mọi thứ, chúng ta luôn cố gắng bắt đầu bằng các câu hỏi và sử dụng loại thanh trượt tự chủ của chúng ta.

Vì vậy, chỉ cần một danh sách các câu hỏi đơn giản mà chúng ta có thể trả lời sẽ là liệu mô hình đã biết đủ về nhiệm vụ cần thực hiện hay chưa, cho dù đó là người dùng đặt câu hỏi hay một số nhiệm vụ khác. Rõ ràng, bạn chỉ cần nhắc lệnh và thực hiện nó. Và lý tưởng nhất là thêm một số ví dụ, một số ví dụ trong tương lai, chỉ vì nó thực sự giúp mô hình thích nghi phần nào ngay lập tức, đó sẽ là nhắc lệnh đơn giản. Sau đó, nếu bạn cần ngữ cảnh bên ngoài, nếu nó không quá lớn và bạn có thể dán nó vào lời nhắc, vào lời nhắc, dưới khoảng 200.000 mã thông báo, bạn có thể dán nó ngay lập tức và lý tưởng nhất là có nó trước khi bạn sử dụng ASCIT và sử dụng bộ nhớ đệm ngữ cảnh để hiệu quả hơn chỉ để, ví dụ, trả lời một số câu hỏi về cùng một báo cáo hoặc cùng một tài liệu quyền riêng tư của bạn hoặc bất kỳ tài liệu nội bộ nào bạn có.

Bây giờ, nếu ngữ cảnh không được biết cho đến khi người dùng đặt câu hỏi cho mô hình của bạn, đây là lúc bạn có thể cố gắng tiêm kiến thức ngay lập tức dựa trên câu hỏi, cho dù đó là vì dữ liệu của bạn là riêng tư và bạn cần truy xuất nó để trả lời câu hỏi, hoặc nếu đó là một điều gì đó gần đây mà các mô hình chưa được đào tạo hoặc cụ thể theo miền, bạn có thể muốn tiêm kiến thức. Và nếu bạn muốn làm tất cả những điều này theo nhiều cách khác nhau hoặc tùy thuộc vào các điều kiện, đây là lúc bạn sử dụng một workflow nâng cao hơn với các bước và trình tự được xác định trước.

Ví dụ về Workflow: Xử lý Yêu cầu Hỗ trợ

Và trong thực tế, một ví dụ về workflow mà chúng tôi đã xây dựng cho một khách hàng là xử lý siêu vé (super ticket handling), nơi về cơ bản bạn luôn có các bước giống nhau theo cùng một thứ tự, hệ thống nhận vé, nó phân loại, định tuyến đến đúng nhóm, nó soạn thảo phản hồi, nó có thể xác thực nó dựa trên chính sách của nhóm và sau đó gửi đi. Và ở đây, điểm mấu chốt là các bước này luôn giống nhau, thứ tự không bao giờ thay đổi, nó luôn cần thực hiện sáu bước này theo cùng một thứ tự. Và vì vậy, xây dựng điều này như một tác nhân sẽ chỉ thêm chi phí mà không thêm bất cứ điều gì bổ sung, bạn không cần phải phản ứng động với bất cứ điều gì, phải không? Ở đây bạn chỉ cần thực hiện các bước này. Vì vậy, một workflow chắc chắn có ý nghĩa trong trường hợp này.

Ví dụ về Agent: Chatbot Tiếp thị CRM

Vì vậy, đối với một tác nhân, điều bạn muốn hỏi bản thân là liệu hệ thống của bạn có cần thực hiện hành động hay có khả năng rẽ nhánh động hay không. Cho dù đó là gọi các API khác nhau, tùy thuộc vào những gì người dùng cần hay ghi vào cơ sở dữ liệu hay không, thực hiện suy luận và những thứ khác. Đây là lúc một tác nhân có thể hữu ích. Và một ví dụ chúng tôi đã có là một nền tảng CRM ở Canada muốn tạo một chatbot cho nền tảng CRM của họ, cho người dùng, khách hàng của họ để có thể tạo nội dung tiếp thị tự động.

Và ban đầu họ liên hệ với chúng tôi vì họ đang xin một khoản trợ cấp AI và họ muốn một hệ thống đa tác nhân để làm nhiều việc khác nhau với các tác nhân cho mọi thứ, điều này nghe có vẻ rất phù hợp với khoản trợ cấp vì nó tập trung vào AI. Nhưng dường như quá mức cần thiết để tạo ra nhiều tác nhân để làm một việc khá đơn giản như một chatbot tiếp thị. Vì vậy, cuối cùng, điều chúng tôi luôn làm là cố gắng thực sự hiểu những gì khách hàng cần và muốn, điều này thường rất khác nhau. Và vì vậy, bằng cách nói chuyện với họ, chúng tôi nhận ra rằng quy trình làm việc thực tế luôn giống nhau, luôn đơn giản.

Tận dụng Công cụ trong Tác nhân Đơn lẻ

Chúng tôi cần tác nhân lập một kế hoạch để quyết định những gì nó nên làm, sau đó truy xuất dữ liệu cụ thể cho khách hàng, tạo nội dung, xác thực và sửa chữa nếu cần. Các tác vụ luôn tuần tự, cùng một loại tác vụ mà chúng tôi muốn thực hiện. Chúng được kết nối chặt chẽ, luôn là một việc về tạo nội dung tiếp thị, nhưng chỉ cho các khách hàng và định dạng khác nhau. Toàn bộ chuỗi này phụ thuộc vào ngữ cảnh. Vì vậy, dù đó là kế hoạch, truy xuất, tạo hay sửa chữa, tất cả đều cần ghi nhớ nội dung để tạo ra nội dung tốt nhất có thể.

Việc phân chia các quyết định cho các tác nhân khác nhau theo yêu cầu của khách hàng có thể gây ra nhiều vấn đề, dù là thông tin hay lỗi cuối cùng với hai mục tiêu và những thứ khác có thể làm giảm độ tin cậy. Vì vậy, thay vào đó, chúng tôi chỉ xây dựng một tác nhân nhưng sử dụng các công cụ làm khả năng AI của chúng tôi. Điều này thực sự tuyệt vời vì với các công cụ, bạn có thể có lời nhắc hệ thống riêng, logic xác thực riêng, thậm chí Mô hình Ngôn ngữ Lớn (LLM) riêng hoặc các lệnh gọi đến LLM riêng. Vì vậy, bạn có thể làm rất nhiều thứ với các công cụ. Trong ví dụ của chúng tôi, chúng tôi có một công cụ xác thực, một công cụ dành riêng cho tất cả các định dạng, công cụ SMS hoặc công cụ email. Kết quả là chúng tôi sử dụng các công cụ như các chuyên gia, nhưng ngữ cảnh toàn cầu vẫn nằm trong tác nhân duy nhất của chúng tôi, đó là người ra quyết định và lập kế hoạch.

Hạn chế của Cửa sổ Ngữ cảnh và Vấn đề "Mất ở giữa"

Tuy nhiên, nếu chúng ta làm vậy, điều đó có nghĩa là mọi thứ vẫn nằm trong tác nhân của chúng tôi. Vì vậy, chúng ta có một hạn chế, đó là cửa sổ ngữ cảnh của tác nhân trong mô hình mà chúng ta đang sử dụng, được tạo thành từ nhiều thứ: lời nhắc hệ thống, rõ ràng là các hướng dẫn mà chúng ta đưa ra, các định nghĩa công cụ, các lược đồ khác nhau và cách sử dụng các công cụ này. Các ví dụ few-shot về tác vụ cần thực hiện, rõ ràng là rất tốt để dạy bằng ví dụ như chúng ta đã thấy với các mô hình, chúng học rất nhanh theo cách đó đối với hầu hết các tác vụ. Bạn có thể có dữ liệu được truy xuất tùy thuộc vào những gì bạn muốn làm, và thậm chí toàn bộ lịch sử trò chuyện, nếu đó là chatbot hoặc bất kỳ loại tác nhân nào phát triển theo thời gian.

Vì vậy, tất cả những điều này có thể chiếm rất nhiều không gian, gây ra vấn đề vì khi chúng ta đi qua từng bước này, ngữ cảnh phát triển và hiệu suất giảm sút, điều mà chúng tôi gọi là tình trạng tắc nghẽn ngữ cảnh (context rut). Vấn đề là điều này xảy ra rất lâu trước giới hạn cửa sổ ngữ cảnh thực tế, ví dụ như một triệu mã thông báo. Nó xấu đi khá nhanh sau khoảng 200.000 hoặc tiếp tục thay đổi, nhưng hiện tại là khoảng 200.000. Điều này chủ yếu là do vấn đề "mất ở giữa" (lost in the middle problem), nơi chúng ta về cơ bản dạy các mô hình ngữ cảnh dài này để có thể xử lý ngữ cảnh dài bằng cách cho chúng ăn một kho ngữ liệu lớn và sắp xếp một sự thật ngẫu nhiên trong đó rồi truy xuất sự thật đó. Vì vậy, về cơ bản, nó là việc truy xuất một thứ cụ thể, nhưng nó không dạy các mô hình đó tận dụng toàn bộ tài liệu, toàn bộ ngữ cảnh để trả lời câu hỏi. Vì vậy, điều này chắc chắn không lý tưởng, nhưng sẽ quá tốn kém để xây dựng loại mô hình lớn như tôi đã nói. Đây là cách đào tạo chúng, bởi vì vấn đề của chúng ta là phải quản lý "ngân sách ngữ cảnh" này, có nghĩa là luôn giữ ngữ cảnh tinh gọn và phù hợp nhất có thể, cả để giảm chi phí về số lượng mã thông báo, mà còn để cải thiện các số liệu (metric) mà chúng ta đang sử dụng.

Kỹ thuật Quản lý Ngữ cảnh và Hệ thống Đa Tác nhân

Và chúng ta có thể sử dụng nhiều kỹ thuật cho việc đó. Chúng ta có thể huấn luyện nội dung, chúng ta có thể tóm tắt nó. Chúng ta có thể truy xuất dựa trên tiêu chí, hoặc cũng có nhiều kỹ thuật thú vị trong Claude Code leak, một phương pháp nén ngữ cảnh (compaction method) mà tôi khuyên bạn nên tìm hiểu. Không có hai phương pháp nào thực sự mạnh mẽ, nhưng điều tôi quan tâm nhất trong buổi nói chuyện này là việc ủy quyền mà chúng ta có thể thực hiện cho các công cụ hoặc tác nhân con với ngữ cảnh riêng của chúng, điều mà hầu hết các hệ thống chúng ta sử dụng đều đang thực hiện.

Và điều này dẫn chúng ta đến các hệ thống đa tác nhân (multi-agent systems), nơi chúng ta về cơ bản muốn sử dụng chúng khi chúng ta có quá nhiều ngữ cảnh này, chủ yếu là trên 22 giây, hoặc ngữ cảnh trở nên quá lớn. Chúng ta có thể ủy quyền cho các công cụ hoặc các tác nhân. Và có thể có những lý do khác như nếu bạn cần đưa ra quyết định tự động (autonomous decision making) hoặc bạn cần sự đa dạng của công cụ (tool variability), hoặc đơn giản là tuân thủ bảo mật (security compliance), nếu bạn cần có một tác nhân cục bộ bên trong một bệnh viện, ví dụ, bởi vì tôi đã làm việc trong lĩnh vực chăm sóc sức khỏe trước đây và chúng tôi thường phải giữ mọi thứ cục bộ. Vì vậy, đó có thể là một lý do cho các tác nhân đa tác nhân. Và tại sao tôi lại nói về tất cả những điều này? Bởi vì những gì chúng ta đã thấy là các sản phẩm AI không bao giờ chỉ là bạn xây dựng một tác nhân hoặc bạn xây dựng một hệ thống đa tác nhân đơn lẻ. Chúng về cơ bản kết hợp tất cả những điều đó, chúng kết hợp các công cụ, quy trình làm việc, một số phần cụ thể và được xác định trước hơn, một số phần có tính linh hoạt cao hơn. Và chúng tôi tin rằng các kỹ sư AI cần hiểu tất cả những điều này để xây dựng các hệ thống phức tạp.

Tổng quan về Hệ thống Nghiên cứu Chuyên sâu

Hệ thống nghiên cứu chuyên sâu thực sự triển khai điều đó, đây là một ví dụ rất tốt về một hệ thống hoàn chỉnh vì nó đã tích hợp tất cả các kỹ thuật này. Và trước khi chúng tôi trình bày cách chúng tôi xây dựng hệ thống của riêng mình và cho phép bạn sử dụng nó, hãy để tôi tóm tắt nhanh về hệ thống nghiên cứu chuyên sâu, đề phòng trường hợp bạn chưa biết. Đó là một hệ thống suy luận sẽ lập kế hoạch những gì nó cần nghiên cứu. Nó có một mức độ tự chủ nhất định để quyết định nên nghiên cứu về điều gì. Nó có công cụ, truy cập internet hoặc web. Nó đáng tin cậy. Nó sẽ trích dẫn các nguồn của mình. Nó có các vòng lặp phản hồi (feedback loops) với chính nó, nhưng cũng với con người để có phản hồi từ con người. Vì vậy, điều này có tính chất tác nhân (agentic) hơn nhiều khi chúng ta thấy nó phát triển trong một môi trường, điển hình là web hoặc các nguồn do người dùng cung cấp hoặc chỉ là truy cập API. Và nó được định hướng theo mục tiêu. Nó có một mục tiêu. Chúng tôi không chỉ cho nó biết chính xác cách làm. Chúng tôi chỉ nói với nó hãy nghiên cứu về một cái gì đó. Vì vậy, nó thường phức tạp hơn nhiều so với một chatbot đơn thuần. Nó về cơ bản thay thế một người sẽ thực hiện một nghiên cứu rất kỹ lưỡng về một chủ đề cụ thể. Nó lập kế hoạch tìm kiếm, nó kiểm tra, phân tích, tổng hợp thông tin và có thể lặp lại. Vì vậy, đối với chúng tôi, các hệ thống nghiên cứu chuyên sâu thực sự là một trong những dự án tốt nhất để học cách xây dựng một hệ thống đầu cuối (end-to-end system) phức tạp như vậy.

Xây dựng Hệ thống Nghiên cứu Chuyên sâu của Riêng Chúng tôi

Vì vậy, chúng tôi quyết định xây dựng hệ thống của riêng mình. Trong trường hợp này, hệ thống của chúng tôi về cơ bản là một quy trình sản xuất bài viết kỹ thuật đầu cuối (end-to-end technical article production) từ một chủ đề, bởi vì chúng tôi tạo các bài học, các bài học khóa học trong trường hợp của chúng tôi. Vì vậy, nó xuất phát từ một tiện ích thực sự, đó là phần quan trọng nhất. Mục tiêu ở đây là lấy một chủ đề, nghiên cứu sâu về nó và viết một bài báo kỹ thuật rất hay với tích hợp mã (code integration) thực sự có thể chạy được, với hình ảnh hữu ích, không chỉ là những hình ảnh được tạo ngẫu nhiên.

Và có một vài thách thức khi thực hiện điều này. Thứ nhất, bạn cần độ chính xác (precision) và độ phủ (recall) thực sự cao khi thực hiện nghiên cứu vì bạn cần càng nhiều nguồn liên quan càng tốt, nhưng bạn không cần quá nhiều trong số đó vì vấn đề ngữ cảnh bị hạn chế. Bạn cần giảm ảo giác (hallucinations) và AI rất thích điều này một cách rõ ràng, và kết hợp nhiều phản hồi từ con người, đặc biệt là trong việc viết và khía cạnh viết. Và như chúng ta luôn làm với các dự án và tôi nghĩ tất cả các bạn cũng nên làm, chúng tôi bắt đầu điều này bằng cách tự hỏi bản thân những câu hỏi để hiểu rõ hơn về cách chúng tôi nên làm và liệu chúng tôi có nên làm nó hay không.

Đánh giá Tính khả thi và Mục tiêu

Vậy câu hỏi đầu tiên là: liệu điều này có đáng giá không? Có giải pháp nào ngoài những gì chúng ta có thể xây dựng đã tồn tại sẵn không? Phân tích của chúng tôi là nội dung kỹ thuật chất lượng cao rất tốn kém để sản xuất. Chúng tôi làm điều đó hàng ngày và cần rất nhiều người, tốn nhiều thời gian và cần được xem xét, và nó thực sự tốn thời gian, thực sự tốn kém, đặc biệt là vì những người này cần phải là kỹ sư AI khá có kinh nghiệm để có thể giải thích bất cứ điều gì trong kỹ thuật AI. Vì vậy, họ cần chuyên môn, nhưng để dạy ai đó không phải là để xây dựng một sản phẩm thành công, vì vậy nó đắt đỏ và không phải là phần sáng tạo nhất của họ. Vâng, sẽ lý tưởng nếu tự động hóa hầu hết quá trình này.

Và như tôi đã nói, nghiên cứu cần độ phủ (recall) và độ chính xác (precision) mạnh mẽ, và mặt khác, việc viết cần được kiểm soát hơn, cần tránh ảo giác, có chất lượng cao, tuân thủ giọng điệu hoặc phong cách viết mà bạn muốn, cấu trúc mà bạn muốn. Và về các công cụ nghiên cứu chuyên sâu, chúng tôi sử dụng tất cả chúng gần như hàng ngày và chúng quá chi tiết, chúng thu thập quá nhiều nội dung và có rất nhiều nhiễu. Nó không lý tưởng cho trường hợp của chúng tôi. Chúng tôi có sử dụng chúng, nhưng chúng tôi quyết định tự xây dựng để có thể làm chính xác những gì chúng tôi muốn. Vì vậy, quyết định là: Có, điều này đáng giá, nhưng đặc biệt là để hỗ trợ người viết (writer augmentation), không phải để thay thế họ, bởi vì như chúng ta đã thấy, ngay cả khi bạn xây dựng hệ thống tốt nhất có thể hiện nay, rất khó để tạo ra một nội dung, dù là video hay bài học bằng văn bản, có thể kết nối với người đọc hoặc người xem. Vì vậy, chúng ta cần một "chạm tay" của con người để nó có thể liên quan đến ai đó. Bạn cần kể những câu chuyện cười, những câu chuyện cười hay, không phải những câu chuyện cũ rích mọi lúc. Và những câu chuyện phù hợp với ngữ cảnh. Vì vậy, thực sự khó để tự động hóa tất cả những điều này và chúng tôi muốn giữ con người tham gia vào vòng lặp (human in the loop) ở đó.

Kiến trúc Hệ thống: Tác nhân Nghiên cứu và Tác nhân Viết

Giờ đây, câu hỏi thực tế đầu tiên chúng tôi tự hỏi là kiến trúc nên như thế nào, liệu nó có nên là một tác nhân, nhiều tác nhân hay một quy trình làm việc. Và ý tưởng ở đây là trước tiên chúng ta có phần nghiên cứu thực sự mang tính khám phá (exploratory). Nó cần tìm nhiều nguồn, nó cần khám phá web để hiểu những gì nó cần tìm nếu thiếu thông tin, vì vậy nó cần có khả năng lặp lại, chuyển hướng, tìm kiếm lại. Nó cần rất nhiều sự linh hoạt. Và mặt khác, tác nhân viết mang tính xác định (deterministic) hơn nhiều. Nó cần tuân theo một giọng điệu cụ thể, tuân theo một cấu trúc, vâng, nó cần bị ràng buộc nhiều hơn là cần sự linh hoạt. Bạn không muốn những ảo giác, bạn không muốn những từ cụ thể, những câu cụ thể, bạn muốn những câu cụ thể và những định dạng cụ thể. Vì vậy, nó bị ràng buộc nhiều hơn.

Vì vậy, chúng ta có một sự xung đột ở đây, nơi nghiên cứu cần sự linh hoạt, nhưng việc viết cần sự ràng buộc. Và vì vậy, quyết định là chia thành hai hệ thống: tác nhân nghiên cứu mang tính khám phá, năng động, có tính chất tác nhân hơn và tác nhân viết (hệ thống viết) mang tính xác định và nhất quán hơn. Và chúng tôi có rất nhiều câu hỏi này và chúng tôi trình bày trong khóa học của mình chính xác cách xây dựng hai hệ thống này, nhưng ở đây chỉ có hai giờ, vì vậy chúng tôi tập trung vào tác nhân nghiên cứu nhiều hơn một chút, đặc biệt là cho một vài câu hỏi tiếp theo.

Giao tiếp giữa các Tác nhân và Orchestration

Vậy ở đây, nó nên được tạo ra như thế nào? Chà, tác nhân nghiên cứu nên giao tiếp với quy trình làm việc viết (bước của người viết) như thế nào? Chúng tôi đã điều chỉnh vài lần sau khi thử nghiệm, và đó là phần quan trọng nhất là thực sự sử dụng sản phẩm của bạn, hoặc một người dùng tiềm năng nên sử dụng sản phẩm của bạn để cung cấp phản hồi cho bạn càng sớm càng tốt. Và về phía chúng tôi, chúng tôi đã sử dụng nó để xây dựng một khóa học, vì vậy rất dễ để lặp lại và dạy những gì chúng tôi đã học và những gì chúng tôi đã làm.

Và những gì chúng tôi thấy là người dùng của chúng tôi, là chính tôi và nhóm, thấy rằng chúng tôi luôn sử dụng cả hai tác nhân, hoặc chúng tôi không sử dụng hệ thống. Vì vậy, chúng tôi không chỉ luân phiên giữa nghiên cứu và sau đó là người viết. Nếu chúng tôi luân phiên, đó chỉ là với người viết ở cuối để thêm các đề xuất mới, chủ đề mới, thông tin mới vào bài viết hoặc xóa bớt. Nhưng phần nghiên cứu đã khá hoàn hảo và được thực hiện từ trước, như bạn sẽ thấy với San Midee. Và nếu cần một thay đổi lớn, chúng tôi chỉ cần chạy lại quy trình, vì vậy chúng tôi không cần có orchestration thích hợp.

Và hai tác nhân làm việc trên cùng một sản phẩm trung gian (artifacts). Tác nhân nghiên cứu tạo ra một tệp MD (Markdown) nghiên cứu với tất cả các nghiên cứu được tóm tắt và gửi nó cho người viết. Vì vậy, chúng cần có cách để giao tiếp với nhau. Quyết định mà chúng tôi đưa ra là tách hai tác nhân và chạy chúng tuần tự với orchestration tối thiểu, tức là chỉ một tập lệnh rất cơ bản. Và hai tác nhân của chúng tôi nằm trong cùng một dự án để dễ bảo trì hơn, nhưng chúng cũng chia sẻ các tệp chuyên dụng. Vì vậy, dễ dàng để chúng giao tiếp với nhau, nhưng cũng để chúng giao tiếp với chúng tôi thông qua các tệp này. Và việc có chúng cùng nhau trong cùng một dự án hữu ích cho lập trình hỗ trợ AI (AI-assisted coding) với Claude Code hoặc bất kỳ hệ thống nào bạn đang sử dụng.

Hành vi và Hướng dẫn của Tác nhân Nghiên cứu

Tác nhân nghiên cứu nên hoạt động như thế nào là câu hỏi tiếp theo. Vì vậy, chúng tôi thực sự cần hiểu rõ quy trình mà chúng tôi mong muốn từ trợ lý nghiên cứu này trước khi xây dựng nó. Và một lần nữa, chúng tôi đã tinh chỉnh điều này sau khi thử nghiệm. Cuối cùng, chúng tôi thực sự cần một hướng dẫn do con người viết tốt, về cơ bản sẽ chỉ ra chủ đề về bất cứ điều gì tôi quan tâm muốn đưa vào bài học này và các liên kết hữu ích mà chúng tôi cho là có liên quan. Đôi khi tôi gửi tin tức AI, sử dụng nó xung quanh một số chủ đề cụ thể. Đôi khi đó là video của riêng tôi hoặc các chủ đề khác mà chúng tôi đã đề cập. Và chúng tôi nhận thấy rằng – rõ ràng có một thiên vị của người tạo ở đây – nhưng chúng tôi thấy rằng càng xác định rõ mục tiêu của tác nhân trong hướng dẫn (nghĩa là tác nhân càng ít tự do), thì kết quả càng tốt.

Quy trình Nghiên cứu của Tác nhân

Sau đó, nếu chúng tôi cung cấp các liên kết trong hướng dẫn đó cho tác nhân, tác nhân cần trích xuất dữ liệu từ các trang web, tiêu hóa các video trên YouTube, truy cập các repo GitHub (thậm chí nếu chúng là riêng tư đối với người dùng, tức là chính tôi) để thu thập tất cả ngữ cảnh cần thiết. Sau đó, tác nhân cần thực hiện công việc nghiên cứu chuyên sâu thực sự của mình: tìm kiếm trên web bất cứ điều gì còn thiếu và cần được hiểu, sau đó xem xét lại tất cả ngữ cảnh này và viết thành một sản phẩm cuối cùng rất tốt, sẽ được gửi đến tác nhân viết. Vậy chúng tôi đã làm tất cả những điều đó như thế nào? Làm thế nào chúng tôi trích xuất dữ liệu nội dung web từ các liên kết đã cho và thực hiện tìm kiếm web? Chà, như thường lệ, chúng tôi đơn giản hóa vấn đề và không tự phát minh lại bánh xe. Chúng tôi sử dụng những thứ có sẵn, các hệ thống và Giao diện lập trình ứng dụng (API) hiện có, và chia vấn đề thành các vấn đề đơn giản hơn.

Công cụ Trích xuất Dữ liệu và Tìm kiếm

Đối với giải pháp trích xuất dữ liệu đầu tiên, chúng tôi sử dụng fire call và trích xuất dữ liệu bằng tác nhân. Có nhiều lý do cho việc này mà Sam sẽ nói thêm một chút về các tác nhân nghiên cứu, nên tôi sẽ không đi sâu quá nhiều, nhưng việc có kiểu trích xuất dữ liệu này thực sự hữu ích cho các trang web động hơn và các loại trang web khác có thể chặn trích xuất dữ liệu. Và để tìm kiếm trên web, chúng tôi sử dụng Perplexity, giờ là Gemini với grounding, để nhận được câu trả lời chính xác cùng với nguồn trực tiếp. Sau đó, chúng tôi có thể trích xuất dữ liệu từ các nguồn này nếu cần, nhưng nếu không, chúng tôi đã có thể nhắc lời (prompt) đủ tốt để nhận được thông tin chúng tôi muốn từ truy vấn grounding này. Đối với các video trên YouTube, vì có rất nhiều thông tin tuyệt vời trên YouTube, chúng tôi muốn lý tưởng là chỉ truyền văn bản cho tác nhân vì video khá nặng. Chúng tôi đã thử rất nhiều thứ, nhưng thông thường, bạn cần tải video xuống và trích xuất bản ghi. May mắn thay, Gemini hiện xử lý trực tiếp điều này với một URL YouTube: bạn chỉ cần cung cấp URL YouTube và đặt câu hỏi về nó, hoặc thậm chí yêu cầu cung cấp bản ghi, vì vậy nó rất hữu ích. Rõ ràng chúng tôi đã quyết định sử dụng điều đó. Và đối với nội dung GitHub, chúng tôi chỉ sử dụng thư viện GitHub.js để lấy nội dung cụ thể dưới dạng Markdown và chúng tôi có thể cung cấp cho nó một mã thông báo để truy cập các repo riêng tư của mình, vì vậy nó thực sự đơn giản và bạn sẽ thấy điều đó trong repo.

Khung làm việc và Lựa chọn Mô hình

Đối với khung làm việc, chúng tôi sử dụng MCP với Fast MCP để có thể có các công cụ cho các quy trình khác nhau và chúng tôi có thể có một lời nhắc MCP về cơ bản để cung cấp một công thức về những việc cần làm và cách sử dụng các công cụ cho tác nhân, điều này rất hữu ích. Chúng tôi sẽ nói sâu hơn về điều đó trong một tiếng rưỡi tới. Sau đó, đối với thiết lập nghiên cứu, về cơ bản chúng tôi chỉ sử dụng Python, UV để quản lý các phụ thuộc và tất nhiên là GitHub. Và đối với các mô hình, chúng tôi gần đây đã chuyển mọi thứ sang Gemini, chủ yếu là do tính năng YouTube mà tôi đã đề cập, nhưng chúng tôi cũng thấy rằng thứ nhất, nó hoạt động thực sự tốt và chúng tôi có thể luân phiên giữa Pro và Flash (phiên bản rẻ hơn và đắt hơn) tùy thuộc vào độ phức tạp của tác vụ. Vì vậy, chúng tôi sử dụng chúng xen kẽ trong mã nguồn, và một điều chúng tôi thực sự thích là nó cũng có một gói miễn phí cho sinh viên của chúng tôi, vì vậy nó thực sự tiện lợi cho chúng tôi. Nhưng rõ ràng, chúng tôi cũng đã so sánh với các mô hình khác mà chúng tôi đã sử dụng trước đây (một cá nhân trước đây, và các mô hình đám mây khác, và thậm chí của OpenAI), nhưng chúng tôi đã thấy rằng Gemini thú vị hơn nhiều, đặc biệt là so với OpenAI hiện nay. Vì vậy, chúng tôi đang sử dụng Gemini, nhưng bạn cần so sánh với các mô hình khác để đảm bảo rằng bạn đang sử dụng mô hình phù hợp.

Giao tiếp và Tổng quan Tác nhân Nghiên cứu Chuyên sâu

Cuối cùng, đối với phần lý thuyết hơn: tác nhân nghiên cứu giao tiếp với người dùng như thế nào? Nó nằm bên trong lời nhắc MCP; chúng tôi có các bước cụ thể để dừng và tương tác với người dùng. Và tất cả các tương tác này được xử lý thông qua các tệp, cho dù đó là hướng dẫn hay tệp nghiên cứu hoặc các tệp khác mà Paul sẽ nói đến trong phần viết. Nhân tiện, mọi thứ tôi đã đề cập và nhiều hơn nữa đều có trong một loại cheat sheet mà chúng tôi cũng đã liên kết trong tệp README của repo. Vì vậy, bạn chắc chắn có thể truy cập nó miễn phí, rõ ràng nó có trên GitHub. Và bây giờ là phần chúng ta nói về nghiên cứu chuyên sâu, và bạn có thể quét mã nguồn nếu chưa để lấy repo. Và Sam sẽ tiếp quản. Xin lỗi mọi người, hãy cho tôi một phút. Tuyệt vời. Vậy tôi sẽ nói về tác nhân nghiên cứu chuyên sâu. Tác nhân nghiên cứu chuyên sâu là gì? Louis đã giải thích rằng nó có thể tìm kiếm bất kỳ chủ đề nào bằng cách tìm kiếm trên web. Nó có thể phân tích các video trên YouTube và cuối cùng nó sẽ cung cấp cho bạn một báo cáo có trích dẫn. Cách chúng tôi xây dựng nó: Chúng tôi đã sử dụng MCP cho việc này, đây là một tiêu chuẩn mở để cấp cho các tác nhân quyền truy cập vào các công cụ và dữ liệu. Ý tưởng chính, như lựa chọn thiết kế ở đây, là tác nhân là một bộ não đang thực hiện tất cả các suy luận, như Louis đã nhấn mạnh, rằng bất kỳ khoảng trống nào trong phần nghiên cứu đều được thực hiện bởi tác nhân. Nó nghĩ xem có bất cứ điều gì còn thiếu trong nghiên cứu hay không, liệu nó có cần chạy nhiều nhà nghiên cứu hay nó phải tìm kiếm thứ gì khác. Đó là phần được thực hiện bởi tác nhân, trong khi máy chủ MCP đang xử lý tất cả khả năng. Vì vậy, nó sẽ phơi bày tất cả các công cụ. Nó sẽ phơi bày các tài nguyên và các lời nhắc có sẵn. Có một thứ gọi là Fast MCP, đây là một thư viện thực sự giúp việc tạo tác nhân rất dễ dàng. Vì vậy, nó ẩn tất cả các sự phức tạp. Và bạn không phải viết bất kỳ loại giao thức nào hoặc bất kỳ loại giao tiếp nào giữa các tác nhân. Tất cả những điều đó được xử lý bởi Fast MCP. Và chúng tôi đang sử dụng Claude Code làm harness tác nhân của mình. Nhưng mã nguồn này độc lập với điều đó. Nếu bạn thiên về việc sử dụng Cursor hoặc GitHub Copilot, bạn có thể hoán đổi Claude Code với bất kỳ harness tác nhân nào bạn thích.

Thành phần của MCP Server và Công cụ Nghiên cứu

Vì vậy, tôi sẽ liên tục nói về ba điều này: một máy chủ MCP phơi bày các công cụ, lời nhắc và tài nguyên. Vậy, công cụ là gì? Công cụ về cơ bản là tất cả các hành động mà một tác nhân có thể thực hiện. Chẳng hạn, nghiên cứu chuyên sâu, hoặc thực hiện tìm kiếm trên Google, hoặc phân tích một video và cung cấp bản ghi, hoặc biên soạn một báo cáo. Tất cả những điều định hướng hành động này đều được thực hiện bởi các công cụ. Trong khi đó, điều thứ hai mà MCP phơi bày là lời nhắc, về cơ bản là một chỉ dẫn. Khi bạn nói chuyện với ChatGPT, bạn cung cấp cho nó các chỉ dẫn. Vì vậy, trong trường hợp này, lời nhắc là những gì tác nhân có thể tuân theo. Và trong trường hợp của chúng tôi, chúng tôi có một lời nhắc chi tiết mà tôi sẽ cho bạn xem trong một phút cùng với mã nguồn. Và cuối cùng, điều thứ ba là tài nguyên, đó là dữ liệu mà tác nhân có thể đọc. Vì vậy, đây là dữ liệu tĩnh, chẳng hạn như tên mô hình chúng tôi đang sử dụng, các phiên bản chúng tôi có. Chúng tôi có bất kỳ cờ tính năng (feature flags) nào. Tất cả đều là một phần của các tài nguyên. Vì vậy, đây là những thứ mà tác nhân có thể đọc; không có hành động nào được thực hiện ở đây. Về công cụ, chúng tôi có ba công cụ. Đầu tiên là công cụ nghiên cứu chuyên sâu. Công cụ nghiên cứu chuyên sâu về cơ bản thực hiện tìm kiếm trên Google và cung cấp cho chúng tôi các nguồn cho mọi thứ chúng tôi có. Vì vậy, nó cung cấp cho chúng tôi câu trả lời cho bất kỳ truy vấn nào chúng tôi có. Và nó cũng cung cấp cho chúng tôi tất cả các nguồn của điều đó. Vì vậy, chúng tôi đang sử dụng API Gemini cho việc này. Công cụ thứ hai mà chúng tôi có là công cụ phân tích video YouTube. Đối với cái này cũng vậy, chúng tôi đang sử dụng API Gemini để bạn có thể lấy bất kỳ URL YouTube nào và dán nó vào. Và nó sẽ cung cấp cho bạn một bản ghi ở đây. Và cuối cùng, chúng tôi có công cụ biên soạn nghiên cứu. Vậy về cơ bản nó biên soạn đầu ra của hai công cụ trước đó. Vì vậy, chúng tôi sẽ nói thêm về tệp .memory và chi tiết của nó khi tôi cho bạn xem mã nguồn.

Kiến trúc Tổng thể và Quy trình Lưu trữ Dữ liệu

Vì vậy, tôi vừa nói về các phần công cụ của tác nhân mà chúng ta có. Nhưng đây là kiến trúc tổng thể. Chúng tôi đang sử dụng Claude Code làm client MCP. Để làm rõ ở đây, Claude Code đối với chúng tôi vừa là client MCP vừa là một Mô hình Ngôn ngữ Lớn (LLM). Vì vậy, nó giống như bộ não đang được sử dụng. Đó là client MCP đang giao tiếp với máy chủ MCP mà chúng tôi có. Máy chủ Fast MCP mà chúng tôi có chứa các công cụ, tài nguyên và lời nhắc. Đây là chi tiết về từng công cụ mà chúng tôi có. Vì vậy, tất cả các công cụ này, cụ thể là hai công cụ đầu tiên, ghi vào một thư mục có tên .memory. Và về cơ bản, chúng tôi muốn lưu giữ tất cả những điều này vì nó dễ dàng hơn cho việc ghi nhật ký (logging). Nó dễ dàng hơn cho chúng tôi để xác minh tất cả các kết quả mà chúng tôi đang nhận được. Vì vậy, chúng tôi đang ghi tất cả các kết quả của mình vào một thư mục. Và công cụ thứ ba đọc từ thư mục này và tạo một tệp cho chúng tôi, cụ thể là tệp Markdown có tên research.md. Hai công cụ đầu tiên thực hiện API call đến Gemini 3. Và cuối cùng, mọi thứ được đọc và ghi vào thư mục cụ thể này. Bây giờ tôi sẽ cho bạn xem mã nguồn.

Cấu trúc Mã Nguồn và Định nghĩa Công cụ

Được rồi, đây là cách chúng tôi đã cấu trúc mã nguồn của mình. Bạn không cần phải lo lắng về điều này. Chúng tôi sẽ đơn giản hóa nó rất nhiều. Vì vậy, đây là hai thư mục chính: thư mục nghiên cứu và thư mục viết. Paul sẽ nói về phần viết. Tôi sẽ đi sâu vào và nói về phần nghiên cứu. Vì vậy, nếu bạn nhớ, khi tôi bắt đầu bài thuyết trình, điều đầu tiên tôi nói đến là máy chủ MCP. Vì vậy, đây là tệp máy chủ MCP mà tôi có. Và đây là cách bạn thiết lập máy chủ MCP. Chúng tôi có một số cài đặt đang được tải lên ở đây. Đây về cơ bản là tên của các mô hình mà chúng tôi có. Tôi có thể cho bạn xem điều đó trong một phút. Và đây là cách bạn thiết lập máy chủ: bạn có thể đặt cho nó một tên và phiên bản. Và sau đó bạn đăng ký ba thứ. Vì vậy, đây là điều bạn nên nhớ: chúng tôi đang đăng ký các công cụ, tài nguyên và lời nhắc. Và sau đó chúng tôi chỉ thiết lập ghi nhật ký (logging) cơ bản ở đây. Và chúng tôi đang sử dụng một cái gì đó gọi là OPIC cho khả năng quan sát. Và Paul sẽ nói chi tiết hơn về điều đó. Và sau đó chúng tôi cuối cùng tạo máy chủ MCP. Vì vậy, hãy xem cách chúng tôi đã đăng ký các công cụ. Vì vậy, nếu chúng ta đi đến tệp có tên tools, tệp Python tools, đây là cách chúng tôi đã đăng ký các công cụ. Vì vậy, để đăng ký các công cụ với Fast MCP, xin lỗi, để đăng ký các công cụ, bạn cần ba điều. Điều đầu tiên tất nhiên là tên của công cụ. Vì vậy, ở đây, tên của công cụ là nghiên cứu chuyên sâu. Và sau đó điều thứ hai là các tham số. Vì vậy, chúng tôi đang truyền cho nó hai tham số: thứ nhất là thư mục làm việc, và thứ hai là câu hỏi hoặc truy vấn mà chúng tôi sẽ hỏi nó. Sau đó, bạn cần một định nghĩa về những gì công cụ của bạn sẽ làm. Vì vậy, bạn phải càng chính xác càng tốt khi viết định nghĩa này. Và cuối cùng, chúng tôi cũng có định nghĩa cho các tham số mà chúng tôi có. Vì vậy, nếu chúng tôi có công cụ, thì chúng tôi chỉ có mã nguồn cho khả năng quan sát. Và sau đó cuối cùng, chúng tôi có triển khai. Chúng tôi đang trả về triển khai cho công cụ. Vậy thôi. Vì vậy, đây là cách bạn định nghĩa một công cụ. Và không có sự phức tạp nào ở đây. Nhưng hãy đi sâu hơn một chút vào bản thân công cụ. Vậy, công cụ này hoạt động như thế nào? Vì vậy, đối với công cụ nghiên cứu chuyên sâu, về cơ bản chúng tôi đang ở bước đầu tiên. Chúng tôi chỉ đang xác thực tất cả các phần của mình. Vì vậy, chúng tôi đang kiểm tra xem chúng tôi có đang ở trong thư mục hiện tại hay không. Và thứ hai, chúng tôi đang đảm bảo rằng chúng tôi, tệp memory mà chúng tôi đang ghi vào...

Công cụ Nghiên cứu Chuyên sâu: Chi tiết Thực thi

Về cơ bản, đó là một thư mục nơi chúng tôi ghi tất cả các kết quả của mình vào đó, bất kể nó có tồn tại hay không. Chúng tôi thực hiện tất cả quá trình xác thực tại đây. Sau đó, chúng tôi chạy tìm kiếm grounded search trên query mà chúng tôi có. Khi nhận được kết quả của query này, chúng tôi trả về trạng thái: liệu nó có thành công hay không, query chúng tôi đã gửi là gì, và câu trả lời chúng tôi nhận được là gì. Vì vậy, chúng tôi nhận được một phản hồi chi tiết. Điều này rất hữu ích cho nhóm của chúng tôi trong việc gỡ lỗi (debug) và xem xét tất cả dữ liệu chúng tôi nhận được để chúng tôi có thể tinh chỉnh các kết quả nghiên cứu của mình.

Đi sâu hơn vào cách chúng tôi đang thực hiện nghiên cứu. Nếu bạn nhìn vào hàm run grounded search, chúng tôi có một lời nhắc đã được viết sẵn. Nếu bạn vào đây, bạn có thể thấy lời nhắc nghiên cứu của chúng tôi. Về cơ bản, chúng tôi đang yêu cầu: nếu có bất kỳ câu hỏi nào, bạn phải cung cấp một câu trả lời chi tiết, toàn diện cho câu hỏi đó. Hãy tập trung vào các tài liệu tham khảo chính thức, có thẩm quyền và đảm bảo bao gồm tất cả các chi tiết liên quan càng nhiều càng tốt. Đồng thời, hãy đảm bảo trích dẫn các nguồn của bạn một cách rõ ràng. Đây là lời nhắc chúng tôi đang sử dụng cho công cụ nghiên cứu chuyên sâu (deep research tool) của mình.

Sau đó, chúng tôi chỉ gọi Giao diện lập trình ứng dụng Gemini (Gemini API) tại đây và nhận được văn bản câu trả lời cùng các nguồn. Trong phần này của codebase, chúng tôi đang... Mỗi khi bạn nhận được các nguồn từ Giao diện lập trình ứng dụng Gemini, chúng không ở dạng có cấu trúc. Vì vậy, ở đây, chúng tôi chỉ cố gắng cấu trúc chúng theo một cách tốt hơn. Tôi sẽ cho bạn thấy điều đó khi tôi chạy. Khi tôi chạy nó, bạn sẽ thấy rằng chúng tôi nhận được kết quả theo cấu trúc này, nơi chúng tôi nhận được URL, title và các snippets. Cuối cùng, chúng tôi đang trả về các kết quả nghiên cứu. Đây là tất cả các chi tiết về công cụ đầu tiên của chúng tôi.

Công cụ Phân tích Video YouTube

Tiếp theo là công cụ thứ hai của chúng tôi, đó là phân tích video YouTube (YouTube video analysis). Công cụ này cũng có cấu trúc tương tự như công cụ nghiên cứu chuyên sâu mà tôi đã chỉ cho bạn. Ba điều: Đầu tiên là tên của công cụ. Thứ hai là các đối số mà nó đang sử dụng. Trong trường hợp này, nó cũng sử dụng thư mục làm việc (working directory) và YouTube URL. Và sau đó là các chi tiết về công cụ, những gì nó đang làm, và các chi tiết về các đối số chúng tôi có. Sau đó, chúng tôi chỉ trả về việc thực thi công cụ.

Đi sâu hơn vào chi tiết về công cụ phân tích video YouTube (analyze YouTube video tool) trông như thế nào. Đây là cách triển khai cho nó. Tương tự như những gì chúng tôi đã làm cho công cụ nghiên cứu chuyên sâu, chúng tôi đang xác thực tất cả các phần ở đây. Sau đó, chúng tôi đang trích xuất ID video YouTube bằng hàm get_video_ID này. Nếu chúng tôi không nhận được ID video cho YouTube URL mà chúng tôi đã cung cấp, chúng tôi sẽ cố gắng làm sạch kết quả và lấy ID video. Và sau đó, chúng tôi đang gọi... Đây là dòng mà chúng tôi đang gọi Giao diện lập trình ứng dụng Gemini. Tương tự như công cụ nghiên cứu chuyên sâu, chúng tôi đang trả về tất cả các chi tiết khác nhau này. Để chúng tôi có thể theo dõi mọi thứ, chúng tôi có thể thấy kết quả mà chúng tôi đã nhận được.

Thực thi và Khả năng Đa phương thức của Gemini

Hãy đi vào việc triển khai phân tích video YouTube (analyze YouTube video). Tương tự như công cụ nghiên cứu chuyên sâu, chúng tôi có một lời nhắc cho bản ghi YouTube. Và đây là lời nhắc chúng tôi đã viết. Chúng tôi chỉ đang nói rằng bạn phải... Điều này về cơ bản đang hướng dẫn Giao diện lập trình ứng dụng Gemini cung cấp cho chúng tôi bản ghi theo một định dạng nhất định và cung cấp cho chúng tôi tất cả các hướng dẫn và chi tiết mà chúng tôi không muốn xuất ra.

Đối với phần này, chúng tôi đang chia yêu cầu của mình thành hai phần: các yêu cầu chúng tôi gửi đến Giao diện lập trình ứng dụng Gemini. Trong phần đầu tiên, chúng tôi đang gửi YouTube URL mà chúng tôi có dưới dạng URI tệp (file URI). Và trong phần thứ hai, chúng tôi đang gửi lời nhắc mà tôi đã chỉ cho bạn. Và, đây là một điều rất thú vị. Gemini là một mô hình đa phương thức (multimodal model). Và nó thực sự, khi bạn gửi YouTube URL dưới dạng URI tệp, nó thực sự "xem" video. Vì vậy, nó đi qua từng phần một. Nó không truy cập bất kỳ loại bản ghi nào. Và đó là lý do tại sao khi chúng tôi chạy công cụ phân tích video YouTube, bạn sẽ thấy rằng nó mất khoảng hai đến ba phút vì nó thực sự đang xem toàn bộ video của bạn. Vì vậy, nó thực sự là đa phương thức.

Ở đây, chúng tôi đang gửi các yêu cầu đến Gemini. Và khi chúng tôi nhận được kết quả, chúng tôi cố gắng làm sạch kết quả mà chúng tôi nhận được theo một định dạng nhất định. Và sau đó, xuất nó và lưu nó vào thư mục .memory mà chúng tôi nhận được.

Công cụ Tổng hợp Kết quả Nghiên cứu

Cuối cùng, quay lại công cụ cuối cùng mà chúng tôi có, đó là Công cụ tổng hợp kết quả nghiên cứu (Compile Research Tool). Về cơ bản, nó làm ở đây là trả về và tổng hợp tất cả các kết quả mà chúng tôi nhận được từ hai công cụ trước đó. Nếu bạn vào đây và xem cách triển khai cho Công cụ tổng hợp kết quả nghiên cứu, bạn sẽ thấy rằng những gì nó đang cố gắng làm là ghi vào tệp output_research.md. Và sau đó nó cung cấp cho chúng ta một loại dữ liệu thành công (success data) hoặc một thông báo trả về.

Đăng ký Công cụ và Tài nguyên với Máy chủ MCP

Chúng tôi đã thấy cách chúng tôi đăng ký công cụ trong máy chủ MCP (MCP server). Tương tự, chúng tôi có codebase để đăng ký các tài nguyên. Vì vậy, đây là tất cả những thứ chúng tôi đang chia sẻ với tác nhân (agent) dưới dạng tài nguyên. Về cơ bản, đó là tên của máy chủ mà chúng tôi có, phiên bản chúng tôi đang sử dụng, loại mô hình Gemini nào chúng tôi đang sử dụng, mô hình phiên âm YouTube của chúng tôi là gì. Và tất cả các chi tiết khác nhau này đang được cung cấp cho tác nhân bằng cách sử dụng tài nguyên.

Lời nhắc MCP và Hướng dẫn Luồng Công việc

Và sau đó là lời nhắc MCP. Đây là cách chúng tôi đã đăng ký lời nhắc MCP. Về cơ bản, chúng tôi đang trả về một thứ gọi là workflow instructions (hướng dẫn luồng công việc). Và đây là lời nhắc chi tiết mà chúng tôi đã viết. Về cơ bản, trong lời nhắc này, chúng tôi đang nói với tác nhân rằng đây là các công cụ có sẵn cho bạn. Và bạn có thể sử dụng luồng công việc này để sử dụng các công cụ này. Và một số chi tiết bổ sung về thư mục làm việc và nơi tất cả các kết quả nên được lưu trữ. Vì vậy, đây là lời nhắc chi tiết mà chúng tôi đang cung cấp cho tác nhân.

Cấu hình Môi trường

Thật tuyệt vời. Quay lại, đây là... Ồ, xin lỗi. Một điều nữa tôi muốn nhấn mạnh ở đây là đây là tệp .env của chúng tôi. Tất cả điều này đang được truy cập dưới dạng tài nguyên, nhưng đây là nơi bạn sẽ phải thêm Khóa API Google (Google API key) của mình. Bạn có thể thêm Khóa API OpenAI (OpenAI API key) nếu bạn muốn bất kỳ loại khả năng quan sát (observability) nào. Nhưng đây là tệp .env mà chúng tôi có. Ngoài ra, chúng tôi có các script ở đây, giúp chúng tôi với codebase xuyên suốt. Và đây là các script chúng tôi đã viết thêm để quản lý một số hướng dẫn.

Tích hợp với Agent Harness (Claude Code)

Xin lỗi. Vâng. Quay lại. Bây giờ chúng ta có toàn bộ kiến trúc ở đó. Vậy chính xác làm thế nào chúng ta kết nối nó với agent harness của chúng ta, trong trường hợp này là Claude Code? Đây là một cách rất đơn giản cho Claude. Bạn chỉ cần tạo một tệp mcp.json trong thư mục gốc của dự án. Và cung cấp cho nó một lệnh như thế này.

Trong trường hợp của chúng tôi, chúng tôi đang chạy MCP cục bộ. Chúng tôi không lưu trữ nó ở bất cứ đâu. Nó đang chạy cục bộ và sử dụng đầu vào/đầu ra chuẩn (standard in và standard out) để giao tiếp. Vì vậy, điều này hoạt động. Nhưng trong trường hợp MCP của bạn được lưu trữ ở nơi khác, bạn sẽ cần một URL, giống như Notion là một ví dụ rất phổ biến. Notion có MCP được lưu trữ riêng. Bạn có thể truy cập nó bằng cách lấy URL. Vì vậy, phần này của codebase sẽ thay đổi một chút. Nếu bạn đang sử dụng lệnh UV, bạn sẽ, ngẫu nhiên, trong lệnh UV, bạn sẽ có URL đó ở đây. Và bạn có thể kết nối với bất kỳ MCP nào có sẵn, Snowflake, Notion, bất cứ thứ gì bạn muốn.

Một điều nữa mà tôi muốn nhấn mạnh ở đây là, như tôi đã nói ở đầu bài nói chuyện của mình, chúng tôi đang sử dụng Claude Code làm agent harness. Bạn có thể sử dụng bất cứ thứ gì bạn muốn. Nếu bạn thích Co-pilot, bạn có thể sử dụng nó cho việc này. Bất kỳ loại agent harness nào bạn muốn sử dụng, MCP. Vì vậy, nếu bạn muốn sử dụng nó cho việc này, bạn có thể sử dụng nó cho việc này.

Cấu trúc Tệp MCP.json

Đây là một Claude Code nhanh chóng. Được rồi, hãy xem tệp đó ở đâu. Nó ở trong... Vì vậy, bạn phải tạo tệp mcp.json đó ngay trong thư mục gốc. Và đây là, tôi có thể giải thích cho bạn. Đó là một điều rất đơn giản. Ở đây chúng ta có tên của máy chủ MCP. Chúng ta có vpresearch. Và đây là lệnh mà chúng ta có. Môi trường ảo (virtual environment) mà bạn đang tạo, bất kỳ loại gói (packages) nào bạn đang tải xuống. Việc tải xuống đều được UV xử lý. Vì vậy, bạn không phải làm bất cứ điều gì. Và sau đó chúng ta có lệnh này, về cơ bản là chạy tệp server mà tôi đã chỉ cho bạn vài phút trước. Vì vậy, nó chỉ làm điều đó. Claude chạy tệp server dưới dạng một tiến trình con (sub-process) cục bộ. Vì vậy, server của chúng ta đang chạy cục bộ. Và toàn bộ codebase này, xin lỗi, toàn bộ lệnh này chỉ làm điều đó. Nó nói chạy fast mcp, chạy, và đường dẫn đến tệp server mà chúng ta có. Và đây là tệp môi trường mà tôi đã nói với bạn rằng bạn phải tạo.

Demo: Chạy Công cụ Phân tích Video YouTube trên Claude Code

Được rồi. Bây giờ là lúc để xem codebase hoạt động như thế nào. Tôi sẽ vào Claude. Xin lỗi. Được rồi. Nếu bạn vào Claude và bạn làm mcp, bạn có thể thấy rằng tôi có hai máy chủ ở đây. Vì tệp mcp.json mà tôi có, nó đã tự động phát hiện cả hai tác nhân. Vì vậy, chúng ta sẽ chỉ xem tác nhân D-presearch ngay bây giờ. Và đây là tất cả các chi tiết. Bạn có thể thấy lệnh, bạn có thể thấy các đối số mà chúng ta có. Bạn có thể thấy tất cả các khả năng (capability) mà server đang hiển thị. Vì vậy, bạn chỉ cần xem công cụ (view tools). Và bạn có thể thấy tất cả các chi tiết về các công cụ. Tên công cụ, mô tả mà tôi đã chỉ cho bạn, tất cả các đối số, các tham số (parameters) mà chúng ta có, tương tự cho tất cả các công cụ khác, bạn có thể thấy tất cả các chi tiết ở đây.

Bây giờ, tôi sẽ cố gắng, xin lỗi, tôi sẽ cố gắng chạy một trong các công cụ và xem Claude làm điều đó như thế nào. Vì vậy, tôi đã viết sẵn câu hỏi này. Đây là từ một cuộc nói chuyện AI trước đó về tác nhân AI (AI agent). Vì vậy, tôi sẽ chỉ yêu cầu nó phân tích video này cho tôi. Và nó sẽ tự động phát hiện công cụ mà chúng ta có, đang được máy chủ MCP hiển thị.

Bạn có thể thấy ở đây rằng nó đã tự động chọn công cụ mà chúng ta đang hiển thị. Và nó đang cố gắng sử dụng nó. Ở bên cạnh, bạn có thể thấy một dot-pollot. Và bạn có thể thấy thư mục .memory mà tôi đã nói với bạn, nơi chúng ta đang theo dõi tất cả các kết quả của mình. Nó đang được tạo và nó sẽ ghi bản ghi vào tệp này. Như tôi đã nói với bạn, Gemini đang xem hoặc phân tích video này trong thời gian thực. Đó là lý do tại sao nó mất khoảng vài phút để tạo bản ghi.

Vâng. Về cơ bản, mỗi khi bạn nhận được câu hỏi này, Claude Code cố gắng xem nó có thể làm gì, những công cụ nào có sẵn. Và sau đó gửi yêu cầu đến máy chủ MCP, "Bạn có thể vui lòng thực thi công cụ này không?". Và khi MCP thực thi công cụ, nó sẽ gửi kết quả trở lại Claude Code và sau đó Claude Code sẽ phân tích thêm kết quả đó. Chúng ta có thể tạo một phút cho điều đó.

Kết quả và Tóm tắt

Vâng. Nó đã tạo tệp markdown này. Vì vậy, nó nói rằng video này là từ hội nghị thượng đỉnh mã nguồn của kỹ sư AI (AI engineer code summit). Nó đã cung cấp cho tôi tất cả các chi tiết. Và đây là một bản ghi chi tiết khá tốt mà chúng ta có thể thấy ở đây. Và nó cũng đưa ra đầu vào của nó ở cuối. Ngoài ra, tôi cũng thực sự thích điều này là chúng ta đang lưu trữ tất cả bản ghi, nhưng nó cung cấp cho bạn một bản tóm tắt rất gọn gàng ở dưới cùng, nơi nó nói, tất cả các ý chính đã được chia sẻ trong video.

Chạy Thử Nghiệm Công Cụ và Pipeline

Và, bạn biết đấy, transcript ở đây. Vậy, đây là một ví dụ ngắn gọn về cách chúng ta có thể chạy và xem liệu Claude có thể chạy một trong các công cụ đó hay không. Giờ đây, tôi sẽ thử chạy lại toàn bộ pipeline. Tôi đã viết sẵn một câu hỏi cho việc đó. Tôi đang yêu cầu nó thực hiện một nghiên cứu end-to-end. Và giờ tôi đang cố gắng sử dụng công cụ nghiên cứu chuyên sâu và công cụ video YouTube mà tôi có. Tôi đang cố gắng xem nó chạy cả hai công cụ đó cùng nhau như thế nào. Nó nói rằng nó đang cố gắng thực hiện phần phân tích video YouTube.

Vậy, khi bạn có một câu hỏi lớn như thế này, toàn bộ quy trình làm việc sẽ hoạt động như sau: Claude chia câu hỏi thành các phần khác nhau và sau đó xem nó cần công cụ nào. Vì vậy, có một toàn bộ quá trình lý luận diễn ra rằng, nếu đây là những loại công cụ tôi có sẵn, tôi cần công cụ phân tích video YouTube để phân tích video YouTube. Tôi cần công cụ nghiên cứu chuyên sâu cho phần đầu tiên của câu hỏi. Vì vậy, nó sẽ chia thành hai phần và sau đó cố gắng gọi cả hai công cụ. Chắc chắn rồi, xin lỗi, thường mất một chút thời gian để nó thực hiện. Tôi thực sự sẽ nói về điều đó. Vâng, tôi thực sự sẽ nói về điều đó, đó là phần tiếp theo. Ban đầu, tôi đã cố gắng xóa kỹ năng khi di chuyển nó vào thư mục tạm thời và nó không nhận kỹ năng đó vì nó có xu hướng làm như vậy. Không phải về điều đó, chỉ là phần lời nhắc thôi. Không, ý tôi là đối với chúng tôi, chúng tôi đang sử dụng kỹ năng và thay thế phần lời nhắc. Vì vậy, tôi sẽ chỉ cho bạn cách sử dụng toàn bộ điều đó trong một phút nữa, tôi nghĩ điều đó có thể làm rõ câu hỏi của bạn. Ở đây, nó cung cấp cho tôi, bạn biết đấy, nó giống như phân tích video YouTube một lần nữa, nó không đưa ra toàn bộ câu trả lời cho phần đầu tiên. Nhưng vâng, ý tôi là tôi nghĩ nó chỉ cần, xin vui lòng chờ một chút. Tôi phải xóa ngữ cảnh của Claude vì nó có xu hướng sử dụng bất cứ điều gì tôi đã hỏi trước đó. Và tôi muốn xóa thư mục bộ nhớ. Vì vậy, trong khi điều này đang chạy và tạo nghiên cứu cho chúng ta. Xin lỗi, trong khi nó đang chạy và tạo nghiên cứu, tôi có thể nói về slide tiếp theo mà chúng ta có, đó là kỹ năng tác nhân.

Giới Thiệu Kỹ Năng Tác Nhân

Tôi chắc chắn rằng tất cả các bạn hẳn đã nghe nhiều về kỹ năng tác nhân. Nó đang rất phổ biến hiện nay. Đây về cơ bản là một cách cô đọng, súc tích để nói cho tác nhân biết về các khả năng và quy trình làm việc. Về cơ bản, các công cụ thực hiện công việc, và các kỹ năng cung cấp cách để thực hiện công việc đó. Chúng ta đã nói về toàn bộ lời nhắc mà tôi đã trình bày cho bạn, lời nhắc quy trình làm việc mà chúng ta có. Trong đó, chúng ta đã nói với tác nhân của mình rằng đây là những công cụ có sẵn và đây là cách bạn nên thực thi chúng. Nhưng thay vì viết nó trong lời nhắc, chúng ta có thể tạo ra một kỹ năng từ đó. Và lợi ích của việc này là gì? Khi một thứ đã giải quyết được vấn đề, tại sao chúng ta lại phải tạo ra một thứ khác? Lý do là kỹ năng có thứ gọi là progressive disclosure (tiết lộ dần).

Lợi Ích và Cấu Trúc của Kỹ Năng

Khi bạn tải kỹ năng, như tôi đã làm và sẽ trình bày cho bạn trong một phút nữa, khi Claude hiển thị kỹ năng đó, nó không tải toàn bộ thông tin. Nó chỉ tải tên và mô tả của kỹ năng. Khi bạn chạy một truy vấn, nó sẽ tải toàn bộ mọi thứ. Và khi truy vấn đó được thực thi, nó sẽ xóa bỏ tất cả. Vì vậy, nó sẽ không còn trong ngữ cảnh nữa. Trong khi đó, khi bạn sử dụng lời nhắc, mọi thứ sẽ nằm trong ngữ cảnh. Nó sẽ xóa ngữ cảnh. Do đó, bạn sẽ muốn tránh điều đó. Vậy nên, kỹ năng là một cách rất gọn gàng để làm điều này. Và nó cũng rất dễ chia sẻ, bởi vì chúng tôi nội bộ viết rất nhiều kỹ năng cho nhóm của mình và chia sẻ với nhau. Vì vậy, đó là một cách súc tích, dễ chia sẻ. Và nó dễ bảo trì hơn, bởi vì bạn có thể kiểm tra nó trên GitHub. Nó giống như nơi bạn thường xuyên truy cập và bạn có thể làm mọi thứ ở đó. Vậy, chúng ta đã có kết quả cho việc này.

Nhưng trước đó, tôi muốn trình bày cách chúng tôi đã viết các kỹ năng. Chúng tôi đã viết các kỹ năng nghiên cứu. Điều này thay thế lời nhắc mà chúng ta có. Ở đây, bạn phải viết tên của kỹ năng bạn muốn. Bạn cần viết mô tả. Lý do mô tả này cần thiết là vì khi tác nhân của bạn cố gắng khớp một truy vấn với một kỹ năng, nó sẽ xem xét phần này của kỹ năng. Vì vậy, bạn cần có một mô tả tốt ở đây. Và sau đó, đây được gọi là front matter được tải. Và đây là phần còn lại của kỹ năng. Trong trường hợp của chúng tôi, chúng tôi đang tái sử dụng lời nhắc quy trình làm việc nghiên cứu mà chúng tôi có, thay vì viết tất cả các chi tiết vào đây. Bạn có thể làm vậy, nhưng đó là một lựa chọn thiết kế của chúng tôi. Và đây là phần thân còn lại của kỹ năng.

Tải và Sử Dụng Kỹ Năng

Vậy, làm thế nào để bạn có thể xem tất cả các kỹ năng đó và ý tôi là gì khi nó chỉ tải front matter? Nếu bạn vào Claude một lần nữa, và nếu bạn nhập skills, bạn sẽ có thể thấy. Đây là một số kỹ năng mà tôi đã tải xuống và đây là các kỹ năng dự án mà chúng tôi đã tạo. Cụ thể là kỹ năng nghiên cứu mà tôi đã đề cập. Và mỗi khi bạn làm điều này và nhìn thấy, chỉ front matter được tải, chứ không phải toàn bộ mô tả. Và, bạn thực sự có thể, nếu muốn sử dụng điều này, bạn chỉ cần làm như thế này. Hoặc Claude có thể tự động chọn kỹ năng khi bạn hỏi một câu hỏi.

Tác Nhân AI Thực Hiện Lý Luận và Nghiên Cứu

Bây giờ, tôi sẽ cố gắng hỏi nó cùng một câu hỏi mà tôi đã hỏi với MCP. Được rồi. Vậy, tôi sẽ yêu cầu nó nghiên cứu kỹ năng tác nhân AI là gì và đồng thời phân tích video YouTube cho tôi. Vâng. Nó đang tải lời nhắc quy trình làm việc nghiên cứu và có thể làm được điều đó vì server của chúng tôi đang chạy cục bộ. Và đó là lý do tại sao nó có thể đọc lời nhắc vì chúng đều nằm trong cùng một thư mục. Và bây giờ, bạn có thể thấy, nó đã bắt đầu thực hiện nghiên cứu chuyên sâu. Xin lỗi. Vậy là nó đã tạo ra, nó đang chạy nghiên cứu chuyên sâu ở đây. Và sau đó, nó đã chạy, đầu tiên, nó chạy công cụ phân tích video YouTube. Sau đó, nó đang chạy công cụ nghiên cứu chuyên sâu.

Và tôi nghĩ một điều tuyệt vời ở đây mà tôi muốn nhấn mạnh là truy vấn ban đầu của tôi là, bạn có thể cung cấp cho tôi chi tiết về kỹ năng tác nhân không. Và mỗi khi, agent harness của chúng tôi xác định khoảng trống trong output mà nó nhận được. Vì vậy, trong câu hỏi ban đầu của tôi, nó sẽ xác định tất cả các khoảng trống hiện có. Và sau đó, nó sẽ hỏi một câu hỏi khác mỗi lần để lấp đầy khoảng trống đó. Vì vậy, nó đang thực hiện tất cả quá trình lý luận đằng sau hậu trường và đảm bảo rằng tất cả các khoảng trống đó được lấp đầy trong nghiên cứu mà chúng tôi đang cố gắng thực hiện. Vâng, ý tôi là, thường mất khoảng hai đến ba phút để tôi chạy toàn bộ output này. Vâng, hãy cùng xem. Chắc chắn rồi. Vâng. Ý tôi là, chúng tôi đã xây dựng nó ban đầu với phần MCP. Và bây giờ, chúng tôi đang chuyển đổi, nhưng chúng tôi muốn giữ cơ sở mã gốc của mình. Và, ý tôi là, không phải phần server, mà là lời nhắc mà chúng tôi có, chúng tôi có thể thay thế nó bằng kỹ năng. Nhưng, chúng tôi có rất nhiều chi tiết và các thành phần khác nhau trong các server. Đó là lý do chúng tôi muốn duy trì điều đó. Vâng. Vâng. Vâng. Trong trường hợp đó, đó là về sự phức tạp nhiều hơn. Đó là lý do tại sao chúng tôi muốn duy trì điều đó.

Tạo Báo Cáo Tổng Hợp

Tại đây, bạn có thể thấy, chúng ta đã có output của video. Và bây giờ chúng ta chỉ cần đợi nó tạo ra output cho tệp MCP. Vậy, ở đây bạn có thể thấy, đây là câu hỏi ban đầu của tôi. Và, nó đã đưa ra câu trả lời cho tôi. Đây là lần chạy đầu tiên mà chúng tôi có. Và bây giờ nó đang thực hiện thêm nghiên cứu về điều đó. Bởi vì, nó đã đưa ra một câu trả lời, nhưng nó xác định một số khoảng trống trong đó. Vì vậy, đây là truy vấn thứ hai nó đã chạy. Và, đây là một câu hỏi khác, bạn có thể thấy ở đây. Vì vậy, nó đã chạy hai truy vấn và nó giống như, được rồi, điều này là đủ tốt. Và sau đó, nó nói rằng cả ba nhiệm vụ nghiên cứu đã hoàn thành. Hãy để tôi chạy thêm một truy vấn nhắm mục tiêu nữa và sau đó hoàn thành mọi thứ. Vì vậy, đó là lý do tại sao chúng tôi muốn tất cả quá trình lý luận được thực hiện bởi các tác nhân. Bởi vì, đây là điều mà con người sẽ làm. Bởi vì nếu bạn đang đọc một bài báo hoặc đang thực hiện bất kỳ loại nghiên cứu nào, bạn sẽ cố gắng xác định các khoảng trống và cố gắng lấp đầy chúng. Vì vậy, đó là điều nó đang cố gắng làm và đó là lý do tại sao chúng tôi cần tất cả trí tuệ. Và, cố gắng tận dụng điều đó. Vì vậy, đây là truy vấn thứ ba mà nó đang chạy cho tôi. Và, cuối cùng, chúng tôi mong đợi nó sẽ tạo ra một báo cáo tổng hợp, điều này sẽ diễn ra trong vài phút nữa.

Chắc chắn rồi. Tôi nghĩ, ý tôi là, điều đó, chúng ta sẽ phải xem khả năng quan sát cho việc đó. Và, kiểm tra và xác định tại sao nó không thấy mã mới nhất. Nhưng chúng tôi cũng đã cung cấp cho nó một video từ năm 2020. Vì vậy, tôi nghĩ có lẽ là do điều đó. Video mà tôi yêu cầu nó transcribe là về điều đó. Nhưng tôi nghĩ để trả lời điều đó tốt hơn, tôi muốn xem tất cả phần khả năng quan sát của cơ sở mã mà chúng tôi có và xem điều gì đang xảy ra ở đó. Vì vậy, cuối cùng, nó hỏi tôi liệu nó có thể tạo một tệp markdown cho tôi không.

Vậy, đây là tệp markdown nghiên cứu mà công cụ cuối cùng của chúng tôi tạo ra. Và, nó thực sự chi tiết. Nó có tất cả các bảng so sánh. Và, nó có tất cả các chi tiết. Vì vậy, tôi nghĩ đây là một cách rất hay để tổng hợp mọi thứ mà chúng ta đã thu thập được cho đến nay. Và, nó cũng tổng hợp và thêm liên kết video YouTube mà chúng ta có. Xin lỗi, transcript video mà chúng ta có ở phía dưới. Vâng. Cảm ơn tất cả mọi người rất nhiều. Bây giờ, tôi sẽ chuyển giao cho Paul. Tuyệt vời. Cảm ơn Luis và Samad đã có những slide tuyệt vời đó. Và, xin cho tôi một giây để thiết lập mọi thứ ở đây.

Giới Thiệu Quy Trình Làm Việc Viết Bài LinkedIn

Được rồi. Bây giờ chúng ta sẽ chuyển sang phần ba của toàn bộ hệ thống này, đó là quy trình làm việc viết bài LinkedIn, về cơ bản là chuyển đổi nghiên cứu này từ tác nhân nghiên cứu chuyên sâu thành các bài đăng tinh chỉnh, đạt yêu cầu để chúng ta có thể biến tất cả các bạn thành những người có ảnh hưởng trên LinkedIn. Được rồi. Vậy, đây là một cái nhìn tổng quan cấp cao về kiến trúc hệ thống hoàn chỉnh của chúng ta. Chúng tôi đã triển khai tác nhân nghiên cứu, tạo ra output là tệp nghiên cứu và được sử dụng làm input cho quy trình làm việc viết bài, ngoài ra còn có input là tệp guideline.md. Tệp này về cơ bản là một cách nói hoa mỹ về đầu vào của người dùng. Và đây là cách chúng ta sẽ mô hình hóa đầu vào của người dùng để hướng dẫn quá trình tạo sinh. Và output cuối cùng sẽ là các bài đăng LinkedIn, phải không?

Được rồi. Bây giờ, hãy thực sự đi sâu vào kiến trúc, được chia thành ba phần lớn. Phần đầu tiên là nơi chúng ta xây dựng ngữ cảnh, và cuối cùng chúng ta sẽ có lời nhắc hệ thống lớn. Bởi vì hãy nhớ, đây, cuối cùng đây không phải là một tác nhân, đây chỉ là một quy trình làm việc vì trên thực tế, để viết một nội dung nào đó, bất kể đó là gì, bài đăng LinkedIn, video hay bài báo, bạn không thực sự cần tác nhân, phải không? Bởi vì như Luis đã nói lúc đầu, quá trình này có thể là tĩnh, bạn luôn đi theo các bước giống nhau. Vì vậy, một tác nhân sẽ chỉ làm mọi thứ trở nên phức tạp hơn rất nhiều. Tất nhiên, bạn có thể đặt các tác nhân vào một số phần của nó, nhưng chúng tôi sẽ không trình bày điều đó trong buổi hội thảo này.

Xây dựng Lời nhắc Hệ thống và Tạo Bản nháp Đầu tiên

Phần đầu tiên là tải ngữ cảnh, bao gồm hướng dẫn và định nghĩa, tức là đầu vào của người dùng, nghiên cứu. Sau đó, chúng ta có một số tệp tĩnh, các hồ sơ, mà tôi sẽ đi sâu vào chi tiết hơn sau. Chúng tôi tổng hợp tất cả những yếu tố này, xây dựng một lời nhắc hệ thống, sau đó chuyển tất cả đến Mô hình Ngôn ngữ Lớn (LLM). Đây là giai đoạn hai. Cho đến nay, không có gì phức tạp, chúng tôi chỉ đơn giản tạo ra lời nhắc hệ thống khổng lồ này và gọi LLM để tạo ra bản nháp đầu tiên của bài đăng.

Vòng lặp Tối ưu hóa Đánh giá

Giai đoạn cuối cùng là áp dụng vòng lặp tối ưu hóa đánh giá (evaluator optimizer loop), có lẽ là phần thú vị nhất, nơi chúng tôi cho LLM tạo đánh giá lặp lại và chỉnh sửa bài đăng vài lần. Điều này cực kỳ quan trọng vì trên thực tế, bạn có thể áp dụng điều này không chỉ cho bài đăng LinkedIn mà cho bất kỳ loại nội dung nào, từ bản ghi video, đến báo cáo, báo cáo tài chính, báo cáo y tế, hoặc thậm chí bài viết, chương sách, hoặc các bài học chi tiết như chúng tôi đã làm trong khóa học của mình, nơi chúng tôi cần tuân theo các đoạn văn bản, hình ảnh, đoạn mã, tài liệu tham khảo và tất cả những chi tiết nhỏ mà LLM đôi khi làm đúng, nhưng thường xuyên hơn là không đúng. Và ngay cả khi chúng đúng 80% thời gian, việc thủ công đi sửa chữa vẫn rất khó chịu, phải không? Đó là toàn bộ vấn đề, vì vậy tất cả điều này được tự động hóa và cứ thế. Chúng ta sẽ đào sâu hơn vào quy trình này sau.

Ví dụ thực tế: Kiểm tra chất lượng bài đăng LinkedIn

Đây chỉ là một trong các ví dụ của chúng tôi. Đây là phần mở đầu của một bài đăng LinkedIn mà chúng tôi yêu cầu tạo ra. Để cho vui, tôi muốn sao chép bài đăng này (là bài đăng chính xác tương tự) và đưa nó vào Slopscore detector khá phổ biến này. Bạn có thể tin tưởng tôi rằng điều này thực sự hoạt động, và sau khi nhấn phân tích, kết quả là "không Slop". Và điều này thực sự có chất lượng thấp hơn và ít Slop-py hơn so với một người, như bạn có thể thấy ở phía dưới. Tất nhiên, không phải tất cả các bài đăng đều không Slop-ish như vậy, nhưng hầu hết chúng đều thực sự tốt và nghe giống con người. Nhưng hãy nhớ, đây là ngôn ngữ LinkedIn, vì vậy chúng ta cần phải nghe hơi giống LinkedIn, phải không? Nhưng cuối cùng, như bạn thấy, nó không có bất kỳ dấu gạch ngang dài, bất kỳ trạng từ hay động từ lạ nào, và những thứ tương tự. Nó có thể được đọc rất trôi chảy, cấu trúc của nó, à, là Kimmelball, như chúng tôi mong muốn cho LinkedIn và những thứ như vậy. Bạn có thể kiểm tra toàn bộ bài đăng tại liên kết này trong kho lưu trữ GitHub và cũng có thể tự mình thử Slop test nếu bạn không sử dụng liên kết đó.

Kiểm soát quá trình tạo nội dung

Bây giờ, hãy đi sâu hơn vào giai đoạn đầu tiên của quy trình làm việc này, nơi trọng tâm cốt lõi của chúng tôi là hiểu cách chúng ta có thể thực sự kiểm soát việc tạo ra nội dung. Bởi vì như chúng tôi đã nói lúc đầu, chúng tôi không chỉ muốn viết, "Này, tôi muốn một bài đăng LinkedIn về chủ đề X," mà chúng tôi thực sự muốn đưa ý tưởng, giá trị và suy nghĩ của mình vào bài đăng đó để nó thực sự giống chúng tôi.

Mẹo đầu tiên thực ra là cấu trúc hướng dẫn này (là đầu vào của người dùng) và cấu trúc nó nhiều hơn là chỉ viết một bài đăng về X, phải không? Vì vậy, điều này thực sự định hướng những gì chúng tôi muốn viết. Thông thường, chúng tôi đã tạo một mẫu cho việc này, nơi chúng tôi cần điền vào các mục như chủ đề muốn đề cập, góc độ muốn có, một số điểm chính, luồng tường thuật, v.v. Và đây là phần duy nhất thay đổi từ bài đăng này sang bài đăng khác. Vì vậy, về cơ bản, từ toàn bộ hệ thống, đây là những gì chúng ta cần tự viết ra với tư cách là con người như một đầu vào để viết một bài đăng khác. Và vâng, như tôi đã nói, điều này là động và thay đổi. Tiếp theo, và một lần nữa, bạn có thể xem một ví dụ ở đây trong ví dụ này từ repo cùng với nhiều cái khác, nhưng tôi sẽ trình bày chúng sau.

Hồ sơ viết lách và Ví dụ Few-shot

Mẹo thứ hai là thêm các hồ sơ viết lách này, về cơ bản cho LLM biết cách viết bài đăng này, phải không? Bởi vì trên thực tế, bạn không thực sự muốn LLM tự làm việc của mình, bạn muốn hướng dẫn nó. Và những hồ sơ này là tĩnh vì như tôi đã nói với hướng dẫn, bạn định nghĩa những gì bạn muốn viết. Và đây là cách bạn định nghĩa cách bạn muốn viết nó. Về cơ bản, đó là lớp tạo kiểu trên cùng. Và chúng tôi chủ yếu tạo ba hồ sơ, bản thân chúng là tệp Markdown, đó là hồ sơ cấu trúc, nơi chúng tôi định nghĩa những thứ như số lượng ký tự trung bình mà một bài đăng LinkedIn có, giống như cấu trúc cốt lõi của một bài đăng LinkedIn, chúng tôi muốn câu dẫn, nội dung chính, kêu gọi hành động, và cả thuật ngữ nữa. Đối với hồ sơ thuật ngữ, chúng tôi định nghĩa những thứ như thể chủ động và các AISLOP words và expressions mà chúng tôi muốn cấm. Và thật không may, đây là tất cả những gì bạn có thể làm. Bạn chỉ cần theo dõi một danh sách khổng lồ các từ delvetetistry, vibrant và tất cả những từ mà chúng ta yêu thích, và chỉ cần nhẹ nhàng yêu cầu LLM không sử dụng chúng cho đến khi bạn cũng bắt đầu sử dụng chúng như một con người. Và cuối cùng là hồ sơ nhân vật, nó có vẻ tĩnh, nhưng bạn cũng có thể cấu hình nó. Ví dụ, trong quy trình làm việc viết lách của chúng tôi, chúng tôi thực sự cấu hình nó dưới dạng polystened biography của tôi, phải không? Vì vậy, nó biết một chút về tôi, cách tôi thường viết, cách tôi thích viết phong cách của mình và những thứ tương tự. Và đây là cách bạn có thể thêm một chút cá tính vào đó. Vì vậy, một lần nữa, chúng tôi đưa tất cả những điều này vào lời nhắc hệ thống cộng với hướng dẫn mà chúng tôi đã định nghĩa trước đó. Và bạn có thể thấy chúng là tĩnh, vì vậy như tôi đã nói, chúng tôi chỉ định nghĩa chúng một lần và bạn có thể truy cập chúng trong hồ sơ viết lách và xem xung quanh. Có những tệp Markdown dài vài trăm dòng từ, phải không?

Mẹo cuối cùng thực ra là thêm các ví dụ few-shot. Điều này không có gì phức tạp, nhưng trên thực tế, phần khó là làm thế nào để có được chúng đúng cách. Về cơ bản, điều này nằm trong phần thu thập dữ liệu của hệ thống của bạn. Và trong trường hợp sử dụng cụ thể của chúng tôi, chúng tôi đã thêm khoảng ba bài đăng LinkedIn từ các bài viết của tôi. Ý tưởng chính là sử dụng các ví dụ few-shot chất lượng cao và đại diện và làm cho chúng đa dạng về chủ đề, độ dài, cấu trúc, v.v. Và một câu hỏi mà tôi nghĩ nhiều người tò mò là tại sao lại là ba bài đăng LinkedIn? Tôi biết ba là một con số kỳ diệu, nhưng thực tế, tôi chỉ đoán thôi. Và vấn đề là với các ví dụ few-shot, bởi vì bạn luôn truyền chúng vào lời nhắc hệ thống của mình, bạn muốn số lượng thấp nhất có thể mà vẫn hoàn thành công việc. Vì vậy, thông thường mọi người nói khoảng ba, năm, mười, hai mươi ví dụ few-shot, nhưng thường bạn muốn bắt đầu với số lượng lớn hơn và cắt giảm càng nhiều càng tốt cho đến khi nó hoạt động. Và khi nó ngừng hoạt động, bạn đưa lại vào. Bởi vì bạn muốn giữ lời nhắc hệ thống của mình với các ví dụ few-shot càng nhỏ càng tốt, bởi vì, bạn luôn truyền điều đó cho rất nhiều LLM, điều này dẫn đến nhiều chi phí hơn, nhiều độ trễ hơn, và thậm chí làm giảm hiệu suất vì nội dung tăng lên.

Tập dữ liệu và Tinh chỉnh

Vì vậy, tôi đã cung cấp một tập dữ liệu có sẵn trong kho lưu trữ GitHub nơi tôi đã trích xuất khoảng hai mươi bài đăng LinkedIn ngẫu nhiên từ hồ sơ của tôi mà có nhiều tương tác hơn. Vì vậy, tôi đã sử dụng điều đó làm tập dữ liệu cho quy trình làm việc viết lách này và sau này để cấu hình những thứ khác. Và một điều cần nhấn mạnh là cách duy nhất để giảm tải này trên lời nhắc hệ thống với các ví dụ few-shot có lẽ là tinh chỉnh, nhưng điều đó thường quá mức cần thiết và thêm rất nhiều trở ngại vào ngăn xếp công nghệ của bạn.

Mẫu Đánh giá Tối ưu hóa

Phần cuối cùng của hệ thống là mẫu đánh giá tối ưu hóa (evaluator optimizer pattern), mà có lẽ là phần phức tạp nhất trong tất cả. Về cơ bản, nó chứa 12 lệnh gọi LLM và điều này thực sự quan trọng. Nó chứa hai cửa sổ ngữ cảnh khác nhau, đó là người viết và người đánh giá. Người viết sẽ viết bản nháp đầu tiên, và người đánh giá với một cửa sổ ngữ cảnh hoàn toàn khác, sẽ xem xét bản nháp đó và đưa ra đánh giá. Điều này cực kỳ quan trọng để tránh sai lệch vì các LLM thường có xu hướng sai lệch khi thích những gì chúng đã viết. Việc đưa nó vào một cửa sổ ngữ cảnh hoàn toàn mới có thể loại bỏ sai lệch đó.

Về cơ bản, cách thức hoạt động như sau: người đánh giá kiểm tra sự tuân thủ của bản nháp đối với hướng dẫn (là đầu vào của người dùng), đối với nghiên cứu (về cơ bản là để loại bỏ ảo giác), và đối với các hồ sơ (gồm hồ sơ cấu trúc, hồ sơ thuật ngữ và hồ sơ nhân vật). Vì vậy, chúng tôi đảm bảo rằng nó tuân thủ các quy tắc. Sau đó, người chỉnh sửa (thường là chính người viết) sẽ áp dụng các đánh giá. Và sau đó, chúng tôi chạy vòng lặp này trong ví dụ của chúng tôi, ba hoặc bốn lần để về cơ bản viết bài đăng, đánh giá nó, chỉnh sửa nó, tối ưu hóa nó, v.v. Điều này tương tự như một vòng lặp tối ưu hóa tinh chỉnh.

Thủ thuật tối ưu hóa và Phản hồi Chủ quan

Một vài thủ thuật mà chúng tôi đã học được theo thời gian là việc chỉ cần giữ tất cả các phiên bản đó trong thư mục làm việc của chúng tôi sẽ hữu ích, bởi vì viết lách là chủ quan và thường nếu bạn áp dụng người đánh giá này quá quá mức, nó có thể khiến bạn không thích nó. Vì vậy, bạn muốn xem xét các phiên bản trước đó và chọn cái mà bạn thích nhất. Và một lần nữa, bởi vì viết lách là chủ quan. Thông thường, mẫu đánh giá tối ưu hóa hoạt động với một điểm số. Về cơ bản, người đánh giá đưa ra một điểm số cho đầu vào và bạn vòng lặp cho đến khi đạt được một ngưỡng cụ thể. Nhưng vì công việc sáng tạo là chủ quan, ngưỡng đó rất khó định lượng. Và vòng lặp này trở nên rất nhiễu loạn và không đáng tin cậy. Và chúng tôi nhận ra rằng việc chỉ đặt một số lần lặp cố định và để người dùng chạy các lần lặp này thủ công lần nữa nếu họ muốn thì dễ dàng hơn.

Cách thức hoạt động của Người đánh giá và Người chỉnh sửa

Bây giờ chúng ta hãy đi sâu hơn một chút vào cách người đánh giá hoạt động. Về cơ bản, đầu vào của nó là trạng thái hiện tại của bài đăng. Tiếp theo, là ngữ cảnh, nó nhận hướng dẫn, nghiên cứu và các hồ sơ, về cơ bản là những gì người viết cần xem xét, và chúng là các quy tắc mà người viết cần tuân theo. Và đầu ra thực sự là một tập hợp các đối tượng Pydantic. Và tôi nghĩ đây là phần thú vị nhất ở đây là bạn thực sự buộc LLM phải xuất ra một danh sách các đối tượng có cấu trúc. Và điều này rất mạnh mẽ vì nếu bạn cung cấp một đối tượng Pydantic cho một LLM. Các đối tượng có thuộc tính này nơi bạn có thể đặt một trường dưới mỗi thuộc tính và thực sự giải thích ý nghĩa của trường đó. Vì vậy, về cơ bản, đây là một kỹ thuật prompt engineering giúp hướng dẫn LLM tốt hơn rất nhiều trong việc thực sự hiểu từng thuộc tính của đối tượng trả về cần chứa gì. Ví dụ, mô hình đánh giá của chúng tôi có các thuộc tính vị trí hồ sơ và nhận xét. Và một đầu ra ví dụ là, ví dụ: "Chúng tôi vi phạm hồ sơ thuật ngữ ở đoạn văn hai nơi LLM đã sử dụng thuật ngữ bị cấm (leverage ban term)." Và cứ như vậy, chúng tôi, người chỉnh sửa, khi nhận được những đánh giá này, sẽ hiểu chính xác những gì đã vi phạm. Và từ các thử nghiệm của chúng tôi, chúng tôi nhận ra rằng việc sử dụng đầu ra có cấu trúc dễ dàng hơn rất nhiều – thực tế, nó cho hiệu suất tốt hơn nhiều khi sử dụng đầu ra có cấu trúc – hơn là chỉ để LLM, tôi không biết, xuất ra bất cứ thứ gì nó muốn. Một lần nữa, bạn có thể kiểm tra mã này trong tệp Python này. Mã này khá đơn giản, vì vậy thật không may, tôi sẽ không có thời gian để đi sâu vào nó.

Bây giờ, về phần người chỉnh sửa, về cơ bản, nó nhận danh sách các đối tượng Pydantic này và trạng thái hiện tại của bài đăng. Và nó cũng nhận tất cả ngữ cảnh mà người viết ban đầu có vì người chỉnh sửa thực ra chính là người viết, phải không? Điều này tương tự như cách một nhóm người viết và người chỉnh sửa làm việc. Tôi viết một cái gì đó, tôi đưa nó cho một nhóm người chỉnh sửa, tôi nhận được các đánh giá và tôi áp dụng chúng. Và một điều quan trọng nữa là các đánh giá không có giá trị ngang nhau, phải không? Đặc biệt là mọi người thường thích đưa ra đánh giá về mọi thứ. Và điều này cũng đúng với các LLM. Và bởi vì chúng tôi vòng lặp vài lần, chúng tôi nhận ra rằng việc đặt mức độ ưu tiên cho chúng là cực kỳ quan trọng. Vì vậy, thông thường chúng tôi luôn muốn ưu tiên hướng dẫn trước (là đầu vào của người dùng), sau đó là nghiên cứu và hồ sơ. Và điều này cực kỳ mạnh mẽ khi những đánh giá đó xung đột trên cùng một đoạn văn hoặc trên cùng một câu và những thứ tương tự, chúng cho LLM biết nên chọn cái nào và áp dụng cái nào.

Ví dụ cụ thể

Một lần nữa, bạn có thể kiểm tra lời nhắc của hệ thống trong tệp Python này trong repo. Và đây là một ví dụ cụ thể nơi chúng ta có thể thấy bài đăng V0, về cơ bản là những gì LLM tạo ra trước vòng lặp tối ưu hóa đánh giá. Và đây là giao diện của nó sau bốn lần lặp đánh giá.

Trình bày Kết quả và Guideline cho Bài đăng

Như vậy, chúng ta có thể thấy văn bản được định dạng đẹp mắt cho LinkedIn, câu đầu tiên, vốn là quan trọng nhất, cũng được chấm câu đầy đủ và những yếu tố tương tự. Điều này cũng đúng với phần đầu và phần sau của bài đăng. Nó đã điều chỉnh cấu trúc, cách diễn đạt, mọi thứ để trông giống những gì bạn mong đợi trên LinkedIn. Và một lần nữa, bạn có thể kiểm tra toàn bộ bài đăng và tất cả các phiên bản từ 0 đến 4 trong thư mục examples.

Cuối cùng, hãy để tôi thực sự cho bạn thấy thư mục này trông như thế nào. Để kiểm thử code này, bạn thực sự có ba cấp độ. Tôi đã tạo một lệnh make đơn giản chỉ để kiểm tra mọi thứ có hoạt động không. Nếu điều này hoạt động và trả về 20, điều đó có nghĩa code của bạn hoạt động cục bộ. Bạn có thể chuyển nó sang Claude Code để code của bạn hoạt động.

Chúng ta phục vụ tương tự như cách tác nhân nghiên cứu hoạt động, mọi thứ đến một lời nhắc của máy chủ MCP. Sau đó, chúng ta đã ghép nối, kết nối MCP này với skill viết bài. Vấn đề là điều này mất khoảng ba, bốn phút để chạy. Vì vậy, tôi đã chạy nó để tránh lãng phí thời gian của bạn. Nhưng đây là cách bạn có thể chạy nó. Về cơ bản, bạn lấy skill viết bài này và giống như Mô hình Ngôn ngữ Lớn (LLM), chúng ta lấy ví dụ tương tự mà tôi đã làm trước đó. Chúng ta sao chép đường dẫn tương đối. Và chúng ta yêu cầu nó sử dụng guideline từ thư mục này. Sau đó, về cơ bản, nó sẽ biết cách chọn guideline và nghiên cứu liên quan đến nó và viết một bài đăng. Và đây là đầu ra. Chúng ta thấy có bốn phiên bản của bài đăng, thực ra là năm phiên bản của bài đăng và cả guideline, mà tôi nghĩ là phần thú vị nhất.

Vì vậy, về cơ bản, như bạn có thể thấy, thay vì chỉ nhẹ nhàng yêu cầu Mô hình Ngôn ngữ Lớn viết về một cái gì đó, bạn cần phải rất rõ ràng về những gì bạn muốn từ nó. Bạn cần đưa ra một góc nhìn, đối tượng mục tiêu mà bạn muốn, các điểm chính mà bạn thực sự muốn đề cập, giọng văn và những thứ tương tự. Và thực tế là một ràng buộc về ký tự ghi đè lên các profile tĩnh khác. Vì vậy, chúng tôi gọi đó là encoding trong hệ thống từ đó, trong guideline này, bạn thực sự có thể ghi đè lên các profile mặc định nếu bạn muốn điều gì đó khác biệt. Ở đây bạn có thể thoải mái nhập bất cứ thứ gì bạn muốn, nhưng tôi chỉ muốn nhấn mạnh rằng bạn thực sự cần bỏ ra một chút công sức để suy nghĩ kỹ. Bạn không thể tự động hóa hoàn toàn mọi thứ nếu bạn không muốn nghe như những slot thực sự.

Tổng quan Luồng Công việc Viết bài

Ngoài ra, chúng tôi còn có một trình tạo ảnh nhỏ. Chúng tôi chưa dành nhiều công sức cho nó, nhưng lời nhắc này thực sự tạo ra bài đăng bằng cách sử dụng workflow viết này và sau đó yêu cầu một công cụ khác tự động tạo ảnh cho bài đăng đó.

Bây giờ, để tiếp tục. Để tóm tắt những gì chúng ta đã xây dựng trong workflow viết, chúng ta đã xây dựng một pipeline workflow viết, nó tạo, xem xét và chỉnh sửa bài đăng. Bạn có thể áp dụng nó cho bất kỳ loại nội dung nào, chúng tôi đã thử nghiệm nó với hầu hết các loại nội dung và nó hoạt động rất tốt. Bạn chỉ cần điều chỉnh các profile, ví dụ và những thứ tương tự. Sau đó, chúng ta học cách kiểm soát việc tạo, guideline, các profile và các ví dụ trong tương lai. Một lần nữa, đối với các loại nội dung khác nhau, bạn sẽ cần điều chỉnh điều này. Và sau đó, cách phục vụ mọi thứ như một máy chủ MCP và skills.

Và vâng, đối với ví dụ cục bộ này, bạn có thể làm mọi thứ thông qua các skill. Bạn không thực sự cần máy chủ MCP để làm cho nó hoạt động. Nhưng theo kinh nghiệm của tôi, các máy chủ MCP giúp bạn phân phối logic. Bởi vì skills giống như thiết lập cục bộ của bạn, thiết lập hack cục bộ của bạn hoạt động rất tốt cho bạn. Nhưng nếu bạn muốn phân phối logic nghiệp vụ, bạn không thực sự muốn yêu cầu ai đó, này, hãy tải xuống các skill đó, cài đặt các dependency UV kia, cắm các công cụ CLI đó. Ồ không, bạn cũng cần những credential đó và mọi thứ nhanh chóng trở nên lộn xộn khi phân phối ở quy mô lớn. Một máy chủ MCP giải quyết vấn đề đó và skills có thể giúp bạn cá nhân hóa cách bạn sử dụng nó. Về cơ bản, nếu bạn muốn một skill không chỉ là một lời nhắc mà thực sự chạy code, nó hoạt động, nhưng nó có thể nhanh chóng trở nên lộn xộn khi thiết lập nếu quá phức tạp.

Khả năng quan sát, Giám sát và eVals

Vậy bây giờ chúng ta hãy chuyển sang phần bốn của hệ thống, đó là khả năng quan sát (observability), cụ thể hơn là monitoring (giám sát) và eVals (hệ thống đánh giá tự động). Chúng ta sẽ sử dụng workflow viết bài làm ví dụ cho eVals và chúng ta đã thực hiện monitoring cho cả hai. Đối với monitoring, chúng ta sẽ đi rất nhanh qua phần này vì, về mặt lý thuyết, không có nhiều điều để nói. Ý tưởng là vấn đề cốt lõi đằng sau monitoring, mà theo ý kiến của tôi, đã bùng nổ khi chúng ta bắt đầu sử dụng các tác nhân và workflow, là việc gỡ lỗi các workflow và tác nhân chỉ thông qua các log là rất khó. Cá nhân tôi không thể thực sự hiểu điều gì đang diễn ra bên trong terminal, đặc biệt là khi bạn thấy những suy nghĩ của tác nhân, vốn che giấu rất nhiều thứ. Vì vậy, việc gỡ lỗi những gì đang xảy ra chỉ bằng cách sử dụng log nhanh chóng trở nên khó khăn.

Về cơ bản, bạn cần một công cụ để monitor điều này một cách hiệu quả, nắm bắt tất cả các trace (dấu vết) của bạn, chẳng hạn như tất cả các API call của Mô hình Ngôn ngữ Lớn và công cụ, đầu vào đầu ra của bạn, metadata của bạn, nắm bắt mọi thứ về quá trình chạy của bạn. Và cả latency (độ trễ) và theo dõi chi phí nữa, đúng không? Và như một phần thưởng, nó cũng lưu trữ các trace của bạn để xây dựng một lớp AI Eval trên tất cả, mà tôi sẽ tìm hiểu sâu hơn một chút sau.

Phân tích Log Giám sát với OPPIC

Bây giờ chúng ta hãy thực sự xem xét các log monitoring của chúng ta. Chúng ta đã sử dụng OPPIC để monitor cả hai tác nhân của chúng ta: tác nhân nghiên cứu và workflow viết bài. Và vâng, chúng ta hãy xem xét nó bởi vì nó dễ hiểu hơn rất nhiều theo cách này. Đối với monitoring, thông thường bạn có ba khái niệm lớn. Bạn có các thread (luồng), mà về cơ bản trong trường hợp sử dụng của chúng ta là toàn bộ workflow của việc viết một bài đăng từ đầu đến cuối, bắt đầu bằng bản thân bài đăng cộng với hình ảnh. Ví dụ, như bạn có thể thấy, workflow này có 44 message (tin nhắn), về cơ bản nắm bắt tất cả các tương tác qua lại giữa người dùng và Mô hình Ngôn ngữ Lớn. Bạn có thể trực quan hơn coi nó như một luồng hội thoại, đó là lý do tại sao nó được gọi là thread.

Và sau đó bạn có các trace và ở đây bạn thực sự có thể tìm hiểu sâu hơn về những gì đang diễn ra. Một thread chứa nhiều trace, đúng không? Và trong một thread, bạn thực sự có thể tìm hiểu những gì đang diễn ra. Ví dụ, đối với một trace tạo bài đăng, ở đây chúng ta có cái nhìn tổng quan cấp cao về lệnh tạo bài đăng, nơi chúng ta có thể thấy nó mất bao lâu để chạy, bao nhiêu mã thông báo nó đã tiêu thụ, chi phí để chạy là bao nhiêu. Và ở đây chúng ta có thể thấy tất cả các API call của công cụ và API call của Mô hình Ngôn ngữ Lớn đã xảy ra bên dưới, đúng không? Vì vậy, chúng ta có thể thấy các mô hình được sử dụng, chi phí trên mỗi mô hình, latency trên mỗi mô hình và tất cả những điều đó. Và ở bên phải, chúng ta cũng có thể thấy đầu vào và đầu ra cấp cao của hệ thống, một số metadata, mã thông báo đã sử dụng, và về cơ bản mọi thứ đã xảy ra trong quá trình chạy đó, điều này đã giúp bạn rất nhiều để nhanh chóng hiểu điều gì đang xảy ra, đúng không? Và chúng ta cũng có điều tương tự cho tác nhân nghiên cứu.

Ở đây, thread dễ hiểu hơn rất nhiều vì, ví dụ, chúng ta có thread mới nhất này, nó nắm bắt tất cả các API call của công cụ đó, về cơ bản là tất cả các API call của công cụ nghiên cứu chuyên sâu, các API call của công cụ tạo báo cáo cuối cùng và tất cả các tương tác qua lại, và sau đó là các trace, vốn chỉ có các API call của công cụ đơn lẻ, chúng chỉ nắm bắt một API call của công cụ duy nhất, nơi bạn có thể thấy, chúng ta chỉ có một API call của Mô hình Ngôn ngữ Lớn cho mỗi API call của công cụ nghiên cứu chuyên sâu.

Tầm quan trọng của AI eVals

Được rồi, bây giờ chúng ta hãy chuyển sang AI eVals. Tôi muốn bắt đầu với lý do tại sao eVals lại quan trọng, bởi vì nó không nhất thiết là một chủ đề thú vị, nhưng nó có thể làm được rất nhiều điều cho hệ thống của bạn. Về cơ bản, hãy lấy ví dụ workflow viết bài của chúng ta. Giả sử chúng ta muốn kiểm tra xem nó hoạt động tốt đến mức nào, đúng không? Tất cả chúng ta đều bắt đầu bằng cảm nhận trực quan. Và khi chúng ta chỉ tạo một bài đăng, chúng ta đọc nó, chúng ta nói rằng này, nó hay đấy, tuyệt vời, nó hoạt động. Sau đó, chúng ta có 10 bài đăng. Chúng ta đọc chúng, có thể, có thể không, có thể chúng ta đọc hai, có thể ba và kết thúc một ngày và nói rằng nó cũng hoạt động tốt cho những bài khác. Vì vậy, khi chúng ta muốn kiểm tra xem nó hoạt động tốt đến mức nào trong 100 bài đăng, điều đó nhanh chóng trở nên bất khả thi. Và chỉ cần tưởng tượng rằng bạn làm điều này lúc ban đầu, nhưng khi bạn phát triển hệ thống của mình, bạn bắt đầu thêm nhiều tính năng hơn, đúng không? Và mỗi tính năng có thể làm hỏng mọi thứ. Và vâng, đây là thực hành tiêu chuẩn trong kỹ thuật phần mềm, nhưng ở đây bạn làm việc với các lời nhắc. Và chỉ một từ ngẫu nhiên ở đâu đó có thể làm hỏng tất cả các tính năng của bạn, nếu bạn không cẩn thận. Và bạn cần lớp này trên cùng.

Các lớp AI Eval và Quy trình xây dựng Dữ liệu

Về cơ bản, eVals phù hợp với ba lớp lớn. Đầu tiên là tối ưu hóa, rất giống với việc huấn luyện một mô hình. Về cơ bản, chúng ta có lớp AI eVals này, cho phép chúng ta định lượng mức độ tốt mà workflow viết bài của chúng ta tạo ra các bài đăng LinkedIn, đúng không? Sau đó, khi chúng ta muốn cải thiện nó, chúng ta có một score (điểm số), cho chúng ta biết rằng, chúng ta có đang đi đúng hướng hay không? Vì vậy, với mỗi thay đổi, chúng ta chạy lớp AI eVals này và chúng ta biết liệu chúng ta làm tốt hơn hay tệ hơn. Lớp tiếp theo là regression testing (kiểm thử hồi quy), về cơ bản tương tự như kiểm thử kỹ thuật phần mềm truyền thống, nơi bất cứ khi nào chúng ta bắt đầu làm việc với một tính năng mới, chúng ta chỉ đảm bảo rằng chúng ta không làm hỏng chức năng hiện tại. Và lớp thứ ba sẽ là chạy điều này trong môi trường production (sản xuất) trên các trace trực tiếp để thực sự nhận được các cảnh báo, lỗi và báo động, khi người dùng thực sự sử dụng hệ thống của bạn. Và trên thực tế, điều này khác với kiểm thử đơn vị, integration (tích hợp) và regression test bình thường ở chỗ mọi thứ bắt đầu từ tập dữ liệu Intel, đúng không? Vì vậy, đây là một vấn đề về dữ liệu, chúng ta thực sự xây dựng một mô hình ở đây.

Đây là cách chúng ta xây dựng nó cho các bài đăng LinkedIn của chúng ta, nơi chúng ta may mắn đã có sẵn dữ liệu. Tôi đã trích xuất 20 bài đăng thực từ LinkedIn của tôi. Tại sao lại là 20? Tôi nói rằng đó là một con số đủ lớn cho một workshop (hội thảo), nhưng trên thực tế, chúng ta có thể cần ít nhất là 100. Sau đó, tôi đã reverse-engineer (phân tích ngược) guideline và nghiên cứu. Về cơ bản, tôi lấy guideline từ bài đăng, và sau đó tôi chạy tác nhân nghiên cứu chuyên sâu dựa trên guideline để tìm bất cứ thứ gì tôi cần để hỗ trợ bài đăng đó. Và sau đó tôi đã tạo ra đầu ra. Về cơ bản, tôi đưa guideline và nghiên cứu làm đầu vào và tạo ra các bài đăng mới. Và điều này cực kỳ quan trọng vì bạn thực sự muốn thấy kết quả từ hệ thống thực của mình. Và khi bạn muốn tạo dữ liệu tổng hợp nào đó, đừng bao giờ yêu cầu Mô hình Ngôn ngữ Lớn trực tiếp tạo ra đầu ra, hãy luôn yêu cầu nó giúp bạn tạo ra đầu vào, nhưng không bao giờ là đầu ra. Bạn muốn đầu ra từ hệ thống thực của mình vì đó là thứ bạn đang kiểm thử cuối cùng.

Và sau đó tôi đã xem xét và gán nhãn cho mỗi đầu ra với nhãn pass (đạt) và fail (trượt) nhị phân cùng với hai, ba câu nhận xét về lý do chính xác tại sao tôi lại gán nhãn pass hoặc fail cho nó. Và thông thường tôi dừng lại khi tôi tìm thấy lỗi đầu tiên; điều đó dễ dàng hơn cho tôi khi gán nhãn và cũng để Mô hình Ngôn ngữ Lớn hiểu rằng bất cứ khi nào tôi thấy lỗi đầu tiên, tôi sẽ dừng lại, tôi viết 'failed' trong ba câu và tiếp tục. Và cuối cùng, tôi đã chia tất cả thành train, dev và test, bởi vì cuối cùng, hãy nhớ rằng ở đây chúng ta đang xây dựng một mô hình học máy. Vì vậy, chúng ta cần đối xử với nó như vậy. Chúng ta cần một sự phân chia cổ điển. Và chỉ khi chúng ta có tập dữ liệu này và các phần chia này, chúng ta mới thực sự có thể xây dựng evaluator (bộ đánh giá) và đánh giá evaluator đó, điều mà hầu hết khi họ xây dựng các element judge (bộ thẩm định yếu tố), họ nghĩ rằng họ có thể bỏ qua bước cuối cùng này, vốn có lẽ là quan trọng nhất. Và một lần nữa, điều quan trọng và thú vị nhất ở đây là tập dữ liệu mà chúng ta đã tạo ra bởi vì việc tạo ra một element judge từ đây nếu bạn có tập dữ liệu thì rất dễ dàng.

Cách Element Judge hoạt động

Được rồi, bây giờ chúng ta hãy xem element judge này sẽ hoạt động như thế nào cho kịch bản hiện tại của chúng ta. Là đầu vào, nó sẽ nhận bài đăng đã tạo mà nó cần để gán nhãn, nhưng cũng nhận các profile, nghiên cứu và guideline. Và điều này cực kỳ quan trọng bởi vì element judge thực sự cần hiểu ngữ cảnh được sử dụng để tạo ra bài đăng đó. Và cuối cùng nó sẽ xuất ra nhãn pass/fail cộng với nhận xét, về cơ bản là chính xác các nhãn tương tự như tập dữ liệu của chúng ta.

Ví dụ Few-Shot và Dataset

Sau đó, chúng tôi truyền một số few-shot examples – là tập dữ liệu đã được huấn luyện (trained split) từ dataset của chúng tôi. Đây là phần quan trọng nhất, bởi vì lời nhắc hệ thống (system prompt) của LM Judge có thể cực kỳ đơn giản nếu nó có sẵn các few-shot examples phù hợp để hướng dẫn LM Judge đưa ra quyết định. Các few-shot examples trông như thế này: chúng có đầu vào của người viết (writer input), là phần hướng dẫn và nghiên cứu; tức là đầu vào trong khi hệ thống thực hiện công việc viết lách. Tiếp theo là đầu ra của người viết (writer output), về cơ bản là bài viết được tạo ra của workflow và các nhãn (labels). Trong các few-shot examples, chúng tôi cũng có các nhãn đạt/không đạt (pass/fail label) và phần phê bình gồm hai đến ba câu về nhãn đó. Bạn có thể kiểm tra lời nhắc hệ thống của chúng tôi trong tệp này, nhưng không có gì quá phức tạp. Phần quan trọng nhất ở đây là xây dựng dataset.

Đo lường Độ tin cậy của LM Judge

Bước cuối cùng của chúng tôi là đo lường độ tin cậy của bộ đánh giá (judge reliability), bởi vì về cơ bản, LM Judge mà chúng tôi xây dựng ở đây chỉ là một bộ phân loại nhị phân (binary classifier), đúng không? Chúng tôi chỉ xuất ra nhãn đạt và không đạt. Vì vậy, chúng tôi sử dụng LM Judge vì thực tế là nó dễ dàng, nhưng chúng tôi có thể sử dụng bất kỳ mô hình nào khác có thể hoàn thành công việc và xuất ra các nhãn đạt và không đạt này. Cuối cùng, khi chúng tôi đo lường độ tin cậy của bộ đánh giá, mục tiêu cuối cùng của chúng tôi là căn chỉnh (align) LM Judge với domain expert. Chúng tôi sẽ thực hiện điều đó bằng cách kiểm tra nó với các dev test datasets. Đây là một quy trình rất giống với việc huấn luyện bất kỳ binary classifier nào khác. Không có gì mới ở đây, chỉ là từ "judge" nghe có vẻ hoa mỹ hơn.

Quy trình Đánh giá và Hiệu chỉnh LM Judge

Vậy, về cơ bản, chúng tôi kiểm tra LM Judge với các dev test datasets. Sau đó sử dụng F1 score – là sự kết hợp của precision và recall – để thực sự đo lường xem LM Judge hoạt động tốt như thế nào đối với những điều này. Quy trình trông như thế này: Đầu tiên chúng tôi chạy LM Judge trên dev split, tính toán F1 score đó và điều chỉnh LM Judge cùng các ví dụ lời nhắc (prompt examples) để tối đa hóa F1 score này. Bởi vì rất có thể khi chúng tôi bắt đầu quy trình này, F1 score sẽ thấp và chúng tôi về cơ bản muốn đạt được điểm số càng cao càng tốt. Chúng tôi lặp lại cho đến khi hội tụ; thông thường bạn cần thực hiện điều này một vài lần. Và khi bạn nghĩ mình đã hoàn thành và LM Judge đã sẵn sàng hoạt động, bạn sẽ chạy nó trên test split như một bước validation step cuối cùng, đúng không? Về cơ bản là huấn luyện một mô hình học máy (machine learning model). Và bây giờ nó đã sẵn sàng để chạy trên dữ liệu mới. Vì vậy, sau khi chúng tôi thực hiện bước này, chúng tôi có LM Judge đã sẵn sàng để chạy trên các mẫu (samples) dữ liệu mới, mô hình sẽ chỉ xuất ra nhãn nhị phân (binary pass or fail) và phê bình (critique).

Giới thiệu quy trình và Demo hiệu chỉnh

Để kết nối mọi thứ chúng ta đã có trong phần này: đầu tiên chúng ta xây dựng dataset. Sau đó, dựa trên đó, chúng ta xây dựng LM Judge, rồi hiệu chỉnh LM Judge, và chỉ sau đó chúng ta mới có thể chạy nó trên dữ liệu thực. Thông thường, tất cả các bước này đều được quản lý bởi một nền tảng khả năng quan sát (observability platform) nào đó. Ở đây chúng tôi sử dụng "Up", nhưng bạn có thể sử dụng bất kỳ nền tảng nào khác hoặc tự xây dựng một nền tảng in-house. Điều đó không thực sự quan trọng, nhưng ý tưởng là mọi thứ nên được quản lý bởi một nền tảng nhất quán. Được rồi, bây giờ, để làm một bản demo nhanh, hãy mô phỏng tối đa bước hiệu chỉnh (calibration step) này, bởi vì LM Judge đã được hiệu chỉnh rồi. Vì vậy, tôi sẽ chỉ cho bạn thấy LM Judge hoạt động như thế nào trên eVals split. Theo cách thực hiện (under the hood) với "A-pick", chúng tôi xây dựng một khung đánh giá (evaluation harness) rất đơn giản cho phép chúng tôi chạy các bước hiệu chỉnh này và sau đó chạy nó trên các dấu vết sản xuất (production traces). Trên thực tế, mã nguồn cho các trường hợp sử dụng của chúng tôi khá đơn giản. Vậy thì hãy cùng xem qua một chút trong khi nó đang chạy. Được rồi, thực ra điều nó đang làm bây giờ là nó lấy tất cả các bài đăng được tạo ra, đúng không? Nó chạy LM Judge trên tất cả các bài đăng được tạo đó. Và sau đó điều tôi muốn cho bạn thấy là F1 score này, về cơ bản chúng tôi tính F1 score dựa trên đầu ra từ LM Judge so với các nhãn của chúng tôi từ dataset, điều mà tôi nghĩ sẽ thú vị hơn khi xem dataset của chúng tôi trông như thế nào một cách nhanh chóng để có cái nhìn tổng quan.

Cấu trúc Dataset và Sử dụng Few-Shot

Về cơ bản ở đây chúng ta có một mẫu (sample) duy nhất trong dataset của chúng ta, điều thú vị hơn là chúng ta có một liên kết đến phương tiện của bài đăng, đến hướng dẫn (guideline), đến bài đăng được tạo (generated post) – về cơ bản là các liên kết đến mọi thứ chúng ta cần làm đầu vào và đầu ra cho cả tác nhân nghiên cứu chuyên sâu (deep research agent) và workflow viết lách (writing workflow). Và sau đó, chỉ cần đưa vào phạm vi này, chúng tôi cắm chúng vào dưới dạng few-shot examples cho bộ tạo bài đăng (post generator) hoặc cho bộ đánh giá (evaluator), hoặc ví dụ cho dev split và những thứ tương tự. Đây là cách chúng tôi cẩn thận để thực hiện các tách (splits) đúng cách giữa bộ đánh giá và cả bộ tạo. Và để đơn giản, chúng tôi có tất cả các tệp đó được liên kết với nhau trong tệp YAML này cục bộ trong GitHub. Vì vậy, bạn có thể kiểm tra mọi thứ và chạy mọi thứ rất dễ dàng với cấu hình tối thiểu.

Đánh giá trên Test Split và Tránh Overfitting

Được rồi, nếu chúng ta quay lại giao diện dòng lệnh (terminal), chúng ta thấy rằng nó có một điểm số hoàn hảo. Vậy bây giờ hãy thực sự chạy cái này trên test split. Và mục tiêu ở đây là để xem LM Judge của chúng ta có bị quá khớp (overfit) hay không. Đúng không? Vì vậy, chúng ta đã chạy nó trên dev split, chúng ta nhận được một điểm số hoàn hảo. Thông thường, đây là một dấu hiệu cao cho thấy nó đã bị quá khớp. Vì vậy, trừ khi F1 score trên test split không phải là một hoặc xung quanh một, điều đó có nghĩa là LM Judge của chúng ta đã bị quá khớp. Vì vậy, một lần nữa, tương tự như quy trình trước, về cơ bản là các bước chính xác giống nhau, nhưng bây giờ chúng ta chạy trên test split. Vậy hãy xem F1 score cuối cùng, cũng là một, điều này tốt. Và các điểm số tốt như vậy vì chúng ta chỉ làm điều này trên năm mẫu (samples) cho mỗi split. Nhưng nếu bạn mở rộng split của mình, mà bạn nên có ít nhất khoảng 20-30 mẫu, thì điểm số có lẽ sẽ không hoàn hảo.

Phân tích kết quả thực nghiệm và Khả năng quan sát

Và hãy để tôi thực sự chỉ cho bạn cách các thử nghiệm (experiments) này trông như thế nào bên trong. Vâng, chắc chắn rồi. Tôi nghĩ điều quan trọng nhất là sự năng động giữa F1 score trên dev split của bạn và sự năng động trên test split của bạn, bởi vì khi mô hình bị quá khớp (overfitted) thì thực chất là so sánh giữa hai split. Ví dụ, nếu như tôi đã nói, nó có một điểm số rất lớn trên dev split và một điểm số thấp trên test split, điều đó có nghĩa là nó đã bị quá khớp. Nhưng bản thân điểm số thường rất tương quan với dữ liệu của riêng bạn. Vì vậy, ví dụ, bạn hài lòng với chính xác... vâng, chính xác. Giá trị tuyệt đối thường rất tương quan với dữ liệu của bạn. Thông thường trên dev split, bạn nói, "Được rồi, F1 score này đủ tốt cho tôi." Và sau đó bạn chạy trên test split để xem bạn cũng có cùng F1 score trên test split hay không. Được rồi, vì vậy, một lần nữa, thông thường với các nền tảng khả năng quan sát này, bạn có tab thử nghiệm nơi bạn thực sự có thể chạy các thử nghiệm tương tự như các công cụ theo dõi thử nghiệm tinh chỉnh (fine-tuning experiment trackers) từ thời trước. Và ví dụ, ở đây chúng tôi có các thử nghiệm dev và test. Vì vậy, hãy mở thử nghiệm test mà chúng tôi vừa chạy. Và ở đó chúng ta thực sự có thể thấy đầu ra từ LM Judge nhị phân (binary LM Judge) và nhãn của chúng tôi. Và chúng ta có thể thấy rằng có sự khớp hoàn hảo giữa hai bên. Và nếu chúng ta di chuột qua đây, chúng ta cũng có thể thấy phê bình của bộ đánh giá. Nhưng trên thực tế ở đây, chúng tôi chỉ tính điểm số giữa các nhãn. Và phê bình này hữu ích hơn cho chúng tôi bởi vì mục tiêu cuối cùng của chúng ta, với tư cách là con người, là xem xét những kết quả này và hiểu những gì đang xảy ra sai sót với hệ thống.

Mô phỏng Trực tuyến, Kết quả và Khóa học Chuyên sâu

Và sau đó, như một bước cuối cùng, chúng tôi cũng chuẩn bị một mô phỏng trực tuyến (online simulation) nơi tôi mô phỏng một số dấu vết trực tuyến (online traces) mà LM Judge thực sự chạy trên đó. Và bạn nhận được các nhãn nhị phân (binary labels) và phần phê bình. Nhưng vấn đề là việc này mất khoảng năm phút hoặc thậm chí hơn để chạy vì nó thực sự cần phải tạo ra tất cả các bài viết và chạy LM Judge trên đó. Vì vậy, tôi sẽ chỉ cho bạn xem một kết quả ở đây, tôi đã gói nó lại thành một thử nghiệm. Đó là kiểm tra trực tuyến (online test) này. Và sau đó là kết quả từ nhị phân từ bộ đánh giá nơi chúng tôi tìm thấy điểm số và chính phần phê bình. Và tất nhiên, hệ thống này chưa hoàn hảo. Và chúng tôi có lẽ cần tinh chỉnh nó nhiều hơn bởi vì ở đây trên các dấu vết trực tuyến, như bạn thấy, thành thật mà nói, nó có vẻ đã thất bại. Nó chỉ vượt qua với một F1 score. Nó chỉ cho chúng tôi một kết quả "đạt" trên tất cả các dấu vết trong khi trên thực tế, tôi cũng có các nhãn cho các kịch bản mô phỏng (simulated scenarios) này. Và điều đó đã thất bại. Có lẽ tôi cần quay lại dev split, mở rộng dev split với các mẫu mới. Ví dụ, tôi có thể chỉ cần lấy các mẫu này và đặt chúng vào dev split và bắt đầu tinh chỉnh (refining) lại và lại và lại cho đến khi nó thực sự hoạt động. Và tôi cũng đang hết thời gian, nhưng bạn cũng có kỹ năng (skill) này để thực sự chạy một bản demo và khi bạn nghiên cứu và viết lách, bạn có thể, ví dụ, viết một hướng dẫn về một điều gì đó mà bạn muốn viết một bài đăng và đưa đó làm đầu vào cho kỹ năng này, đó chỉ là một tệp. Và bạn biết cách chọn để thực hiện nghiên cứu và sau đó tiếp tục viết bài đăng. Và bạn cũng có thể quan sát điều đó trong All Pick với tất cả các dấu vết luồng (thread traces) và tất cả những thứ đó. Và vâng, tôi đoán bước cuối cùng, nếu bạn chưa làm, là thực sự sao chép kho lưu trữ GitHub, tự chạy mọi thứ và đọc mã nguồn. Và nếu không đọc mã nguồn, rất có thể chúng ta sẽ không thực sự hiểu điều gì đang diễn ra bên trong. Vì vậy, bạn có thể làm điều đó bằng cách truy cập liên kết này hoặc quét mã QR. Và bất cứ khi nào bạn sẵn sàng và muốn đi sâu hơn vào việc xây dựng loại hệ thống đa tác nhân (multi-agent systems) này, chúng tôi có khóa học Kỹ thuật Tác nhân (agentic engineering course) này, về cơ bản là nguồn cảm hứng cho workshop này. Nhưng thay vào đó, mục tiêu của chúng tôi thực sự là thiết kế và xây dựng các tác nhân sẵn sàng sản xuất (production-ready agents) và trên một số hệ thống cục bộ nhỏ trong vòng 34 bài học, ba và hai và cổng cho các dự án chứng chỉ và một cộng đồng Discord với quyền truy cập vào chúng tôi. Cho đến nay, nó được đánh giá năm trên năm bởi hơn 300 sinh viên. Và nếu bạn không tin chúng tôi, sáu bài học đầu tiên là miễn phí để thử. Và bạn có thể truy cập nó bằng cách sử dụng liên kết này hoặc quét mã QR. Và đó là tất cả cho workshop ngày hôm nay.