智能語義搜尋 - 徐海蛟

徐海蛟 教學用途

概念：

語義搜尋，指更加智能的搜尋引擎，這是所有搜尋引擎的一緻目标。它代表支援使用者表達複雜的查詢需求，精确定位并給出答案。Rudi Studer (RS)認為：We look at semantic search as a process of information access, where one or several activities can be supported by semantic technologies. These activities include preprocessing and extraction of information, the interpretation of user information needs, the actual query processing, the presentation of results, and finally, the processing of user feedback for subsequent queries and to generate improved refinements。即語義搜尋可以分為:資訊預處理和資訊抽取, 使用者資訊需求的結實,真正的查詢處理,結果表示和使用者回報及優化處理.

語義搜尋的概念在Semantic Web之前就已經出現。搜尋引擎的核心技術是資訊檢索(Information Retrieval)，這最早在digital library中得到應用，并且在早期的搜尋中主要使用基于邏輯表示的boolean比對。在近年中，随着自然語言技術的成熟以及現有syntax-based技術的缺陷，在一些企業搜尋應用(如IBM)或者站點搜尋(如Wikipedia, Freebase)甚至垂直搜尋(如專家搜尋，機票搜尋等)中，語義技術(不僅僅局限于Semantic Web technology)被越來越多的提到和應用。PowerSet被稱為成功的semantic search engine (主要基于自然語言處理的)，于2008年5月被微軟高價收購。

語義搜尋包含很多内容，即使是semantic web search也有很多步驟運用不同的語義技術，是以說語義搜尋走不下去未免過于絕對。同時我認為現階段的semantic search肯定不是基于NLP的，而應該是考慮如何最大限度地利用meta data，那麼就涉及到如何exploit或者leverage這些graph-based data，會有新的ranking問題，有新的更scalable的圖周遊算法等産生，甚至對search的整體infrastructure進行修改。拿Google作例子，可能會對GFS, Bigtable, Map-reduce等進行必要的修改和擴充。是以我覺得結構發現和比對是關鍵。你不可能讓使用者是指定SPARQL或者指定其中包含的結構，但是不代表semantic search不要利用這些資源或者資訊。

類似Google找"~fast food", 傳回 Burger King， Taco Bell，... 隻要搜尋中有語義比對，都能算語義搜尋; 搞語義網的人會說用了ontology來完成語義比對和查找的是語義搜尋; 看過Microsoft Research Asia有幾篇論文關于《Object level Vertical Search》就是不以頁面為機關而以頁面中的元素即object為機關并為這些objects建立relation來完成object級的搜尋，他們也說這是語義搜尋。

很多基于metadata的語義搜尋引擎原型也被提出，其中包括Yahoo的microsearch和searchMonkey等。我覺得Semantic Web的出現使得語義搜尋更加流行也更加受到關注（但同時也使得semantic search這個詞更加具有歧義了）。最大的問題是如何快速有效地進行推理和檢索，畢竟使用者最關心的是檢索結果，而不關心如何實作。語義搜尋引擎天生就比普通搜尋引擎多出一個推理子產品，自然會降低檢索速度。為了做到有效的推理，知識庫又需要足夠完整。目前已有的幾種語義搜尋引擎中，有一些落眼就能看到明顯的缺陷，足見這個領域仍處于起步階段。

主流搜尋引擎采用某些算法來實作語義分析功能，形成了“使用算法進行檢索排序=利用本體進行語義分析”的應用效果格局。關于搜尋和推理，其實目标都是一緻的，最終得到的結果，都是傳回使用者所期望的資料。Kaon2上的幾個執行個體是值得實踐的。要結合常用的關系資料庫進行推理，從技術上講，也還是可行的，最起碼本體的解析過程會提速很多！Kaon2的做法是采用了虛本體的方式，與資料庫建立映射關系。另外WSMO的那一幫人搞了一套東西，叫做加載推理（翻譯有問題的話，回頭再講），通過把檢索語句（面向某個本體，支援合取檢索，Datalog，SPARQL）/本體/本體之間的映射關系/本體與本地資料源模式之間的映射關系，共同加載到推理機中，通過邏輯推理（還有一些LP邏輯程式設計的東西），一次性的完成檢索任務，感覺很不錯！遺憾的是，沒有看到最終可用的系統！

隻有具備自主分析推理能力的搜尋引擎才是真正的語義搜尋引擎，換句話說就是它必須具備類似于知識庫和推理引擎這樣的用于分析其接觸的内容的基礎架構。故而可以把語義搜尋引擎僅分為廣義和狹義語義搜尋。

傳統算法與本體語義分析在使用效果上基本等同？

目前，所熟知的推理引擎對某一種或幾種本體查詢語言提供了支援。從其算法思想來看，它們之間的關系類似理論和實踐的關系：推理引擎提出了一種語義推理的思想和方法，而操作則需要通過具體的查詢語言和本體庫作為“工具”。試想一下，不過一個隻能空想不能做的“推理引擎”，如何實作？從另外一層面來看：1）不通過推理引擎，SPARQL是否可以執行呢？目前，大多數推理引擎均不支援完整的SPARQL文法，但網上有一些SPARQL線上執行的例子卻可以完整的支援。那麼是否可以得出結論，檢索語言和推理引擎并不需要配套使用。事實上，查詢語言是否可以脫離推理引擎而使用的。SQL也同樣可以，是以才有了利用資料庫漏洞執行SQL進行爆庫的攻擊方式，而且有專門為SQL開發的執行器；2）通過推理引擎，SPARQL獲得了那方面的支援那？換句話說，和不加載推理引擎所完成的檢索在結果集上有什麼差別那？支援那種查詢語言事實上隻是出于效能、相容性以及使用者的使用習慣等因素考慮。

SPARQL是一種針對本體模式的查詢語言是以，可以下結論上述所說的所有的推理能力（也就是對RULE的處理能力）他都不具備，看下面的說法 （Pellet supports SPARQL, which will allow you to make ontology queries. However, SPARQL is an RDF-based query language and has no understanding of OWL. It will, however, work with OWL if you have very simple queries. I'm not sure how it will interact with SWRL though. SPARQL can express RDF queries and will work with OWL in some circumstances. However, its lack of understanding of OWL's semantics can make it incredibly difficult to write many OWL queries.）當然，SPARQL和SQL還是有差別的。資料量的大小會影響最終查詢結果的品質。但資料量很小時，本體查詢和資料庫查詢的差別就不是那麼明顯了。這其中設計另外一個很重要的因素，那就是資料之間語義關系的複雜程度。

實作基于RDB的語義查詢，途徑之一便是可以對RDB上的SQL查詢進行擴充，将一個SQL查詢轉換成多個查詢加以執行，稱之為OntoQE（Ontology_based Query Expansion）。但這種查詢擴充隻能利用資料之間同義、上下位等簡單關系，并且這種查詢擴充在提高了查全率的同時，極有可能降低查準率。

語義搜尋若完全依靠本體庫進行推理實作語義查詢，在目前知識庫不是很完備的情況下，反而在一定程度上降低了查全率！譬如假定對于用于輸入的查詢，如果在知識庫中沒有找到對應的本體執行個體，那麼查詢結果為零，而如果直接利用關鍵字在文檔中搜尋反而可能得到查詢結果。是以為了平衡因知識庫不完備而導緻的查全率下降的情況，可以把傳統的關鍵字檢索加入進來，作為語義搜尋的一個重要補充手段。是以即使設計出來的關系模式很完善，但基于其上的推理能力（不管這種推理是直接實作還是間接實作）還是比較有限，對于OWL中定義的一些複雜語義關系，SQL似乎無能為力，而推理應該是語義查詢很重要的一個方面。

自然語言搜尋是資訊搜尋的極緻，但這不是一蹴而就的。同時，它還會必然增加我們對“語義搜尋引擎”的研究和測度範圍。而且事實上這種搜尋引擎幾乎可以說相當于傳統搜尋引擎的分詞與同義詞表加強版，某種角度講和我們平時所說的“語義搜尋引擎”有很大不同。重要的是如果将其劃入“語義搜尋”範疇，可能要改變我們一直遵從的語義網和語義搜尋的認知。部分傳統搜尋引擎也将因其采用一些有利于自然語言分析的算法和新型檢索政策增強使用者體驗來達到接近語義分析的效果。這種情況下，我們是把它們也算作“語義”搜尋還是“非語義”搜尋呢？

本體與資料庫如SQL SERVER如何實作語義檢索

用傳統搜尋引擎的某些算法好像也能在一定程度上達到語義分析類似的效果。例如，在《Sesame：A Generic Architecture for Storing and Querying RDF and RDFS》一文中，提出了将RDF（S）轉換為關系模式存儲的政策。設計合理的關系模式存儲RDF(S)，那麼可以基于使用者的普通SQL查詢，構造出複雜的SQL查詢（構造過程中包含了簡單的語義推理：如subClassof、subPropertyOf關系等），進而也就可以實作基于關系資料庫的語義查詢了。不過，為了達到語義檢索的效果，還需要加入專門的語義分析及推理子產品，這本身就會降低檢索效率，使檢索結果不能馬上傳回。而且，進階複雜的推理還需要大量的工作。問題遠遠不僅僅這些，還會面臨海量資料無法迅速分析和操作的問題，以及結果的回報問題。機器加程式分析真的能夠和絕大多數人的想法完全重合嗎？這就需要知識表達，既要符合人類的思維，又要便于計算機的表達與推理。資料挖掘的算法也是為了發現關系.而語義網則是顯示表示和處理關系.是以資料挖掘的确能達到語義搜尋的效果.但精确度肯定是不夠的.資料挖掘一般都需要有一個資料模型.是以如果語義網的确定模型應用到資料挖掘中可能會有意想不到的效果。

Oracle資料庫，到目前為止，還沒有做資料異構和資料挖掘！先前，RDF存儲是期望利用關系資料庫在語義檢索和本體提取這方面的功能的。關系資料庫的查詢優化到底在語義查詢中可以做點什麼呢？

本體庫存儲到關系資料庫之後是無法直接用SQL查詢的，隻能通過本體庫編輯工具。本體持久化，通俗地說就是将本體資料用資料庫儲存，以增強檢索效能。為大量本體檔案提供高效檢索和管理管道。是以，設計合理的關系模式存儲RDF(S)，那麼可以基于使用者的普通SQL查詢，構造出複雜的SQL查詢（構造過程中包含了簡單的語義推理：如subClassof、subPropertyOf關系等），進而也就可以實作基于關系資料庫的語義查詢了！

如何提取有效的URL，即資訊提取器的選擇，普通的資訊提取器恐怕難以勝任針對語義網絡的資訊抽取，隻能使用特别用于語義網的。這裡面還包括如何使資訊提取器提供有效的URL以友善資訊抽取。

這裡的“資訊提取器”是這類工具的統稱，也可以稱作“爬蟲”、“蜘蛛”或“機器人”，例如，知識工程研究室隸屬清華大學計算機科學與技術系軟體所開發的《中文新聞關鍵詞抽取系統》，就是這樣一種工具。語義搜尋技術無非是對海量的資訊用計算機進行高等級的序化，如果沒有這種工具，隻能由人工添加記錄，就會變成傳統的網絡目錄了。

其實，語義化的知識要進行語義化的查詢還是有路子可循的。目前針對于此的研究重點有：一是如何抽取語義資訊；二是在于如何将查詢語義化，例如将自然語言查詢轉換為SPARQL查詢。自然語言查詢轉化，與此同時，搜尋内容的處理也同樣不能忽視。否則搜尋什麼東西呢？對搜尋内容也要進行統一整理，進行語義化的。三是将語義查詢結果生成自然語言文本。