Cisco Japan Blog
Share

ネットワーク アーキテクチャ考 (37) AI とネットワークシステム


2023年11月10日


人間の知性と計算可能性を結びつける取り組みは、人間そのものの特性や人間の創造性を解明する、という面からも非常に興味深いものです。

人間の脳が、人体の全ての制御を司る司令塔ではなく、実はかなりの部分が受動的である、ということが解明されつつありますが、それと並行して AI 研究においても、予め「フレーム」を与えるのではなく、大量なデータからボトムアップに学習する機械学習が成功につながった、ということは、象徴的なことではないかと思います。

AI 研究の歴史は長く、古くはチューリングテスト [*1] や「中国語の部屋」[*2] などの思考実験があり、2000 年代に入ると「シンギュラリティは近い」という予測 [*3] がされましたが、2022 年 11 月に発表された ChatGPT により、一気に、多くの人が AI を広く実用する状況に至りました。今や話題にならない日は無い程で、技術だけでなく、国家や国際社会における AI に関するルールづくりなども大きな話題になっています。活況であることは良いことですが、行き過ぎた規制はイノヴェーションを阻害する可能性もあるので、技術者の冷静かつ理に適った関与が求められます。ネットワークシステムを扱うエンジニアやアーキテクトがいかに AI に取り組むか、ということも今後ますます重要になります。

そこで今回は、ネットワークエンジニアやアーキテクトが探求すべき、6 つの AI への取組みをご紹介します。

  1. AIOps
  2. RAG(Retrieval Augmented Generation) 検索拡張生成
  3. AI for Networking
  4. AI + Security
  5. Responsible AI
  6. AI Infrastructure

 

AIOps

これは言うまでもありませんが、IT オペレーションにおけるAI活用です。IT 運用の可観測性向上、インサイトの蓄積と利用、システム頑健性の強化、そして自動化など。

 

RAG (Retrieval Augmented Generation) 検索拡張生成

大規模言語モデル(LLM)は非常に強力で、文献の要約、翻訳などに実用されていますが、一方、時として不正確性、幻覚(hallcination)などが問題になることがあります。この問題の原因のひとつとして、その知識が予め訓練したデータに依存していることが挙げられています。RAG は、外部のデータベースを参照し、LLM に RAG で取得した情報を組み込むことにより、より正確な回答を可能にします。ある領域の専門家がそのデータベースを常に適切なものに更新すれば、大規模言語モデルの質や正確性を向上することができます。

 

AI for Networking

そしてもちろん、ネットワーキングのために AI をどう活用するか、はネットワークエンジニア・アーキテクトにとってど真ん中の話題です。どのようにルーティングやクラスタリングを最適化するか、どのように定常状態と異常を区別するかするか、どのようにトラフィック効率やユーザーエクスペリエンスを向上するか、そしてそれらのフィードバックループを自動化させることができるか。特に、IoT デバイスや無線基地局など、それ自体では電力的にも計算能力的にも限界があるデバイスにとっては、必須の技術になると考えられます。この話題については、先日のONIC (Open Networking Conference) 2023 で取り上げましたので、ぜひご覧ください。Cisco Fellow で現在ネットワーキングのための 数々のAI / ML を率いる JP Vasseur が、Video Letter形式で講演を送ってくれました。イントロダクションおよび翻訳を私が担当しました。(公開されるイントロダクション資料に、日本語字幕つきのVideoリンクを入れてあります。)

 

AI + Security

セキュリティと AI は密接に関連します。AI for Security(AI を利用した可視化、異常検出、復旧など)と、Security for AI(AI システムやその活用に関するセキュリティ対策)の双方の話題があります。これについては、別途考察の機会をつくりたいと思います。

 

Responsible AI

AI は、人間を助けるものであって、人間に取って代わるものではありません。また、AI には限界があり、人間がループに入る必要があります。そして、AI が人を傷つけるリスクは現実に存在し、深刻なものになる可能性もあるため、AI ソリューションを提供する側は、責任ある方法で AI の機能を設計する必要があります。どういうアルゴリズムでその結果に至ったか、参照したデータセットは適切であったか、などを可視化するフレームワークが必要です。

現在 Cisco では、Responsible AI(RAI)Framework をオープンソース化し、パフォーマンス、ロバスト性、説明可能性、公平性など、AI システムのさまざまな側面を測定するメトリクスを提供しようとしています。

 

AI Infrastructure

6 つ目、最後になりますが、ネットワークエンジニア・アーキテクトにとっては今一番ホットなトピックかもしれません。それは、AI workload を支えるインフラストラクチャ(コンピューティング、DPU / SmartNIC 、ネットワークファブリック)がどうあるべきか、という話題です。

この話題も非常に広く深く、別途詳しく考察の機会をつくりたいと思いますが、すごくざっくり言うと、

  • AI workload が大規模化、大容量化しており、電力や環境などサステナビリティの観点からも、アーキテクチャ変遷が求められる
  • トラフィック特性も多様化している(例えば、Training と Inference では特性が異なる)
  • これまでは GPU centric なアーキテクチャが主流だったが、これからは非ノイマン型データフローアーキテクチャが台頭する
  • これらの要請に経済合理性と規模を以て応えるためには、オープン技術とエコシステムが必要になる

この辺りの話題は、先日の MPLS Japan 2023 「AI / HPC セッション」で大いに議論されました。(MPLS Japan は、MPLS という技術を早期から日本で推進してきたコミュニテイが中心となり、革新的な技術やアーキテクチャについて議論する場になっています。ここ最近は MPLS とは関係ないトピックがテーマになっていますが、「MPLS を世界に先駆けて普及させた精神」を尊重し(?!)、カンファレンスのタイトルは今も MPLS Japan のままとされているそうです。)

ネットワークファブリックに特化した話をすると、現在は、DCQCN(RoCEv2 + PFC)が主流ですが、将来については問題も指摘されており、より効率よく、よりオープンな方式が求められています。そこで、先日の AI / HPC セッションでは、現行 Nexus による DCQCN と可観測性、将来的には Silicone One による Fully Scheduled Fabric、Ultra Ethernet Consortium [*4] の取り組み、また IPv6 / SRv6 Path Trace のHPCC (High Precision Congestion Control) への適用可能性をお話しさせていただきました。その資料もぜひご覧いただければ幸いです。

この話題は、これからのコンピューティングとネットワーキングの融合を考えるにあたっても、非常に興味深いものです。

 

References:

[*1] https://en.wikipedia.org/wiki/Turing_test

[*2] https://en.wikipedia.org/wiki/Chinese_room

[*3] https://en.wikipedia.org/wiki/The_Singularity_Is_Near

[*4] https://ultraethernet.org/

Tags:
コメントを書く