「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
ルールベース → 機械学習、深層学習
詳細 †
違い †
企画 †
PoC的
色々な難しさ †
- エラー（侵入検知でもあったアレ）の責任
| 実値＼予測値 | 異常がある（Positive） | 異常がない（Negative） |
| 異常がある（Positive） | 真陽性（TP：True Positive | 偽陰性（FN：False Negative |
| 異常がない（Negative） | 偽陽性（FP：False Positive | 真陰性（TN：True Negative |
- 倫理的・法的・社会的課題
（ELSI：Ethical, Legal and Social Issues）
開発の流れ †
→ AIの開発
保守・運用 †
AIの運用と更新があるので、
保守・運用の重要性が高い（→ ポイント）。
組織と文化 †
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）。
アジャイル †
- 試してみないと解らない（仮説検証の試行錯誤を含む）。
- 適応型ライフサイクル（アジャイル手法、変化駆手法）が基本。
評価方法の決定 †
プロジェクト目標を明確化して共有する。
- 難易度への理解
- ベンチマーク方法の策定
- 指標の決定
自社オペレーション †
（✕：業務委託
保守・運用 †
PDCA速度の向上 †
リリース後の改善する計画も必要
品質保証 †
- Data Integrity
- 質においても量においても適切かつ充分なデータの確保と、
- 学習用データと検証用データが独立しているかどうかなどについて考慮
- Model Robustness
モデルの精度と頑健性、デグレードなどについて考慮
- System Quality
AI プロダクト全体の品質の確保について考慮
- Process Agility
プロセスの機動性について考慮する（アジャイル、MLOps的）。
- Customer Expectation
よい顧客との関係性について考慮
- 形式手法活用網羅検証
機械学習モデルを論理式にエンコードし、形式手法によって網羅検証
- ニューロンカバレッジ
テスト与えられたテストケースの集合によりどのニューロンがテストされたかを可視化
- リファレンスモデル照合テスト
正解値のついていないテストケースに疑似的な正解値を付与しテスト自動実行
- メタモルフィックテスト
テストケースの入力値に微細な変更を加えても出力値が変わらないことを検査
- 外れ値自動生成テスト
人手では作成困難な外れ値・異常値を自動生成することでロバスト性を効率的に検査
- 不確実性ベーステスト
訓練データの不足などに起因する認識論的不確実性のロバスト性評価・改善
アンチパターン †
- 実現可能性を見誤る。
- 特定の手法に入れ込み過ぎない。
- 高度な手法が良いとは限らない。
- 試してみないと解らない
（仮説検証の試行錯誤を含む）。
- Po死
- 費用対効果の説明ができなかった。
- 成功・失敗のインサイトに価値が無い
- 精度≠100％（AIは100％は無理、でも人間も無理。）。
- 導入ノウハウ、運用ノウハウがない。
事例 †
AI原料検査 †
- ビジネス価値があり、経営層からの理解とバックアップがあった。
- 自社の理念に結びついている
- 現場が苦労し困っている
- 業界に共通の課題
- 立上げプロセスはテクニカル・フェロー自身が担当
- アプリは自社、AIは協業（覚悟のある２社）、設備は中小企業。
- 経営層、幹部には丁寧に解説・説明。
- その他、公募精度などを作った。
- ビジネス価値があり、経営層からの理解とバックアップがあった。
- 足りないAIスキルは外部ベンダーをパートナーに選定し適切に協業する。
- AIベンダーは技術よりコンセプトを固める所のパフォーマンスを重視した。
- オペレーターとディスカッションしシステムに反映して行くプロセスを繰り返した。
- AI開発が必要な部分をできるだけコンパクトにしてスピーディーに開発した。
- コンセプトで教師データを用意してしてトライ・アンド・エラー
- AIの眼から判断した情報とクレーンを操作するロジックの結合部分を開発
参考 †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
