---
# System prepended metadata

title: darcy-sinopac

---

# darcy-sinopac


## 法金綠能
* [Solar irradiance forecasting using a ground-based sky imager developed at UC San Diego](https://hackmd.io/hNLrKdvgTieK6tfo8weBbA)
* [Metadata-Augmented Neural Networks for Cross-Location Solar Irradiation Prediction from Satellite Images](https://hackmd.io/K7_UqB0bSoqCnOlroKILiw)
* 11/4 慧景:
    1. 客戶用監控廠商要用哪一家
    2. 匯景的資料: 很完整
        *  PR: 會和溫度有關，溫度修正PR是在25度以下的PR
        *  輸出功率: 直流轉交流
        *  交流電流的三相: A, B, C
        *  輻射量=日照量: 一個電廠可能不只一支(會有不同角度)。是一個連續的面積概念(積分)
        *  台電的紙本電表: 客戶自己填，轉換成Excel表格
            *  輸出電量: 電廠發電送回台電
            *  輸入電量: 台電提供的電給電廠設備運轉
            
    3. AI 學遮蔭: 
        * 異常的電流電壓的曲線，專家判斷、詢問客戶，並標註是不是遮蔭
        * 客戶有可能部回報(覺得差一點沒差)
    4. 發電異常的因素
        * 逆變器(inverter)降載: 過熱、偵測到不穩定的電壓電流、風扇壞掉
        * 遮蔭: 電流電壓起不來
        * 髒污: PR值偏低
    5. 模擬系統: PV6(不確定是不是這個名字)，會不準，因為只有考慮到緯度和太陽方位角，沒考慮到天氣=> 改用paper的
    6. 希望不同的監控系統能收到相同的資料(先以慧景為主)
    7. 慧景的database: 兩個，一個裝raw data，一個裝aggregated data
* 法金財務模型:
    * 需要更精準的區域平均輻射量(現在是每個縣市一個值)
    * 成本很高，預估每年發電樹很低=>IR低
    * 需要的資料：維運成本、建置成本、預估IR

* 11/19 iPvita
1. 監控系統之後會變成免費、租賃(一年3000元)
2. 產品：Power plan service （不做模組了）
3. 大型電廠不會用雲端（用雲端是什麼意思？）
4. 衛星雲圖可能不太準
5. 預測明年可以發多少電是騙人的
6. 監控系統的主要廠商：中華電信、友達、我們
7. PR值是現在業界的規範
8. 轉換效率：AC/DC
9. 模組耗損率好像不重要：因為很難衡量（和用量有關，太操會容易耗損）
10. 雲端平台、資料庫、大數據平台是自己的軟硬體和雲端主機（不是GCP之類的）
11. query data 需要費用
12. 可以提供的資訊： 日照、 PR, 統計發電量, event alarm（有把原因記起來）, raw data(一分鐘收一次，只存一年，建議先用處理好的一小時一次)、電廠大略位置
13. Devices: iPVBox、日照計、監控相、dashboard
14. 預期發電程度是沒有意義的


### 票據辨識
1. 沒有"元整"的共53張(train 42張， test 11張)，建classifier
    (reference: https://towardsdatascience.com/deep-few-shot-anomaly-detection-b33f130d1f80)
- [x] global average pooling + dense
- [x] Prototype network
- [x] Prototype network + autoencoder
- [x] ranking loss
- [x] ranking loss + autoencoder
- [x] ranking loss + GAP
- [x] ranking loss + autoencoder + GAP
2. 12/16 開會
    * 收集沒有邏輯的支票
    * 託收票：
        * 帳號 金額 到期日 以AI取代中心一登
        * 版型不同
        * 帳號：各種不同的格式（有“0”、 有“－”、 劃掉寫新的、 顛倒、信用卡帳號） 陷阱（統編、電話、空白、兩組帳號）
        * 每日一萬張，需兩小時辨識完畢
        * 可能有退稅憑單、本票夾在資料裡面
        * 磁字可以判斷票種
3. 辨識是否有元整: https://www.notion.so/bd4f5fc84d244fac8e68a6713b917c75
3. 辨識成大寫數字: 阿拉伯數字轉大寫數字
4. 金額標記系統
### [不動產估價](https://hackmd.io/NmODiGu1SvqVOHzdRb6LMg?both)
![](https://i.imgur.com/KxuQtvD.png)
![](https://i.imgur.com/FonNC0x.png)

1. hierarchical clustering (centriod)
2. hierarchical clustering (single)：
    * price normalize
    * 價差超過最大地理距離則視為最大地理距離：if price difference > max(pairwise geo distance), geo distance = max(pairwise geo distance)
        * 雙北住宅大樓（11層樓以上有電梯）before 108/10/1
    
            | district | cut point | # of clusters | # of data |
            | -------- | -------- | -------- |  -------- |
            | 信義區     | 0.25    | 14 | 1656 |
            | 大安區     | 0.18    | 21 | 1951 |
            | 內湖區     | 0.35    | 7 | 3713 |
            | 中山區     | 0.2    | 13 | 4195 |
            | 士林區     | 0.45    | 5 | 1451 |
            | 文山區     | 0.35    | 11 | 2796 |
            | 松山區     | 0.2    | 12 | 1553 |
            | 北投區     | 0.35    | 10 | 1871 |
            | 中正區     | 0.35    | 6 | 1461 |
            | 萬華區     | 0.25    | 11 | 2688 |
            | 大同區     | 0.15  | 20 | 1329 |
            | 南港區     | 0.4    | 10 | 1745 |
            | 樹林區     | 0.5    | 6 | 4151 |
            | 淡水區     | 0.3    | 19 | 25936 |
            | 五股區     | 0.3    | 13 | 5135 |
            | 汐止區     | 0.3    | 20 | 9938  |
        *  台北公寓混區: (萬華、文山未納入)
            | district | threshold | cut point | # of clusters |
            | -------- | -------- | -------- | -------- |
            | center 4: 信義、中正、大安、松山 | 2 | 0.28  | 44 |
            | north 3: 士林、大同、北投| 2 | 0.32  | 51 |
            | east 3: 中山、南港、內湖| 2 | 0.5  | 31 |
        *  台北公寓混區: （with notes)
            | district | threshold | cut point | # of clusters |
            | -------- | -------- | -------- | -------- |
            | center 2: 信義、松山 | 1 | 0.5  | 36 |
            | center 1: 大安、中正 | 1 | 0.4  | 42 |
            | north 3: 士林、大同、北投| 2 | 0.32  | 51 |
            | east 3: 中山、南港、內湖| 1 | 1  | 39 |
        *  台北大樓混區(不適合混區：萬華、文山)
            
            | district | threshold | cut point | # of clusters |
            | -------- | -------- | -------- | -------- |
            | center 4: 信義、中山(一)、大安、松山 | 4 | 0.18  | 53 |
            | west 4: 中山(一)、大安、大同、中正| 3 | 0.2  | 52 |
            | north 3: 士林、大同、北投| 2 | 0.5  | 44 |
            | east 3: 中山(二)、南港、內湖| 1 | 0.5  | 39 |


    * 使用heap 可使速度加快
        * 2000個資料約需10秒完成
        * 5000個資料約需2分鐘完成
        * 10000個資料約需10分鐘完成
        * 25000個資料約需3小時完成
    
4. 1/27開會
    * 車位修正：
        * 車位好像不可信 
        * 車位有問題的地方改成缺值，然後找到附近的車位價格，根據年份作家全平均，再補上去
        * 雙北單價較高 相對誤差縮小，反映在hit rate上
        * 雙北偏鄉地區不太有感
    * 自動分群
        * 部分行政區是真的有用，但有些沒有
        * 在台北市整體提升約2%
        * 同一群為甚麼會分在兩塊不同的地方？
    * 公寓模型
        * 有些使用各區自己的比較有用 有些要用整個台北市跑的模型
        * 新北市不知道為什麼 資料很多但準確度只有41%
    * 上線結果：
        * 模型-估價：假設估價是正確的情況下 模型傾向低估
        * 行政區分群可能太粗，“我們期待分群演算法可以提高模型效能”

## to-be brainstroming
* 金控數科AI team 的 to-be: 知名Fintech 的專業團隊
    * Definition: 
        * 有能力開發個種關於fintech 的技術，不限於AI（ex: 行動支付、區塊鏈、物聯網等）
        * 客戶不限於行內，也可以當其他新創公司的顧問團隊（教他們如何發展金融科技之類的）
    * Difficulties
        * 金融科技領域範圍廣大，人力不足
        * 同仁們不但需要學會各種技術，也要catch up 新技術（需要更多訓練）
        * 資訊不透明：好像各種東西都需要權限
    * Possible solutions:
        * 可以先從內部比較需要的應用的技術開始，再慢慢擴展到其他技術（例如AI->p2p lending->區塊鏈->物聯網）
        * AI內部再稍微分組，部分組別駐點在其他單位
        * 尋找坊間各種課程

## 區塊鏈
1. 底層 or 應用
2. 改學以太坊 需要用solidity 寫合約 把幣發起來:先起私鏈
3. 期貨想發幣 發幣可以幹嘛：
    * 每個幣都一樣
    * 每個幣不一樣:token
4. 熟悉以太坊的工具 solidity
5. RPC server
6. 使用 web3 和鍊溝通

## 理專洗錢防制專案
* 目前使用資料表
    * fz_BSP_Retail.dbo.X_Deposit_HTR_YYYYMM: 活期交易明細
        * 201901~202103
        * TRANS_REF: 交易序號
        * ACTNO: 帳戶帳號
        * TXAMT: 交易金額
        * TXBAL: 帳戶餘額
        * CHNNCODE: 交易通路，目前使用BRANCH(臨櫃), NETBANK(網銀)
    * fz_BSP_Retail.dbo.DBU_ACCOUNT: 分析客戶存款資料(包含以關戶), fz_BSP_Retail.dbo.OBU_ACCOUNT: 分析客戶存款資料
        * 201712~202102
        * RECID: 帳戶帳號
        * CUSTOMER: 歸戶編號
        * ACCOUNT_OFFICIER: 業務人員編號
    *  fz_BSP_Retail.dbo.CUSTOMER: 
        *  RECID: 歸戶編號
        *  T_MNMONIC: 身分證字號
        *  ACCOUNT_OFFICIER: 業務人員編號
        *  T_DEGREE: 學歷
        *  T_INCOME_1: 年收入
    * z_BSP_Retail.dbo.DEPT_ACCT_OFFICIER_Daily: DAO人資檔
        * MNEMONIC: 業務人員員編
        * RECID: 業務人員代號（編號）

    * fz_BSP_Retail.CUS_CORE_SUMMERIES_YYYYMM: 客戶名單撈取
        * USER_CODE: 業務人員員編
        * AO_CODE
        * CUS_CODE: 客戶身分證字號
    * EmpShare_YYYYMM: 業務人員資料
        * EmpID: 業務人員員編
        * AO_CODE
        * Position: 職位名稱
    * fz_BSP_Retail.Period_X_APBAL: 拵放匯的餘額檔
        * ACTNO: 帳號
        * UNINO: 客戶身分證字號
        * CUSTOMER: 客戶歸戶編號


## 4/23 AWS 爬蟲平台與知識圖譜查詢平台
1. eCloudvally 爬蟲與文字分析
* 爬社群媒體 新聞平台 -> 貼標 分群 分類 -> 放進資料庫 -> 輿情 趨勢分析
* 文本分析
* 好處：金融業要爬蟲需要審核（缺乏時效性）透過外部廠商爬蟲整理好 比較即時
* lambda: serverless 存放爬蟲程式的地方 
* s3: 可以把資料複製三份到三個不同的機房裡
* 不同lambda 互相呼叫的方式：lambda 或是當s3拿到output 的時候trigger 
* Jay: 
    * 希望可以把外部收集資訊的平台和RPA串連
    * 希望可以當builder 但是有廠商來維護 而不是直接外包給廠商
* 如何維護：直接跟客戶測試 

2. 源銳資訊 知識圖譜系統
* 花了好多天的時間查了很多資訊 但要報告的時候資訊可能也變了
* 目的：發掘潛在客戶
* 資料庫(KYCRIGHT) 即時智慧判斷引擎(KY-AI) 知識圖譜查詢平台(KYCHECK)
* 七成的準確度 預測某個自然人背後的資（因為個資法 很多自然人的資訊是拿不到的）：加入客製化的個資可以提高資料完整度
* DB每天更新兩次 從41 sourse websites 去爬蟲資料
* model：RPA, NLP, ML 會自動更新
* 維護的項目：fix DB, 像買保險一樣


```
SELECT ACTNO, UNINO FROM Period_X_APBAL
SELECT DISTINCT USER_CODE, AO_CODE, CUS_CODE, 
from CUS_CORE_SUMMARIES_YYYYMM WHERE USER_CODE != ''
```

```
SELECT * FROM X_Deposit_HTR_YYYYMM
where EXRATE is null 
and (
(CHNNCODE='BRANCH' and TXNMEMO in ('轉帳', ‘連動轉’, '連動轉帳', '台幣匯款') or 
(CHNNCODE='NETBANK' and 
    ((CURR='TWD' and TXNMEMO in ('電子轉帳', ‘網銀轉帳’, '網路轉帳', '網銀儲值')) or 
    TXNMEMO='網銀換匯')
)

```