知識搜索，對於一個企業而言，目前無論是在對內管理還是對外服務的業務上，都有着大量的需求，並表現出急迫性的特徵。
例如，很多企業都積累了大量的企業知識資產，並且規模以每年200%的速度增長，其中80%以上的數據是以文件、郵件、圖片等非結構化數據的形式，存放於企業內計算機系統中的各個角落，並且這些數據的總量，遠遠超過了互聯網信息的總量，這些數據給整理帶來很大的難度。
又如，銀行各個部門擁有衆多IT系統，系統中存儲大量數據、信息，數據結構複雜，每個系統都擁有簡單的“數據庫檢索”功能，但常常出現找不到、找不準、找不全，速度慢等問題。
因此，如何讓不同領域的企業根據自身業務的需求，選擇相應的搜索模式，提升搜索效率，顯得尤爲迫切。本期圍繞“領域情報搜索”這一主題，分析現有的搜索場景，並結合當前我們的工作，從領域知識搜索的場景、知識搜索相關技術、知識搜索實踐中積累的思考等方面進行相關內容的介紹。
一、 領域知識搜索的場景
不同的領域對知識的搜索需求不同，但最終的目的都是做知識的整合、梳理、索引和管理，並在此基礎上提升客戶應答效率。下面從常見的搜索領域和搜索功能兩個方面介紹：
1、 常見搜索領域
1） 銀行保險等金融領域搜索
針對銀行業務、理財產品、保險的售前、售中以及售後環節提供垂直智能化服務支撐方案，面向客戶、服務人員以及代理人提供系統化智能服務方案，爲企業有效降低服務成本、強化組織管理、提升服務體驗。
2） 電子政務與法律領域
針對政府機構，對便民服務、市長熱線、來電辦理、問題督辦等場景在線智能處理，提供民衆自主辦理、快速響應。
3） 遊戲娛樂等消費領域
針對遊戲行業在註冊、宣傳、賬號管理等核心場景，提供專屬智能服務解決方案，面向廣大遊戲愛好者提供針對的方案，提供更好客戶體驗，有效提升客戶價值。
4） 教育培訓與醫療領域
將AI技術與教育行業深度集合，以師生服務、招生、教學保障爲核心場景，通過手機APP、互聯網等溝通渠道，爲教育企業有效降低服務和教學成本，提升教學質量並能更高效挖掘潛在數據價值。
2、 常見搜索場景
1）知識定位搜索
知識定位搜索，指的是針對用戶文檔中的信息進行查找和定位的一類搜索模式。例如，對於答案在文中有明確結果的，返回確切值；對於答案隱藏在段落中的，返回文章中的細節段落；對於答案在文章表格中的，返回經過事先解析好的文章表格內容和具體位置等信息。
從定位的數據類型來看，大致可將搜索分爲句子/段落/全文型、表格型和圖片型三種，圖片型是其中值得關注的一類。例如，金融領域許多研究報告、公告當中包含着大量記錄和反映數據指標的圖表，該圖表作爲檢索的對象，既可以方便寫作素材調取，也可以作爲文本聚合的重要參考依據。
圖1-基於報告的圖片搜索示意圖
2） 知識實證搜索
“實證搜索”是當前一種可信的搜索模式，與直接給出問題答案不同，要求在給定具體結果的同時，將答案的來源給出，這樣能夠提升用戶對知識的把控和鑑別能力。例如，“學跡”中的“學習來源”，就是對結構化答案的實證實踐。
圖2-基於實證的知識搜索示意圖
3） 知識結構化搜索
結構化搜索，又稱圖譜搜索，即一類以非大段文本和知識卡片形式進行知識問答的搜索模式，其特點是簡潔、明瞭和結構化，在谷歌上線知識圖譜問答以來，成爲了一個很火熱的方向。例如，下圖中以“生產口罩的公司”爲例，可以得到以下結構化數據：
圖3-結構化知識搜索示意圖
3、 知識搜索模式變遷
目前知識搜索先後經歷了傳統全文檢索模式、FAQ模式以及泛QA模式三種模式的變遷，三種方式對技術的要求也不斷增加，下圖中列舉了對應的優勢和劣勢。
圖4-知識搜索模式變遷示意圖
在實際的業務實施過程當中，我們常需要根據具體的問題，選擇相應特定的應答策略，這通常表現成一個多問題類型集成的泛QA模式，需要充分考慮搜索引擎、業務系統對接、搜索系統管理以及其他能力調用等模塊之間的協作。
圖5-泛QA知識搜索模式架構示意圖
二、 全文檢索範式下的場景搜索
全文檢索是當前我們所能看見最多的一類搜索方式，百度、谷歌、必應等搜索引擎，絕大多數服務都基於全文檢索實現。
1、關鍵技術
全文檢索通過在服務端預先對待搜索字段（如標題、正文等）進行分詞、倒排索引，在搜索端通過捕獲用戶搜索內容，利用搜索引擎（如solr, es）中內置的匹配排序算法（如BM25,TFIDF）進行排序，最終將結果返回給用戶，下圖展示了一個典型的全文檢索功能架構。
圖6-全文搜索架構示意圖
全文索引、搜索字符串擴展和搜索評分模型是全文檢索中三個核心模塊。
首先，全文索引的前提是整篇文檔都已經是純文本形式或處於可索引的狀態，因此，這就需要針對不同的文本如PDF、DOCX等文檔進行解析和轉換。
圖7-全文搜索文檔轉換與解析路線圖
在某些情況下，還涉及到表格的解析、段落的記錄以及圖片的分離等操作，如通過對錶格進行縱橫兩個方向的掃描組合方式，將表格中的數據轉換成可檢索和標引的數據類型。
圖8-全文搜索表格解析示意圖
其次，使用用戶原始字符串（或經過停用詞等處理）進行匹配，無法直接解決“同義不同形”的問題，即“召回率低”。構造同義詞庫配置、保留專有詞彙、可插拔的相似度算法，先全文候選後相似度二次計算是其中的兩個重要解決方式。
圖9-全文搜索內置引擎示意圖
最後，在搜索評分模式上，可以根據採用的搜索引擎框架，干預其評分模型，如ES中提供了更改評分函數的接口，可以根據實際的業務搜索需求，將其他評分因素加權到原有評分函數當中。
2、項目案例
金融領域的底稿管理是全文檢索方式的一個用武之地，例如，項目現場底稿數量繁多，撰寫材料所需數據分散，數據查找繁瑣，易遺漏，整理歸檔、材料查詢費時費力。爲此，進行紙質底稿電子化，方便數據整理、版本管理，可以讓數據查找更方便、更全面，節省用戶時間，下圖是該項目的實際搜索效果：
圖10-全文搜索項目上線運行截圖
三、 FAQ範式下的搜索
FAQ是英文Frequently Asked Questions的縮寫，中文意思就是“經常問到的問題”，或者更通俗地叫做“常見問題解答”，是較全文檢索信息進一步聚合、回覆進一步精確的搜索方式。
1、關鍵技術
FAQ實施的過程包括兩個核心點，即：問答對數據的構建和問題匹配評分模型。
其中，問答對的規模取決於具體的業務積累，在前期冷啓動環節中常需藉助業務專家標註，設定一些相關的標準問答對。
問題匹配負責將用戶的自然問句和問答庫中的問題進行匹配，找出最佳標準問，常見的方式包括基於es相似度，編輯距離等傳統方式，siamese孿生網絡、BERT-finetune等深度方式。此外，針對問題較爲複雜的場景，還常有問題分類這一前置任務。
問句壓縮，是FAQ模式的一個重要技術，由於FAQ的問題通常較短，用戶在提問的過程當中，往往會夾帶着一些主觀噪聲（即我們常說的口水句，如下圖），這會對實際的標準問匹配造成困擾。
圖11-FAQ口水句壓縮效果示意圖
針對這類問題，解決的方案包括基於語法樹分析與關鍵詞的規則方法以及基於文本摘要和句子壓縮的方法。前者通過標點或空格將長句分割成若干個短句，對短句進行口水句分類，然後基於概率和句法分析進行句子壓縮，儘可能剔除非必要成分，只留下關鍵詞、主謂賓等核心成分。後者的可用模型較多，從傳統的textrank到採用RNN、CNN等的深度學習模型，均可以生成相應的摘要效果。
此外，問題糾錯也是FQA（不限於FAQ，KBQA以及全文搜索範式都需要用到）的預處理流程之一。常見的解決方法包括字典+規則的糾錯以及基於神經網絡模型的糾錯兩種。
圖12-問題就錯技術路線示意圖
2、項目案例
針對該類的搜索，我們針對法律領域，完成了基於20W法務問答對的13類問題分類與法律資訊問答搜索系統，在問題分類步驟，達到了96%的準確率。
圖13-FAQ項目上線效果示意圖
四、 KBQA範式下的搜索
KBQA是針對結構化數據的一種直截了當的問答方式，可以根據設定的問題類型，通過問句解析的方式，形成若干三元組及相關的操作條件，並轉換成特定的查詢語句，直接返回相應結果，是當前一種較爲流行和新穎的搜索方式，但技術還較爲早期。
1、 關鍵技術
1） 意圖分析
意圖分析是KBQA範式下的第一步，其任務在於對用戶所提出的問題進行問題分類，因此又稱爲意圖分類。由於不同的問題所涉及的問題要素不一，後續所需進行的標籤識別、條件體與目標體識別也不同，意圖分類的準確性會影響整個後續環節的性能。
問題分類的方法主要包括基於學習和基於規則兩種方式。例如，在本文提及的FAQ法律問答當中，我們針對13類問題語料進行訓練，得到了基於學習型方法的問題分類，在缺少訓練語料時，基於關鍵詞和規則的問題方式往往成爲首選，下圖針對醫療知識問答中提出的幾類問題，給出了規則示例：
圖14-意圖分類中關鍵詞與規則示意圖
多意圖分類是問題解析中的一個難點，用戶往往會在一個問題中表達多種意圖，這時候，需要採用多分類模型對其中所涉及到意圖進行捕獲。
2） 標籤（實體、操作符）識別
標籤識別，是指識別出與目標數據庫中相關聯的實體、屬性、關係或操作符集合，也有人稱爲槽位識別。實體識別包括常見的機構、日期、金額、地點、人物等實體，職位、指標名稱等屬性關係。
包含操作符的回答是處理難度較大的一類，如我們會經常涉及到一些最高、最低、平均、總和、相差多少等問法，這種問題比確定性問題的解決方法要複雜一些，下圖列舉了一些常見的操作符示例。
圖15-標籤識別中的操作符示意圖
3） 條件體與目標體識別
在識別完特定的標籤之後，還需要在此基礎上形成可供查詢轉換的條件部分和目標部分。條件體，即在進行答案搜索過程中需要進行匹配的條件，如某個實體或標籤應該滿足的屬性值或關係類型（也常稱爲意圖槽填充）。目標體指具體需要返回的數據，通常包括某個實體或標籤、某個實體或標籤的屬性或關係、符合條件體的布爾型數據（是否存在這樣的數據）。
用於條件體和目標體識別的常用的方法包括基於問題模板和基於標籤依存兩種。
例如，在進行電影知識圖譜進行問答時，在識別出電影名稱、人物、角色等標籤後，可針對某一類問題，自定義識別模板。下圖給出了“演員導演作品”、“作品導演”、“導演自導自演的作品”三類問題的模板示例。
圖16-條件體與目標體識別模板示意圖
自定義模板映射的方式具有準確率較高，易維護和擴展的優點，但人工成本要求較多，同一個問題通常會有多種不同問法，在短時間內無法窮舉所有可能。
依存關係的引入，在一定程度上解決了這一難題，構建起所識別的標籤之間的父子關係，可對條件體和查詢體進行準確定位。我們爲此設計了一種標籤依存的識別方法：將實現識別好的標籤組成一張圖，並通過計算標籤與標籤之間的可能關聯，利用動態規劃的方法，找出標籤之間概率最大化的依存路徑。
圖17-數地工場問句標籤依存解析效果圖
上圖以“比亞迪的老總和董祕是誰”這一問題出發，通過識別出比亞迪（公司實體）、老總（職位關係）、董祕（職位關係）並進行統一標準化後，進一步形成 <Root,比亞迪>、<比亞迪，董事長>、<比亞迪，董事會祕書>兩個父子依存關聯，這種關聯關係在圖中清晰的展示，該接口已經上線到數地工場中，歡迎大家測試和使用。網址：https://nlp.datahorizon.cn
2）查詢語句生成
查詢語句生成是整個KBQA過程中的最後一步，通過問題意圖分析之後，得到了查詢體中的條件體和目標體，即可以通過模板轉換的方式，進行語句的映射和轉換。
當然，查詢語句的轉換要和目標數據庫相對齊，如下圖分別展示了以ES、Cypher、SPARQL三種目標數據查詢語句的生成方式。
圖18-面向ES,Neo4j,RDF的查詢語句生成過程圖
2、項目案例
1）KBQA-Neo4j組合的醫療知識問答
Neo4j是目前使用規模較大的一類圖數據庫，其具有多層關係存儲、路徑搜索推理等多項應用場景，並提供了人性化和語義化的查詢語句cypher。
本項目立足醫藥領域，以垂直型醫藥網站爲數據來源，以疾病爲核心，構建起一個包含7類規模爲4.4萬的知識實體，11類規模約30萬實體關係的知識圖譜。
該知識圖譜中記錄了關於診斷檢查項目、醫療科目、疾病、藥品、食物、在售藥品、疾病症狀等多項醫療實體，疾病常用藥品、宜喫食物、所需檢查、忌喫食物、推薦藥品、推薦食譜等實體屬性信息項，疾病名稱、簡介、病因、預防措施、治療週期、治療方式、治癒概率等關係信息，可以支撐關於這些信息項的問答服務。
該項目利用基於關鍵詞的方式完成問題分類，基於規則完成了問句解析和查詢語句轉換，以一種較爲簡易的方式提供了預設的問題回答服務，初步取得了一定的效果。
圖19-醫療知識圖譜問答過程與效果圖
3、KBQA-Mongo組合的軍事武器裝備知識圖譜問答
Mongo作爲一個文檔型數據庫，也是知識圖譜的一類重要存儲方式，基於構建好的mongo結構化數據，採用相同的前置問答解析方式，轉換成mongo的查詢語句，即可輸出相關結果。
我們通過對開源的軍事武器裝備數據進行整合、清洗和融合，建成了規模達到十萬的軍事武器信息三元組，共包括8大類、148小類的武器裝備。基於該武器裝備知識圖譜，提供一個基於模式和打標籤方式的問答系統。
值得注意的是，在該項目中，我們巧妙的藉助了jieba的詞性標註功能，快速地進行了相關實體的識別與解析，提供了用戶模板的配置接口，基於查詢模板完成多類問題的查詢，並展示了這一問答過程。
圖20-軍事知識圖譜問答過程與效果圖
4、KBQA-MySql組合的鋼鐵領域知識問答
同樣的，Mysql也是KBQA範式中常用的一個數據庫選型，傳統的mysql關係型數據庫廣泛適用於銀行、學校等信息系統當中。因此，在實施的環節中，只需要根據sql查詢語句，在sql生成的階段作相應的調整。
在項目上，我們研製了面向鋼鐵領域的一套自動問答系統，並構建了涵蓋多個交易所期貨的資訊數據、情緒數據和關聯指標數據庫，提供資訊類問答、情緒類問答、數據指標類問答三個方面的服務。
例如，對於問題“今天螺紋鋼有哪些利好資訊”，可通過對“螺紋鋼”進行期貨名稱識別、時間項識別與情緒項識別，形成搜索條件，完成搜索並以結果列表頁的方式進行返回；在問及某一期貨的情緒和關聯的指標時，可結合圖標可視化的方式加以表達。
該項目引入了對結果的可視化組織方式，以一種更爲鮮明、友好的方式加強用戶的搜索體驗。
圖21-鋼鐵領域知識問答過程與效果圖
五、 知識搜索的幾點思考
利用現有的知識抽取和知識搜索技術，的確可以在一定程度上滿足一些搜索場景的需求，但在具體搜索項目課題立項以及項目實施的過程中，依舊存在多個需要考慮的關鍵點、誤區和風險點。
1、實施關鍵點
1）明確搜索的對象：受衆，面向個人or面向統一平臺的，DIY式的搜索和大衆搜索所帶來的維護成本、開發成本時截然不同；
2）確定問題的邊界：有所問，有所不問。這個尤其重要，需要將用戶問題約束住，切勿脫離數據而設定問題，脫離現實技術而設定問題，以免預期落空；
3）根據問題找數據：需要根據預先調研和確定好的問題來構建相關的數據庫。如前面所提到的，若是走問答對的形式，則走問答對構建以及問句類型設計的路線；
若走全文檢索的路線，則需要根據所需檢索的字段確定搜索的單元，如針對文檔內部的搜索，常常需要將文檔的層級結構信息，段落、子段落、常句、表格、標題等進行有效索引；
若實施KBQA，則需要構建相應的結構化數據，並考慮多個不同結構化數據庫的存儲、通信、後續數據的接入問題。
4）關注搜索架構的魯棒性：一個成功的搜索系統，需要從搜索性能、搜索變更能力、搜索維護壓力、數據的標準化、外圍數據接入與通信方式等多個方面進行考慮，尤其是在系統升級的過程中，能夠做到快速、平穩的切換。
5）關注數據的安全性與更新機制：一個搜索系統，在上線運行之後，通常會處於一個不斷積累數據和功能擴充的狀態，涉及到數據的安全性問題，這個在銀行、涉密等多個環境下尤爲重要。
2、誤區與風險點
1）認識要冷靜：AI搜索助手沒不會那麼”AI”，大多時候會覺得它很“智障”，尤其是現在“神化知識圖譜”或“神化KBQA”的風氣不減的當下，更是要保持冷靜。
2）預期要實際：“深度學習”有所爲有所不能爲，需要大量的人工、規則、模板，動輒的“模型迭代”和“自我學習”在工業級場景大多很難實施，受到人力、算力、客戶忍耐度、維護等多方因素的制約，警惕將學術論文評測的做法引入到工業級落地當中。
3）人機結合是正道：選擇平穩、可靠的AI助手的最佳方式：靈活可配置的人工參與接口，可迭代升級，儘可能減少後期維護成本額，這樣才能省心、省人力。在整個項目實施上，可以小步快跑，步步迭代，切勿超之過急，先做好每個細分功能點
4）數據整合佔大塊：功能的設計、業務的梳理、數據的整理，佔據整個項目超過70%的時間。針對不同數據庫之間的搜索，需要花費大量的人工進行數據梳理；針對結構化查詢，需要準備大量的外部知識庫（業務詞典、同義詞詞典等）。
5）項目設立要慎重：在確定是否需要建設一個搜索系統之前，需要考慮當前的數據類型是否適合於搜索，自己當前的資源是否能夠支撐搜索代價，預設的數據架構是否能夠涵蓋後續的數據類型，不慎的話會影響後期維護和擴展。
六、 總結
不同的領域對知識的搜索需求不同，但最終的目的都是做的知識的整合、梳理、索引和管理，並在此基礎上提升客戶應答效率。本文結合我們團隊的工作，對知識搜索這一內容進行了相關的分析。
知識搜索，在銀行保險等金融領域、電子政務與法律領域、遊戲娛樂等消費領域、教育培訓與醫療領域上有大量搜索需求。
知識定位搜索、知識實證搜索以及知識結構化搜索是先有搜索服務的三種常見搜索場景，爲了支撐該搜索，常用的搜索範式包括基於全文檢索的、基於FAQ的，基於KBQA三種路線。
文本預處理以及全文匹配搜索評分是全文檢索的兩個核心點，我們在金融領域的底稿管理這一項目中進行了實踐，提升了底稿業務的效率；
問答對數據的構建、問題匹配評分模型、問題的壓縮、問題的糾錯是FAQ搜索範式的幾個關鍵點，我們以法律諮詢問答項目中對該技術進行了驗證和實踐，可快速地針對用戶問提給出準確答案；
KBQA搜索是面向結構化數據搜索的重要搜索範式，我們分別從醫療知識圖譜問答、軍事武器問答、鋼鐵領域知識問答三個項目出發，探索了圖數據庫、文檔數據庫、關係型數據庫的對接策略，提出了基於模版可靈活配置模式的標籤識別、標籤依存關係識別的方法，具有魯棒性的優點。
在具體搜索項目課題立項以及項目實施的過程中，存在着多個風險點和關鍵點，我們需要明確搜索的對象、確定問題的邊界、根據問題找策略、關注搜索架構的魯棒性、數據的安全性與更新機制，此外，還要充分保持冷靜、預期實際、承認人機結合的科學道路，並認識到前期數據整理和設計需要花費的代價。
參考鏈接
[1]https://xueji.zhiwenben.com
[2]https://nlp.zhiwenben.com
[3]https://liuhuanyong.github.io
[4]https://www.iwencai.com
[5]http://www.iwencai.com
[6]https://ask.shannonai.com
[7]https://www.bilibili.com/video/BV1Ub411H73G