上一篇的重點, 就是說我們要做行為預測與輔助, 一定要在下一個行為發生前計算出足以提供參考的資訊, 當然無論就人或者是事或物, 就要看其關係的量及這兩物件的量, 以及這關係的變動量, 所以要在會在變動之前算完一遍, 這對效能調校是一個很嚴刻的挑戰, 但與其說是挑戰還不如說是 "須求" 的必要.

但大家知道系統調校中, 能夠影響只有 30%~300%, 也就是 3 倍就算是很不錯了 (當然是指機器等級差不多), 而上一篇講到要提升 1 萬倍的話, 提升的效率的方向有幾種:

1. 在設計這系統時, 就要考慮到系統的可行性, 此時要找出目前已經有的資訊以及能夠提供甚麼樣的資訊, 而在系統可行的量級內來設計, 這也是為甚麼我常說, 資料探勘最大的門坎是設計出可行系統的企業智慧 (Business Intelligence), 也就是要了解技術的系統分析及商業邏輯與語言, 這對大部份的人也是須要很大的挑戰.

2. 無論是機器的設備調校與購買使用, 到系統程式的系統調校與管理, 要了解程式與演算法跟系統與設備的搭配, 這是一個範圍相當廣的知識須求, 而你每多知道一個環節的角色, 就會多知道一個可以提高效率的著力點, 知道的越深, 能夠提升的程度也越多, 最後這些會化成經驗與能力, 所以我也說 Data Mining 是一個很須要經驗輔助的, 因為你要知道那些點是可行的, 這要經過相當的學習與實作才行的.

3. 決勝點是演算法: 當然系統與程式的調校好壞, 頂多 3~30 倍, 但演算法的改善往往是以 10 倍為單位的, 所以最好本身對數值方法, 代數與離散, 統計, 工程數學, ... 等等數學工具都有足夠的了解, 當然我常常說, 設計一個系統有時更須要的是沉浸在其中, 不能分上下班, 更須要連睡夢中都用上, 就像是我有幾次的演算法都是在睡覺時想到的, 這靈感不是從天而降, 而是你必須隨時隨地都在準備, 才能夠到時如天雷勾動地火一樣一發不可收拾 (用錯形容方式了), 就像是有人是在洗澡看到浴缸的水時才想到解法, 但事實上他是在洗澡時都在想, 不然就不會連結起來了.

4. 程式設計與 DBA 的必要: 當然資料探勘最後的實作就是用程式去算資料, 而我也說演算法書上都有, 只要有一定程度的人不會寫不出來, 但要弄到如前言所說的可以用的效率提升, 實作的程式設計與資料庫設計人員是最基本的, 而有時不能期待這些人去想效率, 因為大部份的 Programmer 與 DBA 在大部份的 SI 下, 已經被訓練成 "很快可以寫出能用的東西", 而不是去寫 "可以很快執行的東西", 尤其是這兩個往往剛好是兩個很難共存的狀況下, 往往有一就不會有二, 所以甚至我常常懷疑 Data Mining 的 Programmer 與 DBA 是必須專業的.

當然上面幾點都可以用人力, 物力, 財力去解決一些點, 只是有時真的要找問題的答案是相當不簡單的, 而這個問題的答案若是沒找出解決方法, 幾乎是完全沒有實用性了, 甚至是失敗了, 這跟很多專案不一樣, Data Mining 若要驗收, 不是在於寫不寫得出來, 也不是在於有沒有用, 因為這個在一開始設計就決定了, 出問題的話在於規劃的人, 而要驗收外包的人, 唯一的檢核點就是 "效率"... 因為這才是最困難的地方阿.