Demand-Driven Context: A Methodology for Coherent Knowledge Bases Through Agent Failure

• Dù AI có khả năng vượt trội trong việc tạo mã và lập luận, doanh nghiệp vẫn gặp khó khăn trong việc chuyển đổi tiềm năng này thành giá trị kinh doanh thực tế, với chỉ 6% giá trị được tạo ra từ 88% công ty sử dụng AI.
• Thách thức lớn nhất là AI không thể hiệu quả với "kiến thức chuyên sâu của tổ chức" (institutional knowledge) vốn thường lỗi thời, không đáng tin cậy, trùng lặp hoặc chỉ tồn tại dưới dạng "kiến thức truyền miệng" (tribal knowledge).
• Giải pháp được đề xuất là "Ngữ cảnh theo hướng yêu cầu" (Demand-Driven Context), một phương pháp tiếp cận "kéo" tương tự như TDD, trong đó tác nhân AI học hỏi dần dần bằng cách thất bại, yêu cầu kiến thức, được con người bổ sung, và sau đó tự quản lý, tài liệu hóa kiến thức đó để phá vỡ cơ sở tri thức nguyên khối.

• Nhận diện vấn đề cốt lõi của AI trong doanh nghiệp: AI gặp khó khăn nghiêm trọng với "kiến thức chuyên sâu của tổ chức" (institutional knowledge), dẫn đến việc không thể hoàn thành các nhiệm vụ kinh doanh và tạo ra giá trị rõ ràng (ví dụ: các Jira ticket không di chuyển).
• Hiểu rõ hạn chế của RAGs và Đồ thị Tri thức: Các lớp truy xuất như RAGs chỉ đạt khoảng 40% độ chính xác với cơ sở kiến thức được ghi lại và thường tạo ra đầu ra không đáng tin cậy, đặc biệt khi kiến thức tổ chức bị phân mảnh, lỗi thời hoặc không được ghi chép.
• Chuyển đổi từ chiến lược "đẩy" sang "kéo" trong quản lý kiến thức AI: Thay vì cố gắng "đẩy" toàn bộ kiến thức cho tác nhân, hãy áp dụng phương pháp "kéo" (pull approach), để tác nhân tự truy xuất thông tin khi cần thiết, giống như cách một nhân viên mới học hỏi.
• Thực hiện vòng lặp học hỏi và quản lý kiến thức cho tác nhân: Giao các "hạng mục công việc" mà tác nhân có thể thất bại. Khi tác nhân không thành công, chúng sẽ liệt kê các yêu cầu kiến thức còn thiếu, con người sẽ cung cấp, và tác nhân sau đó sẽ tự cập nhật, quản lý kiến thức mới này vào một cơ sở dữ liệu được cấu trúc tốt hơn.
• Chia nhỏ cơ sở tri thức nguyên khối: Coi "cơ sở tri thức dạng monolith" của tổ chức như một hệ thống legacy cần được chuyển đổi thành "microservices" kiến thức, chia thành các khối ngữ cảnh nhỏ, hữu ích và có thể tái sử dụng cho tác nhân.
• Đầu tư vào việc tài liệu hóa kiến thức truyền miệng: Ưu tiên biến "kiến thức truyền miệng" (tribal knowledge) không được ghi chép thành các tài liệu rõ ràng, có cấu trúc để tác nhân có thể truy cập và học hỏi, đây là phần lớn kiến thức còn thiếu của AI.
• Áp dụng phương pháp tiếp cận TDD cho quản lý kiến thức: Tương tự như Phát triển hướng kiểm thử (TDD), giao các vấn đề mà tác nhân chắc chắn sẽ thất bại để lộ ra các "lỗ hổng" kiến thức, sau đó lấp đầy chúng một cách có hệ thống để dần dần xây dựng khả năng tự động hóa của tác nhân.
• Triển khai phương pháp trên các nền tảng tác nhân hiện có: "Ngữ cảnh theo hướng yêu cầu" là một phương pháp luận linh hoạt có thể được áp dụng trên nhiều hệ thống tác nhân và nền tảng điện toán đám mây khác nhau (ví dụ: Copilot, Claude Code), tập trung vào kỹ năng, quy tắc và cơ sở tri thức.

• workshop — hội thảo
• AI — Trí tuệ nhân tạo
• tác nhân — agent (AI agent)
• ngữ cảnh — context
• quản lý ngữ cảnh — context management
• code generation — tạo mã nguồn
• kiến thức chuyên sâu của tổ chức — institutional knowledge
• kiến thức chuyên môn — domain knowledge
• prompt engineering — kỹ thuật lời nhắc
• RAGs (Retrieval Augmented Generation) — Tạo sinh tăng cường truy xuất
• Mô hình Ngôn ngữ Lớn — Large Language Model (LLM)
• lợi tức đầu tư — return on investment (ROI)
• đồ thị tri thức — knowledge graphs
• kiến thức truyền miệng — tribal knowledge
• cơ sở tri thức dạng monolith — monolithic knowledge base
• microservices — vi dịch vụ
• demand-driven context — ngữ cảnh theo hướng yêu cầu
• pull approach — phương pháp tiếp cận dựa trên "kéo"
• TDD (Test-Driven Development) — Phát triển hướng kiểm thử
• hạng mục công việc — work item
• tài liệu hóa — document (as a verb)
• phân tích nguyên nhân gốc — root cause analysis

Xin cảm ơn. Có lẽ chúng ta có thể bắt đầu. Trước hết, xin chân thành cảm ơn tất cả quý vị đã đến tham dự buổi workshop, đặc biệt là những người không có chỗ ngồi. Tôi hứa sẽ cố gắng hết sức để buổi chia sẻ này trở nên thú vị, đặc biệt là với các bạn đang theo học. Xin cảm ơn rất nhiều.

>> Vâng. Thật ra, điều này có lý. Bây giờ tôi đã hiểu tại sao vé lại bán hết nhanh đến vậy. Buổi workshop nào thực sự đã cháy vé nhỉ? Vâng, hãy bắt đầu với phần giới thiệu của tôi. Tôi là Raj. Tôi làm Kỹ sư Phần mềm cấp cao tại IKEA, thuộc bộ phận deliverance services. Về cơ bản, chúng tôi có hơn 100 kỹ sư và sáu nhóm pedex cùng nhau. Nó giống như một công ty nhỏ trong lòng công ty vậy. Tôi rất quan tâm đến kiến trúc, khoa học thần kinh và ngôn ngữ học, và giờ là AI. Vì vậy, nếu ai có những dự án thú vị nào – bởi vì ngày nay ai cũng đang xây dựng những dự án hay ho – xin hãy tìm tôi sau buổi gặp mặt này.

Kiểm tra nhanh mức độ quan tâm của khán giả: Ai lần đầu tiên đến London? Tuyệt vời, chào mừng đến London. Ai ở đây có nền tảng kỹ thuật, cũng như kinh nghiệm coding và prototyping?

>> Không, tất cả đều...

Vậy, ai đang tích cực sử dụng các tác nhân như Co-pilot? Ồ, vậy thì điều này sẽ khá khó cho tôi đây. Các extension thì sao? Vậy là mọi người đều chuyên nghiệp rồi. Tốt thôi.

>> Không nhiều như tôi muốn.

Chà, căng thẳng thật. Các bạn sẽ ngồi đây trong căn phòng nóng nực này hơn một giờ đồng hồ. Đầu tiên, tôi sẽ giới thiệu sơ qua về những gì tôi sẽ trình bày hôm nay. Về cơ bản, nó xoay quanh tác nhân và quản lý ngữ cảnh. Tôi đã chia thành ba phần. Phần một là Tình hình chung, tất cả các bạn đều đã biết rồi, nên tôi sẽ nói ngắn gọn trong khoảng năm phút. Sau đó, tôi sẽ nói về Vấn đề. Đây là phần tôi sẽ dành nhiều thời gian hơn trên các slide, vì tôi nghĩ rằng thực sự không ai đang nghiêm túc nhìn nhận vấn đề. Tôi muốn đưa vấn đề này ra. Sau đó, sẽ ít slide hơn và đi sâu hơn vào phần thực hành, về cách ngữ cảnh theo hướng yêu cầu (demand-driven context) thực sự hoạt động. Mọi thứ ổn chứ?

Giới thiệu về Tác nhân và Quản lý Ngữ cảnh

Vậy, hãy bắt đầu với phần đầu tiên. Bao nhiêu người đã xem bộ phim Memento này?

>> Được, được, được. Tuyệt vời.

Tôi sẽ tóm tắt nội dung chính của bộ phim. Anh chàng này rất giỏi, rất tài năng. Vấn đề duy nhất của anh ta là không thể giữ ký ức quá 15 phút. Cứ sau mỗi 15 phút, anh ta phải lấy cuốn sổ của mình, nhìn vào những hình xăm trên cơ thể để tìm hiểu xem mình đã làm gì trước đó 15 phút và anh ta cứ lặp lại điều đó. Nếu bạn liên hệ điều này với AI và các tác nhân AI, nó thực sự khớp chính xác với bộ phim và cách các tác nhân đang hoạt động hiện nay. Nếu bạn xem bộ phim này, bạn không cần phải xem YouTube hay đọc blog để hiểu về tác nhân và MCP. Bộ phim này thực sự kể cho bạn mọi thứ theo đúng nghĩa đen.

Và cũng như anh chàng này có vấn đề về trí nhớ, tương tự, AI mà chúng ta được giới thiệu vài năm trước rất giỏi trong lập luận, tính toán, tạo mã nguồn (code generation), nó được đánh giá là vượt trội về điểm chuẩn. Vấn đề duy nhất là kiến thức chuyên sâu của tổ chức (institutional knowledge), tức là kiến thức chuyên môn (domain knowledge) mà bạn có. Đó là điều duy nhất chúng ta phải gặp một chút rắc rối.

Sự tiến hóa của AI từ Kỹ thuật Lời nhắc đến Tác nhân Sâu

Nếu nhìn vào sự tiến hóa từ AI đến tác nhân, nó đã bùng nổ. Nó bắt đầu từ prompt engineering trước tiên, sau đó là RAGs (Retrieval Augmented Generation), bây giờ là MCPs, sau đó là đa tác nhân (multi-agent), và hiện tại là tác nhân sâu (deep agents). Gần đây tôi phát hiện ra rằng, bằng cách sử dụng Replit, bạn thực sự có thể xây dựng một ứng dụng full-stack trong 10 phút. Điều đó có nghĩa là, trong khi bạn làm mì ăn liền, bạn đã có một ứng dụng trị giá hàng triệu đô la hoạt động trên máy tính xách tay của mình. Chúng ta đã đạt đến điểm này, thật là tốt một cách phi thường. Đó là AI và các tác nhân.

Thách thức của AI trong Doanh nghiệp

Vậy, hãy nói về AI trong doanh nghiệp. Tôi không biết có bao nhiêu bạn có câu hỏi này, nhưng hầu hết các doanh nghiệp tôi thấy đều đặt câu hỏi: " AI khá thông minh. Nó đang tạo mã nguồn, ứng dụng full-stack, xem xét các PR của bạn, quản lý sự cố, và tất cả những thứ đó. Vậy, nếu AI làm được nhiều đến vậy, tại sao các Jira tickets hoặc Epic của chúng ta không di chuyển trên bảng điều khiển? Tại sao tôi không thấy việc chuyển giao thực sự?" Mọi người đều nói về việc mọi thứ đã sẵn sàng trong 3 phút. Vâng, được thôi. Tại sao các Jira tickets của tôi không di chuyển? Bởi vì điều đó định nghĩa việc chuyển giao kinh doanh và điều đó định nghĩa lợi tức đầu tư (return on investment), đúng không?

Và như bạn thấy, theo McKinsey năm nay, 88% tất cả các công ty sử dụng AI nhưng họ chỉ thấy 6% giá trị tạo ra. Tôi nghĩ đây là vấn đề chúng ta đang gặp phải. Tôi có bốn Jira tickets khác nhau, là những mẫu. Bạn có thể thấy những mục màu xanh lá cây mà tôi đã đánh dấu về cơ bản là những gì Mô hình Ngôn ngữ Lớn đã được huấn luyện, như các tiêu chuẩn API hoặc những thứ mà họ đã biết, đó là kiến thức chung. Những nhiệm vụ đó từ ticket, nó có thể tiếp nhận và thực hiện. Bây giờ có phần thứ hai, những mục màu cam, mà chúng ta phải thực sự dạy chúng. "Bạn biết điều này, nhưng hãy làm theo cách này." Vì vậy, tất cả những thứ màu cam đó sẽ phù hợp với extension tác nhân của bạn, như các kỹ năng (skills). Nhưng những mục màu đỏ, đó là kiến thức chuyên sâu của tổ chức nằm trong công ty và trong con người. Vì vậy, trừ khi nó chọn một nhiệm vụ, trừ khi nó chọn một ticket, nó phải hoàn thành tất cả. Nó rất giỏi với các mục màu xanh lá cây và màu cam, nhưng nó gặp khó khăn với mục màu đỏ, tức là kiến thức chuyên sâu của tổ chức. Và tôi tin rằng hiện tại, các tác nhân coding đang ngày càng tốt hơn rất nhiều. Tôi cảm thấy nếu có một AGI (Artificial General Intelligence) xuất hiện, AGI đầu tiên chắc chắn sẽ là một tác nhân coding.

Vấn đề với Kiến thức Chuyên sâu của Tổ chức và Giải pháp Ngành

Để khắc phục việc cung cấp kiến thức chuyên sâu của tổ chức cho các tác nhân, chúng ta đã có một giải pháp công nghiệp. Về cơ bản, đây sẽ là một pipeline (quy trình) lợi tức đầu tư (return on investment) AI của bạn. Bạn có chất lượng mô hình Mô hình Ngôn ngữ Lớn, bạn có tác nhân và bạn có agent harness, và kiến thức chuyên sâu của tổ chức của bạn nằm dưới Confluence, Jira, SharePoint, GitHub và tất cả những thứ đó. Về cơ bản, lớp truy xuất (retrieval layer) là thứ mà ngành công nghiệp đang nói với chúng ta sẽ khắc phục vấn đề đó. Vì vậy, bạn xây dựng lớp truy xuất đó và sau đó nó sẽ tìm nạp tất cả những thứ đó và cung cấp cho một tác nhân, và tác nhân đó sẽ có thể làm được điều đó, đúng không?

Về cơ bản, 40% độ chính xác thực tế có thể đạt được thông qua RAG hoặc đồ thị tri thức (knowledge graphs), nhưng với một cơ sở kiến thức được ghi lại. Về cơ bản, nếu bạn xây dựng một lớp truy xuất, nó phải hoạt động. Bây giờ, hãy để tôi hỏi bạn một câu hỏi. Bao nhiêu người trong số các bạn đã xây dựng các lớp truy xuất như RAGs và MCPs? Được rồi, tuyệt vời, tất cả mọi người. Bây giờ câu hỏi là bạn đã xây dựng bao nhiêu MCP? Bao nhiêu người đã xây dựng hơn 20 máy chủ MCP? Được rồi, được rồi. Vậy thì không ai phá kỷ lục của tôi rồi.

Thách thức của Lớp Truy xuất trong Doanh nghiệp

Những gì tôi thấy là, chủ yếu trong các tổ chức doanh nghiệp, mọi người đang xây dựng khoảng 10 đến 15 hoặc 20 máy chủ MCP hoặc RAGs, đồ thị tri thức trên đỉnh kiến thức chuyên sâu của tổ chức của họ và cho tác nhân. Giả định là nếu tôi có thể xây dựng tất cả các máy chủ MCP đó và cung cấp cho tác nhân, tôi sẽ không cần phải làm gì cả, nó sẽ tự động làm. Nhưng vấn đề là khi bạn cắm các máy chủ MCP này, về cơ bản, tất cả dữ liệu đầu ra chủ yếu là không xác định (undeterministic), không đáng tin cậy (unreliable) và chưa được kiểm thử (untested). Đặc biệt trong kỹ thuật, không ai thực sự làm eVals. Đó là một khái niệm thuộc về khoa học dữ liệu và học máy, nhưng chúng ta không làm eVals. Đối với tôi, nếu bạn... xin lỗi, nếu bạn cắm một MCP hoặc RAG và tất cả, chúng ta chỉ xem đầu ra có ra hay không, chứ không phải liệu nó có thực sự có giá trị hay không, liệu nó có thực sự giải quyết được vấn đề hay không. Đó là vấn đề chính mà tôi thấy. Tôi không nói rằng tôi đang chỉ trích người khác vì tôi cũng từng là người đó. Tôi đã nghĩ: "Được rồi, hãy để tôi xây dựng tất cả các máy chủ MCP, cắm kiến thức chuyên sâu của tổ chức của tôi vào. Tôi sẽ chứng minh rằng các tác nhân có thể bán tự động tiếp tục và điền các Jira tickets và hoàn thành chúng." Đúng không? Nhưng mỗi khi tôi xây dựng các máy chủ MCP đó, 10%, 20%, 30% thời gian là chính xác, nhưng phần còn lại thời gian, tôi đang làm công việc nhập liệu cho chúng. Vì vậy, tôi đã điền vào các khoảng trống, đặt câu hỏi. Về cơ bản, tôi đang làm nhiều việc hơn là làm ít việc.

Bản chất của Kiến thức Chuyên sâu trong Doanh nghiệp

Vì vậy, tôi nghĩ đây là vấn đề chính và tôi thực sự đã ở giai đoạn thứ tư này, nơi tôi đã thực sự bắt đầu viết ngữ cảnh chuyên môn (domain context) bằng tay. Tôi nghĩ: "Được rồi, hãy để tôi viết mọi thứ và chứng minh quan điểm này," nhưng tôi đã thực sự kiệt sức khi làm điều đó.

Tôi không biết có bao nhiêu người có thể liên hệ với biểu đồ hình tròn này, nhưng hầu hết các doanh nghiệp, kiến thức chuyên sâu của tổ chức đều giống như thế này. Nếu bạn thấy, 20% là lỗi thời, 20% không đáng tin cậy. 10% đến 20% luôn bị trùng lặp ở những nơi khác nhau. Và vấn đề lớn nhất là 40% kiến thức luôn là kiến thức truyền miệng (tribal knowledge), nghĩa là mọi người biết cách mọi thứ hoạt động, nhưng nó không bao giờ được ghi lại.

Trong tình huống doanh nghiệp như vậy, nếu bạn xây dựng 100 máy chủ MCP và cắm vào kiến trúc monolith đó, dù bạn xây dựng bao nhiêu, nó cũng sẽ không hoạt động vì về cơ bản, toàn bộ kiến thức chuyên sâu của tổ chức của bạn là một monolith. Tôi nghĩ rằng, vì tất cả các bạn đều đến từ nền tảng kỹ thuật, nên các bạn đã biết về sự chuyển đổi từ hệ thống monolith legacy sang microservices, đúng không? Cũng theo cách đó, trừ khi chúng ta chia nhỏ cơ sở tri thức dạng monolith đó thành các khối ngữ cảnh hữu ích cho các tác nhân, thì khi đó chúng ta mới có thể thực sự làm cho nó hữu ích cho chúng, cho các tác nhân, và thực sự làm cho chúng có thể thực hiện các nhiệm vụ một cách bán tự động.

Giải pháp: Ngữ cảnh theo Hướng Yêu cầu (Demand-Driven Context)

Như đã nói, trong workshop này chúng ta sẽ nói nhiều về cách phá vỡ monolith đó, cách tiếp cận để phá vỡ nó và nó hữu ích như thế nào sau khi chúng ta phá vỡ nó. Và đây là công việc chúng ta cần làm, bởi vì các nhà cung cấp Mô hình Ngôn ngữ Lớn sẽ tập trung vào chất lượng mô hình Mô hình Ngôn ngữ Lớn, các tác nhân sẽ tập trung vào các công cụ harness, và có một thị trường truy xuất lớn trị giá 9 tỷ đô la đang tập trung vào truy xuất, nhưng không ai sẽ đến công ty của bạn để sửa cơ sở tri thức của bạn. Bạn phải tự sửa nó, đúng không? Vậy, làm thế nào chúng ta có thể làm điều đó?

Ngữ cảnh theo hướng yêu cầu (demand-driven context) là giải pháp mà tôi đang cố gắng đề xuất. Về cơ bản, nếu tôi phải đưa ra một bản tóm tắt về nó, nó giống như việc chúng ta có các dịch vụ monolith và chúng ta có quá trình chia chúng thành microservices. Chúng ta có mô hình thác nước (waterfall model) mà chúng ta đã chuyển đổi thành agile. Cũng theo cách đó, khi bạn có một monolith về kiến thức chuyên sâu của tổ chức, làm thế nào để bạn chuyển đổi nó thành các khối ngữ cảnh bằng một cách tiếp cận? Đây là một cách tiếp cận về cách chúng ta có thể làm điều đó.

Trước khi bắt đầu, đây không chỉ là một ý tưởng. Chúng tôi đã thử nghiệm với một số bộ dữ liệu và cố gắng chứng minh cách tiếp cận này hiệu quả, và vào tháng 3, chúng tôi đã xuất bản một bài báo preprint trên RXV. Vì vậy, nếu ai quan tâm đến việc đọc các bài báo học thuật, bạn có thể tìm thấy nó với từ khóa demand-driven context hoặc tôi cũng có thể cung cấp cho bạn một liên kết sau workshop.

Cách Ngữ cảnh theo Hướng Yêu cầu Hoạt động

Vậy, nó hoạt động như thế nào khi chúng ta cung cấp kiến thức chuyên sâu của tổ chức cho các tác nhân? Về cơ bản, những gì chúng ta đang cố gắng làm là chúng ta đang cố gắng thực hiện một chiến lược đẩy (push strategy). Chúng ta xây dựng mọi thứ và chúng ta đẩy nó đến đó.

Phương pháp tiếp cận dựa trên "kéo" (Pull Approach)

Vậy thì, với phương pháp này, đó là một pull approach nhiều hơn. Điều đó có nghĩa là, ví dụ, giả sử một người mới đã gia nhập công ty của bạn, phải không? Làm thế nào bạn giới thiệu người đó? Bạn giới thiệu họ trong một hoặc hai ngày, bạn cung cấp một số định hướng ban đầu, và sau đó bạn nói với họ, "Được rồi, đây là các liên kết Confluence, đây là GitHub, đây là một số loại tài liệu bạn phải tuân theo, và tất cả những thứ khác." Sau đó, bạn chỉ định một nhiệm vụ cho người đó. Nhưng bạn sẽ không nói, "Được rồi, hãy đi học hỏi kiến thức này và quay lại, rồi tôi sẽ giao việc cho bạn," phải không? Vì vậy, bạn sẽ chỉ định hạng mục công việc, và khi bạn chỉ định hạng mục công việc đó, người đó sẽ bắt đầu đặt câu hỏi, lấp đầy các lỗ hổng. Nếu người đó rất chú trọng tài liệu, họ cũng sẽ điền tài liệu cho bạn. Người đó dần dần tiếp thu kiến thức tổ chức, phải không? Tương tự như vậy, chúng ta không đẩy tất cả kiến thức cho tác nhân. Thay vào đó, chúng ta bắt đầu giao vấn đề cho các tác nhân dưới dạng hạng mục công việc và để họ thực sự tự truy xuất thông tin từ chúng ta. Và một khi đã truy xuất thông tin, cũng yêu cầu họ tài liệu hóa nó theo cách tốt hơn thay vì một cấu trúc nguyên khối.

Vòng lặp học hỏi của tác nhân

Vậy đó là bốn lớp. Bạn có một hệ thống nguyên khối, một khung làm việc, và nó thực sự truy xuất và tạo ra các khối ngữ cảnh tốt hơn. Bạn có thể liên hệ trực tiếp nó với việc chuyển đổi từ một hệ thống nguyên khối cũ sang vi dịch vụ nếu bạn có kiến thức về điều đó. Đây là cách nó hoạt động. Đây là một chu trình về cách một vấn đề được giao cho một tác nhân. Trong lần thử đầu tiên, tác nhân sẽ thất bại trong việc thực hiện. Nó sẽ nói, "Bạn biết không, bạn đã giao cho tôi một vấn đề, nhưng tôi không thể tìm thấy hầu hết tài liệu. Tôi không thể làm được. Vậy thì, đây là những điều tôi cần làm để hoàn thành nhiệm vụ này," và nó đưa ra một danh sách kiểm tra các việc. Chúng ta hoàn thành danh sách kiểm tra này. Một khi vấn đề được giải quyết, nó sẽ lấy kiến thức đó và cũng cập nhật – tức là quản lý – kiến thức ở một nơi cụ thể để nó có thể tái sử dụng, hoặc các tác nhân khác cũng có thể tái sử dụng. Đây là một chu trình. Vì vậy, ý tưởng là nếu chúng ta có thể thực hiện điều đó trong nhiều phiên với nhiều vấn đề, nó sẽ dần dần quản lý cơ sở tri thức nguyên khối của bạn và cũng tài liệu hóa nó cho bạn.

So sánh với Phát triển hướng kiểm thử (TDD)

Bạn cũng có thể liên hệ nó với TDD. Vậy có bao nhiêu người thực hiện TDD hay không ai ghét TDD, phải không? Trước khi tôi... Vâng. >> Được rồi. Được rồi. Vậy thì, theo cùng một cách, trong một TDD approach, chúng ta làm gì? Chúng ta chỉ viết các trường hợp kiểm thử thất bại. Chúng ta không xây dựng sản phẩm trước tiên. Chúng ta chỉ viết các trường hợp kiểm thử thất bại. Chúng ta xem mã nào bị thiếu để trường hợp kiểm thử thất bại đó có thể vượt qua, và chúng ta chỉ cung cấp mã, và chúng ta dần dần xây dựng sản phẩm dựa trên các trường hợp kiểm thử thất bại. Tương tự như vậy, chúng ta giao các vấn đề mà tác nhân chắc chắn sẽ thất bại, và chúng ta dần dần lấp đầy những lỗ hổng đó. Và đến một thời điểm nhất định, nó trở nên bán tự động với kiến thức tổ chức tốt đã có sẵn.

Thiết lập và chạy bản trình diễn ban đầu

Được rồi. Vậy tôi nghĩ tôi có thể chuyển sang một bản trình diễn nào đó. Vì vậy, tôi sẽ sử dụng terminal. Đừng ghét tôi. Tôi nghĩ tất cả các bạn đều có nền tảng kỹ thuật, vì vậy tôi nghĩ các bạn sẽ thích terminal. Hãy để tôi chuyển sang terminal. Được rồi. Được rồi. Vậy thì, ở phía ngoài cùng bên phải, những gì bạn thấy là cách nó hoạt động bên dưới. Khi bạn đã giao một vấn đề, tác nhân sẽ thất bại như thế nào? Nó đòi hỏi kiến thức như thế nào để vấn đề được giải quyết? Và một con người, như một chuyên gia lĩnh vực và những người khác, sẽ lấp đầy những lỗ hổng đó, và sau đó nó sẽ quản lý một cơ sở tri thức mới cho bạn, tốt hơn nhiều, và sau đó tác nhân thành công, và bạn lặp lại với các vấn đề tiếp theo. Đó là cách một chu trình hoạt động. Vậy nó có thể được triển khai như thế nào? Nó có thể được triển khai bằng bất kỳ tác nhân nào. Không có – nó có thể được triển khai trên đám mây hoặc Copilot vì đây là một phương pháp bạn có thể thực hiện theo bất kỳ cách nào bạn muốn. Tại nơi làm việc, tôi sử dụng Copilot. Vì vậy, tôi đã triển khai điều này bằng cách sử dụng Copilot. Nhưng bởi vì tôi tin rằng mọi người đều thích Claude Code hơn, nên tôi đã tạo bản trình diễn này với Claude Code. Và bạn có thể thấy nó chỉ là sự kết hợp của kỹ năng, quy tắc, các tác nhân và hook cùng một nơi nào đó để lưu trữ cơ sở tri thức. Trên bảng điều khiển ở giữa, những gì bạn đang thấy ở trên cùng về cơ bản là hệ thống nguyên khối của bạn. Đây là một đại diện cho Confluence, Slack, GitHub của bạn và tất cả. Nhưng chỉ để phục vụ bản trình diễn, tôi chỉ đặt một số tệp phẳng trông giống như chúng. Đó là cách cơ sở tri thức nguyên khối của bạn sẽ trông như thế nào. Ở phía dưới, những gì bạn đang thấy là trên một bản trình diễn trực tiếp. Vì vậy, khi nó đang giải quyết một vấn đề, cách nó thực sự thêm kiến thức mới vào đó. Đó là cách nó hoạt động. Vậy, hãy để tôi... Vậy, tôi sẽ làm gì? Tôi sẽ đến một tác nhân. Được rồi, về cơ bản tôi sẽ giao một vấn đề sự cố để thực hiện phân tích nguyên nhân gốc, phải không?

Khám phá và quản lý kiến thức của tác nhân

Vậy, được rồi, những gì tôi đã làm là – bạn có nhớ trong slide trước có các mẫu GT mà tôi đã trình bày không? Đó là sự kết hợp của kiến thức đã được tài liệu hóa và những thứ hoàn toàn chưa được tài liệu hóa. Vì vậy, sự cố này cũng thể hiện cùng một loại kết hợp. Có một số kiến thức đã được tài liệu hóa trên hệ thống nguyên khối của bạn. Một số thì không có hoặc đã lỗi thời hoặc những thứ tương tự, và hầu hết nó không thể tìm thấy vì nó thực sự chưa bao giờ được ghi lại. Vì vậy, khi tôi giao vấn đề này, nó sử dụng những kỹ năng mà tôi đã phát triển bằng phương pháp này, và nó sẽ cố gắng trước tiên truy cập vào hệ thống nguyên khối của bạn – thực tế, trên cơ sở tri thức – và cố gắng tìm thông tin về những gì có sẵn. Vì vậy, hãy nghĩ về nó như thế này: Phần đầu tiên là truy xuất. Tức là nó đã thực hiện những gì RA và MCP đang làm ở phần đầu tiên. Nhưng điều gì khác nó đang làm là sau khi nó truy xuất dữ liệu, nó sẽ làm gì với dữ liệu đó? Đó là một phần còn thiếu. Ví dụ, khi bạn cung cấp liên kết Confluence mới cho một nhân viên mới, nhân viên đó đi đến đó, xem xét nó, nhưng không tìm thấy thông tin. Nhưng thực tế anh ấy không dừng lại ở đó. Anh ấy tiếp tục đặt câu hỏi để giải quyết vấn đề, sau đó chỉ cần thêm nhiều kiến thức và tất cả những thứ khác. Phải không? Đó là những bước tiếp theo còn thiếu hiện tại. Chúng ta chỉ dừng lại ở truy xuất. Vì vậy, đây là ba bước tiếp theo mà nó thực hiện. Bạn có thể thấy điểm tin cậy gần như từ 1 đến 5 vì nó nói, "Đây là những thuật ngữ cụ thể. Tôi thực sự không hiểu những thuật ngữ này và những logic nghiệp vụ này không cần thiết." Vì vậy, một điều bạn cần lưu ý ở đây là bất cứ điều gì nó đã nói, đây là thông tin chưa được tài liệu hóa – tức là nó chưa bao giờ được ghi lại. Vì vậy, trừ khi bạn làm theo cách này, bạn sẽ không bao giờ biết điều gì chưa được tài liệu hóa. Ví dụ, nếu ai đó nói, "Được rồi, có tài liệu bị thiếu, chúng ta cần viết." "Được rồi, bạn muốn tôi viết gì thực sự?" Có quá nhiều trong đầu mọi người, tôi không thể viết quá nhiều, phải không? Bằng cách nào đó, nó phải làm lộ rõ. Vì vậy, khi bạn giao một vấn đề, nó thực sự làm lộ rõ những gì chưa được tài liệu hóa và nó nói với tôi, "Được rồi, cái này bị thiếu, tôi cần có thông tin mới ở đó."

Vậy thì, những gì tôi sẽ làm là – nó thực hiện cả ba bước. Sau đó, những gì tôi sẽ làm là tôi đã có một câu trả lời được chuẩn bị trước, một câu trả lời được chuẩn bị ở cấp cao, tôi đã đưa cho nó, như là, "Thông tin còn thiếu là gì?" Vậy thì, "Được rồi, đây là thông tin còn thiếu mà bạn yêu cầu tôi giải quyết vấn đề này. Bạn có thể giải quyết vấn đề này bây giờ không?" Tôi đã không mong đợi điều này. Thông báo là có. Tôi sẽ chỉ nói có. >> Nó cũng hỏi tôi nên sử dụng tên hư cấu nào. >> Được rồi, tôi không thấy nó. Bạn thấy đấy, khi tôi thực hiện chạy thử, nó không hỏi tôi các câu hỏi. >> Hãy xem. Nó biết đây là một bản trình diễn. >> Tôi đã huấn luyện nó để... Được rồi. Không, những gì nó đang làm đã... Vậy thì, bạn có thể thấy trên bản trình diễn trực tiếp, nó đã thêm các thực thể mà cơ sở tri thức mới đã được đưa vào. >> Vậy cơ sở tri thức được quản lý như một hệ thống tệp, phải không? Như một hệ thống các tệp. Đối với bản trình diễn, tôi chỉ hiển thị nó như một hệ thống tệp, nhưng về cơ bản đó là các máy chủ MCP của bạn. Dữ liệu sẽ nằm trong Confluence, Slack, hoặc những thứ tương tự. Bạn chỉ cần kết nối và sử dụng cùng các máy chủ MCP hoặc RAG và tất cả. Vì vậy, nó không cần phải là một tệp phẳng. >> Bạn coi đây là lớp lưu trữ của bạn cho điều này, phải không? >> Nó giống như, bạn có sử dụng bất kỳ công cụ bộ nhớ nào cho điều này không? Vâng, tôi sẽ cho bạn thấy ở phần tiếp theo... cách tôi sẽ xem... Được rồi, vậy là nó bắt đầu từ 56 thực thể hoặc gì đó. Với điều này, hiện tại, một vấn đề thực sự đã làm lộ rõ sáu thực thể chưa bao giờ được tài liệu hóa. Và khi tôi cung cấp thông tin đó cho nó, nó có thể thực sự khám phá và quản lý thêm năm hoặc sáu thực thể mới chưa bao giờ được tài liệu hóa. Vì vậy, nó thực hiện khám phá các lỗ hổng. Nó cũng nhận thông tin từ tôi và cũng lưu trữ thông tin, thông tin mới, v.v. Đây là một.

Nâng cao mức độ tin cậy qua nhiều chu trình

Được rồi. Tiếp theo, hãy xem, đây là một cửa sổ bận rộn. Tôi đã cố gắng thực hiện mọi thứ nhưng nó không thành công. Được rồi. Những gì bạn đang thấy trên cửa sổ là 14 sự cố. Bạn đã thấy một vấn đề mà tôi đã giải quyết với một tác nhân, phải không? Vấn đề giao tiếp. Điều gì sẽ xảy ra nếu tôi lấy 14 sự cố và thực hiện 14 chu trình của việc này, và nó hoạt động như thế nào? Vì vậy, nếu bạn nhìn vào phía bên trái, đó là sự cố đầu tiên, phải không? Hiện tại, nó có điểm tin cậy 1.5 và mọi thứ đều nghiêm trọng. Về cơ bản, không có gì được tài liệu hóa, vì vậy mọi thứ đều nghiêm trọng, cao, dữ liệu bị thiếu. Vì vậy, tôi bắt đầu đưa ra câu trả lời cho sự cố đầu tiên, sau đó tôi lặp lại cho sự cố thứ hai và thứ ba, và liên tục trong khoảng 14 sự cố. Nhưng đến sự cố thứ 14, nó về cơ bản đã có thể đạt được mức độ tin cậy 4.4 vì trước tiên, với mỗi sự cố, nó đã nhận được danh sách câu trả lời cho tôi, và nó cũng tài liệu hóa mọi thứ cho tôi. Vì vậy, nó dần dần cải thiện từ 1.4 lên gần như 5 điểm kiến thức. Vậy thì, nếu bạn nhìn vào cách truyền thống, cách truyền thống chúng ta làm là giải quyết tất cả vấn đề ngữ cảnh, phải không? Chúng ta phải giải quyết nó trước, sau đó tôi phải giao nó cho tác nhân. Trong cách này, chúng ta đang chuyển tác nhân từ người tiêu dùng thành quản lý kiến thức. Vì vậy, bạn không chỉ tiêu thụ từ tôi; tôi sẽ nói cho bạn biết, nhưng toàn bộ quản lý kiến thức cũng là công việc của bạn, và bạn phải làm điều đó cho...

Tự động hóa quy trình quản lý kiến thức

Được rồi, tôi nghĩ chúng ta có thể quay lại các slide một chút. Được rồi, vậy những gì chúng ta đã thấy là tôi đã chạy một chu trình, và tôi cũng đã trình bày nó trông như thế nào khi tôi chạy nó trong khoảng 15 hoặc 16 chu trình khác nhau, phải không? Nhưng nếu bạn muốn làm thủ công, điều đó sẽ thực sự khó khăn vì tôi đã thử nó sau 15 chu trình – không ai muốn thực sự ngồi với một tác nhân và bạn biết bạn có một sự cố, nhưng bạn sẽ không ngồi với tác nhân của mình và cứ tiếp tục đặt câu hỏi và nói cho bạn biết về các vấn đề của bạn, phải không? Vì vậy, điều đó thực sự khó khăn. Nhưng vấn đề là chúng ta có thể tự động hóa quy trình này. Vì vậy, đây là nơi nó thực sự tốt và trở nên thú vị. Vậy thì đây là điều: Chúng ta đã có tất cả các hạng mục công việc, phải không? Chúng ta có Jira, chúng ta có các sự cố, chúng ta có các phiếu hỗ trợ khách hàng – tất cả những loại hạng mục công việc đó đã có sẵn, phải không, nằm trong kho lưu trữ. Vậy tại sao chúng ta không thể lấy chúng và thực sự sử dụng khung làm việc và xác thực trên cơ sở dữ liệu nguyên khối của bạn, chạy một tự động hóa, và xem thực sự trạng thái của bạn là gì, phải không? Được rồi, hãy để tôi cho bạn thấy nó trông như thế nào. Vậy, thay vì thực sự làm thủ công ở quy mô lớn, nếu chúng ta thực hiện phương pháp này, nó sẽ trông như thế nào? Bản trình diễn mà bạn đang thấy gần như mọi thứ đều được cài đặt trước. Ví dụ, tôi có bản trình diễn.

Xác Thực Sự Cố và Phát Hiện Khoảng Trống Kiến Thức

Tôi có một tác nhân vận hành nền tảng và tôi đưa cho nó các sự cố gần đây. Giả sử tôi có 20 sự cố gần đây, được lưu trữ trong một tệp .md hoặc .json, chứa tất cả các chi tiết về mô tả, bình luận, v.v. Phần còn lại của các tệp này là cơ sở tri thức của bạn. Đây là một hệ thống tệp, nhưng bạn cũng có thể kết nối nó theo cách tương tự với Confluence và các công cụ khác, chỉ là để trình diễn, tôi đang hiển thị chúng dưới dạng các tệp phẳng.

Hiện tại, điều tôi đang cố gắng làm là lấy tất cả các sự cố đó và xác thực từng sự cố so với cơ sở tri thức của tôi. Sau đó, tôi yêu cầu tác nhân cho tôi biết "có bao nhiêu phần tài liệu là tốt, bao nhiêu phần tài liệu tôi không thể tin tưởng (hoặc đã cũ/lỗi thời), và bao nhiêu phần thực sự bị thiếu, không được ghi lại theo sự cố này".

Hãy để tôi chạy nó. Quá trình này sẽ mất một chút thời gian và thực hiện ba bước. Thứ nhất, nó sẽ tạo ra các probes (các bài kiểm tra cơ bản) để thực sự kiểm tra cơ sở tri thức của bạn. Sau đó, nó sẽ chạy các bài kiểm tra đó và cuối cùng, phân tích các khoảng trống.

Phân Tích và Xếp Hạng Chất Lượng Tài Liệu

Ví dụ, giả sử bạn có một cuộc gọi sự cố liên quan đến "dịch vụ thông báo không gửi tin nhắn khách hàng đến dịch vụ SMS". Khi bạn đề cập đến notification service, tác nhân sẽ kiểm tra xem có tài liệu nào liên quan đến dịch vụ thông báo hay không. Nếu không tìm thấy, điều đó có nghĩa là bạn chưa bao giờ viết tài liệu về notification service. Tôi hiểu customer SMSs và customer notification service là gì. Khi bạn đề cập đó là một khoảng trống, vì nó chưa bao giờ được ghi lại, hoặc tác nhân có thể kiểm tra Confluence và xem tài liệu về customer notification service đã cũ đến mức nào. Nếu nó đã "một năm tuổi", tác nhân sẽ cho bạn biết: "Tôi đã kiểm tra, tài liệu này đã một năm tuổi. Tôi không biết liệu tôi có nên tin tưởng tài liệu này hay không, hoặc nó là tài liệu không đầy đủ."

Bạn sẽ thấy rằng nó đã chấm điểm từng sự cố, kiểm tra tất cả các cơ sở tri thức mà bạn đã kết nối, và đưa ra một danh sách điểm số tổng hợp. Ví dụ: "Các tác nhân có thể xử lý một phần các trường hợp biên cơ bản của các sự cố mà bạn cung cấp, vì cơ sở tri thức của bạn chưa hoàn chỉnh." Nó cũng sẽ cho bạn thấy bao nhiêu tribal knowledge (kiến thức không được ghi chép), thông tin hệ thống, quy trình kinh doanh thực sự bị thiếu trong kiến thức thể chế của bạn (bất cứ điều gì không được tài liệu hóa).

Đây là các probes, và nó cũng sẽ xác định điều gì là "nghiêm trọng" (critical) và điều gì là "cao" (high). Điều này thực sự quan trọng. Giả sử có một ví dụ về notification service mà tôi đã đề cập, nó liên tục xuất hiện trong khoảng 20 sự cố và bạn không có tài liệu cho nó. Đây là điều đầu tiên bạn cần khắc phục theo tài liệu của mình. Vì vậy, nó cũng giúp chúng ta thực sự hiểu khi bạn phân tích cơ sở tri thức của mình, bạn cần hiểu điều gì là "nghiêm trọng", điều gì tôi cần tập trung vào trước tiên, điều gì tạo ra giá trị cho tôi. Vì vậy, nó được tổ chức thành các mức độ "nghiêm trọng", "cao", "trung bình".

Tôi đã trình diễn với các tệp phẳng, nhưng bạn cũng có thể kết nối nó với nhiều nguồn dữ liệu khác nhau.

Quản Lý và Tự Động Hóa Cơ Sở Tri Thức

Bước một về cơ bản là demand extraction. Điều đó có nghĩa là mỗi sự cố nó sẽ trích xuất danh sách kiểm tra các thông tin bị thiếu. Bước thứ hai là nó sẽ tổng hợp mọi thứ bị thiếu. Vì vậy, nó sẽ tạo ra các hệ thống và API, và phân loại bao nhiêu là sạch, bao nhiêu là lỗi thời, cái nào không đầy đủ, cái nào hoàn toàn bị thiếu, cái nào là tribal knowledge. Nó cũng sẽ thực hiện loại phân loại này và tạo một Kanban board cho bạn.

Điều gì sẽ xảy ra? Nếu bạn muốn sửa cơ sở tri thức thể chế của mình, về cơ bản bạn chỉ cần giống như các Jira tickets. Chúng ta hoàn thành nó, chúng ta thực sự phải tài liệu hóa những phần còn thiếu này. Và ngay khi bạn bắt đầu, nó cũng lưu vào context lake, vì vậy nó cũng phải xây dựng cơ sở tri thức của riêng mình và bạn có thể thấy hiệu suất sau khi bạn sửa các lỗi trong cơ sở tri thức.

Vì vậy, đó là cách chúng ta đã thấy. Một là cách tiếp cận ngay từ đầu, không phải pull-push approach mà là pull approach – cách thực hiện một hoặc nhiều chu kỳ sẽ như thế nào. Nhưng nếu bạn đặt nó vào quy mô tự động hóa, thì nó sẽ có giá trị đến mức nào.

Nơi Lưu Trữ Ngữ Cảnh của Tác Nhân

[Tiếng ồn micro] Xin lỗi về điều này. Double mic. Vâng, nó hơi bị gián đoạn. Tôi sẽ bật cái này lên. [Tiếng ồn micro] Tôi có nên lồng tiếng lại sau không? [Tiếng ồn micro] Tôi nghĩ bạn cần nhắc lại. Ai có đủ kiên nhẫn để đợi một giây?

Câu hỏi đặt ra là: Tôi đã luôn nói về việc tác nhân nhận ngữ cảnh (chúng ta cung cấp thông tin, nó sẽ lưu trữ), nhưng câu hỏi là nó thực sự lưu trữ ở đâu? Tôi có một quan điểm rất mạnh mẽ, hãy lắng nghe tôi. Tôi thích nó được lưu trữ trong một kho lưu trữ GitHub. Bởi vì cuối cùng, ai đó sẽ tạo ra một giải pháp SaaS với 20 triệu đô la vốn hạt giống cho bạn. Nhưng trước đó, tôi thích đặt nó vào GitHub dưới dạng một kho lưu trữ. Tại sao? Bởi vì nếu bạn nhìn ở quy mô lớn, nếu bạn muốn làm điều này, sẽ có nhiều tác nhân, nhiều nhóm thực sự đóng góp vào cùng một cơ sở tri thức, và sẽ có các xung đột và giải quyết xung đột, đúng không? Vì vậy, cách dễ nhất để làm điều đó là sử dụng GitHub vì nó đi kèm với các quy trình đánh giá yêu cầu kéo (PR processes) và quy trình xem xét tích hợp. Vì vậy, nếu nhiều chuyên gia miền đang ngồi và tải lên các tệp hoặc các tác nhân đang đóng góp vào đó, cách hiệu quả nhất để quản lý là trong GitHub với một cấu trúc như thế này. Và một lợi thế khác là nếu bạn đặt nó trên GitHub, bạn cũng có thể xuất bản nó lên Confluence sau này hoặc Slack, hoặc bất cứ giải pháp nào khác mà bạn muốn sử dụng. Vì vậy, tôi thích có nó trên GitHub, nhưng nếu bạn muốn tích hợp trực tiếp với Confluence, bạn cũng có thể làm điều đó.

Tầm Quan Trọng của Siêu Mô Hình

Tiếp theo là một siêu mô hình (meta model). Bao nhiêu người ở đây biết từ meta model? Có lẽ tôi có thể nhanh chóng cho bạn thấy nó trông như thế nào. Siêu mô hình về cơ bản là một cái gì đó như thế này, đúng không? Nó mô tả cấu trúc miền của bạn: đó là một quy trình kinh doanh, hay nó liên quan đến các hệ thống như thế nào, các hệ thống liên quan đến API như thế nào, và các thuật ngữ kinh doanh hoặc kỹ thuật này thực sự được liên kết với cái nào. Mối quan hệ kiểu này trong siêu mô hình thực sự quan trọng. Nó không cần thiết cho cách tiếp cận mà tôi đã đề xuất, nhưng nó là một tiện ích bổ sung.

Lý do bạn cần có cái này là gì? Hãy nghĩ về nó như một bản đồ. Hiện tại, tác nhân của bạn không có bất kỳ bản đồ nào để điều hướng cơ sở tri thức của bạn. Về cơ bản, bạn đang đổ hàng tấn tệp vào đó và nó cần phải tìm ra tệp nào cần. Nhưng cấu trúc tệp của bạn thực sự là một sự biểu diễn của siêu mô hình của bạn. Nó thực sự biết cách điều hướng. Ví dụ, nếu bạn hỏi: "Bạn có thể sửa hệ thống này không?", nó sẽ hiểu nếu tôi thực hiện các thay đổi, những quy trình kinh doanh nào sẽ bị ảnh hưởng và những API nào tôi cần thay đổi hoặc "chạm vào". Vì vậy, việc có một siêu mô hình cũng rất quan trọng. Nếu bạn có nó, nó sẽ tạo ra nhiều giá trị hơn. Vì vậy, tôi đặc biệt khuyến nghị có một siêu mô hình cùng với cách tiếp cận này.

Giá Trị Cốt Lõi và Hạn Chế của Cách Tiếp Cận

Phần cuối cùng là về giá trị mà nó đã tạo ra. Có rất nhiều slides và bản demo mà bạn đã xem. Cá nhân tôi cũng cần chia sẻ giá trị mà tôi thấy khi tôi sử dụng nó, hoặc những người khác mà tôi đã chia sẻ đã sử dụng nó và phản hồi lại.

Thứ nhất, điều có giá trị nhất là "biết những điều chưa biết". Điều gì chưa bao giờ được tài liệu hóa là điều chỉ có thể được phát hiện bởi cách tiếp cận này. Nếu không, bạn sẽ chỉ kết thúc trong một bảng trắng Miro board vô tận với việc tạo tickets như "cái này thiếu, cái kia thiếu, tôi cần thêm nó, tôi cần thêm nó" và cứ thế tiếp tục. Đây là cách nhanh nhất và tốt hơn để khám phá những gì chưa bao giờ được tài liệu hóa với các mục công việc trước đây của bạn.

Thứ hai, về cơ bản, tôi có thể giao việc cho các tác nhân thay vì tự mình làm tất cả những việc đó. Thay vì tôi quản lý tất cả thông tin này, hãy để tác nhân quản lý knowledge management của tôi. Tôi không muốn trở thành người quản lý tri thức của nó, vì vậy hãy để nó làm điều đó. Đó là hai giá trị lớn mà tôi đã thấy. Nếu bạn sử dụng nó, tôi nghĩ bạn cũng sẽ thấy hai điều đó là giá trị nhất, nhưng đây là những điều khác mà tôi thấy bây giờ.

Tuy nhiên, tôi cũng cần nói cho bạn biết hạn chế khi sử dụng nó. Trước hết, nếu bạn đến từ một nhóm nhỏ hoặc nếu bạn nói "không, không, tài liệu của tôi, cơ sở tri thức của tôi thực sự tốt", thì tôi rất mừng cho bạn. Bạn là một trong những người may mắn trên thế giới này với các tác nhân. Đối với bạn, nó có thể không thực sự phù hợp, trừ khi bạn có một tài liệu rất, rất phức tạp.

Thứ hai, tôi đã đề cập rằng việc thực hiện thủ công là rất đau đớn. Tôi không khuyến khích bất cứ ai làm điều đó. Nếu bạn chỉ muốn thử nghiệm, bạn có thể làm, nhưng tự động hóa là cách tốt nhất để thực sự sử dụng cách này.

Cách tiếp cận này còn rất sơ khai. Có thể ngay ngày mai, ai đó trên YouTube đã đăng một cái gì đó khác biệt, tốt hơn tôi. Vì vậy, trong thời đại AI, không ai biết một luận án, một cách tiếp cận, hay một sản phẩm ứng dụng sẽ tồn tại bao lâu. Hiện tại, tôi thấy đây là cách tiếp cận tốt nhất.

Quy Trình Ngữ Cảnh Hướng Theo Nhu Cầu

Toàn bộ workshop, chúng ta bắt đầu với một pipeline về ROI. Ngữ cảnh hướng theo nhu cầu thực sự nằm giữa hệ thống nguyên khối này và cả lớp truy xuất. Và điều nó làm là nó thực sự giúp bạn xây dựng các khối ngữ cảnh được tuyển chọn cho riêng bạn. Bạn cũng có thể coi nó như một cơ sở dữ liệu đệm mà bạn có. Vì vậy, mỗi lần tác nhân của bạn không cần phải đi và "đun sôi cả đại dương" để khắc phục một vấn đề. Thay vào đó, nếu bạn có một khối ngữ cảnh tốt, hầu hết thời gian (80% thời gian) thông tin đó có thể sử dụng được. Bởi vì tôi cũng tin rằng đó luôn là quy tắc 80/20: 20% tài liệu của bạn là hữu ích nhất, 80% là các trường hợp góc cạnh mà bạn phải xem xét. Vì vậy, thay vì cung cấp 100% mọi thứ, bạn cần tìm ra 20% nào trong số đó là cực kỳ hữu ích cho tác nhân và lưu trữ nó như một cơ sở dữ liệu đệm (tức là khối ngữ cảnh của nó). Phần còn lại bạn có thể để dưới dạng liên kết, để bất cứ khi nào tác nhân cảm thấy cần thêm thông tin, nó mới có thể đi và kiểm tra toàn bộ kiến thức thể chế monolith.

Những Điều Bạn Có Thể Mang Về Từ Workshop

Vậy từ workshop này, bạn có thể mang về ba điều:

1. Tôi hy vọng tôi đã làm rõ ý nghĩa của cách tiếp cận này. Có một GitHub repo mà tôi đã trình bày chi tiết và một hướng dẫn khởi động kèm theo. Nếu bạn muốn về nhà và thử, bạn có thể làm.
2. Bạn đã biết cách khung làm việc này hoạt động. Vì vậy, nếu bạn muốn về nhà và chỉnh sửa lại toàn bộ cách tiếp cận, bạn có thể làm. Hãy cho tôi biết, tôi sẽ để lại thông tin này và tham gia cùng bạn để đóng góp.
3. Bạn có một trình quét khoảng trống ngữ cảnh mà tôi đã cho bạn xem, hiện đã hoạt động với các cài đặt sẵn. Tôi nghĩ tôi đã thêm 20 đô la vào đó. Vì vậy, hãy tận dụng nó nhiều nhất có thể. 200 đô la, đúng không? [Thảo luận về giá] [Tiếng ồn micro] Vâng, sau 20 đô la, phục vụ người đến trước. Vì vậy, tất cả ba điều này bạn có thể sử dụng, bạn có thể mang về từ workshop này.

Vì đây là một workshop, tôi cũng muốn bạn thử một cái gì đó. Ba điều bạn có thể thử là:

Hai Cách Tiếp Cận với Công Cụ Quét Khoảng Trống Ngữ Cảnh

Có hai cách để sử dụng công cụ này. Một là khi bạn đã mệt mỏi, không muốn tốn nhiều công sức – giả sử đã gần 4 giờ chiều và bạn sắp đi dự tiệc. Bạn chỉ cần truy cập context gap scanner, mọi thứ đã được cài đặt sẵn. Bạn có thể thử, chạy nó và xem cách hoạt động. Nếu bạn nghĩ có thể làm tốt hơn, hãy cho tôi biết để chúng ta có thể hợp tác.

Mặt khác, nếu bạn là người rất thiên về kỹ thuật và muốn biết cách nó hoạt động "dưới vỏ bọc" (under the hood), đây là một GitHub repository (có thể tôi sẽ gỡ nó ra khỏi slide). GitHub repository này chứa tất cả thông tin và cả một hướng dẫn khởi động (starter guide) nếu bạn muốn dùng thử.

Nhưng nếu bạn vẫn muốn một cách đơn giản hơn nhiều, bạn cũng có thể thử cách này: Về cơ bản, bạn không cần làm gì cả. Hãy lấy lời nhắc này, lấy một trong các Jira ticket hoặc incident mà bạn đang có. Nếu bạn đã xây dựng MCP servers hoặc bất kỳ thứ gì tương tự, bạn chỉ cần sử dụng lời nhắc đó, đưa nó cho Tác nhân của bạn cùng với incident hoặc Jira ticket và yêu cầu nó: "Hãy cho tôi biết chất lượng của knowledge base mà tôi có dựa trên incident hoặc Jira ticket này." Sau đó, bạn sẽ thấy có bao nhiêu phần hiển thị màu đỏ, tức là chưa từng được ghi nhận. Bạn cũng có thể thử cách đơn giản này. Tôi sẽ để slide như thế này, có lẽ bạn có thể chụp ảnh. Tôi có thể chuyển sang slide khác nếu ai đó muốn. Hay thôi.

Triển Khai Giải Pháp Ở Quy Mô Lớn

Người hỏi: Tôi thấy cách tiếp cận này rất thú vị. Câu hỏi đầu tiên là liệu bạn đã áp dụng phương pháp làm việc này ở quy mô lớn (at scale) chưa, bởi vì chúng ta đã thấy hầu hết các ví dụ nhỏ lẻ (toy examples) rồi.

Người trình bày: Vâng, tôi đã sử dụng nó nhưng không phải ở quy mô lớn (at scale). Tôi bắt đầu với những thứ đơn giản hơn vì bạn cũng cần phải xem xét phạm vi của nó. Giả sử tôi có một doanh nghiệp (enterprise) và tôi cố gắng triển khai ở cấp độ doanh nghiệp, tôi không thể làm được vì có nhiều lĩnh vực (domains) và nhiều thứ khác. Ngay cả khi tôi làm ở cấp độ lĩnh vực, tôi cũng cần phải hiểu. Tôi đã thử ở cấp độ lĩnh vực, nhưng ngay cả ở cấp độ lĩnh vực, có quá nhiều kiến thức chuyên môn về lĩnh vực (domain expertise) mà tôi cần phải bổ sung và lấp đầy những khoảng trống đó.

Vì vậy, tôi lại thu hẹp lại thành có lẽ là nhóm nhỏ nhất mà tôi có, và các Jira ticket của nhóm nhỏ nhất, các instance của nhóm nhỏ nhất và trang Confluence của nhóm đó, với một chút phạm vi. Sau đó, nếu tôi đào sâu hơn vào phạm vi, tôi cảm thấy nó nhanh hơn và hữu ích hơn. Nhưng nếu tôi làm ở phạm vi lớn hơn, điều xảy ra là không một người nào có toàn bộ kiến thức chuyên môn về lĩnh vực đó. Vì vậy, về cơ bản, nó lại trở thành một tình huống mà ai đó phải đến, và năm hoặc sáu người phải ngồi lại và bắt đầu làm những việc này.

Nỗi Lo Ngại Về LLM và Tầm Quan Trọng của Ngữ Cảnh

Người hỏi: Vâng, tôi hơi lo lắng rằng điều này có thể gây ra một kiểu tấn công từ chối dịch vụ (denial of service attack) đối với các thành viên trong nhóm bạn, bởi vì các Mô hình Ngôn ngữ Lớn (LLM) của chúng ta được tinh chỉnh (fine-tuned) để tiếp tục khai thác thông tin, để tiếp tục thu thập thêm thông tin, để hỏi thêm các câu hỏi. Vì vậy, tôi nghĩ điều đó sẽ gây khó khăn cho các kỹ sư phải thực hiện việc trả lời câu hỏi. Thứ hai, scanner rất hay, nhưng vẫn được xây dựng trên giả định rằng tất cả các thành viên trong nhóm của bạn và phần còn lại của doanh nghiệp vẫn đang sử dụng hệ thống IT nội bộ của doanh nghiệp (enterprise IT) như đã định, rằng họ thực sự điền đầy đủ chi tiết vào các ticket của mình, v.v. Và tôi biết từ thực tế rằng điều đó hầu hết thời gian không phải là trường hợp.

Người trình bày: Điều đó đúng, tôi đồng ý với bạn. Ngay cả khi tôi đến gặp lãnh đạo để nhận được sự đồng ý, kiểu như "này, bạn có thể cấp cho tôi bandwidth hoặc bạn biết đấy, tôi cần những người này thực sự ngồi lại và sửa ngữ cảnh", tôi không nghĩ tại thời điểm này sẽ có ai làm điều đó. Nhưng tôi nghĩ điều đó sẽ xảy ra bởi vì tôi nghĩ chúng ta đang dần dần chuyển sang các nhà quản lý Tác nhân (agent managers), nơi các Tác nhân đang trở nên bán tự động (semi-autonomous) hoặc tự động (autonomous), và chúng ta quản lý chúng. Nhưng đến một thời điểm nào đó, ai đó phải sửa chữa kiến thức đó vì nó sẽ không tự nhiên mà có. Vì vậy, sau đó, trọng tâm của doanh nghiệp sẽ chuyển sang lấp đầy khoảng trống đó. Đó là điều tôi bắt đầu nói. Tôi không nghĩ rằng bây giờ vẫn chưa ai đang thực sự xem xét vấn đề này. Mọi người đều rất tập trung vào Tác nhân tốt như thế nào, truy xuất (retrieval) tốt như thế nào, nhưng ngữ cảnh tốt như thế nào — bạn chưa giải quyết được nó. Tôi nghĩ trong khoảng một năm nữa, mọi người sẽ nhận ra tầm quan trọng của nó và bảng KBAN chắc chắn sẽ trở thành hiện thực rất sớm.

Áp Dụng Cho Cơ Sở Mã và Xung Đột Dữ Liệu

Người hỏi: Vâng, cảm ơn. Tôi nghĩ thực ra là cùng một quan điểm, khi chúng ta nhìn vào tìm kiếm lớn, tài liệu thực sự là mã nguồn. Tôi chỉ tự hỏi bạn đã áp dụng nó cho cơ sở mã (codebase) chưa?

Người trình bày: À, tôi đã làm rồi, tôi cũng đã áp dụng nó cho cơ sở mã. Nhưng tôi nhận được kết quả lẫn lộn. Đây là vấn đề: Khi tôi chỉ sử dụng cơ sở mã, kết quả khá tốt; hoặc khi tôi chỉ sử dụng Confluence hay dữ liệu dạng văn bản (textual data), nó cũng cho kết quả tốt. Nhưng khi tôi kết hợp chúng lại, theo một cách nào đó, chúng lại xung đột. Bởi vì nó tạo ra một lý thuyết từ GitHub repository, nhưng tài liệu của cùng GitHub repository đó cũng có trên Confluence. Vì vậy, ở đó, nó gặp xung đột về việc "đâu là nguồn đáng tin cậy (source of truth)? Mã nguồn nói thế này, tôi có nên triển khai theo tài liệu không?"

Sau đó, tôi lại cần tạo ra một kỹ năng (skill) hoặc các quy tắc bổ sung, kiểu như: "Thứ hạng nào bạn cần ưu tiên? Nếu bạn thấy nó trong GitHub, điều đó có nghĩa là đó là nguồn đáng tin cậy; hoặc nếu bạn không thấy nó, thì bạn phải tìm thông tin trong Confluence," v.v. Nhưng đó vẫn là những điều tôi đang cố gắng khắc phục, tôi đang tìm kiếm những khoảng trống và sửa chữa chúng. Nhưng tôi chắc chắn thấy vấn đề đó khi kết hợp cả hai.

Kỹ Năng Tĩnh và Phương Pháp Khắc Phục Ngữ Cảnh Trước Khi Truy Xuất

Người hỏi: Và câu hỏi thứ hai là, thú vị thay, về kỹ năng. Bởi vì điều chúng tôi nhận thấy là bạn có một quy trình kiểu như chạy một ngữ cảnh và xác định đúng, sau đó bạn thực hiện nhiệm vụ, xác định rồi bạn quay lại và sau đó bạn đang sửa chữa lại kiến thức. Đúng không?

Người trình bày: À, tôi nghĩ hiện tại kỹ năng mà tôi đã xây dựng là tĩnh (static). Nhưng điều bạn đang đề xuất, nếu tôi không nhầm, là một kỹ năng có khả năng phát triển (evolving skill), đúng không? Nếu kỹ năng thất bại, nó phải phát triển, đúng không? Tôi đồng ý với bạn. Tôi chưa bao giờ thử điều đó, nhưng tôi nghĩ nó phải như vậy bởi vì tôi cũng đang tập trung hơn vào cách thực hiện nó ở quy mô lớn (at scale).

Lý do cũng là tôi muốn ngữ cảnh được sửa chữa trước khi truy xuất (retrieval) chứ không phải trong quá trình vận hành (operational). Lúc đầu, khi tôi bắt đầu với nó, tôi đã làm theo cách trong quá trình vận hành, nghĩa là "ồ, tôi có một work item, tôi sẽ gán nó cho Tác nhân, nó sẽ thất bại, sau đó tôi sẽ bắt đầu cung cấp ngữ cảnh," v.v. Nhưng cách đó tốn rất nhiều thời gian, tốn rất nhiều sự kiên nhẫn của tôi. Vì vậy, thay vì làm như vậy, tôi sẽ sửa ngữ cảnh trước khi truy xuất.

Nếu bạn xem xét một nhóm nhỏ (như tôi đã trả lời câu hỏi của cô ấy), ngữ cảnh mà bạn cần sửa rất nhỏ. Vì vậy, bạn có thể sử dụng một thứ như context gap scanner. Và có lẽ nếu bạn có một chuyên gia trình diễn giỏi, tôi nghĩ chỉ trong vài tuần bạn thực sự có thể sửa tài liệu của mình, không phải 100% nhưng ít nhất 60, 70, 80% chất lượng tốt mà bạn đã có thể xây dựng. Vì vậy, đề xuất của tôi sẽ luôn là: đừng làm nó ở cấp độ vận hành (operational level) hoặc cấp độ thời gian thực (real-time level), mà hãy làm nó trước khi truy xuất. Cách tiếp cận này tốt hơn nhiều.

Xử lý Cửa Sổ Ngữ Cảnh Lớn với Mã Thông Báo Claude Code

Người hỏi: Vâng, đặc biệt là trong những tình huống bạn đặt câu hỏi mà có thể cần đến năm hoặc sáu nguồn khác nhau.

Người trình bày: Hiện tại, sau khi Claude Code công bố 1 triệu mã thông báo (tokens) trong cửa sổ ngữ cảnh (context window), tôi không còn gặp vấn đề gì nữa. Tôi đã tính toán, trung bình khoảng 96 nghìn mã thông báo. Bởi vì tôi đã thử với các lĩnh vực (domains) khác nhau, trên mỗi lĩnh vực, tôi thấy khoảng 96 nghìn mã thông báo. Nếu tôi tổng hợp mọi thứ như Confluence và các thứ khác, thì nó dễ dàng vừa với cửa sổ ngữ cảnh.

Tôi đã cố gắng thử nghiệm một số thứ xung quanh việc sử dụng graph RAG để đặt chúng vào đó, thay vì chỉ lấy tất cả các file, sử dụng graph RAG để hiểu ý định (intent). Nhưng đối với tôi, việc chỉ đặt toàn bộ ngữ cảnh vào cửa sổ ngữ cảnh hiện tại mang lại nhiều kết quả hơn so với việc thực hiện RAG trừ khi bạn có một ngữ cảnh rất lớn, gần một triệu mã thông báo mà bạn muốn đưa vào. Khi đó, có thể bạn phải sử dụng thêm một số cơ chế truy xuất (retrieval mechanisms). Nhưng nếu không, tôi nghĩ nó sẽ ổn thôi.

So Sánh Giữa Kiến Thức Lĩnh Vực và Kiến Thức Chiến Lược

Người hỏi: Tôi có một câu hỏi. Tôi đã mở paper của bạn và bạn có thể giải thích biểu đồ này, giống như so sánh giữa các kỹ thuật khác nhau như kiến thức lĩnh vực (domain knowledge), chiến lược, khả năng truy cập kiến thức không?

Người trình bày: À, cái nào? Vâng, chắc chắn rồi. Okay. Vậy thì, tôi cũng đã trích dẫn từ các paper khác. Không trực tiếp liên quan, nhưng bạn có paper về ACE cũng làm điều tương tự. Nhưng ACE không hoàn toàn tập trung vào, làm thế nào để nói nhỉ, khám phá (discovery) và quản lý (curation) nếu tôi nhớ không lầm. Có lẽ tôi cần làm mới lại trí nhớ của mình.

Người hỏi: Ý bạn là gì về sự khác biệt giữa kiến thức lĩnh vực (domain knowledge) và kiến thức chiến lược (strategic knowledge) ở đây?

Người trình bày: Okay. Về kiến thức chiến lược (strategic knowledge). Những gì ACE và các hệ thống tương tự đang làm là khi bạn cố gắng trò chuyện với một Trí tuệ nhân tạo (AI), bạn có thể thấy trong Claude Code và các hệ thống khác, nó cập nhật bộ nhớ (memory) của nó hoặc mối quan hệ (relationship) với những thứ bạn đã nói, phải không? Và từ lịch sử trò chuyện (chat history), nó hiểu ngữ cảnh quan trọng nhất mà nó cần ghi nhớ là gì. Vì vậy, khi bạn giao tiếp với nó, những cuộc trò chuyện vận hành (operational conversations) đó cùng với sự cải thiện của AI là điều họ đề xuất. Vậy thì đề xuất của tôi không dựa trên cuộc trò chuyện của bạn với một AI, mà dựa trên kiến thức lĩnh vực (domain knowledge) của bạn, vốn đã được ghi lại (documented).

Đảm Bảo Tác Nhân Chỉ Dẫn Đến Tài Liệu Phù Hợp và Quản lý Trạng thái Tài liệu

Người hỏi: Xin lỗi. Khi nói đến tài liệu từ xa (như Confluence), làm thế nào để bạn đảm bảo Tác nhân của mình chỉ trỏ đến tài liệu liên quan trong môi trường cục bộ của bạn?

Người trình bày: Okay, khi tôi viết một pipeline để trích xuất từ Confluence, nó cũng cho phép bạn cung cấp ngày tháng, và ai đã cập nhật lần cuối, kiểu như một bản phân tích (analytics) về không gian đó. Vì vậy, bạn có thể sử dụng nó để đặt một ngưỡng (threshold) kiểu như: "Okay, vào ngày cụ thể này, bất cứ thứ gì cũ hơn thì hãy coi đó là lỗi thời (outdated) và hãy cho tôi biết." Đừng chỉ coi nó là lỗi thời, bạn phải cho tôi biết, bởi vì đôi khi tài liệu có thể đã cũ (stale) rất lâu nhưng nó vẫn có thể là một tài liệu quan trọng. Vì vậy, nó sẽ cho bạn biết nhưng không đưa ra quyết định vào lúc này. Bạn là người quyết định cái nào đã cũ và cái nào không.

Người hỏi: Bạn không có một lớp trung gian nào để lưu trữ trạng thái "cũ" này trong repo à?

Người trình bày: Okay, khi nó được quản lý (curated) trong ngữ cảnh, nó cũng cập nhật ngày và trạng thái của tài liệu như cũ (stale), đang hoạt động (active) và sạch (clean). Vì vậy, nó cũng xem xét: "Okay, cái này đã cũ, tôi sẽ không chạm vào nó và tôi sẽ tìm kiếm bất kỳ tài liệu mới nào khác trong số này."

Quản lý Quyền Truy Cập

Người hỏi: Bạn có nghĩ về cách quản lý quyền truy cập không?

Người trình bày: Okay. Bởi vì nó không phải là một sản phẩm hay một giải pháp SaaS, mà về cơ bản chỉ là GitHub đối với tôi vào lúc này. Quyền hạn (permissions) và các vấn đề liên quan không khó để triển khai bởi vì GitHub cung cấp sẵn cho tôi quyền cấp phép cho những ai tôi muốn.

Quản lý Quyền Truy cập và Dữ liệu IP

ai có quyền đọc/ghi và ai có thể hợp nhất chúng. Nhưng nếu nó phát triển thành một sản phẩm, ví dụ như một context gap scanner (công cụ quét khoảng trống ngữ cảnh) như một sản phẩm, và tôi muốn bạn kiểm tra nó, thì lý do tôi sử dụng các cài đặt sẵn cho hội thảo này — mà không yêu cầu bạn tải lên tệp tin — là vì tôi không muốn lấy dữ liệu IP của bạn trong trường hợp này. Đúng không? Vì vậy, trừ khi nó trở thành một sản phẩm, bạn sẽ không gặp vấn đề gì với GitHub hay những thứ tương tự. Nhưng nếu bạn có một giải pháp SaaS cho điều này, thì vấn đề nằm ở cách giải pháp SaaS sẽ quản lý nó, đúng không? Hiện tại, cách tiếp cận không liên quan gì đến quyền truy cập. Cách bạn triển khai các quyền truy cập đó trên dữ liệu kiến thức là tùy thuộc vào bạn.

Mở Rộng Sang Công Cụ Tập Trung và Cơ Sở Hạ Tầng

Bạn đã cân nhắc sử dụng nó trên một số công cụ tập trung mà một công ty có thể dùng chưa? Chẳng hạn, một đội nền tảng có một CLI (giao diện dòng lệnh) mà các đội khác đang sử dụng, và giờ đây nó được sử dụng bởi các tác nhân khác nhau, đúng không? Các tác nhân cũng có thể nói: "Hành động này khả dụng cho một tài nguyên, nhưng tôi không muốn thực hiện 500 API call chỉ vì tôi có danh sách 500 tài nguyên." Sẽ rất tuyệt nếu công cụ có thể làm điều đó. Tôi không biết bạn đã cân nhắc điều này chưa. Tôi nghĩ đó là cách nó phải hoạt động trong một tổ chức: bạn cần có một giải pháp tập trung. Nhưng cách bạn thực hiện giải pháp đó là tùy thuộc vào tổ chức. Ví dụ, chúng ta đang làm việc theo phương pháp agile (phát triển linh hoạt), đúng không? Agile có thể được thực hiện bằng Scrum, Kanban hoặc Lean, v.v. Và bạn cũng có thể sử dụng các ứng dụng khác nhau để làm điều đó. Quy trình thì giống nhau, nhưng cách bạn làm, phương pháp bạn chọn và ứng dụng nào bạn chọn trong tổ chức là khác nhau. Tương tự, những gì chúng ta đã thảo luận là cách tiếp cận. Nếu bạn muốn áp dụng nó trong tổ chức, bạn có thể sử dụng cách tiếp cận đó và thực hiện theo bất kỳ cách nào bạn muốn. Ý tôi là với điều này, bạn có thể xác định các khoảng trống trong công cụ của bạn. Có thể sử dụng nó để xác định các khoảng trống trong công cụ của mình không? Khi bạn nói công cụ, ý bạn là tác nhân? Các công cụ nội bộ mà có thể một đội đang xây dựng cho phần còn lại của công ty? Cơ sở hạ tầng nói chung, đúng không? Có thể. Bạn có thể cho tôi một ví dụ về cách? Giả sử bạn xây dựng một loại lớp trừu tượng nào đó trên Kubernetes. Bạn không muốn các nhà phát triển của mình nhất thiết phải biết cách làm việc với nó. Sau đó, bạn có một CLI khác hoặc một cái gì đó tương tự, đúng không? Nhưng như tôi nói, có thể bạn nghĩ rằng họ sẽ phát hành từng ứng dụng tùy chỉnh hoặc ứng dụng doanh nghiệp của bạn một cách riêng lẻ. Nhưng một đội đã phát triển và sử dụng nhiều hơn thế, và đột nhiên họ có rất nhiều và không muốn thực hiện nhiều API call như vậy. Hoặc thậm chí tác nhân có thể nói: "Điều này không hiệu quả. Tôi muốn công cụ nội bộ này hoạt động theo một cách khác." Và theo cách đó, bạn có thể xác định khoảng trống trong công cụ hoặc cải thiện hiệu suất, giống như cách nó làm với tài liệu.

Mở Rộng Sang Quy Trình Kinh Doanh

Thực tế, nó có thể được mở rộng. Chúng ta cũng đã xem xét các quy trình kinh doanh, đúng không? Vì vậy, nó cũng có thể lập tài liệu quy trình kinh doanh. Quy trình kinh doanh thực chất là cách một quy trình trong ứng dụng vận hành và thực hiện các tác vụ. Do đó, bạn có thể mở rộng nó để tìm ra các khoảng trống trong quy trình kinh doanh hoặc cách nó hoạt động. Đó có thể là một sự mở rộng.

Xử lý Thay đổi và Trùng lặp

Làm thế nào để đảm bảo bạn nắm bắt được các thay đổi? [transcript bị gián đoạn] Khi tôi giới thiệu context gap scanner (công cụ quét khoảng trống ngữ cảnh), bạn cũng thấy một chỉ báo về sự trùng lặp, đúng không? Vì vậy, nếu hôm nay bạn có một tài liệu, ngày mai bạn có phiên bản 2.0 và một cái gì đó khác, thực tế nó sẽ tìm ra cùng một thông tin đang có trong ba tài liệu khác nhau. Nó cũng sẽ tìm thấy. Nếu bạn chỉ có một tài liệu và nó đã thay đổi, nó sẽ lấy phiên bản cập nhật mới nhất, bởi vì là một con người, bạn đã thay đổi nó, nên nó sẽ coi đó là nguồn thông tin đáng tin cậy, đúng không? Nhưng nếu bạn có ba phiên bản của cùng một tài liệu, đó là sự trùng lặp và nó sẽ gắn cờ là một bản sao.

Hiệu suất, Chi phí và Thông tin Sai lệch

Nhưng làm thế nào để bạn đảm bảo hiệu suất với một tài liệu 100.000 từ, chỉ thay đổi một từ? Bạn phải so sánh ba tài liệu đó. Những công cụ nào bạn sử dụng để đảm bảo điều đó? Tôi không hoàn toàn hiểu câu hỏi của bạn. Có phải bạn lo lắng về việc sử dụng mã thông báo? Việc sử dụng nhiều mã thông báo như vậy thì tiết kiệm chi phí như thế nào? Đúng vậy, chính xác là các thay đổi duy trì toàn bộ cơ sở dữ liệu đó. Câu hỏi của tôi là vì những gì bạn trình bày là một kịch bản lý tưởng, nơi bạn có một cái gì đó và sau đó bạn tái sử dụng nó. Nhưng một lúc nào đó, bạn sẽ có một nơi mà bạn giả vờ có khoảng trống đó, nhưng thực tế nó không chứa thông tin cập nhật, mà chứa thông tin sai. Vậy bạn muốn bảo tồn điều đó. À, được rồi. Nó có thể gắn cờ dựa trên thời gian tạo hoặc lần cập nhật cuối cùng. Bạn có thể đặt các bộ lọc như vậy. Nhưng giả sử bạn có một tài liệu mới nhất chứa thông tin sai. Bạn không biết điều đó, đúng không? Đúng vậy. Nhưng ví dụ, với tư cách là một con người, bạn đi và xem tài liệu, bạn bảo ai đó xem tài liệu, và người đó đã xem tài liệu, và theo tài liệu, điều này sẽ được triển khai theo cách này, người đó sẽ làm theo, đúng không? Đó không phải là vấn đề của tác nhân hay con người. Quá muộn. Ý tôi là bạn đã giải quyết được một vấn đề, và tác nhân đang cố gắng giả định, vì vậy nó đang giải quyết, nhưng giải pháp sai. Vậy bạn nói có một máy quét, tốt thôi. Bạn có chạy nó hàng ngày không? Nó sẽ tốn bao nhiêu? Bạn có thể có một điểm quy trình khác sẽ cố gắng xem lần cập nhật cuối cùng, cố gắng xem theo một nhịp độ nào đó để chạy một quy trình sẽ cập nhật kiến thức. Tuyệt vời. Nó sẽ tốn bao nhiêu? Ví dụ, bạn đang nói. Ít hơn so với việc tổ chức nhiều cuộc họp hàng ngày để giới thiệu người mới? Đó là một tuyên bố mạnh mẽ. Nhưng tôi không nghĩ nó sẽ tốn nhiều như vậy theo tiền đề của AI. Đúng vậy. Như tôi đã nói, khi tôi kiểm tra nó, không có tên miền nào vượt quá 100k mã thông báo. Vì vậy, tôi không nghĩ chúng ta sẽ, ví dụ, context gap scanner (công cụ quét khoảng trống ngữ cảnh) đúng không, tôi không nghĩ bạn phải chạy nó hàng ngày hay gì cả. Ngay cả khi bạn chạy hàng ngày, khoảng 100 mã thông báo và thực hiện một lần quét, ví dụ. Nếu bạn cố gắng bắt đầu truy cập tất cả chúng, tất cả các context gap scanner của bạn, tôi nghĩ bạn thậm chí không thể tiêu tốn 1 đô la. Nếu tôi không nhầm, nó đã có... Ồ, bạn đã sẵn sàng rồi. Được rồi, tôi sẽ hủy đăng ký bây giờ. Nhưng tôi sẽ quay lại và bảo vệ hai điều. Một là tài liệu hệ thống có tính chất tổng hợp, vì vậy tôi đồng ý với bạn. Về mặt mở rộng, bạn sẽ phải giải quyết câu hỏi này. Điều đó cũng sẽ phụ thuộc vào tốc độ thay đổi của dữ liệu. Tôi nghĩ không nhiều lắm, bạn sẽ đạt được khoảng 80%.

Chi tiết Đầu ra và Chuyển Giao Kiến Thức

Theo từng trường hợp sử dụng cụ thể. Còn câu hỏi nào khác không? Làm thế nào tôi biết được điều đó? Nó thực sự cố gắng trình bày chi tiết nhất có thể. Hiện tại, tôi chưa thực sự hiển thị mọi thứ mà nó đã làm, chỉ vì mục đích giao diện người dùng. Nhưng với mỗi ticket mà nó tìm thấy, nó sẽ viết khoảng 100 đến 150 dòng vào các file markdown và lưu trữ ở đâu đó. Điều đó cung cấp cho bạn nhiều chi tiết hơn trong trường hợp bạn muốn tìm hiểu. Vì vậy, trong bản demo, tôi chỉ đưa những yếu tố UX (trải nghiệm người dùng) đẹp mắt lên trên, nhưng bạn cũng có thông tin chi tiết tại phần kiểm thử. Có ai khác có câu hỏi không? Tôi có một câu hỏi được không? Vâng, chắc chắn rồi. Cứ tiếp tục. Dễ thôi, phải không? Nếu tôi dịch đúng, tuyên bố của bạn không phải là lấp đầy khoảng trống mà là khám phá chúng. Nhưng nếu bạn giới hạn phạm vi cho một nhóm trong vài tuần, bạn có thể làm được. Ý tôi là nếu bạn không cảm thấy nó và cứ tiếp tục hỏi những câu hỏi đó thì hợp lý, đúng không? Vì vậy, tại một thời điểm nào đó, bạn sẽ có một giá trị khác. Đúng vậy, bạn làm điều đó một lần trước, hoặc nhiều lần lúc đầu. Đầu tiên, hãy xem toàn bộ bức tranh về tình trạng của cơ sở kiến thức của bạn, sau đó khắc phục ở cấp độ đó, rồi bạn chuyển sang vận hành. Bạn vẫn có thể tiếp tục làm điều đó với tác nhân có kỹ năng. Đúng vậy. Và tôi nghĩ cùng một quy trình cung cấp kiến thức đó diễn ra khá thường xuyên khi một thành viên mới gia nhập tổ chức. Vậy liệu việc thay thế đó không chỉ là các cuộc gọi Zoom, chuyển giao chúng và sử dụng chúng làm nguồn không? Giả sử tất cả các cuộc gọi, hoặc tất cả các cuộc chuyển giao kiến thức, hoặc có thể là các buổi giới thiệu diễn ra, hoặc nhóm hoặc bất cứ điều gì mà thành viên mới tham gia hỏi câu hỏi và bạn có quyền truy cập vào điều đó. Được rồi. Vậy ý bạn là bạn cũng có thể cung cấp tất cả các bản ghi thay vì thực hiện chu trình? Ý bạn là điều đó cũng có thể được thực hiện nếu bạn chỉ có mọi lúc bạn có các cuộc thảo luận và mọi thứ đều được lập tài liệu, bản ghi cuộc họp? Nhưng tôi không nghĩ đó là trường hợp chung cho tất cả mọi người, ít nhất là... Nhưng dễ dàng hơn là tôi không biết, tôi không chắc. Tôi nghĩ lượng thời gian mọi người dành cho các nhóm nếu bạn sử dụng các bản ghi, thì đó thực sự là những cái có nhiều mã thông báo hơn. Có rất nhiều cuộc họp vô ích, các bản ghi thực sự. Hoàn toàn đồng ý, nhưng chỉ nén một và sau đó là một phần của cơ sở dữ liệu. Có thể lại tùy thuộc vào từng tổ chức, đúng không? Vậy bạn có thiên về các cuộc họp hơn, giải quyết vấn đề trong các cuộc trò chuyện và những cuộc trò chuyện đó có dữ liệu, hay Confluence của bạn hoặc những thứ tương tự có dữ liệu? Nếu bạn có, hãy sử dụng những bản ghi đó làm cơ sở kiến thức của bạn và đồng thời, việc nén thực sự hiệu quả, điều đó hữu ích hơn. Vâng. Có ai khác có câu hỏi không? Không. Mọi thứ đều ổn. Vậy thì, cảm ơn rất nhiều vì đã tham dự buổi này.