Difyコミュニティでエージェント履歴のプロンプト重複読み込みが報告、長い会話でAPIのメモリ使用量が増加する可能性

10月22日に投稿されたDifyの技術報告は、長い会話における性能上のボトルネックが、API側での履歴データ読み込みにあると指摘している。報告者によると、自前でホストするバージョン1.17.1と、同日に確認したメインブランチの両方で、この挙動が見られたという。また、PostgreSQLで実行できる再現コードも提供されている。現時点の証拠はコミュニティによるテストに基づくもので、すべてのデプロイ環境で同じ結果になるとは断定できない。問題報告

報告の分析によると、organize_agent_historyは会話全体の完全なメッセージ行を読み込む。その中でMessage.messageには、各ターンの生成時に使われたプロンプトが保存されている。各ターンのプロンプトにそれ以前の会話がすべて含まれる場合、第nターンのデータには前のn−1ターン分の内容が再び含まれる。そのため、すべての行を一度に読み込むと、読み込まれるテキスト量は二次的に増加する可能性がある。一方、履歴の再構築で実際に使われるのは質問、回答、エージェントの思考記録であり、この大きなプロンプト欄は必要ない。技術解説とコード

報告者は合成した700ターンの会話でテストを行い、履歴の作成1回あたりRSSが約1.36 GB増加し、約4.2秒かかったと測定した。必要なカラムだけを選択するようload_onlyを使うと、RSSの増加は10.3 MB、所要時間は0.80秒に減少した。これは隔離されたテストであり、本番環境で同じ改善が得られる保証ではない。また、プロセスがすべてのメモリを永続的に保持することを示すものでもない。測定結果

修正の方向性には、明確なORM上の根拠がある。SQLAlchemyのドキュメントによると、load_onlyを使うと、指定されていない大きなカラムをクエリで読み込まずに済む。ただし、その後にアクセスすると遅延クエリが発生する可能性がある。raiseloadを使えば、予期しないアクセス時に例外を発生させられる。つまり、検証ではメモリ使用量の減少に加えて、後続の処理経路でプロンプト欄が再読み込みされないことも確認する必要がある。SQLAlchemyドキュメント

運用チームは、容量テストで会話のターン数を考慮し、履歴作成にかかる時間、プロセスメモリ、SQLクエリをそれぞれ観察するとよい。エンジニアリング面では、カラム削減の前後で履歴の内容が一致するか、ツールの記録が大きい会話でもボトルネックが残るかを確認する必要がある。これらは報告から導かれる検証上の提案だ。実際の影響範囲を判断するには、メンテナーによる確認、修正のマージ、バージョンのリリースを待つ必要がある。