アーキテクチュラル・インテリジェンス – 次のAI

原文リンク(2024-11-26)

アーサー・C・クラーク氏の有名な言葉に、「十分に進歩したテクノロジーは魔法と区別がつかない」と言いました。現在、その「魔法」のような技術がAIとして知られるようになっている。人工知能は素晴らしい包括的な用語であり、マーケティングには最適だが、我々のソフトウェアに単純に追加できる特定のものを意味するものではない。それにもかかわらず、プロダクトオーナーやCEO、マーケティングチームは、あらゆるものに人工知能を追加することを求めている。顧客はAIを要求しているわけではないが、すべてのアプリケーションの最低限必要な条件としてAIを期待し始めるだろう。

我々は、AIをどのように、そしてなぜ使うべきかについて、曖昧で漠然とした指針を乗り越えなければならない。それは、スプレー缶を取り出して、あらゆるものにAIをきれいに塗るよう求められているようなものだ。そのような行き当たりばったりのアプローチでは、人々が期待しているような結果は生み出すことはできないだろう。AIとは何か、いつどこで使うべきかを理解する、思慮深いアプローチが必要なのだ。それが私が「アーキテクチュラルインテリジェンス」と呼んでいるものだ。

ソフトウェアアーキテクトは今、AIとは何か、AIとは何でないか、を理解する必要がある。そのためには、マーケティングや誇大広告のフレーズを乗り越え、実際のソフトウェアについて語る必要がある。

実際のソフトウェアが何であるかを理解した上で、それが設計のどこで意味を持つかを考える必要がある。アーキテクトはシステムのアーキテクチャだけではなく、アーキテクチャのプラクティスを改善する方法を考える必要があるため、ここでは、アーキテクトがシステム設計のプロセスの一部としてAIをどのように活用できるかについて時間をかけて考える。

AIとは何か？

AIは単なるマーケティング用語であり、ほとんど意味がない。真面目な話、AIという用語は、何かを説明するためのより良い用語がないときに使われる。プロセス、コード、製品として、あるウィジェットが既知の存在になると、私たちはそれに名前をつける。それを理解するまでは人工知能と呼び、理解した後はコンピューターサイエンスと呼ぶという人もいる。

「AI」という言葉は、何かに対してより具体的な名前がないことを意味する。これが私が伝えたい重要なポイントのひとつだ。我々のソフトウェアにAIを追加する場所を議論するのではなく、我々のデザインに組み込むことができる実際のものを説明する言葉が必要なのだ。

今までに、あなたやあなたの知り合いは、ビジネスリーダーが「私たちは製品にAIを追加する必要がある」と言った話を少なくとも1つは持っているはずだ。「AI」を「DB」に置き換えて、その要求にどう答えるか考えてみよう。あなたは振り返って、そのビジネス・リーダーにどのような種類のデータベースが欲しいか尋ねるだろうか？それはあまりうまくいかないと思う。

しかし、ソフトウェアアーキテクトとして、私たちはその答えを知っている。それは、状況によるということだ。要件は何かと尋ねる必要がある。どのようなデータを保存する必要があるのか？どのようにアクセスされるのか？どこでアクセスされるのか？そして、これらの要件を使用してトレードオフ分析に役立てる。トレードオフに関するガイダンスはたくさんある。リレーショナルデータベースとドキュメントストアのどちらを選ぶべきか？ファイルベースとインメモリのどちらが良いのか？ACID要件は何か？などだ。

ソフトウェアにAIを追加するよう依頼されたシナリオに戻ろう。ビジネスパーソンがどの種類のAIを望んでいるのかを聞くことはできない。しかし、答えは同じだ。状況による。しかし、それが何に依存するのか知っているだろうか？要件を定義するのに役立つ、適切な質問を知っているだろうか？利用可能な選択肢を知っているだろうか？

AIは通常、生成AIを意味する

5年前、多くの人がAIについて話すとき、AIについて語られるのはSFの世界だけだった。書籍、映画、テレビ番組、その他のメディアには、AIがキャラクターとして登場する。それらのキャラクターは、人工一般知能（AGI）として知られるものの例であり、(現在でも)私たちが持っていないものである。

2024年の今日、誰かが包括的な用語として「AI」と言う場合、おそらく生成AI（Generative AI）またはGenAIを意味するのだろう。これは、ChatGPTやGitHub Copilotなどの専用製品で見られる。また、製品に「AIをスプレーする」アプローチとしてもっとも一般的なアプローチでもある。もしどこかの幹部が自分たちの製品を現代的で革新的に見せたいのであれば、GenAIを追加する。これが、あまりにも多くのチャットボットを生み出している。そして、生成AIは言語に関するものだけではない。Dall-E、Midjourney、その他のツールを使用して画像、動画、音声を生成できる。

GenAIは機械学習から始まる

GenAIは、機械学習（ML）という幅広い概念の具体的な応用である。より具体的には、深層学習プロセスだ。我々の目的にとって、機械学習のプロセスは比較的単純だ。複雑な詳細はデータサイエンティストに任せよう。

MLモデルの作成は、まず大量のトレーニングデータから始まる。過去の販売データ、動物の写真、ユーザーのコメントなど、何でも構わない。その入力データと期待される出力データをMLのトレーニングプロセスに供給する。これは単体テストのようなものだ。入力Aに対して期待される出力Bが与えられた時、どれだけ近づいたか？学習プロセスはMLモデルを作成し、それを期待される出力に対して評価する。これは単純なプロセスで、何千、何百万、何十億回と繰り返し、モデルを継続的に洗練させていく。

非データサイエンティストにとって、MLモデルをコンパイルされたライブラリのような単純な関数ボックスと考えることは有益だ。平方根や対数を計算するために数学ライブラリをインポートするのと同じように、MLモデルをアプリケーションにインポートできる。あるいは、API経由で呼び出すこともできる。

いずれの場合も、MLモデルは単純な関数ボックスである。入力を与え、出力を返す。それだけだ。入力と出力は、平方根関数と比べると非常に複雑になることもあるが、関数ボックスのアナロジーはすべてのタイプのMLモデルに有効である。画像認識モデル、感情分析モデル、売上予測モデル、そしてGenAIの話に戻ると、大規模言語モデルも同様だ。

LLMはMLモデルであり、そこでの学習データ、入力、出力は、たくさん、たくさん、たくさんの単語である。LLMの入力は一連の単語だ。実際にはトークンの羅列なのだが。トークンとは何か？単語かもしれないし、単語の一部である可能性がある。詳細は重要ではない。結果として、すべてが、モデルが処理できる浮動小数点数の配列となることを覚えておいてほしい。

私たちの出力はトークンであり、一連のトークンではなく、単一のトークンだ。LLMは単なる予測テキストエンジンだ。しかし、単一のトークンや単語を予測することはあまり意味がない。次に、その単一のトークンをモデルにフィードバックし、その前に来たものすべてを予測し、次のトークンを予測する。これは、モデルが終了したというトークンを返すまで繰り返される。このプロセスは自己回帰として知られている。

AIはどこで使うべきか？

これまでに、AIはGenAIを意味し、GenAIはLLMを意味し、LLMはMLモデルの一種に過ぎないことがわかったので、その機能が私たちのシステム内でどこに適しているかを考え始めよう。

2024年、機械学習と生成AIはもはや後回しにされる存在ではない地点にいる。これらの最新のソフトウェアシステムの中核要素に急速になりつつあるテクノロジーなのだ。我々はどのようにしてここまで来たのか？

つい最近、企業がデータサイエンティストを雇い始め、機械学習モデルを作成し始めた頃、すべてはアドオンソリューションだった。データはすでに存在していた。そのデータは、カスタムMLモデルの学習に使われた。そしてそれらのモデルは、分析プロセスの一部として使われた。企業は実験をしたが、実験は常に成功するとは限らないので、ビジネスにとって重要なアプリケーションとは別に保管しておく必要があった。

現在、我々はMLがシフトレフトしているのを目の当たりにしている。なぜなら、私たちは得られたモデルを二次的なシステムの余分な追加機能ではなく、ソフトウェアの内部コンポーネントとして利用したいからだ。ここ数年で、チャットボットのような単なる追加機能だったAIコンポーネントが、左にシフトし、ユーザーに機能を提供するコアシステムコンポーネントになるのをすでに目にしている。私たちはそれを目指している。AIを余興にしたくない。しかし、それはどんな内容になるだろうか？開発者が書いた「従来の」ソフトウェアではなく、AIコンポーネントを使う意味はどこにあるのだろうか？

システム内のどこにどのようにAIを使うかを考慮することは、システム設計に新しいテクノロジーを導入するのと同じだ。トレードオフ分析を行う必要がある。AIを使う設計と使わない設計の長所と短所は何か？あるいは、別のAIモデルを使うのか。ソフトウェアにAIを追加するよう依頼された場合のシナリオを考えてみよう。トレードオフ分析をどのように始めるか？状況次第になる要因としては何が考えられるのか？

AIはシナリオに適しているか？

新しい機能を設計する際、通常は適切な選択肢から始め、それに該当しないものを排除する。しかし、AIはハイプサイクルの中にあるため、私たちは関連性のないところでAIを使おうという提案を目にする。AIの代わりに、リレーショナルデータベースをキャッシュエンジンとして使用したり、Lambda関数のみでEメールサービスを構築したりするような、別のテクノロジーとその誤用について考えてみよう。AIは、我々が待ち望んでいた万能のハンマーではない。

AIの使用方法は、良いアイデアから可能性のあるアイデア、悪いアイデアまで幅広く存在する。AIが意味を持つ機能の多くは、言葉が関係する場面だ。これらは大規模な言語モデルであり、言語を扱うことが得意だ。

AIの良い使い方

LLMは自然言語インターフェースを提供できる。これは入力と出力の両方で機能する。ユーザーが自分のやりたいことを説明すると、LLMはそれをシステム指示に変換できる。あるいは、LLMはシステムの応答をより人間に近い形式に変換もできる。

これは、カスタマイズ可能でありながら複雑なUIを持ち、欲しいものを説明できるが、すべてを設定するのに時間がかかるような場合に理にかなっている。AIを活用したアドホックレポートビルダーを考えてみよう。毎週月曜日にチャット形式のインターフェースで実行され、週ごとの比較を提供する新しいレポートをリクエストする。そうすれば、UIからすべての設定を学ぶ時間とフラストレーションを節約できる。

AIの可能な使い方

AIが効果的に機能するシナリオもあるが、思慮深く実装されない限り、その結果は理想から遠くなる可能性がある。多くの複雑なソフトウェアシステムは、重要だが使いにくいサブシステムで構成されている。

eコマースのシナリオでは、顧客が利用できるすべての割引を定義するルールエンジンがあるかもしれない。すべてのルールを設定する際のユーザー体験の悪さに直面したとき、ルールエンジンをAIに置き換えることは魅力的かもしれない。しかし、LLMが顧客が割引を受けられるかどうかを決定する場合、何が起こるかに驚くかもしれない。

LLMは次の言葉を予測するように設計されていることを常に念頭に置いておこう。ある時点で、顧客が割引の対象かどうかを尋ねられたとき、あなたが「いいえ」だと予想した次の言葉が「はい」になるかもしれない。これは機能であり、バグではない。

ルールエンジン全体をLLMに置き換えるのではなく、ユーザー体験を向上させ、ルールの入力や検証をより簡単に行えるように使用しよう。

疑わしいAIの使用

第3のカテゴリーは、AIの使用がとんでもないアイデアである場合だ。これらのシナリオのほとんどは、正確な数学的シナリオや、規制やコンプライアンス上の必要性からレポートを作成する場合など、監査やデータのトレーサビリティに関わるものである。

LLMは、データを分析し、それが何を意味するかを要約し、次に何をすべきかを提案するのに適しているかもしれない。しかし、データを正確に合計する必要がある場合は、LLMを使わないでほしい。彼らは数学が苦手なのだ。LLMにレポートAPIを使ってレポートを作成するのを手伝ってほしいと頼んでいる場合は問題ない。しかし、LLMに前四半期の売上合計を求めている場合は良くない。

会計の基本が何百年も前に作られて以来変わっていないのには理由がある。AIに帳簿のバランスを取らせ、その数字を株主に報告させてはならない。

AIは非決定論的ソフトウェアである

ほとんどのソフトウェアの大部分は決定論的な結果をもたらす。こうすればこうなる。そのため、単体テストを書いたり、機能要件を設定したりできる。もしソフトウェアが予期しない動作をした場合、バグを報告し、期待通りになるまでソフトウェアを書き直す。

しかし、AIは非決定論的であると考えるべきだ。それはランダムという意味ではないが、ある程度の予測不可能な部分があり、それは設計上のものだ。LLMがもっとも確からしい次の言葉を予測するのは、バグではなく機能である。「もっとも可能性が高い」というのは「常に保証されている」という意味ではない。

予測可能なソフトウェアに慣れている私たちにとって、これは大きな欠点に思えるかもしれない。しかし、考慮すべきことが2つある。第一に、GenAIは100％正確ではないが、通常は十分に優れている。そして2つ目は、アーキテクトは常に「十分に良い」を扱うものであることだ。我々は「完璧は十分に良いの敵」であることを知っている。(そのために)アーキテクトはトレードオフ分析を行い、どの妥協が受け入れられるかを判断しようとする。

システム設計においてAIのコンポーネントを考慮する際には、どこで「十分に良い」ということができるかを考えてみよう。私たちは何十年もかけて、期待されたことを実行するソフトウェアを構築してきたことを理解しているため、これは考えるのが複雑なアイデアかもしれない。

思考実験として、提案されているAIコンポーネントを人間に置き換えてみよう。誤った人間の入力を処理するために、どのようにシステムを設計するだろうか？UIバリデーションから、2人目のレビューを要求することまで、様々な方法がある。ユーザーインターフェースのユーザーがAIだったらどうだろう？AIが生成するものについてもおそらく同様の検証になるだろう。

これは、非常に多くの製品が「アシスタント」や「コパイロット」と呼ばれていることに現れている。これらの用語は、あくまでも人間が意思決定を行うことを私たちに再確認させるものだ。しかし、意思決定をAIに委ねた場合、それは副操縦士からエージェントへと移行することになる。AIエージェントに移行するには、検証プロセスをさらに考慮する必要がある。

AIを効果的に使うには

もしGenAIが我々のシナリオに適していると判断した場合、次の設計上の決定は、それをどのように効果的に使うかということだ。繰り返しになるが、答えは「状況次第」だ。AIの効果的な使い方は常に文脈に依存する。しかし、いくつかのハイレベルな考慮事項が通常適用される。

まず、私たちは「十分に良い」ソフトウェアを確実に受け入れ可能なものにしなければならない。AIのアウトプットがハイレベル(あいまい)すぎる「良い」ものばかりであれば意味がない。LLMがどのように進化し、現在ではほとんどの標準テストに合格できるようになったかを見てほしい。

可能な場合は、テストを作成してLLMを定量的に評価・比較できるようにする。具体的なタスクがある場合は、一連のテストプロンプトを作成し、それをLLMに入力し、経験豊富な人が作成すると予想されるものと比較して、そのアウトプットの質を評価する。

提案されているAIの用途は、しばしば人間に取って代わるか、人間を補うものであるため、人間がその仕事をする場合の思考訓練をすることは役に立つ。その人に必要なのは高校卒業資格だけなのか、それとも会計士やパラリーガルのような専門的な訓練が必要なのか。後者であれば、その言語を話す専門モデルを探す。

大きければいいというものではない

新しいLLMが発表されると、大きな数字が見出しを飾り、80億であれ800億であれ、パラメータ数がとても注目される。しかし、アーキテクトは常にトレードオフが存在することを知っており、これらの追加機能には欠点もある。自動的に最新のLLMを使うのではなく、意図する目的を考慮しなければならない。

もっとも重要な大規模言語モデルは、汎用的なタスクには最適だが、必要以上に強力な可能性がある。大きなモデルは、金銭、時間、あるいはカーボンフットプリントで測定すると、訓練と運用にコストがかかる。より小さなモデルでニーズを満たせるのであれば、より速く、より安く、十分に正確かもしれない。

また、小型のモデルは、より専門的で、特定の分野のために訓練されることもある。Taylor Swift氏のことを尋ねることはできないかもしれないが、ソフトウェアが人気アーティストのことを知る必要はないかもしれない。

AIの評価と最適化

自社の製品が言語モデルでない限り、独自の言語モデルをトレーニングすることは意味がない。これらは今や購入可能なコモディティ製品であり、購入するべきか、自社で構築するべきかのソリューションであるべきだ。場合によっては、モデルを大学院に通わせるのと同じように、モデルを微調整することに意味があるかもしれない。しかし、これは、微調整されたモデルがソフトウェア製品の主要な差別化要因となる場合にのみ意味がある。

LLMのパフォーマンスを最適化するために推奨される手法は、RAG（Retrieval-Augmented Generation）である。RAGは知識ベースを検索することでLLMを補完する。これは優れたソフトウェア・アーキテクチャであり、2つの技術を組み合わせてさらに優れたものにする。

LLMは、ユーザー入力をより良い検索クエリに変換する自然言語インターフェースを提供できる。検索結果はLLMに渡され、出典の引用を含むユーザーフレンドリーな応答が生成される。RAGパターンは、製品オーナーが既存のシステムにAIを追加したいと考える多くのシナリオに適している。

レンタルと所有

LLMはコモディティ製品であるため、LLM-as-a-ServiceアプローチでAPI経由でアクセスするか、自社で管理するハードウェアにインストールするかという選択肢がある。LLMを使い始める場合、従量課金のアプローチがもっとも理にかなっている。これにより、実験をして、何がもっとも効果的かを把握し、異なるモデルを比較できる。レスポンスの質、レスポンスを返すまでの時間、コストなど、トレードオフに不可欠なデータを集める。また、LLMを使用することがあなたのシナリオにとって意味がないという結果を導き出すかもしれないし、必要に応じてユースケースを適応させるのに役立つかもしれない。

LLMがあなたのソフトウェアの有用なコンポーネントになりうると判断したら、セルフホスティングアプローチが理にかなっているかもしれない。これは単純なコスト計算ではなく、多くの要素が関わってくるからだ。APIを通じて取得できるのと同じモデルを内部で使用できない可能性がある。ここでも、適切なトレードオフ分析を行うためには、いくつかの実験が必要かもしれない。

考慮すべきもう一つの要素はセキュリティだ。ハードウェアとネットワークをコントロールすれば、データ漏洩の心配は少ない。LLMに送られるデータをサニタイズしなければならない場合、それは出力の品質に影響する。また、モデルを微調整したい場合は、セルフホスティングを利用することになるだろう。

アーキテクトはいつAIを使うべきか？

以前の講演で、私はアーキテクトが日々実践するべき4つの基本的なスキルを取り上げた。まず、すべての基本はコミュニケーションである。2つ目は意思決定。3つ目は変化に適応できること。4つ目はリーダーシップだ。これらはすべて重要であり、その日その日で、どれかに重点を置く必要があるかもしれない。しかし、下記が基本的なランクであり、それらが互いにどのように積み重なっていくかを示している。

良いニュースとして、もしあなたがAIを使って良いアーキテクトになることに役立てたいのであれば、AIはピラミッドの下位層で有益だということだ。AIがあなたの意思決定プロセスを置き換えたるべき、またはすべてのコミュニケーションを処理するべきだと言っているわけではないが、あなたがすでに持っているスキルを補強し、次のレベルに引き上げることができる。

AIでコミュニケーションを強化する

LLMは大量の情報を要約するのが得意だ。ソフトウェアアーキテクトにとって、これは様々な聴衆とコミュニケーションをとる際に特に役立つ。長い設計書から始めて、LLMはCTO、プロダクトオーナー、開発チーム向けに異なる要約を作成できる。

また、LLMにあなたが書いたものに対するフィードバックを求めることもできる。メールを送ったり、プレゼンテーションを行ったりする前に、LMMにCTOやプロダクトオーナーが質問しそうなことをLLMに返答するように促すのだ。

AIで意思決定を強化する

優れたアーキテクチャは、多くの場合、ホワイトボードを囲んで新しいアイデアを描いたり消したりする共同作業から生まれる。一人で仕事をしているアーキテクトや仕事を始めたばかりのアーキテクトにとって、LLMはアイデアを出し合うもう一人のアーキテクトのような役割を果たすことができる。LLMは追加の設計オプションをブレインストーミングするのが得意で、トレードオフを説明できる。

また、LLMに全体アーキテクチャの決定過程の記録（ADR）の作成を依頼することさえもできる。特に、LLMに入力するのに十分なほど要件を明確に考え、記述させるのであれば、これは最初のパスには有用である。しかし、すべてのやりとりと同じように、決してそれが正しいと思い込んではならない。なぜなら、LLMは正しく聞こえるが、実装するには実現不可能な言葉を吐き出すかもしれないからである。

まとめ

アーキテクトは、AIの誇大広告と実際に実装可能なソフトウェアを区別する必要がある。GenAIやLLMには魔法のようなものはない。AIの要素をいつ、どこで、どのように使うかは、伝統的なトレードオフ分析による。どんな新しいソフトウェアでも、その機能に慣れるための一つの方法は、それを定期的に使うことだ。アーキテクトは、AIツールを使って意思決定やコミュニケーションのスキルを補強し、より良い設計とチームメンバー間の理解を深めることができる。

この記事はクラークの第三法則から始まった。クラークの第二法則は、「可能性の限界を発見する唯一の方法は、それを少し超えて不可能性の中に踏み込むことである」と述べている。

世の中には誇大広告があふれている。私は、実際の「AI」ツールをソフトウェアシステムで実用的に使用する方法について、実践的なアドバイスを提供できたことを願っている。しかし、私がすべての答えを持っているわけではないことも、何が可能なのかわからないことも確かだ。

時には、誇大広告を信じて不可能なことに挑戦してみるのも役立つかもしれない。もしかしたら、それによって達成できることに驚くかもしれない。

この記事は、iSAQB Software Architecture Gathering 2024のプレゼンテーションから引用した。