倪慧薈，吳園濤，石 彪

(1.北京市勞動保護科學研究所，北京 100054；2.中國科學院重大科技任務局，北京 100864；3.中國科學院科技戰(zhàn)略咨詢研究院，北京 100190)

0 引言

我國的應急管理體系自2003年“SARS”疫情之后逐步建立起來，經(jīng)過多年的發(fā)展，基本形成了以“一案三制”為核心的架構[1]。2018年3月，應急管理部的成立為防范化解重特大安全風險，整合優(yōu)化應急力量和資源提供了有力支撐。在應急管理理論研究不斷深入、工作實踐日益精進的背景下，與應急管理相關的知識在近年得到了極大的豐富，其專業(yè)化程度也在不斷提升，但從知識保存和使用的方式來看，應急管理的大部分領域知識仍然停留在文檔管理層面，呈現(xiàn)出碎片化、孤島化、斷檔化等問題。而在應急管理實踐中，很多管理者和業(yè)務實施人員并非安全與應急管理相關專業(yè)出身，往往都要遵循“學習知識-掌握知識-實踐檢驗-總結(jié)提升”的閉環(huán)流程，在積累到一定程度后，才能基本達到專業(yè)水平。因此，采用更為高效的知識管理架構來傳承和管理知識，提升知識流轉(zhuǎn)、應用和更新效率，減少實踐中對人員初始專業(yè)素養(yǎng)的依賴，是新形勢下的必然需求。

在上述背景下，應急管理知識庫作為一個可行的解決方案得到了廣泛關注。知識庫的概念早在20世紀80年代就已存在，最初目標是應用專家的專業(yè)能力求解特定問題，因此初期常以“專家系統(tǒng)”的形式出現(xiàn)[2]。隨著相關研究的演進，知識庫的概念逐漸擴大，成為一類特殊的數(shù)據(jù)庫，偏重于知識之間的關系、屬性及語義的溝通[3]，其與普通數(shù)據(jù)庫最大的區(qū)別在于除了需要存儲事實類數(shù)據(jù)外，還需對過程性、啟發(fā)式數(shù)據(jù)(即經(jīng)驗知識)進行處理與存儲，以便讓其發(fā)揮更重要的作用[4]。

初期，學者普遍認為應急管理知識庫應以提高應急處置決策的科學性與效率為首要目的[4]，因此學術界對應急管理知識庫的研究大部分集中于預案庫、案例庫等主題上。如榮莉莉等[5]從知識供需匹配的角度對應急預案的構成做了初步分析和評價；李永海等[6]提出一種基于案例庫的方案生成方法；祁明亮等[7]從預案模塊化的角度提出基于預案庫的預案重構思想；溫志強[8]提出基于應急預案與案例庫的“兩案三制”突發(fā)事件應急決策模式，強調(diào)案例庫建設對于應急決策體制建設的重要性；Bryson等[9]將災害恢復預案(DRP)描述為預案庫中若干子預案的集合；王慶全等[10]將文本型預案表示為由概念及其之間的關系定義的語義信息，從而便于提取相關信息為新的應急情境提供決策輔助。

按照目前學界廣泛認可的應急管理四階段(預防、準備、處置、恢復)劃分，以往的應急管理知識庫相關研究主要匯集在應急處置階段。而從業(yè)務層面來看，應急準備工作(包括儲備物資、鍛煉隊伍、應急演練、建設避難場所、宣傳教育等)占據(jù)的時長和工作量卻要遠遠高于真正的應急處置。應急準備在實踐中又是“知識斷檔”問題的“重災區(qū)”，頻繁的人員調(diào)動和職責變更導致大量的工作出現(xiàn)“斷檔-重新學習摸索-再次斷檔”的困境，嚴重影響了應急準備工作的效率。亟需為之設計相匹配的知識庫系統(tǒng)，從而提升整體的應急管理水平。

本文著眼于應急準備階段的知識內(nèi)容特點和知識管理流程，探討應急準備知識庫系統(tǒng)的設計和實現(xiàn)方法。與過往研究側(cè)重于對知識庫整體架構[4]、功能設計[11-12]、數(shù)據(jù)引擎[13]，知識表示和推理[14-16]等進行理念或理論架構的闡述不同，本文擬從應用實踐的角度出發(fā)，基于用戶視角，以演練方案編制為例，闡述應急準備知識庫系統(tǒng)具體的設計和實現(xiàn)過程。

1 應急準備知識庫概述

1.1 應急準備知識層次架構

要構建應急準備知識庫，首先應明確應急準備知識涵蓋的內(nèi)容。通常來說，應急準備知識可以來源于應急準備工作中需要用到的各類信息載體，如紙質(zhì)文檔、宣貫海報等有形的介質(zhì)，以及預警指標閾值、風險指數(shù)等無形的數(shù)據(jù)或模型。為了更好地界定應急準備知識的概念，本文提出如圖1所示的應急準備知識三級層次架構。其中，“知識范疇”代表最廣義的知識來源，一切與應急準備、甚至應急管理有關的信息載體均可被認為是知識范疇。而“知識主體”是指，經(jīng)過初步提取和篩選后獲得的知識范疇的子集，可以認為是經(jīng)過初篩后按照不同主題或類型進行聚類后得到的較為“大顆?！钡摹按种R”?？紤]到內(nèi)容規(guī)范化、體系化程度的不同，以及使用場景的差別，目前應急準備環(huán)節(jié)能實現(xiàn)模塊化管理的知識主體主要包括：法律法規(guī)、技術標準、應急預案、歷史案例總結(jié)、應急裝備與物資數(shù)據(jù)、應急隊伍數(shù)據(jù)、應急演練方案等(這些知識主體在傳統(tǒng)的應急管理信息系統(tǒng)中就是所謂的“知識庫”)。在知識主體基礎上，再進一步提取，就可以得到“知識點”，其是能應用于知識加工、輸出等復雜應用需求的“小顆?！钡摹熬氈R”。

圖1 應急準備知識層次架構Fig.1 Hierarchical structure of emergency preparedness knowledge

1.2 應急準備知識庫系統(tǒng)定位

知識管理概論通常定義的知識管理業(yè)務流程是一個包含5個主要模塊的螺旋式循環(huán)，如圖2所示，應急準備知識庫也不例外。再結(jié)合引言中所述的“知識斷檔”的困境，應急準備知識庫應該達到的主要定位目標可歸納為如下4條：

1)完成應急準備知識的輸入和提取。

2)實現(xiàn)應急準備知識的體系化、標準化、規(guī)范化存儲。

3)簡單、便利地對應急準備知識進行維護更新。

4)高效地查詢應急準備知識，并且可以利用這些知識生成目標結(jié)果。

圖2 知識管理通用流程Fig.2 General procedure of knowledge management

上述前3條解決的是知識的提取和存儲問題，最后1條解決的是知識的應用問題。前者已有較多的文獻論述[4]，本文不再贅述；后者是相對更重要的應用需求，往往需要結(jié)合應用場景，創(chuàng)建知識點才能完成，這是本文關注的重點。下文就以“應急演練方案的智能生成”這一應用場景為例，提出并探討一種包含方案模板設計和智能向?qū)е谱鞯壤砟钤趦?nèi)的一整套應急準備知識庫系統(tǒng)設計與實現(xiàn)思路和方法。

2 系統(tǒng)設計與實現(xiàn)

2.1 系統(tǒng)設計概述

從知識庫系統(tǒng)應用的角度，設計考慮的要素主要包括：用戶、需要存儲和應用的知識內(nèi)容、使用知識的場景、應用模式等。本文將之歸納為“四要素設計法”。其中，用戶設計需要明確會有哪幾類人群使用知識庫，其各自又分別有多大的操作權限；知識內(nèi)容的設計一方面要明確納入知識庫的具體知識內(nèi)容，另一方面要為不同類型的知識提供合適的管理方法；使用場景設計來源于對應用知識的直接需求，通?？梢苑譃椴樵儭⒎窒淼然拘枨?，以及加工輸出等復雜需求，基本可視為對系統(tǒng)功能的設計；應用模式則主要是考慮系統(tǒng)的使用方式，包括了系統(tǒng)的部署、網(wǎng)絡條件以及不同用戶的業(yè)務模塊、知識流轉(zhuǎn)邏輯等。這4大要素中，最能體現(xiàn)知識庫系統(tǒng)特點的是知識內(nèi)容和使用場景的設計，可以認為是核心模塊。下文分別針對上述4個不同要素進行闡述。

2.2 用戶設計

應急準備知識庫系統(tǒng)不同于一般的知識分享載體或科普用具，其終端用戶主要可以分為2大類：①負責具體實施應急管理職能的政府部門或企事業(yè)單位；②為第①類單位提供咨詢及技術服務的第三方機構。無論具體由哪個組織來使用，知識庫系統(tǒng)的核心均在于知識的存儲、管理、共享與應用。因此，應急準備知識庫系統(tǒng)必然也是一個多種用戶聯(lián)動的系統(tǒng)。僅從應用角度，可以定義如表1所示的4類系統(tǒng)用戶。

表1 系統(tǒng)用戶分類Table 1 Classification of system users

表1中前3類用戶一般為默認用戶，對于知識管理的權限深度不同，但通常均只面向系統(tǒng)用戶對應組織內(nèi)部的人員。最后的知識瀏覽用戶則是組織根據(jù)實際需要來決定是否設置，通常面向外部人員或尚在考察期內(nèi)未完全被組織認可的人員?？梢钥紤]授予有限的瀏覽權限，一方面達成必要的知識共享要求，另一方面也能有效地保護內(nèi)部知識的完整性和私密性。

系統(tǒng)管理員可以對用戶類型進行必要的更改和停用，以適應隨時可能變化的人員身份，同時，也可對用戶進行可獲取數(shù)據(jù)的范圍管理，確保不同級別的用戶只能瀏覽授權的數(shù)據(jù)。

2.3 知識內(nèi)容設計

2.3.1 知識主體結(jié)構化

知識內(nèi)容管理的第1步是從知識范疇中初篩得到知識主體，并轉(zhuǎn)化為系統(tǒng)支持的格式導入知識庫，這可以由具備初步經(jīng)驗的知識使用者來完成。早期的知識庫管理通常是將已形成的方案整體作為一項知識進行存檔，在必要時完整調(diào)出使用，該類知識主體屬于非結(jié)構化內(nèi)容。比如早期的“應急預案庫”中就直接存放了大量的預案文檔，這些文檔通常沒有進行標簽化和版本管理，甚至大多沒有相對比較統(tǒng)一和精確的命名。這樣的知識管理模式無法實現(xiàn)高效精準的查詢，同時也難以實現(xiàn)對知識的智能加工。因此，將知識主體結(jié)構化是識別知識點并實現(xiàn)存儲的基礎工作。

結(jié)構化原理如圖3所示，第1步是把方案整體按照不同的內(nèi)容切分成獨立的內(nèi)容模塊。例如，1個完整的演練方案通常包括：總則、演練基礎信息、事件信息、參演資源清單、進度計劃、風險分析等內(nèi)容，可以首先將上述內(nèi)容作為一個個獨立分析的單元。這一步通常從文檔結(jié)構圖的角度即可完成。

圖3 知識主體結(jié)構化Fig.3 Structuralization of knowledge main body

其次，是對各個內(nèi)容模塊進行解析，區(qū)分出哪些屬于可以標準化的內(nèi)容，哪些屬于知識點。圖4展示了1個演練方案總則模塊的部分內(nèi)容，由圖4可以發(fā)現(xiàn)，圖中劃線的文字部分會根據(jù)演練方案的不同而產(chǎn)生必要的變化，而非劃線的部分則幾乎可認為是萬用型的普適性內(nèi)容。因此，如果能將普適內(nèi)容標準化，同時將劃線內(nèi)容作為知識點靈活調(diào)用，則演練方案這一知識主體就能得到較好的結(jié)構化，使智能生成演練方案成為可能。

圖4 演練方案總則部分示例Fig.4 Drill plan sample (part of general principles)

2.3.2 知識點提取與管理

有效地識別出知識點之后，需要針對其不同特點設計對應的管理方式。以演練方案為例，可能涉及的知識點主要包括圖5所示的4種類型。圖5中最右側(cè)1列的框選部分是對應知識點的示例。

圖5 常見知識點類型Fig.5 Types of common knowledge points

1)靈活型知識點

該類知識點的特點是用戶通常沒有固定范例可用，可根據(jù)實際情況靈活填寫和插入對應位置。靈活型知識點不僅限于文字，也可以是圖片等其他內(nèi)容。

2)文檔型知識點

該類知識點就是指常見的完整文檔文件。顯然，預案和案例類的知識點并不適合這樣處理，會顯得太粗糙，但是某些文檔(比如法律法規(guī)、技術規(guī)范等)用于引用或查詢的頻次較高，因此可以為其做單獨的存儲處理。圖5示例中的各項法律條目和技術標準可以做成索引直接插入方案，用戶可在方案中直接將其打開。

3)數(shù)據(jù)字典型知識點

數(shù)據(jù)字典型的知識點通常是用戶使用頻率較高的知識(如圖5示例中框選內(nèi)容所示)。若將其做成數(shù)據(jù)字典并適時維護，就能支持用戶在編輯時通過下拉選擇進行輸入(數(shù)據(jù)量較大時可采用查詢方式)。數(shù)據(jù)字典的主要素包括數(shù)據(jù)字典分類(為樹狀結(jié)構)和數(shù)據(jù)字典名稱(比如“事故分類”)。此外，可以定義方案內(nèi)數(shù)據(jù)字典和全局數(shù)據(jù)字典，一般情況下采用全局數(shù)據(jù)字典。圖6展示了1個數(shù)據(jù)字典示例。

圖6 數(shù)據(jù)字典示例Fig.6 Data dictionary sample

4)預置型知識點

有些知識點比較常用，并且關聯(lián)關系復雜，例如參演單位、演練人員、演練道具、進度成果等，因此可以進行系統(tǒng)預置，方便后期靈活調(diào)用。預置型知識點的信息，類似固定的數(shù)據(jù)字典，但可以支持比較復雜的主從結(jié)構并進行基礎數(shù)據(jù)的維護。例如，1個參演單位，可以進一步包含多個參演人員信息。

除此以外，按表現(xiàn)形式來分，知識點還可以被進一步分成文字型、表格型、圖片型等，這對知識點的提取與管理并不構成本質(zhì)影響，本文不做展開討論。

2.4 使用場景設計

2.4.1 建立模板

查詢和分享是知識庫系統(tǒng)的基本應用需求。通常來講，一般的數(shù)據(jù)庫操作即可滿足，無須贅述。因此，本文重點闡述如何針對知識的加工輸出進行設計。

在完成知識主體結(jié)構化及知識點提取的基礎上，可以創(chuàng)建業(yè)務模板。所謂業(yè)務模板也就是標準方案，其由資深的業(yè)務專家(比如專業(yè)的應急演練策劃，也即用戶類型中的知識管理員)創(chuàng)建并維護，內(nèi)容主要由2大部分組成，第1部分是該業(yè)務類固定文檔的輸出樣式，第2部分是該業(yè)務類非固定文檔的輸入知識點名稱和形式。業(yè)務模板定型后，業(yè)務實施人員可以直接使用，從而顯著提升方案的輸出速度和質(zhì)量穩(wěn)定性。

考慮到MS Word文檔的通用性，以此作為原始模板制式可以認為是一種較好的選擇。為此，首先需要為用戶制作1個基于MS Word的模板編輯工具(可以以插件的形式存在)。借助該工具，可以手工創(chuàng)建所有需要的方案模板。比如，可以分別為桌面推演和實戰(zhàn)演練創(chuàng)立不同的方案模板。在模板中可以設立書簽(就是未來要填寫數(shù)據(jù)的占位符)。圖7展示了1個示例。

圖7 業(yè)務模板示例Fig.7 An example of work template

模板設計時，一方面需要通過設計工具，填寫好所有固定內(nèi)容部分，同時通過設定占位符的方式，描述非固定內(nèi)容的位置和文字格式。另一方面，還需要設定該占位符對應的知識點具體表現(xiàn)類型(如數(shù)據(jù)字典型、表格型、圖片型等)。

2.4.2 編制向?qū)?/p>

有了標準業(yè)務模板之后，由資深業(yè)務專家編制1個配套的方案智能向?qū)?，最終真正完整實現(xiàn)對已有知識的加工和輸出。方案智能向?qū)嶋H就是為非專家用戶準備的1份面向某知識主體對應知識點的使用指南(比如演練方案向?qū)Ь褪侵笇Р惶☉毖菥毜挠脩羧绾文苁褂眉扔械闹R生成1份較為專業(yè)的演練方案)。與傳統(tǒng)知識庫系統(tǒng)只提供知識查詢功能不同，向?qū)Э梢匀轿惶崾居脩粼撌褂煤畏N知識點，以及相關的注意事項，同時又可以將模板中的通用共性內(nèi)容對用戶黑盒化。從而降低對方案編寫者的專業(yè)素養(yǎng)要求，一方面實現(xiàn)智能方案生成，另一方面幫助工作人員更專注于掌握核心的知識點。

圖8(a)展示了以應急演練方案為例的1個方案智能向?qū)Р襟E編輯器，它將方案分割為不同部分，對應不同步驟，每1步都包含多個知識點，點擊“編輯”，可進入知識點維護功能。比如點擊圖8(a)中序號2對應的步驟：“基礎信息”右側(cè)的“編輯”按鈕，就能出現(xiàn)圖8(b)所示的知識點管理界面，可針對“基礎信息”部分的所有單個知識點進行維護。圖9進一步展示了某個圖片型知識點的維護界面示例。不同的知識點類型，選擇操作的界面有所差異，其中，知識點的名稱和類型屬于通用要素，而向?qū)е凶詈诵牡膬?nèi)容在于“知識點向?qū)崾尽?，該信息將直接告知用戶某特定知識點究竟該如何準確合理地使用。

圖8 向?qū)Р襟E編輯示例Fig.8 An example of guide step editing

圖9 知識點編輯維護示例Fig.9 An example of knowledge points editing and maintenance

最后，在完成提取知識點、建立模板和編制向?qū)е?，還需要將業(yè)務類型、文檔模板、文檔模板中的標簽、知識點等相互關聯(lián)起來，才能真正為自動生成方案文檔提供相應的素材。圖10展示了進行關聯(lián)的界面示例，需要注意的是，有時模板中的知識點與系統(tǒng)中存儲的知識點并不完全一致，因此要仔細審閱關聯(lián)結(jié)果，以免出現(xiàn)錯誤關聯(lián)的情況，尤其是不能將名稱近似，但類型不同的知識點混淆關聯(lián)，這個可以在系統(tǒng)使用中加入一些防差錯的措施(如不允許不同類型的知識點相互關聯(lián)、出現(xiàn)同名知識點時進行提示等)來降低出錯概率。

圖10 知識點與模板關聯(lián)示例Fig.10 An example of knowledge points connecting with templates

2.5 應用模式設計

2.5.1 系統(tǒng)部署與使用

為了便于使用，系統(tǒng)采用B/S與C/S相結(jié)合的架構。部署主要考慮Server端的安裝(基于SQL Server)以及在所有用戶桌面系統(tǒng)中安裝MS Word插件以滿足編輯模板的需要(非認證用戶僅可瀏覽查詢部分經(jīng)過授權可獲取的知識，無需部署C端)。

系統(tǒng)操作分2部分。Browser端通過網(wǎng)絡瀏覽器打開，在用戶端不需安裝任何軟件包；Client端需要安裝MS Office Word及模板編輯工具插件，并通過Word自動打開。

2.5.2 分用戶模式

業(yè)務模板、方案向?qū)?、知識點全部設置完成后，對應的知識主體即實現(xiàn)了系統(tǒng)導入，不同級別的系統(tǒng)用戶可開展對應的應用業(yè)務。

1)系統(tǒng)管理員

該類用戶除了對用戶數(shù)據(jù)庫進行增刪改以外，還可以分配不同用戶對于不同知識主體的權限，允許其對業(yè)務模板、向?qū)А⒅R點等進行更新或僅是瀏覽。

2)知識管理員

該類用戶只能由資深業(yè)務專家擔任，其執(zhí)行的也是知識庫系統(tǒng)中最核心的操作，即定義知識主體的全部規(guī)則(比如演練方案的內(nèi)容構成、格式、知識點提取和編制向?qū)?，并定期進行更新維護，以保持知識庫與時俱進。

3)知識使用者

該類用戶是知識庫中數(shù)量最龐大、操作量最大、使用頻率最高的用戶群體。典型的應用操作包括：添加1個具體項目(如應急演練策劃)，為該項目添加參與的用戶(如演練策劃項目成員)，編制知識主體的具體實例(如利用模板和向?qū)Ь幹?份應急演練計劃方案)，維護項目信息及分享實施經(jīng)驗等。當然，也可以瀏覽與該項目涉及的知識主體相關的知識點信息。值得一提的是，當需要進行機構宣傳時，知識點瀏覽權限亦可開放給部分非認證用戶，這取決于管理策略。知識瀏覽者可以認為是臨時授權的最初級的知識使用者。

編制實例是該應急準備知識庫系統(tǒng)最具價值的應用環(huán)節(jié)，用戶按向?qū)л斎胫R主體的核心要素時，如果是數(shù)據(jù)字典型和預置型知識點，還可以根據(jù)向?qū)崾具M行更為精準的輸入。圖11展示了實例方案生成的樣式，用戶可以在向?qū)Ц鞔蟛襟E及相應子步驟之間進行切換填寫。

圖11 方案實例生成Fig.11 Plan sample generating

2.5.3 知識流轉(zhuǎn)業(yè)務邏輯

知識庫系統(tǒng)構建完成之后，可以不斷執(zhí)行圖12所示的知識流轉(zhuǎn)循環(huán)。該過程涵蓋了知識的提取輸入(一部分來源于新的外部輸入，另一部分來自于知識庫自我產(chǎn)出的反饋輸入)、知識的應用、知識的維護更新(包括知識的新增、修正和刪除)等主要業(yè)務。以演練方案為例，原始的、未經(jīng)知識庫系統(tǒng)處理的應急演練方案可以認為是一種應急管理“知識主體”，是知識庫系統(tǒng)的輸入；經(jīng)由知識庫系統(tǒng)的模板、智能向?qū)Ъ庸さ玫降膽毖菥毞桨讣词菓睖蕚渲R庫系統(tǒng)的輸出成果；經(jīng)過演練實踐檢驗和修正后的應急演練方案又是知識庫系統(tǒng)的反饋輸入，可用于知識內(nèi)容的積累、維護和迭代更新。這種更新可以使方案模板更加與時俱進或知識點更加豐富科學。

3 結(jié)論

1)定義了以“知識范疇-知識主體-知識點”為層級的應急準備知識層次架構。

2)結(jié)合知識管理流程，提出包含“輸入提取、存儲、維護更新、知識應用”在內(nèi)的應急準備知識庫系統(tǒng)定位。

3)歸納論述了由“用戶、知識內(nèi)容、使用場景、應用模式”所構成的應急準備知識庫“四要素設計法”。

4)針對知識加工輸出這一復雜需求，提出了以方案模板設計和智能向?qū)е谱鳛楹诵牡慕鉀Q方案。