在 B 公司有了 Relation Analysis 的幾個中間表後, 有了 "人=>商品", "商品=>人" 關係開始, 而我也搬家, 也在新家蓋了個瞭望台, 當事情 "想不開" 的時候就常去那邊沉思, 而幸運的我兩個大學教授當朋友, 一個教數學, 一個教統計, 我也常找他們來聊天及討論我的困境, 因此也想出了很多種演算法.

事實上第一個降冪的演算法就是在公車想的, 所以我常說, 做資料探戡不能上下班, 要 24小時不停的思考, 如同前面所說的, 一些點子或創意是隨時都會發生, 所以要 24 小時準備, 因為連作夢也會想到解法的經驗是不只一次.
但上一篇所說的關聯購買事實上是 Amazon 已經在用的演算法, 而 Amazon 是一個鄉當龐大的一間公司, 資料也相當旁大, 就如同我說的資料探勘是一個須要大量資料的架構, 因此要挑戰的是如何從不是那麼多的資料找出個可能計算出有用的可行性.

而當時規劃了幾個方向: 薦購, 回購, 必買不可等等的幾種可能的演算法, 再加上若是有問卷之後, 能夠玩的就更多了, 就可以有 "首購推薦" 的實現, 但這都是架構在前幾種的成功.

事實上最早開發來的是薦購, 但這個因為種種的執行面的不可, 最後第一個實現的是一個非常態性的專案: "必買不可"..

這個是一個 "人=>商品/商品=>人/人=>商品" 的三階展開的演算法, 先算出人與人的關係, 然後從這個常態的資訊去整理出歷史資料的展開後再收斂一次, 雖然這演算法看起來繁複, 但相當單純, 相較於人際關係的競爭, 系統的開發就顯得簡單多了.

雖然人心是複雜的, 但行為還是有模式可循的, 加上我們又不是要算出所有人的所有行為, 而是會來這網站的購買行為, 且人的購買是單純的, 公司內的政治與競爭是複雜的, 只是這個必買不可的實現也是靠同事的幫忙才能實現, 畢竟資料探勘在國內還是個不受接受的系統, 有時是喊口號的人多, 做假的人多, 真的要做的話, 要投入人力
與物力又縮回去了.

拉回來必買不可, 必買不可是個可以算出一個人購買的精確演算法, 由於這是一個收斂相當大的演算法, 因此變化相當少, 不見得是一個很好好實用的演算法, 但做一個非常態的 Event 活動, 倒是不錯的實作.

不然下次我們聊聊若是合理的話, 資料探勘須要多少人來投入好了.