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