BREAKING UPDATE

This change introduces semantic-memory to copilot-chat:

• https://github.com/microsoft/chat-copilot/blob/main/README.md
• https://github.com/microsoft/chat-copilot/blob/main/webapi/README.md
• https://github.com/microsoft/chat-copilot/blob/main/memorypipeline/README.md

This change represents a signifant shift our memory architecture with the promise to support use-cases beyond what is possible with the semantic-kernel connectors.

To maintain continuity of service for a existing deployments, we highly recommend upgrading to Release 0.4 prior to deploying this release for the application to support "maintenance mode".

As part of this shift, existing chat memories will be automatically migrated: however, any documents previously imported must be re-imported. For additional details, please refer to migration section at the end of these release notes.

An immediate benefit to this switch is that chat-copilot will no longer create 3 indexes (or containers) per chat in the vector database. Only a single index is utilized for the application. This removes the maximum-index constraint for copilot chat

A downside to this shift is that support for Postgres and Chroma have been temporarily removed.

Co-authored-by: Tao Chen TaoChenOSU@users.noreply.github.com Co-authored-by: Teresa Hoang 125500434+teresaqhoang@users.noreply.github.com

What's Changed

• Semantic Memory Integration into Copilot Chat by @crickman in https://github.com/microsoft/chat-copilot/pull/152

Please sync to the current state of main to realize subsequent stabilization updates.

Full Changelog: https://github.com/microsoft/chat-copilot/compare/0.4...0.5

Memory Migration

Migration of existing chat memories is automatically triggered when the expected index (default: chatmemory) does not exist. During migration, the application will be held in maintenance-mode (no chats) and once completed, the previous indexes may be removed.

Note: Chat history is always preserved. Memory migration affects only the short-term and long-term memory extractions for each chat.

Migrate existing memories:

1. Ensure capacity exist to create one new index (chatmemory) and also create "global-documents" index, if it doesn't already exist.
2. Deploy updated API service
3. Deploy updated APP site
4. Any request will trigger migration (/healthz)
5. Verify webapp functioning (chat)
6. Verify `chatmemory`` index exists
7. Remove all indexes that are not chatmemory

Reset memory migration

If for some reason migration is not successful or needs to be reset:

1. Stop API service
2. Remove chatmemory and global-documents indexes.
3. Start API service
4. Any request will trigger migration (/healthz)
5. Verify webapp functioning (chat)
6. Verify `chatmemory`` index exists

Opt-out of migration:

To avoid memory migration, remove the existing indexes ahead of time:

1. Stop API service
2. Delete all existing indexes.
3. Deploy updated API
4. Deploy updated APP