「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
ルールベース → 機械学習、深層学習
詳細 †
違い †
色々な難しさ †
- エラー（侵入検知でもあったアレ）の責任
| 実値＼予測値 | 異常がある（Positive） | 異常がない（Negative） |
| 異常がある（Positive） | 真陽性（TP：True Positive | 偽陰性（FN：False Negative |
| 異常がない（Negative） | 偽陽性（FP：False Positive | 真陰性（TN：True Negative |
- 倫理的・法的・社会的課題
（ELSI：Ethical, Legal and Social Issues）
開発の流れ †
保守・運用 †
保守・運用の重要性が高い（→ ポイント）。
組織と文化 †
AI活用を拡大するための組織
主な挑戦は技術ではなく文化
体制 †
- チームの構築
強いマトリックス型
- Hub（中心となるグループ）
- Spork（ビジネスユニット）
- Gray Area（繋ぐ領域）
- CTO直下
- 決裁権がある。
- ビジネスインパクトが解る。
- 技術もプロダクトも解る。
成功例と失敗例 †
- 失敗した企業の例
- 発注ベースで取り組んでいる。
- 技術やプロダクトが解っていない。
- 現場の理解が得られずデータが集まらない。
- 成功する企業の例
- 内製化に成功している。
- 人材の戦略的育成
- 担当者と現場の協力体制
- スピード感のある柔軟な進め方
AIの開発 †
ステップ †
- ビジネス・イシューをブレークダウン
（AIが得意な所を発見して適用する）
アルゴリズムの選択 †
アルゴリズムのアーキテクチャをデザイン
- タスク要件を間違うと出口なき開発（≒ 地獄）へ突入する。
- データ取得が可能か？
運用でないと or 運用ですらデータ取得できない。
データの収集 †
- 重要要素
データセットの収集・アノテーションの質を担保
・データセットの収集方法
・画像認識で言うと撮影方法等）
・画角、照明、距離、画質 / FPS
・アノテーションの質の担保
試作モデルの開発と評価 †
- 精度評価指標には色々ある
タスクに合わせて精度評価指標を選択
- エラーのタイプによる指標
※ ハックとは実値異常（or 正常）が99％なら、
予測値全部異常（or 正常）でaccuracy = 99％的な話。
| 指標 | 計算方法 | 適合するケース |
| accuracy（正解率） | = (TP + TN) / (TP + TN + FP + FN) | 予測が当たるか当たらないかの指標 |
| precision | = (TP) / (TP + TN) | 過検出を無くすことが重要な場合の指標 |
| recall | = (TP) / (TP + FN) | 抜け漏れをなすくことが重要な場合の指標 |
| f1score | (2 * precision * recall) / (precision + recall) | ハックし難い指標 |
- 画像認識の指標
| 指標 | 説明 |
| IoU | 物体検出の指標 |
| AP | 物体検出の各クラスのクラス分類の指標 |
| mAP | 物体検出の全クラスのクラス分類の指標（= (AP1 + AP2 + ... + APn) / n） |
- 精度 ≠ 100％
・PM
・スコープの定義
・期待値のコントロール
・実装
UI / UX、運用でカバー
・確信度毎に通知方法を変える。
・確信度と判断基準を出力する。
ポイント †
PoC（概念実証） †
- PoC（Proof of Concept：概念実証）
- 仮説を持つ
・解かり易い仮説
・YES / NO、数値で答えられる。
- PoC（概念実証）
リスクヘッジ（投資の意思決定に資するインサイトが収集できたかが重要
- 仮説を検証可能なサンプル・データを収集する。
- 簡易なモデルを用いて結果を見てみる。
- 仮説のTrue / Falseが明らかになる。
- 新たに発生した不確実性 / 問題点を整理
- 上記の不確実性 / 問題点を解決できるか検討する（PoC2）。
アジャイル †
- 試してみないと解らない（仮説検証の試行錯誤を含む）。
- 適応型ライフサイクル（アジャイル手法、変化駆手法）が基本。
評価方法の決定 †
プロジェクト目標を明確化して共有する。
- 難易度への理解
- ベンチマーク方法の策定
- 指標の決定
自社オペレーション †
- データの収集（✕：業務委託
- MLOps（Machine Learning Operations）を運用するための作業が必要。
保守・運用 †
PDCA速度の向上 †
リリース後の改善する計画も必要
アンチパターン †
- 実現可能性を見誤る。
- 特定の手法に入れ込み過ぎない。
- 高度な手法が良いとは限らない。
- 試してみないと解らない
（仮説検証の試行錯誤を含む）。
- Po死
- 費用対効果の説明ができなかった。
- 成功・失敗のインサイトに価値が無い
- 精度≠100％（AIは100％は無理、でも人間も無理。）。
- 導入ノウハウ、運用ノウハウがない。
事例 †
AI原料検査 †
- ビジネス価値があり、経営層からの理解とバックアップがあった。
- 自社の理念に結びついている
- 現場が苦労し困っている
- 業界に共通の課題
- 立上げプロセスはテクニカル・フェロー自身が担当
- アプリは自社、AIは協業（覚悟のある２社）、設備は中小企業。
- 経営層、幹部には丁寧に解説・説明。
- その他、公募精度などを作った。
- ビジネス価値があり、経営層からの理解とバックアップがあった。
- 足りないAIスキルは外部ベンダーをパートナーに選定し適切に協業する。
- AIベンダーは技術よりコンセプトを固める所のパフォーマンスを重視した。
- オペレーターとディスカッションしシステムに反映して行くプロセスを繰り返した。
- AI開発が必要な部分をできるだけコンパクトにしてスピーディーに開発した。
- コンセプトで教師データを用意してしてトライ・アンド・エラー
- AIの眼から判断した情報とクレーンを操作するロジックの結合部分を開発
参考 †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
