Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ai][assistant] Create package for logos and other static information for AI Assistant #203191

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

clintandrewhall
Copy link
Contributor

@clintandrewhall clintandrewhall commented Dec 5, 2024

This is a prerequisite for the Unified AI Assistant. It is part of a much larger set of changes coming soon for the Unified AI UX.

Summary

This PR is an attempt to extract common service provider information out of the @kbn/stack-connectors-plugin into a package. By importing from the stackConnectors plugin, we introduce a dependency on the plugin bundle, as well as break the package-plugin import relationship we try to maintain.

This would also allow for a single source of truth for logos and display names in an AI Assistant context.

It creates two packages:

@kbn/ai-service-providers

A static package containing logos, display names, connector type IDs and other information regarding AI service providers.

This was derived from @kbn/stack-connectors-plugin in order to be more centralized and portable, (we shouldn't have packages depending on static code from a plugin).

We can choose to move other connectors relevant to AI to this package, or, simply rework it to contain static stack connector information. This would depend on feedback from @elastic/response-ops.

Logos

This package provides provider logos as async React components, base64-encoded strings and pure URLs. Each has its use case and pros/cons: for example, URL-based SVGs (which are commonly used) don't respond to light/dark mode changes, but are smaller and more portable. React components, by contrast, respond to light/dark mode changes, but obviously require React to render.

All are compatible with EuiIcon.

@kbn/ai-assistant-service-providers

A subset plugin, meant to only include service providers compatible with the AI Assistant. As @kbn/ai-service-providers expands, this would keep the providers consistent.

Note: This PR does not move other off-usages of logos and names to this package. That task is left as a follow-up, once this is committed. This helps keep the PR small and focused on the package this PR produces, rather than all of the places it's used.

Notes

Rather than assume I could pull all of the logos and information out of @kbn/stack-connectors-plugin into some package, (e.g. @kbn/stack-connector-types), and then go to all of the work to do so, I opted to create @kbn/ai-service-providers.

Naming and contents

Honestly, I kind of expect the name/contents to change as a result of this PR and its discussion. There may be more information we want to relocate to this package, but it's outside the scope of my interest at the moment.

There are still open questions about the display names, e.g. 'Amazon Bedrock' vs. 'Bedrock'. This PR maintains the status quo in both Stack Connectors and the AI Assistant by overriding the name field in the @kbn/ai-assistant-service-providers exports.

Sub-packages for @kbn/ai-assistant

This PR also introduces a packages directory to packages/kbn-ai-assistant. This directory will hold "subpackages" of logic and components that can be co-located with their parent, and yet allow for independent use in places like @kbn/elastic-assistant without having to import the entire @kbn/ai-assistant package.

Open questions

  • Should we move all connector logos to this package and rename it (e.g. @kbn/stack-connectors?
  • @mistic should I change the raw-loader invocation for the base64 encoding?
  • @serenachou How should we reconcile the service name differences, (e.g. 'Amazon Bedrock' in Stack Connectors and 'Bedrock' in AI Assistant visuals? Do they even need to be reconciled?

Next steps

  • (optional) Find and replace imports of logos and names from @kbn/stack-connectors-plugin with this package.

@clintandrewhall clintandrewhall added review release_note:skip Skip the PR/issue when compiling release notes backport:skip This commit does not require backporting v8.18.0 labels Dec 5, 2024
@clintandrewhall clintandrewhall requested review from a team as code owners December 5, 2024 21:51
import OpenAILogo from '../connector_types/openai/logo';
import BedrockLogo from '../connector_types/bedrock/logo';
import GeminiLogo from '../connector_types/bedrock/logo';
import GeminiLogo from '@kbn/ai-service-providers/logo/gemini';
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This obviously feels a bit weird, but it might be appropriate, if @kbn/ai-service-providers only contained AI-capable providers. We might consider renaming the package and moving all stack connector providers to it. But it's not absolutely necessary for the work we're doing with the AI Assistant.

@clintandrewhall clintandrewhall force-pushed the ai/logos branch 2 times, most recently from af1b2e7 to 138c08a Compare December 6, 2024 02:41

const LOGO_BASE_64 = {
bedrock: async () => {
const svg = await import('!!raw-loader!./bedrock.svg');
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mistic How would this need to change with Webpack 5?

@adcoelho
Copy link
Contributor

adcoelho commented Dec 9, 2024

Regarding the question of

Should we move all connector logos to this package and rename it (e.g. @kbn/stack-connectors)?

I asked in the team channel, I'll get back to you on that but at first glance, I don't think there is that much in the other connectors that we would want to move. This might make sense for common service provider information but the other connectors are independent enough that all they need is restricted to their folders.

Copy link
Contributor

@pgayvallet pgayvallet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See comments

@@ -776,10 +776,12 @@ x-pack/examples/ui_actions_enhanced_examples @elastic/appex-sharedux
x-pack/packages/ai-infra/inference-common @elastic/appex-ai-infra
x-pack/packages/ai-infra/product-doc-artifact-builder @elastic/appex-ai-infra
x-pack/packages/ai-infra/product-doc-common @elastic/appex-ai-infra
x-pack/packages/ai/service_providers @elastic/appex-ai-infra
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If @elastic/appex-ai-infra is really supposed to be the owner of those new packages, then please create any ai-infra plugin / package in their new home (see #202410):

  • x-pack/platform/plugins/shared/ai_infra/
  • x-pack/platform/packages/shared/ai-infra/

(Also we don't do nested-nested package in that team, so ai/service_providers will have to get flat)

If that's supposed to be shared ownership, then we probably want something like x-pack/platform/packages/shared/gen-ai/* or similar?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(note: the core team added to the repo the script they are using to move packages around, which should significantly reduce the burden of moving those packages where they should belong)

Comment on lines +24 to +28
const Gemini = getReactComponentLogo('gemini');

return (
<div><Logo /></div>
);
Copy link
Contributor

@pgayvallet pgayvallet Dec 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the PR is going into the right direction, but I have concerns mixing things that are shared between browser and server (e.g service Id, service name and so on) and things that are strictly going to be used browser-side, suchs as SVG assets. This seems like an architectural smell to me?

(Unless this package is meant to only be used browser-side, in which case that argument is obviously invalid)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can split them, make the constants and service names in a common package, and the svgs and components in a browser package?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm aware how painful it is to create dozens of mini packages, and I usually try to not force it when not strictly necessary, but in that case (given we have webpack-loader type of imports, that are just not supported on the server), I think that would make sense?

@adcoelho
Copy link
Contributor

Having discussed it offline(response-ops), we decided it would be best if all connector logos were moved to a package named @kbn/stack-connectors-logos. We will benefit from these in the future where there is currently some duplication(connectors in cases e.g.). Thanks for this @clintandrewhall 🙌

@elasticmachine
Copy link
Contributor

elasticmachine commented Dec 17, 2024

⏳ Build in-progress, with failures

Failed CI Steps

Test Failures

  • [job] [logs] Jest Integration Tests #3 / Migration actions - serverless environment reindex & waitForReindexTask resolves right and proceeds to add missing documents if there are some existing docs conflicts
  • [job] [logs] Jest Integration Tests #3 / Migration actions - serverless environment reindex & waitForReindexTask resolves right and proceeds to add missing documents if there are some existing docs conflicts

History

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting release_note:skip Skip the PR/issue when compiling release notes review v8.18.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants