1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

「LangChainとLangGraphによるRAG・AIエージェント[実践]入門」でつまずいたことメモ:8章

Posted at

はじめに

「LangChainとLangGraphによるRAG・AIエージェント[実践]入門」の第8章で私がつまずいたことのメモです。

(このメモのほかの章へ:1章 / 2章 / 3章 / 4章 / 5章 / 6章 / 7章 / 8章)

この記事は個人で作成したものであり、内容や意見は所属企業・部門見解を代表するものではありません。

第8章 AIエージェントとは

吉田さんが担当された章です。いよいよAIエージェントのお話です。

8.1 AIエージェントのためのLLM活用の期待

現在のAIはまだまだ指示待ち人間と同じなので、もっと自分で考えて行動するようになって欲しい、というお話です。ついこの間まで、AIが文章を生成してくれたり絵を描いたりしてくれるだけで人間は大喜びしていたのに、AIの進化に合わせて人間の期待もどんどん大きくなっています。

8.2 AIエージェントの起源とLLMを使ったAIエージェントの変遷

「AIエージェント」が1997年にすでに定義されていたことが驚きです。

その後、2013年のWord2Vecの登場辺りで意味を表現できる可能性に盛り上がり、2018年のBERT登場辺りで様々なタスクをこなせる可能性に盛り上がり、2022年にはLLMが人間の能力を超えそうということで盛り上がり、最近では複雑なタスクをこなすための方法が確立されてきてAIエージェントが現実味を帯び盛り上がっている感じでしょうか。

いつものように脱線してしまいますが、ChatGPT - LLMシステム開発大全でも有名なMicrosoftの蒲生さんが、Xでこんなことをつぶやいていました。

これは私もまったく同意見です。この本ではLLMそのものの仕組みなどは解説されていませんが、仕組みを知らないと特性がわからず試行錯誤も非効率になるので、エンジニアとして携わるのであればざっくりとでも把握しておくことをオススメします。

私も蒲生さんが紹介されている書籍2冊で基礎を学んだのですが、手を動かしながら学べるのでオススメです。当時、この本でつまずいた点を今回同様に「つまずいたことメモ」に残していますので、もしよかったら本のお供にどうぞ。

また、これらの本は最近の主役であるTransfomerについての解説がないのですが(Transformer誕生前の本なので)、蒲生さんが紹介されている以下の動画が感動的にわかりやすいです。私のようにTransfomerの勉強で挫折してしまった方はぜひこちらを一度見てください。こんなものが無料で公開されているとは、もう感謝しかありません。

8.3 汎用LLMエージェントのフレームワーク

エージェントという言葉がシステム全体を指していたり内部の1つを指していたりして混乱してきたのでちょっと整理します。

これまでは、LLMを使った1つのロボットを高機能にして(プロンプトを工夫したり外部と連携させたり記憶を持たせたり複数の手順で処理させたり)タスクを実行しようというアプローチでした。
これに対してAIエージェントというのは、できることが異なる複数のロボット達を協調的に動作させることで高度なタスクを実行させようというアプローチみたいです。
一人でなんでもやっちゃうのではなく、各分野の得意な人を集めてきてチームを作って挑もうという、なにか事業が大きくなっていく過程みたいなイメージですね。

8.4 マルチエージェント・アプローチ

前半のSQLを作らせるという例もおもしろいのですが、後半のソフトウェア開発自動化の話がすごいです。いや、すごい時代になってきました。今はまだ実際に人間がやっていることのシミュレーションみたいですが、ウォーターフォールやアジャイルなどとはまた違う、AIエージェントに適した新たなソフトウェア開発の手法が生まれそうです。

8.5 AIエージェントが安全に普及するために

もしかしたら、この項がこの本の中で最も重要な内容かもしれません。AIの提供側は目先の便利さだけで行動してはいけないことがわかります。

またまた本から脱線しますが、私が30年前にIT業界へ入ってこれまでに、多くの技術が便利さ優先で実用化されてしまい、多くの事故が起きてきました。

たとえば、コンピューターが進化して簡単にソフトウェアが作れるようになりました。
でも、皆さんもご存知のとおり、ソフトウェアは一般的な工業製品とは比較にならないほど不具合が多いです。そもそも「バグ」という言葉は、当時は業界の隠語だったのです。でも、一般消費者が普通に使う言葉になってしまいました。人間はソフトウェアを作ることはできても、一般的な工業製品レベルの品質のコントロールはいまだにできないのです。
もちろん、さまざまな事故を経て対策も進みました。たとえば、構造化プログラミングが考案されたり、テスト駆動開発が編み出されたり、ソースコードのバージョン管理が当たり前になったり、お互いがコードをレビューできるオープンソースの文化が生まれたり、不具合があっても簡単に修正ができるようアップデートやパッチの仕組みが当たり前になったりしました。

インターネットの普及も同様です。誰でもネットが使える便利な時代になりました。
でも、ウイルスやマルウェアは今でも猛威を振るい、データ漏洩の事故も頻発し、フェイクニュースに踊らされています。人間はインターネットを作ることはできても、使われ方のコントロールはいまだにできないのです。
もちろん対策も進んでいて、ファイアウォールが高機能になったり、ウイルス対策ソフトが当たり前になったり、企業のデータ管理が法律で厳格化されたり、ファクトチェックの仕組みが生まれたり、学校教育でネットの危険性が教えられるようになったりしました。

もちろん、コントロールできないものは実用化するな!と主張したいわけではありません。それでは自動車すら実用化できなくなってしまいます。そうではなく、リスクをゼロにはできないことを認めた上で、リスクをコントロールするための仕組みも同じくらい力を入れて作らないといけないのです。それは、リスクを最小化するための技術開発かもしれませんし、業界で安全基準を設けることかもしれませんし、利用者側へリスクがあることを啓蒙することかもしれません。

AIの提供側はどうしても便利さに注目して、自分ではコントロールできないものを世に出してしまいがちです。リスクのコントロールについても同時に考えるクセをつけないといけませんね。

いろいろ主語が大きい話をしてしまいましたが自戒をこめて。今回のメモは「ポエム」タグ付けておこう。

8.6 まとめ

ほぼ脱線話で終わってしまいましたが、次章からいよいよAIエージェントのハンズオンです。楽しみ!

(このメモのほかの章へ:1章 / 2章 / 3章 / 4章 / 5章 / 6章 / 7章 / 8章)

1
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?