生成AIはモデリングに使えるか

当方は「生成AIを（使える範囲で）モデリングに利用したい」という立場ですが、アカデミックな世界にはもっと真面目にこの点について研究された論文があります（後で気がついたのですが、知り合いが関与していました）。

“On the assessment of generative AI in modeling tasks: an experience report with ChatGTP and UML” というタイトルで、次の場所にあります。

https://link.springer.com/article/10.1007/s10270-023-01105-5

ChatGTPを使ってきちんとしたUMLモデルが作成できるかという観点から書かれたものだと思います。そういう意味では、とてもよく調べられていると思います。拍手！です。

ただ、XtextやSiriusなどのDSL開発という意味では、論文では能力が低いとされている抽象化が当方の実験では結構いけると評価しています。この違いは、前提、文脈や事例など事前の知識の差によるのではないかと想像します。

いずれにせよ、こういった真面目な研究が継続されることで、どこに使うと効果的かという点が見えてきますので、開発工程への導入・適用も進むのではないかと考えます。

Google NotebookLM お試し

Google の NotebookLM が ChatGTP の GTPs 的なことが出来そうだったので「お試し」してみました。

感想としては、デフォルト設定のせいか、また得意の「検索」機能が強く働くせいか、exact word(s) が見つからないと「見つからない」といった応答になる傾向を感じました。また、ChatGTP と違い URL も sources に追加できますが、やはり先ほどの検索指向の問題解決のせいか、URL で document のページを設定していても、ヒットするかどうかで応答があるような印象でした。

ということで、何らかの分野にカスタマイズするのは ChatGTP の GTPs の方が期待に近い動作をしてくれる印象です。また、URL より PDF 等のファイルで与える方がしっかり読んでくれる印象です。

これ以外にも RAG の仕組みを使う方法が考えられますが、本格的な依頼でもない限り GTPs でいいかな、というのが現在の判断です。

コード生成について

Eclipse の世界で仕事をしていると、モデルに基づくコード生成はテンプレートベースのものが中心になります。Xtextはgeneratorを作成しますし、SiriusではAcceleoなどを併用します。これらはテンプレート型のコード生成になります。

一方、ChatGTPとやりとりをしていると、暗に「生成AIベースのコード生成の方が優れている」という主張を感じます。その根拠についてきいてみたところ、次のようなことを言ってきました。

• トレーニング次第だが、入力仕様に対して柔軟な対応が可能
• 複雑なロジックや構造を備えたコードが得意
• AIは学習し続けるので、より良いコードを生成できるよう進化する
• 入力が自然言語であっても対応できる
• 多様な出力形式に対応できる

直感的には、テンプレートベースの方が確かなものが生成できると思いますが、柔軟性を求めるようになると生成AIを利用したコード生成も候補に上がってきそうです。二者択一ではなく、うまく組み合わせることができれば、より良い解に近づけそうです。

生成AIに書いてもらったブログ記事（改）

AIに自動的にブログ記事を書いてもらうというprompt例があったので、試してみました。入力データはタイトルだけ（サブタイトルはAIが勝手につけています）なので、内容が薄いのは仕方なしです。これをヒントにして、自分で記事を書きなさい、ということのようです。

未来のエンタープライズアーキテクチャと技術革新

---

目的: この記事の目的は、RM-ODP（Reference Model of Open Distributed Processing）の基本概念とその進化について説明し、モデリングと生成AIの融合がどのように新しいエンタープライズアーキテクチャを実現するかを探ることです。

主題の概要: RM-ODPは、分散処理システムの標準化モデルとして広く認識されています。この記事では、RM-ODPの基本とその進化を概観し、モデリングと生成AIの技術を融合させることで、どのようにエンタープライズアーキテクチャを革新できるかを具体例を交えて紹介します。

読者への興味関心の惹きつけ: エンタープライズアーキテクチャや分散システムに関心がある読者に対し、最新の技術トレンドであるモデリングと生成AIがRM-ODPに与える影響について興味深い洞察を提供します。

---

RM-ODPの基本

RM-ODPとは

RM-ODP（Reference Model of Open Distributed Processing）は、分散処理システムの設計と標準化を目的とした参照モデルです。RM-ODPは、エンタープライズアーキテクチャの構築において重要な役割を果たしています。このモデルは、異なるシステム間の相互運用性を確保し、複雑な分散システムを一貫して管理するためのフレームワークを提供します。

RM-ODPの歴史と進化

RM-ODPは、ISO（国際標準化機構）によって標準化されたモデルであり、その歴史は1990年代に遡ります。初期の段階では、主に通信プロトコルやネットワークの相互運用性に焦点を当てていました。しかし、時代とともに技術の進化に合わせて改良され、現在ではクラウドコンピューティングやIoT（Internet of Things）などの新しい技術にも対応しています。

---

モデリングの基本

モデリングとは

モデリングは、データを用いて現象やシステムを数学的に表現する技術です。これにより、複雑なシステムの理解や予測が可能になります。例えば、統計モデルや機械学習モデルを使用して、過去のデータから未来のトレンドを予測することができます。

モデリングの応用例

モデリングは、製造業、ヘルスケア、金融など様々な分野で応用されています。製造業では、生産ラインの最適化や品質管理に利用され、ヘルスケアでは、患者の診断や治療効果の予測に用いられています。金融分野では、リスク管理や投資戦略の策定に重要な役割を果たしています。

---

生成AIの基本

生成AIとは

生成AIは、ニューラルネットワークなどのアルゴリズムを用いて、新しいデータやコンテンツを生成する技術です。代表的な例として、テキスト生成、画像生成、音楽生成などが挙げられます。これらの技術は、創造的なプロセスを自動化し、人間の創造性を補完するものとして注目されています。

生成AIの応用例

生成AIは、画像生成ではアート作品の創出、テキスト生成では自動文章生成や翻訳、音楽生成では自動作曲など、幅広い分野で応用されています。ビジネスの分野でも、マーケティング用のコンテンツ生成やカスタマーサービスの自動化に利用されています。

---

RM-ODPとモデリング、生成AIの融合

統合の利点と可能性

RM-ODPとモデリング、生成AIを統合することで、エンタープライズアーキテクチャの設計がより高度かつ柔軟になります。モデリング技術を用いることで、システム全体の動作をシミュレーションし、最適化することができます。一方、生成AIは、必要なデータやコンテンツを自動的に生成することで、システムの効率を向上させる役割を果たします。

実際の事例と未来の展望

実際の事例として、スマートシティの管理やヘルスケア分野での患者データ管理が挙げられます。スマートシティでは、交通管理やエネルギー効率の最適化にRM-ODPと生成AIが活用されています。ヘルスケア分野では、患者の診断や治療計画の立案において、モデリングと生成AIの技術が統合されています。将来的には、これらの技術がさらに進化し、私たちの生活全般にわたって影響を与えることが期待されます。

---

結論

まとめ: RM-ODP、モデリング、生成AIの融合は、エンタープライズアーキテクチャの新しい可能性を切り開きます。これにより、効率的かつ柔軟なシステム構築が実現し、未来の技術革新に寄与するでしょう。

終わりの言葉: 技術の進化は止まることを知りません。RM-ODPと新しい技術の融合がもたらす未来に期待しながら、これらの技術がどのように私たちの生活を変えていくのか、引き続き注目していきましょう。

GPT-4o について

先日 Modeling + Generative AI の記事を書いたばかりですが、OpenAI 社から GPT-4o が発表され「やはり技術の進化が早い」と思った次第です。少し試しただけですが、まず応答速度に驚きました。公開される GPTs も増えそうです。

自前の環境の場合、外に出したくない情報を処理できるといっても、これだけの性能には及ばないので、自前の環境＋ ChatGTP ＋ … といった複数の手法を用意して案件やさらに小さい区分ごとに使い分けるしかなさそうです。

なお、自前の環境で実用的な反応速度で運用出来るようにするには、高性能なPC等も必要になるので、何を大切にするか優先度をしっかり考えて準備する必要があります。

最後に、自然言語を使ったやりとりでこれだけ出来るなら、モデリングは要らなくなるのか、を考えてみました。見方はいろいろあると思いますが、最終的にはソースコードを書くことになり、その手前の段階で議論や合意をするためのフォーマルでありながら簡易的な情報整理手段としてモデル・モデリングの存在意義が残るのではないかと思っています。

First Step: Modeling + Generative AI

Generative AI についての情報収集は難しくありません。何しろネットの世界のあちこちに、ニュース、ブログ、Youtube解説などがあり、むしろ多過ぎてどれを視聴すれば良いのか判断に困るほどです。そんななか、幾つかの情報を組み合わせて、私もやってみました。

最近流行りの Dify を docker を使いローカル実行し、Meta社が提供するオープンなOllama3を利用して、ローカル（Mac上）で ChatGTP のような自己完結型の環境を作りました。そして、RM-ODPの Part 2/3/Enterprise Language の pdf ファイルを事前情報として渡した上で、RM-ODPに関する幾つかの基本的な質問をしてみました。

以前、ChatGTPでほぼ同じことをしたのですが、結果から言うと ChatGTP の方が良い回答が返ってきたような気がします。ただ、あの時は色々なやりとりを先に行なっていたかもしれないので、誤差の範囲なのかもしれません。また、言語モデル自体についてもパラメタ数など差があるので、これはこれで満足すべきかもしれません。

Eclipse/Xtext と Eclipse/Sirius についての質問をしてみましたが、ある程度はわかっているようです。ただ、実際に Xtext 文法を作らせると、いまいちなものしか出てきませんでした。ChatGTP の時の方がもっともらしい結果が得られたと思いますが、やはり環境の違いによるものかもしれません。

この実験から言えることですが、まず、知識を与えて育ててゆけばある程度使えるところまでもって行けるかもしれない、ということです。また、AI 技術は競争も激しく日々進化していますので、あっという間により良い技術が出てくる可能性もあります（多分そうなるのでしょう）。現時点では Modeling + Generative AI を要素とする何かを想定して準備・実験を重ねてゆくのが良いのかと思います。

なお、関係ありませんが、出たばかりの ChatGTP 4o がとても早いので、しばらくは止められないですね。

Generative AI の利用について

ここではモデル開発という文脈での Generative AI の利用方法について書いています。

LLM の説明を読むと、大量の文書他を学習し、ある単語の次に出現する可能性の高い単語を順次つないで行くことでテキスト生成を行なっている、というようなことが書かれています。

だとすると、このようなことが言えないでしょうか？　学習に使われた文書というのは、過去に書かれた新聞・雑誌・Web の記事や論文などだと思いますが、その範囲内で「次に出現する可能性の高い単語」を探しても、既に知られている範囲の（知識）単語しか出てこない、つまり「全く新しい発想のようなものはまず得られない」と言えるような気がします。

しかし、逆目線でのメリットがあります。人は何かに集中するときどうしても視野が狭くなりがちです。Generative AI は、その視野から外れてしまったものを、過去の知識・常識で補ってくれる可能性があるからです。何かについて質問して、幾つもの項目が返ってくるというのは、そういうことのような気がします。

私は AI の研究者ではありませんし、モデリングに関連した話題では、これ以上のこと（特に二つ目のポイントについて）をやってくれているのも体験もしています。AI のご専門の方から「そんな単純な話ではない」というご指摘があるとは思います。それでも、利用者として試行錯誤することで経験を積み重ねることはできます。

結論としては、アカデミックな話ではありませんが、こういう文脈で、こういう使い方をすれば、こういう結果が期待できる、という知識を蓄積してゆき、必要に応じてそこから使い方を取捨選択し利用する、というのが当面の実用的な Generative AI の利用方法ではないかと感じています。ご意見等をコメントでいただけると幸いです。

なお、こういった知識ベースを自作し、サービスとして提供するというビジネス形態もありそうです。コンサル会社のようなところではもうやっているのかもしれません。

Xtext grammar for StateMachine

Fowler 本にでてくる secret compartment のモデルを ChatGTP に与えて、Xtext grammar を生成してもらいました。

与えたモデル

events
  doorClosed
  drawOpened
  lightOn   
  reset doorOpened
  panelClosed
end

commands
  unlockPanel
  lockPanel
  lockDoor
  unlockDoor
end

state idle
  actions {unlockDoor lockPanel}
  doorClosed => active
end

state active
  drawOpened => waitingForLight
  lightOn    => waitingForDraw
end

state waitingForLight
  lightOn => unlockedPanel
end

state waitingForDraw
  drawOpened => unlockedPanel
end

state unlockedPanel
  actions {unlockPanel lockDoor}
  panelClosed => idle
end

ChatGTP が導きだした文法

grammar org.xtext.example.mydsl.MyDsl with org.eclipse.xtext.common.Terminals

generate myDsl "http://www.xtext.org/example/mydsl/MyDsl"

Model:
    (events=Events)?
    (commands=Commands)?
    (states+=State)*;

Events:
    'events' events+=Event+ 'end';

Event:
    name=ID ('reset' resetEvent=ID)?;

Commands:
    'commands' commands+=Command+ 'end';

Command:
    name=ID;

State:
    'state' name=ID
    ('actions' '{' actions+=[Command]+ '}')?
    transitions+=Transition*
    'end';

Transition:
    event=[Event] '=>' state=[State];

このままでは使わないと思いますが、十分参考になると思います。なお、上の結果テキストでは分かりませんが、結果ボックスの枠には antlr という文字が見えます。

今回は比較的有名な例だったのですが、結局インプットがしっかりしていないと期待するアウトプットを出すことはできない、という当然の話につながります。要件やシナリオなどから次の段階に進める場合にも、インプットが大切になります。