推 sma1033: 對於股市預測的應用來說，我想大多數人都是只想要快速的 10/04 14:58
→ sma1033: 知道是不是拿來賺錢而已(當然是不太可能啦...) 10/04 14:59
推 sma1033: 我猜一般人應賅沒興趣知道背後複雜的模型或是理論啥的(?) 10/04 15:05
推 dishuman: 感謝分享 10/05 09:32
文長慎入
如有問題或建議，請不吝提出 感謝
目前在規畫不同的預測分析應用 (e,g 旅遊景點人擠人指數預測XD)
語言將改用python，看看比起R + shiny，在架web app上會不會更好
----------------------------------------
實驗目標：
利用機器學習(ML)或資料探勘的工具，提供一般user會有興趣的預測分析
同時讓使用者可以自己上傳自有資料，改良模型的預測效果
本次實驗完後，未來改進要點：
1. 更輕量的應用
2. 除非有產生data的配套，否則不再搭配自建模功能
----------以下是本次實驗的說明----------
一、結果與討論：
結果：預測股票市場隔日大盤收盤價為目標的web app，功能如下
簡化版 (無線上ML功能)：https://goo.gl/6vyiDj
完整版：https://goo.gl/i7L8sG (帳密為mmtest001)
預測分析：藉由web app的形式，讓使用者可以在股市開盤前
看到下一個交易日台灣加權指數/台指期的預測值
半自動化建模：使用者上傳的資料，將經過簡易的前處理/特徵工程
再混合選定的母系統的資料集，以半自動的方式重新產生預測值
圖書館：將歷史資料圖形化後，供使用者參考
自8/12分享app連結於stock板後，累計至10/3約53天
1. 817個使用者點選過簡化版app (無建模功能，但如有詢問，就提供帳號密碼)
93.3%來自台灣，6.7%來自美國、日本、加拿大等
2. 4個使用者使用過完整版app，1個成功產生更好的預測
3. 簡化版使用者計數來自Google Analytics，完整版來自信件詢問人數
討論：
1. 原本選擇股市預測是直覺投資人應該會收集歷史資料 來進行分析
因此設計此app多提供一個讓他們量化分析的工具
然而結果只有不到1%的人有資料有興趣嘗試
初始分開app也似乎不是這麼需要了 (本來要要比較好控制server資源)
2. 測試組：數值預測誤差60點，漲跌預測準確度65%
其中一位有長期試用建模功能的user
其最後數值預測誤差60點，但漲跌預測準確度上升到74%
3. 有些user表示預測值，對資料圖書館也沒有興趣
這些user通常為輕量型投資人 (一年可能買個幾張，而且快速脫手)
4. 前3天新user就有728位，後續增加速度非常緩慢，且會回來看的人也少
近一個月多維持在2-3人/天
分析可能原因：
4-1. 手機觀看是個悲劇 (e.g. 互動式圖表，讓user不好滑螢幕)
4-2. 一開始server資源設定給簡易版不足，很多人連不上去或看不到
4-3. loading時間太長 (肇因於首頁的一個plot的程式沒寫好)
4-4. Chrome loading時間比IE多快1倍...?
4-5. 無中文化
4-6. 預測無用或與使用者需求不符
關於4-6. 在與完整版user訪談時，有2位都表示
強力需要台指期每分鐘或per tick (成交一筆？) 的預測
給後續有興趣開發的人參考
5. 參加比賽後的晚宴，裡面有投信的量化投資研究員
他們表示也在嘗試將ML用在量化投資上，但多使用較為基本的演算法
deep learning一是沒有提高太多的表現
二是無法說明，對於主管要aprrove蠻困難的
二、資料來源與爬蟲
1. 本國指數/個股資料：證交所、期交所、櫃買中心
2. 國外指數：yahoo, investing.com
3. 其它：google trend
4. 爬蟲：依據網站，用R的XML, jsonlite, rvest, httr組合而成
三、使用工具：
語言：R
web app & server：shiny.io
自動化建模功能：基於H2O package的autoML功能，修改成可多人同時使用
plot：plotly, highcharter(付費), ggplot
四、資料處理與H2O建模設定細節
1. 國內的資料比較沒問題，唯一要注意的是台指期月中會結算
例如你正在爬的資料最近月是9月，假設9月15日結算，隔日最近月變10月
那你結算隔天收盤價就不能用9/15的9月期指，而是9/15的10月期指收盤價
此外，雖然我每個query都間隔5-17秒，大項目完成間隔30-60秒
後來還是會被ban ip，對於要持續更新模型是一個麻煩
2. 國外的很容易有錯誤或單位誤載，必須先人工抽樣檢查
或者與其它網站的數值抽樣交叉比對
此外，交易量有時台灣開盤前會無法結算出來
或者交易量是最後一筆交易量，而不是當天全部的交易量
要改良這點，以國外期貨來說，可以去芝交所爬結算前的交易量
最後，是國內放假，國外仍有開盤的狀況下
建資料集時要確認數值沒有錯位的問題
沒使用quantmod：資料會有錯，特別是在近期的資料
3. 主要用的特徵值
3-1: 前天收盤價的漲跌幅
3-2: 前天收盤價相對近期(20, 60, 120交易日)收盤價中位數的百分比
交易量的部分，如前所述，常在預測當天會是missing value
因此無載入相關特徵
4. 建模資料集依時間拆成三部分，從資料起始時間到現在約2800筆
testing set: 最近期150筆
validation set: testing set後450筆
training set: 剩下的2200筆
5. 使用H2O的autoML的GBM演算法建模
在web app版本中，有限制建模時間為10分鐘，使用者上傳資料容量上限10MB
同時在每次建模時，會重新連線到H2O，否則有時會有bug而無法更新模型
但也失去其原本設定的記憶功能
6. 在模型準確度的監控上，我嘗試使用SCHILLING的
length of the longest success run
假設模型測試組準確度為65% = 0.65
失誤率p = 1-0.65 = 0.35
q = 1-p
在近n天的模型表現可產生一個eq: nqp^L = 1
將前面的數值代入可解得L，我把它叫做length of the longest faliure run
前提是nq >> 1 (tricky...hmm) 我讓n = 20
去產生目前準確度允許最大的連續失敗次數
如果實際連續失敗次數大於L時，就去檢討模型有何問題
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.173.77.253
※ 文章網址: https://www.ptt.cc/bbs/DataScience/M.1538635614.A.08E.html