A. 交談禮儀中適宜交談的話題有那幾類不適宜交談的有哪幾類
一、適宜交談的話題：
1、氣候關於氣候、四季的話題。
天氣變熱了／涼快了等等。隨著對天氣的談論，逐漸引出一些更加自然而無傷大雅的話題。這種方法十分簡單方便。
2、愛好關於興趣、愛好的話題。
如果對方是男性，則可以談論下專業棒球等體育運動，如果對方是女性，則可以談論下美容或健康等的話題。但由於第一次見面時大多數人都還不了解彼此的興趣愛好，因此這個話題在實際上比較難運用。
3、新聞關於新聞、時事的話題。
最好選擇比較積極的話題。
4、旅遊關於旅行的話題。
可以告訴對方自己最近游歷某地的見聞，或詢問對方是否去過某地。也可以向對方推薦某個地方，或者詢問對方對某地的看法。由此就可以引出對彼此家鄉等等的談論，使話題的涉及面更廣。
二、不適宜交談的有：
1、與錢有關的事。
金錢問題純屬個人私事，最好不要談及。例如：「你一個月掙多少錢？」「你買了多少套房子？」「你現在有多少資產？」「你買了多少股票？」諸如此類的問題，如果你向客戶問及，會造成尷尬，人家沒法回答你。
2、自己的健康狀況。
如果你健康極佳，面對別人「你好嗎？」這樣的問題，應該臉帶微笑且親切地回答：「很不錯！你呢？」如果染有重病，也只需回答「還不錯，那你呢？」即可，沒有必要把你的詳細的病情告訴別人，因為大多數情況下，別人只是客套的問候，而並不是真正要聽你的病情報告。
3、哀傷性的話題。
這類話題如死亡、飢荒和虐待等等，很容易引起人們不愉快的情緒。如果有人提及，也要想辦法盡快岔開話題，畢竟，商務交流並不適宜探討深沉的哲學問題。
4、謠言與閑話。
謠言與閑話聽聽即可，對於那些自己並沒有確切證據的傳言，自己不要參與其中，並妄加評論，這樣做對你沒有任何好處，反倒可能讓別人對你減少信任。
(1)什麼類型的問題可以難倒對話系統擴展閱讀
基本禮儀之交談禮儀：
1、交談時，應力戒口頭禪，注意談吐文明，措詞雅潔；
2、不打斷對方談話，不輕易在他人談話時插嘴；
3、交談時，勿打哈欠，勿抓耳挖腮，搔首擺膝搖頭；
4、對別人講話，勿持冷漠的態度，如斜視、看書、看報等；
5、說話時，要面對談話的人，不要自我吹噓或信口開河；
6、對於生客，不要貿然問人家工資多少，對於女青年，不要隨便問她的年齡和地址；
7、抽煙時，不要朝著別人的臉擦火柴，吐煙霧。
B. 語音對話系統的設計要點與多輪對話的重要性
就從最近短視頻平台的大媽與機器人快寶的聊天說起吧。
某銀行內，一位阿姨因等待辦理業務的時間太長，與快寶機器人展開了一場來自靈魂的對話。對於銀行工作人員的不滿，大媽向快寶說道：「你們的工作人員在裡面哄孩子，怎麼不出來辦業務？」；快寶答：「我們櫃台里的哥哥姐姐也在很努力的辦業務呢。」聽到這個回答，阿姨試圖將快寶的身體轉向櫃台方向，說：「你往裡瞅瞅，是不是在哄孩子？」快寶嚶嚶嚶的好委屈：「你不要觸碰我了，跟我說話就可以了」.
「快寶」說話的語速和聲音非常清晰，邏輯性連貫，跟普通人說話的方式簡直一模一樣，比蘋果的 SIRI強太多，有網友甚至懷疑快寶「背後」是專門的人通過攝像頭在和人對話。
隨著人工智慧相關技術的更新迭代，如今，ASR與TTS技術相對來將已經成熟，自然語言的表示和理解已經取得了很大的進展，在行業的競爭壁壘中也逐步削弱，未來智能對話機器人的核心競爭力在於理解了用戶的意圖之後所提供的差異化服務。下面我就在產品角度聊聊語音對話機器人的喜相關知識點，希望帶給各位一些思考。
智能語音對話系統大致可分為五個基本模塊：語音識別(ASR)、自然語音理解(NLU)、對話管理(DM)、自然語言生成(NLG)、語音合成(TTS).
語音識別將語音轉化文字，讓機器讀取用戶再說什麼，自然語言理解是理解用戶說的話是什麼意思，分析用戶說話的意圖，和對用戶語言中核心詞槽的解析。而對話管理(Dialog Management,DM)就是人機對話中的CPU，控制著整個人機對話的過程。對話管理的任務主要有下四點，對話狀態維護(dialog state tracing,DST)、生成系統決策(dialog policy)、作為介面與後端/任務模型進行交互、提供語義表達的期望值(expections for interpretation)。由對話管理分析出用戶的意圖之後並做出相關行為，自然語言生成對用戶任務的處理結果以文字形式生成，然後語音合成將此結果合成為語音說出來。就形成了人機對話的整個過程。
個人將常見的人機對話分為日常撩撥型和任務驅動型。
最常見的就是任務驅動的多輪對話，用戶是帶著明確的目的如訂餐、訂票、叫車等比較復雜的需求來，而這中間有很多限制條件，用戶並不能一次將任務所需的關鍵信息一次性說完、說清楚，因此就要分多輪進行QA問答。一方面，用戶在對話過程中，可以不斷修正和完善自己的需求；另一方方面，當用戶在陳述需求不夠具體和明確時，機器人可以通過詢問、澄清和確認來幫助用戶尋找滿意的結果，並且在任務的驅動下與用戶完成日常的交互，以此不斷完善對於用戶需求的滿足。
而日常撩撥型對話中的關鍵，是要根據用戶喚醒機器人時和喚醒之後第一句話的日期時間和語氣來判斷用戶當前的情緒，比如：周五晚上9點下班回家，而喚醒時語氣中帶著些許匹配疲憊與不開心，此時就需要機器人的安慰和鼓勵，以此滿足用戶的情感需求。當用戶心情愉悅時，對話中還可以偶爾「皮一下」，對話中一定要有讓用戶驚艷的句子和當下比較流行的詞語，有趣和好玩是日常撩撥對話中的剛需，而這需要訓練師不斷更新語料庫，以此來持續性對智能語音設備的依戀。
對話管理對於多輪對話又異常重要，因為單詞對話每次聊天都需要用戶去喚醒語音對話機器人，用戶必須每次將需求完成的說出，否則幾次對話下來用戶將會產生煩躁的情緒，語音對話機器人將會變得雞肋。下面我們來分解下對話管理的大致任務：
1、對話狀態維護(DST)
2、生成系統決策(dialog policy)
根據DST中的對話狀態，產生系統行為，決定下一步做什麼可以監測到用戶的輸入，就是NLU的過程，以及系統對於NLU的反饋行為，就是NLG。
3、作為介面與後端/任務模型進行交互。
作為應用程序介面與伺服器端或任務模型進行請求交互，獲取反饋結果，生成文字結果。
4、提供語義表達的期望值
根據用戶輸入的表達，包括語言表達和語義解析，做出滿足用戶期望的語義表達，滿足用戶需求。
多輪對話中為了清晰明確的理解用戶的意圖和需求，將對話建模過程中缺少的信息形成一個填槽的過程，槽就是多輪對話當中將初步用戶意圖轉化為明確用戶指令所需要補全的信息。一個槽與任務處理中所需要獲取的一種信息相對應。槽沒有順序，缺什麼槽就向用戶詢問什麼信息。
基於框架式的對話管理(Frame-based DM)需要如下要點：
1、框架：槽位的集合，定義了需要由用戶提供哪些信息；
2、對話狀態：記錄了哪些槽位已經被填充，那些槽位待填充；
3、行為選擇：下一步該向用戶詢問哪些信息，填充哪些槽位，進行何種操作，對哪些槽位進行加權填充。
基於框架的系統本質上是一個生成系統，不同類型的輸入觸發不同的生成規則，每個生成靈活的填入相應的模板，這些模型的和框架的設計只為在滿足用戶需求的前提下，盡快的完成必要信息的獲取。
設計語音對話系統需要注意的5個要點：
行為模式的設計、交互過程的設計、知識結構的設計、人格情緒的設計、熟悉過程的設計，我們又可以將這5中設計要點進行情景細分：
在整體架構設計當中，加入這些細分情景的收集，透過用戶與機器對話的行為細分模式，包括知識結構和人格情緒的收集，來出一個虛擬人格。此模式就相當於某寶或某東商城根據用戶的點擊、搜索和瀏覽行為結合大數據生成的千人千面，通過語音交互的使用過程，了解用戶習慣進而達到更好的體驗。
語音對話體驗可分為三個方向：聲音形象、對話交互模式和對話內容，它們分別對應GUI時代的品牌設計、交互設計、服務設計，產品經理需要把握好機器人與人的平衡點，不要過度人性化，以免某些點不能滿足用戶的過渡預期，而產生的失望。
人類的大腦依賴所學的知識進行思考、邏輯推理和語言理解。而機器人則是依賴數據的訓練，互聯網時代積累的大量的數據能為訓練機器人提供的強有力的保障，對話機器人以數據為基礎，利用深度學習模型和演算法，對人類世界進行感知、識別和判斷，並通過知識圖譜對人類的知識進行梳理、整合、推理，變成有智慧的AI。
人的復雜性(complex)、隨機性(random)、和非理性化(illogica)的特點導致人機對話在應用場景下面臨者各種各樣的問題，包括但不限於如下問題：
1、模型描述能力與業務復雜度的權衡；
2、用戶對話偏離業務涉及的路徑及邊界；
(如：系統問用戶導航的目的地時，用戶反問了一句某地天氣情況)
3、多輪對話的容錯性；
(如：3輪對話的場景，用戶已經完成2輪，第3輪由於ASR或NLU錯誤，導致前功盡棄，如此用戶體驗就非常差。)
4、多場景的的切換和回復；
5、降低交互變更難度，適應業務迅速變化；
6、跨場景信息繼承。
未來對話機器人除了被動回復用戶的請求外，主動預測用戶需求並提供即時方案成為必然的發展方向，當用戶沒有給出明確的需求情況下，提醒即將發生的事件或推薦有用的服務，人們會逐漸依靠他們來管理自己的工作生活，提高生活效率及幸福感。
對話機器人的目標不一定是解決用戶面臨的所有問題，而是成為用戶的虛擬助理。通過與用戶建立情感鏈接，理解用戶，長期范圍內幫助他們，與用戶建立多種形式的交流，包括文本、語音和圖像以及視頻功能。
C. 任務型對話系統中狀態追蹤（DST）
前面寫了對話系統中的SLU之領域 分類/意圖識別 、 槽填充 、 上下文LU和結構化LU 以及 NLG ，DST是對話管理（DM）的一部分，而DM是任務型對話中至關重要的一部分。說個 非嚴格的對比 ：如果把對話系統比作計算機的話，SLU相當於輸入，NLG相當於輸出設備，而DM相當於CPU（運算器+控制器）。
對話系統按功能來劃分的話，分為閑聊型、任務型、知識問答型和推薦型。在不同類型的聊天系統中，DM也不盡相同。
閑聊型對話中的DM就是對上下文進行序列建模、對候選回復進行評分、排序和篩選等，以便於NLG階段生成更好的回復；
任務型對話中的DM就是在NLU(領域分類和意圖識別、槽填充)的基礎上，進行對話狀態的追蹤（DST）以及對話策略的學習（DPL，下次分享），以便於DPL階段策略的學習以及NLG階段澄清需求、引導用戶、詢問、確認、對話結束語等。
知識問答型對話中的DM就是在問句的類型識別與分類的基礎上，進行文本的檢索以及知識庫的匹配，以便於NLG階段生成用戶想要的文本片段或知識庫實體。
推薦型對話系統中的DM就是進行用戶興趣的匹配以及推薦內容評分、排序和篩選等，以便於NLG階段生成更好的給用戶推薦的內容。
什麼是對話狀態？其實狀態St就是一種 包含0時刻到t時刻的對話歷史、用戶目標、意圖和槽值對的數據結構 ，這種數據結構可以給DPL階段提供學習策略(比如定機票時，是詢問出發地還是確定訂單？)繼而完成NLG階段的回復。
對話狀態追蹤（DST）的作用： 根據領域(domain)/意圖(intention) 、曹植對(slot-value pairs)、之前的狀態以及之前系統的Action等來追蹤當前狀態 。他的 輸入是Un（n時刻的意圖和槽值對，也叫用戶Action）、An-1（n-1時刻的系統Action）和Sn-1（n-1時刻的狀態），輸出是Sn（n時刻的狀態） 。 這里用戶Action和系統Action不同，且需要注意
S = {Gn,Un,Hn}，Gn是用戶目標、Un同上、Hn是聊天的歷史，Hn= {U0, A0, U1, A1, ... , U −1, A −1}，S =f(S −1,A −1,U )。
DST涉及到兩方面內容： 狀態表示、狀態追蹤 。另外為了解決領域數據不足的問題，DST還有很多遷移學習(Transfer Learning)方面的工作。比如基於特徵的遷移學習、基於模型的遷移學習等。
為了在抽象的建模的基礎上加深理解，看個小例子：
通過前面的建模和實例化，不難看出對話狀態數跟意圖和槽值對的數成 指數關系 ，維護所有狀態的一個分布非常非常浪費資源，因此需要比較好的狀態表示法來減少狀態維護的資源開銷（相當於特定任務下，更合理的數據結構設計，好的數據結構帶來的直接影響就是演算法開銷變小）。
常見的狀態表示法包括兩種：
Hidden Information State Model (HIS)
這種方法就是：使用 狀態分組 和 狀態分割 減少跟蹤復雜度。其實就是類似於二分查找、剪枝。
Bayesian Update of Dialogue States (BUDS)
這種方法就是：假設不同槽值的轉移概率是相互獨立的，或者具有非常簡單的依賴關系。這樣就將狀態數從意圖和槽值數的 指數 減少到了 線性 。
下面簡單對比下兩種不同狀態表示法的優缺點：
講到DST就不得不講DSTC，DSTC是 Dialog System Technology Challenge ，主要包括6個Challenge。DSTC對DST的作用就相當於目標函數對機器學習任務的作用，真正起到了評估DST技術以及促進DST技術發展的作用。之所以在DST前先說DSTC是因為後面的很多DST的方法是在某個DSTC（大多是DSTC2、DSTC3、DSTC4、DSTC5）上做的。
先來看看DST的形象化
再來看看我總結的DST的方法匯總，注意我沒有整理基於規則的DST（ 基於規則的方法雖然可以較好利用先驗知識從而可以較好解決冷啟動等問題，但是需要太多人工、非常不靈活、擴展性和移植性很差、不能同時追蹤多種狀態 ）。
下面分別介紹一下對話系統中的不同DST技術。
論文： （ Lee, SIGDIAL 2013 ）（ Kim et al., 2014 ）
從BUDS中對不同槽值的轉移概率是相互獨立的假設（是不是很像馬爾可夫假設？）以及St的預測需要Un、An-1和Sn-1（轉移概率和發射概率），是不是想到了HMM和CRF？沒錯，前期的基於統計的DST就是用了很多CRF。 n = （S −1, A −1, U ）。
Lee, SIGDIAL 2013 的主要思想如下：
Kim et al., 2014 的主要思想如下：
論文： （ Mrkšić et al., ACL 2015 ）（ Henderson et al., 2013 ）（ Henderson et al., 2014 ）（ Zilka el al., 2015 ）
關於神經網路的介紹、神經網路的好處和壞處，不再贅述，已經爛大街。基於神經網路的很多方法是在DSTC上做的，這里選取了幾篇有針對性的經典論文簡單介紹下。
Mrkšić et al., ACL 2015 是ACL2015的一篇論文，它是用RNN進行多領域的對話狀態追蹤，主要貢獻是證明：利用多個領域的數據來訓練一個通用的狀態追蹤模型比利用單領域數據訓練追蹤模型效果要好。
Henderson et al., 2013 是利用DNN來解決DSTC，它把DST當分類問題，輸入時間窗口內對話輪次提取的特徵，輸出slot值的概率分布。該方法不太容易過擬合，領域遷移性很好。模型結構圖如下：
Henderson et al., 2014 ，基於DRNN和無監督的自適應的對話狀態魯棒性跟蹤，從論文名字就能看出因為使用DRNN和無監督的自適應導致DST 魯棒性很好 。
先來看看特徵提取的辦法：主要提取f，fs，fv三種特徵，f是針對原始輸入提取，fs和fv是對原始輸入中的詞做Tag替換得到 泛化特徵 。
再來看下模型結構：對slot訓練一個模型，利用無監督的自適應學習，將模型泛化到新的domain以便於提高模型的泛化能力。
Zilka el al., 2015 ，基於增量LSTM在DSTC2做對話狀態追蹤，具體思想如下：
（ Williams 2013 ）（ Mrkšic, ACL 2015 ）
目前對話系統數據較少，我比較看好遷移學習在任務型對話中的應用，尤其是DST這種較復雜的任務。
Williams 2013 ，這是通過 多領域學習與泛化 來做對話狀態追蹤，比較好的解決了數據目標領域數據不足的問題。
Mrkšic, ACL 2015 ，這是ACL 2015的一篇paper，基於RNN做多領域的對話狀態追蹤，主要貢獻是證明：利用多個領域的數據來訓練一個通用的狀態追蹤模型比利用單領域數據訓練追蹤模型效果要好。順便說一句，這篇論文涵蓋了很多任務型對話領域比較高產的學者。
Shietal., 2016 ，基於 多通道卷積神經網路 做 跨語言 的對話狀態跟蹤。為每一個slot訓練一個多通道CNN（中文character CNN、中文word CNN、英文word CNN），然後跨語言做對話狀態追蹤，我個人很喜歡這篇paper，也非常推薦大家好好讀讀這篇paper。
先來看看方法的整體結構：
再來看看多通道CNN的結構圖：
最後看看輸入之前的預處理：
（ Mrkšić et al., ACL 2017 ）
這是發表於ACL 2017的一篇論文，個人覺得水平很高。
先來看一下基於word2vec的表示學習模型，本文提出兩種架構：NBT-DNN、NBT+CNN，結構圖如下：
再來看看整個模型的結構圖，它包含語義解碼和上下文建模兩部分：語義解碼：判斷槽值對是否出現在當前query；上下文建模：解析上一輪系統Act，系統詢問（tq）+ 系統確認（ts+tv）。
模型還有一部分：二元決策器，用來判定當前輪的槽值對的狀態。本文的狀態更新機制採用簡單的基於規則的狀態更新機制。
另外，ACL 2018在本文的基礎上提出完全NBT（ Fully NBT） ，主要變動是修改基於規則的狀態更新機制，把更新機制融合到模型來做 聯合訓練 。具體更新狀態的機制包括One-Step Markovian Update（ 一步馬爾科夫更新，使用兩個矩陣學習當前狀態和前一時刻狀態間的更新關系和系數）和Constrained Markovian Update（約束馬爾科夫更新，利用對角線和非對角線來構建前一種方法中的矩陣，對角線學習當前狀態和前一時刻狀態間的關系，非對角線學習不同value間如何相互影響）。總之，這個工作擴展的比較細致。
其實還有很多種對話狀態追蹤的方法，比如基於貝葉斯網路做DST、基於POMDP（部分可觀測馬爾可夫決策過程）做DST等，因為時間相對比較久遠，這里不再贅述。
以上介紹了多種對話系統中的DST技術，下面簡單總結下它們的優勢和劣勢。
任何一項技術想要取得進步，那麼他的評測方法是至關重要的（就相當於目標函數之於機器學習演算法），所以我列出一些關於DST的評估。遺憾的是，目前DST的評估我感覺並不成熟，這也是制約DST發展的一個重要原因，如果誰能想出更好的評估方法或整理出一個業內公認的高質量數據集，那麼一定會在DST（甚至是對話系統）領域有一席之地，引用量也會蹭蹭的上漲。
6.1.Dialog State Tracking Challenge (DSTC)
Williams et al. 2013, Henderson et al. 2014, Henderson et al. 2014, Kim et al. 2016, Kim et al. 2016, Hori et al. 2017
6.2. State Representation:
6.2.1 HIS
Steve Young, Jost Schatzmann, Karl Weilhammer, and Hui Ye. The hidden information state approach to dialog management.
6.2.2 BUDS
Blaise Thomson, Jost Schatzmann, and Steve Young. Bayesian update of dialogue state for robust dialogue systems.
6.3.DST
6.3.1 CRF
Sungjin Lee. Structured discriminative model for dialog state tracking. In Proceedings of the SIGDIAL 2013 Conference. Lee, SIGDIAL 2013
Seokhwan Kim and Rafael E Banchs. Sequential labeling for tracking dynamic dialog states. Kim et al., 2014
6.3.2 NN-Based DST
Multi-domain Dialog State Tracking using Recurrent Neural Network, Mrkšić et al., ACL 2015
Deep Neural Network Approach for the Dialog State Tracking Challenge, Henderson et al., 2013
Robust dialog state tracking using delexicalised recurrent neural networks and unsupervised adaptation, Henderson et al., 2014
Incremental lstm-based dialog state tracker, Zilka el al., 2015 .
6.3.3 Neural Belief Tracker
Neural Belief Tracker: Data-Driven Dialogue State Tracking , Mrkšić et al., ACL 2017
6.3.4 Multichannel Tracker
A Multichannel Convolutional Neural Network For Cross-language Dialog State Tracking, Shi et al., 2016
6.3.5 Transfer learning for DST
6.3.5.1 Feature based transfer for DST
Jason Williams. Multi-domain learning and generalization in dialog state tracking . In Proceedings of SIGDIAL. Williams 2013
Hang Ren, Weiqun Xu, and Yonghong Yan. Markovian discriminative modeling for cross-domain dialog state tracking .
6.3.5.2 Model based transfer for DST
Nikola Mrkšic, Diarmuid O Séaghdha, Blaise Thomson,Milica Gaši ́c, Pei-Hao Su, David Vandyke, Tsung-Hsien Wen, and Steve Young. Multi- domain dialog state tracking using recurrent neural networks . Mrkšic, ACL 2015
D. 2020年護士資格考試人機對話系統答題技巧有哪些
護士資格考試人機對話的一大特點就是題型之間操作不可逆。具體來說就是進入考試之後默認從A1題型的第一道題開始作答，答完A1題型的所有題目並確認不會更改之後才可以點擊A2題型的試題開始作答。如果A1題型中有題目未作答或者是想改變答案，必須要在進入A2題型之前修改完畢。只要點擊進入A2題型，就不能對A1題型中的作答進行任何修改!
2020年護士資格考試人機對話答題方法：
1、答題原則：單項選擇中，最符合題意的選項指的是最正確最全面的選項，例如，若A、B兩項都是正確的，但是B項的內容覆蓋了A項的內容，則B項是最符合題意的最正確答案。
2、答題技巧：考試中合理運用排除法，首先去掉與題目無關或明顯錯誤的選項，然後在剩下的選項中分析作答。考題選項中有時存在兩個矛盾選項，尤其在多選中，矛盾選項至少有一個是錯誤的。另外合理的猜測也是答題的技巧，因為答總比不答強，所以每個考題都應該作答，一定不要漏答或不答。還要會用單選的唯一性。如果四個選項中有三個與另一個屬性不一樣，那這一個就很可能是答案。
3、掌握速度：每科的考試時間均在一百分鍾左右，應根據題量來安排答題速度。人機對話考試答題不可逆，所以在進入另一個題型前，一定要保證自己所有的題都已經做了。
4、減免差錯：一是每題都要注意審題，弄清題意；二是認真，讀清楚問題再作答。例如：下列選項不正確的是，一定要讀清楚問題；三是要注意在核對自己的姓名、考號等項，並且在交卷時再核對一次；四是在答題完畢後瀏覽全卷，檢查是否有漏題未答。
2020年護士資格考試人機對話答題過程
1、登陸輸入自己的准考證號，點擊登錄，進入考試系統。
2、確認信息登陸之後確認一下自己的考試信息是否正確，以及了解考試屏幕顯示內容。
(1)摘要顯示部分：摘要顯示位於屏幕上部，一般用於顯示所考案例描述性文字，如同臨床醫學題型為「病例摘要」，摘要在本案例的提問沒有結束之前始終存在，以使隨時為考生提供信息。當下一案例題出現時其自動消失。
(2)提示、提問及答題操作部分：該部分位於屏幕中部。提示，主要結合所提的問題，提供一些參考資料，一般反映病情變化或輔助檢查的結果。提問，即需考生回答的問題，通常有6～12個備選答案，考生根據所提供的備選答案直接作答。
(3)圖片顯示：圖片可以是醫學影像、心電圖、腦電圖、病理切片及實物圖片等。作為答題的參考資料，當屏幕右下方提示可調用圖片時，用滑鼠點擊或按相關鍵即換屏顯示圖片。
(4)計算器的調用：考試過程中，有些試題可能需要進行簡單的四則運算，如：單位轉換、劑量計算等。這時可以用滑鼠點擊或按相關鍵在屏幕上調用「計算器」，其使用方法與普通計算器一樣。
(5)操作提示：操作提示部分位於屏幕下部，提示考試剩餘時間、題量、當前答題進度，採用兩條移動線條的形式，一條表示答題進度(答題進度條)，另一條表示時間進度(時間進度條)，通過比較兩者長短或完成百分率，形象地反映答題與時間使用的情況，在實際考試中注意兩線的進展速度，若時間進度條的進展速度快於答題進度條時反映考生的答題速度較慢。
3、按照步驟進行答題。
專業實務和實踐能力兩個科目題型均為選擇題，包括A1A2和A3A4型題，總題量為120問，每個科目考試時間均為100分鍾，每個科目之間間隔為45分鍾，考生在半天參加完這兩個科目的考試。考試內容見當年考試大綱。
人機對話考試與紙筆考試中不同知識模塊、不同系統疾病的比例一致，題型比例一致。
4、交卷答題完畢之後點擊交卷。
備考護士執業資格考試的考生一般都是實習護士，加上疫情的原因，平時備考的時間不多，再加上考試將以前在校分開教學的內科、外科、婦科和兒科等學科混雜在一起考，也增加了考生的取證難度。從以往的考題來看，護士資格考試越來越注重的是考察護士的能力、臨床應用，因此，不能割裂學科，也不能還採取學校裡面的教學方法，要研究歷年考試的規律，抓住重點和難點。
E. Sounds good. 是回答對話中的哪類問題的
是的 建議類
這個沒有什麼特別的 意思就是 聽起來不錯 根據意思做題就可以了。
F. 手機有什麼軟體是能和智能系統對話的，就是你問他問題，他能回答，能跟你聊天的那種
你是說那隻小黃雞嗎，好像是叫SimSimi，這個是可以問他問題然後回答的，還是很可愛的。還有的就是那種虛擬男友女友這類的也可以，這種的可以在應用寶上搜索到，輸入關鍵詞然後進行查找的話就會有這類的軟體可以下載的了，還是有很多可以選擇的。
G. 連載 | 2.3 對話系統話術設計注意事項
歡迎大家來學習我們第二章的第三節， 對話系統話術設計的注意事項 。
首先是簡潔明了，我們來對比這兩個話術。
這是一個對話系統裡面常見的話術，完全照搬了之前GUI的的做法，每個模塊都羅列上去，而正常人交流會說：你是要重復回答，還是要去到下一個。
藉此，給大家介紹一個法則： 格里斯法則 。
格里斯是一個非常有名的語言哲學家，他有四個法則：
給大家舉一些反例：
第二個需要注意的事項是 對話的語句要自然 ，經常會看到很多的機器人，用刻板的對話腳本教導用戶，希望用戶按照他們希望的台詞去說話。
處理的辦法很簡單，大家注意以下這三點：
第三點要處理的是新手用戶和老手用戶。
這是一個醫療保健的助理，你第一次使用的時候，機器人會說：「讓我們來測量血壓，請確保血壓計的袖帶已經打開。將袖帶卷到你的手臂上，並使用藍色箭頭指向你的手掌。請保持坐姿雙腳平方在地上，當你准備就緒時按下按鈕」。
對於一個新用戶，機器人用非常詳細的去跟他交流是沒有問題的。但當一個用戶使用一周之後，機器人依然說這么多廢話，用戶會逐漸變得不耐煩。所以這個時候，你只要跟他說：「到測量血壓的時間了，請帶上袖帶並按下「繼續」按鈕」，就可以了。
很多時候，也不能只依靠次數來確認模式，因為一個人可能使用了多次，但一兩個月只使用一次。在這種情況下，應該繼續保持新手提示。要注意你的目標不是簡單的訓練你的用戶，而是適應用戶的行為，不是用已有命令讓用戶感到厭煩。
我們再來看第四個要注意的事項， 適當的使用問候語和結束語 。
首先，你要告訴你的用戶是誰，用戶要知道他在和機器人說話，還是在和真人說話，讓用戶有一個明確的預知，當你進行轉換的時候你也要告訴他：「我剛剛是機器人，現在我轉到了人工。我是人工的小芮，在這兒為你回答問題。」
第二，對話包含的信息要合適，新接觸的用戶和老用戶需要的內容是不一樣的。這是在設計對話的時候是要考慮的。
第三，是要採用合適的方式來結束對話，當用戶完成目標的時候，比如用戶說：「好的，謝謝」「不需要了，謝謝」，你是否知道它是完成？你是否知道它代表著什麼？然後你能不能夠去快速退出。還是說你會不停的在問：「還有什麼需要幫助您的嗎？」，或者是說：「你還是需要訂機票嗎？」，這樣的話也會顯得你的機器人非常的弱智。
第五個可能會講的稍微多一點，關於確認這一塊，當用戶提出一些請求，機器人必須要給用戶以回應，就像人和人的交流一樣，你需要給對方以回應。你說：「我知道你在說什麼了」，這樣對方才會繼續有跟你溝通下去的慾望， 確認上我們做了三個區分 ：
那這三個有什麼區別，接下來會給大家詳細的去講解。
同時注意兩件事 ：
我們來看一下這三個確認，什麼情況下我們要用到顯性確認。
有三種情況：
隱性確認，根據名字我們就可以看的出來，它是在暗示你，不是在明確的說請您確認。
給大家舉兩個例子，我們看第一個例子：
其實這個就是隱性確認，它也是在偷偷的跟你確認，你是不是在問我北京的天氣。如果你說不是，上海的天氣怎麼樣？那機器人也會說：「上海的天氣小雨加雪」或者類似怎麼樣。所以這個時候你要讓用戶知道，我已經識別到你的信息。
再比如說第二個再給大家舉個例子 ：
如果機器人沒有識別的很好的時候，那它就可以說：「世界上最高山峰珠穆朗瑪峰」，說明我知道你的意思是什麼，在問我世界上最高的山峰，我識別到了，那世界上最高的山峰珠穆朗瑪峰，這種回答遠比回答說：「珠穆朗瑪峰」，要更舒服，貼切和智能。
一般隱性確認的場景，則是在對獲取信息的識別度，識別准確度較高的時候，為了減少出錯進行確認的。
以上是給大家舉的例子，是置信度綜合的顯性確認和隱性確認，這個是看情況而定的。
簡單說是看情況而定，比如這是一個智能音響的例子，你跟機器人說再買一些紙巾，那麼機器人根據對你話術的識別有一個置信度。技術裡面叫confidedce，也可以理解為概率。
當它覺得你80% 的概率會再買一些紙巾，它會直接說：「好的，已經為您訂購了更多紙巾」。
如果因為聲音較遠或者背景嘈雜，他覺得你只有45%-79% 的概率是說在買紙巾的時候，它就會去問你：「你是想再訂購一些紙巾嗎？」。
如果雜音更多或者它聽到了其它的東西，低於45%的概率覺得你在買紙巾，它可以直接問：「對不起，我沒有聽清你說的話，你想要買什麼？」。
當然，80，45也都是一個在現實的場景中迭代總結的數據，任何一個系統不會有一個統一的標准數據的。
最後再給大家做一個對比，那麼左邊是我沒有放任何的確認話術：
這個時候用戶的感知是非常硬冷的，總覺得機器人的信息不一定是准確信息。這是缺少隱性確認的話術進行引導的原因，會讓用戶會覺得很困擾。
以下是修改後的案例：
這個時候你有沒有覺得更踏實一點了呢。
隨機策略是很簡單的，因為機器人是我們去設計的，我們希望機器人更加的貼近人，所以回答的時候，盡量加一些隨機的策略，避免應答的單調或套路化。
比如說好的，沒問題，收到，OK都可以這么說。只要用戶覺得機器人好像還滿聰明的，不會很刻板。
第七個是使用對話式標識。什麼叫對話式標識？
對話式標識是讓用戶了解交談進展，以及進展情況的重要方式。當系統在對話中使用了一些基本的對話禮儀以後，用戶的參與度會更高，並且會以同樣的方式進行回復，就像膠水一樣將各個部分連接在一起。
比如說時間線：
比如說我有三個問題想問你：
類似這樣的一個調研問卷，遠比你直接拋給他三個問題要好。
第二個是接受回應時段
這個之前就有例子給大家介紹了。
積極反饋：
類似這樣比較適合做醫療助理，那麼比如說用戶已經按你的要求測量了血壓等，這個時候你可以給用戶一個積極的反饋，用戶會更願意按照你接下來的操作去往下進行。
這是一個醫療的例子，左邊：
感覺非常生硬，冷冰冰的。
但我們看另外一種話術設計：
用戶就知道自己走到哪一步了，他知道我跟你說吃完了，基本上我可以跟你結束對話了，所以它最後也說：「暫時就這些了，我以後再問你，再見」。
希望大家通過這種對話式標識，讓你的機器人看起來更舒服。
再有一個是加入異常處理，比如說可以主動詢問：
第二類是增強錯誤提示信息，比如機器人說：
用戶隨便說一個數字，機器人說：
機器人很快就反應過來了。
然後這樣的話，會通過這種對話去告訴它，你應該去引導他給出一個正確答案。
最後實在沒有辦法了，我們可以把他轉交給人工。
還有一塊是設計對話通用的模塊，比如說主菜單。這一塊是想跟大家說CUI和GUI是有一些共同的地方的。
GUI里邊有的主菜單、幫助健或退出鍵，我們CUI中或者對話的這種交互中一定要有的，只不過它可能代表的是一種意圖。你要去設計這種意圖，用戶說什麼樣的話會觸發。
那麼很多人會只顧著設計自己的故事線，設計自己的愉悅路徑，就把這些最基本的GUI裡面要注意的點忘記了。
再給大家最後再講幾個設計延遲的話術。
其實很多時候，查詢的過程是需要一些時間的，或者說我們去買一張機票，可能需要等代理商確認以後才能出票，你都要明確告知你的用戶：「請稍等，我在查詢相關記錄」或「請稍等，我正在訂票」，讓用戶知道我需要等待多久，遠比你等三分鍾之後再跟他說：「您好，給您做好了」。用戶為著三分鍾等著就很焦躁，你不如先告訴他，再讓他等三分鍾。
還有一個就是設計歧義的消除話術，也是一個例子吧：
這也是通過一些隱性確認的方式，去做了歧義的消除。
最後再給大家舉一個例子，也是希望大家能夠有這個意識，人的表達會存在各種各樣的情況，不管用戶說什麼，不要把它當場一個錯誤來處理，而是去尋找如何把它變成一個主動學習的機會。
那麼舉一個例子就是：
其實機器人根本就不知道梅球王是誰，那你不要把它當成一個錯誤，你可以問他
把每一種對話的交互都轉變成一種提供價值的互動機會，機器像人一樣在交流中學習。
這就是我們在對話系統設計話術中的一些例子和注意事項，希望大家能夠有所收獲，我們下期再見。
H. 試列舉常見的網路系統故障類型,並說明解決辦法
1.故障現象：網路適配器（網卡）設置與計算機資源有沖突。
分析、排除：通過調整網卡資源中的IRQ和I/O值來避開與計算機其它資源的沖突。有些情況還需要通過設置主板的跳線來調整與其它資源的沖突。
2.故障現象：網吧區域網中其他客戶機在「網上鄰居」上都能互相看見，而只有某一台計算機誰看不見它，它也看不見別的計算機。(前提：該網吧的區域網是通過HUB或交換機連接成星型網路結構）
分析、排除：檢查這台計算機系統工作是否正常；檢查這台計算機的網路配置；檢查這台計算機的網卡是否正常工作；檢查這台計算機上的網卡設置與其他資源是否有沖突；檢查網線是否斷開；檢查網線接頭接觸是否正常。
3.故障現象：網吧區域網中有兩個網段，其中一個網網段的所有計算機都不能上網際網路。（前提：該網吧的區域網通過兩個HUB或交換機連接著兩個的網段）
分析、排除：兩個網段的干線斷了或干線兩端的接頭接處不良。檢查伺服器中對該網段的設置項。
4.故障現象：網吧區域網中所有的計算機在「網上鄰居」上都能互相看見。（前提：該網吧的區域網是通過HUB或交換機連接成星型網路結構）
分析、排除：檢查HUB或交換機工作是否正常。
5.故障現象：網吧區域網中某台客戶機在「網上鄰居」上都能看到伺服器，但就是不能上網際網路。（前提：伺服器指代理網吧區域網其他客機上網際網路的那台計算機，以下同）
分析、排除：檢查這台客戶機TCP/IP協議的設置，檢查這台客戶機中IE瀏覽器的設置，檢查伺服器中有關對這台客戶機的設置項。
6.故障現象：網吧整個區域網上的所有的計算機都不能上網際網路。
分析、排除：伺服器系統工作是否正常；伺服器是否掉線了；數據機工作是否正常；局端工作是否正常。
7.故障現象：網吧區域網中除了伺服器能上網其他客戶機都不能上網。
分析、排除：檢查HUB或交換機工作是否正常；檢查伺服器與HUB或交換機連接的網路部分（含：網卡、網線、接頭、網路配置）工作是否正常；檢查伺服器上代理上網的軟體是否正常啟動運行；設置是否正常。
8.故障現象：進行撥號上網操作時，MODEN沒有撥號聲音，始終連接不上網際網路，MODEN上指示燈也不閃。
分析、排除：電話線路是否占線；接MODEN的伺服器的連接（含：連線、接頭）是否正常；電話線路是否正常，有無雜音干擾；撥號網路配置是否正確；MODEN的配置設置是否正確，檢查撥號音的音頻或脈沖方式是否正常。
9.故障現象：系統檢測不到MODEN（若MODEN是正常的）。
分析、排除：重新安裝一遍MODEN，注意通訊埠的正確位置。
10.故障現象：連接網際網路速度過慢。
分析、排除：檢查伺服器系統設置在「撥號網路」中的埠連接速度是否是設置的最大值；線路是否正常；可通過優化MODEN的設置來提高連接的速度；通過修改注冊表也可以提高上網速度；同時上網的客戶機是否很多；若是很多，而使連接速度過慢是正常現象。
11.故障現象：計算機屏幕上出現「錯誤 678」 或「錯誤 650」 的提示框。
分析、排除：一般是你所撥叫的伺服器線路較忙、占線，暫時無法接通，你可進一會後繼續重撥。
12.故障現象：計算機屏幕上出現「錯誤680：沒有撥號音。請檢測數據機是否正確連到電話線。」或者「There is no dialtone。 Make sure your Modem is connected to the phone line properly。」的提示框。
分析、排除：檢測數據機工作是否正常，是否開啟；檢查電話線路是否正常，是否正確接入數據機，接頭有無松動。
13.故障現象：計算機屏幕上出現「The Modem is being used by another Dial-up Networding connection or another program。Disconnect the other connection or close the program,and then try again」的提示框。
分析、排除：檢查是否有另一個程序在使用數據機；檢查數據機與埠是否有沖突。
14.故障現象：計算機屏幕上出現「The computer you are dialing into is not answering。Try again later」的提示框。
分析、排除：電話系統故障或線路忙，過一會兒再撥。
15.故障現象：計算機屏幕上出現「Connection to xx.xx.xx. was terminated. Do you want to reconnect?」的提示框。
分析、排除：電話線路中斷使撥號連接軟體與ISP主機的連接被中斷，過一會重試。
16.故障現象：計算機屏幕上出現「The computer is not receiving a response from the Modem. Check that the Modem is plugged in,and if necessary,turn the Modem off ,and then turn it back on」的提示框。
分析、排除：檢查數據機的電源是否打開；檢查與數據機連接的線纜是否正確的連接。
17.故障現象：計算機屏幕上出現「Modem is not responding」的提示框。
分析、排除：表示數據機沒有應答；檢查數據機的電源是否打開；檢查與數據機連接的線纜是否正確連接；數據機是損壞。
18.故障現象：計算機屏幕上出現「NO CARRIER」的提示信息。
分析、排除：表示無載波信號。這多為非正常關閉數據機應用程序或電話線路故障；檢查與數據機連接的線纜是否正確的連接；檢查數據機的電源是否打開。
19.故障現象：計算機屏幕上出現「No dialtone」 的提示框。
分析、排除：表示無撥號聲音；檢查電話線與數據機是否正確連接。
20.故障現象：計算機屏幕上出現「Disconnected」的提示時。
分析、排除：表示終止連接；若該提示是在撥號時出現，檢查數據機的電源是否打開；若該提示是使用過程中出現，檢查電話是否在被人使用。
21.故障現象：計算機屏幕上出現「ERROR」 的提示框。
分析、排除：是出錯信息；數據機工作是否正常，電源是否打開；正在執行的命令是否正確。
22.故障現象：計算機屏幕上出現「A network error occurred unable to connect to server (TCP Error：No router to host)The server may be down or unreadchable。Try connectin gagain later」的提示時。
分析、排除故障：表示是網路錯誤，可能是TCP協議錯誤；沒有路由到主機，或者是該伺服器關機而導致不能連接，這時只有重試了。
23.故障現象：計算機屏幕上出現「The line id busy, Try again later」或「BUSY」的提示時。
分析、排除：表示占線，這時只在重試了。
24.故障現象：計算機屏幕上出現：「The option timed out」的提示時。
分析、排除：表示連接超時，多為通訊網路故障，或被叫方忙，或輸入網址錯誤。向局端查詢通訊網路工作情況是否正常。檢查輸入網址是否正確。
25.故障現象：計算機屏幕上出現「Another program is dialing the selected connection」的提示時。
分析、排除：表示有另一個應用程序已經在使用撥號網路連接了。只有停止該連接後才能繼續我們的撥號連接。
26.故障現象：在用IE瀏覽器瀏覽中文站點時出現亂碼。
分析、排除故障：IE瀏覽器中西文軟體不兼容造成的漢字會顯示為亂碼，可試用NetScape的瀏覽器看看；我國使用的漢字內碼是GB，而台灣使用的是BIG5，若是這個原因造成的漢字顯示為亂碼，可用RichWin變換內碼試試。
27.故障現象：瀏覽網頁的速度較正常情況慢。
分析、排除：主幹線路較擁擠，造成網速較慢；(屬正常情況)瀏覽某一網頁的人較多，造成網速較慢；(屬正常情況)有關Modem的設置有問題；局端線路有問題。
28.故障現象：能正常上網，但總是時斷時續的。
分析、排除：電話線路問題，線路質量差；數據機的工作不正常，影響上網的穩定性。
29.故障現象：用撥號上網時，聽不見撥號音，無法進行撥號。
分析、排除：檢查數據機工作是否正常，電源打開否，電纜線接好了沒，電話線路是否正常。（大眾網路報）
30.故障現象：在撥號上網的過程中，能聽見撥號音，但沒有撥號的動作，而計算機卻提示「無撥號聲音」。
分析、排除：可通過修改配置，使撥號器不去檢測撥號聲音。可進入「我的連接」的屬性窗口，單擊「配置」標簽，在「連接」一欄中去掉「撥號前等待撥號音」的復選框。
31.故障現象：在撥號上網的過程中，計算機屏幕上出現：「已經與您的計算機斷開，雙擊『連接』重試。」的提示時。
分析、排除：電話線路質量差，雜訊大造成的，可撥打：112報修。也可能是病毒造成的，用殺毒軟體殺一遍毒。
32.故障現象：若計算機屏幕上出現：「撥號網路無法處理在『伺服器類型』設置中指定的兼容網路協議」的提示時。
分析、排除：檢查網路設置是否正確；數據機是否正常；是否感染上了宏病毒，用最新的殺毒軟體殺一遍毒。
33.故障現象：Windows 98網上鄰居中找不到域及伺服器，但可找到其他的工作站。
分析、排除：在「控制面板→網路→Microsoft網路客戶」中，將登錄時Windows 98與網路的連接由慢速改為快速連接。
34．故障現象：在查看"網上鄰居"時，會出現「無法瀏覽網路。網路不可訪問。想得到更多信息，請查看『幫助索引『中的『網路疑難解答』專題。」的錯誤提示。
分析、排除：第一種情況是因為在Windows啟動後，要求輸入Microsoft網路用戶登錄口令時，點了"取消"按鈕所造成的，如果是要登錄NT伺服器，必須以合法的用戶登錄，並且輸入正確口令。第二種情況是與其它的硬體產生沖突。打開「控制面板→系統→設備管理」。查看硬體的前面是否有黃色的問號、感嘆號或者紅色的問號。如果有，必須手工更改這些設備的中斷和I/O地址設置。
35．故障現象：在「網上鄰居」或「資源管理器」中只能找到本機的機器名。
分析、排除：網路通信錯誤，一般是網線斷路或者與網卡的接確不良，還有可能是Hub有問題。
36.故障現象：安裝網卡後，計算機啟動的速度慢了很多。
分析、排除：可能在TCP/IP設置中設置了"自動獲取IP地址"，這樣每次啟動計算機時，計算機都會主動搜索當前網路中的DHCP伺服器，所以計算機啟動的速度會大大降低。解決的方法是指定靜態的IP地址。（大眾網路報）
37．故障現象：網路安裝後，在其中一台計算機上的「網路鄰居」中看不到任何計算機?
分析、排除：主要原因可能是網卡的驅動程序工作不正常。請檢查網卡的驅動程序，必要時重新安裝驅動程序。
38．故障現象：從「網路鄰居」中能夠看到別人的機器，但不能讀取別人電腦上的數據？
分析、排除：
（1）首先必須設置好資源共享。選擇"網路→配置→文件及列印共享"，將兩個選項全部打勾並確定，安裝成功後在"配置"中會出現"Microsoft網路上的文件與列印機共享"選項。
（2）檢查所安裝的所有協議中，是否綁定了"Microsoft網路上的文件與列印機共享"。選擇"配置"中的協議如"TCP/IP協議"，點擊"屬性"按鈕，確保綁定中"Microsoft網路上的文件與列印機共享"、"Microsoft網路用戶"前已經打勾了。
39．故障現象：在安裝網卡後通過"控制面板→系統→設備管理器"查看時，報告"可能沒有該設備，也可能此設備未正常運行，或是沒有安裝此設備的所有驅動程序"的錯誤信息。
分析、排除：
（1）沒有安裝正確的驅動程序，或者驅動程序版本不對。
（2）中斷號與I/O地址沒有設置好。有一些網卡通過跳線開關設置；另外一些是通過隨卡帶的軟盤中的Setup程序進行設置。
40．故障現象：已經安裝了網卡和各種網路通訊協議，但網路屬性中的選擇框"文件及列印共享"為灰色，無法選擇。
分析、排除：原因是沒有安裝"Microsoft網路上的文件與列印共享"組件。在"網路"屬性窗口的"配置"標簽里，單擊"添加"按鈕，在"請選擇網路組件"窗口單擊"服務"，單擊"添加"按鈕，在"選擇網路服務"的左邊窗口選擇"Microsoft"，在右邊窗口選擇"Microsoft網路上的文件與列印機共享"，單擊"確定"按鈕，系統可能會要求插入Windows安裝光碟，重新啟動系統即可。
41．故障現象：無法在網路上共享文件和列印機。
分析、排除：
（1）確認是否安裝了文件和列印機共享服務組件。要共享本機上的文件或列印機，必須安裝"Microsoft網路上的文件與列印機共享"服務。
（2）確認是否已經啟用了文件或列印機共享服務。在"網路"屬性框中選擇"配置"選項卡，單擊"文件與列印機共享"按鈕，然後選擇"允許其他用戶訪問的我的文件"和"允許其他計算機使用我的列印機"選項。
（3）確認訪問服務是共享級訪問服務。在"網路"屬性的"訪問控制"裡面應該選擇"共享級訪問"。
42．故障現象：客戶機無法登錄到網路上。
分析、排除：
（1）檢查計算機上是否安裝了網路適配器，該網路適配器工作是否正常。
（2）確保網路通信正常，即網線等連接設備完好。
（3）確認網路適配器的中斷和I/O地址沒有與其他硬體沖突。
（4）網路設置可能有問題。
43．故障現象：無法將台式電腦與筆記本電腦使用直接電纜連接。
分析、排除：筆記本電腦自身可能帶有PCMCIA網卡，在"我的電腦→控制面板→系統→設備管理器"中刪除該"網路適配器"記錄後，重新連接即可。
44.故障現象：在網上鄰居上可以看到其它機器，別人卻看不到自己？
分析、排除：經檢查網路配置，發現是漏裝"Microsoft網路上的文件與列印機共享"所致。解決辦法：開始設置控制面板網路，單擊"添加"，在網路組件中選擇"服務"，單擊"添加"按鈕，型號中選擇"Microsoft網路上的文件與列印機共享"即可。重新啟動後問題解決。
45.故障現象：在網上鄰居上只能看到計算機名，卻沒有任何內容？
分析、排除：出現這種問題時一般都以為是將文件夾沒有共享所致。打開資源管理器，點取要共享的文件夾，卻發現右鍵菜單中的"共享"項都消失了。解決辦法是右擊「網上鄰居」圖標，點取「文件及列印共享」，鉤選「允許其它用戶訪問我的文件」，重啟後，問題解決。
46.故障現象：在Windows 98的「網上鄰居」中找不到域及伺服器，但可找到其他的工作站?
分析、排除：在「控制面板→網路→Microsoft網路客戶」中，將登錄時Windows 98與網路的連接由慢速改為快速連接。
47.故障現象：在查看「網上鄰居」時，會出現「無法瀏覽網路。網路不可訪問。想得到更多信息，請查看'幫助索引'中的'網路疑難解答'專題。」的錯誤提示。
分析、排除：
（1）這是在Windows啟動後，要求輸入Microsoft網路用戶登錄口令時，點了「取消」按鈕所造成的，如果是要登錄Windows NT或者Windows 2000伺服器，必須以合法的用戶登錄，並且輸入正確口令。
（2）與其它的硬體起沖突。打開「控制面板→系統→設備管理」。查看硬體的前面是否有黃色的問號、感嘆號或者紅色的問號。如果有，必須手工更改這些設備的中斷和I/O地址設置。
48.故障現象：用Windows 2000專業版做伺服器，然後用Windows 98做客戶機，網上鄰居正常，Windows 98與Windows 98之間突然變得很慢，但從Windows 2000訪問Windows 98卻很快。
分析、排除：大家在通過網路系統瀏覽共享文件時，大概都會要等上30秒鍾。這其實是因為Windows 2000多個BUG，一定要先在「計劃任務」里搜索，再找出共享文件。而我們提到的這個方法就是專門修補這個BUG的，如果做一些改動的話，Windows 2000的用戶就會發現，無論是互聯網還是視窗瀏覽的速度都有了很顯著的提高:
打開注冊表
HKEY_LOCAL_MACHINE/Software/Microsoft/Windows/CurrentVersion/Explorer/RemoteComputer/NameSpace
在其分欄出選擇鍵值：
{D6277990 -4C 6A -11CF-8D87-00AA 0060F 5BF
然後刪除。
因為就是這個健值引導Windows去搜索「計劃任務」。不需要重新開機，幾乎立刻就可以感受到你的瀏覽程序快了很多！
49.故障現象：已經按照要求安裝、設置好Sygate，但伺服器仍不能連接網路。
分析、排除：使用Sygate中特有的Sygate Diagnostics（診斷）功能。可以通過以下兩種方式來啟動診斷醫生，在Sygate王界面的工具欄電權擊Diagnosticstool（診斷工具）圖標，或者點去開始一程序一Sygate——Sygate Diagnostics。這時診斷工具會依次測試系統設置、網路適配器、撥號連接、TCP/IP協議與設置等。如果測試不能通過，系統會出現一個提示，描述問題及指點正確的方向。此時你可以根據提示作相應的更改。如果測試通過，診斷工具會顯示已經測試通過的提示。
50.故障現象：正確安裝Sygate4後，網路中的某些客戶機不能正常使用。
分析、排除：一般情況，客戶機不能正常使用多為TCP/IP的配置出現問題，當然也不排除操作系統和硬體（比如網卡已壞等）的問題，在這種情況下，你可以使用Sygate的Troubleshooting（發現並解決故障）功能，在出現的表單中詳細列出使用Sygate後產生的信息資料，例如：sdsys．log、Sygate．log、sgconf．log、sgsys．log等，在這些日誌中包含了伺服器、操作系統、撥號網路、網卡、瀏覽網址、應用程序等詳細資料，你可以根據這些資料來判斷故障，然後作出相應修改。
51.故障現象：自從安裝Sygate後，伺服器經常會莫名其妙自動撥號上網。
分析、排除：這是因為網路中的客戶機啟動了某些網路軟體，例如瀏覽器、電子郵件軟體等，而又在配置中勾進了Enable Dial－on－Demand For Cline（允許客戶機撥號），這樣當SyGate偵測到網路中有連接到Internet的請求，如此時系統尚未建立連接，便會自動撥號。只要去掉前面的小勾，即能解決這個問題。
52.故障現象：用分機電話線上網，Modem為實達網上之星，上網連接速度最快才48000bps。還有，將Modem放在主機箱側，開機後（未打開Modem電源），家裡的電話就處於忙音狀態。
分析、排除：第一個問題跟分機電話線或線接頭質量有很大關系，另外，如果Modem的速度平常都能接近48000bps，也不要太在意，應該重點先看一下它的實際下載速度是否令你滿意。第二個問題，肯定和主機電源的電磁輻射強和屏蔽效果差有關，最好用物體在主機和Modem之間進行屏蔽，或將Modem遠離主機。
53.故障現象：一台計算機通過區域網連接,一切正常。但是換了一個硬碟、重新安裝Win98操作系統後,查看網上鄰居時,只能看到自己的計算機和所屬的工作組；而訪問外部網卻沒有問題，收發郵件也沒問題。
分析、排除：啟動電腦後不要立即打開網上鄰居，而是等一下再打開，並且按F5鍵刷新，一般可以看到新的工作組和用戶。如果實在不行，就用查找計算機，找到其他組的計算機後作成快捷方式放在桌面上。
54.故障現象：有時ADSL的訪問速度較平時慢。
分析、排除：原因很多：可能是出口帶寬及對方站點配置情況等原因的影響；可能是線路的質量情況的影響；可能是接入局端設備影響。
55.故障現象：在Windows NT4.0操作系統上已經安裝了Modem、TCP/IP協議和RAS服務，但在拔號上網鐵過程中，計算機屏幕上出：「734錯誤，對方伺服器終止(口令和用戶名均無誤，在Windows下可以正常上網)」的提示框。
分析、排除：在「設置」中不要輸入域名試試看。
56.故障現象：在Windows NT4.0操作系統上撥號上網的過程中，在檢測用戶名和密碼時要斷線。
分析、排除：可以將驗證密碼的選項改成明文驗證方式試試看；可以把撥號網路屬性中「撥號後出現終端窗口」復選框選中試試看。
57．故障現象： 在Windows NT4.0操作系統上撥號上網的過程中，在檢測用戶名和密碼後自動斷開。
分析、排除：可在「新的電話簿項」中，單擊「安全」項，然後在「認證與加密規則」中選中「接受任何驗證」。
58．故障現象：只要一啟動IE瀏覽器，就會自動執行發送和接收郵件。
分析、排除：可打開IE瀏覽器，在菜單欄中單擊「工具(T)」項，在彈出的下拉式菜單中選中並單擊「Internet選項(O)」項，在彈出的對話框中單擊「常規」標簽，去掉「啟動時自動接收所有帳號怕郵件」項便可以了。
I. 公務員面試的時候考官都問哪些問題都問什麼類型的問題
公務員面試的題目主要出在處理關鍵、突然、棘手的行政性質的題目。
比如，在北京前年的公務員面試中有一道這樣的題目：你負責采購單位的一批電腦，張領導說要買品牌機，氣派；王領導說要買兼容機，實惠。你要怎麼辦？ 這就涉及到人際關系和上下級、上級之間的關系調和問題。
還有一道國家公務員考試的面試題，是問如果你是導游，帶隊第一次去往新的旅遊線，在景區突然有隊員出現食物中毒的症狀，你怎麼辦？ 這要求的是你處理突然、緊急事務的能力。
其實，考這類題目往往要求你的是穩重，以及大局觀，既要面面俱到又要事事抓在點上，更何況面試的問題往往有彼此的重復性和模式化，並不難對付。第一個問題看似棘手，而且很多人也會為難自己的立場，又難討好上級又怕下屬說自己諂媚，其實這類題目的回答模式就是兩不得罪，另立山頭。
自己去做市場調研，分析品牌機和兼容機的優劣，自己做主選擇一類，而且和張領導解釋你買的電腦式樣好，質量也靠得住；對王領導則說明電腦的價格和其他的電腦相比是比較低的，而且性能也不差。這樣，就是這一道題目的解題技巧，實際上，並不難。
J. 智能客服結構-v1.0
前言 ：這篇文章僅對客服機器人這種偏任務導向型機器人架構的探究，文章中部分是已經得到驗證的經驗，部分是經歷了行業無數競品的對比中針對面臨的問題重構出的產品結構。我一直堅持「對話機器人的對話結構是一個產品策略」的觀點，所以這篇文章更偏向於針對電商（筆者是電商垂直行業）智能客服對話機器人（文中簡稱智能客服）中的用戶現象的產品策略問題，有不足之處歡迎各位產品與技術大佬們指導。
一、目錄概述
內容主要分為整體結構與常見問題兩個角度的探究。因用戶在智能客服中的表現的多樣性，故不窮舉贅述，在每個解決方案與架構設置原因中針對單獨問題一一探究。
二、智能客服主要解決的問題
客服主要解決用戶Q（query）→A（answer）問題，好的資深客服對業務邏輯結構更了解，不僅能基於用戶未完全形容時推斷用戶情況、根據用戶情況給予更多的業務解決方案，更能在對話中判斷用戶的傾向性（情感、期望值等）。
那智能客服如何像客服一樣解決問題呢。下面引入三個概念
圖1 用戶問法，業務邏輯結構，業務解決方案關系圖
名詞解釋：
[if !supportLists]Ø [endif] 業務邏輯結構（因筆者對知識圖譜理解太淺，固用此名字代替） ：面向用戶的業務類型，多呈現樹狀結構，如售後，售後-退貨，售後-退貨-運費等的二叉樹結構；某個子業務的判斷條件，如常見電商的退貨條件為七天。
注 ：為什麼將判斷條件放在業務邏輯結構中，後續會講到的用戶問法中會將某一判斷條件作為意圖放在會話中。如「我要退貨」的處理方式需要判斷用戶訂單是否超過七天，用戶的延伸問法「我的訂單剛買兩天，想退貨」，此問題在理解中屬於重難點解決問題。
[if !supportLists]Ø [endif] 業務解決方案 ：通常針對於某一業務會延伸出多樣化的子業務，如：「我要退貨」「退貨用什麼快遞」「退貨的運費誰承擔」，通常對於一問題會有至少1+的解決方案（公司能提供的解決方案多少問題根據公司能力決定不在此討論）。
[if !supportLists]Ø [endif] 用戶問法 ：自然語言中的現象結合某一子業務產生的問法類型不用，如：「定義類——什麼是七天無理由退貨」「滿足類——我的訂單支持七天無理由退貨嗎」等。
解決智能客服問題應答用戶問題主要解決 兩個問題 ：
1.解決用戶問法在業務邏輯結構（知識圖譜）中的位置問題。
2.解決用戶問法+業務邏輯結構=用戶解決方案問題。
三、
針對於上面我們提到的智能客服主要解決的問題，筆者提供兩種 解題思路 ：
[if !supportLists]1. [endif]分類業務類型，將業務類型中的問題用QA的方式維護，對用戶問題中的子串（去無用詞「嗎」「好的」等）用檢索重排序的方法分別在增加的Q中和A中進行篩選，最終篩選出閾值最高的一條Q或者A，以此條答案為回復用戶問題的答案。當然，中間有不少穩定準確率與召回率的兜底方案，可根據實際情況調控。此方法的好處在於穩定，不過更像解決搜索問題而不是解決對話機器人問題。
2.第二種方案是本篇主要講的方案，引用三角獸科技CEO 王卓然博士《任務驅動多輪對話評測標准【人機對話評測系列之一】》中的圖為例。（文末會有此篇文章的鏈接）
圖2: 任務驅動的多輪對話系統的一個經典框圖
主要把智能客服對話結構為三部分：意圖理解NLU（用戶目的分類和Spoken Language Understanding）、對話狀態（Dialogue State）、應答（System Action）。圖中ASR（語音識別）、NLG（答案生成）、TTS（文語）模塊因並非提升智能客服主要的體驗問題，並且筆者未深入研究，故此篇文章不深入探討，後續了解後會針對這些問題單獨講述。
三、智能客服與業務結合基礎
3.1 把業務教給智能客服
上文中提到，要解決用戶問題，必須讓對話系統模擬業務的真實狀況，所以梳理業務邏輯結構非常重要。
拆分業務邏輯主要為三點原則：
[if !supportLists]² [endif]用戶通常有哪些目的（能提供的業務有哪些）
[if !supportLists]² [endif]這些目的之間有沒有關聯性（不包含會話中易出現的關聯性）
[if !supportLists]² [endif]哪些信息（條件）是實現目的的必要因素
待探究問題：有沒有清晰的拆解規則同時滿足NLU的准確性與業務的完整性？此規則能否通用？
拆分完業務邏輯結構，更重要的是把業務邏輯結構教給智能客服。基於拆分的三點原則，我們要教給智能客服的為兩點：
[if !supportLists]² [endif]有哪些意圖（intent）或分類—自然語言理解的分類問題。
[if !supportLists]² [endif]哪些是實現意圖的必要條件—結構化識別與多輪對話問題。
3.2 理解用戶在對話中的目的
在對話系統中，自然語言中的query會呈現結構化的語義表示，這個結構化的語義通常被稱作dialogue act由 communicative function 和 slot-value pairs 組成，其中 communicative function 表示 query 的類型（如：陳述需求，詢問屬性，否定，選擇疑問，等等）而每個 slot-value pair 則表達一個限制條件（constraint），也可理解為用戶目標的一個組成單元。
例如「我的訂單到上海了嗎」對應的dialogue act可以表示為inform（entity=訂單or物流，location=上海）。這里的inform就是communicative function，表示詢問查詢，「entity=訂單or物流「和「location=上海」是限制條件（slot-value pair）
四、智能客服架構
3.3 意圖識別NLU
此處的意圖識別NLU，單指 對用戶標准問法(用戶一句話把問題描述清楚)的理解與分類 和對話系統中的 口語處理問題 。
由於用戶在對話系統中輸入時更偏向與口語化的表述，所以在對話系統的意圖識別板塊，我們更關注口語處理，其中包含了對非嚴謹語法（即用戶問題可能產生的語法錯誤糾錯與錯別字接錯）和識別中如何保持准確的魯棒問題。
為什麼一定要將用戶語義（dialogue act）作 結構化識別 ，主要是解決用戶將條件加在會話中陳述的導致容易造成智能客服理解混淆問題（例如上文提到的我收貨兩天了能不能退貨）。
當然，我們也可根據業務場景不同才用不同的識別策略。
Google 的dialogflow 在識別上有的三種策略：
[if !supportLists]² [endif]trait策略：整句理解，比如意圖、情感等，通過分析整個用戶問句來得到實體值
[if !supportLists]² [endif]free-text策略：用來抽取用戶問句中的子串，這些子串通常不會包含在預定義的實體值詞典中
[if !supportLists]² [endif]keywords策略：用於處理需要抽取的實體值可枚舉的情況，我們為實體准備好一個預定義的實體值詞典，該實體的抽取就通過使用實體值詞典做匹配來完成
網路UNIT 也同時區分了利用詞槽與槽組的識別與特徵詞的識別。
採取哪種識別策略，主要還是根據業務的可行性與最終達到的效果進行確定 ，當然亦可組合使用，我們可以根據詞槽來判斷用戶詢問的業務之間的關聯性，可根據用戶整句識別判斷用戶的情感偏向，也可在業務子串可窮舉並且關聯性小的情況下使用關鍵詞策略提高識別的准確性。
但是在用戶與機器完成的單輪對話中，依然存在一定的難點，此問題在後面詳細討論。
結論： 上文中提到的意圖識別或SLU問題，大家應該可以注意到，其本身都是典型的結構化分類問題，雖然所用的模型千差萬別，其中對於處理過擬合、欠擬合的方法也褒貶不一，但是無非就是准確率、召回率等問題。
3.4 對話狀態
對話系統中存在的現象決定了對話狀態跟蹤（Dialogue State Tracking）存在的必然性。
大家可以注意到，上文中提到的分類問題屬於標准情況下的處理方式，但用戶在對話系統中的表現擁有不確定性，所以在這里給對話系統引入了一個在不確定性環境下決策的問題（planning under uncertainty），雖然最終的決策是由下面要介紹的對話策略完成的，但是對話狀態需要為後面的決策提供依據，也就是如何刻畫這個不確定性的問題。
在智能客服對話中存在以下現象：
[if !supportLists]ü [endif]不考慮上文中提到的口語處理，在用戶問法中，存在 閑聊 與 業務 兩種形態的對話，其中閑聊為業務的輔助構成部分。
[if !supportLists]ü [endif]業務問題中，存在 意圖清晰 與 意圖模糊 的問法
[if !supportLists]ü [endif]用戶意圖清晰的情況下，我們需要根據業務需要讓用戶補充必要條件，或通過用戶補充讓問題更精確。如：天氣問題中，用戶詢問「北京明天天氣」「北京明天八點天氣」，都可給出答案，不同的在於答案的精準程度。
基於以上三種現象，首先我們需要知道用戶在 當前對話 中 處於什麼狀態， 其次是根據當店對話狀態我們給出用戶 最終答案 需要什麼 對話策略。
3.4.1 對話狀態跟蹤
對話狀態跟蹤，簡單來說就是根據對話來確定用戶 當前或最終的目標 到底是什麼，此處不僅包括封閉域對話中的 任務驅動式多輪對話， 還包括區分閑聊、問答、任務四類問題，根據業務情況劃分意圖模糊與意圖清晰之間的界限。
[if !supportLists]Ø [endif]在區分閑聊、問答、任務類問題中，大概可分為三點
[if !supportLists]1. [endif] 為什麼要區分閑聊 ：閑聊是一種不局限於話題的開放域聊天（開放域機器人如微軟小冰），即在用戶的問題 沒有明確的信息 或 服務需求時 系統做出的回應。
開放域聊天在智能客服中的作用有兩點：第一點為拉近距離、順滑對話過程、建立信任等；第二點為挖掘用戶情緒引導用戶服務請求。
[if !supportLists]2. [endif] 是否需要區分問答、任務類 ：以智能客服行業典範阿里小蜜來說，是區分了問答類和任務類問題的，但是為什麼區分政策和任務類問題以筆者的經驗來說僅是根據解決方案的不同，但在用戶query無法提現。
如：「是否支持七天無理由退貨」的兩層含義：一層為公司政策是否支持，一層是用戶詢問購買的商品是否支持。前者是以搜索較優方案的政策類解答問題，後者是以任務式判斷的方式解答問題更為准確。
所以，在QA問答系統和task flow驅動式系統上，個人認為電商類問題更趨向於用task flow解決問題並將QA融入其中。當然，此問題還需要根據客服解決問題的形態具體情況具體分析。
[if !supportLists]Ø [endif]意圖清晰與意圖模糊問題
如何定義意圖清晰與意圖模糊問題，拋開自然語言中的口語處理不講，我認為它 更偏向 於一個 業務問題 。
對於用戶來說，用戶對智能客服的目標（user goal）是可以確定的，用戶目的的表示形式是一組限制條件（slot-value
pairs）的排列組合。換句話說，理解用戶真正的目的（user goal），需要機器理解上文中說到的業務邏輯結構（知識圖譜）中每一枝乾的關系（或歸屬於某一枝幹）。
也就是說，當用戶當前的會話表述中某一組限制條件的排列組合 對應多個枝幹 時，為 意圖模糊問題 。當 對應一條枝幹 時，為 意圖清晰問題。
對於 意圖模糊問題 的解決方式，大可以用檢索式反問的形式來引導用戶，即詢問用戶 可能想問的問題是什麼 。對於 意圖清晰問題 ，但無法給出明確答案時，為一個 任務驅動式的多輪對話問題 （後文多輪對話展開討論），即電商問題中常見的需要用戶補充訂單號或某些意圖。
[if !supportLists]Ø [endif]當進行了前面的口語處理，閑聊與業務區分，區分意圖模糊與清晰問題後，我們已經可以理解了用戶的目的，即用戶問的問題屬於業務邏輯結構（知識圖譜）中的哪一枝幹，接下來在解決用戶服務請求的過程中，最後需要處理的就是 補充用戶目的所需的判斷條件或槽位 （如「查物流」我們需要知道用戶的訂單號）和 判斷用戶的目的改變 （如「查物流」轉變為「幾天能到」問題） 。
以上問題為智能客服對話狀態跟蹤中常見的需要解決的問題，但是任務驅動式多輪對話中問題現象不僅於此，在下文的多輪對話問題中再詳細闡述。
3.4.2 對話策略
理解了用戶在對話中的行為，我們來討論一下關於對話狀態中使用的對話策略問題。
對話策略是根據上面介紹的置信狀態來決策的過程。對話策略的輸出是一個系統動作（system action）。和用戶的 dialogue act 類似，系統動作也是一個由communicative function 和 slot-value
pairs 組成的語義表示，表明系統要執行的動作的類型和操作參數。「每次決策的目標不是當前動作的對與錯，而是當前動作的選擇會使未來收益的預期（expected long-term reward）最大化」
根據上文中的講述，此問題也可分為三種類型。
[if !supportLists]Ø [endif]基於開放域機器人的閑聊來建立信任、引導操作、增加對話流暢度問題，此問題筆者並沒有深入研究，但就經驗來講，可實現的策略包含用戶發起咨詢時的預判用戶問題與引導用戶操作。
[if !supportLists]Ø [endif]區分用戶意圖模糊與意圖清晰的策略，在意圖模糊中，個人更偏向於用檢索+重排序的方式定位用戶問題在訓練語料或業務邏輯結構，進而產生用戶可能咨詢的問題，也就是在對話中反問用戶，但一方面用戶會因為機器人猜的不準確而對智能客服的信任感降低，另一方面推測的准確性和人一樣，更依賴於知識的覆蓋率與准確率。所以，讓智能客服像資深客服一樣能「猜」的更准，還是一個需要實際驗證的問題。
[if !supportLists]Ø [endif]任務驅動式多輪對話中的補充用戶槽位與目的轉變的槽位繼承問題本身更偏向於根據業務去優化的問題。
補充用戶槽位的問題很好理解，如「查物流」需要詢問「您要咨詢的訂單號是？」，進而能得到很好地解決。
目的轉變後的槽位繼承問題還是需要根據業務情況做詳細調整，如上文提到智能客服在「查物流」中獲取了用戶訂單號，那麼用戶問「多久能送到」時，意圖轉變後訂單號依舊需要繼承。當然此問題中會因用戶有澄清式問法而改變，如用戶增加「我要咨詢其他訂單」的問法後，即清除對話狀態中的「訂單」。以上只是舉了兩個簡單的例子，但一個業務中可能包含多個槽位或一整個槽位組（槽位之間存在平行、依賴關系），針對於業務情況不同，對話策略還需要精細化運營。
3.5 應答-最終答案
在經歷了教會智能客服理解用戶問題的漫長過程後，我們終於來到了討論給予用戶的解決方案部分。
普遍的來講，解決方案可以有文本、圖文、視頻、API集成等多種的樣式，但實際最終用戶的query只會得到唯一的answer，這個唯一的answer的樣式及豐富程度，不僅僅取決於我們業務不同需要給予用戶不同的解決方案，同時也依賴於對話狀態中還可以記錄完成對話任務所需的其他額外信息，例如用戶當前詢問的屬性（requested slots），用戶的交互方式（communication
method），和用戶或系統的歷史對話動作（dialogue history）等等。
以觀察阿里小蜜的經驗來講，小蜜從原來的圖文答案部分轉向了API繼承的方式，但依然沒有感知出針對於用戶畫像給予不同的答案（可能是我不怎麼咨詢客服的原因）。
所以以上的內容就不在這里展開，我會在後面《智能客服服務提升》中討論。
四、結論
能從頭看到這里，我相信不是對智能客服本身有一定了解忽略了一大部分抽象內容，就是根本不需要看前文就能理解結構的大佬。
個人認為，智能客服的架構本身只有三部分意圖識別及SLU問題對業務進行的分類問題，用戶在對話中的表現轉化為標准問法的對話狀態（DST）問題，與歸屬完問題後提供給用戶最終的解答方案問題。完成這三部，大概在產品架構上能實現智能客服從0到1的方案。
當然構建三部分時應該遵循幾點原則：
[if !supportLists]1. [endif]保持訓練語料的一致性，用戶問題是否直接分類、意圖模糊或需要用戶補充統一由對話狀態模塊判斷。
[if !supportLists]2. [endif]業務的拆解盡可能細致，因為業務邏輯結構（知識圖譜）決定了結構化識別的准確性與對話狀態的判斷准確率。
[if !supportLists]3. [endif]識別策略和對話策略中盡可能增加兜底方案保證准確率與召回率，結構化識別並不是萬能的，有時我們也需要加入檢索的方式保證用戶問題會產生一個相對准確的解決方案。
以上為智能客服架構時的一些思路，至於每部分中提到的具體問題，會在後續《智能客服的服務提升中》探討。