Phần 3 của loạt bài “Các kỹ thuật thiết kế Bot App“. Trong phần này mình và các bạn sẽ tiếp tục cùng nhau tìm hiểu những nguyên tắc cơ bản khi thiết kế, lập trình một ứng dụng bot là gì?
Các bạn có thể xem lại phần 2 của loạt bài viết này tại đây.
Các nguyên tắc cơ bản khi thiết kế, lập trình một ứng dụng bot
Các yếu tố UX trong bot
Các ứng dụng bot thường sử dụng 3 phương thức sau để trao đổi thông tin với người dùng:
- Rich user control: Trên thực tế, bot có thể “giả dạng” thành các ứng dụng di động, ứng dụng web bằng cách sử dụng các UI control cơ bản như “button”, “image”, “carousel” (dạng “slideshow”) hay “menu”. Thậm trí khi bot được nhúng vào trong một ứng dụng web/di động, nó còn có thể hiển thị hầu hết các UI control nhờ vào việc khai thác sức mạnh của app mà nó được nhúng vào.
- Chữ viết: Bot có thể cho phép người dùng nhập chữ tùy ý vào và sử dụng các API xứ lý ngôn ngữ tự nhiên như LUIS.ai để hiểu được xem người dùng đang yêu cầu điều gì. Nhiều người nghĩ rằng chữ viết sử dụng trong bot cần được viết dưới dạng ngôn ngữ tự nhiên, tuy nhiên không nhất thiết là phải vậy. Với một số bot, chữ viết hoàn toàn có thể được viết dưới dạng là những câu lệnh khô khan và bot chỉ cần sử dụng những cách bóc tách đơn giản như sử dụng “regex” để hiểu được ý của câu lệnh.
- Âm thanh: Bot có thể sử dụng âm thanh để làm tăng trải nghiệm của người dùng. Phương thức trao đổi thông tin bằng âm thanh cũng giúp bot hoạt động được trên các thiết bị không có màn hình hay bàn phím, trường hợp mà âm thanh là phương thức duy nhất để trao đổi thông tin giữa người và bot.
Rich user control
Trong lập trình ứng dụng di động hay ứng dụng web, lập trình viên sử dụng các UI control để làm đơn giản việc tương tác giữa người dùng với ứng dụng. Với những người mới bắt đầu lập trình ứng dụng bot, việc sử dụng các UI control được đánh giá thấp vì họ nghĩ rằng bot phải là một thứ gì đấy nó cao siêu, thông minh, việc dùng UI control không được “AI” cho lắm. Cần nhắc lại một điều rằng yếu tố làm nên sự thành công của một ứng dụng bot không phải là sự thông minh của bot mà là cách mà con bot của bạn xử lý để giải quyết được vấn đề của người dùng một cách nhanh chóng và hiệu quả. Việc bạn dùng AI hay một nút bấm đơn giản để giải quyết vấn đề không thực sự quan trọng!
Các nền tảng chatbot như Skype, Slack, Microsoft Teams, Facebook Messenger đang tập trung nhiều vào việc phát triển ra những cách khác nhau để lập trình viên có thể nhúng các control trực quan vào một cuộc hội thoại. Nút bấm (“button”) là một ví dụ chung điển hình. Ngay cả khi chỉ có một lựa chọn đơn giản cho người dùng, nút bấm trở nên rất hiệu quả trong trường hợp này, chỉ cần nhấp chuột/chạm vào nút có tên “Hotels” để đặt phòng khách sạn sẽ nhanh hơn và dễ dàng hơn so với việc yêu cầu người dùng gõ “Hotels”. Việc làm này cũng hiệu quả đối với những ứng dụng di động khi mà việc yêu cầu người sử dụng gõ quá nhiều cũng là một thiết kế không thực sự mang lại trải nghiệm thoái mái cho người dùng.
Do vậy, một lời khuyên dành cho những nhà phát triển bot đó là tận dụng các UI control để giải quyết vấn đề của người dùng trước. Thêm các phương thức khác sau nếu như những UI control không đủ để giải quyết vấn đề. Có một điều thú vị là các lập trình viên thường nghĩ tới việc giải quyết bài toán xử lý ngôn ngữ tự nhiên trước. Tuy nhiên theo kinh nghiệm thì hướng làm này thường sẽ không hoạt động hiệu quả bởi vì nhiều khi nó sẽ dẫn tới những vấn đề phức tạp hơn rất nhiều! Giống như người Việt có câu “Dùng dao mổ trâu giết gà”.
Chữ viết, ngôn ngữ tự nhiên
Chữ viết và ngôn ngữ tự nhiên là cách phổ biển để tương tác giữa người và bot. Không có gì làm lạ khi thấy lập trình viên ưu ái sử dụng ngôn ngữ tự nhiên để giải quyết bài toán thay vì sử dụng những cách khác mà có thể xử lý vấn đề hiệu quả hơn.
Có một điều mà mọi lập trình viên bot cần lưu ý đó là việc tương tác giữa người và bot không nhất thiết đòi hỏi phải xây dựng một con bot có khả năng xử lý ngôn ngữ tự nhiên tốt, không nhất thiết đòi hỏi đoạn văn mà người dùng nhập vào cho bot có ngữ điệu, văn phong tự nhiên giống với đoạn văn gửi tới cho một con người! Chúng ta có thể muốn hoặc không muốn người dùng nhập vào một đoạn văn tùy ý mà chúng ta không thể đoán trước được và cần phải sử dụng những API xử lý ngôn ngữ tự nhiên để bóc tách đoạn văn đó ra thành các tập lệnh mà bot có thể hiểu được. Tuy nhiên thậm chí nhiều khi những API xử lý ngôn ngữ tự nhiên này không phải là công cụ cần dùng để xử lý đoạn văn bản mà người dùng nhập vào.
Vậy những lưu ý gì khi sử dụng phương thức tương tác sử dụng chữ viết?
- Với câu hỏi “Bạn tên là gì?”, người dùng có thể trả lời bằng cách chỉ nhập vào tên của họ ví dụ như “Dũng” hoặc viết một câu trả lời đầy đủ, lịch sự là “Tên tôi là Dũng”. Câu hỏi của bạn có định hướng cho người dùng trả lời càng cụ thể bao nhiêu thì sẽ giảm được số lượng câu trả lời tùy ý mà bạn cần phải đoán đi bấy nhiêu. Xét một ví dụ với câu hỏi sau: “Hôm nay bạn cảm thấy như thế nào?”, đây là một câu hỏi rất mở và có nhiều cách cũng như câu trả lời khác nhau, và với câu hỏi này thì rất khó để xử lý được câu trả lời mà người dùng cung cấp. Trong lập trình bot, việc đoán được các biến thể câu trả lời cho một câu hỏi là một công việc rất khó. Thay vì làm như vậy, việc xây dựng các câu hỏi cụ thể như “Hôm nay bạn có bị đau ở đâu không? Có/Không”, “Bạn đau ở vị trí nào? Đầu/Cổ họng/Chỗ khác” sẽ giúp nhận được những câu trả lời cụ thể, tránh được những câu trả lời tùy ý khó đoán, và giảm được khối lượng công việc liên quan đến xử lý ngôn ngữ tự nhiên phức tạp. Đây là chiến lược phổ biến trong xây dựng câu hỏi để nhận được câu trả lời mong muốn từ người dùng. Lưu ý rằng người dùng sẽ rất khó biết được rằng bot của bạn cần thông tin gì khi mà bot của bạn bản thân không thể hiện được rõ ràng rằng nó cần thông tin gì hay nói một cách khác là bot của bạn không cho người dùng biết nó cần gì.
- Trong một vài trường hợp, bot của bạn hỗ trợ nhập các đoạn văn dưới dạng câu lệnh ví dụ như bot hỗ trợ quản lý máy ảo chẳng hạn. Việc sử dụng ngôn ngữ tự nhiên ví dụ như “Bạn có thể khởi động máy ảo ABC được không?” thay cho câu lệnh như “/START VM ABC” là hoàn toàn không cần thiết vì đối với người sử dụng, việc gõ câu lệnh “/START VM ABC” sẽ nhanh và dễ hiểu hơn nhiều mặc dù nó không phải là ngôn ngữ tự nhiên.
- Người dùng có thể đưa ra những yêu cầu rất đơn giản sử dụng ngôn ngữ tự nhiên ví dụ như “Tôi muốn một chiếc bánh mì Hội An” hay câu hỏi “Có nhà hàng ăn nhanh nào quanh vị trí của tôi trong bán kính 5km đang mở cửa không?”. Với những dạng văn này các API xử lý ngôn ngữ tự nhiên như LUIS.ai thể hiện sức mạnh của mình. API sẽ giúp bóc tách được các thành phần trong câu từ đó đưa ra ý định (intent) của câu trên là “Tìm nhà hàng”, các thực thể (entity) bao gồm: “khoảng cách” là “5km”, “mốc tham chiếu” là “vị trí của tôi” và “tình trạng” là “đang mở cửa”. Tuy nhiên mọi thứ không phải lúc nào cũng suôn sẻ. Xét một ví dụ sau:
Tôi muốn mua một căn hộ rộng 100m2, cách chỗ làm của tôi trong khoảng 5km và hướng về trung tâm thành phố. Căn hộ cần có sân cỏ đằng trước và có vườn đằng sau với một bể bơi
Tôi muốn mua một căn hộ
Một lỗi mà nhiều lập trình viên mắc phải khi xây dựng các model xử lý ngôn ngữ tự nhiên đó là họ nghĩ rằng người dùng sẽ cung cấp các thông tin mà bot của bạn cần ngay lập tức, ngay trong cùng một câu. Tuy nhiên đó không phải cách mà con người dùng ta tương tác, chúng ta tương tác với nhau, cung cấp thông tin theo dạng các mảnh ghép thông tin. Với yêu cầu “Tôi muốn mua một căn hộ”, đây là một yêu cầu rất mở và sẽ rất khó để ứng dụng của bạn có thể xử lý được luôn yêu cầu này. Giải pháp đó là hướng dẫn cho người dùng biết được rằng bot của bạn cần thêm thông tin gì bằng cách hỏi thêm các thông tin cần thiết này. Một lần nữa cần phải nhắc lại rằng người sử dụng sẽ không biết được rằng bot của bạn cần những thông tin gì nếu như bạn không cho họ biết bot của bạn cần gì!
- Lấy ví dụ là bạn đang xây dựng một con bot về Q&A, hỏi gì đáp nấy, có nhiệm vụ trả lời các câu hỏi của người dùng. Có một điều chắc chắn rằng sẽ rất khó để con bot này có thể trả lời được câu hỏi của người dùng chỉ bằng việc sử dụng công nghệ xử lý ngôn ngữ tự nhiên. Thử tưởng tượng xem việc bạn phải đoán tất cả các biến thể câu hỏi mà người dùng sẽ có thể đặt ra cho con bot của bạn để train cho API xử lý ngôn ngữ tự nhiên sẽ đi đến đâu? Đây là một nhiệm vụ bất khả thi và đảm bảo sẽ đi tới thất bại. Bạn sẽ không bao giờ đoán được tất cả các câu hỏi cũng như không có đủ thời gian để train cho API xử lý ngôn ngữ tự nhiên của bạn. Với trường hợp này thì công nghệ tìm kiếm tỏa sáng, giúp giải quyết vấn đề này tốt hơn. Có 2 công nghệ là QnA Maker và Azure Search để bạn có thể tham khảo. Tóm lại, trong trường hợp bạn cần phải trả lời các câu hỏi mà dữ liệu để trả lời nằm trong cơ sở dữ liệu hoặc các trang web hoặc trong các tài liệu văn bản, luôn luôn cân nhắc sử dụng công nghệ tìm kiếm trước khi bắt tay vào sử dụng công nghệ xử lý ngôn ngữ tự nhiên.
Âm thanh
Các công nghệ nhận dạng giọng nói hay chuyển đổi chữ viết sang âm thanh là những công nghệ được nhiều lập trình viên quan tâm khi xây dựng bot. Việc ứng dụng những công nghệ này giúp bot thâm nhập vào những công việc mà các ứng dụng truyền thông không thể xử lý được.
Tuy nhiên như có chia sẻ ở phần 1, việc sử dụng âm thanh trong ứng dụng bot cần được phân tích kỹ lưỡng trên khía cạnh là trải nghiệm người dùng (UX) đầu tiên và xem xem liệu rằng âm thanh có thực sự phù hợp trong bài toán cần giải quyết của ứng dụng bot hay không. Hiểu được những ưu, nhược điểm của việc ứng dụng âm thanh vào bot là điều vô cùng quan trọng. Cùng tham khảo bảng sau:
| Ưu điểm | Nhược điểm |
|
|
Phương thức nào tôi nên sử dụng?
Sẽ rất khó để đưa ra một câu trả lời cho câu hỏi này khi mà không nắm được bài toán mà con bot của bạn cần phải giải quyết. Trong nhiều trường hợp, cả 3 phương thức trên đều được sử dụng chung trong cùng 1 con bot. Bạn không cần thiết phải cố gắng lựa chọn sử dụng 1 phương thức duy nhất trong 3 phương thức trên. Lấy một ví dụ với một con bot hướng dẫn nấu ăn. Trong quá trình nấu ăn tay của người dùng sẽ luôn luôn bận rộn, việc tương tác với bot qua việc chạm vào thiết bị là một trải nghiệm tồi, trong trường hợp này, phương thức sử dụng âm thanh “ghi điểm” và trở thành phương thức chính để người dùng tương tác với bot. Tuy nhiên, trường hợp nói trên không phải lúc nào cũng xảy ra khi người dùng sử dụng bot của bạn và không phải ai cũng thích phương thức tương tác bằng âm thanh mà có người lại thích tương tác với bot qua việc thao tác gõ/chạm trên thiết bị thay vì phải nói. Thậm chí có những người cảm thấy rất phiền toái khi phải tương tác với bot qua giọng nói. Ngoài ra, luôn cân nhắc đến trường hợp: Người sử dụng bot của bạn có thể không có khả năng nói và nghe. Hơn nữa, khi bot hướng dẫn cho người dùng về cách nấu một món ăn theo một công thức nhất định, việc hiển thị một đoạn video hay một số hình ảnh để giúp giải thích những bước, thao tác cần được thực hiện sẽ giúp người dùng dễ dàng thực hiện hơn thay vì chỉ hướng dẫn bằng âm thanh.
Phương thức nào tương tác với người “tự nhiên” hơn?
Có thể khẳng định một điều rằng không có bất kỳ 1 phương thức nào trong 3 phương thức trên, khi được sử dụng một cách biệt lập với 2 phương thức còn lại, được coi là 1 phương thức tương tác với người một cách “tự nhiên” cả. Bạn hãy để ý thế giới xung quanh mình, cách chúng ta giao tiếp với nhau, sử dụng hành động, lời nói và các biểu tượng, hình ảnh. Nếu bạn chơi 1 ván cờ và có sử dụng bàn cờ, việc chơi ván cờ đó sẽ rất dễ dàng, nhưng nếu tưởng tượng bạn vẫn chơi ván cờ đó mà không có bàn cờ mà chỉ qua giọng nói, cách chơi đó sẽ không hề tự nhiên đối với hầu hết mọi người một chút nào.
Hãy cùng xem một số tình huống hài hước sau:
Với tình huống trên, bạn thấy rằng việc miêu tả biểu đồ là một chuyện hết sức phức tạp vì nó chứa rất nhiều thông tin. Phương thức trao đổi bằng âm thanh cho tình huống này thực sự không phải là một ý tưởng tốt một chút nào. Tuy nhiên, việc miêu tả này sẽ có thể hữu dụng khi người nghe miêu tả cũng đang nhìn vào cùng một biểu đồ.
Việc chỉ sử dụng giọng nói để tương tác với nhau thực tế không mang đến một trải nghiệm “tự nhiên” một chút nào. Rất nhiều trường hợp, một trải nghiệm tự nhiên đòi hỏi có sự tương tác bằng nhiều phương thức như chữ viết, các hình ảnh kích thích thị giác, các nút bấm hoặc thậm trí là âm thanh.
Việc dùng âm thanh đồng nghĩa với việc sẽ có độ trễ. Đừng đánh giá thấp tốc độ của việc nhấn một nút so với việc nói. Người dùng sẽ hướng tới những trải nghiệm mà đáp ứng được nhu cầu của họ một cách nhanh nhất!
Âm thanh không phải là cách hữu hiệu để trao đổi thông tin nhạy cảm hay phức tạp. Người dùng sẽ rất rất không thoải mái với việc gửi hoặc nhận những thông tin phức tạp hoặc nhạy cảm ví dụ như gửi mật khẩu mới bằng cách đọc qua điện thoại chẳng hạn.
Vậy phương thức nào thì phù hợp cho tình huống cụ thể nào?
Dưới đây là một số “pattern” bạn cần lưu ý. Các “pattern” này được xây dựng dựa trên quá trình quan sát người dùng sử dụng các loạt bot khác nhau trong các tình huống khác nhau và nó có thể thay đổi theo thời gian:
- Người dùng sẽ hướng tới sử dụng nút và các “rich control” đầu tiên. Vì đây là cách nhanh nhất để đạt được kết quả mong muốn cũng như là cách dễ tiếp cận nhất với người sử dụng.
- Như là một giải pháp thứ 2, người dùng sẽ thích sử dụng phương thức sử dụng chữ viết. Gõ chữ sẽ không thuận tiện bằng việc nhấn một nút nhưng vẫn rất hữu dụng trong nhiều trường hợp. Tuy nhiên lưu ý với những điều kiện môi trường, thiết bị của người dùng khi sử dụng phương thức chữ viết: Việc gõ chữ trên một thiết bị di động sẽ khó khăn hơn so với trên bàn phím máy tính. Ngoài ra, một số người dùng sẽ có thói quen viết tắt khá nhiều trong các câu họ viết ra và điều này sẽ gây khó khăn cho các API xử lý ngôn ngữ tự nhiên khi thực hiện bóc tách ý của họ.
- Âm thanh thường là phương thức được ưu tiên lựa chọn khi mà phương thức sử dụng chữ viết không khả dụng. Ví dụ khi sử dụng một con bot huấn luyện cá nhân, thông thường người dùng tương tác với con bot đó sử dụng các nút nhấn và chữ viết, nhưng trong trường hợp người dùng chuyển sang chạy bộ chẳng hạn, phương thức chữ viết hoặc bấm nút sẽ không còn khả dụng và họ sẽ muốn sử dụng một chiếc tai nghe để tương tác với bot bằng âm thanh. Hoặc ví dụ như một con bot dự báo thời tiết mà người dùng thường tương tác bằng chữ viết. Tuy nhiên khi họ lái xe, việc tương tác với bot sẽ chuyển sang sử dụng giọng nói để đảm bảo an toàn.
3 phương thức nói trên không loại trừ lẫn nhau, chúng có thể sử dụng chung với nhau và gần như là nên làm như vậy khi có thể. Tuy nhiên, mặc dù trong trường hợp cả 3 phương thức này khả dụng, bạn cũng nên tham khảo các “pattern” trên để ứng dụng phù hợp vào bot của mình.
Như vậy mình và các bạn đã cùng nhau tìm hiểu về các yếu tố UX trong thiết kế, lập trình ứng dụng bot. Có 3 phương thức thường được sử dụng trong việc tương tác, trao đổi thông tin giữa người và bot: rich user control, chữ viết & ngôn ngữ tự nhiên và âm thanh, các phương thức này có ưu và nhược điểm riêng và có những lưu ý khi sử dụng chúng.
Đây là phần cuối cùng trong chuỗi bài “Các kỹ thuật thiết kế Bot App“, hy vọng là chuỗi bài này đã mang lại cho các bạn kiến thức cơ bản để các bạn có thể dễ dàng bắt đầu xây dựng một ứng dụng bot. Xin nhắc lại là tất cả những gì được chia sẻ trong chuỗi bài này là những gì mà mình học được, đọc được trong quá trình tìm hiểu về lập trình bot, có thể có những thông tin không còn đúng tại thời điểm bạn đọc nên rất hy vọng các bạn coi đây như là một tài liệu tham khảo mà thôi. Và cũng rất hy vọng sẽ nhận lại được những chia sẻ kinh nghiệm về lập trình bot của bạn thông qua trao đổi dưới dạng bình luận dưới bài viết.
Trong bài viết tới, mình và các bạn sẽ tiếp tục tìm hiểu về bot với các bài viết về Microsoft Bot Framework và dịch vụ Azure Bot Service của Microsoft.
Công ty mình chuẩn bị ra mắt một công cụ training tự động mới (…..training bot), có thể tư vấn giúp mình đặt tên Bot là gì cho ấn tượng không ạ? Mình cảm ơn nhiều
Một vài idea của mình:
hoặc