私が「コンテキストオントロジー」と呼ぶ概念についてうなずいていました - 主に、コンテキストがどこから来て、どのプロンプトで使用されているかを確認できる単一の場所があればいいのにと思うからです。 LLM が応答を生成したり、行動を起こしたりするための有用なコンテキストには、(1) 高レベルの目標、(2) 現在のタスク/重点分野、(3) 関連する過去のタスクからの要約情報、(4) 以前の試みから学んだことなどが含まれます。 エージェントにより多くのことを期待するにつれて (より長いタスク、より複雑なプロジェクトなど)、生のメモリはすぐにトークンの重さとノイズが多くなり、LLM 出力の品質が低下します。ほとんどの複雑な AI アプリには、ある種の要約されたコンテキスト (私は推測します)、および複数のコンテキスト ソースがあります。 ここでの考え方は、保存するコンテキスト*、それを構造化する方法、およびシステム内の各プロンプトに対して何を取得するかについてのオントロジーを定義することです。 ※店舗とは、必ずしもAIのDB内という意味ではありません。IMPO では、アプリに保存されているデータを AI のメモリの一部と見なす方が全体的に感じられます (API / MCP接続など)。おそらくこのオントロジーもこれを指定する必要があります。 さらに一歩進んで、これをAIが管理およびテストできる動的なオントロジーにし、エージェントがコンテキスト管理を自己改善できるようにRL環境に貼り付けることができます(仮説上) 要約戦略をここに入れるべきかどうかはわかりませんが、大まかに言うと理にかなっています。ほとんどの人は取り込み時に情報を要約するため、変更するたびに以前の取り込みを再要約する必要があるため、(変更のテストと自己改善のため)が、この問題は関係なく続くと思います。 ここは特に新しいものは何もないと思います。私が見てきたさまざまな戦略をマッピングするために、内部でフレームワークを作成しようとしながら、声に出して考えています。