この進行中の Docker Labs GenAI シリーズ AI開発者ツールのエキサイティングな空間を探ります。 Dockerでは、誇大広告なしでオープンに探求できる広大な範囲があると信じています。 私たちは探索を共有し、開発者コミュニティとリアルタイムで協力します。 開発者はGitHub Copilotのようなオートコンプリートツールを採用し、チャットを使用していますが、AIツールがソフトウェアのライフサイクル全体を通じて、より具体的なタスクやインターフェースを支援する可能性は大いにあります。 したがって、私たちの探求は広範囲に及びます。 ソフトウェアをオープンソースとしてリリースするので、私たちと一緒にプレイしたり、探索したり、ハックしたりできます。
PDFを一連の画像にどのように変換しますか? 現代的な提案は、Claude や GPT に ImageMagick のような CLI コマンドを書かせることかもしれません。 その思考の流れをたどってみましょう。
「ImageMagickを使用してPDFを画像の束に変換するにはどうすればよいですか」のようなプロンプトを入力すると、確かに解決策と思われるものが得られます。
Imagemagick includes a command-line tool called convert which you can use to convert PDF files into images. Here's how you can do it:
1. Open your terminal
2. Change directory to where your PDF is located:
```
cd /path/to/your/pdf
```
3. Use the following command to convert the PDF into images (in this case JPEG):
```
convert -density 300 -quality 100 your_file.pdf output_name.jpg
```
その後、エージェントは convert がどのように機能するかを説明し、「これらのコマンドを実行する前にImageMagickがインストールされていることを確認してください」という提案で終了します。
ただし、ImageMagickがインストールされているかどうかを心配する代わりに、Dockerをツールプロバイダーとして使用し、先に進んでコマンドを実行するように促しましょう。このシリーズを読んでいる方は、Markdownファイルを使用してツールとプロンプトを混在させていることをご存知でしょう。 最初に試したプロンプトは次のとおりです。
---
tools:
- name: imagemagick
---
# prompt user
Use Imagemagick to convert the family.pdf file into a bunch of jpg images.
このプロンプトを実行した後、LLM はツール呼び出しを生成し、 Docker ランタイムで実行し、 family.pdf を 9 つの.jpgに正常に変換しました ファイル(私の family.pdf ファイルは9ページでした)。
図 1 は、 VSCode 拡張機能からのフローを示しています。
LLM に十分なコンテキストを提供したので、この ImageMagick バイナリの呼び出しを計画できます。 また、このツールは Docker Hubで利用できるため、「ImageMagickがインストールされていることを確認する」必要はありません。これは、 docker run を直接使用する場合と同等のコマンドです。
# family.pdf must be located in your $PWD
docker run --rm -v $PWD:/project --workdir /project vonwig/imageMagick:latest convert -density 300 -quality 300 family.pdf family.jpg
ツールエコシステム
これはどのように機能しましたか? このプロセスは、次の 2 つのことに依存していました。
- ツールの配布と検出 (Docker Hub にツールをプルして 、Docker Desktop ランタイムに配布する)。
- エージェントツールインターフェースの自動生成。
このプロジェクトを最初に始めたとき、各ツールのインターフェースの設計には時間がかかるため、小さなツールセットから始めると予想していました。 私たちは、これらのエージェントワークフローで使用するために準備されたツールのエコシステムをブートストラップする必要があると考えました。
しかし、私たちは、はるかに一般的なアプローチを使用できることを学びました。 ほとんどのツールには、コマンドラインヘルプ、例、マニュアルページなどのドキュメントがすでに付属しています。 各ツールを特別なものとして扱うのではなく、エージェントがドキュメントを読み、再試行することでエラーに対応するアーキテクチャを使用しています (図 2)。
ツールを試すプロセスは、開発者としてコマンドラインで行うことと似ています。 コマンドラインを試し、ドキュメントを読み、コマンドラインを調整して、再試行してください。
この種のループの価値は、私たちの期待を変えました。 ステップ1は、ツールをDocker Hubにプルし、エージェントがすぐに使えるドキュメントだけでツールを使用できるかどうかを確認することです。 また、オープンソースソフトウェア(OSS)ツールを nixpkgsから直接引っ張ってきて、何万もの異なるツールにアクセスして実験できるようにしています。
Docker はランタイムをホスト オペレーティング システムから分離し、nixpkgs エコシステムとメンテナーは OSS ツールの豊富なソースを提供します。
予想通り、パッケージングエージェントは依然として問題に直面しており、ツールのパッケージ化方法を再計画する必要があります。 たとえば、上に示したプロンプトでは、最初の試行で正しいツール呼び出しが生成されている可能性がありますが、ImageMagick コンテナは最初の実行で失敗し、次のひどいエラー メッセージが表示されます。
function call failed call exited with non-zero code (1): Error: sh: 1: gs: not found
さいわい、そのエラーを LLM にフィードバックすると、正常に実行するには Ghostscript という別のツールが必要である convert 提案されました。私たちのエージェントは今日、これを自動的に修正することができませんでした。 ただし、イメージのビルドをわずかに調整したため、 vonwig/imagemagick:latest の「最新」バージョンではこの問題がなくなりました。 これは、私たちが一度だけ学ぶ必要があることの一例です。
LLMは自分で convert を見つけ出しました。 しかし、そのエージェンシーはツールの追加から来ました。
Docker Labs の GenAI シリーズを読んで、私たちが取り組んできたことの詳細をご覧ください。
さらに詳しく
- Docker Newsletter を購読してください。
- Docker デスクトップの最新リリースを入手します。
- 質問がありますか? Docker コミュニティがお手伝いします。
- ドッカーは初めてですか? 始めましょう。