👫

ChatGPT-4とのペアプログラミング体験: PDF要約＆Q&Aサービス開発の所感

2023/03/25に公開

こんにちは！本記事ではChatGPT4を使ってPDF文書を要約し、質問応答サービスを提供するWebアプリケーションを開発した記録を紹介します。このサービスは、論文を読む際に役立つサポートツールとして作成しました。

記事では、サービス開発においてChatGPT-4がどのように活用できるか、また、どのようにペアプロを行うと効果的かといった内容をシェアします。

この記事を通じて、AI技術とエンジニアがどのように協力し、新たな価値を生み出すことができそうか、という所感を伝えられたら嬉しいです。

gpt-pdf-summarizerの概要

今回開発したgpt-pdf-summarizerは、PDF文書を読み込み、要約を提供し、さらにその要約に基づいた質問応答を行うことができるサービスです。

これにより、論文を効率的に理解し、さらに疑問点についてもAIと対話を行うことが可能となります。

サービスのスクリーンショット

スマホからの利用も可能です。

私自身、隔週で勉強会で論文紹介を行っており、そのプロセスを効率化したいと感じていたので開発しました。

なお、コードはこちらから利用できます↓

ちなみに、勉強会のURLはこちら↓

gpt-pdf-summarizerの実装内容

実装内容は非常にシンプルです。まず、文章を一定のサイズに区切り（チャンクと呼ぶ）、それぞれのチャンクの内容を翻訳するプロンプトを用いて、GPTに繰り返し命令を送ります。これにより、各チャンクごとに要約を生成することができます。

すべてのチャンクの要約が完了したら、その会話の続きとして会話ができるようにチャットが開きます。以下の図で実装内容を表しています。

なお、チャンクで区切ってAPIに渡してるのは、当初、自分がAPIが一回のpromptにつきToken数の上限が決まっていると勘違いしていたためですorz.. 実際は、会話にまつわる入出力すべてを含めて上限が設定されているので、もう少し良い渡し方がありそうです。

現状、下記のいくつか使いづらいポイントがあるので、ちょこちょこ修正したいと思っています...!

会話が長くなるとtoken数上限をオーバーし、エラーを吐いてしまう
- (修正例)
- 翻訳するページを指定できるようにする
- 翻訳前にtoken数を計算して、早期エラーを吐く
- 先に部分ごとのサマリ一覧を吐きだし、選択した箇所の周辺領域だけを再度読み込ませて会話をスタートさせる
messageを直列で投げているので応答が遅い
- (修正例)
- 並列で処理する。ただし、前後の文脈を記憶できなくなるので各文章を短く要約した後にconcatするなど工夫が必要そう

gpt-pdf-summarizerの使い方

gpt-pdf-summarizerの使い方は下記のとおりです。詳細はreadme.mdを参照してください。

#リポジトリをクローン
git clone https://github.com/your_username/pdf-summarizer.git
cd pdf-summarizer
# dockerを起動
docker-compose up --build
# web uiにアクセス
http://localhost:8501

以上の手順で、gpt-pdf-summarizerを簡単に使い始めることができます。

開発時のやりとり

開発時のChatGPT4とのやり取りは、superpower-chatgptというchrome extensionを使ってmarkdown形式で(ほぼ)すべて書き出し、GitHubに公開してます!

以降の章ではやりとりの中身を抜粋して解説します。

やりとりの一部

サービスの作り方

gpt-pdf-summarizerの開発プロセスは、最初にGPT-4とブレインストーミングを行い、開発方針を決定しました。GPT-4にマイルストーンを作成してもらい、必要な技術や手順を把握しました。

何から手を付ければよいのか指示してもらえるので走り出しがスムーズでした

その後、GPT-4にプロトタイプの開発を依頼し、環境のセットアップやPDFを読み込むために使用するライブラリなど、知らなかった情報も提供してもらいました。

Dockerとかたまに触るツールの使い方とかをぱっと教えてもらえるのは便利

実装の雛形もお願いしました。

streamlitとFastAPIの疎通みたいな詰まりそうなポイントも現状のコード構成に沿って提供してくれる

しかし、開発途中からは、必要とするコンテキスト情報がChatGPTが記憶できる量より多くなり、提供されるコードが不正確になってきたため、自分でコードを読み込んで実装しました。

例えば、提供されるライブラリのバージョンが古く、正常に動作しない場合や、実装が増えるごとに、他のコードとの整合性が取れないコードが提供される場合がありました。

ChatGPTの得意なこと・任せてよかったところ

ChatGPTは、プロジェクトの様々な段階で役立つことがありました。特に得意なことや、任せて良かった点は以下の通りです。

1. ブレインストーミング・壁打ち:

ChatGPTは、ブレインストーミングの際に有益なアイデアを提案してくれました。マネタイズ方法やマイルストーンの設定など、具体的なアドバイスが参考になりました。

マネタイズするならどんな方針があるか、のような、自身が詳しくない分野も今のコンテキストに沿って回答してもらえるのは便利

また実装で悩んだポイントが有ったときに、気軽に壁打ちできるのも体験が良かったです。

メリットデメリットの提供してもらうと比較しやすい

2. 利用人口が多い技術に関する質問:

Docker-composeやプロダクト開発のノウハウ、Webアプリのディレクトリ構造など、多くの人が利用している技術に関する質問に対して、ChatGPTは正確な回答を提供してくれました。また、便利なシェルスクリプトの作成などもサポートしてくれました。

ディレクトリ構造の雛形やそれを構築するshellスクリプトを提供してもらった

3. 入力情報を考慮した出力形式の変換:

ChatGPTは、これまでの会話をもとにドキュメントを作成してくれる能力があります。例えば、READMEの作成などで役立ちました。

また、ChatGPTがどのように実装を理解しているかを確認するために、シーケンス図の作成を依頼することもできました。これは、自分の頭の整理にも役立ちました。

このように、ChatGPTはプロジェクトのいくつかの側面で助けとなりました。特にブレインストーミングや一般的な技術に関する質問、そして入力情報に基づいた出力形式の変換が得意であることが分かりました。

ChatGPTの苦手なこと

ChatGPTは多くの点で役立ちますが、苦手な部分も存在します。以下がそのような例です。

1. 最新ライブラリに関する開発方針:

ChatGPTは、最新のライブラリに関する開発方針やベストプラクティスについては十分に把握していないことがあります。これは、トレーニングデータが一定時点までのものであるため、最新の情報が含まれていないことが原因です。

2. ディレクトリ構造・他のコードとの相互作用を考慮したバグの修正:

ChatGPTを使った開発では、ディレクトリ構造や他のコードとの相互作用を考慮したバグ修正に苦戦しました。したがって、現状はコードの全体像を把握しながらバグ修正を行う際は、開発者自身が手を加える必要があります。ただ、これは現在のChatGPTのインターフェースや会話の記憶量が大量のコードを理解し実装するというユースケースに特化していないだけであり、今後はCopilot Xの誕生などで、この辺りも解消したAIツールがでる予感がします。

3. 自分が要件定義できていないコードの構造化:

ChatGPTは、開発者の意図や背景情報を与えられた情報からしか理解できないため、明確な要件定義がない場合にコードを効果的に構造化することが困難な場合があります。そのため、開発者は、明確な要件定義を定め、ChatGPTと協力してプロジェクトを進める必要があります。明確な要件定義を考えることは困難ですが、これも、ChatGPTと協力して要件定義を創発することで、効率よく実現することができそうです。

次ペアプロするときの改善点

次回以降、より効果的にペアプロするための改善点は、以下のように考えています。

1. 要件の明確化:

GPTに質問を投げる前に、私自身が要件をより具体的に決めておくべきだと感じました。曖昧な要件では、GPTから得られるアウトプットも微妙であり、微妙なアウトプットを意図したものに調整していくのは、かなり骨がいる作業でした。。。
そのため、曖昧性の低い質問を最初にすることで、より良いアウトプットが得られることが期待できます。また、適切なプロンプトは、GPTとの会話を通じて作成することもできると思います。

2. 役割を細分化し、それぞれ振る舞ってもらう:

今回はほぼ一つのスレッドを使って、開発をしていましたが、序盤に与えた情報を忘却してしまうので、役割に応じてスレッドを立てるのが良いのかなと思いました。たとえば、プロジェクトマネージャーやプロダクトマネージャー、UXデザイナーなどの異なる役割を持たせた会話に分けて、それぞれの役割に応じた振る舞いをGPTにさせることで、多様な視点からのアドバイスや提案を得ることができそうだなとおもいます。(記憶量が増えれば1スレッドで事足りるかもしれない)

他の方の例ですが、プロジェクトマネージャーとして振る舞ってもらい、スクラム開発をともに進める、なんて使い方も便利そうです。
また、この記事を読んで、ChatGPTの能力を引き出すには、引き出したい能力に対して自身が一定以上の知見がないと難しいだろうなと感じました。(スクラム開発の知見や経験がないと、このような指示はできなそうと感じた)

今後の開発フローの変化（予想)

ChatGPTをはじめとするAI技術の進歩によって、開発フローはさまざまな面で変化するでしょう。以下に、そのような変化の可能性を挙げています。

1. 特化型AIモデル/サービスの登場によるさらなる効率化:

現在のChatGPTは会話に特化したモデルであり、開発に対して特化したモデルではないです。今後サービス開発やコーディングなどに特化したモデルやサービスが登場することで、開発効率が飛躍的に向上する可能性があります。例えば、Copilot Xのようなコーディングに特化した学習とインターフェースを持ったサービスが提供されれば、更に開発フローは変化していくでしょう。また、フローだけでなく、開発者の母集団や必要なスキルセットも変わっていきそうです。

2. 実装コスト低減によるトレードオフや最適手段の変化:

AI技術の進歩により、プロトタイプの作成など、サービスの実装コストが確実に下がります。ユーザーへの価値検証やMVPの作成は、議論するよりも、AIを活用して実際に動くコードを書いて検証することが一般的になるかもしれません。その結果、プロジェクトの進行速度や柔軟性が向上することが期待されますし、どのような手段を取るのが最適化、という意思決定も変わるかもしれません。

これらの変化を受けて、開発フローは新たな形に進化し、開発者とAIが協力してプロジェクトを推進する新しいスタイルが確立されることが期待されます。最適な手法も変わってくるため、AI技術の進歩に合わせて開発者が適応し、効果的な開発フローを確立していくことが重要そうです。

まとめと今後の展望

今回は、GPT-4を利用した開発プロセスを通じて、AIと共同でプロジェクトを進める新しいアプローチを試みました。

正直なところ、LLMの関連技術は日々ものすごい速さでリリース、進化しており、今後のプロダクト開発においてどのように進めるべきか正確な答えは分かりません。

例えば、今回作成したツールは、OpenAIが提供する公式プラグインによって簡単に置き換えられてしまいそうです。w

しかし、LLMのような革新的なツールを早期に使いこなすためには、アイディアや成果物が他の企業やツールに取って代わられるリスクを受け入れながら、情報を取り入れつつ、自分で積極的に触れることが近道だと感じます。使いこなすための知識はインターネット上でも共有され始めたばかりで、試してみないと分からないことが多いと感じているからです。

そういった意味で、今回GPT-4を使ったプロダクト開発を行うことで、LLMの可能性や限界がより明確になり、良い経験となりました。また、新たな可能性が広がっていることをより実感し、楽しく開発できました！

今後も別のアイデアを考えて、LLMを活用して開発をしたいと思っています。次回はさらに使いこなし、効率的に作っていきたいです！それでは〜

おまけ

お決まりですが、やはりブログも壁打ち・レビューしてもらいました。🙏