Skip to content

Semantic Memory Integration into Copilot Chat

Pre-release
Pre-release
Compare
Choose a tag to compare
@glahaye glahaye released this 25 Sep 20:16
· 287 commits to main since this release
0.5
2244ab2
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.

BREAKING UPDATE

This change introduces semantic-memory to copilot-chat:

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 #152

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

Screenshot 2023-09-18 090927

image

image

image

Full Changelog: 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

Contributors

crickman
Assets 4