-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
base: main
Are you sure you want to change the base?
Conversation
38bebc7
to
227d755
Compare
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'; |
There was a problem hiding this comment.
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.
af1b2e7
to
138c08a
Compare
|
||
const LOGO_BASE_64 = { | ||
bedrock: async () => { | ||
const svg = await import('!!raw-loader!./bedrock.svg'); |
There was a problem hiding this comment.
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?
Regarding the question of
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. |
There was a problem hiding this 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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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)
const Gemini = getReactComponentLogo('gemini'); | ||
|
||
return ( | ||
<div><Logo /></div> | ||
); |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
Having discussed it offline( |
24339ed
to
0d2dfc1
Compare
⏳ Build in-progress, with failures
Failed CI Steps
Test Failures
History
|
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 thestackConnectors
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.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 topackages/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
@kbn/stack-connectors
?raw-loader
invocation for thebase64
encoding?Next steps
@kbn/stack-connectors-plugin
with this package.