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 ]

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。

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

參考文獻

RSC修錶及驗錶過程分享

母親大人的OP26是香港購入的,因不慎從口袋掉出摔破鏡面送修;Batman是歷史高點在玩錶舍購入的,全新有膜沙烏地阿拉伯18年11月保卡,雖然說現在賠了一些,但畢竟停產了相信跌幅有限,購入至今也戴了半年多。

送驗及送修過程:

由於平常會用清水軟刷洗錶,本次趁著幫母親大人送修摔破鏡面的OP26,想檢測Batman的防水性能,但RSC要收2000元檢測費,因此改為利用免費的送驗服務,檢測一下錶況,若防水圈有問題,應該也會藉此發現。

OP26因為殘留的玻璃碎削,RSC小姐要求強制洗油;基本檢測後,師傅發現龍頭有磨損,怕影響防水性能,所以可自費更換。費用分別是藍寶石鏡面NT$2800+龍頭2000+洗油保養11800,總計16600。

最後得到兩張綠色的工作單據,送修的手錶寫明20天後取件,領錶時再付費;送驗的則是待通知。

取回過程:

等待約20天後,接到RSC通知,已可取回手錶;送驗的Batman僅簡單告知沒有問題,但使用數日後發現變準了,本來誤差是+4秒/日,現在接近0秒/日,不知道是調校過,還是消磁所帶來的效果;修好的OP26則是發現錶盤有被玻璃碎屑輕微刮傷,如果在意的應該可以要求換面盤,經過測量得到誤差+2.38秒/日。付費方式可以使用現金或刷卡,本次選擇刷卡。

最後得到了刷卡單據、統一發票、印有Logo的收納紙套、送驗的Batman付塑膠錶套,送修洗油的OP26贈原廠皮套。

Rolex百事圈與藍黑圈搜尋趨勢分析

最近一直在百事可樂與蝙蝠俠間猶豫不決,因此產生了一個疑問,鋼版百事圈和藍黑圈倒底誰比較紅?以及雜誌上的說法到底有沒有根據?


從Chrono24上可以發現新版藍黑圈平均售價63.4萬,比百事圈60.1萬還要來得高;但又觀察到台灣市場,百事圈售價略高藍黑圈約1萬,因此發揮科男的精神,特別做了一下調查。


從Google Trends可以發現,2018年3月鋼板百事圈發布以後,馬上爆款,之後逐步與舊版三板帶藍黑圈打平;而2019年3月新版藍黑圈發布以後,一併拉抬了舊版的聲勢,甚至高過新版。而在近兩個月內,全球新版藍黑圈詢問度52%略高於百事圈48%,但若加上舊版藍黑圈,則藍黑圈整體詢問度70%遠高於百事圈30%。


不看舊版藍黑圈的話,近兩個月在美國,藍黑圈詢問度52%百事圈48%;在日本,藍黑圈
47%百事圈53%。台灣數據過少無法判斷。


結論:
近期數據顯示,若只看新款,兩者持平;其中美國偏愛蝙蝠俠,歐洲持平,亞洲偏愛百事可樂。若納入舊款,蝙蝠俠整體熱門程度高於百事可樂,且舊款詢問度更高。

流言終結者:
Q: 百事圈更紅?
A: 2018年百事圈的聲勢,其實與2013年舊版藍黑圈相當;2019年新版藍黑圈走勢則有待觀察。
Q: 百事圈帶動藍黑圈銷量?
A: 舊版藍黑圈2013至2018年的搜尋量相當穩定,2018年3月百事圈的發布,並未明顯拉抬舊版藍黑圈的詢問度。
Q: 新版藍黑圈帶動舊版的銷量?
A: 2019年3月新版藍黑圈的出現,明顯拉抬了舊版的聲勢,但詢問度仍是舊版比較高,可能是因為五珠鍊接受度不如三板帶。

未來趨勢:
GMT Master II百事圈與藍黑圈等雙色陶瓷圈,在銷售上一直有相乘效應,在今年新版藍黑圈的宣傳推動下,估計已停產的舊版藍黑圈,還會在二手市場熱個幾年。

參考:
2012至2019年的搜尋概況 – Rolex GMT MasterII 鋼版 雙色陶瓷圈 相關型號