- Các tác nhân AI phức tạp, đặc biệt trong AI chuyên biệt, gặp thách thức lớn với các nhiệm vụ dài hạn do giới hạn cửa sổ ngữ cảnh và giao diện trò chuyện kém hiệu quả, dẫn đến trải nghiệm người dùng không tốt.
- Mục tiêu của các công ty AI chuyên biệt là hoàn thành công việc end-to-end; tuy nhiên, việc lập kế hoạch và xem xét công việc đã trở thành nút thắt cổ chai mới, đặc biệt với các nhiệm vụ khó xác minh theo Quy tắc của Người xác minh.
- Để cộng tác hiệu quả giữa con người và AI, cần vượt qua giao diện trò chuyện một chiều, phát triển các giao diện băng thông cao, bền vững và chuyên biệt theo ngành, đồng thời tăng cường sự tin cậy (qua phân tách nhiệm vụ, hàng rào bảo vệ) và kiểm soát (qua kỹ năng, khơi gợi thông tin) tác nhân.
Agents need more than a chat - Jacob Lauritzen, CTO Legora
- Các tác nhân AI phức tạp thường thất bại ở các nhiệm vụ dài hạn do giới hạn "cửa sổ ngữ cảnh" và cơ chế "nén ngữ cảnh", khiến chúng quên thông tin quan trọng và cần được con người can thiệp liên tục.
- Trong các công ty AI chuyên biệt, trọng tâm đã chuyển từ việc thực hiện công việc sang lập kế hoạch và xem xét công việc, vì đây là những "nút thắt cổ chai" mới trong quy trình làm việc phức tạp.
- Áp dụng "Quy tắc của Người xác minh": AI sẽ giải quyết hiệu quả các nhiệm vụ dễ giải quyết và dễ xác minh; đối với các nhiệm vụ khó xác minh (như chiến lược kiện tụng), cần các chiến lược đặc biệt.
- Tăng "sự tin cậy" của tác nhân bằng cách: phân tách các nhiệm vụ lớn thành các phần nhỏ hơn, dễ xác minh; thiết lập "hàng rào bảo vệ" để giới hạn phạm vi hoạt động của tác nhân; và tạo "cơ chế ủy quyền để xác minh" (ví dụ: so sánh với "hợp đồng vàng").
- Nâng cao "kiểm soát" của con người đối với tác nhân bằng cách tích hợp "kỹ năng" đã được mã hóa (để xử lý tình huống bất ngờ) và cơ chế "khơi gợi thông tin" (để tác nhân hỏi người dùng khi không chắc chắn), thay vì chỉ dựa vào lập kế hoạch ban đầu.
- Giao diện "chat" là "băng thông thấp", "một chiều" và không phù hợp để cộng tác với các tác nhân AI phức tạp xử lý "cây công việc" hoặc "DAG" lớn và đa chiều.
- Phát triển các "giao diện băng thông cao", "bền vững" và chuyên biệt theo ngành (như tài liệu cộng tác, quy trình đánh giá hợp đồng có cấu trúc) cho phép con người đưa ra phán đoán hiệu quả và nắm bắt nhanh chóng hành động của tác nhân.
- Không nên giới hạn các tác nhân AI trong ngôn ngữ con người; khuyến khích các giao diện trực quan và tương tác tận dụng khả năng phi ngôn ngữ của AI để thể hiện và quản lý công việc.
vertical AI— AI chuyên biệt theo ngànhagent— tác nhâncontext window— cửa sổ ngữ cảnhCompaction— Nén ngữ cảnh (hoặc giữ nguyênCompaction)bottleneck— nút thắt cổ chaiVerifier's Rule— Quy tắc của Người xác minhcontrol— kiểm soáttrust— sự tin cậyguardrails— hàng rào bảo vệhigh-bandwidth artifacts— hiện vật băng thông cao
Tuyệt vời. Bây giờ là 5 giờ chiều thứ Sáu. Chỉ còn tôi và hai người nữa ở phía sau bạn cùng với bia cuối tuần, nên tôi sẽ cố gắng nói nhanh một chút.
Giới thiệu về AI chuyên biệt và Tác nhân phức tạp
Hôm nay tôi ở đây để nói chuyện với các bạn về vertical AI (AI chuyên biệt theo ngành) và các tác nhân phức tạp, cũng như lý do tại sao tôi nghĩ chúng cần nhiều hơn là chỉ một giao diện trò chuyện. Nếu bạn đã từng làm việc với một tác nhân phức tạp, chạy trong thời gian dài, bạn có thể đã thử điều gì đó tương tự như thế này. Xin lỗi, phần này toàn màu trắng. Tôi có thể thấy ánh đèn chói mắt trên khuôn mặt của các bạn.
Thách thức hiện tại với các tác nhân AI phức tạp
Bạn yêu cầu nó: "Nghiên cứu gì đó. Soạn thảo một hợp đồng, không mắc lỗi." Và nó bắt đầu suy nghĩ. Nó bắt đầu đọc. Khởi chạy một loạt các tác nhân con. Thực hiện tìm kiếm web, ghi tệp. Khởi chạy thêm các tác nhân con. Đọc thêm. Ghi thêm tệp. Tiếp tục. Mất rất nhiều thời gian. Sau 30 phút, nó đưa cho bạn bản hợp đồng. Bạn xem qua. "Điều khoản ba có vẻ không đúng. Bạn có mắc lỗi ở đây không? Bạn có xem tài liệu khác không?" Bạn hoàn toàn đúng. Sau đó bạn thấy thông báo này: "Compaction." Đó là lúc bạn biết mình có thể bỏ cuộc. Nó sẽ quên mọi thứ. Nó đang ở trạng thái cửa sổ ngữ cảnh (context window) rộng lớn. Dù sao, nó vẫn tiếp tục. Nó cứ thế hoạt động. Và bạn sẽ làm một hợp đồng. Trông nó có vẻ, chỉ có điều khoản ba bị thay đổi thôi sao? Có lẽ không. Và thế là bạn sẽ rơi vào trạng thái này. Một trải nghiệm không mấy tuyệt vời.
Tên tôi là Jacob. Tôi là CTO của LaGora. Chúng tôi là một không gian làm việc AI cộng tác dành cho các công ty luật. Vì vậy, chúng tôi là một công ty vertical AI. Chúng tôi có hơn 1.000 khách hàng, tại hơn 50 thị trường. Chúng tôi đã huy động được một khoản tiền lớn. Chúng tôi đang phát triển cực kỳ nhanh chóng. Tôi được cho biết có lẽ là nhanh nhất trong lịch sử. Chúng tôi cũng đang tuyển dụng kỹ sư ở London. Vì vậy, trong trường hợp có ai quan tâm và muốn tham gia vào hành trình phát triển này, vui lòng nói chuyện với tôi sau buổi nói chuyện của tôi.
Mục tiêu của các công ty AI chuyên biệt
Mục tiêu của chúng tôi, và mục tiêu của hầu hết các công ty vertical AI, là làm cho các tác nhân hoàn thành ngày càng nhiều công việc phức tạp một cách end-to-end. Cách thực hiện điều đó đã thay đổi rất nhiều trong 6 đến 12 tháng qua vì có những kinh tế học sản xuất mới.
Trước đây, nếu bạn muốn hoàn thành công việc end-to-end, bạn sẽ tập trung vào việc thực hiện công việc. Đó sẽ là điều chính yếu: thực sự hoàn thành nó. Nhưng ngày nay, mọi thứ trông hơi khác một chút. Bởi vì hiện tại, việc lập kế hoạch công việc và xem xét công việc là nút thắt cổ chai (bottleneck) mới. Vì vậy, việc thực hiện công việc thực tế cực kỳ rẻ. Rất dễ thực hiện. Nhưng bây giờ bạn phải dành thời gian lập kế hoạch. Bạn phải thu thập các yêu cầu phi chức năng (non-functional requirements). Bạn phải có các thông số kỹ thuật (specs). Và bạn phải dành rất nhiều thời gian để xem xét công việc. Và nếu ai đã từng xem xét các PR (Pull Request) lớn trên GitHub, thì nó thực sự tệ. Nó cực kỳ đau đớn. Có lẽ nếu bạn là người rất "mê AI", bạn chỉ cần nhờ các tác nhân AI của mình xem xét công việc của chính chúng, không có sự tham gia của con người. Có thể nó hoạt động. Có thể không.
Quy tắc của Người xác minh
Và khi chúng ta nghĩ về việc hoàn thành công việc phức tạp, cả giai đoạn lập kế hoạch, giai đoạn thực hiện và giai đoạn xem xét, thì Quy tắc của Người xác minh (Verifier's Rule) là một cách tốt để suy nghĩ về công việc. Quy tắc của Người xác minh là một thuật ngữ do Jason đặt ra, trong đó nêu rõ rằng nếu một nhiệm vụ có thể giải quyết được và dễ xác minh, thì nó sẽ được AI giải quyết. Ông ấy chủ yếu nói về các mô hình nền tảng (foundational models). Vì vậy, nếu bạn có thể làm cho một thứ gì đó rất dễ xác minh, thì bạn có thể thực hiện trong các môi trường học tăng cường (RL environments). Bạn có thể huấn luyện hậu kỳ (post-train) nó. Nó sẽ giải quyết được. Tôi nghĩ điều này cũng áp dụng cho các tác nhân. Nếu bạn có thể làm cho một nhiệm vụ có thể xác minh được, bạn chỉ cần chạy một tác nhân trong một vòng lặp cho đến khi nó nói, "Này, bạn đã làm sai cái này. Làm ơn sửa nó." Và cuối cùng nó sẽ đạt được kết quả.
Ứng dụng Quy tắc Người xác minh trong các ngành
Các ngành công nghiệp khác nhau nằm ở những vị trí khác nhau trong phổ này. Nó phức tạp hơn một chút so với chỉ riêng điều này, bởi vì các vertical (ngành dọc) có các nhiệm vụ nằm ở những vị trí khác nhau trên phổ này.
Vì vậy, nếu bạn xem xét lĩnh vực pháp lý, chúng ta có thể kiểm tra các định nghĩa trong một hợp đồng. Rất dễ dàng. Dễ xác minh. Rất dễ thực hiện. Việc viết một hợp đồng rất dễ giải quyết, nhưng thực tế việc thực hiện nó lại khó xác minh. Bởi vì nếu bạn nghĩ về nó, khi bạn viết một hợp đồng, thời điểm duy nhất bạn có thể thực sự xác minh ngôn ngữ bạn sử dụng có hiệu quả hay không là khi nó ra tòa. Và một thẩm phán về cơ bản xác minh nó, nói cho chúng ta biết nó có tốt hay không. Vì vậy, điều đó thực sự khá phức tạp. Chiến lược kiện tụng (Litigation strategy) cũng cơ bản là không thể xác minh. Nếu bạn không biết kiện tụng (litigation) là gì, đó là khi bạn kiện ai đó hoặc ai đó kiện bạn. Tôi biết bây giờ chúng ta đang ở Châu Âu, nhưng người Mỹ thực sự rất thích làm điều này mọi lúc. Nhưng về cơ bản, nếu bạn hỏi năm luật sư, "Chiến lược đúng đắn cho trường hợp kiện tụng này là gì?", họ sẽ đưa ra những câu trả lời khác nhau. Và vì vậy không có sự thật khách quan, điều đó có nghĩa là về cơ bản là không thể xác minh. Rất khó để AI giải quyết. Tương tự, trong lập trình (coding), một số phần thực sự dễ dàng, như xây dựng một ứng dụng tiêu dùng thành công, nhưng rất khó xác minh.
Cộng tác giữa con người và Tác nhân: Kiểm soát và Sự tin cậy
Vì vậy, khi chúng ta nghĩ về điều này, chúng ta nghĩ về cách để con người tham gia vào những nơi thực sự quan trọng và để các tác nhân thực hiện công việc mà chúng ta có thể giao cho chúng. Có hai điều quan trọng cần suy nghĩ khi tác nhân và con người cộng tác (agent-human collaboration). Kiểm soát (Control) là điều đầu tiên. Kiểm soát là mức độ hiệu quả mà một con người có thể truyền tải kiến thức của mình vào công việc mà tác nhân đang thực hiện. Vậy làm thế nào tôi có thể điều hướng nó một cách hiệu quả? Kiểm soát là vấn đề về mức độ chúng ta cần xem xét. Vì vậy, nếu tôi có kiểm soát rất thấp, tôi sẽ xem xét mọi dấu vết tác nhân (tác nhân trace) và xem chính xác những gì nó đã làm. Nếu tôi có sự tin cậy (trust) rất thấp, nếu tôi có sự tin cậy rất cao, tôi sẽ không xem xét nó chút nào. Tùy thuộc vào vị trí nhiệm vụ trong biểu đồ, những điều khác nhau sẽ quan trọng.
Tăng cường sự tin cậy của Tác nhân
Làm thế nào để tăng sự tin cậy? Nếu bạn muốn tăng sự tin cậy, có một vài điều khác nhau bạn có thể làm. Đầu tiên, bạn có thể đưa một nhiệm vụ xuống thấp hơn trong phổ. Đây là một ví dụ từ lập trình (coding). Nếu bạn muốn triển khai một tính năng, bạn có thể cấp cho nó quyền truy cập trình duyệt (browser access). Bạn có thể thực hiện phát triển hướng kiểm thử (test-driven development). Khi đó, đột nhiên, đó thực sự là một nhiệm vụ có thể xác minh được, và nó sẽ làm tốt hơn nhiều. Có những điều tương tự bạn có thể làm trong tài chính (finance) và pháp lý (legal). Bạn cũng có thể làm một số điều tương tự. Chúng ta không có, hãy lấy ví dụ về hợp đồng trong pháp lý. Bạn không thể thực sự xác minh nó, nhưng bạn có thể tìm kiếm một cơ chế ủy quyền để xác minh (proxy for verification). Vì vậy, đối với các hợp đồng, bạn có thể xem xét các hợp đồng trước đó. Đây là những hợp đồng vàng (golden contracts) của chúng tôi. Chúng tôi biết chúng hoạt động tốt. Hãy thiết lập một bài kiểm tra: Hợp đồng mới có tương tự hợp đồng cũ không? Đó là một cơ chế ủy quyền để xác minh. Điều đó sẽ cho phép tác nhân của bạn làm việc tốt hơn nhiều.
Bạn cũng có thể phân tách nhiệm vụ (decompose tasks). Đây là ví dụ về việc viết một hợp đồng. Tôi có thể biến nó từ một nhiệm vụ thành một loạt các nhiệm vụ khác. Và tôi có thể để việc chọn một hồ sơ phong phú (rich profile), chọn tài liệu tiền lệ (precedent document), lập trường đàm phán (negotiation stance) cho con người. Nhưng tôi có thể cố gắng hoàn thành những việc khác ở những nơi dễ xác minh. Ví dụ, áp dụng định dạng: Làm cho nó trông giống như tất cả các hợp đồng khác của tôi. Áp dụng kiểm tra định nghĩa (definition checking), về cơ bản là đảm bảo tất cả các định nghĩa được sử dụng đều được định nghĩa. Loại công việc này bạn có thể xây dựng, và sau đó tác nhân về cơ bản có thể thực hiện tốt hơn nhiều.
Bạn cũng có thể thêm hàng rào bảo vệ (guardrails). Và hàng rào bảo vệ về cơ bản là cách để tăng sự tin cậy bằng cách giới hạn những gì tác nhân có thể làm. Vì vậy, thay vì có thể làm tất cả những điều này, bạn sẽ chỉ nói, "Bạn chỉ có thể làm những việc này." "Bạn chỉ có thể chỉnh sửa ba tệp này." "Bạn chỉ có thể đọc từ thư mục này." "Bạn chỉ có thể tìm kiếm trên các trang web này." Bằng cách giới hạn những gì nó có thể làm, về cơ bản bạn có được sự tin cậy cao hơn. Bởi vì bạn biết rằng nó sẽ không làm tất cả những điều kỳ lạ này. Một ví dụ về điều này, có lẽ ai cũng biết, là low-code (hoặc no-code). Nếu có sự tin cậy rất thấp, nó về cơ bản sẽ hỏi bạn mỗi khi nó muốn làm bất cứ điều gì, điều này khiến nó cực kỳ vô dụng. Và ở phía sự tin cậy cao của phổ, bạn chỉ cần đặt nó vào chế độ tự động (auto-mode), để nó tự thực hiện, và hy vọng rằng nó không xóa cơ sở dữ liệu sản xuất (prod database) của bạn.
Nâng cao khả năng kiểm soát Tác nhân
Sau đó là kiểm soát (control). Vậy làm thế nào để chúng ta tăng kiểm soát? Chà, nếu bạn nghĩ về công việc tác nhân phức tạp, bạn có thể hình dung nó như một cây công việc (tree of work), về cơ bản là một DAG (Biểu đồ có hướng không chu trình - Directed Acyclic Graph). Đây là một ví dụ mà tôi muốn viết một báo cáo về một loạt các hợp đồng lao động. Vì vậy, tác nhân sẽ nói, "Được rồi, hãy để tôi nghiên cứu tổ chức trước. Sau đó tôi muốn xem xét các hợp đồng. Và tôi sẽ xem xét một vài điều khác nhau cho từng hợp đồng. Và sau đó tôi sẽ soạn thảo một báo cáo vào cuối." Điều này có kiểm soát cực kỳ thấp. Bởi vì về cơ bản, tôi chỉ có thể áp đặt phán đoán của mình ở cấp độ gốc. Vì vậy, nó sẽ làm tất cả công việc này, và sau đó nó sẽ quay lại với tôi. Và sau đó tôi có thể cố gắng nói chuyện lại với nó. Và đó về cơ bản là ví dụ tôi đã đưa ra lúc đầu. Vì vậy, kiểm soát rất thấp.
Tiếp theo là lập kế hoạch (planning). Lập kế hoạch về cơ bản cho phép bạn điều hướng tác nhân ngay từ đầu và thống nhất về phương pháp tiếp cận. Và với lập kế hoạch ở đây, nó có thể nói, "Được rồi, bạn hoàn toàn nên thực hiện các bước này. Những điều này là chính xác. Đây là những tài liệu gần nhất mà bạn nên tìm kiếm. Đây là những gì bạn muốn xem xét." Vì vậy, đây là một bước tốt. Nó mang lại cho bạn nhiều kiểm soát hơn một chút. Dễ dàng hơn để áp đặt những gì bạn muốn nó làm. Vấn đề với lập kế hoạch là: Bạn về cơ bản phải làm tất cả công việc chỉ để biết phải làm gì. Tôi chắc chắn mọi người đã thử điều này trong flow-code. Bạn về cơ bản phải đi qua toàn bộ quá trình. Nó thực sự không hiệu quả. Mất rất nhiều thời gian và hỏi bạn rất nhiều câu hỏi. Và cuối cùng, về cơ bản là không thể để nó thực sự biết liệu nó có tất cả thông tin cần thiết hay không. Giả sử, đối với một trong những hợp đồng này, có một điều khoản đặc biệt (special clause). Nó sẽ không biết điều đó trong bước lập kế hoạch. Bạn không thể thực sự nói cho nó biết phải làm gì khi nó thấy điều đó, bởi vì nó chưa làm tất cả công việc. Về cơ bản, bạn có thể so sánh lập kế hoạch với việc làm việc với một đồng nghiệp đến gặp bạn, nói cho bạn biết về cách tiếp cận của họ, bạn thống nhất với họ, và sau đó bạn không bao giờ nghe tin gì từ họ nữa cho đến khi họ giao tài liệu cuối cùng. Đó không phải là một cách cộng tác thực sự tốt. Đây là một điều tốt chúng ta có ngay bây giờ, nhưng tôi không nghĩ lập kế hoạch sẽ tồn tại lâu dài.
Tác động của Kỹ năng và Khơi gợi thông tin
Sau đó chúng ta có kỹ năng (skills). Kỹ năng thực sự, thực sự, thực sự tốt. Chúng rất tốt vì kỹ năng cho phép bạn mã hóa phán đoán của con người vào về cơ bản là các nút công việc diễn ra ở đây. Vì vậy, tôi có thể nói, "Bất cứ khi nào bạn xem xét điều khoản bảo mật (confidentiality), bạn nên làm theo cách này." Và điều thực sự tốt về điều này là nó cho phép xử lý các tình huống bất ngờ (contingencies). Vì vậy, ở đây, tại một trong các điều khoản chấm dứt xem xét (reviewing termination clauses), chúng có vẻ đáng ngờ là bất hợp pháp (unlawful). Nhưng tôi đã có điều đó trong một kỹ năng, điều đó có nghĩa là bất cứ điều gì xảy ra khi nó thực sự thực hiện công việc, nó biết cách xử lý trường hợp đặc biệt đó. Bạn không thể thực sự làm điều này với lập kế hoạch. Ngoài ra còn có khám phá tiến bộ (progressive discovery), mà một lần nữa, thực sự tuyệt vời. Bất cứ điều gì xảy ra, nó biết nó sẽ nhận ra. Vấn đề là, bạn không có kỹ năng cho mọi thứ.
Bước tiếp theo là sử dụng khơi gợi (elicitation), có nghĩa là hỏi người dùng, hỏi chuyên gia về lĩnh vực đó. Vì vậy, bạn cũng có thể có kỹ năng. Nhưng sau đó thay vì bạn cung cấp tất cả thông tin, nó sẽ đến hỏi bạn. Nó sẽ nói, "Này, đây là điều tôi không biết cách xử lý, bạn muốn tôi làm gì?" Điều này rất hợp lý, trước hết. Điều bạn không muốn là bạn không muốn tác nhân bị chặn. Vì vậy, lý tưởng nhất, nếu bạn triển khai điều này, bạn sẽ nói với tác nhân, "Nếu bạn không chắc chắn về điều gì đó, hãy đưa ra quyết định, tự tháo gỡ khó khăn, nhưng hãy ghi lại điều này vào nhật ký quyết định (decision log)." Sau đó, con người nên xem xét nhật ký quyết định sau đó và đảo ngược các quyết định nếu cần.
Giới hạn của giao diện Chat cho công việc phức tạp
Bây giờ, nếu bạn hình dung cây công việc này lớn hơn 10 lần, 100 lần, bạn không muốn điều này trong chat. Bạn không muốn mở một chat, và sau đó nó dài vô tận. Bạn phải trả lời 50 câu hỏi. Bạn sẽ không biết phải trả lời gì. Bạn sẽ không thực sự có thể làm được điều đó vì bạn không có ngữ cảnh (context) phù hợp. Vì vậy, không phải chat. Chat là một chiều (one-dimensional). Nó là một giao diện băng thông thấp (low-bandwidth interface) và nó cố gắng thu gọn cây công việc này thành một chuỗi tuyến tính (linear thing) duy nhất.
Giao diện cộng tác hiệu quả hơn
Vậy, một giao diện (interface) tốt hơn là gì? Chà, tôi nghĩ con người và các tác nhân nên cộng tác (collaborate) trong các hiện vật băng thông cao (high-bandwidth artifacts). Tôi nghĩ họ cần làm việc trong những thứ thường mang tính lưu trữ bền vững (persistent). Và chúng sẽ trông khác nhau tùy theo từng ngành, từng vertical, tùy thuộc vào nhiệm vụ bạn đang giải quyết.
Cộng tác với Tài liệu và Tác nhân
Do đó, một ví dụ của chúng tôi là một tài liệu giống như một giao diện bền vững, nơi việc cộng tác có ý nghĩa. Đó là cách bạn cộng tác với đồng nghiệp của mình. Bạn có thể đánh dấu điều khoản ba, và nó sẽ chỉ thay đổi điều khoản ba. Bạn có thể thêm bình luận. Bạn có thể gắn thẻ các tác nhân của mình. Bạn có thể gắn thẻ các cộng tác viên của mình. Bạn có thể chuyển giao các phần của tài liệu cho các tác nhân đặc biệt.
Quy trình Đánh giá Hợp đồng Tự động
Một ví dụ khác là loại hình đánh giá của chúng tôi. Về cơ bản, tôi yêu cầu nó thực hiện việc xem xét hợp đồng mà tôi đã đề cập, và nó sẽ nói, được thôi, hãy để tôi khởi tạo một loại hình đánh giá, giống như một primitive đã biết mà người dùng của chúng tôi quen thuộc. Và nó trông như thế này. Sau đó, nó sẽ nói, tôi sẽ xem xét tất cả các hợp đồng, và tôi sẽ chỉ đánh dấu một vài mục cho bạn. Những mục mà tôi muốn bạn xử lý. Và sau đó tôi có thể vào đó, và tôi có thể nhanh chóng thấy vấn đề ở đâu. Vì vậy, nó có khả năng kiểm soát cao. Nó rất hiệu quả để tôi đưa ra nhận định. Và tôi cũng có thể rất nhanh chóng nắm bắt được tác nhân đã thực sự làm gì. Vì vậy, việc xem xét rất dễ dàng. Và sau khi tôi hoàn thành việc đó, tôi có thể khởi chạy phần còn lại của tác nhân.
Giới hạn của Ngôn ngữ và Tầm nhìn UI
Hiện tại, điều chúng tôi đang thấy nhiều là sự hội tụ của UI, về cơ bản đây là cuộc trò chuyện hậu kỳ và tuyến tính, trong vòng hai tuần qua, chúng tôi đã triển khai UI mới này. Nói rõ hơn, hộp trò chuyện làm đầu vào thì rất tuyệt. Tôi nghĩ nó cực kỳ linh hoạt. Nó cho phép bạn làm được nhiều việc. Nhưng bạn không muốn trò chuyện là chế độ cộng tác chính của mình với một tác nhân phức tạp.
Điều tốt ở đây là ngôn ngữ, về cơ bản, là giao diện phổ quát. Đó là thứ con người dùng để giao tiếp. Bạn có thể làm mọi thứ bằng giọng nói. Nhưng các tác nhân không phải là con người. Chỉ vài phút trước, tôi đã nói chuyện với một ứng viên tiềm năng cho LaGora. Và tôi đang mô tả sơ đồ tổ chức của chúng tôi. Và tôi bị hạn chế vì tôi chỉ có thể sử dụng ngôn ngữ. Tôi ước mình có thể vẽ sơ đồ tổ chức, và họ có thể tương tác với nó, và họ có thể sử dụng nó. Nhưng tôi không thể, vì tôi là con người, tôi bị giới hạn bởi ngôn ngữ. Nhưng các tác nhân không phải là con người. Và vì vậy chúng ta không nên giới hạn chúng trong ngôn ngữ con người. Cảm ơn.
TL;DR
- Các tác nhân AI phức tạp, đặc biệt trong AI chuyên biệt, gặp thách thức lớn với các nhiệm vụ dài hạn do giới hạn cửa sổ ngữ cảnh và giao diện trò chuyện kém hiệu quả, dẫn đến trải nghiệm người dùng không tốt.
- Mục tiêu của các công ty AI chuyên biệt là hoàn thành công việc end-to-end; tuy nhiên, việc lập kế hoạch và xem xét công việc đã trở thành nút thắt cổ chai mới, đặc biệt với các nhiệm vụ khó xác minh theo Quy tắc của Người xác minh.
- Để cộng tác hiệu quả giữa con người và AI, cần vượt qua giao diện trò chuyện một chiều, phát triển các giao diện băng thông cao, bền vững và chuyên biệt theo ngành, đồng thời tăng cường sự tin cậy (qua phân tách nhiệm vụ, hàng rào bảo vệ) và kiểm soát (qua kỹ năng, khơi gợi thông tin) tác nhân.
Điểm chính
- Các tác nhân AI phức tạp thường thất bại ở các nhiệm vụ dài hạn do giới hạn "cửa sổ ngữ cảnh" và cơ chế "nén ngữ cảnh", khiến chúng quên thông tin quan trọng và cần được con người can thiệp liên tục.
- Trong các công ty AI chuyên biệt, trọng tâm đã chuyển từ việc thực hiện công việc sang lập kế hoạch và xem xét công việc, vì đây là những "nút thắt cổ chai" mới trong quy trình làm việc phức tạp.
- Áp dụng "Quy tắc của Người xác minh": AI sẽ giải quyết hiệu quả các nhiệm vụ dễ giải quyết và dễ xác minh; đối với các nhiệm vụ khó xác minh (như chiến lược kiện tụng), cần các chiến lược đặc biệt.
- Tăng "sự tin cậy" của tác nhân bằng cách: phân tách các nhiệm vụ lớn thành các phần nhỏ hơn, dễ xác minh; thiết lập "hàng rào bảo vệ" để giới hạn phạm vi hoạt động của tác nhân; và tạo "cơ chế ủy quyền để xác minh" (ví dụ: so sánh với "hợp đồng vàng").
- Nâng cao "kiểm soát" của con người đối với tác nhân bằng cách tích hợp "kỹ năng" đã được mã hóa (để xử lý tình huống bất ngờ) và cơ chế "khơi gợi thông tin" (để tác nhân hỏi người dùng khi không chắc chắn), thay vì chỉ dựa vào lập kế hoạch ban đầu.
- Giao diện "chat" là "băng thông thấp", "một chiều" và không phù hợp để cộng tác với các tác nhân AI phức tạp xử lý "cây công việc" hoặc "DAG" lớn và đa chiều.
- Phát triển các "giao diện băng thông cao", "bền vững" và chuyên biệt theo ngành (như tài liệu cộng tác, quy trình đánh giá hợp đồng có cấu trúc) cho phép con người đưa ra phán đoán hiệu quả và nắm bắt nhanh chóng hành động của tác nhân.
- Không nên giới hạn các tác nhân AI trong ngôn ngữ con người; khuyến khích các giao diện trực quan và tương tác tận dụng khả năng phi ngôn ngữ của AI để thể hiện và quản lý công việc.
Từ vựng
vertical AI— AI chuyên biệt theo ngànhagent— tác nhâncontext window— cửa sổ ngữ cảnhCompaction— Nén ngữ cảnh (hoặc giữ nguyênCompaction)bottleneck— nút thắt cổ chaiVerifier's Rule— Quy tắc của Người xác minhcontrol— kiểm soáttrust— sự tin cậyguardrails— hàng rào bảo vệhigh-bandwidth artifacts— hiện vật băng thông cao
Nội dung chi tiết
Tuyệt vời. Bây giờ là 5 giờ chiều thứ Sáu. Chỉ còn tôi và hai người nữa ở phía sau bạn cùng với bia cuối tuần, nên tôi sẽ cố gắng nói nhanh một chút.
Giới thiệu về AI chuyên biệt và Tác nhân phức tạp
Hôm nay tôi ở đây để nói chuyện với các bạn về vertical AI (AI chuyên biệt theo ngành) và các tác nhân phức tạp, cũng như lý do tại sao tôi nghĩ chúng cần nhiều hơn là chỉ một giao diện trò chuyện. Nếu bạn đã từng làm việc với một tác nhân phức tạp, chạy trong thời gian dài, bạn có thể đã thử điều gì đó tương tự như thế này. Xin lỗi, phần này toàn màu trắng. Tôi có thể thấy ánh đèn chói mắt trên khuôn mặt của các bạn.
Thách thức hiện tại với các tác nhân AI phức tạp
Bạn yêu cầu nó: "Nghiên cứu gì đó. Soạn thảo một hợp đồng, không mắc lỗi." Và nó bắt đầu suy nghĩ. Nó bắt đầu đọc. Khởi chạy một loạt các tác nhân con. Thực hiện tìm kiếm web, ghi tệp. Khởi chạy thêm các tác nhân con. Đọc thêm. Ghi thêm tệp. Tiếp tục. Mất rất nhiều thời gian. Sau 30 phút, nó đưa cho bạn bản hợp đồng. Bạn xem qua. "Điều khoản ba có vẻ không đúng. Bạn có mắc lỗi ở đây không? Bạn có xem tài liệu khác không?" Bạn hoàn toàn đúng. Sau đó bạn thấy thông báo này: "Compaction." Đó là lúc bạn biết mình có thể bỏ cuộc. Nó sẽ quên mọi thứ. Nó đang ở trạng thái cửa sổ ngữ cảnh (context window) rộng lớn. Dù sao, nó vẫn tiếp tục. Nó cứ thế hoạt động. Và bạn sẽ làm một hợp đồng. Trông nó có vẻ, chỉ có điều khoản ba bị thay đổi thôi sao? Có lẽ không. Và thế là bạn sẽ rơi vào trạng thái này. Một trải nghiệm không mấy tuyệt vời.
Tên tôi là Jacob. Tôi là CTO của LaGora. Chúng tôi là một không gian làm việc AI cộng tác dành cho các công ty luật. Vì vậy, chúng tôi là một công ty vertical AI. Chúng tôi có hơn 1.000 khách hàng, tại hơn 50 thị trường. Chúng tôi đã huy động được một khoản tiền lớn. Chúng tôi đang phát triển cực kỳ nhanh chóng. Tôi được cho biết có lẽ là nhanh nhất trong lịch sử. Chúng tôi cũng đang tuyển dụng kỹ sư ở London. Vì vậy, trong trường hợp có ai quan tâm và muốn tham gia vào hành trình phát triển này, vui lòng nói chuyện với tôi sau buổi nói chuyện của tôi.
Mục tiêu của các công ty AI chuyên biệt
Mục tiêu của chúng tôi, và mục tiêu của hầu hết các công ty vertical AI, là làm cho các tác nhân hoàn thành ngày càng nhiều công việc phức tạp một cách end-to-end. Cách thực hiện điều đó đã thay đổi rất nhiều trong 6 đến 12 tháng qua vì có những kinh tế học sản xuất mới.
Trước đây, nếu bạn muốn hoàn thành công việc end-to-end, bạn sẽ tập trung vào việc thực hiện công việc. Đó sẽ là điều chính yếu: thực sự hoàn thành nó. Nhưng ngày nay, mọi thứ trông hơi khác một chút. Bởi vì hiện tại, việc lập kế hoạch công việc và xem xét công việc là nút thắt cổ chai (bottleneck) mới. Vì vậy, việc thực hiện công việc thực tế cực kỳ rẻ. Rất dễ thực hiện. Nhưng bây giờ bạn phải dành thời gian lập kế hoạch. Bạn phải thu thập các yêu cầu phi chức năng (non-functional requirements). Bạn phải có các thông số kỹ thuật (specs). Và bạn phải dành rất nhiều thời gian để xem xét công việc. Và nếu ai đã từng xem xét các PR (Pull Request) lớn trên GitHub, thì nó thực sự tệ. Nó cực kỳ đau đớn. Có lẽ nếu bạn là người rất "mê AI", bạn chỉ cần nhờ các tác nhân AI của mình xem xét công việc của chính chúng, không có sự tham gia của con người. Có thể nó hoạt động. Có thể không.
Quy tắc của Người xác minh
Và khi chúng ta nghĩ về việc hoàn thành công việc phức tạp, cả giai đoạn lập kế hoạch, giai đoạn thực hiện và giai đoạn xem xét, thì Quy tắc của Người xác minh (Verifier's Rule) là một cách tốt để suy nghĩ về công việc. Quy tắc của Người xác minh là một thuật ngữ do Jason đặt ra, trong đó nêu rõ rằng nếu một nhiệm vụ có thể giải quyết được và dễ xác minh, thì nó sẽ được AI giải quyết. Ông ấy chủ yếu nói về các mô hình nền tảng (foundational models). Vì vậy, nếu bạn có thể làm cho một thứ gì đó rất dễ xác minh, thì bạn có thể thực hiện trong các môi trường học tăng cường (RL environments). Bạn có thể huấn luyện hậu kỳ (post-train) nó. Nó sẽ giải quyết được. Tôi nghĩ điều này cũng áp dụng cho các tác nhân. Nếu bạn có thể làm cho một nhiệm vụ có thể xác minh được, bạn chỉ cần chạy một tác nhân trong một vòng lặp cho đến khi nó nói, "Này, bạn đã làm sai cái này. Làm ơn sửa nó." Và cuối cùng nó sẽ đạt được kết quả.
Ứng dụng Quy tắc Người xác minh trong các ngành
Các ngành công nghiệp khác nhau nằm ở những vị trí khác nhau trong phổ này. Nó phức tạp hơn một chút so với chỉ riêng điều này, bởi vì các vertical (ngành dọc) có các nhiệm vụ nằm ở những vị trí khác nhau trên phổ này.
Vì vậy, nếu bạn xem xét lĩnh vực pháp lý, chúng ta có thể kiểm tra các định nghĩa trong một hợp đồng. Rất dễ dàng. Dễ xác minh. Rất dễ thực hiện. Việc viết một hợp đồng rất dễ giải quyết, nhưng thực tế việc thực hiện nó lại khó xác minh. Bởi vì nếu bạn nghĩ về nó, khi bạn viết một hợp đồng, thời điểm duy nhất bạn có thể thực sự xác minh ngôn ngữ bạn sử dụng có hiệu quả hay không là khi nó ra tòa. Và một thẩm phán về cơ bản xác minh nó, nói cho chúng ta biết nó có tốt hay không. Vì vậy, điều đó thực sự khá phức tạp. Chiến lược kiện tụng (Litigation strategy) cũng cơ bản là không thể xác minh. Nếu bạn không biết kiện tụng (litigation) là gì, đó là khi bạn kiện ai đó hoặc ai đó kiện bạn. Tôi biết bây giờ chúng ta đang ở Châu Âu, nhưng người Mỹ thực sự rất thích làm điều này mọi lúc. Nhưng về cơ bản, nếu bạn hỏi năm luật sư, "Chiến lược đúng đắn cho trường hợp kiện tụng này là gì?", họ sẽ đưa ra những câu trả lời khác nhau. Và vì vậy không có sự thật khách quan, điều đó có nghĩa là về cơ bản là không thể xác minh. Rất khó để AI giải quyết. Tương tự, trong lập trình (coding), một số phần thực sự dễ dàng, như xây dựng một ứng dụng tiêu dùng thành công, nhưng rất khó xác minh.
Cộng tác giữa con người và Tác nhân: Kiểm soát và Sự tin cậy
Vì vậy, khi chúng ta nghĩ về điều này, chúng ta nghĩ về cách để con người tham gia vào những nơi thực sự quan trọng và để các tác nhân thực hiện công việc mà chúng ta có thể giao cho chúng. Có hai điều quan trọng cần suy nghĩ khi tác nhân và con người cộng tác (agent-human collaboration). Kiểm soát (Control) là điều đầu tiên. Kiểm soát là mức độ hiệu quả mà một con người có thể truyền tải kiến thức của mình vào công việc mà tác nhân đang thực hiện. Vậy làm thế nào tôi có thể điều hướng nó một cách hiệu quả? Kiểm soát là vấn đề về mức độ chúng ta cần xem xét. Vì vậy, nếu tôi có kiểm soát rất thấp, tôi sẽ xem xét mọi dấu vết tác nhân (tác nhân trace) và xem chính xác những gì nó đã làm. Nếu tôi có sự tin cậy (trust) rất thấp, nếu tôi có sự tin cậy rất cao, tôi sẽ không xem xét nó chút nào. Tùy thuộc vào vị trí nhiệm vụ trong biểu đồ, những điều khác nhau sẽ quan trọng.
Tăng cường sự tin cậy của Tác nhân
Làm thế nào để tăng sự tin cậy? Nếu bạn muốn tăng sự tin cậy, có một vài điều khác nhau bạn có thể làm. Đầu tiên, bạn có thể đưa một nhiệm vụ xuống thấp hơn trong phổ. Đây là một ví dụ từ lập trình (coding). Nếu bạn muốn triển khai một tính năng, bạn có thể cấp cho nó quyền truy cập trình duyệt (browser access). Bạn có thể thực hiện phát triển hướng kiểm thử (test-driven development). Khi đó, đột nhiên, đó thực sự là một nhiệm vụ có thể xác minh được, và nó sẽ làm tốt hơn nhiều. Có những điều tương tự bạn có thể làm trong tài chính (finance) và pháp lý (legal). Bạn cũng có thể làm một số điều tương tự. Chúng ta không có, hãy lấy ví dụ về hợp đồng trong pháp lý. Bạn không thể thực sự xác minh nó, nhưng bạn có thể tìm kiếm một cơ chế ủy quyền để xác minh (proxy for verification). Vì vậy, đối với các hợp đồng, bạn có thể xem xét các hợp đồng trước đó. Đây là những hợp đồng vàng (golden contracts) của chúng tôi. Chúng tôi biết chúng hoạt động tốt. Hãy thiết lập một bài kiểm tra: Hợp đồng mới có tương tự hợp đồng cũ không? Đó là một cơ chế ủy quyền để xác minh. Điều đó sẽ cho phép tác nhân của bạn làm việc tốt hơn nhiều.
Bạn cũng có thể phân tách nhiệm vụ (decompose tasks). Đây là ví dụ về việc viết một hợp đồng. Tôi có thể biến nó từ một nhiệm vụ thành một loạt các nhiệm vụ khác. Và tôi có thể để việc chọn một hồ sơ phong phú (rich profile), chọn tài liệu tiền lệ (precedent document), lập trường đàm phán (negotiation stance) cho con người. Nhưng tôi có thể cố gắng hoàn thành những việc khác ở những nơi dễ xác minh. Ví dụ, áp dụng định dạng: Làm cho nó trông giống như tất cả các hợp đồng khác của tôi. Áp dụng kiểm tra định nghĩa (definition checking), về cơ bản là đảm bảo tất cả các định nghĩa được sử dụng đều được định nghĩa. Loại công việc này bạn có thể xây dựng, và sau đó tác nhân về cơ bản có thể thực hiện tốt hơn nhiều.
Bạn cũng có thể thêm hàng rào bảo vệ (guardrails). Và hàng rào bảo vệ về cơ bản là cách để tăng sự tin cậy bằng cách giới hạn những gì tác nhân có thể làm. Vì vậy, thay vì có thể làm tất cả những điều này, bạn sẽ chỉ nói, "Bạn chỉ có thể làm những việc này." "Bạn chỉ có thể chỉnh sửa ba tệp này." "Bạn chỉ có thể đọc từ thư mục này." "Bạn chỉ có thể tìm kiếm trên các trang web này." Bằng cách giới hạn những gì nó có thể làm, về cơ bản bạn có được sự tin cậy cao hơn. Bởi vì bạn biết rằng nó sẽ không làm tất cả những điều kỳ lạ này. Một ví dụ về điều này, có lẽ ai cũng biết, là low-code (hoặc no-code). Nếu có sự tin cậy rất thấp, nó về cơ bản sẽ hỏi bạn mỗi khi nó muốn làm bất cứ điều gì, điều này khiến nó cực kỳ vô dụng. Và ở phía sự tin cậy cao của phổ, bạn chỉ cần đặt nó vào chế độ tự động (auto-mode), để nó tự thực hiện, và hy vọng rằng nó không xóa cơ sở dữ liệu sản xuất (prod database) của bạn.
Nâng cao khả năng kiểm soát Tác nhân
Sau đó là kiểm soát (control). Vậy làm thế nào để chúng ta tăng kiểm soát? Chà, nếu bạn nghĩ về công việc tác nhân phức tạp, bạn có thể hình dung nó như một cây công việc (tree of work), về cơ bản là một DAG (Biểu đồ có hướng không chu trình - Directed Acyclic Graph). Đây là một ví dụ mà tôi muốn viết một báo cáo về một loạt các hợp đồng lao động. Vì vậy, tác nhân sẽ nói, "Được rồi, hãy để tôi nghiên cứu tổ chức trước. Sau đó tôi muốn xem xét các hợp đồng. Và tôi sẽ xem xét một vài điều khác nhau cho từng hợp đồng. Và sau đó tôi sẽ soạn thảo một báo cáo vào cuối." Điều này có kiểm soát cực kỳ thấp. Bởi vì về cơ bản, tôi chỉ có thể áp đặt phán đoán của mình ở cấp độ gốc. Vì vậy, nó sẽ làm tất cả công việc này, và sau đó nó sẽ quay lại với tôi. Và sau đó tôi có thể cố gắng nói chuyện lại với nó. Và đó về cơ bản là ví dụ tôi đã đưa ra lúc đầu. Vì vậy, kiểm soát rất thấp.
Tiếp theo là lập kế hoạch (planning). Lập kế hoạch về cơ bản cho phép bạn điều hướng tác nhân ngay từ đầu và thống nhất về phương pháp tiếp cận. Và với lập kế hoạch ở đây, nó có thể nói, "Được rồi, bạn hoàn toàn nên thực hiện các bước này. Những điều này là chính xác. Đây là những tài liệu gần nhất mà bạn nên tìm kiếm. Đây là những gì bạn muốn xem xét." Vì vậy, đây là một bước tốt. Nó mang lại cho bạn nhiều kiểm soát hơn một chút. Dễ dàng hơn để áp đặt những gì bạn muốn nó làm. Vấn đề với lập kế hoạch là: Bạn về cơ bản phải làm tất cả công việc chỉ để biết phải làm gì. Tôi chắc chắn mọi người đã thử điều này trong flow-code. Bạn về cơ bản phải đi qua toàn bộ quá trình. Nó thực sự không hiệu quả. Mất rất nhiều thời gian và hỏi bạn rất nhiều câu hỏi. Và cuối cùng, về cơ bản là không thể để nó thực sự biết liệu nó có tất cả thông tin cần thiết hay không. Giả sử, đối với một trong những hợp đồng này, có một điều khoản đặc biệt (special clause). Nó sẽ không biết điều đó trong bước lập kế hoạch. Bạn không thể thực sự nói cho nó biết phải làm gì khi nó thấy điều đó, bởi vì nó chưa làm tất cả công việc. Về cơ bản, bạn có thể so sánh lập kế hoạch với việc làm việc với một đồng nghiệp đến gặp bạn, nói cho bạn biết về cách tiếp cận của họ, bạn thống nhất với họ, và sau đó bạn không bao giờ nghe tin gì từ họ nữa cho đến khi họ giao tài liệu cuối cùng. Đó không phải là một cách cộng tác thực sự tốt. Đây là một điều tốt chúng ta có ngay bây giờ, nhưng tôi không nghĩ lập kế hoạch sẽ tồn tại lâu dài.
Tác động của Kỹ năng và Khơi gợi thông tin
Sau đó chúng ta có kỹ năng (skills). Kỹ năng thực sự, thực sự, thực sự tốt. Chúng rất tốt vì kỹ năng cho phép bạn mã hóa phán đoán của con người vào về cơ bản là các nút công việc diễn ra ở đây. Vì vậy, tôi có thể nói, "Bất cứ khi nào bạn xem xét điều khoản bảo mật (confidentiality), bạn nên làm theo cách này." Và điều thực sự tốt về điều này là nó cho phép xử lý các tình huống bất ngờ (contingencies). Vì vậy, ở đây, tại một trong các điều khoản chấm dứt xem xét (reviewing termination clauses), chúng có vẻ đáng ngờ là bất hợp pháp (unlawful). Nhưng tôi đã có điều đó trong một kỹ năng, điều đó có nghĩa là bất cứ điều gì xảy ra khi nó thực sự thực hiện công việc, nó biết cách xử lý trường hợp đặc biệt đó. Bạn không thể thực sự làm điều này với lập kế hoạch. Ngoài ra còn có khám phá tiến bộ (progressive discovery), mà một lần nữa, thực sự tuyệt vời. Bất cứ điều gì xảy ra, nó biết nó sẽ nhận ra. Vấn đề là, bạn không có kỹ năng cho mọi thứ.
Bước tiếp theo là sử dụng khơi gợi (elicitation), có nghĩa là hỏi người dùng, hỏi chuyên gia về lĩnh vực đó. Vì vậy, bạn cũng có thể có kỹ năng. Nhưng sau đó thay vì bạn cung cấp tất cả thông tin, nó sẽ đến hỏi bạn. Nó sẽ nói, "Này, đây là điều tôi không biết cách xử lý, bạn muốn tôi làm gì?" Điều này rất hợp lý, trước hết. Điều bạn không muốn là bạn không muốn tác nhân bị chặn. Vì vậy, lý tưởng nhất, nếu bạn triển khai điều này, bạn sẽ nói với tác nhân, "Nếu bạn không chắc chắn về điều gì đó, hãy đưa ra quyết định, tự tháo gỡ khó khăn, nhưng hãy ghi lại điều này vào nhật ký quyết định (decision log)." Sau đó, con người nên xem xét nhật ký quyết định sau đó và đảo ngược các quyết định nếu cần.
Giới hạn của giao diện Chat cho công việc phức tạp
Bây giờ, nếu bạn hình dung cây công việc này lớn hơn 10 lần, 100 lần, bạn không muốn điều này trong chat. Bạn không muốn mở một chat, và sau đó nó dài vô tận. Bạn phải trả lời 50 câu hỏi. Bạn sẽ không biết phải trả lời gì. Bạn sẽ không thực sự có thể làm được điều đó vì bạn không có ngữ cảnh (context) phù hợp. Vì vậy, không phải chat. Chat là một chiều (one-dimensional). Nó là một giao diện băng thông thấp (low-bandwidth interface) và nó cố gắng thu gọn cây công việc này thành một chuỗi tuyến tính (linear thing) duy nhất.
Giao diện cộng tác hiệu quả hơn
Vậy, một giao diện (interface) tốt hơn là gì? Chà, tôi nghĩ con người và các tác nhân nên cộng tác (collaborate) trong các hiện vật băng thông cao (high-bandwidth artifacts). Tôi nghĩ họ cần làm việc trong những thứ thường mang tính lưu trữ bền vững (persistent). Và chúng sẽ trông khác nhau tùy theo từng ngành, từng vertical, tùy thuộc vào nhiệm vụ bạn đang giải quyết.
Cộng tác với Tài liệu và Tác nhân
Do đó, một ví dụ của chúng tôi là một tài liệu giống như một giao diện bền vững, nơi việc cộng tác có ý nghĩa. Đó là cách bạn cộng tác với đồng nghiệp của mình. Bạn có thể đánh dấu điều khoản ba, và nó sẽ chỉ thay đổi điều khoản ba. Bạn có thể thêm bình luận. Bạn có thể gắn thẻ các tác nhân của mình. Bạn có thể gắn thẻ các cộng tác viên của mình. Bạn có thể chuyển giao các phần của tài liệu cho các tác nhân đặc biệt.
Quy trình Đánh giá Hợp đồng Tự động
Một ví dụ khác là loại hình đánh giá của chúng tôi. Về cơ bản, tôi yêu cầu nó thực hiện việc xem xét hợp đồng mà tôi đã đề cập, và nó sẽ nói, được thôi, hãy để tôi khởi tạo một loại hình đánh giá, giống như một primitive đã biết mà người dùng của chúng tôi quen thuộc. Và nó trông như thế này. Sau đó, nó sẽ nói, tôi sẽ xem xét tất cả các hợp đồng, và tôi sẽ chỉ đánh dấu một vài mục cho bạn. Những mục mà tôi muốn bạn xử lý. Và sau đó tôi có thể vào đó, và tôi có thể nhanh chóng thấy vấn đề ở đâu. Vì vậy, nó có khả năng kiểm soát cao. Nó rất hiệu quả để tôi đưa ra nhận định. Và tôi cũng có thể rất nhanh chóng nắm bắt được tác nhân đã thực sự làm gì. Vì vậy, việc xem xét rất dễ dàng. Và sau khi tôi hoàn thành việc đó, tôi có thể khởi chạy phần còn lại của tác nhân.
Giới hạn của Ngôn ngữ và Tầm nhìn UI
Hiện tại, điều chúng tôi đang thấy nhiều là sự hội tụ của UI, về cơ bản đây là cuộc trò chuyện hậu kỳ và tuyến tính, trong vòng hai tuần qua, chúng tôi đã triển khai UI mới này. Nói rõ hơn, hộp trò chuyện làm đầu vào thì rất tuyệt. Tôi nghĩ nó cực kỳ linh hoạt. Nó cho phép bạn làm được nhiều việc. Nhưng bạn không muốn trò chuyện là chế độ cộng tác chính của mình với một tác nhân phức tạp.
Điều tốt ở đây là ngôn ngữ, về cơ bản, là giao diện phổ quát. Đó là thứ con người dùng để giao tiếp. Bạn có thể làm mọi thứ bằng giọng nói. Nhưng các tác nhân không phải là con người. Chỉ vài phút trước, tôi đã nói chuyện với một ứng viên tiềm năng cho LaGora. Và tôi đang mô tả sơ đồ tổ chức của chúng tôi. Và tôi bị hạn chế vì tôi chỉ có thể sử dụng ngôn ngữ. Tôi ước mình có thể vẽ sơ đồ tổ chức, và họ có thể tương tác với nó, và họ có thể sử dụng nó. Nhưng tôi không thể, vì tôi là con người, tôi bị giới hạn bởi ngôn ngữ. Nhưng các tác nhân không phải là con người. Và vì vậy chúng ta không nên giới hạn chúng trong ngôn ngữ con người. Cảm ơn.