Mergeable by default: Building the context engine to save time and tokens — Peter Werry, Unblocked

• Các tác nhân AI hiện tại thiếu ngữ cảnh sâu sắc về cơ sở mã và văn hóa tổ chức, khiến chúng hoạt động không hiệu quả, mắc lỗi và tạo gánh nặng cho con người trong việc cung cấp thông tin liên tục.
• Các giải pháp phổ biến như RAG đơn giản hoặc cửa sổ ngữ cảnh lớn không đủ để giải quyết vấn đề, vì chúng không mang lại sự thấu hiểu thực sự và dễ mắc phải "sự hài lòng của việc tìm kiếm," bỏ sót thông tin quan trọng.
• Một "Context Engine" mạnh mẽ là cần thiết để tổng hợp, phân tích và cung cấp ngữ cảnh được cá nhân hóa, hiểu biết về lịch sử quyết định, giải quyết xung đột và kiểm soát quyền truy cập, giúp tác nhân AI hoạt động chính xác và hiệu quả như một chuyên gia.

• Vấn đề cốt lõi của tác nhân AI: Các tác nhân AI ban đầu không có ngữ cảnh về cơ sở mã, tổ chức hoặc lịch sử, dẫn đến "doom loop" và yêu cầu con người liên tục cung cấp ngữ cảnh, gây ra tình trạng "chuyển đổi ngữ cảnh" và trở thành nút thắt cổ chai.
• Hạn chế của giải pháp hiện tại: Các phương pháp như RAG đơn giản trên tài liệu hoặc sử dụng cửa sổ ngữ cảnh lớn không hiệu quả, vì chúng không tạo ra sự thấu hiểu sâu sắc, chỉ giỏi tìm kiếm thông tin đơn lẻ mà không suy luận hoặc giải quyết xung đột dữ liệu.
• "Satisfaction of Search" (Sự hài lòng của việc tìm kiếm): Đây là một vấn đề khi tác nhân AI dừng tìm kiếm ngay khi tìm thấy một kết quả có vẻ phù hợp, bỏ qua các thông tin quan trọng hơn có thể nằm ở các nguồn không ngờ tới (ví dụ: Slack, báo cáo sự cố).
• Sức mạnh của Context Engine: Một Context Engine lý tưởng phải hiểu ai là chuyên gia, các quyết định lịch sử, lý do đằng sau các thay đổi, và các quy tắc ngầm của tổ chức, vượt xa thông tin bề mặt từ mã nguồn hoặc tài liệu.
• Giải quyết xung đột: Context Engine cần có khả năng giải quyết các xung đột thông tin, không chỉ dựa vào tính thời sự hay ưu tiên cơ sở mã, mà còn phải hiểu được các trường hợp "vùng xám" và học hỏi từ phản hồi của người dùng.
• Kiểm soát truy cập toàn diện: Việc tích hợp kiểm soát truy cập là cực kỳ quan trọng để đảm bảo tác nhân chỉ sử dụng thông tin mà người hỏi có quyền truy cập, đặc biệt đối với dữ liệu nhạy cảm từ các kênh riêng tư (ví dụ: Slack, Microsoft Teams).
• Tối ưu hóa cung cấp ngữ cảnh: Context Engine phải cung cấp ngữ cảnh phù hợp vào đúng thời điểm, tối ưu hóa việc sử dụng mã thông báo và tìm kiếm câu trả lời nhanh chóng để nâng cao hiệu quả và tốc độ hoàn thành nhiệm vụ của tác nhân.
• Xây dựng "ký ức" tổ chức: Chắt lọc các bình luận lịch sử trên pull request và các mẫu lặp lại trong quá trình phát triển để tổng hợp thành "ký ức" của tổ chức, giúp tác nhân hiểu được các phương pháp hay nhất và cách làm việc cụ thể.

• Context Engine — Công cụ ngữ cảnh
• AI Agent — Tác nhân AI
• Context Window — Cửa sổ ngữ cảnh
• Token — Mã thông báo
• RAG (Retrieval Augmented Generation) — Tạo sinh có tăng cường truy xuất
• Doom Loop — Vòng lặp thất bại/đen đủi
• Satisfaction of Search — Sự hài lòng của việc tìm kiếm
• Codebase — Cơ sở mã
• Context Switching — Chuyển đổi ngữ cảnh
• Pull Request (PR) — Yêu cầu kéo mã
• Legacy code — Mã nguồn cũ/thừa kế
• YOLO mode (You Only Live Once mode) — Chế độ tự do/tự quyết hoàn toàn
• Compaction — Nén/thu gọn (dữ liệu/mã thông báo)
• Personalization — Cá nhân hóa
• Social Technical Graph — Biểu đồ kỹ thuật xã hội

Giới thiệu và Chương trình Nghị sự

Xin chào tất cả mọi người. Xin lỗi vì đã để quý vị chờ đợi. Buổi chia sẻ này sẽ hơi đặc biệt một chút vì có một phần workshop. Vì vậy, tôi đoán mọi người sẽ code trên máy tính xách tay của mình. Xin lỗi. Dù sao thì, tôi là Peter và đây là đồng nghiệp của tôi, Brandon. Chúng tôi sẽ chia buổi chia sẻ này thành hai phần khác nhau. Một là phần trình bày về công dụng của các context engine và cách quý vị có thể xây dựng chúng, cũng như những điều cần cân nhắc. Sau đó, chúng ta sẽ chuyển sang phần thứ hai.

Nói tóm tắt, chương trình nghị sự nhanh của chúng ta sẽ gồm: ba lầm tưởng đang lan truyền hiện nay về các context engine. Sau đó, tôi sẽ trình bày một vài bài học chúng tôi đã rút ra trong quá trình xây dựng một trong những hệ thống này. Cuối cùng, chúng ta sẽ thực hành: xây dựng một biểu đồ kỹ thuật xã hội. Đây là một thành phần cực kỳ hữu ích trong context engine.

Trước tiên, xin giơ tay: có ai biết tôi muốn nói gì về context engine không, hay có ai muốn được giải thích rõ hơn không?

Context Engine là gì?

Trong thế giới tác nhân AI, khi quý vị bắt đầu code, các tác nhân về cơ bản đang ở điểm xuất phát. Chúng không có ngữ cảnh về cơ sở mã của quý vị, về tổ chức của quý vị, không có gì cả. Vì vậy, thông thường, điều đầu tiên chúng làm là bắt đầu khám phá cơ sở mã của quý vị dựa trên nhiệm vụ mà quý vị giao cho chúng, nhằm thu thập một số hiểu biết cơ bản trước khi bắt đầu thực hiện nhiệm vụ.

Vì vậy, kỹ thuật ngữ cảnh (context engineering) là nghệ thuật cung cấp tất cả ngữ cảnh cần thiết, và quan trọng nhất là không cung cấp bất kỳ ngữ cảnh nào không cần thiết, theo một cách được tối ưu hóa cao. Điều này giúp khi tác nhân bắt đầu chạy, nó sẽ thực hiện nhiệm vụ một cách hợp lý, phù hợp với các thực hành tốt nhất và kỳ vọng của tổ chức quý vị.

Vai trò của con người trong việc cung cấp ngữ cảnh

Không lâu trước đây, chỉ khoảng bốn năm trước hoặc ít hơn, chính quý vị là context engine. Khi tác nhân của quý vị cần gì đó, quý vị sẽ đưa ra lời nhắc, lấy phiếu sự cố, và cung cấp tất cả thông tin cần thiết để nó bắt đầu nhiệm vụ. Trong nhiều trường hợp, ngay cả khi nó đã khám phá để thu thập ngữ cảnh nền, đôi khi nó vẫn mắc lỗi khi hoàn thành nhiệm vụ. Thực tế, rất nhiều lần nó đã làm sai, và quý vị phải đặt lại nó, hướng dẫn nó về giải pháp mà quý vị đang nghĩ đến. Hoặc nếu nó hoàn toàn đi chệch hướng, quý vị sẽ phải nói: "Không, không phải mã JavaScript ngớ ngẩn đó. Tôi muốn bạn xem mã nguồn Python."

Hãy nhớ lại cách quý vị xây dựng ngữ cảnh trong một tổ chức. Chúng ta hãy tạm gạt AI sang một bên một chút. Hãy tưởng tượng trước kỷ nguyên AI, quý vị vừa gia nhập một tổ chức, hãy nhớ lại cách chúng ta đã xây dựng nó. Theo thời gian, quý vị sẽ tích lũy loại ngữ cảnh này thông qua kinh nghiệm, đúng không? Quý vị sẽ bắt đầu một công việc, có thể bắt đầu tìm hiểu cơ sở mã một chút để tìm hiểu cách mọi thứ hoạt động. Quý vị có thể gắn bó với một người hướng dẫn. Và cuối cùng, quý vị sẽ trải qua những điều thực tế như sự cố và gián đoạn. Đó là những điều "đau đớn" gắn bó với quý vị – đó là những kinh nghiệm xương máu. Và đó là những gì tạo nên ngữ cảnh tổ chức. Đó là những bài học kinh nghiệm trên con đường, lý do tại sao chúng ta làm mọi việc theo cách đã làm. Và bây giờ quý vị giỏi công việc của mình vì sau tất cả những kinh nghiệm "đau đớn" đó, bây giờ quý vị biết phải hỏi những câu hỏi nào. Quý vị biết phải tìm ở đâu khi một sự cố xảy ra. Và đây là mục tiêu. Đây là điều chúng ta muốn đạt được cho các tác nhân AI của mình.

Đường cong áp dụng AI và sự phát triển của cửa sổ ngữ cảnh

Tôi sẽ lấy đường cong áp dụng này từ Vimath. Tôi có thể đã phát âm sai họ của anh ấy, nhưng xin lỗi Vim nếu anh thấy điều này.

Hãy bắt đầu từ ban đầu, khoảng bốn năm trước vào năm 2022. Mọi người đều nhớ autocomplete nâng cao, đúng không? Vào thời đó, các cửa sổ ngữ cảnh và AI khá hạn chế. Tôi không chắc mọi người có nhớ điều này không, nhưng nó chỉ khoảng 8 kilobyte hoặc 8 nghìn mã thông báo. Và đó không phải là nhiều. Vì vậy, các mã thông báo được tối ưu hóa cao, và các IDE tác nhân như Cursor chỉ tập trung vào mã nguồn xung quanh mã mà quý vị muốn tự động hoàn thành. Về cơ bản, chúng lấy một số mã trước, lấy một số mã sau, đưa nó vào một mô hình và nói: người dùng này đang làm việc trên đoạn mã này, điều tiếp theo có khả năng xảy ra nhất là gì? Và đó là những gì được in ra.

Sau đó, nó dần trở nên tốt hơn khi các language server được tích hợp. Và sau đó, quý vị có thể kéo các đoạn mã nguồn và đưa tất cả vào ngữ cảnh, và các LLM thực sự rất giỏi trong việc hoàn thành mã.

Thách thức và tắc nghẽn hiện tại

Ở những cấp độ đó, quý vị chính là context engine. Và trong nhiều trường hợp, đây là nơi mà hầu hết mọi người đang ở hiện tại: họ đang sử dụng tác nhân song song được kết nối với MCP và kỹ năng. Chỉ tò mò, có ai đã vượt qua ngữ cảnh được quản lý để đạt đến mức độ tự do tác nhân cao hơn, nơi quý vị có các tác nhân nền chạy trên đám mây trong YOLO mode không? Có ai đang thử nghiệm điều đó không?

[transcript bị gián đoạn]

Tuyệt vời, điều đó rất hay. Đó là công nghệ tiên tiến nhất. Nhưng hãy dành một chút thời gian để nhận ra rằng công nghệ tiên tiến nhất hôm nay sẽ là tin tức của ngày hôm qua trong sáu tháng nữa. Vì vậy, "quả bóng" (tôi là người Canada, nên tôi sẽ nói vậy) chắc chắn đang lăn về phía các tác nhân nền.

Và một trong những điều chúng ta gặp phải hiện nay là đây: chúng ta đang trở thành nút thắt cổ chai với tư cách là con người, đúng không? Tôi không chắc mọi người đã thử quản lý các tác nhân song song và làm việc trên nhiều nhiệm vụ cùng một lúc chưa, nhưng mọi người đang bắt đầu cảm thấy sự ngắt kết nối nhận thức này vì quý vị phải chuyển đổi ngữ cảnh (context switching) liên tục, và điều đó thực sự rất khó khăn. Rất khó để chuyển từ chế độ quý vị là con người quản lý ngữ cảnh sang chế độ tác nhân nền trừ khi quý vị có một context engine hiểu cách cơ sở mã của quý vị hoạt động, cách tổ chức của quý vị vận hành và hiểu các động lực đằng sau những thay đổi lịch sử và những thứ tương tự.

Ngữ cảnh là nút thắt cổ chai mới

Andre đã nói đúng. Các hệ thống AI đang trở nên thông minh. Chúng ta sẽ sớm đạt đến mức tăng trưởng theo cấp số nhân về trí tuệ cho mã nguồn. Mọi người đều đã thấy thông báo về Mythos. Mặc dù chúng ta chưa có cơ hội thực sự dùng thử, nhưng lời hứa là từ góc độ trí tuệ về mã, công cụ này gần như hoàn hảo.

Nhưng bây giờ, nút thắt cổ chai chính là ngữ cảnh. Dĩ nhiên, không có ngữ cảnh – tôi chỉ muốn nhấn mạnh lại điểm này – quý vị có thể sẽ rơi vào doom loop. Mọi người có biết doom loop là gì không? Doom loop giống như khi quý vị đang vật lộn với tác nhân. Nó không làm đúng như quý vị muốn, và quý vị phải liên tục lặp lại nó. Kịch bản tồi tệ nhất là quý vị chạy công cụ này ở YOLO mode và nó hoàn thành toàn bộ nhiệm vụ nhưng lại hoàn toàn sai. Quý vị phải quay lại và sửa các giai đoạn khác nhau. Vì vậy, khi quý vị có một context engine, quý vị có thể đạt được mục tiêu nhanh hơn.

Tiếp cận không đồng nghĩa với thấu hiểu

Vấn đề là việc tiếp cận không đồng nghĩa với sự thấu hiểu. Chúng tôi có những khách hàng đang ở các giai đoạn khác nhau trong hành trình này. Và một trong những điều thú vị chúng tôi nhận thấy là mọi người cảm thấy rằng họ hiểu rõ tổ chức của mình nhất. Vì vậy, khi cung cấp ngữ cảnh phù hợp cho các tác nhân này, mọi người sẽ cố gắng xây dựng một thứ giống như một context engine. Họ có thể xây dựng một hệ thống RAG hoặc một cách nào đó để cấp dữ liệu tổ chức cho một tác nhân.

Thật không may, việc tiếp cận không có nghĩa là thấu hiểu. Điều đó có nghĩa là quý vị có thể chỉ cần kết nối một loạt các máy chủ MCP. Và nó sẽ không thể hiểu được các mối quan hệ giữa tất cả dữ liệu đó, làm thế nào nó lại ở đó, và tại sao nó lại như vậy. Và sau đó có một vấn đề khác mà tôi sẽ nói đến sau một chút, gọi là "sự hài lòng của việc tìm kiếm" (satisfaction of search). Vì vậy, hãy nhớ thuật ngữ đó. Tôi sẽ quay lại nó sau.

Giá trị của một Context Engine

Tôi chỉ muốn cho quý vị thấy điều này. Đây là điều chúng tôi thực sự đã triển khai và chúng tôi đã làm nó trong hai phần. Một là không có bất kỳ context engine nào, nhưng được kết nối với một loạt máy chủ MCP. Nó đã làm khá tốt. Nhưng sau đó, khi chúng tôi kết thúc, nó đã bỏ qua một thực tế rằng chúng tôi có một số thứ legacy phụ thuộc vào phương pháp cũ này về kích thước trí tuệ của Anthropic. Vì vậy, bây giờ họ có tư duy thích ứng (adaptive thinking), nhưng trước đây quý vị phải cung cấp một ngân sách mã thông báo (token budget), và đó là cách quý vị có thể tăng kích thước cửa sổ tư duy. Vì vậy, chúng tôi có một số mã phụ thuộc vào điều này, và có những lý do cho điều đó mà tác nhân không hiểu hoặc không thấy, và vì vậy nó chỉ đơn giản là đã clog tất cả mã đó. Nhưng khi chúng tôi thêm context engine, nó đã thấy tất cả những lý do đó và triển khai đúng cách. Vì vậy, nó đã thực hiện các thay đổi thích hợp ở đúng nơi, bao gồm khả năng tương thích ngược cho mã đang sử dụng phương pháp cũ.

Ba Lầm tưởng về Context Engine

Lầm tưởng 1: RAG đơn giản trên tài liệu của tôi là một Context Engine

Nếu quý vị triển khai, ví dụ, tìm kiếm vector (vector search) hoặc chỉ một vài phương pháp tìm kiếm, quý vị sẽ gặp phải một vài vấn đề. Một trong số đó là vấn đề "sự hài lòng của việc tìm kiếm" này, nơi tác nhân sẽ tìm kiếm một cách điên cuồng, tiêu tốn mã thông báo của quý vị, và trong trường hợp xấu nhất, quý vị sẽ đạt đến compaction.

Vì vậy, nếu không thể tìm thấy mục tiêu cuối cùng, có một vài kỹ thuật khác nhau như quý vị cần có cá nhân hóa (personalization) khi xây dựng một hệ thống truy xuất (retrieval system) bởi vì nếu quý vị chỉ RAG tất cả dữ liệu của mình, đặc biệt đối với các tổ chức rất lớn, sẽ có những thứ như xung đột mà quý vị phải giải quyết trong dữ liệu. Nó sẽ không tập trung vào nhiệm vụ mà quý vị đang cố gắng thực hiện. Nó có thể kéo mã nguồn liên quan từ các phần khác trong tổ chức của quý vị, đặc biệt nếu quý vị có một tổ chức thực sự lớn và có rất nhiều repository khác nhau. Điều đó sẽ chỉ tạo ra một mớ hỗn độn lớn. Vì vậy, quý vị cần có một yếu tố cá nhân hóa.

Và một lần nữa, kết nối một loạt MCPs. Tôi chỉ muốn nhắc lại điểm này. Tôi đã xong. Không, chắc chắn là chưa. Đó là điều thực sự nhấn mạnh điểm "sự hài lòng của việc tìm kiếm". Và tôi sẽ giải thích điều đó trong giây lát.

Lầm tưởng 2: Cửa sổ ngữ cảnh lớn hơn sẽ giải quyết vấn đề này

Vậy thì, từ lâu, khi các mô hình bắt đầu lớn, mọi người thực sự rất hào hứng về một triệu mã thông báo trong cửa sổ ngữ cảnh của quý vị. Các mô hình đầu tiên thử điều này, tôi nghĩ có thể là Claude phải không? Hay OpenAI. Gemini. Đúng vậy, Gemini. Tôi rất xin lỗi.

Gemini là mô hình đầu tiên thử điều này và nó thực sự giỏi trong việc tìm "kim trong đống rơm". Vì vậy, quý vị có thể đưa một tài liệu khổng lồ cho nó và miễn là quý vị biết trước mình đang tìm kiếm điều gì, nó có thể tìm thấy nó. Nhưng nó hoàn toàn không giỏi trong việc suy luận giữa các nguồn dữ liệu khác nhau, hiểu ý nghĩa thực sự đằng sau một vấn đề và sau đó đề xuất các giải pháp phù hợp. Không điều nào trong số đó là khả thi.

Rõ ràng là mọi thứ đã trở nên tốt hơn rất nhiều. Bây giờ, vấn đề là hầu hết các tổ chức có nhiều hơn một triệu mã thông báo ngữ cảnh. Vì vậy, việc cố gắng đưa tất cả vào cửa sổ ngữ cảnh sẽ không hiệu quả dù sao đi nữa. Hãy nhìn về tương lai và tưởng tượng rằng quý vị có thể đưa vào 10 triệu mã thông báo, 50 triệu mã thông báo. Với tốc độ tiêu thụ bộ nhớ hiện tại chỉ để vận hành các mô hình, điều đó sẽ không khả thi trong một thời gian rất dài.

Khắc phục vấn đề "Satisfaction of Search" và Hiểu Ngữ cảnh Toàn diện

Ngay cả khi bạn đưa được toàn bộ ngữ cảnh đó vào cửa sổ ngữ cảnh của mình, bạn vẫn sẽ gặp khó khăn trong việc hiểu điều gì là đúng, điều gì là sai và làm thế nào để chọn thông tin phù hợp.

Được rồi, bây giờ tôi sẽ quay lại điểm thứ hai này: satisfaction of search. Đây là một thuật ngữ thực ra bắt nguồn từ lĩnh vực y tế, cụ thể là X-quang. Ý tưởng là khi các kỹ thuật viên xem xét phim X-quang và tìm kiếm nguyên nhân của các triệu chứng, họ có thể tìm thấy một điều gì đó trên phim X-quang giải thích các triệu chứng đó và sau đó họ dừng lại. Điều đó khá nguy hiểm về mặt y tế vì có thể có các chỉ số khác cho những bệnh như ung thư bị bỏ sót. Vì vậy, satisfaction of search là một vấn đề thực sự trong X-quang, và có rất nhiều giao thức để ngăn chặn việc dừng lại ngay khi bạn tìm thấy điều đầu tiên.

Đây là điều xảy ra với các tác nhân khi chúng tìm kiếm trong, ví dụ, Notion và cơ sở mã của bạn hoặc Confluence: chúng sẽ tình cờ tìm thấy thứ trông giống như điều chúng đang tìm kiếm, và chúng sẽ dừng lại rồi tiếp tục. Nhưng những "viên ngọc quý" thông tin thực sự có thể nằm ở một nơi khác mà tác nhân sẽ không nghĩ đến việc tìm kiếm, như trong một cuộc trò chuyện Slack trước đây hoặc trong một báo cáo sự cố.

Tầm quan trọng của Context Engine

Đây là meme tảng băng trôi kinh điển. Cơ sở mã biên dịch được: đó là mức cơ bản. Liệu tác nhân có tạo ra cơ sở mã biên dịch được không? Nhưng mọi thứ thực sự quan trọng đều nằm bên dưới. Vì vậy, việc hiểu ý định ban đầu của người dùng, những gì đã bị nhóm từ chối trong quá khứ và đã thử nhưng thất bại. Làm thế nào bạn có thể đưa loại ngữ cảnh đó lên bề mặt chỉ bằng cách xem các tài liệu và mã nguồn? Bạn cần phải hiểu điều đó bằng cách nào đó. Và tệ hơn nữa, đôi khi thật khó để biết khi nào mọi thứ bị xóa, trong trường hợp thiếu thông tin. Vì vậy, bạn cũng cần lịch sử dẫn đến các quyết định. Đây là lý do tại sao chúng tôi nghĩ bạn cần một context engine.

Một context engine hiểu bạn là ai, bạn làm việc trong nhóm nào, bạn làm việc với ai, ai là chuyên gia trong tổ chức của bạn, và những quyết định nào đã dẫn đến phiên bản hiện tại của cơ sở mã của bạn. Nó có khả năng giải quyết xung đột. Đây giống như một tình huống đúng-sai: điều gì là đúng, điều gì không. Đôi khi sự "đúng đắn" đó là một vùng xám, phải không? Vì vậy, context engine cũng cần hiểu khi nào nên hướng dẫn tác nhân rằng nó không thể giải quyết xung đột và sau đó học hỏi từ đầu vào bổ sung của người dùng.

Điểm thứ ba này cực kỳ quan trọng, dĩ nhiên, trong bất kỳ tổ chức lớn hay doanh nghiệp nào. Thường có những repository mà không phải ai cũng có thể truy cập, các dự án bí mật, và những thứ tương tự. Vì vậy, điều rất quan trọng là bạn phải truyền các kiểm soát truy cập lên trên. Tôi sẽ đưa ra một ví dụ mà mọi người sẽ hiểu, đó là Slack. Context engine của chúng tôi tích hợp với Slack hoặc Microsoft Teams. Và khi bạn có các kênh riêng tư, đó là thông tin rất nhạy cảm, phải không? Chẳng hạn bạn có thể đang thảo luận thông tin HR hoặc có thể là điều gì đó mà bạn thực sự không muốn mọi người khác nhìn thấy. Vì vậy, khi Unblocked trả lời các câu hỏi, nó sẽ sử dụng thông tin từ kênh riêng tư, nhưng nó sẽ chỉ sử dụng thông tin đó nếu người hỏi có quyền truy cập vào nó. Và sau đó, những câu trả lời đó không công khai, chúng là riêng tư đối với bạn.

Cấu trúc và Yêu cầu của Context Engine

Và cuối cùng, dĩ nhiên, là việc cung cấp ngữ cảnh phù hợp vào đúng thời điểm. Điều này liên quan đến hiệu quả mã thông báo. Đó là về việc tìm ra câu trả lời nhanh nhất có thể. Vậy, đây là một cái nhìn tổng quan cấp cao về cách một context engine có thể hoạt động. Ở bên trái, chúng ta có các đầu vào từ nguồn dữ liệu. Chẳng hạn như công cụ lập kế hoạch, tài liệu (docs), các cuộc trò chuyện, cơ sở mã, PRs (yêu cầu kéo mã) – về cơ bản là bất cứ thứ gì liên quan đến việc hoàn thành công việc ở cấp độ kỹ thuật. Và sau đó ở bên phải, chúng ta có các đầu ra. Tất cả những điều này có thể chảy đến các tác nhân viết mã, CLI tool. Bạn có thể tự xây dựng các ứng dụng thông qua API. Chúng tôi có một thành phần code review chỉ cần cắm thẳng vào SCM của bạn và cung cấp các đánh giá mã, và dĩ nhiên, tích hợp với các ứng dụng nhắn tin xã hội.

Vậy đây là sáu yêu cầu rộng mà chúng tôi cho là quan trọng. Thực tế có nhiều hơn thế, nhưng đây là những điều cấp cao. Vì vậy, một lần nữa, ngữ cảnh hệ thống hợp nhất – điều này là về việc xây dựng mối quan hệ giữa các dữ liệu. Được rồi. Nhưng nó không chỉ đơn thuần là nhận biết khi một phần dữ liệu này liên quan đến một phần dữ liệu khác. Ví dụ, trong Slack, bạn có thể có các cuộc trò chuyện về các PR. Đó là một liên kết dễ dàng vì việc đăng các liên kết qua lại. Vì vậy, điều đó dễ dàng. Điều khó hơn là hiểu lý do tại sao các quyết định được đưa ra hoặc các phương pháp hay nhất của tổ chức bạn, phải không? Vì vậy, để hiểu điều đó, bạn phải đi sâu hơn một chút. Hãy làm những việc như chắt lọc các bình luận lịch sử về pull request trên các PR và cố gắng chắt lọc chúng xuống bản chất cốt lõi của chúng. Và sau đó, khi bạn thấy các mô hình lặp lại, bạn có thể tổng hợp các mô hình đó lại và lưu trữ chúng dưới dạng "ký ức" để khi ai đó đang làm việc trên một phần cơ sở mã tương tự, bạn có thể tải những ký ức đó, và sau đó tác nhân có thể thấy điều đó và nói, "À đúng rồi, đây là cách mà tổ chức này thực hiện điều cụ thể này."

Giải quyết xung đột là cực kỳ quan trọng. Ban đầu, chúng tôi tiếp cận vấn đề này một cách khá ngây thơ, chỉ dựa vào tính thời sự (recency). Vì vậy, chúng tôi sẽ ưu tiên những thứ mới hơn. Thật không may, khi bạn có đầy đủ tất cả ngữ cảnh của mình, tính thời sự là không đủ. Thường thì mọi người viết tài liệu hoặc trò chuyện trên các nền tảng nhắn tin của họ và họ có thể nói những điều không hoàn toàn phù hợp với cách hệ thống AI hoạt động. Vì vậy, sau đó chúng tôi bắt đầu ưu tiên cơ sở mã. Chúng tôi có tính thời sự và chúng tôi nghĩ, "nhánh chính chắc chắn là nguồn sự thật của bạn," nhưng không phải lúc nào cũng vậy, bởi vì đôi khi điều quan trọng là điều gì sẽ xảy ra tiếp theo, chứ không phải cách một hệ thống AI hiện tại hoạt động. Chẳng hạn khi bạn đang làm một task, điều bạn thực sự muốn là tác nhân hiểu bạn đang đi đâu, chứ không nhất thiết là bạn đã ở đâu. Nơi bạn đã ở giúp nó hiểu điều gì không nên làm. Nơi bạn đang đi giúp nó hiểu điều gì bạn nên làm.

Được rồi. Vậy, trong trường hợp Slack, việc xem xét các cuộc trò chuyện mà các chuyên gia của tổ chức bạn đang có quan trọng hơn là chỉ hiểu những gì mọi kỹ sư ngẫu nhiên đang nói. Targeted retrieval (truy xuất mục tiêu) và personal relevance (mức độ liên quan cá nhân) rất liên quan đến nhau, vì vậy tôi sẽ nói về chúng cùng nhau một cách ngắn gọn. Một lần nữa, khi bạn kéo ngữ cảnh vào, điều quan trọng là bạn chỉ kéo ngữ cảnh vào cho task liên quan đang thực hiện và có lẽ là liên quan đến bạn. Vậy, đây là một kỹ thuật khá thú vị: bạn có thể hiểu một người làm việc trên những repo nào nhiều nhất dựa trên số lượng PR mà họ đóng góp. Và sau đó, nếu bạn đang thực hiện vector retrieval, bạn có thể thực hiện một truy xuất sâu trên các repository tập trung đó và sau đó là một truy xuất rộng hơn trên phần còn lại của mã nguồn, và sau đó điều chỉnh lựa chọn theo hướng các repository tập trung vì đó là nơi mà ai đó có nhiều khả năng làm việc và dành thời gian của họ. Và sau đó, bạn biết đấy, chúng ta đã nói về data governance, vì vậy tôi không nghĩ mình cần phải nói lại điều đó. Mặc dù rất quan trọng.

Kết quả Thử nghiệm và Bài học Kinh nghiệm

Đây chỉ là một thử nghiệm nhỏ mà chúng tôi thực hiện với một task lớn hơn. Tôi hoàn toàn thừa nhận rằng một số con số này hơi kỳ lạ. Về cơ bản, đây giống như Claude đang xuất ra các con số. Vì vậy, đừng tin vào nó. Chỉ cần tin vào cảm giác chung của vấn đề chứ không nhất thiết là các con số. Về cơ bản, điều nó nói là khi chúng tôi bắt đầu mà không có máy chủ MCP hoạt động, hoặc xin lỗi, không có context engine hoạt động, nó đã bỏ lỡ rất nhiều thứ. Và đó là vì nó không hiểu cách triển khai hiện có thực sự hoạt động và tại sao nó lại như vậy, những gì đã được thử trước đây và thất bại. Và vì vậy, nó đã mắc phải rất nhiều lỗi tương tự. Với một context engine được bật, rõ ràng là nó đã hoàn thành xuất sắc. Tuy nhiên, các con số quan trọng là thời gian và số mã thông báo mà nó đã tiêu thụ. Vì vậy, nếu không có context engine, mất hai tiếng rưỡi để hoàn thành task này với 21 triệu mã thông báo, đó là rất nhiều mã thông báo. Nhưng với context engine, chỉ mất 25 phút và 10 triệu mã thông báo. Vì vậy, đó là một sự khác biệt khá lớn.

Được rồi, vậy những bài học khó – đây chỉ là các ví dụ thôi, nhưng đây là những điều chúng tôi thấy khá thú vị. Đầu tiên, ban đầu chúng tôi tối ưu hóa cho quyền truy cập, chứ không phải sự hiểu biết. Vì vậy, tiền đề ban đầu của chúng tôi là nếu chúng ta chỉ cần kết nối một loạt công cụ và cung cấp một knowledge graph (đồ thị tri thức), nó sẽ có thể điều hướng knowledge graph và thực thi một loạt công cụ chuyên biệt cho việc truy xuất cho các tích hợp cụ thể, v.v., và tìm ra mọi thứ. Điều đó không hiệu quả. Vì vậy, bạn sẽ phải đi sâu hơn một chút. Thứ hai là chúng tôi đã che giấu các xung đột thay vì đưa chúng ra ánh sáng. Bằng cách che giấu xung đột, tôi không có ý là chúng tôi chỉ đơn giản bỏ qua các xung đột. Thay vào đó, chúng tôi đã cố gắng giải quyết các xung đột đó bằng cách sử dụng các chiến lược ngây thơ và chúng tôi đã không đưa ra các xung đột mà chúng tôi không thể giải quyết. Vì vậy, đây là một bài học thực sự tốt: một context engine – ý tôi là, có lẽ chúng ta sẽ đạt được điều đó cuối cùng – nhưng nó không thể lúc nào cũng biết đâu là các yếu tố sự thật, và khi nó không thể, bạn nên đưa điều đó ra ánh sáng và học hỏi từ nó. Đó là điều then chốt. Và cuối cùng, tôi nghĩ nhiều người đã thử điều này. Đây là một ý tưởng thực sự tồi tệ. Vì vậy, khi một context engine cung cấp một câu trả lời, đừng cache (lưu trữ tạm thời) câu trả lời đó và cố gắng phục vụ lại câu trả lời tương tự cho một câu hỏi tương tự. Lý do khá rõ ràng khi nhìn lại: mọi thứ thay đổi liên tục, phải không? Cơ sở mã thay đổi, tài liệu (docs) thay đổi, lý do cho mọi thứ thay đổi. Vì vậy, điều này đơn giản là không hiệu quả. Điều khác là nếu bạn cố gắng sử dụng các câu trả lời trước đó làm ngữ cảnh cho các câu trả lời mới, bạn sẽ thoái hóa về giá trị trung bình. Vì vậy, nếu mô hình đang hoạt động sai hoặc làm điều gì đó không tốt và bạn liên tục đưa điều đó vào ngữ cảnh, rõ ràng bạn sẽ làm ô nhiễm ngữ cảnh. Và đây là điều xảy ra.

Ứng dụng Context Engine trong Các Nhóm Tiên Phong về Trí tuệ nhân tạo

Được rồi. Vậy bây giờ hãy nói về việc các nhóm tiên phong về Trí tuệ nhân tạo (AI-forward), giống như những nhóm đang thực hiện điều này với tác nhân dựa trên đám mây, đang sử dụng và tận dụng context engine ở đâu. Chắc chắn và đặc biệt là trong giai đoạn lập kế hoạch. Đây là nơi bạn nhận được lợi ích lớn nhất (biggest bang for buck) một cách không thể nghi ngờ. Hãy để context engine tham gia, sử dụng một kỹ năng để đưa nó vào. Kết nối nó với máy chủ MCP và xem nó hoạt động. Đây là nơi bạn nhận được lợi ích lớn nhất. Nó cũng hữu ích để làm điều này trong quá trình xem xét. Vì vậy, bạn có kế hoạch và xem xét ở cuối. Bởi vì bạn biết đấy, nếu bạn để một tác nhân thực hiện việc xem xét, về cơ bản nó sẽ chỉ chú ý đến cơ sở mã và cố gắng hiểu các điểm dừng (break points), các vấn đề bảo mật, v.v. Nhưng nếu không có ngữ cảnh của tổ chức, nó sẽ không hiểu động lực đằng sau điều đó. Vì vậy đó là điều thực sự quan trọng. Làm giàu thông tin phiếu (Ticket enrichment). Đây là một trường hợp sử dụng (use case) siêu tuyệt vời. Bạn tạo một phiếu (ticket) cho một tính năng mới và sau đó bạn chỉ cần yêu cầu tác nhân được kết nối với context engine điền vào các chỗ trống. Hoạt động tốt. Phân loại (Triage). Tôi sử dụng cái này mọi lúc. Khi tôi thấy một vấn đề trong môi trường sản phẩm (production), tôi chỉ cần đưa nó vào một tác nhân được kết nối với context engine và nó ngay lập tức đưa ra tất cả các vấn đề trong quá khứ liên quan đến điều này và bắt đầu hoạt động ngay lập tức. Ngày càng nhiều chúng ta thấy điều này trong quản lý sự cố (incident management). Được rồi. Vì vậy, chúng tôi vừa kết nối Datadog và Sentry và Datadog, xin lỗi. Và điều này đã chứng tỏ là một trường hợp sử dụng siêu tuyệt vời.

Tích hợp và Tối ưu hóa Quy trình

Nó có thể nhìn thấy các tín hiệu, sau đó hành động theo tất cả các tín hiệu và liên hệ điều đó với mã nguồn, liên hệ nó với các sự cố trong quá khứ và các cuộc thảo luận bạn đã có trong Slack. Việc có tất cả những điều đó kết hợp lại cùng một lúc gần như là điều kỳ diệu. Và cuối cùng, tôi nghĩ đây thực sự là điều tôi thích nhất và là điều mà khách hàng sử dụng nhiều nhất: hỗ trợ thành công khách hàng, bán hàng và kỹ thuật. Vậy, điều mà nhiều nhóm lớn làm là họ có các kênh hỗ trợ kỹ thuật nơi các nhóm khác có thể đến và đặt câu hỏi. Nếu bạn đặt một context engine vào một trong những kênh này, bạn có thể tự động trả lời rất nhiều câu hỏi và tiết kiệm rất nhiều thời gian cho các kỹ sư.

Tùy chỉnh Context Engine bằng Kỹ năng và Workflow

Được rồi. Vậy, làm thế nào các nhóm biến một context engine thành kỹ năng riêng của họ. Chắc chắn hãy xây dựng các kỹ năng mà bạn có thể sử dụng để sắp xếp ngữ cảnh trong một kho lưu trữ GitHub (GitHub repo). Và bạn có thể xây dựng các kỹ năng khác xung quanh nó, ví dụ như nhập ticket enrich, cung cấp ID sự cố, và sau đó nó có thể sử dụng context engine để xây dựng nội dung phong phú đó. Các workflow như thế này: chuẩn bị một timeline sự cố, và sau đó bạn chỉ cần gửi nó đến tác nhân của mình một lần nữa – context engine blah blah blah mang mọi thứ lại với nhau, thật kỳ diệu. Và cái này đây, bạn có thể kết nối nó với tất cả các loại tác nhân. Tôi có một trong những điều mà nhiều khách hàng thích làm là kết nối nó với Claude code trong hệ thống CI của họ. Chúng tôi thực sự có một thành phần code review (đánh giá mã), vì vậy bạn không cần phải làm điều này nếu bạn đang sử dụng Unblocked. Nhưng mọi người sử dụng cái này cho những mục đích khác, không chỉ code review. Ngay khi bạn kết nối một context engine ở chế độ nền, cấp cho nó một Khóa API (API key), để nó tự chạy, nó có thể làm một số điều khá điên rồ.

Ví dụ thực tế: Code Review với Context Engine

Vậy, tôi sẽ chỉ trình bày một ví dụ nhanh về những gì việc kết nối một context engine có thể làm. Đây là một PR mà đồng nghiệp của tôi đã viết, và Unblocked đã xem xét và cung cấp một loại đánh giá cho cái này. Ở cuối phần đánh giá này, đây là phần đánh giá. Bạn có thể thấy rằng Richie, tác giả của PR này, đã nói: "Rất tuyệt, đây là điều tôi sẽ nói." Lý do cho nhận xét đó – "Bạn về cơ bản đã trùng lặp một loạt các bài kiểm tra, bạn có thể rút gọn nó một chút" – là vì đây là một best practice (thực hành tốt nhất) được đúc kết từ nhiều PR khác, và điều buồn cười là tác giả của những PR đó chính là Richie. Vì vậy, anh ấy chính là người đã truyền bá best practice đó trong tổ chức. Đó chỉ là một khoảnh khắc thú vị khi chúng tôi phát hiện ra điều đó.

So sánh hiệu suất: Context Engine và Tác vụ lớn

Đây là một ví dụ khác. Đây là một bản ghi khá dài. Tôi sẽ không trình bày toàn bộ, nhưng chúng tôi đã giao cho nó một nhiệm vụ lớn. Nếu không có Unblocked, nó đã mất khá nhiều thời gian. Như bạn có thể thấy, các bản ghi khá dài. Và nó đã bỏ lỡ rất nhiều thứ. Với Unblocked, nó gọn gàng hơn nhiều. Nó đã tìm ra câu trả lời rất nhanh chóng và chính xác. Và chỉ vì chúng tôi hiện đang AI-tiên phong và "lười biếng", chúng tôi đã lấy cả hai bản ghi đó và đưa chúng vào Claude và chỉ nói: "Này, Claude, tại sao bạn không phân tích cả hai điều này và cho chúng tôi kết quả của bạn?" Vậy, nó đã thực hiện – tôi sẽ không làm bạn nhàm chán với các chi tiết – nhưng chỉ để nói rằng cuối cùng, phán quyết là kế hoạch context engine là điều tôi sẽ triển khai. Cái còn lại tốt cho một bản prototype, nhưng nó thiếu rất nhiều thứ quan trọng đối với tổ chức này. Nó đã được thảo luận trước đó.

Tầm nhìn về mã nguồn do AI tạo ra và Bản chất của Context Engine

Được rồi, về cơ bản đây là những gì tôi đã cố gắng nói: mã nguồn do AI tạo ra phải có cảm giác như nó được viết bởi một người đã ở trong nhóm của bạn khoảng 20 năm. Được rồi. Nếu nó chưa đạt được điều đó, không sao cả. Nó sẽ làm được. Nếu bạn kết nối Unblocked, bạn sẽ thấy sự khác biệt lớn về hiệu suất của các tác nhân. Và nếu bạn đang xây dựng một trong những thứ này, hãy chắc chắn tận dụng tất cả những điều này và xây dựng, và chúng ta hãy xem nó sẽ đi đến đâu. Vậy, ngay trước khi chúng ta đi vào phần workshop, có lẽ chúng ta sẽ có khoảng năm, mười phút Q&A.

Tôi là Brandon.

Và đây là Brandon. Vậy, anh ấy sẽ giúp đỡ với điều này.

Cảm ơn. Vậy, rõ ràng là nó làm gì cho bạn và nó giải quyết những loại vấn đề gì? Nhưng đối với tôi, một dấu hỏi lớn là "nó là cái gì?" "Cái artifact nào phù hợp với mô tả đó?" Nó có phải là một chương trình bạn cài đặt, một API được lưu trữ từ xa, hay một máy chủ MCP? Nó là gì?

Context Engine: Đa hình thái và Vai trò Quản lý Tri thức

Nó là tất cả những điều đó. Vậy, một context engine – tôi sẽ giải thích Unblocked là gì. Có lẽ tôi có thể trình diễn nhanh một chút. Nói rộng ra, có nhiều bề mặt khác nhau cho một context engine. Bạn muốn đưa nó vào agent flow (luồng tác nhân), và bạn có thể làm điều đó với một máy chủ MCP. Bạn có thể làm điều đó với một công cụ CLI, chẳng hạn. Chúng tôi cũng có bề mặt dashboard này, nơi bạn có thể đặt câu hỏi về mã nguồn của mình. Đây là một cái khá cơ bản, nhưng bạn có thể thấy nó hiểu tôi là ai và tôi đang làm gì. Và sau đó, chúng tôi cũng có kết nối Slack. Vì vậy, bạn có thể đưa Unblocked vào Slack, điều khiển nó trong các cuộc trò chuyện và để nó tự động trả lời mọi thứ. Điều đó có ý nghĩa không? Tôi đã trả lời câu hỏi của bạn chưa hay...

Được.

Vâng. API, CLI, MCP.

Vâng. Vâng,

Xin lỗi.

Cảm ơn bạn. Vậy câu hỏi của tôi là, theo như tôi hiểu thì nó giống như một ứng dụng quản lý và truy xuất tri thức.

Vâng. Và điều này có liên quan gì đó đến những thứ như LLM wiki – như nó đã trở nên phổ biến gần đây bởi Andre Karpathy – hoặc decision traces và context graphs đã được thảo luận nhiều cách đây vài tháng không?

Context Engine: Vượt xa Wiki và Phạm vi Ứng dụng

Vâng. Vậy bạn có thể coi tất cả những điều đó như những thành phần hữu ích cho một context engine. Một context engine phải làm nhiều hơn thế bởi vì các tác nhân thực sự rất giỏi trong việc duyệt qua một wiki, chẳng hạn. Điều đó phụ thuộc vào cách bạn xây dựng wiki này, bởi vì có rất nhiều thứ như organizational memories (ký ức tổ chức), best practices (thực hành tốt nhất), bạn biết đấy, chuyên gia trong tổ chức của bạn và những điều đó được sử dụng làm pivot points (điểm mấu chốt) để truy xuất ngữ cảnh. Vì vậy, một wiki không giải quyết được những vấn đề đó trừ khi nó có một cấu trúc mà bạn có thể xây dựng với nó. Và tôi nghĩ Karpathy đã phát hiện ra rằng nếu bạn coi một wiki giống như một hệ thống tập tin, bạn có thể chia nhỏ nó và để tác nhân xử lý nó như một hệ thống tập tin. Nhân tiện, các tác nhân được tối ưu hóa cao cho việc duyệt hệ thống tập tin.

Vâng. Bước biên dịch. Chính xác.

Vâng. Vâng, xin lỗi. Xin lỗi, có lẽ cùng câu hỏi, nhưng nó có phải là một context engine đa năng hay nó nhắm mục tiêu vào mã nguồn? Bởi vì, liệu nó có hữu ích như, chẳng hạn, một chuyên gia lĩnh vực kinh doanh (business domain expert), hoặc xây dựng một lĩnh vực kinh doanh (business domain) và sau đó để context engine này sử dụng của tôi để tất cả các tác nhân AI khác của tôi có thể sử dụng điều này làm ngữ cảnh cho doanh nghiệp. Hay bạn sẽ nói rằng nó chỉ dành cho phần mã nguồn?

Chuyên biệt Kỹ thuật và Vấn đề Quản trị Dữ liệu

À, vậy nó chắc chắn tập trung vào kỹ thuật; các tích hợp tập trung vào các hoạt động kỹ thuật. Vì vậy, bạn biết đấy, tích hợp SCM và các công cụ khác mà các kỹ sư sử dụng. Chúng tôi đang ngày càng thấy khách hàng sử dụng nó cho các mục đích khác. Vì vậy, business intelligence (thông tin doanh nghiệp) là một yếu tố quan trọng. Và điều đó thường hữu ích khi những người trong các chức năng kinh doanh đang cố gắng hiểu về sản phẩm và chức năng của nó. Chúng tôi không có các tích hợp Salesforce được kết nối cho việc đó. Vì vậy, bạn không thể sử dụng nó để hiểu bất cứ điều gì liên quan đến bán hàng. Nó thực sự chủ yếu là một context engine tập trung vào kỹ thuật. Điều đó không có nghĩa là nó sẽ không thay đổi. Vâng. Về vấn đề quản trị (governance), nếu bạn đang tôn trọng quyền truy cập, làm thế nào nó có thể tổng hợp các thứ và sau đó phát triển kiến thức mới nội bộ mà nó có thể hiển thị cho mọi người?

Tổng hợp Thông tin Phân vùng và Kỹ thuật Tổng hợp Nâng cao

Vâng, bạn nói đúng khi chỉ ra điều đó. Sự tổng hợp được phân vùng. Vì vậy, có những nơi được phân vùng như các kho lưu trữ (repository) riêng lẻ. Đó là mức độ truy cập. Vì vậy, nếu bạn có thể tổng hợp dữ liệu lịch sử dựa trên điều đó và sau đó tương quan nó với thông tin Slack công khai, thì đó là một cách để thực hiện tổng hợp mà không vượt qua ranh giới tổ chức. Cách khác là xem xét và gắn thẻ khi thông tin được tổng hợp vượt qua các ranh giới tổ chức đó, và bạn có thể áp dụng một cách tiếp cận group ID (ID nhóm) cho vấn đề đó, nơi bạn đính kèm thẻ group ID vào thông tin được tổng hợp và sau đó chỉ truy xuất nó nếu người có truy cập vào đó có thể xây dựng nó. Vì vậy, trước tiên hãy áp dụng cách tiếp cận phân vùng bởi vì đó là nơi bạn sẽ đạt được hiệu quả cao nhất, và sau đó bạn xây dựng từ đó. Ý tôi là đây là vấn đề cốt lõi khi sử dụng một công nghệ như Graph RAG, đúng không? Bởi vì Graph RAG giống như một kim tự tháp nơi nó xây dựng theo các lớp và sau đó về cơ bản tóm tắt từng lớp, nhưng điều đó chắc chắn vượt qua ranh giới quyền hạn. Vì vậy, bạn phải tạo ra các phần phân vùng. Vâng. Đó là một câu hỏi hay.

Vâng.

Vâng. Bạn đã nói rất nhiều về tất cả các nguồn thông tin khác nhau mà bạn tiêu thụ và kết hợp tất cả chúng lại với nhau. Khi nó tổng hợp những thứ đó xuống, liệu đó vẫn là kiểu RAG ngây thơ (naive RAG), tìm kiếm vector (vector search), tất cả những thứ đó bên dưới không? Hay là các tác nhân đang quyết định điều gì là phù hợp? Hay có lẽ là sự kết hợp của tất cả chúng, nhưng bước đó là gì?

Phương pháp xây dựng Knowledge Graph và Giải quyết Xung đột

Ừm, vâng, bạn nói đúng. Đó là sự kết hợp của tất cả chúng. Vì vậy, việc xây dựng knowledge graph (đồ thị tri thức) xảy ra theo nhiều cách khác nhau. Cái liên quan đến PR mà tôi đã chỉ cho bạn, chẳng hạn, đầu tiên bạn xây dựng một knowledge graph ngây thơ (naive knowledge graph) một cách theo thủ tục, và sau đó từ đó bạn có thể sử dụng một Mô hình Ngôn ngữ Lớn (LLM) để chắt lọc và tóm tắt và xây dựng các loại kỹ thuật đó. Context engine của chúng tôi đầu tiên xây dựng một knowledge graph từ cơ sở, cố gắng tận dụng tất cả các thực thể khác nhau. Nó giống như một thứ hạng trang (PageRank) nơi nó xây dựng các mối quan hệ một cách theo thủ tục, và sau đó tất nhiên, nó vectorizes data (chuyển đổi dữ liệu thành vector). Và sau đó có các công cụ theo thủ tục để tìm nạp dữ liệu trong thời gian chạy (runtime). Rất nhiều công việc chắt lọc để giải quyết xung đột xảy ra ở hai nơi. Vì vậy, một là trong thời gian nhập dữ liệu (data ingestion time), có các thẻ (tags) liên quan dữ liệu với nhau để chúng ta có thể xem liệu chúng ta có thể khử xung đột ở cấp độ đó và sau đó xếp hạng lẫn nhau ở cấp độ đó. Và sau đó, tất nhiên, trong thời gian chạy, bạn phải chuyển mọi thứ cho một người đánh giá với các tiêu chí, và sau đó nó thực hiện thêm khử xung đột trong thời gian thực.

Điều đó có hợp lý không?

Vâng.

Được.

Vai trò của Con người trong Giải quyết Xung đột Ngữ nghĩa

Một câu hỏi nữa. Tôi tò mò, bạn nói về các xung đột nhưng đến một lúc nào đó, bạn gặp phải các xung đột mà một thứ có nghĩa là doanh thu cho một công ty và có nghĩa là doanh thu cho một công ty khác lại là một ý nghĩa hoàn toàn khác. Làm thế nào bạn có thể nhận ra điều đó? Vậy, làm thế nào bạn đưa con người vào vòng lặp (humans in the loop)? Làm thế nào bạn sử dụng các ontology (hệ thống phân loại kiến thức) của họ, và làm thế nào bạn sử dụng nó khi bạn gặp phải điều đó? Tôi thực sự rất tò mò về điều đó. Làm thế nào, làm thế nào...

Vâng, nếu bạn – tôi có thể chỉ cho bạn một điều nhanh chóng ở đây – bạn sẽ nhận thấy rằng ở phía dưới, các tham chiếu được sử dụng cho các câu trả lời được gửi cả cho con người trong giao diện này mà còn cho tác nhân. Vì vậy, nếu tác nhân, nếu context engine không thể thực hiện việc khử xung đột, thì tại thời điểm này, con người có thể can thiệp và hướng dẫn tác nhân khi có đủ...

Vì vậy, bạn có thể chỉ cần trả lời và nói rằng "điều đó không chính xác" hoặc bạn có thể đến đây...

và...

Ồ vâng, xin lỗi.

Vâng, hoặc bạn có thể làm điều này như "Không hữu ích" và đưa ra lý do tại sao. Nó hơi là một quy trình thủ công (manual process) ở giai đoạn này, nhưng các tín hiệu tích lũy theo thời gian...

Thật buồn cười phải không? Bạn có thể thu thập rất nhiều trí tuệ con người bằng cách này, đúng không?

Vâng, điều đó thật tuyệt vời.

Phản hồi từ người dùng về Tác nhân

Hỏi: Đối với một khách hàng điển hình, bạn có số liệu thống kê về mức độ phản hồi như thế nào?

Đáp: Ồ, con số này rất lớn, thật đáng kinh ngạc. Tôi thực sự rất bất ngờ về mức độ sẵn lòng cung cấp phản hồi của mọi người. Vâng, không, đó là...

Hỏi: Hàng nghìn hay hàng trăm?

Đáp: Ý tôi là, đối với các nhóm nhỏ (khoảng 20-30 người), con số này lên tới hàng trăm. Đối với các nhóm lớn (100-200 người), đó là hàng trăm và hàng trăm phản hồi.

Hỏi: Ồ, tuyệt vời.

Đáp: Vâng. Mọi người thực sự thích tương tác với các tác nhân và nói cho chúng biết bằng ngôn ngữ tự nhiên những gì đang gặp sự cố. Đó là một điều hoàn toàn tự nhiên để làm.

Hỏi: Vâng.

Giới thiệu Workshop và Công cụ Xây dựng Biểu đồ Xã hội

Tuyệt vời. Được rồi. Chúng ta đã sẵn sàng cho phần hỏi đáp chưa? Sau đó chúng ta có thể tiếp tục. Hãy đặt câu hỏi trong lúc chúng ta cùng thực hành. Vâng, hãy chuyển sang phần workshop. Vì vậy, chúng tôi đã tạo một... thực ra tôi sẽ làm điều này trước. Bạn có thể làm điều này ngay bây giờ nếu muốn. Tôi sẽ quay lại slide này sau một chút.

Ý tưởng ở đây là chúng ta sẽ yêu cầu mọi người tham gia một không gian làm việc Slack mà chúng tôi đã tạo, sau đó chúng ta sẽ đưa mọi người vào một repo nơi mã nguồn mẫu này cư trú, và sau đó chúng ta sẽ bắt đầu thực hành cùng nhau. Được chứ?

Vâng, tôi thấy một số người đang tham gia. Khi bạn tham gia, bạn sẽ thấy một kênh AI Engineering London. Hy vọng sẽ có một liên kết đến đây và liên kết unblocked sẽ không hoạt động cho đến khi bạn thực hiện bước hai. Vâng. Để vào GitHub hoặc... Ồ không. Tôi có rất nhiều người đang tham gia. Vì vậy, tôi thực sự hy vọng rằng đây là mạng lưới? Vâng, chúng ta sẽ tìm hiểu.

Được rồi, trong khi mọi người đang làm điều đó, tôi sẽ chỉ cho bạn thấy những gì chúng ta sắp thực hiện ở đây. Đây là tổ chức GitHub. Những gì chúng ta đang xây dựng là một công cụ social graph builder. Công cụ này sẽ xem xét một kho mã nguồn. Bạn có thể chạy nó trên repo của riêng mình. Nó sẽ không tải lên bất cứ thứ gì, tất cả đều chạy cục bộ. Để bạn có thể thấy công cụ này được xây dựng dựa trên tổ chức của riêng mình.

Và nó sẽ làm một số điều. Về cơ bản, chúng ta sẽ nhận được một social graph từ nó, và tôi sẽ cho bạn thấy nó trông như thế nào. Và chúng ta sẽ hiểu ai là các chuyên gia và họ làm việc trên những phần nào của mã nguồn. Và sau đó sẽ có một công cụ trực quan hóa tương tác nhỏ.

Vì vậy, mục tiêu của bài tập này là đưa công cụ này hoạt động và bắt đầu thực hành trên đó. Giống như, bắt đầu gửi PR ngay khi chúng ta khởi động nó. Đây là hình ảnh của nó. Biểu đồ này là tổ chức unblocked của chúng tôi. Và những gì bạn đang thấy ở đây là một relationship graph (biểu đồ quan hệ) cho thấy ai đang xem xét PR của ai và ai đang được xem xét.

Về cơ bản, công cụ này là một sự chắt lọc của tất cả các nhóm khác nhau trong unblocked. Vì vậy, điều này thực sự khá chính xác. Vâng, không phải "khá", mà là rất chính xác. Chúng tôi đã làm điều này từ đầu năm 2025 (dù đây là một lỗi đánh máy, ý nghĩa có thể là 2015 hoặc một năm cụ thể trong quá khứ). Khi bạn chạy công cụ này, tôi khuyên bạn nên làm cho một dòng thời gian ngắn hơn một chút vì nó sẽ hơi chậm nếu bạn quay lại tận 2025. Có thể mất khoảng 15 phút.

Nhưng nó đã chắt lọc một cách hiệu quả các nhóm là ai và bước AI duy nhất trong này là gắn nhãn cho các nhóm. Bạn không cần phải chạy bước AI nếu không muốn; nó sẽ chỉ sử dụng các phần mã nguồn mà mọi người làm việc nhiều nhất.

Tab này sẽ hiển thị các chuyên gia trong tổ chức và những gì họ làm việc. Điều này chỉ được chia nhỏ theo khu vực dự án và đường dẫn và cho thấy những khu vực mã nguồn nào có độ phủ sóng tốt. Độ phủ sóng chủ yếu được định nghĩa bởi việc có một chuyên gia tổ chức đóng góp cao hiện diện hay không và liệu đó có phải là một phần mã nguồn được đóng góp tích cực hay không.

Và cuối cùng, chúng ta sẽ có interactive graph này mà nó sẽ chia nhỏ mọi thứ theo khu vực nhóm và sẽ hiển thị ví dụ như ai là những người đóng góp chính. Tôi đang ở đây, trong nhóm AI. Vâng, vậy thôi. Hãy đưa mọi người vào và chúng ta sẽ bắt đầu thực hành trên đó.

Thiết lập GitHub và Vấn đề Kỹ thuật

Vâng, chắc chắn rồi. Nhiều bạn đã nhận được lời mời nếu đã nhập GitHub của mình. Vì vậy, hãy kiểm tra. GitHub thật tệ. Vâng, chúng tôi sẽ làm vậy. Nó là một giấy phép Apache 2.0. Chúng tôi sẽ công khai nó sau, nhưng bây giờ, chúng tôi cần khóa nó lại. Ồ, bạn vẫn còn... Tôi sẽ cho bạn xem. Bạn đã làm gì vậy? Tôi cũng hơi... Vì vậy, tôi nghĩ phần còn lại của phiên này bây giờ sẽ chỉ là thực hành thôi. Vì vậy, lát nữa đây, tôi nghĩ tôi sẽ gỡ cái này xuống nếu mọi người đã có nó. Để Brian và tôi có thể tập trung làm việc với các bạn để xây dựng các tính năng.

Ồ, nhân tiện, khi bạn gửi PR, bạn sẽ thấy rằng unblocked đang ngồi đó với tư cách là một người đánh giá mã. Vì vậy, đừng cảm thấy tệ nếu nó hơi "phun" vào PR của bạn một chút. Tùy thuộc vào mức độ... Bạn có một cái tên người dùng tuyệt vời. Làm tốt lắm. Mọi người đều ổn với điều này chứ? Tôi sẽ gỡ nó xuống. Được rồi, tốt. Thế là xong. Brandon, bạn đang quản lý các lời mời phải không? Được rồi, tốt. Còn một vài người nữa. Tôi đang đến chỗ Chris đã đưa hai cái. Không sao đâu. Tôi sẽ gửi cả hai. Đừng lo lắng. Đó chỉ là vị trí của tôi trong danh sách này. Ồ, thực ra tôi quên không đề cập đến một vài điều ở đây.

Vâng. Trực tiếp trở lại. Vâng, tốt. Chỉ một vài điều. Vì vậy, nếu bạn đang tìm kiếm thứ gì đó để triển khai và bắt đầu với bất kỳ việc gì với việc đưa ra ý tưởng, v.v., thì có một tập hợp các vấn đề đã được định nghĩa trước mà bạn có thể thực hành. Vì vậy, bạn chỉ cần lấy một trong số này, đưa nó vào Claude và xem nó hoạt động như thế nào khi được kết nối với context engine.

Máy chủ MCP cho unblocked ở đây. Vì vậy, nếu bạn muốn hướng dẫn cách kết nối cái này với CLaude Code hoặc một tác nhân khác, thì bạn có thể lấy hướng dẫn từ đây. Được rồi. Tôi đang ở chỗ Lars. Còn hai người nữa ở đây. Vì vậy, tôi vẫn đang tiếp tục, nhân tiện, đối với những người mới tham gia... Chuyện gì đang xảy ra vậy, Brandon? Ồ, xin lỗi. Chỉ là một trong những tên người dùng là... Ồ, được rồi. Bạn nên có ngay sau Christopher, bạn chưa nhận được lời mời phải không? Không, tôi chưa nhận được. Lạ thật. Để tôi kiểm tra lại. Bạn nên có một cái, nhưng... Vâng, tôi nên có. Bạn nên có một email. Tôi đang gửi tới một trong số các bạn. Khó thật. Cần tới năm lần nhấp để thêm một thành viên. Tôi thì như thể... Tôi định nói rằng bạn nên có thể sử dụng giao diện dòng lệnh cho việc này. Chuyện gì đang xảy ra vậy? Đúng vậy. Không, họ cứ đưa nó vào PR của tôi và tôi không muốn nó ở đó. Copilot sẽ xem xét giúp tôi... rất tệ, nhưng nó sẽ đặt câu hỏi.

Phân tích Sử dụng Tác nhân và Công cụ

Vâng, chắc chắn rồi. Khoan đã. Để tôi đưa micro cho bạn. Hy vọng nó đang bật. Nó hoạt động không? Vâng.

Hỏi: Tôi đoán context engine hoạt động rất tốt cho các tác nhân không đồng bộ để bạn không cần phải chỉ định mọi thứ trên bàn phím vì chúng có thể tìm nạp những gì chúng cần. Đó là một trong những cách sử dụng chính mà tôi đoán. Và nó hoạt động rất tốt, tôi nghĩ, với các tác nhân như Copilot trên GitHub. Bạn có thấy, nếu bạn có thể chia sẻ, những tác nhân nào được sử dụng nhiều nhất với unblocked, liệu có phải là vì trong thực tế, các nhà phát triển với máy tính xách tay của chúng tôi, tôi nghĩ CLaude Code được sử dụng nhiều hơn Copilot, nhưng có lẽ bạn thấy một bức tranh khác?

Đáp: Được rồi, tôi sẽ gỡ cái này ra khỏi màn hình trong giây lát và cố gắng tìm thông tin đó cho bạn. Nhưng câu trả lời là có, chúng tôi biết sơ bộ về sự phân bổ đó trông như thế nào. Vì vậy, để tôi lấy nó ra. Được rồi. Tôi nghĩ điều này cho bạn một cái nhìn tổng quan. Được rồi. Đây là bức tranh tổng thể. Thật không may vì cách trình bày này, tôi có lẽ nên mở rộng màn hình, nhưng tôi sẽ bước sang đây.

Vì vậy, CLaude Code cho đến nay là được sử dụng nhiều nhất. Tiếp theo là Cursor. Điều đó có vẻ khá rõ ràng. Cái cuối cùng này là một loại tập hợp con, nhưng điều thực sự thú vị là rất nhiều người sử dụng CLaude Desktop, điều này rất bất ngờ, nhưng đó là sự thật.

Và sau đó VS Code và Codeex chiếm một phần nhỏ hơn nhiều, nhưng vâng, có vẻ như mọi người đều sử dụng Cursor hoặc CLaude Code. Tôi đã mong đợi nhiều hơn từ một tác nhân hoàn toàn không đồng bộ, như thứ gì đó mà mọi người sẽ chỉ chạy từ một PR. Được rồi, bạn có thể chạy CLaude Code từ một PR, nhưng điều đó ít phổ biến hơn. Đôi khi bạn sử dụng Copilot vì nó được tích hợp sẵn.

Vâng, thực ra cái này ở đây, CLaude Code, có thể nắm bắt một phần lưu lượng truy cập đó. Vì vậy, đó có lẽ là những gì bạn đang thấy bởi vì mọi người sẽ kết nối CLaude Code trong CI và làm những việc tương tự.

Hỏi: Cảm ơn.

Đáp: Không có gì. Tôi có một câu hỏi có thể hơi ngớ ngẩn.

Hỏi: Không có câu hỏi ngớ ngẩn.

Đáp: À, chúng ta sẽ xem. Thực ra, bạn biết đấy, bạn sẽ sớm biết thôi. Tôi đã có một giáo viên lớp ba từng nói với tôi rằng: "Không có câu hỏi ngớ ngẩn, chỉ có những người ngớ ngẩn." Cứ tiếp tục đi. Tôi có thể là một trong số họ.

Biểu đồ Xã hội như một Điểm then chốt trong Engine Ngữ cảnh

Hỏi: Từ quan điểm của bạn, bạn có thể sử dụng các tác nhân con từ góc độ khám phá. Làm thế nào mà điều đó cộng với bộ nhớ cộng với việc lưu trữ các đoạn thông tin có thể... Tôi đang nghĩ về social graph mà bạn vừa trình bày, phải không? Ngay cả trong một tổ chức có vài nghìn người, bạn vẫn có thể lưu trữ nó trong một tệp rất nhỏ. Đúng không?

Đáp: Bạn sẽ làm được như biểu đồ bạn đã trình bày. Ồ, tôi hiểu thành phần social graph. Vâng. Vâng, nó có thể nhỏ gọn. Tôi đang cố gắng hiểu điều này so sánh như thế nào, USP (điểm bán hàng độc nhất) của nó so với các tác nhân khám phá và việc lặp lại điều đó.

Tôi hiểu ý bạn rồi. Được rồi. Có hai thành phần cho điều đó. Một là tác nhân khám phá sẽ phải làm điều này mỗi lần. Vì vậy, khi nó bắt đầu từ đầu, vâng, có thể nó sẽ tái cấu trúc một loại social graph hierarchy (hệ thống phân cấp biểu đồ xã hội), nhưng nó sẽ phải làm hai điều để làm được điều đó.

Một là nó thực sự phải viết mã nguồn để tạo thành biểu đồ, ít nhất là theo cách các tác nhân hiện nay hoặc các mô hình hiện nay hoạt động. Bạn sẽ không thể chỉ yêu cầu nó chạy các công cụ cơ bản xung quanh tổ chức và tìm ra ai là ai. Nó sẽ phải viết một loại thuật toán social graph đó, chạy nó và sau đó nhận được sự chắt lọc ở phía sau. Vì vậy, tại thời điểm đó, bạn về cơ bản đã gần với thành phần đó rồi. Dù sao đi nữa, bạn sẽ rút ngắn quy trình và chỉ cần chạy nó và sử dụng nó.

Có lẽ tôi nên giải thích một số động lực cho điều đó. Thực ra tôi nhận ra rằng có lẽ tôi đã không làm điều đó hiệu quả. Social graph không chỉ là truyền đạt thông tin về các chuyên gia là ai. Nó được sử dụng trong context engine như một điểm then chốt để đi sâu vào các ngữ cảnh quan trọng hơn.

Vì vậy, việc hiểu ai là các chuyên gia trong một khu vực mã nguồn cụ thể đóng vai trò như một điểm nhảy vì một phần khác của context engine xảy ra ở lớp nhập liệu và xử lý là chắt lọc... chúng tôi gọi là "đóng chai chuyên gia" nhưng về cơ bản đó là chắt lọc những gì cá nhân đó đã làm trong quá khứ, vị trí của họ trong hệ thống phân cấp của tổ chức, những quyết định mà họ đã đưa ra dựa trên các cuộc trò chuyện Slack mà họ đã có, dựa trên các bình luận PR của họ, tất cả những thứ này.

Khi bạn chắt lọc điều đó và bạn chuyển nó cho tác nhân, thì điều gì sẽ xảy ra là, giả sử tôi là một nhân viên mới và tôi đến để làm việc trên một khu vực mã nguồn cụ thể, có nhiều cách khác nhau để tải ngữ cảnh cho mã nguồn đó. Một là tìm kiếm ngữ nghĩa thông qua tìm kiếm vector. Đúng không? Đó là lớp một. Một lớp khác là bộ nhớ được xây dựng trước.

Khai thác kiến thức chuyên gia và Hướng dẫn sử dụng Claude Code

Lớp thứ ba là khai thác kiến thức chuyên gia cho từng khu vực mã nguồn. Việc đưa những hiểu biết của chuyên gia vào ngữ cảnh là một cơ chế thực sự mạnh mẽ. Nó giúp thúc đẩy phần còn lại của quá trình truy xuất trong một Agent Loop và giúp tác nhân định hướng nơi cần đến tiếp theo. Điều đó có hợp lý không?

Người tham gia: Vâng, tôi nghĩ mọi người đã sẵn sàng rồi.

Diễn giả: Tuyệt vời. Vậy chúng ta hãy... Được rồi, tôi nghĩ nếu tất cả chúng ta đã sẵn sàng thì điều tiếp theo là khi tôi đưa cái này trở lại màn hình.

Người tham gia: Tôi vẫn đang gửi lời mời. Tôi vừa thấy ai đó... Vậy nên, mọi người hãy tiếp tục tham gia và chúng ta có thể tiếp tục.

Diễn giả: Vâng, vì vậy, hãy cứ thoải mái chạy repo này với tác nhân của bạn và để nó chạy. Nếu bạn chỉ cần nói với Claude Code là "chạy cái này với repo của tôi", hãy đảm bảo bạn cung cấp một khoảng thời gian hoặc giới hạn PR, nếu không nó sẽ mất kiểm soát và mất rất nhiều thời gian để hoàn thành. Vì vậy, chỉ cần nói như "xử lý 300 PR cuối cùng" hoặc "xử lý cho đến tháng 9 năm 2025" hoặc đại loại thế. Có đủ thông tin trong README để nó có thể tự thực hiện và chạy nó trên repo của bạn.

Người tham gia: Tôi đã clone, đọc README và thực hiện nó.

Diễn giả: Vâng.

Tầm nhìn tương lai: Tác nhân tự chủ và khai thác kiến thức

Người tham gia: Tôi có thể hỏi một câu khác không? Kế hoạch của bạn cho năm tới là gì?

Diễn giả: Đối với Unblock ư?

Người tham gia: Nó có phải về Unblock hay về dự án phụ này không?

Diễn giả: Cái này... Ờm, tôi đã từng đề cập đến điều này trước đây, nhưng xu hướng đang đi tới là các tác nhân hoàn toàn tự chủ. Vì vậy, chúng tôi rất tập trung vào việc đảm bảo các quy trình của tác nhân tự chủ được tối ưu hóa cao. Như tôi đã nói ở đầu cuộc trò chuyện, bạn không thể vận hành những thứ đó một cách hiệu quả nếu không có ngữ cảnh được tinh chỉnh rất kỹ lưỡng.

Người tham gia: Vâng. Vậy khi bạn nghĩ về nó, có lúc tôi đọc những thứ như tracing, tác nhân làm gì và bạn nhận được run books từ đó. Đó có phải là con đường bạn đang đầu tư vào không, hay nó là gì? Retrieval là gì?

Diễn giả: Bạn đang nói cụ thể về quản lý sự cố sao?

Người tham gia: Xin lỗi.

Diễn giả: Bạn có đang nói cụ thể về quản lý sự cố, những thứ như vậy không?

Người tham gia: Không, tôi đang nói về... Tôi thực sự đang nghĩ nhiều hơn từ góc độ kinh doanh. Làm thế nào chúng ta có thể trích xuất kiến thức kinh doanh đã ăn sâu vào các hệ thống mà không ai còn biết nữa, và một số người nghĩ rằng họ biết nhưng thực ra không biết.

Diễn giả: Vâng.

Người tham gia: Và tài liệu, kiến thức của con người, đúng không? Kiến thức đã được kiểm chứng.

Diễn giả: Vâng. Có hai cách để phục vụ điều đó: hoặc ở cấp độ sản phẩm, hoặc thông qua chính context engine. Và ngày càng nhiều, chúng tôi thấy rằng mọi người tận dụng tác nhân để thực hiện công việc của họ ngay cả ở cấp độ đó. Vì vậy, họ sẽ truy cập Claude Code, kết nối Unblock Context Engine, nó sẽ như kiểu "hãy làm điều này cho tôi" và sau đó context engine sẽ tìm tất cả những thứ cần thiết để thực hiện nhiệm vụ đó và hiển thị dữ liệu đó.

Kế hoạch lộ trình API và hướng dẫn đóng góp

Người tham gia: Vâng.

Diễn giả: Đối với chúng tôi, điều đó có nghĩa là lộ trình ngắn hạn đầu tiên là API.

Người tham gia: Vâng. Nó giống như CLI.

Diễn giả: Câu hỏi về CLI API hay chỉ là tuyệt vời. Tôi sẽ trình chiếu lại cái này. Hy vọng mọi người sẽ bắt đầu gửi các PR và chúng ta có thể...

Người tham gia: Vâng, bạn đang ở trong GitHub đó. Để tôi thực sự đăng lại nó trong kênh Slack vì liên kết đó sẽ...

Diễn giả: Vì vậy, org này sẽ hoạt động cho đến cuối tuần. Đến lúc đó, chúng tôi sẽ ngừng hoạt động và phát hành cái này dưới dạng mã nguồn mở, và tất cả những người đóng góp rõ ràng sẽ được ghi công. Vì vậy, tên của bạn sẽ có trên đó. Chúng ta có nên thiết lập repo cục bộ và sau đó bắt đầu làm gì đó không? Tôi vừa thiết lập xong.

Diễn giả: Vâng, chỉ cần clone repo. Điều dễ nhất là lấy một tác nhân như Claude và hướng nó đến... chỉ cần khởi chạy nó từ repo đó, từ thư mục đó và chỉ cần nói "làm ơn khởi tạo và chạy sản phẩm này" và nó sẽ hoạt động. Nếu các bạn gặp bất kỳ vấn đề kỹ thuật nào, chúng tôi rõ ràng sẽ ở đây để hỗ trợ. Vâng.

Đánh giá hiệu suất: Claude Code và Unblock

Người tham gia: Đợi chút. Để tôi đưa micro cho bạn. Ồ, bạn có rồi. Tôi có một cái kẹp áo bây giờ.

Diễn giả: Tuyệt vời.

Người tham gia: Vâng. Bạn có nghe thấy tôi không? Vâng. Hoàn hảo. Ờm, vậy trên slide mà bạn có về hiệu suất, các bạn đạt 80% và không có Unblock thì chỉ là 20%.

Diễn giả: Vâng.

Người tham gia: Ờm, và bây giờ tôi thấy rằng bạn về cơ bản đang kết nối Unblock với Claude Code. Vậy theo một cách nào đó, liệu có công bằng khi nói rằng tôi sẽ sử dụng Claude Code nguyên bản với quyền truy cập vào MCP và các kỹ năng.

Diễn giả: Vâng.

Người tham gia: Và sau đó tôi sẽ sử dụng Claude Code được kết nối với Unblock với cùng MCP và cùng kỹ năng.

Diễn giả: Vâng.

Người tham gia: Và ở đây bạn có thể so sánh hiệu suất. Và ở đây bạn vẫn có rất nhiều điều alpha mà tôi đoán là những gì bạn đang "nấu" bên trong Unblock. Đó có phải là phép so sánh đã được thực hiện không, hay nó được thực hiện mà không có...

Người tham giả: Nó có được thực hiện với Claude Code nguyên bản nhưng không có ngữ cảnh không?

Diễn giả: Không, nó được thực hiện với các máy chủ MCP như GitHub và Slack được kết nối.

Người tham gia: Tôi hiểu.

Diễn giả: Vâng, tuyệt.

Người tham gia: Chúng tôi về cơ bản đã đạt được sự tương đồng với tất cả các máy chủ MCP của mọi nhà cung cấp SaaS trong một lần. Đó là Claude Code nguyên bản với tất cả MCP và cái còn lại là Claude Code chỉ với Unblock.

Người tham gia: Và sau đó thực hiện nhiệm vụ và...

Người tham gia: Cùng ngữ cảnh, giống như cùng một tệp ngữ cảnh.

Người tham gia: Cùng một lời nhắc.

Người tham gia: Và cùng quyền truy cập. Vâng. Vâng.

Người tham gia: Khá là vui. Vâng. Ồ, cảm ơn bạn.

Xây dựng biểu đồ xã hội và nhận diện chuyên gia

Người tham gia: Ờm, có lẽ hai câu hỏi. Đầu tiên là tôi thấy rằng nhiều biểu đồ xã hội này được xây dựng bằng cách tính toán mạng truyền thống và các khía cạnh thống kê của mạng. Đây có phải là cách tiếp cận bạn bắt đầu và nó đã hoạt động tốt nhất, hay bạn đã... vì hầu hết các hệ thống bộ nhớ bạn làm việc nhiều hơn về việc lọc ra như episodic memory hoặc những thứ khác, và đây thực sự là một hệ thống tính điểm rất tốt. Đó là câu hỏi đầu tiên, liệu nó cũng giống với Unblock không? Câu hỏi thứ hai, bạn đã đề cập rằng nó hoạt động với các nhóm trong môi trường Microsoft. Tôi tự hỏi bạn đã quan sát thấy những khác biệt nào giữa việc xây dựng biểu đồ xã hội cho các môi trường khác nhau, bởi vì trên GitHub tôi hình dung nó rất khác so với trên SharePoint, Teams, v.v. Nó cũng dựa trên các số liệu thống kê mạng này hay có điều gì khác biệt?

Diễn giả: Ờm, vậy thì, triển khai đầu tiên của chúng tôi vô cùng ngây thơ, đúng không? Nó chỉ sử dụng số lượng đóng góp PR và so sánh trực tiếp với số lượng PR được xem xét bởi mỗi người, chỉ là một trò chơi số liệu đơn giản. Với cách đó, nó không tạo ra các cụm nhóm chính xác. Vì vậy, sau đó chúng tôi chuyển sang các thuật toán mà bạn thấy ở đây. Unblock làm được nhiều hơn thế này một chút. Vì vậy, đây chỉ là một giải pháp trung gian. Một chiến lược khác mà Unblock sử dụng là các chuyên gia theo cụm véc-tơ. Khi chúng tôi nạp mã nguồn và chuyển thành véc-tơ, chúng tôi hiểu ai là những người đóng góp nhiều nhất cho phần mã nguồn đó. Vì vậy, khi chúng tôi tìm kiếm từng cá nhân, chúng tôi có thể thấy họ đã làm gì và các cụm lân cận là gì, sau đó liên kết mọi người dựa trên sự gần gũi của cụm của họ. Đó là một cách tiếp cận kiểu ML hơn. Và sau đó có một lớp cuối cùng, đó là một lớp nặng về AI LLM thực hiện việc chắt lọc một loạt các yếu tố ngữ cảnh khác nhau, những thứ mà mọi người đã làm trong quá khứ, các cuộc trò chuyện họ đã có trên Slack. Và sau đó, khi bạn lấy tất cả những điều đó và cân nhắc nó dựa trên biểu đồ được tạo theo thủ tục, bạn sẽ có được một sự chắt lọc chính xác hơn nhiều. Ở đây, bạn sẽ nhận thấy một số người sẽ được kéo vào các cụm nhóm mà bạn biết là hoạt động trên nhiều nhóm khác nhau chẳng hạn, và điều này sẽ không tính đến sự khác biệt đó.

Người tham gia: Các thuật toán khác nhau, hãy nói rằng bạn, tôi không muốn...

Diễn giả: Không, thuật toán này hoàn toàn dựa trên SCM. Vì vậy, các thuật toán cho các nhóm Slack thực sự khác biệt đáng kể vì bạn không có những điểm xem xét này. Vì vậy, sau đó nó trở thành việc ai là người hoạt động tích cực nhất trong các kênh cụ thể và sau đó bạn cần một sự chắt lọc hoặc tóm tắt về kênh đó, và bạn cần chuyển nó thành véc-tơ và sau đó tính điểm nó so với những người đóng góp thường xuyên nhất. Ờm, nhưng điều đó là chưa đủ. Bạn phải liên hệ điều đó trở lại với dữ liệu SCM để tìm ra ai là chuyên gia thực sự. Một trong những vấn đề tôi đã đích thân trải nghiệm trong một số tổ chức tôi từng làm việc là bạn gặp phải những kỹ sư cấp dưới ồn ào, đúng không? Họ rất ồn ào, họ thích nói chuyện, nhưng tỷ lệ tín hiệu trên nhiễu không cao. Và chỉ vì ai đó không nói nhiều điều không có nghĩa là tin nhắn của họ không có tác động. Vì vậy, một phần của trò chơi này là về việc đánh giá tác động của việc khi mọi người nói điều gì đó, thì điều đó liên quan như thế nào đến các PR được tạo ra sau đó? Bao nhiêu trong số các PR đó được hợp nhất? Đại loại thế.

Sự cố quyền truy cập và chấp thuận PR

Người tham gia: Vâng.

Diễn giả: Ồ, không có ư?

Người tham gia: Phải có chứ. Được rồi, kiểm tra lại.

Người tham gia: Chà, bạn phải có khả năng mở một pull request. Bạn không thể push lên main.

Diễn giả: Được rồi.

Người tham gia: Vậy thì, nếu đó là tình huống... nhưng ý tôi là, chúng tôi sẽ kiểm tra.

Diễn giả: Vâng, bạn phải có khả năng tạo một nhánh.

Người tham gia: Ồ, ờ, không. Không. Anh ấy không thể fork repo được.

Diễn giả: Ồ. Ờm, vâng, forks có thể bị tắt. Cái này sẽ là mã nguồn mở vào cuối tuần này. Ờm, và tất cả đóng góp của bạn sẽ có trên đó. Điều thực sự thú vị là sử dụng công cụ biểu đồ xã hội đó sau này với repo của riêng bạn và cho nhóm của bạn xem.

Người tham gia: Vâng.

Người tham gia: Ồ, xin lỗi.

Người tham gia: Ồ, tôi sẽ đến. Tôi thích điều đó. Unblock đã cố gắng trả lời bạn cho câu hỏi đó.

Diễn giả: Ồ, bạn thấy cái phản hồi tự động của Slack không? Xin lỗi. Bạn có ở đây không? Đó là một camera. Xin lỗi.

Người tham gia: Ồ, không sao đâu. Tôi chỉ... Ồ, được rồi. Ờm, để tôi kiểm tra xem. Điều đó không nên xảy ra. Được rồi. Cho tôi biết nếu bạn vẫn cần lời mời GitHub.

Diễn giả: Chỉ cần kiểm tra các thành viên. Tôi nghĩ có thể có... Vâng, có thể có vấn đề ở đây. Khoảnh khắc. Ồ, đây là các phân công trực tiếp. Vì vậy, tôi nghĩ chúng ta phải đưa mọi người vào toàn bộ dự án vì họ không được chỉ định cho org.

Người tham gia: Ồ, GitHub, tôi yêu bạn.

Người tham gia: 09s of uptime.

Diễn giả: Vâng, chúng tôi sẽ sửa cái này ở đây. Vâng, đưa tất cả mọi người vào. Nào.

Người tham gia: Bạn đã hoàn tất rồi. Tôi đang cố gắng vì bây giờ chúng ta chỉ cần thêm người.

Diễn giả: Vào cài đặt, cộng tác viên. Unblock. Tất cả các bạn đều có quyền ghi. Đó là tên công ty.

Người tham gia: Vui lòng xác thực điều đó giúp chúng tôi.

Diễn giả: Vâng, vui lòng cho tôi biết.

Người tham gia: Hoàn hảo.

Diễn giả: Được rồi. Được rồi, chúng ta đang nhận được các PR thực sự rồi. Tuyệt vời. Tuyệt vời.

Người tham gia: Tuyệt vời. Bây giờ chúng ta hãy làm những điều thú vị. Được rồi, tuyệt. Đối với tôi thì ổn.

Người tham gia: Gì cơ?

Diễn giả: Tôi nghĩ chúng ta đã có PR đầu tiên được chấp thuận. Tôi đang gửi các cuộc trò chuyện ngớ ngẩn đến Unblock để bạn có thể thấy nó cố gắng trả lời các câu hỏi trong Slack khi các PR xuất hiện. Tôi sẽ xem nó nói gì về điều này.

Người tham gia: Yêu cầu nó...

Người tham gia: Nó như kiểu "Ồ, để tôi nghĩ xem."

Người tham gia: Ồ, bạn đã hỏi nó về PR à?

Diễn giả: Vâng, nhưng PR tôi nghĩ bạn đã chấp nhận. Vậy chúng ta sẽ xem điều gì xảy ra.

Diễn giả: Vâng, ý tôi là nó đã chấp thuận. Vì vậy, bạn biết đấy, Unblock đã...

Diễn giả: Unblock như kiểu "cái này ổn đối với tôi, anh bạn." Unblock đã bị lỗi.

Diễn giả: Chỉ hiển thị cho bạn. Ồ không.

Người tham gia: Nhưng đó là một câu trả lời hay mà.

Người tham gia: PR đẹp. Unblock làm tốt lắm. Câu trả lời tuyệt vời.

Diễn giả: Vâng. Ồ, vâng. Vâng. Tôi sẽ đưa nó lên lại. Tôi sẽ đưa nó lên lại. Một giây.

Diễn giả: Ờ, nó đi đâu rồi? Thực ra, tôi đã mất... ở đây.

Người tham gia: Ồ, vâng. Xử lý các nguồn hoặc có thể là điều gì đó.

Diễn giả: Bạn có muốn ứng dụng không?

Người tham gia: Vâng, chắc chắn rồi.

Đóng góp vào Dự án và Trình diễn Giá trị của Unblock

Vâng. Ồ, đúng vậy. Vâng. Tất nhiên. Chúng tôi đang tập trung vào việc bạn xây dựng, nhưng... Tôi phải làm gì đây? Ồ không, không sao. Ý tôi là, cứ thế đi. Ồ. Ồ, tôi xin lỗi. Vậy thì, cái... cái thứ tôi đã trình bày trước đây, đó là dự án tồn tại trong kho lưu trữ (repo) đó. À, vậy ý tưởng là hãy suy nghĩ về các tính năng bạn muốn thêm hoặc những thứ bạn muốn sửa, hoặc các thành phần mới, sau đó cứ thoải mái lập trình và gửi một PR (Pull Request). Xin lỗi. Vâng, lỗi của tôi.

Bạn có muốn mở một phiên làm việc trên terminal và trình diễn MCP không? Ồ, chắc chắn rồi. Vâng, bởi vì mọi người rõ ràng có thể sử dụng nó nhưng họ không có toàn bộ mã nguồn của chúng tôi. Một nhà tư vấn muốn thử đề xuất nó cho một khách hàng. Tôi không thể trình bày ngữ cảnh hoặc có thể có một ý tưởng. Chà, ý tôi là, một điều bạn có thể làm khi đến thăm khách hàng là bạn có thể hỏi họ xem họ có chạy công cụ trên kho lưu trữ của họ hay không, và sau đó nó sẽ tạo ra kết quả này cho họ để họ có thể tự mình thấy giá trị trên dự án của chính họ. Đúng chứ?

Tôi nghĩ Peter, anh ấy chỉ hỏi về sản phẩm của chúng ta cụ thể, không phải cái này. Ồ, Unblock. Bạn đang hỏi về Unblock. Lỗi của tôi, anh bạn. Chúng ta đang đi theo hướng này. Xin lỗi. Xin lỗi, chỉ nghĩ một chiều thôi. Được rồi. Vậy câu hỏi của bạn là làm thế nào để bạn có thể trình bày giá trị của Unblock cho khách hàng, hay là nhìn thấy giá trị? Vâng, xin lỗi.

Trình diễn Unblock và Trải nghiệm Người dùng

Vâng, bạn có thể tạo ra các xung đột trong ứng dụng của mình, nhưng... và sau đó có lớp tuân thủ, điều này rất thú vị đối với các khách hàng doanh nghiệp. Tôi đang nghĩ làm thế nào điều này được chuyển đổi thành trải nghiệm người dùng (UX), bởi vì bạn biết đấy, nhiều người biết... tôi hiểu rằng nó chủ yếu dành cho việc mã hóa. Vâng.

Và liệu điều này có phải dành cho những người có chuyên môn kỹ thuật hay có thể là những người giám sát một số kỹ sư, hoặc chính kỹ sư đó? Ý tôi là, chỉ cần xem nền tảng của bạn hoạt động như thế nào. Nhưng nếu nó nằm ngoài ngữ cảnh thì... tôi nghĩ không sao cả. Không, không, hoàn toàn ổn. Vì vậy, bảng điều khiển này giống như... cái giao diện khách hàng ở front-end của sản phẩm. Bạn biết đấy, bạn vào đây và có thể hỏi bất kỳ câu hỏi nào về cơ sở mã của mình hoặc tổ chức của bạn và nhận được câu trả lời ở đây. Hiện tại, điều này đang được... xin lỗi tôi làm mất con trỏ rồi. Điều này đang được đính kèm vào... cái bài kiểm tra này hoặc cái chúng ta có, nhưng tôi có thể sử dụng nó với Unblock và tôi có thể nói rằng... bạn biết đấy, tôi có một thứ nổi bật nhỏ ở đây mà tôi có thể trình diễn. Ối!

Source mark engine là một thành phần nội bộ mà chúng tôi sử dụng để theo dõi các thay đổi mã nguồn theo thời gian, bao gồm cả việc các thay đổi di chuyển giữa các tệp và vân vân. Vì vậy, như một buổi trình diễn, bạn có thể giới thiệu, ý tôi là, bạn có thể đặt lịch cho khách hàng của mình tham gia buổi demo với chúng tôi và chúng tôi có thể trình diễn điều này, hoặc bạn có thể kết nối nó với tổ chức của riêng mình và trình diễn workflow này cho khách hàng, và cố gắng tìm các trường hợp sử dụng mà các nguồn dữ liệu xung đột và trình diễn rằng thách thức với các context engine là rất khó để trình diễn giá trị cho ai đó mà không thực sự kết nối nó. Vì vậy, có một chút chi phí ban đầu ở đó khi mọi người phải kết nối nó với tất cả các integration của họ. Điều tốt là Unblock có một giai đoạn dùng thử doanh nghiệp miễn phí, vì vậy mọi người có thể dùng thử sản phẩm ở dạng đầy đủ nhất trước khi trả tiền. Vâng.

Cơ chế Phản hồi và Biểu đồ Chuyên gia (Experts Graph)

Vậy nếu một số thông tin đó không chính xác, bạn có thể chỉ cần trả lời trong chatbot hoặc gắn cờ nó trong các tham chiếu. Chính xác. Vâng. Bạn có thể trả lời ở đây hoặc bạn có thể nói "không hữu ích" và giải thích lý do, và sau đó nó sẽ chắt lọc cho vòng tiếp theo. Vậy nó sẽ điều chỉnh một số trọng số (weights) hoặc điểm tin cậy (confidence scores) nội bộ? À, nội bộ thì nó sẽ xây dựng task memory.

Vì vậy, nó tìm kiếm những loại tín hiệu lặp lại đó và đây chính là lúc experts graph phát huy tác dụng. Nó được sử dụng rất nhiều. Experts graph cung cấp các trọng số. Vì vậy, khi một chuyên gia đến và nói điều đó không đúng, nó sẽ nhận được thêm trọng số và chắt lọc một bộ nhớ cho điều đó. Nếu đó chỉ là một kỹ sư mới nói điều đó không đúng, thì đó chưa phải là một nguồn đáng tin cậy. Vì vậy, bạn phải có một nguồn đáng tin cậy để dựa vào. Điều đó có ý nghĩa không? Vâng, rất có ý nghĩa. Giống như một mạng xã hội vậy. Chính xác. Bằng cách nào đó. Vâng. Vâng. Cảm ơn. Không có gì. Tuyệt.

Kiến trúc Nền tảng và Khởi tạo Bộ nhớ (Memory Hydration)

Ồ, dưới lớp vỏ. Ừm, khi nó được trình bày cho AI, nó được trình bày dưới dạng các tệp. Nhưng dưới lớp vỏ, chúng tôi lưu trữ nó trong các bảng cơ sở dữ liệu và những thứ tương tự. Các bộ nhớ được hình thành từ một loạt các nguồn khác nhau. Vì vậy, chúng không chỉ dựa trên các tệp phẳng, bạn biết đấy, toàn bộ cấu trúc bộ nhớ sẽ được "thủy hóa" (hydrated) tại thời gian chạy (runtime). Vậy bạn sẽ chỉ cung cấp công cụ của mình cho cơ sở dữ liệu dựa trên bất kỳ tiêu chí nào của người dùng? Vâng. Đối với... vâng. Vì vậy, có, có rất nhiều công cụ để truy xuất dữ liệu. Đặc biệt đối với bộ nhớ, bạn không thể thực sự giao cho tác nhân thực hiện memory hydration bởi vì đó là một phần của context khởi tạo (seed context). Để tác nhân đi đúng hướng, bạn phải khởi tạo nó với dữ liệu thích hợp và experts context là một điểm khởi đầu tốt cho tác nhân. Vậy đó. Đúng vậy.

Các Điểm Chuẩn và Hiệu suất

Có điểm chuẩn chính thức nào đó theo dõi loại giá trị mà bạn đang cố gắng mang lại không? Bởi vì tôi cảm thấy nó không hoàn toàn là mã hóa, hoặc có thể là vậy, nhưng tôi tò mò liệu có bất kỳ điều gì công khai mà bạn đang tự mình theo dõi để so sánh không.

Vậy chúng tôi có một số điểm chuẩn nội bộ. Bạn nói đúng, nó hơi khó định lượng. Ừm, vậy Anthropic... bạn đã nghe Boris Churnney nói chuyện tại Claude Code chưa? Anh ấy là người tạo ra Claude Code. Người tạo ra Claude Code. Vâng. Vậy thì anh ấy đã thực hiện một cuộc phỏng vấn, nơi họ nói về cách họ đo lường thành công cho Claude Code nội bộ. Điều này có thể đã thay đổi vì hiện tại họ có rất nhiều điểm chuẩn, như talk benchmark chẳng hạn. Chắc các bạn đã thấy cái đó rồi. Nhưng điều thực sự chắt lọc xuống là "cảm nhận" (vibes). Vì vậy, điều quan trọng nhất trong các hệ thống AI như thế này là nắm bắt sentiment. Và nếu sentiment của bạn đang có xu hướng tăng lên thì đó là một điều tốt. Sentiment của chúng tôi hiện tại, trên thang điểm từ -100 đến 100, là khoảng 60 điểm. Vậy trên thang điểm chuẩn hóa thì nó khoảng 0.75 đến 0.8. Vậy thì, "cảm nhận" sẽ được ghi nhận bằng những thứ như ít tranh luận qua lại hơn trên các PR hoặc có thể, tôi không biết, bạn ít phải trao đổi qua lại để hoàn thành công việc của mình.

Vâng. Vậy thì các "cảm nhận" là về việc mọi người có hài lòng không, đúng không? Sự hài lòng có thể đến từ nhiều nguồn khác nhau và sự không hài lòng cũng vậy. Vì vậy, cách nghĩ về điều đó là nó mã hóa tất cả những điều đó. Ừm, nhưng bạn có thể nắm bắt các số liệu cụ thể, và chúng tôi đang làm điều đó, về thời gian hoàn thành công việc, và chúng tôi thực sự đang làm việc rất chăm chỉ để giảm thời gian phản hồi, bởi vì, bạn biết đấy, mặc dù các tác nhân... đây là điều thú vị, khi chúng ta hướng tới một vũ trụ tự động hơn, thời gian phản hồi của máy chủ MCP thực sự ngày càng ít quan trọng hơn. Điều quan trọng hơn là chúng phải đưa ra câu trả lời hoàn toàn chính xác. Vâng.

Thời gian Thu thập Ngữ cảnh so với Thực thi Tác vụ và Chi phí Mã Thông Báo

Và lý do là bởi vì, lượng thời gian mà một context engine dành để thu thập tất cả thông tin đó và chắt lọc nó là một vi mô của những gì toàn bộ tác vụ cần để triển khai và thực hiện. Vì vậy, nếu bạn có thể dành thêm một chút thời gian và cắt giảm việc triển khai xuống khoảng 60, 70, 80% thì đó là một chiến thắng lớn, đúng không? Cứ tiếp tục đi. Xin lỗi, một câu hỏi nhỏ tiếp theo. Thực ra, tôi tò mò. Bạn có bất kỳ con số ước tính nào về lượng thời gian nó dành để truy xuất ngữ cảnh so với thực thi tác vụ không? Chẳng hạn như hiện tại là 10%, 90% hay tôi không biết? Ý tôi là, tôi có kinh nghiệm của riêng mình.

Vâng, việc thu thập ngữ cảnh tác nhân có lẽ gần với con số đó. Khoảng 90%. Còn phần viết mã thực tế thì cực kỳ nhanh. Nếu bạn có thể chỉ cần quan sát tác nhân đang làm gì. Khi nó viết mã, các mã thông báo đầu ra (output tokens) mới là thứ kéo hiệu suất xuống. Mọi người từng nghĩ đó là mã thông báo đầu vào (input tokens). Chúng tôi đã thực hiện rất nhiều thử nghiệm với điều này. Bạn có thể tăng kích thước mã thông báo đầu vào và thời gian để có mã thông báo đầu ra đầu tiên hiện nay khá tốt, được tối ưu hóa cao. Điều thực sự ảnh hưởng đến hiệu suất là mã thông báo đầu ra. Vì vậy, bạn phải thận trọng với cách bạn thu thập và cung cấp ngữ cảnh trở lại cho tác nhân để nó duy trì chặt chẽ các vòng lặp đầu ra của nó.

Ví dụ Thực tế và Giảm thiểu Mã Thông Báo

Đối với một điểm chuẩn mà Peter đã đề cập trong buổi nói chuyện, chúng tôi đã đưa ra một tác vụ đầy tham vọng bởi vì rõ ràng nó phụ thuộc vào lời nhắc về lượng thời gian bạn thêm vào và với một context engine. Nhưng tác vụ đầy tham vọng mà chúng tôi đưa ra là triển khai chế độ tư duy thích ứng mới trong bộ công cụ của Anthropic khi họ giới thiệu nó, mà như đã đề cập, nó đã giảm từ 25 phút thời gian thực (wall clock time) xuống, với Unblock và một context engine. Trường hợp còn lại, không có Unblock, là 2,5 giờ. Chính xác là 2 giờ 25 phút. Nhưng lý do chính cho điều đó là chúng tôi đã cung cấp tất cả dữ liệu. Chúng tôi chạy lời nhắc và sau đó đầu ra đầu tiên của nó hoàn toàn sai. Vì vậy, con người phải lặp lại và nói "không, không, không, cái này, cái này, cái này" và đầu ra tiếp theo sai, rồi đầu ra tiếp theo cũng sai. Vì vậy, một khi bạn thực hiện bốn vòng lặp, bạn sẽ mất khoảng 2,5 giờ thời gian thực so với rõ ràng là 25 phút khi không cần bất kỳ sửa chữa nào.

Vì vậy, như đã đề cập, hãy nghĩ nó như một thác nước. Bạn càng có nhiều ngữ cảnh chất lượng cao, chính xác, tín hiệu tốt ngay từ đầu, thì mọi thứ mà tác nhân sẽ làm cho đến khi nó báo hoàn thành, dù đúng hay sai, đều tốt hơn. Vâng. Hiểu rồi.

Bạn cũng đề cập rằng việc sử dụng mã thông báo cho các API call và tìm kiếm thông tin thực sự đã giảm. Tôi biết rằng nhiều công cụ hoặc aggregator cho tool use có mức sử dụng mã thông báo rất lớn. Vậy có thể có một số ước tính về việc ví dụ như tôi cần một bản tóm tắt cuộc trò chuyện Slack từ cuộc trò chuyện này sang cuộc trò chuyện khác, hoặc cách mọi người tương tác ở đó sẽ là khoảng 60.000 mã thông báo trên Composio. Tôi tự hỏi sẽ mất bao nhiêu mã thông báo khi sử dụng Unblock. Vâng, thấp hơn. Chúng tôi vẫn còn dựa nhiều vào "cảm nhận" ở đó, vì rất khó để có được dữ liệu thực tế từ các khách hàng hoặc những người khác trên thị trường. Nhưng một lần nữa, với cùng tác vụ mà tôi vẫn đang nói đến. Tác vụ đó đã giảm từ tổng mức sử dụng 21 triệu mã thông báo xuống còn 10 triệu mã thông báo với context engine. Một phần lý do là vì bạn không phải rơi vào vòng lặp sai sót (doom loop).

Vậy thì, dĩ nhiên, điều đó đã làm tăng đáng kể chi phí mã thông báo. Vì vậy, chúng tôi đã giảm 50% cho một tác vụ lớn. Rõ ràng, nếu bạn chỉ muốn căn giữa một div, bạn sẽ không nhận được nhiều lợi ích. Nó có lẽ đã có trong dữ liệu huấn luyện. Nhưng vâng, giống như bất kỳ tính năng sửa lỗi nào khác. Rất nhiều thứ mà mọi người đang thực hiện thông qua Unblock là những gì một kỹ sư làm hàng ngày. Rất hiếm khi bạn thực hiện một tác vụ nhỏ đến mức... ý tôi là, tôi đã yêu cầu Claude thực hiện git push, vì vậy tôi cá là tôi không phải người duy nhất. Tôi đã nghĩ "bạn làm đi." Rồi tôi lại tự hỏi "Tại sao cái đó lại tốn của mình 30 cent nhỉ?" Tôi không biết. Vâng, tôi đã nỗ lực hết sức để đặt các GPG keys của mình đúng chỗ, vì vậy tôi nghĩ "Claude, tiến lên." Còn câu hỏi nào nữa không trong khi các bạn vận chuyển? Có nhầm lẫn gì không? Có điều gì tôi có thể "mở khóa" cho các bạn không? Đó là mục đích sống của tôi.

Tần suất cập nhật dữ liệu và RAG

Khách mời: Xin lỗi, có thể bạn đã trả lời câu hỏi này rồi, nhưng liệu bạn có đang sử dụng RAG dựa trên tri thức trong Unblocked hay công nghệ cụ thể nào mà bạn đang khai thác?

Diễn giả: Ồ, rất nhiều thứ. Tôi có thể nói chuyện với bạn sau. Tôi sẽ tháo mic. Tôi sẽ chỉ trả lời câu hỏi đó thôi.

Khách mời: Chắc chắn rồi.

Diễn giả: Đó chỉ là...

Khách mời: Đúng vậy.

Diễn giả: À, về cơ bản là thời gian thực. Vì vậy, có lẽ có hai phần cho câu hỏi đó. Một là Unblocked cập nhật dữ liệu ở phần phụ trợ nhiều hay thường xuyên đến mức nào. Vì vậy, nó là thời gian thực cho nhiều integration và sau đó là một cron job cho những cái khác, bởi vì đối với những integration cụ thể đó, chúng không có web hook.

Xây dựng lại dữ liệu đồ thị

Khách mời: Đúng vậy. Nhưng điều đó có nghĩa là việc xây dựng lại dữ liệu đồ thị phải diễn ra rất thường xuyên. Đúng vậy.

Diễn giả: Đúng vậy. Không, nó là tăng dần. Vì vậy, thuật toán xây dựng đồ thị xã hội của chúng tôi có một thành phần tăng dần. Chúng tôi không phải chạy lại toàn bộ. Nhưng đồ thị xã hội cũng ít nhạy cảm với những thay đổi dữ liệu thường xuyên hơn vì không chắc rằng một thay đổi duy nhất sẽ tạo ra tác động lớn đến đồ thị chuyên gia, trừ khi tổ chức của bạn là hoàn toàn mới. Vậy thì...

Khách mời: Đúng vậy.

Diễn giả: Đúng vậy. Ví dụ, chúng tôi chắt lọc các best practices với tần suất thấp hơn nhiều, về cơ bản là hàng tuần, vì nó không thay đổi nhiều.

Quyền riêng tư của khách hàng và lưu giữ dữ liệu

Diễn giả: Đúng vậy. À, vâng. Hãy nhắc lại câu hỏi của bạn. Đó là một câu hỏi hay. Tôi muốn đảm bảo chúng ta ghi nhớ nó. Ồ...

Khách mời: ... về quyền riêng tư của khách hàng, việc lưu giữ dữ liệu, kiểu như...

Diễn giả: ... đúng vậy, từ quan điểm của tôi, tôi đang nghĩ về các triển khai enterprise SaaS hoặc thậm chí là on-premise, tôi không gợi ý rằng bạn, tôi chỉ đang nghĩ về mô hình khách hàng đó. Ừm...

Khách mời: ... bạn có gặp phải sự phản đối không? Họ cảm thấy thế nào khi bạn lưu giữ dữ liệu? Đó là một bộ xử lý khác trong vòng lặp.

Diễn giả: À, các cuộc thảo luận về quyền riêng tư diễn ra ở cấp độ tổ chức. Vì vậy, chúng tôi không thực sự gặp nhiều trở ngại. Chắc chắn có những môi trường như trong chính phủ và các ngân hàng có những nhu cầu siêu nhạy cảm, và đối với những nhu cầu đó, chúng tôi có một giải pháp on-prem nhưng chắc chắn đó không phải là con đường tôi khuyến nghị, như việc duy trì dựa trên Claude. Chúng tôi có các tổ chức enterprise rất lớn hoàn toàn dựa trên Claude, tức là hoàn toàn trên Claude. Bí quyết không còn được mã hóa nhiều trong cơ sở mã nữa mà được mã hóa nhiều hơn trong reasoning. Vì vậy, các tổ chức có xu hướng nhạy cảm hơn một chút về những thứ như dữ liệu Slack chẳng hạn, nhưng cách chúng tôi lưu trữ dữ liệu, chúng tôi có một tài liệu white paper về cách chúng tôi bảo vệ dữ liệu khách hàng, và điều đó chưa bao giờ là vấn đề.

Triển khai On-premise

Khách mời: Đúng vậy. Xin lỗi, bạn có thể chạy on-prem không?

Diễn giả: Vâng, chúng tôi có giải pháp on-prem, nhưng như tôi đã nói, đó không phải là phương pháp được khuyến nghị, nhưng đối với các môi trường nhạy cảm thì chắc chắn là có. Đúng vậy.

Khách mời: Ồ, tại sao nó không được khuyến nghị?

Diễn giả: À, các integration dựa trên Claude được cập nhật thường xuyên hơn nên có các bản vá phần mềm. Việc bảo trì trong một tổ chức khó hơn một chút. Có một khách hàng là ngân hàng, việc quản trị nền tảng trở nên khá khó khăn vì họ có sự cô lập mạng, và vì vậy, một trong chúng tôi phải ngồi trong mạng đó để quản trị nền tảng hoặc chúng tôi phải đào tạo các cá nhân trong công ty để quản trị nền tảng. Vì vậy, đó chỉ là một bài tập bảo trì và hướng dẫn. Nhưng đúng vậy.

Khách mời: Đúng vậy, chính xác. Hoàn toàn đúng.

Diễn giả: Vâng. Cảm ơn bạn. Cảm ơn vì đã đến rất nhiều.