接著建模雜談系列10-ai squad討論ai團隊的構建，本次討論的基礎假設是「人的服務不可靠」。
由於人生活在社會中，除了本身的生物週期（生老病死）之外，社會環境的變化也會極大的影響到人的態度，進而影響到服務和合作。例如，a原來是個特別積極的員工，後來發現薪資跟不上，就特別消極。這個時候站在資本家的角度應該怎麼辦？傳統的方法是kpi考核，但是如何制定kpi是個很大的問題。
本篇討論如何建立乙個滿意（但可能不完美）的kpi制度，一開始由人推動，之後完全自動化（賞罰由系統控制）。
每個人都是乙個映象。服務化 + 標準化 + 價值估計。
圍繞展示、服務、建模、計算、優化等五方面的能力體系
名稱涉及的技術
作用框架型前端
react, vue
快速構建前端
**型前端
jquery, bootstrap, awesomefont
更加靈活的前端
**型前端
d3.js , echarts.js
基於前端的視覺化
it架構
nginx, frp
內網穿透，反向**，負載均衡
架構部署
docker, docker-compose, docker machine
應用快速部署
分布式計算架構
rabbitmq, pytorch, numpy
高效能計算
分布式服務架構
rabbitmq, docker-compose, neo4j
高穩定服務
資料分析
pandas, mysql
溝通業務
資料處理
pandas, mysql, mongo, neo4j, hive
資料的儲存與處理
經典資料建模
pandas, numpy, sklearn, xgboost
以邏輯回歸為基礎的建模
深度學習
pandas, numpy, pytorch
處理、文字、語音
貝葉斯建模
pandas, numpy,scipy, pymc3
基於貝葉斯的另一整套方法（= 經典資料建模+深度學習+概率推理）
圖建模pandas, py2neo, neo4j, networkx , pytorch
基於圖方法進行的聚類和分類
運籌優化
scipy
運籌及優化
正如我們使用區域網/公網的機器構建了伺服器：
要解決的問題，或者要運籌的內容是：始終保持有服務可用，即便有伺服器down掉。當然如何合理的分散伺服器和進行任務分派是重要的。
按照期望提供的sla以及運籌學，我們可以預備足夠多的」伺服器「。
人工智慧的意義並不是取代人類，而是促進人類的進步。例如，把漢字抄一千遍，這事該人幹嗎？
如果事情/業務的規範性和重複性很高，那麼就應該被抽取出來，再用機器去替代掉。人幹這種事本能也會覺得疲勞和煩躁。
人類的工作應該是去做新的探索，思考演算法/規則層面的問題，然後把一些無規律/無法控制的事慢慢變得清晰可控，再把這些成果交給人工智慧進行最大化。
例如人為了解決某個問題花費了100的成本，再花100的成本變**工智慧型，可以近乎無限的復用。然後只要能夠對其他人有1的幫助，有1000個人使用並付費就很划算了。
人應該創新，發現，提煉規律，演算法；找到新領域的價值=問題按照上面的討論，既然明確了人和機器的分工，那麼作為乙個主體(entity)，如何run起來呢？人工智慧（計算機+網路+工業控制+ 感測器）則負責工業化的實現這些價值
早些時候我曾經粗粗的看了區塊鏈：加密貨幣、分布式記賬和智慧型合約構成了內容的全部，當然現在似乎只是談到加密貨幣和分布式記賬，這其實只完成了基礎的部分（即可以交易）。
最核心的，改變生產組織方式的是智慧型合約：也就是生產方發布任務（合約），然後生產者只要提交完成就自動校驗然後付錢。
這種方式其實非常適合人工智慧領域，簡單來說人才難得，人才難以驅動。乙個主體是很難以擁有硬體資產的方式占有人才的，既不經濟也不可能。所以可以考慮以下方式：
以測試為導向的內容分發。例如，我們希望有人能寫乙個函式f，能夠實現將x轉變為y的過程。那麼定義可能的數十種，或者數百種測試結果是最重要的。（當然高階點的可以通過演算法模擬更全面的測試）
任務發布後，給到描述和意義，然後提供乙個測試介面。對於合格的開發者（實體認證）可以接受並完成這個任務，完成後只要通過測試就可以把**git上傳到某個倉庫(submodule)。
任務可以有多種型別。排他的、競爭的、限時的…按照任務的要求會略有不同，簡單來說分為基本收益和提成收益。不同的開發者在完成了不同數量或者難度的任務後會有不同的等級，這個等級將對應費率（例如1000元/小時）。任務發布者需要顧及任務的難度，以基礎費率吸引不同級別的開發者來參與。但是對於比較牛的開發者來說，僅僅是基礎費率是無太大吸引的，所以也要同時考慮提成。
提成的方式可以考慮按使用次數、使用時長給予一定比例的獎勵。可以類似期權性質的方式，但是要確保及時兌現。這種獎勵是隨著使用來的，如果任務發布者採取ab test方式，那麼可以自然的優化任務的收益，也促進開發者的提公升。所以，最後的難處反而拋給了任務的發布者/專案組織者。我覺得這樣反而是合理的，每個角色負責對應的工作，承擔責任。
建模雜談系列2 建模過程（邏輯回歸）
以邏輯回歸為例，簡述一次建模過程的流程。0公式0 的梳理。對於一般的監督學習而言，目標是首先要確認的。在這步甚至可以保留多個可能的目標變數 但是在每次建模中只使用乙個 當變數的缺失比例較高時，可以考慮直接棄用變數。缺失的問題是比較麻煩的 可能是由於客戶不願意錄入 錄入了但是儲存失敗甚至是取數時的失誤...
建模雜談系列14 建模流程1 從資料開始
探索建模的流程和處理步驟。從資料 檔案的角度看，在整個建模過程中會發生什麼 2 檔案和變數的命名 3 持久化 檔案儲存 資料庫 4 引數的產生和管理 5 過程檔案的產生和管理 6 模型的產生和管理 7 報告檔案 從資料表開始 在乙個專案空間下，表的原始字段應該是固定含義的。例如name如果表示名字，...
建模雜談系列6 任務機制
思考兩個問題 要達成什麼樣的目標？有何意義 如何基於人 小團隊 完成？沒有目標也就無所謂了對錯，一般來說專案都應該有具體的目標。所以評估目標及其意義是重要的第一步，簡單來說也就是評估內外部環境，自身的強弱項 swot 夫未戰而廟算勝者，得算多也 未戰而廟算不勝者，得算少也。多算勝，少算不勝，而況於無...