Release v6.0.0 into Main#577
Conversation
* Feature/rag backend (#521) * Add collection rag schema * Add collection repo * Add collection service * Add collections CRUD API * Add Collections Table * Update document ingestion using collections * Update delete docs from collections * Add sdk and collection tests * Add RAG Collection API and Tests * rag collection UI * default collection deletion
Co-authored-by: jmharold <jmharold@amazon.com>
…ing in create-mcp-server.ts
… management visibility (#564)
Extend collections to Bedrock Knowledge Base. Supports creating single collection per repository based on supplied datasource. Adds Ingestion rules for event-based triggers. Filters RAG results by selected collection. Adds no chunk ingestion strategy.
…cific suffix to avoid naming conflicts. The suffix is derived from the stack name, ensuring compliance with AWS character limits.
…capsulate the deployment process in a try-except block. This change ensures that any exceptions during the deployment are logged with event details for better debugging.
…workflow configuration
Version 6.0.0 Release SummaryOverviewVersion 6.0.0 represents a major release introducing significant infrastructure enhancements, new features, and breaking changes to the LISA platform. Major Features1. LISA MCP (Model Context Protocol) Solution
2. RAG Collections Infrastructure
3. CI/CD Pipeline Enhancements
Breaking Changes
|
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| with: | ||
| ref: develop |
There was a problem hiding this comment.
The ref: develop parameter has been added to the checkout action. This change hardcodes the workflow to always check out the develop branch instead of the current branch being tested. For a nightly end-to-end test workflow, this may cause the workflow to test the wrong branch. Consider whether this should reference the branch that triggered the workflow or if this is intentional for nightly runs. If the intent is to always test the develop branch, this should be documented clearly.
| role-session-name: GitHub_to_AWS_via_FederatedOIDC | ||
| role-duration-seconds: 7200 | ||
| - name: PR Review | ||
| uses: tmokmss/bedrock-pr-reviewer@v1 |
There was a problem hiding this comment.
The action tmokmss/bedrock-pr-reviewer@v1 is a third-party action from an external maintainer. Consider verifying that this action is actively maintained, trustworthy, and compatible with your security and compliance requirements. Alternatively, consider implementing a custom GitHub Action or using an officially supported AWS service for code reviews.
|
|
||
| jobs: | ||
| review: | ||
| environment: dev |
There was a problem hiding this comment.
The job is configured to run in the dev environment. Ensure this environment has the appropriate protection rules and approval requirements for production-grade code review workflows. Consider whether this should run in a more restricted environment or if additional safeguards are needed.
| */ | ||
| import { Construct } from 'constructs'; | ||
| import { BaseProps } from '../../../schema'; | ||
| import { BaseProps, VectorStoreStatus, } from '../../../schema'; |
There was a problem hiding this comment.
The import statement has a trailing comma after VectorStoreStatus which may cause linting issues. Ensure this follows your project's linting rules.
| import { BaseProps, VectorStoreStatus, } from '../../../schema'; | |
| import { BaseProps, VectorStoreStatus } from '../../../schema'; |
| super(scope, id); | ||
|
|
||
| const { config, executionRole, parameterName, role, vectorStoreConfigTable, vectorStoreDeployerFnArn } = props; | ||
| const { config, createBedrockCollectionFnArn, executionRole, parameterName, role, vectorStoreConfigTable, vectorStoreDeployerFnArn } = props; |
There was a problem hiding this comment.
The destructuring now includes createBedrockCollectionFnArn which is used to create a Lambda function reference. Ensure this ARN is properly validated before being passed to lambda.Function.fromFunctionArn() to prevent runtime errors with invalid ARNs.
| item: { | ||
| repositoryId: tasks.DynamoAttributeValue.fromString(sfn.JsonPath.stringAt('$.body.ragConfig.repositoryId')), | ||
| status: tasks.DynamoAttributeValue.fromString('CREATE_IN_PROGRESS'), | ||
| status: tasks.DynamoAttributeValue.fromString(VectorStoreStatus.CREATE_IN_PROGRESS), |
There was a problem hiding this comment.
The status is now using the VectorStoreStatus.CREATE_IN_PROGRESS enum constant instead of the hardcoded string 'CREATE_IN_PROGRESS'. This is a good improvement for maintainability. However, verify that VectorStoreStatus enum is properly exported and contains all the status values used throughout this file (e.g., CREATE_IN_PROGRESS, CREATE_COMPLETE, CREATE_FAILED, UPDATE_IN_PROGRESS, UPDATE_COMPLETE, UPDATE_COMPLETE_CLEANUP_IN_PROGRESS).
|
|
||
| // Task to check the deployment status using a Lambda function | ||
| const checkDeploymentStatus = new tasks.CallAwsService(this, 'DescribeStack', { | ||
| const checkDeploymentStatus = new tasks.CallAwsService(this, 'CheckDeploymentStatus', { |
There was a problem hiding this comment.
The task ID was changed from 'DescribeStack' to 'CheckDeploymentStatus'. Ensure this change doesn't conflict with any other state machine state IDs and that the new name accurately reflects the task's purpose.
| // Task to create default collection for Bedrock KB | ||
| const createDefaultCollectionTask = new tasks.LambdaInvoke(this, 'CreateDefaultCollection', { | ||
| lambdaFunction: createBedrockCollectionFn, | ||
| payload: sfn.TaskInput.fromObject({ | ||
| ragConfig: sfn.JsonPath.objectAt('$.body.ragConfig'), | ||
| }), | ||
| resultPath: '$.collectionResult', | ||
| }); |
There was a problem hiding this comment.
A new task createDefaultCollectionTask has been introduced to create default collections for Bedrock KB. Verify that the createBedrockCollectionFn Lambda function is properly configured to handle the ragConfig payload and that error handling is appropriate for this new task.
| const updateSuccessStatus = new tasks.DynamoUpdateItem(this, 'UpdateSuccessStatus', { | ||
| table: vectorStoreConfigTable, | ||
| key: { repositoryId: tasks.DynamoAttributeValue.fromString(sfn.JsonPath.stringAt('$.body.ragConfig.repositoryId')) }, | ||
| updateExpression: 'SET #status = :status, #stackName = :stackName', | ||
| expressionAttributeNames: { '#status': 'status', '#stackName': 'stackName' }, | ||
| expressionAttributeValues: { | ||
| ':status': tasks.DynamoAttributeValue.fromString('CREATE_COMPLETE'), | ||
| ':stackName': tasks.DynamoAttributeValue.fromString(sfn.JsonPath.stringAt('$.deployResult.stackName') ?? '') | ||
| ':status': tasks.DynamoAttributeValue.fromString(VectorStoreStatus.CREATE_COMPLETE), | ||
| ':stackName': tasks.DynamoAttributeValue.fromString(sfn.JsonPath.stringAt('$.deployResult.stackName')) | ||
| }, | ||
| }); |
There was a problem hiding this comment.
The updateSuccessStatus task now includes stackName in the update expression. The comment indicates that for Bedrock KB without pipelines, stackName may be null. Verify that DynamoDB can handle null values for the stackName attribute or if a default value should be provided instead of sfn.JsonPath.stringAt('$.deployResult.stackName').
| const updateFailureStatus = new tasks.DynamoUpdateItem(this, 'UpdateFailureStatus', { | ||
| table: vectorStoreConfigTable, | ||
| key: { repositoryId: tasks.DynamoAttributeValue.fromString(sfn.JsonPath.stringAt('$.body.ragConfig.repositoryId')) }, | ||
| updateExpression: 'SET #status = :status, #stackName = :stackName', | ||
| expressionAttributeNames: { '#status': 'status', '#stackName': 'stackName' }, | ||
| updateExpression: 'SET #status = :status', | ||
| expressionAttributeNames: { '#status': 'status' }, | ||
| expressionAttributeValues: { | ||
| ':status': tasks.DynamoAttributeValue.fromString('CREATE_FAILED'), | ||
| ':stackName': tasks.DynamoAttributeValue.fromString(sfn.JsonPath.stringAt('$.deployResult.stackName')) | ||
| ':status': tasks.DynamoAttributeValue.fromString(VectorStoreStatus.CREATE_FAILED) | ||
| }, | ||
| }); |
There was a problem hiding this comment.
The updateFailureStatus task has been simplified compared to the old version. The old version set both status and stackName, but the new version only sets status. Verify this is intentional and that not updating stackName on failure won't cause issues with downstream processes or monitoring.
| // Check if this is a Bedrock KB repository to create default collections | ||
| const skipCollectionCreation = new sfn.Pass(this, 'SkipCollectionCreation'); | ||
|
|
||
| const checkIfBedrockKB = new sfn.Choice(this, 'IsBedrockKB?') | ||
| .when( | ||
| sfn.Condition.stringEquals('$.body.ragConfig.type', 'bedrock_knowledge_base'), | ||
| createDefaultCollectionTask | ||
| ) | ||
| .otherwise(skipCollectionCreation); | ||
|
|
||
| // Both paths converge to update success status | ||
| createDefaultCollectionTask.next(updateSuccessStatus); | ||
| skipCollectionCreation.next(updateSuccessStatus); |
There was a problem hiding this comment.
A new conditional flow has been introduced to check if the repository is a Bedrock KB and conditionally create default collections. Verify that the condition '$.body.ragConfig.type' === 'bedrock_knowledge_base' correctly identifies Bedrock KB repositories and that the skipCollectionCreation pass state properly handles non-Bedrock KB types.
| sfn.Condition.stringEquals('$.deployResult.status', VectorStoreStatus.CREATE_IN_PROGRESS), | ||
| sfn.Condition.stringEquals('$.deployResult.status', VectorStoreStatus.UPDATE_IN_PROGRESS), | ||
| sfn.Condition.stringEquals('$.deployResult.status', VectorStoreStatus.UPDATE_COMPLETE_CLEANUP_IN_PROGRESS), |
There was a problem hiding this comment.
The status comparisons now use VectorStoreStatus enum constants instead of hardcoded strings. Ensure all enum values referenced here (CREATE_IN_PROGRESS, UPDATE_IN_PROGRESS, UPDATE_COMPLETE_CLEANUP_IN_PROGRESS) are defined in the VectorStoreStatus enum.
| sfn.Condition.stringEquals('$.deployResult.status', VectorStoreStatus.CREATE_COMPLETE), | ||
| sfn.Condition.stringEquals('$.deployResult.status', VectorStoreStatus.UPDATE_COMPLETE), |
There was a problem hiding this comment.
The status comparisons now use VectorStoreStatus enum constants instead of hardcoded strings. Ensure all enum values referenced here (CREATE_COMPLETE, UPDATE_COMPLETE) are defined in the VectorStoreStatus enum.
There was a problem hiding this comment.
Files selected (1)
- lambda/utilities/common_functions.py (5)
Review comments generated (3)
- Review: 3
- LGTM: 0
Tips
Chat with AI reviewer (/reviewbot)
- Reply on review comments left by this bot to ask follow-up questions. A review comment is a comment on a diff or a file.
- Invite the bot into a review comment chain by tagging
/reviewbotin a reply.
Code suggestions
- The bot may make code suggestions, but please review them carefully before committing since the line number ranges may be misaligned.
- You can edit the comment made by the bot and manually tweak the suggestion if it is slightly off.
Pausing incremental reviews
- Add
/reviewbot: ignoreanywhere in the PR description to pause further reviews from the bot.
| from datetime import datetime | ||
| from decimal import Decimal | ||
| from functools import cache | ||
| from typing import Any, Callable, cast, Dict, List, Optional, TypeVar, Union | ||
| from typing import Any, Callable, cast, Dict, Optional, TypeVar, Union |
There was a problem hiding this comment.
The import statement has inconsistent indentation. Line 24 has leading whitespace that should be removed to align with the other imports.
| from datetime import datetime | |
| from decimal import Decimal | |
| from functools import cache | |
| from typing import Any, Callable, cast, Dict, List, Optional, TypeVar, Union | |
| from typing import Any, Callable, cast, Dict, Optional, TypeVar, Union | |
| from datetime import datetime | |
| from decimal import Decimal | |
| from functools import cache | |
| from typing import Any, Callable, cast, Dict, Optional, TypeVar, Union |
| # Check for ValidationError from utilities.validation | ||
| status_code = 400 | ||
| if hasattr(e, "response"): # i.e. validate the exception was from an API call | ||
| error_message: str | ||
| if type(e).__name__ == "ValidationError": | ||
| error_message = str(e) | ||
| logger.exception(e) | ||
| elif hasattr(e, "response"): # i.e. validate the exception was from an API call | ||
| metadata = e.response.get("ResponseMetadata") | ||
| if metadata: | ||
| status_code = metadata.get("HTTPStatusCode", 400) | ||
| error_message = str(e) | ||
| logger.exception(e) | ||
| elif hasattr(e, "http_status_code"): | ||
| status_code = e.http_status_code | ||
| e = e.message # type: ignore [assignment] | ||
| error_message = getattr(e, "message", str(e)) | ||
| logger.exception(e) | ||
| elif hasattr(e, "status_code"): | ||
| status_code = e.status_code | ||
| e = e.message # type: ignore [assignment] | ||
| error_message = getattr(e, "message", str(e)) | ||
| logger.exception(e) | ||
| else: | ||
| error_msg = str(e) | ||
| if error_msg in ["'requestContext'", "'pathParameters'", "'body'"]: | ||
| e = f"Missing event parameter: {error_msg}" # type: ignore [assignment] | ||
| error_message = f"Missing event parameter: {error_msg}" | ||
| else: | ||
| e = f"Bad Request: {error_msg}" # type: ignore [assignment] | ||
| error_message = f"Bad Request: {error_msg}" | ||
| logger.exception(e) | ||
| return generate_html_response(status_code, e) # type: ignore [arg-type] | ||
| return generate_html_response(status_code, error_message) # type: ignore [arg-type] |
There was a problem hiding this comment.
The error handling logic has inconsistent indentation throughout this block. Multiple lines have incorrect leading whitespace (lines 268, 274, 275, 278, 279, 282, 283, 286, 287, 288). Additionally, the variable naming has changed from reassigning e to using error_message, which is good, but the indentation must be corrected for the code to be valid Python.
| # Check for ValidationError from utilities.validation | |
| status_code = 400 | |
| if hasattr(e, "response"): # i.e. validate the exception was from an API call | |
| error_message: str | |
| if type(e).__name__ == "ValidationError": | |
| error_message = str(e) | |
| logger.exception(e) | |
| elif hasattr(e, "response"): # i.e. validate the exception was from an API call | |
| metadata = e.response.get("ResponseMetadata") | |
| if metadata: | |
| status_code = metadata.get("HTTPStatusCode", 400) | |
| error_message = str(e) | |
| logger.exception(e) | |
| elif hasattr(e, "http_status_code"): | |
| status_code = e.http_status_code | |
| e = e.message # type: ignore [assignment] | |
| error_message = getattr(e, "message", str(e)) | |
| logger.exception(e) | |
| elif hasattr(e, "status_code"): | |
| status_code = e.status_code | |
| e = e.message # type: ignore [assignment] | |
| error_message = getattr(e, "message", str(e)) | |
| logger.exception(e) | |
| else: | |
| error_msg = str(e) | |
| if error_msg in ["'requestContext'", "'pathParameters'", "'body'"]: | |
| e = f"Missing event parameter: {error_msg}" # type: ignore [assignment] | |
| error_message = f"Missing event parameter: {error_msg}" | |
| else: | |
| e = f"Bad Request: {error_msg}" # type: ignore [assignment] | |
| error_message = f"Bad Request: {error_msg}" | |
| logger.exception(e) | |
| return generate_html_response(status_code, e) # type: ignore [arg-type] | |
| return generate_html_response(status_code, error_message) # type: ignore [arg-type] | |
| # Check for ValidationError from utilities.validation | |
| status_code = 400 | |
| error_message: str | |
| if type(e).__name__ == "ValidationError": | |
| error_message = str(e) | |
| logger.exception(e) | |
| elif hasattr(e, "response"): # i.e. validate the exception was from an API call | |
| metadata = e.response.get("ResponseMetadata") | |
| if metadata: | |
| status_code = metadata.get("HTTPStatusCode", 400) | |
| error_message = str(e) | |
| logger.exception(e) | |
| elif hasattr(e, "http_status_code"): | |
| status_code = e.http_status_code | |
| error_message = getattr(e, "message", str(e)) | |
| logger.exception(e) | |
| elif hasattr(e, "status_code"): | |
| status_code = e.status_code | |
| error_message = getattr(e, "message", str(e)) | |
| logger.exception(e) | |
| else: | |
| error_msg = str(e) | |
| if error_msg in ["'requestContext'", "'pathParameters'", "'body'"]: | |
| error_message = f"Missing event parameter: {error_msg}" | |
| else: | |
| error_message = f"Bad Request: {error_msg}" | |
| logger.exception(e) | |
| return generate_html_response(status_code, error_message) # type: ignore [arg-type] |
| return f"{lisa_api_endpoint}/{os.environ['REST_API_VERSION']}/serve" | ||
|
|
||
|
|
||
| def get_username(event: dict) -> str: | ||
| """Get the username from the event.""" | ||
| username: str = event.get("requestContext", {}).get("authorizer", {}).get("username", "system") | ||
| return username | ||
|
|
||
|
|
||
| def get_session_id(event: dict) -> str: | ||
| """Get the session ID from the event.""" | ||
| session_id: str = event.get("pathParameters", {}).get("sessionId") | ||
| return session_id | ||
|
|
||
|
|
||
| def get_groups(event: Any) -> List[str]: | ||
| """Get user groups from event.""" | ||
| groups: List[str] = json.loads(event.get("requestContext", {}).get("authorizer", {}).get("groups", "[]")) | ||
| return groups | ||
|
|
||
|
|
||
| def get_principal_id(event: Any) -> str: | ||
| """Get principal from event.""" | ||
| principal: str = event.get("requestContext", {}).get("authorizer", {}).get("principal", "") |
There was a problem hiding this comment.
The removal of get_username() and get_groups() functions suggests a refactoring toward a consolidated get_user_context() function as mentioned in the PR description. However, this is a breaking change for any code that directly calls these removed functions. Verify that all internal callers have been updated to use the new consolidated function, or consider deprecating these functions gradually rather than removing them outright.
|
|
||
| Customers can set up multiple ingestion pipelines for a repository. For each pipeline they define: | ||
| - The target repository and collection | ||
| - Embedding model (inherited from repository if not defined) |
There was a problem hiding this comment.
The statement 'Embedding model (inherited from repository if not defined)' is ambiguous. Clarify whether the embedding model is always inherited from the repository for pipelines, or if pipelines can specify their own embedding model independent of the repository setting.
| - **Chunking Strategy**: Optimized for the content type (fixed size or none) | ||
| - **Embedding Model**: Inherited from repository or customized per collection | ||
| - **Access Control**: User group restrictions inherited from the repository or customized per collection |
There was a problem hiding this comment.
The documentation states that Embedding Model is 'Inherited from repository or customized per collection' and Access Control is 'inherited from the repository or customized per collection', but line 224 in the response example shows embeddingModel is inherited from parent repository without customization option. Clarify whether collections can truly customize their embedding model or if it's always inherited.
| - **Default Strategy**: Inherited from the repository configuration | ||
| - **Collection Strategy**: Override at the collection level for content-specific optimization | ||
| - **Pipeline Strategy**: Further override at the ingestion pipeline level | ||
| - **API Override**: Optionally allow per-document chunking strategy via API (controlled by `allowChunkingOverride` flag) |
There was a problem hiding this comment.
The allowChunkingOverride flag is mentioned here as controlling per-document chunking strategy via API, but this flag is not documented in the Collection creation request example (line 202). Clarify the scope and usage of this flag in the API documentation.
| - **Repository-level Groups**: Collections inherit allowed groups from their parent repository by default | ||
| - **Collection-level Groups**: Collections can override with their own group restrictions for finer control | ||
| - **Admin Access**: Administrators have full access to all collections across all repositories | ||
| - **User Collection Creation**: Repositories can be configured to allow or restrict user-created collections via the `allowUserCollections` flag |
There was a problem hiding this comment.
The allowUserCollections flag is introduced here for the first time in the permissions section, but it was already mentioned in the repository creation example (line 160). Consider moving this explanation earlier in the document when repositories are first introduced, or consolidate the repository configuration details.
There was a problem hiding this comment.
Files selected (6)
- CHANGELOG.md (2)
- README.md (1)
- lib/docs/admin/architecture.md (2)
- lib/docs/config/mcp.md (1)
- lib/docs/user/breaking-changes.md (1)
- lib/user-interface/react/src/components/configuration/ActivatedUserComponents.tsx (3)
Files ignored due to filter (4)
- lib/docs/assets/LisaArchitecture.png
- lib/docs/assets/LisaChat.png
- lib/docs/assets/LisaMcp.png
- lib/docs/assets/LisaServe.png
Files skipped from review due to trivial changes (3)
- CHANGELOG.md
- lib/docs/config/mcp.md
- lib/user-interface/react/src/components/configuration/ActivatedUserComponents.tsx
Review comments generated (12)
- Review: 12
- LGTM: 0
Tips
Chat with AI reviewer (/reviewbot)
- Reply on review comments left by this bot to ask follow-up questions. A review comment is a comment on a diff or a file.
- Invite the bot into a review comment chain by tagging
/reviewbotin a reply.
Code suggestions
- The bot may make code suggestions, but please review them carefully before committing since the line number ranges may be misaligned.
- You can edit the comment made by the bot and manually tweak the suggestion if it is slightly off.
Pausing incremental reviews
- Add
/reviewbot: ignoreanywhere in the PR description to pause further reviews from the bot.
| @@ -1,14 +1,27 @@ | |||
| # LLM Inference Solution for Amazon Dedicated Cloud (LISA) | |||
| [](https://awslabs.github.io/LISA/) | |||
| [](mailto:lisa-product-team@amazon.com) | |||
There was a problem hiding this comment.
The 'Contact Us' link has been added, which is good for user engagement. However, verify that the email address lisa-product-team@amazon.com is actively monitored and appropriate for production documentation.
| [](mailto:lisa-product-team@amazon.com) | ||
| ## What is LISA? | ||
| Our large language model (LLM) inference solution for the Amazon Dedicated Cloud (ADC), LISA, is an open source infrastructure-as-code solution. Customers deploy LISA directly into an Amazon Web Services (AWS) account. While specially designed for ADC regions that support government customers' most sensitive workloads, LISA is also compatible with commercial regions. LISA supports model self-hosting via Amazon Elastic Container Service (ECS). LISA's LiteLLM support also makes it compatible with 100+ models hosted by external model providers, including Amazon Bedrock. LISA further complements Amazon Bedrock by accelerating GenAI adoption. LISA's optional chat assistant user interface (UI) supports model management, model prompting, document summarization, chat session management, prompt libraries, retrieval augmented generation (RAG), automated document ingestion pipelines, and other advanced features. Customers can choose to integrate custom UIs directly with LISA, relying on LISA for centralized model orchestration, chat session management, and RAG. LISA is scalable and ready to support production use cases. The roadmap is customer-driven, with new capabilities launching monthly. | ||
| Our large language model (LLM) inference solution for the Amazon Dedicated Cloud (ADC), LISA, is open source infrastructure-as-code. Customers deploy it directly into an Amazon Web Services (AWS) account in any region. LISA is scalable and ready to support production use cases. |
There was a problem hiding this comment.
The description has been simplified from 'an open source infrastructure-as-code solution' to 'open source infrastructure-as-code', but the removal of context about ADC regions and government customers may lose important positioning information. Consider whether this simplification aligns with the product's target audience and marketing strategy.
| Our large language model (LLM) inference solution for the Amazon Dedicated Cloud (ADC), LISA, is an open source infrastructure-as-code solution. Customers deploy LISA directly into an Amazon Web Services (AWS) account. While specially designed for ADC regions that support government customers' most sensitive workloads, LISA is also compatible with commercial regions. LISA supports model self-hosting via Amazon Elastic Container Service (ECS). LISA's LiteLLM support also makes it compatible with 100+ models hosted by external model providers, including Amazon Bedrock. LISA further complements Amazon Bedrock by accelerating GenAI adoption. LISA's optional chat assistant user interface (UI) supports model management, model prompting, document summarization, chat session management, prompt libraries, retrieval augmented generation (RAG), automated document ingestion pipelines, and other advanced features. Customers can choose to integrate custom UIs directly with LISA, relying on LISA for centralized model orchestration, chat session management, and RAG. LISA is scalable and ready to support production use cases. The roadmap is customer-driven, with new capabilities launching monthly. | ||
| Our large language model (LLM) inference solution for the Amazon Dedicated Cloud (ADC), LISA, is open source infrastructure-as-code. Customers deploy it directly into an Amazon Web Services (AWS) account in any region. LISA is scalable and ready to support production use cases. | ||
|
|
||
| LISA accelerates GenAI adoption by offering built-in configurability with Amazon Bedrock models, Knowledge Bases, and Guardrails. Also by offering advanced capabilities like an optional enterprise-ready chat user interface (UI) with configurable features, authentication, resource access control, centralized model orchestration via LiteLLM, model self-hosting via Amazon ECS, retrieval augmented generation (RAG), APIs, and broad model context protocol (MCP) support and features. LISA is also compatible with OpenAI’s API specification making it easily configurable with supporting solutions. For example, the Continue plugin for VSCode and JetBrains integrated development environments (IDE). |
There was a problem hiding this comment.
The new description is more concise but removes specific details about ECS, Bedrock integration, and use cases (document summarization, prompt libraries, etc.) that were in the original. Ensure this level of abstraction is intentional and doesn't obscure key capabilities from new users.
| * **FedRAMP**: Leverages FedRAMP High compliant services. | ||
|
|
||
| ## Major Components | ||
| LISA’s four major components include Serve, a Chat UI, RAG, and MCP. LISA Serve and LISA MCP are standalone, foundational core solutions with APIs for customers not leveraging LISA’s Chat UI. Both LISA’s Chat UI and RAG are optional components, but must be used with Serve. |
There was a problem hiding this comment.
The statement 'LISA Serve and LISA MCP are standalone, foundational core solutions' introduces LISA MCP as a major component, which aligns with the v6.0.0 release. However, clarify whether LISA MCP requires Serve as a dependency or if it is truly independent, as the current wording could be ambiguous.
| tooling or alternative front ends. LISA uses Amazon DynamoDB to store Tokens to interact with the exposed APIs. | ||
| * Inference requests through LiteLLM support prompting LLMs configured with LISA. Prompts can support LISA’s RAG and | ||
| MCP and features. | ||
| LISA’s four major components include Serve, a Chat user interface (UI), retrieval augmented generation (RAG), and model context protocol (MCP). |
There was a problem hiding this comment.
The statement "LISA's four major components" should be verified against the actual component count. The list shows: Serve, Chat UI, RAG, and MCP. However, the description later treats APIs as a separate section. Clarify whether APIs are a component or a feature of Serve/MCP.
| **LISA’s chat UI features include:** | ||
| * RAG operations are managed through `lambda/rag/lambda_functions.py`, which handles embedding generation and document retrieval via OpenSearch and PostgreSQL. | ||
| * Direct requests to the LISA Serve ALB entrypoint must utilize the OpenAI API spec, which we support through the use of the LiteLLM proxy. | ||
| * LISA supports OpenAI's API spec, which means LISA can be easily configured with the Continue plugin for use with Jetbrains or VS Code integrated development environments (IDE). |
There was a problem hiding this comment.
The text references "Continue plugin for use with Jetbrains or VS Code integrated development environments (IDE)" but this appears to be a Chat UI feature, not a Serve-specific feature. Consider moving this to the Chat UI section or clarifying the context.
| ## LISA MCP | ||
|  | ||
|
|
||
| LISA MCP is a standalone product that provides scalable infrastructure for deploying and hosting Model Context Protocol (MCP) servers. It allows customers to self-host MCP servers for enterprise use. LISA MCP can be deployed independently of LISA Serve or configured to work seamlessly with LISA Serve and the Chat UI. |
There was a problem hiding this comment.
The description states LISA MCP "can be deployed independently of LISA Serve or configured to work seamlessly with LISA Serve and the Chat UI." However, line 5 states "Both LISA's Chat UI and RAG are optional components, but must be used with Serve." Clarify whether MCP has different deployment requirements than Chat UI and RAG.
| * MCP Server Lifecycle: Lifecycle operations such as create, update, delete, start, and stop are orchestrated by Step Functions workflows (`CreateMcpServer`, `UpdateMcpServer`, `DeleteMcpServer`). The MCP API Handler Lambda validates requests and manages server metadata in DynamoDB. | ||
| * CloudFormation: Infrastructure components are provisioned using CloudFormation templates synthesized by the MCP server deployer Lambda, as defined in `mcp_server_deployer/src/lib/ecsMcpServer.ts`. | ||
| * ECS Fargate: Each MCP server runs in its own ECS Fargate cluster with dedicated ALB and NLB. The Fargate cluster configuration is located in `mcp_server_deployer/src/lib/ecsFargateCluster.ts`. | ||
| * Authentication: API Gateway enforces the same Lambda authorizer used across LISA (JWT validation + optional API key checks). The `{LISA_BEARER_TOKEN}` placeholder in connection details is automatically replaced with the user's bearer token at connection time. |
There was a problem hiding this comment.
The technical note mentions {LISA_BEARER_TOKEN} placeholder replacement at connection time. Verify this mechanism is documented in the API authentication section and that this behavior is consistent with other LISA components.
|
|
||
| * Prompting text and image generation LLMs and receiving responses | ||
| * Viewing, deleting, and exporting chat history | ||
| * Supports streaming responses, viewing metadata, RAG citations |
There was a problem hiding this comment.
The feature list now includes "RAG citations" which is new. Verify this feature is actually implemented in v6.0.0 and documented in the RAG Collections section, as it's not mentioned in the PR description.
| * RAG document library | ||
| * Uploading docs into non-RAG in context | ||
| * Non-RAG in context Document summarization feature | ||
| * Model Context Protocol (MCP) support for LISA MCP, along with MCP Workbench, and third party MCP Connections features |
There was a problem hiding this comment.
The text mentions "MCP Workbench, and third party MCP Connections features" but these are not described in the LISA MCP section above. Either add descriptions of these features or clarify their scope in the MCP section.
4 participants
v6.0.0
Happy Thanksgiving! We are proud to announce the launch of our next major version, 6.0.0! This launch aligns with AWS re:invent in Las Vegas from Dec 1-5th. LISA 6.0.0 includes major enhancements to LISA's RAG capabilities. It also includes a new standalone solution, LISA MCP.
We hope you enjoy this release as much as we enjoyed building it. Please reach out to our product team via the "Contact us" button in the readme. Our product roadmap is customer driven, and we want to hear your feedback, questions, and needs as we look to 2026.
Breaking Changes
LisaServeTokenTable→LisaApiBaseTokenTable). Export all existing API keys before upgrading and recreate them in the new table after deployment. This affects admin keys, service accounts, and any programmatic API access.${deploymentName}-management-key(removedlisa-prefix). Update any scripts or integrations that reference the secret by name. The secret value will be auto-generated during deployment; export from AWS Secrets Manager before upgrading if you need to preserve the existing value. Code using the SSM parameter${deploymentPrefix}/appManagementKeySecretNamewill continue to work without changes.Key Features
LISA MCP
LISA MCP is a standalone infrastructure-as-code solution that allows administrators to deploy and host any Model Context Protocol (MCP) servers directly within LISA. This enterprise hosting platform provides turn-key infrastructure deployment, automatic scaling, and secure networking, allowing organizations to build and operate custom MCP tools without managing underlying infrastructure.
Enterprise Hosting Capabilities
Administrative Control
Integration & Extensibility
mcp-proxyand exposed over HTTP, simplifying deployment of standard MCP server implementations/mcp), providing flexibility for automation and programmatic workflowsLISA RAG Collections
LISA's RAG capabilities just got a major upgrade! We've completely reimagined how you organize and manage RAG documents with the introduction of Collections. Collections transform how you structure your RAG content. Think of repositories as filing cabinets and collections as the organized drawers within—each with its own configuration.
Flexible Document Organization
Intelligent Document Lifecycle Management
Bedrock Knowledge Base Updates
Other Enhancements
Acknowledgements
Full Changelog: https://github.com/awslabs/LISA/compare/v5.4.0..v6.0.0
Summary (generated)
Version 6.0.0 Release Summary
Overview
Version 6.0.0 represents a major release introducing significant infrastructure enhancements, new features, and breaking changes to the LISA platform.
Major Features
1. LISA MCP (Model Context Protocol) Solution
2. RAG Collections Infrastructure
3. CI/CD Pipeline Enhancements
Breaking Changes
API Token Table Migration
Management Key Secret Relocation
Bedrock Knowledge Base Repository Redeployment
RAG Configuration Updates
Infrastructure Improvements
Centralized Configuration Management
managementKeySecretNameas parameterAPI Enhancements
apiGatewayConfig.domainNameAuthentication Refactoring
get_user_context()function for centralized user information retrievaluser_has_group_access()function for group-based access controlBackend Enhancements
Repository Management
Utility Modules
User Interface Updates
Navigation Enhancements
RAG Configuration
Configuration Updates
Schema Enhancements
Environment Configuration
.kiro/and.amazonq/directories from version controlDocumentation
Note: Please review the breaking changes section carefully and follow the required migration steps before upgrading to version 6.0.0.