-
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
[Inference] create the @kbn/inference-common
package
#193464
[Inference] create the @kbn/inference-common
package
#193464
Conversation
@kbn/inference-common
package
/ci |
/ci |
/ci |
/ci |
/ci |
/ci |
/ci |
/ci |
/ci |
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.
message: string = i18n.translate('xpack.inference.internalError', { | ||
defaultMessage: 'An internal error occurred', | ||
}), | ||
message = 'An internal error occurred', |
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.
question: why did we un-internationalize this string?
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.
We never i18n-ize technical errors. ES doesn't, Kibana doesn't.
@@ -15,3 +15,7 @@ export type ChatCompleteRequestBody = { | |||
messages: Message[]; | |||
functionCalling?: FunctionCallingMode; | |||
} & ToolOptions; | |||
|
|||
export interface GetConnectorsResponseBody { |
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.
Why are these types not extracted to the inference-common
package? Is it because they aren't used outside of the inference
plugin?
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.
Correct, those are the types for the response payloads of the http APIs, it's only used internally by the plugin.
export function createToolNotFoundError(name: string): ChatCompletionToolNotFoundError { | ||
return new InferenceTaskError( | ||
ChatCompletionErrorCode.ToolNotFoundError, | ||
`Tool ${name} called but was not available`, |
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.
Does this need i18n
?
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.
Same as #193464 (comment) - I'd say no (fwiw this was only moved, not introduced by the PR)
|
||
export const generateEsqlTask = <TToolOptions extends ToolOptions>({ | ||
chatCompleteApi, | ||
export const generateEsqlTaskFn = <TToolOptions extends ToolOptions>({ |
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.
The changes in the nl_to_esql
directory appear to be more substantial than (& unrelated to?) type/utility extraction. Can you help me understand the context for these changes?
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.
Oh right, I realized I did not mention anything on that part, sorry...
There are two things:
- I refactored the flow of the task to use a shared output observable instead of chaining observable calls (which was a nightmare to follow and to evolve, it's way easier to add steps and flow now)
- I introduced a summarizing pre-step, to see the effect on generation efficiency, but the step is disabled by default and there's no way to enable it from production usages atm (it's only for testing via evaluation)
(3. I apparently also tweaked a few prompts, from evaluation tuning I did a while ago - the PR root is old)
That refactor is definitely something I want to merge, but tell me if we're not comfortable mixings things in that PR, I can extract those changes elsewhere.
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 it's not too much, maybe it's good to pull the changes to the ES|QL task out and into a separate PR, and then we can run the evaluation suites on both sides against it?
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.
Agreed. I actually forgot I used that other PR as base for those changes... I will revert that part from there
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 for future me: kbx-xxx-nl-to-esql-refactor-2
* Run the query through the kibana | ||
* @param query | ||
*/ | ||
export const validateQueryAst = async (query: string): Promise<QuerySyntaxError[]> => { |
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.
Perhaps out of scope or premature, but this feels like something that should exist within an es|ql 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.
Yeah, I want to take a closer look at the ESQL task later, as I'd like to even extract it from the inference
plugin (this is a task, not part of the inference plugin/framework), but I was planning on doing it on a distinct PR as it's still not totally clear to me how exactly we should restructure.
(but fwiw, not sure it would benefit from living into an esql package rather than with the task esql, the function already mostly depend on low-level ESQL directives)
import { isToolValidationError } from '../../common/chat_complete/errors'; | ||
import { ToolChoiceType } from '../../common/chat_complete/tools'; | ||
import { ToolChoiceType } from '@kbn/inference-common'; | ||
import { isToolValidationError } from '@kbn/inference-common/src/chat_complete/errors'; |
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.
nit: should we be reaching this far into the inference-common
package for the import?
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.
Agreed, we absolutely need to do that |
@elasticmachine merge upstream |
⏳ Build in-progress
History
|
Starting backport for target branches: 8.x |
💔 All backports failed
Manual backportTo create the backport manually run:
Questions ?Please refer to the Backport tool documentation |
## Summary At the moment, all inference API related types and utilities (`chatComplete`, `output` and more) are living inside the `inference` plugin's common folder. This is somewhat problematic because it forces any consumers of those types to explicitly depends on the `inference` plugin (via plugin dep or ts ref), which could lead to any kind of cyclic dependency issues, in addition to being overall a bad design pattern. This also makes it more complicated that it should to try to split the inference logic / task framework / task implementation into distinct packages or plugins, due to some (concrete) utilities living in the inference plugin's code. It's also a bad experience for consumers, as it's quite difficult to easily resolve imports they need (we're mixing internal and public exports atm, plus not all types are exported from a single entry point, making it very tedious to find the right path for each individual import we need to consume the inference APIs) This PR addresses most of those points, by introducing a new `@kbn/inference-common` package and moving all the low level types and utilities to it, while exposing all of them from the package's entrypoint. --------- Co-authored-by: kibanamachine <[email protected]> Co-authored-by: Elastic Machine <[email protected]>
Friendly reminder: Looks like this PR hasn’t been backported yet. |
Friendly reminder: Looks like this PR hasn’t been backported yet. |
## Summary At the moment, all inference API related types and utilities (`chatComplete`, `output` and more) are living inside the `inference` plugin's common folder. This is somewhat problematic because it forces any consumers of those types to explicitly depends on the `inference` plugin (via plugin dep or ts ref), which could lead to any kind of cyclic dependency issues, in addition to being overall a bad design pattern. This also makes it more complicated that it should to try to split the inference logic / task framework / task implementation into distinct packages or plugins, due to some (concrete) utilities living in the inference plugin's code. It's also a bad experience for consumers, as it's quite difficult to easily resolve imports they need (we're mixing internal and public exports atm, plus not all types are exported from a single entry point, making it very tedious to find the right path for each individual import we need to consume the inference APIs) This PR addresses most of those points, by introducing a new `@kbn/inference-common` package and moving all the low level types and utilities to it, while exposing all of them from the package's entrypoint. --------- Co-authored-by: kibanamachine <[email protected]> Co-authored-by: Elastic Machine <[email protected]> (cherry picked from commit 631ccb0) # Conflicts: # .github/CODEOWNERS
#199002) # Backport This will backport the following commits from `main` to `8.x`: - [Inference] create the `@kbn/inference-common` package (#193464) (631ccb0) <!--- Backport version: 8.9.8 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Pierre Gayvallet","email":"[email protected]"},"sourceCommit":{"committedDate":"2024-11-01T09:08:44Z","message":"[Inference] create the `@kbn/inference-common` package (#193464)\n\n## Summary\r\n\r\nAt the moment, all inference API related types and utilities\r\n(`chatComplete`, `output` and more) are living inside the `inference`\r\nplugin's common folder.\r\n\r\nThis is somewhat problematic because it forces any consumers of those\r\ntypes to explicitly depends on the `inference` plugin (via plugin dep or\r\nts ref), which could lead to any kind of cyclic dependency issues, in\r\naddition to being overall a bad design pattern.\r\n\r\nThis also makes it more complicated that it should to try to split the\r\ninference logic / task framework / task implementation into distinct\r\npackages or plugins, due to some (concrete) utilities living in the\r\ninference plugin's code.\r\n\r\nIt's also a bad experience for consumers, as it's quite difficult to\r\neasily resolve imports they need (we're mixing internal and public\r\nexports atm, plus not all types are exported from a single entry point,\r\nmaking it very tedious to find the right path for each individual import\r\nwe need to consume the inference APIs)\r\n\r\nThis PR addresses most of those points, by introducing a new\r\n`@kbn/inference-common` package and moving all the low level types and\r\nutilities to it, while exposing all of them from the package's\r\nentrypoint.\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine <[email protected]>\r\nCo-authored-by: Elastic Machine <[email protected]>","sha":"631ccb031ca59d51b5db0939cf6327e36e5a34b3"},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[]}] BACKPORT-->
Summary
At the moment, all inference API related types and utilities (
chatComplete
,output
and more) are living inside theinference
plugin's common folder.This is somewhat problematic because it forces any consumers of those types to explicitly depends on the
inference
plugin (via plugin dep or ts ref), which could lead to any kind of cyclic dependency issues, in addition to being overall a bad design pattern.This also makes it more complicated that it should to try to split the inference logic / task framework / task implementation into distinct packages or plugins, due to some (concrete) utilities living in the inference plugin's code.
It's also a bad experience for consumers, as it's quite difficult to easily resolve imports they need (we're mixing internal and public exports atm, plus not all types are exported from a single entry point, making it very tedious to find the right path for each individual import we need to consume the inference APIs)
This PR addresses most of those points, by introducing a new
@kbn/inference-common
package and moving all the low level types and utilities to it, while exposing all of them from the package's entrypoint.