生成ＡＩの機能分離について考えたこと

ＧＷは暇である。
かと言って、こんなにも与えられた時間、無駄に過ごしてはいけないと思う。

# やったこと

とにかくFACEBOOKの登山コミュニティを盛り上げることが必須。
思えばSUNO-AIで作ったハイキングアルバムが丸々完成した。

https://suno.com/playlist/c35fdc89-85e4-4553-8cc4-585bfc553b73

次に５／３の登山イベントのために、またしてもMEETSUPを立ち上げてしまう。
生成ＡＩを使い倒して、英語の案内などを作成したが、やはり山中ではＡＩに頼れないことがネックだ。

https://www.meetup.com/ja-JP/lovelyjapanoutdoors/

# 考えたこと

生成ＡＩのネックはローカルデバイスで収束しないこと　→　つまりネットが無いと成り立たない　→　山では使えない　→　いざ災害が起こったら役に立たなくなる。

もちろん、武器や兵器でも同じだが、これからは衛星通信のようなものや、ローカルで動く生成ＡＩデバイスのようなものが重要になってくると思われる。

そのための重要な技術は、ずばりＡＩの機能分離である。
つまり、一個のＡＩにすべてを託すのではなくて、ＡＩ同士を小さいネットワークで繋げて、機能分離をすることで、よりコンパクトにまとめていく方法である。

# 事例①　文書作成

業務でも、生成ＡＩを使ったプログラムの保守をやっている。

例えば、とあるバグ修正をするための計画書を作ったとしよう。
最終的には、ある書式に落とし込んでしまう必要があるが、これは一つのプロンプトにぶち込んでも、確度が低くて回答が安定しない。

こういう場合は、やはりプロンプトをいくつかの段階に区切った方が良い。

* 計画書作成AI: バグ修正のための計画書を作成するAIシステム
* マークダウン変換AI: 計画書をマークダウン形式に変換するAIシステム
* PowerPoint変換AI: 計画書をPowerPoint資料に変換するAIシステム
* JSON変換AI: 計画書をJSON形式に変換するAIシステム

イメージ図
```plantuml
@startuml
actor "ユーザー" as user

node "計画書作成AI" as plan_ai {
 component "計画書作成" as create_plan
}

node "マークダウン変換AI" as md_ai {
 component "Markdown変換" as to_md
}

node "PowerPoint変換AI" as ppt_ai {
 component "PowerPoint変換" as to_ppt
}

node "JSON変換AI" as json_ai {
 component "JSON変換" as to_json  
}

user -> create_plan : バグ情報を入力
create_plan -> to_md : 計画書を渡す
to_md --> user : Markdownで出力

create_plan -> to_ppt : 計画書を渡す
to_ppt --> user : PowerPointで出力  

create_plan -> to_json : 計画書を渡す
to_json --> user : JSONで出力

@enduml
```

### 従来との比較

CHATGPTでも同じで、プロンプトがやたらと長くなる場合には、なるべく単純なタスクにした方が良い。

```plantuml
@startuml
skinparam componentStyle uml2

component "1つのモデル" {
   node "プロンプト" as one_prompt

   node "出力" as one_output
   
   note left
     コンテキストを
     一括で処理
     
     大量の計算リソース
     必要
   end note
}

component "段階的なプロンプト" {
   node "第1段階" as multi_step1
   node "第2段階" as multi_step2
   node "第n段階" as multi_stepN
   node "出力" as multi_output
   
   multi_step1 -left-> multi_step2
   multi_step2 -left-> multi_stepN
   multi_stepN -down-> multi_output
   
   note right
     段階的に
     コンテキスト最適化
     計算リソース節約
     
     各段階で特化された
     プロンプト設計可能
     パフォーマンス向上
     
     出力の再利用性向上
   end note
}

one_prompt ..> multi_step1 : vs
@enduml
```

# 事例② 登山ツアーの場合
これから企画していくイベントを想定して、機能分離を考えてみた。
この体制は負荷が非常に高く、状況次第では計画変更や中止を検討するなど、安全性を最優先する必要がある。

* 参加資格の説明や同意書の内容を外国人観光客に正しく伝えるためには、一定の英語力が求められる
* ガイド同士の役割分担やコミュニケーションには英語が必要不可欠
* 状況次第で参加者に求める役割分担の説明にも英語が必要となる可能性がある
* 緊急時の対応や重要事項の説明には英語が必須となる

```plantuml
@startuml
actor "外国人観光客" as Foreign_Tourists

note left of Foreign_Tourists
【参加資格条件】
- 基礎的な登山経験
- 健康状態と体力
- 緊急時の自力行動能力
- 英語力
- 登山リスクの理解と同意
end note

participant "Head_Guide" as Head
participant "副ガイド(英語)" as Sub_Guide_EN

Head -> Head : 参加資格をチェック
Head -> Foreign_Tourists : 資格条件を説明\n同意書への署名要求

Head <-> Sub_Guide_EN : 役割分担・調整

note right of Sub_Guide_EN
状況次第で参加者にも
- 先発隊
- 気象観測
- 通訳補助
などの役割分担を求める
可能性がある
end note

Head -> Foreign_Tourists : 参加者への役割分担説明\n同意を得る

== 登山開始 ==

@enduml
```

# 事例③　サザエさん

サザエさん一家で機能分離を学ぼう！ カレー作り編

* フネさんは客人を迎える役割(音声認識AI)
* マスオさんと波平さんは調理の前準備(前処理AI)
* カツオくんは野菜を切る役割(翻訳AI)
* サザエさんはカレールーを作る役割(出力生成AI)

```plantuml
@startuml
actor "客人" as guest

participant "フネさん" as fune
participant "マスオさん" as masuo
participant "波平さん" as namihei
participant "カツオくん" as katsuo 
participant "サザエさん" as sazae

== カレー作り ~機能分離~ ==

guest -> fune : 玄関をノック
fune -> masuo : マスオさん、お客様です
masuo -> namihei : 一緒に玄米を研ごう

masuo -> katsuo : カツオくん、野菜を切ってくれる?
katsuo -> sazae : サザエさん、野菜切りました!
sazae -> sazae : カレールーを作る

sazae -> katsuo : カレールーできたよ
katsuo -> masuo : ご飯の用意はできた?
masuo -> namihei : 一緒に盛り付けよう

namihei -> guest : 出来上がりました!

guest -> sazae : おいしかったです!
sazae -> sazae : 次は何を作ろうかな

@enduml
```

# ANDREWさんも同じことを言ってます

https://youtu.be/sal78ACtGTc?feature=shared

https://www.youtube.com/watch?v=wM5837pVh1g

# 最後に

自分もこういう英語がストレスなく理解できるようになったのは、三年にも及ぶ英語勉強の成果だったと実感する。

https://qiita.com/EasyCording/items/3ad5486693b358f25e81