[心得] 實驗：ML web app for general user

看板DataScience作者TreeMan (好啊...)時間6年前 (2018/10/04 14:46)推噓10(10推 0噓 6→)

留言16則, 5人參與討論串1/1

文長慎入如有問題或建議，請不吝提出感謝目前在規畫不同的預測分析應用 (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

推

sma1033

10/04 14:58, 6年前 , 1^F

10/04 14:58, 1^F

→

sma1033

10/04 14:59, 6年前 , 2^F

10/04 14:59, 2^F

推

sma1033

10/04 15:05, 6年前 , 3^F

10/04 15:05, 3^F

是的，主要是用起來的感覺 (記憶中的數字...hmm) 只有像文中提到長期測試的職業操盤手，才會問的很仔細但對於一次要賭到收盤，不適合他的操作習慣所以才真心希望出每分鐘版的XD 我還有接觸過印刷仲介業、電池電壓sensor廠商、遊戲公司(一般和博奕) 目前只有sensor廠有做過初步的分析 (因為沒label，所以只先試用kmeans) 他們的數據是從訊號分析開始的但至少有data 其它是知道"大數據"、"AI"，但不會想去用印刷傳產是數據都習慣記在腦中遊戲商有其它的考量，特別是博奕也許同業間開始廣為採用，他們才會想去用找到lead user就變成關鍵了