2010-03-12 81 views
1

我有一個相當小的結構化記錄坐落在數據庫中的語料庫。給定一條記錄中包含的一小部分信息,通過一個Web表單提交(與表格模式的結構相同)(我們稱之爲測試記錄),我需要快速繪製一份記錄最有可能與測試記錄匹配,並提供關於搜索條件與記錄匹配程度的信心估計。此搜索的主要目的是發現是否有人試圖輸入與語料庫中的記錄重複的記錄。有一個合理的機會,測試記錄將是一個愚蠢的,並有一個合理的機會,測試記錄不會是一個騙局。結構化數據的模糊匹配

記錄大約12000字節寬,記錄總數約爲150,000。表格模式中有110列,95%的搜索將位於最常見搜索列的前5%。

這些數據就像名字,地址,電話號碼和其他行業特定的數字。在語料庫和測試記錄中,它都是手動輸入的,並且在一個單獨的字段中是半結構化的。你可能會在第一時間說「用手來加重列數並匹配它們中的單詞標記」,但這並不容易。我也這麼認爲:如果我得到一個電話號碼,我認爲這將表明一個完美的匹配。問題在於,表單中沒有單個字段的標記頻率不會按數量級變化。電話號碼可能在語料庫中出現100次,或在語料庫中出現1次。其他領域也是如此。這使得在現場級別上的權重不切實際。我需要更細緻的方法來獲得體面的匹配。

我最初的計劃是創建散列哈希,最高級別是字段名。然後,我將從語料庫中爲給定字段選擇所有信息,嘗試清理其中包含的數據,並標記處理過的數據,在第二級對令牌進行散列處理,使用令牌作爲鍵和頻率作爲值。

我將使用頻率計數作爲權重:參考語料庫中令牌的頻率越高,如果在測試記錄中找到該令牌,則附加到該令牌的權重越小。

我的第一個問題是房間裏的統計員:我怎麼會把頻率當做體重?在n,記錄數,f(t),記號t出現在語料庫中的頻率,記錄是原始記錄而不是重複記錄的概率,以及概率p是否存在精確的數學關係測試記錄實際上是記錄x給定的測試,並且x在同一個字段中包含相同的t?跨多個字段的多個令牌匹配關係如何?

既然我真的懷疑存在,有沒有什麼能讓我接近,但比一個完全武斷的黑客充滿魔力因素更好?

除了這個,有沒有人有辦法做到這一點?

我尤其熱衷於不涉及維護數據庫中另一個表(如令牌頻率查找表)的其他建議。

回答

0

您或許可以從這個不同但相似的SO問題中獲得一些想法: calculating-context-sensitive-text-correlation

更具體手頭的問題,這裏有一些想法和意見:

首先,承認了非常傾斜的使用(只有6到10個屬性覆蓋使用的95%),可以/應該在屬性上應用不對稱的努力,即在編程時間和運行時CPU分配方面投入更多,用於處理這些少數屬性而不是100多個附加屬性。

提供的數據量相對較小,用於匹配數據庫中可能的重複項,通常使用的相對較小的一組屬性以及這些(電話號碼,地址,名稱......)的明顯通用語義表明基於機器學習的手工解決方案而不是完全的

注意:之後的很多建議都不需要應用到所有的屬性上(因爲其中幾乎涵蓋了所有的用法,沒有任何意義,至少在一開始就與其他用戶進行了大量投資屬性。

  • 規範化數據
    如果不允許你改變原來的字段值可能複製相應的列到「norm_xxx」 coluumn其中xxx是原來的名稱。
    什麼,怎麼標準化可能隨着每個屬性而變化;對於像數據那樣的「自由文本」,確保沒有前導空格或尾隨空格,單詞之間只有一個空格s,沒有標籤和不可打印的字符。使用全部大寫字母或全部小寫字母(事件原始/顯示文本可能包含混合,通過假設統一套管,處理速度會更快)。更具體地說,對於地址和/或公司名稱,您可以將常用術語轉換爲標準格式(ST用於STREET,ST和ST等)(請務必保留此列表以應用於用戶搜索條件)。標準化的一部分也可能是完全丟掉一些噪音字(如CO,INC,GMBH在公司名稱末尾)
  • 創建幾個計算列
    例如,對於屬性可以用尾隨通配符搜索
  • 考慮對某些屬性使用類似Soundex的轉換。
  • 全文索引,單獨地,所有文本狀柱
  • 創建上的所有6〜10多使用的列用於實際

所有上述,僅僅是離線時間製劑平原(SQL)索引表演比賽。現在..用戶輸入他/她的查詢......這裏是關於如何對付它的一些想法

  • 歸其保證它
  • 運行多個搜索的搜索條件...
    這是有點棘手;執行這些搜索有幾個部分衝突的目標。我們希望大大減少「潛在匹配」的數量:用用戶提供的標準對所有150,000條記錄進行完整的一對一比較是不切實際的;例如,某些匹配邏輯可能意味着計算數據庫的給定記錄的字段與搜索條件之間的編輯距離。我們還希望確保我們不會因爲在公司名稱中輸入錯字而排除「潛在匹配」列表中的記錄......最後,我們希望以排名方式提供潛在匹配列表。
    執行這些搜索的方式遵循一些預先定義的啓發式方法(我發現策略設計模式對此非常有效,允許運行搜索的靈活性取決於用戶提供的輸入)。簡而言之,我們在最具選擇性/相關屬性中搜索最具選擇性的單詞,並根據發現的「匹配」數量,我們或者與其他搜索結果進行「或」(聯合)或「與」,直到我們有幾個百項紀錄。
  • 計算「潛在匹配」記錄的每個屬性與相應搜索條件之間的相似度值。可能對這個值應用一個係數(允許更多的權重來表示一個公司名稱[部分]與城市匹配相匹配)
  • 記錄完整記錄的整體相似度值(與完整搜索條件相比)
  • 顯示記錄超過相似性值提供給最終用戶的特定的閾值,以供審覈

    最後,總會有一個部分自動的過程中,可以改變基於由端提供一些反饋的一些參數-用戶。 (這是非常棘手的事情,我會保留這個爲其他職位;-))

+0

感謝您的想法和更多的研究的鏈接。我可能最終計算編輯距離,或者不是,我無法確定。但是我認爲我會將記號匹配記爲1/f(t)*字段權重,並且在計算編輯距離之前查看距離我有多近。 – masonk 2010-03-12 20:29:53