Chatbot thực sự hoạt động thế nào: Quy tắc, truy xuất, LLM, công cụ và chuyển tiếp cho con người

Một cuộc trò chuyện với chatbot có thể diễn ra dễ dàng cho đến lúc nó thất bại. Bạn hỏi một kiện hàng ở đâu. Bot lặp lại chính sách giao hàng chung. Bạn cung cấp số đơn hàng. Nó lại hỏi số đơn hàng. Sau ba vòng lặp, bong bóng trò chuyện nhỏ hứa hẹn sự tiện lợi đã trở thành một cánh cửa khóa giữa bạn và câu trả lời.

Trải nghiệm ngược lại gần như vô hình. Chatbot nhận ra rằng bạn muốn theo dõi đơn hàng, nắm bắt đúng số, kiểm tra hồ sơ hiện tại, giải thích kết quả trong một câu, và cung cấp một người nếu trường hợp không bình thường. Sự khác biệt không chỉ đơn giản là một bot có một trí tuệ nhân tạo cao hơn. Mà là một hệ thống trò chuyện có nhiệm vụ rõ ràng hơn, trạng thái tốt hơn, công cụ đáng tin cậy, ranh giới an toàn hơn và cách khôi phục được lập kế hoạch.

Hướng dẫn này nhìn sâu vào phía sau bong bóng chat. Nó giải thích các loại chatbot chính, theo dõi một tin nhắn qua một kiến trúc thực, và chỉ ra lý do tại sao ngôn ngữ trôi chảy chỉ là một phần của cuộc trò chuyện đáng tin cậy.

Chatbot là gì?

Chatbot là phần mềm trao đổi tin nhắn với con người thông qua văn bản, giọng nói hoặc kênh hội thoại khác. Nó một đầu vào, quyết định những gì nên xảy ra tiếp theo, và trả về phản hồi hoặc hành động. Định nghĩa rộng này bao gồm một menu cố định trong widget hỗ trợ, một luồng giọng nói thu thập số tài khoản, một trợ lý kiến thức tìm kiếm tài liệu, và một hệ thống mô hình ngôn ngữ có thể soạn thảo phản hồi mở.

Cuộc trò chuyện là giao diện, không phải công nghệ nền tảng. Hai chatbot có thể trông giống nhau trong khi hoạt động theo những cách hoàn toàn khác nhau. Một chatbot theo cây quyết định. Một cái khác khớp một ý định và gọi webhook. Một cái thứ ba truy xuất tài liệu và yêu cầu một mô hình ngôn ngữ lớn viết câu trả lời. Các hệ thống hữu ích nhất thường kết hợp nhiều phương pháp.

Một bài học từ ELIZA, sáu mươi năm sau

Vào năm 1966, Joseph Weizenbaum đã xuất bản ELIZA, một chương trình cho hội thoại ngôn ngữ tự nhiên. Kịch bản DOCTOR nổi tiếng của nó sử dụng các mẫu và biến đổi để chuyển một phần phát biểu của người dùng thành phản hồi. Một câu như “Tôi không vui” có thể được khớp, sắp xếp lại và phản chiếu thành câu hỏi. Cuộc trao đổi có thể cảm giác attentive mặc dù chương trình biết rất ít về cuộc sống của người đó và không có mô hình ngôn ngữ hiện đại.

ELIZA vẫn còn có ý nghĩa vì con người phản ứng với ngôn ngữ theo cách xã hội. Một câu hỏi đúng lúc, một cụm từ cảm thông, hoặc một câu trả lời tự tin có thể tạo ra ấn tượng về sự hiểu biết vượt qua cơ chế bên dưới. Các mô hình hiện đại có năng lực cao hơn nhiều, nhưng giao diện vẫn mời gọi cùng một sai lầm: đánh giá những gì một hệ thống biết dựa trên mức độ tự nhiên của nó.

Do đó, một chatbot chuyên nghiệp nên tạo được niềm tin thông qua việc hoàn thành nhiệm vụ đúng cách, các giới hạn có thể thấy được, và các lỗi có thể khôi phục. Tính cách cá nhân có thể cải thiện tương tác. Nó không thể thay thế việc truy cập thông tin đúng hoặc một quy trình an toàn.

Ba kiến trúc chính của chatbot

Chatbot dễ hiểu hơn khi chúng ta tách ba nhóm kiến trúc. Đây không phải là những thế hệ nghiêm ngặt mà mỗi cái mới làm cái trước trở nên lỗi thời. Chúng là các công cụ với các điểm mạnh khác nhau.

1. Quy tắc và luồng hội thoại

Một chatbot dựa trên quy tắc theo các lộ trình đã được thiết kế trước. Nó có thể hiển thị nút bấm, khớp với từ khóa, điền vào biểu mẫu, hoặc chuyển giữa các trạng thái khi các điều kiện được thoả mãn. Logic có thể rõ ràng: nếu người dùng muốn thay đổi ngày giao hàng, thu thập số đơn hàng, kiểm tra xem bưu kiện có đủ điều kiện hay không, hiển thị các ngày khả dụng và yêu cầu xác nhận.

Các quy tắc có giá trị khi quy trình hẹp và các hành động chấp nhận được đã biết. Chúng giúp các bước tuân thủ và các hành động gây hại dễ kiểm soát hơn. Điểm yếu của chúng xuất hiện khi người dùng diễn đạt yêu cầu theo cách bất ngờ hoặc đi ra ngoài lộ trình đã thiết kế. Một hệ thống quy tắc tốt cần các phương án dự phòng, sửa lỗi và lối thoát, không chỉ có một lộ trình lý tưởng hoàn hảo.

2. Khớp và truy xuất mục đích

Một hệ thống dựa trên ý định ước lượng những gì người dùng đang cố gắng làm, sau đó trích xuất các chi tiết hữu ích được gọi là thực thể hoặc tham số. “Theo dõi đơn hàng 4821” có thể được ánh xạ thành một ý định theo dõi đơn hàng và một tham số số đơn hàng. Google Cloud's Tài liệu về ý định của Dialogflow mô tả mô hình này như việc so sánh một đầu vào với các cụm từ huấn luyện để tìm sự trùng khớp.

Truy xuất thêm một lớp tìm kiếm. Thay vì chỉ trả lời từ một phản hồi cố định, hệ thống sẽ tìm các đoạn liên quan, các mục chính sách, bài viết hướng dẫn, hoặc hồ sơ. Một chatbot truy xuất có thể trích dẫn trực tiếp câu trả lời đã biết hoặc chuyển tài liệu đã chọn cho bộ tạo. Chất lượng của nó phụ thuộc vào những gì đã được lập chỉ mục, cách truy vấn được hình thành, liệu nguồn có cập nhật hay không, và liệu hệ thống có tìm đúng đoạn hay không.

3. Mô hình ngôn ngữ, công cụ và hệ thống kết hợp

Một mô hình ngôn ngữ lớn có thể diễn giải các cách diễn đạt khác nhau và tạo ra các phản hồi tự nhiên trên một phạm vi đầu vào rộng hơn nhiều. Nó có thể tóm tắt, giải thích, dịch, đặt câu hỏi làm rõ, hoặc chuyển đầu ra công cụ có cấu trúc thành ngôn ngữ dễ đọc. Để có giải thích sâu hơn về việc tạo token và giới hạn của mô hình, xem Trí tuệ nhân tạo thực sự là gì?.

Mô hình vẫn cần hỗ trợ với các dữ kiện và hành động trực tiếp. Nó không thể biết vị trí hiện tại của đơn hàng 4821 trừ khi ứng dụng cung cấp thông tin đó thông qua ngữ cảnh, tìm kiếm hoặc một công cụ. Nó không thể an toàn thực hiện hoàn tiền chỉ vì có thể viết câu “Hoàn tiền của bạn đã hoàn tất.” Ứng dụng phải kết nối mô hình với các dịch vụ được ủy quyền và xác minh kết quả.

Đây là lý do tại sao nhiều chatbot hiện đại là dạng lai. Quy tắc bảo vệ các bước chuyển quan trọng. Tìm kiếm cung cấp kiến thức hiện tại. Một mô hình ngôn ngữ xử lý ngôn ngữ linh hoạt. Các công cụ đọc hoặc thay đổi trạng thái bên ngoài. Mã thông thường xác thực quyền hạn và kết quả. Con người xử lý các trường hợp cần sự xét đoán hoặc thẩm quyền.

Điều gì xảy ra trong một lượt trả lời của chatbot

Theo một thông điệp đơn giản: “Đơn hàng 4821 ở đâu?” Việc triển khai thực tế có thể kết hợp hoặc đổi tên các bước, nhưng các trách nhiệm cơ bản vẫn nhận dạng được.

1. Nhận và chuẩn hóa đầu vào. Kênh có thể cung cấp văn bản đã đánh máy, lời nói được ghi lại, lựa chọn nút bấm, ngôn ngữ, hoặc dữ liệu phiên.
2. Xác định mục tiêu. Hệ thống xác định xem yêu cầu liên quan đến theo dõi, hủy đơn, thanh toán, chủ đề khác, hoặc điều gì đó không được hỗ trợ.
3. Trích xuất chi tiết cần thiết. Trong trường hợp này, số đơn hàng là 4821. Nếu nó bị thiếu hoặc không rõ ràng, bot nên hỏi thay vì tự tạo ra.
4. Kiểm tra trạng thái cuộc trò chuyện. Hệ thống xác định những gì nó đã biết, những gì nó được phép lưu giữ, và bước nào đang hoạt động.
5. Truy xuất kiến thức hoặc gọi một công cụ. Dịch vụ theo dõi trả về tình trạng hiện tại. Chatbot không nên tạo ra tình trạng đó từ các mẫu ngôn ngữ.
6. Soạn thảo và xác thực phản hồi. Ứng dụng chuyển kết quả thành ngôn ngữ rõ ràng, kiểm tra các trường cần thiết và tránh tiết lộ dữ liệu nội bộ hoặc cá nhân.
7. Phản hồi, khôi phục, hoặc chuyển giao. Một kết quả bình thường được trả về cho người dùng. Một lỗi, trường hợp không được hỗ trợ, hoặc yêu cầu cho người sẽ theo một đường đi khác.

Google Cloud sử dụng thuật ngữ fulfillment cho phần của một lượt hội thoại trả về phản hồi tĩnh, gọi webhook để lấy thông tin động, đặt tham số, hoặc thực hiện một hành động. Nó Tài liệu fulfillment của Dialogflow tạo ra một sự phân biệt quan trọng: hiểu yêu cầu và thực hiện nó là những trách nhiệm riêng biệt.

Trạng thái hội thoại không phải là trí nhớ của con người

Một chatbot cần đủ trạng thái để tránh bắt đầu lại trong mỗi lượt. Trạng thái phiên có thể ghi lại rằng nhiệm vụ hiện tại là theo dõi bưu kiện, số đơn hàng là 4821, và người dùng đã xác nhận mã bưu điện. Nếu không có trạng thái, “Còn gói hàng thứ hai thì sao?” sẽ không có tham chiếu hữu ích.

Trạng thái đó là dữ liệu được tạo ra, không phải ký ức của con người. Một số hệ thống chỉ giữ phiên hiện tại. Những hệ thống khác lưu trữ lịch sử trò chuyện, tóm tắt, sở thích hoặc thông tin tài khoản. Một mô hình cũng có thể chỉ nhận một phần của cuộc trò chuyện dài vì ngữ cảnh của nó có dung lượng giới hạn hoặc vì ứng dụng cố ý giới hạn những gì được gửi.

Người dùng không nên giả định rằng một chatbot quên khi một cửa sổ đóng lại hoặc nhớ vì nó nói như thể nó nhớ. Việc lưu giữ, liên kết tài khoản, sử dụng cho đào tạo và xóa dữ liệu phụ thuộc vào dịch vụ cụ thể. Trước khi chia sẻ thông tin nhạy cảm, hãy xem xét giải thích về quyền riêng tư của dịch vụ và chỉ sử dụng thông tin tối thiểu cần thiết cho nhiệm vụ.

Cách thức hoạt động của việc tạo sinh được tăng cường truy xuất

Các tham số của một mô hình ngôn ngữ không phải là nơi thích hợp để lưu trữ chính sách hoàn trả thay đổi thường xuyên. Tăng cường sinh bằng truy xuất (retrieval-augmented generation), thường được viết tắt là RAG, giải quyết vấn đề này bằng cách tìm kiếm một bộ sưu tập bên ngoài để lấy tài liệu liên quan và đặt các đoạn trích đã chọn vào ngữ cảnh của mô hình trước khi nó viết câu trả lời.

Bản gốc Bài báo Retrieval-Augmented Generation kết hợp một bộ sinh đã được huấn luyện trước với bộ nhớ phi tham số rõ ràng được truy xuất từ một chỉ mục. Mô hình rộng này hiện xuất hiện trong nhiều trợ lý tri thức: tìm kiếm trước, tạo ra sau.

Một quy trình RAG hữu ích có ít nhất bốn khả năng thất bại. Bộ sưu tập nguồn có thể không đầy đủ. Tài liệu có thể đã lỗi thời. Việc truy xuất có thể chọn một đoạn văn không liên quan. Bộ tạo có thể đọc sai hoặc thêm thắt những gì nó nhận được. Trích dẫn chỉ hữu ích nếu chúng chỉ đến nguồn hỗ trợ chính xác và người dùng có thể kiểm tra nó.

Do đó, RAG cải thiện quyền truy cập vào kiến thức hiện hành, có thể kiểm tra, nhưng không đảm bảo sự thật. Nó nên được đánh giá toàn diện: nguồn chính xác đã được nhập vào chỉ mục chưa, tìm kiếm có tìm thấy nó không, câu trả lời có vẫn nằm trong bằng chứng không, và trích dẫn có hỗ trợ cho khẳng định không?

Câu trả lời và hành động đòi hỏi các mức độ kiểm soát khác nhau

Một chatbot giải thích chính sách hoàn tiền không giống với một chatbot thực hiện hoàn tiền. Hệ thống thứ hai có thể thay đổi trạng thái bên ngoài. Nó có thể gọi dịch vụ tài khoản, lịch, hệ thống thanh toán, công cụ nhắn tin hoặc điều khiển thiết bị. Khả năng đó đôi khi được mô tả là quyền tác động, nhưng câu hỏi thực tiễn đơn giản hơn: ứng dụng này có thể làm gì ngoài việc tạo ra văn bản?

Một lộ trình hành động an toàn nên giữ các kiểm tra quan trọng bên ngoài văn bản của mô hình:

• Xác thực người dùng và xác nhận rằng tài khoản hoặc tài nguyên thuộc về họ.
• Ủy quyền cho hành động cụ thể thay vì cho phép chatbot quyền truy cập rộng.
• Xác minh các tham số công cụ, số tiền, điểm đến và phạm vi cho phép bằng mã thông thường.
• Yêu cầu xác nhận rõ ràng trước các hành động không thể đảo ngược hoặc tốn kém.
• Trả về kết quả công cụ đã được xác minh thay vì giả định rằng hành động đã thành công.
• Ghi lại đủ thông tin để điều tra các thất bại mà không tiết lộ dữ liệu nhạy cảm không cần thiết.

Hình minh họa cho thấy một kiến trúc mục tiêu, không phải là một lời hứa về bất kỳ chatbot cụ thể nào. Một mô hình ngôn ngữ có thể gợi ý công cụ nào cần gọi, nhưng ứng dụng xung quanh nên quyết định liệu cuộc gọi đó có được phép hay không. Tăng độ tự chủ sẽ làm tăng giá trị của các giới hạn về quyền, giới hạn tốc độ, xác nhận, giám sát và xem xét của con người.

Chèn lệnh (prompt injection): khi nội dung cố gắng trở thành một hướng dẫn

Một chatbot sử dụng công cụ hoặc truy xuất có thể đọc văn bản do người dùng, trang web, email hoặc tài liệu cung cấp. Một số văn bản đó có thể chứa các hướng dẫn nhắm mục tiêu đến mô hình, chẳng hạn như bảo nó bỏ qua các quy tắc trước đó, tiết lộ thông tin ẩn hoặc gọi một công cụ theo cách không dự định. Đây là chèn lệnh (prompt injection).

The Dự án An ninh OWASP GenAI liệt kê tấn công prompt như một rủi ro hàng đầu cho các ứng dụng mô hình ngôn ngữ. Vấn đề cốt lõi là các mô hình xử lý lệnh và nội dung thông thường qua cùng một kênh ngôn ngữ. Một tài liệu không đáng tin có thể trông giống về mặt ngữ pháp như một lệnh từ ứng dụng.

Không có prompt nào có thể thay thế các kiểm soát ở cấp hệ thống. Các ứng dụng nên coi nội dung được truy xuất và do người dùng cung cấp là không đáng tin, hạn chế các công cụ có sẵn, áp dụng nguyên tắc quyền tối thiểu, xác thực các lệnh gọi công cụ, cô lập các thao tác nhạy cảm và yêu cầu xác nhận khi hậu quả quan trọng. Mô hình không nên nhận khóa chính chỉ vì giao diện là trò chuyện.

Tại sao chatbot lại đưa ra câu trả lời sai hoặc gây thất vọng

Chúng hiểu nhầm yêu cầu

Ngôn ngữ thì mơ hồ. “Đóng tài khoản của tôi” có thể có nghĩa là đăng xuất, xóa hồ sơ, hủy đăng ký, hoặc đóng một tài khoản tài chính. Một chatbot đáng tin cậy nhận ra khi chi phí đoán mò cao hơn chi phí của một câu hỏi làm rõ duy nhất.

Họ thiếu thông tin cần thiết

Một mô hình có thể biết từ vựng chung về vận chuyển nhưng thiếu hồ sơ đặt hàng của người dùng. Việc truy xuất có thể bỏ lỡ chính sách liên quan. Một công cụ có thể không khả dụng. Phản hồi đúng là nêu ra hạn chế hoặc sử dụng phương án thay thế, không phải lấp đầy khoảng trống bằng một câu chuyện có vẻ hợp lý.

Họ tạo ra thông tin sai một cách tự tin

NIST gọi những nội dung sinh ra sai hoặc lỗi được trình bày một cách tự tin là tưởng tượng (confabulation). Hồ sơ AI Sinh tạo ghi nhận rằng hành vi này có thể bao gồm lập luận hoặc trích dẫn bịa đặt. Sự trôi chảy khiến những lỗi này khó nhận ra hơn, không làm giảm mức quan trọng của chúng.

Chúng mất trạng thái hoặc mang trạng thái sai sang bước tiếp theo

Một phiên làm việc có thể quên một chi tiết, nhầm hai đơn hàng, giữ một giả định sai, hoặc áp dụng thông tin từ công việc này sang công việc khác. Trạng thái nên đủ rõ để có thể sửa chữa và được giới hạn đủ hẹp để tránh trộn lẫn không mong muốn.

Chúng không có lối thoát duyên dáng

Vòng lặp đau đớn nhất thường là do lỗi thiết kế. Bot đã đạt đến giới hạn khả năng của nó nhưng vẫn tiếp tục diễn đạt lại cùng một câu trả lời. Một phương án dự phòng nên thay đổi hướng đi: yêu cầu một chi tiết thiếu, đưa ra một tùy chọn có hỗ trợ, tạo ra một trường hợp, hoặc chuyển cuộc trò chuyện.

Việc chuyển giao cho con người là một phần của hệ thống, không phải là sự thừa nhận thất bại.

Một số yêu cầu mơ hồ, mang tính cảm xúc, đặc biệt, hoặc hệ quả. Những yêu cầu khác đòi hỏi quyền hạn mà chatbot không nên có. Chuyên gia con người có thể giải thích bối cảnh, thương lượng một ngoại lệ, chịu trách nhiệm, hoặc nhận ra rằng quy trình đã được ghi chép không phù hợp với trường hợp.

Việc chuyển tiếp chỉ hoạt động nếu bối cảnh được truyền đi cùng với nó. Người nhận nên nhận được mục tiêu của người dùng, các chi tiết đã được xác nhận, kết quả công cụ liên quan và lý do cần phải chuyển tiếp. Ép người dùng lặp lại toàn bộ cuộc trò chuyện sẽ biến một việc chuyển tiếp về mặt kỹ thuật thành một trải nghiệm tồi.

Tài liệu của Dialogflow về chuyển tiếp cho đại lý trực tiếp xem việc chuyển tiếp như một sự chuyển đổi rõ ràng. Nguyên tắc thiết kế này rộng hơn một nền tảng cụ thể: việc chuyển tiếp nên là một lộ trình đã được kiểm tra với trách nhiệm rõ ràng, không phải là một câu mà bot tự ứng biến khi bị mắc kẹt.

Cách đánh giá xem chatbot có tốt hay không

Một bản demo thuyết phục rất dễ dàn dựng. Một chatbot đáng tin cậy phải xử lý được sự biến đổi bình thường và thất bại có thể nhìn thấy được. Việc đánh giá nên bắt đầu từ công việc mà người dùng đến để thực hiện.

• Hoàn thành nhiệm vụ: người dùng có nhận được câu trả lời hoặc thực hiện hành động đúng cách không?
• Căn cứ: các tuyên bố thực tế có dựa theo nguồn cung cấp hoặc kết quả công cụ đã được xác minh hay không?
• Phục hồi: thông tin thiếu, sự kiện không khớp và sự cố công cụ có dẫn đến bước tiếp theo hữu ích không?
• An toàn: quyền hạn, xác nhận, xử lý dữ liệu và giới hạn công cụ có được duy trì dưới các đầu vào đối nghịch không?
• Chất lượng chuyển giao: cuộc trò chuyện có đến đúng người với đủ ngữ cảnh không?
• Ngôn ngữ và khả năng tiếp cận: luồng tương tác có hoạt động qua các ngôn ngữ được hỗ trợ, kiểu gõ, điều kiện phát âm, điều hướng bàn phím và công nghệ hỗ trợ không?
• Nỗ lực của người dùng: cần bao nhiêu lượt, lặp lại và sửa chữa để hoàn thành nhiệm vụ?

Các cuộc hội thoại thử nghiệm nên bao gồm nhiều hơn con đường thuận lợi. Sử dụng số đơn hàng bị thiếu, hai số trong một tin nhắn, lỗi chính tả, yêu cầu không được hỗ trợ, tài liệu lỗi thời, thời gian chờ công cụ, yêu cầu đổi chủ đề, yêu cầu trực tiếp một người và hướng dẫn độc hại ẩn trong nội dung được truy xuất. Google Cloud's hướng dẫn thiết kế đại lý tương tự khuyến nghị thiết kế lặp đi lặp lại và các trường hợp thử nghiệm thay vì cố gắng thiết kế mọi đường đi cùng một lúc.

Cách sử dụng chatbot mà không mất khả năng đánh giá

1. Nêu rõ mục tiêu và bối cảnh liên quan tối thiểu. Một yêu cầu chính xác giúp giảm số lượt không cần thiết.
2. Không dán mật khẩu, mã xác thực, thông tin thanh toán, khóa riêng hoặc các hồ sơ nhạy cảm trừ khi dịch vụ đáng tin cậy cụ thể yêu cầu rõ ràng và bảo vệ những thông tin đó.
3. Phân biệt giữa giải thích và kết quả trực tiếp. Hãy hỏi xem câu trả lời đến từ hồ sơ hiện tại, nguồn trích dẫn, hay kiến thức tổng quát của mô hình.
4. Mở các trích dẫn và xác minh các tuyên bố quan trọng. Một liên kết nguồn có thể không liên quan, lỗi thời, hoặc không nhất quán với câu trả lời.
5. Xem xét mọi hành động trước khi xác nhận. Kiểm tra tài khoản, số tiền, điểm đến, ngày tháng, và xem thay đổi đó có thể được đảo ngược hay không.
6. Hỏi một người khi bot lặp lại chính nó, thiếu thẩm quyền, hiểu sai vấn đề nhạy cảm, hoặc không thể chỉ ra nguồn gốc của câu trả lời.

Mô hình tư duy đáng giữ gìn

Một chatbot không phải là một cá tính sống bên trong một quả bóng. Nó là một giao diện đàm thoại được kết nối với một số tổ hợp của các luồng, bộ phân loại, tìm kiếm, mô hình ngôn ngữ, ghi chép, công cụ, chính sách, kiểm tra an toàn và con người. Phản hồi bạn thấy là bước cuối cùng của hệ thống lớn hơn đó.

Câu hỏi hay nhất không phải là “Bot này nghe có giống con người không?” Hãy hỏi liệu nó có hiểu nhiệm vụ, sử dụng bằng chứng đúng, tôn trọng quyền hạn, phục hồi trung thực và để bạn kiểm soát hay không. Ngôn ngữ tự nhiên giúp hệ thống dễ tiếp cận hơn. Kỹ thuật âm thanh khiến nó đáng để sử dụng.

Tài liệu tham khảo chính và kỹ thuật

• Joseph Weizenbaum, ELIZA: Chương Trình Máy Tính Nghiên Cứu Giao Tiếp Ngôn Ngữ Tự Nhiên Giữa Con Người và Máy, 1966.
• Lewis và cộng sự, Tạo Sinh Bổ Sung Tìm Kiếm cho Các Nhiệm Vụ NLP Cường Độ Kiến Thức, 2020.
• NIST, Khung Quản lý Rủi ro Trí tuệ Nhân tạo: Hồ sơ Trí tuệ Nhân tạo Tạo sinh, 2024.
• Google Cloud, Tài liệu Dialogflow CX cho các ý định, thực hiện, thiết kế đại lý và chuyển giao cho con người.
• Dự án Bảo mật GenAI của OWASP, LLM01:2025 Tiêm lệnh Prompt.