[對話式AI-9] 2020 Chatbot Framework Comparison 聊天機器人框架對比

這是經過數個月的調查與更新,所做的2020年聊天機器人框架對比。本表整理了10個知名的Chatbot框架,幾乎涵蓋時下Chatbot所有的Feature;經過一輪基本的驗證後,針對模糊之處再深入使用,藉此得到詳盡的對比。今年10月做了一次修正與更新,為了將資料整合到部落格的AI專欄上,也克服網誌呈現表格的問題,在此分享給各位業界先進與同好。

TypeFeatureDescriptionGoogleMicrosoftXiao-i Robot小i機器人IBMDYDUSAPFlow XOMeyaGupshupHubspot
DialogflowAzureBotiBot Enterprise
/ Pro
iBot International
/ Express
WatsonDYDURecast.aiFlow XOMeyaGupshupHubspot
Operation & appearanceCode-free backend透過後端介面拖拉流程圖就能建立chatbot,不須寫程式××
Structure & logicKnowledge-independent assistantknowledge(skills)的編輯與assistant的創建彼此獨立×××××××
Bots collaboration可以定義一系列彼此knowledge不相關的bot,然後通過組合bot來構建一個assistant的整體輸出××××
FAQ-based intent支援FAQ格式的intent與答案,而每個intent的答案是固定的×××××××
Multi-languageMulti-language支援多語言對話×××
Auto-language detection系統自動偵測語言,使用者不需自行選擇×××××
Pre-build contentKnowledge預置常用的一般或行業知識,允許客戶快速構建chatbot
Knowledge editIntent -- intent conflict resolution利用AI技術偵測人工填寫intent/user samples時產生的錯誤和衝突××××××××
Intent -- utterance對某個intent編輯不同的問法(擴展問)×××
Entity -- my entity可自行定義entity(例如通過同義詞)××××
系統可自動推薦同義詞×××××××
Multi-turn Dialog若問句資訊不足,系統可以反問使用者(多輪對話)√(ibot ui)√ (scene)√(5)
× (workflow)√(50)
Dialog -- slots系統可自動擷取與填充槽位
Dialog -- disambiguation當使用者的問句匹配到dialog中2個以上的intent節點時,assistant會請使用者決定正確的intent××××××××
Dialog -- 意圖推薦當使用者的問題超出服務範圍,或無法識別意圖時,系統可以推薦相關的意圖給使用者×××××××
Dialog -- multi slots filling對intent缺失的多個資訊,進行一次性的提問,讓使用者可以一次補充所有資訊,而非逐條詢問與回覆×××××××
Dialog -- multi reply對同一intent有多種回答,讓系統可以隨機選擇,產生更自然的對話效果××
Dialog -- Digression允許用戶在dialog中,進行話題(node)的切換,例如從某個流程節點跳轉到另一節點,並允許跳回等。×××
Dialog -- interruptions可讓使用者在對話中暫時討論不同的主題,然後再返回原來的主題××××√ (quit keyword)×××
Knowledge map顯示不同knowledge之間的關係和聯繫×××××××
Answer - variable提供特定參數,讓系統獲取相關資訊,如使用者名稱、IP、URL等內容,也可以直接用variable的形式添加在答案中。×××
Sentiment允許系統對正反及不同程度的情感狀態,做出對應的回應××××××××
Import/export支援knowledge匯出及匯入×××××
DashboardAnalytics dashboard提供報表讓客戶進行數據分析√ (7 D)√ (2 WK)√ (30 D)
√ (30/90 D)√ (3 M)√ (increase)
TestingTester提供測次問句的各種工具
Batch test支援問句的批次測試××××××××
ImproveDeep learning model支援深度類神經網路模型×××××
Active learning從日誌中收集待確認的對話,經客戶確認後學習到知識中××××
Intent recommendation根據已有的對話數據推薦意圖,從而實現更快地訓練××××××
IntegrationCustom plug-in可以客製化整合其他API××
Preview link可提供預覽chatbot的連結××××
Service desk integrations支援無縫轉人工服務××
Versioning允許對assistant的編輯結果,進行版本控管××××××
AuthorizationAccess control可以允許添加訪問人員和管理相應的權限××××××
Search skill支援透過搜索非結構化數據來擴展assistant的knowledge×××××××
DataLog data across instances將正式環境中的insights整合到開發環境中×××××××
Data isolation××××××××
ServiceSLA 99.9%服務等級協議達到99.9%的可用時間×××××××××
Mail subscription支援透過郵件訂閱comments等資料×××××××××
Survey可設立問卷調查模板(對內部或外部調查)×××××××××
對話預處理通過預設的對話匹配規則,可快速自訂簡單的場景××××××××
Matching strictness可調整匹配的閾值××××××××
定時任務支援知識和詞的定時同步××××××××
前後綴處理可自動忽略位於句首或句末的特定詞語或短句××××××××
停用詞可自動忽略句中任意位置的特定詞語×××××××××
Table QA可動態載入結構化數據,並通過自然語言交互,轉換成SQL語句,對資料庫進行查詢×××××××××
質檢自動分析交互日誌,將可能的錯誤應答的對話,提供給維運人員審核××××××××
地區維度根據使用者所在地區給出不同答覆××××××××
知識編輯鎖一位編輯人員操作某個知識時,系統將鎖定該知識群組,使其他人員無法編輯,藉此防止衝突的產生×××××××××

Chia奇亞幣P圖8核每天28P(2.8TB)配置方法

建議電腦配置:
處理器 i7-10700 or 11700
主機板 b460 / z490 / b560 / z590 (支援兩個以上的M.2插槽)
記憶體 16GB D4-3200 x 2
系統碟 SATA SSD 250GB
緩存碟 M.2 SSD PCIE4 2TB x 2 (其實1TB x 2就可以了)

BIOS配置:
Intel C-State設為Disabled

# This is a single variable that should contain the location of your chia executable file. This is the blockchain executable.
#
# WINDOWS EXAMPLE: C:\Users\Swar\AppData\Local\chia-blockchain\app-1.1.5\resources\app.asar.unpacked\daemon\chia.exe
#   LINUX EXAMPLE: /usr/lib/chia-blockchain/resources/app.asar.unpacked/daemon/chia
#  LINUX2 EXAMPLE: /home/swar/chia-blockchain/venv/bin/chia
#  MAC OS EXAMPLE: /Applications/Chia.app/Contents/Resources/app.asar.unpacked/daemon/chia
chia_location: /home/lionethan/chia-blockchain/venv/bin/chia


manager:
  # These are the config settings that will only be used by the plot manager.
  #
  # check_interval: The number of seconds to wait before checking to see if a new job should start.
  #      log_level: Keep this on ERROR to only record when there are errors. Change this to INFO in order to see more
  #                 detailed logging. Warning: INFO will write a lot of information.
  check_interval: 60
  log_level: ERROR


log:
  # folder_path: This is the folder where your log files for plots will be saved.
  folder_path: /home/lionethan/.chia/mainnet/plotter


view:
  # These are the settings that will be used by the view.
  #
  #            check_interval: The number of seconds to wait before updating the view.
  #           datetime_format: The datetime format that you want displayed in the view. See here
  #                            for formatting: https://docs.python.org/3/library/datetime.html#strftime-and-strptime-format-codes
  # include_seconds_for_phase: This dictates whether seconds are included in the phase times.
  #        include_drive_info: This dictates whether the drive information will be showed.
  #               include_cpu: This dictates whether the CPU information will be showed.
  #               include_ram: This dictates whether the RAM information will be showed.
  #        include_plot_stats: This dictates whether the plot stats will be showed.
  check_interval: 60
  datetime_format: "%Y-%m-%d %H:%M:%S"
  include_seconds_for_phase: false
  include_drive_info: true
  include_cpu: true
  include_ram: true
  include_plot_stats: true


notifications:
  # These are different settings in order to notified when the plot manager starts and when a plot has been completed.

  # DISCORD
  notify_discord: true
  discord_webhook_url: https://discordapp.com/api/webhooks/844138664589393920/io3jQxoTO6XoYOtbddojJkE-IXDSsWZ8wpIxTHgaFpdYvBgfRuHjbBYBMECgXl1em3uG

  # IFTTT, ref https://ifttt.com/maker_webhooks, and this function will send title as value1 and message as value2.
  notify_ifttt: false
  ifttt_webhook_url: https://maker.ifttt.com/trigger/{event}/with/key/{api_key}

  # PLAY AUDIO SOUND
  notify_sound: false
  song: audio.mp3

  # PUSHOVER PUSH SERVICE
  notify_pushover: false
  pushover_user_key: xx
  pushover_api_key: xx
  
  # TELEGRAM
  notify_telegram: false
  telegram_token: xxxxx

  # TWILIO
  notify_twilio: false
  twilio_account_sid: xxxxx
  twilio_auth_token: xxxxx
  twilio_from_phone: +1234657890
  twilio_to_phone: +1234657890


instrumentation:
  # This setting is here in case you wanted to enable instrumentation using Prometheus.
  prometheus_enabled: false
  prometheus_port: 9090


progress:
  # phase_line_end: These are the settings that will be used to dictate when a phase ends in the progress bar. It is
  #                 supposed to reflect the line at which the phase will end so the progress calculations can use that
  #                 information with the existing log file to calculate a progress percent.
  #   phase_weight: These are the weight to assign to each phase in the progress calculations. Typically, Phase 1 and 3
  #                 are the longest phases so they will hold more weight than the others.
  phase1_line_end: 801
  phase2_line_end: 834
  phase3_line_end: 2474
  phase4_line_end: 2620
  phase1_weight: 33.4
  phase2_weight: 20.43
  phase3_weight: 42.29
  phase4_weight: 3.88


global:
  # These are the settings that will be used globally by the plot manager.
  #
  # max_concurrent: The maximum number of plots that your system can run. The manager will not kick off more than this
  #                 number of plots total over time.
  # max_for_phase_1: The maximum number of plots that your system can run in phase 1.
  # minimum_minutes_between_jobs: The minimum number of minutes before starting a new plotting job, this prevents
  #                               multiple jobs from starting at the exact same time. This will alleviate congestion
  #                               on destination drive. Set to 0 to disable.
  max_concurrent: 16
  max_for_phase_1: 4
  minimum_minutes_between_jobs: 5


jobs:
  # These are the settings that will be used by each job. Please note you can have multiple jobs and each job should be
  # in YAML format in order for it to be interpreted correctly. Almost all the values here will be passed into the
  # Chia executable file.
  #
  # Check for more details on the Chia CLI here: https://github.com/Chia-Network/chia-blockchain/wiki/CLI-Commands-Reference
  #
  # name: This is the name that you want to give to the job.
  # max_plots: This is the maximum number of jobs to make in one run of the manager. Any restarts to manager will reset
  #            this variable. It is only here to help with short term plotting.
  #
  # [OPTIONAL] farmer_public_key: Your farmer public key. If none is provided, it will not pass in this variable to the
  #                               chia executable which results in your default keys being used. This is only needed if
  #                               you have chia set up on a machine that does not have your credentials.
  # [OPTIONAL] pool_public_key: Your pool public key. Same information as the above.
  #
  # temporary_directory: Can be a single value or a list of values. This is where the plotting will take place. If you
  #                      provide a list, it will cycle through each drive one by one.
  # [OPTIONAL] temporary2_directory: Can be a single value or a list of values. This is an optional parameter to use in
  #                                  case you want to use the temporary2 directory functionality of Chia plotting.
  # destination_directory: Can be a single value or a list of values. This is the final directory where the plot will be
  #                        transferred once it is completed. If you provide a list, it will cycle through each drive
  #                        one by one.
  #
  # size: This refers to the k size of the plot. You would type in something like 32, 33, 34, 35... in here.
  # bitfield: This refers to whether you want to use bitfield or not in your plotting. Typically, you want to keep
  #           this as true.
  # threads: This is the number of threads that will be assigned to the plotter. Only phase 1 uses more than 1 thread.
  # buckets: The number of buckets to use. The default provided by Chia is 128.
  # memory_buffer: The amount of memory you want to allocate to the process.
  # max_concurrent: The maximum number of plots to have for this job at any given time.
  # max_concurrent_with_start_early: The maximum number of plots to have for this job at any given time including
  #                                  phases that started early.
  # initial_delay_minutes: This is the initial delay that is used when initiate the first job. It is only ever
  #                        considered once. If you restart manager, it will still adhere to this value.
  # stagger_minutes: The amount of minutes to wait before the next plot for this job can get kicked off. You can even set this to
  #                  zero if you want your plots to get kicked off immediately when the concurrent limits allow for it.
  # max_for_phase_1: The maximum number of plots on phase 1 for this job.
  # concurrency_start_early_phase: The phase in which you want to start a plot early. It is recommended to use 4 for
  #                                this field.
  # concurrency_start_early_phase_delay: The maximum number of minutes to wait before a new plot gets kicked off when
  #                                      the start early phase has been detected.
  # temporary2_destination_sync: This field will always submit the destination directory as the temporary2 directory.
  #                              These two directories will be in sync so that they will always be submitted as the
  #                              same value.
  # exclude_final_directory: Whether to skip adding `destination_directory` to harvester for farming
  # skip_full_destinations: When this is enabled it will calculate the sizes of all running plots and the future plot
  #                         to determine if there is enough space left on the drive to start a job. If there is not,
  #                         it will skip the destination and move onto the next one. Once all are full, it will
  #                         disable the job.
  # unix_process_priority: UNIX Only. This is the priority that plots will be given when they are spawned. UNIX values
  #                        must be between -20 and 19. The higher the value, the lower the priority of the process.
  # windows_process_priority: Windows Only. This is the priority that plots will be given when they are spawned.
  #                           Windows values vary and should be set to one of the following values:
  #                             - 16384 (BELOW_NORMAL_PRIORITY_CLASS)
  #                             - 32    (NORMAL_PRIORITY_CLASS)
  #                             - 32768 (ABOVE_NORMAL_PRIORITY_CLASS)
  #                             - 128   (HIGH_PRIORITY_CLASS)
  #                             - 256   (REALTIME_PRIORITY_CLASS)
  # enable_cpu_affinity: Enable or disable cpu affinity for plot processes. Systems that plot and harvest may see
  #                      improved harvester or node performance when excluding one or two threads for plotting process.
  #        cpu_affinity: List of cpu (or threads) to allocate for plot processes. The default example assumes you have
  #                      a hyper-threaded 4 core CPU (8 logical cores). This config will restrict plot processes to use
  #                      logical cores 0-5, leaving logical cores 6 and 7 for other processes (6 restricted, 2 free).
  - name: mp600_1
    max_plots: 999
    farmer_public_key:
    pool_public_key:
    temporary_directory: /media/lionethan/chia_temp
    temporary2_directory:
    destination_directory:
      - /media/lionethan/chia_final
    size: 32
    bitfield: true
    threads: 2
    buckets: 128
    memory_buffer: 4000
    max_concurrent: 7
    max_concurrent_with_start_early: 8
    initial_delay_minutes: 0
    stagger_minutes: 60
    max_for_phase_1: 2
    concurrency_start_early_phase: 4
    concurrency_start_early_phase_delay: 0
    temporary2_destination_sync: false
    exclude_final_directory: false
    skip_full_destinations: true
    unix_process_priority: 10
    windows_process_priority: 32
    enable_cpu_affinity: false
    cpu_affinity: [ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 ]
    
  - name: mp600_2
    max_plots: 999
    farmer_public_key:
    pool_public_key:
    temporary_directory: /media/lionethan/chia_temp1
    temporary2_directory:
    destination_directory:
      - /media/lionethan/chia_final
    size: 32
    bitfield: true
    threads: 2
    buckets: 128
    memory_buffer: 4000
    max_concurrent: 7
    max_concurrent_with_start_early: 8
    initial_delay_minutes: 0
    stagger_minutes: 60
    max_for_phase_1: 2
    concurrency_start_early_phase: 4
    concurrency_start_early_phase_delay: 0
    temporary2_destination_sync: false
    exclude_final_directory: false
    skip_full_destinations: true
    unix_process_priority: 10
    windows_process_priority: 32
    enable_cpu_affinity: false
    cpu_affinity: [ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 ]

Airpods 2與Airpods Pro評測與對比

去年在香港機場買了Airpods 2後,由於它戴起來非常舒適,如今已經變成我最常用的耳機,雖然他的音質不如其他高端耳機,但也相當夠用了。萬萬沒想到的是,幾個月後擁有降噪功能的Airpods Pro發表了。

雖然我平常也有隔音降噪的需求,但考慮到荷包的重量,我一直忍受捷運及街頭的噪音,直到今天看到PChome週年慶,才以便宜新台幣1800元,也就是6190元的特價購入。使用幾個小時之後,在此提供Airpods 2與Airpods Pro的比較與心得,給想要購買的朋友參考。

AirPods 2與AirPods Pro

AirPods 2

優點:

  • 目前用戴過最舒適的耳塞式耳機,有時甚至會忘了它的存在
  • 擁有中上的音質,符合一般大眾的口味
  • 無線耳機與麥克風功能,除了iOS裝置,也適用於Android及其它藍芽裝置
  • 可提供超過24小時的聆聽時間,或長達18小時的通話時間
  • 充飽一次電後,最長可提供5小時的聆聽時間或3小時的通話時間
  • 網路售價約新台幣4090元,比AirPods Pro便宜2100元

缺點:

  • 偶爾會受到干擾,導致一耳或全部連線中斷,但大多數的情況會很快恢復
  • 採用Lightning接頭充電,Android使用者必須多帶一條充電線
  • 只能在iOS裝置上,呼叫Siri語音助理;也就是無法在Android上呼叫Google Assistant
  • 開放式耳塞,無隔音效果,在吵雜的環境必須調高音量,可能會影響耳朵的健康

獅子評分

評分:5 分,滿分為 5。

AirPods Pro

優點:

  • 目前用戴過最舒適的耳道式耳機
  • 跟Airpods 2差不多的中上音質,符合一般大眾的口味
  • 無線耳機與麥克風功能,除了iOS裝置,也適用於Android及其他藍芽裝置
  • 物理隔音加降噪功能,確實可以消除80%的低頻噪音,適合在捷運上使用
  • 通透模式下,還原的外界聲音,近似真實的情況

缺點:

  • 由於塞住耳道,舒適度還是略差於Airpods 2,甚至是一般耳塞式耳機,久戴會有疼痛感
  • 偶爾會受到干擾,導致一耳或全部連線中斷,但大多數的情況會很快恢復
  • 採用Lightning接頭充電,Android使用者必須多帶一條充電線
  • 只能在iOS裝置上,呼叫Siri語音助理;也就是無法在Android上呼叫Google Assistant
  • 開啟降噪模式,在馬路上使用必須特別注意安全
  • 由於降噪功能,聆聽與通話時間比起Airpods 2略少10%
  • 雖是耳道式耳機,但設計上只有貼緊耳道而未深入,隔音效果不如一般耳道式耳機
  • 網路售價約新台幣6190元,比AirPods 2貴2100元

獅子評分

評分:4.5 分,滿分為 5。

網友們可能會詢問,那麼Airpods 2和AirPods Pro哪個好?若撇除預算限制,我認為好壞取決於你的使用環境。Airpods 2有最舒服的設計,但容易受噪音影響,最適合在室內的使用;Airpods Pro則是為了隔音,犧牲了一點舒適性,並擁有良好的降噪功能,特別適合在通勤及戶外使用。如果你預算充足,買兩款交替使用也不嫌多餘。

Cybershoes座式全向跑步機評測

Cybershoes是一台低成本的座式全向跑步機,技術上左右腳各採用一條滾輪感測,因此僅支援前後滑步,無法平移;其已足夠讓你在開放世界中順暢遊走,但在室內場景移動則有點彆腳,可能需要花一點時間練習。

Cybershoes 包裝外觀

筆者體質不太容易有VR動暈症,但在Skyrim、Fallout 4等戶外場景用搖桿走,不開移動時的防暈遮罩,還是會覺得不適,使用Cybershoes後,就算把遮罩拿掉也不會VR暈,防暈效果和體驗都非常好。

至於Alyx等室內場景,由於Cybershoes無法平行移動,場景對步伐精準度要求又比較高,我時常會因為冗餘動作,不慎讓滾輪後滑,導致不時產生些許倒退,影響操作及體驗。但這點在開放場景中,可能是因為視野和場地比較遼闊,所以影響不大;也就是說,雖是用Cybershoes走路,但是以滑步的方式進行,因此有點像是用腳在開車,曲折的小徑比較不好走。

優點

  • 可以用Cybershoes鞋底裝置滑步,取代搖桿走路、跑步及倒退
  • 經證實可減緩VR暈動症
  • 採用低延遲的無線傳輸,反應時間良好
  • 有實體滑桿可供調節80%到120%的行走速度
  • 椅子與地毯美觀,鞋底堅固耐用
  • 長時間使用,有類似飛輪的運動效果
  • 比起動輒3000美金以上的全向跑步機,此方案只需349美金(不含運費)

缺點

  • 雖然說是跑步機,實際上是利用滑步驅動雙腳各一根的滾輪旋轉,以得到行走速度
  • 不支援平移走路,這是由於坐在高腳椅上平移或轉向,滾輪會產生一致的軌跡,系統難以區分
  • 向前走路若稍有不慎,可能會驅動滾輪反向,導致些許後退;倒退走路反之亦然。可透過練習改善
  • 不是所有VR內容都支援;所支援的不同VR內容,行走速度和體驗也不一致
  • 堅硬的Cybershoes鞋底使用時,容易撞到椅子底盤與中柱發出聲響
  • 從芬蘭訂購到台灣,運費高達130美金

如上所述,Cybershoes非常適合開放世界,連續走了幾小時後,就像是在騎飛輪運動,不只是腿痠,屁股還很痛;但在室內場景中,需要練習才能走得好,我正在設法減少冗餘動作,並在不移動時固定滾輪,透過精準操作克服上述問題。

獅子評分

評分:4 分,滿分為 5。

Kat Loco VR運動系統評測

日前購買的Kat Loco(VR locomotion system)及腳踏墊終於到了,這是可以在VR中模擬步行的裝置;經過這幾天的測試,得到了一些結論。由於本身是技術背景的,對於此產品只採用三個六軸傳感器,已經可以預期體驗不會太好了;但有介於用VR手把進行走動的不直覺,除了自身使用之外,主要也想要借此探索感測器和深度學習,在VR輔助設備的應用,也許有一天會想自己立項開發,以下是我的評測心得。

Kat VR腳踏墊

產品外觀

優點:

  • 可協助使用者保持在場地的中心。
  • 踏墊夠厚,即使穿鞋也可以感受到。

缺點:

  • 由於踏墊的觸感不同於地板,走動出入時會影響沉浸感。
  • 踏墊較厚,也容易掀開,會經常絆到腳。

結論:

  • 放上踏墊反而危險,容易因絆到腳而跌倒,適得其反。

獅子評分

評分:2 分,滿分為 5。

Kat Loco

產品外觀
使用者介面

優點:

  • 可用原地踏步的方式前行。
  • 精美的包裝。
  • 美觀的使用者介面。

缺點:

  • 原地踏步動作必須維持一定的速度才能行走,非常耗費力氣;也很難藉由踏步的速度,控制行走的速度。
  • 動作的實際延遲時間肯定比官方宣稱的20ms還要長,反應不夠即時。
  • 透過擺出向前、向後、向左、向右,各四種姿勢的巡航模式,根本無法正常使用。
  • 可以從監測數據中發現,雙腳配戴的位置角度,對六軸傳感器的影響非常巨大,讓準確度大打折扣。
  • 線上說明文件不足,即使想要調校也難以進行。

結論:

  • 由於巡航模式無法正常使用,就只能原地踏步筆直往前走,非常愚蠢。
  • 另外一套運動系統Cybershoes,坐著使用滾輪鞋移動,可能會比這個更好用。
  • 雖沒用過全向跑步機,但觀察過影片,目前市面上跑步機的體驗,可能都不會太理想。
  • 以上,讓我確信使用Inside-out定位在足夠大的空間(可大至操場),使用真實的雙腳到處跑蹲跳,可以得到最好的體驗。

獅子評分

評分:1 分,滿分為 5。

Oculus Quest有線與無線串流比較

由於近期Vault發表了Half-Life的VR大作,促使我訂購了Oculus Link連接線,搭配Oculus Quest重啟PC VR之旅。在嘗試使用Link技術後,對其體驗基本滿意,但仍希望擁有更好的效果,因此對備受好評的Virtual Desktop感到好奇;除了用自身的小米路由器測試外,也購買了支援MU-MIMO的最新路由器,避免多裝置連線時影響串流速度。以下是我的測試心得分享。

Oculus Link 頭戴式裝置連接線

Oculus Link 連接線
  • 數據
    • 連接線NT$2400
    • USB 3.0轉Type C轉接頭(VL160晶片)NT$300
    • 軟體官方免費提供
    • 線長5公尺
    • 附帶Quest頭戴顯示器用的線纜固定器,防止線纜脫落
  • 優點
    • 可以用Quest玩PC VR
    • 無論是顯示器或控制器延遲,都比無線更少
    • 沒有無線偶爾出現的卡頓問題
    • 可以一邊玩一邊充電
  • 缺點
    • 壓縮率高導致色彩黯淡,而且目前不能調整壓縮率
    • 轉向時會常常卡到線,影響VR沉浸感;可用吊線支架改善體驗,但仍不如無線方便

獅子評分

評分:3 分,滿分為 5。

舊款 Wi-Fi 5 無線路由器(支援802.11ac)+ Virtual Desktop

2014年 小米路由器 mini
  • 數據
    • 路由器NT$600
    • 軟體NT$600
    • 平均延遲(Latency) 25ms,不含控制器延遲
    • 最高傳輸速率(Video Bitrate)約49Mbps
    • 電池續航力約2.5小時
  • 優點
    • 可以用Quest玩PC VR
    • 少了線的束縛,讓VR沉浸感更好
    • 影音串流壓縮技術佳,色彩較Oculus Link好
  • 缺點
    • 延遲較有線多一倍左右,但仍落在可以接受的範圍
    • 無線會受到環境干擾,偶爾會卡頓,穩定度不如Oculus Link
    • 小米路由器無法發揮802.11ac的性能,導致傳輸速率只有49Mbps
    • 目前只要是無線VR頭戴顯示器,都會有續航力低的問題
    • 多裝置連線時會影響串流速度

獅子評分

評分:4 分,滿分為 5。

Wi-Fi 6 無線路由器(支援802.11ax、MU-MIMO)+ Virtual Desktop

2019年 TP-link AX10
  • 數據
    • 路由器NT$2300
    • 軟體NT$600
    • 平均延遲(Latency) 25ms,不含控制器延遲,實測數字比前者更穩定
    • 最高傳輸速率(Video Bitrate)約92Mbps
    • 電池續航力少於2.5小時
  • 優點
    • 可以用Quest玩PC VR
    • 少了線的束縛,讓VR沉浸感更好
    • 影音串流壓縮技術佳,色彩較Oculus Link好
    • MU-MIMO技術可降低多裝置連線時,對串流的影響
  • 缺點
    • 延遲較有線多一倍左右,但仍落在可以接受的範圍
    • 無線會受到環境干擾,偶爾會卡頓,穩定度不如Oculus Link
    • Oculus Quest只支援到802.11ac,我考慮到後續升級與其他用途,才直接上802.11ax
    • 目前只要是無線VR頭戴顯示器,都會有續航力低的問題
    • 比較高的Video Bitrate,會讓續航力差的Quest頭戴顯示器更加耗電;意外的是92Mbps與49Mbps相比,在一般遊戲中畫質差異並不大,但玩動作遊戲就能感受到串流率不足帶來的模糊感。
Virtual Desktop的使用者介面

結論

  • 使用線纜的Oculus Link技術,擁有絕對穩定的串流與低延遲,在顯示與控制上,適合要求反應速度及低延遲的動作遊戲等;但得到此優勢的同時,線纜卻會造成移動不便。缺點是畫面壓縮率高導致灰濛,在不比較的情況下沒有傷害。
  • 無線的Virtual Desktop串流技術適合看FPS僅有24幀的電影,或不要求反應速度及低延遲的遊戲;但在動作遊戲中,卻又因無線所帶來的順暢移動,為其劣勢加分。偶爾會出現的卡頓,並不影響遊玩體驗,所以適用於大部分遊戲,推薦玩家採用此方案。
  • 日前Oculus要求Virtual Desktop移除遊戲串流功能,使用者必須自行透過SideQuest解禁;相信是因為Virtual Desktop串流技術過於強勢,會使得擁有高端PC的玩家,將大部分消費轉移至Steam、Viveport等平台,的確對Oculus Store的發展不利;特別是為Quest一體機開發的遊戲,以及平台上的影音內容。

獅子評分

評分:4.5 分,滿分為 5。

[對話式AI-3] Chatbot的記憶與決策–對話管理篇

聊天機器人的對話管理(Dialogue Management)是為了總結目前的對話狀態,並決定系統該做些什麼。通常分為兩個子模組,負責更新對話狀態的「對話狀態追蹤」(Dialogue State Tracking),其輸入自然語言理解模組所得到的使用者動作,以及過往的對話歷史,輸出對話狀態;以及決定系統動作」的「對話策略學習」(Dialogue Policy Learning),其輸入對話狀態,輸出系統動作。上述的「使用者動作、對話狀態、系統動作」皆可用一個意圖與一組槽位值表示。

對話狀態追蹤(Dialogue State Tracking)

目的是透過「使用者動作」及「對話歷史」更新對話狀態,其對話歷史可能隱含著因資訊不足,經過系統反問使用者後,產生的「多輪對話」內容;有些需求還會參考使用者畫像(User Profile),以補足必要的「個性化資訊」。透過推理和總結上述內容,轉換成簡單的對話狀態(一個意圖與一組槽位值),系統可以將當前的對話狀態映射成更完整的表示(Representation)。為了考慮自然語言的模稜兩可、語音辨識或自然語言理解模組產生的失誤,根據可能正確的使用者動作數量,可進一步分成只考慮置信度最高的1-Best,以及考慮多個使用者動作與置信度的N-Best方法;常用CRF、RNN、LSTM模型追蹤序列。

對話策略學習(Dialogue Policy Learning)

目的是透過「對話狀態」決定系統該做些什麼,如果對話狀態的意圖在系統能夠提供的服務項目之內,系統會檢查槽位值是否齊全,然後使用其內容查詢服務API,以得到關鍵答案或內容;若對話狀態的意圖不明,或其符合特定服務但槽位值有缺失,系統應該主動向使用者提問,透過多輪對話及對話狀態追蹤來蒐集足夠的資訊。最後將關鍵答案或內容封裝到系統動作中,以一個意圖及一組槽位值代表,提供給自然語言生成模組(Natural Language Generation)。

對話策略的實作方法

  • 基於規則( Rule-based )的方法,透過編寫明確的規則,來建立各種槽位狀態下,使用者動作所對應的系統動作,此種方法無法處理不確定的狀態,且需要手工編寫大量規則,僅適合特定領域的簡單場景。
  • 基於有限狀態機(Finite-State Machine, FSM),此種方法又可分為「以點代表槽位狀態,以邊代表系統動作」,以及「以點代表系統動作,以邊代表槽位狀態」兩種方案;槽位狀態可分為有或無,系統動作則是詢問槽位或最後回答兩種,為避免置信度過低,也可以增加動作請使用者二次確認。由於前者在槽位增加時,會使狀態數量急遽增多,只適合資料驅動的方式;若要以手工建置會建議採用後者。採用有限狀態機的優點在於實作簡單,且容易理解,缺點是每個狀態和動作都要手工設計,不利於複雜場景。
  • 基於統計(Statistical-based)的方法,通常採用馬可夫鏈(Markov Chain)將對話過程表示成決策過程,而系統在每個對話狀態中決定下一步動作。採用馬可夫鏈的優點在於只需要在決策過程中定義槽位狀態與系統動作,就可以自動學習到狀態的移轉關係,也可在過程中導入強化學習(Reinforcement Learning)與線上學習(Online Learning),缺點是同樣需要手工設計,不利於複雜場景。
  • 基於深度學習(Deep Learning)的方法,輸入使用者動作及相關特徵,輸出對應的系統動作,以訓練深度類神經網路模型。基於深度學習的方法需要大量訓練資料才能夠取得效果,目前實際應用上還難以滿足此須求。

對話管理的具體流程

  1. 自然語言理解模組取得使用者對話「推薦我一家台北的餐廳」,此時會偵測使用者意圖及識別命名實體,並將結果封裝成使用者動作(意圖=推薦餐廳, 地點=台北),得以將自然語言映射成簡單的語意表示。
  2. 對話狀態追蹤模組透過使用者動作(意圖=推薦餐廳, 地點=台北)更新當前的對話狀態,然後在地點填充常用的預設值,並透過使用者畫像補充用餐的個性化資訊,最後輸出對話狀態(意圖=推薦餐廳, 地點=台北公館, 口味=喜歡吃辣)。
  3. 對話策略學習模組得到對話狀態後,發現其意圖在系統能夠提供的服務項目之內,但還缺少了用餐時間,系統應該反問使用者;所以輸出系統動作(意圖=對空白槽位提問, 地點=台北公館, 口味=喜歡吃辣, 時間=Null)。
  4. 自然語言生成模組執行系統動作,產生問句向使用者提問欲用餐的時間「你想在什麼時候用餐呢?」。
  5. 自然語言理解模組取得次輪的使用者對話「明天中午」,再次偵測意圖及識別命名實體,得到使用者動作(意圖=不明, 時間=2020年3月30日12點)。
  6. 對話狀態追蹤模組參考使用者動作及對話歷史,更新當前的對話狀態(意圖=推薦餐廳, 地點=台北公館, 口味=喜歡吃辣, 時間=2020年3月30日12點)。
  7. 對話策略學習模組利用對話狀態及對話歷史,蒐集餐廳推薦服務的必要資訊,透過查詢服務API得到答案後,封裝成系統動作(意圖=推薦餐廳, 地點=台北公館, 口味=喜歡吃辣, 時間=2020年3月30日12點, 餐廳=右手餐廳, 類型=泰式料理)。
  8. 自然語言生成模組執行系統動作,產生具體答案「建議你明天中午可以到台北公館的右手餐廳享用酸辣的泰式料理」。

未來的發展方向

為了解決基於深度學習的對話管理方法,在訓練資料上普遍不足的問題,業界已嘗試使用N-Shot Learning在小樣本下進行訓練,或使用Zero-Shot Learning在沒有任何訓練資料的情況下,進行現有模型的遷移與補全,以及在馬可夫鏈決策過程中,導入強化學習(Reinforcement Learning)與線上學習(Online Learning),建立獎懲與持續學習的機制;也有學者將生成對抗網路(Generative Adversarial Network, GAN)應用在自然語言處理上,透過結合強化學習的SeqGAN讓兩個模型相互博弈,以學習到最強的對話策略。

參考文獻

[對話式AI-2] Chatbot的閱讀能力–自然語言理解篇

一個基本的文字型聊天機器人框架(Chatbot Framework),包含「自然語言理解、對話管理、自然語言生成」三大模組。有些機器人能夠使用語音與使用者交互,還需包含「自動語音辨識、語音合成」模組 ,例如知名的Siri、Google Assistant。本期AI專欄將為大家詳細介紹聊天機器人的核心「自然語言理解 」模組。

自然語言理解是什麼?

自然語言理解(Natural Language Understanding)是為了把自然語言轉換(映射)成機器可讀的語意表示(Semantic Representation),是自然語言處理(Natural Language Processing)中最困難的技術;若要讓機器理解自然語言,必須分析「語音、音韻、詞法、句法、語意和語用」,可以簡單理解如下:

  • 語音(Phonetics):人類如何發出語音
  • 音韻(Phonology): 如何拼出自然語言的讀音
  • 詞法(Morphology):如何構成自然語言的單詞
  • 句法(Syntax):如何構成自然語言的句子
  • 語意(Semantics):如何理解自然語言的句子
  • 語用(Pragmatics):如何使用自然語言的句子

對機器來說,自然語言理解可能碰到以下問題:

  • 語音辨識所產生的錯誤,是否能在自然語言理解中容錯?
  • 中文並沒有像是英文的空格去分隔單詞,如何正確分詞?
  • 如何兼容同一個語意的上百種自然語言表示?例如:「我愛你、我喜歡你、我中意你、你是我的菜」 等 。
  • 同一句話可能會因情境(上下文)不同,而有不同的語意, 如何正確判斷 ?
  • 對話中的代詞或省略所代表的內容?
  • 還沒學到的詞彙該如何處理?例如:「是在哈囉、 新冠肺炎」。

自然語言理解在聊天機器人的功用

自然語言理解在聊天機器人發揮的功能,主要可分為以下七點:

  • 使用者意圖偵測( User Intent Detection ):針對使用者對話的意圖進行分類,得以確定使用者想要或計劃做什麼,可分為顯性(直接知道分類,例如:「今天天氣好嗎?」)和隱性意圖(間接推敲出分類,例如:「今天適合出門嗎?」),以上兩個問句,使用者意圖都是「查天氣」。
  • 命名實體識別(Named Entity Recognition):用來擷取使用者對話中具有特定意義的實體,例如:「查詢日期、地點」等專有名詞,以填充特定意圖的槽位(Slot filling),例如:「2020年2月25日台北的天氣?」,日期的槽位值是「2020年2月25日 」,地點的槽位值是「台北」;而上述的使用者意圖「查天氣」正是需要這兩個槽位值補充說明。
  • 指代消解(Coreference Resolution):判斷在對話中代詞所代表的實體或事件,例如威諾格拉德模式(Winograd Schema)的示例
  • 省略恢復:判斷使用者在對話中所省略的內容。
  • 情感分析(Sentiment analysis):識別使用者對話中的主觀資訊,例如正面或負面,或尋找更複雜的狀態,例如開心、生氣、哀傷等;可以讓機器與人交互時更有溫度。
  • 意圖確認:當意圖識別的置信度(Confidence)不足時,請使用者再次進行確認。
  • 拒絕識別:當識別的意圖超出服務範圍、涉及敏感內容或置信度過低時,系統可拒絕回覆。

不同類型的聊天機器人(請參考聊天機器人的類型與對比),其自然語言理解著重的技術有所不同,如下:

一、問答系統(Question Answering system):

著重於識別問題中的資訊詞,例如問題詞(Who What Where When Why How)、焦點詞、主題詞、中心動詞等,與自然語言理解略有不同,比較偏向自然語言處理的範疇;以模板比對、基於統計、基於深度學習的語意分析,基於深度學習的端對端生成(此方法目前處於研究階段),以上四種方法為主流。主要評估指標為召回率(Recall)、精確率(Precision)、F-Score。

二、任務導向對話系統(Task-Oriented Dialogue system)

著重於將自然語言,轉換成機器可讀的語意表示,例如分為使用者意圖(User Intent)及槽位值(Slot Value)。具體工作有中文分詞、詞性標註、命名實體識別、指代消解、句法分析等。以基於規則、基於統計、基於深度學習的意圖識別與槽位填充,以上三種方法為主流;主要評估指標為意圖分類準確率(Accuracy)、槽位填充的F-Score。

三、閒聊系統(Chit-Chat Dialogue system)

著重於個性化,以及情感分析(使用自然語言處理來識別對話中的主觀資訊,例如正面或負面等)。以對話庫檢索、基於深度學習的端對端生成,以上兩種方法為主流。主要評估指標為詞重疊率和向量距離。

自然語言理解的實作方法

如上所述,自然語言理解可視為分類和序列標註問題,通常分為基於規則、基於統計、基於深度學習三種方法:

  • 採用基於規則的方法,優點在於容易調整修正,而且不需仰賴訓練資料,缺點是當場景變多時,規則數量也大幅增加,將變得難以維護。
  • 採用基於統計的方法,優點在於系統強健性高(Robustness),而且容易維護。缺點是訓練出來的模型較難解釋和修正。常用支持向量機( Support Vector Machine, SVM)或自適應增強(Adaptive Boosting, )進行意圖分類,隱藏式馬可夫模型(Hidden Markov Model, HMM)或條件隨機域(Conditional Random Field, CRF)進行分詞、實體識別。
  • 採用基於深度學習的方法,優點在於其效果最佳,系統強健性高,而且容易維護,缺點是需要大量的訓練資料,模型的空間與時間複雜度高 ,而且幾乎無法解釋與修正, 如同黑盒子一般。常用Attention-based RNN及LSTM等模型,進行意圖偵測與槽位填充等任務。

自然語言理解相關技術的其他用途

自然語言理解涉及的自然語言處理技術,除了用於聊天機器人,也可用於其他用途:

  • 垃圾郵件偵測 (Spam Detection):分析大量的資料歸納出特徵,協助使用者過濾垃圾郵件,例如Gmail中的垃圾郵件匣。
  • 搜尋引擎建議(Search Engine Suggestions):透過預測使用者輸入的字詞,主動推薦搜尋的內容,例如在Google搜尋輸入些許字詞,所出現的推薦搜尋清單。
  • 機器翻譯(Machine Translation):將某種自然語言翻譯成另一種自然語言,例如Google翻譯的英翻中功能。
  • 自動摘要(Automatic Summarization):分析一篇或多篇文章,自動產生一段大意,常應用在新聞短訊中。

參考文獻

[對話式AI-4] Chatbot的挑戰與發展趨勢

雖然電腦視覺(Computer Vision)透過深度學習(Deep Learning)技術取得了重大進展,但在自然語言處理(Natural Language Processing)領域,深度學習的導入仍然處於發展初期。

以聊天機器人(Chatbot)來說,自從圖靈測試在2014年被聊天機器人Eugene通過後,加拿大學者改進測試的缺失提出了威諾格拉德架構挑戰賽(Winograd Schema Challenge),也是目前最具權威的AI競賽。

該競賽的第一輪是代詞消歧問題(Pronoun disambiguation problems)。舉例來說,當人類分析句子時,會用經驗來理解指代的對象:

  • 市議會拒絕示威者,因為他們害怕暴力。
  • 市議會拒絕示威者,因為他們提倡暴力。

而這個選擇題只有兩個答案,代詞”他們”是指”市議會”還是”示威者”,AI應該要指出在第一句說的是市議會,第二句說的是示威者,從問題上可以發現,系統無法透過這段話的上下文進行理解得到答案,這在傳統實作上必須透過知識圖譜(Knowledge Graph)進行推理,或使用深度類神經網路模型,要通過比賽拿到獎金25,000美金,準確率(Accuracy)必須達到90%以上,但目前最好的成績只有58%,遠比人類低得多。

除了上述根本影響Chatbot問答品質的問題,還有幾個難題仍未被突破:

  1. 通用的模型架構(Universal Model Architecture):為了整合語音辨識、詞法分析、句法分析、語意分析、深度學習,答案搜尋,對話管理、自然語言生成和語音合成等模組,確保其相容性,當前Chatbot架構與模型相當複雜,管理較為困難,如何研發通用的架構與模型,是未來所有同業的發展目標。
  2. 情感計算( Affective Computing ):從分析文本的情感 (Sentiment Analysis)到辨識人類情緒的情感計算,例如開心、生氣、哀傷等;可以讓Chatbot與人交互時更有溫度,是目前產學界熱門研究方向。
  3. 開放領域(Open Domain):現在的Chatbot只能做好特定領域的工作,如何建構開放領域的知識,甚至不需要人工建構知識,讓機器自學習,也是產學界正在努力的方向。
  4. 端對端 ( End to end ) :不經過傳統的模組串聯,利用深度學習 ( Deep Learning ) 建立端對端的簡潔模型;達到輸入原始資料後,可直接得到想要的輸出結果,但與此同時還要支援多輪對話管理、上下文情境及知識圖譜推理,避免安全回答,甚至是保持Chatbot個性的一致性,正確的進行指代消解,這些挑戰都是產學界近期的目標。
  5. 基於生成的模型(Generative Model):目前自然語言生成技術 ,可分為基於檢索、基於範本及基於生成兩種方法,三者都可以導入深度學習技術,目前以基於檢索及基於範本為業界主流;雖然深度學習Seq2seq模型非常適合產生文字,但此基於生成方法尚處早期的發展階段,空間和時間複雜度高,實際應用效果不佳。

[對話式AI-7] 預訓練語言模型比較(ELMO、BERT、GPT-2)

預訓練(Pre-train)語言模型可用於自然語言理解(Natural Language Understanding)的命名實體識別(Named Entity Recognition)、問答(Extraction-based Question Answering)、情感分析(Sentiment analysis)、文件分類(Document Classification)、自然語言推理(Natural Language Inference)等任務。

以及自然語言生成(Natural Language Generation)的機器翻譯(Machine translation)、自動摘要(Automatic summarization)、閱讀理解(Reading Comprehension)、資料到文本生成(Data-to-Text Generation)等任務。

本文透過列舉時下主流預訓練語言模型的特點,介紹最具代表性的ELMO、BERT及GPT-2模型;用最簡短的文字敘述,讓大家能夠輕易比較出差異。

ELMO(Embeddings from Language Model)

  • RNN-based Language Models
  • 透過一堆句子訓練,不需要標註
  • 預測下一個Token
  • 從RNN的hidden layer取得Contextulize word embedding
  • 從正反向embedding接起來就是上下文的embedding
  • 最後把每一層的embedding都加起來,再由後續任務學習到加權參數
  • 94M個參數

Source: https://arxiv.org/abs/1802.05365

BERT(Bidirectional Encoder Representations from Transformers)

  • 屬於Transformer的Encoder
  • 只需要訓練Transformer的Encoder(輸入輸出一對一)
  • 透過一堆句子訓練,不需要標註
  • 給一個詞序列,每一個詞都會吐embedding
  • 中文更適合用字為單位,因為用one-hot encoding詞太多了;常用中文字約4800個,中文詞則比這個高數倍
  • Masked LM: 輸入詞序列中隨機15%的詞被換成特殊的Token [Mask],並做預測
  • 預測下一個句子: 引入[SEP]代表兩個句子的交界,及[CLS]代表輸出分類結果的位置
  • 上述兩種方法都是把抽出來[Mask]或[CLS]的Vector丟到Linear Multi-class Classifier去預測詞
  • 以上兩種方法要同時使用
  • 340M個參數

Source: https://arxiv.org/abs/1810.04805

GPT-2(Generative Pre-Training)

  • 屬於Transformer的Decoder
  • 預測下一個Token
  • 40GB的文本訓練出來的
  • 可以做到Zero-shot Learning,不需訓練資料,做到Reading Comprehension(F-score=55接近Dr.QA)、Summarization(跟隨機差不多)、Translation(跟隨機差不多)
  • 1542M個參數

Source: https://d4mucfpksywv.cloudfront.net/better-language-models/language_models_are_unsupervised_multitask_learners.pdf