上記のプロセスは、ユーザーが 1 つの質問しかできない場合に適しています。しかし、このアプリケーションでは追加の質問も許可されており、これによりいくつかの追加の複雑さが生じます。たとえば、新しい質問を LLM に送信するときに追加のコンテキストとして含めることができるように、以前の質問と回答をすべて保存する必要があります。
このアプリケーションのチャット履歴は、Elasticsearch と Langchain の統合の一部である別のクラスであるElasticsearchChatMessageHistoryクラスを通じて管理されます。関連する質問と回答の各グループは、使用されたセッション ID への参照とともに Elasticsearch インデックスに書き込まれます。
前のセクションで気づいたかもしれませんが、LLM からの応答はチャンク単位でクライアントにストリーム配信されますが、完全な応答でanswer変数が生成されます。これは、各やり取りの後に、応答と質問を履歴に追加できるようにするためです。
クライアントがリクエスト URL のクエリ文字列でsession_id引数を送信する場合、その質問は同じセッションでの以前の質問のコンテキストで行われたものと見なされます。
このアプリケーションがフォローアップの質問に対して採用しているアプローチは、LLM を使用して会話全体を要約した要約された質問を作成し、それを検索フェーズで使用することです。この目的は、潜在的に大量の質問と回答の履歴に対してベクトル検索を実行することを避けることです。このタスクを実行するロジックは次のとおりです。
これは主な質問の処理方法と多くの類似点がありますが、この場合は LLM のストリーミング インターフェースを使用する必要がないため、代わりにinvoke()メソッドが使用されます。
質問を要約するには、ファイル **api/templates/condense_question_prompt.txt` に保存されている別のプロンプトが使用されます。
このプロンプトには、セッションのすべての質問と応答に加えて、最後に新しいフォローアップの質問が表示されます。LLM は、すべての情報を要約した簡略化された質問を提供するように指示されています。
LLM が生成フェーズで可能な限り多くのコンテキストを取得できるように、取得されたドキュメントとフォローアップの質問とともに、会話の完全な履歴がメインプロンプトに追加されます。以下は、サンプル アプリケーションで使用されるプロンプトの最終バージョンです。
要約された質問の使用方法は、ニーズに合わせて調整できることに注意してください。一部のアプリケーションでは、生成フェーズでも要約された質問を送信すると、トークン数も減ってより効果的であることがわかります。あるいは、要約された質問をまったく使用せず、常にチャット履歴全体を送信すると、より良い結果が得られるかもしれません。これで、このアプリケーションがどのように動作するかを十分に理解し、さまざまなプロンプトを試して、自分のユースケースに最適なものを見つけることができると思います。