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


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的答案是固定的×××××××
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的形式添加在答案中。×××
DashboardAnalytics dashboard提供報表讓客戶進行數據分析√ (7 D)√ (2 WK)√ (30 D)
√ (30/90 D)√ (3 M)√ (increase)
Batch test支援問句的批次測試××××××××
ImproveDeep learning model支援深度類神經網路模型×××××
Active learning從日誌中收集待確認的對話,經客戶確認後學習到知識中××××
Intent recommendation根據已有的對話數據推薦意圖,從而實現更快地訓練××××××
IntegrationCustom plug-in可以客製化整合其他API××
Preview link可提供預覽chatbot的連結××××
Service desk integrations支援無縫轉人工服務××
AuthorizationAccess control可以允許添加訪問人員和管理相應的權限××××××
Search skill支援透過搜索非結構化數據來擴展assistant的knowledge×××××××
DataLog data across instances將正式環境中的insights整合到開發環境中×××××××
Data isolation××××××××
ServiceSLA 99.9%服務等級協議達到99.9%的可用時間×××××××××
Mail subscription支援透過郵件訂閱comments等資料×××××××××
Matching strictness可調整匹配的閾值××××××××
Table QA可動態載入結構化數據,並通過自然語言交互,轉換成SQL語句,對資料庫進行查詢×××××××××

My Experience with XREAL Air 2 Pro AR Glasses

As an enthusiast of VR, AR, and MR, I sincerely believe that Apple Vision Pro’s biggest competitor in the future is XREAL (formerly NREAL). XREAL introduced the XREAL Air product, achieving an ultimate slim design for AR glasses and using a smartphone as the computational solution by a Chinese company.

The XREAL Air display component has a limited field of view (FOV) of only 46 degrees, which falls short of the immersive requirements for VR experiences. The developer ecosystem is not robust enough, and there is no dedicated app store, resulting in a lack of sufficient content for the primary AR experience. However, due to its relatively affordable price, lightweight design, higher pixel density (PPI), and a real background light (non-VR-generated realistic background), XREAL Air serves as a 3 DoF giant screen display with superior clarity and comfort compared to various VR devices. It is especially suitable for watching videos and playing games while lying down.

XREAL Air, as an excellent giant screen, is often used in conjunction with the Steam Deck for gaming or with high-end Samsung phones supporting the Dex operating system for watching videos. You may also consider purchasing the hastily released Beam, the official computing terminal device from XREAL, to upgrade the giant screen from 0 DoF to 3 DoF. However, its performance, image quality, operating experience, and application support are not as good as the former two options.

In addition, the second-generation product, XREAL Air Pro 2, improves comfort, speaker sound quality, and achieves individual color calibration. The upcoming XREAL Air 2 Ultra adds two cameras to support 6 DoF and hand tracking, emphasizing Spatial Computing, taking a step further toward XR, resembling a more affordable and lightweight version of Apple Vision Pro. However, facing Apple Vision Pro’s luxurious hardware, XREAL Air 2 Ultra is noticeably lacking in numerous sensors, raising concerns about its overall effectiveness.

Nevertheless, the simplified hardware architecture of XREAL Air 2 Ultra has increased my expectations for the ultimate slim and comfortable XR glasses. As a user of XREAL Air and Air 2 Pro, I will now compare the hardware advancements in the context of video watching and gaming scenarios.

The improvements of XREAL Air 2 Pro are as follows:

  • 10% lighter (72 grams for the second generation, compared to 79 grams for the first generation).
  • 20% higher brightness (500 nits for the second generation, compared to 400 nits for the first generation).
  • Color calibration on an individual basis, resulting in smaller color deviations.
  • More balanced weight distribution in the frame, preventing a top-heavy feel.
  • The nearsighted glasses frame is positioned at a more appropriate distance from the eyeballs, avoiding contact between eyelids and lenses.
  • Softer nose pad cushions, reducing the likelihood of imprints and discomfort on the nose.
  • The Pro version includes electrochromic lenses, allowing for three-stage adjustment of outdoor lighting, providing practical functionality.

The drawbacks are as follows (not officially disclosed by the manufacturer):

  • Smaller display components and a reduced pupil distance (PD), resulting in blurred edges of the display, with more pronounced effects for individuals with larger pupil distances. This issue was not present in the first generation.
  • Unexplained reasons leading to high-contrast scenes, such as white text on a black background, causing more severe glare compared to the first generation.

XREAL Air 2 Pro AR眼鏡的使用心得

身為VR、AR及MR的愛好者,我真心認為Apple Vision Pro,未來最大的競爭者是XREAL(前NREAL);一間推出XREAL Air產品,把AR眼鏡極致輕薄化,用手機作為運算解決方案的中國公司。

由於XREAL Air顯示元件只有46度的可視範圍(FOV),達不到VR沉浸體驗的要求,開發者生態不夠蓬勃,也還沒有自己的應用商店,以至於主打的AR體驗沒有足夠的內容。但受益於相對親民的價格、輕薄的體積、較高的像素密度(PPI),以及真實的背景光(非VR再生成的現實背景),作為3 DoF巨屏顯示器,畫面清晰度及舒適度都遠勝過各種VR設備,特別適合躺著看影片和玩遊戲。

XREAL Air作為一塊優秀的巨屏(巨大顯示器),用戶經常搭配Steam Deck來玩遊戲,或使用支持Dex操作系統的三星高階手機來看影片;你也可以考慮購入官方倉促推出的計算終端裝置Beam,將巨屏從0 DoF提升至3 DoF,但其效能、畫質、操作體驗與應用支持,都不如前面兩者。

此外,XREAL二代產品Air Pro 2,提升了配戴的舒適度、揚聲器音質,並做到逐台調色,即將發布的XREAL Air 2 Ultra還增加了兩個攝像頭,以支持6 DoF和手部追蹤,主打空間運算Spatial Computing,讓這個產品進一步邁向XR,頗有Apple Vision Pro輕薄廉價版本的架式。但面對Apple Vision Pro豪華的硬體,XREAL Air 2 Ultra明顯缺乏眾多感測器,其效果令人堪憂。

無論如何,XREAL Air 2 Ultra簡潔的硬體架構,讓我對極致輕薄、舒適配戴的XR眼鏡有了更多期待。最後作為XREAL Air及Air 2 Pro的用戶,我將以看影片與玩遊戲的使用場景,為您比較二代硬體的進步:

Xreal Air 2 Pro進步如下:

  • 重量輕10%(二代72克,一代79克)
  • 亮度高20%(二代500尼特,一代400尼特)
  • 經過逐台調色,色差更小
  • 鏡腳有更平衡的配重,不會頭重腳輕
  • 近視鏡架與眼球有更適當的距離,避免眼皮碰到鏡片
  • 更軟的氣墊鼻托,讓鼻子不容易產生壓痕與不適
  • Pro版本還有電致變色鏡片,可以三段調整戶外光線,此功能非常實用


  • 較小的顯示器元件及更小的瞳距(PD),導致畫面邊緣模糊,瞳距大者會更嚴重,一代無此問題
  • 不明原因,導致高反差畫面,如黑底白字,會有更嚴重的散光,一代無此問題


處理器 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就可以了)

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

  # 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

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

  # 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

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

  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}

  notify_sound: false
  song: audio.mp3

  notify_pushover: false
  pushover_user_key: xx
  pushover_api_key: xx
  notify_telegram: false
  telegram_token: xxxxx

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

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

  # 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

  # 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

  # 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
    temporary_directory: /media/lionethan/chia_temp
      - /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
    temporary_directory: /media/lionethan/chia_temp1
      - /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 包裝外觀

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



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


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



評分: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):分析一篇或多篇文章,自動產生一段大意,常應用在新聞短訊中。